MITRE ATT&CK T1596 Search Open Technical Databases: Reducing and Detecting Reconnaissance

Every domain you register, certificate you issue and service you expose leaves a public technical record that an adversary can query without ever sending a packet to you. MITRE ATT&CK T1596 Search Open Technical Databases covers adversaries searching freely available technical databases, such as domain and certificate registrations and public collections of network data gathered from traffic and scans, for victim information they can use during targeting. It sits in the Reconnaissance tactic (TA0043), on the PRE platform, with five sub-techniques in ATT&CK v20: T1596.001 DNS/Passive DNS, T1596.002 WHOIS, T1596.003 Digital Certificates, T1596.004 CDNs and T1596.005 Scan Databases. Because the queries hit third-party services, the defensive work is to see the same records first and shrink what they reveal. This guide is for attack surface, network, DNS and threat intelligence teams. How to use internet search engines and scan data as a defender is covered in the Internet Exposure Search Engines and Internet Scanning Data for Defenders guides; this page covers the ATT&CK technique view per sub-technique.

Key takeaways

• Five databases, one question: what does DNS, WHOIS, certificate, CDN and scan data say about you today? Each sub-technique maps to a record set you can query yourself.
• Scan databases shorten the attack. CISA reports Volt Typhoon using FOFA, Shodan and Censys to search for exposed infrastructure, and ATT&CK records APT41 using FOFA for passive scanning of victims.
• Certificates publish hostnames. Certificate Transparency logs are public, append-only records of issued TLS server certificates, so every name on a publicly trusted certificate should be treated as public.
• Detection is downstream. ATT&CK's detection strategies for T1596 and every sub-technique say the activity is largely outside the target's visibility; detect the follow-on scanning and exploitation, and watch the databases for changes about you.
• Only M1056 applies. ATT&CK maps T1596 and each sub-technique to M1056 Pre-compromise, which means minimising the amount and sensitivity of data available to external parties.

What T1596 covers

ATT&CK says information from these databases may reveal opportunities for further reconnaissance (T1598 Phishing for Information, T1593 Search Open Websites/Domains), establishing resources (T1583 Acquire Infrastructure, T1584 Compromise Infrastructure) and initial access (T1133 External Remote Services, T1199 Trusted Relationship).

How adversaries use it: recorded cases

From ATT&CK v20 and the reports it cites; attribution is as stated by those sources.

• Volt Typhoon (G1017), T1596.005: CISA advisory AA24-038A says, citing industry reporting, that the actors use FOFA, Shodan and Censys for querying or searching for exposed infrastructure, as part of extensive pre-compromise reconnaissance into network architecture, security measures and key IT staff. The same advisory recommends limiting internet exposure of systems and management interfaces when not necessary and using attack surface management services. See the Volt Typhoon Threat Actor Profile.
• APT41 (G0096), T1596.005: ATT&CK records the group using the Chinese website fofa.su, similar to Shodan, for passive scanning of victims.
• APT41 DUST campaign (C0040), T1596.005: ATT&CK records the campaign using internet scan data for target development. Mandiant's report describes APT41 visiting victim-owned infrastructure that was externally reachable and observed in internet scan data, and finding web shells on a Tomcat Apache Manager server active since at least 2023. See the APT41 Threat Actor Profile.
• Kimsuky (G0094), T1596: ATT&CK records the group using large language models to better understand publicly reported vulnerabilities, which shortens the step from a scan result to a working plan.

The pattern across these cases is that scan data turns into initial access through exposed edge devices and management interfaces. The MITRE ATT&CK T1190 Exploit Public-Facing Application guide covers that next step.

Sub-technique by sub-technique: exposure and controls

The controls below are NHI Mgmt Group recommendations that put M1056 into practice.

T1596.001 DNS/Passive DNS

• Exposure: descriptive subdomains (vpn, citrix, jenkins, dev), internal names in public zones, and passive DNS history that keeps old records searchable long after deletion.
• Controls: restrict zone transfers to named secondaries, keep internal names in internal zones (split DNS), remove records for decommissioned services, and fix dangling records that point at released cloud resources. See the Passive DNS and DNS History Guide and Subdomain Takeover and Dangling DNS Guide.

T1596.002 WHOIS

• Exposure: named individuals as registrant or technical contacts, registrar and name server choices, and the IP blocks assigned to you in regional internet registry records.
• Controls: use role-based contact addresses, use registrar privacy where appropriate, keep registrar accounts protected with strong MFA and registry lock for critical domains, and track the address space registered to you. See the Domain Portfolio and Lookalike Domain Management Guide.

T1596.003 Digital Certificates

• Exposure: RFC 9162 (Certificate Transparency Version 2.0, Experimental, obsoleting RFC 6962) describes CT logs as public, append-only records, and log operators should not impose conditions on retrieving data from them. Hostnames on publicly trusted certificates, including pre-production and internal-sounding names, become searchable.
• Controls: issue certificates for internal-only services from a private CA, consider wildcard certificates where individual names would reveal sensitive services (weighing the wider blast radius of a wildcard key), and monitor CT logs for unexpected certificates on your domains. See the Certificate Transparency Monitoring Guide for Web Teams.

