Actionable intelligence on real-world threats as they unfold. Get insights into attacker behavior, infrastructure, exploitation of zero-days and n-days, temporal pattern, and geographic hotspots — all sourced from GreyNoise’s Global Observation Grid (GOG). Stay ahead of emerging threats, block malicious IPs, and understand what’s happening in the moment.
Subscribe to GreyNoise
Get the latest blog articles delivered right to your inbox.
GreyNoise has observed active exploitation attempts against CVE-2025-5777 (CitrixBleed 2), a memory overread vulnerability in Citrix NetScaler. Exploitation began on June 23 — nearly two weeks before a public proof-of-concept (PoC) was released on July 4.
We created a tag on July 7 to track this activity. Because GreyNoise retroactively associates pre-tag traffic with new tags, prior exploitation attempts are now visible in the GreyNoise Visualizer.
Key Observations
First observed activity: June 23, 2025
PoC released: July 4, 2025
GreyNoise tag published: July 7, 2025
CISA confirms activity with GreyNoise: July 9, 2025 (prior to KEV addition)
Early exploitation attempts came from malicious IPs geolocated in China. Rather than exploiting indiscriminately, these IPs targeted GreyNoise sensors configured to emulate Citrix NetScaler appliances, suggesting deliberate targeting.
CISA Confirmation
On July 9, shortly after we published the tag, CISA contacted GreyNoise to confirm exploitation activity. CVE-2025-5777 was subsequently added to the Known Exploited Vulnerabilities (KEV) catalog.
Recommended Actions
Defenders can dynamically block malicious IPs to reduce exposure and suppress alerts.
The above list will stay updated as new IPs are observed attempting to exploit CVE-2025-5777.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content initiatives that illuminate the complexities of internet noise and threat intelligence. In past roles, he led partnered research initiatives with Google and the U.S. Department of Homeland Security. With a background in finance, technology, and engagement with the United Nations on global topics, Stone brings a multidimensional perspective to cybersecurity. He is also affiliated with the Council on Foreign Relations.
2025-01-29 Update After identifying a significant overlap between IPs exploiting CVE-2024-40891 and those classified as Mirai, the team investigated a recent variant of Mirai and confirmed that the ability to exploit CVE-2024-40891 has been incorporated into some Mirai strains.
GreyNoise is observing active exploitation attempts targeting a zero-day critical command injection vulnerability in Zyxel CPE Series devices tracked as CVE-2024-40891. At this time, the vulnerability is not patched, nor has it been publicly disclosed. Attackers can leverage this vulnerability to execute arbitrary commands on affected devices, leading to complete system compromise, data exfiltration, or network infiltration. At publication, Censys is reporting over 1,500 vulnerable devices online.
CVE-2024-40891 is very similar to CVE-2024-40890 (observed authentication attempts, observed command injection attempts), with the main difference being that the former is telnet-based while the latter is HTTP-based. Both vulnerabilities allow unauthenticated attackers to execute arbitrary commands using service accounts (supervisor and/or zyuser).
VulnCheck disclosed CVE-2024-40891 to their partners as "Zyxel CPE Telnet Command Injection" on August 1, 2024, but as of this writing, the CVE has not yet been officially published by the vendor, nor have they published an advisory. Last week, researchers from GreyNoise collaborated with VulnCheck to verify the accuracy of the detection, ensuring that the traffic is linked to this CVE specifically. GreyNoise researchers created a tag for this issue on January 21, 2025, and worked with VulnCheck to coordinate this disclosure. Ordinarily, disclosure would be coordinated with the vendor, but due to the large number of attacks, we decided to publish this immediately.
Network Monitoring: Filter traffic for unusual telnet requests to Zyxel CPE management interfaces.
Patch Readiness: Monitor Zyxel’s security advisories for updates and apply patches or mitigations immediately, if released. Halt the use of devices that have reached end-of-life.
Mitigation: Restrict administrative interface access to trusted IPs and disable unused remote management features.
GreyNoise users can track live exploitation patterns, including attacker IP addresses, for this CVE here.
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.
Over 15,000 Fortinet FortiGate firewalls have been exposed in a breach, leaving thousands with exposed login interfaces vulnerable to exploitation. GreyNoise has identified hundreds of these devices actively being weaponized by attackers for malicious purposes, providing defenders with a real-time view into their behavior and intent.
This breach, tied to CVE-2022-40684 — an authentication bypass vulnerability disclosed in late 2022 — has created new opportunities for attackers to exploit these devices. While patches have been available since October 2022, thousands of firewalls remain exposed as of January 2025, continuing to pose a serious risk.
But this breach isn’t just about exposure — it's about the active exploitation happening right now. In this blog, GreyNoise reveals how attackers are leveraging these devices in real time and provides critical insights to help defenders respond effectively.
GreyNoise’s Real-Time Insights: What We’re Seeing
GreyNoise specializes in observing and classifying internet activity in real time. Our global observation grid tracks attacker behaviors by monitoring interactions with thousands of our sensors worldwide. Unlike sources that focus on theoretical risks or exposure, GreyNoise reveals the actual behaviors of these compromised devices as they interact with our sensors.
Of the 15,000+ affected IPs, according to Censys around 4,600 are still exposing their FortiGate web login interfaces, down from over 5,000 at the time of a Censys blog detailing the figures. The below chart illustrates the steady decline.
1. In this Case, Interaction with GreyNoise’s Sensors = Harmful Intent
Firewalls hitting GreyNoise’s sensors are behaving abnormally.
“The majority of affected IPs are classified as Unknown simply because we don’t yet have tags for their activity,” explains Bob Rudis, VP of Data Science, Security Research & Detection Engineering. “But make no mistake: by hitting our sensor network, all 366 IPs are up to no good.”
All 366 IPs are engaging in behaviors indicative of threat activity. While some are confirmed as malicious, others are flagged as Suspicious or Unknown but still require attention.
2. Behavioral Breakdown and List of Compromised IPs
GreyNoise classifies observed activity into three categories. Here’s the breakdown for the 366 Fortinet IPs:
Malicious (35 IPs): Actively scanning, probing, or delivering malicious payloads.
Suspicious (45 IPs): Abnormal or pre-malicious behavior flagged under GreyNoise’s new “Suspicious” classification, designed to provide early warnings.
Unknown (286 IPs): Activity that doesn’t match known tags but is inherently suspect, as Fortinet firewalls shouldn’t scan or probe networks. This suggests the devices are being leveraged for malicious purposes.
This activity is not new. GreyNoise has observed compromised Fortinet devices exhibiting harmful behaviors over several years, as shown below. The timeline highlights both the first and most recent sightings of these devices interacting with our sensor network.
To help defenders — particularly firewall administrators — take immediate action, we’re sharing a list of the 366 Fortinet IPs interacting with our sensor network, updated as of January 28:
Download the full list of observed IPs here. This information may change; to view a dynamic list of all IPs interacting with our network, navigate to the GreyNoise Analysis Tab:
Tags assigned to these devices reveal active reconnaissance or exploitation activity originating from compromised Fortinet systems:
SMBv1 Crawlers (82 instances): Scanning for outdated SMB protocols, often linked to WannaCry-like attacks.
SSH Connection Attempts (24 instances): Brute-force or reconnaissance targeting S
WebCrawler (23 Instances): Reconnaissance aimed at mapping networks or identifying exposed assets.
4. Geographic Distribution
These compromised devices originate from multiple regions worldwide. The top 10 hotspots are:
Brazil (45%)
Thailand (15%)
Mexico (8%)
Egypt (4%)
Malaysia (3%)
United Arab Emirates (2%)
Colombia (2%)
India (2%)
Kenya (2%)
Israel (1%)
This global spread underscores how widely Fortinet firewalls are deployed and how attackers are leveraging them for malicious purposes.
Actionable Steps for Defenders
SOC Analysts & Threat Hunters
1. Audit Your IPs and CIDRs
Cross-check your external-facing IPs against the list of 366 observed IPs to identify any suspicious or malicious activity originating from your infrastructure. Or, obtain a real-time view of compromised IPs by navigating to the GreyNoise Analysis Tab and pasting the 15,000+ affected IPs.
If you are a firewall administrator using Fortinet devices, ensure your configurations are reviewed immediately to confirm no unnecessary interfaces are exposed.
2. Monitor Your Infrastructure for Compromise
Use GreyNoise to track malicious behaviors originating from compromised devices and ensure you receive alerts for suspicious activity tied to your infrastructure.
Firewall Admins & Vulnerability Managers
1. Patch and Secure Your Devices
Ensure all Fortinet devices are updated to address CVE-2022-40684 and other known vulnerabilities. Review configurations to close any unnecessary access points.
2. Block Compromised Fortinet IPs
Use GreyNoise to swiftly and instantly block Fortinet IPs hitting our sensor network.
Take Action Now
With GreyNoise, organizations can monitor their external-facing IPs, reduce noise in their threat landscape, and focus their defenses on the most immediate and significant risks. In the case of Fortinet firewalls, if it’s hitting GreyNoise sensors, it’s already up to no good.
Take control of your external threat landscape today. Use GreyNoise to monitor malicious activity, track behaviors in real time, and protect your organization. Add your IPs or CIDRs to GreyNoise’s alerts now.
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.
Attackers are increasingly capitalizing on newly disclosed vulnerabilities within hours of proof-of-concept (PoC) code becoming public. This shrinking timeline leaves defenders with little time to react. A recent example is the rapid response to two Mitel MiCollab vulnerabilities — CVE-2024-41713 (authentication bypass) and CVE-2024-35286 (SQL injection). On December 5, GreyNoise was ready. The same day the PoC went public, GreyNoise began observing attacker activity, demonstrating the speed at which threat actors exploit new information.
Timeline: From Disclosure to Observed Activity
May 2024: CVE-2024-35286, the SQL injection vulnerability, is patched by Mitel.
October 2024: CVE-2024-41713, an authentication bypass vulnerability, is disclosed. No PoC or large-scale visible activity is observed at this time.
December 5, 2024: PoC code is publicly released for CVE-2024-41713, chaining it with another vulnerability. GreyNoise immediately deploys detection tags for both CVEs and begins observing attacker activity, including reconnaissance or exploitation, within hours.
Seeing the Activity: Data from GreyNoise
The following screenshots from GreyNoise’s Visualizer show unique IP addresses associated with attacker activity following the PoC release. These spikes coincide with the deployment of detection tags, providing a clear picture of how quickly attackers respond to new exploit information.
Leveraging our IP blocklists, GreyNoise customers can immediately block IPs targeting these vulnerabilities.
The chart below shows unique IP addresses probing for CVE-2024-41713 on December 5, immediately after the PoC release. This activity demonstrates attacker interest, highlighting how quickly attackers act on new exploit opportunities. For defenders, this means prioritizing visibility and mitigation immediately after public disclosures.
While the SQL injection vulnerability showed limited activity, it’s important to monitor for potential escalation. Even low activity levels can indicate attackers testing the waters, making proactive mitigation essential.
Addressing the Threat: Patches Are Available
Both vulnerabilities have been addressed by Mitel:
CVE-2024-35286: Mitel released a patch in May 2024. Organizations should apply this fix immediately to mitigate risk.
CVE-2024-41713: Mitel resolved this issue in MiCollab version 9.6, released in October 2024. Upgrading to this version or later is essential.
By applying these patches, organizations can reduce their exposure to attacker activity.
The Value of Real-Time Intelligence
The divergence between predicted exploit likelihood and real-world attacker behavior highlights the necessity for real-time threat intelligence. Predictive models like EPSS currently list both CVEs at 0% likelihood of exploitation, yet GreyNoise’s data provides concrete evidence of attacker activity. This underscores a critical reality: attackers act on opportunities as soon as they arise, often outpacing static predictions.
With GreyNoise, defenders can:
Gain Immediate Visibility: Real-time data shows attacker activity targeting vulnerabilities as it happens.
Prioritize Effectively: Knowing where attackers are focusing their efforts helps defenders allocate resources wisely.
Preempt Escalation: Use GreyNoise blocklists and intelligence feeds to disrupt attacker workflows before reconnaissance escalates into exploitation.
Recommendations for Defenders
Organizations leveraging Mitel MiCollab should act quickly:
Apply Available Patches: Ensure that fixes for both CVEs are implemented without delay.
Leverage Real-Time Monitoring: Use platforms like GreyNoise to stay informed about attacker activity targeting your infrastructure.
Adopt Layered Defenses: Implement network segmentation, access controls, and continuous monitoring to reduce exposure and contain potential breaches.
Proactively Block Malicious IPs: Leverage real-time intelligence to identify threat actor IPs and dynamically block them.
Staying Ahead of the Curve
The Mitel MiCollab vulnerabilities demonstrate the importance of rapid response in cybersecurity. While defenders cannot always predict when attackers will act, real-time visibility ensures they can respond effectively to reconnaissance or exploitation efforts as they emerge. GreyNoise’s ability to deploy detection tags on the same day as the PoC release exemplifies its commitment to staying ahead of attackers. This readiness is crucial in a world where the window between disclosure and active attacker activity continues to shrink. By detecting reconnaissance or exploitation efforts within hours, GreyNoise gives defenders the critical lead time needed to respond effectively.
The insights in this blog were made possible by GreyNoise’s Global Observation Grid, a network of internet-facing, primary sensors that passively observe and analyze global attack traffic. GreyNoise recently announced significant enhancements to its sensor and data pipeline technology that deliver deeper insights and broader coverage into cyber threats, equipping security teams with actionable intelligence to better detect, prioritize, and respond to emerging and resurgent threats.
Stay ahead of emerging threats with GreyNoise’s real-time intelligence. Contact us today to learn how we can help protect your organization from evolving vulnerabilities.
Discover the latest findings from GreyNoise Labs as we delve into a perma-vuln plaguing the D-Link DIR-859 router. In our newest blog post, "Perma-Vuln: D-Link DIR-859, CVE-2024-0769," we uncover the intricacies of CVE-2024-0769, a path traversal vulnerability affecting D-Link DIR-859 WiFi routers, leading to information disclosure.
The exploit's variations, including one observed in the wild by GreyNoise, enable the extraction of account details from the device. The product is End-of-Life, so it won't be patched, posing long-term exploitation risks. Multiple XML files can be invoked using the vulnerability.
Click here to see the details and interesting payload that Sift has identified.
On June 5, 2024, SolarWinds published an advisory detailing CVE-2024-28995 - a path-traversal vulnerability in Serv-U, discovered by Hussein Daher. Our Labs team - with our brand new deception engineer - seized this opportunity to deploy a new honeypot they've been working on. It's supposed to look more real - and vulnerable! - than past honeypots.
What did they discover?
They show off all kinds of information gleaned from their honeypot - who's attacking it, what files they're trying to steal, how often they come back, and more.
But, that's not all!
They actually managed to capture a live attacker making several copy/paste mistakes, and attempting to correct the exploit only to foul it up again! They track the attacker's progress over the course of 4 hours, including one instance where they sent the completely wrong exploit (which happens to be for an unpatched vulnerability!).
Check out the full blog on GreyNoise Labs to learn more about this vulnerability and our observations.
Check out the latest from GreyNoise Labs as we examine the technical details of CVE-2024-4577, a serious remote code execution vulnerability in PHP affecting Windows deployments. Discovered by DEVCORE and demonstrated by watchTowr, this vulnerability exploits a 'best-fit' Unicode processing behavior in Windows. This allows attackers to inject command-line arguments via HTTP requests.
Detailed examples of payloads observed in the wild to achieve remote code execution are included, showcasing how attackers exploit the vulnerability in the real world. These payloads range from simple PHP code snippets to more complex scripts that download and execute malicious binaries.
Check out the detailed post here for a deeper dive into the technical details and the full range of payloads.
On May 28, 2024, Check Point published an advisory (and emailed customers) regarding CVE-2024-24919, a CVSS 8.6 vulnerability that they described using fairly vague language: "exploiting this vulnerability can result in accessing sensitive information on the Security Gateway. This, in certain scenarios, can potentially lead the attacker to move laterally and gain domain admin privileges."
Although they buried the lede a bit, if you scroll way down and click through a bit, you'll see that attacks in the wild occurred as far back as April 7, 2024 (nearly 2 months)! Two days after the advisory came out (May 30, 2024), we published a tag, which currently shows rapidly increasing exploitation:
Although you can’t see it on the graph, the very first attempts we saw were on May 31, 2024 at around 9:30am UTC. We also observed some attempted exploits on May 30, 2024, but they don’t show up in our public data because they don’t actually work (more on that below).
On May 31, 2024, our friends at Censys published their write-up, which indicated that there are nearly 14,000 devices running some version of that software, although it’s not clear how many of those have exposed management ports.
The vulnerability
The core vulnerability is a pretty straight-forward path traversal issue. One of the folks on my team reverse engineered the patch concurrently with watchTowr and came up with basically the same exploit (this one is from watchTowr):
POST /clients/MyCRL HTTP/1.1
Host: <redacted>
Content-Length: 39
aCSHELL/../../../../../../../etc/shadow
Since the server runs as root, an attacker can grab any file on the filesystem! We’ll show you what attackers are actually searching for below.
Our observations
Sift
Although we tagged this issue very quickly, we actually saw the first exploit attempt (attempt), with a non-working exploit, hitting Sift on May 30, 2024 - presumably somebody thought they’d figured it out and pushed the big “go” button a bit too quickly:
We started seeing actual exploitation attempts logged in Sift on May 31, 2024:
POST /clients/MyCRL HTTP/1.1
Host: <ip>
Connection: close
Accept-Encoding: gzip
Connection: close
Content-Length: 39
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
aCSHELL/../../../../../../../etc/shadow
I’m always impressed when an automated system can catch a novel exploit without being told about it!
Honeypot data
We manually searched our honeypot data going back 90 days prior to today (June 4, 2024), and the oldest exploit attempts that we see started on May 30, 2024, at about 5pm UTC:
POST /clients/MyCRL HTTP/1.1
Host: <IP_ADDRESS>
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 38
/clients/MyCRL/../../../..//etc/passwd
The word “attempts” is doing a lot of work in that sentence because, from what we can tell, this payload doesn’t actually work - perhaps somebody pressed the big red button before actually testing their exploit?
In any case, the IP address using that broken payload was 125.229.221.55, a Taiwan-based address that started scanning for HNAP-enabled devices on May 30, 2024, then a few hours later (on the same day) started scanning for CVE-2024-24919. We can’t say with certainty whether the HNAP scan is related, but it’s the only other traffic we’ve ever seen from that IP address. In the exploits, the IP attempted to fetch /etc/passwd and /etc/shadow.
The first real exploitation we observed began on the morning of May 31, around 9:40am UTC, when a New York-based IP address, 45.88.91.78, took a break from searching for CISCO ASA appliances and started launching exploits for this issue with a payload that would appear to actually work (and, in fact, is suspiciously identical to watchTowr’s PoC, including the number of ../s):
POST /clients/MyCRL HTTP/1.1
Host: <IP_ADDRESS>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:82.0) Gecko/20100101 Firefox/82.0
Connection: close
Content-Length: 39
Accept-Encoding: gzip
aCSHELL/../../../../../../../etc/shadow
Around that same time, a chorus of different scanners emerged that used a bunch of different paths. Due to the nature of the vulnerability, it’s very hard to determine the actual intent of the attacker - all we know is which file they’re trying to fetch. Whether they’re using that to steal passwords or to test the vulnerability is hard to know.
That being said, as of June 4, 2024, here is the top-10 list of plausibly-working payloads that we’ve observed, with the counts:
As you can see, /etc/fstab remains a popular target - probably it’s a reliable path being used by some off-the-shelf scanner(s).
/etc/shadow of course remains popular, but we’re suddenly seeing a lot of attempts to pull
/sysimg/CPwrapper/SU/Products.conf and /config/db/initial that we weren’t seeing yesterday. That demonstrates how the attack is evolving day over day!
Unfortunately, we didn’t directly observe the 0-day exploitation prior to the advisory being released; presumably, the attacks were targeted and didn’t hit our sensor network (although as we expand our new sensors and personas to real networks, we expect to start seeing this type of 0-day exploitation in Sift!)
Conclusion
With a public proof of concept out, and exploitation quickly ramping up, we recommend patching Check Point as soon as possible!
Yesterday, GreyNoise reached a fun and significant milestone after publishing our 1,337th tag. 1337 is a cherished number in hacker culture, as it is a numerical shorthand for "leet", which itself stands for "elite". This term has deep roots, going all the way back to the 80's when one had to make modems scream to access bulletin board systems (now, we humans are the ones screaming whenever we go online to see what fresh hades awaits us each day).
What makes this milestone even more significant is how it was achieved.
The chart, below, shows the cumulative sum of tag counts by year. While there was a modest improvement in intra-year tag creation from 2022 to 2023, we're just into the first few weeks of Q2 in 2024 and are almost at the total tag count for 2023.
We will almost certainly blow past 2023's tag count well-before the end of Q2, and this has all been made possible by our focused and practical use of AI. This system helps our incredible detection engineers quickly triage the millions of events our sensor fleet absorbs every day. With it, they discover and tag novel payloads to help inform and protect our customers, community, and the internet as a whole. The application that fuels this work is called Sift, and we've waxed poetic about it quite a bit over the past few months.
This boost to the tag inventory has also meant an increase in CVE coverage.
(Since it most likely drew your attention, the jumps in 2022 were due numerous factors, including the increase in Russian hostilities towards Ukraine.)
60% of 2024 tags are based on CVEs, and — along with plenty of "modern" vulnerabilities — Sift has helped us catch exploitation attempts of some very old CVEs, too:
I'm incredibly proud of our team of data scientists, security researchers, and detection engineers. Their leet expertise powers the detections that folks rely on every day, and we hope you'll join in our celebration of achieving this epic milestone!
To learn more about GreyNoise tags and how they differ from "traditional" detections, check out our Tags Webinar Series.
On April 12th, 2024, Palo Alto Networks announced CVE-2024-3400. CVE-2024-3400 is a CVSS 10 critical arbitrary file-write vulnerability in Palo Alto Networks PAN-OS software versions 10.2, 11.0, and 11.1. This vulnerability enables unauthenticated attackers to execute arbitrary Linux commands with root-level privileges on affected firewalls if firewalls are configured with a GlobalProtect gateway or portal (or both) and device telemetry enabled.
Palo Alto and Unit 42 have confirmed that threat actors have exploited CVE-2024-3400 in a limited number of attacks in the wild. CISA published guidance and added it to the Known Exploited Vulnerability (KEV) on Friday, April 12, 2024.
Palo Alto Networks released workaround guidance and some hotfixes on April 14, 2024. Customers can also mitigate the vulnerability by enabling Threat ID 95187 if they have a Threat Prevention subscription, or by temporarily disabling device telemetry until the device is upgraded to a fixed PAN-OS version.
GreyNoise is tracking opportunistic exploitation attempts here. As of April 15, 2024, 17:00 UTC, no attempts have been observed by our fleet.
Of note: our sensor fleet has detected instances of nonworking exploits that have been circulated online, claiming to be for CVE-2024-3400. This indicates that opportunistic exploitation will quickly follow once a successful exploit code is released.
(04/11/2024): Clarification on CVE-2024-3273 & CVE-2024-3272
Exploitation of the CVE-2024-3273 command injection vulnerability requires the two valid `user=` and `passwd=` parameters. There is a companion vulnerability tracked as CVE-2024-3272 and describes the issue as "manipulation of the argument user with the input messagebus leads to hard-coded credentials". It is important to note that the "credentials" as described are only the username for the user "messagebus".
"messagebus" is not a backdoor account. It is one of many common pre-configured linux system users that functionally cannot "log in", and thus have no password. Other common example system users include avahi, syslog, nobody, ntp, rtkit, and whoopsie. D-Link correctly validates that the username exists and also correctly validates that the provided password is correct. The logic flaw exercised by CVE-2024-3273 is that the empty (correct) password for the "messagebus" user is never validated that the user should ever be able to log in using a password, if at all.
(04/09/2024): Update on number of vulnerable devices
Upon further analysis, it appears the number of vulnerable devices is much lower than initially reported. According to our friends at Censys, the number is closer to 5,500 devices.
GreyNoise quickly released a tag for tracking under D-Link NAS CVE-2024-3273 RCE Attempt, which was relatively easy for us because our Sift tooling surfaced the exploit to us automatically. Sift curates a report of new/interesting traffic observed by GreyNoise sensors daily after doing much of the analysis and triage work itself.
Sift’s analysis above is correct! Taking it a step further, the command the above IP is attempting to execute is a generic shell script pattern used by botnet operators to try to execute malware for every possible CPU architecture in the expectation that at least one will work. The malware is fetched from 38[.]6[.]224[.]248 over HTTP.
We have retrieved the sample skid.x86 and uploaded it to VirusTotal for sharing and further analysis:
Ever wonder what happens to vulnerabilities after they're forgotten?
In a new blog from the GreyNoise Labs team, we look at CVE-2023-22527, an Atlassian Confluence vulnerability that was all over the news back in January/2024, then forgotten a week later. But even though the media has forgotten, attackers haven't!
The Labs team digs a little into who the attacker is and their techniques - killing other malware, deleting log files, and even using SSH keys to infect other hosts.
If you're interested in how attackers use old vulnerabilities and what they do once they're on a host, check it out!
In October 2023 — as part of the Ransomware Vulnerability Warning Pilot (RVWP) — CISA began tagging entries in their Known Exploited Vulnerabilities (KEV) catalog. This field designates whether exploits for a given vulnerability are known to be used in ransomware attacks. Ransomware has disrupted critical services, businesses, and communities worldwide, and many organizations are working diligently to get ahead of these attacks to prevent losses, disruptions, and exposures.
We’ve talked about this topic before, but today we dig a bit deeper into the topic with some specific guidance as to how your organization can fight the good fight against these foes by leveraging the power of GreyNoise tags.
GreyNoise Tags vs. Ransomware
As scores of organizations who use them know, GreyNoise tags are a signature-based detection method that categorizes internet noise into actionable intelligence. As of this writing, we’ve observed recent activity in 63 tags that CISA has identified as being used in association with ransomware attacks. The figure at the beginning of this post shows the frequency and volume of this opportunistic activity. One striking feature of this activity is the diversity of targeted platforms.
In the case of internet-facing attack campaigns, one might assume that vulnerabilities targeted by ransomware actors would lean towards remote access technologies. The chart and our data that backs it up shows that almost no technology category is safe from these types of attacks. Collaboration tools, such as Atlassian Confluence or JetBrains TeamCity; email platforms, such as Microsoft Exchange; software that powers application middleware services, such as Jboss and WebLogic; or, even devices that are intended to help elevate safety and resilience, such as SonicWall, Ivanti, Citrix, and Fortinet are all regularly targeted.
If you use any of these technologies, knowing when new activity is seen can be helpful in shoring up defenses and readying response activities. By leveraging GreyNoise platform features, such as our Alerts and block lists, security teams can, respectively, determine if more focus should be placed on monitoring key systems and preventing opportunistic harm. With the noise weeded out, response teams can focus their attention on similar activity that is likely to be more targeted, which may also mean by more capable adversaries. And, because we play incredibly well with a host of other security tools, teams can also save time, and use our intelligence within familiar environments.
The Long, Sporadic Tail Of Ransomware Tag Activity
Another striking feature of our ransomware tag activity chart is the diversity of activity. Cloud deployments top the list, with attackers looking to take advantage of misconfigurations that may arise in these highly dynamic environments. Broad and commonly deployed technologies are also regular targets, since these systems can also become victims of errant misconfigurations, especially when restored from unpatched backups.
However, as we move down the list, the frequency becomes far more sporadic, and many involve only single hosts vs. botnet armies. This can be due to attacker familiarity, or individual actors keying off results from well-timed Censys or Shodan searches that show newly exposed vulnerable configurations. If your organization uses any of these components, there truly is no rest from vigilance.
The Ransomware GNQL Listicle
To help defenders get a leg up on these attacks, the list below has links to each individual tag that’s known to be used in ransomware attacks. At each tag page, you can find the block list URL which you can use to immediately weed out the opportunistic noise. Wrap one or more of them inside a GNQL query, such as tags:"F5 BIG-IP iControl RCE Attempt", and you can set up an alert to notify you when new activity is seen, especially in generally dormant tags.
If you're curious as to just how GreyNoise researchers craft our tags we have a three-part webinar series that discusses the makeup of our tags, walks you through how we discover what needs to be tagged, and illustrates how AI is empowering the creation of new tags and detections:
Not a GreyNoise customer — yet? See how much time GreyNoise may be able to save your organization, and how many hours your defenders can save with our ROI calculator.
Sign up and take our platform for a free enterprise trial to see all the features and data available.
SnakeYAML has slithered its way into a deserialization vulnerability, with versions before 2.0 allowing remote code execution when used to parse untrusted input. In this GreyNoise Labs post, Lead Security Researcher Ron Bowes digs into the technical details, drama, and exploits around CVE-2022-1471.
By default, SnakeYAML allows the instantiation of arbitrary Java classes from untrusted YAML sources. This "insecure by default" design has led to at least eight different vulnerabilities prior to its official designation as a CVE. We'll highlight the unhelpful responses from developers and the importance of secure defaults.
Additionally, we'll demonstrate how to build a vulnerable app and understand how the deserialization actually works, developing an exploit to demonstrate how to achieve remote code execution.
Diverse Set of IPs Exploiting Atlassian Vulnerabilities, Not Just a Few Bad Actors.
At GreyNoise, we focus heavily on analyzing data trends and anomalies, as they form a fundamental part of our business. While we collect a vast amount of data regarding unsolicited packets being transmitted across the internet, it is only meaningful if we look at the bigger picture.
We have recently introduced some changes to our back-end system for calculating the trending and anomalous events we update hourly here. This has already proven beneficial, as it helped us detect a sudden increase in malicious Atlassian exploitation attempts late last week (gee, I wonder why…).
Atlassian-related topics occupy seven out of the top ten trending tag anomalies at the time of this writing.
We conducted an analysis on the various spikes and attempted to determine if they were all caused by the same few IPs searching for all possible vulnerabilities. However, our findings suggest a fair distribution of IPs trying to exploit different vulnerabilities. After examining data from the past 24 hours, we found that the highest number of overlapping IPs across all the tags mentioned above was only 9, with 67% of the total IPs seen only once.
As the year ends, ensure your Atlassian products are secure by removing them from the public internet and keeping them up to date. If they’re still unpatched, it likely is too late to avoid compromise. For extra measure, use our dynamic IP blocking feature to protect your organization from opportunistic mass exploitation.
Over at the GreyNoise Labs Grimoire, Ron Bowes has a new, deep-dive post out on the creation of a simple clone of the F5 BIG-IP management port to attract traffic and analyze it. Ron deployed the honeypot for a couple of weeks and then analyzed the traffic using tshark.
Some interesting findings include:
Brute-force attacks on the login page with basic credentials like “user123” and “password123”.
Attempts to exploit CVE-2021-22986, an SSRF issue in the authentication parser.
Traffic targeting the “/mgmt/tm/util/bash” endpoint, which is typically targeted for auth-bypass issues like CVE-2022-1388.
Two instances of exploitation attempts targeting the “/mgmt/shared/iapp/rpm-spec-creator endpoint”, which is related to CVE-2022-41800, an authenticated remote code execution vulnerability.
Ron does note that the majority of the traffic is not related to a rumored 0-day exploit, and that the honeypot helped provide insights into various attack attempts and vulnerabilities.
Pour out your fav caffeinated beverage and sink into Ron's insightful post!
CVE-2022-28958 was initially reported as a remote code execution (RCE) vulnerability in the D-Link DIR816L_FW206b01 firmware via the value parameter at shareport.php. This vulnerability, if real, would have posed a significant security risk, allowing unauthorized remote users to execute arbitrary code on the affected device.
However, further investigation into CVE-2022-28958 revealed that the vulnerability did not actually exist. Tests conducted on various firmware versions, including the reportedly vulnerable version 2.06b1, found no evidence of the vulnerability. Moreover, the original researcher who reported the vulnerability did not provide supporting evidence.
The CVE has been marked as REJECTED by the CVE List, retracted by the Certified Naming Authority that originally vetted and published the CVE, and CISA has removed the vulnerability from their catalog of known exploited vulnerabilities.
In response to these findings, GreyNoise researchers made the call to pull their D-Link DIR-816 tag for CVE-2022-28958. This action aligns with GreyNoise's commitment to providing the cybersecurity community with accurate and reliable threat intelligence.
The case of CVE-2022-28958 serves as a reminder of the importance of thorough and rigorous vulnerability verification. Incorrectly reported vulnerabilities can lead to unnecessary alarm and resource allocation in the cybersecurity community. They can also undermine trust in the reporting and cataloging systems that are crucial for effective vulnerability management.
In this context, the work of organizations like GreyNoise Intelligence and CISA is invaluable. By investigating reported vulnerabilities and making informed decisions based on their findings, they help ensure that the cybersecurity community can focus its efforts on real and present threats.
Have you heard of CVE-2023-49105? While the 10/10 CVE-2023-49103 got all the attention last week, organizations should not quickly overlook CVE-2023-49105!
–
Last week, GreyNoise published a high-level and deep-dive blog into a seemingly simple (but actually complex) vulnerability in ownCloud (CVE-2023-49103) that permitted users to enumerate environmental variables. Since it was listed as CVSS 10/10, everybody jumped on it.
Once we understood the 10/10 vulnerability, CVE-2023-49103, we shifted focus to the 9.8/10 vulnerability, CVE-2023-49105, a WebDAV Api Authentication Bypass in ownCloud.
What we found is that CVE-2023-49105 is arguably a more severe vulnerability. Ron Bowes, Lead Security Researcher, quickly developed a PoC for this vulnerability (another deep-dive here!) and verified the findings published by Abionics Security’s write-up demonstrating how this vulnerability can enable remote code execution.
CVE-2023-49105 is an authentication bypass issue affecting ownCloud from version 10.6.0 to version 10.13.0. It allows an attacker to access, modify, or delete any file without authentication if the username is known. Even if the user has no signing key configured, ownCloud accepts pre-signed URLs, enabling the attacker to generate URLs for arbitrary file operations.
Successfully exploiting CVE-2023-49105 can lead to serious impacts like data theft, ransomware deployment, and remote code execution. While it may have received less initial attention than the CVSS 10 issue, organizations using affected ownCloud versions should treat patching this vulnerability as a critical priority. Unlike the CVSS 10 issue, this affects *all* installations, not just Docker-based ones.
Upgrading to ownCloud 10.13.3 or later is reported to resolve CVE-2023-49105.
Ron Bowes of the GreyNoise Labs team has made some updates to the deep dive into this critical vulnerability in ownCloud’s Graph API.
2023-11-29 UPDATE
Ron Bowes of the GreyNoise Labs team has put together a deep dive into this critical vulnerability in ownCloud’s Graph API. Ron discusses the exploit, its impact on Docker installations, and our comprehensive testing process, here at GreyNoise.
2023-11-27 ORIGINAL POST
On November 21, 2023, ownCloud publicly disclosed a critical vulnerability with a CVSS severity rating of 10 out of 10. This vulnerability, tracked as CVE-2023-49103, affects the "graphapi" app used in ownCloud.
ownCloud is a file server and collaboration platform that enables secure storage, sharing, and synchronization of commonly sensitive files.
The vulnerability allows attackers to access admin passwords, mail server credentials, and license keys.
GreyNoise has observed mass exploitation of this vulnerability in the wild as early as November 25, 2023.
The vulnerability arises from a flaw in the "graphapi" app, present in ownCloud versions 0.2.0 to 0.3.0. This app utilizes a third-party library that will reveal sensitive PHP environment configurations, including passwords and keys. Disabling the app does not entirely resolve the issue, and even non-containerized ownCloud instances are at risk. Docker containers before February 2023 are not affected.
Mitigation information listed in the vendor's disclosure includes manual efforts such as deleting a directory and changing any secrets that may have been accessed.
In addition to CVE-2023-49103, ownCloud has also disclosed other critical vulnerabilities, including an authentication bypass flaw (CVE-2023-49105) and a critical flaw related to the oauth2 app (CVE-2023-49104).
Organizations using ownCloud should address these vulnerabilities immediately.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
