What an Attacker Already Knows About You Before They Ever Make Contact

MITRE ATT&CK ranks reconnaissance first for a reason. Threat intelligence is now a formal ISO 27001 control, and the input every other test depends on.

Every real intrusion begins the same way, and it isn't with an exploit. It's with a search engine, a domain registry, a company careers page, and a few hours of patient, unremarkable-looking research.

MITRE's ATT&CK framework — the industry-standard catalogue of adversary behavior — places Reconnaissance as tactic TA0043, the very first tactic in the entire enterprise matrix. Everything else, including initial access, comes after it. That ordering isn't arbitrary. It reflects how attacks actually happen.

The phase nobody can see

A malicious actor doesn't start by touching your systems. They start by surfing the open web — gathering information about the target, its environment, its architecture, its employees, its likely intrusion points, and the domains and APIs that were never meant to be visible to the public.

This is the part worth sitting with: this phase produces no alert. Nothing in this stage touches your network, so nothing in this stage can be logged, flagged, or blocked. By the time an organization detects an "attack," the reconnaissance that made it possible is usually long finished — and it was never visible in the first place. Good OSINT is a critical ingredient in a successful intrusion precisely because it happens where no defense is watching.

MITRE ATT&CK catalogues this formally, and the techniques map closely onto what actually gets used against real organizations:

  • T1589 — Gather Victim Identity Information: names, roles, email formats, credentials exposed in prior breaches.
  • T1590 — Gather Victim Network Information: domains, IP ranges, DNS records, and the sub-technique of Domain Properties specifically — registrar data, name servers, administrative contacts.
  • T1591 — Gather Victim Org Information: business relationships, vendors, physical locations, organizational structure.
  • T1592 — Gather Victim Host Information: the specific software, versions, and configurations in use.
  • T1595 — Active Scanning: probing exposed infrastructure directly to see what responds.
  • T1596 — Search Open Technical Databases: certificate transparency logs, Shodan, Censys, and other indexes that quietly catalogue exposed assets.

OWASP's own Web Security Testing Guide treats this the same way, opening its methodology with a dedicated Information Gathering category before any active testing begins — because you cannot meaningfully assess risk to a system you haven't first mapped.

Why this matters as a matter of business risk, not just curiosity

It's now a compliance requirement, not just good practice. ISO/IEC 27001:2022 introduced Annex A Control 5.7 — Threat Intelligence — as a new, dedicated control. It requires certified organizations to collect and analyze information relating to security threats and use it to take mitigating action, across three recognized layers: strategic (the big-picture threat landscape), tactical (the techniques currently in use against organizations like yours), and operational (specific, timely indicators). An organization pursuing or maintaining ISO 27001 certification cannot treat threat intelligence as optional anymore.

It closes the biggest blind spot most companies have. Most security investment goes toward detecting and stopping activity inside the network. Almost none goes toward understanding what's already visible outside it. A company can have a hardened perimeter and a fully staffed SOC and still have no idea that an exposed staging subdomain, a misconfigured API, or an employee's oversharing on social media is sitting in plain sight, cataloged and ready to be used.

It informs every other kind of test that matters. A physical assessment is only as convincing as the pretext behind it, and a convincing pretext is built from real reconnaissance — the kind of organizational detail a receptionist has no reason to doubt. A phishing simulation modeled on genuine open-source research about your company produces a meaningfully different result than one built from a generic template. Threat intelligence isn't a separate concern from the rest of a security program. It's the input that makes the rest of it accurate.

Our approach

We treat this as a structured intelligence process, not a one-off scan, following the same logic used in professional threat intelligence work:

Observation. Passive, undetectable reconnaissance — mapping what's genuinely exposed about an organization across domains, subdomains, APIs, employee footprints, technology stack, and organizational structure. Nothing at this stage touches the target's systems directly; it mirrors exactly what a real adversary does before ever making contact.

Collection and analysis. Everything gathered gets consolidated and analyzed together. Individually, a leaked email format or an old subdomain looks minor. Combined, they often reveal a specific, exploitable path that no single data point would have suggested on its own.

Hypothesis formation. Every notable finding becomes a testable claim, assigned a confidence level rather than treated as a certainty — the same discipline used in professional intelligence reporting, where analytic judgments are graded by how well-supported they actually are, not stated as flat fact.

Filtering. Not everything found is valuable. This stage strips out noise and speculation, keeping only what's specific, current, and actually actionable for the client.

Validation. Before anything goes into a report, findings are verified — confirming what's real and relevant, distinguishing genuine exposure from false positives, without crossing into unauthorized exploitation.

Standards we align with

Our methodology is built on recognized frameworks, not an internal checklist invented in isolation:

  • ISO/IEC 27001:2022, Annex A 5.7 — the formal requirement to collect, analyze, and act on threat intelligence.
  • MITRE ATT&CK, particularly the Reconnaissance (TA0043) and Resource Development (TA0042) tactics — the standard taxonomy for how adversaries gather information and build capability before an intrusion.
  • MITRE ATLAS — the equivalent framework for AI systems, which we draw on when threat modeling extends into AI red teaming engagements.
  • OWASP, including the Web Security Testing Guide's Information Gathering methodology and established threat modeling approaches such as STRIDE, for structuring how a threat model gets built and validated.

Using recognized standards means a client can see exactly what was tested against, why it was tested that way, and how the findings map to frameworks their own auditors, regulators, or board likely already recognize.


If you don't know what's already visible about your organization, an attacker researching you right now already does.

Get in touch to talk about what a threat intelligence assessment would actually surface about your organization.

Go deeper

Related

Get in touch

Find your blind spot before an attacker does.

Tell us what you're building and what you're worried about. We'll come back with a scope, a timeline, and a quote.

Request engagement
Tbilisi, Georgia/ Response within 1 business day/ [email protected]