Event logs: logons, RDP, services and PowerShell

Windows event logs record who logged on, from where and how, which services and tasks were installed, when the system started and stopped, and sometimes the PowerShell code that ran, each with a precise UTC time. This lesson covers the EVTX format, the events examiners use most on Windows 10 and 11, and how to correlate several logs into one account of a session.

Where the logs are and how EVTX is built

The logs are in C:\Windows\System32\winevt\Logs, one file per channel. The classic logs are Security.evtx, System.evtx and Application.evtx. Other channels use the channel name with the slash written as %4: the channel Microsoft-Windows-TerminalServices-LocalSessionManager/Operational is stored as Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx. A triage collection copies these files with their original paths; check that the channels you need were collected before concluding that an event never happened.

The EVTX format is simple at the top level:

Records are stored as binary XML, a compact encoding that refers to templates kept in the chunk; parsers rebuild the XML you see in Event Viewer. Self-contained chunks can also be carved from unallocated space.

Record fields

Every record has a System section and a data section:

• Provider (the component that wrote it, e.g. Microsoft-Windows-Security-Auditing) and EventID. The same number can mean different things for different providers, so always read them together.
• TimeCreated SystemTime, always UTC, e.g. 2026-03-14T22:47:33.2014417Z.
• EventRecordID, a sequence number per log; gaps or a restart at 1 deserve a closer look.
• Channel and Computer (the host name when the event was written).
• EventData (or UserData): named fields such as TargetUserName or IpAddress.

Size and rollover

Each log has a maximum size and, by default, overwrites its oldest events when full. The Security log is by default often 20 MB, so the Security log may only reach back days on a busy system. Operational channels have their own, often smaller, limits but receive fewer events, so they can reach further back than Security. For classic logs, the configured size is the MaxSize value under ControlSet00x\Services\EventLog\<log> in the SYSTEM hive; compare the oldest record with the period under investigation.

Logons in the Security log

Security events depend on the audit policy. Windows 10 and 11 audit logon success and failure by default, but many categories, including process creation, are off unless enabled. The absence of an event is not proof that the action did not occur.

