External IP Discovery and Open Ports

What it is

External IP discovery is the systematic identification of all internet-facing assets owned or operated by an organisation, along with the network services running on them. The output of a thorough discovery looks like a long table:

• IP addresses and IP ranges
• Hostnames and DNS records pointing to those IPs
• Open TCP and UDP ports
• Service banners (the application identifying itself when you connect)
• Inferred technology stack (web server, framework, CMS, CDN)
• Geolocation, ASN, and hosting provider

This sounds straightforward when you have ten servers in a single data centre. It becomes hard quickly. A modern enterprise may run workloads across three cloud providers, a dozen SaaS platforms, several third-party hosting arrangements, and any number of vendor-managed properties. Each one of those can spin up new public endpoints without security being aware.

Discovery is the foundation of every other external security control. Vulnerability scanning, certificate management, DNS hygiene, and threat exposure all depend on a current inventory. If discovery is wrong, everything built on top of it is wrong too.

Why it matters

The single most consistent finding across attack surface programmes is that organisations underestimate how many internet-facing assets they own. The typical first scan turns up 30 to 50 percent more than the team expected. Sometimes more.

The business stakes are real:

• Forgotten servers. Old marketing campaign servers, test environments left exposed, decommissioned applications that were never actually decommissioned. Each is a potential entry point.
• Shadow IT. A business unit signs up for a SaaS tool, which provisions a custom subdomain pointing at a public endpoint nobody on the security team has seen.
• Mergers and acquisitions. Acquired companies arrive with their own attack surface, often poorly documented. The first six months after an acquisition are statistically rich in breach incidents.
• Cloud sprawl. A developer spins up an EC2 instance for a quick test, opens port 22 for convenience, and never tears it down. The instance lives for years.
• Inherited cloud IPs. Public IPs in cloud providers are recycled. The previous tenant's reputation, listings, and sometimes leftover DNS records come with them.

Many breaches in the past five years trace back to assets the victim either did not know they owned or had forgotten about. The 2019 Capital One incident, the 2021 Microsoft Exchange wave, and a long list of less famous incidents all involved exposed services that better discovery would have surfaced.

How attackers exploit it

The attacker's reconnaissance against a target organisation is largely a discovery exercise of the same kind defenders run, just done with more enthusiasm and fewer scruples about scan rates.

A typical workflow looks like:

1. Enumerate the organisation's domains. Starting from the obvious one and expanding through certificate transparency logs, brand portfolio, and trademark filings.
2. Resolve every DNS record. A, AAAA, CNAME, MX, and historical records via passive DNS sources.
3. Map IPs to ASNs and hosting providers. Identify which ranges to focus on.
4. Scan ports. Tools like masscan and zmap can scan the entire IPv4 space in under an hour. A targeted scan against a specific organisation finishes in minutes.
5. Banner grab. For every open port, pull the service identification string. Most services announce themselves freely.
6. Fingerprint applications. HTTP responses, TLS certificate details, and protocol-specific quirks reveal the underlying technology stack.
7. Cross-reference with vulnerability databases. Old versions of jQuery, exposed admin panels, default credentials, and known CVEs become the target list.

Public services like Shodan, Censys, FOFA, and ZoomEye continuously index this data. An attacker can search for "all instances of vulnerable software X within the IP ranges of company Y" in seconds. The defender has to be everywhere. The attacker just needs to find one weak spot.

How to detect it

Discovery is not a one-off project. It is a continuous practice. The detection methods that hold up over time are:

• Active port scanning. Periodic scans across known ranges plus organic discovery into adjacent ranges. Modern tools do this at speed without significant impact on target services.
• Passive DNS analysis. Historical DNS data reveals subdomains and IP changes that current DNS no longer shows. Useful for finding orphaned records and dangling endpoints.
• Certificate transparency monitoring. Every public TLS certificate is logged in CT logs. New certificates issued for your domains, subdomains, or related properties show up here within minutes.
• Cloud account inventory. Direct API queries against AWS, Azure, GCP and other providers are the most reliable way to enumerate cloud workloads. Discovery tools that do this with read-only credentials catch what external scanning misses.
• Internet-wide scan databases. Shodan, Censys and similar services maintain a public index of every reachable port on the internet. Using their data alongside your own scans accelerates discovery.
• DNS provider integrations. Pulling zone data directly from Route 53, Cloudflare, Azure DNS and others gives ground truth on what your DNS infrastructure actually contains.
• WHOIS and ASN data. For larger organisations, ASN ownership is a fast way to identify ranges.

The key signals to watch for are:

• New IP addresses appearing within your owned ranges
• Newly opened ports on existing IPs (a service that opened up since the last scan)
• Banner changes (a service that changed software or version)
• New subdomains in CT logs
• Hosts responding from cloud accounts you did not know you had

Each of these can be the first hint of either legitimate change or something accidentally exposed.

How to remediate

When discovery surfaces something unexpected, the response is less about technical remediation and more about disposition. The questions to answer for every newly discovered asset are:

1. Do we own this? If unclear, trace it back through DNS, hosting account, payment records, and team interviews. Sometimes assets belong to a vendor or a former employee.
2. Is it intentional? Some exposures are by design (the public website is meant to be public). Some are not (the database admin port was meant to be VPN-only).
3. Is it secure? For intentional exposures, verify the service has appropriate authentication, current patching, and configuration hardening.
4. Should it exist at all? Many discovered assets fail the "is this still needed" test. Decommissioning is the safest remediation.

Concrete steps for common findings:

• Forgotten dev or test servers. Take them offline. Document why. Add to decommissioning checklist for future projects.
• Open management ports (SSH, RDP, database ports) on public IPs. Restrict to VPN, bastion host, or specific source IPs at minimum. Better yet, do not expose them at all.
• Outdated services. Patch immediately if reachable. If patching is not possible, segment behind a WAF or restrict access.
• Default credentials or exposed admin panels. Change credentials, restrict access, audit recent activity.
• Exposed cloud storage. Apply least-privilege ACLs. Audit historical access.
• Unowned assets. Confirm ownership. If they belong to a vendor, request remediation or removal under contract.

Best practices

• Maintain a single source of truth for external assets. Spreadsheets become outdated within weeks. A continuous discovery feed integrated with asset management is the only way to keep up.
• Run external discovery at least daily for the major data points. New subdomains, new IPs, new ports. Slower cadences miss high-priority changes.
• Cover IPv6. Many organisations focus their discovery on IPv4 and ignore the v6 space. Cloud workloads increasingly default to dual-stack.
• Watch for newly registered DNS records on existing parent domains. A new subdomain on your primary domain is either a legitimate launch (which security should know about anyway) or an accident (which security definitely needs to know about).
• Treat the inventory as living. Every quarter, review assets that have not been touched in twelve months. They are usually candidates for decommissioning.
• Integrate discovery into change management. New cloud accounts, new vendors, new acquisitions should trigger discovery cycles, not be discovered by accident later.
• Make ownership explicit. Every asset has a business owner. Without ownership, when something breaks or needs patching, no one is accountable.