Ivanti EPMM Zero-Days: Attack Chain, Threat Actor Infrastructure, and What Defenders Need to Do Now

What Is Ivanti EPMM and Why Does It Matter?

Ivanti Endpoint Manager Mobile, formerly MobileIron Core, is an enterprise mobility management platform used to manage, secure, and enforce policy across iOS, Android, and other mobile endpoints. It handles corporate application distribution, device configuration, VPN settings, and compliance enforcement across an organization's entire managed device fleet. T1133T1133 — External Remote ServicesEPMM is an external-facing service that mobile devices connect to directly. Attackers exploit this necessary internet exposure as the initial attack surface.

EPMM servers are almost always exposed to the internet because mobile devices need to reach them. Compromising an EPMM instance gives an attacker visibility into every managed device in an organization, including names, email addresses, phone numbers, GPS data, and device identifiers. It also provides the ability to push configuration changes, modify VPN settings, modify authentication settings such as LDAP and SSO, and distribute applications to the entire managed fleet.

EPMM additionally has command execution privileges on Ivanti Sentry gateways, which route traffic from mobile devices into internal network systems. Ivanti's own advisory warns that if an EPMM deployment has been compromised, attackers may have compromised Ivanti Sentry as well. A compromised EPMM is therefore not just a data exposure event — it can become a pivot point into backend infrastructure that mobile devices rely on. T1078T1078 — Valid AccountsPost-compromise, attacker-controlled EPMM credentials can be used to authenticate to connected systems including Sentry and LDAP-integrated services, extending lateral movement options.

Palo Alto Networks' Cortex Xpanse telemetry identified over 4,400 EPMM instances exposed on the public internet during the exploitation period. The Shadowserver Foundation's sensors tracked approximately 1,600 exposed instances worldwide as of early February 2026. The product is widely deployed across government, healthcare, financial services, and enterprise environments.

This is not the first time EPMM has been targeted. It was exploited in the wild via CVE-2023-35078 in 2023, and again in 2025 through an exploit chain involving CVE-2025-4427 and CVE-2025-4428. CISA has flagged 31 Ivanti vulnerabilities on its Known Exploited Vulnerabilities catalog since late 2021. The pattern is consistent: Ivanti products sit at the network edge, hold privileged access, and become recurring targets.

The Vulnerabilities: CVE-2026-1281 and CVE-2026-1340

Both vulnerabilities are code injection flaws. They affect two specific EPMM features: In-House Application Distribution (CVE-2026-1281) and Android File Transfer Configuration (CVE-2026-1340). Both score 9.8 on CVSS v3.1. Both allow unauthenticated remote code execution via T1190T1190 — Exploit Public-Facing ApplicationAttackers exploit a vulnerability in an internet-facing service (EPMM) to gain initial access without credentials. This is the primary initial access technique for this campaign.. Both affect on-premises EPMM only — Ivanti's cloud product Neurons for MDM is not affected.

The root cause, as detailed in watchTowr Labs' reverse engineering of Ivanti's patches, lies in how EPMM handles certain HTTP requests through Apache RewriteMap directives. The vulnerable code paths rely on two Bash shell scripts: /mi/bin/map-appstore-url and /mi/bin/map-aft-store-url. These scripts process parameters from specially crafted HTTP GET requests. The specific exploitation vector involves injecting a command substitution into the h parameter, which is subsequently referenced by gStartTime during an arithmetic expansion — a textbook case of T1059.004T1059.004 — Unix ShellThe vulnerability is exploited by injecting OS commands via Bash arithmetic expansion. The Apache RewriteMap passes attacker-controlled input to a Bash script, which executes it as shell commands..

An unauthenticated attacker can send a crafted GET request to the application store path and inject OS commands through the URL parameters. watchTowr's proof-of-concept demonstrated that a request structured like the following achieves command execution:

GET /mifs/c/appstore/fob/3/5/sha256:kid=1,st=theValue,et=1337133713,h=gPath[`sleep 5`]/e2327851-1e09-4463-9b5a-b524bc71fc07.ipa

The backtick-enclosed command (sleep 5) is a demonstration payload showing timing-based confirmation of execution. If the connection hangs for exactly five seconds before returning an error, the attacker has confirmed RCE. In real attacks, this is where reverse shells, webshell deployment commands, and automated payload droppers appear.

Ivanti's interim RPM patches address this by replacing both vulnerable Bash scripts with newly compiled Java classes — AFTUrlMapper.java and AppStoreUrlMapper.java — in the Apache RewriteMap configuration, eliminating the Bash-based command injection vector entirely.

