Detecting T1087 Account discovery

How T1087 account discovery shows up before an attacker picks a target

Account enumeration is one of the quietest steps in an intrusion, and it often looks like routine administration. For a SOC lead, the practical question is not whether listing accounts is suspicious in itself, but whether a given identity has any reason to be listing them at that moment. Under the Discovery tactic (TA0007), MITRE describes the adversary as "trying to figure out your environment." Account Discovery, T1087, is where that effort focuses on people and identities: which accounts exist, which of them are privileged, what roles they hold and which groups they belong to. That map tells an attacker which accounts are worth targeting next, so the same few commands and queries show up in many intrusions long before any credential is used.

The technique is not tied to one operating system. The four sub-techniques cover local accounts, domain accounts, email accounts and cloud accounts, which means the telemetry you need sits in different places: process and command logs on hosts, directory and identity provider audit logs, mail platform logs and cloud control plane logs. Each platform has its own normal administrative pattern, so a single detection rule written for one environment will miss or over-alert in another. Before tuning anything, confirm which platforms and identity sources are in scope for your environment, and which of them forward logs to your SIEM at a level of detail that includes the querying identity, the source host and the target object.

Target the mapping to ATT&CK Enterprise 20.0, and record that version in every detection you write, since MITRE can rename or revoke techniques between releases. A practical first decision is to agree which identities are allowed to enumerate accounts as part of their job, such as directory administrators, helpdesk tooling and backup or monitoring service accounts, and to treat any enumeration from outside that list as a question to answer. Ask your team to confirm the current technique and sub-technique IDs against the MITRE ATT&CK tactic page for Discovery before you add them to a detection backlog.

Which telemetry reveals account discovery and which open-source tool collects it

This table maps the data components relevant to T1087 Account Discovery to each platform in scope, with the signal to look for and the open-source collector that gathers it. Read each row as a starting point: confirm the exact sub-technique and data component mapping against the ATT&CK 20.0 STIX bundle before writing detection rules. The main takeaway is that identity provider and cloud coverage depends on application and audit logs, not only on endpoint process telemetry.

Platform	Telemetry and signal to look for	Open-source collector and hunting use
Linux hosts	Process Creation (DC0032) and Command Execution (DC0064): account listing or group membership queries run by unexpected users or from unusual parent processes	Auditd or equivalent process logging forwarded to Wazuh agents; Velociraptor for hunting account and group files across endpoints
Linux account files	File Access (DC0055): reads of local account and group database files by processes that do not normally need them	Wazuh file integrity and audit rules on account database paths; Velociraptor artifacts for scheduled sweeps
ESXi hosts	Command Execution (DC0064) on the hypervisor shell and related host-level logs showing account enumeration from new sessions	Syslog forwarded to Wazuh or a Security Onion pipeline; confirm which ESXi log sources your version exposes
IaaS control plane	Application Log Content: cloud audit events showing identity or account list calls from principals outside their normal role	Cloud provider audit logs exported to a SIEM such as Wazuh; confirm event names with the provider's documentation
Identity provider	Application Log Content: directory query and user listing events, especially bulk reads by service or admin accounts	Identity provider audit exports ingested by Wazuh with custom decoders; Sigma rules translated to the SIEM query language
Network sensors	Network Traffic Content: directory protocol queries (for example LDAP) from hosts that do not normally query the directory	Zeek or Suricata sensors feeding Security Onion; rules tuned to the directory servers in your environment
Windows and cross-platform endpoints	Process Creation and Command Execution for account listing commands, where Windows or macOS hosts share the estate	Sysmon-equivalent process logging forwarded to Wazuh; Velociraptor for interactive hunting

Why account enumeration blends into normal administration

Account enumeration is one of the most routine things an identity platform does, so a SOC cannot treat a single listing event as suspicious. Domain controllers, Linux hosts, identity providers and cloud consoles all answer queries about who exists. Administrators run these queries during onboarding and audits, monitoring agents poll them on a schedule, and provisioning jobs such as directory sync tools and configuration management runs enumerate accounts before they create, change or remove them. An alert keyed only to a command such as a user listing or a group membership query will fire all day and teach analysts to ignore it. The detection has to combine the source host, the account making the request, the time of day, and what the same session did before and after the query.

