MITRE ATT&CK T1087 Account Discovery: Detection Guide for SOC Analysts

MITRE ATT&CK T1087 Account Discovery describes techniques adversaries use to enumerate user accounts on a target system, domain, email infrastructure, or cloud environment. It is classified under the Discovery tactic and sits in a critical position in the kill chain: attackers who complete account discovery have everything they need to prioritize lateral movement targets, identify privileged accounts to steal, and map blast radius for ransomware deployment.

Account discovery is not a sophisticated technique. It uses built-in operating system utilities and widely available open-source tooling. That is precisely what makes it dangerous: it is fast, low-effort, and blends into the noise of legitimate IT administration. The entire T1087 technique family was observed in 68% of confirmed intrusions tracked by CISA between 2022 and 2024, making it one of the most reliably present MITRE techniques across breach reports.

Threat actor groups known to heavily use T1087 include:

• APT29 (Cozy Bear): Uses LDAP enumeration and PowerShell-based account discovery in their initial access and lateral movement phases, documented extensively in the SolarWinds supply chain attack (2020) and subsequent Microsoft 365 cloud campaigns.
• Lazarus Group (HIDDEN COBRA): Combines T1087 with T1078 Valid Accounts and T1003 OS Credential Dumping; their 2022 Ronin Bridge cryptocurrency heist began with systematic domain enumeration.
• Black Basta ransomware affiliates: Use BloodHound and SharpHound within hours of initial access to identify domain admin paths before deploying ransomware.
• Scattered Spider (UNC3944): Performs cloud-focused account discovery against Azure AD and Okta before pivoting to social engineering targeted at high-privilege accounts.

Understanding what each sub-technique looks like in telemetry is the first step toward writing detection rules that actually fire in production.

MITRE ATT&CK breaks T1087 into four sub-techniques. Each maps to a distinct target environment and distinct tooling.

The following commands and tools appear repeatedly in incident reports and red team assessments. Detection engineers should build signatures around both the process names and their characteristic arguments.

Native Windows Commands (T1087.001 and T1087.002):

net user
net user /domain
net group "Domain Admins" /domain
net group "Enterprise Admins" /domain
whoami /all
whoami /groups
query user

LDAP Enumeration (T1087.002):

ldapsearch -x -H ldap://dc01.corp.local -b "DC=corp,DC=local" "(objectClass=user)"
dsquery user -limit 0
dsquery group -limit 0

PowerShell Active Directory Module (T1087.002):

Get-ADUser -Filter * -Properties *
Get-ADGroupMember -Identity "Domain Admins"
Get-ADComputer -Filter * | Select Name

PowerView (T1087.002) -- most commonly seen in red team and APT activity:

Import-Module PowerView.ps1
Get-DomainUser -Properties samaccountname,memberof,lastlogon
Get-DomainGroupMember -Identity "Domain Admins"
Get-DomainController
Find-LocalAdminAccess

BloodHound/SharpHound (T1087.002):

SharpHound is the C# ingestor for BloodHound. It runs LDAP queries and SMB enumeration in parallel, collects group memberships, session data, and ACLs, then writes compressed JSON to disk for analysis in the BloodHound GUI.

./SharpHound.exe -c All --zipfilename bloodhound_data.zip
Invoke-BloodHound -CollectionMethod All -OutputDirectory C:\Temp

Cloud Account Discovery (T1087.004):

az ad user list --output table
aws iam list-users
aws iam list-roles
gcloud iam service-accounts list

Microsoft Graph API abuse (T1087.003 and T1087.004):

Attackers with a valid OAuth token query the Graph API directly to enumerate users and group memberships without triggering traditional on-premise logging:

curl -H "Authorization: Bearer <token>" \
  "https://graph.microsoft.com/v1.0/users?$select=displayName,userPrincipalName,jobTitle"

This pattern is particularly difficult to detect because it looks identical to legitimate application traffic. Detection requires Entra ID (Azure AD) sign-in logs and conditional access policy anomaly alerting.

Account discovery activity surfaces across multiple Windows log sources. The following Event IDs are highest-signal for T1087 detection. All require the appropriate audit policy to be enabled; many environments have these disabled by default.

Process Execution Logging (requires Audit Process Creation + command-line auditing):

• Event ID 4688: A new process has been created. When paired with command-line argument logging, this fires on every net user, dsquery, or whoami execution. The critical field is Process Command Line. Without this field populated, 4688 is nearly useless for T1087 detection.

PowerShell Script Block Logging:

• Event ID 4103: Module logging output. Captures pipeline execution results.
• Event ID 4104: Script block logging. Captures the full text of every PowerShell script block executed, even obfuscated ones that are decoded at runtime. This is where Get-DomainUser and Invoke-BloodHound appear in the logs. Enable via Group Policy: Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on Script Block Logging.

Active Directory Object Access (requires Audit DS Access):

