Event ID 4724: An attempt was made to reset an account's password

Event 4724 records an administrative password reset: one account, the Subject, sets a new password for a different account, the Target, without ever needing to know or supply the old one. That is the defining mechanic of the event and the reason it exists as a separate ID from 4723, self-service password change: resetting rights bypass the normal prove-you-know-the-current-secret requirement entirely, which makes them powerful for legitimate help-desk work and equally powerful for an attacker who has already compromised an account holding that permission.

SubjectUserSid, SubjectUserName, and SubjectLogonId identify the account that performed the reset, correlating back to that account's own 4624 logon session. TargetUserName, TargetSid, and TargetDomainName identify the account whose password changed. In the ordinary case these are two different, unrelated identities: a help-desk technician resetting a locked-out employee's password. When Subject and Target end up being the same account, something unusual is happening, since a self-directed administrative reset through this path is rare; the normal self-service flow generates a 4723, not a 4724.

The permission required to trigger this event, Reset Password, is delegable in Active Directory independent of full domain-admin rights, which is exactly why help-desk staff can be granted it without also handing them broader administrative control. That same delegability is what makes 4724 worth watching closely: an attacker who compromises a single help-desk credential with Reset Password delegated over a specific organizational unit gains a very targeted but very real capability, the ability to lock any account in that OU out of its own password and set a new one only the attacker knows.

The event does not carry the new password value, by design, but it does carry everything needed to reconstruct who reset what and when. Two shapes deserve dedicated attention beyond a single reset in isolation. First, a reset targeting a privileged account, a domain admin, a service account, a break-glass identity, outside any documented change-management window is a red flag regardless of who performed it, because a compromised help-desk credential resetting a high-value target's password is a direct account-takeover step, not routine support work. Second, one Subject account resetting many different Target accounts' passwords in a short window is the signature of either a scripted bulk operation, which should be traceable to a known automation account and a known reason, or an attacker locking out a broad set of users, a pattern that has preceded both credential-harvesting campaigns and ransomware-adjacent disruption, where mass lockouts serve as either cover for other activity or as direct impact.

4724 sits next to 4723 as the two halves of a password changed in Windows auditing, distinguished entirely by whether Subject and Target match. It is worth pairing both events in any dashboard tracking credential changes across the environment, since an attacker with help-desk-level access could reasonably use either path depending on which one draws less attention in a given environment's existing alerting.

The baseline for 4724 in most organizations is narrow and predictable: a small, known set of help-desk and IT-admin accounts performing resets during business hours, each reset traceable to a ticket in a service-management system. That narrowness is what makes this event unusually easy to baseline compared to noisier account-management events; unlike group-membership changes or attribute edits, legitimate reset volume rarely comes from more than a handful of identities.

A reset from any Subject account outside that known set is the first and strongest signal. This includes service accounts that have no documented reason to hold reset rights, accounts belonging to roles with no help-desk responsibility, and any Subject making its first-ever appearance in your 4724 history. None of these should require sophisticated correlation to catch: a static allowlist of accounts with legitimate delegated reset rights, checked against every 4724's Subject, catches the majority of real incidents on its own.

Target sensitivity is the second axis. A reset against a privileged account, domain admin, enterprise admin, a service account tied to a critical system, or a break-glass identity, deserves escalation even from a known-good Subject if it falls outside a documented change window, since privileged-account resets are exactly the kind of action that should always have a paper trail, and their absence is itself informative.

Volume and breadth catch the mass-reset pattern: a legitimate bulk operation, a domain-wide policy-driven reset, an HR-driven contractor-account cleanup, is traceable to a known automation identity and typically announced ahead of time. An unannounced burst of resets against many distinct Target accounts from one Subject, especially one that has not performed bulk resets before, should be treated as a likely account-takeover or disruption event until proven otherwise, since it removes the affected users' access to their own accounts in a way that is difficult to reverse quickly at scale.

The rare case of Subject equaling Target on a 4724 deserves its own look rather than being dismissed as a data-quality quirk: some administrative tools and support workflows do reset an account's own password through the administrative path rather than the self-service one, but it is uncommon enough that a first occurrence for a given account is worth a quick check against whatever tooling might explain it. False positives generally come from legitimate but under-documented automation: HR system integrations, contractor-lifecycle tools, and identity-governance platforms that perform resets as part of routine account provisioning. The fix is documenting and allowlisting those Subject accounts explicitly rather than tuning around them ad hoc, since an undocumented automation account is itself an audit gap worth closing.