Insights

Imagine this scenario: You’re running a security operations center, and your team is processing a bunch of alerts coming out of Splunk Enterprise Security. As you add new detections and log sources, the volume of alerts begins to rise, your analysts start to get overwhelmed, and that familiar alert fatigue starts to kick in. Your security engineering team jumps in with yet another cycle of tuning to get the alert volumes back down to manageable levels. Then the cycle starts all over again...

Hurricane Labs lives this reality every day as a managed services provider that is 100% focused on Splunk and Phantom. The company manages these platforms for customers, providing 24x7 monitoring services supported by a team of Splunk ninjas to handle the heavy lifting.

Recently the Hurricane team found a way to leverage GreyNoise Intelligence data to identify the noise in Splunk and Phantom alert traffic, reducing the load on their analysts by 25%.

We had the good fortune to chat with Hurricane Labs Director of Managed Services, Steve McMaster, to learn how the company had done it.

GreyNoise: Thanks for joining us, Steve. Perhaps we could start off with a bit of your background - how did you get started with Hurricane Labs?

STEVE MCMASTER: Sure - to set the stage, we manage Splunk and Phantom deployments for our customers, running the gamut from infrastructure management, to search and SPL creation, to security analysis and alerting, to rapid incident response. As part of these services, we provide 24x7 security monitoring, and I oversee the two teams that deliver this service. I’ve been with Hurricane for almost 14 years at this point - it's actually the only job I've ever had. I started here at age 17, right out of high school, and along the way, I've done a little bit of everything.

GN: What kind of challenges were you and your teams at Hurricane facing around your managing security alerts?

STEVE MCMASTER: We process a high volume of alerts on behalf of our customers, and as part of this traffic, we often see a lot of noisy alerts. This includes everything from known benign scanners (such as Shodan) to what we call "internet background noise," scanners that are constantly scanning the internet as a whole, looking for things to poke at.

The alert volumes we see are a constant ebb and flow, and we spend a lot of time tuning our customer’s environments to turn down the noise to a manageable level. But then, as we add new customers and more detections, the alert volumes start to creep back up. That’s when we see our analysts getting overwhelmed and feeling alert fatigue. It’s a normal cycle for our business, alert volumes go up, and then we need to dig in and tune our implementations to bring the volumes back down.

GN: What was it that drew you to GreyNoise?

STEVE MCMASTER: We were starting a new cycle of tuning to get alert volumes to come back down when I stumbled on Andrew [Morris, GreyNoise founder]. I saw my boss and Andrew exchanging views on Twitter, and I thought, “Who is this guy, and why does the stuff he’s saying make so much sense?” So I took a look at the GreyNoise product.

I have to say, I’ve always been a big skeptic of threat intelligence as an industry because once enough people know about a piece of intelligence to publish it for general consumption, it’s already burned infrastructure. Yes, you might find some threats with it, but it's not worth the $150K per year that they charge for it.

But GreyNoise was different. I always refer to GreyNoise now as “anti-threat intelligence.” It’s specifically the opposite of traditional threat intelligence. Instead of saying, “pay attention to this,” GreyNoise says, “STOP paying attention to this; go spend your time on other things.”

So this approach fit into an argument I was having with our customers a lot at the time - my point was that the things that you’re detecting are not actionable. They’re not targeted at you; they’re not somebody trying to exploit you; they’re JUST scanning the internet. So you shouldn’t worry about them or spend time on them.

Shodan makes a really good example of this, because Shodan is scanning everybody and showing up in a lot of alerts. But this is not something YOU need to care about, Mr. Customer; therefore, it's not something WE need to care about as part of our monitoring service. The problem is that this is really hard to quantify. You can show people that alerts from Shodan should be ignored — that's easy, but trying to identify broader Internet background noise was a lot harder to do. To be able to say, “Okay, we've seen this thing across our 40 customers, so let’s ignore it,” that's not really enough scale to be able to make this conclusion definitively.

And then along came this guy who had a product that did exactly that. So GreyNoise let us expand our service in a way that customers kind of already expected from us. Now we could say, “Look, this is opportunistic, this is generalized, this is global, this is not targeted.” And we could say this definitively because of the scale that GreyNoise operates.

