Detect CVE-2026-6973: Ivanti EPMM Improper Input Validation Exploitation in Microsoft Sentinel
Detects exploitation attempts targeting CVE-2026-6973, an improper input validation vulnerability in Ivanti Endpoint Manager Mobile (EPMM). This vulnerability is actively exploited in the wild (CISA KEV) and may allow attackers to bypass authentication or execute unauthorized actions against the EPMM management interface.
MITRE ATT&CK
KQL Detection Query
union isfuzzy=true
(
CommonSecurityLog
| where DeviceVendor == "Ivanti" or DeviceProduct has_any ("EPMM", "MobileIron")
| where RequestURL has_any ("/mifs/", "/api/v1/", "/api/v2/", "/admin/")
| where Activity has_any ("400", "422", "500") or AdditionalExtensions has "malformed"
| project TimeGenerated, DeviceVendor, DeviceProduct, SourceIP, DestinationIP, RequestURL, Activity, AdditionalExtensions
),
(
W3CIISLog
| where csUriStem has_any ("/mifs/", "/api/v1/", "/api/v2/")
| where scStatus in ("400", "422", "500") or csUriQuery matches regex @"[\x00-\x1f%00-%1f]"
| project TimeGenerated, cIP, csUriStem, csUriQuery, scStatus, csUserAgent
),
(
AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where requestUri_s has_any ("/mifs/", "/api/v1/", "/api/v2/")
| where httpStatus_d in (400, 422, 500)
| project TimeGenerated, clientIP_s, requestUri_s, httpStatus_d, userAgent_s
)
| extend AccountCustomEntity = iff(isnotempty(SourceIP), SourceIP, cIP)
| extend IPCustomEntity = iff(isnotempty(SourceIP), SourceIP, cIP)Detects anomalous or malformed HTTP requests targeting Ivanti EPMM API and admin endpoints, which may indicate exploitation of CVE-2026-6973 improper input validation. Looks for error responses and suspicious request patterns across IIS logs, common security logs, and Azure Application Gateway diagnostics.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate automated scanners or vulnerability assessment tools probing the EPMM interface
- Misconfigured MDM clients sending malformed enrollment requests resulting in 400/422 errors
- Load balancer health checks generating unexpected HTTP response codes
- Administrative API calls with unusual but valid payloads during migration or upgrade activities
Other platforms for CVE-2026-6973
Testing Methodology
Validate this detection against 4 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 1CVE-2026-6973 EPMM Input Validation Probe — Null Byte Injection
Expected signal: HTTP 400 or 422 responses from EPMM server for null-byte payloads; web server access log entries with %00 in the URL; WAF alert if WAF is present
- Test 2CVE-2026-6973 EPMM API Endpoint Fuzzing — Oversized Input
Expected signal: HTTP 400 or 500 response; web server log entry with large Content-Length header; potential application error log entry on EPMM server
- Test 3CVE-2026-6973 EPMM Admin API Unauthorized Access Attempt — CRLF Injection
Expected signal: HTTP 400/422 responses; EPMM access log entries with CRLF sequences in headers; potential WAF alert on header injection attempt
- Test 4CVE-2026-6973 Post-Exploitation — EPMM Unauthorized Admin Enumeration
Expected signal: Successful HTTP 200 responses to admin API endpoints (if token is valid); authentication/authorization log entries in EPMM audit log; network flow records showing enumeration pattern
Response Playbook
Triage
- Identify the source IP(s) generating malformed or error-producing requests to EPMM endpoints and determine if they are known internal management systems, external IPs, or VPN exit nodes.
- Review the specific URL paths and payloads in the requests — look for null bytes (%00), CRLF sequences (%0a/%0d), oversized bodies, or unexpected parameter names that suggest input fuzzing or injection attempts.
- Check Ivanti EPMM server logs (application log, access log) for any successful responses (200/201/204) immediately following error sequences from the same source, which may indicate successful exploitation.
- Correlate source IP against threat intelligence feeds and check for prior indicators of compromise, scanning activity, or association with known threat actors targeting Ivanti products.
- Determine if any administrative accounts were accessed or created around the time of the suspicious requests by reviewing EPMM audit logs.
Containment
- If exploitation is confirmed or strongly suspected, immediately isolate the Ivanti EPMM server from external network access by implementing firewall rules blocking inbound connections on management ports (443, 8443) from all sources except known management IPs.
- Block the offending source IP(s) at the perimeter firewall and web application firewall, and add to threat intelligence blocklists to prevent further access attempts.
- Revoke all active EPMM administrator sessions and force re-authentication, rotating credentials for all accounts with access to the EPMM console.
- If Ivanti has released a patch for CVE-2026-6973, initiate emergency patching procedures per your change management process.
Evidence Collection
- Export all EPMM web server access logs and application logs from the 72-hour window preceding detection, preserving originals in a forensically sound manner (hash verification).
- Capture network packet captures (PCAP) from the EPMM server's network interface if still ongoing, focusing on traffic to/from suspicious source IPs on management ports.
- Collect EPMM database audit logs to identify any unauthorized device enrollments, policy changes, or data exports that may have occurred as a result of exploitation.
- Preserve memory dump of the EPMM server process if active exploitation is ongoing to capture in-memory artifacts such as injected payloads or credentials.
Escalation Criteria
- !Escalate immediately to CISO and incident response team if any successful POST/PUT requests to admin endpoints are observed following error sequences from an unrecognized source IP, or if new administrator accounts are found in EPMM.
- !Escalate if evidence of lateral movement from the EPMM server is detected — such as outbound connections to unusual destinations, new scheduled tasks, or unexpected process execution on the EPMM host.
- !Escalate if managed mobile devices have received unauthorized policy changes, certificate updates, or MDM commands, as this indicates the attacker may have leveraged EPMM's device management capabilities post-exploitation.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
EPMM web server access logs at default path /var/log/ivanti/epmm/ — contain full HTTP request details including URI, payload size, response codes, and source IPs - >
EPMM application audit log recording administrative actions, configuration changes, and API calls with authenticated user context - >
OS-level auth logs (/var/log/auth.log or Windows Event Log 4624/4625) on the EPMM host for any local authentication events following exploitation - >
Network flow records (NetFlow/IPFIX) showing connection history to EPMM management ports, useful for establishing attacker dwell time and lateral movement - >
EPMM database tables for device enrollment, admin users, and policy configurations — snapshot these to detect unauthorized modifications
Tuning Guidance
Tune detection thresholds based on your organization's baseline EPMM API traffic volume. In environments with large MDM fleets, request counts per 5-minute window may need to be raised to avoid alert fatigue from legitimate bulk enrollment operations. Whitelist known EPMM management server IPs, MDM relay servers, and CI/CD integration accounts that legitimately call administrative APIs. For the error-then-success hunting query, verify that your EPMM deployment's normal operational pattern does not involve clients retrying on 400 errors — some older MDM client versions do. Consider adding WAF rules to inspect and block requests containing null bytes or CRLF sequences to EPMM endpoints as a complementary control.
Hunting Queries
Hunt for any source IP that has successfully reached Ivanti EPMM administrative API endpoints (HTTP 200) in the past 7 days — these should be limited to known management IPs. Any unexpected sources warrant immediate investigation as potential post-exploitation activity.
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceProduct has_any ("EPMM", "MobileIron") or RequestURL has_any ("/mifs/", "/api/v1/", "/api/v2/")
| where Activity has "200" and RequestURL has_any ("/admin/", "/api/v1/admins", "/api/v2/admins")
| summarize SuccessfulAdminCalls=count(), UniqueEndpoints=dcount(RequestURL), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by SourceIP
| where SuccessfulAdminCalls > 0
| sort by SuccessfulAdminCalls descindex=proxy OR index=webserver sourcetype IN ("ivanti:epmm", "iis")
(uri_path IN ("/admin/*", "/api/v1/admins*", "/api/v2/admins*"))
status="200"
| stats count as successful_admin_calls, dc(uri_path) as unique_paths, min(_time) as first_seen, max(_time) as last_seen by src_ip
| where successful_admin_calls > 0
| sort -successful_admin_callsIdentify source IPs that exhibit the error-then-success pattern on EPMM endpoints within hourly windows — a strong indicator of iterative exploitation where an attacker fuzzes inputs until finding a valid payload.
W3CIISLog
| where TimeGenerated > ago(24h)
| where csUriStem has_any ("/mifs/", "/api/")
| summarize ErrorCount=countif(scStatus in ("400","422","500")), SuccessCount=countif(scStatus in ("200","201","204")), TotalRequests=count() by cIP, bin(TimeGenerated, 1h)
| where ErrorCount > 5 and SuccessCount > 0
| extend ExploitPattern = (ErrorCount > 5 and SuccessCount > 0)
| sort by ErrorCount descindex=webserver sourcetype=iis uri_path IN ("/mifs/*", "/api/*")
| eval outcome=if(status IN ("400","422","500"), "error", if(status IN ("200","201","204"), "success", "other"))
| stats count(eval(outcome="error")) as errors, count(eval(outcome="success")) as successes by src_ip, span(_time, 1h)
| where errors > 5 AND successes > 0
| sort -errorsAtomic Red Team Tests
Simulate an attacker probing the Ivanti EPMM API endpoint with null byte-injected payloads to test input validation bypass. This replicates the class of input manipulation associated with CWE-20 / CVE-2026-6973.
Command
TARGET_HOST='epmm-lab.internal'; for PAYLOAD in '%00' '%00admin' 'admin%00' '%00%00'; do echo "Testing payload: $PAYLOAD"; curl -sk -o /dev/null -w "%{http_code} | %{url_effective}\n" "https://${TARGET_HOST}/mifs/j_spring_security_check?j_username=${PAYLOAD}&j_password=test"; sleep 1; doneCleanup
No persistent changes — HTTP requests only. Review target server logs and delete test entries if needed.Expected Telemetry
HTTP 400 or 422 responses from EPMM server for null-byte payloads; web server access log entries with %00 in the URL; WAF alert if WAF is present
Expected Detection
KQL/SPL query should fire on >3 error-producing requests from the test host to /mifs/ endpoint; Chronicle YARA-L rule should match on null byte pattern in query string
Test EPMM input validation by submitting oversized POST bodies to the API, which may trigger different code paths in improper input validation vulnerabilities.
Command
TARGET_HOST='epmm-lab.internal'; LARGE_PAYLOAD=$(python3 -c "print('A' * 100000)"); curl -sk -X POST -H 'Content-Type: application/json' -o /dev/null -w "%{http_code}\n" --data-raw "{\"username\":\"${LARGE_PAYLOAD}\",\"password\":\"test\"}" "https://${TARGET_HOST}/api/v2/users/login"Cleanup
No persistent changes — HTTP POST request only. Verify no test data persisted in EPMM database.Expected Telemetry
HTTP 400 or 500 response; web server log entry with large Content-Length header; potential application error log entry on EPMM server
Expected Detection
Sumo Logic and SPL queries should detect oversized request (bytes_in > 100000) to EPMM API endpoint
Simulate exploitation by injecting CRLF sequences into EPMM API parameters, a common exploitation vector for improper input validation vulnerabilities that may enable header injection or log poisoning.
Command
TARGET_HOST='epmm-lab.internal'; for INJECT in '%0d%0a' '%0aX-Injected:true' '%0d%0aContent-Length:0'; do echo "Testing CRLF: $INJECT"; curl -sk -o /dev/null -w "%{http_code}\n" -H "X-Forwarded-For: 127.0.0.1${INJECT}" "https://${TARGET_HOST}/api/v1/admins"; sleep 1; doneCleanup
No persistent changes — HTTP requests only.Expected Telemetry
HTTP 400/422 responses; EPMM access log entries with CRLF sequences in headers; potential WAF alert on header injection attempt
Expected Detection
QRadar AQL and KQL queries should detect repeated error responses to /api/v1/admins from test source; Chronicle YARA-L should match CRLF pattern
Simulate post-exploitation reconnaissance by enumerating EPMM administrator accounts via the API, as an attacker who has bypassed input validation may attempt to enumerate privileged accounts.
Command
TARGET_HOST='epmm-lab.internal'; TOKEN='YOUR_TEST_TOKEN'; for ENDPOINT in '/api/v2/admins' '/api/v2/admins?adminDeviceSpaceId=1' '/api/v1/admins' '/mifs/admin/api/v1/admins'; do echo "Probing: $ENDPOINT"; curl -sk -H "Authorization: Bearer ${TOKEN}" -o /dev/null -w "%{http_code} - ${ENDPOINT}\n" "https://${TARGET_HOST}${ENDPOINT}"; sleep 1; doneCleanup
No persistent changes — read-only GET requests using test token. Revoke test token after exercise.Expected Telemetry
Successful HTTP 200 responses to admin API endpoints (if token is valid); authentication/authorization log entries in EPMM audit log; network flow records showing enumeration pattern
Expected Detection
KQL and SPL hunting queries for successful admin API calls should surface this activity; alert if source IP is not in approved management IP whitelist