Nearly half of Ransomware attacks exploit vulnerable internet-facing services to get the first foot into an organization.

When it is not ransomware, attackers compromise internet-facing machines for crypto mining, data theft, participate in DDoS attacks or serve as a relay for future attacks.

The major issue that organizations are currently facing with Cloud adoption and the post-covid era, is the increase in infrastructure complexity spreading across multiple clouds and SaaS providers.

Being aware of an organization's attack perimeter is a daunting task and has become the number one priority of CISOs across large organizations. Some even resolve to tactics like tracking credit card purchases to identify unknown cloud or saas deployments.

This article goes over the technical implementation of Ostorlab new attack surface discovery capabilities that has yielded on average an increase in over 400% of known organization infrastructure.

These include forgotten or missing acquisition infrastructure that was either not decommissioned or not migrated, it includes unaccounted for dev and production machines that were lost during internal restructuring or staff change.

These environments suffered from critical vulnerabilities like Weak Credentials, domain hijacking, Remote Code Execution vulnerabilities, or service session hijacking due to inappropriate cookie session scoping.

What is an attack surface?

So first of all, what composes the attack surface of an organization. This includes anything an organization owns from IP addresses, domain names, Source Code Repos, SaaS service Accounts, Mobile Applications, API endpoints, and the list goes on.

Any of these can be and has been leveraged by attackers to compromise an organization, from leeky credentials. RCE vulnerabilities, weak credentials to domain hijacking vulnerabilities.

Attack surface techniques are limited to domain enumeration, as is commonly done only to look at a limited portion of the problem.

So how do I map my attack surface?

Attackers love to look at where no one's looking, if you check any of the bug bounty public content, you will be surprised with the wealth of techniques used to find these dark spots, from acquisition listing, Wayback machines, reverse lookups, analytics ID searches, and the list goes on.

Funnily often found environments are out of bug bounty scope, leaving attackers plenty of space to do their damage.

To enable exhaustive coverage, Ostorlab has implemented every trick in the book to generate a billion-wide graph of the internet mesh and its hidden connection.

Some of these are available as part of open-source tools like Subfinder, Amass, Nmap, Wappaylzer, Whatweb, and Dnsx, and we have also open-sourced several new ones that help with correlating these tools to provide truly an unparalleled coverage.

Using these tools combined allows for:

• Subdomain enumeration with brute force
• Subdomain enumeration using public resources, like transparent certificate databases, malware domain trackers, public
• crawler listings, internet archives, and so on
• Domain Whois Mapping and reverse lookup
• DNS lookup and reverse lookup
• Acquisition listing
• IP Whois and BGP ASN lookup
• Analytics ID collection and correlation
• Technical Stack collection and correlation
• IP Geolocalisation and distance correlation
• Mobile Apps listing and link extraction

These techniques have resulted in the generation of multi-billion graph nodes that are constantly growing, detecting more connections, domains, and their hidden links, some even yielding millions of confirmed owned assets.

If you would like to combine these techniques and use them with open-source security scanning tools like Nuclei, Openvas, or tsunami, you can use the following agent group definition by Ostorlab to perform DNS enumeration, IP resolution and pipe it automatically into your favorite network or scanning tools.

kind: AgentGroup
description: Grouping of 6 agents.
agents:
  - key: agent/ostorlab/nmap
  - key: agent/ostorlab/tsunami
    args: [ ]
  - key: agent/ostorlab/openvas
    args: [ ]
  - key: agent/ostorlab/nuclei

oxo scan run --install -g agent_group.yaml ip 8.8.8.8 8.8.4.4

You can also tweak these by increasing the number of running instances of these tools for faster coverage.

kind: AgentGroup
description: Grouping of 6 agents.
agents:
  - key: agent/ostorlab/nmap
    replicas: 10

Most of these agents accept arguments to tweak their behavior, like setting the default Nmap ports or changing the list word to use in the DNS brute-forcing

kind: AgentGroup
description: Grouping of 6 agents.
agents:
  - key: agent/ostorlab/nmap
    replicas: 10
    args:
      - name: ports
        type: string
        description: List of ports to scan.
        value: '22,443,80'

In the next part we will go through the algorithm iterations we used to increase the accuracy in detecting known assets, also go over efficient data storage to efficiently apply these algorithms on this scale, and finally go over the challenge of visualizing this data in a human intelligible format, especially for very large organizations.