Cybersecurity Bootcamp — Phase 4, Week 7

DAY	TOPIC	WHAT YOU'LL LEARN	KEY TOOLS
Day 43	SIEM Fundamentals	What a SIEM is and why every enterprise runs one. Splunk vs ELK architecture. Ingesting log sources, index structure, field extraction. Building dashboards. SPL (Search Processing Language) from first principles — search, eval, stats, table, where, rex. Your first detection dashboard for failed logins.	Splunk, ELK Stack, SPL
Day 44	Log Analysis	Windows Security Event IDs that matter (4624, 4625, 4648, 4688, 4698, 4720, 4732, 7045). Linux auth.log, syslog, and /var/log structure. Web server access log analysis. Parsing with grep/awk pipelines. Identifying brute-force, lateral movement, and persistence in raw log data.	Event Viewer, auditd, grep, Splunk
Day 45	Threat Detection	Writing Splunk SPL detection queries for real attacks: port scans, brute-force, Mimikatz (LSASS access), Pass-the-Hash (4624 logon type 3), Kerberoasting (4769), scheduled task creation (4698), new service (7045). Introduction to Sigma rules — vendor-agnostic detection format. Converting Sigma to SPL and Snort.	Splunk SPL, Sigma, sigmac
Day 46	IDS/IPS — Snort & Suricata	Network-based intrusion detection vs host-based. Snort rule syntax deep dive: action, protocol, source, destination, options (content, pcre, threshold, sid, rev). Writing rules to detect Nmap scans, SQL injection, XSS, reverse shells, C2 beaconing. Suricata advantages: multi-threaded, built-in EVE JSON logging, protocol detection. Alert tuning to reduce false positives.	Snort, Suricata, EVE JSON
Day 47	Incident Response	The 6-phase IR lifecycle (Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned). IR playbooks for ransomware, account compromise, and data exfiltration. Triage methodology: what to do in the first 15 minutes of an incident. Chain of custody. Communication with management. Legal considerations.	IR playbooks, Velociraptor, TheHive
Day 48	Digital Forensics I	Forensics methodology and order of volatility. Disk imaging with dd and FTK Imager — bit-for-bit copies preserving evidence. File system structure: MFT, inodes, slack space, deleted file recovery. File carving with foremost/scalpel. Autopsy for graphical forensics analysis. Metadata extraction and timeline creation.	FTK Imager, Autopsy, dd, foremost
Day 49	Digital Forensics II + Review	Memory forensics with Volatility 3: process listing (windows.pslist), network connections (windows.netstat), injected code detection (malfind), extracting strings from process memory, dumping process executables. Volatility plugins for detecting Mimikatz artifacts and hollowed processes. Week 7 capstone: analyze a provided malware-infected memory image and write a one-page forensic report.	Volatility 3, strings, yara

SIEM FUNDAMENTALS

THEORYLAB Splunk · ELK Stack · SPL · Dashboards · Log Ingestion

WEEK 7 PROGRESS — DAY 43 OF 49

🛡️

Welcome to the Blue Team. Everything you did in Phases 2 and 3 left traces. A SOC analyst's job is to find those traces before the damage is done. A SIEM (Security Information and Event Management) system collects logs from every source across the environment, normalises them, and lets analysts search, alert, and dashboard them. Today you become the analyst hunting your own attacks.

// 43.1 — WHAT IS A SIEM?

SIEM ARCHITECTURE

A SIEM has three jobs: collect logs from every device and application, correlate events across sources to detect attack patterns, and alert analysts when something suspicious matches a rule. Think of it as the nervous system of a SOC.

Without a SIEM: an attacker moves laterally across 15 machines, and each machine's local log sees only one hop. With a SIEM: all 15 logs arrive in one place and the full lateral movement chain is visible.

SPLUNK VS ELK

FEATURE	SPLUNK	ELK STACK
Cost	Commercial ($)	Free (open source)
Ease of use	Excellent GUI	Steeper learning curve
Query language	SPL	KQL / Lucene
Industry use	Enterprise standard	Growing rapidly
Student access	Free (500MB/day)	Fully free
Start with	Both — different jobs use different tools

// 43.2 — SPL: SEARCH PROCESSING LANGUAGE

💡

SPL reads left to right like a pipeline. Each command takes the results of the previous command as input. Search → transform → display. Once you understand the pipeline model, any SPL query becomes readable.

Splunk Search & Reporting — SPL REFERENCE

| ── BASIC SEARCH ──────────────────────────────────────────────────── index=windows_logs EventCode=4625 | failed login events index=* sourcetype=syslog "Failed password" | SSH failures from any index index=web_logs status=404 | head 100 | first 100 404 errors | ── TIME MODIFIERS ────────────────────────────────────────────────── index=windows_logs earliest=-24h latest=now index=windows_logs earliest="01/15/2024:00:00:00" latest="01/15/2024:23:59:59" | ── STATS — aggregate and count ───────────────────────────────────── index=windows_logs EventCode=4625 | stats count by src_ip, Account_Name | sort -count src_ip Account_Name count 10.0.0.50 Administrator 847 ← brute-force attacker! 10.0.0.50 john.smith 312 192.168.1.5 admin 45 | ── TABLE — display specific fields ───────────────────────────────── index=windows_logs EventCode=4624 | table _time, src_ip, Account_Name, Logon_Type, Workstation_Name | sort -_time | ── EVAL — create computed fields ─────────────────────────────────── index=web_logs | eval response_kb = bytes / 1024 | where response_kb > 1000 | table _time, uri, src_ip, response_kb | Large responses — potential data exfiltration? | ── REX — extract fields with regex ───────────────────────────────── index=syslog sourcetype=linux_secure | rex field=_raw "Failed password for (?P<username>\S+) from (?P<attacker_ip>\S+)" | stats count by username, attacker_ip | sort -count | ── TRANSACTION — group related events ────────────────────────────── index=windows_logs EventCode IN (4625,4624) | transaction src_ip maxspan=5m | where eventcount > 5 AND match(_raw,"4624") | table src_ip, eventcount, duration | Finds IPs that failed multiple times then succeeded — credential spray! | ── ALERT THRESHOLD ───────────────────────────────────────────────── index=windows_logs EventCode=4625 | bucket _time span=5m | stats count by _time, src_ip | where count > 20 | Triggers when any IP has 20+ failed logins in 5 minutes