Build the baseline per platform before tuning any rule. On Linux, record which service accounts and automation hosts routinely read the account database or run group queries, and from which parent processes. On Windows domain environments, list the management workstations, backup and inventory servers, and directory sync accounts that issue directory queries, along with their normal hours. On identity providers and IaaS consoles, export the set of application identities and automation roles that list users, groups or roles, and note which ones run from known CI/CD networks. The usual false positive sources are vulnerability scanners, asset inventory agents, helpdesk tools, SIEM and EDR collectors themselves, and newly onboarded applications that have not yet been profiled. Confirm each source with its owner in writing and record the review date, because service accounts change ownership and infrastructure often moves.

Treat the baseline as a living control, not a one-time spreadsheet. Review it after every onboarding wave, every change to privileged group membership and each ATT&CK version update that renames or splits sub-techniques, because detection mappings should name the version they target. Pair enumeration alerts with a sequence rule, for example an unfamiliar account enumerating users and then requesting elevated group membership within a short window, so that analysts see context and not just a count. Ask your team to document which baseline entries were approved by whom, so auditors and incident responders can see why a given enumeration pattern was accepted as normal.

Detection logic for each platform, with thresholds and false positives to tune

The four ideas below cover the platforms where T1087 Account Discovery shows up most often: Linux hosts, ESXi, identity providers and IaaS control planes. Each one is written as detection logic in words, with a starting threshold that should be set against your own baseline and the benign sources that will trigger it first. Express the final rules in Sigma so they can be converted to your SIEM and reviewed like code.

Local account enumeration on Linux

Flag reads of the local account databases, such as the password and group files, or enumeration commands run from sessions that are not administrative and have no change ticket or job schedule behind them. Process Creation and File Access events on the account store are the core telemetry. Start by counting distinct account-enumeration events per user per host over a short window and alert on a count well above the normal baseline for that role. Expect false positives from configuration management agents, backup agents, monitoring checks and login-policy scripts, so allowlist them by parent process and service account rather than by user name.

Bulk account listing on ESXi

On ESXi, look for a single administrative session that lists the local user and role inventory across several hosts in a short period, especially when the session originates from a jump host that does not normally manage hosts. Command Execution logs from the host shell and the management plane audit trail are the main sources. Set the threshold against the number of hosts your administrators touch in a normal shift and alert on crossing it. Monitoring tools, inventory collectors and hypervisor backup jobs commonly produce the same pattern, so record their service accounts and source addresses before tuning.

Identity provider directory queries

Alert when a principal that is not an IAM administrator or sanctioned sync service queries user or group directories through the identity provider API at a volume outside its own history. Relevant telemetry includes directory query audit events and the account metadata returned for each query. A practical starting point is a per-principal baseline of directory reads per day, with an alert at a multiple of the 30-day median that you agree with your identity team. Provisioning connectors, HR synchronization, access reviews and helpdesk tools are the usual false positives, so document each one with its expected query pattern.

IaaS identity listing from new sources

Watch for control-plane calls that list users, roles or service principals and originate from a source address, region or client application that has never made such calls for that account. Cloud audit logs with source address, user agent and identity fields are the key data. Build the allowlist from known automation hosts and CI runners, then alert on first-seen source and identity pairs that also perform listing operations. Vulnerability scanners, cost management tools, compliance scanners and IAM governance platforms are the main false positive sources, so confirm their egress ranges and tag them in your inventory before you enable the rule.

How to prove the detection fires before you trust it

This sequence turns a T1087 Account Discovery detection from a rule that looks right on paper into one that has been shown to fire, on time, with usable fields, on each platform in scope. It ends with a test log that ties every result to the ATT&CK version it was written against.

