ATT&CK Reconnaissance Tactic (TA0043) Guide: Shrinking What Attackers Learn Before They Strike

Most reconnaissance happens on infrastructure defenders do not own, so the realistic goal is not to catch it but to control what it can find. MITRE ATT&CK v20 describes the Reconnaissance tactic (TA0043) as the adversary "trying to gather information they can use to plan future operations": details of the victim organisation, its infrastructure and its staff, used to plan initial access, scope later objectives or drive further reconnaissance. ATT&CK maps 38 of the 46 techniques and sub-techniques in the tactic to a single mitigation, Pre-compromise (M1056), which is a fair summary of the problem. This hub covers all 12 Reconnaissance techniques and their 34 sub-techniques in v20, shows from the ATT&CK data which ones are actually used, and sets out an exposure reduction programme plus the few places where detection is practical. It is written for threat intelligence analysts, attack surface owners and SOC leads.

Key takeaways

• Reconnaissance is a human activity in the data. Of 181 procedure records in v20, 145 come from groups and 30 from campaigns; only 6 come from software, the opposite of post-compromise tactics.
• Scanning and phishing for information lead. Vulnerability Scanning (T1595.002) and Spearphishing Link (T1598.003) have 19 records each, Email Addresses (T1589.002) 17, and the parent Gather Victim Identity Information (T1589) 12.
• Only three techniques leave evidence you can see. Active Scanning, Phishing for Information and Search Victim-Owned Websites touch your systems; the other nine happen in search engines, public databases, social media and closed sources.
• Exposure reduction is the control. Reduce what scans find, what DNS, certificates and code repositories reveal, and what staff and job adverts disclose, then measure it the way an attacker would.
• AI and threat intelligence are now in the matrix. v20 includes T1682 Query Public AI Services and T1681 Search Threat Vendor Data, reflecting attackers using LLMs to aggregate public information and reading defenders' reports about themselves.

What Reconnaissance covers

The 12 techniques fall into three groups by where the activity happens, which decides what a defender can do about each.

The information goal techniques (T1589 to T1592) describe what is being collected, while the source techniques (T1593 to T1598) describe how, so one real activity often maps to both: searching a code repository (T1593.003) for credentials (T1589.001), for example. For the methods themselves from the tester's side, see the OSINT and Reconnaissance Guide.

Every technique in the tactic

Counts are computed from the ATT&CK v20 Enterprise STIX dataset: procedure records are non-revoked "uses" relationships from groups, software and campaigns to the technique and its sub-techniques; mitigations are distinct "mitigates" relationships, including M1056 Pre-compromise. Sub-technique record counts are in brackets.

Ten of the 34 sub-techniques have no procedure records at all, including DNS, WHOIS, Digital Certificates and CDNs under T1596. That reflects the visibility problem rather than lack of use: activity that never touches the victim rarely appears in the incident reports ATT&CK draws on.

How attackers chain it

Reconnaissance feeds two places: Resource Development (acquiring infrastructure, accounts and tools fitted to the target) and Initial Access. The procedure data shows three repeating patterns.

• Scan, then exploit at scale: 19 v20 entries for T1595.002 include Sandworm Team, APT28, APT29, APT41, Magic Hound and campaigns such as Cutting Edge and SharePoint ToolShell Exploitation. Opportunistic actors scan for one exposed product version, then exploit every match. The Gravity SMTP CVE-2026-4020 (2026) page shows the pattern: hosting providers counted hundreds of scanning IP addresses probing one unauthenticated plugin endpoint for weeks, and the response leaked email provider API keys.
• Harvest identities, then phish or spray: email addresses (T1589.002) and employee names (T1589.003) feed phishing for information and initial access phishing; roles (T1591.004) select who to target for help desk social engineering. LAPSUS$, Kimsuky and Magic Hound are among the groups with the most distinct Reconnaissance techniques in v20.
• Search code for secrets: T1593.003 Code Repositories is recorded for LAPSUS$, HAFNIUM, ShinyHunters, Contagious Interview and the Shai-Hulud campaign. A token found in a public repository can skip the rest of the attack chain entirely.

Discovery is the post-compromise equivalent of this tactic: the same questions asked from inside. See the ATT&CK Discovery Tactic (TA0007) Guide and, for the next stage, the ATT&CK Resource Development Tactic Guide.

Reducing exposure

ATT&CK's Pre-compromise mitigation describes the goal as reducing the attack surface, identifying adversary preparation and making successful operations harder. The specific mitigations beyond M1056 are narrow: M1017 User Training and M1054 Software Configuration for phishing for information, M1013 Application Developer Guidance and M1047 Audit for code repositories, and M1042 Disable or Remove Feature or Program for wordlist scanning. A practical programme turns them into five workstreams.

