Discovery and Reconnaissance Techniques Guide: Spotting Attacker Discovery in Your Environment

Attackers almost always map an environment before they act on it, and that mapping is one of the few phases where defenders get a warning before damage is done. This guide is written for defenders and authorised testers only, and describes techniques at the level of the MITRE ATT&CK descriptions, not as procedures. It covers the two tactics that describe this mapping: Reconnaissance (TA0043), which happens before access, and Discovery (TA0007), which happens once an attacker has a foothold. Most of the page is about what you can see, log and alert on, how to reduce what an attacker learns, and how to respond when discovery is spotted. It is aimed at SOC analysts, detection engineers, Active Directory and cloud administrators, and the people who scope purple team exercises.

Key takeaways

• Reconnaissance is mostly invisible, discovery is not. Pre-access reconnaissance (TA0043) largely happens on third-party infrastructure, so your job there is to shrink what is public; post-access discovery (TA0007) runs inside your estate and leaves logs.
• Discovery hides in normal admin activity. Directory queries, group lookups and cloud list or describe API calls are what administrators, scripts and IT tools do all day, so detection depends on baselines, context and sequence rather than single events.
• Identity is the main target of discovery. Account Discovery (T1087), Permission Groups Discovery (T1069) and Domain Trust Discovery (T1482) exist to find privileged accounts, service accounts and paths to them.
• Deception gives the highest-fidelity signal. A decoy account or object that no legitimate process touches turns noisy enumeration into a near-certain alert, mapped in D3FEND as Decoy User Credential (D3-DUC) and Decoy Object (D3-DO).
• Hardening reduces the value of discovery. Restricting remote SAM enumeration, tightening cloud read permissions and removing stale accounts mean an attacker who enumerates successfully still learns less.

Reconnaissance and discovery in ATT&CK

ATT&CK v20 separates the two phases cleanly. Reconnaissance (TA0043) covers gathering information to plan an operation, much of it from sources you do not control: search engines, certificate transparency logs, social media, technical databases and phishing for information. Discovery (TA0007) covers learning about a system and network after gaining access, using whatever the compromised account can read. The OSINT side of reconnaissance is covered in depth in the OSINT and Reconnaissance Guide; this page focuses on what defenders can observe and change.

All IDs above were checked against the ATT&CK v20 enterprise matrix. ATT&CK also added T1681 Search Threat Vendor Data under Reconnaissance, which describes adversaries reading threat intelligence about themselves; it is not observable by the victim but is worth knowing when you publish indicators.

Detecting discovery on Windows and Active Directory

On-premises discovery is dominated by queries against the domain controller and the local Security Account Manager (SAM). The challenge is not missing data but too much of it, so start with the sources that carry context about who asked and from which process.

Analytics that work

• Unexpected callers: Microsoft recommends alerting on 4798 events where the calling process is not on an expected list, or runs from outside System32 and Program Files. Build that list from 30 days of baseline data.
• Burst and breadth: One workstation enumerating hundreds of users or groups within minutes is rarely an administrator. Alert on counts of distinct targets per source per time window, not on single events.
• Sequence: A user-context process running several discovery utilities (identity, group, trust, network configuration) in quick succession from an Office or browser parent is a classic early-stage pattern. Correlate on process lineage, which D3FEND describes as Process Lineage Analysis (D3-PLA).
• Who, not what: The same directory query is normal from a management server and suspicious from a receptionist's laptop. Tag hosts and accounts by role in the SIEM so analytics can use it.
• Critical group watchlists: Monitor 4799 filtered on Administrators, Backup Operators and other privileged local groups, as Microsoft suggests, and route those to a lower-volume queue.

For writing and testing these as portable rules, see the Sigma Rules Guide and KQL for Threat Hunting Guide. Event field details are in the Windows Event Log Guide.

Detecting discovery in cloud, containers and Linux

Cloud discovery is API-driven: an attacker holding a stolen access key or token calls list and describe operations to see what the identity can reach. Every call is logged, but read operations are the bulk of cloud audit volume, and some providers do not log data-plane reads by default.

• AWS: CloudTrail records management events, including list and describe calls; S3 object-level reads need data events enabled. GuardDuty raises Discovery:IAMUser/AnomalousBehavior when a discovery API is invoked in an anomalous way, and Recon:IAMUser/MaliciousIPCaller, Recon:IAMUser/MaliciousIPCaller.Custom and Recon:IAMUser/TorIPCaller when list or describe APIs are called from threat-listed or Tor addresses.
• Azure and Entra ID: Activity logs cover resource management reads only partially, so pair them with Entra sign-in logs and Microsoft Graph activity logs to see bulk directory reads by an application or user.
• Google Cloud: Admin Activity audit logs are always on; Data Access logs, which include many read operations, must be enabled explicitly per service.
• Kubernetes: The API server audit log captures list and get calls against pods, secrets and nodes (T1613). A workload service account listing secrets across namespaces is a strong signal. See the Kubernetes Service Account Token Guide.
• Linux hosts: auditd execve rules and EDR process telemetry capture host discovery (T1082, T1033, T1057) and reads of sensitive configuration. See the Linux Logging and auditd for Defenders Guide.

