If you defend an enterprise network, you almost certainly trust an IP blocklist somewhere in your stack. That blocklist was almost certainly built for a different threat landscape than the one you are defending against today.
We measured it. On a single day, May 14, 2026, the GreyNoise Global Observation Grid recorded 119,842 malicious, non-spoofable IPs targeting edge infrastructure. We compared that set against eleven of the most widely deployed OSINT and commercial IP feeds in the industry. The average coverage was 2.0%. The strongest individual feed closed less than five percent of the gap.
That is not a flaw in any single feed. It is the cost of static curation in 2026.
Eleven feeds tested. None broke five percent. The list with the largest absolute size (Avastel, half a million IPs) caught fewer than two percent of the malicious traffic we observed in the same window. The vendor-curated EDLs that ship by default in many enterprise firewalls came in under half a percent.
This is not because those feeds are bad. They are doing the job they were designed to do, which is to flag IPs that meet a high bar for confidence. The problem is that "high bar" is often the result of a manual and slow review process.
The pace of attacker infrastructure has changed. Three forces are compressing the useful life of an indicator faster than any curated list can keep up.
Automated reconnaissance no longer requires a human in the loop. Threat actors can spin up scanners at a scale and speed that was operationally impractical even two years ago, then rotate the source infrastructure once it gets noisy.
A growing share of malicious traffic now originates from compromised consumer devices and rented residential IP pools. These IPs do not look like traditional badness. They sit inside ISP ranges that you cannot blanket-block without breaking legitimate traffic, and they recycle constantly.
Attackers stand up VPS instances, run a campaign, and tear them down before most curation pipelines have rotated through their next refresh cycle. The same IP that was scanning Cisco IOS XE on Monday belongs to someone else's WordPress blog by Friday.
The result: list turnover at most curated feeds is measured in dozens of IPs per day. The threat infrastructure those feeds are trying to track is churning by the tens of thousands. A list refreshed weekly, or even daily, is staring at yesterday's attackers.
GreyNoise is primary-source intelligence. Every IP in our dataset was observed by a GreyNoise sensor doing the thing we say it was doing. We do not aggregate other vendors' lists or infer from reputation. We have the receipts: raw session data captured at the moment of the event, whether that was a scan, an exploit attempt, or a brute-force payload.
The Global Observation Grid is a globally distributed sensor network specifically designed to attract and classify internet-wide scanning and exploitation activity. When an IP shows up in our 1D / Malicious / Non-Spoofable feed, it is there because we watched it do something malicious in the last 24 hours, and we can show the evidence behind the verdict for any IP, tag, or CVE in the dataset.
This matters for two reasons.
First, the data is primary-source. We are not synthesizing a confidence score from third-party reports. The classification is grounded in observed traffic on infrastructure we control.
Second, the IPs are non-spoofable. The GreyNoise sensor architecture eliminates the class of IPs that look malicious in scan logs but are actually forged source addresses in reflection or amplification attacks. When we tell you an IP was scanning your edge, that IP was scanning your edge.
That combination is what makes the data viable for the use cases the static lists were built for, and a lot of use cases they were never designed to support.
Closing the 98% gap is only useful if the intelligence can get into the box that does the blocking. GreyNoise offers two ways to do that, and they are intentionally separate products built for different audiences and different levels of customization.
The GreyNoise Platform, best suited for large security teams, enterprises, and governments, includes advanced blocklist functionality built directly into the Visualizer. These Query-Based Blocklists are built using GNQL: you write or refine the query yourself, validate the results, and convert that query into a managed blocklist with one click.
This is the right path for teams that already live in the Visualizer and want full GNQL expressiveness without leaving the platform. The workflow is:
last_seen_malicious:1d AND spoofable:false AND tags:*Cisco* will block recently malicious IPs hitting Cisco gear.
Common starting queries documented by GreyNoise include recent malicious or suspicious activity, vendor-tagged activity (Cisco, Palo Alto, Fortinet, and so on), CVE-specific exploitation attempts, and geographic scoping. Anything you can express in GNQL, you can turn into a deployable list.
A configuration walk-through for Palo Alto Networks External Dynamic Lists is published here, and the same pattern applies to most NGFW vendors that support URL-based dynamic lists.
Try the GreyNoise Platform free — explore query-based blocklists and enterprise-grade threat intelligence firsthand. Request a trial >
GreyNoise Block is a separate product built specifically for small and mid-sized organizations that only need blocking capabilities.
Block gives you two ways to define a list:
Deployment is the same either way: copy the blocklist URL, paste it into your firewall's external dynamic list configuration, and authenticate with either an inline ?key=YOUR_API_KEY parameter or a request header named key. Lists refresh hourly after the initial 5–10 minute provisioning window.
Try GreyNoise Block for 14 days with a free trial. Try it free >
The blocklists that defended the perimeter for the last decade were good products built for a slower-moving adversary. They are still doing useful work today, and we are not suggesting anyone rip them out.
What we are suggesting is this: if 98% of the malicious activity hitting your edge on a given day is invisible to your current feeds, the right response is to add a source that can see it, not to keep waiting for static curation to catch up to something that has fundamentally changed.
GreyNoise enriches the tools you already run with continuously updated, primary-source intelligence. No list maintenance overhead. No second curation team. The customers who have done the integration get the benefit of seeing what we see, in the systems they are already running.
By the way, there is nothing special about May 14th. The 119,842 IPs we saw on that day are not a number that will hold tomorrow. By the time you read this, the count has already turned over. That is the point.
----
Data collected 2026.05.14. Source: GreyNoise 1D / Malicious / Non-Spoofable. Comparison destinations include FireHol Levels 1 through 4, Blocklist.de, CINS Army List, Palo Alto Known Malicious EDL, Palo Alto High Risk EDL, ShadowWhisperer Malware/Hackers, Binary Defense Ban List, and Avastel 1-Day Proxy/Bot IPs.
Between May 9 and May 18, 2026, GreyNoise observed a significant new spike in scanning of SonicWall SonicOS management interfaces. The May 12 peak — approximately 597,000 sessions — was the largest single-day total recorded on the SonicWall SonicOS API Scanner tag in the past 90 days, roughly 46× the typical daily volume for this tag in the 30 days before the elevation.
Similar elevations in activity against this GreyNoise tag have preceded new vulnerability disclosures affecting SonicWall (Ten Days Before Zero, GreyNoise 2026).
Activity on this tag spiked three times in an earlier sequence — on January 18, January 30, and February 14 — at 37, 25, and 10 days before the February 24 disclosure of CVE-2026-0400. The current spike may be a similar early warning.
The relationship is one observed precedent, not a rule. The current spike could be the first of a multi-event sequence like the Q1 pattern, a single event preceding a disclosure, or unrelated activity. Three documented spikes on this tag preceded a single CVE — a precedent, not an established cadence, and not a definitive rule.
GreyNoise is publishing the signal, not predicting a CVE.
Single-day session volume on the SonicWall SonicOS API Scanner tag. Three Q1 activity spikes — January 18, January 30, and February 14, 2026 — preceded the February 24 disclosure of CVE-2026-0400. The May 12 peak is the largest single-day total recorded on this tag in the past 90 days.
Immediate:
Over the next several weeks (the documented lead-time window for this pattern):
Reference
.png)
Here at GreyNoise, we’ve spent years building one of the most advanced deception networks on the internet. Our Global Observation Grid has over 5,000 sensors across 80 countries processing more than 500 million sessions per day, allowing us to see the internet's attack traffic before it reaches your doorstep. We've used that visibility to alert the world to mass scanning surges, vuln exploitation waves, and early reconnaissance patterns that signal what's coming next.
But there's a class of adversaries we can't catch alone.
The most advanced threat actors, state-sponsored adversaries like the Typhoon groups, have figured something out: the network edge is still a blind spot. Firewalls, VPN gateways, routers, load balancers — these devices can't run EDR agents. They often don't even support basic telemetry like logging. And they sit at the most critical exposure point: the network edge.
These adversaries have made edge devices their preferred point of initial access. They exploit vulnerabilities in firewalls and VPN gateways, hijack built-in tools on perimeter devices to maintain persistence, and send quiet, targeted probes designed to blend into the background. The Typhoon actors have demonstrated the most sophisticated version of this approach, building massive residential botnet proxies by compromising edge devices with little-to-no monitoring. APT41 has exploited zero-days in Fortinet VPNs, Cisco routers, and Citrix appliances. And well-funded ransomware crews are increasingly following the same path. The edge is where advanced adversaries go first, because it's where defenders see least.
Meanwhile, the exposure window keeps widening. The average patch time for edge devices is roughly 32 days, but exploit time is often near zero. For an entire month, your critical internet-facing infrastructure sits exposed to adversaries who are already watching.
The perimeter was never dead — it's the hardest attack surface to defend, and threat actors know it.
When the adversary specializes in staying quiet, you have to change the game. We believe deception is the best way to provide visibility into edge attacks — you can’t detect the threat; but you can make the threat reveal itself.
GreyNoise deploys sensors that emulate the exact assets attackers are looking for. When an adversary probes a sensor, they believe they've found a real target. Instead, they've exposed their tools, their payloads, their behavioral fingerprints, and their intent.
But here's the problem: no single organization can build the deception infrastructure needed to cover the internet's entire attack surface. We need more IP diversity, more device profiles, and faster detection rules than any one company can produce on its own.
That's why we're opening up our platform.
Today, we're launching Project Swarm — a research initiative that opens the GreyNoise deception platform to the global security community.
Project Swarm transforms GreyNoise from a proprietary sensor network into a collective intelligence platform. We're inviting security researchers, universities, non-profits, ISPs, and OEM manufacturers to contribute to three pillars that make edge deception work at scale:
When you deploy a GreyNoise sensor through Project Swarm, you get visibility into all the traffic hitting that sensor, and everything your sensor captures is yours to work with.
Every session is recorded with full fidelity: raw PCAPs, payloads, HTTP headers, TLS metadata, and behavioral artifacts. That means you're not just seeing that something probed you — you're seeing exactly what it did, what it sent, and how it behaved.
For researchers, this opens up a world of possibilities. Here are some ideas to get you started:
The possibilities are limited only by what IPs, emulators, and devices you can bring to Project Swarm.
We believe deception is the best and only way to gain real visibility on the edge. You can't install agents on embedded systems. You can't rely on logs that don't exist.. But you can put something in the attacker's path that looks real enough to make them show their hand. When they probe a deceptive asset, they reveal themselves — their tools, their intent, their techniques — without ever knowing they've been caught.
The challenge is scale. To see the full picture, deception infrastructure needs to span more IP space, emulate more device types, and develop detection rules faster than any single organization can manage. That's what Project Swarm is about — turning the security community's collective reach into the world's most advanced deception network.
The era of defending in isolation is over. The adversaries targeting the edge are patient, precise, and well-resourced. But together, we can be everything, everywhere, all at once. Security is a collective team sport.
Before Cisco published its advisory for CVE-2026-20127 — a CVSS 10.0 zero-day cited in a Five Eyes joint warning — GreyNoise sensors had already observed eight distinct surges of Cisco-targeting activity. The earliest arrived 39 days before disclosure. Each one came closer than the last. A new study finds this pattern is not an anomaly.
Over 103 days, GreyNoise tracked 147.8 million sessions across 276 vendor-specific tags covering 18 network infrastructure vendors. Of 104 detected surge events, 68 preceded a vendor-matched CVE — spanning 33 vulnerabilities across 16 vendor families. Statistical testing confirmed the pattern is not coincidence.
Mandiant's M-Trends 2026 found that mean time-to-exploit has gone negative. VulnCheck documented that 28.96% of KEVs in 2025 were exploited on or before publication day. The traditional model — wait for the advisory, then act — leaves a measurable gap. The signals that narrow that gap are already visible in GreyNoise data.
Download GreyNoise's Ten Days Before Zero report to discover the full findings.
A fleet of 21 IP addresses is now generating nearly half of all the RDP scanning traffic on the public internet. On April 7, 2026 alone, those IPs produced 1,856,167 of the 2,753,274 RDP Crawler sessions observed globally by the GreyNoise Observation Grid (GOG) — 67.4% of the worldwide total. Across a 48-hour window from April 5–7, the same fleet accounted for 49.7% of global RDP Crawler activity, while the other 3,644 sources on the internet produced the rest combined.
RDP — short for Remote Desktop Protocol — is how Windows lets people log into a computer remotely. Attackers scan the internet for exposed RDP endpoints, initiating connection requests at scale to map targets. Once they find an open service, brute-force password attempts typically follow. RDP has been one of the top entry points into corporate networks for years, which is why the sudden concentration of scanning activity in one small network matters.
The 21 RDP fleet IPs are part of a larger cluster of active addresses in a single autonomous system: AS213438, registered in RIPE WHOIS to ColocaTel Inc. of Mahe, Seychelles. This is the same ASN GreyNoise previously reported on for producing roughly 10.7 million sessions the week of March 5–11, 2026 — before activity collapsed 97.7% overnight on March 7 and went quiet for most of the month. In the first week of April, the ASN came back: smaller fleet, tighter geography, single-protocol focus on RDP. Then, just as before, it crashed — dropping 99.9% in a single day and going fully silent by April 9.
GreyNoise sensors observe unsolicited traffic hitting the public internet — scanning, probing, exploitation attempts, payload delivery, credential-harvesting requests, and RCE attempts. We do not observe successful compromises on real production systems. Every number in this post describes attacker activity reaching GreyNoise sensors, not confirmed impact on third-party environments.
GreyNoise does not attribute this activity to a named actor. ColocaTel Inc. is the RIPE-registered holder of AS213438. IP geolocation describes where infrastructure is routed, not where operators sit.
For most of the past year, Romania was the largest single country-level source of RDP scanning traffic observed by GreyNoise. That changed in two days. Romania dropped from 29.89% to 15.78% of global share, and the Netherlands — where the 21 RDP fleet IPs are hosted — rose from 7.17% to 53.86%. AS213438 accounts for the majority of that country-level shift.
Two things make this notable. First, 21 IPs generating half of a global scanning category is not normal — typical source distributions are spread across thousands of IPs and hundreds of networks. Country-level or broad reputation feeds tuned to the old distribution are now pointing at the wrong place. Second, the same ASN was recently the loudest thing on the GOG, then fell silent, then came back smaller and narrower — and then crashed again. That repeating burst-and-crash rotation pattern is a defensive consideration on its own.
The week of March 5–11, 2026, AS213438 was among the top source ASNs on the GOG, generating roughly 10.7 million sessions across mixed scanning behavior. On March 6, the ASN produced 3,756,496 sessions. On March 7, that figure crashed to 86,953 — a 97.7% single-day drop. The ASN stayed quiet through mid-March.
In the first week of April, it came back.
The April 7 jump is the operational detail: session volume went from 180,293 to 2,011,365 (11.1x) in a single day. By the end of April 7, AS213438 was the single largest source ASN for RDP Crawler activity on the GOG.
Then it crashed. The RDP Crawler fleet — the core of AS213438's activity — went from 1,856,167 sessions on April 7 to 1,795 on April 8, a 99.9% single-day drop. The last RDP Crawler session from AS213438 was observed at 2026-04-08T06:22:49Z. By April 9, the fleet had produced zero RDP Crawler sessions. The remaining AS213438 sessions on April 8–9 are non-RDP activity from other IPs in the same ASN.
This mirrors March exactly: a steep ramp, a volume peak, and then a near-total collapse overnight. Two burst-and-crash cycles from the same ASN, the same IP addresses, and the same operational pattern — 30 days apart.
April 7's activity spike coincided with a routine change in GreyNoise's sensor observation infrastructure — the kind of change that can, in some cases, make traffic appear to increase when it hasn't actually changed. GreyNoise cross-checked the spike using five independent tests, including comparison against the structurally identical March spike (which involved no infrastructure change), per-sensor rate normalization, and peer-ASN isolation analysis. The result: the spike is real. It presents identically to earlier observed behavior that did not involve an infrastructure change.
The verification also surfaced something interesting about the fleet's scanning speed. When new observation points came online as part of the infrastructure change, AS213438 traffic appeared on them almost immediately — suggesting these IPs are scanning the internet aggressively enough that newly reachable hosts are discovered and probed within minutes.
The current activity profile is also narrower than early March's. Instead of mixed scanning, it is overwhelmingly focused on RDP:
RDP Crawler alone accounts for roughly 85% of AS213438's total observed sessions in the window. Adding the other two RDP tags pushes the RDP-related share to ~88%.
AS213438 had 32 active IP addresses in the 48-hour window, but only 21 of them are tagged by GreyNoise as RDP Crawler — the fleet behind the headline numbers. The remaining 11 IPs in the ASN are engaged in unrelated activity: web scanning, MySQL probing, Oracle WebLogic exploitation, and broad-spectrum reconnaissance.
The 21 RDP fleet IPs span four /24 network blocks:
Those four /24s hold 20 of the 21 RDP fleet IPs. One additional low-volume RDP Crawler IP (5.253.86[.]23, Lelystad) sits in a fifth /24. All 21 RDP fleet IPs are geolocated to the Netherlands.
The Amsterdam-and-Lelystad concentration, on infrastructure routed through a single ASN registered to one trading name, looks like hosting concentration — not a distributed botnet built from compromised devices. Two details reinforce that read:
One IP in the ASN — 31.56.110[.]107, geolocated to Colchester, UK — has been on GreyNoise's radar since May 2019 and operates as a broad-spectrum reconnaissance host classified as suspicious, not malicious. It is responsible for 259,925 of AS213438's 2,172,094 total sessions in the window, but contributes zero RDP Crawler sessions. The headline numbers are not affected by it: all RDP Crawler sessions come from the 21-IP RDP fleet, and the 67.4% global share holds whether you include the broader ASN or not.
RDP Crawler is one of the most consistent high-volume tags in the GreyNoise dataset. For months, Romania led it. Here is what the composition looks like now:
The Netherlands' daily rate went from ~64,894 sessions/day across the baseline to ~997,200 sessions/day in the window — a 15.4x increase. Romania's daily rate actually rose about 8% over the same comparison. Romania's share dropped because the Netherlands' volume grew much faster, not because Romania withdrew. This is a composition change driven by additive new volume.
For defenders, the effect is the same: any country-level RDP scanning weighting built from baselines before April 5 is misaligned with the current source distribution.
In the Ghost Fleet Hong Kong blog published March 25, 2026, GreyNoise reported on 109.205.211[.]101 — one of the most active source IPs in the dataset the week of March 12–18, 2026, producing roughly 7.97 million sessions (99.5% of which were RDP Crawler). That IP's route is announced by AS201814, a Polish hosting network operated by MEVSPACE sp. z o.o. The /24 containing it, however, is registered in RIPE WHOIS to an organization carrying the ColocaTel Inc. trading name at a Seychelles address.
Two RIPE organization records — one holding AS213438, one holding the /24 that contained 109.205.211[.]101 — are registered to the same ColocaTel Inc. name at the same Seychelles address (306 Victoria House, Victoria Mahe), with the same abuse contact (`abuse@colocatel.com`). The two records have distinct RIPE org IDs (ORG-CI158-RIPE and ORG-CI159-RIPE) and distinct maintainer handles, so GreyNoise cannot assert operational continuity from RIPE metadata alone. What we can say is that the same trading name, at the same Seychelles address, with the same abuse contact, has been linked to two separate high-volume RDP scanning incidents in GreyNoise data within the past 30 days — first on a /24 routed through MEVSPACE, now on /24s routed through AS213438 itself.
These are source IPs and CIDRs from which GreyNoise observed scanning. They are not compromise indicators — a match in outbound traffic from your environment is not evidence of infection. Treat them as inbound block/monitoring candidates.
Attribution note.
GreyNoise does not attribute this activity to a named threat actor or nation-state. ColocaTel Inc. is the RIPE-registered organization for AS213438. The /24 holding the IP referenced from the prior Ghost Fleet HK reporting is registered to a separate RIPE organization carrying the same ColocaTel Inc. trading name and Seychelles address. IP geolocation describes where infrastructure is routed, not where operators are located. GreyNoise has not made contact with ColocaTel and cannot confirm whether the registered organization is aware of, complicit in, or unaware of the activity sourced from address space registered to its name.
Methodology.
All counts come from the GreyNoise Observation Grid (GOG). The 48-hour window is April 5, 2026 19:49 UTC through April 7, 2026 19:49 UTC. The 14-day baseline is March 22, 2026 19:49 UTC through April 5, 2026 19:49 UTC. Daily figures for April 7 reflect a full UTC day of observations. "21 IPs" refers to the count of unique AS213438 source addresses tagged by GreyNoise as RDP Crawler during the observation window; the broader ASN had 32 active IPs, with the remainder engaged in unrelated scanning activity. RDP Crawler is a stable long-running GreyNoise behavioral tag — tag-deployment artifacts are not a factor here. AS213438 registration details were independently verified against RIPE WHOIS on April 7, 2026. Historical AS213438 activity from March 5–11, 2026 and the early-March drop are drawn from the Ghost Fleet Hong Kong blog, published March 25, 2026. Volume verification details are described in the body of this report.
.png)
When a firewall gets exploited, nothing happens, at least, nothing you can see. No EDR alert. No endpoint log. The device just quietly reaches out to an attacker-controlled server, downloads a payload, and waits for instructions.
From the attacker's perspective, access is established. From yours, it's Tuesday.
Edge and perimeter devices, routers, firewalls, VPN concentrators, are the most actively exploited assets on the internet right now. They're also the ones your security stack has the least visibility into. EDR doesn't run on them. Their native telemetry is sparse. And when they're compromised, the only evidence is an outbound connection buried somewhere in your firewall logs.
Today, we're launching C2 Detection, a new GreyNoise intelligence module that gives you two distinct, high-confidence signals that a device in your environment has been compromised.
C2 Detection is a new GreyNoise intelligence capability that surfaces the attacker-controlled infrastructure, malware-hosting servers, C2 nodes, and associated file hashes that compromised devices phone home to after a successful exploit.
Here's how it works: GreyNoise reads the exploit payloads that attackers send to its global sensor network and extracts the callback destinations embedded in those payloads. It then collects the malware hosted at those destinations and analyzes it to map the next stages of the attack chain — from staging servers to command-and-control infrastructure. This is payload-derived intelligence. GreyNoise doesn't need to wait for an exploit to succeed. It reads the payload directly, observes the post-exploitation chain, and delivers the results as a continuously updated dataset of confirmed callback IPs and associated malware hashes.
In the Visualizer, you'll see this as callback IP intelligence and malware hash data — two new layers that extend GreyNoise beyond inbound scanning into outbound threat detection.
Every callback IP is classified into one of three stages based on what GreyNoise has confirmed:
This stage-based model gives you a built-in severity framework. Instead of a binary "good or bad," you get a signal calibrated to where the attacker is in their kill chain so your response matches the actual risk.
C2 Detection strengthens a use case GreyNoise customers already know, detecting compromised assets by adding a second, independent signal:
C2 Detection expands GreyNoise coverage beyond inbound activity, bringing high-confidence visibility into outbound communication with attacker-controlled infrastructure.
This is entirely net-new. GreyNoise previously tracked only IPs actively scanning the internet, inbound threat intelligence. C2 Detection is the first GreyNoise capability focused on post-exploitation, outbound-facing threat intelligence. It introduces:
callback_ipsNone of these existed in GreyNoise before.
If you're already enriching alerts with GreyNoise, the integration model doesn't change. The Callback IP dataset is accessed through the same API and Visualizer you already use. It's a different dataset, a different API call, but the workflow pattern is identical: take an IP, ask GreyNoise about it, act on the answer.
The difference is that Greynoise now extends beyond inbound activity to surface high-confidence signals from outbound traffic. What was once context is now a detection signal.
C2 Detection is available as a dataset add-on for existing GreyNoise customers, with access delivered directly in the Visualizer and via API.
Already a customer? Contact your account team or email support@greynoise.io to enable access.
Not a customer? Get access with an Enterprise Trial.
(An existing GreyNoise Community Visualizer Account is required, create one free here.)
Want the technical details first? Explore the documentation:
.png)
GreyNoise observed 4 billion sessions targeting the edge over 90 days. The data challenges a core assumption of network defense: that you can tell attackers from legitimate users by where the traffic comes from.
A residential proxy is a compromised home internet connection used as a disguise. Attackers route malicious traffic through ordinary home broadband, mobile data, and small-business connections — the same IP address ranges used by employees, customers, and partners. To a reputation feed, the source IP is indistinguishable from a legitimate user's connection — the same ISPs, the same address ranges.
39% of unique IPs targeting the edge come from home internet connections — nearly double their 22% share of sessions. Each residential IP averages fewer than 3 sessions before disappearing, and the median is just 1. They are everywhere, briefly.
78% of residential IPs are observed at most twice across the entire Global Observation Grid before rotating. By the time a reputation feed flags a residential IP, the malicious behavior has already rotated to a new address. The rotation rate makes feed-based detection structurally ineffective.
0.1% of residential sessions carry exploitation payloads, versus 1.0% from hosting infrastructure. Residential proxies map the terrain; the exploitation payloads come later from hosting infrastructure.
Traffic from IPs geolocating to India drops 34% between daytime peak and overnight trough. The most likely explanation is that the infected machines are physically powered off. Server traffic varies less than 3%. The device owners are victims — these are home PCs infected with worms, not willingly enrolled proxy nodes.
SMB worm propagation runs 84% residential, with zero overlap between SMB and Telnet source IP populations — confirming completely separate device populations rather than general-purpose scanning infrastructure.
The residential proxy problem is not theoretical. Google Threat Intelligence Group disrupted IPIDEA in January 2026 — a network with 9 to 11 million daily active proxies used by over 550 distinct threat groups. The DOJ dismantled 911 S5 (19 million IPs across 190 countries) and indicted operators of AnyProxy/5Socks (over 7,000 proxies, $46 million in revenue). Mandiant M-Trends 2025 documented state actors routing operations through residential infrastructure. Every major takedown produces the same result — temporary disruption, then regeneration.
The report presents both the data and its limitations — including a Censys ground-truth validation and an explicit discussion of what GreyNoise can and cannot observe.
Last week, the GreyNoise Observation Grid (GOG) observed something unusual: 242,666 new scanning IPs geolocating to Hong Kong appeared in seven days — nearly half of all new scanning IPs observed by GreyNoise that week. And 99.7% of them never completed a single TCP connection.
These IPs are ghosts — they appeared in GreyNoise data but never proved they were real. Because they never completed a TCP handshake, GreyNoise cannot verify that the traffic actually originated from those addresses. They carried no payloads, triggered no detection signatures, and performed no exploitation. All they left behind were a quarter-million unverified IP addresses now sitting in observation datasets.
Geographic references throughout this post describe where IPs are registered, not where the traffic necessarily originated or where operators are located.
Here's why that matters: any detection system that observed this traffic and doesn't distinguish between verified and unverified source addresses just absorbed a quarter-million ghost IPs into its dataset. Meanwhile, the 702 IPs geolocating to Hong Kong that actually completed connections — the ones observed scanning MySQL, SSH, SMB, and RDP, hitting GOG sensors in 20+ countries — could easily get lost in the noise. One provider alone, UCLOUD, surged 472% in session volume to become the largest ASN by session volume in GreyNoise data, with 38% of its IPs classified malicious. That's the signal. The other 242,000 IPs are the noise.
On top of that, the entire scanning landscape reshuffled last week. A top ASN disappeared overnight. Traffic from IPs geolocating to Australia dropped 72%. New infrastructure geolocating to Poland and Germany appeared. The scanning sources that dominated the prior week were not the same ones that dominated last week.
Between March 12 and 18, GreyNoise observed 242,666 new IPs geolocating to Hong Kong — nearly equal to the rest of the world combined (253,646). Six hosting providers account for 93.3%:
When GreyNoise labels an IP "spoofable," it means the IP was observed sending traffic but never completed a TCP three-way handshake — the source address is unverified. Of these 242,666 IPs, 241,964 are spoofable. They are classified "unknown," categorized as "hosting" infrastructure (92.3%), and carry almost no GreyNoise tags.
GNET INC. (AS9294) is the single largest contributor — one organization that added 28.9% of all new IPs observed by GreyNoise in a single week:
No exploitation. No brute-force activity. No web crawling. Incomplete connections only.
Several ghost fleet entities are registered under names that don't align with where their IPs geolocate:
The ghost fleet is the noise. The signal is UCLOUD (AS135377).
UCLOUD contributes just 1,746 IPs — 0.4% of the active IPs geolocating to Hong Kong in GreyNoise data. But it accounts for an outsized share of observed scanning and exploitation attempts:
The contrast is stark. The entity generating 82x more IPs (GNET INC.) has zero classified malicious. The entity generating 82x fewer IPs (UCLOUD) has 663 — observed scanning MySQL, SSH, SMB, and RDP, with traffic reaching GOG sensors in more than 20 countries.
UCLOUD's session volume went from 9.7 million to 55.4 million in one week — displacing DigitalOcean as the top ASN by session volume in GreyNoise data:
The ghost fleet wasn't the only change. The entire scanning landscape observed by GreyNoise reshuffled. AS213438, a top ASN the prior week with 10.7 million sessions, disappeared entirely — an abrupt shutoff consistent with infrastructure being decommissioned or rotated.
What declined (source refers to IP geolocation; destination refers to GOG sensor location):
What appeared (source refers to IP geolocation; destination refers to GOG sensor location):
Cross-referencing GreyNoise observations with Censys internet-wide scan data and VirusTotal reputation data reveals infrastructure patterns not visible from any single source.
A cluster on infrastructure geolocating to Germany, registered to a Seychelles entity, shows configurations consistent with deployment from a single VM image. A separate Windows VPS cluster uses IPs geolocating to Bulgaria, Romania, and France across three ASNs with an identical service configuration on each node — scanning infrastructure deployed from a common template.
Censys data reveals purpose-built traffic relay and tunneling software deployed across UCLOUD at a density not typical of legitimate hosting. Repeating non-standard port configurations appear identically across multiple subnets — the signature of a single VM template deployed at scale.
The top scanning IPs are barely flagged:
GreyNoise cannot determine the purpose of the ghost fleet from GreyNoise data alone. Censys confirms these ASNs are active hosting ecosystems — the spoofable traffic uses source addresses in IP ranges distinct from the legitimate hosted infrastructure. What we can say: 242,666 IPs appeared, almost none completed connections, and the source addresses are unverified.
GreyNoise is not attributing this activity to a named threat actor or state sponsor. The geographic references in this post describe where IPs are registered, not necessarily where the operators are located. Hosting infrastructure is routinely used by actors with no geographic connection to the provider's registration.
GreyNoise is launching a new SIEM and SOAR integration — with improved dashboards, detection rules, playbooks, and webhook support
Your SIEM ingests everything. Every port scan, every crawl, every opportunistic spray across the internet. The problem isn't the collection — it's context. Which of those IPs are scanning everyone, and which ones are targeting you?
That's the question GreyNoise answers. We observe over over 800,000 unique IPs daily across 5,000+ sensors in 80+ countries, classifying each as malicious, suspicious, benign, or unknown, and tagging them with 3,000+ behavioral descriptors. Traditional threat feeds add more indicators to investigate. GreyNoise removes the ones that don't matter.
Today, as a Google Integration partner, we're announcing a new and improved integration with Google Security Operations that spans both SIEM and SOAR — delivering standardized indicator ingestion, pre-built dashboards, YARA-L detection rules, saved searches, SOAR response actions, webhook support, and ready-to-deploy playbooks.
The GreyNoise ingestion script now lives in Google's official Chronicle ingestion-scripts repository — a standardized process for importing threat intelligence indicators into your environment. Deployed as a Google Cloud Function, it pulls IP reputation data and GNQL query results from the GreyNoise API and ingests them via the Chronicle Ingestion API. The default configuration focuses on malicious IPs observed in the last 24 hours, but teams can customize the GNQL query to match their threat profile.
Two interactive dashboards ship with the integration, ready to import into Google Security Operations:
Indicator Dashboard — 15+ visualization panels covering classification distribution (Malicious, Suspicious, Benign, Unknown), top 10 rankings for organizations, actors, tags, ASNs, categories, operating systems, and source countries, plus CVE distribution, trend analysis, and business service intelligence.
Correlation Dashboard — Shows IOC matches between GreyNoise intelligence and events from your environment, with geolocation mapping, event match trends, classification breakdowns, and top IP indicator rankings.
.png)
Three ready-to-deploy rules that start correlating immediately:
Four pre-built UDM queries for investigation workflows:
Updated Response Actions (v7.0)
The GreyNoise SOAR response integration has been updated to version 7.0 with the full suite of actions:
A major addition: webhook support for ingesting GreyNoise alerts and event feeds directly into Google Security Operations SOAR. Three webhook types are now available:
Pre-built playbooks ship with the integration, providing ready-made automation workflows that teams can deploy or customize. Combined with the webhook connectors and the Generate Alert from GreyNoise GNQL connector, security teams can build end-to-end automated triage pipelines.
The SIEM and SOAR components work as a unified pipeline:
Webhooks close the loop by pushing GreyNoise alerts — including classification changes and CVE spikes — directly into SOAR for immediate action.
This integration is available to any joint Google Security Operations customer with a GreyNoise API key. No additional licensing required — just configure and go.
Ready to bring GreyNoise intelligence into your Google Security Operations environment? Learn more here:
Every SOC analyst knows the feeling: another morning, another queue of hundreds of alerts, and the gnawing question of which ones actually matter. The volume of internet background noise — automated scanners, research probes, vulnerability crawlers — hasn’t slowed down. If anything, it’s accelerating. And as adversaries adopt AI to move faster, the cost of chasing the wrong signals isn’t just frustrating — it’s dangerous.
That’s the problem GreyNoise was built to address. We operate one of the largest passive sensor networks on the internet — more than 5,000 sensors across 80 countries, analyzing up to one billion sessions per day and tracking over 50 million IPs. That scale lets us classify internet-wide scanning and reconnaissance activity with confidence: which IPs are known benign scanners, which are actively malicious, and which are unknown — meaning we haven’t observed them scanning the internet indiscriminately.
That classification data is now available across the CrowdStrike Falcon platform — in Next-Gen SIEM, Falcon Fusion SOAR, and the agentic workflows that are defining the next era of security operations.
For teams running Falcon, GreyNoise intelligence is operationalized across three integrated capabilities — inline investigation context in Next-Gen SIEM, automated enrichment and response in Falcon Fusion SOAR, and agentic collaboration through Charlotte AI.
The GreyNoise Foundry App — available directly on the CrowdStrike Marketplace — is the operational core of the integration. Once installed, it automatically imports a fresh GreyNoise indicator lookup file into Next-Gen SIEM every day. No manual feed management. No stale data.
That lookup file contains GreyNoise’s full dataset of classified IPs — benign scanners, malicious actors, CVE-targeting sources, and tagged threat infrastructure. Inside Next-Gen SIEM, analysts use the match() function to incorporate that data directly into their searches and analytics. GreyNoise classification columns — classification, observed activity, exploited CVEs — surface right alongside event data in the query view, with no pivot to an external tool required.
Detections tied to IPs that GreyNoise has identified as active exploit sources or malicious infrastructure stand out. Teams can build correlation rules and dashboards that weight GreyNoise-validated threats higher. And IPs that GreyNoise has classified as benign — known research scanners, internet measurement services, well-documented security vendors — carry that context right in the query results, giving analysts the information they need to make confident triage decisions.
The Foundry App ships with a pre-built app template containing GreyNoise threat intelligence actions, ready to deploy in Foundry and extend into Fusion SOAR workflows.
Knowing an IP is malicious is useful. Acting on that intelligence automatically is where the efficiency gain lives.
The GreyNoise Foundry App includes a native Falcon Fusion SOAR integration that puts GreyNoise enrichment directly into workflow logic. Security teams can build — or extend — automated playbooks that take action based on GreyNoise IP context:
GreyNoise’s benign classification is particularly valuable here. Because GreyNoise classifies known-good IPs — security researchers, CDN health checks, legitimate vulnerability scanners — SOAR workflows have a higher-confidence basis for automated routing decisions. That confidence is grounded in what our sensor network directly observes, not aggregated from third-party sources.
CrowdStrike’s blog on building an agentic security workforce names GreyNoise among the trusted ecosystem participants supported in Charlotte AI’s Agentic Response Collaboration capability — alongside Corelight, ExtraHop, Proofpoint, Google, Abnormal AI, and Zscaler. These integrations provide what CrowdStrike describes as “deep cross-domain context to drive faster, more accurate analysis.”
Charlotte AI’s use of ecosystem data is still maturing, and we’ll share more as it develops. But the direction is clear: as agentic workflows become a core part of how SOC investigations run, GreyNoise intelligence can be part of the reasoning loop.
Here’s what that looks like in practice. An alert fires on a suspicious external IP. Charlotte AI’s Detection Triage Agent is working the case. As part of its investigation, GreyNoise context is available: Is this IP part of a known mass scanner campaign? Has it been observed exploiting the specific vulnerability that generated the alert? Is it tied to active threat infrastructure? That intelligence informs the agent’s triage decision — contributing internet-wide scanning context to a process that already draws from endpoint, identity, and cloud telemetry.
Charlotte AI’s agentic response can trigger workflows in Falcon Fusion SOAR, which means GreyNoise intelligence already available in your SOAR playbooks carries naturally into AI-driven triage. CrowdStrike’s mission-ready agents — covering detection triage, malware analysis, exposure prioritization, and threat hunting — are trained on years of expert decisions from Falcon Complete analysts. GreyNoise’s classification data adds internet-wide reconnaissance context to those workflows.
GreyNoise intelligence across the Falcon platform produces three specific outcomes:
The GreyNoise Foundry App is available on the CrowdStrike Marketplace for Falcon Next-Gen SIEM and Falcon Insight XDR customers. Installation takes minutes, and the daily automated indicator import requires no ongoing maintenance.
→ Install the GreyNoise Foundry App on the CrowdStrike Marketplace
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
.png)
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.
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.
Step 1 — Check your logs (2 minutes). Search firewall logs for external requests to these paths between February 22–25:
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.
View real-time GreyNoise data on SonicWall activity:
GreyNoise analyzed 2.97 billion sessions over 162 days in H2 2025, and the patterns reveal where edge defenses hold up — and where they fall short. The data exposes specific concentration points in VPN targeting, infrastructure sourcing, and exploitation behavior that challenge conventional defensive assumptions.
Across the GreyNoise Global Observation Grid, several findings challenge conventional assumptions about where attacks concentrate:
Palo Alto GlobalProtect received 16.7 million sessions — more than 3.5x Cisco and Fortinet combined. This disproportionate concentration warrants investigation, though direct market share comparison was not part of this analysis. GlobalProtect deployments provide direct network access if compromised, making them high-value targets.
52% of remote code execution attempts came from IPs with no prior history in GreyNoise data. For remote code execution — widely considered the highest-severity exploitation category — GreyNoise had no prior record of more than half the attacking IPs. That means attackers are spinning up and burning through fresh infrastructure faster than any static threat feed can catalog it — and GreyNoise detected these IPs the moment they first appeared, before any other source had them.
Pre-2015 CVEs generated 7.3 million sessions — 4x more than 2023-2024 CVEs combined. One vulnerability — CVE-1999-0526, a 26-year-old X Server information disclosure — accounts for the majority. Even excluding it, Shellshock and PHP-CGI continue generating measurable traffic a decade later. Patching programs optimized for recency leave decade-old exposure unaddressed.
300,000 residential IPs participated in a single credential-spraying campaign — 73% classified as residential by ISP categorization, with no prior GreyNoise history. Geographic blocking, reputation scoring, rate limiting: would have limited effectiveness against this traffic pattern.
91,403 sessions targeted AI/LLM infrastructure. The same types of automated scanning patterns hitting VPNs and routers are now cataloging exposed LLM endpoints.
The Verizon 2025 DBIR documented an 8x increase in edge device exploitation in a single year — edge vulnerabilities jumped from 3% to 22% of all vulnerability exploitation breaches. Mandiant M-Trends 2025 found the top four most frequently exploited vulnerabilities were all in edge devices — Palo Alto PAN-OS, Ivanti Connect Secure, Ivanti Policy Secure, and Fortinet FortiClient EMS. CISA issued Binding Operational Directive 26-02, requiring federal agencies to address end-of-support edge devices. The GreyNoise data is consistent with all of it — and quantifies the scale.
This isn't a theoretical shift. If your organization runs internet-facing VPN appliances, routers, or AI infrastructure, this traffic is reaching you.
The full report includes:
.png)
It took less than 24 hours.
On February 10, a proof-of-concept exploit for CVE-2026-1731, a critical pre-authentication remote code execution vulnerability in BeyondTrust Remote Support and Privileged Remote Access, was posted to GitHub. By February 11, GreyNoise’s Global Observation Grid was recording reconnaissance probing for vulnerable BeyondTrust instances.
CVE-2026-1731 is an OS command injection flaw (CVSS v4: 9.9) that lets an unauthenticated attacker execute arbitrary commands on a BeyondTrust Remote Support or Privileged Remote Access server. No credentials required. No user interaction needed. Low complexity to exploit.
It's a variant of CVE-2024-12356, the same vulnerability class that Chinese state-sponsored group Silk Typhoon used to breach the U.S. Treasury Department in late 2024. Same WebSocket endpoint, different code path.
BeyondTrust patched cloud customers automatically on February 2. Self-hosted customers need to update manually to RS v25.3.2+ or PRA v25.1.1+.
Our global sensor network, a passive collection of sensors that observe and classify internet-wide scanning and reconnaissance activity, detected a clear surge beginning February 11, 2026. This is the reconnaissance phase; what comes next is predictable.
A single IP accounts for 86% of all observed reconnaissance sessions so far. It's associated with a commercial VPN service hosted by a provider in Frankfurt and has been an active scanner in our data since 2023. This isn't a new actor; it's an established scanning operation that rapidly added CVE-2026-1731 checks to its toolkit.
Standard BeyondTrust deployments run on HTTPS (port 443), but few sessions target that port. The rest systematically probed clusters of non-standard ports, suggesting the attackers know that enterprises often move BeyondTrust to non-default ports for security-through-obscurity.
GreyNoise captures JA4+ fingerprints on every session. At the TCP layer, 100% of sessions show Linux stack characteristics. The dominant scanner's TCP fingerprint has an MSS of 1358 (vs. the standard 1460), confirming VPN tunnel encapsulation at the network layer and independently validating the VPN association. At the HTTP layer, two distinct exploit tools are in use: one lightweight 5-header tool shared by the top 5 IPs (including all 4 classified as malicious), and a 7-header variant used by 10 different single-session scanners. Neither tool matches any known application in the JA4 fingerprint database. One session even shows a loopback MSS (65495), a distinctive operational artifact.
The IPs performing reconnaissance for CVE-2026-1731 aren't single-purpose. While their BeyondTrust activity is a check (enumeration), their GreyNoise profiles show they're simultaneously conducting active exploitation attempts against other products: SonicWall, MOVEit Transfer, Log4j, Sophos firewalls, SSH brute-forcing, and IoT default-credential testing. Some IPs are even using out-of-band callback domains (OAST), a more sophisticated technique to confirm vulnerability before delivering payloads.
BeyondTrust's remote access tools occupy a uniquely sensitive position. They're designed to manage privileged access to enterprise networks. When they're compromised, attackers don't just get a foothold; they get the keys to the castle.
Dec 2024 │ CVE-2024-12356 — Silk Typhoon breaches U.S. Treasury
│ via BeyondTrust zero-day (same WebSocket endpoint)
│
Jan 2026 │ GreyNoise sensors catch a malicious IP replaying the
│ exact Treasury breach exploit chain (CVE-2024-12356 +
│ CVE-2025-1094 SQLi)
│
Feb 2026 │ CVE-2026-1731 — Variant discovered by AI-assisted
│ analysis. PoC drops. Recon begins within 24 hours.
│
??? │ What comes next?
Before CVE-2026-1731 even existed, the old exploit chain was still in active use.
On January 5, we observed a Polish hosting provider running the same BeyondTrust RCE + PostgreSQL SQLi chain that Silk Typhoon used against the Treasury, all targeting the /nw WebSocket path on port 443. That IP shares a TLS fingerprint with the new CVE-2026-1731 scanners and also targets SimpleHelp, another remote support product. 26 days later, the new variant was discovered, and by February 11, a fresh set of actors had already begun mapping targets.
GreyNoise customers can track this activity in real time:
The tag was deployed on February 10 and is actively classifying new reconnaissance IPs as they appear. Customers get full IP context, JA4+ fingerprint analysis, behavioral profiling, timeline data, and the complete IOC list for blocking.
Not a GreyNoise customer? You can look up individual IPs against our dataset at viz.greynoise.io and see classification data for free.
CVE-2026-1731 follows a predictable but dangerous pattern: critical disclosure, rapid PoC, and immediate reconnaissance. The last time a BeyondTrust pre-auth RCE went unpatched, a nation-state actor exploited it to breach a U.S. government agency.
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.
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.
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.
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.
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.
IP geolocation reflects infrastructure registration, not operator location. GreyNoise is not attributing this activity to a specific threat actor.
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.
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.
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.
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.
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.
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.
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.
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.
For Security Leadership:
For Security Operations:
For Ivanti EPMM Administrators:
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.
.png)
There is a critical gap in defense: the window between when an attacker starts hammering a specific vendor’s infrastructure and when a specific CVE is assigned or a signature is written.
In that window, defenders are often flying blind, waiting for a vulnerability disclosure to tell them what to look for. But the network noise is often already there. The most dangerous threats don't always start with a named vulnerability—they start with a sudden, coordinated shift in attacker behavior toward a specific technology stack.
Today, we are closing that visibility gap by expanding GreyNoise Event Feeds with two new signals: Vendor CVE Spike and Tag Spike.
These new feed types allow you to monitor the behaviors and technologies that matter to your environment, without needing to manually track every individual vulnerability or signature.
Individual CVEs and tags are continually added, updated, and deprecated as new research emerges. This creates significant overhead and potential blind spots if your team attempts to track these changes manually.
The Vendor CVE Spike feed reduces this complexity by alerting only when exploitation activity across a vendor meaningfully increases.
How it helps: This feed is designed to help you focus on when attacker interest spikes, rather than managing lists of specific CVEs. As vulnerabilities and tags associated with a vendor evolve, the feed updates its coverage to include them, ensuring you are monitoring the broader technology stack rather than just static indicators.
Attackers often target the technology stack, not just a single bug. In our analysis from the week of January 19, 2026, GreyNoise sensors observed a coordinated campaign targeting enterprise VPN infrastructure. Specifically, we saw a significant elevation in targeting of both Fortinet SSL VPNs and Palo Alto GlobalProtect portals.
This activity validates findings from our Early Warning Signals research: vendor-level spikes—whether from credential stuffing, scanning, or exploitation of older vulnerabilities—often precede the disclosure of new CVEs for that same vendor. A Vendor CVE Spike would have flagged this anomaly, providing the early warning needed to enforce tighter MFA controls or geo-blocking before the specific threat was fully characterized.
Setting up a Vendor CVE Spike is designed to be a "set and forget" workflow that integrates directly into your existing Event Feeds. When you search for a vendor name (e.g., "Palo Alto"), the feed uses wildcard matching to find all tags containing that term. It then resolves those tags to their associated CVEs and monitors activity for those CVEs.
Example Payload:
{ "vendor": "Acme", "event_type": "Vendor CVE Spike Spike", "old_state": { "benign_ip_count_1d": 40, "threat_ip_count_1d": 40 }, "new_state": { "benign_ip_count_1d": 90, "threat_ip_count_1d": 90 }, "timestamp": "2025-04-30T08:10:00Z" }
Watch the video below to see Vendor CVE Spike in action:
Sometimes, the threat isn't a specific vulnerability—it is a behavior, a tool, or a botnet. Tag Spike feeds allow you to monitor for sudden increases in activity associated with specific GreyNoise tags directly.
How it helps: Tag Spike lets you monitor activity for specific threats, botnets, or scanning behaviors directly by tag name. Unlike Vendor CVE Spike, which resolves matching tags to their associated CVEs, Tag Spike tracks the tags themselves. This is essential for tracking threats where a CVE may not yet be assigned.
You define a tag or keyword (e.g., "Mirai," "Worm," or "Cisco"), and the feed uses wildcard matching to find all tags containing that term. GreyNoise then watches for significant changes in IP counts for tags matching your filter criteria over a rolling 2-hour window.
Watch the video below to see Tag Spike feed in action:
Vendor CVE Spike and Tag Spike are available now in the GreyNoise Visualizer.
.png)
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.
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.
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.
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.
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:
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.
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
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.
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:
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.
In 2025, 59 vulnerabilities silently flipped to "known ransomware use." If CISA updates a vulnerability's status in the Known Exploited Vulnerabilities (KEV) catalog and nobody notices, did it even matter?
Stick around to the end for a new tool that exposes these hidden flips. But first, some background.
In October 2023, CISA added a knownRansomwareCampaignUse field to KEV, designed to help organizations prioritize more effectively. Relying on KEV for prioritization is already a trailing indicator, and waiting for the ransomware flag is even slower. But I get it: practitioners often need substantial evidence to move the needle internally. (Another problem for another day.)
CISA doesn't just flag ransomware usage when vulnerabilities are added. They also silently update existing entries.
When that field flips from "Unknown" to "Known," CISA is saying: "We have evidence that ransomware operators are now using this vulnerability in their campaigns." That's a material change in your risk posture. Your prioritization calculus should shift. But there's no alert, no announcement. Just a field change in a JSON file.
This has always frustrated me. So I dug into the 2025 data to surface every silent flip.
59 vulnerabilities flipped.
Tracking these changes required pulling down a daily snapshot of KEV throughout 2025 and diffing the dailies for field changes. Silly, right?
Fortinet SSL-VPN. Ivanti Connect Secure. Palo Alto GlobalProtect. Check Point Security Gateway. Ransomware operators are building playbooks around your perimeter.
19 of the 59 target network security appliances, the very devices deployed to protect organizations. Legacy bugs show up too; Adobe Reader vulnerabilities from years ago suddenly became ransomware-relevant.
Authentication bypasses and RCE vulnerabilities led the pack as ransomware operators prioritize "get in and go" attack chains.
The vendor breakdown shouldn't surprise anyone:
Ransomware operators are economic actors after all. They invest in exploit development for platforms with high deployment and high-value access. Firewalls, VPN concentrators, and email servers fit that profile perfectly.
While some CVEs sat in KEV for years before the ransomware flag, the 2025 crop moved fast:
Today, ransomware operators are integrating fresh exploits into their playbooks faster than defenders are patching.
Watch knownRansomwareCampaignUse. When it flips from "Unknown" to "Known," reassess, especially if you've been deprioritizing that patch because "it's not ransomware-related yet."
Since my presentation at BSidesLV in 2024, I've hoped to see CISA provide more transparency by releasing a changelog or an RSS feed whenever updates occur, similar to the additions feed they already maintain. After complaining expressing my desires, my boss made encouraged me to create a solution myself.
So here it is:
Subscribe to the RSS feed at https://kev.labs.greynoise.io/kev-ransom-feed.rss
It checks hourly and will notify you whenever a ransomware flag flips. No more silent changes.
As an aside, the most recent flips occurred just a few days ago:
This data dive exposed a blind spot in how we consume threat intelligence. We're good at reacting to new disclosures. Decent at tracking active exploitation. But we're not great at noticing when the characterization of existing threats evolves.
CISA is already tracking these ransomware campaigns, correlating TTPs, and updating assessments. That intelligence only matters if defenders are watching the delta, not just the headlines.
So consider this your heads-up: the tree fell, and it absolutely made a sound. The question is whether your detection was tuned to hear it and whether it will be tomorrow.
The 59 CVEs that silently flipped in 2025:
.png)
Time is the one variable defenders can’t control. The gap between an exploit disclosure and a patch, or between an initial compromise and its discovery, is where attackers thrive. They automate everything—recon, scanning, and exploitation—shifting their infrastructure by the hour to stay ahead of static blocklists.
To keep pace, defenders need more than a snapshot of what is happening right now. They need to see how behavior evolves.
At GreyNoise, our standard GreyNoise Query Language (GNQL) has always provided a highly accurate, 90-day aggregated view of "the now." It tells you what an IP is doing today. But we realized that for incident responders and threat hunters, a summary isn't always enough. You need to know exactly what was happening during a specific window in the past.
Today, we are launching Recall to address these challenges.
Recall is a time-series capability that enables customers to query GreyNoise data over specific historical ranges. Instead of a static summary of current IP behavior, Recall allows you to see exactly how scanner activity looked at any given hour.
Recall eliminates the need for manual data collection pipelines, acting as a time- and cost-saver by providing historical insights on-demand. This allows teams to move from observing "what is this IP doing now?" to understanding how that behavior has evolved.
When investigating a compromise, Recall lets you reconstruct the attacker’s timeline. You can see when an IP first appeared in GreyNoise, whether it scanned your perimeter days earlier, and how its behavior changed before a successful exploit. This gives you context you cannot get from point-in-time enrichment.
Recall helps determine whether a surge is new or part of a recurring pattern. For example, you can compare a single-day spike in exploitation activity against prior weeks to understand if you are seeing the start of a coordinated campaign or a known cycle.
GreyNoise consistently observes scanning and exploitation activity against enterprise edge technologies before public CVE disclosure. Recall allows teams to look back and confirm when these early signals began, helping validate whether suspicious activity preceded an advisory or zero-day announcement.
Teams can compare traffic across regions, products, or time ranges to see how attacker focus shifts. This is especially useful for measuring changes in exposure or validating whether defensive actions had a real impact.
Recall exposes two API endpoints. Use Stats to identify the spike, then Data to pull the raw records.
Endpoint: GET /v3/gnql/timeseries/stats
Returns unique IP counts per hour or day for your query. Use this to visualize activity volume before pulling detailed records.
Response: count (total unique IPs), min/max (bucket extremes), data (array of { date, count })
curl 'https://api.greynoise.io/v3/gnql/timeseries/stats?query=tags%3A*Scanner*&start=2025-08-08T06%3A00%3A00Z&end=2025-10-12T23%3A00%3A00Z&interval=day' \
--header 'key: <your-api-key>'
Endpoint: GET /v3/gnql/timeseries
Returns full GreyNoise context for each IP, keyed by hour. Use this when you need the actual records—tags, ports, ASN, classification—as they appeared at each timestamp.
Response: JSON keyed by hour (yyyy-mm-dd-hh), each containing ip and internet_scanner_intelligence context.
curl 'https://api.greynoise.io/v3/gnql/timeseries?query=ip%3A212.18.104.107&start=2025-09-08T06%3A00%3A00Z&end=2025-10-23T12%3A00%3A00Z' \
--header 'key: <your-api-key>'
Recall is built to integrate into the way modern security teams work:
Recall is available now. Lookback window depends on your license tier:
Syntax note: Recall enforces stricter GNQL parsing for performance. Escape spaces with backslashes: tags:*Palo\ Alto* instead of tags:*"Palo Alto"*.
We'll be publishing research built on Recall in the coming weeks—including a retrospective timeline of the React2Shell campaign and analysis of scanning patterns preceding recent zero-day disclosures.
For implementation details and query examples, see the Recall documentation.
Please update your search term or select a different category and try again.
