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.
Industrial Control System (ICS) is a term describing systems that monitor and control industrial processes, such as mine site conveyor belts, oil refinery cracking towers, power consumption on electricity grids, or alarms from building information systems. NIST references them as “encompass[ing] several types of control systems, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other control system configurations such as programmable logic controllers (PLC) often found in the industrial sectors and critical infrastructures.”
Governments often describe ICS as critical infrastructure; they are essential to societal and economic function. Their critical nature means changes, updates, and replacements are risky and costly endeavors. Put simply: ICSs are slow to change with a strong bias toward legacy technology and compatibility.
Many ICSs feature custom network serial-based protocols for coordinating industrial hardware. The rise of the modern internet came with worldwide networking standardization. Without security as a priority, many vendors simply packed their legacy protocols inside TCP or UDP and called their devices network or internet-ready.
ICSs critical nature – combined with lagging security – incentivizes attackers and defenders to scan the internet for exposed devices.
GreyNoise Researchers have identified and created tags for the following ICS-related protocols:
Create a free account today to start researching ICS-related protocols and more.
On October 6th, Fortinet sent an advance notice email to selected customers notifying them of CVE-2022-40684, a critical severity vulnerability (CVSS: 9.6) authentication bypass on the administrative interface of FortiOS / FortiProxy.
Affected versions and software include:
Mitigation steps and workarounds can be found at: https://www.fortiguard.com/psirt/FG-IR-22-377
GreyNoise was contacted by Horizon3 for collaboration of their ongoing research into the FortiOS vulnerability. They graciously provided the necessary information needed to accurately tag this vulnerability.
GreyNoise users can track IPs attempting to exploit CVE-2022-40684 via:
Users can also search for the vulnerabilities using GNQL by CVE –
<span class="code-block" fs-test-element="rich-text">cve:CVE-2022-40684</span>
or by tag name –
<span class="code-block" fs-test-element="rich-text">tags:”FortiOS Authentication Bypass Attempt”</span>
As of October 13, GreyNoise has observed IPs attempting internet-wide exploitation of this vulnerability, with activity increasing quickly over the past 24 hours. We are aware of several Proof-Of-Concept (POC) code examples to exploit CVE-2022-40684 and expect related exploitative network activity to continue to increase now that these are publicly available.
FortiOS handles API calls by proxying all requests to an interface that is only accessible internally. This internal interface is responsible for verifying authentication and authorization. Proxied requests contain some additional parameters which can be used by FortiOS to bypass or authenticate internal requests. This allows an attacker to masquerade as an internal system API call, bypassing authentication on all externally-facing API endpoints.
Horizon3 has demonstrated leveraging the exploit to achieve authenticated SSH access to vulnerable devices as well as a blog on relevant Indicators Of Compromise (IOCs):
Independent of any knowledge of Horizon3’s collaboration with GreyNoise, one of our engineers (Ian Ling) got curious and spent some time over the weekend researching the vulnerability, leading to successful exploitation with a slightly different methodology.
Authentication bypass in FortiOS / FortiProxy (CVE-2022-40684) is trivial to exploit and users should patch or employ mitigations immediately.
If you need to buy time under SLAs: use a block list and apply mitigations, check for presence of IOCs, and work towards upgrading software.
Today, Tenable announced its new Research Alliance Program to share vulnerability information prior to public disclosure. GreyNoise is proud to be an inaugural member of this program, which aims to reduce the window of opportunity for threat actors seeking to exploit newly discovered vulnerabilities.
At a high level, cyber threat intelligence is the craft of predicting what villains and miscreants are going to do on the internet—including how, why, and where they will do it. Unfortunately, most threat intelligence solutions have not delivered on this promise. Within the wider cybersecurity community, threat intelligence is often viewed as a commodity that brings unquantifiable business value and uncertain security value. Over time, this dynamic has caused the security community to lose faith in the entire concept.
Here is the root of the problem: while many threat intelligence providers are great at cybersecurity, they are bad at providing data in a way that is useful for their customers. Generally speaking, the data provided by most threat intelligence solutions is of poor quality, because it is based on inaccurate assumptions. Some solutions even lack the conviction to provide guidance on how to make automated block decisions based on their data. And if a machine can’t use the data, how useful can it be?
As an industry, cybersecurity needs to get better at sharing information about threats–including what organizations are encountering and what they are doing to defend themselves. To compare with the airline industry, plane crash investigations are an enormous collaborative effort involving input from dozens of governmental organizations and industry partners. Their collaboration creates insights that improve flight safety for everyone, long into the future; cybersecurity can learn much from this approach.
As the primary source for understanding internet noise, GreyNoise believes that sharing data about threat intelligence with other industry partners will improve data quality for the entire industry. The combination of Tenable vulnerability data with the real-time mass exploit awareness that GreyNoise provides will help our mutual customers and industry partners to respond faster (and more accurately) to newly emerging vulnerabilities.
“Whenever a vulnerability is disclosed, the dinner bell sounds for good and bad actors alike, meaning organizations are already on their back foot,” explains Robert Huber, Tenable Chief Security Officer and Head of Research. “We know threat actors are monitoring disclosure programs in the same way we are, looking for newly announced vulnerabilities, studying all available information such as proof of concepts, but they’re looking to utilize the flaw. By giving our customers the tools to address these weaknesses when they’re publicly announced, we reduce that intelligence gap and hand the advantage back to the good guys.”
For more information about how to partner with GreyNoise, please visit https://www.greynoise.io/partners.
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.
Presently, there are three source IPv4 classifications defined in our GreyNoise Query Language (GNQL): benign, malicious, and unknown. Cybersecurity folks tend to focus quite a bit on the malicious ones since they may represent a clear and present danger to operations. However, there are many benign sources of activity that are always on the lookout for new nodes and services, so we’re starting our new sensor retrospective by looking at those sources first. Don’t worry, we’ll spend plenty of time in future posts looking at the “bad guys."
While likely far from a comprehensive summary, there are at least 74 organizations regularly conducting internet service surveys of some sort (we’ll refer to them as ‘scanners’ moving forward):
We were curious as to how long it took these scanners to find our new nodes after they came online and were ready to accept connections. We capped our discovery period exploration at a week for this analysis but may dig into longer time periods in future updates.
Out of the 74 known scanners, only 18 (24%) contacted our nodes within the first week.
As the above chart shows, some of the more well-known scanners found our new sensor nodes within just about an hour after being booted up. A caveat to this data is that other scanners in the main list may have just tried contacting the IP addresses of these nodes before we booted them up.
One reason organizations should care about this metric is that some of these scanners are run by “cyber hygiene” rating organizations, and you only get one chance to make a first impression that could negatively impact, say, your cyber insurance premiums. So, don’t deploy poorly configured services if you want to keep the CFO happy.
It’s pretty “easy” to scan the entire internet these days, thanks to tools such as Rob Graham’s masscan, provided you like handling abuse complaints and can afford the bandwidth costs on providers that allow such activity. We identified each of these scanning organizations via their published list of IPs. We decided to see just how many unique IPs of each scanner we saw within the first week:
Bitsight dedicates a crazy amount of infrastructure to poke at internet nodes. Same for the Internet Census. By the end of the week, we saw 346 unique benign scanner IPs contact our sensors, which means your internet-facing nodes likely did as well. While you may not want these organizations probing your perimeter, the reality is that, while you may be able to ask them to opt you out of scanning, you cannot do the same for attackers (abuse complaints aren’t a great solution either). Some organizations, ShadowServer in particular, are also there to help you by letting you understand your “attack surface” better, so you are likely better off using our benign classified IPs to help thin down the alerts these services likely generate (more on that in a bit).
The chart above also shows that some services have definite “schedules” for these scans, and others rarely make contact. Just how many contacts can you expect per day?
Hopefully, you are using some intelligent alert filtering to keep your defenders from being overloaded.
Web servers may rule the top spot of deployed internet-facing services, but they aren’t the only exposed services and they aren’t just hosted on ports 443 and 80 anymore. Given how many IP addresses some scanners use and how many times the node in the above example was contacted by certain scanners, it’s likely a safe assumption that the port/service coverage was broad for some of them. It turns out, that assumption was spot-on:
At least when it comes to this observation experiment, Censys clearly has the most port/service coverage out of all the benign scanners. It was a bit surprising to see such a broad service coverage in the top seven providers, although most have higher concentrations below port 20000.
If you think you’re being “clever” by hosting an internet-facing service on a port “nobody will look at," think again. Censys (and others’) scans are also protocol-aware, meaning they’ll try to figure out what’s running based on the initial connection response. That means you can forget about hiding your SSH and SMB servers from their watchful eyes. As we’ll see in future posts, non-benign adversaries also know you try to hide services, and are just as capable of looking for your hidden high port treasure.
If we strip away all the benign scanner activity, we’re left with the real noise:
We’ll have follow-up posts looking at “a week in the life” of these sensors to help provide more perspectives on what defenders are facing when working to keep internet-facing nodes safe and sound.
Remember: you can use GreyNoise to help separate internet noise from threats as an unauthenticated user on our site. For additional functionality and IP search capacity, create your own GreyNoise Community (free) account today.
UPDATE 01-Oct-22: Microsoft Security Threat Intelligence released updated mitigation guidance through their blog. This is noted in the Mitigations section.
GreyNoise is investigating claims of multiple zero-day vulnerabilities in Microsoft Exchange Server, nicknamed ProxyNotShell.
Microsoft announced these are being tracked under the following CVEs:
Microsoft has reserved CVEs, but details have been added to the MITRE database:
These vulnerabilities are also being tracked by Zero-Day Initiative (ZDI), who demonstrated the exploit on Twitter, under ZDI-CAN-18333 and ZDI-CAN-18802.
GreyNoise is currently monitoring for any activity matching indicators described in the original vulnerability write-up.
This vulnerability is similar to (but not the same as) ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207).
GreyNoise has released a single tag for tracking IPs checking for the presence of a vulnerability to ProxyNotShell:
GreyNoise is actively monitoring for additional information needed to track and tag ProxyNotShell Vuln Attempts.
Users can also search for the vulnerabilities using GNQL by CVE -
<span class="code-block" fs-test-element="rich-text">cve:CVE-2022-41040 OR cve:CVE-2022-41082</span>
or by tag name -
<span class="code-block" fs-test-element="rich-text">tags:"Exchange ProxyNotShell Vuln Check"</span>
Please note that this tag is not the same as the tags for tracking for ProxyShell (2021):
Additionally, the write-up authors note that they “detected exploit requests in IIS logs with the same format as ProxyShell vulnerability.” Using this information, GreyNoise researchers searched historical sensor records from 2021-01-01 to 2022-09-29 for Proxyshell-related backend paths. GreyNoise has not observed any new backend paths in use since 2021-08-27.
The GreyNoise Analyzer shows that four of the IOC IPs have been observed by GreyNoise:
Of these, 104[.]244[.]79[.]6 and 185[.]220[.]101[.]182 are Tor exits:
GreyNoise did not observe any OWA-related traffic from them in the past year.
The other two IPs, 137[.]184[.]67[.]33, the C2, and 103[.]9[.]76[.]208 can be seen here:
At this time, GreyNoise has not observed anything believed to be related to the vulnerability from these IPs in the past year.
Microsoft indicated that CVE-2022-41040 could enable an authenticated attacker to trigger CVE-2022-41082 remotely. This vulnerability is similar to the 2021 ProxyShell vulnerability, which involved fabricating an authentication token. At this time, we lack the information necessary to determine if “ProxyNotShell” leverages a similar authentication token leak.
Microsoft Security Threat Intelligence is releasing official up-to-date mitigation guidance through their blog.
Additionally, anyone can download the Blocklist for ‘Exchange ProxyNotShell Vuln Check’ to block at their firewall. For more information on how this works, please see GreyNoise documentation on Firewall Blocking with GreyNoise Trends.
There is currently no patch available for these vulnerabilities. We will update this blog with more information as it becomes available.
GreyNoise tags are described in the documentation as “a signature-based detection method used to capture patterns and create subsets in our data.” The GreyNoise Research team is responsible for creating tags for vulnerabilities and activities seen in the wild by GreyNoise sensors. GreyNoise researchers have two main methods for tagging: a data-driven approach, and an emerging threats-driven approach. Each of these approaches has three main stages:
When using a data-driven approach, researchers work backward from the data collected by GreyNoise sensors. Researchers will manually browse data or create tooling to aid in finding previously untagged and interesting data. This method relies heavily upon intuition and prior expertise and has led to non-vulnerability-related discoveries such as a Holiday PrintJacking campaign. Using this approach, GreyNoise steadily works toward providing some kind of context for every bit of data opportunistically transmitted over the internet to our sensors.
During the discovery phase, researchers identify interesting data that does not appear to be tagged by manual or tool-assisted browsing of raw sensor data. Researchers will simply query the data lake for interesting words or patterns, using instinct to drive exploration of the data. Once they have identified and collected an interesting set of data, they begin the research phase.
During the research phase, the researcher works to identify what the data is. This could be anything from CVE-related traffic to a signature for a particular tool. They do this by scouring the internet for various paths, strings, and bytes to find documentation relating to the raw traffic. This often requires the researcher to be adept at reading formal standards, like Requests for Comments, as well as reading source code in a variety of programming languages. Once they have identified the data, the researcher will gather and document their findings before moving on to the implementation phase.
Using their research, the researcher will implement a tag by actually writing the signature and populating the metadata that makes it into a GreyNoise tag. Once complete, a peer will review the work, looking for errors in the signature and false positives in the results before clearing it for production.
When using an emerging threats-driven approach, researchers seek out emerging threats observable by GreyNoise sensors. For the most part, GreyNoise only observes network-related vulnerability and scanning traffic. This rules out vulnerabilities like local privilege escalations. Using this method, GreyNoise can provide early warning for mass scanning or exploitation activity in the wild of things like CVE-2022-26134, an Atlassian Confluence Server RCE.
During the discovery phase, researchers monitor a wide variety of sources such as tech news outlets, social media, US CISA’s Known Exploited Vulnerabilities Catalog, and customer/community requests. Researchers identify and prioritize CVEs that customers and community members may be interested in due to their magnitude, targeted appliances, etc.
Similar to the data-driven approach, researchers will gather publicly available information regarding the emerging threat that will allow them to write a signature. Proof-of-Concept (PoC) code is often the most useful piece of information. On rare occasions, lacking a PoC, researchers will sometimes attempt to independently reproduce the vulnerability. Researchers will often attempt to validate vulnerabilities by setting up testbeds to better understand what elements of the vulnerability should be used to create a unique and narrowly scoped signature.
Finally, using all collected information, the researcher will seek to write the signature that becomes a tag. When doing this, researchers focus on eliminating false positives and tightly scoping the signature to the targeted data or vulnerability. When relevant for emerging threats, GreyNoise researchers will run this signature across all of GreyNoise’s historical data to determine the date of the first occurrence. This allows GreyNoise to publish information regarding when a vulnerability has first seen mass exploitation in the wild and, occasionally, if a vulnerability, like OMIGOD, was exploited before exploit details were publicly available.
GreyNoise provides insight into IP addresses that are scanning the internet or attempting to opportunistically exploit hosts across the internet. Tag data associated with a specific IP address provides an overview of the activity that GreyNoise has observed from a particular IP, as well as insight into the intention of the activity originating from it. For example, we can see that this IP is classified as malicious in GreyNoise because it is doing some reconnaissance but also has tags associated with malicious activity attempting to brute force credentials as well as traffic identifying it as part of the Mirai botnet.
GreyNoise tags are also a great way to identify multiple hosts that are scanning for particular items or CVEs. For example, querying for a tag and filtering data can show activity related to a CVE that is originating from a certain country, ASN, or organization. This gives a unique perspective on activity originating from these different sources.
Finally, tag data is accessible via the GreyNoise API and allows integrations to add this tag data easily into other products.
See which tags are trending right now.
For approximately 12 weeks this summer, I got to work as an intern on the GreyNoise Intelligence research team. During my time in the GreyNoise internship program, I did great things with amazing people while learning a lot about the workplace (as well as myself).
Given an arsenal of ideas, the intern team decided to centralize the primary goal of our summer internship project around finding a vulnerability in an Internet of Things (IoT) device, release a proof of concept, disclose the vulnerability, and then track the lifecycle of the vulnerability using the GreyNoise dataset. While we did not end up locating a vulnerability, the experience of attempting to achieve this task taught me many non-technical skills.
Walking into this program, I did not have prior work experience. Having previously done contracting, the process of working with a team – let alone communicating with a group – was a whole new experience for me. I had many opportunities to hone my communication skills (which I learned is an area that will always need improvement) and to grow relationships with the research team. Looking back, one of my favorite experiences was observing how everyone on the research team interacted both inside and outside of the office and how they supported each other throughout the day.
When I assisted the research team (and didn’t work on the internship project), I was able to contribute to a company mission that I feel passionate about, which isn’t a luxury that many people have. Working alongside the researchers gave me the opportunity to meet people from other departments (e.g., engineering, data science, sales), and I enjoyed seeing how the various teams interacted and how well everyone meshed together.
As related to the job function, I was able to learn about how the research team produces content for blogs, writes tags, and interacts with customers. I learned how to answer a customer’s request for technical support, and I researched the (now deprecated) EternalBlue tag to better understand what customers were experiencing.
In terms of personal betterment, I learned that while I used to be good at time management, I can easily unlearn that skill. I realized the importance of working on communication with others, staying focused, setting realistic expectations for myself and the speed at which I can work, and setting a structured schedule for when things need to be completed. In hindsight, I think the reason I was able to get other things done (like school assignments) was the fear factor, but I know that’s not practical in any setting and that milestones for progress should be set on my end without stressing myself out.
Below are some of the key takeaways I’ve gleaned from my experiences during the summer internship program:
Overall, I learned a great deal both technically and professionally from interning with the GreyNoise research team this summer. I discovered that I deeply enjoy conducting all sorts of research, then writing about the research. I obtained valuable workplace skills and realized that I have a lot more to learn about working in the real world. I’m extremely grateful to have had the experience of working at GreyNoise this summer, and I’m excited to see how the company grows – and I have absolutely loved being involved.
One of the most valuable attributes of GreyNoise is the ability to increase Security Operations Center efficiency by providing context, which allows the relevant security personnel to prioritize alerts. We listen and collect data from around the world from IP addresses that are opportunistically scanning the internet. We intentionally do not solicit traffic and rotate the IPs our services listen on frequently to preserve one of the most important attributes of the GreyNoise dataset: All traffic we observe is unsolicited in nature.
This attribute of our dataset allows us to quickly provide contextual information to answer the question, “Is my organization the victim of a targeted attack?”
On the left is the IP traffic GreyNoise can observe. On the right is the IP traffic a given organization may observe. Where these two groups overlap is the traffic seen by both GreyNoise and your organization. Unfortunately, this means that targeted network requests to your organization may frequently be outside of what GreyNoise can see.
If your organization observes traffic from an IP that has not been observed by GreyNoise, this traffic is likely targeted at your organization due to business verticals, software vendors in use, or implied value. Alerts falling into this category deserve a higher priority for investigation.
The largest volume of traffic targeted at your organization will likely be sourced from your desired user base or from automated tooling specific to your organization’s needs, such as API calls. As this is a near-constant occurrence, your security and infrastructure team are best equipped to recognize and identify what qualifies as normal.
Of course, there is also malicious network traffic targeted at your organization that GreyNoise may not have observed. Despite it being targeted, GreyNoise can still help provide context.
Consider that your organization has observed HTTPS traffic to the path “/v2.57/version” from an IP that GreyNoise has not observed. The GreyNoise Query Language (GNQL) supports wildcards, meaning that values and attributes of network requests that are specific to your organization, such as version differences in software, can be omitted in order to return query results that preserve the overall structure of the request.
Example: raw_data.web.paths:"/v*/version"
This allows you to surface IPs and context that GreyNoise has observed that share structural similarities with traffic observed by your organization that GreyNoise has not observed.
While this type of context association is fuzzy in nature, we can still quickly ascertain that the traffic observed by your organization is likely to be targeting web-accessible containerization software.
Since the traffic observed by your organization was HTTPS, you can further combine and pivot stricter fingerprints such as JA3 hashes to rapidly create actionable documentation for investigations of targeted network traffic.
If you’ve worked in a SOC, you might know this scene:
You clock into work, open the SIEM, and see RAT alerts. Hundreds of them.
Scary, right? Until one of your coworkers goes, “Oh, the RAT alerts. Yeah, just close those out; those are all false positives.”
But how can you be sure?
Actually, you cannot be sure - or, not right away. First, it is crucial to look into how the RATs - Remote Access Trojans - are communicating with each other and their command and control servers.
Remote Access Trojans (viruses used to establish persistent remote access to computers) are typically found using beacons. As you can imagine, there are many methods for beaconing multiplied across as many ports and protocols. In a single day, you might see a RAT “beaconing” via IRC, random UDP packets sent to a command and control server, feeding directly into a Discord bot, or even sending requests via Gopher protocol.
The broadest definition of beaconing is when a RAT communicates to its Command and Control (C2) server. This often appears as if the machine itself is communicating with the RAT C2.
Crawling, broadly defined, is a server scanning known IP addresses for machines that have installed RATs. Before communicating with a command and control server, the operator will need to see which machines are infected and have communication open. For that purpose: they may crawl the internet, sending a message to every machine and network that might have been infected, hoping for a response from the RAT itself.
We will often observe beaconing and crawling for the same malware, with the beacon and crawl playing a game of call-and-response between the infected machine and a command and control server.
Beaconing can be hard to verify. Sometimes we have observed unique packets on a seemingly random UDP port, only to find out telemetry is being sent by a legitimate program. Crawling, on the other hand, can be easier to find. Typically a crawler tries to send a set payload in order to get a response from the RAT
This article focuses on what we can do with crawling activity.
As an example, search for the tag “gh0st RAT crawler.” https://viz.greynoise.io/query/tags:%22Gh0st%20RAT%20Crawler%22
On this page, many results appear (with mixed reputations). Some of them are from other security companies doing routine scanning for gh0st RAT traffic to monitor the spread of the RAT. However, others are from anonymous servers and may be malicious.
These detections are from a tag GreyNoise has written based on a common hex-encoded header that the crawler sends when checking for gh0st RAT-infected machines.
Using the example of gh0st RAT crawler traffic, there are a few things you may want to consider.
One consideration is the kinds of devices being scanned: gh0st RAT is typically found on Windows machines. Is the crawler coming from a benign source and hitting a Linux server? Perhaps don’t worry about that.
Another factor is where in the network your machine is positioned. It is common for edge devices (web servers and firewalls are two examples) to be constantly scanned at all times by any number of devices for any number of reasons. Is the crawling excessive? You may want to check the source of the crawler to verify if it is a legitimate source. If not, it doesn’t hurt to block them at the firewall.
Finally, are your machines responding? If so, you may want to review your network for signs of compromise. Take stock of any outbound traffic your machine is sending in response to the crawler. If you see that your machine is already ignoring the crawler, you may want to run a quick antivirus scan for peace of mind and carry on. If you’re seeing unfamiliar responses or traffic that’s not usual for your network: perhaps run a thorough antivirus scan, disable RDP on the machine in question, and block the IP address trying to contact you. You may also want to conduct an internal investigation to make sure no data has been exfiltrated if you’re sure that there was a successful connection between your machine and the server trying to communicate with it.
This is where GreyNoise can help your process: by integrating GreyNoise into your environment, you can look for this crawling traffic and determine the reputation of whoever is doing the crawling, taking some of the leg work out of your investigation and response. When minutes count, even saving a few clicks can help.
The Cybersecurity and Infrastructure Security Agency (CISA)'s Cyber Safety Review Board (CSRB) was established in May 2021 and is charged with reviewing major cybersecurity incidents and issuing guidance and recommendations where necessary. GreyNoise is cited as a primary source of ground truth in the CSRB's first report (direct PDF), published on July 11, 2022, covering the December 2021 Log4j event. GreyNoise employees testified to the Cyber Safety Review Board on our early observations of Log4j. In this post, we'll examine key takeaways from the report with a GreyNoise lens and discuss what present-day Log4j malicious activity may portend.
It may seem as if it's been a few years since the Log4j event ruined vacations and caused quite a stir across the internet. In reality, it's been just a little over six months since we published our "Log4j Analysis - What To Do Before The Next Big One" review of this mega-incident. Since that time, we've worked with the CSRB and provided our analyses and summaries of pertinent telemetry to help them craft their findings.
The most perspicacious paragraph in the CSRB's report may be this one:
Most importantly, however, the Log4j event is not over. The Board assesses that Log4j is an “endemic vulnerability” and that vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer. Significant risk remains.
In fact, it reinforces their primary recommendation: "Organizations should be prepared to address Log4j vulnerabilities for years to come and continue to report (and escalate) observations of Log4j exploitation." (CSRB Log4j Report, pg. 6)
The CSRB further recommends (CSRB Log4j Report, pg. 7) that organizations:
This is all sound advice, but if your organization is starting from ground zero in any of those bullets, getting to a maturity level where they will each be effective will take time. Meanwhile, we've published three blogs on emerging, active exploit campaigns since the Log4j event:
Furthermore, CISA has added over 460 new Known Exploited Vulnerabilities (KEV) to their ever-growing catalog. That's quite a jump in the known attack surface, especially if you're still struggling to know if you have any of the entries in the KEV catalog in your environment.
While you're working on honing your internal asset, vulnerability, and software inventory telemetry, you can improve your ability to defend from emerging attacks by keeping an eye on attacker activity (something our tools and APIs are superb at), and ensuring your incident responders and analysts identify, block, or contain exploit attempts as quickly as possible. That's one area the CSRB took a light touch on in their report, but that we think is a crucial component of your safety and resilience practices.
Log4j is (sadly, unsurprisingly) alive and well:
This hourly view over the past two months shows regular, and often large amounts of activity by a handful (~50) of internet sources. In essence, Log4j has definitely become one of the many permanent and persistent components of internet "noise," and this is a further confirmation of CISA's posit that Log4j is here for the long haul. As if on queue, news broke of Iranian state-sponsored attackers using the Log4j exploit in very recent campaigns, just as we were preparing this post for publication.
If we take a look at what other activity is present from those source nodes, we make an interesting discovery:
While most of the nodes are only targeting the Log4j vulnerability, some are involved in SSH exploitation, hunting for nodes to add to the ever-expanding Mirai botnet clusters, or focusing on a more recent Atlassian vulnerability from this year.
However, one node has merely added Log4j to the inventory of exploits it has been using. It's not necessary to see all the tag names here, but you can explore these IPs in-depth at your convenience.
Building on the conclusion of the previous section, you can safely block all IPs associated with the Apache Log4j RCE Exploit Attempt tag or other emerging tags to give you and your operations teams breathing room to patch.
You are always welcome to use the GreyNoise product to help you separate internet noise from threats as an unauthenticated user on our site. For additional functionality and IP search capacity, create your own GreyNoise Community (free) account today.
On 28-April-2022, in light of escalating cyber attacks in India, the Indian Computer Emergency Response Team (CERT-In) issued new directions to sub-section (6) of section 70B of the Information Technology Act, 2000. Among other expanded requirements, the new directions mandate reporting of any cyber security incident, including targeted scanning of systems and data breaches, within 6 hours of noticing the incident to CERT-In. Prior to this change, CERT-In had been allowing organizations to report the incidents within “a reasonable time.”
The implications and sweeping nature of the changes caused quite a stir in the security community when initially released, especially since organizations ranging from service providers, intermediaries, data centers, government entities, and corporations, all the way down to small and medium businesses, need to follow CERT-In requirements.
The directions were to become effective 60 days from the date of issuance in April. However, after receiving a large volume of feedback from affected organizations, CERT-In extended the enforcement deadline to 25-September, 2022. Despite the reprieve on the enforcement deadline, responses to the CERT-In’s standing FAQ indicate that the national agency is not inclined to adjust the main provisions it introduced.
GreyNoise helps customers identify and respond to opportunistic “scan-and-exploit” attacks in real time. In the case of CERT-In’s new reporting mandate, GreyNoise helps customers filter opportunistic mass-scanning activity out of their alerts, so they can focus (and report on) targeted scanning activity. GreyNoise’s guidance on how to automate the process of detecting and reporting on targeted scanning/probing of critical networks and systems is below.
At a high level, the new CERT-In directions require organizations to:
CERT-In defines “Targeted scanning/probing of critical networks/systems” as:
The action of gathering information regarding critical computing systems and networks, thus, impacting the confidentiality of the systems. It is used by adversaries to identify available network hosts, services and applications, presence of security devices as well as known vulnerabilities to plan attack strategies.
These days, every machine connected to the internet is exposed to scans and attacks from hundreds of thousands of unique IP addresses per day. While some of this traffic is from malicious attackers driving automated, internet-wide exploit attacks, a large volume of traffic is benign activity from security researchers, common bots, and business services. And some of it is just unknown. But taken together, this internet noise triggers potentially thousands of events requiring human analysis. Given the expansive wording and stringent timeline of the directions, it’s crucial to intelligently reduce the number of alerts that are in scope and quickly prioritize mass exploit and targeted activity.
Using GreyNoise, you can effectively identify IP addresses that are connecting to your network and prioritize those that are specifically targeting your organization (versus non-targeted, opportunistic scanning that can be ignored).
In this representative scenario, we have configured our perimeter firewalls to send logs to Splunk.
Using the GreyNoise App for Splunk (which you can install from Splunkbase), you can configure the gnfilter command to query the IP addresses against GreyNoise API and only return events that GreyNoise has not observed.
Important note - GreyNoise data identifies IP addresses that “mass-scan” the internet - so If GreyNoise has NOT observed an IP address, that means it is potentially “targeted" scanning activity.
For better presentation, the results are deduplicated and stored as a table.
Within Splunk Enterprise, adjust the query to reflect events in the last 6 hours:
By selecting Search, the query will enrich all the filtered IP addresses against GreyNoise data and return only those IP addresses that have not been observed across our distributed sensor network.
In our case, the query returned seven IP addresses for which GreyNoise has not seen activity.
Prioritize this filtered list for additional analysis to rule out targeted scanning on your infrastructure.
To automate this process going forward, save the query as an Alert. You can adjust the Cron Expression to set a query frequency. In this example, it is set to every 6 hours.
Before clicking Save, consider two other helpful actions for configuration: setting a destination email address for the alert, and then formatting the results as a CSV file.
With the alert configured, our query will run every 6 hours to ensure that any IP addresses that should be prioritized for analysis are packaged in a CSV format for review.
To learn more about how GreyNoise can help you comply with the updated reporting mandates from CERT-In, reach out to schedule a demo with one of our technical experts.
Please update your search term or select a different category and try again.
