Event ID 4634: An account was logged off

Event 4634 is the closing half of a pair. Every interactive, network, service, or remote logon session that Windows opens with a 4624 eventually ends, and when it does, the system logs a 4634 carrying the same TargetLogonId hex value that the 4624 recorded when the session started. That shared LogonId is the single most useful thing about this event: on its own, a 4634 tells you only that some session closed; joined back to its opening 4624, it tells you which account, which LogonType, and exactly how long the session lasted.

TargetUserSid, TargetUserName, and TargetDomainName identify the account whose session ended, mirroring the same fields on the originating 4624. LogonType repeats the enumeration from that same event, 2 for interactive, 3 for network, 10 for RemoteInteractive/RDP, and so on, which matters because "an account logged off" means something very different for a console session than it does for a scheduled-task service logon that opens and closes in milliseconds.

The event fires for a wide range of session endings, not just a user clicking a visible sign-out option. A network share disconnecting, an RPC-authenticated service call completing, an SMB session timing out, an RDP session disconnecting or being forcibly reset, all of these close out with a 4634 tagged to the LogonType that opened them. This breadth is exactly why 4634 alone is a weak signal: it fires constantly, for entirely mundane reasons, dozens or hundreds of times an hour on a busy file server.

What turns 4634 from noise into evidence is arithmetic, not the event itself. Subtracting the 4624 timestamp from the paired 4634 timestamp gives you real session duration, and duration is where the interesting patterns live. A session that opens and closes in under five seconds is not a human interactively working, it is a script, a credential-validation check, or an automated tool authenticating and immediately disconnecting, a shape worth flagging especially when the LogonType is interactive or RemoteInteractive, where a genuine user session almost never closes that fast.

The reverse gap matters just as much. Not every 4624 gets a clean matching 4634. A host that crashes, loses power, or has a logon session forcibly killed by another process leaves the session open from the log's perspective with no closing event ever arriving. That absence is itself diagnostic: a privileged interactive session that opened and never logged a corresponding 4634 within a reasonable window deserves the same scrutiny as an explicit anomaly, because it usually means either an unclean shutdown worth investigating operationally, or a session an attacker deliberately kept alive by killing the logging path rather than logging off normally.

RemoteInteractive sessions deserve their own attention layer beyond individual duration checks. A cluster of RDP logoffs across many distinct accounts within a tight window, particularly outside business hours, reads as a mass disconnect event: a VPN or jump-host outage, a forced logoff pushed by group policy, or, less benignly, an attacker cleaning up multiple sessions across compromised hosts in one coordinated action.

Most 4634 volume is exactly what it looks like: routine session closure generated by users signing off, scheduled tasks completing, and services cycling their authenticated connections. The baseline for any given host or account is high frequency and largely uninteresting, which is why alerting on 4634 directly is close to useless. Everything that matters here comes from correlation, not from the raw event.

Sub-five-second session durations on interactive or RemoteInteractive logon types are the strongest single tell available from this event. A legitimate interactive user, even one who immediately locks their screen after logging in, takes longer than that between a 4624 and the matching 4634. Automated tooling, credential-validation scripts, and some categories of lateral-movement frameworks authenticate and tear down the session in a fraction of a second, and that gap is measurable precisely because 4634 carries the same LogonId the opening event does.

A missing 4634 is a true positive candidate specifically when the LogonType is privileged or interactive and enough time has passed that a normal session should have closed. Treat this as a two-tier signal: on a workstation, a missing logoff after a crash is common enough to be an IT-hygiene metric rather than a security alert; on a domain controller or another Tier-0 asset, the same pattern, a 4624 with no 4634 within, say, a business day, is unusual enough to warrant checking whether the session is still active and, if so, why.

Bulk RemoteInteractive logoffs are almost always benign when they line up with a known maintenance window, a VPN concentrator restart, or a scheduled group-policy-driven session reset, and the fix here is an allowlist of known maintenance events rather than a fixed numeric threshold. The same pattern outside any documented window, especially spanning accounts that do not normally share a logoff cadence, is worth treating as a possible sign of an attacker closing out sessions across multiple footholds in a short window, either to reduce visible dwell time or as a side effect of a broader disruptive action.

False positives cluster around two causes: legitimate automation, health-check scripts, monitoring agents, and backup jobs that log on and off in seconds as part of normal operation, and environments with aggressive idle-session timeout policies that generate many closely spaced logon and logoff pairs for a single active user bouncing between authentication contexts. Baseline both before tuning a duration threshold, and always pivot to the paired 4624's LogonType and Account fields before deciding whether a short session or a missing logoff is a routine artifact or something that needs a closer look.