And it really just happened to fit at a time when that was a problem we were trying to tackle with our customers.

GN: So now, fast forward, how are you using GreyNoise with Splunk and Phantom today to deliver on this promise of “reducing the noise?”

STEVE MCMASTER: We’re using GreyNoise in two ways - we use the data inside Splunk to eliminate alerts before they ever get to us, and then we do enrichment of alerts in Phantom once they reach us. We integrate the GreyNoise data into these environments using pre-built integrations that we initially developed, although we have turned these over to GreyNoise to maintain and extend for all their customers.

Our goal with these integrations is that if the IP address is in GreyNoise, then we eliminate it from alerting. GreyNoise actually returns 3 basic categories of “noise:”

1. an IP can be “known benign,” which is something I don't have to care about;
2. any IP identified as “known malicious” is something I should be automatically blocking at the edge;
3. and anything else (“unknown”) is when I want to stick a person on it to see what actually happened and what impact it had.

The reality is that some customers are not totally comfortable with the accuracy of these classifications (at least at first), so for some customers, we still raise a low-priority alert so they can have a human look at it. I think that this comes down to trust --and based on OUR experience-- if GreyNoise is confident the IP address is a scanner, then we are happy to ignore it. I would say about two-thirds of our customers are there today.

I’m also really excited about something Andrew mentioned at the last Open Forum conference GreyNoise held, the new RIOT service. Instead of identifying internet scanner “noise,” RIOT looks at the flip side of this by identifying the “known good,” common business services that everyone uses, like Slack or Office365, or Google IP addresses. So now we can easily tell the difference between a legitimate service like a Microsoft update and a "not legitimate" service like a malware download.

GN: Could you give us some more detail on how the implementations work?

STEVE MCMASTER: Sure, so when we use GreyNoise to filter noisy alerts out of Splunk, we use the GreyNoise-Splunk integration. We install that in our customer’s Splunk environment and add it to the search language for various detections. The logic is straightforward: if something in the search results matches GreyNoise, it gets excluded.

More specifically, we apply GreyNoise to any correlation search or detection inside of Splunk that we think is relevant. The big ones are IDS events and Splunk’s vulnerability scanner detection rules; those are the main ones that we use it for.

For Phantom, on the other hand, we use GreyNoise as an enrichment. The way our monitoring service works, we bring all of our customers’ alerts into a single Phantom instance, and we have the GreyNoise-Phantom integration installed. For our analysts looking at the alerts, one of the first things they do is look at the GreyNoise data. If the verdict is “noise,” then we know we don't need to do a lot more digging beyond that. This ends up saving us a lot of time because rather than investigating whether this is a targeted attack and figuring out whether anything was exploited, we can just short circuit the process, note it as a scanner, and send it over. Today we’re doing this as a manual process, but it's on our list to automate this into our incoming Phantom playbooks.

GN: What kind of impact has GreyNoise had on your business? Can you share any results?

STEVE MCMASTER: When I first told Andrew that we'd be interested in subscribing, I told him I had no concept of how much something like this would be worth. I didn’t know if we were going to turn this on and see matches with 10 alerts per day across our customers or 100. But the impact on alerts is really the only thing I had to help quantify the value of GreyNoise.

So Andrew gave us a two week trial, and I added it to our triage tool (this was before we stood up Phantom). And I just counted up how many alerts over a week would have been something we could totally ignore with GreyNoise versus what we would not have been able to. We were somewhere in the vicinity of saving the equivalent of one to one and a half analysts per day, out of 22 total analysts at the time, based on the alerts that we could safely eliminate with GreyNoise.

Today, after implementation and with more customers in hand, GreyNoise helps my teams eliminate background noise and focus on the most actionable and relevant alerts for our customers. Rather than presenting our analysts with even more data to investigate, GreyNoise has allowed us to reduce the volume of alerts that are triggered by 25%, which makes for a happier and more effective SOC team.