// 43.3 — ELK STACK: THE FREE ALTERNATIVE

ELASTICSEARCH · LOGSTASH · KIBANA

Elasticsearch stores and indexes logs. Logstash (or Beats agents) collects and ships logs from endpoints. Kibana is the web UI for searching, dashboarding, and alerting. Combined they replicate most of Splunk's functionality for free.

ELK STACK — SETUP ON KALI (QUICK INSTALL)

# Install Elasticsearch and Kibana: $ wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - $ echo "deb https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list $ sudo apt update && sudo apt install elasticsearch kibana -y $ sudo systemctl start elasticsearch kibana # Access Kibana: http://localhost:5601 # Install Winlogbeat on Windows target to ship logs to ELK: # winlogbeat.yml: winlogbeat.event_logs: - name: Security - name: System - name: Application output.elasticsearch: hosts: ["192.168.56.100:9200"] # Install Filebeat on Linux target to ship /var/log: $ sudo apt install filebeat -y $ sudo filebeat modules enable system $ sudo filebeat setup && sudo systemctl start filebeat # KQL query in Kibana (equivalent to Splunk SPL): event.code: 4625 AND winlog.event_data.LogonType: 3 # Failed network logons event.code: 4624 AND source.ip: "10.0.0.50" # Successful logins from IP

// DAY 43 — QUIZ

You write this SPL query: index=windows_logs EventCode=4625 | stats count by src_ip | sort -count | head 10. It returns 192.168.1.50 = 3,847 failures in the last hour. What does this almost certainly indicate, and what is your immediate next step as a SOC analyst?

A A misconfigured service — 3,847 failures is normal for some applications

— did ANY login succeed? A success after failures = compromised account. (3) Contain — block the source IP at the firewall immediately if this is live. (4) Escalate — open an incident ticket. (5) Check the IP in threat intel (VirusTotal, AbuseIPDB). Never just dismiss high-volume failure alerts.')">B Brute-force or password spray attack — pivot to check targeted accounts, immediately check if any 4624 (success) event followed from the same IP, then block at firewall

C Nmap port scan — port scanners generate failed connection events

D Probably a false positive — wait for more data before acting

// DAY 43 — LAB

LAB TASKS

Install Splunk Free on your Kali VM. Download and ingest the BOTS (Boss of the SOC) dataset — the best free Splunk training dataset available at github.com/splunk/botsv1.
Run the basic SPL queries from section 43.2. Understand what each pipeline stage does before moving to the next.
Build a dashboard panel showing failed logins per hour over the last 24 hours as a bar chart.
TryHackMe room: "Splunk: Basics" — guided SPL practice with real log data.
TryHackMe room: "Splunk 2" — intermediate investigation using the BOTS dataset.

LOG ANALYSIS

THEORYLAB Windows Event IDs · Linux Auth Logs · Web Logs · Parsing Pipelines

WEEK 7 PROGRESS — DAY 44 OF 49

📋

Logs are the attacker's footprints. Every command run, every login attempted, every file opened — all of it leaves entries in log files. The challenge isn't finding the footprints. It's knowing which logs to look at, which fields matter, and what normal looks like so that abnormal stands out instantly.

// 44.1 — CRITICAL WINDOWS EVENT IDs

4624

Successful Logon

Account successfully logged on. Key fields: Logon Type (2=interactive, 3=network, 10=remote, 7=unlock). Type 3 at unusual hours or from unusual IPs = lateral movement.

4625

Failed Logon

Account failed to log on. Sub Status codes reveal why: 0xC000006A = wrong password, 0xC0000064 = username doesn't exist. High volume = brute force.

4648

Logon with Explicit Credentials

A process used explicit credentials (runas). Mimikatz Pass-the-Hash and lateral movement with psexec generate this. Flag: 4648 from non-admin accounts.

4688

Process Creation

New process created. With command-line logging enabled this is gold — reveals cmd.exe /c whoami, powershell -enc, mimikatz.exe. Most underused detection source.

4698

Scheduled Task Created

A scheduled task was created. Persistence mechanism. Legitimate tasks have recognisable names — random strings or typo-squatted names are red flags.

4720

User Account Created

New user account created. Attackers add backdoor accounts after compromise. Any 4720 outside of IT change windows should be investigated immediately.

4732

Member Added to Group

User added to a security group. 4732 where Group=Administrators or Domain Admins is a critical escalation event. Alert immediately.

7045

New Service Installed

A service was installed. PSExec creates a temporary service — you'll see 7045 immediately before a PSExec session. Also used for malware persistence.

4769

Kerberos Service Ticket

Kerberos TGS ticket requested. Kerberoasting generates 4769 events with Ticket Encryption Type 0x17 (RC4) — a strong indicator when volume is high or from unusual accounts.

// 44.2 — READING WINDOWS EVENT LOGS