Scope the platforms and the behavior under test
The detection owner and the platform team agree which platforms are in scope for T1087 Account Discovery, such as ESXi, IaaS, the identity provider and Linux hosts, and which of the four sub-techniques each platform can reasonably see. For each platform, write the emulated behavior in plain language only, such as enumerating accounts from a session that normally never does so. No commands are recorded in the plan. The step is done when the scope is signed off and every in-scope platform has a one-line behavior description.
Set expected alerts and fields per platform
For each platform, the detection owner writes down what should happen: which data component is expected to produce the event (for example Process Creation, Command Execution or File Access), which alert should fire, what severity it carries, and which fields must be present, such as the host, the user context and the process lineage. Expected results are written before the emulation runs so the team cannot adjust them afterward. The step is done when each platform has a written expectation the reviewer has approved.
Pin the ATT&CK version and open the test log
Record the ATT&CK version the detection maps to, because releases can rename, deprecate or revoke techniques and sub-techniques. Create the detection test log with columns for the ATT&CK version, the technique and sub-technique ID, the platform, the detection identifier, the date of the run and the tester. Confirm the mapping against the current STIX data for that version before the run. The step is done when the log exists and the version is written on its first line.
Run the emulation in an isolated range
A tester runs the agreed emulation in a private cyber range or lab that mirrors the production logging pipeline, not in production. Each run is timestamped, and the tester notes the start and end of each action. The tester does not improvise beyond the written behavior. The step is done when every platform has been exercised once and the raw event timestamps are saved with the run record.
Measure time to alert, fields and fidelity
Compare the saved timestamps with the time each alert reached the analyst queue to calculate time to alert for each platform. Check each alert against the field list from the expectation step, and judge fidelity by whether the alert points to the right host, account and process context without requiring a manual lookup. Note false positives raised by normal administrative activity. The step is done when each platform has a recorded latency, a field check result and a fidelity note in the test log.
Tune the rule and rerun the same emulation
Where an alert missed, fired late, lacked fields or was noisy, the detection engineer adjusts the rule, enrichment or log collection and records what changed and why. The tester then reruns the same written behavior on the same platforms so the result compares directly with the first run. Tuning changes that cannot be reproduced are not accepted. The step is done when the rerun is logged against the original run with the changes listed.
Review the log and accept or hold the detection
The detection owner and an independent reviewer read the full test log, confirm every in-scope platform has a passing run on the pinned ATT&CK version, and decide whether to accept the detection, accept it with stated gaps or hold it. Open gaps, such as a platform whose logs do not carry the needed fields, are assigned owners. The log is retained with the rule so the evidence survives later ATT&CK releases. The step is done when the decision and its gaps are recorded.

Preventive controls that shrink what account discovery reveals

Account discovery succeeds when an attacker can read account lists that were never meant to be visible to them. The two ATT&CK mitigations covered here, User Account Management and Operating System Configuration, reduce what those lists reveal and who can request them. Each card names one control point and one check to confirm it against the ATT&CK 20.0 mitigation pages.

Least privilege on directory reads

Directory and identity queries that enumerate users, groups and roles should be limited to the service accounts and administrators who need them. Review which service principals, LDAP binds and API tokens can list all accounts, not just their own record. Many environments grant broad read access by default for convenience, and that access is exactly what an adversary uses for T1087 Account discovery. Confirm that enumeration rights are scoped by role and reviewed on a fixed schedule.

Removing stale and dormant accounts

Dormant user, service and test accounts add entries to every account listing an adversary can retrieve. Lifecycle processes should disable accounts when people leave, when projects end and when service owners change. Compare identity provider and host account inventories regularly, because accounts that exist only on one platform are often forgotten. Ask whether each platform has an owner who can justify every enabled account.

Restricting account listing on hosts

On Linux and other hosts, local account files and group memberships are readable by default in many configurations, and that is intentional for normal operations. The question for operating system configuration is which local accounts, sudo rules and group memberships are needed at all, and which tools can read them. Restrict unnecessary interactive shells for service accounts and review administrative group membership against a documented baseline. Confirm the hardening baseline is applied, drift-checked and mapped to M1028.

Limiting enumeration on hypervisors

ESXi and other hypervisor management planes expose local user and role lists to administrators and sometimes to service integrations. Restrict who can authenticate to the management interface and to the shell, and keep administrative roles to named, reviewed groups. Vendor documentation for each hypervisor version defines the exact roles, so confirm the permission model in the version you run. Check that no shared or generic administrator account exists on the management plane.

Hardening identity provider query permissions

Identity providers often let any authenticated user query basic directory objects, and some integrations request wider read scopes than they use. Review the scopes granted to applications, the default user-read permissions and any custom roles that allow listing users or groups. Narrow them to what each application requires and log changes to those permissions. Verify that application consent and admin-granted scopes are reviewed, not just approved once.

Confirming mappings against ATT&CK 20.0

Mitigation mappings change between ATT&CK releases, so the link between a control and a technique should be checked, not assumed. Confirm the current mappings for User Account Management and Operating System Configuration on the ATT&CK 20.0 mitigation pages, and record the version in your control evidence. Treat this page as a starting point for that review. Name the ATT&CK version in every detection and control mapping you keep.

Triage steps when an account discovery alert fires

