What an attacker learns
about your business
in the first 10 minutes.
Before anyone touches your login page, sends a phishing email, or runs a single exploit — they spend time learning everything publicly available about you. Your DNS records. Your mail server. Your staff names and email patterns. Your technology stack. Your social handles. All of it, gathered passively, without triggering a single alert. Here is exactly what that looks like.
Most security conversations start at the attack — the phishing email, the ransomware, the breach. What rarely gets discussed is the hour before any of that happens. The reconnaissance phase. The part where an attacker builds a complete picture of your business using nothing but publicly available information — and you never know it is happening.
This phase has a name in the security community: OSINT — Open Source Intelligence. It is the systematic collection of information from public sources. No hacking. No exploits. No illegal access. Just a structured process of gathering what you have already made available, whether you intended to or not.
Every business with a website has an OSINT footprint. The question is not whether you have one — it is how much it tells an attacker and whether you have ever looked at it from their perspective.
The 10-minute reconnaissance timeline
// What actually happens, in orderWhat a DNS record actually reveals
// Chapter 01 — Reading your own infrastructure mapDNS records are designed to be public — they are how the internet knows where to send traffic for your domain. But the information they contain goes far beyond "this domain points to this IP address." A full DNS query on a typical business domain reveals the following:
That output — from a completely passive DNS query — tells an attacker that this business uses SendGrid for transactional email, Mailchimp for marketing, Zoho for business email, and Freshdesk for customer support. It also tells them the mail server is self-hosted on a subdomain that bypasses Cloudflare. And it tells them there is no DMARC record — meaning they can send emails that appear to come from this domain with no technical barrier.
None of this required touching the website. No request was logged. No alert was triggered. This is public information that any DNS lookup tool can retrieve.
What your social footprint reveals
// Chapter 02 — What you are giving away without knowing itThe social footprinting phase is where reconnaissance becomes personal. DNS records tell an attacker about your infrastructure. Social footprinting tells them about your people — which is where most successful attacks actually land.
From that output, an attacker now knows: the developer's full name and email address, the exact technology stack the business runs on (AWS, Firebase, Node.js, Stripe), that there was a recent production deployment (potential instability window), and — most damaging — that a `.env` file was committed to GitHub at some point. Even if the file was deleted, it remains in the Git history and is fully recoverable.
That `.env` file almost certainly contained API keys, database credentials, or Stripe secret keys. Deleted from GitHub does not mean gone from GitHub.
git log --all --full-history -- "**/.env" on any public repository to find deleted environment files. This is one of the first things professional security researchers check — and it is one of the most commonly found vulnerabilities in vibe-coded projects pushed to public repositories.
What this looks like for a vibe-coded project specifically
// Chapter 03 — Why AI-built sites carry extra exposureVibe-coded projects carry a specific set of reconnaissance vulnerabilities that traditionally-built projects do not, because of how they are typically developed and deployed.
Public GitHub repositories as the deployment pipeline. Many vibe coders push directly to a public GitHub repository that serves as their GitHub Pages host. That repository contains the full commit history, the build process, often the project structure, and sometimes credentials that were committed before a `.gitignore` was properly configured.
Technology stack visible in source. The Tailwind CDN script tag. The Firebase configuration object in the JavaScript. The Formspree form ID. The Google Analytics measurement ID. All of these are publicly visible in your page source and each one tells an attacker something about your infrastructure. The Firebase configuration object specifically contains your project ID and API keys — and while the API keys themselves are meant to be public, a misconfigured Firestore security rules file can allow anyone with those keys to read or write your entire database.
No security headers. As discussed in previous articles — missing `Content-Security-Policy`, `X-Frame-Options`, and `X-Content-Type-Options` headers are instantly visible to any scanner and tell an attacker that the site was deployed without a security review.
What you should check right now
// Chapter 04 — Your own reconnaissance auditRun this on yourself before someone else does. All of these tools are free and publicly available — which is exactly why attackers use them.
| What to check | Tool | What you are looking for | Risk |
|---|---|---|---|
| DNS records | mxtoolbox.com or dnschecker.org | Self-hosted mail servers, missing DMARC, SPF exposing your full SaaS stack | HIGH |
| DMARC policy | mxtoolbox.com/dmarc.aspx | Missing or p=none DMARC — means your domain can be spoofed | HIGH |
| GitHub commit history | GitHub search or git log | Deleted .env files, API keys, database URLs in old commits | HIGH |
| Subdomain exposure | crt.sh (certificate transparency) | Forgotten dev, staging, or admin subdomains | HIGH |
| Security headers | securityheaders.com | Missing CSP, X-Frame-Options, HSTS, Referrer-Policy | MEDIUM |
| Technology stack | wappalyzer.com or page source | Outdated frameworks, exposed version numbers, server headers | MEDIUM |
| Staff breach exposure | haveibeenpwned.com | Staff email addresses appearing in known breach databases | HIGH |
| Origin IP exposure | censys.io or shodan.io | Origin server IP visible — Cloudflare bypass possible | MEDIUM |
| Social footprint | LinkedIn + Google | Email patterns, staff roles, technology mentions, travel patterns | VARIES |
The three fixes that matter most
// Chapter 05 — Start here
Add a DMARC record. A missing DMARC record is the single most impactful gap for most South African small businesses. Add a TXT record to your DNS: _dmarc.yourdomain.com with value v=DMARC1; p=quarantine; rua=mailto:[email protected]. Start with p=quarantine rather than p=reject until you have confirmed all legitimate email sources are in your SPF record.
Audit your GitHub commit history. If you have ever pushed a project to a public GitHub repository, run a search for credentials in the history. GitHub's secret scanning will flag some automatically — but not all. Search for patterns like FIREBASE_, STRIPE_, DATABASE_URL, API_KEY in your commit history. If you find any, rotate the credentials immediately — even if the commit is deleted.
Check crt.sh for your domain. Go to crt.sh, search for your domain, and review every subdomain that has ever had a certificate issued. Each one is a potential entry point. If you find subdomains you did not know existed — or ones that should not be public — investigate immediately.
Vibe Coder's Playbook
The reconnaissance phase described in this article is legal, passive, and completely undetectable. Every tool mentioned is publicly available. Every data source is public by design. The information is there whether you look at it or not — the only question is whether you see it before someone with different intentions does.
Run the audit on yourself this week. Fix what you find. Then think about what comes after the reconnaissance phase — because that conversation is longer and the stakes are higher.