2024-01-15 02:34:17 WIN-WS01 EventID: 4625 An account failed to log on. Account Name: Administrator Workstation Name: KALI Source Network Address: 10.10.10.50 ← external machine, 2AM, admin account Logon Type: 3 ← network logon (not local) Failure Reason: Unknown user name or bad password Sub Status: 0xC000006A ← wrong password (not wrong username) 2024-01-15 02:34:52 WIN-WS01 EventID: 4624 An account was successfully logged on. Account Name: Administrator Source Network Address: 10.10.10.50 ← same IP, 35 seconds later — password cracked! Logon Type: 3 Authentication Package: NTLM ← NTLM not Kerberos = possible PtH 2024-01-15 02:35:01 WIN-WS01 EventID: 7045 A new service was installed. Service Name: BTOBTO ← random name = PSExec service! Service File Name: %SystemRoot%\BTOBTO.exe Service Account: LocalSystem 2024-01-15 02:35:02 WIN-WS01 EventID: 4688 A new process has been created. New Process Name: C:\Windows\BTOBTO.exe Process Command Line: cmd.exe /Q /c whoami 1> \\127.0.0.1\C$\__output 2>&1 Creator Subject: NT AUTHORITY\SYSTEM ← running as SYSTEM via PSExec

🚨

Reading this chain: 4625 (failed login from 10.10.10.50) → 4624 (success 35s later from same IP, NTLM auth) → 7045 (random service name = PSExec) → 4688 (SYSTEM running cmd.exe with output redirection = PSExec command). This is a complete lateral movement event chain. Every single step is detectable — but only if you're looking.

// 44.3 — LINUX LOG ANALYSIS

LINUX LOG ANALYSIS — KEY FILES AND COMMANDS

# ── KEY LOG FILES ──────────────────────────────────────────── /var/log/auth.log # SSH logins, sudo, su, PAM — PRIMARY security log (Debian/Ubuntu) /var/log/secure # Same on RHEL/CentOS/Fedora /var/log/syslog # General system messages /var/log/kern.log # Kernel messages — useful for detecting rootkits, USB events /var/log/apache2/access.log # Web server — every HTTP request /var/log/apache2/error.log # Web errors — 500 errors, path traversal attempts ~/.bash_history # Commands run by each user — often deleted by attackers /var/log/wtmp # All logins (read with: last) /var/log/btmp # Failed logins (read with: lastb) # ── FIND FAILED SSH ATTEMPTS AND ATTACKER IPs ──────────────── $ grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20 4721 203.0.113.50 ← top attacker 312 10.0.0.23 89 198.51.100.5 # ── FIND SUCCESSFUL LOGINS AFTER FAILURES (compromise indicator) ── $ grep "Accepted" /var/log/auth.log | grep "203.0.113.50" Jan 15 02:41:33 server sshd[1234]: Accepted password for root from 203.0.113.50 ← root SSH login from the same IP that was brute-forcing → COMPROMISED # ── DETECT COMMANDS RUN AS ROOT ───────────────────────────── $ grep "sudo" /var/log/auth.log | grep -v "session closed" $ cat /root/.bash_history # Attackers often run: curl | bash, wget | sh, python -c, nc -e # ── APACHE WEB LOG — DETECT ATTACK PATTERNS ────────────────── $ grep "\"GET.*\.\./\.\." /var/log/apache2/access.log # Path traversal $ grep "sqlmap\|nikto\|nmap\|masscan" /var/log/apache2/access.log # Scanner UA strings $ awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -10 # Top source IPs

// DAY 44 — QUIZ

You see Windows Event ID 4769 (Kerberos Service Ticket) appearing 500 times in 2 minutes from a single user account (john.smith), with Ticket Encryption Type: 0x17 for hundreds of different SPNs. What attack does this indicate and what does 0x17 specifically tell you?

A Golden Ticket attack — forging domain tickets

B Normal Kerberos authentication — users frequently request service tickets

C Kerberoasting — the volume of SPN requests is the attack pattern; 0x17 means RC4-HMAC encryption which is fast to crack offline, unlike AES

D AS-REP Roasting — requesting authentication tickets without credentials

THREAT DETECTION

TOOLLAB SPL Detection Queries · Sigma Rules · MITRE ATT&CK Detection · Alert Tuning

WEEK 7 PROGRESS — DAY 45 OF 49

🎯

Detection is the blue team's exploitation. Just as a pentester uses known attack patterns to compromise systems, a defender writes detection rules that catch those same patterns. Today you write the exact Splunk queries and Sigma rules that would have caught every attack you ran in Phases 2 and 3. This is the most direct form of purple teaming.

// 45.1 — SPL DETECTION QUERIES FOR REAL ATTACKS

DETECTION QUERIES — Built from Week 3 & 4 attack knowledge