Start by confirming what the alert describes: the source account, the host or tenant where the enumeration ran, and the process or API call that produced it. Record whether the identity is a human user, a service account or a workload identity, and review its recent group and privilege changes. A service account listing groups on a build server means something different from an interactive user doing the same on a domain controller. Next, check whether the activity matches an approved admin or automation job. Ask the owning team for the change ticket, job schedule or runbook entry, and confirm the expected host and command pattern. If nothing matches, escalate the alert for investigation and keep it open until the owner has answered.

Correlate the alert with authentication and session events for the same identity across the preceding window. Look for an unfamiliar sign-in source, a new logon session on a host the account rarely uses, a token issued without a matching interactive login, or failed attempts that came before the enumeration. Then scope the blast radius: which other hosts, cloud accounts, identity provider tenants or SaaS workspaces did the same identity touch, and did they record Cloud Service Enumeration or Instance Enumeration events in the same period? Confirm how far back your logs reach before drawing conclusions, since the depth of history depends on how your platform retains data.

Choose containment in proportion to confidence. If the activity is unexplained and the identity holds elevated rights, disable the session or revoke the token through the identity provider and reset the credential, while the affected host stays online for examination. Before changing anything, preserve evidence: export the relevant log windows, snapshot the affected host or cloud resource where your procedure allows, and record the time and hash of each export so the chain of custody holds. Involve incident response leads as soon as the identity is privileged, the activity spans more than one host or tenant, or a second technique such as credential access appears. Document each decision with timestamps, because responders and auditors will ask for that record.

Rehearsing account discovery detection in a private cyber range

This track builds a private range with a small set of Linux hosts and an ESXi host or nested virtual lab, each forwarding authentication and process telemetry to an open-source stack such as Wazuh, with Security Onion or Zeek sensors where network visibility is needed. The exercise team plays a scenario in which an operator who has gained a foothold begins listing local accounts and group memberships on a host, then repeats the pattern on the hypervisor management plane. Injects are described as scenario events: an unfamiliar session appears on a Linux host, a service account is used outside its normal window, and a management login to ESXi follows shortly after. Good detection means the Process Creation and Command Execution alerts fire within the agreed window, are enriched with the user, parent process, host role and whether the account is a known administrator, and carry triage notes that separate routine inventory tasks from enumeration. Good response means the analyst makes a documented containment decision, such as suspending the session or restricting the account, and records what telemetry was missing. Confirm with your own platform team which audit settings and log sources are enabled before the exercise starts.

Questions detection engineers and SOC leads ask about account discovery

How do I separate account enumeration from normal directory sync?

Start by baselining the accounts, service principals and hosts that legitimately query your directory on a schedule, then alert on deviations from that baseline rather than on the query itself. Directory sync agents, backup jobs and identity governance connectors usually run from known hosts, under known service accounts, at predictable intervals. Enumeration by an adversary tends to come from an unexpected host or interactive session, uses broad queries across many accounts in a short window, and follows other discovery activity. Document the baseline per data source so that exceptions are reviewed, not silently suppressed.

Which account discovery telemetry is most often missing on ESXi?

On ESXi hosts, the most common gap is that command execution and shell activity are not forwarded to a central log platform, so account listing performed from the local shell is invisible to the SOC. Confirm whether the shell and authentication events are enabled, where they are written, and whether the forwarding agent or syslog configuration captures them with host names and user identities intact. Also check vCenter audit logs, which record many management actions that the hosts themselves do not. Validate this with a test in a private cyber range before relying on it in production.

How do I handle false positives from identity governance tools?

Identity governance, access review and provisioning tools enumerate accounts by design, so they will trigger naive rules constantly. Create an allowlist keyed on the specific service account, source host, application identifier and time window, and review that list whenever the tool is upgraded or its connectors change. Keep the exception tied to a documented owner so that the suppression is auditable. Avoid excluding the whole tool, because a compromised connector credential would then look normal.

How often should I re-test account discovery detections after ATT&CK updates?

Re-test whenever you adopt a new ATT&CK version, because releases can rename, deprecate or revoke techniques and change the data components that detections reference. Recent releases in the ATT&CK update cadence were v18 in October 2025, v19 in April 2026 and v20 in October 2026, so map your rules to a named version and check the release notes for T1087 and its sub-techniques. Also re-test after any change to logging sources, such as a new identity provider tenant or a log forwarder upgrade, since those changes break detections silently.