Timeline of Events

The Threat Actor Infrastructure

GreyNoise's analysis of exploitation traffic between February 1 and 9 provides the clearest picture of who is attacking EPMM instances and how. This infrastructure is an example of T1583.008T1583.008 — Acquire Infrastructure: Bulletproof HostingThreat actors acquire or lease space on bulletproof hosting services that are resistant to legal takedown and abuse complaints. PROSPERO OOO is a documented provider of this infrastructure. in practice.

Out of 417 observed exploitation sessions from 8 unique source IPs, 346 sessions (83%) originated from a single IP address: 193.24.123[.]42. This IP is hosted on PROSPERO OOO (AS200593), a bulletproof hosting provider geolocating to Saint Petersburg, Russia. GreyNoise cautions that IP geolocation reflects infrastructure registration, not operator location, and does not attribute this activity to a specific threat actor.

PROSPERO's background is well-documented. French cybersecurity firm Intrinsec established that PROSPERO (AS200593) and Proton66 (AS198953) share nearly identical peering agreements and are linked to the same internet exchange point in Saint Petersburg. Both networks have hosted command-and-control servers for GootLoader and SpyNote malware. Proton66 infrastructure has additionally been used to distribute XWorm, StrelaStealer, and WeaXor ransomware. The bulletproof services marketed under the names SecureHost and BEARHOST — advertised on Russian-language cybercrime forums as explicitly ignoring all abuse complaints — are linked to this infrastructure. Security journalist Brian Krebs separately reported in early 2025 that PROSPERO had begun routing its operations through networks run by Kaspersky Lab in Moscow.

The dominant source IP is not limiting itself to Ivanti targeting. GreyNoise observed it simultaneously exploiting three additional, unrelated vulnerabilities — a signature of T1046T1046 — Network Service Discovery / ScanningAutomated tools are scanning across multiple products simultaneously to discover and catalog vulnerable services. The concurrent exploitation of four unrelated products from one IP indicates fully automated, opportunistic scanning at scale.:

• CVE-2026-21962 (Oracle WebLogic): 2,902 sessions
• CVE-2026-24061 (GNU InetUtils telnetd): 497 sessions
• CVE-2025-24799 (GLPI): 200 sessions

"The IP rotates through 300+ unique user agent strings spanning Chrome, Firefox, and Safari." GreyNoise, February 12, 2026

Post-Exploitation: What Attackers Do After Getting In

Unit 42's broader campaign analysis identified exploitation across state and local government, healthcare, manufacturing, professional and legal services, and high technology sectors in the United States, Germany, Australia, and Canada.

Threat actors moved rapidly from initial reconnaissance to deploying dormant backdoors built to outlast patching cycles. Palo Alto Networks Unit 42, February 2026

The Sleeper Shell Campaign

Beyond mass automated exploitation, Defused Cyber identified a more sophisticated campaign targeting compromised EPMM instances. Attackers deployed a dormant in-memory Java class loader to the path /mifs/403.jsp on compromised systems. The implant has a specific design constraint: it can only be activated with a particular trigger parameter. At the time of Defused Cyber's report, no follow-on exploitation had been observed.

A dormant in-memory class loader was planted at /mifs/403.jsp, triggerable only by a specific parameter — classic initial access broker staging tradecraft. Defused Cyber, February 9, 2026

GreyNoise corroborated this assessment. Eighty-five percent of the exploitation sessions they observed beaconed home via DNS using T1071.004T1071.004 — Application Layer Protocol: DNSDNS OAST callbacks confirm "this target is exploitable" without deploying any malware or exfiltrating data. Each callback is essentially a vulnerability confirmation signal sent covertly through DNS queries. OAST callbacks. These DNS callbacks confirm "this target is exploitable" without deploying any malware or exfiltrating data. The campaign is cataloging which targets are vulnerable rather than deploying payloads immediately — consistent with initial access operations that verify exploitability first and deploy follow-on tooling later.

Because the sleeper webshells are in-memory Java class loaders, they do not survive an application server restart. However, if the attacker has already confirmed exploitability and sold access, a restart alone does not eliminate the risk. The buyer can re-exploit the vulnerability at any time if the patches have not been applied.

Confirmed Victims and Impact