| ── DETECT: Nmap SYN Port Scan (network logs) ─────────────────────── index=network_logs tcp_flags="S" | stats dc(dest_port) as unique_ports count by src_ip, _time span=30s | where unique_ports > 50 | table _time, src_ip, unique_ports, count Fires when any IP hits 50+ unique ports in 30 seconds = port scan | ── DETECT: Mimikatz LSASS Access (Sysmon EventID 10) ────────────── index=windows_logs source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 TargetImage="*lsass.exe" | where NOT (SourceImage IN ("*MsMpEng.exe","*csrss.exe","*wininit.exe")) | table _time, ComputerName, SourceImage, TargetImage, GrantedAccess Any process reading lsass.exe memory that isn't AV or OS = Mimikatz-like | ── DETECT: Pass-the-Hash (4624 Logon Type 3 + NTLM) ─────────────── index=windows_logs EventCode=4624 Logon_Type=3 Authentication_Package=NTLM | where Account_Name!="ANONYMOUS LOGON" AND src_ip!="127.0.0.1" | stats count by src_ip, Account_Name, Workstation_Name | where count > 3 | sort -count NTLM network logons from same IP to multiple hosts = PtH lateral movement | ── DETECT: Kerberoasting (4769 RC4 tickets) ─────────────────────── index=windows_logs EventCode=4769 Ticket_Encryption_Type=0x17 Service_Name!="krbtgt" | stats dc(Service_Name) as spn_count count by Account_Name, Client_Address | where spn_count > 5 | sort -spn_count User requesting RC4 tickets for 5+ SPNs = Kerberoasting in progress | ── DETECT: New Admin Account Created (backdoor) ─────────────────── index=windows_logs (EventCode=4720 OR EventCode=4732) | eval action=case(EventCode=="4720","Account Created",EventCode=="4732","Added to Group",true(),"Unknown") | where match(Group_Name,"Admin") OR match(Group_Name,"Domain Admin") | table _time, ComputerName, Subject_Account, Target_Account, action, Group_Name New accounts or group additions in admin groups outside change windows | ── DETECT: Suspicious PowerShell (encoded commands) ────────────── index=windows_logs EventCode=4688 New_Process_Name="*powershell*" Process_Command_Line IN ("*-enc*","*-EncodedCommand*","*IEX*","*Invoke-Expression*","*DownloadString*") | table _time, ComputerName, Account_Name, Process_Command_Line PowerShell with encoded commands or download cradles = likely malicious | ── DETECT: Scheduled Task Persistence ───────────────────────────── index=windows_logs EventCode=4698 | rex field=Task_Content "Command>(?P<task_cmd>[^<]+)" | where match(task_cmd,"powershell|cmd|wscript|cscript|mshta|regsvr32") | table _time, ComputerName, Subject_Account, Task_Name, task_cmd

// 45.2 — SIGMA RULES: VENDOR-AGNOSTIC DETECTION

WHAT IS SIGMA?

Sigma is a generic signature format for SIEM systems — write a rule once, convert to SPL, KQL, Lucene, QRadar, or any SIEM's query language. It's the YARA for log detection. The community Sigma repository (github.com/SigmaHQ/sigma) has 3,000+ pre-built rules you can deploy immediately.

# Sigma rule: Detecting Mimikatz via LSASS memory access title: Mimikatz LSASS Process Access id: a7ae4f4c-f8b2-4d3e-9c8a-1e2f4d6b8c0a status: stable description: Detects process access to LSASS memory — indicative of credential dumping tools like Mimikatz references: - https://attack.mitre.org/techniques/T1003/001/ author: SOC Team tags: - attack.credential_access - attack.t1003.001 logsource: category: process_access product: windows detection: selection: TargetImage|endswith: '\lsass.exe' GrantedAccess|contains: - '0x1010' - '0x1038' - '0x40' - '0x1fffff' filter_legit: SourceImage|contains: - 'MsMpEng.exe' - 'csrss.exe' - 'wininit.exe' - 'lsm.exe' condition: selection and not filter_legit falsepositives: - Some EDR products (tune filter_legit accordingly) level: high

SIGMA CONVERSION — ONE RULE, MANY SIEMs

# Install sigma tools: $ pip install sigma-cli --break-system-packages $ sigma plugin install splunk $ sigma plugin install elasticsearch # Convert Mimikatz Sigma rule to Splunk SPL: $ sigma convert -t splunk -p sysmon mimikatz_lsass.yml EventCode=10 TargetImage="*\\lsass.exe" (GrantedAccess="0x1010" OR GrantedAccess="0x1038") NOT (SourceImage="*\\MsMpEng.exe" OR SourceImage="*\\csrss.exe") # Convert same rule to Elasticsearch KQL: $ sigma convert -t elasticsearch mimikatz_lsass.yml winlog.event_data.TargetImage:(*\\lsass.exe) AND (winlog.event_data.GrantedAccess:0x1010 OR winlog.event_data.GrantedAccess:0x1038) # Download the full Sigma community rule pack: $ git clone https://github.com/SigmaHQ/sigma.git # 3,000+ rules covering every MITRE ATT&CK technique # Convert entire directory to your SIEM in one command $ sigma convert -t splunk -p sysmon -r sigma/rules/windows/

// DAY 45 — QUIZ

Your Splunk detection rule for PowerShell encoded commands fires 2,000 times per day, mostly from legitimate IT admin scripts. Your SOC team is overwhelmed with false positives and starts ignoring the alert. What is the correct approach to fix this without losing detection capability?

A Delete the rule — too many false positives means the detection is wrong

B Raise the threshold to 50 occurrences before alerting

. (2) Context enrichment — add the parent process. Legitimate scripts run from schtasks or specific deployment tools. Mimikatz-delivered commands typically run from cmd.exe or user-interactive PowerShell. (3) Aggregate differently — group by parent process + user, alert only on unusual combinations. (4) Build a lookup table of approved encoded command hashes. The goal: zero false positives for known-good, 100% detection of novel encoded commands. "Alert fatigue" — where analysts ignore noisy alerts — is one of the biggest causes of missed real incidents.')">C Whitelist known-good accounts and machines, add parent process context, and group alerts by unusual combinations rather than individual events — eliminate false positives without losing coverage

D Keep the rule but route alerts to the IT team instead of SOC

IDS/IPS — SNORT & SURICATA

TOOLLAB Snort Rules · Suricata · Alert Tuning · Network Detection

WEEK 7 PROGRESS — DAY 46 OF 49

🔍

