One of the most frequent customer questions we get is: where can I best apply GreyNoise data? GreyNoise has a trove of data, but when talking about how to actually operationalize our datasets, one of the easiest use cases is through the lens of the MITRE ATT&CK framework.
The MITRE ATT&CK is a globally accessible knowledge base of adversary tools, tactics, and techniques (TTPs) based on real-world observations. The ATT&CK framework was originally designed to standardize discussion around adversary behavior between public and private sectors. Creating such a framework has allowed organizations to share remediation, mitigation, and detection strategy as it relates to adversary TTPs. Since its inception in 2018, it has become a globally adopted framework for organizations. For further information, check out the MITRE ATT&CK whitepaper.
GreyNoise has close to four thousand sensors distributed across the internet passively listening and capturing (good, bad, and unknown) actors conducting scans. Activity observed by these actors can include running large scale nmap or masscan scans indiscriminately searching for devices, looking for exposed services or directories, or going beyond basic discovery and actively searching for vulnerable devices and brute-forcing credentials. Because of the unique data GreyNoise gathers with our extensive sensor network, the two main ATT&CK tactics with which we see customers using GreyNoise data are Reconnaissance (TA0043) and Initial Access (TA0001).
Let’s look at a few examples of specific MITRE ATT&CK techniques and how customers are using GreyNoise to identify attacks better and earlier.
Sub-techniques: T1595.001 Active Scanning: Scanning IP Blocks, T1595.002 Active Scanning: Vulnerability Scanning
This is one of our most frequent uses for GreyNoise. By this point, it is well-known that anything put online will be scanned at any time. However, this brings a huge challenge: identifying whether or not something is opportunistic activity, or whether someone is specifically targeting your organization. This hurdle becomes further compounded by the volume of alerts generated on this inbound traffic - volume that can quickly overwhelm even the largest security teams.
When monitoring these devices and logging the data to a SIEM, one of the quickest ways to filter out noise and start to look at things that are targeted is to compare that data against what GreyNoise has observed. Below, firewall data feeds into Splunk that is being enriched with GreyNoise to better understand what is hitting the firewall. By filtering data this way, teams can see context on most of the IPs to sort them out, quickly find what needs to be investigated, and not spend as much time tracking down IPs that are only opportunistically scanning the internet.
Filtering the data this way quickly sifts opportunistic scan-and-ATT&CK traffic, allowing teams to identify the IP address that should be prioritized for deeper investigation. Better, this yields additional context on the remaining IP addresses for further prioritization. Using GreyNoise data this way facilitates detection of ATT&CKs directed at your organization earlier in the Kill Chain.
Sub-techniques: T1189 Drive-by Compromise, T1190 Exploit Public-Facing Application
Another popular GreyNoise use case among customers: gaining a better understanding of hosts that are sending exploit payloads across the internet. At the time of this writing, GreyNoise observed almost 85,000 hosts over a 24-hour period who were opportunistically attempting to exploit hosts at scale across the internet.
On closer re-examination of the firewall data (in the data that is enriched by GreyNoise) we can see many IPs and information about the exploits that are being launched.
These are enrichments that easily correlate against vulnerability or ASM data to validate that no one is running vulnerable configurations, allowing teams to quickly close an alert. This can also be used in conjunction with a SOAR tool to verify configurations.
For example, on hosts tagged as brute forcers by GreyNoise, it’s a fast step to see if there was a successful login from that IP. If there is, then panic is justified… but the most likely case is that there is no successful login and the alert can be closed without ever having to alert someone.