1. External attack surface inventory. Enumerate every internet-facing IP, domain, certificate and cloud endpoint the way a scanner would, owned or not, and assign each an owner. See the Attack Surface Management Guide.
2. Remove what should not answer. Take management interfaces, admin panels, debug and diagnostic endpoints and default pages off the internet or behind authenticated access; strip version banners. This is what turns T1595.002 from a hit list into noise.
3. Watch technical databases. Monitor Certificate Transparency logs for certificates issued for your domains (T1596.003), keep DNS zones free of internal hostnames (T1590.002, T1596.001), and check what internet scan databases already hold about your ranges (T1596.005). See the Certificate Transparency Monitoring Guide for Web Teams.
4. Keep secrets out of code. GitHub documents that secret scanning runs free on public repositories and that, for partner secrets, GitHub notifies the provider so it can act, for example by revoking the credential. Enable scanning and push protection on private repositories too, and treat a detected secret as compromised: rotate first. See the Git Secret Scanning Guide.
5. Limit human disclosure. Review job adverts for technology stack detail, publish role mailboxes rather than personal addresses where practical, enforce DMARC so harvested addresses cannot be spoofed easily, and train help desk and finance staff on information requests (T1598.004 Spearphishing Voice). See the DMARC, SPF and DKIM Guide.

Small organisations versus large

A small organisation gets most value from a quarterly self-scan of its own ranges, secret scanning on every repository, DMARC at enforcement and a short staff briefing on information requests. A large organisation needs continuous external attack surface monitoring, a feed of leaked credentials matched to its domains, CT log alerting and a threat intelligence function that tracks scanning campaigns against products it runs. In both cases, start with discovery mode: inventory and report before closing anything, agree exceptions with service owners, and remove exposures in batches with a rollback plan (firewall rule or DNS record restore) for anything that turns out to be needed.

Detecting the visible part

ATT&CK's own detection strategies for the invisible techniques, such as DET0805 for code repositories and DET0919 for public AI services, say plainly that the activity mostly takes place outside the target's visibility and suggest focusing on related later stages such as Initial Access. Do not build a SOC queue on internet background scanning: aggregate it, enrich source addresses with threat intelligence, and alert only when a scan is followed by a successful authentication or an exploit attempt that matches a product you run.

Where identity fits

Identity is the main product of reconnaissance. Names, email formats, roles and credentials (T1589) decide who gets phished and which accounts get sprayed, and leaked machine credentials in code or diagnostic output are the shortest path in. Monitor for your domains in breach and infostealer data, rotate any non-human credential that appears in a public repository or diagnostic dump, and keep a record of which keys are exposed to the internet by design. See the MITRE ATT&CK T1589 Gather Victim Identity Information page for the identity techniques in depth.

Measuring progress

• Unowned external assets: count of internet-facing assets without an owner, trending to zero.
• Exposed management interfaces: number of administrative and diagnostic interfaces reachable from the internet.
• Secret exposure time: median time from a secret being detected in code to its rotation.
• DMARC enforcement: percentage of sending domains at p=quarantine or p=reject.
• Scan to exploit correlation: number of alerts where a scan source later attempted exploitation or authentication, reviewed monthly.

Framework mapping

Common failure patterns

• Alerting on every scan: internet background scanning never stops, and a queue full of it hides the scan that preceded an exploit.
• Inventory from the inside only: CMDB views miss shadow IT, forgotten cloud endpoints and acquired domains that scanners find in minutes.
• Patching without rotation: fixing a flaw that leaked secrets leaves every key read before the fix valid, as the Gravity SMTP case shows.
• Secrets only scanned in public repositories: private repositories are cloned by insiders, contractors and attackers holding stolen tokens.
• Diagnostic endpoints left open: system reports, debug pages and status endpoints disclose versions, plugins and sometimes credentials.

Practitioner checklist

• Build and own an external asset inventory that includes cloud endpoints and acquired domains.
• Scan your own ranges from outside on a schedule and compare with the inventory.
• Remove management, admin and diagnostic interfaces from the internet.
• Monitor Certificate Transparency logs for your domains.
• Enable secret scanning and push protection on all repositories; rotate on detection.
• Monitor breach and infostealer data for your domains and act on matches.
• Enforce DMARC and brief help desk and finance staff on information requests.
• Correlate scan sources with later authentication and exploit attempts rather than alerting on scans alone.

Standards and references

• MITRE ATT&CK: Reconnaissance (TA0043)
• MITRE ATT&CK: Pre-compromise (M1056)
• MITRE ATT&CK: Active Scanning (T1595)
• MITRE ATT&CK: Phishing for Information (T1598)
• MITRE ATT&CK: Query Public AI Services (T1682)
• GitHub Docs: About secret scanning
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: ATT&CK Mitigations · T1595 Active Scanning Defensive Guide · Attack Surface Management Guide · OSINT and Reconnaissance Guide