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.
AI is so hot right now, and the cybersecurity space is no exception. Technology leaders are unveiling exciting new capabilities, vendors are making extravagant claims, and practitioners are working hard to understand how to separate the wheat from the chaff, leveraging AI where it can make the most difference to their operations’ and their organization’s risk.
Here at GreyNoise, we’ve been investigating where AI capabilities can have the biggest impact, and then working to deploy them internally, externally, and in partnership with other security vendors. In this blog we’ll discuss several GreyNoise AI projects and how they’re helping defenders identify and understand threats and secure their environment.
Traditional automation is rule-based and rigid. “IF a packet matches this malware signature, THEN block it AND generate an alert”, etc. AI-based approaches are different. AI makes it possible to automate pattern recognition—and its inverse, anomaly discovery. With AI, defenders can rapidly process high volumes of data, and automatically identify the most suspicious observations for high-priority analysis and triage.
Sift is GreyNoise’s tool for solving this problem. It leverages multiple advanced AI techniques, including:
Sift runs daily, helping our research team process the data generated by our global sensor fleet to identify novel behavior, traffic, and attacks.
For more on Sift and how it works, check out our technical launch blog here.
But Sift doesn’t stop there. The same techniques can be applied to the data generated by targeted subsets of our sensors, helping specific organizations generate intelligence insights and reports tailored to observations from their own networks. This AI application will bring the industry-leading research capabilities of GreyNoise into any organization’s internal security processes, reducing triage overhead, accelerating attack identification, and making life easier for defenders—and harder for attackers.
For more on how to bring the insights of Sift into your own organization, talk to our team.
The capabilities of AI aren’t limited to stochastic data analysis. Recent advances in transformer architectures and LLMs have cracked the natural language barrier, making it possible to generate well-formulated utterances at scale. This has opened up a new frontier of AI assistants. Microsoft Copilot for Security is leading the charge to bring these capabilities into the cybersecurity space, and GreyNoise is working together with Microsoft on this initiative. We’re a partner in the Microsoft Copilot for Security Partner Private Preview, and our plug-in means that both free and enterprise users can access GreyNoise insights from within their Copilot interface with natural language prompts.
For more on how GreyNoise and Microsoft Copilot for Security work together, check out our dedicated integration page.
The future of AI is hard to predict, and the evolution of the field has famously surprised both boosters and skeptics. Organizations looking to leverage these rapidly transforming capabilities will need to roll with the punches—and continue to partner with security vendors who can do the same. Here at GreyNoise we’re committed to doing just that. We’re excited to share how AI is already empowering our security—and we can’t wait to see what’s next.
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.
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.
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 and check it out for yourself at https://sift.labs.greynoise.io/
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:
In the InfoSec community, sharing knowledge and expertise is key to moving the industry forward and crucial to creating the next generation of security professionals. As part of our commitment to building and investing in the community, we’re excited to announce our new online conference series: NetNoiseCon.
NetNoiseCon is a livestream conference viewable on the GreyNoise YouTube channel on April 19th, starting at 12pm ET / 9am PT.
The conference will feature both technical and career-advice focused talks, with speakers from across the InfoSec industry and the GreyNoise researcher community. We’ve curated a set of talks with the goal in mind that all viewers should come away with new skills or insights that they can use in their work ASAP.
Click the “Notify Me” button to receive a notification when we go live or sign-up for a reminder here. Join us on the livestream for the event and hang out in our community Discord server to join our post-event voice chat / StarCraft sessions 👾.
We hope to see you there!!
- Sam Houston, Senior Community Manager, GreyNoise
.png)
Welcome to our Monthly Roundup, where we curate a unique mix of articles, books, podcasts, and more that have captured the attention of the GreyNoise team. From deeply technical articles to literary treasures, join us on this eclectic journey through the media that sparks our curiosity each month. Explore + discover as we share the gems that have fueled our inspiration!
Travel Light | Naomi Mitchinson (from Rich Horton's recommendation)
🐲 Thoughts: It's a Norse-inspired fairytale incongruously grounded in the very real history of the Byzantine Empire and Eastern Europe; beautifully humane and strikingly alien. It also might be the lost ancestor of all the princess-and-dragon subversions that are so (thankfully!) common these days.
👻 Camp Damascus | Chuck Tingle
Why I like it: It's a real page turner of a horror novel about quite literally facing your demons. Highly recommend it if you like horror, if you are socially awkward and want a relatable protagonist or if you like books about queer people taking down a conversion therapy camp.
🕰️ Four Thousand Weeks: Time Management for Mortals | Oliver Burkeman
Thoughts: Great book that I think I'll keep coming back to; this is my second time, as I always seem to find something new. It's a nice, albeit brutal, reminder that life is short and time cannot be "managed" the way other productivity books would make it seem. You will always have to make sacrifices; just make sure you pay attention to what you're sacrificing.
🦥 Slow Productivity: The Lost Art of Accomplishment Without Burnout | Cal Newport
Why I liked it: In a similar vein, I read Slow Productivity, Not my favorite by Cal Newport, but it was still a good read. Probably not a lot in here that you haven't heard before but probably don't think about regularly. Still, there was some great insight, especially in regard to the difference between "obsessing over quality" and "perfectionism." Definitely recommend it for the the productivity nerds.
💰 The Challenger Sale: Taking Control of the Customer Conversation | Matthew Dixon + Brent Adamson
Why I like it: A recommendation by a co-worker, Mike Baker, exploring the results of a study done by CEB on behaviors and attitudes that drive performance in complex sales in-spite-of market fluctuations. The authors were surprised that they did not arrive at their hypothesis, so it makes a highly interesting read backed by research data.
⛽ Fossil Capital: The Rise of Steam Power and the Roots of Global Warming | Andreas Malm
Thoughts: This one is taking some time, clocking in at a thick 400 pages, but Andreas Malm did an impressive amount of cited research constructing a narrative that challenges the traditional thinking that energy production was driven by market forces, arguing instead their hypothesis that it was not economic incentive, but centralized control of labor and means of production. Malm offers a deep dive into the political and social ramifications of disrupting the status quo of fossil fuel-driven infrastructure.
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!
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.
If you’re just looking for the tag, you can track Fortinet's CVE-2024-21762 here:
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:
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:
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:
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
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.
Welcome to our Monthly Roundup, where we curate a unique mix of articles, books, podcasts, and more that have captured the attention of the GreyNoise team. From deeply technical articles to literary treasures, join us on this eclectic journey through the media that sparks our curiosity each month. Explore + discover as we share the gems that have fueled our inspiration!
⚡ Book Series: CyberStorm | Matthew Mather
TLDR: The premise is to demonstrate the catastrophic consequences of cyber warfare in a modern-day, fictional setting. The series starts with "CyberStorm," and is centered around a blizzard that's compounded by a cyber attack. Mather uses it to explore the fragility of urban life when faced with the breakdown of logistical systems and the ensuing chaos that disrupts the fabric of civilization.
In "CyberSpace," the story picks up six years after the events of "CyberStorm," with the original protagonist reuniting with old friends amidst rising international tensions and a new wave of satellite destruction that cripples global communication. "CyberWar" concludes the series with a depiction of the world's militaries struggling to cope with the aftermath of a Chechen separatist attack that has decimated thousands of satellites, leading to widespread power and communication failures. It does require some suspension of disbelief, but it's not "farcical" and would likely be a good read for cyber folk. The narration in the audiobooks is 👍
🤬 Book: Plunder: Private Equity's Plan to Pillage America | Brendan Ballou
Thoughts: If you ever wonder why everything's fucked in Housing, Healthcare, Retail, Prisons, Income Inequity- this book will shine a light on the people screwing up America and how the government made it easy for them. They gobbled up your houses and affordable/quality healthcare, and now they're trying to get their grimy paws on your 401K (I'm feeling...angry but informed). [ Editor was told not to remove profanity, that’s how worked up this book has gotten her]
🚂 Book: Staff Engineer: Leadership Beyond the Management Track | Will Larson
Thoughts: I Love Will Larson's insight. He has given so much insight into how effective Engineering organizations should run. Staff Engineer focuses on the technical leadership career track.
📚 Book: Management of Organizational Behavior Leading Human Resources | Paul Hersey
Why I like it: If you ever thought that "good management" is just a "gift" or something people just get. This "textbook" (Yes, I read textbooks for fun 🤓) breaks down mgmt into system-level constructs. One of the best books I have read in a long time.
🎵 Book: The Women in Me | Britney Spears
Why I like it: I've always felt like there was more to her story than what I saw on the news, and it turns out that was true in ways that make me want to drop kick half the music industry into the sun.
💥 Podcast: Smashing Security | Graham Cluley + Carole Theriault
Why I like it: I make it a point to listen to Smashing Security. It's equal parts useful security news and funny quips.
🕵️ Book: Extreme Privacy: What It Takes to Disappear + Book: OSINT Techniques: Resources for Uncovering Online Information | Michael Bazzell
Why I like it: I am reading both of these books at the same time, I like to play both sides, so I always end up on top. These books are great if you want to feel just a little bit paranoid
🥸 Book: The Imposter's Handbook | Rob Conery
Why I like it: As a college dropout and "self-taught" dev, I've always felt like a bit of an outsider when folks start talking about computer science topics. This has been filling in those gaps in a really approachable way that I feel will make me a better engineer in the end.
🕶️ Podcast: Darknet Diaries | Jack Rhysider
Why I like it: Continuously binging this podcast, which probably doesn't need an explanation to anyone who's going to be reading this lol.
💰 Podcast: BG2 Pod // Ep2 | Bill Gurley + Brad Gerstner
Why I like it: If you're interested in the tech market and enjoy financial analysis from insiders, check out this new podcast from VC investors Bill Gurley & Brad Gerstner. I'll shoutout the episode with Box's CEO/cofounder Aaron Levie as especially interesting and entertaining.
🔬 Book: Homo Deus: A History of Tomorrow | Yuval Noah Harari
Thoughts: My former genetic engineering self revels in Sapiens’ ending on essentially the intro of RNAi and CRISPR into the realm of medicine, Homo Deus is more on the “what’s going to happen next” for humans with the continued advancement of technology (not just medicine).
(Bonus Article: in case anyone wants to nerd out on those RNAi days of mine when my friends referred to me as the “Lord of the Flies.”)
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!
I started GreyNoise in 2018 by myself in an apartment in Arlington, Virginia to bring visibility into what scanners and attackers were up to on the Internet. My theory at the time was that the edge telemetry from a single internet-exposed device or sensor was not useful or interesting, but the edge telemetry of a large, diverse set of internet-exposed devices or sensors would tell really interesting stories in aggregate. Better yet, I figured if this feed of data was enriched and analyzed properly and was directly integrated into the tools being used by security analysts around the world, they would have more context on the threats they were responsible for defending their organizations against.
The first pain point this approach solved for customers was alert fatigue: Security analysts could now easily “subtract” all the internet noise, automated attacks, and benign scanners from the attacks targeting their networks, giving them a cleaner signal of which targeted attacks to focus on. I closed a handful of customers for this use-case, raised some money, and hired a small team of incredibly talented people. Since then, GreyNoise has launched community and enterprise products that are trusted by tens of thousands of security practitioners, our customer-base includes over 150 of the most advanced organizations in the world, and our team has grown to over 50 of the smartest people I’ve ever known. We’re integrated into the most widely deployed security products and are cited by government intelligence agencies and news media on a near weekly basis.
As we continued to refine the security efficiency use-case at GreyNoise, a second use-case started to emerge: Every time a critical software vulnerability was disclosed, security analysts were left in the dark about whether attackers were actually exploiting it in the wild or not. Simultaneously, many of the times this would happen, we would start to see interesting new shapes and patterns show up in our raw sensor data. At first, this happened a few times per year. Now this happens every week.
Initially, we would detect in-the-wild exploitation by luck. But this use-case quickly became the most frequently asked by customers, as it was something they were not getting fast enough or clearly enough from their other vendors. So, at GreyNoise we started investing in new approaches that would enable us to consistently detect in-the-wild exploitation of software vulnerabilities within minutes. Not once, or twice, but every single time. We re-invented our core sensor and data processing architecture, deployed sensors to hard-to-reach places, and partnered with other security companies to get further and further ahead of attackers.
Entering 2024, a few things feel different:
These are all really hard problems. As such, last year I started looking for a partner to take over the business so I could focus on the things I’m uniquely passionate about. I found that partner in Ash Devata.
Ash is relentlessly customer and employee-focused. His reputation in the security industry is phenomenal, and his experience at the intersection of technology and business is unbeatable. I could not be more grateful or excited to partner with him to continue growing GreyNoise. I’ve spent the last few months getting to know Ash and, after every conversation or dinner we’ve had, I am more and more impressed with his outlook and thoughtfulness. Ash is joining us from Cisco where he was Vice President and General Manager for the Duo and Zero Trust business. He joined Cisco by way of acquisition from Duo where he built and ran a world-class Product organization since the early days of Duo. Ash’s brain and my brain are very different, but our hearts are very much the same.
Moving forward, I’ll be stepping into the role of Chief Architect at GreyNoise. My job will be to drive technical innovation specifically to stay ahead of cyber attackers, evangelize our products to the security community, set and implement our AI strategy, trawl through our data to document and understand attacker tactics, and be the first and most critical user and customer of our own products. It’s literally my dream job.
My ask to all of our customers, users, partners, and followers is that you greet Ash as warmly as you have always greeted me.
I have never been as excited as I am now about the future of GreyNoise and serving the broader security community.
Onward,
Andrew Morris
Founder, Chief Architect
GreyNoise
Software-defined radio (SDR) technology has been a transformative force in the world of wireless communications, enabling users to transmit and receive radio signals across a wide range of frequencies using software-controlled hardware. However, this innovative tool has recently come under scrutiny in Canada due to its misuse in auto thefts. As researchers at GreyNoise, we believe that the Canadian government's response to this issue, which leans towards a ban on open-source SDR technology, is not only harsh but also ineffective.
The Canadian government's recent actions, as outlined in the "Federal action on combatting auto theft" document, focus on — in theory — enhancing the capacity of the Canada Border Services Agency (CBSA) to combat auto theft. However, this policy indirectly touches upon the broader implications for SDR technologies. It mentions the goal of banning devices used to steal vehicles by copying wireless signals for remote keyless entry, which could include devices like the Flipper Zero.
The same hardware components and features that make a Flipper Zero are those found in nearly every modern mobile phone, and other consumer-grade devices. It is more than a stretch to blame any problems solely on the availability of such components under the brand name of “Flipper Zero” rather than, say, Apple/Samsung, or more directly comparable devices, such as the Lime SDR.
Open-source SDR hardware and software have revolutionized modern radio communications, enabling innovation and democratizing what had previously been expensive and proprietary. SDRs are capable of performing a wide range of communication functions that were traditionally executed by hardware components. Thanks to this innovation, we can now use software to access any part of the spectrum in any way. This has enabled rapid adaptation of new communication standards and technologies without the need for physical modifications or replacements of the radio hardware.
Banning or severely restricting this technology will stifle innovation and hinder new development. SDRs play a crucial role in research and development within telecommunications, as they help foster testing and development of new protocols and systems efficiently and — even more importantly — cost-effectively.
Moreover, SDRs are instrumental in security research, allowing cybersecurity professionals to analyze and understand wireless communications, including potential vulnerabilities. This knowledge is crucial for developing more secure communication systems.
The auto industry and other industries that rely on electronic locks and remote keyless entry systems are absolutely potential targets for exploitation using SDR technology. However, the solution should not be to ban or overly restrict SDRs, but to enhance the security of these systems. Industries using electronic locks should invest in robust security measures, including encryption and secure authentication protocols, to safeguard against unauthorized access.
Rather than impose overly broad restrictions on technologies like SDR, which 100% have legitimate and beneficial uses, efforts should focus on enhancing the security of vulnerable systems. This includes:
While government officials may view this new policy as an “easy button” way out of a current threat, it is far from a panacea and will not solve the problem.
Why not treat the current situation as a simple “recall” problem? Automobiles regularly have systemic issues that require a recall and manufacturer remediation. Rather than criminalize a technology category essential to future innovation (this policy would not be limited to just the “Flipper Zero”), have the manufacturers design a more secure solution and issue a recall. This makes future wireless security systems more robust and protects the owners and operators of current technology.
By focusing on enhancing vehicle security, the government can protect consumers without stifling the growth and development of open-source technologies that have far-reaching benefits. It is crucial to strike a balance between security and innovation, ensuring that the measures taken do not inadvertently harm the broader tech community and the positive advancements it brings to society.
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.
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.
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.
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.
Welcome to our Monthly Roundup, where we curate a unique mix of articles, books, podcasts, and more that have captured the attention of the GreyNoise team. From deeply technical articles to literary treasures, join us on this eclectic journey through the media that sparks our curiosity each month. Explore + discover as we share the gems that have fueled our inspiration!
🧠 Book: Memories, Dreams, Reflections | Carl Jung
⚖️ Audio Book: Oath and Honor | Liz Cheney
TL;DR: Never thought I’d read a book by Liz Cheney, but here I am.
🫧 Article: Introducing the Data Cleaning Day | Madeline Spinks
TL;DR: The team learned valuable lessons from the experience, such as the satisfaction of decluttering, discovering tech issues with file sharing, and improving version control. They recommend planning the event well in advance, involving team members in identifying priorities, and considering including training elements for better file management.
💰 Article: New Ransomware Reporting Requirements Kick in as Victims Increasingly Avoid Paying | Coveware
TL;DR: Coveware's new report discusses the ongoing debate surrounding ransomware payment bans and their effectiveness
🔎 Article: Analyzing Honeypot Data with Sentinel | Martin Rothe
Why I like it: Now that we have a new Sentinel integration, I've been using it more and more (sorry Splunk!). One of the first things that I needed to do was get some data in to learn how to actually write a KQL query instead of just copying and pasting and hoping that it works. I've been using this blog by Martin Rothe to get honeypot and Suricate data into Sentinel to start building out some pretty slick dashboards.
💼 Podcast: Business Wars | David Brown
Why I like it: Business Wars is an entertaining and informative storytelling of the historical milestones of two corporations competing with each other. I love it for long car rides especially. They have covered a VARIETY of wars. They range from things like “Nintendo vs. Sega vs. Microsoft”, “Starbucks vs. Dunkin” , “Covid Vaccine Wars” and “Crypto Wars”
👟 Audio Book: Shoe Dog | Phil Knight
Why I liked it: Listened to this audiobook on my morning walks. The challenges that Nike faced, the great team that Phil built, and the singular focus and determination he had in the early days of Nike resulted in a captivating and entertaining read.
The GreyNoise Labs team recently released a report on stats and trends the research team observed over the course of 2023. Here's a breakdown of some of the key elements gleaned from the data, with much more to be found in the original tome.
In 2023, our massive network of fake computers and services continued to lure attackers into revealing their tactics. Throughout the year, our researchers and platform helped provide many useful insights for the cybersecurity community. We do this simply to make the internet a safer place. This year saw our epic community increasingly institutionalize our observations, with our fellow security vendor partners integrating more of our data than ever. Government agencies and news media regularly cited our observations, a testament to the value of our work.
However, 2023 also marked the first time we directly observed attackers deliberately changing their behaviors to avoid our specific detection capabilities. We also noted that the time between software vulnerabilities becoming public and attackers using them at large scale continues to decrease. Yet, our approach to respond continues to be effective. In 2024, and beyond, we will continue to make our detection network larger and smarter, and share the attacker behaviors we observe with the world as quickly as possible.
Among the 242 Common Vulnerabilities and Exposures (CVEs) we covered in 2023, some stood out for their impact. The Progress MOVEit Transfer SQL Injection Vulnerability (CVE-2023-34362) was exploited by the Cl0p ransomware group, leading to data breaches in over 2.6K organizations and affecting ~90 million individuals. The Citrix NetScaler ADC and NetScaler Gateway Buffer Overflow Vulnerability (CVE-2023-4966; a.k.a., CitrixBleed) allowed threat actors to hijack authenticated sessions, bypassing multifactor authentication and password requirements. And, the PaperCut MF/NG Improper Access Control Vulnerability (CVE-2023-27350) was exploited by the Bl00dy Ransomware Gang, targeting vulnerable PaperCut servers, particularly within Education, but also in other sectors.
GreyNoise researchers are huge fans of CISA’s Known Exploited Vulnerabilities (KEV) catalog. In 2023, 67 of our tags had corresponding entries in CISA’s KEV catalog, 34% of which were also known to be associated with ransomware attacks. We meet or beat CISA nearly 63% of the time when it comes to having a published tag for a CVE that enters their catalog. This makes it much easier for federal agencies to meet or exceed remediation time requirements. It’s also helpful in the same way if your organization is tracking with KEV.
We cannot let 2023 go into the record books without some mention of the part that nation state conflicts have had on the mass exploitation landscape. The present major conflicts between Russia/Ukraine, Israel/Hamas, and other regional hostilities play out in both kinetic/physical (guns/bombs) and cyber fields. The evolution of nation state conflicts is also putting virtually every organization in the crossfire. No matter where adversaries aim their attacks, GreyNoise is there. No matter how many packets they sling, our systems analyze them instantly, enabling us to identify and communicate even the oddest trends and anomalies.
The GreyNoise platform, including our aforementioned vast sensor network, is designed to identify these probes and attacks with pinpoint precision at the very moment they occur. This gives defenders the tools and data they need to stop attacks before they start, plus buy time to focus on patching, mitigation, and response.
Dive into our report and don't hesitate to drop us a note or question in our community Slack or via email (research@greynoise.io).
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!
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
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.
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.
Here's the first payload that caught my eye:
Which decodes to:
As of writing, that file is live and installs a persistent backdoor using cron:
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:
What does the backdoor do? Let's take the lazy approach - strings:
Aha, a bitcoin miner!
Next up, this payload:
Which decodes to:
Unsurprisingly, m.sh is a shell script:
Kinda weirdly, the scripts are 64-bit and 32-bit executables:
Both files are UPX-packed (what year is this?), which is fortunately quite easy to unpack:
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:
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
And finally, the last payload:
Which decodes to:
And the shellscript it fetches:
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:
Advice: Check for a systemd service called .ssh_miner, a .profile entry that rusn a miner, or a file called /tmp/script.sh
Here are the SHA256 sums of all the files I saw:
And some file paths:
And the IP addresses / users I observed:
We recommend organizations block IPs that have recently exploited Ivanti. We have published a Gist containing these IPs.
Please update your search term or select a different category and try again.
Explore Our Data