Whether responding to incidents or hunting through large and complex data sets, IP addresses usually feature fairly heavily as a key analysis data point.
When looking at lateral movement cases, for example, knowing what IP address a particular login originated from is a key piece of information. Likewise, when looking at something like a VPN intrusion, IP addresses are also critical in establishing incident narratives and “ground truth.”
IP addresses alone only tell you part of the story, however, and we must rely on data enrichment to establish where a particular IP address is located, where the IP address is hosted, and whether a particular IP address is associated with known-bad or confirmed malicious activity.
Another key piece of data when it comes to IP addresses is the AS (autonomous system) to which an IP belongs. Depending on investigative or hunting context, an IP address belonging to a residential ISP (internet service provider) versus a hosting provider may change analyst conclusions.
It is within this context in which the blog is situated. In it, we’ll cover what exactly ASNs are, how they can be utilized in hunting and incident response workflows, and provide real-life examples of how we used ASNs to unravel intrusions and locate malicious activity in partner networks.
What are ASNs?
These days, when we think of “the internet,” we typically think of some kind of abstract “cloud” found in a diagram.
This abstraction, however, belies a complex series of networks that all communicate with one another and make up what we know of as the internet.
To paraphrase Cloudflare, autonomous systems (AS) can be thought of as groupings of networks that have a unified routing policy.
We love Cloudflare’s analogy here:
“Imagine an AS as being like a town's post office.”
Each internet “post office” has a number attached to it: the ASN, or autonomous system number.
Each external IP address belongs to a particular ASN or “post office.” For example, my home IP address belongs to the ASN AS812, which belongs to Rogers Communications Canada.
Armed with knowledge regarding what ASNs are, let’s now take a look at how this data point can be utilized and generated.
How are ASNs utilized?
Now that we know that an ASN is like an address, the next step is to utilize this information in the context of threat hunting or incident investigation.
When we hear phrases such as “data enrichment” or “IP enrichment,” what’s often meant by these phrases is enriching the IP address with metadata such as its ASN information and/or its geolocation.
As an example, we can check out the IP enrichment information provided by ipinfo.io for one of Google’s DNS servers:
Figure 1: Image showing IP enrichment information for Google’s DNS server
We can see from the image above that one enriched IP address provides us with a bunch of useful information.
We know where the IP address is located (Mountain View, California, USA), and we also know which ASN the IP belongs (AS15169 Google LLC).
Now, place yourself in the shoes of an analyst who’s been asked to review a set of firewall logs. How would you be able to tell which connections may be malicious or at least suspicious?
One way to accomplish this is to enrich these IP addresses with the type of metadata outlined above, and use that information to detect any anomalies.
ASNs are a critical data point in these types of investigations, as geographic data alone may not tell you the full story.
Let’s take a look at some concrete and real-world examples of how the Huntress Tactical Response team utilizes ASN telemetry to unravel intrusions.
The case of remote desktop compromise
This case started out with the Huntress SOC detecting lateral movement and domain enumeration.
This is a relatively common set of signals to receive, and when lateral movement is involved, the network is typically isolated to prevent the spread of unauthorized access.
Once the network was isolated and reports issued, the Tactical Response team began to look at the available telemetry to identify the initial access vector. We focus heavily on this investigative aspect, as knowing where intrusions originated helps our partners lock down their environment in a tactful and risk-based manner.
Based on the available telemetry, the compromise appeared to originate from the partner's remote desktop gateway host.
This is not enough information, however, and we needed to understand who “patient zero” was and when exactly the account was compromised, so that the partner (and us) understood the full scope of the incident.
Remote desktop gateway logs were available for this case, and these logs contained IP information. However, as we outlined earlier in this blog, an IP alone isn’t enough to go on. We need to enrich this information and then analyze it.
When we enriched the IPs with ASN information, the compromised account was evident, along with information regarding when exactly the account was compromised and from where.
Figure 2: Search illustrating normal versus abnormal ASNsAs we can see in the above image, the first time block of telemetry shows the user in question authenticating from residential ISPs such as Comcast and Rogers.
In contrast, later authentications for the same user account start occurring from more suspicious ASNs such as “LeaseWeb,” “BLNWX,” and “Datacamp Limited.”
Without this ASN enrichment in place, it would be difficult—if not outright impossible—to flag this account compromise. For data sets containing thousands of authentication events, checking each IP manually is not feasible.
In this case, we were able to provide the partner with a full picture of the intrusion, including the initial access vector. With this information, the partner could now communicate to their client the need for stronger authentication controls such as multi-factor authentication (MFA) in a manner which is backed up by hard telemetry and data. A win all around!
At this point in the blog, astute readers who possess some incident response background may be wondering, “What about IP geolocations?” “Isn’t that a great data point as well?”
Like all things in life, the answer to the above question is a bit complicated. Let’s break it down by looking at another case of password spraying a RADIUS device.
The RADIUS password spray
In this case, a partner had a RADIUS device that utilized Microsoft Entra for MFA.
The user would authenticate to the RADIUS device, which is connected to the partner networks’ Active Directory domain, and the MFA prompt would be handled by Entra.
In this case, the partner was alerted by their users to an unexpected MFA prompt. Upon investigation, it was discovered that about 60 accounts were targeted. Successful authentication occurred on the RADIUS side, but thankfully no user accepted the unexpected MFA prompts.
This case is interesting for a number of reasons.
First, it demonstrates how critical context is when looking at authentication-related compromise.
Had an analyst only looked at the RADIUS logs in isolation, without understanding how AuthN and AuthZ were configured in the environment, all the logins would appear to be successful.
Only with additional Entra telemetry, we were able to correlate the RAIDUS logins to their corresponding Entra authentication events, and were able to confirm that none of the logins succeeded on the Entra side.
Secondly, and more relevant to this blog, the case illustrates the limitations of IP geolocation when dealing with cloud-based incidents.
Looking at users’ authentication events on the RAIDUS end with the IP information geolocated, everything appears normal. The user is historically authenticating from the United States in and around the cities flagged in the screenshot below.
Figure 3: Search showing a user’s geolocation pattern appearing normal without ASN dataIt was only after adding ASN enrichment to these events that we discovered that the account was indeed compromised:
Figure 4: Search showing users geolocation pattern in addition to ASN dataWhen looking at geolocation alone, all appeared normal. However, when adding ASN enrichments, “Stark Industries” and “ROUTERHOSTING” all stood out as malicious.
This case is an excellent reminder of not relying on one data point alone—such as geolocations—when making determinations regarding whether a particular event is malicious or benign.
ASNs are critical data points when investigating VPN device compromise.
VPN compromise case
If you’ve read our previous blogs, it should come as no surprise that VPN compromise accounts for a large portion of the cases that tactical response covers.
When investigating VPN compromise, ASN enrichment is invaluable and critical to our investigative workflow.
Let’s look at one example.
In this case, Huntress received the following signals for the affected network:
Figure 5: Image showing initial signals received for an intrusionWe can see a common pattern of the threat actor going after credentials in two distinct ways:
- Through registry dumping
- Through browser login history theft
The command line arguments utilized for the above techniques indicated that lateral movement was at play for this particular incident as well, so the network was isolated to prevent further threat actor progress.
When we analyzed the Windows event logs for the affected network, the authentication patterns indicated compromise through a VPN appliance. This is a very common occurrence and a popular method of initial access, as previously mentioned.
Upon reviewing the VPN logs, two logins stood out immediately.
Both logins utilized the super_admin profile, and each occurred within one second from the other, but with different IP addresses.
This is an unusual authentication pattern for a VPN appliance, especially for a user account that has Administrative privileges to the device.
When we checked both IP addresses for their ASN values, our confidence level that these authentication events were malicious increased, as both IPs belonged to the same ASN: DigitalOcean.
It should be noted that the DigitalOcean ASN isn’t inherently evil or nefarious, and administrators may be utilizing machines hosted in DigitalOcean for their legitimate operations.
In this case, however, the observed authentication patterns in combination with the DigitalOcean ASN values found in the VPN logs was enough to, at the very least, bubble this up to the partner where it was (unfortunately) confirmed as malicious behavior.
Figure 6: Logs from VPN appliance showing IPs belonging to suspicious ASNsConclusion
ASNs are a critical data point when conducting hunting and investigations.
Often, malicious activity can be identified via its associated ASN value alone.
Conversely, ASN values can also be used as additional data points within hunts and investigations to either help confirm or deny malicious activity.
As we’ve shown in this blog, ASN enrichment is critical when conducting investigations for a myriad of services, including RDGs, Firewall/RADIUS devices and VPN appliances.
This blog only scratches the surface in terms of ASN utility as a critical telemetry data point. The mind map below presents some further ideas for utilizing ASN values in your own hunting and investigation adventures, and it provides a list of ASN values that we’ve observed recently as linked to malicious behavior.
Figure 7: Mind map of ASN telemetry and investigative steps
