Hackers Exploiting Ivanti EPMM Devices to Deploy Dormant Backdoors

Hackers are actively exploiting Ivanti Endpoint Manager Mobile (EPMM) appliances to plant “dormant” backdoors that can sit unused for days or weeks.

Ivanti recently disclosed two critical EPMM flaws, CVE-2026-1281 and CVE-2026-1340, spanning authentication bypass and remote code execution in different packages (aftstore and appstore).

While the packages differ, defenders face the same practical impact: unauthenticated access to application-level endpoints. Ivanti has published mitigation and patching guidance in its security advisory, but exploitation in the wild followed shortly after disclosure.

Across observed intrusions by Defusedcyber tied to this latest wave, successful exploitation consistently resulted in a dropped artifact at the path /mifs/403.jsp. The filename and location are not new in Ivanti/MobileIron targeting; what’s different is the payload’s purpose.

Instead of deploying an interactive webshell capable of command execution, the attackers delivered a Base64-encoded Java class file via HTTP parameters. Each decoded payload contained valid Java bytecode (the CAFEBABE class header), functioning as a dormant in-memory class loader rather than an immediately usable backdoor.

This distinction matters operationally: traditional webshell hunting often keys on follow-on commands and filesystem artifacts. Here, the attacker’s workflow prioritized “land and confirm,” not “land and operate.”

The implanted class has been observed as base.Info (compiled from Info.java). It does not expose file browsing, command execution, or a typical operator console. Instead, it waits for a later “activation” request that delivers a second Java class, which the loader then runs directly in memory.

Notably, the loader uses equals(Object) as an entry point rather than standard servlet methods like doGet or doPost, a choice that can reduce friction with simplistic detections.

It extracts HttpServletRequest and HttpServletResponse from the supplied object (with fallbacks for PageContext and servlet wrapper/facade patterns), increasing portability across Java web container implementations.

When triggered, the loader checks for an HTTP parameter named k0f53cf964d387. If present, it strips a two-character prefix, Base64-decodes the remaining value into raw bytes, and reflectively calls ClassLoader#defineClass to load the second-stage class without writing to disk.

The loader instantiates the resulting class with basic host context and returns the class’s toString() output to the requester, wrapped in fixed delimiters (3cd3d and e60537) and served as text/html—a format that is easy for automated tooling to parse. For Base64 decoding, it supports both java.util.Base64 (Java 8+) and sun.misc.BASE64Decoder for older JVMs.

Before handing off control, the loader fingerprints the host (for example, user.dir, filesystem roots, OS name, and username) and passes that data to the second-stage class likely to help an operator quickly orient on a target later.

Across all observed cases by Defusedcyber, the loader was deployed and verified, but did not observe follow-on requests supplying a second-stage class. That “implant now, operate later” pattern aligns with initial access broker behavior, where one actor establishes dependable access at scale and another actor later monetizes or weaponizes it from a different infrastructure.

Shadowserver observed that attackers deploy a webshell on Ivanti EPMM devices, possibly exploiting CVE-2026-1281 Vulnerability. According to the scans, 56 IPs were found compromised.