CTI & OSINT

Analysis of the Compromise of Ivanti Endpoint Manager Mobile Systems (EPMM) – CISA MAR AR25-261A

by  • 

Executive Summary

On September 18, 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a detailed Malware Analysis Report (AR25-261A) regarding a cyber intrusion targeting Ivanti Endpoint Manager Mobile (EPMM) systems. In this incident, cyber threat actors exploited two critical vulnerabilities (identified as CVE-2025-4427 and CVE-2025-4428) to bypass authentication in the Ivanti EPMM product and execute arbitrary code remotely on the server. Using this exploit chain, the attackers surreptitiously deployed persistent malware on the compromised server – consisting of malicious loaders and listeners – granting them prolonged control over the system while evading standard detection methods.

This report provides a comprehensive analysis of how these malicious components function (injecting code via stealth web listeners within the application), the relevant MITRE ATT&CK techniques observed (obfuscation, reflective loading, encrypted channels, etc.), and the key indicators of compromise identified. Finally, it offers concrete guidance for detecting such activity, effectively responding to the incident, thoroughly remediating the vulnerabilities, and hardening Ivanti EPMM deployments against future threats.

Exploited Vulnerabilities: CVE-2025-4427 and CVE-2025-4428

The compromise was made possible by the chaining of two critical vulnerabilities in Ivanti EPMM disclosed in May 2025:

  • CVE-2025-4427 – an API authentication bypass in Ivanti EPMM (versions 12.5.0.0 and prior) that allows an unauthenticated attacker to access protected API resources without valid credentials.
  • CVE-2025-4428 – an API code injection vulnerability in Ivanti EPMM (versions 12.5.0.0 and prior) that allows an attacker (once access is obtained, e.g. via the above bypass) to execute arbitrary code on the server through crafted API requests.

Ivanti released patches for these flaws on May 13, 2025, but by May 15 a public proof-of-concept (PoC) exploit had become available, leading to active exploitation in the wild almost immediately. By leveraging CVE-2025-4427 and CVE-2025-4428 together, an unauthenticated remote attacker can achieve full remote code execution (RCE) on a vulnerable EPMM server. CISA noted that affected products included Ivanti EPMM versions 11.12.0.4 and earlier, 12.3.0.1 and earlier, 12.4.0.1 and earlier, and 12.5.0.0 and prior – essentially any unpatched EPMM instance as of mid-May 2025.

