GreyNoise finds Ivanti exploitation is concentrated on one host

At a glance

What this is: GreyNoise’s analysis shows Ivanti EPMM exploitation is being driven mainly by one bulletproof-hosting source, not the widely shared IOC set many defenders may be using.

Why it matters: For IAM and NHI practitioners, the lesson is that defensive trust in published indicators can be misplaced when exploitation infrastructure, not just exploit code, determines whether access paths remain open.

By the numbers:

• 83% of observed exploitation comes from one IP on bulletproof hosting.
• GreyNoise recorded 417 exploitation sessions from 8 unique source IPs between February 1 and February 9.
• 85% of exploitation payloads triggered out-of-band DNS callbacks to verify command execution.
• The February 8 spike reached 269 sessions in a single day, roughly 13 times the daily average of the preceding week.

Context

IOC sharing is often treated as a substitute for understanding attacker infrastructure, but that assumption breaks down when the published indicators are noisy, recycled, or taken from adjacent activity. In this case, defenders were being asked to block IPs without enough context on whether those addresses were actually participating in Ivanti EPMM exploitation or merely appearing in unrelated scanning traffic.

For identity security teams, the deeper issue is governance over the trust decisions that sit behind blocklists, detections, and emergency response workflows. A control is only as good as the evidence that feeds it, and in high-speed exploitation windows that evidence must be enriched before teams act.

Key questions

Q: What breaks when teams rely on published IOCs without campaign validation?

A: They can block low-confidence infrastructure while leaving the main exploitation source untouched. That creates a false sense of containment and can also waste analyst time on unrelated traffic. The better approach is to validate whether an indicator matches the actual exploit path, infrastructure type, and timing before turning it into an enforcement rule.

Q: Why does unauthenticated RCE against mobile device management systems create such high risk?

A: Because the management server sits close to device enrollment, policy enforcement, and administrative control. A foothold there can affect the broader device estate, not just one host. That is why internet exposure, segmentation, and post-disclosure investigation matter more than the application label might suggest.

Q: What signs suggest an exploitation campaign is staging access instead of finishing compromise?

A: Out-of-band callbacks, low-volume probing followed by sharp spikes, and the absence of a deployed second-stage payload all point to staging rather than immediate impact. Teams should treat those patterns as evidence that the attacker is cataloguing viable targets for later use, not as proof that the environment is safe.

Q: How should teams respond when a trusted platform is exploited before normal patching cycles?

A: Treat it as an identity and access containment event. Patch the system, rotate reachable secrets, terminate sessions, and review whether any service accounts or delegated privileges could have been abused through that platform.

Technical breakdown

Why IOC lists can miss the real exploitation source

IOC lists are snapshots, not ground truth. When multiple actors share infrastructure, use VPN exits, or rotate hosts quickly, an indicator can be technically real but operationally misleading. GreyNoise’s data shows exactly that problem here: some published indicators were active in the wild, but not in the Ivanti exploitation path defenders were trying to stop. That is why infrastructure type, traffic concentration, and temporal proximity to disclosure matter as much as the raw IP itself. In practice, detection quality depends on whether the indicator was derived from the exploit campaign you care about or from a nearby but different one. See the Zero-Day and Exploited Vulnerabilities Guide.

Practical implication: Enrich indicators with infrastructure and campaign context before turning them into block rules.

How blind RCE verification changes the threat model

Blind remote code execution verification means the payload is not trying to steal data or deploy malware immediately. Instead, it triggers a callback, usually through DNS or another out-of-band mechanism, to prove the command ran successfully on the target. That behaviour matters because it suggests the attacker is cataloguing viable systems for later use, not finishing the attack in one step. For defenders, that means compromise can exist even when the host looks quiet and no obvious post-exploitation payload appears. The absence of malware is not the absence of access. See the Vulnerability Management Guide.

Practical implication: Treat successful callback patterns as evidence of exploitation even when no second-stage payload is visible.

Why mobile device management exposure has outsized impact

Mobile device management platforms sit in a privileged control plane for the enterprise device fleet. If an attacker reaches the management server, they are not just touching one application, they are getting close to policies, enrollments, configuration changes, and potentially the managed devices themselves. That is why EPMM compromise can become a lateral movement platform even when the initial exploit is remote code execution against a single internet-facing service. The control boundary is much larger than the server footprint, which is why these systems need stronger segmentation and monitoring than ordinary business apps. See the NHI Lifecycle Management Guide.

Practical implication: Treat MDM services as high-value infrastructure and isolate them from general internet exposure.

Threat narrative

Attacker objective: The likely objective is to establish reliable initial access on vulnerable EPMM instances and stage them for later exploitation or resale rather than to complete the intrusion immediately.

1. Entry occurs through unauthenticated remote code execution against Ivanti Endpoint Manager Mobile, allowing exploitation of CVE-2026-1281 over the internet.
2. Credential or access verification is not the primary goal; instead, the payload uses out-of-band DNS callbacks to confirm that arbitrary commands executed successfully on the target.
3. Impact is the creation of a foothold on a high-value management platform that can be staged for later abuse, even when no second-stage malware is visible yet.

Breaches seen in the wild