• Event ID 4661: A handle to an object was requested. This fires when a process opens an Active Directory object for read access. BloodHound and LDAP enumeration tools trigger this at high volume against the user and group object classes.
• Event ID 4662: An operation was performed on an object. Fires on read operations against AD objects. The Properties field identifies which attributes were read. Mass reads of samAccountName, memberOf, userAccountControl, and lastLogonTimestamp within a short window are a strong BloodHound indicator.

Logon Events (context enrichment):

• Event ID 4624: An account was successfully logged on. Use Logon Type to distinguish interactive (2), network (3), and remote interactive (10). T1087 activity performed over the network after a network logon correlated with 4624 Type 3 is a high-confidence lateral movement precursor.

Recommended audit policy settings to capture the above:

Audit Process Creation: Success
Audit Directory Service Access: Success, Failure
Audit Directory Service Changes: Success
PowerShell Module Logging: Enabled
PowerShell Script Block Logging: Enabled
Command Line Process Auditing: Enabled (via registry or GPO)

The following KQL query detects account discovery activity using process creation events (SecurityEvent table with Event ID 4688) and PowerShell Script Block logs (Event table). It is designed for Microsoft Sentinel and produces a single alert per host per hour when multiple discovery commands are observed within a rolling window.

let DiscoveryCommands = dynamic([
    "net user", "net group", "whoami /all", "whoami /groups",
    "query user", "dsquery user", "dsquery group",
    "Get-ADUser", "Get-ADGroupMember", "Get-DomainUser",
    "Get-DomainGroupMember", "Find-LocalAdminAccess",
    "Invoke-BloodHound", "SharpHound", "ldapsearch"
]);
let TimeWindow = 30m;
let MinCommands = 3;
let ProcessEvents = SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4688
| where isnotempty(CommandLine)
| extend CommandLineLower = tolower(CommandLine)
| where CommandLineLower has_any (DiscoveryCommands)
| project TimeGenerated, Computer, Account, CommandLine, ParentProcessName, ProcessName;
let PSEvents = Event
| where TimeGenerated > ago(1d)
| where Source == "Microsoft-Windows-PowerShell"
| where EventID in (4103, 4104)
| extend MessageLower = tolower(RenderedDescription)
| where MessageLower has_any (DiscoveryCommands)
| project TimeGenerated, Computer, Account = UserName, CommandLine = RenderedDescription, ParentProcessName = "powershell.exe", ProcessName = "powershell.exe";
union ProcessEvents, PSEvents
| summarize
    CommandCount = count(),
    Commands = make_set(CommandLine, 20),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by bin(TimeGenerated, TimeWindow), Computer, Account
| where CommandCount >= MinCommands
| extend
    TimespanMinutes = datetime_diff("minute", LastSeen, FirstSeen),
    AlertSeverity = iff(CommandCount >= 10, "High", "Medium")
| project
    TimeGenerated,
    Computer,
    Account,
    CommandCount,
    Commands,
    FirstSeen,
    LastSeen,
    TimespanMinutes,
    AlertSeverity
| order by CommandCount desc

Tuning notes: Set MinCommands to 5 in environments with frequent legitimate AD tooling (helpdesk scripts, Ansible/DSC). Add a process parent allowlist to exclude known SIEM agents and monitoring tools. The AlertSeverity threshold of 10 commands should be adjusted based on your baseline.

The following SPL query targets account discovery in environments using Splunk Enterprise Security with the Sysmon data model or Windows Security Event logs forwarded via the Splunk Add-on for Microsoft Windows.

index=wineventlog (EventCode=4688 OR EventCode=4103 OR EventCode=4104)
| eval CommandLine=coalesce(CommandLine, Message)
| eval CommandLineLower=lower(CommandLine)
| where match(CommandLineLower, "net\s+user|net\s+group|whoami\s+/all|whoami\s+/groups|dsquery\s+user|dsquery\s+group|get-aduser|get-adgroupmember|get-domainuser|get-domaingroupmember|find-localadminaccess|invoke-bloodhound|sharphound|ldapsearch")
| eval AccountName=coalesce(Account_Name, user)
| eval HostName=coalesce(ComputerName, host)
| bin _time span=30m
| stats
    count as command_count,
    values(CommandLineLower) as commands,
    min(_time) as first_seen,
    max(_time) as last_seen
    by _time, HostName, AccountName
| where command_count >= 3
| eval severity=if(command_count >= 10, "high", "medium")
| eval duration_minutes=round((last_seen - first_seen) / 60, 1)
| table _time, HostName, AccountName, command_count, severity, duration_minutes, commands
| sort - command_count

For BloodHound/SharpHound specifically, add a dedicated hunt for the characteristic LDAP filter strings SharpHound uses. SharpHound issues LDAP queries with filters like (objectclass=user), (objectclass=group), and (objectclass=computer) in rapid succession from the same source IP. This pattern is highly distinctive:

index=wineventlog EventCode=4662
| where match(Properties, "(?i)(samaccountname|memberof|useraccount|lastlogon|pwdlastset|admincount)")
| stats count as ldap_reads, dc(ObjectName) as unique_objects, values(SubjectUserName) as accounts by ComputerName, SubjectUserName, bin(_time, 5m)
| where ldap_reads > 100 AND unique_objects > 50
| eval alert="Potential BloodHound enumeration"

The following attack chain is representative of how Black Basta affiliates and similar ransomware operators have used T1087 as a pivot from initial access to domain-wide deployment.

T1087.004 is where most SOC teams have the least coverage. On-premise Windows Event Log pipelines do not capture Azure AD, AWS IAM, or Google Workspace enumeration. Attackers who obtain a valid OAuth token or cloud API key can enumerate thousands of users and service principals with no on-premise footprint at all.

Azure AD / Entra ID detection:

Microsoft Graph API calls and Azure AD enumeration appear in the Entra ID Sign-in Logs and Audit Logs (unified audit log category: DirectoryActivity). Key indicators:

AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName in (
    "List users",
    "List groups",
    "List group members",
    "List servicePrincipals",
    "List applications"
)
| where Result == "success"
| summarize
    OperationCount = count(),
    Operations = make_set(OperationName),
    TargetResources = make_set(TargetResources)
    by bin(TimeGenerated, 15m), InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), IPAddress = tostring(InitiatedBy.user.ipAddress)
| where OperationCount > 20
| order by OperationCount desc

AWS IAM detection via CloudTrail:

The following event names indicate account discovery in AWS:

• ListUsers
• ListRoles
• ListGroups
• GetAccountAuthorizationDetails (high value: dumps entire IAM configuration in one call)
• ListAttachedUserPolicies

A single GetAccountAuthorizationDetails call is a high-confidence indicator of T1087.004 because legitimate applications rarely need the full IAM dump. Alert on any principal outside your known IAM automation roles calling this API.

Google Workspace:

Admin SDK Directory API calls to users.list and members.list in the Google Workspace audit log (Admin Activity events) serve the same function. Scattered Spider has been documented abusing Workspace API access after compromising a service account key.

When a T1087 alert fires in production, the following runbook covers the first hour of response. Adjust timing and ownership to your organization's IR structure.

Step 1: Triage (0 to 10 minutes)

Determine whether the alert is a true positive or expected activity:

• Is the source account a known IT admin, service account, or authorized red team?
• Is the source host part of an authorized penetration test or vulnerability assessment?
• Does the volume and speed of queries match a known scripted IT process?

If none of the above explain the activity, treat as a true positive and escalate.

Step 2: Containment (10 to 30 minutes)

• Isolate the source host from the network via EDR (CrowdStrike contain, Microsoft Defender isolate, or equivalent). Do not power off: preserve volatile memory for forensics.
• Disable the source account in Active Directory if the account is a standard user. If the account is a service account, coordinate with application owners before disabling; rotate the password instead.
• Block the source IP at the perimeter firewall and any internal network segmentation controls.
• If cloud enumeration is suspected: revoke the OAuth token or API key. In AWS, attach an explicit Deny policy to the IAM principal; in Azure, revoke refresh tokens via Revoke-AzureADUserAllRefreshToken.

Step 3: Investigation Scope (30 to 60 minutes)

Account discovery by itself is reconnaissance; the attacker has not yet achieved their objective. The critical question is: what did they enumerate, and where have they moved since?

• Pull all process execution events from the source host for the 24 hours preceding the alert.
• Search for lateral movement indicators from the source host: 4624 Type 3 logons originating from the host to other systems, SMB connection logs, RDP session initiation.
• Search for credential access indicators: LSASS access events (Event ID 10 in Sysmon), Kerberoasting activity (Event ID 4769 with RC4 encryption type), or NTLM downgrade attempts.
• If BloodHound is suspected: identify all shortest paths from the compromised account to Domain Admin in your own BloodHound instance and prioritize those paths for immediate review.

Step 4: Post-Incident Hardening

• Implement LDAP signing and LDAP channel binding on all domain controllers to prevent anonymous or unauthenticated LDAP enumeration.
• Enforce Protected Users security group membership for all Tier 0 and Tier 1 accounts.
• Deploy Microsoft Defender for Identity (MDI) if not already present; it provides purpose-built detection for SharpHound, BloodHound, and LDAP-based enumeration with lower false positive rates than generic SIEM rules.
• Review service account Kerberos delegation settings: remove unconstrained delegation everywhere; replace with resource-based constrained delegation where technically required.

The single highest-ROI action most organizations can take is enabling PowerShell Script Block Logging (Event ID 4104) via Group Policy. This one change surfaces BloodHound, PowerView, and every other PowerShell-based discovery framework without requiring any additional tooling or licenses.