In the analyzed incident, the threat actors specifically targeted the EPMM API endpoint **/mifs/rs/api/v2/**. Around May 15, 2025 (immediately following the PoC’s release), attackers sent a series of crafted HTTP GET requests to this endpoint, taking advantage of the CVE-2025-4428 vulnerability via the **?format=** query parameter. This parameter was manipulated to include malicious Java Expression Language (EL) code that the server would interpret, effectively enabling the execution of arbitrary system commands on the server without authentication (thanks to CVE-2025-4427). Through these initial commands, the attackers were able to perform reconnaissance and preparatory steps on the system: gathering system information, downloading further malicious payloads, listing the server’s root directory, mapping the network, generating a Java heapdump, and dumping Lightweight Directory Access Protocol (LDAP) credentials stored on the server. These actions established an initial foothold and provided the attackers with sensitive data (like credentials), setting the stage for deploying their persistent malware.

Malicious Payloads and Analysis

The CISA analysis identified two distinct sets of malicious files that the attackers had placed on the compromised server (specifically in the /tmp directory). In total, five files were recovered, grouped into two malware sets. Each set consists of a loader (a malicious JAR file) and an accompanying listener component (Java class) that the loader injects into the running EPMM server. Working together, these components create a backdoor on the server, allowing the threat actors to maintain persistence and execute arbitrary code at will.

  • Set 1: Files: web-install.jar (referred to as Loader 1), ReflectUtil.class, and SecurityHandlerWanListener.class.
  • Set 2: Files: web-install.jar (referred to as Loader 2) and WebAndroidAppInstaller.class.

Set 1 – Loader 1 and SecurityHandlerWanListener listener: Loader 1 is a malicious JAR that contains a class called ReflectUtil. When executed on the server (triggered via the exploit), it loads ReflectUtil.class into the EPMM’s Java process (Apache Tomcat). ReflectUtil functions as an injector – its job is to dynamically introduce and manage a new servlet filter class, SecurityHandlerWanListener, within the running Tomcat server. This effectively implants a malicious listener into the EPMM web application’s processing pipeline.

Once in place, SecurityHandlerWanListener.class monitors incoming HTTP requests to the server, looking for certain triggering criteria (likely specific URL patterns or payloads that the attackers know to send). When it intercepts a specially crafted request from the attackers, the listener will decode and decrypt the hidden payload carried in that request and then dynamically generate a new Java class in memory based on that payload. The listener then loads and executes this new class, which contains whatever arbitrary code the attacker sent. This mechanism allows the threat actors to effectively execute remote code on demand by sending carefully formatted requests to the compromised server. In summary, Set 1 establishes a persistent in-memory backdoor on the EPMM server through Loader 1 (which deploys the components) and the ReflectUtil/SecurityHandlerWanListener combo (which intercepts and executes attacker-supplied code).

Set 2 – Loader 2 and WebAndroidAppInstaller listener: Loader 2 is a second malicious JAR which, when run, loads the class WebAndroidAppInstaller at runtime. This class acts as another hidden listener/backdoor attached to the Tomcat web service, similar in intent to the first but with a slightly different mode of operation. WebAndroidAppInstaller.class also intercepts specific HTTP requests from the attackers. However, instead of directly executing a payload, it first expects a “password” parameter in the incoming request that is AES-encrypted. The class contains a hard-coded AES key which it uses to decrypt this parameter value (establishing a kind of symmetric encrypted channel for commands).

Once the secret data is decrypted, WebAndroidAppInstaller proceeds to define and load a new malicious class in memory, presumably using the decrypted data (or instructions derived from it) – effectively unlocking the next-stage payload. It executes this newly loaded malicious class, then takes the output (or any data result) of that execution and encrypts & encodes the output before generating an HTTP response back to the attacker containing the encrypted result. This complex sequence means that any data or command outputs exfiltrated via this backdoor are securely transmitted to the attacker (difficult for defenders to interpret if intercepted). Essentially, Set 2 provides a more advanced interactive backdoor that both accepts encrypted commands and returns encrypted results, all through seemingly normal web traffic.

As with Set 1, these malicious components in Set 2 are camouflaged to blend in. The class WebAndroidAppInstaller is placed under a package namespace that mimics legitimate Ivanti code (com.mobileiron.service – MobileIron being Ivanti’s predecessor), whereas ReflectUtil in Set 1 impersonates an Apache library (org.apache.http). This masquerading technique (MITRE T1036) helps the malware avoid easy identification by administrators or simplistic security scans that might flag unusual class names or paths.

Malware Delivery and Evasion Techniques

Initial deployment method: The attackers delivered the malware payloads to the EPMM server in a segmented fashion to avoid detection. Rather than uploading the loader JARs in one piece, they split each JAR into multiple Base64-encoded chunks (MITRE tactic Obfuscated Files or Information: Compile After Delivery – T1027.004). They then used the exploited API endpoint (via the format parameter injection) to write these chunks to a file on the server. Specifically, each chunk was sent in a separate HTTP GET request using the Java Expression Language (EL) injection in the format parameter to append binary data to a file. The first GET request would create the file (e.g., /tmp/web-install.jar) and write the first decoded segment; subsequent requests would append additional decoded bytes to this file until the complete malicious JAR was reconstructed on the server.

For example, one malicious request observed by CISA looked like this (simplified for clarity):

GET /mifs/rs/api/v2/featureusage?format=${... 
    FileOutputStream("/tmp/web-install.jar", true)
        .write(Base64.getDecoder().decode("[BASE64_CHUNK]")) }

This shows how the attacker’s payload, embedded in the URL, invoked Java functions to open a file handle in append mode pointing to /tmp/web-install.jar, decode a Base64 chunk provided in the request, and write the resulting bytes to the file. By repeating this with sequential chunks ([BASE64_CHUNK] being different segments of the JAR file), the entire malicious JAR was pieced together on the target system.

Evasion benefits: This chunked delivery method was a deliberate defense evasion tactic. Transferring the malware in small encoded pieces makes it much harder for signature-based defenses to recognize the payload. Each chunk by itself appears as harmless Base64 gibberish, and only when assembled on the host does it form the malicious code. This also helps bypass any file size limits or deep packet inspection rules that might flag a large suspicious JAR file sent in one go. In effect, the technique combines encoding and chunking to fly under the radar, and uses legitimate server functionality (the EL interpreter) to perform the file write, thereby not triggering some security tools that monitor for standard file upload or download activity.

The choice of the /tmp directory for writing the files might also be intentional – on many systems, /tmp is a world-writable directory used for temporary files and might not be closely monitored by security tools. Additionally, many Linux systems clear /tmp on reboot, which could incidentally help the attackers cover their tracks if the system is restarted (though in this case, it would also remove their malware, unless re-deployed).

After the loader files were fully written to disk, the attackers presumably triggered their execution (again via the EL injection capability or other means), which in turn installed the malicious listeners into the running application memory. Notably, very little of the attackers’ code resides in clear on disk – only the obfuscated JARs in /tmp. The core malicious logic (the listeners) are injected directly into memory, which means traditional file-scanning antivirus might not catch them easily.

Further stealth techniques: The malware incorporates multiple techniques to remain stealthy and persistent, aligning with several MITRE ATT&CK tactics:

  • Masquerading (T1036): As mentioned, naming conventions and package paths were chosen to resemble legitimate files (e.g., using org.apache.http and com.mobileiron.service namespaces).
  • Reflective Code Loading (T1620): The use of ReflectUtil.class to load additional classes at runtime means code is introduced without being present as a static file – it’s loaded directly into memory, complicating detection.
  • Deobfuscate/Decode (T1140): The malicious classes are not stored in plain form; they are encoded (possibly compressed or encrypted) and only decoded by the loader at runtime right before execution. This means static analysis of the loader file has to peel away layers of encoding to get to the actual malicious code.
  • Use of Standard Application Protocol (T1071.001 – Web Protocols): All communication between the attacker and the backdoor takes place over HTTP(S), blending in with normal web traffic. There are no separate listener ports or obvious beaconing to an external C2 server – commands come as seemingly benign web requests.
  • Encrypted Channel (T1573.001 – Symmetric Encryption): In Set 2, the backdoor communications are encrypted with AES. Even if defenders capture the network traffic, the contents of the commands and responses are concealed.
  • Obfuscated Files or Information (T1027.004 & T1027.009): The splitting of files (as described) and the embedding of ReflectUtil.class inside the loader JAR can be seen as obfuscation sub-techniques (compile-after-delivery and embedded payloads, respectively).

By combining these methods, the attackers achieved a high level of stealth and persistence, making detection challenging without specialized analysis.

Persistence of Malicious Access

By injecting these malicious listeners into the EPMM server’s runtime, the attackers established persistent access that did not rely on the vulnerabilities anymore (post-exploitation). As long as the Ivanti EPMM service (Tomcat) remained running, the backdoor listeners (SecurityHandlerWanListener and WebAndroidAppInstaller) would continue to run in the background, ready to process attacker instructions. This persistence is essentially an in-memory web shell baked into the application’s normal operations. The attackers could come back days or weeks later and still have the ability to execute code by sending the appropriate requests, without needing to re-exploit the CVEs (which might have since been patched).

One important aspect of this persistence is that it lives in application memory, not on the filesystem (beyond the initial loader JARs). If the server or service is restarted, these malicious listeners would not automatically reload (unless the attackers’ loader is somehow re-run). In the incident observed, the attackers might have relied on the assumption that critical infrastructure like MDM servers have high uptime and are not frequently rebooted. However, should a reboot occur, the attackers would either need to exploit the system again or have alternate persistence mechanisms in place. The CISA report did not mention additional persistence techniques such as scheduled tasks or root-level backdoors, but those are possibilities in sophisticated intrusions.

From a defender’s perspective, this type of persistence is dangerous because it bypasses typical startup or boot persistence checks – nothing new is installed as a service or autorun program, and no system files are modified. The malware lives solely within the process of a legitimate service (Tomcat), making it harder to spot. It underscores the need for runtime monitoring and memory forensics in critical servers where file-based indicators may not tell the full story.

In summary, until the organization fully removes the malicious code (by wiping and rebuilding the server or restarting and cleansing the application) and patches the vulnerabilities, the threat actors maintain a latent presence on the network. They can continuously leverage this backdoor to issue new commands, harvest data, or move laterally, all while using the compromised EPMM as a beachhead.

Detection and Monitoring

Identifying this compromise and related malicious activity requires diligent monitoring of both system indicators and network/application logs. Below are key steps and tools for detection:

  • Use of Indicators of Compromise (IoCs): Leverage the IoCs provided by CISA (and other threat intelligence sources). CISA’s report includes a JSON file with hashes of the malware files (e.g., the SHA-256 hashes of Loader 1, ReflectUtil.class, Loader 2, WebAndroidAppInstaller.class, etc.), suspicious file names, and potentially attacker infrastructure indicators (IP addresses, domain names if any were associated). Integrate these IoCs into your detection tools:
    • Scan file systems of EPMM servers for the presence of any file with a matching hash or name (for instance, any web-install.jar in unusual locations, especially /tmp, or any .class files dropped in temp directories).
    • Monitor network traffic logs for connections to any external IPs listed as IoCs (the Sigma rule in the CISA report lists several IP addresses potentially used by the actors).
    • If feasible, perform memory scans on the EPMM server’s Java process using IoC signatures (YARA rules can be particularly useful for scanning memory for telltale byte patterns of the malicious classes).
  • Log analysis for exploitation patterns: Examine the application and web server logs of the Ivanti EPMM system for anomalies. In particular, look for:
    • Strange URL access patterns: Requests to the /mifs/rs/api/v2/ endpoints that include the format parameter with suspicious content. Legitimate usage of the format parameter (if any in the product) is unlikely to have long, complex strings or code-like syntax. Instances of ${ in this parameter or repeated hits to featureusage?format= could indicate exploitation attempts.
    • Command execution traces: The attackers’ use of system commands (like collecting info or fetching files) might leave indirect clues. For example, if the underlying OS logged process executions, you might see processes like /bin/sh -c curl http://... initiated by the Tomcat user, or unusual invocations of ping, ifconfig, wget, etc. within a short timeframe. While the malware was executing these via Java, some actions (like network scans or dumps) could trigger other logs.
    • Unusual response codes or sizes: If the backdoor was used to exfiltrate data (like LDAP credentials or heapdump), some responses might be larger than typical API calls. Monitor for any API responses with abnormally large payloads or any error codes that might hint the attacker probing (e.g., a series of 500 errors if they were troubleshooting their exploit).
    Employing a SIEM, you can craft detection rules. For example, set up an alert for any log entry containing ?format=${ which is a strong sign of EL injection attempts. Another rule could flag multiple GET requests to the same featureusage endpoint in a short span (as chunked delivery would generate many sequential requests). These are specific to this scenario but can greatly speed up detection if such an attack is underway or has occurred.
  • Memory and behavior monitoring: Use EDR (Endpoint Detection & Response) tools on the EPMM server if available. An EDR might catch the reflective loading behavior or flag the creation of unusual threads or network connections by the Tomcat process. For instance, after exploitation, the Tomcat process might suddenly attempt to reach out to an external IP (if the malware is actively fetching additional payloads or exfiltrating data). A baseline of normal behavior for the EPMM server (which typically should not initiate outbound internet connections beyond maybe updates) would help spot deviations.
  • YARA and SIGMA rules: CISA provided specialized YARA rules and a SIGMA rule to detect this malicious activity. Deploy the YARA rules on systems and files (and even in-memory scans) to catch the presence of the specific malware components. For example, running YARA scans on the /tmp directory or in process memory could reveal the strings that match ReflectUtil or SecurityHandlerWanListener signatures. The SIGMA rule can be converted to queries for your SIEM to automate the log analysis patterns described above. Incorporating these rules:
    • YARA: Focus on scanning EPMM-related directories and any Java archive files. The YARA signatures from the report target unique byte sequences and strings from the malicious JAR and class files, which should not appear in legitimate files.
    • SIGMA: The provided Sigma rule (entitled “Detects Artifacts Based on MAR-251126”) looks for a combination of keywords in logs: HTTP GET requests, the /api/v2/ path, suspicious substrings like sh -i, java, getRuntime, file permission changes in /tmp, known malicious file paths or hashes, and known attacker IPs. It then triggers alerts if multiple conditions are met, indicating likely malicious activity. Ensure your log source (Ivanti or Tomcat logs) is properly ingested so that these patterns can be detected.

Below, we present the CISA-provided YARA and SIGMA rules for reference, which can be used as-is or adapted to your environment:

YARA Rules (for malicious Ivanti EPMM components detection)

rule CISA_251126_01 : trojan hides_artifacts {
    meta:
      author = "CISA Code & Media Analysis"
      incident = "251126"
      date = "2025-07-23"
      malware_type = "trojan"
      description = "Detects malicious jar filter samples"
      sha256_1 = "c1f60ca5a5f7b94ab7122718a44b46de16c69d22c2eb62ce2948cab14bc78d50"  // loader1
    strings:
      $s0 = { 6F 72 67 2F 61 70 61 63 68 65 2F 68 74 74 70 2F 63 6C 69 65 6E 74 }   // "org/apache/http/client"
      $s1 = { 2F 77 6F 2F 52 65 66 6C 65 63 74 55 74 69 6C 2E 63 6C 61 73 73 }       // "/wo/ReflectUtil.class"
      /* ... additional hex string patterns ... */
    condition:
      all of them
}