Network-based detection catches what host logs miss. An attacker who clears Windows Event Logs leaves network evidence. Snort and Suricata sit on the wire and inspect every packet — they see the port scan, the SQL injection payload, and the reverse shell connection whether or not the target machine keeps any logs.

// 46.1 — SNORT RULE ANATOMY

SNORT RULE STRUCTURE AND REAL EXAMPLES

# RULE FORMAT: # action proto src_ip src_port direction dst_ip dst_port (options) alert tcp any any -> any any (msg:"Nmap SYN Scan Detected"; flags:S; threshold: type both, track by_src, count 20, seconds 5; classtype:network-scan; sid:1000001; rev:1;) # Breaking down the options: # msg: Human-readable alert description # flags:S Only SYN flag set (nmap -sS pattern) # threshold: Alert only after 20 SYN packets in 5 seconds (reduce noise) # classtype: Category for prioritisation # sid: Unique rule identifier (yours start at 1000000+) # rev: Rule version number # ── SQL INJECTION DETECTION ─────────────────────────────────── alert tcp any any -> any 80 (msg:"SQL Injection Attempt - UNION SELECT"; content:"UNION"; nocase; content:"SELECT"; nocase; distance:0; within:20; http_uri; classtype:web-application-attack; sid:1000002; rev:1;) # ── REVERSE SHELL DETECTION ─────────────────────────────────── alert tcp any any -> $HOME_NET any (msg:"Possible Reverse Shell - /bin/bash"; content:"/bin/bash"; content:"-i"; within:20; flow:established,to_server; sid:1000003; rev:1;) # ── C2 BEACONING DETECTION (regular interval) ──────────────── alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Possible C2 Beaconing - Regular HTTPS"; flow:established,to_server; detection_filter: track by_src, count 30, seconds 1800; classtype:trojan-activity; sid:1000004; rev:1;) # ── MIMIKATZ NETWORK INDICATOR ──────────────────────────────── alert smb $HOME_NET any -> $HOME_NET any (msg:"Mimikatz DCSync Activity"; content:"|05 00 0b|"; content:"DrsuApi"; nocase; within:100; sid:1000005; rev:1;) # ── RUNNING SNORT ───────────────────────────────────────────── $ snort -A console -i eth0 -c /etc/snort/snort.conf $ snort -r capture.pcap -c /etc/snort/snort.conf -A console # test against PCAP

// 46.2 — SURICATA: THE MODERN CHOICE

FEATURE	SNORT 3	SURICATA
Threading	Single-threaded	Multi-threaded — handles 10Gbps+
Protocol detection	Basic	Deep protocol awareness — HTTP/2, TLS, DNS, SSH
Output format	Alert log	EVE JSON — structured, SIEM-ready
Lua scripting	Limited	Full Lua for complex detection logic
File extraction	No	Yes — extract files from network streams
Rule compatibility	Snort rules	Compatible with Snort rules + own extensions
Industry trend	Established	Preferred for new deployments

SURICATA — SETUP AND EVE JSON ANALYSIS

# Install Suricata on Kali: $ sudo apt install suricata -y $ sudo suricata-update # Download latest community ruleset (Emerging Threats) # Run against a network interface: $ sudo suricata -c /etc/suricata/suricata.yaml -i eth0 # Run against a capture file for testing: $ sudo suricata -r metasploitable_attack.pcap -l /tmp/suricata_output/ # Read EVE JSON output (structured, one event per line): $ cat /tmp/suricata_output/eve.json | python3 -m json.tool | head -50 { "timestamp": "2024-01-15T02:34:55.123456+0000", "flow_id": 1234567890, "event_type": "alert", "src_ip": "10.10.10.50", "src_port": 51234, "dest_ip": "10.10.10.5", "dest_port": 445, "proto": "TCP", "alert": { "action": "allowed", "signature_id": 2027865, "signature": "ET EXPLOIT EternalBlue Attempt", "category": "Attempted Administrator Privilege Gain", "severity": 1 } } # Filter EVE JSON for alerts only: $ jq 'select(.event_type=="alert") | {ts:.timestamp,src:.src_ip,sig:.alert.signature}' eve.json # Ship EVE JSON to Splunk or ELK for centralised analysis: # Configure /etc/suricata/suricata.yaml outputs.eve-log to Filebeat input

// DAY 46 — QUIZ

Your Suricata rule detects SQL injection in HTTP traffic by matching UNION SELECT strings. An attacker switches to sending UN/**/ION SEL/**/ECT (SQL comment injection). Your rule stops firing. What is the correct approach to make the rule robust against this evasion?

A Add more content matches — also detect "UN" followed by "ION" within 10 bytes

B Use PCRE (regex) with comment-stripping patterns and add behavioural detection (error response rates, abnormal response sizes) rather than relying purely on payload string matching

C Block all traffic containing SQL keywords at the firewall level

D Switch to Suricata EVE JSON logging — it captures the full payload making evasion impossible

INCIDENT RESPONSE

THEORYLAB IR Lifecycle · Playbooks · Triage · Containment · Communication

WEEK 7 PROGRESS — DAY 47 OF 49

⚡

Incident Response is what happens when detection finds something real. The average dwell time for a threat actor in a network before detection is 16 days. Every hour of slow IR means more data exfiltrated, more systems compromised, more damage done. A practised IR process turns a potential catastrophe into a controlled recovery.

// 47.1 — THE 6-PHASE IR LIFECYCLE (NIST SP 800-61)

Preparation

Build IR capability BEFORE an incident. IR playbooks, contact lists, forensic toolkits, network diagrams, asset inventories, logging infrastructure, and tabletop exercises. Most organisations fail here — the first incident shouldn't be when you discover you have no playbook.

