Insights

Explore articles on cybersecurity fundamentals, industry trends, best practices, and key things every security professional should know about today’s evolving landscape.

Checking It Twice: Profiling Benign Internet Scanners — 2024 Edition

This is a follow-up from our October, 2022 post — Sensors and Benign Scanner Activity

Throughout the year, GreyNoise tends to focus quite a bit on the “naughty” connections coming our way. After all, that’s how we classify IP addresses as malicious so organizations can perform incident triage at light speed, avoid alert fatigue, and get a leg up on opportunistic attackers by using our IP-based block-lists.

At this time of year, we usually take some time to don our Santa hats and review the activities of the “nice” (a.k.a., “benign”) sources that make contact with our fleet.

Scanning the entire internet now drives both cybersecurity attack strategies and defense tactics. Every day, multiple legitimate organizations perform mass scanning of IPv4 space to gather data about exposed services, vulnerabilities, and general internet health. In November 2024, we deployed 24 new GreyNoise sensors across diverse network locations to study the behavior and patterns of these benign scanners.

Why This Matters

When organizations deploy new internet-facing assets, they typically experience a flood of inbound connection attempts within minutes. While many security teams focus on malicious actors, understanding benign scanning activity is equally crucial for several reasons:

  1. These scans generate significant amounts of log data that can obscure actual threats
  2. Security teams waste valuable time investigating legitimate scanning activity
  3. Benign scanners often discover and report vulnerable systems before malicious actors

The Experiment

We positioned 24 freshly baked sensors across five separate autonomous systems and eight distinct geographies and began collecting data on connection attempts from known benign scanning services. We narrowed the focus down to the top ten actors with the most tags in November. The analyzed services included major players in the internet scanning space, such as Shodan, Censys, and BinaryEdge, along with newer entrants like CriminalIP and Alpha Strike Labs.

Today, we’ll examine these services' scanning patterns, protocols, and behaviors when they encounter new internet-facing assets. Understanding these patterns helps security teams better differentiate between routine internet background noise and potentially malicious reconnaissance activity. There’s a “Methodology” section at the tail end of this post if you want the gory details of how the sausage was made.

The Results

We’ll first take a look at the fleet size of the in-scope benign scanners.

The chart below plots the number of observed IP addresses from each organization for the entire month of November vs. the total tagged interactions from those sources (as explained in the Methodology section). Take note of the tiny presence of both Academy for Internet Research and BLEXBot, as you won’t see them again in any chart. While they made the cut for the month, they also made no effort to scan the sensors used in this study.

As we’ll see, scanner fleet size does not necessarily guarantee nimbleness or completeness when it comes to surveying services on the internet.

Contact Has Been Made

The internet scanner/attack surface management (ASM) space is pretty competitive. One area where speed makes a difference is how quickly new nodes are added to the various inventories. All benign scanners save for ONYPHE (~9 minutes) and CriminalIP (~17 minutes) hit at least one of the target sensors within five minutes of the sensor coming online.

BinaryEdge and ONYPHE display similar dense clustering patterns, with significant activity bursts occurring around the 1-week mark. Their sensor networks appear to capture a high volume of unique IP contacts, forming distinctive cone-shaped distributions that suggest systematic scanning behavior.

Censys and Bitsight exhibit comparable behavioral patterns, though Bitsight’s first contacts appear more concentrated in recent timeframes. This could indicate a more aggressive or efficient scanning methodology for discovering new hosts.

ShadowServer shows a more dispersed pattern of first contacts, with clusters forming across multiple time intervals rather than concentrated bursts. This suggests a different approach to host discovery, possibly employing more selective or targeted scanning strategies.

Alpha Strike Labs and Shodan.io demonstrate sparser contact patterns, indicating either more selective scanning criteria or potentially smaller sensor networks. Their distributions show periodic clusters rather than continuous streams of new contacts.

CriminalIP presents the most minimal contact pattern, with occasional first contacts spread across the timeline. This could reflect a highly selective approach to host identification or a more focused scanning methodology.

The above graph also shows just how extensive some of the scanner fleets are (each dot is a single IP address making contact with one of the sensors; dot colors distinguish one sensor node from another).

If we take all that distinct data and whittle it down to count which benign scanners hit the most sensors first, we see that ONYPHE is the clear winner, followed by Censys — demonstrating strong but more focused scanning capabilities — with BinaryEdge coming in third.

The chart below digs a bit deeper into the first contact scenarios. We identified the very first contacts to each of the 24 sensor nodes from each benign scanner. ONYPHE shows a concentrated burst of activity in the 6-12 hour window, while Bitsight’s contacts are more evenly distributed throughout the observation period. Censys demonstrates a mixed pattern, with clusters in the early hours followed by sporadic contacts. ShadowServer exhibits a notably consistent spread of first contacts across multiple time windows.

BinaryEdge’s pattern suggests coordinated scanning activity, with tight groupings of contacts that could indicate automated discovery processes. Alpha Strike Labs shows a selective, possibly more targeted approach to first contact, while CriminalIP has minimal but distinct touchpoints. Shodan rounds out the observation set with periodic contacts that suggest a methodical scanning approach.

Speed Versus Reach

While speed is a critical competitive edge, coverage may be an even more important one. It’s fine to be the first to discover, but if you’re not making a comprehensive inventory, are you even scanning?

We counted up all the ports these benign scanners probed over the course of a week. Censys leads the pack with an impressive 36,056 ports scanned, followed by ShadowServer scanning 19,166 ports, and Alpha Strike Labs covering 14,876 ports.

ONYPHE, Shodan, and even both BinaryEdge and Bitsight seem to take similar approaches when it comes to probing for services on midrange and higher ports. All of them, save for CriminalIP, definitely know when you’ve been naughty and tried to hide some service outside traditional port ranges.

Before moving on to our last section, it is important to remind readers that we are only showing a 7-day view of activity. Some scanners, notably Censys, have much broader port coverage than a mere 55% of port space. The internet is a very tough environment to perform measurements in. Routes break, cables are cut, and even one small connection hiccup could mean a missed port hit. Plus, it’s not very nice to rapidly clobber a remote node that one is not responsible for.

Tag Time

The vast majority of benign contacts have no real payloads. Some of them do make checks for specific services or for the presence of certain weaknesses. When they do, the GreyNoise Global Observation Grid records a tag for that event. We wanted to see just how many tags these benign scanners sling our way.

Given ShadowServer’s mission, it makes sense that they’d be looking for far more weaknesses than the other benign scanners. The benign scanner organizations that also have an attack surface management (ASM) practice will also usually perform targeted secondary scans for customers who have signed up for such inspections.

In Conclusion

We hope folks enjoyed this second look at what benign scanners are up to and what their strategies seem to be when it comes to measuring the state of the internet.

If you have specific questions about the data or would like to see different views, please do not hesitate to contact us in our community Slack or via email at research@greynoise.io.

Methodology

Sensors were deployed between 2024-11-19 and 2024-11-26 (UTC) across five autonomous systems and in the IP space of the following countries:

  • Croatia
  • Estonia
  • Ghana
  • Kenya
  • Luxembourg
  • Norway
  • Slovenia
  • South Africa
  • Sweden

The in-scope benign actors (based on total tag hits across all of November):

Both Palo Alto’s Cortex Expanse and ByteSpider were in the original top ten, but were removed as candidates. Each of those services are prolific/noisy (one might even say “rude”), would have skewed the results, and made it impossible to compare the performance of these more traditional scanners. Furthermore, while ByteSpider may be (arguably) benign, it has more of a web crawling mission that differs from the intents of the services on the rest of the actor list.

We measured the inbound traffic from the in-scope benign actors for a 7-day period.

Unfortunately, neither Academy for Internet Research and BLEXBot reached out and touched these 24 new sensor nodes, therefore have no presence in the results.

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

Mozi-ing around C2s with Black Lotus Labs

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:

Figure 1: Volume of netflow records  associated with known Mozi botnet IPs observed  by Black Lotus Labs for the month of May, 2021.
Figure 1: Volume of netflow records associated with known Mozi botnet IPs observed by Black Lotus Labs for the month of May, 2021.

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.

Figure 2: Potential C2 determined by a one-to-many relationship to tagged bots.
Figure 2: Potential C2 determined by a one-to-many relationship to tagged bots.

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.

Figure 3: Centralized botnet (left) vs P2P botnet (right)
Figure 3: Centralized botnet (left) vs P2P botnet (right)

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:

Figure 4: Example request with C2 IP.
Figure 4: Example request with C2 IP.

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.

Figure 5: Potential C2s observed scanning by the GreyNoise Analyzer.
Figure 5: Potential C2s observed scanning by the GreyNoise Analyzer.

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.

Figure 6: Left, percentage of IPs analyzed by Black Lotus Labs . Right, breakdown C2 families for the analyzed IPs.
Figure 6: Left, percentage of IPs analyzed by Black Lotus Labs. Right, breakdown C2 families for the analyzed IPs.

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.

Some Thoughts On Fixing Alert Fatigue In The SOC

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.

Get Started With GreyNoise for Free

GreyNoise Use Cases: Twitter Edition

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!

I'd like to do an overview of the three most common use-cases to use  @GreyNoiseIO  for.   1. Ignore/deprioritize pointless telemetry or alerts in the SOC 2. Identify compromised systems 3. Track which vulnerabilities are being opportunistically exploited ITW  Thread (1/26)

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

Example of GreyNoise Visualizer showing benign IP address detail

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.

Example of GreyNoise Community API showing benign IP address detail

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

Example of GreyNoise Visualizer showing malicious IP address detail

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.

Example of GreyNoise Visualizer showing "No results found"

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~*~

Example of GreyNoise Visualizer showing Analysis results

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.

Example of netflow log with a large number of IP addresses to triage
After analysis, just a handful of IP addresses are identified as "malicious" or "unknown"
Example of GreyNoise Visualizer showing RIOT IP address detail

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

Example of GreyNoise Visualizer showing malicious scanning from devices within an IP address range

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

Example of GreyNoise Visualizer showing malicious IP addresses related to government
Example of GreyNoise Visualizer showing malicious IP addresses related to hospitals
Example of GreyNoise Visualizer showing malicious IP addresses from a country related to hospitals

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

Example of GreyNoise Visualizer showing how to set up 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

Example of GreyNoise Visualizer showing malicious IP addresses related to a CVE

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.

Example of GreyNoise Visualizer for a malicious IP address showing targeted CVEs

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

Some of the activities and actors and exploits and vuln probes GreyNoise has identified

Onward.

--Andrew

GreyNoise Use Cases: Twitter Edition V2

Andrew Morris got on a roll the other day and whacked out this tweetstorm describing the three key use cases for GreyNoise. Enjoy!


How Internet Noise Makes Security Harder

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!

Get Started With GreyNoise for Free

No blog articles found

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

Get started today