Windows Security Log · Event 4624

Event 4624: An account was successfully logged on

Someone or something signed in successfully. This is the most common event in the Windows Security log and almost all of it is routine. What matters is the logon type, the source address, and whether the account should have been signing in there at all.

Also written as 4624Event ID 4624Audit Success 4624

How oftenFires constantly
Vendor calls itAudit Success
LogSecurity
SourceMicrosoft-Windows-Security-Auditing

What it means for you

On a personal computer

This records every successful sign-in to your PC, including the one you just did. Seeing thousands of them is normal — Windows logs its own background sign-ins too. It is only worth a look if one appears at a time nobody was using the machine.

For an analyst

Never alert on 4624 alone. The valuable shapes are LogonType 10 from outside your management ranges, LogonType 3 to a workstation from another workstation, service accounts appearing interactively, and any 4624 immediately following a run of 4625s from the same source.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample

An account was successfully logged on.

Subject:
  Security ID:    NULL SID
  Account Name:   -
  Logon ID:       0x0

Logon Information:
  Logon Type:     10
  Restricted Admin Mode: -
  Virtual Account: No
  Elevated Token:  Yes

New Logon:
  Security ID:    CORP\jbrooks
  Account Name:   jbrooks
  Account Domain: CORP
  Logon ID:       0x3E9A11

Process Information:
  Process Name:   C:\Windows\System32\svchost.exe

Network Information:
  Workstation Name: -
  Source Network Address: 198.51.100.77
  Source Port: 51993

Detailed Authentication Information:
  Logon Process:  User32
  Authentication Package: Negotiate

The fields that decide it

Everything else in the log line is context.

TargetUserName: The account that signed in. Names ending in $ are computer accounts, not people.
LogonType: How the sign-in happened. This single field decides whether the event is boring or urgent.
IpAddress: Where the sign-in came from. A dash or 127.0.0.1 means it originated on the machine itself.
LogonProcessName: The component that handled the sign-in.
AuthenticationPackageName: Which authentication protocol was used.
ElevatedToken: Whether the session holds full administrative rights.
TargetLogonId: A session identifier unique to this sign-in. Use it to join the sign-in to the 4634 logoff and to everything the session did in between.
WorkstationName: The name the connecting machine claimed. Attacker tooling frequently leaves this blank or fills it with something random.

Ordinary reasons this happens

Most of the time it is one of these.

You, or anyone else, signing in to the machine normally.
A domain-joined computer authenticating itself — these appear as an account name ending in $ and account for a great deal of the volume.
Scheduled tasks and Windows services starting, which produce LogonType 4 and 5 continuously.
File share and printer access from other machines on the network, logged as LogonType 3.
Backup agents, monitoring tools, and management software connecting on a fixed schedule.
Unlocking the screen after a break, recorded as LogonType 7.

When it is not ordinary

An attacker signing in with a password they stole or guessed.

What gives it awayA 4624 from a source address that produced a run of 4625 failures shortly before. That sequence is the whole question.

ATT&CK T1078

Remote Desktop access from the internet.

What gives it awayLogonType 10 with a public source address, particularly outside working hours.

ATT&CK T1021.001

Lateral movement between machines using valid credentials.

What gives it awayLogonType 3 arriving at a workstation from another workstation. Normal networks push administration from servers, not sideways between desktops.

ATT&CK T1021.002

Pass-the-hash using a stolen NTLM hash.

What gives it awayLogonType 3 with AuthenticationPackageName NTLM and LogonProcessName NtLmSsp, for an account that normally authenticates with Kerberos.

ATT&CK T1550.002

A stolen token reused to run a process as another user.

What gives it awayLogonType 9 with LogonProcessName seclogo. Legitimate on developer machines, rare everywhere else.

ATT&CK T1134.001

A dormant or service account being used interactively.

What gives it awayA service account with LogonType 2 or 10. Service accounts are not supposed to sit at a desk.

ATT&CK T1078.003

What to do next

Read LogonType first. It narrows the question faster than any other field.
Check IpAddress against what you expect for that account and that machine.
Look backwards for 4625 failures from the same source in the preceding hour. A success after a run of failures is the sequence that matters.
Check ElevatedToken. An administrative session for an account that should not hold admin rights is a finding on its own.
Take TargetLogonId and pull every event carrying the same value to reconstruct what the session actually did.
For LogonType 10, confirm whether Remote Desktop should be reachable from that source at all before investigating the account.

Queries to run

kql Remote Desktop sign-ins from public addresses. On most networks this should return nothing.

SecurityEvent | where EventID == 4624 and LogonType == 10 | where not(ipv4_is_private(IpAddress)) | project TimeGenerated, Computer, TargetUserName, IpAddress, WorkstationName | order by TimeGenerated desc

kql A success preceded by many failures from the same source and account — the shape of a guessed password.

let fails = SecurityEvent | where EventID == 4625 | summarize failures = count() by IpAddress, TargetUserName, bin(TimeGenerated, 1h);
SecurityEvent | where EventID == 4624 | join kind=inner fails on IpAddress, TargetUserName | where failures > 10 | project TimeGenerated, Computer, TargetUserName, IpAddress, failures

powershell Local triage on one machine when there is no central logging.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-1)} | Where-Object { $_.Properties[8].Value -in 10,3 } | Select-Object TimeCreated, @{n='User';e={$_.Properties[5].Value}}, @{n='Type';e={$_.Properties[8].Value}}, @{n='Source';e={$_.Properties[18].Value}}

splunk One account authenticating to an unusual number of hosts — the footprint of credential reuse.

index=wineventlog EventCode=4624 Logon_Type=3 | stats dc(dest) as hosts values(dest) as targets by Account_Name | where hosts > 10

Common questions

Why does Event 4624 appear thousands of times a day?

Because Windows logs every successful authentication, not just the ones a person performs. Services starting, scheduled tasks running, the computer account authenticating to the domain, and other machines reaching your file shares all produce 4624. High volume is the normal state; the event is useful for reconstructing what happened, not for alerting on.

What is the most important field in Event 4624?

Logon Type. It separates someone sitting at the keyboard (type 2) from a network connection (type 3) from Remote Desktop (type 10), and that distinction changes what the event means more than any other field. Read it before the account name.

Does Event 4624 mean someone logged into my account?

It means an authentication succeeded for that account, but most 4624 entries are not a person. Check the Logon Type: types 4 and 5 are scheduled tasks and services, and an account name ending in $ is a computer, not a user. A type 2, 7, or 10 entry at a time you were not using the machine is the one worth investigating.

What is Logon Type 3 in Event 4624?

A network sign-in. Something connected to the machine over the network and authenticated — accessing a shared folder, a shared printer, or performing remote administration. It is the highest-volume logon type on most machines and normally means nothing on its own.

How do I find what someone did after signing in?

Take the Logon ID from the New Logon section of the 4624 and search the Security log for other events carrying the same value. Windows stamps that identifier on the events a session generates, so it stitches the sign-in to the actions that followed.

Mentioned by

Vendor documentation

Last reviewed 28 August 2026