Imagine if the Empire knew that there was a flaw in the Death Star’s thermal exhaust port. How would this change the events of the SW story? This critical piece of knowledge would empower them to make informed decisions — maybe install a few deflector shields to protect this crucial piece of infrastructure. In the end, the events of Episode IV would have played out very differently. While none of us can condone the actions of the Empire, there is certainly a lesson we can draw from this epic saga.
What is External Recon?
External Recon highlights open ports and services that are exposed to the Internet, such as RDP or SMB. When exposed, these services are ripe entry points for attackers to launch their attacks — we see this happen time and time again.
We have to remember that attackers have to start somewhere. How do they decide who to target next? In studying attacker behavior, one common theme we see over and over again is scanning for services open on the public internet. Even a simple RDP search on Shodan shows several login screens of Windows servers. Attackers are always opportunistically looking for an easy target, port scanning for external services, and brute-forcing their way in.
If these exposures exist, how can we shine a spotlight on them so that informed decisions can be made to improve security posture? With External Recon, the goal is to provide more visibility to inform key security decisions and actions by helping answer the following questions:
- How can I see if my clients have critical external exposures?
- Can I be notified when a change impacts the external attack surface?
- When I take on a new client, how quickly can I identify potential exposure?
What’s important to note about these exposed services is that they are often part of normal system operation but are vulnerable when exposed. To use our humble analogy, these services are like our thermal exhaust port — also highly vulnerable but necessary to eliminate excess heat away from the Death Star reactor core. With External Recon, visibility to these exposed services does not necessarily mean they should be eliminated or turned off; it simply means additional measures should be taken to protect those critical services such as hardened firewall policies or even multi-factor authentication.
How is External Recon Different from a Vulnerability Scan or a Penetration Test?
In any evaluation of an attack surface, there are countless areas to cover — and each can be scrutinized at varying levels of depth. With vulnerability scanning, the focus is usually around automated assessment. For example, vulnerability scanning may look at open services by performing port enumeration, looking for externally available services that open access to certain applications. They may then probe that application for version information to cross-reference it against known vulnerable versions, or even look for application misconfigurations.
Penetration tests go a step further by putting humans behind these tests as well, essentially putting on that white hat to see how far they can go and shed light on extremely deep vulnerabilities. There are dozens of elements that could be reviewed when looking at the external attack surface. A full and rounded vulnerability scan or pen test will not only highlight some of these exposures, but also provide a probability of occurrence (or a criticality score) to prioritize and highlight more urgent issues.
External Recon does not replace a vulnerability scan or a pen test report that would occur at regular intervals or for compliance reasons. It focuses on continuous scanning of high-level exposures to highlight when new attack vectors are discovered in order to accelerate response.
How Often Will External Recon Rescan?
With this initial iteration of External Recon, we are using a third-party service called Shodan to help us gather this information. At the moment, we are simply surfacing the information we receive based on the requested scan. While we do have the ability to rescan, we do not have control over when this occurs. We are actively developing new solutions to help supplement the data we are receiving from Shodan and offer more timely results.
How Will the Agent Change to Accommodate External Recon?
With this iteration of External Recon, nothing changes on the agent for Huntress to offer visibility into exposed services. When the agent sends metadata surrounding persistence (as it always has), Huntress is able to capture the public IP from where the agent is calling from. This public IP is then scanned using Shodan to determine what services are open for that public IP.
Can I Tell Which Endpoint Has Exposed Services Running?
The way most networks are configured, there isn’t a way for us to identify the single endpoint where the open port is surfacing from. To explain this, let’s take a step back and look at NAT (Network Address Translation).
One of the biggest use cases of NAT is to conserve public IPv4 address space; by allocating specific IP ranges for private internal use, those IPs could be reused from network to network. In the majority of cases, there are several internal IPs that are mapped to a single “global” public IP and it is the responsibility of the edge firewall to know which connections going out to the Internet are tied to specific internal endpoints.
External Recon emulates how an attacker would scan public IPs for open services. Here’s how this works:
- When the Huntress agent calls out to the Huntress cloud, Huntress captures the public IP address from where it is calling.
- A list of public IPs are gathered from all agents in the organization and scanned by the External Recon service sitting in the cloud — not by the agent itself.
- Services that are discovered open and available through the public IP addresses are then reported to the Huntress External Recon dashboard.
Because External Recon takes on an external attacker vantage point, it cannot correlate back to the internal IP of the internal host actively running the service — in most cases, the NAT relationship table managed by the edge firewall or router holds and maintains this information.
In addition, there are other factors to consider. For one, multiple hosts on the inside may have the same exact service running (i.e. RDP 3389, see diagram). Again, it is rules on the edge firewall that decides which internal host is actually exposing that service through the external public IP.
What’s Next for External Recon?
There’s a lot we know about how attackers are succeeding when launching their attacks. Filtering through days, weeks, months of hands-on threat research, we’ve filtered down some of the most common attack vectors and are starting with open service ports exposed to the Internet. As part of our Huntress Security Platform, faster and targeted response through iteration is key. We want to continue our iteration of services based on how threats are changing, what is/isn’t working, and feedback from our partners as a constantly refine and improve security defense.
The future is quite open and there are so many different directions we can go in order to shed light on the external attack surface. There are possibilities to explore skimming for password dumps found on the dark web all the way to scanning domain registration info for usernames and contact numbers. Starting small with service port monitoring helps us get a sense of what works and what doesn’t work for our partners and we have no intention of stopping here.