4624 (successful logon) is the core event. Its key fields are TargetUserName, TargetUserSid, TargetLogonId, LogonType, IpAddress, WorkstationName (the client's name), LogonProcessName (e.g. User32, NtLmSsp, Kerberos) and AuthenticationPackageName (e.g. Negotiate, NTLM, Kerberos).

4625 (failed logon) has the same layout plus Status and SubStatus. SubStatus 0xC000006A means a wrong password for an existing account; 0xC0000064 means the user name does not exist. Many 0xC0000064 failures from one IP suggest user-name guessing; a burst of 0xC000006A followed by a 4624 for that account suggests a successful password guess.

Other events in the same family:

• 4634 logoff (the session ended) and 4647 user-initiated logoff (the user chose Sign out).
• 4648 logon with explicit credentials, e.g. runas or mapping a drive with another account.
• 4672 special privileges assigned to a new logon: the account holds sensitive privileges, typically an administrator (or SYSTEM).
• 4720 user account created, 4722 enabled, 4724 password reset attempt, 4732 member added to a security-enabled local group (e.g. Administrators).
• 4688 process creation, only when "Audit Process Creation" is enabled; the CommandLine field is filled only when the extra policy "Include command line in process creation events" is also set.

The Logon ID (TargetLogonId in 4624, a 64-bit value shown in hex) identifies one logon session until it ends. Later events carry it as SubjectLogonId (4672, 4688, 4648) or TargetLogonId (4634, 4647), so filtering on it gathers everything done in that session. Logon IDs are unique only until the next reboot, so pair the ID with the time window.

Remote Desktop across three logs

An RDP session leaves events on the target in three channels:

• RemoteConnectionManager/Operational 1149, "User authentication succeeded", with the user, domain and source IP. It shows that an RDP connection from that IP was accepted for that user name; it does not show that a desktop session started.
• Security 4624 type 10 with the same IP in IpAddress. With Network Level Authentication (NLA) a type 3 logon from the same IP often appears just before. A reconnection or unlock may show type 7 instead.
• LocalSessionManager/Operational (LSM) 21 (session logon succeeded), 22 (shell start notification received), 24 (session disconnected) and 25 (session reconnection succeeded), each with the user, Session ID and source address. Console logons show LOCAL as the address.
• Security 4778 (session reconnected) and 4779 (session disconnected), with LogonID, ClientName and ClientAddress, if "Other Logon/Logoff Events" is audited.

Closing the RDP window disconnects the session without logging off: 24 and 4779 appear, but 4634 only when the user signs out or the session is reset.

Services, tasks, boot and shutdown

In the System log, 7045 (provider Service Control Manager) records a service installation with ServiceName, ImagePath, StartType and AccountName. A random name with an ImagePath running cmd.exe or powershell.exe is typical of remote execution tools. 7036 records a service entering the running or stopped state. 6005 and 6006 (Event Log service started/stopped) mark boot and clean shutdown, 6008 records that the previous shutdown was unexpected, and 1074 (provider User32) names the process and user that initiated a shutdown or restart.

In Microsoft-Windows-TaskScheduler/Operational, 106 records a task being registered with its name and the registering user, and 200/201 record a task action starting and completing. This channel can be disabled, so check that it holds events. Lesson 2.6 covers USB device events.

PowerShell

• Microsoft-Windows-PowerShell/Operational 4104 (script block logging) records the code that ran, after decoding, with a ScriptBlockId; long scripts span several records ("1 of 3"). With the policy on, all blocks are logged. Without it, Windows PowerShell 5.x can log some script blocks automatically, at Warning level, when it considers their content suspicious.
• 4103 (module logging) records pipeline execution details such as commands and parameters, when module logging is enabled.
• Windows PowerShell.evtx 400 and 403 mark the engine starting and stopping; their HostApplication field shows the command line that started PowerShell, including -EncodedCommand values. 600 records providers starting.
• PowerShell 7 uses its own PowerShellCore/Operational channel.

Outside the logs, PSReadLine saves typed console commands in %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt for each user, keeping by default the last 4,096 lines. It has no timestamps, so date its entries by correlation (4104, file system times).

Cleared logs

Security 1102 ("The audit log was cleared") and System 104 (another log cleared) record who cleared a log. Module 7 covers log clearing as anti-forensics.

Tools and method

Event Viewer can open a copied .evtx for spot checks, but displays local time of the analysis machine. For analysis, parse all logs into one table: EvtxECmd, for example, uses maps that normalize event fields into common columns (user, remote host, executable) and writes CSV in UTC. Hunting tools such as Hayabusa and Chainsaw apply detection rules across many logs; verify every hit in the original record.

Worked example: one RDP session

A triage collection from workstation WS-FIN-07 shows these events (UTC):

Linking. The user and the IP tie 1149 to 4624; the 4624 TargetLogonId ties it to 4672 and 4779; the user, IP and Session ID tie the three LocalSessionManager events. Some tools show Logon IDs in decimal: 0x3E1A2B = 62 × 65,536 + 0x1A2B (6,699) = 4,069,931.

Reading. mreyes connected from 203.0.113.45 (client computer DESKTOP-K2M9QX), logged on at 22:47:33Z with special privileges (4672) and disconnected at 23:31:05Z. Duration: 23:31:05.117 − 22:47:33.201 = 43 min 31.916 s. No 4634 or 4647 follows, so the session stayed logged on but disconnected. Filtering on 0x3E1A2B in this window would show what ran in the session, if 4688 was audited.

Event ID reference

Exam focus: Expect to report a logon time in UTC, a source IP, a Logon ID, a client workstation name or a service ImagePath from parsed logs, and to choose the right event for a question (1149 versus 4624 type 10 versus LSM 21). Know the logon types and the two common 4625 SubStatus codes, and be ready to explain why a missing event may reflect audit policy or rollover rather than inactivity. Take times from SystemTime, not from a viewer that converts them to local time.

Key points

• EVTX files live in C:\Windows\System32\winevt\Logs; a 4 KB ElfFile header is followed by 64 KB ElfChnk chunks holding binary XML records with UTC times and an EventRecordID.
• Logs roll over: the Security log is often only 20 MB, so compare its oldest record with the period of interest.
• 4624 gives user, SID, LogonType, Logon ID, IP and workstation; 4625 Status/SubStatus explain failures; 4672 marks privileged logons.
• RDP appears as 1149, 4624 type 10, LSM 21/22/24/25 and 4778/4779; link them by user, IP, Session ID and Logon ID.
• 7045 records new services, 106/200/201 scheduled tasks, 4104 PowerShell code; ConsoleHost_history.txt keeps typed commands without times.
• Many events depend on audit or logging policy, so absence is not proof of absence.