Identification

Detect and confirm the incident. SIEM alert fires → is this a true positive? Triage the alert: check correlated events, timeline the activity, determine scope (one machine or many?). Declare an incident and assign severity. Time is critical — every minute of uncertainty is attacker dwell time.

Containment

Stop the bleeding without destroying evidence. Short-term: isolate affected systems from the network (VLAN, firewall rule, pull cable — not shutdown). Long-term: change credentials, block C2 IPs, revoke tokens. Forensic image BEFORE containment actions alter the system.

Eradication

Remove the attacker and their artifacts. Delete malware, close backdoors, revoke persistence mechanisms (scheduled tasks, registry keys, SSH keys). Patch the exploited vulnerability. Reset ALL compromised credentials — not just the ones you found, assume all were harvested.

Recovery

Restore systems to normal operation safely. Rebuild from known-good backups rather than cleaning infected systems (you can't guarantee all malware is removed). Validate systems are clean before reconnecting. Monitor intensively for 30 days — attackers frequently re-enter through overlooked persistence.

Lessons Learned

Write the post-incident report within 2 weeks while details are fresh. What happened, how it was detected, timeline, impact, what worked, what failed, and specific improvements to prevent recurrence. Brief leadership. Update playbooks. This phase is where organisations actually improve — most skip it.

// 47.2 — FIRST 15 MINUTES: RANSOMWARE IR TRIAGE

RANSOMWARE IR — IMMEDIATE RESPONSE CHECKLIST

# ── MINUTE 0–2: CONFIRM AND SCOPE ──────────────────────────── [!] Alert: Files being renamed to .locked extension on FILE-SRV01 ACTION: Don't shut down anything yet — confirm first IR> Check Splunk: index=* FILE-SRV01 | head 50 # What else is happening? IR> netstat -an | grep ESTABLISHED # Active C2 connections? IR> tasklist /v # Suspicious processes? # ── MINUTE 2–5: FORENSIC PRESERVATION ─────────────────────── BEFORE touching anything — capture volatile evidence: IR> netstat -an > C:\IR\network_connections.txt IR> tasklist /v > C:\IR\processes.txt IR> ipconfig /all > C:\IR\network_config.txt IR> wevtutil epl Security C:\IR\security_log.evtx # Export logs NOW before overwritten # Take memory dump if possible (RAMMap, WinPmem) # ── MINUTE 5–10: CONTAINMENT ───────────────────────────────── DO: Isolate via VLAN reassignment (preserves machine, cuts network access) DO: Block the C2 IP at perimeter firewall DON'T: Power off (destroys memory evidence, may worsen encryption) DON'T: Delete suspicious files (need for forensic analysis) # ── MINUTE 10–15: SCOPE ASSESSMENT ────────────────────────── IR> crackmapexec smb 10.10.10.0/24 --gen-relay-list # What else is reachable? # Check Splunk for same C2 IOCs across ALL machines: IR> index=* [known_c2_ip OR file_hash OR mutex_name] # How many machines? Define blast radius before recovery planning # ── COMMUNICATION ──────────────────────────────────────────── Notify (in this order, immediately): 1. IR team lead / CISO 2. Legal counsel (ransomware may require breach notification) 3. Executive team (brief, not technical) 4. Law enforcement (FBI/CISA for ransomware — optional but recommended) DO NOT: Notify publicly before legal review DO NOT: Contact ransomware group without legal counsel DO NOT: Pay ransom without legal/insurance guidance

// DAY 47 — QUIZ

You discover an attacker has had access to your network for 14 days (detected via SIEM). They've compromised 3 servers. You've identified all their persistence mechanisms and the initial access vector. A manager says "just patch the servers and change the passwords — done." What's wrong with this approach and what must you do instead?

A Nothing is wrong — patching and password resets is sufficient for 3 servers

B You should also pay the ransom to ensure all data is recovered

C 14-day dwell time means credential harvesting is near-certain — ALL domain passwords and krbtgt must be reset. Systems should be rebuilt not cleaned. Scope validation and breach notification assessment are also required.

D Shut down all systems immediately until forensics complete

DIGITAL FORENSICS I

THEORYLAB Disk Imaging · File Carving · Autopsy · Timeline · MFT Analysis

WEEK 7 PROGRESS — DAY 48 OF 49

🔬

Digital forensics answers the question: what exactly happened? After containment, forensics builds the complete picture — what files were accessed, what commands were run, what data was exfiltrated, and exactly when every action occurred. This evidence supports legal proceedings, insurance claims, and regulatory breach notifications.

// 48.1 — ORDER OF VOLATILITY

COLLECT THE MOST VOLATILE EVIDENCE FIRST

Volatile data disappears when the system is powered off. Non-volatile data persists. Always collect in this order — never power off a live system before capturing volatile evidence.

ORDER	DATA TYPE	PERSISTENCE	HOW TO CAPTURE
1	CPU registers / cache	Lost instantly on shutdown	Memory dump tools (WinPmem, LiME) — rarely needed
2	RAM / Physical Memory	Lost on shutdown	WinPmem (Windows), LiME kernel module (Linux), RAM dump via hypervisor
3	Network connections	Changes constantly	netstat -an, ss -tulpn, captured immediately
4	Running processes	Changes constantly	tasklist /v, ps aux, process dump with procdump
5	Open files / handles	Changes with processes	handle.exe (Sysinternals), lsof
6	Disk / File system	Persists after shutdown	FTK Imager, dd, dcfldd — bit-for-bit forensic image
7	Logs and event data	Persists (can be deleted)	Export before any remediation activity
8	Backup / archive	Most persistent	Check backup integrity — attackers corrupt backups

// 48.2 — DISK IMAGING

FORENSIC DISK IMAGING — dd, dcfldd, FTK IMAGER

# ── dd: create bit-for-bit forensic image ──────────────────── $ dd if=/dev/sdb of=/mnt/evidence/disk_image.dd bs=4M status=progress # if = input file (source disk), of = output file (image) # bs = block size (4MB is fast), status = show progress # This creates an EXACT copy including deleted files, slack space, unallocated areas # Generate MD5 hash BEFORE and AFTER to prove integrity: $ md5sum /dev/sdb > evidence_hash_original.txt $ md5sum disk_image.dd > evidence_hash_image.txt $ diff evidence_hash_original.txt evidence_hash_image.txt # If hashes match → image is forensically sound (court admissible) # ── dcfldd: dd with hashing built-in ───────────────────────── $ dcfldd if=/dev/sdb of=/mnt/evidence/disk.dd hash=md5 hashlog=/mnt/evidence/hash.log # ── Mount image READ-ONLY for analysis ────────────────────── $ mkdir /mnt/forensic_mount $ mount -o ro,loop disk_image.dd /mnt/forensic_mount # -o ro = read-only (NEVER mount evidence read-write — it alters timestamps) # ── FTK Imager (Windows GUI) ───────────────────────────────── # File → Create Disk Image → Select source → Choose E01 format # E01 (EnCase) format: includes metadata, case info, automatic hash verification # More court-accepted than raw dd images for legal proceedings # ── Key locations to examine in mounted image ───────────────── /mnt/forensic_mount/Windows/System32/winevt/Logs/Security.evtx ← Event logs /mnt/forensic_mount/Users/*/NTUSER.DAT ← User registry hives /mnt/forensic_mount/Windows/Prefetch/*.pf ← Program execution evidence /mnt/forensic_mount/$MFT ← Master File Table (all file metadata) /mnt/forensic_mount/Windows/System32/config/SAM ← Local password hashes

// 48.3 — AUTOPSY: GRAPHICAL FORENSICS

AUTOPSY WORKFLOW

Autopsy (sleuthkit.org) is a free, open-source forensic analysis platform — the same underlying technology used by law enforcement worldwide. It parses disk images and presents an organised view of the file system, deleted files, browser history, email, and timeline.

KEY AUTOPSY MODULES

Timeline Analysis — Visualises file system activity over time. Spikes of activity at 2AM on a server that's normally idle = attacker activity window.
Keyword Search — Search entire disk image for strings: "password", "mimikatz", attacker IP addresses, exfiltrated data samples.
Web Artifacts — Browser history, downloads, cookies, cached pages. Did the attacker research your environment from a compromised workstation?
Recent Activity — Recently accessed files, installed programs, USB device history. Attackers often plug in USB drives for data exfiltration.
Hash Lookup — Compare file hashes against NSRL (National Software Reference Library) to identify known-good files and highlight unknown/malicious ones.
File Carving — Recover deleted files from unallocated disk space. Even after deletion and emptying recycle bin, files often recoverable until overwritten.

// DAY 48 — QUIZ

You're imaging a live Windows server suspected of compromise. The server hosts a critical database that must stay online. You cannot shut it down. Which approach preserves the most evidence while meeting the operational constraint?

A Shut it down to take a clean disk image — live imaging is unreliable

B Copy only the suspicious files you've already identified to save time

C Capture volatile data first (netstat, tasklist), take a live RAM dump with WinPmem, then take a live disk image with FTK Imager Lite — prioritise what will be lost at shutdown

D Wait for the next scheduled maintenance window to take a proper offline image

DIGITAL FORENSICS II + WEEK 7 REVIEW

TOOLLAB Volatility 3 · Memory Analysis · Malware Artifacts · YARA · Capstone

WEEK 7 — COMPLETE ✓

🧠

Memory forensics finds what disk forensics misses. Fileless malware never touches disk. Process injection leaves no file. Encryption keys exist only in RAM. Volatility extracts this from a memory dump — revealing running malicious processes, injected shellcode, network connections, and cryptographic material that disk analysis can never surface.

// 49.1 — VOLATILITY 3 CORE WORKFLOW

VOLATILITY 3 — MEMORY FORENSICS INVESTIGATION

# Install Volatility 3: $ git clone https://github.com/volatilityfoundation/volatility3.git $ pip3 install -r requirements.txt --break-system-packages # Memory dump file: memory.dmp (captured with WinPmem or from VM snapshot) # ── STEP 1: Identify OS (auto-detected in Vol3) ────────────── $ python3 vol.py -f memory.dmp windows.info Kernel Base: 0xf80000000000 Image Type: Service Pack 1 NtSystemRoot: C:\Windows NtProductType: NtProductWinNt # ── STEP 2: List running processes ─────────────────────────── $ python3 vol.py -f memory.dmp windows.pslist PID PPID ImageFileName Offset Threads Handles 4 0 System 0xe00000... 147 2303 624 4 smss.exe 0xe1234... 2 29 888 844 svchost.exe 0xe5678... 12 502 1337 888 powershell.exe 0xf1234... 4 211 ← suspicious parent! 1492 1337 cmd.exe 0xf5678... 1 42 ← svchost spawning powershell spawning cmd # ── STEP 3: Check for hidden processes (rootkit detection) ──── $ python3 vol.py -f memory.dmp windows.psscan # psscan scans raw memory for EPROCESS structures — finds processes # hidden from pslist (rootkit technique: DKOM — Direct Kernel Object Manipulation) # ── STEP 4: Detect process injection (malfind) ─────────────── $ python3 vol.py -f memory.dmp windows.malfind PID: 4892 Name: explorer.exe Address: 0x1e0000 Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE 0x00 4d 5a 90 00 03 00 00 00 MZ...... ← MZ header = PE executable injected into explorer! # MZ header in non-executable memory region = process injection = Meterpreter/shellcode # ── STEP 5: Network connections ────────────────────────────── $ python3 vol.py -f memory.dmp windows.netstat Offset Proto LocalAddr LocalPort ForeignAddr ForeignPort State PID 0xe1234 TCPv4 10.10.10.5 52341 203.0.113.50 443 ESTAB 4892 ← explorer.exe calling home to external IP! # ── STEP 6: Extract injected process for analysis ───────────── $ python3 vol.py -f memory.dmp windows.dumpfiles --pid 4892 --output-dir /tmp/dumps/ $ file /tmp/dumps/*.exe $ strings /tmp/dumps/*.exe | grep -i "http\|192.168\|beacon\|sleep" # C2 indicators # ── DETECT MIMIKATZ ARTIFACTS IN MEMORY ────────────────────── $ python3 vol.py -f memory.dmp windows.strings --pid 1337 | grep -i "sekurlsa\|mimikatz\|wdigest" Found: "sekurlsa::logonpasswords" in PID 1337 memory → Mimikatz was run

// 49.2 — YARA: MALWARE SIGNATURE MATCHING

/* YARA rule to detect Mimikatz strings in memory or files */ rule Mimikatz_Indicators { meta: author = "SOC Team" description = "Detects Mimikatz credential dumper" reference = "https://attack.mitre.org/software/S0002/" strings: $s1 = "sekurlsa::logonpasswords" ascii nocase $s2 = "gentilkiwi" ascii $s3 = "mimikatz" ascii nocase $s4 = "lsadump::dcsync" ascii nocase $hex1 = { 4d 69 6d 69 4b 61 74 7a } /* MimiKatz hex */ condition: any of ($s*) or $hex1 }

YARA — SCAN FILES AND MEMORY

# Install yara: $ apt install yara -y # Scan a single file: $ yara mimikatz.yar suspicious_file.exe Mimikatz_Indicators suspicious_file.exe ← MATCH FOUND # Scan an entire directory recursively: $ yara -r mimikatz.yar /tmp/dumps/ # Scan a memory dump directly: $ yara -r all_rules.yar memory.dmp # Download community YARA rules (thousands of malware families): $ git clone https://github.com/Yara-Rules/rules.git $ yara -r rules/malware/ suspicious_file.exe

// 49.3 — WEEK 7 COMPLETE REVIEW

DAY	SKILL	KEY CAPABILITY	TOOL
43	SIEM Fundamentals	SPL pipelines, log ingestion, dashboards, KQL	Splunk, ELK
44	Log Analysis	9 critical Windows Event IDs, Linux auth log pipelines, lateral movement event chains	Event Viewer, grep/awk
45	Threat Detection	SPL detection for Mimikatz/PtH/Kerberoasting/PowerShell; Sigma rules and conversion	Splunk SPL, Sigma, sigmac
46	IDS/IPS	Snort rule writing, Suricata EVE JSON, tuning for evasion	Snort, Suricata
47	Incident Response	6-phase IR lifecycle, ransomware 15-minute triage, communication chain	IR playbooks, TheHive
48	Digital Forensics I	Order of volatility, dd/FTK Imager, Autopsy, timeline analysis, file carving	FTK Imager, Autopsy, dd
49	Digital Forensics II	Volatility 3 plugins, malfind process injection, YARA rule writing, memory-based IOCs	Volatility 3, YARA

// WEEK 7 — CAPSTONE LABS

LAB 1 — BLUE TEAM LABS ONLINE

blueteamlabs.online — Free platform with scenario-based defensive challenges. Complete "The Report", "Phishing Analysis", and "Malware Analysis" challenges.
TryHackMe: "Splunk: Investigating with Splunk" — investigate a real attack scenario using SPL
TryHackMe: "Windows Event Logs" — identify attacks purely from Windows Event Viewer

LAB 2 — MEMORY FORENSICS CHALLENGE

Download the MemLabs challenges (github.com/stuxnet999/MemLabs) — 6 progressively harder Volatility challenges.
Start with Lab 1: identify the OS, list processes, find the hidden flag in a process's command line arguments.
Write a one-page forensic report for any one challenge: timeline of events, what you found, how you found it.

LAB 3 — PURPLE TEAM: ATTACK THEN DETECT

In your lab: run an nmap scan against Metasploitable. In Splunk/Suricata, write a rule that catches it. Verify your rule fires.
Run Mimikatz sekurlsa::logonpasswords on your Windows lab VM. Check Splunk for the Sysmon Event 10 LSASS access. Does your detection rule catch it?
Create a scheduled task for persistence. Write the 4698 detection query. Verify. Then delete the task and confirm the query no longer fires.
This purple team loop — attack → detect → verify → improve — is the most valuable skill for any security role.

✅

Week 7 Readiness Check: Before Week 8, verify you can: (1) Write an SPL query to detect brute-force and pivot to check if any succeeded. (2) Explain what Windows Event IDs 4625, 4688, 4698, and 4769 indicate and write a detection query for each. (3) Write a Sigma rule for a specific attack technique and convert it to SPL. (4) Walk through the 6-phase IR lifecycle from memory for a ransomware scenario. (5) Take a disk image with dd, verify the hash, and open it in Autopsy. (6) Run at least 3 Volatility plugins against a memory dump and interpret the output.

DETECT.RESPOND.CONTAIN.