Event ID 4738: A user account was changed

Event 4738 fires every time an existing user account's attributes change, in the Audit User Account Management subcategory, and it is intentionally broad: password resets, account-control flag changes, delegation-rights grants, profile-path edits, and dozens of other attribute writes all collapse into the same event ID with the same shape. That breadth is the event's defining characteristic and its main triage challenge: "an account changed" tells you almost nothing until you look at exactly which fields moved.

SubjectUserSid, SubjectUserName, and SubjectLogonId describe who made the change, the actor, correlating back to that actor's own 4624 logon. TargetUserName and TargetSid describe the account that was modified. As with account creation, conflating Subject and Target here is the most common analyst error: a help-desk technician resetting a forgotten-password flag produces the same event shape as an attacker with a stolen admin credential quietly granting themselves delegation rights, and the only field-level difference is what actually changed and who did it.

The two fields that matter most for detection are OldUacValue and NewUacValue, a before-and-after pair of the account-control bitmask. Neither value on its own tells you much; the diff between them tells you exactly which control bit flipped. A flag that flips from password required to password not required, or from password expires to password never expires, is a durability change to how that account can be authenticated against in the future, and those specific flips are worth alerting on regardless of who made them, because a legitimate admin rarely has a reason to disable expiry on a standard user account.

AllowedToDelegateTo is the field most incumbent references skip entirely, and it is one of the highest-value fields on this event. A non-empty value here means the account is now permitted to delegate to the listed service on behalf of other users, the mechanism behind constrained Kerberos delegation. Going from empty to populated is not a routine account edit; it is a privilege grant that hands the account impersonation rights it did not have before, and it is a documented step in several real-world Kerberos-abuse chains, MITRE T1098 Account Manipulation, precisely because delegation rights are easy to grant quietly and easy to overlook in a routine account-attribute audit.

PasswordLastSet appears in the event specifically when the change touched the password, which lets you separate a password-reset 4738 from an attribute-only 4738 without needing a second event. Other attributes commonly seen changing, home directory, profile path, logon script, workstation restrictions, are lower signal individually but worth tracking in aggregate: a batch of unrelated attribute changes on one account in a short window is a pattern worth a second look even when no single change looks alarming.

4738 relates closely to two sibling events: 4720, account created, which fires once at creation and never again for that account, and 4725/4726, disabled and deleted, which are themselves special cases of an account-state change that get their own dedicated event IDs rather than folding into 4738. If you are building a full account-lifecycle view, all four events need to be correlated by TargetSid to reconstruct the account's history in order.

The overwhelming majority of 4738 volume in any organization is legitimate account administration: help-desk password resets, HR-driven profile updates, automated provisioning tools syncing attributes from an HR system or identity provider, and routine account-lifecycle management. The baseline pattern looks like a small, stable set of Subject accounts, help-desk staff, provisioning service accounts, a handful of IT admins, making changes during business hours, each change touching one or two attributes at a time.

The pattern worth escalating starts with the specific UAC bits involved rather than the mere fact that a UAC value changed. Password-never-expires and password-not-required flipping to enabled on any account outside a documented list of legitimate exceptions, some service accounts do need this, is a durable persistence mechanism: it removes a rotation cycle an attacker would otherwise have to survive. The same flip on a human user account, especially a privileged one, is close to always worth investigating immediately.

AllowedToDelegateTo going from empty to populated is the single highest-priority 4738 pattern on this page. Legitimate constrained-delegation grants are rare, deliberate, and usually tied to a specific application deployment a change-management ticket would document. An unexplained delegation grant, particularly one pointing at a service like cifs or ldap on a domain controller, is a credential-relay or lateral-movement setup step and should be treated as a high-confidence indicator pending explanation, not a routine attribute edit.

Subject identity is the other major triage axis. A change made by an account that has never touched account management before, or by a service account whose normal job has nothing to do with user administration, is inherently more suspicious than the same change made by a known help-desk identity, independent of which attribute changed. Pair this against an allowlist of accounts with legitimate account-management responsibilities; any 4738 from outside that list is an anomaly by construction and worth a look regardless of the specific field touched.

Timing compounds both signals. A privilege-relevant attribute change, a delegation grant, an expiry-flag flip, made within minutes of the acting account's own suspicious logon, an unfamiliar source IP, an off-hours timestamp, or immediately preceding a burst of other account-management activity on the same or a different Target, moves the finding from worth a look to escalate now. A single off-pattern field in isolation is common operational noise; a privilege-relevant flag change stacked with an unusual Subject and unusual timing is the combination that should never wait for a scheduled review.