What does a Windows Security 4624 record with logon type 3 actually prove?
answer
- the record is about acceptance, not presence
- one field carries most of the meaning
- 2 at the keyboard, 3 over the wire
- 10 is RDP, 9 is runas /netonly
basics
~10 sIt proves a credential was accepted for that account on that machine, and nothing about who supplied it. Logon type 3 adds that the logon came over the network rather than at the keyboard.
solid answer
~50 sEvent 4624 means an account was successfully logged on, written by the machine that accepted the logon. It asserts that some credential or ticket satisfied authentication for the named account. It does not assert that a human was present, that the account's owner did it, or that the activity was authorised. The Logon Type field carries the meaning: 2 is interactive at the console, 3 is a network logon such as an SMB share or a remote management call with no interactive desktop, 10 is RemoteInteractive (RDP), 9 is NewCredentials (`runas /netonly`, where the process keeps its local identity but presents different credentials outbound). I would then read the New Logon account name, the Logon Process and Authentication Package (NTLM versus Kerberos), the Workstation Name and Source Network Address, and the Logon ID that links to the later 4634 or 4647 logoff.
code
text · 9 linesEvent ID: 4624 (An account was successfully logged on)
Logon Type: 3
New Logon / Account: CORP\svc_backup
Logon ID: 0x8f2a41
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: WKSTN-4471
Source Network Address: 10.14.6.88
...go deeper
Be ready to state what 4624 does and does not prove, and to name logon types 2, 3 and 10 without hesitating. This is used as a screening question, so a crisp answer matters more than breadth.
Explain how logon type, authentication package, source address and Logon ID together change the reading, and why type 9 is rare enough to be worth baselining.
Show how you find signal in a file server's tens of thousands of daily type-3 events: which account, from where, to what, at what hour, judged against what is normal for that account.
Own the consequence that logon telemetry answers acceptance and nothing else. Decide which corroborating sources the estate must collect so questions about authorisation can be answered at all, and be candid with stakeholders when only the logon record exists.
## What the record is Windows Security event **4624 — "An account was successfully logged on"** is written by the machine that *accepted* the logon: the workstation, the file server, the domain controller. It is the log line for an authentication decision that came out "yes". There is no central authority writing it, which is why an estate-wide answer requires collecting it from every host you care about. ## What it proves, precisely It proves that **a credential was accepted for the named account** — a password, a challenge response derived from a hash, a Kerberos ticket, a certificate. That is the whole claim. It does **not** prove: - that a human was at the device; - that the account's legitimate owner did it; - that the logon was authorised in any policy sense — authentication is not authorisation; - that anything happened afterwards. A logon is a door opening, not a description of the room. Getting this direction right is the point of the question. Candidates who say "4624 shows the user logged in" have quietly substituted a person for a credential, and every later inference inherits the error. ## The field that carries the meaning: Logon Type | Type | Meaning | |---|---| | 2 | Interactive — at the console, keyboard present | | 3 | Network — SMB, remote management, authenticated RPC; no interactive desktop | | 4 | Batch — scheduled task | | 5 | Service — a service starting under the account | | 7 | Unlock — workstation unlocked | | 8 | NetworkCleartext — network logon where the password reached the host in a recoverable form | | 9 | NewCredentials — `runas /netonly`: local token kept, different credentials presented for outbound network access | | 10 | RemoteInteractive — RDP / Terminal Services | | 11 | CachedInteractive — cached domain credentials used because no domain controller was reachable | Type 3 is the workhorse and by far the most common: every file-share access, every remote WMI call, every authenticated service connection produces one. Type 10 is the one people casually call "remote login", and confusing it with type 3 is the most common junior error on this record. Type 9 deserves its own note because it is rare and informative. `runas /netonly` lets a process keep the local user's identity while presenting a *different* set of credentials to network resources — exactly the shape of someone using credentials they have obtained without wanting an interactive session under them. It has legitimate administrative uses, so it is a baselining candidate, not an alert on sight. ## The other fields that change the reading - **New Logon: Account Name / Account Domain / Logon ID** — who was logged on, and the handle that ties this session to later events on the same host. - **Logon Process / Authentication Package** — `NtLmSsp` with `NTLM` versus `Kerberos`. In a domain that mostly speaks Kerberos, an NTLM logon to a member server can itself be worth a question. - **Workstation Name** — supplied by the client, so it is attacker-influenced; treat it as a hint, never as identification. - **Source Network Address / Source Port** — present for network logons; often empty for local ones. - **Elevated Token / Impersonation Level** — whether the session carries administrative privilege. ## Volume and base rates A busy file server writes tens of thousands of type-3 events a day. Volume alone is never signal here. The useful questions are: *which* account, *from* where, *to* what, *at* what hour, and whether that combination is normal for that account. A service account authenticating type 3 to the backup server all night is background; the same account authenticating type 3 to fifty workstations in two minutes is not. ## Correlating to the end of the session **4634** (an account was logged off) and **4647** (user-initiated logoff) carry the same **Logon ID**, which is how you get session duration on a host. The Logon ID is unique per boot on that machine, not globally — correlate it within a host, never across the estate. ## What this source cannot give you 4624 never says what the session *did*. For that you need the host's process-creation records, file or share auditing, or the service's own logs. And where audit policy was never configured or the Security log has already rolled, the **absence** of a 4624 is not evidence that no logon occurred — it is evidence that you were not looking.
- The same account shows 4624 type 3 on fifty machines within two minutes. What does that pattern add?It shows a fan-out of network logons from one credential. The record cannot say whether that is a vulnerability scanner, a backup agent, a management agent, or lateral movement. Check whether the source address is a single host, whether the account is a service account whose job explains it, and whether type-3 logons to workstations are normal for it at all.
- Why is a 4624 with logon type 9 worth a second look?Type 9 is NewCredentials, produced by `runas /netonly`: the process keeps the local user's token but presents different credentials for network access. That is how someone uses credentials they have acquired without opening an interactive session under them. Administrative tooling does it legitimately, so baseline which accounts and hosts do it before treating it as a finding.
- What ties a 4624 to the end of that session?The Logon ID. Events 4634 (logged off) and 4647 (user-initiated logoff) carry the same Logon ID on the same host, which gives you session duration. The Logon ID is only unique per boot on that machine, so never join on it across hosts.
A turnstile log records that a valid badge was swiped, not who was holding the badge — and it says nothing about which rooms the person then walked into.
saying these in an interview costs you the question
- Says 4624 proves the user was sitting at the machine
- Reads logon type 3 as a Remote Desktop session
- Treats every successful logon as benign by definition
- Ignores the logon type field and reports only a count
- Claims 4624 tells you what the account then accessed