Domain Account

Creating a domain account is persistence by paperwork. Rather than leaving an implant on a machine, the attacker adds an identity to the directory, and from then on they have a legitimate way in that does not depend on any host staying compromised.

It is the most durable form of persistence there is, and the hardest to remove by reflex. Reimage the machine and the account survives. Reset the password of the credential that was stolen and the account survives that too, because it is a separate principal with its own password. Unless somebody specifically goes looking for accounts that should not exist, it simply becomes part of the directory.

This comes after access, not before it: an attacker creates a domain account once they already hold a credential with the rights to create one. That is often not an administrator. Directory permissions are routinely delegated in narrow slices to help desks and to team administrators, and a slice that allows creating user objects in one container is enough.

The account is usually made to look boring. Service-account naming, a plausible description, a container full of similar objects. It may be left disabled and unused for a long time, which is the point: an attacker who is evicted next month still has a way back, and an account that has never done anything attracts no attention from anything watching behaviour.

One property makes this more findable than attackers expect. A directory write is recorded by the directory, on a different host, under different administrative control from the machine the command was typed on. Whatever is done to the logging where the attacker is working, the object still gets written somewhere else, and that somewhere else keeps its own record.

Data source: Domain controller's Windows Security event log -- user account creation (Event 4720), naming both the created account and the creating context, and the enable, password and group changes that follow

{
  "host": {
    "name": "example-dc"
  },
  "event": {
    "code": "4720",
    "action": "User Account Management"
  },
  "winlog": {
    "event_data": {
      "SamAccountName": "newuser01",
      "TargetUserName": "newuser01",
      "SubjectUserName": "a.admin"
    }
  }
}

Prebuilt Elastic rule: User Account Creation

Domain account creation is high-value and low-volume, so this is one of the rare techniques where you can review every instance. Pull account creations on the domain controllers over a period and reconcile the list against the system of record: the HR or identity-management process that is supposed to be the only thing creating accounts. Anything not in that list is worth a name.

Three discriminators do most of the work. WHO: is the creating context one of the provisioning service accounts, or is it a human account working interactively? WHERE: was the object created in the container accounts normally go into, or in one where some other team happens to hold rights? AND WHAT FOLLOWED: was the account enabled, given a password and put into groups in the usual sequence, or does it sit there incomplete?

When the creating context is a human account, do not stop at the account. The security context recorded on a directory write is the identity of the connection that wrote the object, which is not necessarily the account the process on the originating machine was running as. That cuts both ways: a task running with high local privilege can write an object under a stolen user's name, and the record will say so truthfully. So treat the name on the event as the credential that was used, and go and look at how that credential was behaving just before.

Finally, ask the standing question this event always raises: what permission let that account create an object there at all? An account creating users successfully is an account that had the right to, and whether it should have had it is usually the more durable finding.

Organisations create accounts constantly, and provisioning systems create them in ways that look automated because they are: from a service account, in a consistent container, in bursts that follow the joiner process, and with the full sequence of enable, password and group events behind them.

The shapes that are not that: a creation by an interactive human account rather than a provisioning identity; a creation outside any change or onboarding window; an account whose name imitates a service or system account without belonging to any service; a creation in a container that is not where accounts normally land; and a creation that stops short, with no enable and no password, which can mean an incomplete automation run but can equally mean the creator only had permission to get that far.

Two cautions. Help desk and delegated administration are legitimate and common, so a human account creating a user is not by itself an incident; it is a question about that account's activity in the surrounding hour. And a persistence account is not always used immediately. Absence of subsequent logons for the new account is not evidence it is benign, which is why this finding is usually contained on its own timeline rather than the intrusion's.

• MITRE ATT&CK: T1136.002 Create Account: Domain Account
• Elastic Security: User Account Creation

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