People tend to imagine an attack beginning with a port scan or a login attempt. Often the first step makes no noise at all, because it happens somewhere else.
Plenty of useful information about your company is sitting in public records, search engines and old web archives. Most of it can be read without touching your website, so it won’t appear in your application logs.
Testers call this passive reconnaissance. Here is what it turns up, and how to look at your own company the same way. Only use these techniques on organisations you are responsible for.
1. Every server you ever got a certificate for
When a public certificate authority issues an HTTPS certificate, it is normally recorded in Certificate Transparency logs. They exist for a good reason: they let anyone spot certificates issued by mistake or by fraud. As the project itself explains, the logs are public and append-only, so entries can’t be deleted or changed.
The side effect is a permanent, searchable list of your hostnames. That includes staging, old-admin, vpn2 and the demo somebody built in 2021, even if nothing links to them.
Try it: search for your domain at crt.sh, using %.yourcompany.com. The service is free and can be slow, so try again if it times out.
What to look for: anything you don’t recognise, and anything that should no longer exist.
2. Which suppliers you use, from your DNS
DNS records are public by design, and they say a lot about how a company runs. One command is enough:
dig +short TXT yourcompany.com
dig +short TXT _dmarc.yourcompany.com
dig +short MX yourcompany.comYour SPF record names the services allowed to send email as you. Verification strings often reveal which SaaS tools you have signed up for. To an attacker, that is a ready-made list of convincing phishing lures: a fake invoice from a supplier you really do use lands very differently.
What to look for: old suppliers still in your records, and a DMARC policy of p=none, which only monitors and doesn’t tell receivers to reject mail that fails the check.
3. Subdomains pointing at nothing
Suppose promo.yourcompany.com once pointed to a hosted landing page. The campaign ended and the hosting account was cancelled, but nobody removed the DNS record.
On some platforms, someone else can now claim that same name and serve anything they like from your domain. This is called subdomain takeover, and it makes for extremely believable phishing.
What to look for: go through the list from step 1. Every DNS record should point at something you still own.
4. What you used to publish
Deleting a page doesn’t delete it from the internet. The Wayback Machine keeps old copies of many sites, including old staff pages, forgotten documents and past versions of JavaScript files. Those scripts can contain API routes and internal hostnames.
What to look for: anything sensitive that was ever public. If it contained a credential, assume that credential is compromised and change it.
5. Your stack, from your job adverts
“Senior engineer, 5 years of Kubernetes, Terraform, Okta and Jenkins.” That’s a useful advert, and it’s also a useful briefing.
Nobody is suggesting you stop describing the job. But an advert that names exact versions and internal tools gives more away than it needs to, and attackers can match those names against known vulnerabilities.
What to look for: specific product versions, and names of internal systems. Say “experience with CI/CD” unless the exact product really matters.
6. Your developers’ public code
Search your company name and domain on public code hosts. You may find an old proof of concept, a personal project with a work configuration file in it, or a script with a hostname and a token. Public commits also reveal names and email addresses, and often your email format too.
A credential found here is especially serious, since deleting a file doesn’t remove it from a repository’s history. We explain that in You deleted the password from Git. It’s still there.
What to look for: your domain, internal hostnames and the word “password” alongside your company name.
7. Your people
Professional networks show who works in finance, who just joined and who is on the IT team. A new starter who doesn’t yet know how IT normally contacts people is a natural target. So is the person who pays invoices.
What to do: you can’t hide your staff, and you shouldn’t have to. Instead, make it safe to be targeted: phishing-resistant logins, a second channel for confirming payment changes, and an easy way to report something odd.
Run this on yourself once a quarter
An afternoon four times a year covers most of the above:
- Export your hostnames from Certificate Transparency and DNS.
- Give each one a named owner, or take it down.
- Remove DNS records that point to services you no longer use.
- Check that SPF lists only current suppliers, and move DMARC towards enforcement.
- Search public code for your domain and internal hostnames.
- Change any credential you find. Don’t only delete it.
The goal isn’t to become invisible, because no business can. It’s to know about your forgotten staging server before somebody else does, since they only need to find one.