.png)
GreyNoise has spent years observing the earliest stages of an attack. Our Global Observation Grid sees adversaries as they scan the internet, probe exposed systems, and attempt to exploit vulnerabilities at the edge. That visibility has traditionally focused on the left side of the MITRE ATT&CK framework, from Reconnaissance through Initial Access and it’s where we built our primary-source intelligence brand.
But we’ve known that is only half the equation.
Earlier this year, we launched our C2 Detection Module, expanding our visibility beyond inbound scanning to the attacker-controlled infrastructure used after exploitation. GreyNoise reads the callback destinations embedded in exploit payloads to identify where a compromised device would call home, from malware-hosting servers to suspected C2 infrastructure.
This marked our first move right of Initial Access on MITRE ATT&CK, extending visibility beyond the exploit itself to the infrastructure supporting what happens next. Defenders can match outbound traffic from their edge devices against GreyNoise callback intelligence to identify connections to confirmed malware-serving infrastructure or suspected C2 servers.
When we launched Project Swarm, we opened our deception platform to the global security community. Participants could deploy GreyNoise Deception Sensors across their own infrastructure that looked like the firewalls, routers, VPN gateways, and other internet-facing systems that adversaries target.
Project Swarm users gained full visibility into the sessions reaching their sensors, including raw payloads, HTTP headers, TLS metadata, and other behavioral artifacts.
But a common ask from them was deeper visibility into what happened after an exploit succeeded. What shell commands did the adversary run? What files did they touch? What did they try to do next?
Today, we are launching Tactics, giving anyone deploying a GreyNoise Deception Sensor deeper visibility into what attackers do after initial compromise.
Tactics automatically maps qualifying attacker sessions captured by sensors in your workspace to the MITRE ATT&CK framework. Each detection represents one session and shows the tactics and techniques observed, along with the activity behind the mapping.
You can find Tactics under Observe → Tactics in the GreyNoise Visualizer. Open a detection to:
.png)
Tactics begin populating when your workspace has a sensor running a vulnerable profile. Once an attacker compromises that profile and performs activity mapped to a MITRE ATT&CK technique, the session will appear as a detection.
Routine and unclassified sessions are filtered out, so the view focuses on meaningful adversary behavior rather than every connection your sensor receives.
Because GreyNoise captures the attacker’s interaction with the host, Tactics can identify behavior across the post-compromise stages of MITRE ATT&CK.
That includes:
With Tactics, GreyNoise now shows what adversaries do with access, not just how they find and exploit exposed systems.
Every command, file, hash, path, and network connection captured by a sensor gives defenders a lead they can investigate inside their own environment.
Because this intelligence comes directly from observed session activity, defenders can work from what the adversary actually did after gaining access. Mapping that activity to MITRE ATT&CK makes it easier to understand and use across existing security workflows.
Before launching Tactics, we analyzed weeks of post-compromise activity across our own Deception Sensor network in the Global Observation Grid.
Much of what we observed was commodity cryptomining, with adversaries treating each new foothold as more infrastructure to consume. A smaller set of sessions showed more serious behavior, going after cloud credentials, attempting container escapes, or creating backdoor accounts.
We break down these findings in After the Shell, a new GreyNoise research report published today. It examines what adversaries did after gaining access, which behaviors appeared most often, and what those observations mean for defenders.
Tactics is available for all users who have deployed a GreyNoise sensor. If you already have a sensor deployed, open Tactics under Observe in the GreyNoise Visualizer to see what it has captured.
If you’re new to Project Swarm, deploy a Greynoise Deception Sensor to start observing what attackers do after compromise.
Resolving detection coverage gaps is a universal problem across the security industry. Before joining GreyNoise, I led Elastic’s Endpoint Protections security research team which was tasked with building visibility and detection capabilities in their Endpoint Detection and Response (EDR) solution. Researchers, red teamers, and attackers alike would constantly poke, prod, and reverse engineer our EDR’s detection capabilities then broadcast their evasions and bypasses to the masses. However, I always saw this as a unique challenge; iron sharpens iron, after all, and resolving these issues led to an improved product with expanded coverage. I believe this experience suits me well as I transition into my new role as the Head of Adversary Engagement at GreyNoise and lead our detection and deception engineering efforts.
When GreyNoise was founded in 2018, 16,510 entries were added to the Common Vulnerabilities and Exposures (CVE) system. The number of entries (48,162) added in 2025 shot up to almost triple the number from 2018. Part of this astounding increase in CVEs can be attributed to the sharp rise in the number of CVE Numbering Authorities over the last decade from 23 in 2016 to over 500 by 2026. However, generative AI has had an undeniable impact on the annual number of reported CVEs over the past few years (130% growth from 2022 through 2025) which speaks to an existential crisis currently facing the security industry.
Large language models (LLMs) have lowered the barrier of entry for aspiring vulnerability researchers and exploit developers while significantly enhancing the capabilities of more experienced researchers and attackers. The mean time to exploit CVEs has sharply dropped to the point where it is now slightly negative, meaning that the average vulnerability was likely exploited in the wild before it was reported and assigned a CVE number.
In the face of impactful vulnerabilities and exploits popping up at rates faster than ever, we saw a critical need to revise our approach to threat detection. Our goals are the following:
This article will primarily focus on the first item above, with subsequent articles to come in the following months to highlight the other facets of our evolved threat detection approach.
The typical workflow for a detection engineer after CVE publication may resemble the following:
As you can see, this is a lot of effort for a lone detection engineer to undertake even for a single CVE. With annual CVE additions on track to hit the hundreds of thousands starting in 2027, it is simply not feasible to continue down this path and provide accurate, up to date intelligence on the most critical emerging threats to our users. Evolving our approach is essential to keep pace with a rapidly shifting threat landscape.
Allocating the research and development resources required to design, implement, and refine an efficient pipeline accelerated by agentic workflows is a necessary first step towards proactive threat detection at scale. We aim to leverage frontier large language models to reduce friction and remove onerous mental load bottlenecks for our detection engineers, which will allow us to focus on refining detection logic for the most pervasive threats and quickly provide accurate intelligence to our customers.
Agentic workflows will be critical to delivering real world impact in our revised approach to detection engineering. Agents are currently being designed and implemented to carry out the following tasks for a given CVE:
At this point, our detection engineers will step in to review the draft detection logic and a detailed summary of all tasks the agents carried out along with key indicators associated with exploitation of the given vulnerability. If further refinement of detection logic is needed, changes can be made at this point and reevaluated against our data to ensure sustained precision.
After a GreyNoise Tag is published, agents will continue to monitor for additional references to collect which may be relevant to a given CVE. These periodic collection tasks will similarly assess the quality and relevance of the data and determine whether it is additive in nature and thus necessitate further revision of our detection logic. Proposed tag updates will be drafted and our detection engineers will be notified for further review and to determine if an update needs to be published.
This is the first step in a bold new direction for GreyNoise and our capability to assess and detect the most pervasive and critical threats. We look forward to sharing more with you in the coming months!
Every day, GreyNoise's global sensor network observes scans and attacker traffic from hundreds of thousands of IPs across the internet. GreyNoise analyzes that activity to understand what each IP is doing, why it matters, and which tags and CVEs are connected to it. You can explore it all in the Visualizer.
The Intelligence Dashboard, available now, gives that intelligence a home. You can pin any combination of CVEs, tags, countries, IPs, and GNQL queries into one persistent, always-current view. Open it, and the activity you care about is already there, up to date.
The first time you open the Dashboard tab, GreyNoise builds a Daily Intelligence Dashboard for you, stamped with today’s date and populated from what is currently notable across the sensor network. It is a starting point, not something you have to maintain. Edit it, save your own version, or let it regenerate fresh the next day.
Watch how to build a dashboard from scratch, add and configure panels, and save it for ongoing use.
A dashboard is a set of panels. Each panel combines a panel type (how the data is shown) with a focus (what it shows activity for).
There are five panel types:
And five ways to focus a panel:
The GNQL focus is the most flexible option. Any query you already run in GreyNoise can become a live dashboard panel, so a standing query like tags:mirai classification:malicious turns into something you watch instead of rerunning every time. Just give the panel a name (a sensible default is suggested), and click *Add Panel*.
Every dashboard is built from panels, and adding one takes just a few clicks: pick a panel type and a focus, give it a name, and it lands on your dashboard already populated. You can drag panels to rearrange them, resize them, or expand any panel to full screen.
For the full step-by-step, including every panel type, focus option, and layout control, see the Intelligence Dashboard documentation.
Two controls in the header apply to every panel at once:
The Activity Map is worth a closer look. Countries are color-coded to show whether they are the source of activity, the destination, or both. Click any country on the map or in the sidebar to see the IPs the activity is coming from and the IPs being targeted, along with the organization that owns each one. Every IP links to its detail page, while “View all IPs” in the Visualizer opens the full result set as a GNQL query. When building a map panel, you can also filter it by source or destination country. For example, you could create a map that only shows activity targeting the regions where you operate.
Changes are not saved automatically. When you have unsaved edits, a banner appears with a “Save” button. The dashboard manager, accessed through the panel icon in the header, lets you switch between saved dashboards, search by name, create a new dashboard, or delete one. Dashboards are personal to you within your workspace. You can save up to 50 dashboards, with up to 24 panels in each.
Community and My Workspace require a deployed Swarm sensor. Once you deploy one, access is granted within about 6 hours.
The Intelligence Dashboard is available to all signed-in GreyNoise users. GreyNoise customers and Community users with a business email get at least 10 days of data lookback, while Community users with a consumer email get 2 days. Available data sources may also vary by account type.
To build your first dashboard, open the GreyNoise Visualizer and navigate to Query → Dashboard.
.png)
Every week, GreyNoise publishes a threat intelligence brief called At The Edge. This covers what attackers are doing on the internet, including which products are drawing exploitation traffic, which vulnerabilities are being exploited, and what changed from the previous week. Each brief is built on primary-source data from our global sensor network and analyzed by our research team into named findings, IOCs, and recommended actions.
The Threat Brief Library is now available in the GreyNoise Visualizer. You can browse, search, filter, and download every brief available to your account as a PDF. Community users can access every At The Edge Clear edition, while customers get the full library.
The library includes three report types:
Each brief is built on primary-source data from the GreyNoise Global Observation Grid, our global network of sensors that emulate the edge infrastructure attackers target. The sensors record all the exploitation attempts and our research team correlates them into named campaigns, confirms the CVEs involved, attributes the hosting infrastructure behind them, and writes the detection and remediation guidance.
A full At The Edge brief includes:
Want to see what a week looks like? Read the latest At The Edge Clear edition.
Log in to the GreyNoise Visualizer, click your name on the top right, and open the Threat Brief Library. You can search by title or description, filter by category, and download any brief you have access to as a PDF. The newest briefs appear first. Briefs are also available through the API and an RSS feed, so you can pull them directly into your own tools or subscribe to new briefs as they publish.
The library is available to all GreyNoise users. Community users can read every At The Edge Clear edition, while GreyNoise customers get the full library, including weekly At The Edge briefs and Executive Situation Reports. Read the Threat Briefs documentation to learn more.
Contact us to get access to the full library.
.png)
I spend a lot of my time in SOAR consoles with security teams, and the same pattern shows up almost every time. The automation is already there. Playbooks fire, tickets open, enrichment runs. However, the decisions underneath are still shaky. Automation moves fast; it doesn't move smart on its own. A playbook that auto-routes a case is only as good as the context it routes on.
That's the gap GreyNoise fills. We don't replace your SOAR or your SIEM, we feed them. We tell your playbooks what not to worry about so the team can spend its hours on the activity that's actually aimed at them. Here are the five integrations I walk through in nearly every deployment.
This is where almost everyone starts, and for good reason. Most SOCs still have analysts manually looking up IPs to determine whether an alert matters. The process is slow, repetitive, and often leads to inconsistent triage decisions.
We drop a /v3/ip lookup into the front of the playbook (single lookups or bulk, up to 10K at a time) so every alert gets enriched automatically with classification, tags, and threat level. Then you build your routing rules on top of that. The enrichment writes straight back to the case so the analyst sees the reasoning, not just the verdict.
The payoff is what teams care about most: faster response times, more consistent triage decisions, and a 40–60% reduction in alert volume once routine internet noise is identified and filtered.
Individual organizations often don’t see global exploitation spikes targeting their vendors until it’s too late. A surge in scanning or exploitation against a particular vendor's CVE can be an early sign of a zero-day or novel attack, but those patterns are difficult to detect when you're only looking at activity inside your own environment. By the time you hear about it after the vendor publishes an advisory, it may already be too late.
GreyNoise Event Feeds push an alert into SOAR the moment scanning or exploitation activity against your vendors' CVEs spikes. The playbook takes it from there: assess benign versus malicious activity, enrich with CVE and IP context, open a case, create a VM ticket, update blocklists, and notify the team in ChatOps.
The outcome is simple: detect rising exploitation activity days before vendors announce new vulnerabilities, patch and harden before attacks become widespread, and automatically separate real threats from benign scanning activity.
This one resonates with anyone who's been burned by a compromised firewall or VPN appliance. You can't run EDR on those boxes, so when one gets popped and starts scanning the internet or calling home to attacker-controlled C2 infrastructure, you typically don't find out until blacklisted or it’s reported by an external party.
We run two feeds into the SOAR for this. First, a webhook fires when GreyNoise observes your IP ranges conducting unsolicited scanning, a strong signal something behind that address is compromised. Second, a callback IP feed alerts whenever we detect a new attacker callback destination, which the SOAR correlates against your outbound traffic. Either one triggers automatic case creation and a containment ticket. That means catching compromise before it leads to reputation damage, responding automatically in seconds, and keeping persistent issues tied together in a single case timeline.
Every team wants to automate blocklist updates. Almost none of them fully trust the automation, because the nightmare scenario is auto-blocking a business-critical IP and taking down a legitimate service during business hours.
The fix is a validation step. Before an IP gets added to the blocklist, the playbook checks it against GreyNoise business services intelligence. If the IP is tied to a known business service, it routes to a human for manual review. If it's not, the block proceeds automatically. You get fast response to likely-malicious IPs without the over-blocking risk that keeps people from turning automation on in the first place.
The result is greater confidence in automated blocklist updates, reduced over-blocking risk, and faster response to likely malicious IPs. When I show this to a hesitant team, it's usually the thing that unblocks their whole automation roadmap.
Most of the teams I work with are building agentic workflows now, and they keep running into the same wall: an agent is only as good as the context it can reach. Point it at incomplete or low-confidence data and you get confident-sounding nonsense.
GreyNoise plugs into those workflows through APIs, skills, or MCPs, so an agent investigating an alert can pull high-quality threat intelligence directly into its reasoning before it acts. The agent receives a trigger, queries GreyNoise, analyzes the context, and either returns an answer or kicks off a response workflow. This is grounded in observed attacker behavior rather than guesswork.
It's still early days for a lot of these deployments, but the teams seeing the most success are treating threat intelligence as a core input to the agent, not something bolted on afterward. The result is faster, more confident investigation and response grounded in high-quality threat intelligence.
Which alerts deserve attention? Which CVEs are actively being exploited? Which IPs are worth blocking? Which signals point to a compromised device?
The reason these workflows work is because they're all built on the same foundation: real observations from across the internet. GreyNoise continuously watches scan and attack activity through our global sensor network, so when a playbook makes a decision, it's based on what an IP is actually doing in the wild, not just what it happened to do in your environment.
That's what gives teams the confidence to automate. Route an alert. Open a case. Block an IP. Escalate an investigation. The decision is backed by observed behavior, not a hunch.
I tell teams all the time that automation isn't the hard part anymore. Most organizations already have playbooks that can move fast. The challenge is making sure they're making the right decisions when they do.
If your SOAR is great at taking action but you're still questioning the inputs behind those actions, these are the first five workflows I'd look at. Explore our SOAR integrations >
Want to see any of these wired up live? Book a demo >
Every organization connected to the internet faces the same background noise: automated exploitation attempts, vulnerability scanning, and credential abuse hitting the perimeter around the clock. The hard part isn't seeing the traffic, it's answering three questions fast enough to matter. What's hitting us? What's getting through? And what's already talking to adversary infrastructure?
GreyNoise continuously observes scan and attack activity across the internet, classifies the source IPs by behavior, and delivers that intelligence into your SIEM. The point isn't more data. It's separating the opportunistic noise, the stuff hitting everyone, from activity that might actually be aimed at you. Here are four ways SOC teams are putting that distinction to work.
Detections on perimeter scans and attacks are noisy by nature. Most alerts off edge devices aren't real threats, so they get ignored or suppressed. The alerts worth investigating are in there but they're just buried under scanning noise that hides anything resembling a targeted threat.
Filter your firewall and WAF logs down to inbound internet traffic, then match source IPs against GreyNoise and exclude the known mass scanners. Prioritize what's left by source-IP volume. Stripping out opportunistic scanning means analysts triage far fewer events, and the detection logic that remains has room to surface traffic more likely to represent targeted reconnaissance or attack activity.
Fewer alerts, better signal-to-noise. Every remaining alert comes from an IP GreyNoise has never observed scanning the internet, which is a much stronger indicator of potential targeted reconnaissance.
Perimeter gaps go unnoticed because nothing validates whether traffic that was allowed through should have been. Without external intelligence, traffic that passes through the firewall may not receive additional scrutiny, even when the source IP has a documented history of malicious activity.
Correlate firewall and WAF allow logs against GreyNoise intelligence. Filter to inbound allowed events, match the source IPs against GreyNoise, and surface the malicious and suspicious matches, prioritized by source-IP volume. That tells you when something you let in originated from a host observed conducting mass scanning or exploitation.
A list of sessions where known-malicious or suspicious IPs were permitted through your perimeter. Each match is two things at once: a session worth investigating, and a firewall or WAF rule worth re-evaluating.
Authentication failures and brute-force attempts from the internet are constant for any perimeter device. The trouble is telling opportunistic account access apart from attempts aimed specifically at your organization. Hosts running mass scans or operating as part of botnet or proxy infrastructure authenticate to VPNs and identity providers all the time, and standard detection logic doesn't flag it.
Correlate VPN and identity-provider authentication logs with GreyNoise. Filter to authentication events, match source IPs against GreyNoise, include the not-spoofable matches, and prioritize by source-IP volume. That surfaces auth attempts coming from hosts already observed scanning the internet, early enough to intervene on both successful and failed attempts.
A successful auth from a GreyNoise-flagged IP is an immediate, high-priority alert. Failed attempts from flagged IPs are worth a look too, as they can indicate active targeting of your identity infrastructure rather than random background noise.
Outbound connection volume is so high that alerting on or investigating anomalous connections individually is impractical, so connections from internal infrastructure to known-malicious systems slip by. Most threat intel feeds don't help here either because they lack the real-time behavioral data needed to tell which outbound connections actually warrant a look.
Internal hosts reaching out to malicious infrastructure is a clear sign of compromise. Take outbound network and EDR logs, filter to public connections that egress allowed, match destination IPs against GreyNoise, and surface the malicious matches, prioritized by internal source-IP volume. When an internal host lights up here, the correlation points at a possible indicator of compromise - C2 beaconing, data exfiltration, or botnet participation.
Any successful outbound connection to GreyNoise-classified malicious infrastructure warrants immediate investigation of the internal host for indicators of compromise.
Stacked together, these four detections move the needle on the things that security teams actually care about:
None of this replaces the tooling you already run. GreyNoise is the context layer that makes your firewall, WAF, identity provider, EDR, and SIEM better at separating the internet's constant background noise from the activity worth your analysts' time.
Want to start deploying these detections? Talk to our team >
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 integration with Google Security Operations enables 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, we're announcing a new and improved integration with Google Security Operations — delivering standardized indicator ingestion, pre-built dashboards, YARA-L detection rules, saved searches, response actions, webhook support, and ready-to-deploy playbooks.
The GreyNoise ingestion script is now available in Google Security Operations 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 Google Security Operations 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 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 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. 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.
Webhooks close the loop by pushing GreyNoise alerts — including classification changes and CVE spikes — directly into Google Securioty Operations for quick 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:
Please update your search term or select a different category and try again.