The strongest cloud analytic is a change in behaviour per identity: a CI/CD role that has only ever written to one bucket suddenly enumerating IAM roles, or a key used from a new network enumerating every region. Machine identities are predictable, which makes this baseline cheap to build. See the Cloud Logging and Audit Trail Guide.

Where identity fits

Discovery is mostly identity reconnaissance. Attackers enumerate to answer three questions: which accounts are privileged, which accounts are weakly protected, and which non-human identities hold standing access. Service accounts with non-expiring passwords, Kerberos service principal names and cloud roles with broad read permissions are high-value findings for them. Two defensive consequences follow.

• Know your own graph first: Run attack path analysis on your own directory so that whatever an attacker could discover, you already know and have reduced. See the BloodHound and Active Directory Attack Path Guide.
• Baseline non-human identities: Service accounts and workload identities rarely need to enumerate the directory. Any that do should be documented; any that start should alert. See the Service Account Security Guide.

Deception for high-fidelity discovery alerts

Because most discovery looks legitimate in isolation, deception is the most efficient detection investment. A decoy has no business purpose, so any interaction is suspicious. NIST SP 800-53 covers this as SC-26 Decoys and SC-30 Concealment and Misdirection.

Register every decoy in your asset inventory as a decoy so that vulnerability scanners and IT tools are excluded and do not trigger false positives. See the Deception Technology Guide.

Prevention and hardening

• Restrict remote SAM enumeration: The Group Policy setting "Network access: Restrict clients allowed to make remote calls to SAM" (registry value RestrictRemoteSam) limits who can enumerate local users and groups over SAMR. Since Windows 10 1607 and Server 2016, non-domain-controllers default to allowing only Administrators; domain controllers default to allowing everyone for compatibility. Microsoft documents an audit-only mode (RestrictRemoteSamAuditOnlyMode) that logs Event 16968 for calls that would be denied, which is the safe way to find legitimate callers before enforcing. Microsoft warns that enforcement can break admin scripts and Exchange 2013 and 2016 offline address book generation.
• Reduce what reads reveal: Remove stale and orphaned accounts, clean up group nesting, and avoid putting secrets or role hints in description fields, which any authenticated user can usually read. See the Active Directory and Entra ID Hardening Guide.
• Least privilege for cloud reads: Broad read policies such as organisation-wide viewer roles turn one stolen key into a full map. Scope read permissions to the resources a workload needs (NIST SP 800-53 AC-6). See the AWS IAM Policies and Roles Guide.
• Segment the network: Internal scanning (T1046) from user subnets to server management ports should be blocked, not just logged. See the Network Segmentation Guide.
• Shrink the public footprint: Review exposed services, DNS records, code repositories and staff-facing information on a schedule (CSF ID.AM and ID.RA). See the Attack Surface Management Guide and Nmap for Defenders Guide.

Implementation: a phased approach

1. Turn on the telemetry (weeks 1 to 2): Enable Audit User Account Management, Audit Security Group Management and process creation with command line on all Windows hosts; deploy Sysmon with Event 3 and Event 22 configured on servers and a pilot workstation ring; enable cloud read and data-access logging for crown-jewel accounts and storage.
2. Baseline (weeks 2 to 6): Record which accounts, processes and hosts normally enumerate users, groups and cloud resources. Tag management servers, IT tooling and scanners so analytics can exclude or down-rank them.
3. Deploy deception (week 4 onward): Create two or three honeytoken accounts and one decoy share, set SACLs, and alert on any touch. Start small so the SOC learns to triage them.
4. Build behavioural analytics (weeks 6 to 10): Burst, breadth and sequence rules, first in report-only mode, then as alerts once false-positive rates are acceptable.
5. Harden in audit mode first: Enable RestrictRemoteSam audit-only mode on a representative set of servers, review 16968 events, build the SDDL with approved callers, then enforce. Rollback is removing or relaxing the policy, which needs no restart.
6. Validate with authorised testing: Run a purple team exercise that emulates the discovery techniques above against a scoped set of hosts and measure what was detected. See the Purple Teaming Guide and Penetration Test Scoping Checklist.