T1596.004 CDNs

• Exposure: origin servers reachable directly, which bypasses CDN protections; content cached or hosted on the CDN that was never meant to be public; and login portals on CDN hostnames without the controls of your main site, which ATT&CK specifically calls out.
• Controls: allow origin traffic only from the CDN (provider address ranges or authenticated origin pulls), inventory every CDN property and hostname, and apply the same authentication and WAF policy to all of them. See the CDN Security Guide.

T1596.005 Scan Databases

• Exposure: open ports, service banners with versions, certificates that tie an IP address to your organisation, and exposed management interfaces on edge devices.
• Controls: keep management interfaces off the internet, remove version banners, patch internet-facing systems on a risk-based timeline, and subscribe to alerts from scan services for your address space so you see new exposure as quickly as an adversary does.

Where identity fits

Scan databases frequently index identity infrastructure: VPN and remote access gateways, single sign-on portals, Outlook Web Access, legacy ADFS servers and exposed API endpoints. Each is a place where stolen or guessed credentials are tried, including service account and API credentials that are not behind MFA. When a scan service shows a new authentication surface, confirm that it enforces phishing-resistant MFA for people, that machine credentials accepted there are scoped and short-lived, and that sign-in logs from it reach your SIEM. CT logs also reveal hostnames of identity providers and token endpoints; that is expected, but those endpoints should never be the only control.

What to detect and where

ATT&CK v20 publishes detection strategies DET0860 (T1596), DET0877 (T1596.001), DET0832 (T1596.002), DET0831 (T1596.003), DET0809 (T1596.004) and DET0858 (T1596.005). Each analytic says the activity may have a very high occurrence and false positive rate and takes place largely outside the target's visibility, so detection should focus on related stages such as initial access. In practice, watch the databases about you and watch for the follow-on activity.

Implementation: a phased approach

1. Weeks 1 to 3, baseline: pull your own records from each database type: zone contents and passive DNS, WHOIS for every domain and address block, CT entries, CDN properties and scan service results for your IP ranges.
2. Weeks 2 to 6, triage: for each finding, record owner, business need and risk. Start with management interfaces, remote access and identity endpoints.
3. Weeks 4 to 12, reduce: remove or restrict exposed services, clean DNS, move internal names to a private CA and internal zones, and lock origins to the CDN. Make DNS and firewall changes through change control with the previous configuration saved for rollback, and test origin restrictions in a staging property first.
4. Ongoing, monitor: set alerting for new exposure, new certificates and DNS changes, and review the baseline monthly.
5. Test: twice a year, ask a red team or an authorised third party to build a target list for you using only these public databases, and compare it with your inventory.

Measuring it

• Unknown exposure: internet-facing services found in scan data that were not in your inventory, per quarter.
• Time to close: median days from a new exposure alert to removal or restriction.
• Management interfaces exposed: count of admin consoles reachable from the internet (target zero).
• Unexpected certificates: CT findings not matched to a request, and time to resolve.
• Dangling records: DNS records pointing at released resources, trending to zero.

Common failure patterns

• Deleting a record and assuming it is gone: passive DNS and CT keep history, so a removed name may still point adversaries at an old server that was never decommissioned.
• Publicly trusted certificates for internal names: internal hostnames appear in CT logs and describe your internal estate.
• Open origins: the CDN is protected but the origin answers anyone who finds its IP address in scan data.
• Inventory from the inside only: asset lists built from internal tools miss shadow IT and supplier-hosted services that scan databases see.
• Exposure reports without owners: monthly scan exports are produced but nobody is accountable for closing findings.

Framework mapping

The AI counterpart is covered in AML.T0000 Search Open Technical Databases. Related techniques: T1590 Gather Victim Network Information (see T1590 Gather Victim Network Information) and T1595 Active Scanning (see T1595 Active Scanning Defensive Guide). Sibling reconnaissance pages: MITRE ATT&CK T1593 Search Open Websites/Domains and MITRE ATT&CK T1594 Search Victim-Owned Websites.

Practitioner checklist

• You hold a baseline of your own DNS, WHOIS, CT, CDN and scan service records, refreshed monthly.
• Scan service and CT alerts for your domains and address space go to a named owner.
• No management interface or admin console is reachable from the internet.
• Zone transfers are restricted and internal names live in internal zones.
• Internal services use certificates from a private CA.
• Origins accept traffic only from the CDN, and every CDN hostname has the same authentication and WAF policy.
• WHOIS contacts are role-based and critical domains use registry lock.
• Identity endpoints found in scan data enforce phishing-resistant MFA and log to the SIEM.

Standards and references

• MITRE ATT&CK: T1596 Search Open Technical Databases
• MITRE ATT&CK: T1596.005 Scan Databases
• MITRE ATT&CK: M1056 Pre-compromise
• CISA: AA24-038A PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure
• IETF: RFC 9162 Certificate Transparency Version 2.0
• Google Cloud (Mandiant): APT41 Has Arisen From the DUST
• CIRCL: Passive DNS

Related NHI Mgmt Group resources: Attack Surface Management Guide, Internet Exposure Search Engines, DNS Security Guide, ATT&CK Reconnaissance Tactic (TA0043) Guide.