Event ID 4738: A User Account Was Changed — Reading Changed Attributes

What it records

Event 4738 is Windows reporting that a user object changed. Microsoft’s description is short: “This event generates every time user object is changed.” It is written on all three tiers — “This event generates on domain controllers, member servers, and workstations” — so a domain account change lands on the DC that processed it and a local account change lands on that machine. One event covers one change: “For each change, a separate 4738 event will be generated.”

The event has three parts. Subject (Security ID, Account Name, Account Domain, Logon ID) is the account that requested the “change user account” operation. Target Account (Security ID, Account Name, Account Domain) is the account that was changed. Everything after that is Changed Attributes: SAM Account Name, Display Name, User Principal Name, Home Directory, Home Drive, Script Path, Profile Path, User Workstations, Password Last Set, Account Expires, Primary Group ID, AllowedToDelegateTo, Old UAC Value, New UAC Value, User Account Control, User Parameters, SID History and Logon Hours. An attribute that was not changed appears as a dash, so on a domain controller the populated attributes are the change.

Two caveats shape triage. First, a 4738 can arrive with every attribute showing a dash; Microsoft says this usually happens when the change was to an attribute the event does not list, and gives a DACL change as the example — the event confirms something changed and nothing more. Second, “Some changes do not invoke a 4738 event”, so the audit trail is not exhaustive.

The flag fields need care. User Account Control “shows the list of changes in userAccountControl attribute. You will see a line of text for each change.” In the raw XML those lines are message identifiers — Microsoft’s sample event shows %%2050 %%2089 — which Event Viewer renders as text. Old UAC Value and New UAC Value are the SAM implementation of account flags, whose definition Microsoft notes differs from userAccountControl in AD.

When it matters

What the event shows	Reading
User Account Control lines around enable/disable	The account’s state was flipped; pair with 4722 or 4725 and with 0xC0000072 failures before or after
AllowedToDelegateTo not a dash	The services list on the Delegation tab changed — Microsoft’s own recommendation is to monitor exactly this condition
AllowedToDelegateTo marked <value not set>	Microsoft: “it means the list was cleared” on an account that previously had a services list
SID History not a dash	”This field will always be set to - unless the account was migrated from another domain” — unexpected outside a migration
Primary Group ID not 513	Microsoft: “Typically, the Primary Group value is 513 for domain and local users. Other values should be monitored.”
User Workstations changed	Where the account may log on from was redefined; related failures carry 0xC0000070
Logon Hours changed	Time restrictions were rewritten; related failures carry 0xC000006E
Password Last Set changed	Microsoft gives a manual account password reset as a cause — correlate with 4723/4724
Account Expires changed	A leaver or expired account was given life again

Microsoft notes that “Some organizations monitor every 4738 event”, and otherwise recommends watching the event where Target Account\Account Name is a critical account — domain administrators and service accounts — and monitoring all changes to Display Name, User Principal Name, Home Directory, Home Drive, Script Path, Profile Path, User Workstations, Password Last Set, Account Expires, Primary Group ID and Logon Hours for those accounts.

How to investigate

Start with flag changes, which carry the most security weight:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4738
| parse EventData with * 'UserAccountControl">' UacChanges '<' *
| parse EventData with * 'OldUacValue">' OldUacValue '<' *
| parse EventData with * 'NewUacValue">' NewUacValue '<' *
| where UacChanges != "-"
| project TimeGenerated, Computer, TargetUserName, TargetDomainName,
          SubjectUserName, SubjectDomainName, SubjectLogonId,
          UacChanges, OldUacValue, NewUacValue
| order by TimeGenerated desc

Then the two attributes that should almost never move — the delegation list and SID history:

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4738
| parse EventData with * 'AllowedToDelegateTo">' AllowedToDelegateTo '<' *
| parse EventData with * 'SidHistory">' SidHistory '<' *
| parse EventData with * 'PrimaryGroupId">' PrimaryGroupId '<' *
| where AllowedToDelegateTo != "-" or SidHistory != "-"
      or (PrimaryGroupId != "-" and PrimaryGroupId != "513")
| project TimeGenerated, Computer, TargetUserName, SubjectUserName,
          AllowedToDelegateTo, SidHistory, PrimaryGroupId
| order by TimeGenerated desc

Finally, look at the operator rather than the object — one subject rewriting many accounts in a short window is the shape of scripted manipulation rather than help-desk work:

SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID in (4738, 4720, 4722, 4724, 4725, 4732)
| summarize Changes = count(), Targets = dcount(TargetUserName),
            TargetList = make_set(TargetUserName, 20), Events = make_set(EventID, 10)
    by SubjectUserName, SubjectDomainName, SubjectLogonId, Computer
| order by Targets desc, Changes desc

When a change looks wrong, pivot on SubjectLogonId: the matching 4624 tells you how that session was created, from which address and by which logon type, and whether the administrator’s own credentials were used from a machine they never use. Work outward to the account-management events around it — 4720 creation, 4722/4725 enable and disable, 4723/4724 password change and reset, 4732 group additions, 4740 and 4767 lockout and unlock — and to any lockouts carrying 0xC0000234. Without a SIEM, export the Security log as XML from Event Viewer and load it into the free browser log analyzer to read the EventData of each 4738 directly.