Most business owners assume that unless an attacker is actively targeting them, there's nothing to see. That's not true. The public internet is full of data about every organization — data that attackers gather as the first step of any operation, long before they decide what to do. Understanding what they see is the first step to deciding what to close.

DNS Records: The Infrastructure Map

Every domain has DNS records — information about which IP addresses, mail servers, and subdomains belong to your organization. This data is public and queriable by anyone. You can't hide it by making it private; it's fundamental to how the internet works.

What attackers learn from DNS:

• IP ranges you own — Your DNS records reveal the IP addresses your infrastructure lives on. Attackers can then scan those ranges for open ports, exposed services, and forgotten servers.
• Mail server locations — MX records show your mail providers. Many companies don't realize they've exposed their entire email infrastructure through DNS.
• Cloud provider fingerprints — DNS records for AWS, Azure, and GCP resources often reveal which cloud platforms you use, which regions, and sometimes which account IDs.
• Subdomains — Things like dev.yourcompany.com, staging.yourcompany.com, admin.yourcompany.com, or vpn.yourcompany.com. These are often less secured than the main site.

Certificate Transparency Logs: Subdomains You Forgot

Every time a certificate is issued for your domain — even for a dev server that only existed for two weeks three years ago — it's recorded in public Certificate Transparency (CT) logs. These logs are searchable by anyone, and they never expire.

The result: any subdomain that ever had a SSL/TLS certificate is permanently, publicly discoverable. That old staging server you decommissioned? The dev environment you spun up for a hackathon? The internal tool you set up with a Let's Encrypt certificate? All in the logs, forever.

Search for your domain at crt.sh and see what comes up. If you're surprised by anything, so will an attacker.

WHOIS Data: Your Organization's Business Card

When a domain is registered, the registrant's information goes into the WHOIS database — a public record of who owns what domain, when it was registered, and how to contact them. For many businesses, this reveals:

• Business name and legal entity
• Physical address and phone number
• Names and email addresses of technical and administrative contacts
• Creation date (revealing how old the business is)
• Nameservers (which can reveal infrastructure details)

Privacy services exist to mask this information, but they cost extra and many businesses don't use them. Even with privacy enabled, registration dates and nameservers are often still visible — and those reveal plenty.

Exposed Ports and Services: The Entry Points

Once an attacker knows your IP ranges and subdomains, they run port scans. This maps what's exposed to the internet — and it's often more than businesses expect.

A single exposed admin panel on a forgotten staging subdomain — with a weak password — has been the root cause of multiple major breaches. It's not glamorous, but it works.

LinkedIn: The Human Attack Surface

People are the softest part of any organization. LinkedIn reveals:

• Organizational structure — Who works in IT, who manages infrastructure, who has admin access to systems
• Technology choices — Job postings for "Senior AWS Engineer" or "Windows Server Administrator" tell attackers exactly what cloud platforms and OSes you run
• Vendor relationships — Employees mentioning third-party tools and vendors reveals your supply chain
• New hires and org changes — A new employee in IT with no training yet is a prime spear-phishing target

LinkedIn isn't "bad" — it's just public information. Attackers use it to craft convincing phishing emails ("Hey, it's Mike from IT, reset my password") and to identify who has access to what systems.

GitHub: The Code That Left the Building

Public GitHub repositories and commits are one of the most underappreciated sources of exposed credentials and system information. Security researchers routinely find:

• API keys and secrets — Developers accidentally commit AWS keys, Stripe tokens, database passwords, and JWT secrets into public repos
• Internal hostnames — Code references internal service names, staging environment URLs, internal API endpoints
• Architecture details — README files and architecture diagrams describe system design
• Employee names and emails — Commit history ties code to individuals, enabling targeted attacks
• Old credentials — Even credentials that have been rotated stay in git history forever

GitHub's secret scanning catches some of this, but not all of it. Organizations should assume anything ever committed to a public repo is permanently discoverable — even after deletion.

Have I Been Pwned: Credentials Already Exposed

HaveIBeenPwned.com aggregates data from hundreds of breaches. Searching your corporate domain there shows whether any employee email addresses appear in breach data — and what types of credentials were exposed.

The critical point: most people reuse passwords. If an employee's corporate email appears in a breach with a password, attackers will try that email/password combination on corporate services — VPN, O365, cloud apps. It's called credential stuffing, and it's effective because password reuse is everywhere.

Why "Security Through Obscurity" Doesn't Work

Some organizations believe that if something isn't widely known, it's safe. They use obscure internal naming conventions, hide dev servers behind non-standard ports, or assume "no one will think to look there."

This fails because:

• CT logs are permanent — Any hostname that ever had a certificate is in a public database. You can't remove it.
• DNS is public — All your hostnames and IP ranges are queryable by anyone with an internet connection.
• Tools automate discovery — Subdomain enumeration tools scan millions of records automatically. Your "obscure" hostname will show up in seconds.
• Attackers don't guess — They use wordlists of common subdomain patterns, internal codenames, and permutations of your brand name to find things you think are hidden.
• Breach data is searchable — Employee credentials are already out there. The question is whether attackers can use them.

The only security that works is security that assumes attackers can see everything public about your organization — and designing your defenses accordingly.

What to Do: Your Quarterly Audit Checklist

The Bottom Line

Attackers start with public data. They don't port-scan you until they know what you're running. They don't phishing your employees until they've built a profile. The recon phase is where they decide if you're worth attacking at all — and most of that recon is just reading public information.

The good news: it's fixable. You can audit your DNS, lock down your CT log exposure, remove exposed admin panels, and clean up your public code footprint. You can't unring the bell on breached credentials — but you can stop those credentials from working by enforcing unique passwords and MFA everywhere.

Do the audit. Know what they see. Close what needs closing.