What an attacker learns about you before touching anything
Before anyone touches a system they read what you already published. Certificate logs, job adverts, document metadata. Here is how to audit your own exposure the same way.
Nothing happens to you
Every serious intrusion starts with a period where nothing happens. No scan, no login attempt, no email. Just reading.
By the time anyone goes near a system, they can know your mail provider, your VPN vendor, the format of every employee's email address, which staging server nobody has patched since it was built, and the name of the person who authorises payments. None of that comes out of your network. It comes out of certificate logs, DNS records, job adverts, and PDFs you published on your own website.
Reconnaissance is not an attack on your systems. It is somebody reading what you already published, all of it at once, in one sitting.
There is no alert for this, because nothing was done to you. Which means the only way to know what it produces is to run it against yourself. That is what the rest of this is: the sources, what each one gives away mechanically, and how to read your own.
Your DNS is a vendor list
Three queries describe most of a company's email posture.
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
The MX records name your mail provider. The TXT records are worse, because domain verification strings accumulate and nobody ever removes them — google-site-verification, atlassian-domain-verification, a DocuSign token, an old MS= from a tenant you migrated off. Each one names a system where your staff have accounts.
Then the two lines that decide the shape of the attack:
"v=spf1 include:_spf.google.com include:mail.zendesk.com include:spf.mandrillapp.com ~all"
"v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The first says which third parties can send as you. The second says: nothing spoofing this domain will be rejected. p=none is a monitoring mode, and it is where most domains stop. That single field is the difference between an attacker spoofing your exact domain and having to register a lookalike one — and spoofing the real domain works far better, because it survives the check most people actually do, which is looking at the sender.
Certificate logs, and the hosts you forgot
Since 2018 Chrome has refused publicly trusted certificates that were not logged in Certificate Transparency. That mechanism is the reason misissued certificates get caught. The price is that every hostname you have ever certified is in a public, searchable, permanent index. crt.sh?q=%25.example.com returns it in a second.
What comes back is rarely the marketing site. It is vpn-test, jira, hr-portal, staging-api, backup-owa. Names that describe function, on hosts built by someone who has since left.
Add passive DNS — historical resolution data collected by resolvers and sensors elsewhere on the internet — and internet-wide scan datasets, and you get something uncomfortable: a third party has already scanned your perimeter, catalogued the banners, and published it. An attacker reads that instead of scanning you. Nothing hits your logs.
Forgotten hosts are the target for one reason. They are outside the patch cycle, outside the monitoring, and outside anyone's mental model of the estate. The asset you do not know about cannot be the asset you maintain.
Job adverts are the richest source there is
Nothing else comes close, and the reason is structural: a job advert is written by someone whose incentive is to be specific. Vagueness costs them candidates. So they publish the stack.
Reporting to the Head of Financial Operations. You will own month-end
close in NetSuite and the weekly payment run. Experience with FortiGate,
Splunk ES and Okta required. We are mid-migration from on-prem Exchange
to Microsoft 365.
Four lines. That is the firewall vendor, the SIEM, the identity provider, the finance system, one edge of the org chart, and the fact that two mail systems are live at once — which is the period when mail routing rules are messy and a rule that forwards externally is least likely to be noticed.
Two more signals people miss. A role reposted three times means the team is short-staffed, and short-staffed teams answer alerts slowly. And a recruiter's own address on the posting confirms the email format for the whole company, which turns a list of names into a list of working addresses.
The org chart, rebuilt
You cannot hide who works for you. Staff list themselves, with titles and reporting lines, because that is what a career profile is for. Add conference speaker bios, press releases, procurement notices, regulatory filings, the "our team" page, and a webinar recording where somebody says "I'll pass that to Amal on the treasury side." Combine it with the email format, and the chart is rebuilt.
This is what makes business email compromise work, and it is worth being precise about why. BEC does not need malware or a stolen password. It needs four facts: who can move money, who that person accepts instruction from, when that person is unreachable, and what a normal request looks like. All four are public. The last one comes from your own published invoices and vendor announcements. The third comes from a conference photo posted the same morning.
So the message that lands is not "urgent wire transfer." It is a short note in the right register, from the right superior, about a supplier you genuinely use, during a week that superior is genuinely away.
The defence is not detection. It is making the process independent of the chart: payment changes verified out-of-band on a number you already held, and a standing rule that authority never arrives by email, no matter how correct the email looks.
Working in the open
Public repositories give away more than the occasional leaked key.
git log exposes committer addresses, which confirms the naming convention. The organisation's member list maps to employees. Workflow files name cloud account IDs, role ARNs, and internal registry hostnames. Dependency manifests point at private package indexes. Issue threads contain pasted stack traces with internal paths and machine names.
And one fact that surprises people: deleting does not retract. A secret force-pushed out of history usually remains reachable by its commit SHA, and forks keep their own copies of objects. If a credential was ever public, rotate it. Removing the commit is not rotation.
The file remembers the machine
Every document you publish carries a description of the computer that made it.
exiftool -Author -Creator -Producer -CreateDate quarterly-report.pdf
Author : a.hassan
Creator : Microsoft Word for Microsoft 365
Producer : Acrobat Distiller 21.0 (Windows)
Create Date : 2026:03:11 09:42:07+02:00
The Author field gives the username convention — a.hassan, first initial and surname. That one field turns your staff directory into a list of probable usernames. The rest gives the office suite, a Windows fleet, and software versions old enough to guess at a patch level. Office files carry the same in docProps/app.xml and core.xml, including who last saved the document.
Photographs carry EXIF: GPS coordinates, timestamps, sometimes camera serial numbers linking images across accounts. Screenshots are worse than photos, because they are read for their content and published without being looked at — internal hostnames in a browser bar, a filesystem path, an unredacted second monitor.
Breach data, read passively
Old breach corpora are not used for cracking, mostly. They are used for confirmation: which addresses exist, what the format is, which staff registered work email at consumer services, and who reused a password somewhere else. That ranking is how a target list gets ordered — reuse is the highest-yield property a person can have.
You cannot delete your data from a dump. You can make it inert: unique passwords, and phishing-resistant second factors so that a valid password is not sufficient.
Audit yourself the same way
None of the passive methods require permission, because none of them touch anything. Run them on your own organisation quarterly.
| Source | What it hands over | Check it yourself |
| --- | --- | --- |
| DNS TXT and SPF | Every SaaS vendor you use | dig +short TXT example.com |
| DMARC | Whether spoofing you works | dig +short TXT _dmarc.example.com |
| Certificate Transparency | Every hostname you certified | crt.sh?q=%25.example.com |
| Passive DNS and scan data | Hosts you forgot you own | Look yourself up in public scan indexes |
| Job adverts | Stack, versions, reporting lines | Read your last ten as an attacker would |
| Published documents | Usernames, software versions | exiftool across your whole site |
| Public repositories | Addresses, paths, account IDs | Search your own org, and its forks |
| Breach corpora | Which staff reuse credentials | Have I Been Pwned, domain search |
Fix what is cheap: strip metadata at publication, remove stale DNS verification records, move DMARC to enforcement, retire hosts instead of leaving them certified. Then write down what is left, because that list is what an attacker will be working from.
What you cannot remove
Most of this is not fixable, and pretending otherwise wastes the effort. Certificate logs are append-only by design. Your staff will keep public profiles. Your job adverts have to be specific or you will not hire. The org chart will be rebuildable.
The goal was never invisibility. It is that the reconnaissance produces nothing you did not already know about yourself, and that nothing important — a payment, an access grant, a password reset — depends on any of it staying secret. Recon does not fail because it found little. It fails because what it found was not worth anything.