Before a phishing email lands or an exploit fires, attackers spend days quietly building a profile of your company using nothing but public information — a technique called open-source intelligence (OSINT) reconnaissance. They map your domains and DNS records, list your employees from LinkedIn, search leaked-credential dumps for your corporate email domain, hunt for exposed cloud storage and code repositories, and pull metadata out of your public documents. None of it is illegal, none of it touches your network, and almost none of it gets logged anywhere you'd notice. For Indian SMBs, understanding this reconnaissance phase — and locking down what feeds it — is one of the highest-leverage moves a security or IT lead can make.
What OSINT Reconnaissance Actually Is
OSINT is the practice of collecting and correlating publicly available information to build actionable intelligence about a target. In a cyberattack lifecycle, it's the first phase — before scanning, before exploitation, before the phishing email — because everything downstream gets more effective when it's personalised. A generic phishing email gets ignored; an email that names your CFO, references a vendor you actually use, and mimics your internal signature format gets clicked. That specificity comes entirely from OSINT.
Unlike active reconnaissance (port scanning, vulnerability probing), OSINT is passive. Attackers never touch your infrastructure directly — they query public records, scrape public pages, and search public databases. This makes it essentially undetectable, and it's why most SMBs have no idea how much of their attack surface is already mapped before an attacker sends a single packet toward their network.
Domain and DNS Footprinting
The first step in most OSINT workflows is domain footprinting: mapping every subdomain, DNS record, and piece of infrastructure tied to your primary domain. Tools like whois, dig, Shodan, and certificate transparency logs (crt.sh) reveal far more than most companies expect — staging environments, forgotten test subdomains, internal tool hostnames, and hosting providers.
Certificate transparency logs are particularly revealing. Every publicly trusted SSL/TLS certificate issued for your domain — including for subdomains like staging.yourcompany.com — gets permanently logged in a public, searchable ledger the moment it's issued. An attacker searching crt.sh for your domain can enumerate infrastructure your own team may have forgotten existed.
dig yourcompany.com ANY
whois yourcompany.comWHOIS records, where not privacy-protected, can expose registrant names, phone numbers, and email addresses — a direct feed into social engineering. DNS records reveal mail server software and third-party services (payment processors, CRMs, marketing tools) via SPF/TXT records.
Employee Enumeration via LinkedIn and Social Platforms
Once the technical footprint is mapped, attackers turn to people. LinkedIn is the single richest OSINT source for this: company pages list every employee who's linked their profile, complete with job titles, tenure, and often direct reporting lines. From this, an attacker can build an org chart without ever contacting the company — identifying the finance team for business email compromise (BEC) targeting, IT administrators for credential-phishing, and executives for whaling attacks.
Tools built for this — Hunter.io, theHarvester, and similar — combine LinkedIn employee lists with common corporate email-naming patterns (firstname.lastname@company.com) to generate a working list of real corporate email addresses, often with high accuracy, entirely from public data.
Social media compounds this. Employees posting about a new vendor contract, a system migration, or an out-of-office message naming a colleague as backup contact all hand an attacker context that makes a phishing attempt more convincing.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanTechnology Stack Fingerprinting
Job postings, developer forum questions, and public repositories quietly reveal what software a company runs. A listing asking for "3 years of experience with [specific CRM]" tells an attacker exactly which vendor systems to research for known vulnerabilities. Passive tools like Wappalyzer identify the CMS, analytics, and JavaScript frameworks a public website runs, often down to version numbers exposed in HTTP headers.
This matters because vulnerability research is version-specific — knowing a target's exact CMS, plugin, or framework version lets an attacker check public vulnerability databases for known, unpatched exploits before investing any further effort.
Leaked Credentials and Data Breach Exposure
Every major data breach ever recorded gets scraped into "combo lists" and credential-stuffing databases, many freely searchable or traded on underground forums. An attacker simply searches for your corporate email domain against these datasets. Even if the leaked password is from an unrelated service — a forum, a delivery app, an old SaaS trial — employees who reuse passwords hand attackers a working set of credentials to try against corporate email, VPN, or SaaS logins.
This is precisely why credential-stuffing remains one of the most common initial-access techniques globally, and why reused passwords are consistently flagged as a top contributing factor in breaches.
Exposed Cloud Buckets, Repositories, and Documents
Misconfigured cloud storage is one of the most consistently exploited OSINT findings. Publicly readable AWS S3 buckets, Azure Blob containers, or Google Cloud Storage buckets — often set to "public" during testing and never locked back down — can expose customer data, internal documents, or credentials directly. Automated scanners that continuously enumerate cloud storage naming patterns make this discovery near-instant for attackers.
Public code repositories carry a parallel risk: developers accidentally committing API keys or database credentials into a public GitHub repo — sometimes removed in a later commit but still recoverable from git history, which most people forget is permanently public once pushed.
Even ordinary public documents — PDFs, Word files, spreadsheets on your own website — carry metadata: the author's real name, internal usernames, and sometimes internal file paths. Tools like exiftool extract this automatically, at scale, across every public document on your site.
| OSINT technique | What it reveals | Primary defence |
|---|---|---|
| DNS/certificate transparency | Subdomains, hosting, forgotten infra | Decommission unused subdomains, audit crt.sh regularly |
| LinkedIn enumeration | Org chart, roles, likely email format | Limit public role detail, employee awareness training |
| Job postings/forums | Tech stack, software versions | Generalise postings, avoid naming exact vendor versions |
| Breach databases | Reused/leaked passwords | Enforce MFA, monitor for domain in breach data |
| Cloud storage scanning | Exposed buckets, files, credentials | Bucket audits, least-privilege ACLs, no public-by-default |
| Document metadata | Author names, internal paths, tool versions | Strip metadata before publishing |
| Google dorking | Indexed sensitive files, login pages, error pages | Robots.txt review, remove sensitive files from indexable paths |
Google Dorking: Search Engines as a Recon Tool
Google dorking uses advanced search operators to find content search engines have indexed but that was never meant to be publicly discoverable — exposed login panels, configuration files, directory listings, or sensitive documents. Queries like site:yourcompany.com filetype:pdf or site:yourcompany.com intitle:"index of" surface exactly this kind of accidental exposure, using nothing more than a standard search engine.
Because this relies on what search engines have already crawled, the fix isn't reactive — it requires proactively controlling what gets indexed via robots.txt, noindex directives, and not leaving sensitive files reachable at predictable, unauthenticated URLs.
How OSINT Feeds Phishing and Social Engineering
Every piece of OSINT collected feeds directly into the next attack phase. An attacker who knows your CFO's name, your finance team's reporting structure, your actual vendor relationships, and your corporate email format can craft a business email compromise attempt that looks exactly like a legitimate internal request — often asking finance to process an urgent payment or update banking details. This is why BEC and targeted spear-phishing consistently outperform generic phishing: the personalisation is built entirely from information the target organisation made public itself.
These figures are drawn from the Verizon Data Breach Investigations Report and periodic advisories published by CERT-In, India's national computer emergency response team.
Defensive Counter-OSINT: What Indian SMBs Should Lock Down
Counter-OSINT isn't about disappearing from the internet — it's about reducing the specific, actionable details an attacker can weaponise. Start with a periodic self-audit: search your own domain on crt.sh, run a Google dork sweep against your own site, and check whether your corporate domain appears in public breach datasets.
- Enable WHOIS privacy on all owned domains and audit subdomains quarterly.
- Strip metadata from PDFs, Word docs, and images before publishing them publicly.
- Set cloud storage buckets to private-by-default; require a reviewed exception for anything public.
- Scan repositories for accidentally committed secrets, and rotate any credential ever exposed — deleting the commit does not remove it from history.
- Train employees on what NOT to post publicly — project names, vendor contracts, org-chart detail.
- Enforce MFA everywhere, since it neutralises the value of leaked or guessed passwords found via OSINT.
- Use
robots.txtandnoindexdeliberately; never rely on "security through obscurity" for sensitive URLs.
Where This Fits Into a Broader Security Programme
Counter-OSINT hygiene reduces the quality of information available to attackers, but it doesn't replace testing your actual defences. A structured VAPT engagement — delivered with a CERT-In empanelled partner where regulatory submission is required — typically includes an OSINT phase as its own deliverable, showing exactly what's discoverable about your organisation before moving into active scanning and exploitation testing. That combination — reducing your public footprint and independently verifying what's still exploitable — closes the gap between "we think we're fine" and knowing it. Bachao.AI, built by Dhisattva AI Pvt Ltd, provides continuous, automated visibility into this kind of exposure so Indian SMBs aren't relying on a once-a-year manual review. Organisations handling personal data should also review obligations under India's DPDP Act, enacted under the framework maintained by MeitY, since leaked customer data discovered via OSINT can itself constitute a reportable exposure.
Ready to see what's publicly discoverable about your organisation? Get a free VAPT scan, or browse the Bachao.AI blog for more practical security guides built for Indian SMB teams.
Frequently Asked Questions
What is OSINT reconnaissance in cybersecurity?
Can attackers really find employee email addresses from LinkedIn?
firstname.lastname@company.com to generate accurate working email address lists without ever contacting the target directly.