Cyber Reconnaissance: How Attackers Map Your Public Attack Surface
HTTPS certificates leave a public paper trail. When a website gets a certificate trusted by browsers, the domain names it covers generally enter public Certificate Transparency logs. Retiring a hostname doesn’t erase that record.
The logs exist so site owners and researchers can catch certificates issued without permission. They have another use, though. A security team can discover an old service name that never made it into the current inventory. The name may be obsolete; the team still needs to account for it.
Cyber reconnaissance is research that can happen before an attempted intrusion. The public attack surface includes systems outsiders can reach and potentially interact with. For defenders, public records offer a way to check whether the company’s own list of systems is complete.
Who Owns the Hostname?
MITRE ATT&CK describes reconnaissance as gathering information that may help an attacker plan an intrusion. Public domain records can show names once used for test servers or customer portals. Old documentation may reveal which vendor ran a particular service.
None of that proves a system is reachable today. Ownership can change, and the same IP address may host unrelated companies. A defender comparing these records with an approved asset list should establish which name belongs to the organization before treating it as an exposure.
There is also a firm boundary around the work. Checking public records is different from actively probing a system. Vulnerability testing needs permission from whoever is authorized to grant it.
Your Public Attack Surface Extends Past the Homepage
A company can secure its main website and still leave an old administrative interface reachable. A cloud service might retain access after a project ends. Public APIs also deserve attention, especially when they handle customer information.
OWASP’s attack surface guidance explains why a review needs to consider where systems accept data and what controls protect those entry points. This includes remote access systems and vendor portals, even if nobody advertises them to customers.
CISA’s Internet Exposure Reduction Guidance recommends identifying what is reachable and deciding which services genuinely need public access. The priority is often an unnecessary management interface that could be restricted. Taking the company’s public website offline wouldn’t help.
Compare the Public View With Your Own Records
Asset inventories describe what a company thinks it runs. Public DNS and certificate records may tell a different story. The gap deserves an investigation, particularly when nobody can name the owner of a service that still answers requests.
Start with a public name missing from the current inventory. Ask its former owner what it was used for. If a vendor once managed it, check whether the relationship ended cleanly. For a temporary service, find the retirement record and confirm the related public access was removed.
CISA’s asset visibility directive distinguishes finding assets from checking for vulnerabilities. Although its requirements apply to federal agencies, that distinction is useful to any security team. Discovery provides a lead for the people responsible for the system.
What Public Records Can Tell You About a System
Public records disagree for ordinary reasons. A DNS entry can point to a replacement host while an older certificate still lists the previous name. Service observations may lag behind both. Check what each source recorded and when before treating the results as evidence of a current system.
DNS Can Tell You Who Handles a Service
DNS connects domain names to information a browser or email service needs to reach them. An organization’s public DNS records can reveal which provider handles its email and where a website points today. The records might also mention old names nobody links to anymore.
Check what the record says at the time you find it. A name pointing to a hosting company proves only that the name was configured to point there. It won’t tell you which customer owned the server or whether an application was running.
Why HTTPS Certificates Leave a Public History
In 2011, the Dutch certificate authority DigiNotar issued a fraudulent certificate covering *.google.com. Investigators reported that the certificate had been presented to internet users in Iran. A published investigation of the breach shows how serious a wrongly issued certificate could become. Browsers needed better ways to detect this kind of problem.
Certificate Transparency (CT) gives people a way to monitor publicly trusted certificate issuance. The protocol specification describes logs that anyone can audit. Chrome’s guidance for site operators explains an important side effect: the domain names listed on a public certificate become visible through these logs.
A forgotten subdomain can therefore appear in a certificate record even after the site stops linking to it. The record shows that a certificate was issued for the name. It can’t tell you whether the service is still online. A wildcard certificate, such as *.example.com, can also cover several hosts without listing each one separately.
For a security team, an unfamiliar name is a starting point for checking the inventory. It isn’t proof that somebody left an insecure server running.
A Name in a Log Versus a Service You Can Reach
Certificate records preserve names. Internet exposure databases can report which services were reachable when they observed them. That difference matters when deciding how urgently to investigate a result.
CISA’s exposure reduction guidance discusses services such as Censys and Shodan for finding internet connected assets. Even those observations have dates. A service seen last month might be gone today; a previously unseen management interface could deserve immediate attention from its owner.
Use the public information to decide what the authorized team should verify. An automated discovery result can’t grant permission to probe an unrelated system.
What an Old Repository Can Give Away
A repository can preserve configuration long after the related system disappears. Deployment instructions might name a former hosting provider or an application that the company no longer uses. The commit history tells you what someone wrote at the time; the current asset inventory is needed to establish what’s running.
Exposed credentials are more urgent. A password or API token copied into public source code may continue working even after the latest file is edited. GitHub’s secret scanning guidance explains how repositories can be checked for leaked credentials. Removing a secret from a file doesn’t revoke it. The owner needs to disable or rotate the credential and review what it could access.
Old issue reports can also help identify the team that maintained a service. Preserve the date and source before relying on the reference. A project name repeated across several files may come from one outdated configuration.
The DNS Record That Outlives Its Service
Some old records are harmless. Others need a closer look. A company can delete an application from a cloud provider while leaving a DNS record pointing to the old resource. That leftover reference is called a dangling DNS record.
Depending on the provider and its protections, an abandoned target may become available to somebody else. Traffic intended for the company’s subdomain could then reach content controlled by a stranger. Security teams call that subdomain takeover. Microsoft’s security guidance explains the risk and why DNS cleanup belongs in the service retirement process.
An old hostname appearing in a certificate log doesn’t prove this vulnerability exists. The asset owner needs to verify its DNS configuration and the provider’s ownership protections. Some providers reserve names or require proof of domain ownership precisely to prevent takeovers.
Archived instructions and public repositories may still mention the retired service. Those are useful leads for identifying who once maintained it. Our OSINT Field Guide explains how to check older sources without treating an archived page as a current record.
Who Looks After the Services a Vendor Runs?
An organization might depend on an outside identity provider for staff logins. The application may run entirely on somebody else’s infrastructure, yet access to it still affects the business. Somebody inside the organization needs responsibility for reviewing the relationship and removing access when it ends.
Public information about employees and vendors can help identify whom to ask. It needs checking before it’s included in a security report. A branded sign in page may belong to a third party, while a former employee’s public profile may still display a role they left years ago.
Confirm the relationship with the business owner. A resemblance between two hostnames can waste a lot of investigation time when the systems belong to unrelated organizations.
Two Matching Clues Can Come From One Old Record
A hostname in a certificate log and the same name in a code repository may look like independent evidence. They could both refer to the same abandoned deployment. A public IP address adds another source of confusion because many unrelated websites can share hosting infrastructure.
Find out where each claim originated. Was the asset linked by a current official record? Did both mentions copy the same old document? An AI search summary can make the connection sound more certain than its sources justify. Read the evidence before reporting an organization as the owner.
Bad attribution wastes a security team’s time. It can also lead somebody to scan infrastructure they have no permission to test.
Review Your Own Public Exposure
Start with a domain or service the organization owns. You can compare approved inventory records with public sources before considering any intrusive testing. Keep the investigation within the authorization the team received.
- Find the current owner. Begin with the organization’s actual domain and service records. Note which team or vendor is responsible.
- Compare public evidence. Check relevant DNS records and certificate history. Record where the information came from and when it was observed.
- Resolve unfamiliar names. Find out whether each one belongs to the organization and whether its associated service still exists.
- Decide what should stay exposed. Review public access with the owner. Remove unnecessary access through the approved change process, including DNS records left behind by retired resources.
- Verify the result. Recheck the public evidence where appropriate and document any exposure the business deliberately retains.
This follows the practical approach in CISA’s exposure reduction guidance. Active scanning or vulnerability testing needs its own authorized scope. Public records alone can’t establish whether a system is vulnerable.
Make the Finding Easy for Its Owner to Check
A long spreadsheet of unexplained hostnames can leave the receiving team doing the investigation again. Give the owner the source record and when you found it. Explain why you think the asset belongs to the organization and leave ownership unconfirmed until someone verifies it.
Priority depends on what is exposed today. An administrative interface reachable from the internet may need urgent attention. A hostname seen only in an old certificate could simply need an inventory note. If a service was retired, somebody should confirm that its DNS entry was removed too.
CMX’s infrastructure scaling article covers the operational consequences of systems growing beyond their original ownership arrangements.
Sometimes the Right Finding Is “We Don’t Know Yet”
A certificate log can tell you that a name appeared on a certificate. It can’t answer who operates the service today. If the organization’s own records don’t settle that question, leave it open and ask the person responsible for the domain.
The owner may confirm the service still needs public access. They may find a DNS record pointing to a resource that was deleted. If nobody can establish who controls the name, record that uncertainty and continue through the authorized channels. An unverified hostname doesn’t deserve a made up risk rating.
For the research methods behind this kind of verification, our OSINT Field Guide goes into more detail.
