Log Analysis – It’s Not About Knowing, It’s About Correlating
- 2 minutes ago
- 10 min read
I know, I know — Log Analysis doesn’t sound like the most exciting topic these days. Everyone in cybersecurity has gone through it at some point, and if you’ve sat in an interview, you’ve probably been asked about it too. There are already tons of articles and videos on this topic out there.
But here’s the thing — log analysis isn’t about knowing event IDs by heart. It’s about correlating different events together to tell a story. That’s the part most people miss.
And that’s what I’m going to focus on today.
------------------------------------------------------------------------------------------------------------
Why This Topic Still Matters
Even with so many amazing tools available now — like
Chainsaw understanding how to correlate logs is still essential.
These tools automate the process, but they don’t think for you. They can highlight suspicious events, but they can’t explain why something happened, or how one event connects to another.
That’s where your analysis skills come in.
To help with this, I’ve created a personal Intrusion Detection Cheat Sheet — it’s available under the Resume page on my website, under Quick Guides.
It contains core correlations and scripts I’ve built for my own investigations — things that are hard to remember when you’re in the middle of an IR case.
------------------------------------------------------------------------------------------------------------
Tracking Account Usage: Logon Events
One of the most common and powerful ways to start log analysis is by tracking account activity — basically, who logged in, from where, and when.
Relevant Event IDs
4624 → Successful Logon
4625 → Failed Logon
4634 / 4647 → Successful Logoff
4648 → Logon using explicit credentials (like RunAs)
4672 → Special privileges assigned to a new logon
These five are the bread and butter of account tracking.
How to Read These Events
Every log entry is more than just a timestamp. When you expand an event in the Event Viewer (or parse it with a tool), focus on the following fields:
Timestamp: When the event occurred.
Computer: The hostname — helps correlate across multiple systems.
Account Name: Who logged in or attempted to.
Logon Type: How they logged in — locally, over the network, via RDP, etc.
Event ID: What kind of logon or logoff this was.
Understanding Logon Types
Here’s a quick reference to some of the most useful logon types:
Logon Type | Description |
2 | Interactive logon via console or KVM |
3 | Network logon (SMB, PowerShell remoting, etc.) |
4 | Batch logon (used by Scheduled Tasks) |
5 | Service logon (Windows service accounts) |
7 | Session reconnect (unlock, RDP reconnect, etc.) |
8 | Network logon sending credentials in cleartext |
9 | Logon using different credentials (RunAs /netonly) |
10 | Remote interactive logon (RDP) |
11-13 | Cached or reconnected logons |
This is where correlation starts to get interesting.
If you see Logon Type 10 on a workstation, for example, that means Remote Desktop was used — which might be normal on a jump server, but very suspicious on a regular user laptop.
If you see 4625 (failed logons) with Type 3 repeatedly from different IPs — that’s often a password spray or brute-force attempt.
Correlating Logons and Logoffs
Let’s say you find this:
A 4624 (successful logon) event at 12:00 PM
A 4647 (user-initiated logoff) event at 12:00 AM the next day
Using the Logon ID (a unique value assigned to each session), you can tie these together and calculate how long the user was active.
That’s useful in profiling behavior:
Was this an abnormally long session?
Was it active during non-business hours?
Did any privileged actions happen in between (like a 4672 event)?
That’s what log correlation really means — finding connections between time, behavior, and privilege.
------------------------------------------------------------------------------------------------------------
When Logs Don’t Tell the Whole Story
It’s important to remember that not every access attempt creates a logon event. If a system is exploited via a backdoor or remote code execution vulnerability, you might not see a normal 4624 event.
That’s why correlation must extend beyond Security.evtx — you need to look at:
Sysmon events (especially Event ID 1, 3, and 7)
Prefetch files and ShimCache
USN Journal and Amcache
PowerShell and WMI logs
When combined, these help fill the gaps where the Event Viewer stays silent.
------------------------------------------------------------------------------------------------------------
Pro Tip: Don’t Memorize — Build Your Correlations
You don’t have to remember every event ID.Instead, build a mental (or written) correlation map like this:
Scenario | Event IDs to Link | Description |
Brute-force attack | 4625 + Source IP pattern | Repeated failed logons from same IP |
Lateral movement | 4624 + 4672 + Type 3/10 | Successful logon with admin privileges |
Privilege escalation | 4672 + 4688 | Elevated rights + new process creation |
RunAs misuse | 4648 + 4624 | Explicit credential use detected |
RDP session | 4624 (Type 10) + 4634 | Remote login session tracking |
This is exactly what I’ve built in my Intrusion Detection Cheat Sheet, and I can tell you — it makes a huge difference during investigations.
------------------------------------------------------------------------------------------------------------
Understanding Built-In Accounts in Windows Logs
When you’re digging through event logs, you’ll often stumble upon strange account names like SYSTEM, LOCAL SERVICE, NETWORK SERVICE, or even things like UMFD-0 and DWM-1.
At first glance, these can look suspicious — especially if you’re new to Windows log analysis.But here’s the truth: not every “unknown” account is an attacker. Many of these are built-in service accounts that Windows uses to run background processes and manage system functions — often before a real user even logs in.
Common Built-In Accounts You’ll See
Account | Description | Typical Logon Type | Privilege Level |
SYSTEM | The most powerful local account. Has unlimited privileges on the machine. | 5 | Highest (root-equivalent) |
LOCAL SERVICE | Runs processes that don’t need network access. Uses null sessions for network calls. | 5 | Low |
NETWORK SERVICE | Similar to LOCAL SERVICE, but can authenticate over the network. | 5 | Medium |
<Hostname>$ | The computer account for a domain-joined machine. Used for machine-to-domain authentication. | 3 | System |
DWM / UMFD | Internal Windows components (Desktop Window Manager and Font Driver Host). | 2 | Low |
ANONYMOUS LOGON | Represents unauthenticated connections (e.g., null sessions, some network access). | 3 | None |
💡 Tip: Built-in accounts are noisy. Don’t panic if you see multiple 4624 (Logon) events with these accounts — they appear frequently as part of normal Windows operation.
Why These Accounts Exist
Each service or process in Windows must run under an identity — something that defines its permissions. When Windows boots, dozens of processes start before any user logs in, and these rely on internal accounts like SYSTEM or LOCAL SERVICE.
For example:
The SYSTEM account might handle core OS-level operations.
LOCAL SERVICE might manage background maintenance tasks.
NETWORK SERVICE might handle updates or telemetry that require outbound connectivity.
The Microsoft Trustworthy Computing Initiative (post-Windows 2003) actually reduced the power of SYSTEM by introducing these limited accounts, following the principle of least privilege.
Filtering Out the Noise
When you’re hunting for intrusions, seeing dozens of system account logons can clutter your view. To focus on real user activity, it’s smart to filter out built-in accounts like these:
SYSTEM
LOCAL SERVICE
NETWORK SERVICE
DWM-*
UMFD-*
<Hostname>$
ANONYMOUS LOGON
This will leave you with cleaner visibility on human actions — the kind attackers try to mimic.
------------------------------------------------------------------------------------------------------------
Tracking Privileged Account Activity (Event ID 4672)
Now let’s talk about one of the most powerful log events for defenders:
Event ID 4672 — “Special privileges assigned to new logon.”
Whenever a user logs in and is assigned admin-level privileges (like SeDebugPrivilege or SeTakeOwnershipPrivilege), Windows records Event ID 4672.
This event appears immediately after a 4624 (Successful Logon) event and indicates that the account logging in has administrative capabilities — either local admin, domain admin, or system-equivalent rights.
Why 4672 Is a Goldmine
Every attacker, at some stage, needs admin-level access to move laterally, dump credentials, or persist. That means tracking Event ID 4672 can help you:
Detect unexpected privilege elevation.
Spot service accounts behaving unusually.
Identify high-value targets for auditing.
Here’s what a typical 4672 looks like:
Field | Example | Meaning |
Account Name | Dean | The account that logged in |
Privileges Assigned | SeDebugPrivilege, SeTakeOwnershipPrivilege | Indicates admin-level capabilities |
Correlating Event | 4624 (Logon) | Shows when and how they logged in |
If you see a 4624 + 4672 pair on a system where admin logons are rare, your threat-hunting instincts should kick in immediately.
Correlation Example
Let’s say you see this sequence:
4624 — Successful logon (User: Dean)
4672 — Special privileges assigned
4688 — New process created (possibly with elevated rights)
This combination can signal an attacker using stolen credentials or a scheduled task executing under admin privileges.
To confirm, look at:
Logon Type (e.g., Type 10 for RDP or Type 3 for network)
Source IP (was it remote?)
Timestamp proximity (did 4672 appear right after 4624?)
If yes — that’s a strong indicator of admin-level access.
------------------------------------------------------------------------------------------------------------
Event ID 4648 — Explicit Credential Use
Another powerful event in correlation chains is 4648, which records when a user explicitly provides credentials.
This happens when someone:
Uses Run As to launch a program with another account.
Connects via PsExec, Enter-PSSession, or net use /user:.
Initiates RDP or SMB connections that prompt for alternate credentials.
In short:
4624 = Logon occurred4648 = Credentials explicitly entered
4648 in Action
Here are two examples:
Example 1 — RDP Connection
Source: dean.cyberengage.org
Target: Server10
Credential Used: dean@cyberengage.org
SPN: TERMSRV/server10
This means the user on <Endpoint> used admin credentials to open an RDP session to Server10.
Example 2 — SMB Share Mapping
Command:
net use S: \\server10\share /user:cyberengage.og\administrator
Network Address: 192.168.0.0
Port: 445 (SMB)
SPN: CIFS/server10
Here, 4648 records that the user explicitly entered alternate credentials to access a network share.
Why This Matters
When combined, 4624, 4672, and 4648 tell a powerful story:
4624: The account logged in.
4648: They used a different credential (e.g., administrator).
4672: That credential had admin-level privileges.
This pattern — especially across multiple machines — often signals credential misuse, lateral movement, or privilege escalation.
Defensive Takeaway
You don’t need fancy tools to spot privilege abuse — just solid log correlation.
Start with this simple approach:
Search for Event ID 4672 across endpoints.
Correlate each one with 4624 and 4648.
Flag logons from:
Unusual hosts
Non-working hours
Service accounts acting interactively
These insights often expose attacker behavior long before malware is detected.
------------------------------------------------------------------------------------------------------------
RDP (Remote Desktop Protocol)
Why RDP Matters in IR
Attackers love RDP: It’s one of the most abused remote access mechanisms.
Sophos (2023): 90% of investigated intrusions involved RDP.
RDP abuse examples:
Lateral movement within internal networks.
Persistence via hijacked sessions.
Rogue outbound RDP (social engineering or misconfigurations).
Credential theft or privilege escalation via RDP sessions.
Core Windows Event IDs
Event ID | Description | Notes |
4624 | Successful Logon | Logon Type 3 (network), 7 (unlock/reconnect), 10 (RDP) |
4647 | Logoff | User-initiated logoff |
4778 | Session Reconnected | Captures hostname + IP of client |
4779 | Session Disconnected | Captures client that disconnected |
4801 | Workstation Unlocked | Often seen before Type 7 reconnects |
Key Forensic Insights
1. Event 4778 (Session Reconnected)
Indicates a user reconnected to an existing session.
Contains both Client Name and Client IP Address (often the attacker’s system).
Often paired with:
4624 (Type 7) → Unlock / RDP reconnect
4801 → Workstation unlock
Important: Not every RDP session logs 4778—only reconnects.
2. Event 4779 (Session Disconnected)
Marks when a session was closed or disconnected.
Use it with 4778 to “bookend” RDP session activity.
3. Event 4624 (Logon Type) Reference
Logon Type | Meaning |
3 | Network (NLA) — pre-authenticated connection |
7 | Unlock / Reconnect |
10 | Classic RDP Interactive Logon |
Many analysts mistakenly only track Logon Type 10 → this can miss modern NLA-based (Type 3) or reconnect-based (Type 7) RDP events.
Supporting Logs (Auxiliary Sources)
Log Source | Event IDs | Use |
RDPCoreTS | 131 | Outbound RDP connections |
TerminalServices-RDPClient | 1024, 1102 | Destination hostname & IP for outbound RDP |
Prefetch | tscon.exe | Evidence of RDP hijacking (session switching) |
Sometimes Mismatched Logon IDs — What It Means
You may notice sometimes that the Logon ID in Event ID 4778 doesn’t match the one in 4624.That’s normal.
Here’s why:
Event IDs 4778 and 4779 track session reconnect/disconnect activity.
These events inherit the Logon ID of the earliest still-active session by that user.
If there was a prior session (and it was never fully logged off), the reconnect event uses that old session ID — leading to a mismatch.
Practical Takeaways for DFIR Analysts
Correlate Events Together
Combine 4778, 4779, 4624, and 4647 to reconstruct RDP timelines.
Look Beyond Logon Type 10
Type 7 and Type 3 can hide RDP reconnects or NLA-based connections.
Pay Attention to Client Name & IP
These are often your best clues about attacker infrastructure.
Check for Persistence via Unclosed Sessions
Attackers can hijack old sessions left open by admins to avoid detection.
Pivot to Auxiliary Logs
Inspect RDPCoreTS (Event 131) and RDPClient logs (Events 1024/1102) for outbound connections.
Check Prefetch for tscon.exe (used in RDP hijacking).
Additional RDP Logging and Account Logon Events
Why This Matters
Attackers abuse RDP (Remote Desktop Protocol) both for initial access and lateral movement. Unfortunately, traditional Security logs roll over quickly, so responders can lose critical evidence unless they correlate data across custom RDP logs and authentication logs (Account Logon Events).
1. Primary RDP Log Sources
Target Log | Key EIDs | Relevant Data Captured | Description |
Security | 4624, 4778 | Source IP / Hostname / Username | Standard logon + RDP reconnects |
TerminalServices-RDPClient | 1024, 1102, 1029 | Destination Hostname / Destination IP / Hashed Username | Logs outbound RDP connections (source-side) |
Remote Desktop Services-RDPCoreTS | 98, 131 | Successful connections / attempts / Source IP / Username | Helps identify RDP sessions and connection attempts |
TerminalServices-RemoteConnectionManager | 1149 | Source IP / Username | Tracks successful RDP authentications |
TerminalServices-LocalSessionManager | 21, 22, 25, 41 | Source IP / Username | Tracks session creation, connection, and disconnection |
Tip: Combine these logs for complete RDP session reconstruction. The Security log gives general logon evidence, while the custom RDP logs persist longer and provide IPs, hostnames, and session context that may be missing from Security.
2. Key Log: Microsoft-Windows-TerminalServices-RDPClient/Operational
This is the most valuable log for tracking lateral movement because:
It’s recorded on the source system (unlike most Windows logs that log activity on the destination).
It shows where the attacker moved from the compromised machine.
Event IDs
Event ID | Meaning | Example Use in IR |
1024 | Records the name of each system accessed | Identify lateral movement destination hostnames |
1102 | Records the IP address of each system accessed | Validate connections or pivot points |
1029 | Contains a Base64-encoded SHA256 hash of the username used | Useful for detecting reused or suspicious usernames |
Event ID 1029 – Username Hashing Details
Hash = SHA256(username) (case-sensitive, domain ignored).
Example: dean@cyberengage.org → hash based only on administrator.
Case matters: Admin ≠ ADMIN ≠ administrator.
Helps detect unusual capitalization patterns (e.g., ADMINistrator) used by attackers to bypass detection.
Pro Tip: Always correlate 1029 events with Event ID 4648 (Explicit Credential Use) in the Security log to see the account actually used for RDP.
3. Account Logon vs Logon Events
Event Category | Recorded On | Purpose |
Logon Events | System where authorization happens (workstation/server being accessed) | Local or remote login tracking |
Account Logon Events | System where authentication happens (local SAM or Domain Controller) | Credential validation tracking |
Account Logon Events
Protocol | Event IDs | Meaning |
NTLM | 4776 | Account authentication success/failure |
Kerberos | 4768 | Ticket Granting Ticket (TGT) requested |
4769 | Service Ticket requested | |
4771 | Pre-authentication failed |
How They Work
Local Accounts: Authentication logged on the same workstation (Local SAM).
Domain Accounts: Authentication logged on the Domain Controller (Kerberos/NTLM handshake).
A single logon can generate:
4624 (Logon Event) on the workstation, and
4768/4769 (Account Logon Events) on the DC.
If you see Account Logon events on a workstation, it often signals a rogue local account — a potential attacker-created persistence mechanism.
We will continue more in next article!
------------------------------------------------------------------------------------------------------------
Closing Thoughts
Log analysis might not sound exciting compared to hunting with EDR or sandboxing malware samples — but it’s still the foundation of incident response.
The automation tools will help you find the “what,” but your understanding of correlation helps you find the “why” and “how.”
So the next time someone asks you about Event ID 4624 in an interview — don’t just define it. Explain how you’d correlate it with other events to tell the story of an intrusion. That’s where the real skill lies.
-------------------------------------------------Dean----------------------------------------------------
Comments