Is Event ID 4724 always suspicious?

No — helpdesk password resets are normal business operations and generate hundreds of 4724 events in most organizations. The suspicious patterns are: reset of a domain admin account by a non-helpdesk account, reset of a service account outside a scheduled rotation window, reset where the Subject Account Name itself shows recent unusual activity, and reset immediately followed by a privileged group membership change (4728). The key question is always whether the reset corresponds to a legitimate helpdesk ticket.

How can I detect account takeover using Event ID 4724?

Look for this chain: (1) 4624 logon for an admin account from an unusual IP or workstation; (2) 4724 where that admin account (Subject) resets a high-value account (Target); (3) 4624 or 4728 showing the target account is now being used from an attacker-controlled location. The attacker compromises one admin, uses it to reset another admin's password, and then has two admin footholds. Alert on any admin-on-admin 4724 event where the Subject's own session cannot be verified as legitimate.

What happens when a service account password is reset without updating the service?

The service will fail to start or will throw authentication errors on the next restart, credential refresh, or scheduled task execution — depending on how the password is stored. Common symptoms: Event ID 7034 (service terminated unexpectedly), Event ID 7036 (service entered stopped state), Kerberos errors in the Application log, or scheduled task failures. If you see 4724 on a service account followed quickly by service-related failures in System or Application logs, the reset was either uncoordinated or malicious. Treat both as incidents requiring immediate investigation.

How is Event ID 4724 different from Event ID 4723?

Event 4724 is an admin-initiated reset where the Subject (resetter) and Target (account being reset) are different accounts, and the resetter must have the 'Reset Password' right in Active Directory. Event 4723 is a self-service change where any user can change their own password without elevated rights — Subject and Target are the same account. In practice, 4724 is the higher-priority event because it requires compromising an admin account first, making it a second-stage indicator.

Scan your Security and Sysmon logs·Detection guides

Event ID 4724Audit SuccessSecurity

Windows Event ID 4724 — Password Reset Attempted

Logged when an administrator resets another user's password. Unlike Event ID 4723 (self-service), this requires elevated privileges — only admins, helpdesk accounts with delegated rights, or accounts with specific AD permissions can generate this event.

Why It Matters

Admin-initiated password resets on sensitive accounts (other domain admins, service accounts, executives, finance accounts) without a corresponding helpdesk ticket are a critical signal — the resetting account may itself be compromised, and the reset may be the attacker locking out the legitimate owner of a high-value account. The chain to watch: compromised admin account → 4724 (reset another admin's password) → 4728 or 4732 (add controlled account to privileged group) establishes a new admin foothold before the legitimate account owner notices.

Key Fields

Target Account NameThe account whose password was reset — admin accounts, service accounts, and executive accounts are highest priority. A reset on these without a ticket is a critical alert.

Subject Account NameThe admin account that performed the reset — verify this is a known IT/helpdesk account with legitimate authority. An unexpected resetter is as important as an unexpected target.

Subject Logon IDLinks to the resetting account's 4624 session — correlate to check logon type and source IP. A Subject session that itself came from an unusual location indicates the admin account was compromised before performing this reset.

Workstation NameThe machine the reset was performed from — helpdesk resets should come from known IT workstations or the helpdesk management system, not from workstations belonging to regular users

Investigation Tips

1.Admin resets of other admin accounts are the highest-priority scenario — these require explicit authorization and should always correspond to a change ticket. No ticket = investigate immediately.
2.Trace the Subject Account Name's recent activity via the Subject Logon ID back to its 4624 session. If the resetting admin session originated from an unusual IP, used NTLM instead of Kerberos, or occurred outside business hours, the admin account was likely compromised before performing this reset.
3.Service account resets without coordinating with the consuming service cause immediate outages. Unexpected 4724 on a service account is both a security indicator and an operational risk — verify against your change management records before assuming it is benign.
4.Correlate the reset target with 4624 logons from that account immediately after — if the target account is used for logon minutes after a reset, and the logon source is unexpected, the reset transferred control of the account to an attacker.
5.Check for multiple resets in a short window by the same Subject Account — an attacker with a compromised admin account may systematically reset multiple privileged accounts to establish control before detection.

Seeing Event ID 4724 in your own logs? Upload an .evtx file — EventPeeker flags password reset attempted automatically, maps it to MITRE ATT&CK, and writes the triage report. No account, files auto-deleted.

Analyze my logs →

Related Event IDs

4723Self-service password change — does not require admin, Subject == Target

4738User account changed — broader attribute changes often accompany a reset

4728Added to privileged group — often follows a reset as the second step in account takeover

4624Successful logon — check for immediate logon with the reset account from a new source

Frequently Asked Questions

Is Event ID 4724 always suspicious?: No — helpdesk password resets are normal business operations and generate hundreds of 4724 events in most organizations. The suspicious patterns are: reset of a domain admin account by a non-helpdesk account, reset of a service account outside a scheduled rotation window, reset where the Subject Account Name itself shows recent unusual activity, and reset immediately followed by a privileged group membership change (4728). The key question is always whether the reset corresponds to a legitimate helpdesk ticket.
How can I detect account takeover using Event ID 4724?: Look for this chain: (1) 4624 logon for an admin account from an unusual IP or workstation; (2) 4724 where that admin account (Subject) resets a high-value account (Target); (3) 4624 or 4728 showing the target account is now being used from an attacker-controlled location. The attacker compromises one admin, uses it to reset another admin's password, and then has two admin footholds. Alert on any admin-on-admin 4724 event where the Subject's own session cannot be verified as legitimate.
What happens when a service account password is reset without updating the service?: The service will fail to start or will throw authentication errors on the next restart, credential refresh, or scheduled task execution — depending on how the password is stored. Common symptoms: Event ID 7034 (service terminated unexpectedly), Event ID 7036 (service entered stopped state), Kerberos errors in the Application log, or scheduled task failures. If you see 4724 on a service account followed quickly by service-related failures in System or Application logs, the reset was either uncoordinated or malicious. Treat both as incidents requiring immediate investigation.
How is Event ID 4724 different from Event ID 4723?: Event 4724 is an admin-initiated reset where the Subject (resetter) and Target (account being reset) are different accounts, and the resetter must have the 'Reset Password' right in Active Directory. Event 4723 is a self-service change where any user can change their own password without elevated rights — Subject and Target are the same account. In practice, 4724 is the higher-priority event because it requires compromising an admin account first, making it a second-stage indicator.

Go deeper: the full Account Persistence — Backdoor Accounts and Unauthorized Group Changes guide

Builds on this page with the attack chain, step-by-step investigation, immediate containment actions, KQL/Sigma detection queries, and an annotated example log.

Read the Account Persistence — Backdoor Accounts and Unauthorized Group Changes guide →

See Event ID 4724 in your logs

Upload a Windows Event Log (.evtx) file — EventPeeker automatically detects password reset attempted patterns, maps findings to MITRE ATT&CK, and generates an AI triage report.

Analyze EVTX Logs Free →

← All detection guides·Analyze EVTX Logs Free →