You may have noticed that we have announced a couple of new relationships in the last several months with the US federal government. We announced our partnership with the Defense Innovation Unit (DIU) of the US Department of Defense (DoD) to help optimize their investigations, and recently announced our partnership with In-Q-Tel (IQT). I wanted to talk a bit about what this means for GreyNoise and why we’re excited about it.
First, I’m very excited about cracking the nut of working with the defense and intelligence communities of the US federal government. We already work with a number of intelligence and defense agencies around the world, as we have mentioned in the past, but these new relationships really serve to validate the value of our solution. Specifically, DIU helps us provide our existing product to DoD customers more quickly, and IQT facilitates feedback and helps us fast-track features that solve customer problems, which will ultimately benefit all federal and non-federal customers.
Second, while we work closely with our commercial customers to ensure that we have prioritized their needs, we’ve found it can be harder to get these requirements from government agencies because of the nature of their programs. In other words, government customers are harder to solicit product feedback from due to the classified nature of their work. DIU and In-Q-Tel help to bridge that gap.
And finally, I wanted to finish with a note on our security and privacy policies. We passively collect and analyze a massive amount of internet scan traffic as part of our solution, but we will NEVER share user account and customer data or usage data with anyone outside of our organization. Our customers’ and users’ trust is extremely important to what we do, and we don’t want to compromise that trust in any way. It is common for corporate entities to defer announcement of government customers to reduce the risk of entangling themselves in complex geopolitical dynamics, but we felt strongly that we should publicly acknowledge our relationships. Transparency isn’t a bumper sticker to us; it’s a way of being, and a core value of the company.
The reality is that both government and commercial organizations are struggling with the same pressures and challenges in areas like alert fatigue and analyst investigative efficiency. These new partnerships with DIU and IQT will help make GreyNoise better for ALL of our users and customers.
Onward.
--Andrew
CVE-2020-25494
Tag: SCO OpenServer RCE Attempt [Intention: Malicious]
CVE-2021-22911
Tag: Rocket.Chat server RCE Attempt [Intention: Malicious]
Tag: Vesta Control Panel RCE Attempt [Intention: Malicious]
CVE-2021-27144/46 | CVE-2021-27148/55 | CVE-2021-27158/59 | CVE-2021-27162/66 | CVE-2021-27168/69 | CVE-2021-27172
Tag: FiberHome Telnet Backdoor [Intention: Malicious]
Tag: LokiBot C2 Crawler [Intention: Unknown]
Tag: Aerospike Crawler [Intention: Unknown]
As part of our process, our research team continues to clean up and improve on existing tags as new information or better processes are introduced.
Tag: Tomcat Manager Scanner [Intention: Unknown]
GreyNoise sees a lot of botnet activity, both benign and malicious, through our fleet of global sensors. We enlisted Black Lotus Labs®, the threat research arm of Lumen, to help us bring you more information about these botnets and their Command and Control (C2) hosts. A botnet’s C2, as the name implies, is a host from which bots receive their commands, download malicious files, and/or simply report back. Effectively, the C2 is the brain of the operation, and without one, a bot may simply sit dormant.
Black Lotus Labs' mission is to find and disrupt C2s to make the internet a cleaner and safer place. The amount of noise generated by these botnets, driven by their C2s, is astounding. For example, check out the traffic for May just for the Mozi botnet:
Some reports estimate that bots generate 25% of all internet traffic. This reflects what we see at GreyNoise - for example, on any given day, we tag around 30k IPs as ‘Mirai’ or ‘Mirai Variant,' one of the most prevalent bots in the wild. We are always looking for ways to identify sources of internet noise, so hunting botnets and their C2s with the Black Lotus Labs team was a natural fit.
To kick off our project, Black Lotus Labs enriched their netflow data using IPs tagged as ‘Mirai Variant’ in GreyNoise and applied some basic graph algorithms to identify a list of potential C2 IPs. These algorithms mapped 23 suspected C2 IPs in Black Lotus Labs’ data that communicated the most with several hundred GreyNoise ‘Mirai Variant’-tagged IPs. This one-to-many relationship is indicative of a traditional C2. Some of the potential C2 IPs in Black Lotus Labs’ data were previously identified Mirai C2s, but, interestingly enough, others were identified as a botnet family known as Mozi, a newer family that eschews the traditional C2 model.
Mozi exhibits many of the characteristics of Mirai, with one major exception: it has no central C2. Instead, Mozi is a peer-to-peer (P2P) botnet where every infected host is both a bot and a C2. Each peer propagates configurations and hosts payloads while also performing bot duties such as participating in DDoS, scanning the internet, and exploiting hosts to expand the botnet. For more on Mozi and P2P botnet technology, check out Black Lotus Labs’ analysis.
From the GreyNoise side of the project, we decided to look at request payloads within scanner traffic to see if we could identify C2s. We observed that, despite their difference in centralization, botnets like Mirai and Mozi are both notorious for inserting C2 addresses (IPs or domains) into their initial exploit attempt. Typically these exploits will execute a script that fetches a malicious payload from the C2 address and initializes the bot.
If you’ve ever looked at traffic hitting your network perimeter, you have probably seen a request like this:
If you extract and check the IP, you might discover, unsurprisingly, that the host is a C2. That’s it. No advanced analytics. No machine learning. No blockchain. Just IP and domain extraction.
We decided to leverage this insight and test if this was an accurate way to identify P2P Mozi family C2s - that is, IPs that scan like a bot AND deliver peer-to-peer C2 addresses. Our approach was to extract a set of IPs matching this request pattern from our data and then compare the results with Black Lotus Labs C2 data.
Using this method, we compiled a list of 3,368 suspected C2 IPs that appeared to be delivering requests with embedded C2 addresses. Our free Analysis tool confirmed that 97% of these IPs scanned the internet within the last 90 days. So our hypothesis was that this combination of bot and C2 behaviors allows us to accurately identify P2P Mozi family C2s.
To test the hypothesis, we asked Black Lotus Labs to analyze the IP list and identify any C2s already known to them. They found that our list contained 962 IPs previously identified as C2s or botnet peers.
In total, 28% of our potential Mozi IPs were identified by Black Lotus Labs as C2s. Of those, 98% were confirmed as Mozi. So while this is a promising start at identifying suspected C2 IPs, it doesn’t provide conclusive evidence that IPs exhibiting this behavior belong to the Mozi family. Further research is required to profile the remaining 71%, which are most likely simple bots.
Why is it important to identify C2 IPs like Mozi? Using the confirmed C2 data in hand, we found we can now pivot around the addresses (both IPs and domains) to help identify the vulnerabilities being exploited. For example, take the following C2 domain:
bp65pce2vsk7wpvy2fyehel25ovw4v7nve3lknwzta7gtiuy6jm7l4yd[.]onion[.]ws
We found that more than 50% of traffic containing this C2 domain belonged to IPs, probably bots, exploiting the same three vulnerabilities: TerraMaster TOS (CVE-2020-28188), Zend Framework (CVE-2021-3007), and Liferay Portal (CVE-2020-7961).
The FreakOut botnet is known to exploit this unholy trinity. Although we already have tags for all three of these vulnerabilities, this demonstrates how we can use C2 addresses to automate the process of identifying and tagging known unknowns: vulnerabilities used by botnets.
Recall that bot traffic comprises almost a quarter of all internet traffic. Developing and expanding these techniques allow us to closely examine some of the most common noise on the internet. Any vulnerability checks or exploit used by a botnet like Mirai or Mozi is bound to be one of the most well used on the internet. By knowing botnets, we know noise.
Additionally, we want to refine and share these fun C2 addresses, like cnc[.]tacobelllover[.]tk, with our customers and community as a data feed for your projects, research, and work. If this interests you, create a GreyNoise account and join our Community Slack to give us feedback.
Please check out Andrew Morris' guest blog on IOActive
It turns out that alert fatigue is not unique to cybersecurity - who knew? Given the fact that alert overload is a problem across industries like healthcare, manufacturing, transportation, and utilities, you’d think that we in the cybersecurity industry would have some better tools and insights about how to handle it. Unfortunately, that’s not the case.
This is why Andrew Morris, founder and CEO of GreyNoise, pulled together his thoughts on the topic and shared them in a guest blog for IOActive. The post is titled “Cybersecurity Alert Fatigue: Why It Happens, Why It Sucks, and What We Can Do About It.” In the article, he covers the main contributing factors to alert fatigue for cybersecurity practitioners, the impact it has on analysts and SOC teams, and some thoughts about addressing the problems at multiple levels.
You know you might have an alert fatigue problem if any of these technical causes of alert fatigue sound familiar:
And all of these factors are made worse by a SOC ecosystem that’s not set up for success. This includes vendors who sell on fear, build products that don’t play well with others, focus only on the signal (not the noise), and price their products in ways that drive them to raise as many alerts as possible. And SOCs are equally culpable, putting enormous pressure on analysts to catch every single attack in an environment where the alert volumes just keep growing, and half of them are false positives. Is it any wonder that security analysts exhibit serious alert fatigue and burnout, and that SOCs have extremely high turnover rates?
Please check out the blog post here to learn more about the causes of alert fatigue, why it sucks, and what we can do about it.
CVE-2021-21985
Tag: Vmware vSphere Client RCE Attempt [Intention: Malicious]
Tag: VMware vSphere Client RCE Vuln Check [Intention: Unknown]
CVE-2021-28799
Tag: VMware ESXi OpenSLP RCE Attempt [Intention: Malicious]
As part of our process, our research team continues to clean up and improve on existing tags as new information or better processes are introduced.
Tag: Elasticsearch RCE Attempt [Intention: Malicious]
These tags have been removed because they no longer exist, scan, and/or can no longer be accurately identified
Andrew Morris got on a roll the other day and whacked out this tweetstorm describing the three key use cases for GreyNoise. You can check out the original Twitter thread here. Enjoy!
Let's say I get a wacky IDS alert or am seeing something strange in my logs. I'll look up the IP address in GreyNoise (either using our visualizer or our free community API.
I looked up the IP address and, oh wow! It's just Shodan! GreyNoise already marked it as benign. No big deal. Paste a link in your ticket to the GreyNoise visualizer and move on.
https://viz.greynoise.io/ip/71.6.135.131
Maybe I don't want to use the GreyNoise web interface. Let's say I look up the IP in the free unauthenticated GreyNoise Community API and... cool, reports back that it's Censys. No problemo. Move on.
Let's say I look up an IP address, and it comes back with this big scary red IP address that says "malicious." What does this mean?
https://viz.greynoise.io/ip/45.155.205.165
Well, this means that the IP is probably malicious (or was observed by GreyNoise doing something bad on our sensors), but whatever attack you're seeing is not targeted at *you specifically*. It was an opportunistic attack. Background noise.
What if the IP address... doesn't come back at all?
This means that we've never seen that IP scanning/crawling the Internet, and it doesn't belong to any benign business services. It actually *might* be targeted your organization specifically. Investigate.
The GreyNoise Community API is rate limited to a few thousand lookups per day, but it's completely free and unauthenticated. As long as we continue to add enterprise customers and can afford to pay our staff and AWS bills, this will continue to be free.
Note that you don't get context, raw data, metadata, or tags using the Community API. Sorry folks, we've gotta make our money somewhere. This is available in our Enterprise API. If you want this data via API, hit up our sales team. But hey, it's free.
Fun fact: Just about every customer we have at GreyNoise sees at least a 20% alert contextualization/reduction rate from using GreyNoise. That's a LOT of wasted human hours spent chasing ghosts.
Now let's say you've had an incident, and you need to figure out which of the gazillion IP addresses in some log file compromised your device.
No problemo. Just dump the log file (or just the IP addresses) into the GreyNoise analysis page, and now you can do two things:
Here's an Analysis from an SSH auth.log I grabbed on a live server on the Internet.
~*~97.22% noise~*~
Let's say I'm trawling through a ton of netflow logs, and I want to identify any connections OUT of my network that might be going to bad guys.
I can filter known-benign services (Zoom, Github, Office365, Cloudflare, etc.). I can use GreyNoise RIOT for this.
*I'd like to note here that the IPs in RIOT *could potentially* be used by a sufficiently advanced adversary to attack you (async c2, etc.), but that doesn't mean that 99% of bad guys will be doing this, and it's not like you can just *BLOCK ZOOM* and not expect blowback.
Don't think of RIOT as a NACL or whitelist/allowlist. Think of RIOT as added context and a time-saver. You can either find out from GreyNoise via RIOT, or you can find out from your helpdesk reps when you block an IP and execs suddenly can't send emails anymore ¯\_(ツ)_/¯
Let's say I want to find compromised devices that belong to ME, my users, or just some interesting network around the world.
Just punch in a GNQL query into the web interface of the IP block I'm interested in + the facet: "classification:malicious"
You can actually also find compromised devices in other facets as well. Here are examples of finding compromised devices in a specific country or using free text search to find compromised devices in hospitals or government facilities (or both):
You can use your FREE GreyNoise account to register alerts on any network block or IPs. Once you've registered your alerts, we email you if we see any of your IPs get compromised (e.g., unexpectedly start scanning the internet )
https://viz.greynoise.io/account/alerts
You can use GreyNoise to find whether a given vulnerability is being opportunistically exploited or "vuln checked" at scale. Simply craft a GNQL query for CVE.
https://viz.greynoise.io/query/cve:CVE-2021-3129
When a big scary vulnerability is announced, basically everyone has the exact same thought:
"How much do I **really** have to care about this? Is this... being exploited in the wild right now?"
GreyNoise is declaring war on this ambiguity.
You can also see *which* CVEs a given IP address is probing the internet for or opportunistically exploiting. This list is not exhaustive - it takes a lot of work to add coverage to these. This is what @ackmage @nathanqthai and @4b4c41 do.
We have a long ways to go on properly productizing this offering. It's really hard to do at scale, and not every vulnerability can be exploited in a way that GreyNoise will ever see. That said, we'll be announcing some new offerings focusing on this use case later this year.
Our business model is pretty simple:
Expect a lot of this stuff to shift over the next few months/years as we find better ways to price/package our features.
That pretty much covers it.
Here are my asks to you:
And, of course, ping me anytime. I can't promise a snappy response, but I try to clear my inbox at least every few weeks (aspirational). My email is andrew@greynoise.io.
Oh, last thing. We tag like... hundreds of activities and actors and exploits and vuln probes and tools. Check them all out here (it's searchable, but the layout is pretty unwieldy considering how massive our tag library is now).
Onward.
--Andrew
Andrew Morris got on a roll the other day and whacked out this tweetstorm describing the three key use cases for GreyNoise. Enjoy!
CVE-2021-26912 | CVE-2021-26913 | CVE-2021-26914 | CVE-2021-26915
Tag: NetMotion Mobility Server RCE Attempt [Intention: Malicious]
CVE-2021-21402
Tag: Jellyfin File Disclosure [Intention: Malicious]
CVE-2021-28799
Tag: QNAP walter SSH Backdoor Attempt [Intention: Malicious]
CVE-2021-30461
Tag: VoIPmonitor Unauthenticated RCE Attempt [Intention: Malicious]
As part of our process, our research team continues to clean up and improve on existing tags as new information or better processes are introduced.
Tag: RDP Bruteforcer [Intention: Malicious]
Rapid 7 InsightConnect: Supports Enterprise API and Community API access.
CORTEX XSOAR: Supports Enterprise API and Community API access.
Every machine connected to the internet is exposed to a constant barrage of communications from tens of thousands of unique IP addresses per day. A percentage of these communications are malicious attacks and web crawls; some are non-malicious scans and pings; some are legitimate business services; and still others are unknown. Taken together, this massive volume of unsolicited traffic is a challenge for security organizations because these communications trigger security tools to generate thousands of events to be analyzed, with little context on the potential threats.
Let’s take a look at the different kinds of internet communications traffic that create this “noise” for security organizations:
Scanning the internet means reaching out and trying to initiate communications with a wide range of devices that are directly connected to the internet. At a technical level, mass scanning the internet means requesting a slight amount of information (specifically a TCP SYN, UDP/ICMP packet, or banner grab) from all 4.2 BILLION IP addresses on the entire routable IPv4 space. And it turns out that tens of thousands of devices are scanning the internet constantly, generating a tremendous amount of internet “noise.”
Good guys scan the internet to measure the exposure of vulnerabilities, take inventory of software market share, and find botnet command & control servers. In fact, there are entire websites and companies that act as "search engines" devoted to mass scanning the internet. Examples of this include companies like Shodan and Censys, as well as researchers and universities, who scan in good faith to help uncover vulnerabilities for network defense.
Bad guys scan the internet with malicious intent to find vulnerable devices that they can compromise and use for nefarious purposes. So while benign mass-scanner IP addresses might check if a port is running and then go away, malicious scanners might attempt to compromise the target machine by brute-forcing login credentials or launching a remote exploit. A good example was a recently discovered vulnerability in F5 network devices - in this case, malicious IPs scanned for F5 BIG-IP devices, checked if the device was vulnerable, and attempted to exploit the vulnerability.
Unknown groups scan the internet for unclear or covert reasons. Unknown actors could be individual researchers, companies, or nation-state actors that are attempting to remain anonymous, and everything in between.
At the end of the day, web crawlers, port scanners, researchers, and malware such as worms and botnets are all part of the activities that contribute to Internet Noise. The challenge for security organizations is differentiating which of these scans are malicious signs of a targeted attack, and which are just “noise.”
Another increasingly challenging source of Internet Noise is legitimate network communications with common business applications like Microsoft O365, Google Workspace, and Slack, as well as services like CDNs and public DNS servers. These applications often communicate through unpublished or dynamic IPs, making them difficult to identify. The result is a storm of log events from “unknown” IP addresses that are, in reality, from well-known and benign business services. Without context, this harmless communication distracts security teams from investigating true threats.
The goal for security teams is to identify malicious internet traffic that represents a potential threat to the organization, so they can focus research and remediation efforts quickly. Internet Noise ends up being a huge tax on SOC teams by taking time away from analysts that could be spent addressing true threats, inflating log volumes and increasing storage costs, and contributing to analyst burnout.
GreyNoise tracks two distinct sets of Internet Noise today, making them available through our API, integrations, and visualizer:
The data GreyNoise collects can be used by security analysts to identify and de-prioritize traffic from omnidirectional scanners and common business services, allowing them to focus on targeted scan and attack traffic. They can use the data to
If you’re interested in learning more about what Internet Noise is and how much of it is happening on the internet right now, please check out the GreyNoise Visualizer. Free to use, the Visualizer can show you:
And if you find this information interesting or useful, please sign up for a free Community account, which includes access to our API for a subset of the “noise” data we collect. Our community of 10,000+ security analysts is a tremendous source of insight into Internet Noise and other InfoSec knowledge. If you are interested in joining, please reach out to community@greynoise.io
Also, please follow us on Twitter and LinkedIn!
Every company has a distinct culture and style of communicating information between itself and the rest of the world. At GreyNoise, we’ve relied heavily on our use of Twitter and other social media that are popular with our users. This has historically worked well, but it has limited us to only brief pulses of information. Now, I’m excited to announce the GreyNoise blog, where we will be able to convey more information and ideas with more opportunities for detail and nuance.
GreyNoise was founded in 2017 with a simple mission: Use data to make security teams more efficient, and provide answers and insights where there are none. Our flagship enterprise product contextualizes noisy alerts in the SOC that are generated by internet background noise and harmless online services. Our free web interface and community API provide insights to thousands of security professionals every day.
To provide these services, we collect lots of data from across the internet at a very large scale. We operate a really big network of passive collector sensors in hundreds of data centers around the world (kind of like honeypots) to analyze internet background noise. And we constantly enumerate the IP addresses and domains of common benign SaaS services to “rule out” harmless traffic from security products.
In building and scaling GreyNoise, we’ve learned a lot of interesting lessons and witnessed a lot of interesting phenomena. The GreyNoise blog will be another forum for us to share these lessons and phenomena with the rest of the world.
GreyNoise has made a tremendous amount of progress over the past three years, but we are still in the early days. I’m excited to share the journey with you here.
Onward.
– Andrew
Please update your search term or select a different category and try again.