rule CISA_251126_02 : trojan {
    meta:
      author = "CISA Code & Media Analysis"
      incident = "251126"
      date = "2025-07-23"
      description = "Detects malicious servlet filter class loader samples"
      sha256_1 = "065c1c2fb17ba1c3f882bead409215df612673cd455698768ed71412f9190ba3"  // ReflectUtil
    strings:
      $s0 = "org/apache/http"                            // appears in package name
      $s1 = "ReflectUtil"                                // class name
      $s2 = "SecurityHandlerWanListener"                 // class name
      $s3 = "getListener"
      $s4 = "addListener"
      $s5 = "TomcatEmbeddedContext"
      /* ... additional patterns ... */
    condition:
      all of them
}

rule CISA_251126_03 : trojan installs_other_components exfiltrates_data {
    meta:
      description = "Detects malicious servlet filter class samples"
      sha256_1 = "b1b1cf33b8d3da35293d6b74c378f0cd9452a4351e26d07c896c4d9a8257ef89"  // SecurityHandlerWanListener
    strings:
      $s0 = "ServletRequestListener"
      $s1 = "ClassLoader"
      $s2 = "ServletRequestEvent"
      $s3 = "/HttpServletResponse"
      $s8 = "pass"
      $s9 = "SecretKeySpec"
      /* ... */
    condition:
      all of them
}

