A single IP drives the exploitation of Ivanti EPMM: CERs vulnerabilities, automated bots and the urgency of parking

Threat intelligence analysis has detected a concentrated campaign against Ivanti Endpoint Manager Mobile (EPMM) in which a single actor appears to be behind most active holdings of two critical failures identified on the platform. These vulnerabilities, listed in reports such as CVE-2026-21962 and CVE-2026-24061, allow for the injection of code without authentication and can therefore lead to the remote code execution (CERs) on exposed systems, making them extremely dangerous vectors if not quickly mitigated.

The Internet intelligence company GreyNoise has published a detailed follow-up of the activity observed between 1 and 9 February: during that period they collected 417 operating attempt sessions from just eight different IP addresses, and where a very clear pattern of automation and focus on the above-mentioned failures is seen. You can read GreyNoise's report here: http: / / www.greynoise.io / blog / active-ivanti-exploitation.

The most striking of GreyNoise's work is that a single IP address - 193 [.] 24 [.] 123 [.] 42, housed in the autonomous system PROSPERO OOO (AS200593) - concentrates more than 83% of the total volume of operating sessions detected. Censys and other analysts have described AS as a bulletproof nature, that is, an abuse-tolerant infrastructure, commonly used for malicious operations that seek to avoid rapid blockages or withdrawals of resources by legitimate suppliers. For contexts like this it is appropriate to consult search platforms for hosts and ASN as Censys to get more signals about the infrastructure involved.

The activity observed shows very intense point peaks: on February 8, 269 sessions were recorded in a single day, almost 13 times more than the daily average of about 22 sessions that are seen in the rest of the period discussed. In addition, the campaign seems to be fully automated, with rotations of up to three hundred different user agents to hide or diversify requests and make it difficult to identify by simple patterns.

One data that suggests commercial objectives in the attack is that 85% of the sessions (354 of the 417 recorded) used DNS callbacks in OAST style to check if the remote code had been executed correctly. This behavior is typical of actors who seek to validate initial access and then sell or reuse it, which fits the activity of initial access brokers.

In parallel, researchers note discrepancies between commitment indicators (IoC) published in some reports and observed telemetry: for example, addresses linked to commercial VPN services, such as Windkirbe ranges (185 [.] 212 [.] 171 [.] 0 / 24), have appeared in public listings but in GreyNoise's telemetry these PIs were scanning instances of Oracle WebLogic, without evidence of Ivanti exploitation. This highlights a practical idea for defence teams: blocking only public IoC can leave out the most active source of the campaign if this is not on those lists.

In addition to attempts against Ivanti EPMM, the same IP attributed to the actor simultaneously exploited other vulnerabilities in different products - including instances of Oracle WebLogic and GNU Inetutils Telnetd - and has also been linked to the exploitation of CVE-2025-24799 in GLPI, as followed. In the case of the WebLogic, most of the telemetry observed was precisely that platform, with thousands of sessions recorded, which shows that a single point of origin can scan and exploit multiple objectives in parallel.

Ivanti has published a safety notice with immediate hotfixes and recommendations to mitigate EPMM failures; the company has also announced that it will launch complete patches in version 12.8.0.0 of EPMM in the first quarter. Until this version is available, Ivanti advises applying specific RPM versions according to the branch of EPMM being used and, as a more conservative measure, building a new EPMM instance and migrating data there. The official security note and the supplier's instructions are here: Ivanti's safety notice and the reconstruction guide is available here: Instructions for rebuilding EPMM.

For safety officials and managers managing EPMM, the conclusion is clear: to apply the corrections provided by the manufacturer without delay and, where possible, to follow the most cautious recommendation to migrate to a reconstructed instance to remove any trace of previous commitment. It is also appropriate to extend the defenses beyond a simple list of IoC and to monitor behaviors: detection of atypical DNS callbacks, traffic peaks in ports and routes of the platform, and alerts by unusual user- agent patterns are useful signs that can anticipate automated operating attempts.

The campaign leaves another moral for the community: modern attackers combine mass automation, abuse-tolerant infrastructure and remote verification techniques to maximize the performance of your operations. This forces an equally technical and proactive defensive response: agile patching, segmentation of exposed services, and collaboration between security teams and suppliers to share real telemetry and not rely only on publicly disseminated IoC.

If you manage EPMM or related infrastructure, immediately review the manufacturer's recommendations and public intelligence notes, and prepare a response plan that will provide for reconstruction of instances and continuous monitoring. To deepen the technical findings and indicators observed, check GreyNoise's analysis here: GreyNoise - Active Ivanti exploitation, and check Ivanti's support pages to apply the suggested corrections.