By Xhield Team · June 10, 2026 · 8 min read
Tags: Pre-VAPT Attack Surface Reconnaissance OSINT Penetration Testing
Hook
A pentester opens their laptop. They type one command. Within seconds, your company's entire subdomain structure is on their screen — and they haven't signed the engagement letter yet.
Most organisations spend months preparing for a VAPT: selecting a vendor, defining scope, signing NDAs, aligning stakeholders. Meanwhile, an attacker — or the pentester themselves — can map your attack surface in under half an hour using only publicly available data. No credentials. No access. No warnings.
This post walks through exactly what a pentester sees in those first 30 minutes, tool by tool, finding by finding — and what it means for your real security posture.
A pentester begins passive reconnaissance — gathering intelligence before a single packet is sent to your network.
1. Why the first 30 minutes matter most
The recon phase of a pentest is passive. No login attempts, no port scans, no exploit payloads — just open-source intelligence gathering from data your organisation has already made public, often without realising it.
This phase matters disproportionately because it sets the scope for everything that follows. A wider, more accurate picture of the attack surface means more findings, more accurate risk assessment, and a report that reflects reality rather than what the security team thought existed.
Here's the uncomfortable truth: most enterprise VAPT scopes are defined by what the internal team believes exists. Unknown subdomains, forgotten cloud environments, shadow IT, third-party integrations — none of these make it into the scope document. That gap is where critical vulnerabilities live.
The typical enterprise attack surface: what the security team documents is only part of what an attacker maps.
2. Minutes 0–10: domain and subdomain enumeration
The first thing a pentester does is find every domain and subdomain associated with your organisation. They don't need special access. Every tool they use is free and public.
Certificate transparency logs (crt.sh)
Every TLS certificate your organisation has ever issued is publicly logged. A single query on crt.sh returns every subdomain that's ever had a certificate issued against your primary domain — including dev.companyname.com, staging-api.companyname.com, admin-old.companyname.com, and internal tools that were briefly exposed.
Passive DNS tools
Tools like SecurityTrails and Shodan's historical DNS records surface subdomains that no longer resolve but were once active. Decommissioned environments, test servers, acquired company domains — all visible.
What they typically find
In a real engagement, a common discovery looks like this: a forgotten staging environment, running for 14 months after the product it supported was deprecated, with an unauthenticated admin panel that mirrored production customer data. It wasn't in the VAPT scope. It had never been mentioned in a risk review. A pentester found it in six minutes.
Certificate transparency logs and passive DNS records expose every subdomain an organisation has ever used — including ones long forgotten.
3. Minutes 10–20: infrastructure and service fingerprinting
With subdomains mapped, the pentester now asks: what's running on them? What software versions? What ports are open? What services are exposed?
Shodan and Censys
These search engines index internet-facing services continuously. A pentester queries your IP ranges and ASN to find open ports, Nginx/Apache versions, exposed Redis instances, unauthenticated Elasticsearch clusters, misconfigured cloud storage, and more — before making a single direct connection to your infrastructure.
ASN and IP range lookups
By looking up your organisation's Autonomous System Number, a pentester can identify every IP block you own — including cloud ranges that teams provisioned years ago and forgot to document.
GitHub and code repositories
Public repositories are goldmines. Hardcoded API keys, AWS credentials accidentally committed and never rotated, internal infrastructure hostnames, Terraform configs describing your cloud architecture — tools like truffleHog or a handful of manual GitHub dorks find these in minutes.
Google dorks
Simple Google search operators — filetype:pdf site:companyname.com, inurl:admin companyname, intitle:"index of" companyname — regularly surface internal documents, open directory listings, and login panels indexed by mistake.
What shocks most clients
A visible internal Jira instance. A Jenkins CI server with public access. An RDP port exposed on a cloud VM that someone spun up for a short project and never shut down. A pentester finds all of this without logging in anywhere — just reading what the internet already knows about you.
Shodan and Censys continuously index exposed services across your entire IP range — open ports, service versions, and misconfigurations visible to anyone who searches.
4. Minutes 20–30: people and identity surface
The last ten minutes expand the surface from infrastructure to people — the most exploited attack vector in modern breaches.
LinkedIn enumeration
LinkedIn reveals your technology stack (job postings, employee skill endorsements), the names and roles of infrastructure engineers, and recently departed employees who may still have active accounts or credentials.
Credential breach databases
HaveIBeenPwned and similar services flag corporate email addresses found in public breach dumps. These become the starting point for credential stuffing attacks — particularly against corporate SaaS tools, VPNs, and admin portals that don't enforce MFA.
Email format discovery
Once the email format is known (firstname.lastname@company.com), a complete employee directory becomes a usable attack list. Tools like Hunter.io confirm the format within seconds.
Job postings as intelligence
A job listing for "Senior AWS Infrastructure Engineer experienced with Terraform, EKS, and Datadog" is not just a hiring notice — it's a map of your stack. An attacker now knows exactly what to look for.
People are the largest component of the external attack surface — email patterns, credentials, and role intelligence are all publicly accessible through OSINT techniques.
5. What this means for your VAPT program
If a pentester finds all of this in 30 minutes, an attacker — operating with no rules of engagement, no time pressure, and no ethical constraints — has had months.
The scope problem
If subdomains, forgotten cloud instances, decommissioned environments, and third-party integrations aren't in your VAPT scope, your pentest report will reflect a clean bill of health for systems that don't represent your actual risk. You'll fix the vulnerabilities in your scope document. The real entry points go untested.
The discovery gap
Most Indian enterprises define VAPT scope based on known assets — what the security team can list from memory or from a CMDB that hasn't been fully updated. Pre-VAPT discovery is the process of finding the unknown assets before the engagement starts. It's what bridges the gap between "the systems we think we have" and "the attack surface an attacker sees."
The CERT-In dimension
CERT-In's 6-hour incident reporting window assumes you have visibility into your full environment. If a breach enters via a forgotten subdomain or an undocumented cloud instance, detection alone becomes a challenge — let alone reporting within six hours. The compliance obligation presupposes asset awareness. Most organisations don't have it.
6. Closing
The 30 minutes described above happen whether you're ready or not. Every time a pentester begins an engagement — or an attacker begins targeting your organisation — this reconnaissance phase runs. The only question is whether you've already seen what they're going to find.
Pre-VAPT discovery is how you close that gap. Not by reacting to what a pentest report tells you, but by mapping your own attack surface — the way an attacker would — before the engagement begins.
See your attack surface the way a pentester would.
Start with xhield →
Related reading: