Skip to content
Hermes Codex

Incident Response Playbook: Ivanti EPMM (CVE-2026-1281 & 1340)

1. Vulnerability Mechanics: The Bash Injection

Section titled “1. Vulnerability Mechanics: The Bash Injection”

According to deep-dive research by WatchTowr Labs, the root cause of both vulnerabilities is an improper sanitization flaw leading to OS command injection.

The EPMM architecture utilizes specific API endpoints (/mifs/c/aftstore and /mifs/c/appstore) to handle file uploads and application staging. When processing requests to these endpoints, the backend Java application passes user-supplied input (specifically the theValue parameter) directly into a poorly constructed Bash script executed via Runtime.getRuntime().exec().

By carefully crafting a payload using Bash expansion and command substitution techniques (bypassing simple space and quote filters), an attacker breaks out of the intended execution context and executes arbitrary commands directly on the underlying Linux OS.

2. Phase 1: Log Triage (The 15-Minute Check)

Section titled “2. Phase 1: Log Triage (The 15-Minute Check)”

The primary objective is to determine if an exploitation attempt occurred and whether it was successful. This requires analyzing the Apache access logs on the appliance.

Target File: /var/log/httpd/https-access_log

  1. The Hunting Regex: Attackers target specific URI paths containing the vulnerable parameters. Use grep on the extracted logs:
    Terminal window
    grep -E ".*\/mifs\/c\/(aft|app)store.*theValue\?\?.*" /mnt/analysis/var/log/httpd/https-access_log
  2. Interpreting the HTTP Status Code (The 404 Paradox):
    • Status 404 Not Found: Do not ignore this! Due to how the backend handles the malformed payload after the command injection triggers, a successful exploit will frequently return a 404 status code. A matching regex with a 404 is a high-confidence Indicator of Compromise (IOC).
    • Status 200 OK: This often represents legitimate “heartbeat” or sync traffic (e.g., requests ending in .../sha256:kid=0). If the URI matches the exact known benign heartbeat pattern, it can be filtered out.

3. Phase 2: Dead-Disk Forensic Analysis (Post-Exploitation)

Section titled “3. Phase 2: Dead-Disk Forensic Analysis (Post-Exploitation)”

Unlike Ivanti Connect Secure (ICS), EPMM does not have a mature Integrity Checker Tool (ICT) for automated artifact hunting. DFIR analysts must manually mount the forensic image (e.g., at /mnt/analysis/) and hunt for staging and persistence mechanisms.

A. Hunting Webshells & Droppers

Section titled “A. Hunting Webshells & Droppers”

Threat actors, as observed by Unit 42, drop distinct webshells to establish persistent remote access.

  • Target Directories:
    • / (Root directory, for poorly written exploits)
    • /tmp/ and /var/tmp/ (Standard payload staging)
    • /var/www/ext/html/ (The critical web root for persistence)
  • File Signatures to Hunt:
    • Extremely short filenames (e.g., a, x.sh).
    • Archives compressed using the LZMA2 algorithm (frequently used in this specific campaign to bypass basic network inspection).
    • Files masquerading as error pages: 401.jsp or error.jsp.
    • Trojanized Assets: Attackers overwrite legitimate image files with webshell code. Pay specific attention to favicon.png in /var/www/ext/html/. Check its file type using file favicon.png and verify its hash. If it contains Java or Perl code, it is a webshell.

B. Network IOCs & Reverse Shells

Section titled “B. Network IOCs & Reverse Shells”

EPMM appliances should not initiate unexpected outbound connections.

  • Check outbound firewall or proxy logs for long-duration connections originating from the EPMM IP.
  • Specific User-Agent: Hunt for Edg/143.0.0.1 in your edge logs. This specific UA string was hardcoded into several public exploit scripts.

4. Phase 3: Impact Assessment

Section titled “4. Phase 3: Impact Assessment”

If a successful exploit and subsequent webshell placement are confirmed, analysts must assume a worst-case scenario. The threat actor gained access to the entire MDM database.

Exfiltrated Data likely includes:

  • Administrative Data: Names, emails, and usernames of EPMM administrators.
  • User PII: Names, corporate emails, UPNs of all registered employees.
  • Device Telemetry: Phone numbers, IMEI/MEID, GPS locations, and lists of installed applications on corporate devices.
  • Corporate Secrets: LDAP bind passwords, Kerberos service account hashes, and potentially client-side certificates pushed via the MDM.

5. Phase 4: Remediation (The “Scorched Earth” Policy)

Section titled “5. Phase 4: Remediation (The “Scorched Earth” Policy)”

Ivanti’s official security guidance is explicit: Do not attempt to clean a compromised appliance. The depth of the OS command injection and the potential for deep rootkits make remediation unreliable.

If the appliance is compromised, you must execute a “Scorched Earth” rebuild.

  1. Isolate & Preserve: Disconnect the compromised EPMM appliance from the network immediately. Capture a forensic snapshot (memory and disk) for legal and investigative purposes.
  2. Rebuild: Deploy a completely new, clean EPMM appliance instance.
  3. Restore: Import a configuration backup taken from a date strictly prior to the first identified exploitation attempt in the logs.
  4. Patch: Apply the patches for CVE-2026-1281 and CVE-2026-1340 to the new instance before connecting it to the production network.
  5. Rotate All Secrets (CRITICAL):
    • Reset all EPMM local administrative passwords.
    • Reset the passwords for all Active Directory service accounts (LDAP, KDC) utilized by the EPMM integration.
    • Revoke and replace the public-facing TLS certificate of the EPMM appliance.
    • Consideration: Depending on the severity of the breach, evaluate the necessity of revoking client-side certificates pushed to the managed mobile devices.

6. Threat Hunting Queries

Section titled “6. Threat Hunting Queries”
hunt_epmm_cve_1281.spl
# Hunt for the specific exploit URI pattern in Apache/EPMM access logs
index=web_logs sourcetype=access_combined
| search uri_path="*/mifs/c/aftstore*" OR uri_path="*/mifs/c/appstore*"
| search query="*theValue??*"
# Alert specifically if the server returned a 404 (Exploit success indicator)
| eval is_suspicious = if(status==404, "HIGH", "MEDIUM")
| table _time, src_ip, http_method, uri_path, query, status, is_suspicious
| sort - _time

Sources & References

Section titled “Sources & References”