The Netherlands: The Dutch Data Protection Authority (AP) and the Council for the Judiciary (Rvdr) both confirmed breaches linked to the Ivanti EPMM zero-days. In an official letter to parliament, State Secretary Arno Rutte confirmed that unauthorized parties accessed work-related employee data including names, business email addresses, and telephone numbers. Officials stressed that the intrusions did not compromise mobile devices themselves. NCSC-NL subsequently advised that all organizations using Ivanti EPMM should assume they have been compromised and mount a forensic investigation.

European Commission: The EC confirmed a cyberattack on its "central infrastructure managing mobile devices," detected on January 30. CERT-EU contained the intrusion and cleaned the system within nine hours. The Commission stated the breach may have resulted in access to staff names and mobile phone numbers for some employees, but confirmed no compromise of mobile devices themselves. The EC has not confirmed the vendor involved, though the timing and description align with the Ivanti EPMM exploitation campaign.

Finland: Valtori, the central government ICT service provider under Finland's Ministry of Finance, disclosed a breach affecting the mobile device management service it operates on behalf of government agencies. The incident was detected on January 30, 2026. The attacker gained access to names, work email addresses, phone numbers, and device details. Valtori's investigation found that the system had marked deleted data as removed without actually erasing it, meaning historical device and user data remained accessible. The final estimated scope reached up to 50,000 users of shared state ICT services — roughly two-thirds of Finland's entire central government workforce of approximately 77,000 people. Finland's National Bureau of Investigation is conducting a criminal investigation.

Germany: BSI issued a formal warning and confirmed German organizations were among those targeted. Shadowserver detected over 20 confirmed compromised EPMM instances in Germany alone.

Broader impact: As of February 9, Shadowserver identified at least 86 confirmed compromised instances globally. Palo Alto Networks' Cortex Xpanse telemetry tracked over 4,400 EPMM instances with internet exposure. Exploitation was observed across state and local government, healthcare, manufacturing, professional and legal services, and high technology sectors in the US, Germany, Australia, and Canada.

What Ivanti's Patches Actually Do (and Don't Do)

Ivanti's initial response was to release version-specific RPM patches on January 29, followed by updated security patches on February 4. These patches replace the vulnerable Bash scripts with Java classes in the Apache configuration — specifically compiling AFTUrlMapper.java and AppStoreUrlMapper.java and modifying the Apache RewriteMap directives to invoke these Java classes instead — eliminating the T1059.004T1059.004 — Unix ShellIvanti's fix removes the vulnerable Bash scripts entirely, replacing them with compiled Java classes in the Apache RewriteMap. This eliminates the shell injection pathway at its root. command injection vector.

The RPM patches are not persistent. They are overwritten during version upgrades and must be manually reapplied after any appliance upgrade. The RPMs are version-specific — the correct RPM must be matched to the installed EPMM version. A permanent fix will be included in EPMM version 12.8.0.0, expected in Q1 2026.

Patching does not remediate prior compromise. If an EPMM instance was internet-facing and unpatched at any point between the start of zero-day exploitation and when the patch was applied, defenders must assume the system was compromised. For any instance where integrity cannot be confidently verified, Ivanti's advisory recommends either restoring from a known-good backup, or performing a full rebuild and controlled data migration.

The patch requires no downtime. Ivanti confirmed there is no feature functionality impact and no downtime required. There is no operational excuse for not patching immediately.

How to Respond: Step-by-Step

The following procedure applies to any organization running on-premises Ivanti EPMM that was internet-facing between late January 2026 and the date the patch was applied. Steps are sequenced by urgency — complete earlier steps first even if later steps require more investigation time.

1. Identify and patch all EPMM instances immediately. Locate every on-premises EPMM deployment. Confirm the installed version and apply the correct version-specific RPM patch. No downtime is required. If the instance is upgraded to a new version later, the RPM must be reapplied — it does not persist through upgrades. A permanent fix is in EPMM 12.8.0.0.
2. Restart EPMM application servers. A process restart flushes any in-memory implants. The IAB sleeper shell at /mifs/403.jsp does not survive a restart. This buys time but does not eliminate risk if access has already been sold.
3. Block PROSPERO OOO (AS200593) at the perimeter. This autonomous system was the source of 83% of observed exploitation sessions. Block its full CIDR range at the network boundary.
4. Check Apache access logs for exploitation indicators. Run the vendor regex against /var/log/httpd/https-access_log. If logs were not forwarded off-appliance before patching, historical visibility may not exist — note this gap for your incident timeline.
5. Hunt for webshells. Search for /mifs/403.jsp, 401.jsp, and 1.jsp in the Tomcat webroot. Run Ivanti's NCSC-NL-developed detection script from the Ivanti security advisory hub.
6. Review DNS logs for OAST callbacks. OAST callbacks to unique subdomains are the fingerprint of the IAB campaign confirming RCE. Their presence means the instance was flagged as exploitable and may have been sold.
7. Audit EPMM administrative configuration. Check for unauthorized administrator accounts, SSO/LDAP changes, newly pushed applications, modified device policies, and VPN configuration changes. Review Sentry-accessible systems for lateral movement indicators.
8. Remediate confirmed compromise. Restore from a known-good backup or perform a full rebuild with controlled data migration. Reset all local EPMM accounts, LDAP and KDC service accounts, and service accounts configured within EPMM. Revoke and replace the EPMM public certificate.

