For the past three years, the Bishop Fox engineering team has been tackling a number of emerging challenges in the offensive space and developing technology that amplifies their security capabilities. Most people, however, don’t even know that Bishop Fox has an engineering team.
In an effort to share our learnings with the security community and invite meaningful discussions, we wanted to introduce a new blog series, Inside Engineering, where we will talk about the problems we’re solving, the obstacles we’re facing, and the new technology we’re building.
To kick things off, the first three posts will walk you through our experiences developing a new methodology to identify the modern attack surface.
Why Develop a Whole New Methodology to Gain Visibility Into the Modern Attack Surface?
While there are innumerable open-source intelligence (OSINT) tools and data sources for discovering domains and subdomains, scanning ports for exposed services, and fingerprinting tech stacks, we weren’t able to find a suitable model that could synthesize all those results and recognize which digital assets should be prioritized as targets. So we decided to build a new framework.
Our approach now unites existing technologies into a codified, modern representation of the attack surface. But this first post of three will begin at the beginning with the first asset and target models we developed and the lessons we learned along the way.
As with designing any model, we first developed a set of principles to guide how we map an effective, representative attack surface that could be continuously discovered and updated. We decided that the model must be the following:
Reliable and Scalable. We intend to perform discovery at scale, so the framework must support scalable ingestion of large amounts of data - typically in a short, daily window. By our estimates, the system would need to ingest approximately 10 million data elements in 6 hours to be considered useful.
Consistent. As we intend to incorporate insights from different perspectives on the modern attack surface, we need to ensure that the data tells a consistent story. In order to scale our efforts, we perform discovery against subdomains and scanning against targets independently. The resulting data sets can be greatly affected by constantly changing DNS records. We need to ensure that our understanding of a subdomain’s IP addresses reflects scans against the same IP addresses for associated targets.
Precise. We intend to provide a well-defined representation of the modern attack surface. Because security tools and data sources are not inherently accurate, up-to-date, or definitive, our framework must be flexible enough to layer the benefits of many scanning and collection techniques. For example, we discover and aggregate subdomains from several data sources to precisely identify the scope of the attack surface.
While our principles defined our destination, outlining our challenges helped us choose which routes to take in our preliminary activities.
From past experiences developing security tools (notably Search Diggity), we anticipate certain obstacles we need to account for as we develop our model. Namely, the following:
We kept these challenges in mind as we developed our technology and continually tested our framework to ensure it would give us a reliable, scalable, and comprehensive view of the modern attack surface.
In our first model, our goal was to identify the entire attack surface. We chose to start by testing the following hypothesis:
If we include subdomains in the representation of an organization’s attack surface, we can discover major gaps in the modern attack surface.
Many companies have subdomains open to the internet that they are not aware of. And because they don’t have visibility into those subdomains, they are unable to secure them. Our professional services group has often found security risks during finite assessments that other testers have missed because they didn’t review the entire attack surface, including subdomains.
As a first step for mapping our external attack surface, we focused on finding all subdomains and CIDRs – including those served by serverless, cloud, and rapidly changing or fraudulent hosts. In other words, we wanted to ensure that our tool saw every potential attack surface or subdomain that a threat actor could put in place.
In order to test our first hypothesis, we need our framework to represent targets originating from both subdomains and network ranges (CIDRs). An example HTTP target to a subdomain is
http://www.bishopfox.com:80. An an example RDP target to a CIDR is:
As illustrated in the diagram below, we developed a pipeline for automating the collection and aggregation of our targets:
FIGURE 1 - The first attack surface pipeline for continuously discovering targets
We were pleased with the results of this first iteration. In a wide variety of testing environments, we were able to see all targets (both subdomains and CIDRs) associated with the organization within a matter of hours. We cross-referenced these targets through significantly intensive manual efforts to learn that, not only had we identified all targets, but we were able to replicate the testing to ensure consistent and reliable results.
While this first iteration showed enormous potential to efficiently collect a comprehensive picture of an organization’s digital attack surface, we knew we could do better. The lessons we learned translated into three areas of focus for future improvements:
Through this iteration process, the engineering team has arrived at an accurate and holistic view of our clients’ businesses and provided a framework for them to operationalize that information.
But since this first iteration left us room to improve, the next Inside Engineering blog post will walk through how we used the lessons from the first approach to refine our framework with new applied techniques and perspectives.