Explore Our Data
IP “Whack-a-Mole” experiment – to block or not to block mass exploitation attacks
Security organizations have historically been hesitant to block IP addresses at their perimeter to stop the bad guys. There are two primary reasons for this - the short lifetime of malicious IP addresses, and the generally poor quality of IP block lists (i.e., way too many false positives). As David Bianco mentions in his Pyramid of Pain blog, “If you deny the adversary the use of one of their IPs, they can usually recover without even breaking stride.”
However, in the situation of an emerging “exploit storm” where the organization is exposed with unpatched vulnerable systems, we think that short-term blocking of mass exploitation attackers could be helpful and valuable. So we decided to run an experiment to test whether this strategy (which we started calling “whack-a-mole”) might help.
The whack-a-mole strategy temporarily blocks IP addresses that have been observed scanning for or actively exploiting a vulnerability over the past 24 hours. The intent is to provide breathing space for security teams to patch vulnerable systems and search for compromises that may have occurred before blocking was implemented.
In order to test whether this security strategy could work, GreyNoise Research conducted a study comparing the compromise rates between two weakly-credentialed servers - one using the whack-a-mole IP address blocking strategy, and the other that was wide open to the Internet.
“Whack-a-mole” shows a surprising amount of promise in blocking of mass exploitation attacks:
- Unblocked Host - Time to Compromise - 19 minutes
- Blocked Host - Time to Compromise - 4 days, 6 hours
Read on for more details about the GreyNoise Research IP Blocking study.
Some Insights from the Apache Log4j Vulnerability Storm
Since early December, security teams have been scrambling to deal with the fallout from the Log4Shell vulnerability (CVE-2021-44228). This vulnerability was particularly serious given the broad deployment in internet-facing systems of the Log4j service. Because of the massive surge of exploit scanning we observed and requests from our Community, we created a publicly available set of IOCs to help security teams defend themselves from the massive barrage of vuln checking and remote code execution attempts. Within 24 hours, we were able to stand up data sets that included:
The consistent feedback we received was that this data was most helpful in the early (and most crucial) hours and days of this exploit storm.
After things calmed down, we asked ourselves a question - how were people using the data? When we reached out to ask folks, we found two general use cases:
- Blocking inbound connections to stop attacks and provide “breathing space” for response efforts
- Hunting for compromised systems that may have happened before blocking started
These use cases were particularly interesting to us, given the traditional viewpoint that IP blocking is not useful.
Based on this feedback, we decided to run an experiment with our GreyNoise IP data to determine if there might be some value to the “whack-a-mole” strategy of blocking malicious mass scanner IPs during the early stages of an exploit storm.
What is a “mass exploitation” attack?
According to a recent report by IBM, severe vulnerabilities in internet-facing enterprise software are being exploited and weaponized at an increasing rate and at massive scale. Opportunistic “scan-and-exploit” attacks are quickly approaching phishing as the most-used cyber attack vector, with 34% of attacks in 2021 using vulnerability exploitation, compared to 41% of attacks leveraging phishing.
So we are using the term “Mass Exploitation” to describe these large-scale, opportunistic attacks launched by attackers trying to take advantage of common or newly announced vulnerabilities. These attackers use mass scanning technology to cast a broad net across the entire 4.2 billion IP addresses on the internet, trying to locate, vuln check, and ultimately exploit vulnerable internet-facing devices. This type of attack is very different from a more traditional “targeted attack” that aims for a selected, focused target.
Mass exploitation attacks are internet-wide exploit attempts using state-of-the-art mass scanning technology that targets vulnerable internet-facing systems.
Mass exploitation attacks are conducted for a variety of reasons, including:
- Adding compromised hosts to a botnet
- Installing malware such as ransomware, trojans, or Bitcoin miners
- Gaining access to a network and selling the access to targeted attackers
- Accessing sensitive data/information
- Network infiltration
- Reconnaissance
“Whack-a-mole” experiment setup
Our hypothesis for this experiment was that blocking opportunistic “scan and exploit” IP addresses would meaningfully increase the amount of time it takes for a vulnerable host on the Internet to be compromised.
We set up two identical vulnerable hosts, open to the Internet, with weak or default credentials, and then measured how quickly they would be compromised by credential stuffing/brute force attacks:
- Services used: SSH/TELNET/FTP/HTTP/REDIS
- Credentials used: admin/admin
For one of these hosts (the BLOCKED host), we loaded up a list of all the scanner IPs from our GreyNoise NOISE data set into an iptables blocklist. This list came from an export of all IPs seen in GreyNoise in the past day using the filter “last_seen:1d”. For the other host (the UNBLOCKED host), we did not block any IPs.
Our goal was to measure the time to first compromise, as well as the total number of compromises seen over a similar time period. We used OpenCanary for our honeypots and ran the experiment from January 12-30, 2022.
What we found
Our preliminary results show that whack-a-mole blocking works. On average, the wide open (unblocked) server was compromised in 19 minutes, while the blocked host took 4 days, 6 hours, and 24 minutes to be popped. We also measured the average number of compromises per day, and the number of compromise attempts per hour - all of these statistics showed significant differences between the protected and unprotected servers.
.png)
One insight worth mentioning is the decay rate we saw with the IP address list we used. For our blocked server, we only sourced one set of IP addresses and did NOT update the list with fresh IPs every 24 hours. What we observed was that connection attempts increased exponentially each day over the 5 days of the experiment, indicating that the IP list “decayed” in terms of effectiveness over time as the IP list aged.
Tracking the total attempts made, the first day saw an average of six attempts, and the fifth day was over 2,500. By comparison, the unblocked hosts saw between 2100 and 7100 attempts in the first 24 hours compared to 5 - 8 attempts on the blocked host. The unblocked hosts ended up getting compromised so quickly that we never kept them up for longer than a day.
One conclusion we can draw from this is that “fresh” IP addresses are crucial. In order to remain effective, an IP blocklist must be updated at least every 24 hours.
How can GreyNoise help with opportunistic attacks?
We have launched a new capability as part of our service called GreyNoise Trends that provides visibility into trending internet-wide exploits, as well as the ability to download “fresh” IP lists of all the malicious IPs participating in the attacks over the past 24 hours. This service was initially created based on customer requests experienced during Log4j. But we think the experiment described above helps validate the value of IP block lists for malicious mass scanners, and their use as part of a whack-a-mole strategy. Of course, your mileage may vary, and your defense infrastructure will be different from ours.
If you’re interested in learning more about this blocking strategy or trying to replicate the experiment for yourself, please visit https://www.greynoise.io/ to create a free Community account, and join our Community Slack to join the discussion. Also, please come to our Open Forum webcast on March 17, 2022 at 11am ET. You can register to attend here.
