Gaining visibility into an application’s attack surface is really important in identifying risk areas. In cases of an attack, it can also help in determining root cause i.e. the part(s) of an attack surface that was the origin of the breach.

In using an attacker’s perspective through reconnaissance, you can proactively identify attack surfaces. This will always help in quickly noticing attack surface changes or deciding on the best strategy for minimizing risk.

I will be highlighting the various attack surface components that can be found during the different phases of a typical (web app) reconnaissance workflow. To have a better understanding, I will make use of football analogies.

Football Analogy: Attack Surface Enumeration via Recon

Let’s do an illustration by using analogies from the beautiful game of football, specifically using a phase of play that has been well discussed in the last couple of years: The Build-Up Play. Think of this as any football game where in building up from the back, the goal is to move the ball (in this case our workflow/process) from our half to the opponent’s half.

Befittingly we’ll be using the 4-3-3 formation to show this, used by some of the greatest and most celebrated teams of all time; Ajax 1971–73, Bayern 1973–76, Barcelona 2008-2012.

PATHWAY 1: Build-Up Play (Through the Middle)

A flowing move through the middle is always fun

[6] SUBDOMAIN ENUMERATION

Usually, the first task is to discover subdomains in a given scope/target list and then map it to their corresponding ip addresses.

• ATTACK SURFACE (DNS Information)

There is great value in having complete knowledge of all DNS properties (e.g. subdomains) mapped to an application. Subdomain enumeration is a process that involves a lot of open source intelligence (OSINT), by combing various sources for valuable data like ip addresses, whois info, asn, zone records, email addresses etc. A company could have subdomains that they are not aware of, which affects visibility into those subdomains and could make them less secure. A good tool for finding, tracking and automating the DNS discovery process is Amass.

[5] PORT SCAN

Using the ip address(es) mapped to the (sub)domain, we do a port scan to get a list of open ports and the services running on them.

• ATTACK SURFACE (Network Information)

Disabling unneeded ports or services is a well known hardening control to help reduce attack surfaces.

[4] GATHER VALID TARGETS

This is probably the most important step as it involves visually identifying subdomains through screenshots, walking through the application and mapping each functionality. The questions to ask here are: What does it do and How does it do it? 

• ATTACK SURFACE (Input Vectors)

In navigating the application, the aim here is to discover any functionality in the application that accepts input.

• ATTACK SURFACE (Access Controls)

We also want to understand how the application implements security measures for things like authentication, authorization or session management.

• ATTACK SURFACE (Key Functionality)

Finally we try to identify key functions based on the business workflow or logic.

[8] DIRECTORY-FILE DISCOVERY

Moving forward, using the list of valid subdomain targets as input, we try to check for information disclosure on existing/hidden paths and files with tools like dirsearch/gobuster. Doing this will also help us have an idea of the directory structure. This step also marks the first time we move to the opposition’s half, thereby making our build-up play successful.

• ATTACK SURFACE (Hidden Content)

It is time to find additional data, anything that will uncover parts of the application that may be hidden or content that does not have direct links to pages.

[10] PLATFORM IDENTIFICATION

What does it run on? Finally, using the valid list of subdomains as input again, we can identify the different platforms or technologies (e.g. development/cloud platform) used by the web application.

• ATTACK SURFACE (Tech Stack)

PATHWAY 2: Build-Up Play (Long Ball Over the Top)

A long ball over the top could achieve the same goal

[9] FIND MISCONFIGURATIONS

Quick misconfiguration checks can either be made on the list of valid subdomains or from the target list. We can check for things like subdomain takeover or CORS misconfiguration etc. depending on the identified platforms.

• ATTACK SURFACE (3rd Party Platforms)

PATHWAY 3: Build-Up Play (Through the Flanks)

Sometimes the flanks provide a better path to move upfield

[2]&[7] DISCOVER PUBLIC EXPLOITS

Going through the left flank, we can use the output of the nmap results in the previous port scan to enumerate running web services (e.g. CMS Version) and search for disclosed vulnerabilities (searchsploit). 

• ATTACK SURFACE (Known Vulnerabilities)

Vulnerability scanners primarily perform this function, which is to identify service/software versions and compare it with a database of known vulnerabilities or use any signature-matching process. However because of the possibility of false positives or negatives, it is always a good idea to manually review vulnerability scan results when possible.

[3]&[11] DISCOVER ENTRYPOINTS

Through the right, we try to gather interesting entrypoints by looking through js files, api calls (e.g get/post requests), url links, old versions of a webpage, web services etc.

• ATTACK SURFACE (ENDPOINTS)

Conclusion

Attack surfaces change all the time from the introduction of new app servers, to changes in the software packages running on them and so on. Therefore it is crucial that different strategies be taken to keep accurate information of an applications attack surface. Today we have looked at enumerating attack surfaces via a typical recon workflow, but beyond identification it is also necessary to do analysis for determining high risk areas based on the different functionalities of the application. To read further on this, I recommend going through the owasp cheatsheet for attack surface analysis: Owasp Attack Surface Cheatsheet.