Decision guidance

• Small organisations: Prioritise deception and native cloud detection (honeytoken accounts, GuardDuty or equivalent) over custom analytics. They give high-fidelity alerts without a detection engineering team.
• Large organisations: Invest in per-identity baselines and sequence analytics in the SIEM, because the volume of legitimate enumeration makes single-event rules unworkable.
• Directory sensors versus raw logs: A directory sensor on domain controllers sees LDAP and SAMR traffic that Windows logs do not fully capture; raw logs are cheaper and portable. Mature teams use both.

Responding when discovery is detected

A confirmed discovery alert means an attacker, or an unsanctioned tester, already holds a foothold. Treat it as an early-stage intrusion, not a nuisance.

• Confirm authorisation: Check whether a sanctioned test is running before escalating; the test plan should name source hosts and accounts. See the Red Team Rules of Engagement Template.
• Scope the identity: Identify the account and host behind the queries, review its recent sign-ins, token issuance and process tree, and look for initial access. See the Initial Access Techniques Guide.
• Contain without tipping off early: Isolate the host and revoke sessions and keys once enough evidence is preserved; enumeration output is the attacker's target list, so review what the queried objects were.
• Anticipate the next step: Discovery precedes credential access and lateral movement. Raise monitoring on the privileged accounts and hosts that were enumerated. See the Lateral Movement Guide.

Measuring detection coverage

• Technique coverage: Percentage of the TA0007 techniques in the table above with at least one tested detection, validated by an emulation exercise in the last 12 months.
• Time to detect discovery: Median time from the first emulated discovery action to an alert in purple team exercises.
• Decoy coverage: Number of domains, cloud accounts and Kubernetes clusters with at least one monitored decoy.
• Alert precision: Proportion of discovery alerts that are true positives or authorised tests; aim to raise it quarter on quarter.
• Telemetry health: Percentage of Windows hosts sending 4688 with command line, 4798 and 4799, and percentage of cloud accounts with read logging enabled.

Common failure patterns

• Single-event alerting: Alerting on every 4799 or every list API call floods the queue, and analysts start closing discovery alerts unread.
• Telemetry assumed, not verified: Command line logging is not enabled, Sysmon Event 3 is off by default, and Google Cloud Data Access logs are off unless enabled. Teams discover the gap during an incident.
• Excluding all IT tooling: Blanket exclusions for management servers and admin accounts blind you to the most valuable targets, because attackers who compromise them enumerate from there.
• Decoys that break: Honeytoken accounts that are cleaned up by account hygiene scripts, or that trigger on every vulnerability scan, are disabled within weeks.
• Ignoring machine identities: Baselines built only for human users miss a stolen CI/CD key or service account token enumerating cloud resources, Stolen cloud credentials are a recurring entry point: in the Sumo Logic Breach 2023 a compromised credential was used to access an AWS account, and per-identity baselines are what surface the first unusual reads made with a key like that.
• Enforcing hardening without audit: Turning on RestrictRemoteSam without the audit phase breaks legitimate tools, and the policy is rolled back permanently.

Framework mapping

Practitioner checklist

• Enable Audit User Account Management, Audit Security Group Management and process creation with command line on every Windows host.
• Deploy Sysmon with network connection (Event 3) and DNS query (Event 22) configured on servers and high-risk workstations.
• Enable cloud read and data-access logging for privileged accounts and sensitive storage, and turn on native discovery findings.
• Build a 30-day baseline of which accounts and processes enumerate users, groups and cloud resources.
• Deploy at least two honeytoken accounts with SACLs and one decoy share, and alert on any interaction.
• Run RestrictRemoteSam in audit-only mode, review Event 16968, then enforce with an approved SDDL.
• Remove stale accounts and secrets from description fields, and scope cloud read permissions.
• Write burst, breadth and sequence analytics and test them in report-only mode first.
• Validate detections with an authorised purple team exercise at least annually and track time to detect.

Standards and references

• MITRE ATT&CK: Discovery (TA0007)
• MITRE ATT&CK: Reconnaissance (TA0043)
• MITRE D3FEND: Decoy User Credential
• Microsoft Learn: Network access: Restrict clients allowed to make remote calls to SAM
• Microsoft Learn: Event 4798, a user's local group membership was enumerated
• Microsoft Learn: Microsoft Defender for Identity security alerts
• AWS: GuardDuty IAM finding types
• Microsoft Learn: Sysmon

Related NHI Mgmt Group resources: OSINT and Reconnaissance Guide · Threat Hunting Guide · Deception Technology Guide · Defence Evasion Techniques Guide · Open Source Penetration Testing Tools Landscape Guide