How should I log identity provider queries for account discovery?

Identity provider queries are usually recorded in the provider's audit or sign-in logs, not in endpoint telemetry, so confirm which event types cover directory reads and admin API calls. Forward those logs to your SIEM with the calling principal, source IP, user agent, application and result preserved. Set retention to meet your own investigation and compliance needs, and check whether your plan or license tier includes the audit events you need. Ask the provider and your SOC to confirm field names, because they vary between platforms.

Can my own team build and maintain these detections without outside help?

Many teams can, provided they have someone who understands both the logging platform and the adversary behavior behind T1087. The work splits into building log collection, writing and tuning rules, validating them, and maintaining them after upgrades. Ask any partner to describe its scope in writing, including which data sources, platforms and ATT&CK version are covered, and who owns tuning after handover. DeployOpen plans and implements self-hosted open-source platforms in your own environment and runs cyber range rehearsals, so the scope of any engagement is set in writing before work starts.

What should a rehearsal of account discovery detection prove?

A useful rehearsal proves that the telemetry exists, the rule fires on the expected platform, the alert reaches an analyst, and the analyst can follow a documented response. Run the exercise in a private cyber range that mirrors your identity provider, hypervisor and Linux estate, and record the results against the ATT&CK version your rules target. Treat gaps as tickets with owners, and repeat the exercise after each logging or platform change. The output is evidence your team can show auditors and leadership, not a guarantee that every variant will be caught.

Official ATT&CK sources to check before you map this technique

Before you write a detection for T1087 Account discovery, confirm which ATT&CK version your mappings target and check the technique against the official MITRE sources for that version. Account discovery sits under the Discovery tactic (TA0007), and the tactic page describes the goal as the adversary trying to figure out your environment. That framing matters for scoping: account enumeration on ESXi, IaaS, Identity Provider and Linux platforms is one of several discovery behaviors, so your rule set should record exactly which platforms and sub-techniques it covers. Start with the MITRE ATT&CK tactic page for Discovery to confirm the tactic definition and the list of techniques it contains.

Next, read the ATT&CK updates page for every release since the version your detections were written against. ATT&CK v18 (October 28, 2025) replaced technique-level detections with detection strategies and analytics, updated data components and deprecated some data sources, so any Process Creation or Command Execution mapping you wrote for T1087 before that release should be re-checked against the new data component IDs. Releases can also rename, deprecate or revoke techniques and sub-techniques. The owner of your detection content should record the ATT&CK version in each rule's metadata and re-run the check at every upgrade.

For a machine-readable check, download the Enterprise 20.0 STIX bundle from the enterprise-attack 20.0 bundle in the attack-stix-data repository. Search it for T1087 and its sub-techniques, confirm the platforms and data components listed for each, and compare them with your SIEM rule inventory. Note that the bundle is one version of the content, so a mapping that passes against version 20.0 still needs review if your environment is on an earlier release. Document the check, the version and the reviewer so auditors can trace the mapping.

How DeployOpen builds account discovery detections and range exercises

DeployOpen approaches T1087 Account discovery as a defined engagement: the telemetry, platforms and sub-techniques are agreed in writing first, then detections are built on open-source tooling inside the client's own environment and rehearsed in a private cyber range. Engagements are fixed-scope, and the work ends with documentation the client's own team can run.

How we scope

Confirm which of the four T1087 sub-techniques apply to your estate, including Linux, ESXi, IaaS and Identity Provider accounts.
Inventory the telemetry you already collect for Process Creation, Command Execution and File Access before writing any detection logic.
Record the ATT&CK version each detection targets, since releases can rename or deprecate technique content.

How we build

Write detection logic in your Wazuh, Security Onion or Sigma pipeline, mapped to the data components referenced for T1087.
Map each detection to the ATT&CK mitigations User Account Management and Operating System Configuration, and note where coverage is partial.
Tune alert thresholds against your normal administrative activity so that routine account queries do not flood the queue.

How we hand over

Deliver written detection and response runbooks that name the data source, expected log fields and triage steps for each alert.
Provide cyber range exercise scripts that a defender can rerun, with expected detections recorded for each run.
Document validation results and open gaps so your compliance and security leads can review them independently.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement closes.
Re-run range exercises when your platforms change or when MITRE publishes a new ATT&CK version that touches T1087.
Confirm with your team which parts of ownership stay in-house, so the retainer covers only the agreed services.

T1087 Account discovery