Log Dejargonizer

Windows Security Log · Event 4724

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

Someone reset another account's password without knowing the old one — an administrative reset. It is routine at a help desk and it is also how an attacker takes over an existing account, so the pairing of who reset whose password is the thing to read.

Also written as 4724Event ID 4724

What it means for you

On a personal computer

Someone with administrator rights changed an account's password without needing the old one. If you did not do this and it was not a family member with admin access, it means someone else had administrative control of the machine.

For an analyst

The distinction from 4723 matters: 4724 is a reset by someone else, 4723 is a user changing their own. A 4724 targeting a privileged or service account outside a change window is worth immediate attention, because it is account takeover and it is also disruptive enough to notice.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
An attempt was made to reset an account's password.

Subject:
  Security ID:    CORP\helpdesk01
  Account Name:   helpdesk01
  Account Domain: CORP
  Logon ID:       0x3E9A11

Target Account:
  Security ID:    CORP\jbrooks
  Account Name:   jbrooks
  Account Domain: CORP

The fields that decide it

Everything else in the log line is context.

TargetUserName
The account whose password was reset.
SubjectUserName
Who performed the reset. The pairing of this and the target is the whole event.
SubjectLogonId
The session that did it. Join to the 4624 for the source address.

Ordinary reasons this happens

Most of the time it is one of these.

  • A help desk resetting a password for a user who forgot theirs.
  • Routine rotation of service account passwords.
  • Self-service password reset tooling, which performs the reset with a service account.
  • A new account's password being set shortly after creation.
  • An administrator preparing an account before handing it over.

When it is not ordinary

Taking over an existing account rather than creating a new one.

What gives it awayA reset of a privileged or dormant account by someone who does not normally perform resets, followed by a sign-in as that account.

ATT&CK T1098

Locking a legitimate owner out during an intrusion.

What gives it awayResets of administrator or executive accounts outside working hours, with no matching ticket.

ATT&CK T1531

Service account takeover.

What gives it awayA reset of a service account outside a change window. Legitimate rotations are scheduled; opportunistic ones are not, and they usually break something visibly.

Help desk social engineering.

What gives it awayA reset performed shortly after an unusual inbound contact, for an account the requester cannot properly verify.

ATT&CK T1078

What to do next

  1. Read the subject and target pair. Does this person reset passwords as part of their job, and for this class of account?
  2. Check for a matching ticket or change record.
  3. Look for a 4624 for the target account shortly afterwards, and note where it came from.
  4. If the target is a service account, find out what broke — a legitimate rotation updates the dependent services too.
  5. Check whether the same subject reset several accounts in a short window.

Queries to run

kql 
SecurityEvent | where EventID == 4724 | project TimeGenerated, Computer, ResetAccount = TargetUserName, ResetBy = SubjectUserName | order by TimeGenerated desc
kql One person resetting many accounts in an hour. Normal for a bulk migration, not for anything else. 
SecurityEvent | where EventID == 4724 | summarize resets = count(), targets = dcount(TargetUserName) by SubjectUserName, bin(TimeGenerated, 1h) | where targets > 5

Common questions

What is the difference between Event 4724 and Event 4723?

4723 is a user changing their own password, which requires supplying the current one. 4724 is an administrator resetting someone else's without knowing it. That is why 4724 is the more security-relevant of the two — it is a takeover of access rather than a routine change.

Does Event 4724 mean my account was hacked?

Not necessarily. It is the ordinary result of a help desk resetting a forgotten password, or of self-service reset tooling. It is a concern when nobody requested the reset, when the account is privileged, or when a sign-in from an unfamiliar location follows shortly after.

Why does Event 4724 appear right after a new account is created?

Because creating an account and setting its password are separate operations in Windows. A 4720 followed by a 4724 is simply an account being finished so it can actually be used.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026