Your network security team just informed you they found malicious code on the network beaconing to 18.104.22.168. First thought, what other infrastructure might be related to the IP address? Naturally, if one data point is good than hundreds must be better. You notice the IP address is part of a larger class C address space (22.214.171.124/24), so you scan the entire subnet and wait for results. Just then, your co-worker comes by and tells you to block the whole 38478 autonomous system because it's known to be bad. Sound's great...No!
One common question we get at PassiveTotal is why we don't allow for subnet and AS searches. The reason is simple, we don't view them as strong enough data points when attempting to connect potentially unrelated infrastructure. Using the example introduced above, we will walk through the issues in considering subnets and autonomous systems.
126.96.36.199 is part of a class C network which means there are 254 other IP addresses as part of that allocation. Depending on the provider, it's possible that there could be some related IP addresses, but there's no guarantee they are contiguous or a clear indication of when the addresses were allocated. Furthermore, looking at the autonomous system name, it appears the allocation is controlled by SunnyVision Limited Internet Service Provider located in Hong Kong. Does this ISP service businesses only? What about individual customers? Could our IP address of interest be in some closet in an apartment building?
For cases like this, it's difficult to find a strong connection between addresses. However, there are times when the network allocation is small enough that it could infer a single owner. There's no rule of thumb, but we generally evaluate subnets when their allocations are above a /27, meaning they have 32 IP allocations or less. Even with such a small address pool, it's still entirely plausible for all of the items on the IP addresses to be unrelated.
It's likely after the subnets portion above that you realize blocking an entire AS is a bad idea, but lets continue exploring with our example. The IP address in question belongs to a network that's advertised under AS 38478. Using Hurricane Electric's BGP tool, we can see that this AS advertises 162 IPv4 subnets which happens to encompass over 41,000 (41,472 to be exact) different IP addresses. For each subnet, we need to consider the same details as listed above when trying to find related data.
Taking a look at the AS names for each of the advertised subnets reveals the potential for at least 10 different organizations to be in charge of the class C allocations. Are they all ISPs? Could they be in the same building? Are some of the different companies owned by a larger organization? All of these questions are not likely to get answered in a timely manner and reveal one critical detail about autonomous systems, they're complicated.
Right about now, you may be asking yourself why you would ever use the AS data when performing threat infrastructure analysis. While it may not be a strong connection point, AS names do reveal the potential owner of a given set of prefixes. Inside the PassiveTotal platform, we attempt to automatically extract key elements from the AS name to use as a tag for the next hop infrastructure. These tags are often helpful in cases where one of the IP addresses is using a content delivery network or hosting provider which could easily result in thousands of unrelated domains. Representing the data in a tag allows the analyst to prioritize research and avoid long query times.
So, it’s all useless?
Not quite. Subnets and autonomous systems have a place when doing threat analysis, but for individual threats, they aren’t going to provide too much value. Situations or attacks where higher-level routing could be helpful would be things like BGP hijacking, Distributed Denial of Service (DDoS) attacks, data sniffing and so on. It’s for these reasons and the explanations above that PassiveTotal doesn’t provide these values as searchable points within the platform.