Whether you’re working with netflow data collected from your own devices, flow logs from a cloud provider, or purchasing data from netflow providers, you may find it challenging to get immediate value out of it. Not only is there a vast amount of data to hunt through, but it can be challenging to fully understand what is happening based on netflow logs alone. While there are plenty of benefits to collecting and analyzing flow data, these challenges can make it difficult to use the data day-to-day to support investigations.
In order to start using netflow effectively in an investigation, it’s important to have a good understanding of the network and an established baseline of activity. This makes it easier to distinguish between normal traffic on the network and anomalous traffic that should trigger alerts to your team. Beyond defining these baselines, netflow data often needs to be correlated with additional sources such as alerts from the firewall and threat intelligence data to better understand particular flows and further establish patterns and relationships in the connections.
Even with these baselines defined and alerts being created using correlated data, oftentimes users still need to hunt though a massive amount of flow data to identify malicious activity that might have been missed. Outside of looking at deviations from a baseline it can be challenging to determine where to start investigating.
This is where GreyNoise can help! Filtering opportunistic and mass scan activity with data gathered from GreyNoise’s sensor network fast-forwards the process, allowing analysts and threat hunters to identify suspicious activity and find targeted threats that might have been missed by other detections . GreyNoise also provides information on infrastructure used by common business services, which can be used to filter egress netflow traffic and hunt for malicious activity leaving the network.
Taking this one step further, let’s look at organizations purchasing commercial netflow data from different sources. Oftentimes these groups combine this data with internet scanning services like Censys or Shodan in order to identify C2 beacons. While taking a proactive approach like this can help identify infrastructure and compromised systems earlier, there is still a lot of data to sift through. Instead, let’s use GreyNoise as a first pass filter to remove IP addresses that are saturating these sources and focus the investigation to find the signal in the noise.
While the volume of data may present a challenge, flow data also does not always contain all of the necessary information needed to act on. Oftentimes this data needs to be correlated with other sources of data to have a true understanding of the activity observed. Using VPC flow logs as an example, instead of just filtering out the noise, users may also want to identify malicious IP addresses accessing their assets. In this case, enriching the data with GreyNoise provides insight into how these IPs operate and highlights access attempts that may violate defined policies.
Netflow data provides a solid option for understanding who is doing what on the network but comes with an operational challenge based on the volume of traffic and the lack of details in the data. In order to address these challenges:
GreyNoise doesn’t have much common need for detailed firmware analysis. If it’s happening on the internet, we already see it. However, when we do need to investigate vulnerabilities in embedded devices, things can get very complicated, very quickly if no information is publicly available. It can be fun and insightful to learn these skills in the rare case we need them.
In late October 2022, we became aware of CVE-2022-41140, a buffer overflow and remote code execution vulnerability in D-Link routers, which D-Link had been notified of on February 17th. Noting the months-long turnaround time, we decided this was a good chance to perform a learning and discovery exercise.
On March 13th, 2023 we became aware of CVE-2023-24762, a command injection vulnerability in D-Link DIR-867 devices. This recent CVE spurred us to share some of our internal documentation regarding a research spike into D-Link devices.
This blog aims to explain the process of gaining a foothold in firmware or a physical device for vulnerability research and achieving a debuggable interface. While existing Proof-Of-Concept code for (yet another) D-Link vulnerability CVE-2022-1262 is utilized within this document, as well as strong hints at suspect areas of code, don’t expect to find any new ready-to-fire exploits buried in the contents below.
D-Link was notified of CVE-2022-41140, a buffer overflow vulnerability on February 17th, 2022. By November 15th, 2022, no additional information was available, which sparked an investigation into discovering available hints about the nature of the vulnerability. While this accurately speaks to the current state of public vulnerability tracking, we start off our investigation with a simple search on Google for the CVE and find two relevant links:
While the Zero Day Initiative lists the vulnerability as
(…) flaw exists within the lighttpd service, which listens on TCP port 80 by default. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer.
the D-Link Technical Support page provides more detailed information
(…) a 3rd party security research team reported Buffer Overflow & RCE vulnerabilities in the Lighttpd software library utilized in DIR-867, DIR-878, and DIR-882/DIR-882-US router firmware.
A stack-based buffer overflow in the prog.cgi binary in D-Link DIR-867. A crafted HTTP request can cause the program to use strcat() to create a overly long string on a 512-byte stack buffer. Authentication is not required to exploit this vulnerability.
Additionally, the D-Link support page provides a table of the Affected Models
From this information, we can derive that the vulnerability is triggered by an HTTP request to TCP port 80, which will hit the lighttpd service and route to the prog.cgi binary resulting in an overflow on a 512-byte stack buffer.
We can also derive that the vulnerability can be patched/mitigated on some hardware models, but not others.
The D-Link support pages provide links to download firmware images for the DIR-878, including base firmware versions like v1.30B08 as well as security advisement firmware versions like v1.30B08 Hotfix_04b.
Knowing that we can access the firmware images before/after the security patch for CVE-2022-41140, we will attempt the following steps:
We start by downloading a known vulnerable version of the firmware for a model that also offers a patched version. We download DIR-878_REVA_FIRMWARE_v1.30B08.zip and extract the firmware image DIR_878_FW1.30B08.bin.
We run the file command to quickly determine if it’s a commonly known file type. Unfortunately, this returns generic information.
Next, we use a more specialized tool, binwalk, which assists in searching binary images for embedded files and executable code. Again, this produces no results.
A handy feature of binwalk is the -E, --entropy command line flags, which allow you to measure the entropy or “randomness” of a file.
As an example, here is an entropy graph of 1024 bytes of Lorem ipsum:
And here is an entropy graph of DIR_878_FW1.30B08.bin
As you can see, the entropy of our firmware image is very high. Typically, this is indicative that a file is in a compressed archive format or is encrypted. Since neither file nor binwalk identified it as a compressed archive format, it’s reasonable to assume that it may be encrypted.
If you believe a file is encrypted, it’s always a good idea to take a peek at the bytes at the start of the file, just in case there’s an identifiable file header:
At the start of the file is a 4-byte sequence that maps to the ASCII characters “SHRS”.
A quick Google search for “SHRS firmware” turns up relevant results, indicating that we’re on the right track.
After a bit of reading, we can determine that D-Link does indeed encrypt some of their firmware, which is identifiable by the “SHRS” header. The blogs linked above go into depth on how they obtained a copy of the imgdecrypt binary and reverse engineer the binary to determine how to decrypt the firmware and produce the relevant python script.
Since we will be dealing with encryption again later in this blog, we won't go into depth on this specific layer of encryption. Our firmware can be decrypted with:
Taking our decrypted firmware and running it through binwalk again we can see that some file signatures are recognized.
Since file signatures were recognized, we can recursively extract them by using the -e, --extract, and -M, --matryoshka, command line flags.
This creates nested folders for each extracted layer of the file, ultimately resulting in a cpio-root folder containing the root filesystem for the firmware.
The desired prog.cgi file is located exactly where those familiar with *nix directory structures would expect it to be. However, for completeness, the file can be located by name using:
Now we have a copy of the entire root filesystem, including prog.cgi.
Repeating the same steps on the patched firmware sets us up for the next step.
In the previous step, we obtained an unpatched and patched copy of prog.cgi. We’ll rename them prog_old.cgi and prog_new.cgi, respectively, to help keep track.
BinDiff is a comparison tool for binary files, that assists vulnerability researchers and engineers to quickly find differences and similarities in disassembled code
For this blog, we’ll be using Binary Ninja with the BinDiff Viewer Plugin. There are roughly comparable free alternatives and plugins like Ghidra.
Following the relevant plugin steps to generate a bindiff, we open old/new and begin to look for functions that are very similar but not 1.00, indicating that a small change such as a patch may have been performed.
Using our list of similar (but not exact duplicate!) functions, we work our way down the list, looking for uses of strcat() that have changed between old/new. In this example, the main function:
Here we can see that the old binary used strcat() and the new binary has a different set of logic.
The strcat() function concatenates the destination string and the source string, and the result is stored in the destination string.
A quick check of the destination var_20c shows that its size is 0x200, or 512 bytes. For a sanity check, we can list all uses of strcat() throughout the binary.
There are 22 uses of strcat(). After reviewing them, none but the usage within main operate on a 512-byte buffer.
We now have a reasonable candidate for the location of the vulnerability.
Now that we have a reasonable candidate for a vulnerable code path, the next step is to start determining what conditions are required to actually reach the vulnerable code path. While wiser minds may be able to determine these conditions without needing a debugger, it’s always a safe bet to make getting a debugging interface a priority.
We want to run the necessary components and attach a debugging interface to a running program.
First, we need to determine the attributes of the file we would like to emulate. The file command we used earlier can be used to identify important information about the architecture the binary is meant to run on.
Using QEMU is an easy way to run binaries for other architectures, but with the same operating system as the current one. In this case, we want qemu-mipsel-static which is provided from the qemu-user-static package.
However, we need to know what to run.
There are init scripts that run when a system boots, and we can find the relevant one in /etc_ro/rcS:
It’s best to start at the top and work your way down and Google things where applicable.
/var/log folder is created if it doesn’t exist
Understanding the functionality of the init_system binary is elementary:
If init_system start is run, it checks for the presence of /var/run/nvramd.pid. If the pid file is not found, it enters a loop printing lighttpd: waiting for nvram_daemon. If the pid file is found, it branches into the following logic.
nvram is init then closed. sub_400e50 starts a number of .cgi binaries from /etc_ro/lighttpd/www/cgi-bin/, and finally the lighttpd web server is started with:
Using a combination of chroot and qemu-mipsel-static we can minimally and directly launch the lighttpd web service like so:
This results in an error of:
(network.c.747) SSL: Private key does not match the certificate public key, reason: error:02001002:system library:fopen:No such file or directory /var/private/lighttpd.pem
By simply commenting out the SSL related lines in /etc_ro/lighttpd/lighttpd.conf config file, we can just run the web service in HTTP mode exclusively and bypass the error.
Upon further review of the config, we can observe that the lighttpd web service is running in fastcgi mode and HTTP requests to the path /HNAP1/ are routed to be handled by prog.cgi.
If we navigate to our emulated system in a web browser, we can see that a page is loaded, and numerous UI assets load successfully, but the page is blank due to a malformed XML response from the /HNAP1 endpoint.
The root cause of the malformed XML response is due to the default values for nvram not being set. I spent a large amount of time trying to fix this by using LD_PRELOAD tricks and eventually ended up ordering a physical DIR-867 model (guaranteed vulnerable, no patch available) in frustration.
By the time the physical router was about to be delivered, I had a mostly working proxy for calls to functions from libnvram-0.9.28.so, at which point I remembered that the vulnerability was Pre-Authentication. I was trying to fix something that was part of the login flow which, I thought, was necessary.
After taking a bit of time to find a different endpoint to sanity check myself, I found that most of the other pre-auth functions of prog.cgi respond without issue. They are missing default values which would have been stored in nvram, but do not result in errors.
For our purposes, this is enough to work with and proceed forward. Getting a debugger attached by invoking prog.cgi in QEMU with the -g flag starts a GDB connection on port 1234.
As stated earlier, I purchased a used physical model DIR-867 router, which is guaranteed to be vulnerable as no patches are available.
After opening the box, I began the setup process and set a device admin password of Password1 and set updates to “manual”.
After completing the setup steps, the router reboots.
Most importantly, I figured out how to reset the router using the button on the back and re-do the setup steps again to make sure nothing that I’d set so far has persisted across a reset.
Now that the router is set up in its most basic state, I do a quick scan for open ports.
Much to my chagrin, there is no 23/tcp open telnet result, despite the telnetd service appearing in the /etc_ro/rcS init scripts I’d found during emulation. I’ll need to find another way to get an interactive interface on the router to run a debugger.
At this point, physically opening the router up and trying to find a UART interface would probably be the quickest path to success. However, as I wasn’t in any particular rush, I decided to try to figure out how to just re-enable the telnet interface since I know from extracting the firmware that the telnetd binary already exists in the firmware.
Running a recursive grep on our extracted firmware shows that “telnet” shows up in many binary files, as well as what appears to be factory and default settings shipped with the device.
Note the telnetEnabled=0. This probably explains why telnet isn’t running. It also seems to indicate that it’s a setting.
While poking around earlier looking for command injection, I located the “System” menu, which allows exporting/importing settings. If we’re lucky, telnetEnabled is a hidden setting we can just flip on and re-import.
Clicking “Save Settings To Local Hard Drive” results in downloading a 5.9kB config.bin file.
We use binwalk to check for known file formats.
It looks like we have a SEAMA firmware header and the config is encrypted. Again, we turn to Google and search for the starting bytes of the file 0x5EA3A417 which returns a very useful C header file that defines the structure of a SEAMA file.
In the same folder on GitHub there’s a corresponding .c file for a command line tool to unpack a SEAMA file, but a quick review does not show any usage of OpenSSL. This likely means D-Link is doing some additional layer of encryption on top of SEAMA, and we’re better off doing some more static analysis on the firmware itself and using the GitHub repo for sanity checking ourselves.
Re-Opening prog.cgi in Binary Ninja and searching for usages of the string “config.bin” we see that it’s used in a single section of code at sub_42ad78.
Taking a closer look at sub_42ad78 we see the following flow graph:
At a high level:
Taking a closer look at the call with mkconfig:
snprintf(&var_14c, 0x100, "mkconfig -a enca -m %s -i %s -o %s", &var_18c, "/var/backup_tmp.tar.gz", "/var/backup.tar.gz", 0x4f1530)
This results in &var_14c containing mkconfig -a enca -m DIR-867_A1 -i /var/backup_tmp.tar.gz -o /var/backup.tar.gz
Now that we know the command being run to generate the encrypted config.bin, we take a look at /bin/mkconfig to determine what those flags do. We can just run it in QEMU without any arguments to view the help message.
As the description states, it can encapsulate or de-encapsulate a config. However, it’s unclear where the suspected presence of encryption comes into play. A reasonable assumption from looking at the available flags indicates that the -m flag may be used in some sort of key derivation function. Remember that the -m flag is the model_name and hw_version. If the model and hardware version are used for a key derivation function, this would prevent someone from uploading a config from a different D-Link router model and potentially breaking their device.
We can confirm this by taking a peek at the enca function of mkconfig in Binary Ninja:
Indeed, we see the usage of openssl as well as a new, but fully expected binary seama.
In the first relevant part of the program flow, the -m flag (DIR-867_A1) is used in sub_400e30
Then the logic enters a loop that writes the MD5 hash as a hex string to &buffer
The OpenSSL command is as follows:
If we had preferred not to disassemble the function to figure out how the encryption key was generated, we could have simply added the -E "QEMU_STRACE=1" flag when running mkconfig and the resulting key would have shown in the strace output.
Command:
qemu-mipsel-static -E "QEMU_STRACE=1" /bin/sh -c "mkconfig -a de-enca -m DIR-867_A1 -i config.bin -o config.dec"
Strace output:
39 execve("/bin/sh",{"sh","-c","openssl enc -e -aes-256-ecb -k 81F9A6E40BDEC26DB67FE53A555D0E8E -in config.dec -out config.dec.enc >/dev/null 2>&1",NULL})
As expected, 81F9A6E40BDEC26DB67FE53A555D0E8E is the hex string representation of the MD5 hash of “DIR-867_A1”.
Knowing this is true, we can make a simple shell script to recreate this logic and patch in Telnet support:
The result being telnetpatched.bin, which should be a valid settings file for us to upload and enable telnet.
Indeed, another nmap scan shows the desired results of an open telnet port.
Unfortunately, when trying to connect, we are instantly prompted for authentication.
After a quick peek at the disassembly of prog.cgi, we can see that the password is set to the value we provided originally, Password1 + @twsz2018
A guess that the username is admin allows us to log in successfully with a password of Password1@twsz2018
While we have successfully logged in over telnet, we are dropped into a limited shell with only a select number of commands available to run. We cannot directly use this shell to load a gdb server and attach it to prog.cgi.
Here we will cheat a bit and leverage CVE-2022-1262, a command injection vulnerability in the protest binary that is available to us in the limited shell. Using the Proof-Of-Concept exploit included in this writeup from Tenable, we spawn another telnetd instance running on port 1337 and running as root.
From here, we can get a hint about the version of Linux headers the firmware was built with by running:
Finally, we can either cross-compile a mips32el uclibc GDB server against Linux headers 3.10.14+ ourselves by using something like crosstool-NG … or we can download a pre-built toolchain matching our criteria from https://toolchains.bootlin.com/
This allows us to transfer a gdb server to /tmp on the physical router and attach gdb to prog.cgi for remote debugging purposes.
Learning how to gain a debuggable interface with both emulated and real D-Link devices is a valuable skill for anyone interested in vulnerability research and network security. By using emulated devices, you can experiment and test in a safe environment before attempting changes to real hardware. The ability to debug real devices can help you identify and fix issues, as well as determine how firmware operates “in the real world”. While it may seem daunting at first, with the right tools and resources, anyone can learn these skills. With this knowledge, you can enhance your understanding of network security and device development, and apply these concepts to future projects, such as writing network signatures for malicious traffic.
GreyNoise tags for command injection CVE-2023-24762 and stack-based buffer overflow CVE-2022-41140 are live and available to all users for tracking related activity:
To ensure we have as much visibility into activity on the internet as possible, we regularly deploy new sensors in different “geographical” network locations. We’ve selected two sensors for a short “week in the life” series to give practitioners a glimpse into what activity new internet nodes see. This series should help organizations understand the opportunistic and random activity that awaits newly deployed services, plus help folks understand just how little time you have to ensure internet-facing systems are made safe and resilient.
We initially took a look at what the sources of "benign" traffic are slinging your way. Today, we're going to look at the opposite end of the spectrum. We stripped away all the benign sources from the same dataset and focused on incoming tagged traffic from malicious or unknown sources. After all, these detection rules are the heart and soul of the GreyNoise platform, and are also what our customers and community members depend upon to keep their organizations safe.
If we hearken back to our previous episode, it took over an hour for even the best-of-the-best of the "benigns" to discover our freshly deployed nodes. This makes sense, since there aren't too many legitimate organizations conducting scans, and they do not have infinite resources. Sure, they could likely spare some change to scan more frequently, but they really don't need to.
In contrast, we tagged 8,697 incoming IP addresses in that first week, and the first packet of possible ill-intent appeared ten seconds after the nodes were fully armed and operational. However, the first tagged event — RDP Alternative Port Crawler — was seen three hours later. The difference between those two events lies in one of our core promises: our tags are 100% reliable. We don't just take every IP address hitting our unannounced sensor nodes and shove it into a list of indicators of compromise (IoCs).
The above chart is the raw, non-benign connection data to those sensors for that week. You're likely wondering what those spikes are. We did to!
Let's look at some summary data by tallies of:
The August 28th malicious traffic spike (for an hour) focused mainly on SMB exploits, and originated from the "Data Communication Business Group" autonomous system in Taiwan. It is odd that we saw so little other activity, and that the port volume was an order of magnitude less. There are any number of reasons for this. Given where these sensors are (which we're not disclosing), it could have been a day of deliberate country network isolation. Or, it could just mean that the botnet herders were super-focused on SMB.
Over the course of those seven days, non-benign nodes hit over thirteen-thousand ports, and you can likely guess which ones made the top of the list.
Port numbers associated with Telnet, RDP, SSH, and SMB were, by far, the most common.
Since we called out one autonomous system, we should be fair and call them all out.
These are very common autonomous systems to see in malicious attack logs. What should concern you, however, is that "high reputation" sources such as Linode, OVH SAS, Google LLC, and Microsoft Corporation are all in the visible treemap cells. Even if you don't consider them as high reputation sources, you cannot permanently block communication to/from them. These are all hosting providers, and we see other hosting providers with decent IP reputation also hosting malicious traffic sources. The hourly updated nature of our API-downloadable block lists, combined with the scheduled roll off of IP addresses when they stop sporting malicious activity after a while, means you can make your organization safe from these IPs while they are trying to do harm.
What you, and we, truly care about is the tagged, non-benign traffic.
Of the 115 identified tags, those associated with RDP, SMB, and MS SQL attacks topped the list, along with scrapers looking for useful information. If you still haven't removed RDP from your perimeter, please stop reading and take the opportunity to do so now.
Head on over to the Observable notebook that houses all these charts and data for a more interactive version of the chart and data tables.
You can see the aforementioned yellow SMBv1 Crawler August 28th spike right after "12 PM".
When you deploy a new internet-facing system, you have only seconds until unwanted traffic comes knocking on your door. After that, there's a constant drumbeat, and sometimes even an entire off-key orchestra, of unsought after:
You can sign up for a GreyNoise account to start exploring the tags and networks identified in this post, and check out some of our freshly minted new features such as IP Similarity — which lets you hunt for bad actors exhibiting behavior similar to ones we've tagged — and, IP Timeline — where you can see what sources have been up to, and how their behavior has changed over time.
Yesterday, our founder & CEO, Andrew Morris, got to join Ed Bailey from Cribl for a live stream conversation discussing how to help SOC analysts overcome common struggles and improve security detections. Over the years, we’ve built a great relationship with Cribl and truly believe in our “Better Together” message. The Cribl + GreyNoise integration is available now, so if you want to learn more about it, let us know.
During the conversation, Andrew mentions our new product features. We put out a series of blogs and a press release last week if you want to learn more.
You can feel Andrew’s excitement when Ed poses this question. Here is how Andrew broke it down:
In addition, Ed explains that 30% of your detections are things that just don’t matter. With better data & context (like GreyNoise) you can finally ignore the noise. This prevents wasting hours and hours analyzing alerts and events that don’t matter.
Some security teams are left with a problem of determining which logs matter. Or that storing logs or processing data is all or nothing. Those with years of experience in the SOC know this isn’t true. Not only do different event types have different analytical value, but also logs from certain places matter more than others. So, how do you scale this knowledge?
So what does GreyNoise do? We help our customers understand the alerts and events that DON’T matter. It’s kind of the opposite of a typical threat intel feed. By eliminating the noise you can focus on what really matters.
Big thanks to Ed Bailey and the Cribl team for letting us join. Hopefully you found this information interesting and insightful. If you want to learn more about our Cribl integration, contact us.
Giving back to the cyber security community will always be a key part of the GreyNoise mission, so our free plan isn’t going anywhere.
But there are a lot of benefits to a paid plan that may not be immediately obvious (benefits other than subsidizing Andrew’s tweets). Let’s dig into the top 7 reasons you should upgrade, and when a paid plan might not be a good fit for you.
The most obvious reason for a user to upgrade from free to paid is the expanded Search limits. Search is at the core of our product, it’s the first thing users see when they land on our visualizer and the primary way most users interact with GreyNoise. Asking GreyNoise for data on an IP, a CVE, a tag, or a trend all counts as a Search.
The Free limits are designed for hobbyists, independent users, or for someone who is just starting to explore the GreyNoise ecosystem. They aren’t high enough to tap into automation or large scale data enrichment. So if you’re a team who wants to save time by throwing out all the hay to get to the needles faster, a paid plan will give you the volume you need.
In addition to Search, all paid customers get increased limits for alerts and dynamic blocklists - the other two features that make up the core of the GreyNoise product.
Alerts let you configure an email notification that will trigger anytime the response to a GreyNoise Query Language (GNQL) query changes. Use them to identify compromised devices on your network (or a vendor or third party supplier’s network), or get a heads up when attackers start exploiting a vulnerability in the wild.
Dynamic blocklists give you a full list of IPs associated with a GreyNoise tag. The list is updated hourly, and can be plugged directly into your next gen firewall to keep your perimeter safe. When the next Log4j happens, you can use a dynamic blocklist to buy your team needed time to patch.
The Community API has 1 endpoint, it takes an IP and returns a simple response with some basic information about that IP. Is the IP in the GreyNoise Noise or RIOT datasets? What is its classification? And a link to the visualizer.
For some teams this is enough. But for teams that are stretched thin and need comprehensive answers fast, rely on automation to make their lives easier, or want to run more complex queries (like pulling back a list of IPs tagged with a specific CVE) access to our Enterprise API is a must.
Our Enterprise API has 16 endpoints. Enterprise API users can:
.png)
We have 31 integrations that support using a Community API key. But these integrations are limited by what the Community API can return, so if you need full context on the IP (which most users do) you'll have to click into the Visualizer to get a full picture.
Full integrations and integration with some of the most popular security tools like Splunk, QRadar, LogStash, and Recorded Future are available to paid customers. You’ll also want the higher Search limits that come with our paid plans to maximize our integrations and automate more of your work.
While limited access to the core GreyNoise features will always be available to free users, there are a handful of features that are only available to Paid customers, with more being added this year. These features can be used for enhanced enrichment, threat hunting, and protecting your perimeter from mass exploitation.
Premium data fields like our IP Destination fields tell users even more about what an IP is doing on the internet, and open up new Search queries. IP Destination specifically tells users which countries our sensors observed an IP scanning, and let users narrow down their searches to geo-targeted traffic. All paid plans come with IP Destination.
Getting data out of the visualizer (or accessing full context in the API) is restricted to paying customers. You can export GNQL search results or analysis results to a CSV or JSON file.
IP Timeline lets security analysts and threat hunters look back at an IP’s behavior over time. Answer the question, “what was this IP doing 7 days ago?” Useful if you find an IP in your logs and want to know what it was doing the day it hit your system.
IP Similarity helps users identify potential actors and infrastructure associated with an IP you’re investigating. All users can see how many IPs GreyNoise has identified as similar to a given IP, but only paying customers can access the list of similar IPs and a breakdown of the factors that determine similarity.
Feeds are a useful way to enrich your existing data without blowing up your Search limit, or to narrow down a search into a big dataset.
Paying customers get direct access to our Customer Success team who have a deep knowledge of the GreyNoise product, integrations, and customer use cases. While we will always do our best to support all of our users, our Customer Success team goes above and beyond for our customers with onboarding, training sessions, and quarterly check-ins.
One of the most important benefits of a paid plan is convenience, and our best customers get this. You’re strapped for time. You’re trying to keep up with changing tactics from the bad guys, training and hiring good analysts, and the latest demands from the rest of your org. Any time you can save has real value.
GreyNoise has proven time and time again that we save our paying customers time, and generate a pretty significant ROI.
There’s a lot of value unlocked when you move from a Free GreyNoise account to one of our paid plans. You probably want to upgrade if you fit into one or more of these buckets.
A GreyNoise paid plan isn’t necessary for everyone, we get that. Don’t worry about a paid plan right now if you fit into one of these buckets:
Look, if you’re a team of 1 or 2 analysts, and you can easily handle all of the perimeter-related alerts in your SIEM then you’re probably not going to get a ton of benefit from a GreyNoise subscription right now. You can always create a free account, and use it as needed when you have questions about a strange IP or hot, new CVE.
If most or all of your security program is managed by MSSP/MDR partners, they can leverage GreyNoise on your behalf to provide you a better service more cost-efficiently. Some of our rockstar MSSP/MDR partners include:
If you’re a student, academic, or an independent researcher using GreyNoise for non-commercial purposes then you may actually qualify for our VIP program. VIP users get access to all of the same features and benefits as paying customers, at no cost.
In the end it’s up to you. GreyNoise isn’t going to be a good fit for everyone, and that’s okay. You can always use GreyNoise for free, and reach out later when your security team has grown. But if these benefits resonated with you, then consider reaching out to our sales team. They’re here to help, not be pushy, and know a ton about GreyNoise.
.png)
When running across an unknown IP address in the logs, the first move might be to check the IP address’s reputation through a number of services. This check is useful for the immediate task at hand, but what if you could see not only reputation reports but see, at a granular level, when and what is causing this reputation? That’s where GreyNoise comes in.
Alongside the common fields of a GreyNoise IP address page’s located in the Visualizer (which include relevant DNS information, destination sites, and other data), GreyNoise now has a feature called the IP Timeline. The IP Timeline displays activity as seen by GreyNoise sensors of a particular IP Address over the past thirty days. Let’s take a look at an IP address and explore this tool further.
When an IP address is entered into the GreyNoise search box, if GreyNoise has observed scan activity from the IP, you will receive an IP Address page detailing data and related tags:
In this example (IP address 41.65.223.220), an opportunistic scanner appears to be crawling for SMBv1 endpoints and trying to brute force MSSQL servers.
Within the fields displayed are which ports this address scans, any associated fingerprints and what kinds of web requests the IP is known to make. In this case, GreyNoise does not have a lot of fingerprint and request data. So, how can we know for sure that this IP address is still active and malicious?
This is where the IP Timeline feature comes into play. Next to the summary of the IP address, there’s a tab labeled ‘timeline’. Let’s click that and see what we find:
Voila! The page has gone from an overview of the IP address to discrete data points showing when, exactly, GreyNoise has noticed activity. Consecutive days of the same activity are connected by a line.
Each data point GreyNoise has for the IP address is a field along the Y axis, and each day that GreyNoise notices it is the X axis. You can see respective fields and dates along the left and top sides of the graph. In this example, you can see that on the 1st of January there is SMBv1 crawling observed. Then, on the 2nd, there’s MSSQL brute force attempts. The SMBv1 crawling has an unknown intention so it’s listed as white, while the MSSQL brute force attempts are highlighted in red as they are tagged as malicious activity.
This graph can be used for more than just a quick check on an IP address. For example: you are running an MSSQL server and found this IP address in your logs. Seeing somebody trying to brute force your server can be a nerve-wracking experience! However, by checking this graph you can see that this address attempts to brute force every 8 days on the dot, implying an automated process. That’s still not great, but it’s less scary than a concerted human effort. From there, you could make the call to block at the firewall or you could make sure your passwords aren’t on any well-known word lists and continue to observe the IP address.
Additionally, if you are looking for behavior patterns on an IP address, this graph could come in handy. In this example, we only see two cases where the IP address crawls SMBv1 and then attempts to brute force the next day but, if this was a consistent pattern, this may be indicative of a pattern used when deciding which hosts to try and brute force. You could then use that information to pivot into checking your SMB logs for anything suspicious.
GreyNoise is always looking for new ways to bring as much value as possible. IP Timeline data is only one part of a much bigger ecosystem you can integrate into your processes and investigations. Try it out yourself by signing up for our *enterprise trial or contact us to schedule a more in depth demo.
(*Create a free GreyNoise account to begin your enterprise trial. Activation button is on your Account Plan Details page.)
.png)
While we at GreyNoise have been collecting, analyzing, and labeling internet background noise, we have come to identify patterns among scanners and background noise traffic. Often we’ll see a group of IPs that have the same User-Agent or are sending payloads to the same web path, even though they are coming from different geo-locations. Or, we might see a group that uses the same OS and scanned all the same ports, but they have different rDNS lookups. Or any other combination of very similar behaviors with slight differences that show some version of distributed or obfuscated coordination.
With our new IP Similarity feature, we hope to enable anyone to easily sniff out these groups without having an analyst pore over all the raw data to find combinations of similar and dissimilar information. Stay tuned for an in-depth blog covering how we made this unique capability a reality, but for now, here’s a quick snapshot of what the feature does and the use cases it addresses.
GreyNoise has a very rich dataset with a ton of features. For IP Similarity we are using a combination of relatively static IP-centric features, things we can derive just from knowing what IP the traffic is coming from or their connection metadata, and more dynamic behavioral features, things we see inside the traffic from that IP. These features are:
IP Centric
Behavioral
Of note, for this analysis we do not use GreyNoise-defined Tags, Actors, or Malicious/Benign/Unknown status, as these would bias our results based on our own derived information.
The output of the IP Similarity feature has been pretty phenomenal, which is why we’re so excited to preview it.
We can take a single IP from our friends at Shodan.io, https://viz.greynoise.io/ip-similarity/89.248.172.16, and return 19 (at the time of writing) other IPs from Shodan,
And we can compare the IPs side by side to find out why they were scored as similar.
While we have an Actor tag for Shodan which allows us to see that all of these are correct, IP Similarity would have picked these out even if they were not tagged by GreyNoise.
As with any machine learning application, the results of IP Similarity will need to be verified by an aware observer, but this new feature holds a lot of promise for allowing GreyNoise users to automatically find new and interesting things related to their investigations. In fact, we see some immediate use cases for IP Similarity to help accelerate and close investigations faster, with increased accuracy, and provide required justifications before acting on the intelligence. For example:
For more on how you can use IP similarity in your investigations, check out our recent blog from Nick Roy covering use cases of IP similarity. You can also read more about IP similarity in our documentation. IP Similarity is available as an add on to our paid GreyNoise packages and to all VIP users. If you’re interested in testing these features, sign up for a free trial account today!*
(*Create a free GreyNoise account to begin your enterprise trial. Activation button is on your Account Plan Details page.)
.png)
Our friends over at Elastic published a great piece on how to set up Distributed Alerting with Elastic Stack - and gave a shout out to us! As big proponents of SOC efficiency and sleep-filled nights for Incident Response teams, using GreyNoise data in your process with Elastic Stack and Tines can (1) prevent false positive alerts from ever reaching your SOC teams and (2) help provide additional context when you do receive an alert.
Our sensors are placed around the world to passively capture network traffic and give you details on what IPs are scanning the internet on a daily basis. We then tag the behavior we’re seeing with additional details and deliver that context to our users to help you understand what traffic is benign and what traffic is attempting to exploit everyone (or just you).
Beyond our Noise dataset as described above, we also provide data on common Internet services (Google DNS, Apple, CDNs, etc.), known as RIOT.
By adding GreyNoise data (Noise and/or RIOT) into your Distributed Alerting workflow, we can help enrich logs with full context data on IPs seen by our sensors. As our friends at Tines highlighted, “Simply put, if an IP is classified in RIOT and has a trustworthy confidence level, the impact of the alert is very likely to be minimal, and it can be set as a low priority or closed immediately. Suppose the IP has a somewhat trustworthy confidence level. In that case, the priority could be raised, and/or additional risk factors could be added in to arrive at a confident automated determination of the status of the alert before any analyst review.”
GreyNoise has both Elastic and Tines integrations available to our paid users, which we’re happy to demonstrate further. Whether you’re trying to tune your alerting system or digging deeper in an investigation, we hope you check out our data further.
Start an enterprise Trial today.*
(*Create a free GreyNoise account to begin your enterprise trial. Activation button is on your Account Plan Details page.)
Microsoft’s Patch Tuesday (Valentine’s Edition) released information on four remote code execution vulnerabilities in Microsoft Exchange, impacting the following versions:
Attackers must have functional authentication to attempt exploitation. If they are successful, they may be able to execute code on the Exchange server as SYSTEM, a mighty Windows account.
Exchange remote code execution vulnerabilities have a bit of a pattern in their history. This history is notable due to authentication being a requirement for exploitation of these newly announced vulnerabilities.
CVE-2023-21529, CVE-2023-21706, and CVE-2023-21707 have similarities to CVE-2022-41082 due to them all requiring authentication to achieve remote code execution, which GreyNoise covered back in September 2022. Readers may know those previous September 2022 vulnerabilities under the “ProxyNotShell” moniker, since an accompanying Server-Side Request Forgery (SSRF) vulnerability was leveraged to bypass the authentication constraint. “As per our last email” we noted this historical pattern of Exchange exploitation in prior blogs as well as tracked recent related activity under the Exchange ProxyNotShell Vuln Check tag which sees regular activity.
Shadowserver, a nonprofit organization which proactively scans the internet and notifies organizations and regional emergency response centers of outstanding exposed vulnerabilities, noted that there were over 87,000 Exchange instances vulnerable to CVE-2023-21529 (the most likely vulnerability entry point of the four new weaknesses).
As of the publishing date of this post, there are no known, public proof-of-concept exploits for these new Exchange vulnerabilities. Unless attackers are attempting to bypass web application firewall signatures that protect against the previous server-side request forgery (SSRF) weakness, it is unlikely we will see any attempts to mass exploit these new weaknesses any time soon. Furthermore, determined attackers have been more stealthy when it comes to attacking self-hosted Exchange servers, amassing solid IP address and domain inventories of these systems, and retargeting them directly for new campaigns.
GreyNoise does not have a tag for any of the four, new Exchange vulnerabilities but is continuing to watch for emergent proof-of-concept code and monitoring activity across the multi-thousand node sensor network for anomalous Exchange exploitation. Specifically, we are keeping a keen eye on any activity related to a SSRF bypass or Exchange credential brute-force meant to meet the authentication constraints needed by an attacker to leverage these vulnerabilities.
GreyNoise researchers will update this post if and when new information becomes available.
Given the likely targeted nature of new, malicious Exchange exploit campaigns, you may be interested in how GreyNoise can help you identify targeted attacks, so you can focus on what matters to your organization.
Don’t have a GreyNoise account? Sign-up for a free account.
One of the things that I was really excited about when I joined GreyNoise was the amount of data gathered by our sensor network and how it could be used in other ways outside of the traditional SOC efficiency use case. I spend a lot of time working with GreyNoise data, and inevitably, finding some thread to pull at that leads me down a rabbit hole. Our sensors see hosts that are scanning for known CVEs and misconfigurations end everything in between, but with the introduction of IP Similarity, we’re now able to group IPs by how they are operating, providing intelligence on botnets or even infrastructure used by adversaries.
Prior to this feature, users would have to look through GreyNoise data and extract this manually. Now, using a combination of ports, requests, and fingerprint data the new IP similarity feature does the work for you. In preparation for a meeting the other day, I was looking through some of the ICS tags published on GreyNoise and reading up on the Tridium NiagraAX Fox ICS Scanner, which is always interesting to look at who’s scanning for it, as well as the results on Shodan/Censys since they typically provide details about the building they are located in.
Digging into the results, there were a couple of IPs that stood out immediately, especially the ones that were classified as unknown. If you’re not familiar with GreyNoise, these are IPs that we’ve observed scanning the internet but haven’t seen any malicious activity from. There were a number of IPs that were scanning for ICS tags, and several in particular seemed to be opportunistically scanning for really any kind of SCADA device exposed to the internet. In this case, there is a JA3 fingerprint that we can pivot on, but the hash 19e29534fd49dd27d09234e639c4057e returns over 7,000 results.
That’s still a lot of information to parse through, and we could use a combination of requests and tags, but by using IP similarity and filtering down to a confidence score of 95% or greater, we can quickly find 8 other IPs that have been active in the last month all performing similar reconnaissance. This now gives us a way to start further investigating infrastructure and better understand what these IPs are targeting.
Coming from the SOAR world, we were always looking for sources that could be used to make better decisions when automating responses or threat hunting. IP similarity now makes it even easier to identify common infrastructure and botnets in order to further hunt based on the data. It also makes it easy to create a blocklist since we know that these IPs have all recently had very similar scan behaviors.
I’m really excited about the different ways people are going to be using IP similarity and the benefits they will get from this new feature. Try IP Similarity for free with our enterprise trial** or contact us for a demo.
(**Create a free GreyNoise account to begin your enterprise trial. Activation button is on your Account Plan Details page.)
Figuring out if a security product is right for you is hard. Beyond the technical problem it solves, you have to make a business case for why those with purchasing power in your company should buy your favorite security tool vs. putting the money to another use. Most of the time, the rationale is “Gartner says it’s cool” or check out this testimonial that is definitely not from the company’s CEO’s cousin. We wanted to take a more data-based approach, which is the inspiration for creating our ROI calculator.
To do this, we surveyed our customers, the people that pay us real-life dollars to use GreyNoise, about how our products have been used in their day-to-day work. We asked about their company: how big it is, what sort of security team they have, what sort of work they do, and the number and average time of investigations. We also asked about GreyNoise’s impact, how often it is helpful in an investigation/project, how much time it saves, threats found, IP coverage, efficiency gain, etc.
From aggregating this data and segmenting it by the size of the company and type of work, we’re able to use real customer insights to give you an expectation of what GreyNoise’s value to your company could be. We know you love GreyNoise, and we hope this proves helpful when advocating to get the tooling you need to do your job effectively!
Try our new ROI Calculator and see how much GreyNoise could save your organization.
Not yet familiar with GreyNoise? We collect, analyze and label data on IPs that scan the internet and saturate your security tools with noise. This unique perspective helps analysts spend less time on irrelevant or harmless activity and more time on targeted and emerging threats.Sign-up for our free plan to see for yourself!
How often do you find yourself asking “is this targeting me or just opportunistically exploiting parts of the internet?” Whether this has happened to you once or happens every single day, you probably spent too much time trying to figure out the answer. At GreyNoise we help our customers answer this question and many more. Here are the top 6 ways we can help threat hunters improve their investigations.
The GreyNoise Query Language (GNQL) is well documented, but you often want to query GreyNoise without knowing exactly what you are looking for. Using wildcard searches in conjunction with boolean logic lets you start with a broad search and then begin to remove items that aren’t interesting based on specific conditions. For example, starting with a search for the tag “RDP Alternative Port Crawler'' returns close to 8000 results. Or using the query cve:"CVE-2022-*" shows over 1600 IP addresses observed by GreyNoise.
When starting with a broad search, there can be a lot to unpack in the data, but that’s where the boolean operators can be added in. You can remove things like organizations or countries that you’re not interested in. Alternatively, you can filter out specific fields, including ports or IP’s classified as benign by GreyNoise. Using the RDP Alternative Port Crawler as an example, by removing a few noisy organizations and ports we can end up with some interesting results with a query like this:
tags:"RDP Alternative Port Crawler" NOT classification:benign NOT raw_data.scan.port:3389 NOT (metadata.asn:AS14061 OR metadata.organization:"Linode, LLC")
Sometimes, a user might have a particularly active IP address that they are researching, but not seeing any activity from the IP in GreyNoise. Even if there isn’t a match for a specific IP, users can query GreyNoise by ASN or organization. Digging through some web logs there was a particularly interesting IP address looking for exposed cryptominers. Although GreyNoise hadn’t seen this particular IP, querying based on the ASN provided some details on the type of activity observed from this specific organization. Nothing in the results jumps out as particularly malicious other than one host. Still, it can be helpful to understand where the scanning originates from, and how the hosting provider handles complaints, or how common it is to see their services abused.
Example query: metadata.asn:AS41608
JA3 is essentially a way to fingerprint SSL/TLS connections and the applications associated with them. Using these hashes we can start to better understand how an actor is operating and what tools they are using. As a quick example of using JA3 hashes with GreyNoise, let’s look for IP’s that are using bitsadmin as part of their toolkit. Using this GitHub repo https://github.com/marcusbakker/Miscellaneous/blob/master/ja3_hashes.csv we can start hunting using a few of the hashes in the repo:
2c14bfb3f8a2067fbc88d8345e9f97f3 OR 613e01474d42ebe48ef52dff6a20f079 OR 05af1f5ca1b87cc9cc9b25185115607d OR 8c4a22651d328568ec66382a84fc505f
Searching GreyNoise this way allows us to better understand the tools being used and can be useful for building out additional hosts to start pivoting to and collecting additional indicators for hunting.
Plus, without JA3 hashes how could we easily identify hosts looking for license.txt files across the internet? 1f24dbdea9cbd448a034e5d87c14168f
GreyNoise tags are built to identify the activity observed across sensors, but looking into the raw requests can provide some interesting insights into how these different actors are operating. One easy way to query GreyNoise is with the following:
base64 OR fromcharcode OR powershell OR "sh "
This looks for requests that are attempting to encode a command before executing it or just executing a command as part of an exploit or misconfiguration. This is also a quick way to find C2 servers that might be used as well as IP’s hosting second stage payloads. Typically it appears that most payloads are a variant of Mirai but there have been a number of interesting ones that have been discovered this way.
One of the fastest ways to get data from GreyNoise is using the GreyNoise CLI. This allows you to lookup an IP address or query GreyNoise using regular GNQL searches. While this data is easily accessible, combining it with a few other tools makes it easy to write some one liners to pull interesting data from GreyNoise based on tags or recently observed activity. A few of my favorites are below
1. If a tag is written for a vulnerable web application GreyNoise captures and displays the requests observed. As an example, using the tag for CVE-2022-26134 you can extract the first command to be executed, assuming the application is vulnerable. This can provide all kinds of interesting details from commands being run, to files being modified, and even finding second stage payloads being downloaded and executed.
2. These two are pretty similar and are designed to find requests or user agents from newly seen hosts across the GreyNoise sensors. A lot of this can be pretty typical paths that are seen but you can also find some interesting new paths that hosts are scanning for and find new tools based on user agents.
3. The stats option in the CLI provides a nice overview of the GreyNoise data. In this case I also want to look at activity that is not on traditional ports to get an idea of where it is originating from and what tags are associated with the activity. Some interesting modifiers to add are country codes, first/last seen time modifiers, or ASN’s.
When looking through the backend of GreyNoise one day I noticed that of the top 50 noisiest IPs looking for RDP exposed to the internet they had covered almost every one of the 65,535 possible open ports. Obviously there is plenty of incentive to find RDP exposed to the internet, but it was staggering to see how thorough the attempts to find it is.
GreyNoise can answer the question “Is this IP scanning just me or large portions of the internet,” but combining this information with other sources can provide fascinating details about IPs we might be seeing. Of the top 20 noisiest IPs 80% had one of these two banners returned on Shodan:
What was more interesting to see is that even though both of these versions of Windows have some vulnerabilities associated with them, several of them originated from the same provider. This might mean that they have a default image they deploy that is not being updated.
Whether you’re investigating interesting data in our own network or hunting beyond, we hope these tips are helpful on how to do the most with GreyNoise data. If you’re interested in learning more about our Threat Hunting features, check out our solutions page: Contextualized Threat Hunting with GreyNoise or contact us to get a demo.
Wow do I hate ESXi Threat Intel (right now)
UPDATE 2023-02-14: in response to an inquiry, GreyNoise researchers went back in time to see if there were exploit attempts closer to when CVE-2021-21974 was released.
From January 1st 2021 through June 1st 2021, 2 IP's were observed exploiting CVE-2021-21974, each active (as observed by GreyNoise sensors) for a single day.
In recent days CVE-2021-21974, a heap-overflow vulnerability in VMWare ESXi’s OpenSLP service has been prominently mentioned in the news in relation to a wave of ransomware effecting numerous organizations. The relationship between CVE-2021-21974 and the ransomware campaign may be blown out of proportion. We do not currently know what the initial access vector is, and it is possible it could be any of the vulnerabilities related to ESXi’s OpenSLP service.
The Security Community seems to be focusing on a single vulnerability. GreyNoise believes that CVE-2021-21974 makes sense as an initial access vector, but are not aware of any 1st party sources confirming that to be the case. We encourage defenders to remain vigilant and not accept every vendor at their word (including us).
The objective of the following document is to provide clarity to network defenders surrounding the ransomware campaign as it relates the the following items:
CVE-2021-21974 is a heap-overflow vulnerability in ESXi’s OpenSLP service.
CVE-2020-3992 is a use-after-free vulnerability in ESXi’s OpenSLP service.
CVE-2019-5544 is a heap overwrite vulnerability in ESXi’s OpenSLP service.
Back in October 2022, Juniper Networks wrote a blog regarding the potential usage of CVE-2019-5544 / CVE-2020-3992 as part of an exploitation campaign. Due to log retention on the compromised server they were unable to confidently attribute which specific vulnerability resulted in successful exploitation. Instead they focused their blog on the details of the backdoor that was installed post-exploitation.
On February 3rd, 2023 the cloud hosting provider OVH published a notice regarding an active ransomware campaign effecting many of their ESXi customers, hereafter referred to as “ESXiArgs” due to the ransomware creating files with an extension of .args. As part of their notice they provide the following quote:
According to experts from the ecosystem as well as authorities, the malware is probably using CVE-2021-21974 as compromission vector. Investigation are still ongoing to confirm those assumptions.
On February 6th, 2023 VMWare published a security blog acknowledging the “ESXiArgs” campaign and stated:
VMware has not found evidence that suggests an unknown vulnerability (0-day) is being used to propagate the ransomware used in these recent attacks.
In summary, while there are many 3rd party sources of intelligence directly attributing this ransomware campaign to CVE-2021-21974, the first party sources are not.
Tl;dr:
There are many companies that scan the internet with benign intentions for inventory, research, and actionable intelligence. GreyNoise sees these companies on a very regular basis, since we operate “sensors” similar to a honeypot. They scan, and we (GreyNoise) listen.
Without going into too much depth, there is a significant complexity jump between “determining if a port is open on a server” and “determining what protocol is operating on a port”.
For scanners, high interaction protocols such as those used by the ESXi OpenSLP service may be checked on a weekly/monthly basis, whereas more common protocols such as HTTP(s) on common ports like 80/443 may be checked nearly constantly.
Much like the variety of benign internet-wide scanning companies, GreyNoise is not the only organization operating honeypots on the internet. This causes biases in reported metrics of potentially vulnerable servers on the public internet.
Once an incident such as the ESXiArgs campaign has begun, “scanning” organizations will ramp up scanning, and “honeypot” organizations will ramp up honeypots. At this point, the ESXiArgs campaign is already underway and accurate metrics can be drawn upon from other attributes.
Tl;dr:
One of the publicly visible aspects of the “ESXiArgs” campaign is that a ransom note is made available on a hosts public IP with a title of How to Restore Your Files.
By performing a query for How to Restore Your Files we can generate a list of the autonomous system organizations and countries affected by this campaign, complete with a generated timestamp since this number will continually fluctuate and is only accurate as a point-in-time metric.
Our data partner, Censys, provided the data/query. To see current results, use the query — services.http.response.body: "How to Restore Your Files" and services.http.response.html_title:"How to Restore Your Files”.
Tl;dr:
GreyNoise has had a tag available for tracking and blocking CVE-2021-21974 since June 2021:
At this moment in time, we’re seeing a the Log4j-style conundrum 😬; the majority of CVE related activity is related to benign cybersecurity companies checking for the presence of the vulnerability.
As described above, there is no confirmed reports of the initial CVE exploit vector, so how can GreyNoise help defenders when the attack vector is unknown?
As we explained in our “How to know if I am being targeted” blog, IPs that return no results when searched on GreyNoise are traffic that is targeted at your organization.
If your organization observes a connection from an IP that returns no search results in GreyNoise: You should almost certainly prioritize that investigation, because it’s targeting your organization instead of the entire internet. If you find that the IP not known to GreyNoise was connecting to your organization’s VMWare ESXi on TCP/427, you should definitely prioritize that investigation.
In cases where initial access vectors are unknown, using GreyNoise as a filter for internet background noise can help prioritize the things that matter the most, because absence of a signal is a signal itself.
If you’ve ever heard our founder and CEO, Andrew Morris, speak, you’ll know that one of the core reasons GreyNoise exists is to answer the question “Is everyone seeing this, or is it just me?”
GreyNoise provides details about opportunistic scan activity by source IP as observed across our sensor network. When large geopolitical events happen, like the ongoing Russia-Ukraine war, our research team historically has been able to provide details on the destination of the traffic we’re seeing as well (e.g. Russian scans and exploitation attempts only focusing on our Ukrainian sensors). We are proud to share that this capability, labeled as IP Geo Destination, is now available to all GreyNoise customers via the Visualizer and API endpoints as of today.
Using the new IP Geo Destination feature, we can delve deeper into anomalies in scanning traffic.
Recently, there has been an uptick in scan activity related to scanning for DB2 databases as highlighted by the trends page. Using this as a starting point organizations can begin to investigate further to better understand why there is a sudden increase in scan activity.
Using the GreyNoise command line tool, we can search ‘.metadata.destination_countries’ to derive where this activity is pointing to. The traffic seen from the DB2 Scanner in the last 7 days reveals an even distribution of traffic across GreyNoise sensors in 41 different countries (see our docs for a list of all countries where we have sensors today).
Further investigating IPs active in the last seven days that are scanning for DB2 instances shows that all of them have been tagged as malicious in GreyNoise. Most of them have multiple tags associated with each IP address, several of which are related to various worms attempting to propagate across the systems connected to the internet.
Threat hunters looking for more targeted activity can add the `single_destination` parameter to identify IPs focusing on a particular geographic region.
In the example above, by entering the search `tags:"DB2 Scanner" destination_country:Ukraine single_destination:true `, you can filter results to show only activity that is targeting a single country, in this case, Ukraine. Defenders that work for the government, non-profit organizations, or are generally interested in a specific country or region can utilize this to focus on localized activities and potential threats.
----
With the additional data provided by IP Geo Destination, GreyNoise users can better understand how attacks impact different geographic regions. Our destination data is built off of our own sensor network so the geographic information being provided is first-hand. This feature is designed for cyber defenders to connect geopolitical motivations with scan and attack traffic and help responders quickly prioritize and triage alerts.
If you have questions about this feature or are interested in getting a demo contact our sales team.
On December 12th, 2022 Fortinet released a PSIRT Advisory for CVE-2022-42475 noting that it had been exploited in the wild.
CVE-2022-42475 is a heap-based buffer overflow vulnerability (CWE-122) in FortiOS SSL-VPN, which may allow a remote unauthenticated attacker to execute arbitrary code or commands via specifically crafted requests.
Since the vulnerability’s announcement, GreyNoise has actively monitored for any activity potentially related to FortiGuard products.
Beginning December 29th, 2022 GreyNoise observed a significant increase in credential brute force attempts against Fortinet SSL VPN.
GreyNoise is not aware of any publicly available Proof-of-Concept code for CVE-2022-42475 at this time. We have created a tag for tracking Fortinet SSL VPN brute force activity as its recent volume is malicious in nature is notably targeting the same product as another high-profile vulnerability.
On December 29th, 2022 GreyNoise sensors observed a sudden high volume of HTTP traffic to the "/remote/logincheck" path containing credentials. We have correlated this as targeting Fortinet SSL VPN products using the following sources:
As of 2023-01-31 GreyNoise has observed 13,513,728 login attempts to the specified POST path from 263 unique source IP addresses since 2022-12-02.
Defenders can keep up to date with associated activity on the Fortinet SSL VPN Bruteforcer Trends page.
Use our GreyNoise tag to track and monitor this activity: GreyNoise Search, and optionally block all IPs associated with it.
Follow Fortinet's guidance on "How to secure and limiting SSL-VPN unknown user login (Bruteforce attack)" and "Restrict unauthorized access on the SSL-VPN service".
GreyNoise Researchers reviewed Rapid7's Fortinet SSL VPN Bruteforce Login Utility and created a test environment consisting of attacker and target Docker images. We used this environment to verify packet similarity to ensure our sensors were seeing similar traffic.
The attack container used a Kali Linux base with Metasploit installed. The target consisted of a vanilla Ubuntu container running a netcat listener on a specific port.
The "fortinet_ssl_vpn.rb" module was slightly altered to override valid server checks to make it easier to capture packets and perform analysis over HTTP.
Once configured and run, the payload was observed on the Docker instances using Wireshark.
UPDATE (2023-01-31): Added link to the QA'd Tag.
You may have noticed an anomalous uptick of PUT requests in the GreyNoise sensors these past couple of days (2023-01-22 → 2023-01-24). For those interested, we’ve put together a quick summary of the details for you to dive into.
The majority of PUT requests occurred from January 15, 2023, to January 26th, 2023. During this time period, 2,927 payloads were observed containing HTTP paths of randomly generated letters and either a “.txt” or “.jsp” file extension. Similarly, the body of the PUT requests contained a randomly generated string as text and another randomly generated string contained within the markdown of a Jakarta Server Page (JSP) comment field. We believe this to be a methodology attempting to insert a unique identifier into the target server to determine potential capabilities of further exploitation; such as the ability to upload arbitrary files, retrieve the contents of the uploaded file, and determine if the JSP page was rendered (indicative of possible remote code execution).
The remaining path counts can be seen here:
The most common being "/api/v2…", a path often found in FortiOS authentication bypass attempts. Check out our blog to learn more about tracking this exploit. We’ve also seen variations of "/FxCodeShell.jsp…", which is indicative of a Tomcat backdoor usage. Each has their respective packet example below:
Inquiring into these paths led to a discovery for us as well! Having been formally unfamiliar with the "/_users/org.couchdb.user:..." path, we did some digging, which led to a new signature for CVE-2017-12635.
This highlights novel ways attackers are attempting to fingerprint exposed services using known vulnerabilities, and is a starting point for hunting for additional malicious activity related to these requests.
If you want to do your own threat hunting, check out GreyNoise Trends (Anomalies).
When digging into these anomalies, GreyNoise researchers noticed a pattern of randomly generated JSP checking to see if they can upload, and then access their uploaded files.
The FortiOS authentication bypass used both the "/api/v2" HTTP PATH prefix along with a header of "User-Agent: Node.js"
"FxCodeShell.jsp" is associated with a well-known webshell.
Researchers at GreyNoise Intelligence have added over 230 tags since January 1, 2022, which include detections for over 160 CVEs. In today’s release of the GreyNoise Intelligence 2022 "Year of Mass Exploits" retrospective report, we showcase four of 2022's most pernicious and pwnable vulnerabilities.
Activity around the Log4j remote code execution flaw, which burst on the scene in last 2021, continued apace, and has found its place in daily internet background noise along with a cadre of other “celebrity vulnerabilities”. During the initial exploitation period, every single GreyNoise sensor (over six hundred sensors handle traffic from over five thousand internet IP addresses) fielded Log4j exploit traffic, handling nearly one-million attempts within the first week alone. Attackers continue to hunt for newly exposed, vulnerable nodes, and for nodes that may have accidentally had mitigations or patches removed.
The Atlassian Confluence Object Graph Notation Library (OGNL) injection weakness was an especially rueful one since it gave anyone unauthenticated access to any fathomable query, and Confluence is the knowledge repository of countless organizations. Due to the way this API endpoint handles input, clever attackers used varying techniques to obfuscate exploit payloads like the one below to avoid detection:
At the height of exploitation attempts, the GreyNoise sensor network saw nearly 1,000 unique IP addresses looking for exposed vulnerable nodes. We continue to see a daily average of nearly 20 unique addresses hoping for unpatched Confluence instances.
Apache httpd's path traversal and Remote code execution one-two punch may have entered the ring in 2021, but this contender made our 2022 list due to a steady increase in traversal exploit volume throughout the year (nearly 3x as many attempts as when the vulnerability first emerged on the scene). Apache’s httpd server may not have the top spot anymore, but it is still highly prevalent, and patching of legacy instances tends to be very spotty.
The F5 Big IP iControl's REST authentication bypass made the cut for the report as it hit the sweet spot in terms of the GreyNoise Celebrity Vulnerability Hype Cycle model (which is detailed in the report):
Finally, GreyNoise researchers took a hard look at CISA’s Known Exploited Vulnerability (KEV) Catalog releases in 2022 (through late-November):
and followed up on our mid-year assessment of CISA’s overall KEV performance, noting that:
GreyNoise has tags for over 100 CVEs in the 2022 component of the KEV catalog. KEV CVEs without tags are ones where we would not see internet-facing remote exploit attempts (though there are a tiny number of KEV CVEs we're in the process of developing tags for).
Out of these 100+ CVEs, GreyNoise tag creation beat CISA's CVE updates 60% of the time, and we tied these updates 5% of the time. You can now search by CVE and set up GNQL like this one we recently published that covers CISA's published list of the top CVEs most used by Chinese state-sponsored attackers. Defenders can then use the pristine block lists (updated by the hour) to either remove the noise before it has a chance to reach them, or filter out the noise from events and alerts to enable significantly faster defense.
Ready to dig in to the data?
This blog will be updated as new information becomes available
Based on our current understanding of the vulnerabilities, CVE-2022-3786 and CVE-2022-3602, patched in OpenSSL 3.0.7, GreyNoise is unlikely to observe opportunistic mass exploitation in the wild.
On Oct 25, 2022 the OpenSSL project authors announced via mailing list that OpenSSL 3.0.7 would become available on Nov 1st, 2022 between 1300-1700 UTC and include a high severity, marked HIGH, security-fix
The release occurred on Nov 1st, 2022, at 1600 ET and includes fixes for affected versions v3.0.x through v3.0.6. The patch, available here, addresses following issues:
OpenSSL is a library that provides general purpose cryptographic functions. As with any usage of cryptographic operations, there is a reasonable expectation that operation involves sensitive data and any disclosure of information is highly problematic in nature.
The full change log provides the full description of both vulnerabilities as follows:
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.
In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
An attacker can craft a malicious email address to overflow an arbitrary number of bytes containing the `.` character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). ([CVE-2022-3786])
An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution depending on stack layout for any given platform/compiler. ([CVE-2022-3602])
For additional details, see OpenSSL Security Advisory [01 November 2022].
OpenSSL is a library and toolkit that can be used in a variety of ways. The most common integration scopes are via the System, or as a Dynamically or Statically linked library. The security vulnerabilities addressed in today’s patch address versions v3.0.x through v3.0.6. If you are not utilizing a version within that range then you are not affected by these vulnerabilities.
If OpenSSL is installed as a toolkit on your system you can quickly check by running the command openssl version which will report back the installed system version.
When OpenSSL is utilized as a library in a larger program it can be linked Statically or Dynamically.
When OpenSSL is statically linked, the library is bundled into the resulting executable of program when it is compiled, making the single executable contain all of the needed functionality as a single file.
When OpenSSL is dynamically linked, the library is expected to already exist on the system for which the program is expected to run. When the program is executed it searches a list of filesystem paths to locate the OpenSSL library and loads it as needed.
If you have access to the source code for the program you wish to evaluate for this vulnerability, the best way way is check for usage of the openssl3 library in the dependencies.
If you do not have access to source code, we recommend reaching out to the software vendor to ask for an evaluation and corresponding announcement. There are operating system specific methods to attempt to evaluate this yourself, but they require a more complex understanding of how libraries are loaded when a program is run. We recommend reaching out to the software vendor and requesting an announcement if you believe the software may be impacted. The software vendor should be able to answer in confidence.
OpenSSL 3.0.0 was released in September 2021 meaning that its usage is not as pervasive in older, more widely deployed software. For more details, see Censys’ blog regarding potentially vulnerable OpenSSL 3.x enabled devices.
In a self-evaluation of all of GreyNoise’s infrastructure which included our wide array of honeypot style sensors spread across a large variety of operating systems and cloud providers we did not identify any usage of vulnerable versions of OpenSSL v3.0.x
This will not hold true of all organizations, but it is a data-point we can provide at this time.
Please update your search term or select a different category and try again.
