Most companies dont actually know what is sitting on their external perimeter. They think they do. There is a spreadsheet somewhere with the main domains and a couple of IP ranges. But then you run a proper scan and find 40 subdomains nobody knew about, three of which point to infrastructure that was decommissioned last year.

We see this constantly. That is basically why we built Recon.

What attack surface management actually is

Your external attack surface is everything an attacker can reach from the internet. Domains, subdomains, IPs, web apps, APIs, cloud buckets, mail servers, VPN endpoints. The stuff you know about and (this is the important part) the stuff you dont.

Attack surface management is finding all of it, keeping track of it, and making sure nothing is quietly sitting there waiting to be exploited. Not once a year during a pentest. Continuously.

Gartner calls it External Attack Surface Management (EASM). We just call it knowing what you have.

Why pentests and vuln scanners dont cover it

We do pentests for clients all the time. They are useful. But a pentest is a snapshot. It tells you what was wrong during that specific week, against that specific scope.

Between one pentest and the next your company might spin up three new web apps, let a certificate expire, have a developer push credentials to GitHub, or acquire another business and inherit all their technical debt. None of that waits for your next assessment.

Vulnerability scanners have a different problem. They only scan what you point them at. If you dont know an asset exists, it doesnt get scanned. We have seen companies with solid vuln management programmes get compromised through a Jenkins instance on a non-standard port that nobody remembered deploying.

Vuln scanning asks “what is wrong with the things I know about?” ASM asks “what do I actually have?” Different questions.

What makes up your attack surface

Subdomains and DNS

Your domain is not just www. It is every subdomain, every CNAME, every MX record. Companies accumulate them like clutter. staging.yourcompany.co.za, old-api.yourcompany.co.za, test-payment.yourcompany.co.za. Each one is a way in.

Dangling DNS is a specific problem. A CNAME pointing to an Azure instance you shut down six months ago means an attacker can claim that resource and serve whatever they want on your subdomain. Subdomain takeover. It happens more than people realise.

Open ports and services

Port 22 with SSH. Port 3389 with RDP facing the internet. Port 9200 with an unauthenticated Elasticsearch cluster. Port 27017 with MongoDB accepting connections from anywhere.

Attackers dont need a zero-day when your database has default credentials on a public IP. That is not hacking. That is just looking.

Certificates

Certificate Transparency logs are public. Every certificate ever issued for your domains is discoverable. That includes the internal-sounding ones like vpn-internal.yourcompany.co.za and admin-panel.yourcompany.co.za.

Expired certs tell an attacker that a service is probably not being maintained. It is a signal.

Cloud

S3 buckets, Azure Blob containers, GCP storage. All potentially public if someone ticked the wrong box. A developer can spin up an EC2 instance with a public IP in minutes. No change control, no firewall request, no entry in the CMDB. It just exists.

APIs

REST APIs, GraphQL endpoints, legacy SOAP services. Often less protected than the front-end apps they serve. Swagger files at /swagger.json or /api-docs that were never meant to be public. We find API endpoints in ASM scans that the clients security team didnt know existed.

OSINT exposure

Employee credentials in breach databases. Metadata in published documents leaking internal usernames. Public GitHub repos with hardcoded API tokens. Job postings that spell out your entire tech stack. (“Looking for an engineer experienced with Kubernetes, Terraform, and AWS EKS.” Thanks for that.)

Third-party exposure

Third-party JavaScript on your website. SaaS platforms with access to your data. Partners with VPN tunnels into your network. Your attack surface extends beyond what you directly control.

How attackers actually map your perimeter

This is roughly what happens when someone decides to look at your infrastructure.

Subdomain enumeration

Passive first. Pull subdomain data from CT logs, search engines, DNS datasets without touching the target at all.

subfinder -d example.com -o subdomains.txt

That single command queries VirusTotal, Censys, Shodan, SecurityTrails, and CT logs. Returns hundreds of subdomains. Zero packets sent to the target.

Then check what is alive:

httpx -l subdomains.txt -status-code -title

Now you can see that staging.example.com returns a 200 with “Jenkins Dashboard” in the title. Nobody in IT knew it was there.

For CT logs specifically:

curl -s "https://crt.sh/?q=%.example.com&output=json" | jq -r '.[].name_value' | sort -u

Port scanning

naabu -l resolved-hosts.txt -top-ports 1000 -o open-ports.txt

Or skip the scanning entirely and just ask Shodan. It has already scanned everything. Search for org:"Your Company" or ssl.cert.subject.cn:"yourcompany.co.za" and see what comes back.

Fingerprinting and vulns

nuclei -l live-hosts.txt -t technologies/ -o tech-stack.txt
nuclei -l live-hosts.txt -severity critical,high -o vulnerabilities.txt

Then checking for exposed .git directories, .env files, backup files, directory listings. The manual stuff that automated scanners sometimes miss.

This whole process takes hours, not days. Automated, it runs continuously. That is what you are up against.

What a decent ASM programme looks like

Automated discovery on a schedule. Daily at minimum. Covering subdomains, ports, cloud assets, certificates. New assets get flagged for review.

Attribution matters. Not everything you find belongs to you. A subdomain pointing to a third-party SaaS, a cloud IP shared with another tenant. You need to figure out what is actually yours.

Prioritisation based on context, not just CVSS. An exposed RDP on a domain controller is more urgent than an info disclosure on a marketing microsite. Same CVSS score, completely different risk.

Alerting when things change. New subdomain appears, port opens, certificate is about to expire, a service version changes. The value is in catching changes, not just building an inventory once.

And feeding it all into your existing processes. ASM findings should create tickets, inform your pentest scope, show up in your risk reporting. If findings sit in a dashboard nobody checks, nothing actually improves.

SA blind spots

Working with companies across South Africa we see the same things. Legacy systems that “still work” and therefore never get turned off. Mergers where Company B’s infrastructure sits untouched for years with its own vulnerabilities. Remote work infrastructure deployed quickly in 2020 and never reviewed since. Cloud adoption without guardrails.

Getting started

Run subfinder against your own domains. Check crt.sh. Look yourself up on Shodan. Check Have I Been Pwned for your email domain. Review your DNS records for stale entries.

Takes a few hours. Compare what you find to what you thought you had. The gap is usually eye-opening.

$ ironsky recon --free-scan yourdomain.com

Where Recon fits

We built IronSky Recon because we kept finding the same problem in our consulting work. Companies with decent security programmes but no idea what was actually exposed. Things that should have been caught months earlier if someone had been watching.

Recon does the discovery, monitoring, and prioritisation automatically. Built by people who do pentesting, so the detection logic is based on how attackers actually work.

If you want a quick version before talking to us, try the free scan.