And for us as an MSSP, this is even more significant than it might be for an enterprise. When you’re in a normal enterprise business, you can make a decision to spend money on a person or spend money on a product that eliminates alerts--you kind of have to pick your poison. But for us, the calculus is a bit different. When we invest in a person, that analyst can do, say, 20 alerts per day. But if we invest in a product, that product can triage a certain number of alerts at every one of our customers. And for every new customer, it can repeat that work. So even if GreyNoise could only eliminate 8 alerts per day across 40 different customers, that’s 320 alerts. As we add more customers, GreyNoise scales in a way a person wouldn’t.

‍

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.

Identifying C2s Using Graph Analysis

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.

Identifying C2s Using Request 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.

Identifying Vulnerabilities Using Extracted C2s

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:

• Overmatched, misleading, or outdated indicator telemetry
• Legitimate computer programs doing weird things
• Poor security product UX
• Expected network behavior is a moving target
• Home networks are now corporate networks
• Cyberattacks are easier to automate
• Activity formerly considered malicious is being executed at internet-wide scale by security companies
• The internet is really noisy

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.

‍

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!

1. Improve SOC efficiency

Benign IPs

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.

Malicious IPs

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.

Unknown IPs (to GreyNoise)

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.

GreyNoise APIs

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.

Analyze a List of IPs

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:

1. Quickly filter out known good guys
2. If the situation warrants it, quickly identify opportunistic bad guys.

Here's an Analysis from an SSH auth.log I grabbed on a live server on the Internet.

~*~97.22% noise~*~

Filter Known-Benign Services (RIOT)

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 ¯\_(ツ)_/¯

2. Identify compromised devices

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

3. Emerging vulnerability exploitation

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.

Our Business Model

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:

• Most viz stuff == free but rate limited
• Community API == free but rate limited
• GreyNoise in your SIEM/TIP/SOAR == paid

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:

• If you use GreyNoise's free products, get in touch with @SupriyaMaz and she'll hook you up with free swag
• If you work in SOC/TI or at an MSSP and want to hear about our commercial offering, ping sales@greynoise.io

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

https://viz.greynoise.io/tags

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!

Defining Internet Noise

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.

Sources of Internet Noise

Let’s take a look at the different kinds of internet communications traffic that create this “noise” for security organizations:

Internet Scanners (aka Internet Background Noise)

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

Who scans the Internet?

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

Common Business Services

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.

Security Challenges of Internet Noise

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 Identifies Internet Noise So Security Teams Can Focus on Targeted Threats

GreyNoise tracks two distinct sets of Internet Noise today, making them available through our API, integrations, and visualizer:

• Internet Background Noise: At GreyNoise, we deploy and manage hundreds of servers in multiple data centers and countries around the world to listen to internet Background Noise. Our purpose is to sit back and soak up all the opportunistic traffic generated by anyone mass scanning the internet. GreyNoise analyzes and enriches this data to identify behavior, methods, and intent. The goal is to give analysts the context they need to answer questions like: How many people are scanning the internet right now? What IP addresses is it coming from? What are they scanning for?
• RIOT: RIOT provides context to communications between your users and common business applications (e.g., Microsoft O365, Google Workspace, and Slack) or services like CDNs and public DNS servers. These applications communicate through unpublished or dynamic IPs, making it difficult for security teams to track. Without context, this harmless behavior distracts security teams from investigating true threats.

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

• Track opportunistic botnets and other compromised devices
• Understand what software vulnerabilities the bad guys are actively scanning for
• Automatically enrich and prioritize alerts in SIEM and SOAR systems
• And, if so inclined, opt out of many malicious mass-scanners altogether by blocking them preemptively and dynamically at the firewall

Viewing Internet Noise with GreyNoise

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:

• Overall volume of Internet Noise
• New IPs generating Internet Noise
• Classification of Internet Noise into malicious, benign, and unknown actors
• Top organizations that are sources of Internet Noise
• Trends and anomalies in Internet Noise traffic over the past month
• Detailed behavioral information about specific IP addresses running scans
• Emerging threat data about vulnerabilities being actively exploited

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!

‍