Red teaming gets romanticized a lot - people picture someone in a hoodie typing furiously, breaking into servers in real time. In reality, most of a red team engagement happens before anyone touches a live system.
It starts with reconnaissance: quietly building a complete picture of a target's digital footprint using only public information.
No logins, no exploits, no alarms triggered.
Here's how that process actually played out during a recent engagement against a mid-sized fintech company - a payment gateway handling UPI, card tokenization, and netbanking transactions.
I'm not naming the company, but the findings are real, and the process is worth walking through because it shows how much damage can be planned before an attacker ever "hacks" anything.
By the end of this engagement, without a single login attempt, exploit, or intrusion, we had assembled a near-complete map of the company's infrastructure, a live and forgeable cryptographic signing key, multiple unencrypted administrative logins reachable from the public internet, an unpatched remote-code-execution vulnerability, evidence of malware-compromised credentials, and a ready-made social engineering target list.
This is the real value of a red team's reconnaissance phase - it's not about proving you can break in, it's about proving how much of the work is already done for an attacker before they even try. Every finding here was addressed with the company directly, with the most sensitive detail (the actual signing key) withheld from any public-facing report and shared only through a secure, out-of-band channel with their security team, alongside clear remediation priorities: rotate exposed keys, lock down admin panels, patch known vulnerabilities, and tighten control over how internal documentation moves outside the organization.
Every engagement starts by understanding the target as a business, not just a set of IP addresses. Who are they, how big are they, who do they partner with, what's their industry footprint?
This came from public legal registries, corporate databases, and the company's own marketing pages - incorporation records, GST filings, headcount, banking partnerships, card network affiliations. None of this required any technical skill, just knowing where to look.
But it mattered strategically: knowing which banks a payment company partners with tells you the potential blast radius if their systems get compromised. It also gives later phishing pretexts more credibility - knowing the real corporate structure makes a fake email far more convincing.
This is where reconnaissance turns into real leverage. Using certificate transparency logs, DNS enumeration tools, and passive infrastructure scanners, we built a map of every subdomain, IP address, and hosting environment tied to the company - not just what's linked from the homepage, but everything that has ever had a certificate issued or a DNS record created.
The result was a footprint far larger than what any visitor to the main website would ever see: production payment APIs, sandbox and QA environments, staging servers, a CI/CD pipeline, admin panels, a VPN gateway, and even a leftover domain from an old company rebrand. This phase is the backbone of any red team assessment, because the goal isn't to attack the front door - it's to find every door, including the ones the company forgot existed.
A polished, well-secured main website means very little if a QA environment three subdomains deep is still running unpatched software from two years ago.
Once the attack surface was mapped, we ran a lightweight, non-intrusive sweep to see what was actually reachable from the public internet, and how each system responded.
Some hosts returned a normal response, fully public. Some were access-controlled. Some timed out entirely, suggesting VPN or IP restrictions. The value here isn't any single result - it's the pattern across the whole environment. In this case, the production payment infrastructure was properly locked down, but several administrative panels were sitting wide open, served without encryption.
That's the kind of finding a red team flags as high priority, even before digging further, because it tells you where the company's security attention has and hasn't been focused.
Next, we fingerprinted the technology stack - CMS, database, web server, cloud provider, third-party SaaS tools - and reviewed the company's public developer documentation. Payment companies publish API docs by necessity; developers need to integrate. But documentation is also one of the richest sources of intelligence a red team can find, because it often explains internal request formats, authentication flows, and - in this case - included a live cryptographic signing key embedded directly in a client-side tool meant to help developers test their integration.
That key was viewable by anyone who opened the page's source code. No login required. We independently verified it was a genuine, currently active key - not a placeholder - by using it to recompute a transaction signature and matching it against a real sample request found elsewhere. That confirmation step is a standard part of red team validation: don't just report a finding, prove its real-world impact.
Red team recon doesn't stop at the company's own infrastructure. We also searched GitHub, plugin registries, and public study-sharing platforms for anything referencing the company. This surfaced employee-authored repositories (useful for building a picture of internal tooling and identifying real employee accounts), third-party plugin integrations, and - critically - a publicly re-shared internal QA testing document, apparently uploaded by a student or intern for coursework purposes.
On its own, a leaked test document is a data-handling issue. Combined with the exposed signing key from Phase 4, it became something more valuable: a worked example showing the exact request format needed to forge a transaction. This is a pattern red teams see constantly - individually minor exposures compounding into serious risk once combined.
We also ran passive checks against known vulnerability databases and infostealer-intelligence sources. A banner check (not an active exploit attempt) against one internet-facing host revealed a known, unauthenticated remote-code-execution vulnerability in an outdated SSH service. Separately, a check against infostealer malware logs showed that several internal QA login URLs had previously appeared in credential-harvesting logs - meaning at least one device that accessed those pages had been compromised by malware at some point, and any credentials typed there should be considered burned.
Neither of these required exploitation. Both are exactly the kind of findings a red team escalates immediately, because they represent real, currently exploitable risk sitting quietly in production.
The final piece of reconnaissance was building a human map of the organization: employee names, roles, and public profiles via LinkedIn and B2B contact platforms, plus a WordPress configuration that was inadvertently exposing content-author usernames through an auto-generated sitemap. We also identified that HR and payroll functions were outsourced to a third-party platform, branded with the company's own logo - a realistic phishing target, since employees are conditioned to trust anything that looks like their internal HR portal.
This phase doesn't get exploited during an OSINT-only engagement, but it's what a follow-on social engineering assessment would build from - a target list, believable pretexts, and a sense of which login pages employees are used to trusting.
No system was breached, and no credential was used. Every finding, the signing key, the open admin panels, the unpatched SSH service, the leaked QA document, the social engineering map, came from information the company itself had left in public view. That is the real lesson of reconnaissance: attackers do not need to be skilled to be dangerous, they just need to look carefully at what is already exposed.
Closing that gap starts with the basics, rotate keys, lock down admin access, patch known vulnerabilities, and control what leaves the organization, whether by accident or through a forgotten subdomain.
.png)
