Full Report
Introduction Hi there! I’m one of the researchers at Greynoise. While on the main blog I try to write formally, expect my blog posts in the Grimoire to be a little more off the cuff. Over the course of our work, we get a lot of fresh, famous and common vulnerabilities tagged thanks to a combination of security news, vendor updates, CISA KEV updates, and private collaboration with security researchers and vendors. These methods are excellent for writing up-to-date tags for the most relevant security vulnerabilities, but what happens when someone is trying older or more rare vulnerabilities? Or if someone is trying an exploit with no public documentation? In those cases, we have to do a little digging ourselves. In this blog post, I’ll pull the curtain back a little bit on how we find and tag on less popular internet traffic. There’s gold in them there hills As of this blog post, we’ve got thousands of sensors emulating a huge number of different appliances, servers and other pieces of internet-connected software. There’s a lot to go through! I’m going to let you in on a little secret: sometimes, when I’m bored, I like to take a lucky dip into the sensor logs, turn my front end to full-screen mode, and pretend I’m reading the source code in The Matrix: Blonde, red dress, attacking Fortinet. When I want to be a little more productive, though, we’ve got a tool for that that we’re using internally pending a public release: Sift. (psssst, we have a preview edition of Sift that shows items older than 1 week that you can play with here) Sift looks through the logs sent by our sensors, looks for anything weird, then makes a report about the weird thing it found so we can tag it. If we’re panning for gold, then Sift is the pan after you’ve run the rocks and dirt through a screen. Let’s look at Sift and make a tag from it! Here, we can immediately see a few key items: The payload itself The confidence level that this payload is what the heading says it is (the headings are automated) Any existing tags that match that payload It’s helpful to have a lot of side information included on these pages. For example, the “existing tags” links have saved me a LOT of time doing research on something that is ultimately already tagged. Usually, though, I focus on the HTTP payload. The game has now changed from “find strange traffic for something we haven’t tagged yet” to “here is strange traffic that we haven’t tagged yet. What is it doing?” What the dog doing? There’s more than one way to figure this out, but I’ll just start with the easiest: a search that contains parts of the path being exploited. I put the URL in quotes and then search for it. I use Kagi for my searches, so your results may look different if you use something like Google or DuckDuckGo, but not dramatically different. From there, I start digging. Eventually, when looking through the proof of concept code, firewall log pages and git repos, you’ll get a feel for what the vulnerability is. In this case, it’s CVE-2006-2529. Oooh, this vulnerability was released in 2006, meaning it’s been knocking around since everybody was playing Guitar Hero 2 and trying to get a PERFECT SCORE on Freebird. Neat! After working backward to find the CVE from the path, I then work forward to find proof of concept code for the CVE. This is good to confirm my findings and also to reference the proof of concept when we make an eventual tag in case the CVE page doesn’t have valid references, or if the vulnerability in question does not have a CVE associated with it. After a bit of finagling, I found this! …Or I can just read comments from my coworkers telling me what they’ve found :) From there, it’s just a matter of writing out the tag. That’s a bit of secret sauce, but the end result looks nice: Lather, rinse, repeat with each vulnerability we find in Sift, and the result is a tag database that not only shows the latest and greatest celebrity hacks, but also the old and obscure vulnerabilities that are still floating around in the wild. Oh, and keep your eyes peeled in April for news about Sift. 👀
Analysis Summary
# Tool/Technique: Sift (GreyNoise Internal Tool)
## Overview
Sift is an internal tool developed by GreyNoise used to analyze sensor logs for unusual or untagged internet traffic, especially concerning older or less popular vulnerabilities or exploits with no public documentation. Its purpose is to help researchers identify, investigate, and subsequently create metadata tags for these lesser-known threats found across GreyNoise's sensor network.
## Technical Details
- Type: Tool
- Platform: Internal to GreyNoise (operates by processing sensor logs from various emulated appliances/servers)
- Capabilities: Ingests sensor logs, identifies "weird" activity, generates reports, and provides key data points like the HTTP payload, confidence level of the automated heading, and existing matching tags.
- First Seen: N/A (Internal tool, public news pending April release mentioned)
## MITRE ATT&CK Mapping
*No direct mapping provided as the focus is on a detection/analysis tool, not an adversary TTP itself. However, the output of its findings often maps to the following:*
- TA0001 - Initial Access
- T1190 - Exploit Public-Facing Application
## Functionality
### Core Capabilities
- **Log Analysis:** Scans data collected by thousands of sensors emulating various internet-connected software and appliances.
- **Anomaly Detection:** Identifies traffic patterns that appear "weird" or warrant further investigation.
- **Payload Extraction:** Displays the raw HTTP payload associated with suspicious traffic.
- **Metadata Correlation:** Shows confidence levels of automated classification and existing tags associated with the observed payload.
- **Vulnerability Discovery Pipeline:** Facilitates the workflow for moving from suspicious traffic to confirmed vulnerability identification (often by searching for parts of the exploit path).
### Advanced Features
- **Historical Analysis:** A preview edition allows users to examine data older than one week.
- **Research Aid:** Helps researchers confirm findings by providing references (or facilitating the search for PoC code) related to discovered exploits, even when CISA KEV or public documentation is sparse.
## Indicators of Compromise
- File Hashes: N/A (Tool focuses on network traffic analysis)
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: The tool isolates exploitable paths (e.g., parts of URLs related to an exploit) which, once investigated, can lead to known IOCs for specific vulnerabilities.
- Behavioral Indicators: Unusual HTTP payloads targeting services or applications.
## Associated Threat Actors
- N/A (Tool is used for *defensive* detection and tagging of widespread scanning/exploitation attempts, including those from unknown actors or legacy exploit attempts.)
## Detection Methods
- The use of Sift itself *is* a detection method—it surfaces potentially malicious or weak traffic that might otherwise be missed by signature-based systems focusing only on high-profile threats.
- Specific vulnerabilities identified through Sift (like CVE-2006-2529) would then be detectable via network monitoring or intrusion detection systems looking for matching payloads.
## Mitigation Strategies
- Continuous monitoring using internal tools like Sift to track both trending and legacy exploitation attempts.
- Regular patching based on inputs from vulnerability research derived from tools like Sift.
## Related Tools/Techniques
- **GreyNoise Tags:** The output of the Sift process results in GreyNoise Tags (e.g., `fckeditor-cve-2006-2529-file-upload-scanning`).
- **Vulnerability Scanning:** The methodology complements traditional vulnerability scanning by focusing on active exploitation attempts observed in the wild.