Executive Summary

Security researchers uncovered a stealthy post-exploitation technique affecting Ivanti Endpoint Manager Mobile (EPMM) servers. Instead of immediately deploying ransomware or stealing data, attackers planted dormant in-memory Java web shell loaders at the path:

/mifs/403.jsp

These implants do nothing until specifically triggered. That’s why researchers are calling them “sleeper” shells.

The tradecraft strongly suggests Initial Access Brokers (IABs) are behind this activity. Their goal appears to be securing and maintaining access to compromised Ivanti servers so they can sell that access later to ransomware groups.

This is not smash-and-grab. It’s quiet positioning.

---

What Happened

Organizations running vulnerable Ivanti EPMM instances were exploited through newly disclosed critical vulnerabilities. After successful exploitation:

1. Attackers gained remote code execution on the appliance.
2. They deployed a malicious Java class loader embedded in a JSP file.
3. The loader was placed at /mifs/403.jsp.
4. The loader remains memory-resident and inactive unless triggered.

No ransomware was deployed at the time of discovery. No obvious data theft was observed in many cases. The attacker simply established persistence and stopped.

That is what makes this dangerous.

---

What Is Ivanti EPMM?

Ivanti EPMM (Endpoint Manager Mobile) is an enterprise mobile device management (MDM) solution. It manages:

• Corporate phones
• Tablets
• Mobile apps
• Authentication
• Certificates
• Device compliance policies

Because it integrates with:

• Active Directory / LDAP
• Exchange
• Certificate authorities
• Internal apps

…it often has high privileges and trusted access inside enterprise networks.

Compromising it provides a powerful foothold.

---

How the Attack Worked

1. Initial Access Vector

Attackers exploited publicly disclosed critical vulnerabilities in Ivanti EPMM. These were remote code execution and authentication bypass flaws affecting internet-exposed instances.

The initial vector was:

• Direct internet scanning for vulnerable EPMM servers
• Exploiting the vulnerability via crafted HTTP requests
• Gaining server-side execution inside the application container

No phishing required.
No stolen credentials required.
Just vulnerable exposed appliances.

---

2. Payload Deployment

After exploitation, attackers deployed:

• A malicious JSP file located at: /mifs/403.jsp

This file is not a traditional noisy web shell. Instead, it contains:

• An encoded Java class loader
• Logic to dynamically load classes into JVM memory
• Trigger-based execution conditions

The key point:

• It does not immediately execute commands.
• It does not drop additional malware on disk.
• It does not beacon automatically.

It waits.

---

3. How the Sleeper Shell Works

Here’s what makes it different from a typical web shell:

Traditional Web Shell:

• Executes commands when accessed
• Writes logs
• Often easy to detect via behavior

Sleeper Shell:

• Loads malicious bytecode into memory
• Hooks into JVM runtime
• Only activates when a specific HTTP parameter is supplied
• Can decode and execute arbitrary payloads in memory

The trigger is typically:

• A specific HTTP POST request
• A hidden parameter name
• Base64-encoded command data

Until that happens, the file just sits there looking harmless.

---

Why This Is IAB Tradecraft

This behavior matches Initial Access Broker methodology:

1. Scan for vulnerable infrastructure
2. Exploit and implant persistence
3. Verify access
4. Leave it dormant
5. Sell access weeks or months later

Ransomware groups often prefer buying pre-compromised enterprise access rather than doing the noisy exploitation themselves.

The sleeper shell allows:

• Re-entry at will
• Payload delivery on demand
• Credential harvesting later
• Lateral movement staging

---

What Was Impacted

Directly Impacted:

• Internet-facing Ivanti EPMM servers
• Organizations that had not applied latest patches

Potential Downstream Impact:

Because EPMM connects to:

• Active Directory
• Exchange
• Certificate services
• Mobile authentication tokens

An attacker could pivot into:

• Domain controller compromise
• Email system compromise
• Certificate abuse
• Full enterprise ransomware deployment

Even if nothing has happened yet, compromise of EPMM is serious.

---

Indicators of Compromise (IOCs)

File-Based

Look for:

/mifs/403.jsp

Red flags:

