Attack surface management: Find your assets before the hackers do
When Intruder’s Security Research Engineer, Daniel Thatcher, was asked to dive into attack surface management at DTX Europe, he showed how easily attackers can find what’s exposed to the internet – and how you can monitor and protect your own attack surface.
Here we’ll talk about the external attack surface – everything on the internet that an attacker can target to try and compromise your data. Companies often don't know what their attack surface is, and it can be hard to stay on top of all your servers, exposed services, cloud resources and SaaS accounts with developers constantly spinning stuff up. So, let’s dive in and see why.
Untracked attack surface
We looked at 3,000 organizations and ran basic asset discovery to see what they had exposed to the internet, and our results were a bit worrying. We found that only 21% of their internet facing assets were tracked as part of vulnerability management programs, which means that 79% weren't.
We filtered down for just domains with the word "admin" in them, and that 21% of assets being tracked dropped to 17%, which is even more scary. However, while companies don't always have the best grip on what they've got exposed to the internet, unfortunately, attackers do. We'll discuss how, but first, what happens as a result of this disparity?
Breaches in the headlines
Unfortunately, this disparity leads to breaches. For example, the Capita breach earlier this year left a lot of council data exposed in an unsecured S3 bucket. Recently, Wiz researchers found a token in GitHub that got access to an Azure storage bucket for Microsoft, leaking 38 terabytes of private data, including 30,000 internal Teams messages.
The Australian telecoms giant Optus left PII exposed to the internet. This may not immediately jump out as an attack surface issue – the exposed data wasn't from a cloud storage bucket, but from an unauthenticated API. However, you can be pretty sure their security team didn't know the API was out there without authentication, giving away customer details.
SMBs are in the crosshairs too
While we see these headlines made when enterprise gets breached, it’s not just big businesses that need to worry. As enterprises invest in security, it's becoming more costly for attackers to target them – so they’re now targeting smaller businesses with less security. Here’s a quote from TrendMicro's report on LockBit, the most prevalent current strain of ransomware:
“The majority of LockBit’s victims have been either small or medium-size businesses (SMBs) - 65.9% and 14.6% respectively, with enterprises only comprising 19.5%.” Ransomware Spotlight, LockBit, TrendMicro
TrendMicro saw 80% of LockBit attacks were targeting small or small to medium sized businesses, with only 20% of victims being from the enterprise sector. Unfortunately, whatever size you are, you need to be on top of your attack surface.
What do attackers look for?
IP ranges owned by a company can be very useful for an attacker. If an attacker is looking to target you, they can monitor these IP ranges for new services or servers being spun up, and instantly jump on them knowing that they're going to be yours and likely hold some of your data if exploited.
Domains and subdomains are useful to attackers as well – DNS provides a useful list of your assets for an attacker to enumerate. In some organizations, it’s easy for people to create new domain names, or even buy new domains, notifying attackers of new assets.
As we saw with Wiz's investigation into Microsoft, source code repositories can often contain secrets and leak a lot of data. They can also often contain references to internal systems, and give some understanding of how your services work, which is useful for attackers in launching further attacks.
You're likely using SaaS products, for example for email or file sharing – these are also great targets for an attacker. So are your cloud assets, which include not just misconfigured storage buckets as we’ve seen, but also other cloud services and APIs.
The enumeration process that an attacker will perform starts with known assets. If an attacker wants to target your company, they might know you own “example.com” and a particular IP range. They'll first try to go "wider" from this start point, finding other IP ranges you own or other domains you own.
Where real company data is used in the following examples, we’re using Uber. They have a public bug bounty program, and allow and encourage this enumeration. Nothing sensitive is going to be shown – we haven't dug so deep that you can compromise them from this!
IP range ownership
When you have an IP range on the internet, the fact that you own it is public information by design. An attacker can look up your IP ranges in one of many services that provide a searchable format for this data, such as Hurricane Electric’s service, Robtex, or BGPView.
Mergers and acquisitions
Mergers and acquisitions can also be a useful source for an attacker - a company like Uber buys and absorbs smaller companies, and they may be softer targets. Security is often not a priority for smaller companies, and recent acquisitions may not have been brought in line with the larger company’s security standards. They’re not hard to find either – Uber wants everyone to know “we bought this company”.
Analytics IDs are a clever technique that’s often overlooked. BuiltWith’s relationships service can be used to correlate these IDs across websites. In the screenshot below you can see that this service has found a number of analytics IDs used on “uber.com”, and then shows other websites which also use these same analytics IDs on the righthand side. If two websites use the same Google Analytics ID, they are reporting into the same Google Analytics account, and are likely related.
Certificate transparency provides a public log of every certificate issued. This means all the information on newly issued certificates, including domain names, is publicly available. crt.sh is a service which lets anyone search for this information, and can be very powerful in finding new domains. CertStream demonstrates an interesting use of certificate transparency, providing a real-time stream of newly-issued certificates. Attackers can monitor this service, or setup similar monitoring themselves, to allow them to quickly start targeting new domains found in these certificates.
In recent years, some bug bounty hunters have also taken to scanning the IPv4 ranges used by cloud providers to find certificates, and provide themselves with a searchable list of the domain names in these certificates.
A technique sometimes called “wide spidering” can also be useful for discovering new assets. A spider is a program that will automatically browse websites to discovery content. By configuring the spider to have a wide scope, for example considering anything with “uber” in the domain name, to be a target, an attacker can often discover new assets. The spider can also be left to run for much longer than a human would be willing to manually click around these websites to search for new content.
This screenshot is from five minutes into this process, and you see there's already a few interesting things in there.
The next step for an attacker is to search deeper into what they’ve found. The assets found during the previous steps essentially provide seeds for deeper investigation to find more assets.
Internet scan databases
One of the most popular methods for discovering new assets is internet scan databases, such as Shodan, Censys, ZoomeEye, and hunter.how. These scan the entire IPv4 range of the internet to find exposed services, and then present these services in a searchable format.
These databases also help attackers who aren’t specifically targeting your company to find your vulnerable services easily. An attacker who has an exploit for a critical vulnerability can use internet scan databases to quickly find vulnerable services and exploit them, even if they don’t know who owns the service.
Datasets like those provided by SecurityTrails, Rapid7’s Project Sonar and DNSDumpster collect data from multiple sources, some of which may not otherwise be available to an attacker. These can be used to discover more domains and subdomains belonging to an organization without active enumeration.
You can also use gau to easily find URLs from a given domain and its subdomains. The screenshot below shows this tool being run against "uber.com" and the (very) truncated output. This allowed not only new subdomains to be found, but also content on those subdomains.
Of course, there’s also Google, who present everything on the internet in a searchable format available to everyone. Searching Google for the copyright text found on Uber's homepage brings up more assets deeper into the search results.
Public source code
Developers may be publishing source code on platforms like GitHub or GitLab, which is searchable directly on these platforms, as well as by using tools such as the github-search scripts, and through other websites such as grep.app. This will often contain references to internal systems that, which can be useful to an attacker in future attacks.
If these techniques don't work, there's always simply guessing. Subdomain brute forcing is the art of saying “does this subdomain exist” repeatedly and very fast. There are many tools which can achieve this, such as sublist3r and dnsx.
These tools need a wordlist to provide the list of likely subdomain names. AssetNote's "best DNS" wordlist is pretty typical of what people are using. It's got about 10 million lines in it, and in their words, “you'll find that you discover some pretty obscure subdomains using this wordlist”, which in our experience has been true.
Don’t forget email
If you're using Microsoft 365 or Google for your email, all your email accounts have a public login portal that attackers can target. Both of these services allow an attacker to test which accounts are actually valid, meaning they can build up a large list of email addresses using a tool like O365Enum. Once they have this list, they can test all of the enumerated email addresses for common passwords, for example by using MSOLSpray. In larger organisations, the chances that at leastone user is using a weak password is quite high.
Also, don't forget SaaS applications. Some of these applications make it easy for an attacker to check whether a company is using them. For example, the screenshot below shows Uber’s login portal for Box, which we found easily by manually guessing. Not only can an attacker try to guess account passwords on these apps, but knowing which apps a company uses can help create convincing phishing emails.
Stay ahead of the hackers
With all the above techniques, you might be wondering how easy is this to do? Do you need 10 years of experience or can a 13-year-old do it? Unfortunately, it's nearer the latter. Attackers have all these different ways of finding what you have exposed to the internet. So what's our advice?
Perfect is the enemy of good
Start with finding all your assets now – do 10% of the perfect solution and build on it.
Let everyone do their jobs
Ensure that everyone in the company who creates infrastructure can do it in a secure way. This should include reducing barriers to make this secure way the path of least resistance, for example by automating getting visibility on new systems rather than requiring users to tell you.
Make your data work for you
Somewhere in your company there is some record of what exists. Make sure that you’re aware of all the cloud accounts in use, and that you’re pulling in data from them all. Try to keep a record of which SaaS applications are in use, and who has access to what.
The goal posts are always moving
Ongoing monitoring is a necessity. Members of your organization will be spinning up new infrastructure and services, and registering for new applications. On top of this, the threat landscape is always changing and new vulnerabilities are always being found. Continuous monitoring is a necessity to keep on top of it all.
How can you manage it all?
Get professionals like Intruder to help. Choose our Premium plan or bolt ons, and we’ll take a look at your assets, find what's out there, and approach them like an attacker to let you know what can be done.
We'll connect into your cloud accounts to bring anything in your cloud into our vulnerability management service. We can give you alerts on any changes and anything spun up or down. And we'll provide data and remediation advice to help you protect your attack surface. Why not try Intruder for free for 14 days and see how we can help protect your attack surface?
- Raw CVE Coverage
- Risk Rating Coverage
- Remote Check Types
- Check Publication Lead Time
- Local/Authenticated vs Remote Check Prioritisation
- Software Vendor & Package Coverage
- Headline Vulnerabilities of 2021 Coverage
- Analysis Decisions
Red teamers, security researchers, detection engineers, threat actors have to actively research type of vulnerability, location in vulnerable software and build an associated exploit.
Tenable release checks for 47.43% of the CVEs they cover in this window, and Greenbone release 32.96%.
Red teamers, security researchers, detection engineers and threat actors now have access to some of the information they were previously having to hunt themselves, speeding up potential exploit creation.
Tenable release checks for 17.12% of the CVEs they cover in this window, and Greenbone release 17.69%.
The likelihood that exploitation in the wild is going to be happening is steadily increasing.
Tenable release checks for 10.9% of the CVEs they cover in this window, and Greenbone release 20.69%.
We’re starting to lose some of the benefit of rapid, automated vulnerability detection.
Tenable release checks for 9.58% of the CVEs they cover in this window, and Greenbone release 12.43%.
Any detection released a month after the details are publicly available is decreasing in value for me.
Tenable release checks for 14.97% of the CVEs they cover over a month after the CVE details have been published, and Greenbone release 16.23%.
With this information in mind, I wanted to check what is the delay for both Tenable and Greenbone to release a detection for their scanners. The following section will focus on vulnerabilities which:
- Have CVSSv2 rating of 10
- Are exploitable over the network
- Require no user interaction
These are the ones where an attacker can point their exploit code at your vulnerable system and gain unauthorised access.
We’ve seen previously that Tenable have remote checks for 643 critical vulnerabilities, and OpenVAS have remote checks for 450 critical vulnerabilities. Tenable release remote checks for critical vulnerabilities within 1 month of the details being made public 58.4% of the time, but Greenbone release their checks within 1 month 76.8% of the time. So, even though OpenVAS has fewer checks for those critical vulnerabilities, you are more likely to get them within 1 month of the details being made public. Let’s break that down further.
In Figure 10 we can see the absolute number of remote checks released on a given day after a CVE for a critical vulnerability has been published. What you can immediately see is that both Tenable and OpenVAS release the majority of their checks on or before the CVE details are made public; Tenable have released checks for 247 CVEs, and OpenVAS have released checks for 144 CVEs. Then since 2010 Tenable have remote released checks for 147 critical CVEs and OpenVAS 79 critical CVEs on the same day as the vulnerability details were published. The number of vulnerabilities then drops off across the first week and drops further after 1 week, as we would hope for in an efficient time-to-release scenario.
While raw numbers are good, Tenable have a larger number of checks available so it could be unfair to go on raw numbers alone. It’s potentially more important to understand the likelihood that OpenVAS or Tenable will release a check of a vulnerability on any given day after a CVE for a critical vulnerability is released. In Figure 11 we can see that Tenable release 61% their checks on or before the date that a CVE is published, and OpenVAS release a shade under 50% of their checks on or before the day that a CVE is published.
So, since 2010 Tenable has more frequently released their checks before or on the same day as the CVE details have been published for critical vulnerabilities. While Tenable is leading at this point, Greenbone’s community feed still gets a considerable percentage of their checks out on or before day 0.
I thought I’d go another step further and try and see if I could identify any trend in each organisations release delay, are they getting better year-on-year or are their releases getting later? In Figure 12 I’ve taken the mean delay for critical vulnerabilities per year and plotted them. The mean as a metric is particularly influenced by outliers in a data set, so I expected some wackiness and limited the mean to only checks released 180 days prior to a CVE being published and 31 days after a CVE being published. These seem to me like reasonable limits, as anything greater than 6 months prior to CVE details being released is potentially a quirk of the check details and anything after a 1-month delay is less important for us.
What can we take away from Figure 12?
- We can see that between 2011 and 2014 Greenbone’s release delay was better than that of Tenable, by between 5 and 10 days.
- In 2015 things reverse and for 3 years Tenable is considerably ahead of Greenbone by a matter of weeks.
- But, then in 2019 things get much closer and Greenbone seem to be releasing on average about a day earlier than Tenable.
- For both the trendline over an 11-year period is very close, with Tenable marginally beating Greenbone.
- We have yet to have any data for 2021 for OpenVAS checks for critical show-stopper CVEs.
With the larger number of checks, and still being able to release a greater percentage of their remote checks for critical vulnerabilities Tenable could win this category. However, the delay time from 2019 and 2020 going to OpenVAS, and the trend lines being so close, I am going to declare this one a tie. It’s a tie.
The takeaway from this is that both vendors are getting their checks out the majority of the time either before the CVE details are published or on the day the details are published. This is overwhelmingly positive for both scanning solutions. Over time both also appear to be releasing remote checks for critical vulnerabilities more quickly.