T1087.002

Domain Account

Windows

What it is

Domain account discovery is the act of asking Active Directory who exists. Which user accounts are in the domain, which groups they belong to, who administers what, and which accounts are privileged enough to be worth attacking next.

Nothing is exploited to do this. Active Directory is BUILT to answer these questions, and by design any authenticated domain user can read most of the directory, because ordinary software needs that to function. A user account with no special rights at all can enumerate the domain from a standard workstation using tools that ship with Windows.

That design decision is what makes this technique so awkward to detect. There is no exploit to catch, no malware to flag, no privilege boundary being crossed, and no error raised anywhere. The same queries an attacker runs to build a target list are the queries a helpdesk technician runs to do their job, executed by the same binaries, and frequently by an account that is genuinely entitled to run them.

Note the boundary with the neighbouring technique. Account Discovery is about WHO EXISTS: the accounts themselves. Permission Groups Discovery (T1069.002) is about WHAT A GROUP GRANTS. In practice an attacker does both in the same sitting, and the same commands often serve both, which is why a real intrusion usually lights up both techniques within a couple of minutes.

How adversaries use it

This is early-stage work. It happens after a foothold is established and before lateral movement, because it is how the attacker decides where to move. An intruder who has just landed on a workstation knows almost nothing useful: they need to learn who they are running as, what that account can reach, which accounts are privileged, and which hosts are worth the next step.

The usual progression is outward from self. Start with the current account and its group memberships, then the domain's user and group lists, then the privileged groups specifically, then the members of those groups. Each answer narrows the next question. The whole sequence commonly takes under a minute of wall-clock time.

The tooling is deliberately boring. net.exe and net1.exe, nltest, dsquery, whoami /groups, net group /domain and the Active Directory PowerShell cmdlets are all signed Microsoft binaries that are present on a standard Windows install and run constantly during normal administration. Using them means nothing has to be dropped to disk, nothing is unsigned, and nothing looks foreign to an inventory of installed software. This is why the technique is so heavily favoured: it is free, it is quiet, and it works on every domain-joined host.

There is a quieter form still. The directory can be queried directly over LDAP from within a script or a compiled tool, without ever launching one of those binaries. That path produces NO suspicious command line at all, because no new process is created. An estate that hunts only for process names will not see it, which is worth knowing before trusting a clean result.

Detect it in Elastic

Data source: Endpoint process-execution telemetry from Windows hosts, carrying the full command line and the parent process for each execution, read together with directory-service query telemetry from the domain controllers where the estate collects it

Key fields

The full command line is the primary evidence, and the binary name on its own is close to worthless here. Every tool involved is a signed Microsoft utility that also runs legitimately, often many times a day, so process.name alone selects thousands of benign executions. The ARGUMENTS are what separate a domain-scoped query from a routine local one.

Key fields: process.command_line (the whole string, not a prefix), the parent process, the executing account, the host, and an accurate timestamp, which is what makes the burst visible at all.

On the domain controller side, where auditing is configured for it: Event 4662 records access to a directory object and is the closest thing to a record of the query itself, while Events 4798 and 4799 record enumeration of a user's local group membership and of a security-enabled local group. Be realistic about these. All three are extremely high volume, 4662 in particular is usually filtered down heavily or turned off entirely in production estates, and many domains do not collect them at all. Treat them as a bonus signal when present rather than as the plan.

Hunt guidance

Rank the discriminators, because they are not close to equal and the weakest one is the one most people reach for first.

Strongest is the ARGUMENTS. A domain-scoped query is a different act from a local one, and the command line is where that distinction lives. Filtering on the binary name and reading what comes back is the wrong shape of hunt: it produces a pile of legitimate executions with the interesting ones buried inside.

Next is SEQUENCE. One enumeration command is unremarkable. Several distinct queries in quick succession, escalating from the current account outward to privileged groups and then stopping, is a recognisable shape that ordinary administration rarely produces. Reconnaissance is a burst that ends; administration is scattered across the day.

Next is the PARENT PROCESS. These commands normally descend from an interactive administrative shell. The same command descending from an Office application, a browser, a scripting engine or a service process is a strong signal regardless of what the arguments say.

Next is ACTOR CONTEXT. An account and a host with no administrative reason to be asking these questions matter more than the commands themselves.

WEAKEST, and the trap, is the binary name in isolation. It is present in every baseline in the world.

A practical method that does not depend on knowing what to search for: anchor on something you already believe, such as a confirmed foothold, take its timestamp and process tree, and list everything that process spawned over the following few minutes sorted by time. Discovery activity tends to appear as a cluster immediately after the foothold, and reading forward from a known point finds it without needing a filter that already describes the answer.

Remember the LDAP path when a hunt comes back clean. Absence of suspicious process executions is not absence of enumeration.

Ruling out legitimate activity

Assume benign until the context says otherwise, because on this technique the benign population is enormous and genuinely looks the same.

Administrators and helpdesk staff. Looking up who is in a group is routine support work. The commands, the arguments and often the privilege level are identical to an attacker's.

Logon and Group Policy scripts. Many estates run net commands at every logon to map drives or check membership. That produces the same process executions at very large scale, on every workstation, every morning.

Inventory, asset-management and monitoring agents. These enumerate accounts and groups on a schedule. The cadence is the tell: automation repeats on a regular interval, whereas reconnaissance is a one-off burst that does not come back tomorrow at the same minute.

Security and audit tooling. Compliance scanners and access-review jobs enumerate the directory comprehensively, which can look far more aggressive than a real attacker does.

Software installers and line-of-business applications. Plenty check group membership at startup to decide what to enable.

What actually separates them: the schedule (periodic versus a single burst), the parent process (a service or scheduler versus an interactive or spawned shell), whether the account has a legitimate administrative role, and whether the activity sits immediately after something else you already consider suspicious. That last one carries the most weight. Discovery is rarely interesting on its own, and is very interesting a minute after an unexplained foothold.

Practice it

1 scenario in this catalog covers T1087.002. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →