Event ID 4723: An attempt was made to change an account's password

Event 4723 records a self-service password change: the account holder supplies their current password to set a new one, which is the field-level fact that separates this event entirely from an administrative reset, 4724. SubjectUserSid and TargetSid are the same value here, the account changing its own password, whereas 4724's Subject and Target are, in the ordinary case, two different identities. That single structural difference is the whole distinction between these two events, and it is worth checking explicitly rather than assuming from context, since both events describe a password changed.

SubjectUserSid, SubjectUserName, and SubjectLogonId identify the account, and importantly the specific logon session, under which the change was made. TargetUserName, TargetSid, and TargetDomainName repeat the same account's identity in the Target fields, confirming the self-service nature of the change. SubjectLogonId ties the change back to a specific 4624, which is the pivot point for everything interesting this event can tell you: what kind of session was the user in when they changed their password, and where did that session originate.

The event carries a success or failure distinction, commonly rendered as an F or S suffix depending on how your SIEM parses the audit outcome. A successful change means the old password was verified and the new one accepted by whatever complexity and history policy applies. A failed attempt, Audit Failure, means the change was rejected, most commonly because the supplied current password did not match, though a new password failing a complexity or history check produces the same failure outcome from a different cause.

The routine case is exactly what it sounds like: users changing their password on a normal expiry cycle, or proactively after using it somewhere they later regret, or because a help-desk instructed them to do so following an unrelated support interaction. None of that needs special attention. What makes 4723 worth building detection around is timing relative to two other things: the session it happened in, and the pattern of failures immediately preceding a success.

A self-service password change made within minutes of an unfamiliar or otherwise suspicious logon, particularly a RemoteInteractive, RDP, session from a source or at a time the account does not normally use, is a recognizable post-compromise move: an attacker who has just gained access to an account changes the password specifically to lock the legitimate owner out and remove any dependency on a credential that could be independently rotated or revoked by the victim once they notice something is wrong. This is a persistence action, not merely a logon, and it should be triaged with the same urgency as any other confirmed account-takeover indicator.

Repeated Audit Failure 4723 events from one account in quick succession, followed by an eventual success, is the credential-stuffing tell for this event: it suggests the actor is testing a stolen or guessed current password across multiple attempts before finding one that works, at which point they immediately lock in a new password of their own choosing.

The vast majority of 4723 activity reflects exactly what the event describes: users managing their own credentials through entirely normal channels, on their own schedule, from their own usual devices and locations. No correlation is needed to dismiss the baseline case, and any detection strategy for this event should be built entirely around the two specific patterns that deviate from it, not around the event's raw occurrence.

The session-correlation check, a 4723 following a suspicious 4624 within a short window, needs a working definition of suspicious tuned to your environment: an unfamiliar source IP or geography, a RemoteInteractive logon type on an account that normally only logs in interactively at a workstation, or any logon type flagged by other detections running independently. The password change itself is the confirming action, not the initial signal; treat the underlying suspicious logon as the primary alert and the subsequent 4723 as an escalation that should move the response from investigate to contain now, since the attacker is actively working to entrench their access at that moment.

Repeated failures preceding a success is a pattern best measured per account over a short rolling window rather than as a fixed lifetime count, since a user who genuinely forgets a recently changed password might generate two or three failures before getting it right, indistinguishable in isolation from early-stage credential testing. The distinguishing factor in practice is usually the number of distinct failure attempts and, where available, whether the session's other characteristics, source IP, logon type, time of day, match the account's established baseline; failures from a familiar device followed by a success is far more likely to be user error than failures from an unfamiliar source.

A volume spike in self-service password changes across many accounts in a short window has two plausible explanations that require different responses: a policy-driven expiry wave, many accounts hitting their rotation deadline simultaneously, which correlates cleanly against your password-policy configuration and should recur on a predictable cycle, or an organization-wide reactive response to a suspected breach, where security teams instruct users to change passwords proactively. Distinguish between the two using the correlation against your policy's expiry cadence; a spike that does not line up with any expected expiry wave deserves its own investigation into what prompted it.

False positives concentrate around legitimate self-service password-manager integrations and identity-provider synchronization tools that can generate 4723 events as a side effect of credential rotation policies, particularly in hybrid identity environments. Confirm any automation account or synchronization service that regularly triggers 4723-shaped events on behalf of users, and exclude it explicitly rather than let it dilute the signal from the two patterns that actually matter.