rule CISA_251126_04 : trojan hides_artifacts {
    meta:
      description = "Detects malicious jar Tomcat listener shell samples"
      sha256_1 = "b618057de9a8bba95440f23b9cf6374cc66f2acd127b3d478684b22d8f11e00b"  // loader2
    strings:
      $s0 = "com/mobileiron/service/"
      $s1 = "WebAndroidAppInstaller.class"
      /* ... binary patterns ... */
    condition:
      all of them
}

rule CISA_251126_05 : trojan installs_other_components exfiltrates_data {
    meta:
      description = "Detects malicious Tomcat listener shell class samples"
      sha256_1 = "df501b238854d6579cafebeba82581a728e89ed1f6cd0da54c79ef4eb6f4f9fd"  // WebAndroidAppInstaller
    strings:
      $s1 = "mobileiron/service"
      $s2 = "WebAndroidAppInstaller"
      $s3 = "addListener"
      $s4 = "ServletRequestListenerClass"
      $s5 = "addApplicationEventListenerMethod"
      $s6 = "base64Decode"
      $s12 = "SecretKeySpec"
      /* ... */
    condition:
      all of them
}

(The YARA rules above correspond to: 01 – Loader 1’s JAR, 02 – the ReflectUtil loader class, 03 – the SecurityHandlerWanListener class, 04 – Loader 2’s JAR, 05 – the WebAndroidAppInstaller class. They match on specific ASCII strings like class names, package paths, and unique binary sequences present in the malware code.)

