.png)
Security teams already have access to blocklists; commercial feeds, community lists, vendor-curated sets of bad IPs — they’ve been around for decades. And yet, every practitioner has experienced the same frustrations: the lists are too noisy, too static, too opaque, too slow to update, or just not quite meeting the right criteria.
That’s why GreyNoise built Block, a blocklist approach designed to be highly configurable, grounded in primary-sourced intelligence, and updated in real-time as attacker behavior changes.
Most blocklists share common issues:
As a result, network security teams struggle to balance security and availability, concerned that they’ll block legitimate traffic or fail to block malicious traffic.
GreyNoise approaches blocklists from a different angle:
GreyNoise Block delivers practical benefits to cybersecurity teams:
Creating blocklists within GreyNoise Block could not be easier. To optimize flexibility, each blocklist is associated with a GNQL query. For ease of use, GreyNoise includes a set of query templates that provide pre-built blocklists. Start by either selecting a pre-built template or writing a query from scratch.
When selecting a template, you can click “Block These IPs” to create a blocklist immediately or click “Edit Query” to refine the blocklist’s criteria even further. When editing the query, you can add, remove, or modify fields and group them logically through and/or clauses. As you modify fields, the Query Stats panel on the right updates automatically.
Once you have the query looking as you want it in the Query Builder, click the “Block These IPs” button to turn the query into a blocklist.
In the Create Blocklist dialog box, give the query a name and assign it an IP limit, which might be necessary if your firewall has a maximum supported size.
Once the block list is created, click the My Blocklists link at the top of the page to view the new block list and any others you have created. From the list, you can copy the blocklist URL to your firewall.
That’s all there is to it. Your firewall will periodically poll the blocklist URL and keep that bad traffic out of your network.
GreyNoise Block is available now with a free trial for 14 days.
.png)
In a significant escalation, the botnet has grown to ~300,000 IPs — more than tripling in size. The threat actor(s) continues its focus on RDP infrastructure in the United States, leveraging IPs from Brazil, Argentina, Singapore, and other countries.
The associated threat actor(s) is rapidly activating new botnet nodes to target U.S. RDP infrastructure. Therefore, static defense measures will not be effective at mitigating this threat.
Since October 8, 2025, GreyNoise has tracked a coordinated botnet operation involving over 100,000 unique IP addresses from more than 100 countries targeting Remote Desktop Protocol (RDP) services in the United States. The campaign employs two specific attack vectors — RD Web Access timing attacks and RDP web client login enumeration — with most participating IPs sharing one similar TCP fingerprint, indicating centralized control.
Use GreyNoise Block to dynamically block all IPs engaged in this activity.
The botnet was discovered after GreyNoise detected an unusual spike in Brazilian IP space this week, which prompted investigation into broader traffic patterns.
Note: Full interaction = completed three-way handshake; No 3wh = no three-way handshake
Broadening our analysis, we observed additional surges in activity across many source countries since the beginning of October.
Pivoting from these findings, we then discovered a repeated pattern in RDP targeting — originating from many countries, sharing a similar client fingerprint, and all targeting US RDP infrastructure.
Several factors suggest this activity is originating from one botnet:
GreyNoise will continue monitoring the situation and provide updates here as necessary.
---
This discovery was led by boB Rudis with contributions from the broader GreyNoise team.
Time is critical in incident response. The gap between exploit disclosure and patching, between compromise and containment, or between detection and recovery often determines the difference between a near miss and a major breach. Attackers automate everything from recon to exploit creation. Defenders need to close the speed gap.
Most threat intelligence workflows still rely on polling. Analysts or automated systems query APIs or dashboards on fixed schedules—every few minutes, every hour, sometimes even less frequently. By the time new data is pulled in, attackers may have already rotated infrastructure, moved laterally, or pivoted to a new exploit. This delay undermines automation investments, keeping defenders stuck in reaction mode.
GreyNoise Feeds eliminate the need for polling by delivering event-driven webhook-based push notifications the moment something changes. Instead of waiting for the next scheduled query, your automation receives the update as soon as GreyNoise sees it. Teams can subscribe to three types of events:
GreyNoise Feeds are designed to be wired directly into automation platforms like SIEMs and SOARs. With feeds in place, teams can:
GreyNoise Feeds are quite easy to configure. Give the Feed a name, specify the type, that is whether IP classification change, CVE status change, or CVE activity spike, indicate the direction of the change (such as from unknown to malicious), and specify whether to notify on all IP addresses and CVEs or a select subset.
You will also need to configure where GreyNoise should deliver the notifications, and each feed can have a unique delivery address. The address is a url that has been configured to receive webhook feeds. In order to support authentication and other features, GreyNoise Feeds supports adding custom HTTP headers.
GreyNoise Feeds take intelligence out of batch mode. Instead of asking what changed after the fact, your systems can respond the moment GreyNoise sees new exploitation, malicious activity, or infrastructure shifts. For defenders racing against automated attackers, that time advantage matters.
Learn more and watch videos on how to use at GreyNoise docs.
.png)
GreyNoise has identified several links between three recent campaigns:
We assess with high confidence that all three campaigns are at least partially driven by the same threat actor(s), evidenced by:
In addition to continued escalation of login attempts against Palo login portals, GreyNoise has identified likely related and coordinated credential brute forcing against Fortinet SSL VPNs. We are providing a list of credentials used in the recent Fortinet campaign.
All three campaigns — Cisco ASA scanning, Palo login attempts, and Fortinet VPN brute forcing — heavily rely on the same subnets:
Use GreyNoise Block to directly block threat IPs from all relevant GreyNoise tags (ASA Scanner, Fortinet VPN Bruteforcer, Palo Scanner) and the below ASNs:
Defenders can use GreyNoise Block to craft custom blocklists, instantly mitigating risk at the perimeter.
In July, GreyNoise research identified a significant correlation:
Spikes in Fortinet VPN brute force attempts are typically followed by Fortinet VPN vulnerabilities disclosures within six weeks.
Block all IPs brute forcing Fortinet SSL VPNs, and consider hardening defenses for firewall and VPN appliances amid these findings.
For defender review, GreyNoise has published a list of all unique usernames and passwords from Palo login attempts observed in the last week.
GreyNoise has produced an Executive Situation Report (SITREP) on the situation, intended for decision makers.
In the past days, GreyNoise has observed an escalation in scanning against Palo Alto Networks PAN-OS GlobalProtect login portals. Since our original reporting of ~1,300 IPs in the afternoon of 3 October, we have observed a sharp rise in the daily number of unique IPs scanning for Palo login portals. Peaking today on 7 October, over 2,200 unique IPs scanned for Palo login portals.
In addition to an increase in the number of IPs involved, GreyNoise has observed a sharp increase in the unique count of ASNs involved in scanning Palo login portals, suggesting an increase in the number of threat actors involved.
Separately, we discovered that approximately 12 percent of all ASN11878 subnets are allocated to scanning Palo login portals.
The pace of login attempts suggests elevated activity may be driven by a threat actor(s) iterating through a large dataset of credentials.
.png)
On October 3, 2025, GreyNoise observed a ~500% increase in IPs scanning Palo Alto Networks login portals, the highest level recorded in the past 90 days.
GreyNoise research in July found that surges in activity against Palo Alto technologies have, in some cases, been followed by new vulnerability disclosures within six weeks (see chart below). However, surges against GreyNoise’s Palo Alto Networks Login Scanner tag have not shown this correlation. GreyNoise will continue monitoring in case this activity precedes a new Palo Alto disclosure, which would represent an additive signal to our July research.
GreyNoise analysis shows that this Palo Alto surge shares characteristics with Cisco ASA scanning occurring in the past 48 hours. In both cases, the scanners exhibited regional clustering and fingerprinting overlap in the tooling used. Both Cisco ASA and Palo Alto login scanning traffic in the past 48 hours share a dominant TCP fingerprint tied to infrastructure in the Netherlands. This comes after GreyNoise initially reported an ASA scanning surge before Cisco’s disclosure of two ASA zero-days.
These similarities indicate the activity may be related through shared tooling or centrally managed infrastructure, but GreyNoise cannot confirm whether it was carried out by the same operators or with the same intent.
In addition to a possible connection to ongoing Cisco ASA scanning, GreyNoise identified concurrent surges across remote access services. While suspicious, we are unsure if this activity is related.
These factors distinguish the surge from background noise and mark it as a clear reconnaissance event. GreyNoise will continue monitoring for potential follow-on exploitation attempts.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
This research and discovery was a collaborative effort between boB Rudis and Noah Stone, with additional contributions from Towne Besel.
.png)
For executive audiences, please see the accompanying Situation Report (SITREP) for this activity.
On 28 September 2025, GreyNoise observed a sharp one-day surge of exploitation attempts targeting CVE-2021-43798 — a Grafana path traversal vulnerability that enables arbitrary file reads. Over the course of the day, 110 unique IPs attempted exploitation against GreyNoise’s Global Observation Grid (GOG). All 110 IPs are classified as malicious.
Grafana exploitation had been largely quiet in recent months. On 28 September, activity spiked sharply:
Two elements stand out in the data:
The alignment across both geography and tooling suggests shared tasking or a common target list, not uncoordinated traffic.
Two IPs geolocated to China are worth highlighting:
Both belong to CHINANET-BACKBONE, were first observed on 28 September, active only that day, and overwhelmingly focused on Grafana.
Exploitation of older, high-impact vulnerabilities like CVE-2021-43798 is common across different threat categories:
This activity reflects a coordinated push against a known, older vulnerability. The uniform targeting pattern across source countries and tooling indicates common tasking or shared exploit use. GreyNoise does not attribute this to a specific threat actor, but the convergence suggests either one operator leveraging diverse infrastructure or multiple operators reusing the same exploit kit and target set.
We anticipate old vulnerabilities — like CVE-2021-43798, and even older ones — will continue resurging in the future. Read GreyNoise’s research from earlier this year to learn more about the patterns and behaviors resurgent vulnerabilities tend to exhibit, and how defenders can stay ahead.
Please contact your GreyNoise support team if you are interested in the JA4+ signatures in this investigation.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
This research and discovery was a collaborative effort between Glenn Thorpe, Noah Stone, Towne Besel, and boB Rudis.
.png)
While we may not know when the agentic SOC will arrive, we do know it will need timely and accurate intelligence to make good decisions. To provide that intel, we’re making the GreyNoise MCP Server available today, enabling easy integration of GreyNoise intel by Model Context Protocol (MCP) compatible AI agents.
When an AI agent sees an IP address or CVE in a workflow, it can query GreyNoise in real time and learn:
This grounding mitigates the risk of hallucinations and prevents agents from treating every alert equally, enabling more realistic, risk-based automation.
With GreyNoise data inside the reasoning loop, agents can handle several critical tasks more effectively:
SOC teams already use GreyNoise to separate background scanning from true threats. What changes with the MCP Server is that the same logic is now available directly to AI agents.
This combination makes GreyNoise data especially well-suited to agentic SOC environments, where decisions need to be fast but also defensible.
Let’s say your manager wants an intelligence report, perhaps regarding an external threat, a set of IP addresses, or a vulnerability. For example, I may need to create a report based on a CVE, so I open Claude with the GreyNoise MCP server installed and enter the prompt:
Notice how Claude is making several calls to the GreyNoise MCP server as well as other sources so that it can combine these sources into a report.
Because of the GreyNoise MCP, the report includes details about IP address counts and recent surges in activity. Adding more to the prompt, such as “Tell me about the source geography of the attacks”, causes Claude to generate a much more detailed report. With minimal effort, you can write a prompt that creates just the report that you need. You can even ask for vendor risk reports and threat hunting plans. It’s a great way to reliably use AI to lighten your workload.
Agentic SOCs are still an emerging concept, but the risks can be mitigated and the value better realized if AI agents make decisions grounded in trustworthy data. The GreyNoise MCP Server provides a way to embed that grounding directly into agentic workflows.
For security teams, this doesn’t mean replacing analysts—it means giving agents access to the same noise-filtering and exploitation-awareness that practitioners already rely on, so that automation can act responsibly at scale.
Indeed, analysts can make great use of the MCP just by interacting with an LLM application that supports MCP, such as Claude. Conduct research. Look into trends. Generate reports. It’s as easy as it is fun.
Find everything you need to know in the GreyNoise MCP Server docs.
GreyNoise identified a connection between three campaigns targeting Cisco, Palo Alto, and Fortinet firewalls and VPNs. We observed infrastructure overlap between recent Cisco ASA scanning, Palo login attempts, and Fortinet brute force attempts:
See the full update here.
GreyNoise has produced an Executive Situation Report (SITREP) on the situation, intended for decision makers.
Yesterday, Cisco announced two zero-day vulnerabilities affecting their Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) platforms. These disclosures come just weeks after GreyNoise reported a surge in scanning activity against Cisco ASA devices (see initial reporting below). The timing is notable because recent research found that spikes in attacker activity against a specific technology (white dots) may serve as an early warning signal for future vulnerability disclosures affecting that same technology (red dots).
GreyNoise’s detection of 25,000 IPs scanning Cisco ASA in the weeks leading up to two zero day disclosures is a clear example of this research turning into reality:
“This is a real signal we’re seeing in our data across enterprise edge tech,” said boB Rudis, VP of Data Science and Security Research at GreyNoise. “We see elevated attacker activity against XYZ tech and then weeks later, new CVEs are disclosed affecting XYZ tech. This has repeatedly happened across enterprise edge, with Cisco ASA being the most recent example. So, yes, we’re very excited to learn our data may serve as an early warning signal for future vulnerability disclosures and we hope defenders will use this information to make the world a little safer.”
CISA issued an Emergency Directive (ED 25-03), requiring federal agencies to apply mitigations within 24 hours — representing the third-ever emergency directive since the agency’s founding. Both vulnerabilities, tracked as CVE-2025-20333 and CVE-2025-20362, have been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog.
After investigating activity against our Cisco profiles, GreyNoise identified resurgent brute force attacks targeting Cisco SSL VPNs occurring yesterday at approximately 1:00pm EST. This activity was preceded by a period of inactivity, ceasing on September 24 at 6PM EST and restarting yesterday. All traffic during this period shares the same client fingerprint and source organization (Global Connectivity Solutions LLP), along with other shared characteristics:
CISA has issued guidance and mitigation instructions related to CVE-2025-20333 and CVE-2025-20362. We encourage defenders to review CISA’s official resources and apply recommended actions.
GreyNoise will continue monitoring its Cisco profiles for anomalous behavior, and will provide updates here as necessary.
---
GreyNoise observed two scanning surges against Cisco Adaptive Security Appliance (ASA) devices in late August. The first involved more than 25,000 unique IPs in a single burst; the second, smaller but related, followed days later. This activity represents a significant elevation above baseline, typically registering at less than 500 IPs per day.
Both events targeted the ASA web login path (/+CSCOE+/logon.html), a common reconnaissance marker for exposed devices. Subsets of the same IPs also probed GreyNoise’s Cisco Telnet/SSH and ASA software personas, signaling a Cisco-focused campaign rather than purely opportunistic scanning.
.png)
In the past 90 days, GreyNoise has observed traffic triggering its Cisco ASA Scanner tag originating from and targeting the following countries:
Note: Target country percent sum may exceed 100% due to one source IP targeting several IPs based in different countries.
Analysis of the August 26 wave shows that it was driven primarily by a single botnet cluster concentrated in Brazil. By isolating a specific client fingerprint, and reviewing two months of activity, GreyNoise determined that this fingerprint was used exclusively to scan for Cisco ASA devices.
On August 26:
The client signature was seen alongside a suite of closely related TCP signatures, suggesting all nodes share a common stack and tooling. This makes the August 26 spike attributable to a coordinated botnet campaign dominated by Brazil-sourced infrastructure.
GreyNoise’s Early Warning Signals research shows that scanning spikes often precede disclosure of new CVEs. In past cases, activity against GreyNoise’s Cisco ASA Scanner tag surged shortly before a new ASA vulnerability was disclosed (see last row in chart below). The late-August spikes may represent a similar early warning signal.
Even if organizations are fully patched, blocking these IPs now may reduce the likelihood of appearing on target lists used to exploit new CVEs in the future.
Monitor GreyNoise’s Cisco ASA tags for real-time scanning and exploitation activity:
GreyNoise will continue monitoring the situation and update this blog as necessary. Concentrated reconnaissance bursts, such as those in August, should be treated as potential early indicators of future vulnerability disclosures.
Please contact your GreyNoise support team if you are interested in the JA4+ signatures in this investigation.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
This research and discovery was a collaborative effort between Towne Besel and Noah Stone.
Hours after publishing this blog, GreyNoise identified a much larger wave: on August 24, over 30,000 unique IPs simultaneously triggered both Microsoft RD Web Access and Microsoft RDP Web Client tags, largely from the same client signature behind the August 21 spike we reported below.
On August 21, GreyNoise observed a sharp surge in scanning against Microsoft Remote Desktop (RDP) services. Nearly 2,000 IPs — the vast majority previously observed and tagged as malicious — simultaneously probed both Microsoft RD Web Access and Microsoft RDP Web Client authentication portals. The wave’s aim was clear: test for timing flaws that reveal valid usernames, laying the groundwork for credential-based intrusions.
Separately but potentially relevant, on August 22 GreyNoise observed a spike in scanning for open proxies. This heightened activity follows recent anomalies observed on July 31 and August 9 against GreyNoise’s Open Proxy Scanner tag. Early research indicates there is partial overlap in client signatures between this spike and the RDP scan detected on August 21.
The timing may not be accidental. August 21 sits squarely in the US back-to-school window, when universities and K-12 bring RDP-backed labs and remote access online and onboard thousands of new accounts. These environments often use predictable username formats (student IDs, firstname.lastname), making enumeration more effective. Combined with budget constraints and a priority on accessibility during enrollment, exposure could spike.
The campaign’s US-only targeting aligns with that calendar — education and IT teams should harden RDP now and watch for follow-up activity from this same client signature.
The RDP scanners were doing more than just touching login pages:
This is enumeration: confirming accounts on exposed systems so later credential stuffing, password spraying, or brute force has a much higher chance of success.
A large, uniform, maliciously-classified scanner set is actively mapping Microsoft RDP authentication surfaces for account discovery weaknesses. Even without immediate exploitation, the output of this campaign (which endpoints exist, which accounts likely exist) is directly reusable for:
Recent research found spikes in attacker activity against a given technology tend to precede new vulnerabilities in that technology. In 80 percent of cases, a new vulnerability emerged within six weeks of a spike.
RDP has been leveraged by threat actors in the past to conduct espionage, deploy ransomware, and run global exploit campaigns:
GreyNoise will continue monitoring the situation and update this blog as necessary.
Please contact your GreyNoise support team if you are interested in the JA4+ signatures in this investigation.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content initiatives that illuminate the complexities of internet noise and threat intelligence. In past roles, he led partnered research initiatives with Google and the U.S. Department of Homeland Security. With a background in finance, technology, and engagement with the United Nations on global topics, Stone brings a multidimensional perspective to cybersecurity. He is also affiliated with the Council on Foreign Relations.
On August 3, GreyNoise observed a significant spike in brute-force traffic targeting Fortinet SSL VPNs. Over 780 unique IPs triggered our Fortinet SSL VPN Bruteforcer tag in a single day — the highest single-day volume we’ve seen on this tag in recent months.
New research shows spikes like this often precede the disclosure of new vulnerabilities affecting the same vendor — most within six weeks. In fact, GreyNoise found that spikes in activity triggering this exact tag are significantly correlated with future disclosed vulnerabilities in Fortinet products. The below chart shows spikes in activity against Fortinet tags (white dots) and CVE disclosures affecting Fortinet products (red dots):
.png)
Critically, the observed traffic was also targeting our FortiOS profile, suggesting deliberate and precise targeting of Fortinet’s SSL VPNs. This was not opportunistic — it was focused activity.
The top target countries in the past 90 days are Hong Kong and Brazil.
When we reviewed a two week window of traffic matching the Fortinet SSL VPN Bruteforcer tag, two distinct waves emerged:
This made the decision easy: we pivoted to the second wave to learn more.
Once the TCP signature for the second wave was isolated, we paired it with an observed client signature seen in sessions during the same timeframe.
What we found was surprising.
While the August 3 traffic has targeted the FortiOS profile, traffic fingerprinted with TCP and client signatures — a meta signature — from August 5 onward was not hitting FortiOS. Instead, it was consistently targeting our FortiManager - FGFM profile albeit still triggering our Fortinet SSL VPN Bruteforcer tag.
This indicated a shift in attacker behavior — potentially the same infrastructure or toolset pivoting to a new Fortinet-facing service.
IPs associated with the meta signature:
31.206.51.194
23.120.100.230
96.67.212.83
104.129.137.162
118.97.151.34
180.254.147.16
20.207.197.237
180.254.155.227
185.77.225.174
45.227.254.113
One additional lead emerged during the investigation.
When reviewing historical data tied to the same post-August 5 TCP fingerprint, we found an earlier spike in June with a unique client signature that resolved to an IP — a FortiGate device — in a residential ISP block (Pilot Fiber Inc.). This may indicate that the brute-force tooling was initially tested or launched from a home network — or it could reflect use of a residential proxy. A quick search of the device revealed:
Notably, traffic tied to that same client signature in June was later seen paired with the same TCP signature associated with the longer-running brute-force cluster (Wave One) mentioned earlier. This overlap doesn’t confirm attribution, but it suggests possible reuse of tooling or network environments. Simply put, this side quest led us back to the original traffic associated with the August 3 spike.
Use GreyNoise to:
Please contact your GreyNoise support team if you are interested in the JA4+ signatures in this investigation.
GreyNoise will continue monitoring the situation and provide updates as necessary.
GreyNoise is developing an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more or get on the waitlist.
— — —
This research and discovery was a collaborative effort between Towne Besel and Noah Stone.
In today’s threat landscape, speed isn’t optional — it’s existential. As attacks get faster, so too must your defense.
Attackers increasingly leverage automation, AI, and vast, ephemeral infrastructure to launch mass exploitation campaigns that scan, breach, and pivot within minutes — sometimes before a CVE is even publicly disclosed. Defenders, meanwhile, are often stuck pulling data manually, querying APIs, or waiting for threat feeds to update.
That’s the speed gap that attackers exploit. Today, we're launching a series of new capabilities to help defenders close that gap. These new capabilities help security teams leverage real-time threat intel to detect, block, and respond faster than ever before
The game has changed:
Yet many defenders still operate in batch mode: querying APIs, pulling feeds manually, or reacting only after the damage is done. GreyNoise is flipping that script. We’re giving defenders real-time, automation-ready intelligence — designed to meet the speed, volume, and precision required by modern security teams.
Stop mass exploitation at the edge — before it gets in.
GreyNoise-verified malicious IPs involved in opportunistic reconnaissance and exploitation are delivered in real time, designed to be integrated directly into your perimeter defenses.
Use it to:
Threat intelligence that comes to you — automatically.
Say goodbye to the delays caused by polling APIs. Our new push-based data delivery means GreyNoise intelligence is streamed directly to your systems via webhooks — the moment we detect something new.
In security, minutes (even seconds) matter. Push-based intelligence closes the speed gap between attack and defense.
From detection to action — with zero manual steps.
GreyNoise now integrates natively with leading SOAR platforms–such as Splunk SOAR, Palo Alto Networks XSOAR, IBM QRadar SOAR–to help teams turn intelligence into action, instantly and automatically.
Automate key workflows like:
The result:
These launches are part of GreyNoise’s commitment to empowering defenders with:
These new capabilities are built for:
GreyNoise is building the future of threat intelligence for defenders who don’t have time to wait.
Meet with us at Black Hat 2025 to learn more — or get started today.
.png)
It’s well known that the window between CVE disclosure and active exploitation has narrowed. But what happens before a CVE is even disclosed?
In our latest research “Early Warning Signals: When Attacker Behavior Precedes New Vulnerabilities,” GreyNoise analyzed hundreds of spikes in malicious activity — scanning, brute forcing, exploit attempts, and more — targeting edge technologies. We discovered a consistent and actionable trend: in the vast majority of cases, these spikes were followed by the disclosure of a new CVE affecting the same technology within six weeks.
This recurring behavior led us to ask:
Could attacker activity offer defenders an early warning signal for vulnerabilities that don’t exist yet — but soon will?
Across 216 spikes observed across our Global Observation Grid (GOG) since September 2024, we found:
Exploit activity may be more than what it seems. Some spikes appear to reflect reconnaissance or exploit-based inventorying. Others may represent probing that ultimately results in new CVE discovery. Either way, defenders can take action.
Blocking attacker infrastructure involved in these spikes may reduce the chances of being inventoried — and ultimately targeted — when a new CVE emerges. Just as importantly, these trends give CISOs and security leaders a credible reason to harden defenses, request additional resources, or prepare strategic responses based on observable signals — not just after a CVE drops, but weeks before.
The full report includes:
This research builds on our earlier work on resurgent vulnerabilities, offering a new lens for defenders to track vulnerability risk based on what attackers do — not just what’s been disclosed.
One of our engineers was reviewing our telemetry dashboard when he came across something unusual:
A tight cluster of red dots — each one representing a malicious IP — lighting up a rural patch of New Mexico:
Nothing unusual about botnet traffic. But this time, dozens of malicious IPs were all coming from a single region with a population of just over 3,000 people.
It didn’t fit the pattern. So we dug in.
We zoomed into the map and picked up the first IP: 137.118.82.76.
It had a troubling combination of GreyNoise tags:
This wasn’t just a misconfigured device — it looked like a system actively participating in a botnet.
So we pulled the thread.
Zooming out, we found ~90 IPs in the same New Mexico region, all tied to a single provider: Pueblo of Laguna Utility Authority.
100% of this traffic was Telnet-based.
To dig deeper, we used our internal tooling — including the GreyNoise Model Context Protocol (MCP) server (an AI-powered analysis environment) — to iterate quickly on investigation paths.
We fed IP metadata and network behavior into Claude, exploring ideas in real time. We then used Censys infrastructure data and tshark packet captures to enrich the dataset.
This AI-powered analysis helped confirm that many of the systems were VOIP-enabled devices.
While we did not identify exact device models for each system, enrichment suggested hardware from Cambium Networks was likely involved in a portion of the activity.
It wasn’t a one-off misconfiguration — it appeared to be a coordinated cluster of similar systems likely running comparable stacks.
After confirming the localized activity, we widened the investigation.
Using GreyNoise tags, behavioral similarity, and Telnet traffic patterns, we identified about 500 IPs globally exhibiting similar traits:
Some of these IPs were linked to VOIP-capable devices and shared similar infrastructure characteristics — suggesting a wider class of exposed systems is being targeted for botnet activity.
VOIP devices often run on older Linux-based firmware, sometimes with Telnet exposed by default. They’re also frequently:
Some Cambium routers, for example, may still be running firmware versions impacted by a known remote code execution (RCE) vulnerability from 2017.
While we did not confirm exploitation of that CVE in this case, the activity reinforces a broader point: Vulnerabilities remain part of the attack surface long after disclosure.
We recently explored this dynamic in our latest report on resurgent vulnerabilities, where we highlight how long-patched flaws in edge devices are repeatedly targeted.
Shortly after a member of our team posted a brief mention of the activity on social media, the traffic from the New Mexico utility dropped off — completely.
Whether coincidence or evidence that attackers monitor visibility, it was a sharp cutoff.
And shortly after that, activity spiked yet again and the global behavior continued.
What started as a spike from a single utility in a rural part of the United States became a lens into an ongoing global pattern — one defenders should track closely.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
---
This investigation was sparked by GreyNoise’s keen-eyed Lead Software Engineer Jeff Golden, with contributions from the broader GreyNoise research team.
GreyNoise has received a statement from TeleMessage, stating:
CVE-2025-48927 was fully remediated in the TeleMessage environment in early May. That remediation has been independently verified by our third-party cybersecurity partner. As a cloud-native SaaS platform, all fixes were applied centrally, and no action was required by customers. As such, any attempts to exploit CVE-2025-48927 since that time have been unsuccessful.
A vulnerability disclosed in May 2025, CVE-2025-48927, affects certain deployments of TeleMessageTM SGNL, an enterprise messaging system modeled after Signal, used by government agencies and enterprises alike to archive secure communications. The issue stems from the platform’s continued use of a legacy confirmation in Spring Boot Actuator, where a diagnostic /heapdump endpoint is publicly accessible without authentication.
If exposed, this endpoint can return a full snapshot of heap memory — roughly 150MB — which may include plaintext usernames, passwords, and other sensitive data. While newer versions of Spring Boot no longer expose this endpoint by default, public reporting indicates that TeleMessage instances continued using the older, insecure configuration through at least May 5, 2025.
On July 14th, CVE-2025-48927 was added to CISA’s Known Exploited Vulnerabilities (KEV) catalog.
See GreyNoise’s technical writeup here.
As of July 16, GreyNoise has observed 11 IPs attempting to exploit CVE-2025-48927 (tag created July 10).
Related reconnaissance behavior is ongoing. Our telemetry shows active scanning for Spring Boot Actuator endpoints — a potential precursor to identifying systems affected by CVE-2025-48927.
Organizations using Spring Boot — particularly in internal tools or secure messaging environments — should verify whether the /heapdump endpoint is exposed to the internet.
GreyNoise will continue monitoring for shifts in scanning behavior and provide updates if exploitation begins.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
---
This analysis was led by GreyNoise Researcher Howdy Fisher.
GreyNoise has observed active exploitation attempts against CVE-2025-5777 (CitrixBleed 2), a memory overread vulnerability in Citrix NetScaler. Exploitation began on June 23 — nearly two weeks before a public proof-of-concept (PoC) was released on July 4.
We created a tag on July 7 to track this activity. Because GreyNoise retroactively associates pre-tag traffic with new tags, prior exploitation attempts are now visible in the GreyNoise Visualizer.
.png)
Early exploitation attempts came from malicious IPs geolocated in China. Rather than exploiting indiscriminately, these IPs targeted GreyNoise sensors configured to emulate Citrix NetScaler appliances, suggesting deliberate targeting.
On July 9, shortly after we published the tag, CISA contacted GreyNoise to confirm exploitation activity. CVE-2025-5777 was subsequently added to the Known Exploited Vulnerabilities (KEV) catalog.
Defenders can dynamically block malicious IPs to reduce exposure and suppress alerts.
The above list will stay updated as new IPs are observed attempting to exploit CVE-2025-5777.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content initiatives that illuminate the complexities of internet noise and threat intelligence. In past roles, he led partnered research initiatives with Google and the U.S. Department of Homeland Security. With a background in finance, technology, and engagement with the United Nations on global topics, Stone brings a multidimensional perspective to cybersecurity. He is also affiliated with the Council on Foreign Relations.
GreyNoise has identified a previously untracked variant of a scraper botnet, detectable through a globally unique network fingerprint. While the botnet uses a simple and easily spoofed user-agent string — Hello-World/1.0 — its real signature lies in the behavior of the devices sending the traffic.
To detect it, GreyNoise analysts created a signature using JA4+, the suite of JA4 signatures used to fingerprint network traffic. This approach allows analysts to detect traffic based not on what it claims to be, but how it behaves — making it difficult to evade or spoof.
The signature includes:
These behavioral fingerprints form a meta-signature that is globally unique to this botnet variant.
GreyNoise has detected over 3,600 unique IPs matching this signature, geolocated around the world:
Of these IPs:
Targeted systems are predominantly located in the United States and United Kingdom.
Geographic analysis shows a clear concentration of this botnet’s infrastructure in Taiwan, with:
The dominance of Taiwanese IP space could suggest:
GreyNoise users can track this botnet variant in the Visualizer or via API. We recommend defenders:
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
This analysis was led by GreyNoise Deception Engineer Towne Besel, who developed the detection signature and conducted the underlying research.
GreyNoise has identified a notable surge in scanning activity targeting MOVEit Transfer systems, beginning on May 27, 2025. Prior to this date, scanning was minimal — typically fewer than 10 IPs observed per day. But on May 27, that number spiked to over 100 unique IPs, followed by 319 IPs on May 28.
Since that initial jump, daily scanner IP volume has remained intermittently elevated between 200 to 300 IPs per day — a significant deviation from baseline and an indicator that MOVEit Transfer is once again in the crosshairs.
These patterns often coincide with new vulnerabilities emerging two to four weeks later.
GreyNoise also observed low-volume exploitation attempts on June 12, 2025, associated with two previously disclosed MOVEit Transfer vulnerabilities:
These events occurred during the period of heightened scanning and may represent target validation or exploit testing, but at this time, no widespread exploitation has been observed by GreyNoise.
A significant portion of scanner IPs are hosted by a small number of cloud providers:
This level of infrastructure concentration — particularly within a single ASN — suggests that the scanning is deliberate and programmatically managed, rather than random or distributed probing.
Organizations should take the following steps:
1. Dynamically block malicious and suspicious IPs using GreyNoise Block:
2. Audit public exposure of any MOVEit Transfer systems.
3. Apply patches for known vulnerabilities, including CVE-2023-34362 and CVE-2023-36934.
4. Monitor real-time attacker activity against MOVEit Transfer by navigating to each respective GreyNoise tag:
We will continue to monitor the situation and provide updates as necessary.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content initiatives that illuminate the complexities of internet noise and threat intelligence. In past roles, he led partnered research initiatives with Google and the U.S. Department of Homeland Security. With a background in finance, technology, and engagement with the United Nations on global topics, Stone brings a multidimensional perspective to cybersecurity. He is also affiliated with the Council on Foreign Relations.
On June 16, GreyNoise observed exploit attempts targeting CVE-2023-28771 — a remote code execution vulnerability affecting Zyxel Internet Key Exchange (IKE) packet decoders over UDP port 500.
Exploitation attempts against CVE-2023-28771 were minimal throughout recent weeks. On June 16, GreyNoise observed a concentrated burst of exploit attempts within a short time window, with 244 unique IPs observed attempting exploitation.
The top destination countries were the U.S., U.K., Spain, Germany, and India.
Historical analysis indicates that in the two weeks preceding June 16, these IPs were not observed engaging in any other scanning or exploit behavior — only targeting CVE-2023-28771.
All 244 IP addresses are registered to Verizon Business infrastructure and geolocated to the United States. However, because CVE-2023-28771 is exploited over UDP (port 500), spoofing is possible and these IPs may not reflect the true source of the traffic.
Deeper analysis by GreyNoise identified indicators consistent with Mirai botnet variants, as confirmed by VirusTotal. Example payload, and IP metadata below:
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content initiatives that illuminate the complexities of internet noise and threat intelligence. In past roles, he led partnered research initiatives with Google and the U.S. Department of Homeland Security. With a background in finance, technology, and engagement with the United Nations on global topics, Stone brings a multidimensional perspective to cybersecurity. He is also affiliated with the Council on Foreign Relations.
GreyNoise recently observed a coordinated spike in malicious activity against Apache Tomcat Manager interfaces. On June 5, 2025, two GreyNoise tags — Tomcat Manager Brute Force Attempt and Tomcat Manager Login Attempt — registered well above baseline volumes, indicating a deliberate attempt to identify and access exposed Tomcat services at scale.
Roughly 400 unique IPs were involved in the activity observed across both tags during this period of elevated activity. Most of the activity originating from these IPs exhibited a narrow focus on Tomcat services.
A significant portion of this activity originated from infrastructure hosted by DigitalOcean (ASN 14061).
Immediately block the malicious IPs engaged in this activity with GreyNoise Block
While not tied to a specific vulnerability, this behavior highlights ongoing interest in exposed Tomcat services. Broad, opportunistic activity like this often serves as an early warning of future exploitation.
Organizations with Tomcat Manager interfaces accessible over the internet should verify that strong authentication and access restrictions are in place. Reviewing recent login activity for anomalies is also advised.
GreyNoise will continue monitoring for shifts in behavior or signs of follow-on exploitation. Subscribe to the GreyNoise Blog for updates.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content initiatives that illuminate the complexities of internet noise and threat intelligence. In past roles, he led partnered research initiatives with Google and the U.S. Department of Homeland Security. With a background in finance, technology, and engagement with the United Nations on global topics, Stone brings a multidimensional perspective to cybersecurity. He is also affiliated with the Council on Foreign Relations.
Please update your search term or select a different category and try again.