• File modification timestamps that don’t match installation
• Unexpected JSP files in /mifs/
• JSP files with obfuscated Java code
• Base64 blobs inside JSP
• Use of ClassLoader.defineClass

---

Log-Based IOCs

Suspicious HTTP Requests

Look for:

• POST requests to: /mifs/403.jsp
• Requests containing:
  • base64 strings
  • unusual parameters
  • long encoded values
• HTTP 200 responses from /403.jsp (should normally return 403 behavior)

---

Memory Indicators

• Unexpected loaded classes in JVM runtime
• Reflection API usage
• Dynamically defined classes
• ClassLoader abuse
• Unusual Metaspace growth

---

Network Indicators

• Outbound DNS lookups to random or attacker-controlled domains
• Unexpected egress from EPMM server
• Encrypted outbound traffic to unknown IPs

---

Behavioral Indicators

• JVM spawning shell commands
• EPMM service spawning:
  • /bin/sh
  • bash
  • cmd.exe
  • powershell.exe

---

Were Anti-Malware Tools Used?

In most cases:

• Traditional antivirus did NOT detect it.
• EDR may not alert because:
  • No process injection
  • No dropped EXE
  • No persistence in typical registry keys
  • No scheduled tasks

This attack lives inside:

• The application container
• JVM memory
• Legitimate process context

Detection requires:

• Application log inspection
• Web server monitoring
• JVM telemetry
• File integrity monitoring

---

Was Data Stolen?

In early discovery cases:

• No confirmed mass data exfiltration
• No ransomware deployed yet
• No obvious lateral movement

However:
Presence of the sleeper shell = confirmed compromise.

---

Full Breach Timeline

1. Vulnerability disclosed
2. Mass scanning begins
3. Exploit attempt
4. Shell written to /mifs/403.jsp
5. Memory loader deployed
6. Access verified
7. Attacker leaves environment
8. Weeks later:
   • Ransomware affiliate buys access
   • Attacker re-enters
   • Deploys payload via trigger parameter

---

Threat Hunting Guidance

1. Immediate Checks

• Verify patch level of Ivanti EPMM
• Check for existence of /mifs/403.jsp
• Compare file hash against clean baseline
• Review web logs for access to that path

---

2. Log Hunt Queries

Suspicious Access to 403.jsp

index=web_logs
uri_path="/mifs/403.jsp"
| stats count by src_ip, http_method, user_agent

Look for:

• POST method
• Unknown external IPs
• Repeated attempts

---

Large Encoded Parameters

uri_query_length > 200
AND uri_path="/mifs/403.jsp"

---

Suspicious Child Processes

parent_process="java"
AND (process_name="bash" OR process_name="sh" OR process_name="cmd.exe" OR process_name="powershell.exe")

---

3. YARA Detection

rule Ivanti_Sleeper_Shell
{
    strings:
        $base64 = "Base64.getDecoder"
        $loader = "defineClass"
        $reflect = "getDeclaredMethod"
    condition:
        all of them
}

---

4. File Integrity Monitoring

Alert if:

• Any new JSP appears under /mifs/
• 403.jsp modified
• Unexpected file permissions change

---

5. JVM Telemetry Hunting

Monitor for:

• Custom class loaders
• Reflection-based method invocation
• In-memory bytecode loading

---

Remediation Steps

If found:

1. Immediately isolate server
2. Do NOT just delete JSP file
3. Assume credential compromise
4. Rotate:
   • Service accounts
   • LDAP credentials
   • API tokens
5. Check domain controller logs
6. Conduct full memory forensic acquisition
7. Rebuild appliance from known good image

---

Why This Is Dangerous

This is not ransomware.
This is positioning.

It represents:

• Quiet infrastructure pre-staging
• Long-term persistence
• Enterprise-level compromise preparation

By the time ransomware hits, the sleeper shell may have been there for weeks.

---

Risk Level

High.

Even without active exploitation, this technique demonstrates:

• Successful remote code execution
• Stealth persistence
• Delayed operational deployment

---

Final Takeaway

This is a professional, patient intrusion method designed to:

• Stay invisible
• Survive patching
• Be activated on demand
• Be sold as access

If your Ivanti EPMM server was exposed and unpatched during the vulnerable window, assume compromise until proven otherwise.

---