Logs are the raw material of security investigations. Knowing which Event IDs matter, what fields to focus on, and how to spot anomalies in a stream of noise is one of the most practical skills in SOC work. Click any log row below to inspect its fields and see what it tells you.
| Event ID | Name | Why it matters |
|---|---|---|
| 4624 | Successful logon | Baseline of all authentication activity. Logon Type field distinguishes interactive (2), network (3), batch (4), service (5), unlock (7), remote interactive (10). Type 3 and 10 from unusual sources are high-value. |
| 4625 | Failed logon | Failed auth attempts. A burst of 4625 from one source to many accounts is password spraying. Many 4625 from many sources to one account is credential stuffing. |
| 4648 | Logon with explicit credentials | A process used explicitly provided credentials (runas, pass-the-hash, lateral movement). Legitimate uses exist but combined with unusual target hosts it is high-signal lateral movement. |
| 4768 | Kerberos TGT requested | User requested a Ticket Granting Ticket. Normal on logon, but tools like Rubeus generate these. Kerberoasting requests (4769) follow TGT requests for service accounts. |
| 4769 | Kerberos service ticket requested | A user requested access to a specific service. Kerberoasting harvests these to crack offline. Requests for service accounts with RC4 encryption (not AES) at high rate is the signature. |
| 4776 | NTLM credential validation | Domain controller validated credentials via NTLM. NTLM should be largely retired; its presence from modern clients can indicate relay attacks or legacy tooling. |
| 4688 | Process created | A new process was started. The most useful log in Windows when command-line auditing is enabled -- shows the full command line, parent process, and user. The basis of most EDR detection logic. |
| 4698 | Scheduled task created | A new scheduled task was registered. Persistence mechanism -- attackers create tasks to survive reboots. Tasks created outside of known software deployments warrant review. |
| 4732 | Member added to local group | A user was added to a local security group. Adding accounts to Administrators or Remote Desktop Users is a common privilege escalation step after initial access. |
| 7045 | New service installed | A new Windows service was installed (System log, not Security). Services are a persistence vector -- malware installs as a service to run as SYSTEM on boot. |
Sysmon (System Monitor) fills the gaps in native Windows logging. While Windows Event ID 4688 logs process creation, it requires a separate audit policy to capture the command line and does not log network connections, DNS queries, or file hash values by default. Sysmon does all of this and more.
The most critical Sysmon events: Event 1 (process creation with hash and command line), Event 3 (network connection from a process), Event 7 (image loaded -- DLL loads), Event 10 (process access -- used to detect LSASS memory reads), and Event 22 (DNS query). Together these provide enough telemetry to reconstruct almost any attack chain without relying on an EDR agent.
| Sysmon ID | Event type | Key detection use |
|---|---|---|
| 1 | Process Create | Full command line + parent + hash. Detects malicious PowerShell, encoded commands, LOLbins (living off the land binaries) |
| 3 | Network Connect | Process-to-IP:port mapping. Detects C2 beacons, tools connecting to the internet from unexpected processes |
| 7 | Image Loaded | DLL loads. Detects DLL hijacking, reflective DLL injection (no file on disk) |
| 10 | Process Access | One process reading another's memory. Detects Mimikatz, credential dumpers reading LSASS |
| 11 | File Created | New file on disk. Detects dropper payloads, malware staging in temp directories |
| 13 | Registry Set | Registry value modification. Detects persistence via Run keys, service config changes |
| 22 | DNS Query | Process-level DNS resolution. Detects DNS-based C2, unusual domains resolved by system processes |
Entra ID sign-in logs are essential for investigating cloud-based identity attacks including AiTM phishing, password spray, and account takeover. Every sign-in generates a log entry with: user, application, IP address, result code, device/browser, location, and MFA status.
The fields that matter most in an investigation: IP address (look for Tor exit nodes, hosting providers, unexpected countries), User Agent (AiTM proxies sometimes show unusual browser strings or Python request libraries), Authentication requirement (single-factor vs MFA -- a successful single-factor sign-in for an MFA-required account is a major red flag), and Token issuer type (AzureAD vs AzureADMyOrg -- guest accounts or token confusion).
Baseline first, then deviation: A single failed logon is noise. Three hundred failed logons in 60 seconds from a single IP is a spray attack. Volume and rate only mean something relative to a baseline. Know what normal looks like for the environment before declaring an anomaly.
Correlate by time: Logs in isolation are less useful than logs in relation to each other. If a user fails to authenticate 200 times and then succeeds at 03:14 UTC, and 45 seconds later a service account runs a scheduled task that was never seen before -- each event alone is ambiguous. Together they tell a story.
Follow the chain: Start from a known bad indicator (a flagged IP, a malicious domain, a triggered alert) and work outward in both directions through time. What happened before the indicator? What happened after? This bidirectional pivot is the core of log-based investigation.
Presence vs absence: Sometimes the most significant finding is what is missing. A machine that normally generates 4000 events per hour dropping to zero could indicate an agent failure -- or an attacker disabling logging. Gaps in the timeline are evidence.