Detection and Threat Hunting Guidance

Log analysis T1190T1190 — Exploit Public-Facing ApplicationLog analysis is the primary detection method for this technique. The vendor-supplied regex looks for 404 responses to the vulnerable endpoint paths, which indicate exploitation attempts regardless of whether they succeeded.: Check the Apache access log at /var/log/httpd/https-access_log using this vendor-supplied regex pattern:

^(?!127\.0\.0\.1:\d+ .*$).*?\/mifs\/c\/(aft|app)store\/fob\/.*?404

Requests returning HTTP 404 responses may indicate attempted or successful exploitation. Attackers have been observed running T1070.002T1070.002 — Indicator Removal: Clear Linux/Mac System LogsAttackers actively clean logs after compromise. If EPMM logs are not forwarded off-appliance before this occurs, historical visibility is permanently lost. log cleanup commands. If EPMM logs are not forwarded off-appliance, historical visibility may be absent entirely.

Webshell detection T1505.003T1505.003 — Server Software Component: Web ShellSearch for web shells on the file system. Both persistent file-based shells and the path associated with the in-memory IAB sleeper shell should be checked.: Search for /mifs/403.jsp (sleeper shell campaign) and additional paths 401.jsp and 1.jsp in the Tomcat webroot.

DNS analysis T1071.004T1071.004 — Application Layer Protocol: DNSReview DNS logs for OAST-pattern callbacks — lookups to unique subdomains of known OAST providers like interactsh, Burp Collaborator, and similar. These indicate exploitation tooling confirming RCE.: Review DNS logs for OAST-pattern callbacks. These indicate exploitation tooling confirming vulnerability before deploying payloads.

Process and network monitoring T1105T1105 — Ingress Tool TransferMonitor for unexpected outbound HTTP/S requests from the EPMM appliance process (curl/wget activity), especially to uncommon external hosts. The /slt script and Nezha agent are both pulled this way.: Look for anomalous Java processes, unexpected outbound connections over TCP/443, and evidence of curl or wget retrieving external payloads. The Nezha monitoring agent has been observed as a follow-on tool in some exploitation chains.

Ivanti detection script: Ivanti released an exploitation detection script developed with NCSC-NL. Available through Ivanti's security advisory hub at forums.ivanti.com.

Administrative review T1078T1078 — Valid AccountsAttackers may create new administrator accounts or modify existing credentials after gaining access to EPMM. Review for unauthorized account changes as part of post-compromise investigation.: Check for new or recently changed administrators, modifications to SSO and LDAP authentication settings, new pushed applications, configuration changes to existing applications, new or modified policies, and network or VPN configuration changes pushed to devices.

Sentry and downstream systems: If EPMM has command execution privileges on Ivanti Sentry, systems accessible through Sentry must also be reviewed for reconnaissance or lateral movement activity.

Credential reset T1078T1078 — Valid AccountsAfter a confirmed or suspected compromise, all credentials associated with the EPMM deployment should be rotated. An attacker with prior access may have harvested credentials for use in future campaigns even after patching.: After restoring from clean backups, reset passwords for all local EPMM accounts, LDAP and KDC service accounts, and any service accounts configured within EPMM. Revoke and replace the public certificate used on the EPMM deployment.

Network-Level Mitigations

Block PROSPERO (AS200593) T1583.008T1583.008 — Acquire Infrastructure: Bulletproof HostingBlocking PROSPERO's ASN at the network perimeter disrupts the primary exploitation source identified by GreyNoise. This is a network-level countermeasure against the infrastructure, not just the specific IP. at the network perimeter. This autonomous system hosts the dominant exploitation source and has documented ties to malware distribution infrastructure. NCSC-NL and multiple security advisories have recommended blocking all CIDR ranges associated with PROSPERO and its linked infrastructure.