• Ivanti Connect Secure exploitation 2024: Two Ivanti VPN zero-days exposed user passwords, service account credentials, API keys and certificates on 1,700+ appliances, including at CISA.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Infrastructure provenance is now part of exploitation governance. Security teams cannot treat every IOC as equally trustworthy when one indicator comes from concentrated bulletproof-hosting activity and another comes from shared VPN exit traffic. The operational question is not just whether an IP is bad, but whether it is bad for this campaign and this control decision. That pushes IOC handling toward confidence scoring, campaign correlation, and better source validation before enforcement.

<> should be tied to exploit path, not just patch urgency. The article shows a familiar failure mode: defenders were reacting to disclosure artefacts while exploitation was already underway on a different infrastructure set. When the blocklist reflects the wrong cluster, teams can over-block low-confidence sources and under-block the actual attack path. Practitioners should therefore align emergency response to exploit telemetry, not to the loudest shared indicator.

Management-plane compromise is the real identity issue here. EPMM is not just another internet-facing app; it is a governance point for device enrollment, policy, and access orchestration across the estate. That makes this a control-plane security problem with identity consequences, because compromise of the manager can alter who and what is allowed to exist in the enterprise device environment. The practical conclusion is that mobile device management systems should be governed like privileged infrastructure, not routine software.

Blind verification is a staging signal, not a reassurance. The heavy use of OAST callbacks suggests the operator wants proof of command execution before deciding what to do next. That pattern should trigger assumptions about dwell time, handoff risk, and delayed exploitation rather than comfort that no payload was dropped. Teams should interpret callback-heavy exploitation as evidence of access staging.

Published indicators can encode the wrong threat model. When widely shared IOCs point to unrelated WebLogic scanning while the true EPMM exploitation source sits elsewhere, the defender is inheriting someone else’s inference chain. That is a governance problem as much as a detection problem, because it means the response process is trusting secondary evidence without checking whether the indicator actually maps to the observed attack path. Practitioners should validate source quality before making enforcement decisions.

Read next: Zero-Day and Exploited Vulnerabilities Guide

What this signals

Indicator confidence is becoming a core control variable. The lesson from this campaign is not simply that IOCs can be wrong, but that defenders need a way to rank which indicators are operationally trustworthy before they are enforced. That is especially important where infrastructure is shared, transient, or used for unrelated scanning. Teams that do not score evidence quality will keep mistaking noisy adjacency for actionable threat intelligence.

Management-plane exposure should be treated as a governance boundary problem. When a mobile device management platform is internet-facing, its compromise risk extends into enrollment, policy, and device control. That means the security programme has to classify these platforms as privileged systems, with tighter access paths and stronger monitoring than standard application services. The threat is not just remote code execution, but control over the environment that issues trust to devices.

Callback-heavy exploitation should trigger post-exploitation assumptions. A high share of OAST traffic suggests the attacker is validating access for a later phase, which means teams should prepare for delayed abuse rather than immediate payload noise. That changes how hunting teams prioritise DNS review, process inspection, and compromise-window analysis.

For practitioners

• Validate IOC provenance before enforcement Separate indicators tied to the Ivanti exploitation path from shared VPN exits or unrelated scanning sources before adding them to blocklists. See the Zero-Day and Exploited Vulnerabilities Guide.
• Hunt for OAST callback evidence Review DNS telemetry for high-entropy subdomains and unique callback patterns that indicate the exploit executed on target systems.
• Treat EPMM as privileged infrastructure Segment mobile device management servers from general internet exposure and restrict administrative reachability to trusted network paths.
• Inspect for sleeper-shell artefacts Check compromised or exposed EPMM systems for unexpected files at /mifs/403.jsp, unfamiliar Java processes, and other signs of in-memory implants.
• Reinvestigate the exposure window If an instance was internet-facing and unpatched between disclosure and remediation, perform a compromise review rather than assuming patching removed risk.

Key takeaways

• The campaign shows that published indicators can be directionally useful but still miss the infrastructure actually driving exploitation.
• GreyNoise’s telemetry points to concentrated exploitation, callback-based verification, and a growing risk that patched systems may already have been staged.
• Security teams should validate indicator provenance, hunt for evidence of execution, and treat exposed management planes as privileged infrastructure.

Related NHI Mgmt Group resources: Zero-Day and Exploited Vulnerabilities Guide · NHI Lifecycle Management Guide · Vulnerability Management Guide · Ivanti Connect Secure exploitation 2024

Key terms

• Out-of-Band Application Security Testing: Out-of-band application security testing validates whether an application can make external callbacks or reach attacker-controlled infrastructure during a test. Security teams use it to confirm exploitability in live or near-live systems when a vulnerability can be triggered through network interaction rather than obvious local behaviour.
• Bullet-Proof Hosting: Bullet-proof hosting is hosting designed to resist takedowns, complaints, and law enforcement pressure. Operators use it to keep malicious sites, command infrastructure, or payment services online for longer periods. In cybercrime ecosystems, this kind of resilience supports ransomware, malware delivery, and other abuse that depends on persistent access.
• Indicator Confidence: The level of trust a defender places in an indicator based on its source quality, context, and observed behaviour. High confidence indicators map clearly to a specific campaign, while low confidence ones may be real but operationally misleading or too broadly shared.
• Management Plane: The administrative layer used to configure, govern, and enforce behaviour across many endpoints or services. A management plane is not the workload itself. It is the control layer above it, which makes it especially sensitive to privileged misuse and delegated automation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes they run.