Failed login events can reveal a mistyped password, an outdated service credential, a disconnected mapped drive, or a real attack. Windows Event Viewer provides the evidence, but the event ID alone is not enough. You also need the timestamp, account, source, logon type, failure status, and nearby successful events.
Enable and Confirm the Audit Policy
On current Windows systems, account logon and logon auditing are normally available through Advanced Audit Policy. In a managed domain, use Group Policy so settings remain consistent. For a standalone system, open Local Security Policy and review Advanced Audit Policy Configuration > Logon/Logoff.
Audit failures for Logon and, where relevant, Credential Validation. Audit successes on important systems so you can correlate a successful login with preceding failures. Avoid enabling every audit category without a retention plan; excessive noise shortens the useful history.
Find Event ID 4625
- Open Event Viewer as an administrator.
- Go to Windows Logs > Security.
- Select Filter Current Log.
- Enter
4625in the event ID field and choose a relevant time range. - Open an event and review both the General and Details tabs.
Event 4625 means an account failed to log on to the computer that recorded it. A domain controller may instead record supporting credential-validation events. Confirm which machine produced the log before attributing the source.
Interpret the Important Fields
- Account Name and Domain: the identity that was attempted. Machine accounts end with a dollar sign.
- Logon Type: indicates the access method, such as interactive, network, service, or Remote Desktop.
- Source Network Address: useful for remote attempts, but may be absent for local processes.
- Workstation Name: can identify the originating device in Windows networks.
- Status and Sub Status: hexadecimal codes that distinguish an unknown user, bad password, disabled account, restriction, or other failure.
- Process Information: may show which local component initiated the attempt.
Do not publish full event details without redacting account names, internal addresses, and identifiers.
Use Logon Type to Narrow the Cause
Logon type 2 is an interactive local sign-in. Type 3 is a network logon and often appears for file shares, remote administration, or services accessing another system. Type 5 is a service startup. Type 10 is RemoteInteractive and commonly indicates RDP. Scheduled tasks may produce batch logons.
A repeated type 5 failure after a password change often points to a service still using the old credential. Repeated type 3 failures from one workstation may be a saved credential, mapped drive, script, or malicious lateral movement. Type 10 failures from an unexpected address deserve immediate investigation, especially if RDP should not be internet-accessible.
Correlate With Related Events
Look for successful logon event 4624 near the same time, account lockout event 4740 in a domain, explicit credential use event 4648, and process creation events where enabled. For RDP, review Microsoft-Windows-TerminalServices-RemoteConnectionManager and LocalSessionManager operational logs.
A successful event after many failures can mean the user finally typed the correct password, but it can also mean an attacker succeeded. Compare source, logon type, device, time, and subsequent activity.
Create a Focused Custom View
Use Create Custom View for a reusable filter covering the Security log and relevant IDs. On one computer, PowerShell provides a quick summary:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
Select-Object TimeCreated, Id, MachineName, MessageFor many systems, forward events to a protected collector or SIEM. Centralization preserves evidence if an endpoint is compromised and enables correlation across hosts.
Distinguish Noise From Suspicious Patterns
A handful of failures from a known user during work hours is different from hundreds of usernames from one source, one username from many countries, or regular attempts against disabled administrator names. Build alerts around rate, novelty, sensitive accounts, and a subsequent success rather than treating every failure as an incident.
If RDP is exposed, remove that exposure and use the architecture in our secure remote-access guide. Hardening steps for the endpoint are covered in our Windows 11 remote-work baseline.
Respond Without Destroying Evidence
- Record the time range, system, account, source, logon type, and event record IDs.
- Check whether the source is a known device, VPN address, service, or scanner.
- Contain a credible threat by blocking the narrow source or disabling the affected account.
- Reset credentials through a trusted channel and revoke active remote-access credentials where needed.
- Review successful logons and post-login activity.
- Fix the root cause, such as a public RDP rule or stale service password.
Export relevant logs before they roll over. Do not clear the Security log as a troubleshooting step.
Frequently Asked Questions
Why is the source IP blank?
The attempt may be local, initiated by a process, or recorded at a layer that did not supply a network address. Use logon type, process, workstation, and related logs.
Does event 4625 prove an attack?
No. It proves a failed logon on that computer. Context and pattern determine whether the cause is user error, stale automation, or hostile activity.
How long should Security logs be retained?
Long enough to investigate expected detection delays and meet organizational requirements. Size the log and central retention from actual event volume rather than a universal number.
Final Review
A useful failed-login investigation connects the event to an access method, source, identity, and outcome. Preserve timestamps, correlate successes, fix exposed services or stale credentials, and tune monitoring around meaningful patterns. Event Viewer supplies facts; disciplined context turns them into a decision.
