False Negatives in Attack Surface Mapping

Attack surface mapping tools can miss assets for a wide variety of reasons. Here we list 15 such scenarios, including a broken DNS server, the use of round-robin DNS and ephemeral infrastructure.

Assets can slip through the cracks for many different reasons. The ones that are missed are often the least important in terms of risk, but it is never a good idea to miss any asset if you can help it. Let us walk through some of the reasons an asset can go unnoticed.

1. The asset does not belong to you. Sometimes people find an asset critical to them that they believe belongs to them. Still, for whatever reason, the attack surface map believes it belongs to another company. An example would be: yourcompany.salesforce.com. Do you own it or does Salesforce? Technically Salesforce owns it, and you rent it, so this is a gray area that can be solved on a one-off basis by manually adding said singular hostname. Still, the perfect programmatic solution doesn’t exist due to all possible variants of this issue.

2. The asset is internal. If the asset is entirely internal or has no public route (RFC1918, for example), it may not be found because nothing links to it. In that case, no DNS entries are publicly available (in the case of split-horizon DNS.) Even if it is a public DNS entry, it may not be found because it lacks an observable footprint. Sometimes people will use local /etc/hosts or C:/ WINDOWS/system32/Drivers/etc/hosts files, and no one will see the entries within those files except for whoever has them on their local systems.

3. The asset has no DNS. In a DNS-centric world, if your asset has no DNS entry, and you do not know the IP address in question to have it monitored, attack surface mapping tools may not find it.

4. The asset does not use SSL/TLS. One way attack surface mapping tools find assets is by using certificate transparency. If your asset does not use SSL/TLS, it will not leak that information to be collected later, which makes it less likely to be found.

5. Your DNS server is broken. Although unlikely, sometimes DNS servers are broken. How they are broken is not always clear. I have seen sites that blow up on long strings. I have seen others that do not respond after a few requests. If your DNS server is broken, assets may get missed. Quite often, failover pairs of DNS servers will have different zone files. If I only query one of them because the failover is rarely, if ever used, I will not see the entries on the failover.

6. You just bought a company. Occasionally a paper-only transaction occurs between two business entities. While there may be a public announcement about it, no technical changes may have taken place. In that case, it may be challenging to know that the assets belong to your company. This can be even more difficult if it is a stock agreement where your company owns a large share of stock. No other mechanical levers into the company exist that would give away that information to correlate the two entities.

7. Your DNS entry is not RFC compliant. About 1% of all DNS entries are invalid. That is partially due to collection issues, to how flaky DNS is, and, yes, to DNS errors. Many characters are not RFC compliant. Yet, the system will pass the characters along, and the resolver must decide to drop it. A simple example would be this_is_invalid.com vs. this-is-valid.com.

8. Your domain uses whois privacy. Suppose the domain is intentionally protecting its association with your other domains. In that case, it may not be found, and the assets associated with the domain will not be found either.

9. You use round-robin DNS. With round-robin DNS, each request may yield one or more different IP addresses. Just by bad luck, it can take forever to get the same result twice, and, therefore, a single asset may be missed while others for the same DNS entry will be found many times. It is the luck of the draw with round-robin DNS. I can flip a coin a million times and always get heads, and I can query your DNS a million times and never get the one IP address in question.

10. The DNS goes up and down frequently. When infrastructure is ephemeral, it may be missed because the systems are not fast enough to manage something that only lives momentarily. This can be mitigated to some extent by using agents via the API. Still, the customer must manage it because it’s impossible to track that behavior externally at any cadence without ultimately receiving cease and desist letters due to how much traffic it would require to monitor.

11. It is a very new asset. If the asset just appeared, it may take some time for the system to identify its location. This can be mitigated by manually adding the asset in question via the API or via an agent.

12. Your asset is hidden amongst wildcards. This can sometimes happen where all *.test.yourcompany.com DNS entries point to a singular wildcard, but you also have a testing.test.yourcompany.com subdomain, for example. In this case, a test would confirm the presence of a wildcard and would not attempt a brute force. If it did, it would need to selectively remove the IP in question associated with the wildcard. If that IP is the same, you are out of luck because it’s impossible to identify the wildcard at that point.

13. There is no traffic to the site. Un-indexed websites or assets that have no users on them will not be spotted using external passive DNS sources. The more traffic to a site, the more likely it is to be spotted by some third party that does passive DNS telemetry.

14. It is not an asset with a dictionary name. If the asset is 180r0818.scotland04-rack41.yourcompany.com, the chances of brute forcing that name approach zero. Typical brute forcing uses dictionary words or very common hostnames, and if it is uncommon, the fallback of brute force will have little to no chance of finding it in situations where it is a long/unique string.

15. DNS is hacked. DNS is a very flakey protocol overall, given that it is stateless and unencrypted. It is ripe for interception, modification, and as my late friend Dan Kaminsky once found, it can also be very vulnerable. Some users may get one result and others a different result.

I have attempted to outline most of the issues, but there are certainly more. Hopefully, this gives you a good idea of how assets can go unfound in an Attack Surface Map. Let us know if you think I have missed anything!

Visit the Tenable.asm product page to learn more about attack surface management.