Restrict EPMM internet exposure T1133T1133 — External Remote ServicesWhere architecturally feasible, restricting EPMM to known network ranges or requiring VPN authentication before reaching the EPMM interface removes it from the class of internet-facing external services that can be targeted without prior authentication.: Evaluate whether EPMM needs to accept connections from the open internet. Where architecturally feasible, restrict access to known network ranges or require VPN authentication before reaching the EPMM interface.

Restart EPMM application servers to clear in-memory implants. The sleeper webshells deployed by the IAB campaign do not survive a process restart. This is a stopgap measure, not a substitute for patching and full investigation.

Defender Checklist

The Bigger Picture

This incident follows a now-familiar pattern with network edge devices and enterprise management platforms. The product sits at the perimeter, manages sensitive data, has privileged access to internal systems, and becomes a single point of compromise that bypasses traditional network segmentation. The 2023 EPMM exploitation targeted Norwegian government agencies and was attributed to Chinese state-sponsored actors. The current exploitation pattern has not been publicly attributed, though some researchers note the targeting of European government institutions and the timing after EU supply-chain security announcements as potentially consistent with a state interest.

Ivanti stated at disclosure that only a very limited number of customers had been exploited at that point in time. Ivanti, January 29, 2026

GreyNoise summarized the structural problem: organizations with internet-facing MDM, VPN concentrators, or other remote access infrastructure should operate under the assumption that critical vulnerabilities face exploitation within hours of disclosure. In this case, vendor disclosure, CISA KEV listing, and confirmed government compromise all occurred on the same day. By the time many organizations saw the advisory, exploitation was already underway — and BSI evidence suggests exploitation may have begun months earlier.

The involvement of a suspected initial access broker adds a second dimension to the threat. Even organizations that were scanned and cataloged but not immediately exploited remain at risk. That cataloged access has value and may be monetized weeks or months from now through ransomware deployment, espionage operations, or further sale to other threat groups.

For defenders managing EPMM or similar internet-facing infrastructure: patch immediately, investigate retroactively, forward logs off-appliance before they rotate, and challenge whether internet exposure is truly necessary for your deployment architecture.

Frequently Asked Questions

References

• Ivanti Security Advisory: CVE-2026-1281 and CVE-2026-1340 — forums.ivanti.com
• Ivanti Analysis Guidance — forums.ivanti.com
• Ivanti Blog: January 2026 EPMM Security Update — ivanti.com
• GreyNoise: Active Ivanti Exploitation Traced to Single Bulletproof IP — greynoise.io
• watchTowr Labs: Someone Knows Bash Far Too Well (CVE-2026-1281 & CVE-2026-1340) — labs.watchtowr.com
• Palo Alto Networks Unit 42: Critical Vulnerabilities in Ivanti EPMM Exploited — unit42.paloaltonetworks.com
• Rapid7: Critical Ivanti EPMM Zero-Day Exploited in the Wild — rapid7.com
• Help Net Security: Ivanti EPMM Exploitation — Researchers Warn of Sleeper Webshells — helpnetsecurity.com
• The Hacker News: 83% of Ivanti EPMM Exploits Linked to Single IP — thehackernews.com
• The Hacker News: Dutch Authorities Confirm Ivanti Zero-Day Exposed Employee Contact Data — thehackernews.com
• BleepingComputer: European Commission Discloses Breach — bleepingcomputer.com
• Helsinki Times: State Data Breach Exposes Details of Up to 50,000 Officials — helsinkitimes.fi
• Deutsche Telekom Security: Mass Exploitation of CVE-2026-1281 and CVE-2026-1340 — github.security.telekom.com
• Intrinsec: PROSPERO & Proton66 — Uncovering Links Between Bulletproof Networks — intrinsec.com
• KrebsOnSecurity: Notorious Malware/Spam Host PROSPERO Moves to Kaspersky Lab — krebsonsecurity.com
• Tenable: CVE-2026-1281 and CVE-2026-1340 Zero-Day Vulnerabilities Exploited — tenable.com
• Arctic Wolf: CVE-2026-1281 and CVE-2026-1340 Advisory — arcticwolf.com
• CISA Known Exploited Vulnerabilities Catalog — cisa.gov
• NVD: CVE-2026-1281 — nvd.nist.gov
• NVD: CVE-2026-1340 — nvd.nist.gov
• MITRE ATT&CK: Enterprise Techniques referenced in this article — attack.mitre.org