SIGMA Rule (detecting Ivanti EPMM exploitation in logs)

title: Detects Artifacts Based on MAR-251126, Ivanti EPMM CVE-2025-4427/4428
id: 83df757f-54e7-44a0-be21-ae2306ca3240
status: test
description: >
  Detects abused URL paths and suspicious commands in HTTP requests to Ivanti EPMM,
  based on CISA MAR-251126 and known CVE-2025-4427/CVE-2025-4428 exploitation patterns.
author: CISA Code & Media Analysis
date: 2025-08-08
modified: 2025-08-13
logsource:
  product: ivanti_epmm  # or "apache" depending on how logs are categorized
  service: webserver
detection:
  keywords:
    - 'GET'
  api_path:
    - '/mifs/rs/api/v2/*'
  susp_commands:
    - 'sh -i'
    - 'invoke'
    - 'java'
    - '/dev/tcp/'
    - 'getRuntime'
    - '.jar'
    - '.class'
    - 'evilClassName'
    - 'ping'
    - 'dig'
    - 'curl'
    - 'wget'
    - 'fetch'
    - 'echo'
  chmod_usage:
    - 'chmod'
  file_rights:
    - '+x'
    - 'a+r'
    - '755'
    - '/tmp'
  known_artifacts:
    - '/mi/tomcat/webapps/mifs/401.jsp'
    - '/mi/tomcat/webapps/mifs/css/css.css'
    - '/mi/tomcat/webapps/mifs/session.jsp'
    - '/mi/tomcat/webapps/mifs/baseURL.jsp'
    - '065c1c2fb17ba1c3f882bead409215df612673cd455698768ed71412f9190ba3'  # ReflectUtil SHA256
    - 'c1f60ca5a5f7b94ab7122718a44b46de16c69d22c2eb62ce2948cab14bc78d50'  # Loader1 SHA256
    - 'b618057de9a8bba95440f23b9cf6374cc66f2acd127b3d478684b22d8f11e00b'  # Loader2 SHA256
    - 'df501b238854d6579cafebeba82581a728e89ed1f6cd0da54c79ef4eb6f4f9fd'  # WebAndroidAppInstaller SHA256
    - '1b1dda5e8e26da568559e0577769697c624df30e'  # example additional hash (maybe JSP)
    - '83.229.126.234'
    - '82.132.235.212'
    - '37.219.84.22'
    - '91.193.19.109'
    - '47.120.74.19'
    - '150.241.71.231'
    - '5.181.159.149'
condition: |
  keywords and api_path and susp_commands or
  keywords and api_path and chmod_usage or
  chmod_usage and file_rights or
  known_artifacts
falsepositives:
  - Legitimate admin scripts or API calls that use similar patterns (low probability)
level: high

Interpretation: The above Sigma rule is designed to catch the tell-tale signs of the Ivanti EPMM attack in log data. It looks for:

  • HTTP GET requests to any URL path under /mifs/rs/api/v2/ (likely only a few specific endpoints exist, like featureusage).
  • The presence of suspicious substrings in the request (commands like sh -i, or Java method names like getRuntime, which don’t usually appear in normal requests).
  • Usage of chmod and typical permission strings in requests (the attackers in some cases might have used chmod +x or similar in their payload to make files executable, as indicated by logs).
  • References to known malicious JSPs or file paths that were possibly used by the attackers.
  • Known file hashes from the malware (which might appear in logs if, say, those hashes were part of a URL or command).
  • Known attacker IP addresses that were associated with this campaign.

The rule triggers (level “high”) when multiple conditions are satisfied, indicating a strong likelihood of malicious activity rather than benign admin use.

By employing such tailored detection mechanisms and maintaining vigilance, organizations can improve their chances of catching similar attacks early, even if the threat actors use advanced evasion techniques.

Incident Response

