Themes:
- Reducing the Impact of Promiscuous Scanners on Your Enterprise
- Reducing the Effectiveness of Reconnaissance in Attack Surface Management
- Technique of Volt Typhoon: T1592.001, T1592.002, T1592.003, T1592.004
Interrupting the Reconnaissance Phase of an Attack
As enterprises work to block key concerns in the MITRE ATT&CK Framework, there is a belief that not much can be done regarding the ‘Reconnaissance’ phase of a typical attack. Even in the MITRE documentation this is echoed “This technique cannot be easily mitigated with preventive controls since it is based on behaviors performed outside of the scope of enterprise defenses and controls. Efforts should focus on minimizing the amount and sensitivity of data available to external parties.” [i]Availability is of key concern and inhibits traditional reliance on block lists requiring IP addresses that may cause problems one day, but be assigned to a new client the next.
But the truth is that you can do a lot to reduce the effectiveness of unwanted scanning of your resources. In support of this research and identifying how to make our enterprises less of a target, we have found that certain TCP fingerprints present themselves when different tools are used during the recon phase of a potential attack. These fingerprints are difficult to manipulate because they enable the adversary to scan at extremely high speeds when conducting their activities. So, the TCP fingerprinting correlates to their toolbox in a way, that if you can detect the scanning activity by tool type, you can effectively stop the reconnaissance. For the Blue Team, this is much like a Star Trek ‘cloaking’ device for your enterprise.
As a product of this research, the MuonFP[ii] open-source project was born and is a utility, written in Rust, that allows for real-time fingerprinting of the TCP SYN-ACK handshake. This fingerprint follows a similar format that is often seen in other well-known fingerprinting tools but doesn’t require dependencies on other open-source code or even storing pcaps. As an example, using MuonFP, a typical Windows 11 or Mac system offers a fingerprint of:
65535:2-4-8-1-3:1412:8
| TCP Window | Options (in order presented) | MSS | Scale |
| 65535 | 2-4-8-1-3 | 1412 | 8 |
There are misconceptions as to what the ‘fingerprint’ really provides in context identity from the TCP-IP settings. A better definition would be to call this a ‘signature’ as the term ‘fingerprint’ insinuates that the value can be used to identify a particular actor. The fingerprint can offer strong clues to the network stack configuration, tools being used and other helpful information to reveal the actor’s intention.
Here is another common fingerprint found in the MuonFP logs concerning scanners:
65535:::
| TCP Window | Options | MSS | Scale |
| 65535 |
This MuonFP fingerprint shows that the TCP SYN-ACK was given only a TCP Windows size. That’s it. There is no intention of normal TCP communications and the purpose of this appears to be for ‘high speed’ scanning where the only goal is to perform reconnaissance of the target network and most likely the actor is scanning extremely high number of TCPv4 addresses where speed is of the essence, thus reducing the handshake to bare minimum in order to accomplish scan efficiency. Of technical interest, the empty values are not zeroes, they are NULL and therefore MuonFP properly records them as empty. It should be noted ‘0’ in TCP options denotes ‘End of Options List’ and these empty values do not equate to ‘0’.
Studying this high-speed scanner traffic over a 90 day period, shows that the number of fast scanners using this shortened fingerprint configuration is quite high. For this honeypot configuration, high-speed scanner traffic comprised 35% to 70% of the daily traffic in terms of connection attempts by SYN-ACK activity in our AWS environment.
Some of the scanners are listed as ‘benign’ per cyber intelligence vendors, those being the most common scanner companies, but they share this information online with unvetted users providing this reconnaissance information to potentially malicious actors. With this in mind, it is particularly useful to consider these large scanning companies as ‘promiscuous’ at best. When categorizing scanner activity in your environment, perhaps ‘Malicious’, ‘Authorized’, ‘Unknown’ and ‘Promiscuous’ would provide better context when assessing risk.
In the shadows of these large, well known scanning companies, you will also see IP and geolocation information not attributed to known scanners and may be assumed to be indicating nation-state actors heavily scanning infrastructure as well. Regardless of whether you see the large scanning companies as a threat, dubious nation state actors are doing a similar reconnaissance[iii] or at least we do not know what their actual motivations could be.
Typical Scenario
Some of our previous investigations over the last 18 months show a possible correlation of scanning activity that is followed up by a brute force or exploit attempts by a different IP address shortly thereafter. This correlation rule roughly follows these attributes:
- Scans for specific ports on the host
- Followed by a short window (<15 minutes) where a direct connect attempt at password spray/brute force or trying a particular exploit against the port
- The scanner is NOT categorized as ‘Promiscuous’ or ‘Authorized’
Though coincidence could be the explanation for such timing and the attack modus operandi, it is our conclusion that the original scanner, operating from a clean IP address, is ‘shot calling’ the attacks for the malicious attempts that come after. This describes typical automated bot activity, which we see as much more the norm than individual probing of vulnerabilities[iv]. In this scenario, preventing such reconnaissance would be an effective tool against attacks.
We see activity that sometimes appears to be quite manual and attributable to individual exploit attempts. This could be from bug bounty researchers, hands on keyboard vulnerability probing or similar scenarios and should be of high interest as well. These scenarios demonstrate that the attacker is spending a lot of time and resource to probe your defenses and should have it’s own focus. Ultimately the attacker will need to run some form of scan against a network or endpoint, even if carefully limited in scope, and using fingerprints is one way of detecting and either alerting your SOC or blocking it.
Another scenario to consider is while most enterprises monitor for brute force or password spray activity as one form of detection and defense on the perimeter, it may not be as effective in today’s threat landscape. With the proliferation of stolen credentials through credential stealing malware, many of these unauthorized access attempts now go undetected since brute forcing isn’t required and just finding the right endpoint for the credential will work. The ability to prevent reconnaissance can be an important part of the Blue Team defense matrix, since the attacker, matching the stolen credential to the possible enterprise resource may be more difficult if you do not have a scan of all public facing systems.
Potential Solutions
Using MuonFP on the backend, we were able to create a fingerprint firewall, FPFW[v], to quickly find the IP address and block scanners that were doing recon against our assets. FPFW collected a list of approximately 14,500 IP addresses and blocked them after 30 days of activity. Using the IP address was a workaround due to the limitations of both IPTABLES and NFTABLES. Though these simple firewalls have the ability to surface specific TCP settings in their filtering, using wildcarding was problematic.
Additional risk in this approach also included the potential for lock out attacks and other unintended consequences. It was also difficult to come up with an appropriate scheme of ‘delisting’ blocked IP addresses, much like problems found with many IP reputation lists. There were also issues with how often to poll the fingerprint data and since scanning can be done so quickly, by the time the block occurred, the scan was completed.
Additional collaboration with Vlad Iliushin, founder of ELLIO.TECH suggested an approach using eBPF and XDP to create wildcard fingerprint blocking system that could safely block traffic in the event of a TCP connection using scanning techniques as identified by the MuonFP fingerprint, while still allowing legitimate non-scanning activities. This method has been tested effectively and found that this may be the best approach to interrupting the reconnaissance activities of dubious visitors based on fingerprinting. (Author’s note: this eBPF tool will be released as open source shortly)
After using eBPF rule to drop SYN-ACK of “%:::” via intel provided by MuonFP fingerprints, the amount of this particular type of scanning activity on the honeypot dropped to zero.
Additional fingerprints related to undesirable tools are also fingerprinted with high reliability. Therefore, additional fingerprints could be dropped via this method and includes: NMAP, ZMAP, CURL, MASSCAN and even TOR as they appear to have rather unique MuonFP fingerprints.
| TOR Exit | 42340:2-1-1-4-1-3:1460:11 |
| NMAP | 62727:2:8961: |
| CURL | 65535:2-1-3-1-1-8-4-0:1343:6 |
| MASSCAN | 1024:2:536: |
| ZMAP | 65535:2-1-3-1-1-4:1460:8 |
Summary
The often-overlooked MITRE ATT&CK Framework category of ‘Reconnaissance’ is an important component to your risk management and your enterprise should have a strategy that includes listening and categorizing malicious activity. By implementing honeypots that can collect this activity, you can effectively tune out scanning from unauthorized groups and protect your enterprise from further exploit attempts.
MITRE ATT&CK Technique
| Reconnaissance: Gather Victim Host Information | |
| ID: T1592 | T1592.001, T1592.002, T1592.003, T1592.004 |
About the Author:
Ken Webster has worked for Imperva, A Thales Company for the last 4 years as the Incident Response Leader for their corporate security program. He’s responsible for not only investigations, forensics and cyber security response, but also threat intelligence, bug bounty and reducing overall risk for the organization. He was previously with IBM and has a decade or two of experience in cyber security and systems management. He is the author of the GitHub open source project, MuonFP.
[i] Reconnaissance: Gather Victim Host Information, https://attack.mitre.org/techniques/T1592/004/
[ii] MuonFP, https://github.com/sundruid/muonfp
[iii] Volt Typhoon, https://www.cisa.gov/news-events/alerts/2024/02/07/cisa-and-partners-release-advisory-prc-sponsored-volt-typhoon-activity-and-supplemental-living-land
[iv] Bots Now Make Up Nearly Half of All Internet Traffic Globally, https://www.imperva.com/company/press_releases/bots-make-up-half-of-all-internet-traffic-globally/
[v] FPFW, https://github.com/sundruid/fpfw