Backdoor Accounts and Group Changes
Also calledpersistence accounts, rogue admin accounts
Leaves an account behind, or adds one to a privileged group, as a quiet way back in.
- Technique
- MITRE ATT&CK T1136.002: Create Account: Domain Account (opens in a new tab)MITRE ATT&CK T1098.007: Account Manipulation: Additional Local or Domain Groups (opens in a new tab)
- Needs
- Directory WriteorDomain Admin
- Gives
- Account Access
How the Attack Works
Once an intruder holds enough rights over the directory, the quiet way to keep access is to leave an account behind, or to put an account into a privileged group so it inherits that group's reach. Both are ordinary administrative actions, so the signal is not the action itself but who did it, to what, and whether it was expected. A domain controller records each change in its Security log, naming the account that made it.
Read first Authentication and Authorisation
How It Plays Out
The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.
ws-042 Foothold
dc-01 Domain controller
Step 1 of 3: Account Created
ws-042 Foothold to dc-01 Domain controller
A domain account that no joiner request explains appears in the directory, created from the foothold on ws-042.
Logged
4720 A user account was created
On dc-01, in the Security log
A new user account, with the account that created it as the subject.
What Defenders See
The Security log on dc-01 shows event 4720 naming the new account and, as the subject, the account that created it.
Step 2 of 3: Group Change
ws-042 Foothold to dc-01 Domain controller
The account is added to a privileged group, so it inherits that group's access across the whole domain.
Logged
4728 A member was added to a security-enabled global group
On dc-01, in the Security log
A member added to a security-enabled global group, with who added it.
What Defenders See
The Security log on dc-01 shows event 4728 naming the member added, the group and the account that added it.
Step 3 of 3: Account Changed
ws-042 Foothold to dc-01 Domain controller
An old account is re-enabled or its flags are changed, a quieter way to keep a way in without creating anything new.
Logged
4738 A user account was changed
On dc-01, in the Security log
A user account changed, with the User Account Control flags that changed.
What Defenders See
The Security log on dc-01 shows event 4738 with the User Account Control flags that changed on the account.
Needs First
What the attacker must already hold for this attack to be possible.
- Write Access to a Directory Object or Domain Admin RightsRights to create an account or change a group, from a delegated write up to Domain Admin.
Comes From
Gives the Attacker
What running it hands the attacker to use next.
- Access as Another AccountA standing way back in as a member of a privileged group, kept through a reset of other accounts.
What Defenders See
What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.
| Event and Log | Written On | Look For | Switch It On |
|---|---|---|---|
| 4720 A user account was created (opens in a new tab) Security log | Domain controllers for domain accounts, the computer itself for local ones | A domain account created that no joiner request explains, especially one named to blend in such as support or an svc- account. | Audit User Account Management |
| 4728 A member was added to a security-enabled global group (opens in a new tab) Security log | Domain controllers (domain groups only) | An account added to Domain Admins or another sensitive global group, read with who added it and whether a change request explains it. | Audit Security Group Management |
| 4732 A member was added to a security-enabled local group (opens in a new tab) Security log | Domain controllers for the domain's local groups, the computer itself for its own | A member added to a built-in local administrators group on a server or a domain controller, where a quiet foothold is easy to miss. | Audit Security Group Management |
| 4756 A member was added to a security-enabled universal group (opens in a new tab) Security log | Domain controllers (domain groups only) | A member added to a universal group that reaches across domains, such as Enterprise Admins, read with who added it. | Audit Security Group Management |
| 4738 A user account was changed (opens in a new tab) Security log | Domain controllers for domain accounts, the computer itself for local ones | A dormant account re-enabled, or its flags changed (preauth not required, password never expires), in the User Account Control field. | Audit User Account Management |
What It Looks Like
One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.
4728 A member was added to a security-enabled global group
In the Security log on dc-01,
A member added to Domain Admins on dc-01, soon after adm-alice's credentials were stolen.
The group the member was added to. Domain Admins controls the whole domain, so any addition here is worth running down.
As Windows writes it:
Group NameDomain AdminsThe account added, a domain backdoor. Read event 4720 for when it was created and whether any joiner request explains it.
As Windows writes it:
Member Account NameCN=svc-helpdesk,CN=Users,DC=corp,DC=exampleThe account that made the change. Her credentials were read from LSASS at 22:16, so match her Logon ID to event 4624 to see where this was done from.
As Windows writes it:
Subject Account Nameadm-alice
Defender for Identity Alerts
Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.
- Suspicious additions to sensitive groups (opens in a new tab)Profiles the normal group changes on each domain controller over four weeks, then alerts on an addition to a sensitive group that does not fit.
Blind Spots
Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.
- A group change is an ordinary admin action, so the event alone does not say it was wrong. Read who did it, from where, and whether a change request explains it.
- The events name the account that made the change, not the machine it came from. Match the subject's Logon ID to its event 4624 in the Security log to find where it signed in.
Look for It on a Machine
The Registry keys on an endpoint that hold a trace of this, each opening its own page.
Hunt It
The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.
Needs Defender for Identity sensors on every domain controller, which profile normal group changes and alert on an abnormal one. The alert is a lead, so confirm it against event 4728 and who made the change.
// Defender for Identity alerts for an abnormal addition to a sensitive groupAlertInfo| where Timestamp > ago( 30d)| where Title == "Suspicious additions to sensitive groups"| join kind= inner AlertEvidence on AlertId| summarize FirstSeen = min( Timestamp), Accounts = make_set( AccountName), Devices = make_set( DeviceName) by AlertId, Title| order by FirstSeen descHow to Prevent It
The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.
Least-privilege administration (opens in a new tab)
Keep Domain Admins and the other most powerful groups nearly empty, so any addition to them stands out at once.
Tiered administration (opens in a new tab)
Make account and group changes only from privileged access workstations, so a change from an everyday machine is itself a flag.
Honeytoken accounts (opens in a new tab)
Leave decoy accounts tagged in Defender for Identity, so any sign-in with one, or query for one, raises an alert.
Sources
- MITRE ATT&CK T1136.002: Create Account: Domain Account (opens in a new tab)
- MITRE ATT&CK T1098.007: Account Manipulation: Additional Local or Domain Groups (opens in a new tab)
- Microsoft Learn: Security event 4720, a user account was created (opens in a new tab)
- Microsoft Learn: Audit Security Group Management (events 4728, 4732 and 4756) (opens in a new tab)
- Microsoft Learn: Security event 4738, a user account was changed (opens in a new tab)
- Microsoft Learn: Defender for Identity classic alerts, persistence and privilege escalation (opens in a new tab)