If indicators or detections suggest that an Ivanti EPMM system has been compromised by this or similar malware, a swift and structured incident response process should be initiated. CISA’s guidance, along with industry best practices, can be summarized as follows:

  1. Isolation: Immediately isolate the affected host(s) to contain the threat. This means removing the compromised EPMM server from the network or internet (pulling network cables, disabling switch ports, or equivalent network segmentation). This prevents the attackers from continuing to interact with the backdoor or moving laterally, and halts any ongoing data exfiltration.
  2. Triage and Artifact Collection: Once isolated, collect and preserve critical artifacts from the system for forensic analysis. This includes:
    • Running processes and in-memory artifacts (dump the process memory of the EPMM service if possible, as it may contain the malicious class code).
    • Volatile data like network connections, open ports, logged-in users, and scheduled tasks.
    • System and application logs (especially Ivanti/Tomcat logs around the time of suspected compromise).
    • A full disk image of the server and any relevant log or database servers.
      Additionally, check for unusual user accounts or authentication events (since credentials were dumped, the attackers might have attempted to reuse them elsewhere). This step is crucial for understanding the scope of the breach and exactly what the attackers did.
  3. Initial Scoping: Analyze the collected data to determine the extent of the intrusion. Key questions:
    • Did the attackers manage to execute code beyond the EPMM application (e.g., did they elevate privileges on the server OS or pivot to other systems)?
    • What data was accessed or exfiltrated (for instance, were user device data, configuration databases, or directory credentials stolen beyond the LDAP creds mentioned)?
    • Are there signs of lateral movement? (For example, connections from the EPMM server to internal hosts that are unexplained).
      This scoping will dictate the next steps. If evidence suggests the compromise was contained to the EPMM server and its application, the response can focus on eradication and recovery on that system. If a broader compromise is uncovered, a more extensive incident response across the environment will be necessary.
  4. Eradication: Remove the malware and the attackers’ access:
    • For the EPMM server, the safest approach is to rebuild the server from a clean state (see Recovery below). Short of that, terminating the malicious processes (e.g., restarting Tomcat to unload the malicious listeners) is a temporary measure, but it must be coupled with patching the vulnerabilities to prevent re-exploitation.
    • If the attacker created any backdoor user accounts or left any scheduled tasks/OS-level malware, those need to be eliminated. This requires thorough hunting on the system (checking for new accounts in local users or in the EPMM application, examining crontab or scheduled tasks, etc.).
    • If credentials were compromised, change passwords or rotate keys for any accounts that were on the EPMM (especially LDAP service accounts, admin accounts, API tokens, etc.). Assume that any credentials stored or passing through the EPMM might now be in attacker hands.
    • Containment of lateral movement: If the EPMM server was used to pivot, those systems should be isolated and cleaned as well. It’s critical to not bring systems back online before removal of all known malware and addressing exploited vulnerabilities, or the attacker may return.
  5. Notification and Reporting: Report the incident to relevant authorities or cyber incident response partners. CISA encourages organizations to:
    • Contact them via their 24/7 Operations Center or online incident reporting system. By doing so, you contribute to broader threat intelligence and can receive guidance. When reporting, include as much detail as possible (timeline of events, IOCs, impacted systems).
    • Submit malware samples to CISA (using their Malware Analysis Submission Form) or another trusted analysis body (like an ISAC or CERT). Include any assigned incident case number. This helps identify if the malware is known to be associated with a particular threat group and can result in getting additional IOCs or decryptor tools (if ransomware was involved, for example).
      Depending on your jurisdiction, you may also need to inform customers (if data was compromised) or regulators, especially if personal data or sensitive information was accessed.
  6. Recovery and Hardening: Perform a clean restoration of services:
    • Reimage compromised hosts: For the EPMM, it is advised to wipe the server and reinstall the OS and EPMM software from scratch, then apply the latest patches. This guarantees removal of any deeply embedded or hidden malware (since it’s possible the attack could have tampered with things not easily detectable).
    • Verify the system is no longer compromised before reconnecting it to the network (run fresh vulnerability scans, integrity checks, etc., on the new build).
    • Restore configurations from backups only after careful inspection to ensure they weren’t altered by the attacker.
    • Monitor the restored system intensively for any sign of the previous indicators reappearing or any new suspicious behavior.
    • Apply the mitigations from the next section (patches, network restrictions, etc.) before putting the system fully back into production. Essentially, do not just restore to the original state—restore to a hardened, patched state.

Throughout this process, maintain clear documentation of all findings and actions (for post-incident review and possibly legal/insurance purposes). Given the sophisticated nature of this attack, a post-incident analysis will be valuable to improve defenses and response playbooks.

Remediation and Hardening Recommendations

After addressing the immediate incident, it’s vital to take steps to prevent future attacks of this nature and generally improve the security posture of Ivanti EPMM systems. CISA’s report and best practice frameworks (like the Cross-Sector Cybersecurity Performance Goals, CPGs) suggest the following measures:

  • Patch Ivanti EPMM promptly: Ensure all EPMM servers are upgraded to the fixed versions (or later) that resolve CVE-2025-4427 and CVE-2025-4428. As of May 2025, those versions were:
    • 11.12.0.5 (for 11.12.x branch),
    • 12.3.0.2 (for 12.3.x branch),
    • 12.4.0.2 (for 12.4.x branch),
    • 12.5.0.1 (for 12.5.x branch).
      Apply any subsequent updates released by Ivanti as well. In addition, subscribe to Ivanti security advisories so that you are alerted to new vulnerabilities and patches. The window between vulnerability disclosure and exploitation was extremely short in this case (PoC in 2 days), highlighting that rapid patch management is critical for internet-facing systems.
  • Treat MDM systems as High-Value Assets (HVAs): Recognize that a compromise of an MDM like Ivanti EPMM can be as damaging as compromising a domain controller or other critical infrastructure, because MDM has broad control and visibility. Therefore:
    • Place EPMM in a secured network segment with very limited inbound and outbound access. Only allow traffic from managed devices and authorized admin subnets to reach the EPMM, ideally via a VPN or secure access gateway. Outbound internet connections from EPMM should be blocked or tightly controlled (the application might not need to initiate external connections except for updates).
    • Apply extra monitoring on these systems: enable detailed logging, consider deploying host-based intrusion detection (HIDS), and set up alerts for any anomalies (as discussed in detection).
    • Periodically audit the security of the MDM: for example, review user accounts with access, ensure strong passwords and MFA are enforced, verify that no unnecessary services are running, etc.
  • Implement phishing-resistant Multi-Factor Authentication (MFA): Although the initial entry in this attack didn’t involve stealing credentials, using MFA for all administrator access (and remote access in general) adds a crucial layer of security. Ensure all administrative interfaces of EPMM (and other critical systems) require MFA. Use strong methods like authenticator apps or hardware tokens (avoid SMS if possible). This mitigates a wide range of other attacks and is part of a strong zero-trust approach.
  • Follow general cybersecurity best practices: Strengthen your overall security posture, which in turn protects EPMM and other systems:
    • Network segmentation: Limit what the EPMM server can communicate with. For instance, the EPMM likely needs to query an internal database or directory – make sure those credentials are limited in scope. If EPMM doesn’t need to talk to the internet or to user workstations, block those paths.
    • Principle of least privilege: Ensure that accounts and processes on the EPMM have only the minimum privileges required. If the EPMM service runs as a particular OS user, make sure that user has limited rights on the system (no unnecessary sudo privileges, etc.). Similarly, any API tokens or service accounts configured in EPMM (like for APNs or Google services in device management) should be restricted to just that purpose.
    • Regular backups and offline storage: Have regular backups of EPMM configurations and any critical data. Store them offline or in a way that an attacker who gains control of EPMM cannot tamper with them (this helps in recovery if something like ransomware hits).
    • Monitoring and anomaly detection: Use tools to baseline normal operation of EPMM (in terms of process activity, network traffic, and user behavior) so that deviations stand out. For example, if suddenly the EPMM server starts compressing a large file or opening a network connection to a new IP, that should be flagged.
    • Incident response plan: Develop and rehearse an incident response plan specifically for critical systems like EPMM. Knowing in advance how you’d isolate and recover that system can save valuable time in an actual event.
    • Refer to resources like CISA’s Cross-Sector Cybersecurity Performance Goals (CPGs) for a checklist of baseline security practices. These include things like having an updated asset inventory, vulnerability management program, and protective controls across various layers, all of which contribute to resilience against attacks.

By implementing these remediation steps and hardening measures, organizations can significantly reduce the risk of similar compromises in the future. The Ivanti EPMM incident underscores how crucial it is to secure administrative and infrastructure systems: apply patches swiftly, lock down access, monitor actively, and prepare for the worst-case scenario with robust incident response plans. In essence, ensure that if one defense fails (as it did with the zero-day exploit), multiple other controls are in place to limit the damage and detect the intrusion early.

Enjoy !

Sources

  • CISA – Analyse AR25-261A : Malicious Listener for Ivanti Endpoint Mobile Management Systems
  • CISA – Malware Analysis Report AR25-261A (PDF) : “Malicious Listener for Ivanti EPMM Systems”
  • CISA – Fichier d’indicateurs MAR-251126.r1.v1 (JSON) : IoCs et artefacts associés à AR25-261A (TLP:CLEAR)