eSOC Exam - Guided By RedBlock

eSOC Field Guide — Security Operations Certified, Level 1 (INE)

The complete, example-driven study guide for the INE Security Operations Certified – Level 1 (eSOC) certification — a practical, role-aligned Blue Team credential that validates the foundational skills of a Tier 1 SOC analyst: alert triage, log analysis, SIEM investigation, incident detection and response, case management, threat intelligence, and AI-aware SOC practices. Every concept is paired with concrete examples so you learn how a Security Operations Center (SOC) analyst actually thinks and works.

Keywords & topics covered: SOC analyst training, Tier 1 SOC, blue team, SIEM analysis (Splunk/Elastic/Sentinel), alert triage, incident detection and response, EDR, SOAR, ticketing and case management, threat intelligence, phishing email analysis, malware and command-and-control (C2) detection, data exfiltration, log analysis, MITRE ATT&CK, Cyber Kill Chain, false-positive tuning, escalation-ready documentation, and AI-augmented security operations.

What eSOC validates: operational readiness over theory. You're tested on thinking like a SOC analyst — correlating evidence, validating alerts, prioritizing incidents, and producing escalation-ready documentation. This guide teaches the mindset, the tools, and the repeatable workflows, with worked examples for phishing, endpoint, and network scenarios.

Table of Contents

1. eSOC Overview & Exam Strategy

2. What Is a Security Operations Center (SOC)?

3. SOC Roles, Tiers & Escalation Paths

4. The SOC Analyst Mindset & Daily Workflow

5. Security Foundations Every SOC Analyst Needs

6. Core Frameworks: MITRE ATT&CK, Cyber Kill Chain, NIST & the Pyramid of Pain

7. Logging Fundamentals & Log Sources

8. Windows Logs & Key Event IDs for SOC

9. Linux, Network & Cloud Logs

10. SIEM Fundamentals — How a SIEM Works

11. SIEM Querying & Searching (with examples)

12. Alert Analysis & Alert Quality (true vs false positives)

13. Event Correlation & Investigation Techniques

14. Incident Detection & Classification

15. Triage, Severity & Prioritization

16. The Incident Response Lifecycle (NIST)

17. Tier 1 Response Actions & Playbooks

18. SOC Tool: EDR (Endpoint Detection & Response)

19. SOC Tool: SOAR & Automation

20. SOC Tool: Ticketing & Case Management

21. Data Enrichment, OSINT & Indicator Lookups

22. Writing SOC Tickets & Escalation-Ready Reports

23. Applied Scenario #1 — Phishing Email Analysis

24. Applied Scenario #2 — Endpoint & Malware Investigation

25. Applied Scenario #3 — Network Traffic, C2 & Exfiltration

26. Threat Intelligence for SOC Analysts

27. AI-Augmented SOC Operations (and its limits)

28. Common Incident Types — Quick Reference

29. SOC Metrics & Performance

30. End-to-End Triage Walkthrough (a shift in the life)

31. SIEM Detection Use-Case Library

32. Deep-Dive: Email Header Analysis (annotated example)

33. More Applied Scenarios — Brute Force, Ransomware & Insider Exfil

34. Network Analysis & Packet Inspection Basics

35. Digital Forensics & Evidence Handling Basics

36. Vulnerability & Threat Context for SOC

37. Practice Questions & Scenario Drills (with answers)

38. Exam-Day Tips & Study Plan

39. Glossary & Quick Reference

1. eSOC Overview & Exam Strategy

What it is. The eSOC (Security Operations Certified – Level 1) is a hands-on, scenario-based certification that proves you can do the real work of a Tier 1 SOC analyst. Rather than memorizing definitions, you demonstrate that you can take an alert, investigate it with a SIEM and EDR, decide whether it's a true or false positive, assign severity, respond or escalate, and document it clearly.

The seven exam domains:

Strategy that scores:

• Think, don't memorize. For every alert ask: What triggered this? What does the evidence show? Is it malicious or benign? How bad is it? What do I do, and how do I document it? That loop is the whole job.

• Evidence over assumption. Validate alerts with data (logs, EDR telemetry, enrichment). Never close or escalate on a hunch.

• Know the tools conceptually. SIEM (search/correlate), EDR (endpoint visibility/response), SOAR (automation), ticketing (case management) — understand what each does and when to use it.

• Master the three applied scenarios — phishing, endpoint/malware, and network/C2/exfil (§23–25) — they mirror the exam and real Tier 1 work.

• Communicate clearly. A correct investigation documented badly fails the task. Learn to write a clean, escalation-ready ticket (§22).

2. What Is a Security Operations Center (SOC)?

Definition. A Security Operations Center (SOC) is the team (and the function) responsible for continuously monitoring, detecting, investigating, and responding to cybersecurity threats across an organization. It's the defensive nerve center — the "blue team" operations hub — that watches the environment 24/7, catches malicious activity, and coordinates the response before (or as) damage occurs.

The SOC mission (what it exists to do):

• Monitor — continuously collect and watch security telemetry (logs, alerts, endpoint and network data).

• Detect — identify potential threats and suspicious activity, often via SIEM/EDR alerts.

• Investigate / triage — validate whether an alert is a real threat, understand its scope, and prioritize it.

• Respond — contain and remediate confirmed incidents (or escalate to those who can).

• Report & improve — document everything, communicate to stakeholders, and feed lessons back to strengthen defenses.

Why organizations have a SOC. Attacks are constant and automated; a single missed alert can become a breach. A SOC provides continuous coverage, specialized expertise, consistent processes, and fast response — turning a flood of raw security data into prioritized action. The measure of a good SOC is how quickly it detects (MTTD) and responds to (MTTR) threats (§29).

SOC models (awareness):

• In-house SOC — the organization runs its own team and tools.

• Managed SOC / MSSP (Managed Security Service Provider) — a third party provides SOC services.

• Co-managed / hybrid SOC — shared between in-house staff and a provider.

• Virtual SOC (vSOC) — distributed/remote analysts, often part-time or follow-the-sun.

Key inputs to a SOC: logs from endpoints, servers, network devices, cloud, applications, and identity systems; alerts from SIEM, EDR, IDS/IPS, firewalls, and email security; and external threat intelligence. Key outputs: validated incidents, response actions, escalations, tickets, and reports.

3. SOC Roles, Tiers & Escalation Paths

SOCs are typically organized into tiers, each with a defined scope and an escalation path upward. Knowing where you (Tier 1) sit — and when to escalate — is a core exam objective.

The tiered SOC model:

• Tier 1 — Alert Triage / SOC Analyst (where eSOC places you). The first line. Monitors the alert queue, performs initial triage, validates alerts (true vs false positive), gathers basic evidence, handles routine incidents with playbooks, and escalates anything complex or confirmed-serious to Tier 2. Goal: quickly separate noise from real threats and act or escalate appropriately.

• Tier 2 — Incident Responder / Investigator. Takes escalated alerts, performs deeper investigation, confirms and scopes incidents, performs containment and remediation, and uses advanced tools/forensics.

• Tier 3 — Threat Hunter / Senior Analyst / Subject-Matter Expert. Proactively hunts for threats that evaded detection, handles the most complex incidents, does malware analysis/forensics, and improves detections.

• SOC Manager / Lead. Runs the SOC — people, process, metrics, and coordination with the business.

• Supporting roles: Detection Engineer (builds/tunes detections), Threat Intelligence Analyst (provides intel/context), Incident Response (IR) team (major-incident handling), and SOAR/automation engineer.

Escalation path (the Tier 1 lifeline):

Alert → Tier 1 triage
   ├─ False positive / benign  → document & close (and suggest tuning)
   ├─ True positive, routine    → handle per playbook, document, close
   └─ True positive, complex/serious → ESCALATE to Tier 2 (with a clear, evidence-backed ticket)
Tier 2 → (if major) → Tier 3 / IR team / SOC Manager → (if business-critical) → leadership/legal/comms

When Tier 1 escalates: confirmed malware/compromise, signs of lateral movement or data exfiltration, anything outside your playbook, privileged-account involvement, or high business impact. How to escalate: with a concise, escalation-ready ticket (§22) that states what happened, the evidence, the severity, and what you've already done — so Tier 2 can pick it up without starting over.

4. The SOC Analyst Mindset & Daily Workflow

Being a good SOC analyst is a mindset as much as a skill set: curious, methodical, skeptical, and clear.

The core triage loop (apply to every alert):

1. UNDERSTAND the alert  — what rule/signature fired, on what asset, for which user, when?
2. GATHER context/evidence — pull related logs (SIEM), endpoint telemetry (EDR), enrichment (threat intel)
3. ANALYZE               — does the evidence show malicious activity or benign behavior?
4. DECIDE                — true positive or false positive? what severity?
5. ACT                   — respond (contain/remediate per playbook) OR escalate OR close
6. DOCUMENT              — record findings, actions, and rationale in a clear ticket

Analyst principles:

• Evidence-driven. Conclusions come from data, not guesses. "The alert fired" isn't a finding; "the host made 200 beacon-like connections to a known-malicious IP" is.

• Assume nothing, verify everything. A benign-looking alert can hide a real threat; a scary alert can be a false positive. Investigate before deciding.

• Context is king. The same event (e.g., PowerShell running) is normal for an admin and alarming on a receptionist's laptop at 3 a.m. Always consider who, what, where, when, and normal-for-this-environment.

• Prioritize ruthlessly. You can't chase everything equally — triage by severity and business impact (§15).

• Document as you go. If it isn't written down, it didn't happen. Clear notes enable escalation and future reference.

• Reduce noise. Recognize recurring false positives and recommend tuning so the team isn't drowning in alerts (alert fatigue is real).

• Stay calm and consistent. Follow the process even under pressure; consistency beats heroics.

A realistic Tier 1 shift: monitor the alert queue → pick the highest-priority alert → run the triage loop → close or escalate with a ticket → repeat; alongside, watch dashboards, respond to new detections, and hand off open items at shift change. Continuous monitoring means the SOC never sleeps — hence shift work and follow-the-sun coverage.

5. Security Foundations Every SOC Analyst Needs

You can't analyze threats without the underlying security concepts. These foundations recur throughout the exam and the job.

The CIA triad — the three goals of security:

• Confidentiality — keep data secret from unauthorized parties (encryption, access control). A data leak breaks confidentiality.

• Integrity — keep data accurate and untampered (hashing, signing, change control). Malware modifying files breaks integrity.

• Availability — keep systems and data accessible to authorized users (redundancy, DDoS protection). Ransomware/DoS breaks availability. Every incident maps to one or more of these — framing impact in CIA terms sharpens your analysis.

Threat vs Vulnerability vs Risk (don't confuse these):

• Threat — a potential danger (a hacker, malware, an insider).

• Vulnerability — a weakness that a threat can exploit (an unpatched server, a weak password).

• Risk — the likelihood and impact of a threat exploiting a vulnerability. Risk = Threat × Vulnerability × Impact.

Defense in depth — layered security controls (perimeter, network, endpoint, application, data, identity) so no single failure is catastrophic. The SOC monitors across all layers.

Core attacker concepts:

• TTPs — Tactics, Techniques, and Procedures (how attackers operate — see MITRE ATT&CK, §6).

• IOC (Indicator of Compromise) — evidence an attack occurred (a malicious hash, IP, domain, filename).

• IOA (Indicator of Attack) — evidence of attacker behavior in progress (e.g., credential dumping, lateral movement).

• Attack surface — all the points where an attacker could get in.

• Zero-day — a vulnerability with no patch yet.

Common attack & malware types (you'll triage these): phishing, malware (virus, worm, trojan, ransomware, spyware, rootkit), brute-force/credential stuffing, privilege escalation, lateral movement, command-and-control (C2), data exfiltration, denial of service (DoS/DDoS), insider threat, and supply-chain attacks. §28 is a quick reference.

Networking & identity basics: IP addresses/ports/protocols (TCP/UDP, HTTP/S, DNS, SMB, RDP), the difference between internal and external traffic, and identity concepts (authentication, authorization, accounts, privileges, MFA) — because most investigations revolve around a user or host doing something on the network.

6. Core Frameworks: MITRE ATT&CK, Cyber Kill Chain, NIST & the Pyramid of Pain

Frameworks give analysts a shared language to describe and reason about attacks. The exam expects familiarity with the major ones.

MITRE ATT&CK — the most important for SOC work. A global knowledge base of adversary tactics and techniques based on real-world observations. It's organized as:

• Tactics — the why (the attacker's goal at a stage): Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command & Control, Exfiltration, Impact.

• Techniques / sub-techniques — the how (specific methods), each with an ID (e.g., T1566 Phishing, T1059 Command and Scripting Interpreter, T1003 OS Credential Dumping, T1071 Application Layer Protocol / C2). How SOC analysts use it: map every alert/finding to an ATT&CK technique to describe what the attacker is doing in a standard way, understand what usually comes next, and communicate clearly ("we see T1059.001 PowerShell execution following a T1566 phishing email").

Cyber Kill Chain (Lockheed Martin) — a 7-stage model of an intrusion: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command & Control → Actions on Objectives. Useful for understanding where in the attack you are and that stopping it earlier is cheaper. (ATT&CK is more granular and detection-focused; the Kill Chain is a higher-level narrative.)

NIST frameworks:

• NIST Cybersecurity Framework (CSF) — five functions: Identify, Protect, Detect, Respond, Recover. The SOC lives primarily in Detect and Respond.

• NIST SP 800-61 (Incident Handling Guide) — the incident response lifecycle the SOC follows (§16).

Pyramid of Pain — ranks indicator types by how much it "hurts" the adversary to change them, from easy (bottom) to hard (top): Hash values → IP addresses → Domain names → Network/Host artifacts → Tools → TTPs. The lesson: detecting on behavior (TTPs) is far more durable than blocking a hash, because attackers can trivially change hashes/IPs but not their fundamental techniques.

Why frameworks matter in the exam: they're the vocabulary of professional SOC communication. Mapping findings to ATT&CK techniques and framing incidents in Kill-Chain/NIST terms makes your analysis clear, credible, and escalation-ready.

7. Logging Fundamentals & Log Sources

Logs are the raw material of SOC work — nearly every investigation is reconstructed from logs. Knowing the sources and what each reveals is foundational.

What is a log? A timestamped record of an event — who/what did something, when, where, and the outcome. SOCs centralize logs into a SIEM (§10) so analysts can search and correlate across sources.

Key log sources and what they tell you:

Log quality concepts:

• Log level / verbosity — not everything is logged by default; critical events (e.g., Windows process creation with command line, PowerShell ScriptBlock logging) must be enabled.

• Timestamps & time sync — accurate, synchronized time (UTC/NTP) is essential for correlating events across sources.

• Normalization — the SIEM maps different formats into common fields (e.g., src_ip, user, action) so you can search across sources.

• Retention — how long logs are kept (balancing cost vs investigation/compliance needs).

• Coverage / blind spots — an event you don't log is an attack you can't see. Knowing what you don't collect is part of the job.

The golden rule of log analysis: start from the alert's key fields (host, user, time, IP, hash), then pivot through related logs to build the story — e.g., an EDR alert on a host → pull that host's process logs → the parent process → its network connections → the DNS/firewall logs for those connections.

8. Windows Logs & Key Event IDs for SOC

Windows is the most common enterprise endpoint, so Windows logs dominate SOC investigations. Memorize the high-value Event IDs.

Windows Security log — essential Event IDs:

4624  Successful logon        (check Logon Type: 2=console,3=network,10=RDP,9=runas/alt-creds)
4625  Failed logon            (spikes = brute force / password spraying)
4634 / 4647  Logoff
4672  Special privileges assigned to a logon (admin-level logon)
4688  Process creation        (ENABLE command-line auditing — hugely valuable)
4720  User account created    4722 enabled  4725 disabled  4726 deleted  4738 changed
4728 / 4732 / 4756  Member added to a (global/local/universal) group
4740  Account lockout
4698  Scheduled task created   4697 service installed (Security)
7045  Service installed (System log)
1102  Security log cleared   (!! strong anti-forensics indicator)
4104  PowerShell ScriptBlock logging (captures script content)
4768  Kerberos TGT request   4769 Kerberos service ticket   4776 NTLM authentication

Logon Types (the number in 4624/4625) — critical for interpreting logons:

2  Interactive (at the console)      10 RemoteInteractive (RDP)
3  Network (SMB/share/remote access) 9  NewCredentials (runas /netonly — often used in credential attacks)
4  Batch (scheduled task)            5  Service          7  Unlock

Sysmon (System Monitor) — a free Microsoft tool many SOCs deploy for much richer endpoint telemetry than default logging:

1  Process create (image, command line, parent, hashes, user) — the single most useful event
3  Network connection    7 Image/DLL load    8 CreateRemoteThread (injection)
10 Process access (handle to lsass.exe = credential-dumping tell)
11 File create    12/13/14 Registry    22 DNS query    19/20/21 WMI persistence

Example — reading a brute-force pattern: dozens of 4625 (failed logon) events for one account from one source IP in a short window, followed by a single 4624 (success) = likely successful brute force → investigate what that account did next. Example — reading suspicious execution: a 4688/Sysmon-1 showing winword.exe spawning powershell.exe -enc <base64> = Office spawning an encoded PowerShell = classic phishing-payload execution (ATT&CK T1566→T1059.001) → high priority.

9. Linux, Network & Cloud Logs

SOC analysts work across platforms. Beyond Windows, know the key Linux, network, and cloud log sources.

Linux logs:

/var/log/auth.log  (Debian) or /var/log/secure (RHEL)  — SSH/sudo/su authentication
/var/log/syslog, /var/log/messages                     — general system events
auditd (/var/log/audit/audit.log)                       — syscalls: execve, file access, user changes
/var/log/<service>                                       — web (nginx/apache), app logs
bash history (~/.bash_history)                           — commands run (often cleared by attackers)
journalctl                                               — systemd journal

Example Linux hunts/reads: repeated Failed password in auth.log from one IP = SSH brute force; a successful Accepted password/Accepted publickey after many failures = possible compromise; sudo to root followed by downloads (curl/wget) and chmod +x = suspicious.

Network logs & telemetry:

• Firewall — allowed/blocked connections (source/dest IP, port) — spot blocked exfil, scanning, or allowed connections to bad IPs.

• Proxy / web gateway — outbound web requests (URLs, user-agents) — spot malware downloads, C2 over HTTP, data upload.

• DNS — domain lookups — spot C2 domains, DGA (random-looking domains), DNS tunneling (long/odd queries).

• IDS/IPS (Snort/Suricata) — signature alerts on known-bad traffic patterns.

• NetFlow / Zeek — connection metadata (who talked to whom, how much data) — spot beaconing (regular connections) and large outbound transfers (exfil).

Cloud logs:

AWS CloudTrail        — API/control-plane actions (who created/deleted/changed what)
Azure Activity Log + Entra ID Sign-in/Audit logs — resource ops + identity events
Google Cloud Audit Logs — admin/data-access activity

Example cloud reads: a sign-in from an unusual country then a privileged action; a new access key created then used to access storage; StopLogging/DeleteTrail (disabling audit logs — the cloud equivalent of clearing event logs).

The cross-platform skill: regardless of source, you're always asking the same questions — who (user/IP), what (action/process), where (host/resource), when (timestamp), and is this normal? — then pivoting across sources to build the timeline.

10. SIEM Fundamentals — How a SIEM Works

The SIEM (Security Information and Event Management) is the SOC analyst's primary workstation — where logs land, alerts fire, and investigations happen.

What a SIEM does:

1. Collects logs from many sources (endpoints, network, cloud, apps, identity) via agents/forwarders/APIs.

2. Normalizes & parses them into common fields so you can search across sources (e.g., every source's "user" maps to one user field).

3. Correlates events with rules — combining multiple events into a meaningful detection (e.g., 10 failed logons then a success then a new admin group membership = "possible account compromise").

4. Alerts when a rule or anomaly matches, placing an item in the analyst queue.

5. Enables investigation — search, pivot, dashboards, and visualizations over all collected data.

6. Supports reporting & compliance — dashboards, metrics, and retained logs for audits.

Common SIEM platforms (know the names): Splunk, Microsoft Sentinel (cloud-native, uses KQL), Elastic Security (ELK), IBM QRadar, Exabeam, Securonix, Google Chronicle. They differ in query language and UI but share the collect→normalize→correlate→alert→investigate model.

Key SIEM concepts:

• Data source / index — where a type of log is stored.

• Parsing / field extraction — turning raw log text into searchable fields.

• Correlation rule / analytic — logic that generates an alert from one or more events.

• Dashboard — visual summary of activity/health.

• Use case — a specific detection scenario the SIEM is tuned to catch (e.g., "impossible travel login").

• Alert tuning — adjusting rules to reduce false positives (§12).

• UEBA (User and Entity Behavior Analytics) — baselining normal behavior to flag anomalies.

Why it matters: the SIEM is where Tier 1 lives. Your job is to work the alert queue it produces — validating each alert with searches and pivots — and to recognize when rules are noisy and need tuning. Understanding how the SIEM correlates and alerts helps you interpret why an alert fired and whether it's trustworthy.

11. SIEM Querying & Searching (with examples)

You investigate by querying the SIEM. You don't need to be a query-language expert for eSOC, but you must read and write basic searches and understand the logic. Examples below use Splunk SPL (the most common) with KQL (Sentinel) equivalents noted — the concepts transfer to any SIEM.

The anatomy of a search: filter to the relevant data → narrow by conditions → select/aggregate the fields you need → sort/visualize.

Core Splunk SPL patterns (with what each does):

index=windows EventCode=4625                         # all failed logons
| stats count by Account_Name, Source_Network_Address # count failures per user/IP
| sort -count                                         # worst offenders first

# brute force then success (correlation idea)
index=windows (EventCode=4625 OR EventCode=4624) Account_Name="jdoe"
| sort _time | table _time EventCode Source_Network_Address Logon_Type

# suspicious process execution
index=edr EventCode=1 ParentImage="*winword.exe" Image="*powershell.exe"
| table _time host User CommandLine ParentImage

# beaconing / connections to a suspicious IP
index=network dest_ip="203.0.113.45"
| stats count by src_ip dest_port | sort -count

# readable timeline + unique values
... | eval t=strftime(_time,"%F %T") | sort _time | table t host user CommandLine
... | stats values(dest_ip) dc(dest_ip) by src_ip         # distinct destinations per host

KQL (Microsoft Sentinel) equivalents — same ideas:

SecurityEvent | where EventID == 4625
| summarize count() by Account, IpAddress | sort by count_ desc
DeviceProcessEvents
| where InitiatingProcessFileName == "winword.exe" and FileName == "powershell.exe"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine

Query skills every analyst needs:

• Filter precisely — start narrow (host/user/time/IP from the alert) to cut noise.

• Aggregate — stats count by ... / summarize count() by ... to spot patterns (top talkers, failure counts).

• Pivot — take a value from one result (an IP, a hash, a user) and search for it across other data sources.

• Time-bound — always scope to a relevant time window; sort chronologically to build a timeline.

• Deduplicate / distinct — dedup / distinct / dc() to find unique values (e.g., unique destinations = possible scanning or beaconing).

Example investigation flow with queries: an EDR alert says powershell.exe on WKS-07 ran an encoded command.

1. index=edr host=WKS-07 EventCode=1 | sort _time → see the full process tree (what spawned PowerShell, what PowerShell spawned).

2. Decode the base64 command (§21) → it downloads from http://bad.tld/x.

3. index=network host=WKS-07 dest_domain="bad.tld" → confirm the connection and find the C2 IP.

4. index=dns host=WKS-07 query="*bad.tld*" → confirm the lookup and timing.

5. Build the timeline, assign severity, and escalate or respond. The query is just the tool; the pivoting and the story are the skill.

12. Alert Analysis & Alert Quality (true vs false positives)

The heart of Tier 1 work is deciding whether an alert represents a real threat. This is where analysts spend most of their time.

The four outcomes of an alert (the confusion matrix):

• True Positive (TP) — the alert correctly identified real malicious/suspicious activity. Action: respond or escalate.

• False Positive (FP) — the alert fired, but the activity is benign. Action: close with rationale; recommend tuning if recurring.

• True Negative (TN) — no alert, no threat (the normal, silent majority).

• False Negative (FN) — a real threat that no alert caught — the most dangerous, because it's invisible. (Threat hunting, §3, exists to find these.)

How to validate an alert (true vs false positive):

1. Read the alert fully — what rule fired, on what host/user, when, and why (the matched condition).

2. Gather context — is this host/user known? Is the activity expected (an admin running a script vs a user)? Was there a change window / ticket?

3. Pull supporting evidence — SIEM logs around the event, EDR process tree, the involved IP/domain/hash.

4. Enrich the indicators — reputation of the IP/domain/hash (§21): known-bad, known-good, or unknown.

5. Compare to baseline — is this normal for this environment, this user, this time of day?

6. Decide — malicious (TP), benign (FP), or needs-escalation-to-confirm.

Example — likely false positive: an alert for "PowerShell execution" on an IT admin's workstation during business hours, running a known internal management script from a signed path. Context + baseline = benign. Document as FP; recommend excluding that script/path. Example — likely true positive: the same "PowerShell execution" on a finance user's laptop at 2 a.m., with an encoded command that downloads from an unknown external domain. Context + enrichment = malicious. Escalate.

Alert quality & alert fatigue:

• Alert fatigue — too many alerts (especially FPs) overwhelm analysts, causing real threats to be missed. A top operational risk.

• Tuning — refining detection rules to reduce FPs (adding exclusions for known-good behavior) and improve fidelity. Tier 1 analysts spot noisy rules and recommend tuning (Tier 2/detection engineers implement it).

• Alert fidelity / signal-to-noise — a good detection has high true-positive rate and low false-positive rate. Part of your value is improving this over time by feeding back patterns.

• Allow-listing / exceptions — documenting known-good behavior so it stops alerting (carefully — over-exclusion creates blind spots).

The mindset: treat every alert as "guilty until proven innocent" and "innocent until proven guilty" simultaneously — i.e., investigate thoroughly, but let the evidence (not the alert's scary name) decide. Never close an alert without understanding why it fired and whether the activity is benign.

13. Event Correlation & Investigation Techniques

Single events rarely tell the whole story. Correlation — connecting related events across time and sources — is how analysts reconstruct what actually happened.

What correlation means: linking multiple events that share a common thread (a host, a user, an IP, a time window, a process) into a single coherent picture. The SIEM does automated correlation (rules), and the analyst does manual correlation (pivoting) during investigation.

Pivot points (the shared values you follow across data sources):

HOST/asset   → all activity on that machine (processes, logons, network)
USER/account → everything that account did, everywhere
IP address   → who connected to/from it (internal and external)
DOMAIN/URL   → who looked it up / connected to it (DNS, proxy)
FILE HASH    → where that file appeared across the fleet
PROCESS (PID/GUID) → parent and child processes, its network connections
TIME window  → everything that happened around the event

The investigation method (build the timeline):

1. Start at the alert — note its key fields (anchor values).

2. Pivot outward — for each anchor, search other sources (e.g., alert host → its process tree → the parent process → its network connections → the DNS/firewall logs for those connections → the reputation of the destinations).

3. Walk the attack chain — map events to MITRE ATT&CK stages: how did it start (initial access)? what ran (execution)? did it persist, escalate, move laterally, or exfiltrate?

4. Establish scope — one host or many? one account or several? how far did it get?

5. Build a chronological timeline — time · host · user · action · evidence · ATT&CK technique. This timeline is your investigation output.

Example correlation (phishing → execution → C2):

09:02  email gateway: user receives email with link (phishing verdict: suspicious)
09:05  proxy: user's host visits hxxp://bad.tld/login  (clicked the link)
09:06  EDR(Sysmon 1): winword.exe -> powershell.exe -enc ...  (payload executed)
09:07  DNS: host queries c2-domain.tld
09:07+ firewall: host beacons to 203.0.113.45:443 every 60s  (C2)

Each log is one piece; correlated, they tell the story: phishing (T1566) → user-execution (T1204/T1059) → C2 (T1071). That chain is what you escalate.

Correlation pitfalls: don't assume causation from coincidence (two events close in time aren't always related — verify the link via a shared anchor); watch for clock skew between sources (sync on reliable timestamps); and beware tunnel vision (confirm your hypothesis against the evidence, and consider benign explanations).

14. Incident Detection & Classification

Once you confirm an alert is a true positive, you classify it — what kind of incident is it? Classification drives the playbook, severity, and response.

What is a security incident? An event (or series of events) that violates security policy or threatens the confidentiality, integrity, or availability of systems/data. Not every alert is an incident — triage decides.

Common incident categories (classify the alert):

• Phishing / social engineering — malicious emails/messages aiming to steal credentials or deliver malware.

• Malware infection — virus, worm, trojan, ransomware, spyware, etc., on an endpoint.

• Unauthorized access / account compromise — stolen/brute-forced credentials; logins from unusual locations.

• Privilege escalation — a user/process gaining higher rights than authorized.

• Lateral movement — an attacker spreading from one host to others.

• Command & Control (C2) — compromised host communicating with attacker infrastructure.

• Data exfiltration / data breach — sensitive data leaving the environment.

• Denial of Service (DoS/DDoS) — attempts to make systems unavailable.

• Insider threat — malicious or negligent authorized user.

• Policy violation — risky but not necessarily malicious (e.g., unauthorized software).

• Reconnaissance / scanning — attacker probing the environment.

Classification helps you: pick the right playbook (§17), estimate severity/impact, communicate clearly ("this is a confirmed malware incident on one endpoint"), and map to MITRE ATT&CK.

Detection sources that create alerts to classify: SIEM correlation rules, EDR detections, IDS/IPS signatures, email security verdicts, firewall/proxy blocks, threat-intel matches, and user reports (e.g., "I think I got phished"). User-reported phishing is one of the most common and valuable Tier 1 inputs.

Example classification: an EDR alert shows a host encrypting files rapidly and dropping ransom notes → classify as ransomware (malware → impact) → invoke the ransomware playbook → high/critical severity → immediate containment + escalation.

15. Triage, Severity & Prioritization

You can't treat every alert equally. Triage is rapidly assessing and prioritizing alerts so the most dangerous get attention first — a defining Tier 1 skill.

Triage = quick assessment + prioritization. For each alert, rapidly determine: Is it real? How bad is it? How urgent? What's next?

Assigning severity (impact × urgency): most SOCs use levels like Critical / High / Medium / Low / Informational. Severity is driven by:

• Asset criticality — a domain controller, finance server, or executive's laptop > a test VM.

• Scope — one host vs many; one account vs the domain.

• Stage of attack — early recon < active C2 < data exfiltration < ransomware encryption. (Later Kill-Chain stages = higher severity.)

• Data sensitivity — is regulated/confidential data involved?

• Confidence — how certain is it a true positive?

• Business impact — does it threaten operations, revenue, or reputation?

A simple severity guide:

CRITICAL  active, widespread, high-impact (ransomware spreading, confirmed data exfil, DC compromise)
HIGH      confirmed compromise on an important asset; active C2; privileged account involved
MEDIUM    suspicious activity needing investigation; single non-critical host; contained
LOW       minor/benign-leaning or policy issues; low impact
INFO      no action needed; noted for awareness

Prioritization in practice: work highest severity first; within the same severity, favor active/ongoing over historical, critical assets over low-value, and higher-confidence true positives. Don't let a flood of low alerts bury a single critical one — that's exactly the failure alert-fatigue causes.

The triage decision tree (Tier 1):

Alert → Is it a true positive?  ── No → document FP, close (suggest tuning)
            │ Yes
            ▼
     What's the severity/impact?
            │
   ┌────────┼─────────────────────────────┐
 Low/Med routine                  High/Critical or complex
   │                                      │
 handle per playbook,            ESCALATE to Tier 2 with an
 document, close                 evidence-backed ticket (and
                                 contain if the playbook allows)

Example triage: two alerts arrive — (A) a single failed login on a test server, (B) ransomware notes appearing on a file server. B is Critical (active, high-impact, critical asset) → handle immediately; A is Low → queue it. Prioritization is about impact and urgency, not arrival order.

16. The Incident Response Lifecycle (NIST)

When an alert becomes a confirmed incident, the SOC follows a structured incident response (IR) lifecycle. The NIST SP 800-61 model is the standard — know its phases and where Tier 1 contributes.

The NIST IR lifecycle:

1. Preparation — before incidents: tools, playbooks, training, logging, access, and contacts are ready. (Ongoing; not during an incident.)

2. Detection & Analysis — identify that an incident is occurring and understand it. This is where Tier 1 lives — detecting via alerts, triaging, validating, classifying, scoping, and documenting.

3. Containment — stop the incident from spreading/worsening. Short-term (isolate the host, block the IP, disable the account) and long-term (temporary fixes while preparing eradication). Tier 1 often performs initial containment per playbook (e.g., isolate an endpoint via EDR).

4. Eradication — remove the threat (delete malware, close the vulnerability, remove persistence, reset credentials). Usually Tier 2/IR.

5. Recovery — restore systems to normal and verify they're clean; monitor for recurrence. Usually Tier 2/IR + IT.

6. Post-Incident Activity ("Lessons Learned") — review what happened, what worked, and how to improve detections/processes. Feeds back into Preparation.

(Some models combine these as Prepare → Detect & Analyze → Contain, Eradicate & Recover → Post-Incident. The SANS 6-step PICERL is similar: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned.)

Where Tier 1 fits: primarily Detection & Analysis (triage, validate, classify, document, escalate) and initial Containment when the playbook authorizes it (e.g., isolate host, disable account, block indicator). Deeper eradication and recovery are typically Tier 2/IR — but Tier 1's clean documentation and timely escalation make the whole lifecycle work.

Containment decisions (a Tier 1 judgment call): containment stops damage but can tip off the attacker or disrupt business. Follow the playbook; when in doubt on a significant action (e.g., isolating a production server), confirm with Tier 2/lead. Speed matters — the faster you detect and contain, the less damage (lower MTTD/MTTR).

Example lifecycle (malware on one endpoint): detect (EDR alert) → analyze (confirm malicious, scope to one host) → contain (isolate the host via EDR, disable the user if credentials were exposed) → escalate to Tier 2 for eradication (remove malware/persistence, reset creds) → recovery (reimage/restore, verify clean) → lessons learned (why did it get in? improve the detection/user training). Tier 1 owns the first two phases and the hand-off.

17. Tier 1 Response Actions & Playbooks

Tier 1 doesn't improvise — it follows playbooks (also called runbooks or standard operating procedures). Knowing how to execute a playbook is a core exam objective.

What is a playbook? A documented, step-by-step procedure for handling a specific alert or incident type (e.g., "phishing email reported," "malware detected on endpoint," "brute-force login," "suspicious outbound connection"). Playbooks ensure consistency, speed, and completeness regardless of which analyst handles the alert.

A typical playbook structure:

1. Trigger / scope       — what alert/condition invokes this playbook
2. Initial validation    — how to confirm true vs false positive (what to check)
3. Investigation steps   — specific queries/enrichment/evidence to gather
4. Severity guidance     — how to classify impact
5. Response actions      — what Tier 1 may do (contain/block/disable) and what to escalate
6. Escalation criteria   — when and to whom to escalate
7. Documentation         — what to record in the ticket

Common Tier 1 response actions (what you're authorized to do):

• Isolate/quarantine an endpoint (via EDR) — cut it off the network to contain malware while keeping it for investigation.

• Block an indicator — add a malicious IP/domain/hash to firewall/proxy/EDR block lists.

• Disable/lock a user account — stop a compromised account from being used; force a password reset.

• Quarantine/delete a malicious email — remove a phishing message from mailboxes (via the email security tool).

• Kill a malicious process / quarantine a file (via EDR).

• Reset credentials — for compromised accounts (often coordinated with IT).

• Collect evidence — preserve logs, screenshots, and artifacts for the ticket/escalation.

• Escalate — hand off to Tier 2 with full documentation when beyond Tier 1 scope.

Example playbook — "Phishing email reported by user":

1. Confirm the report; obtain the email (headers, body, links, attachments).
2. Analyze: sender/SPF-DKIM-DMARC, reply-to, display-name spoofing, link destinations, attachment hashes.
3. Enrich: reputation of sender domain, URLs, and attachment hashes (VirusTotal/threat intel).
4. Determine: is it malicious? did the user click/enter credentials/open the attachment?
5. If malicious: quarantine the email from all mailboxes; block the sender/domain/URL; if the user
   interacted, isolate their host and/or reset their credentials.
6. Scope: who else received it? did anyone else click?
7. Document everything; escalate if there's evidence of compromise.

Example playbook — "Malware detected on endpoint":

1. Validate the EDR detection (file/process, hash, path, user).  2. Enrich the hash/indicators.
3. Review the process tree and network connections.  4. If confirmed: isolate the host (EDR),
   block indicators, preserve evidence.  5. Scope: did it spread? credential theft? persistence?
6. Escalate to Tier 2 for eradication/recovery.  7. Document.

Why playbooks matter for the exam: eSOC explicitly tests executing appropriate Tier 1 response actions using documented playbooks. Know the common playbooks, what actions Tier 1 is authorized to take, and — critically — when to escalate rather than act alone.

18. SOC Tool: EDR (Endpoint Detection & Response)

EDR (Endpoint Detection and Response) is, after the SIEM, the SOC analyst's most important tool — deep visibility into and control over endpoints (laptops, servers).

What EDR does:

• Detects threats on endpoints using behavioral analytics, signatures, and ML (process injection, credential dumping, ransomware behavior, etc.).

• Provides rich telemetry — detailed process execution (with command lines, parents, hashes), file/registry changes, network connections, and loaded modules — far beyond default OS logging.

• Enables investigation — view the full process tree, timeline, and activity on a host; see exactly what a suspicious process did.

• Enables response — remotely isolate (quarantine) the host, kill processes, delete/quarantine files, collect artifacts, and sometimes run remediation — all from the console.

Common EDR platforms (names to know): CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Carbon Black, Cortex XDR, Elastic Endpoint. XDR (Extended Detection and Response) extends EDR's correlation across endpoints, network, email, and cloud.

How Tier 1 uses EDR:

1. An EDR alert fires (e.g., "credential dumping detected on WKS-07").

2. Open the detection → review the process tree: what ran, its command line, its parent, its hashes.

3. Check the host's network connections and file activity around the event.

4. Enrich the file hash and any IPs/domains (§21).

5. Decide TP/FP and severity; if malicious, isolate the host and preserve evidence.

6. Escalate with the EDR evidence attached to the ticket.

Example EDR investigation: an alert flags rundll32.exe making an external network connection — unusual. The process tree shows winword.exe → rundll32.exe with a suspicious command line, and the network tab shows a connection to a flagged IP. Hash enrichment returns "malicious." Conclusion: malware delivered via a document, now attempting C2 → isolate the host, block the IP, escalate. EDR gave you the process lineage, the network activity, and the one-click containment.

Key EDR concepts: endpoint agent (installed on each host), detection (the alert), process tree/lineage (parent-child relationships — the story of what happened), isolation/containment (network-quarantine the host), and IOC search / sweeping (search the whole fleet for a hash/indicator to find other infected hosts).

19. SOC Tool: SOAR & Automation

SOAR (Security Orchestration, Automation, and Response) helps SOCs handle alert volume by automating repetitive tasks and orchestrating actions across tools.

What SOAR does:

• Orchestration — connects and coordinates the SOC's tools (SIEM, EDR, email security, threat intel, ticketing, firewall) so they work together.

• Automation — runs repetitive steps automatically (enrich an IP/hash, pull related logs, create a ticket, send a notification) without manual effort.

• Response — executes response playbooks automatically or semi-automatically (e.g., auto-isolate a host, auto-block an indicator, auto-disable an account — often with a human approval step).

• Playbook execution — codifies the manual playbooks (§17) into automated/semi-automated workflows.

Why it matters: SOCs face far more alerts than analysts can manually handle. SOAR reduces repetitive work, speeds response (lower MTTR), and ensures consistency — freeing analysts to focus on judgment-heavy investigation. It directly fights alert fatigue.

Common SOAR platforms: Palo Alto Cortex XSOAR, Splunk SOAR (Phantom), Microsoft Sentinel (built-in SOAR/playbooks via Logic Apps), Google Chronicle SOAR (Siemplify), Tines, Swimlane.

Examples of SOAR automation:

Phishing playbook (automated enrichment):
  alert/report → extract indicators (sender, URLs, hashes) → auto-enrich (VirusTotal, threat intel,
  URL sandbox) → auto-create ticket with results → if malicious, auto-quarantine the email and
  present the analyst a one-click "block + isolate" action.

Suspicious login:
  alert → auto-pull the user's recent logins and geo → auto-enrich the source IP → if impossible
  travel + bad IP, auto-disable the account (with approval) and open a case.

How Tier 1 interacts with SOAR: you'll often receive enriched alerts (SOAR already attached the IP reputation, the related logs, the hash verdict) and be presented with suggested/automated actions to approve. Understand that SOAR does the busywork, but the analyst still provides judgment — reviewing the automated findings and approving consequential actions. Automation accelerates the human; it doesn't replace the decision.

20. SOC Tool: Ticketing & Case Management

Every alert and incident is tracked in a ticketing / case management system — the SOC's system of record. Good case management is what makes a SOC auditable, consistent, and able to hand work off.

What ticketing/case management provides:

• A record of every alert/incident — what it was, who worked it, what was found, what was done, and the outcome.

• Workflow & ownership — assignment, status (new/in-progress/escalated/closed), and SLAs (time targets).

• Collaboration & hand-off — Tier 1 → Tier 2 escalation with full context; shift hand-offs.

• Metrics — data for MTTD/MTTR, alert volumes, FP rates, and SLA compliance (§29).

• Audit & compliance — evidence that incidents were handled properly.

Common platforms: ServiceNow (SecOps), Jira, TheHive (open-source case management), Cortex XSOAR cases, Microsoft Sentinel incidents, Splunk Mission Control, PagerDuty (for on-call/alerting).

The ticket lifecycle (Tier 1 view):

New alert → ticket created (often auto) → assigned/picked up → investigate (triage loop) →
  → FP: document & close   |   TP routine: respond, document & close   |   TP serious: escalate (status=escalated)

Key case-management concepts:

• Ticket / case / incident — the unit of tracked work.

• Severity & priority — set during triage (§15); drives SLAs.

• SLA (Service Level Agreement) — time targets (e.g., "critical alerts triaged within 15 minutes").

• Status & ownership — always clear who holds the ticket and its state.

• Linking / correlation — related tickets grouped into one case (e.g., 10 alerts = 1 incident).

• Evidence attachment — logs, screenshots, enrichment results, timeline attached to the ticket.

Why it matters for the exam: eSOC explicitly tests creating accurate SOC tickets and documenting investigations clearly. A ticket is both your work product and the hand-off to the next person — the quality of your ticket determines whether Tier 2 can act fast or has to redo your work. §22 covers how to write one well.

21. Data Enrichment, OSINT & Indicator Lookups

Enrichment means adding context to the indicators in an alert — turning a bare IP/domain/hash into a verdict. It's how you tell "known-bad" from "known-good" from "unknown," and it's central to validating alerts.

What you enrich (the common indicators):

• IP addresses — reputation, geolocation, owning organization (ASN), is it a known C2/scanner/Tor node?, is it internal or external?

• Domains / URLs — reputation, age (newly-registered domains are suspicious), category, is it known-malicious/phishing?, where does it resolve?

• File hashes (MD5/SHA256) — is this file known-malicious, known-good, or unknown? (A hash is a unique fingerprint of a file.)

• Email addresses / sender domains — reputation, spoofing, prior abuse.

Enrichment tools & sources (OSINT and commercial):

VirusTotal        — multi-engine verdicts for files/hashes, URLs, domains, IPs (the SOC staple)
AbuseIPDB         — IP reputation / abuse reports
URLScan.io        — safely inspect what a URL does (screenshots, resources, redirects)
Any.Run / Hybrid Analysis — sandbox: detonate a file/URL and observe behavior
Shodan / Censys   — internet-exposure info about an IP/host
WHOIS / DomainTools — domain registration age/owner (new domains = suspicious)
MITRE ATT&CK      — map observed behavior to techniques
Threat intel feeds / TIP — curated IOC and actor context (§26)
MXToolbox / mail header analyzers — email authentication (SPF/DKIM/DMARC)

How enrichment changes a verdict (examples):

Alert: outbound connection to 203.0.113.45
  → AbuseIPDB: 100% abuse confidence, reported as C2  → verdict shifts to MALICIOUS → escalate
Alert: user downloaded file hash abc123...
  → VirusTotal: 58/70 engines flag it as a trojan  → MALICIOUS → isolate host
Alert: email link to login-microsoft-secure[.]tld
  → WHOIS: domain registered 2 days ago; URLScan: clones the M365 login page  → PHISHING → quarantine

Safe-handling rules (important): never click suspicious links or open attachments on your own machine. Analyze them safely — use URL scanners, sandboxes, and defanged indicators (write malicious URLs/IPs "defanged," e.g., hxxp://bad[.]tld, 203.0.113[.]45, so no one accidentally clicks them). Detonate samples only in isolated sandboxes.

Decoding encoded data (a frequent task): attackers hide commands/URLs in Base64 or hex. Decode safely to reveal intent:

echo "aHR0cDovL2JhZC50bGQvcGF5bG9hZA==" | base64 -d   →  http://bad.tld/payload

Why enrichment matters: it's often the deciding factor between TP and FP. An unknown IP is just noise until reputation data says "known C2." eSOC tests your ability to enrich data and integrate findings into the investigation — so build the habit: for every suspicious indicator, enrich before you conclude.

22. Writing SOC Tickets & Escalation-Ready Reports

Your investigation is only as good as your ability to communicate it. A clear, complete ticket is what lets the next analyst act — and it's a graded eSOC skill. A brilliant investigation documented poorly fails the task.

What makes a good SOC ticket: it answers what happened, what you found, how bad it is, what you did, and what's next — clearly enough that someone with no prior context can understand and act.

Ticket / escalation report structure:

Title            — concise and specific: "Confirmed phishing → PowerShell C2 on WKS-07 (user: jdoe)"
Severity         — Critical/High/Medium/Low (with one-line justification)
Status           — e.g., Escalated to Tier 2 / Contained / Closed-FP
Summary          — 2-3 sentences: what happened, in plain language
Affected assets  — hosts, users, accounts, IPs involved
Timeline         — chronological: time · event · evidence (the backbone)
Evidence / IOCs  — key log excerpts, hashes, IPs, domains (defanged), screenshots
Analysis         — what the evidence shows and the ATT&CK mapping
Actions taken    — what you did (isolated host, blocked IP, disabled account…)
Recommendation / Next steps — what Tier 2 should do; tuning suggestions; open questions

Example escalation ticket:

Title:    Confirmed malware + C2 on WKS-07 (user: jdoe) — ESCALATION
Severity: High — confirmed compromise, active C2, standard-user endpoint (no lateral movement seen yet)
Status:   Escalated to Tier 2; host ISOLATED via EDR
Summary:  jdoe opened a phishing attachment at 09:06; Word spawned encoded PowerShell that downloaded
          a payload now beaconing to a known-malicious IP. Host isolated; indicators blocked.
Timeline:
  09:02  Email with malicious .docm delivered (gateway verdict: suspicious)
  09:06  Sysmon 1: winword.exe -> powershell.exe -enc <b64>  (decoded: downloads hxxp://bad[.]tld/p)
  09:07  DNS: query c2-domain[.]tld ; firewall: beacons to 203.0.113[.]45:443 every ~60s
  09:20  EDR: host WKS-07 isolated; IP/domain/hash added to block lists
IOCs:     SHA256 abc123…(VT 58/70 trojan); 203.0.113[.]45 (AbuseIPDB C2); c2-domain[.]tld (3-day-old)
Analysis: Phishing (T1566) → user execution + PowerShell (T1204/T1059.001) → C2 (T1071). No lateral
          movement or exfil observed in logs so far; jdoe is a standard user (no admin rights).
Actions:  Host isolated; IOCs blocked; jdoe password reset requested; email quarantined fleet-wide.
Next:     Tier 2 to confirm eradication (remove persistence, verify clean), check for lateral movement
          and data access, and determine reimage vs clean. Recommend user phishing re-training.

Communication principles:

• Be clear and factual — state what the evidence shows, not speculation; separate facts from analysis.

• Lead with the bottom line — severity and summary up top, so a busy reader gets it in seconds.

• Be complete but concise — include everything needed to act, nothing that just pads.

• Defang indicators — so no one accidentally clicks/executes.

• Write for the audience — technical detail for Tier 2; a plain-language summary for managers/non-technical stakeholders.

• Reproducibility — enough detail (queries, timestamps, sources) that someone could verify your findings.

Why it's graded: eSOC explicitly tests accurate tickets, clear documentation, effective communication, and escalation-ready reports. The ticket is the SOC's product. Practice writing them until the structure is automatic.

23. Applied Scenario #1 — Phishing Email Analysis

Phishing is the #1 initial-access vector and the most common Tier 1 workload. The exam tests analyzing phishing emails end to end. Here's the full method with an example.

Why phishing matters: most breaches start with a phishing email — credential theft (fake login pages) or malware delivery (malicious attachments/links). Fast, accurate phishing triage stops attacks at the door.

What to analyze in a reported/suspicious email:

1. Email headers (the metadata — don't trust the display):

   • From / Return-Path / Reply-To — do they match? A mismatch (display "IT Support [email protected]" but reply-to goes to [email protected]) is a red flag.

   • Authentication results — SPF, DKIM, DMARC: did the sending server pass these checks? SPF fail / DKIM fail / DMARC fail suggests spoofing. (SPF = is the sender authorized for the domain; DKIM = cryptographic signature; DMARC = policy combining both.)

   • Received headers — the path the email took; the originating IP (enrich it).

   • Display-name spoofing — a trusted name with an untrusted address.

2. Sender reputation — is the sending domain known-bad? Newly registered? Look-alike (typosquat, e.g., micros0ft.com, company-support.tld)?

3. Subject & body (social-engineering cues): urgency ("your account will be closed!"), authority (pretending to be IT/CEO/bank), fear, reward, generic greetings, spelling/grammar errors, requests for credentials/payment/gift cards.

4. Links / URLs: hover (don't click) to see the real destination; is it a look-alike login page? a URL shortener? Enrich with URLScan/VirusTotal; check domain age (WHOIS). Defang before sharing (hxxps://bad[.]tld).

5. Attachments: file type (macro-enabled Office .docm/.xlsm, .zip, .iso, .lnk, .html, .exe), hash it and check VirusTotal, or detonate in a sandbox (Any.Run/Hybrid Analysis). Never open on your own machine.

The phishing triage workflow (example):

Report:  user forwards "Microsoft 365 — unusual sign-in, verify now" email.
1. Headers: From "Microsoft Account Team <[email protected]>" but Return-Path/Reply-To =
   account-verify@secure-ms-login[.]tld ; SPF=fail, DMARC=fail  → spoofed sender.
2. Link: hxxps://secure-ms-login[.]tld/verify  → WHOIS: registered 2 days ago;
   URLScan: pixel-perfect clone of the M365 login page  → credential-phishing site.
3. Scope: email search shows 14 recipients received it; proxy logs show 2 users clicked the link.
4. Interaction: 1 user (jdoe) submitted credentials (POST to the phishing site seen in proxy).
VERDICT: confirmed credential-phishing campaign; 1 confirmed credential compromise.

Response actions (Tier 1):

• Quarantine/remove the email from all 14 mailboxes (email security tool).

• Block the sender domain and the phishing URL (gateway/proxy/EDR).

• For the user who submitted credentials: reset their password immediately, revoke active sessions/tokens, enforce MFA, and check for suspicious logins to that account.

• For users who clicked but didn't submit: monitor; advise.

• Document the campaign (IOCs, recipients, who interacted) and escalate the confirmed credential compromise.

• Recommend user awareness follow-up.

Key phishing indicators cheat-sheet: sender/reply-to mismatch, SPF/DKIM/DMARC failures, look-alike/new domains, urgency/authority social engineering, credential-harvesting links, malicious attachments, and requests for sensitive action. ATT&CK: T1566 (Phishing), often → T1204 (User Execution) → credential access or malware.

24. Applied Scenario #2 — Endpoint & Malware Investigation

The second core scenario: investigating endpoint activity to detect malware — typically starting from an EDR or SIEM alert on a host.

The endpoint investigation method:

1. Start at the alert — what fired (EDR detection, Sysmon event, AV hit), on which host, which user, when, which file/process.

2. Examine the process tree (lineage) — what spawned the suspicious process (parent), and what it spawned (children). The parent-child chain tells the story. Red flags: Office/Adobe/browser spawning powershell/cmd/wscript/mshta/rundll32; powershell -enc (encoded); processes running from \Temp\, \Downloads\, \Public\, or \AppData\; a process masquerading as a system binary but running from the wrong path.

3. Inspect the command line — encoded/obfuscated commands, download cradles (IEX (New-Object Net.WebClient).DownloadString(...)), LOLBins (certutil -urlcache, bitsadmin /transfer, mshta http...).

4. Enrich the file hash — VirusTotal verdict; known-malicious?

5. Check network activity — did the process connect out? To where? Enrich those IPs/domains (C2?).

6. Check for persistence — new scheduled task (4698), service (7045), run-key (Sysmon 13), or WMI subscription — does it survive reboot?

7. Check for credential access / lateral movement — LSASS access (Sysmon 10), new admin logons (4672), remote logons to other hosts (4624 type 3/10) — did it spread?

8. Scope — sweep the fleet for the hash/indicators (via EDR) to find other infected hosts.

Example endpoint investigation:

Alert: EDR flags "suspicious PowerShell" on WKS-07 (user: jdoe).
Process tree:  winword.exe → powershell.exe -enc JABz...  (decoded: downloads hxxp://bad[.]tld/a.exe)
                                   → a.exe (from C:\Users\jdoe\AppData\Local\Temp\)
Hash of a.exe: VirusTotal 52/70 → trojan/backdoor  → MALICIOUS.
Network: a.exe → 203.0.113[.]45:443 every ~60s (beacon) → C2.
Persistence: Sysmon 13 shows a new Run key "Updater" → C:\...\Temp\a.exe  → survives reboot.
Credential access: no LSASS access or admin logon observed. Lateral movement: none seen.
Scope: EDR hash sweep → only WKS-07 affected.
VERDICT: single-host malware infection via phishing document; active C2; persistence established;
         no credential theft or spread observed yet.

Response actions (Tier 1):

• Isolate WKS-07 via EDR (contain the C2 and any spread).

• Block the C2 IP/domain and the file hash across the fleet.

• Preserve evidence (the sample, process tree, logs) for Tier 2.

• Request password reset for jdoe as a precaution; quarantine the delivering email fleet-wide.

• Escalate to Tier 2 for eradication (remove persistence, confirm clean / reimage) and a deeper check for credential theft/lateral movement.

• Document the full timeline and IOCs.

Malware behavior red flags (quick list): encoded/obfuscated commands; Office spawning shells; execution from temp/appdata; beaconing network connections; persistence mechanisms; LSASS access (credential dumping); rapid file encryption + ransom notes (ransomware); disabling AV/clearing logs (defense evasion). ATT&CK: Execution (T1059), Persistence (T1547/T1053), Defense Evasion (T1562/T1070), Credential Access (T1003), C2 (T1071).

25. Applied Scenario #3 — Network Traffic, C2 & Exfiltration

The third core scenario: analyzing network traffic to detect command-and-control (C2) and data exfiltration — the attacker communicating out and stealing data.

What to look for in network telemetry (firewall, proxy, DNS, NetFlow/Zeek, IDS):

Command & Control (C2) indicators:

• Beaconing — regular, repeating connections to the same external destination (e.g., every 60s), often similar in size — the malware "checking in." The hallmark of C2.

• Connections to known-bad IPs/domains — enrichment flags the destination as C2/malicious.

• Suspicious DNS — queries to newly-registered or random-looking domains (DGA — Domain Generation Algorithm), or DNS tunneling (abnormally long/frequent TXT/subdomain queries encoding data).

• Unusual ports/protocols — e.g., non-web traffic on 443, or a workstation making server-like connections.

• Odd user-agents / TLS fingerprints (JA3) — tools often have distinctive signatures.

Data exfiltration indicators:

• Large outbound data transfers — especially to external/unusual destinations or at odd hours.

• Uploads to cloud storage / file-sharing / paste sites — or via unusual channels.

• Data staging then transfer — an archive (.zip/.7z/.rar) created, then a big upload.

• Exfiltration over DNS/ICMP — covert channels when normal uploads are blocked.

• Connections right after a Collection event — recon/staging followed by a big outbound flow.

Example network investigation (beaconing → exfil):

Lead: proxy shows WKS-07 making steady connections to 203.0.113[.]45.
1. Beaconing: ~240 connections over 4 hours, ~every 60s, uniform small size → classic C2 heartbeat.
2. Enrich 203.0.113[.]45: AbuseIPDB/threat intel → known C2 infrastructure → MALICIOUS.
3. Pivot to the host (EDR): the beaconing process is a.exe (the malware from Scenario #2).
4. Later: firewall shows a single LARGE outbound transfer (850 MB) from WKS-07 to a new external IP,
   right after a 7-Zip archive was created on the host → likely data exfiltration.
5. DNS: no DGA/tunneling here, but note the pattern for other cases.
VERDICT: confirmed C2 (beaconing to known-bad IP) + likely data exfiltration (large staged upload).

Response actions (Tier 1):

• Isolate the host immediately (stop ongoing C2/exfil).

• Block the C2 and exfil destinations.

• Preserve the network evidence (connection logs, the archive, timestamps, byte counts).

• Escalate urgently — confirmed exfil is high/critical (potential data breach); Tier 2/IR + possibly legal/compliance need to assess what data left.

• Scope — any other hosts talking to the same C2? (sweep).

• Document the C2 pattern, the exfil volume/destination, and the timeline.

Beaconing analysis tip: true C2 beacons show low variance in interval (low jitter) and similar byte sizes to a single destination — distinguishable from normal periodic traffic (software updates, legitimate APIs) by enriching the destination and checking the process. ATT&CK: C2 (T1071, T1571), Exfiltration (T1041 over C2 channel, T1048 over alternate protocol, T1567 to web services).

26. Threat Intelligence for SOC Analysts

Threat Intelligence (CTI) is evidence-based knowledge about threats — adversaries, their infrastructure, their tools, and their TTPs — used to enrich investigations and make faster, better-informed decisions. The exam tests applying threat intel to enrich SOC work.

The three levels of threat intelligence:

• Strategic — high-level, for leadership: threat landscape, trends, risk (non-technical). E.g., "ransomware targeting our industry is rising."

• Operational — about specific campaigns/actors: who's attacking, their motivations and TTPs. E.g., "APT-X uses this phishing lure and these C2 patterns."

• Tactical — the technical details analysts use daily: IOCs (malicious IPs, domains, hashes, URLs) and TTPs (mapped to MITRE ATT&CK). This is what Tier 1 uses most — to enrich and detect.

How Tier 1 uses threat intel:

• Enrichment — check an alert's indicators (IP/domain/hash) against threat-intel feeds to get a verdict and context (§21). "This IP is C2 for the Qakbot campaign" instantly raises severity and confidence.

• Context — understand what a threat is and what it typically does next (e.g., "this malware family steals credentials then deploys ransomware") so you anticipate and scope.

• Detection — IOC feeds power SIEM/EDR detections (block/alert on known-bad indicators).

• Prioritization — intel about active campaigns targeting your sector/org raises the priority of related alerts.

Threat-intel concepts & sources:

• IOC (Indicator of Compromise) — atomic evidence (hash/IP/domain/URL). Easy to share, but attackers change them (recall the Pyramid of Pain, §6).

• TTPs — behaviors (ATT&CK techniques) — far more durable to detect on.

• Threat feeds — streams of IOCs (commercial, open-source, ISAC/sector-specific, government).

• TIP (Threat Intelligence Platform) — aggregates, de-duplicates, and operationalizes intel (e.g., MISP, Anomali, ThreatConnect).

• Open sources (OSINT): VirusTotal, AlienVault OTX, Abuse.ch (URLhaus/MalwareBazaar/Feodo Tracker), MISP, CISA advisories, vendor threat reports.

• Attribution — linking activity to a known actor/group (interesting context, but behavior and containment matter more to Tier 1 than "who").

Example of intel enriching a case: an alert shows a connection to 203.0.113.45. A threat feed identifies it as Cobalt Strike C2 infrastructure associated with a ransomware affiliate. Instantly: confidence → high, severity → high, and you know the likely next steps (credential theft, lateral movement, ransomware) — so you contain fast and scope aggressively. Without the intel, it was just "an unknown external IP."

Caution: intel can be stale or wrong (an IP flagged last month may be clean now; a shared hosting IP may host both good and bad). Treat intel as context to weigh, not absolute truth — corroborate with the actual evidence in your environment.

27. AI-Augmented SOC Operations (and its limits)

Modern SOCs increasingly use AI and machine learning to cope with alert volume and speed up analysis. eSOC uniquely tests understanding how AI is used in the SOC — and its limitations and the continued need for human judgment.

How AI/ML helps the SOC:

• Alert triage & prioritization — ML models score and rank alerts by likely severity/maliciousness, surfacing the ones that matter and suppressing obvious noise (fighting alert fatigue).

• Anomaly detection / UEBA — baseline normal behavior for users/hosts and flag deviations (impossible travel, unusual data access, abnormal process behavior) that signature rules miss.

• Enrichment & summarization — AI can auto-gather context and summarize an incident ("here's what happened, the affected assets, and the likely technique") to speed analyst understanding.

• Investigation assistance — AI copilots suggest next investigative steps, draft queries, explain alerts, and draft ticket/report text.

• Automated response (via SOAR) — AI-informed automation enriches and even executes playbook steps (with human approval for consequential actions).

• Detection engineering — ML helps find patterns and reduce false positives.

The limits of AI in the SOC (equally important):

• False positives and false negatives — ML models are probabilistic; they flag benign things and miss novel threats. They're an aid, not an oracle.

• No true context/judgment — AI doesn't understand your business, which assets are critical, or the nuance of a specific situation the way a human does.

• Explainability — ML verdicts can be "black boxes"; analysts must still validate why with evidence.

• Adversarial evasion — attackers adapt to and try to fool AI detection.

• Hallucination (generative AI) — AI assistants can produce confident but wrong answers; never act on AI output without verifying against real evidence.

• Data quality dependence — AI is only as good as the telemetry it's fed.

The human-in-the-loop principle (the key exam takeaway): AI augments the analyst — it accelerates triage, enrichment, and documentation — but the human provides judgment, context, validation, and accountability. Consequential decisions (confirming an incident, isolating a production server, declaring a breach) require human verification. The right model is AI does the heavy lifting; the analyst decides. An analyst who blindly trusts AI output is as dangerous as one who ignores a real alert — always verify AI-suggested findings against the actual evidence.

Practical stance for Tier 1: use AI to work faster (prioritized queues, auto-enrichment, summaries, drafted tickets), but own the decision — confirm with logs/EDR, apply context, and document your own reasoning. AI is a powerful junior assistant, not a replacement for the analyst's judgment.

28. Common Incident Types — Quick Reference

A fast reference for the incident types you'll classify and respond to, with the tell and the first move.

Using this table: classification → playbook → severity → response/escalation. The "first move" is the Tier 1 action; serious or confirmed incidents always get documented and escalated with evidence.

29. SOC Metrics & Performance

SOCs measure themselves to improve. Know the key metrics — they appear in the exam and shape how you work.

The core metrics:

• MTTD (Mean Time To Detect) — average time from when an incident begins to when it's detected. Lower is better (faster detection = less damage).

• MTTR (Mean Time To Respond / Resolve) — average time from detection to containment/resolution. Lower is better (faster response = less damage).

• MTTA (Mean Time To Acknowledge) — how fast an analyst picks up an alert.

• Dwell time — how long an attacker was present before detection (lower is better).

• Alert volume — how many alerts the SOC receives (context for staffing/tuning).

• False positive rate — proportion of alerts that are benign (high FP rate = tuning needed, alert fatigue risk).

• True positive rate / detection accuracy — detection fidelity.

• Escalation rate — proportion of alerts escalated beyond Tier 1.

• SLA compliance — % of alerts triaged/handled within the time target.

• Backlog / queue depth — unworked alerts (a growing backlog is a warning sign).

Why metrics matter to a Tier 1 analyst:

• Your speed and accuracy feed MTTD/MTTR and SLA compliance — triage promptly and correctly.

• Spotting and reporting noisy rules (false positives) improves the FP rate and reduces alert fatigue for everyone.

• Clean documentation keeps escalations fast (helping MTTR).

• Metrics reveal where the SOC needs tuning, automation, or more coverage.

The improvement loop: measure → find the bottleneck (noisy rules, slow enrichment, coverage gaps) → fix (tune, automate via SOAR, add logging/detections) → measure again. A mature SOC continuously drives MTTD and MTTR down. The analyst's contribution: fast, accurate, well-documented triage and a habit of feeding back patterns (FP tuning, detection gaps) that improve the whole operation.

30. End-to-End Triage Walkthrough (a shift in the life)

Putting it all together — a realistic Tier 1 triage from alert to escalation, showing every skill in sequence.

08:15 — Alert appears in the SIEM queue.

Detection: "Encoded PowerShell execution" — host WKS-07, user jdoe, severity (initial) Medium.

Step 1 — Understand the alert. The rule fired on a Sysmon EID 1 showing powershell.exe -enc spawned by winword.exe. Anchors: host WKS-07, user jdoe, time ~09:06 (reviewing after the fact), the PowerShell process.

Step 2 — Gather evidence (SIEM + EDR).

index=edr host=WKS-07 EventCode=1 | sort _time | table _time ParentImage Image CommandLine

Process tree: winword.exe → powershell.exe -enc JABz... → a.exe (from \Temp\). Decode the base64 (§21) → it downloads hxxp://bad[.]tld/a.exe.

Step 3 — Enrich indicators (§21). Hash of a.exe → VirusTotal 52/70 (trojan). bad[.]tld → WHOIS 3-day-old domain. Network logs show a.exe → 203.0.113[.]45:443 beaconing ~every 60s → AbuseIPDB flags it as C2. Verdict: malicious — true positive.

Step 4 — Correlate & scope (§13). Email gateway shows jdoe received a suspicious .docm at 09:02 (initial access). Persistence: a new Run key points to a.exe. No LSASS access, no admin logon, no lateral movement in the logs. EDR hash sweep → only WKS-07 affected. Scope: one host, one user, standard privileges; active C2; persistence present; no spread/exfil observed yet.

Step 5 — Classify & assign severity (§14–15). Classification: malware infection via phishing, with active C2. Severity: High (confirmed compromise + active C2, but single standard-user host, contained, no exfil/lateral movement).

Step 6 — Respond (Tier 1 playbook, §17). Isolate WKS-07 via EDR; block the hash, bad[.]tld, and 203.0.113[.]45; quarantine the phishing email fleet-wide; request a password reset for jdoe; preserve evidence.

Step 7 — Document & escalate (§22). Write the escalation ticket: title, High severity, summary, timeline, IOCs (defanged), ATT&CK mapping (T1566→T1059.001→T1071), actions taken, and next steps for Tier 2 (confirm eradication, check for lateral movement/data access, reimage decision). Status: Escalated to Tier 2; host isolated.

08:45 — Done. From alert to escalation in 30 minutes: understood → investigated → enriched → correlated → classified → responded → documented. That loop — fast, evidence-driven, well-documented — is the job, and it's exactly what eSOC measures.

Hand-off note (shift change): open items, what's escalated and to whom, and anything to watch — so the next analyst has continuity. Continuous coverage means clean hand-offs.

31. SIEM Detection Use-Case Library

A reference of common SIEM detection use cases you'll see as alerts — what each detects, why it matters, an example query, and the likely verdict logic. Examples use Splunk SPL (KQL idea noted); the concepts transfer to any SIEM.

Authentication detections:

# Brute force: many failed logons then a success (same account)
index=windows (EventCode=4625 OR EventCode=4624) | transaction Account_Name maxspan=10m
| where eventcount>20 AND searchmatch("EventCode=4624")
# Password spray: one IP failing against MANY accounts
index=windows EventCode=4625 | stats dc(Account_Name) as users by Source_Network_Address | where users>15
# Impossible travel: same user, two far-apart locations in a short time (needs geo enrichment)
# After-hours admin logon
index=windows EventCode=4672 date_hour>=0 date_hour<=5

Verdict logic: correlate failures→success, check what the account did next, enrich the source IP, compare to the user's baseline.

Execution / endpoint detections:

# Office spawning a shell (phishing payload execution)
index=edr EventCode=1 ParentImage IN ("*winword.exe","*excel.exe","*outlook.exe") Image IN ("*powershell.exe","*cmd.exe","*mshta.exe")
# Encoded / download-cradle PowerShell
index=edr (EventCode=1 OR EventCode=4104) (CommandLine="*-enc*" OR CommandLine="*DownloadString*" OR CommandLine="*FromBase64*")
# LOLBin abuse
index=edr EventCode=1 (CommandLine="*certutil*urlcache*" OR CommandLine="*bitsadmin*transfer*" OR CommandLine="*regsvr32*scrobj*")

Credential-access detection:

# LSASS access (credential dumping) — non-system process opening a handle to lsass
index=edr EventCode=10 TargetImage="*lsass.exe" NOT SourceImage IN ("*MsMpEng.exe","*wininit.exe")

Persistence detection:

index=windows (EventCode=4698 OR EventCode=7045)      # scheduled task / service created
index=edr EventCode=13 TargetObject="*CurrentVersion\\Run*"   # run-key autostart

Defense-evasion detection:

index=windows EventCode=1102                           # security log cleared (!)
index=edr (CommandLine="*Set-MpPreference*DisableRealtime*" OR CommandLine="*vssadmin*delete*shadows*")  # disable AV / delete shadow copies (ransomware prep)

C2 / exfil detection:

index=network | stats count by src_ip dest_ip dest_port | where count>100          # beaconing candidate
index=dns | eval l=len(query) | where l>50                                          # long DNS (tunneling)
index=proxy | stats sum(bytes_out) as out by src_ip dest | sort -out                # large uploads (exfil)

How to use the library: when an alert fires, recognize which use case it maps to, run the supporting query to gather evidence, enrich the indicators, and decide TP/FP. Over time you'll recognize these patterns instantly — which is what makes triage fast. Each use case also maps to a MITRE ATT&CK technique, giving you the standard language for your ticket.

32. Deep-Dive: Email Header Analysis (annotated example)

Phishing triage lives or dies on reading email headers — the metadata the display never shows. Here's a full annotated walkthrough.

How email headers work (bottom-to-top = oldest-to-newest). Each mail server that handles the message adds a Received: line on top, so you read the path from the bottom up. The From: you see in your client is just a display field — easily forged. The real trust signals are Return-Path, Received (originating IP), and the authentication results (SPF/DKIM/DMARC).

Annotated example (suspicious "Microsoft" email):

From:          "Microsoft Account Team" <[email protected]>     ← DISPLAY (can be spoofed)
Return-Path:   <bounce@secure-ms-login.tld>                          ← REAL envelope sender (mismatch! red flag)
Reply-To:      account-verify@secure-ms-login.tld                    ← replies go to attacker (red flag)
Received: from mail.secure-ms-login.tld (203.0.113.77)              ← ORIGINATING server/IP (enrich it)
          by mx.company.com ...
Authentication-Results: mx.company.com;
    spf=fail   (sender IP not authorized for microsoft.com)          ← SPF FAIL  (spoofing)
    dkim=fail  (no valid signature)                                  ← DKIM FAIL
    dmarc=fail action=quarantine                                     ← DMARC FAIL  → strong spoof signal
Subject:       Unusual sign-in detected — verify within 24 hours      ← urgency (social engineering)

What each authentication check means:

• SPF (Sender Policy Framework) — does the sending IP appear in the domain's authorized-senders list (DNS record)? SPF fail = the server isn't allowed to send for that domain → likely spoofing.

• DKIM (DomainKeys Identified Mail) — is the message cryptographically signed by the domain and intact? DKIM fail = no/invalid signature.

• DMARC — a policy that ties SPF/DKIM to the visible From: domain and tells receivers what to do on failure (none/quarantine/reject). DMARC fail with the From claiming microsoft.com is a near-certain spoof.

The red-flag checklist (from this header):

✗ From (microsoft.com) ≠ Return-Path/Reply-To (secure-ms-login.tld)   → sender mismatch/spoof
✗ SPF fail, DKIM fail, DMARC fail                                      → failed authentication
✗ Originating IP 203.0.113.77 (enrich: reputation, geo, ASN)          → suspicious infrastructure
✗ secure-ms-login.tld — look-alike + newly registered (WHOIS)         → typosquat/new domain
✗ Subject uses urgency/authority                                       → social engineering

Tools for header analysis: your mail client's "show original/source," MXToolbox Email Header Analyzer, Google's Message Header tool, or simply reading the raw headers. Then enrich the originating IP (AbuseIPDB), the sender domain (WHOIS age/reputation), and any URLs (URLScan/VirusTotal).

The verdict: multiple authentication failures + sender mismatch + look-alike new domain + urgency = confirmed phishing (spoofed sender). From here you run the phishing playbook (§23): quarantine, block, check who clicked, reset creds if interacted. Reading headers confidently is one of the most valuable, most-tested Tier 1 skills — practice on real samples.

33. More Applied Scenarios — Brute Force, Ransomware & Insider Exfil

Three more worked Tier 1 investigations to round out the applied-scenario skill set.

33.1 Brute Force → Account Compromise

Alert: spike in failed logons (Event ID 4625) for user svc_backup.

Investigation:
  index=windows EventCode=4625 Account_Name=svc_backup
  → 420 failures from 198.51.100.23 over 15 minutes (T1110 brute force / password guessing)
  index=windows EventCode=4624 Account_Name=svc_backup Source_Network_Address=198.51.100.23
  → ONE success at 14:22 (Logon Type 3) → the attacker guessed the password
  Follow the account: after 14:22 → 4672 (admin privileges), 4732 (added self to a group),
     then network logons (4624 type 3) to TWO other servers → lateral movement beginning.
Enrich 198.51.100.23: AbuseIPDB → known brute-force source.
VERDICT: successful brute force → account compromise → early lateral movement. TRUE POSITIVE, HIGH.
Response: disable/reset svc_backup; revoke sessions; block the source IP; isolate the touched hosts;
          escalate to Tier 2 (scope the lateral movement). Recommend: strong password/MFA, lockout policy.
ATT&CK: T1110 (Brute Force) → T1078 (Valid Accounts) → T1021 (Lateral Movement).

Key tell: many 4625 → a 4624 success → privileged/lateral activity. Service accounts with weak passwords and no MFA are a classic target.

33.2 Ransomware Incident

Alert: EDR flags "mass file modification" + "shadow copy deletion" on a file server.

Investigation:
  EDR process tree: a process is rapidly renaming/encrypting files (adding a ".locked" extension)
     and dropping "READ_ME.txt" ransom notes in every folder.
  Command seen: vssadmin delete shadows /all /quiet   → deleting backups (anti-recovery, T1490)
  Also: wbadmin delete / bcdedit disabling recovery; possibly disabling AV (T1562).
  Network: the process beaconed to an external IP earlier (C2 → ransomware deployment).
  Scope: EDR shows the same binary/behavior starting on 3 more servers (spreading via SMB/admin shares).
VERDICT: ACTIVE RANSOMWARE, spreading. TRUE POSITIVE, CRITICAL.
Response (SPEED is everything):
  - ISOLATE all affected hosts IMMEDIATELY (contain the spread) — network-quarantine via EDR.
  - Block the C2 and the ransomware hash fleet-wide; disable the compromised account(s).
  - Do NOT power off (preserve memory/evidence) unless directed; preserve ransom note + sample.
  - ESCALATE CRITICAL to Tier 2 / IR / SOC manager immediately — this is a major incident
    (leadership, legal, comms, and backups/DR teams get involved).
ATT&CK: Impact — T1486 (Data Encrypted for Impact), T1490 (Inhibit System Recovery), T1562 (Impair Defenses).

Key tell: rapid mass file changes + ransom notes + shadow-copy/backup deletion. Ransomware is time-critical — contain first, investigate in parallel, escalate fast. Early detection of the precursors (C2, credential theft, lateral movement) is how SOCs stop ransomware before encryption.

33.3 Insider Threat & Data Exfiltration

Alert: DLP/UEBA flags unusual large data access + external upload by an employee leaving the company.

Investigation:
  - User accessed an abnormal volume of files from a sensitive share (far above their baseline) over 2 days.
  - Then: a large archive (customer_data.zip) created locally, followed by an upload to a personal
    cloud-storage/webmail account (proxy logs show ~2 GB outbound to a file-sharing site).
  - Context (HR): the user resigned last week (motive/opportunity). Access was legitimate (authorized user)
    but the BEHAVIOR (bulk access + personal exfil) is anomalous.
VERDICT: likely malicious insider data exfiltration. TRUE POSITIVE, HIGH/CRITICAL (data breach risk).
Response (handle carefully — people/legal sensitivity):
  - Preserve evidence meticulously (logs, the archive, upload records, timeline).
  - Escalate per the INSIDER-THREAT process — this almost always involves HR and Legal, and must be
    handled discreetly (do NOT tip off the user). Follow the organization's specific procedure.
  - Containment (e.g., revoking access) is decided WITH HR/Legal, not unilaterally by Tier 1.
ATT&CK: Collection (T1005/T1039) → Exfiltration (T1567 to web service).

Key tell: authorized user, anomalous behavior (volume, timing, destination), often with a life-event context (resignation, grievance). Insider cases are as much process and discretion as technical — document precisely and escalate through the proper channel.

Cross-scenario lesson: different incident types, same discipline — understand the alert, gather and correlate evidence, enrich, decide TP/FP + severity, respond per the appropriate playbook (and escalate confirmed/serious cases), and document thoroughly. Ransomware demands speed; insider cases demand discretion; brute force demands scoping the post-compromise activity.

34. Network Analysis & Packet Inspection Basics

SOC analysts frequently examine network evidence — flow logs, proxy/DNS logs, and sometimes packet captures (PCAPs). You don't need to be a network engineer, but you must read network telemetry and spot malicious patterns.

The layers of network evidence (least to most detailed):

• Flow data (NetFlow/IPFIX) — connection metadata: who talked to whom, when, which ports, how much data. Great for spotting beaconing and large transfers at scale.

• Logs (firewall/proxy/DNS/IDS) — allowed/blocked connections, web requests, domain lookups, signature alerts.

• Zeek (Bro) — rich connection + protocol logs (conn/dns/http/ssl/files) — the analyst's network "SIEM data."

• Full packet capture (PCAP) — every byte; deepest detail, highest storage. Analyzed with Wireshark or tcpdump.

Protocols & ports you'll see constantly:

80/443  HTTP/HTTPS (web, and most C2/exfil hides here)   53 DNS (lookups; C2/tunneling)
22 SSH   3389 RDP (remote access, lateral movement)       445 SMB (file sharing, lateral movement)
25/587/465 SMTP (email)   21 FTP   23 Telnet   1433 MSSQL  389/636 LDAP   135 RPC

Reading a PCAP in Wireshark (basics):

Display filters:
  ip.addr == 203.0.113.45           # traffic to/from an IP
  http.request                      # HTTP requests (see URLs/hosts/user-agents)
  dns                               # DNS queries/answers
  tcp.port == 443                   # by port
  http.request.method == "POST"     # data submission (credential phishing, exfil)
Follow TCP/HTTP Stream → see the full conversation (e.g., a credential POST, a malware download).
Statistics → Conversations / Protocol Hierarchy → spot top talkers and odd protocols.

Malicious network patterns to recognize:

• Beaconing (C2) — regular, uniform connections to one external destination (low jitter); the heartbeat of malware check-in.

• C2 over HTTPS/HTTP — connections to a known-bad or newly-registered domain; odd user-agents.

• DNS tunneling / DGA — abnormally long/frequent DNS queries, or lookups to random-looking domains.

• Data exfiltration — large outbound transfers, uploads to cloud/paste/file-sharing sites, especially after a staging event.

• Scanning / recon — one source hitting many IPs/ports.

• Lateral movement — internal host-to-host SMB/RDP/WMI it wouldn't normally make.

• Cleartext credentials — passwords over HTTP/FTP/Telnet (a finding in itself).

Example PCAP read: a capture from WKS-07 shows (1) a DNS query for c2-domain.tld, (2) an HTTP GET to /a.exe (malware download), then (3) repeated POSTs to 203.0.113.45 every 60 seconds with small uniform payloads (beaconing C2), and later (4) a large POST of a .zip to an external host (exfil). Following the streams confirms the download and the beacon content. That single capture tells the whole story: delivery → C2 → exfil.

Practical stance for Tier 1: most of your network analysis is log/flow-based (proxy/DNS/firewall/Zeek in the SIEM); deep PCAP analysis is often Tier 2, but you should be able to open a capture, filter to the relevant host/IP, follow a stream, and recognize the patterns above. Enrich every external destination before concluding.

35. Digital Forensics & Evidence Handling Basics

Tier 1 analysts aren't forensic examiners, but you collect and preserve evidence and must do it correctly — a mishandled artifact can ruin an investigation or a legal case.

Why evidence handling matters: incidents may lead to legal action, insurance claims, regulatory reporting, or disciplinary cases. Evidence must be authentic, intact, and defensible — able to withstand scrutiny about whether it was tampered with.

Core principles:

• Chain of custody — a documented record of who handled the evidence, when, and why, from collection to storage. Unbroken custody = admissible/trustworthy evidence.

• Preserve, don't alter — collect evidence in a way that doesn't change it; work on copies, not originals. Document everything you do.

• Order of volatility — collect the most volatile (short-lived) evidence first, because it disappears:

  1. CPU registers / cache (most volatile)
  2. RAM / memory (running processes, injected malware, encryption keys) — capture BEFORE powering off
  3. Network state (active connections, ARP, routing)
  4. Running processes & logged-on users
  5. Disk (files, logs) 
  6. Remote/archived logs, backups (least volatile)
  

  Key implication: don't power off a compromised host before capturing memory — RAM-only (fileless) malware and keys vanish on shutdown. Isolation (network-quarantine via EDR) contains the threat while preserving volatile state.

• Hashing for integrity — compute a hash (SHA256) of collected evidence/images so you can later prove it hasn't changed.

• Timestamps & documentation — record exact times (UTC) and your actions in the ticket.

What Tier 1 typically collects/preserves:

• Logs — export the relevant SIEM/EDR/host logs and note the time range.

• Screenshots — of alerts, dashboards, ransom notes, suspicious emails/pages.

• Malware samples / suspicious files — hash them; store safely (never execute outside a sandbox).

• Email artifacts — the full email with headers (.eml/.msg), not just a screenshot.

• EDR data — process trees, timelines, network connections (export/snapshot).

• Memory/disk images — usually captured by Tier 2/IR, but Tier 1 may initiate with the right tools (e.g., EDR memory capture, WinPMEM/DumpIt for RAM, KAPE for triage collection).

Forensic artifacts that reveal attacker activity (awareness): Windows Prefetch and Amcache/Shimcache (execution evidence), the $MFT and USN journal (file activity), registry (persistence, run keys), event logs, browser history, PowerShell transcripts/history, and memory (injected code, decrypted strings, network state). Tools: Volatility (memory), Autopsy/Sleuth Kit (disk), KAPE (collection), Eric Zimmerman's tools (parsing).

The Tier 1 rule of thumb: when in doubt, preserve more, alter less, document everything. Isolate (don't power off) to contain while keeping volatile evidence; collect logs/screenshots/samples with timestamps; hash what you collect; and hand a clean, well-documented evidence package to Tier 2/IR. Good evidence handling is a quiet but critical SOC skill.

36. Vulnerability & Threat Context for SOC

SOC analysts don't run the vulnerability-management program, but vulnerability context sharpens triage — knowing whether a targeted system is exploitable changes an alert's severity.

Key concepts:

• Vulnerability — a weakness (software bug, misconfiguration, weak credential) an attacker can exploit.

• CVE (Common Vulnerabilities and Exposures) — the standard identifier for a publicly-known vulnerability (e.g., CVE-2021-44228 = Log4Shell). Each has a description and affected products.

• CVSS (Common Vulnerability Scoring System) — a 0–10 severity score (Low/Medium/High/Critical) reflecting exploitability and impact. Higher = more urgent.

• Exploit — code/technique that takes advantage of a vulnerability. A proof-of-concept (PoC) exploit being public raises risk sharply.

• Patch — the vendor fix. Patch management = the process of applying fixes; unpatched systems are the SOC's recurring headache.

• Zero-day — a vulnerability with no patch available yet (highest risk).

• Attack surface — all exploitable entry points; reducing it reduces risk.

How vulnerability context helps triage:

• An alert targeting a known-vulnerable, unpatched service is far more likely to be a real, successful attack → raise severity. (e.g., exploitation attempts against an unpatched internet-facing server with a critical CVE.)

• Knowing a widely-exploited CVE is active (e.g., a new critical RCE with public exploits) tells you what to watch for and prioritize.

• Scan data (from Nessus/Qualys/OpenVAS/Rapid7) tells you which of your assets are exposed — context for whether an exploit attempt could have succeeded.

Common vulnerability/attack categories you'll encounter in alerts:

• Web: SQL injection (SQLi), cross-site scripting (XSS), remote code execution (RCE), path traversal, insecure deserialization.

• Infrastructure: unpatched RCE (e.g., Log4Shell, ProxyLogon-class), default/weak credentials, exposed services (RDP/SMB/databases on the internet), misconfigurations.

• Identity: weak passwords, no MFA, excessive privileges.

The SOC ↔ vuln-management link: the SOC detects exploitation attempts and successes; vulnerability management reduces the attack surface that makes those attempts succeed. When you triage an alert, asking "is the target vulnerable/exposed/unpatched?" helps you judge likelihood and impact — and your findings (e.g., "we're seeing active exploitation of CVE-X against our unpatched servers") feed back to drive patching. Threat + vulnerability + asset context together = accurate risk-based prioritization.

37. Practice Questions & Scenario Drills (with answers)

Scenario-style questions with reasoning — the way eSOC tests. Cover the answer, reason it out, then check.

Q1. You see 300 Event ID 4625 events for one account from a single IP in 10 minutes, followed by one 4624. What happened, and what do you do? → Successful brute force / account compromise. Investigate what the account did after the 4624; disable/reset the account; block the IP; escalate. (§8, §33.1)

Q2. An alert shows winword.exe spawning powershell.exe -enc. True or false positive, and why? → Almost certainly true positive / malicious — Office spawning encoded PowerShell is a classic phishing-payload execution (T1566→T1059.001). Decode the command, check the download, enrich, and respond. (§24)

Q3. What's the difference between a true positive and a false positive? → True positive = the alert correctly caught real malicious activity. False positive = the alert fired on benign activity. (§12)

Q4. An email's From: says paypal.com but SPF, DKIM, and DMARC all fail and the Reply-To is a different domain. Verdict? → Spoofed/phishing email. Authentication failures + sender mismatch = spoofing. Quarantine, block, check for interaction. (§23, §32)

Q5. A host makes a connection to the same external IP every 60 seconds with similar payload sizes. What is this? → Beaconing — likely C2. Enrich the IP, find the process (EDR), isolate the host, block the IP, escalate. (§25, §34)

Q6. Which NIST IR phase is Tier 1 primarily responsible for? → Detection & Analysis (triage/validate/classify/document), plus initial containment per playbook. (§16)

Q7. You confirm malware with active C2 on one standard-user laptop, contained, no spread. What severity, and next step? → Roughly High (confirmed compromise + active C2, but single low-value host, contained); isolate, block IOCs, escalate to Tier 2 with a documented ticket. (§15, §22)

Q8. Why should you never power off a compromised host before capturing memory? → Volatile evidence (RAM — running processes, injected/fileless malware, keys, network state) is lost on shutdown. Isolate (network-quarantine) instead to contain while preserving it. (§35)

Q9. What does enrichment add to an investigation, and name three enrichment sources. → Context/verdict on indicators (known-bad vs good vs unknown). Sources: VirusTotal, AbuseIPDB, URLScan/sandbox, WHOIS, threat feeds. (§21)

Q10. Event ID 1102 appears in the logs. Why does it matter? → The Security event log was cleared — a strong defense-evasion / anti-forensics indicator; investigate what happened around it. (§8)

Q11. A SOAR playbook auto-isolated a host and the AI copilot says it's malware. Do you close the case? → No — verify. AI/automation can be wrong (false positives, hallucination). Confirm with the actual evidence (process tree, hash verdict, logs) before concluding. Human judgment owns the decision. (§27)

Q12. Rapid file encryption, ".locked" extensions, ransom notes, and vssadmin delete shadows. Classification and first move? → Active ransomware (CRITICAL). Isolate affected hosts immediately, block IOCs, preserve evidence (don't power off), escalate to IR/manager at once. (§33.2)

Q13. What is the Pyramid of Pain's lesson for detection? → Detect on TTPs/behavior (hard for attackers to change) rather than just hashes/IPs (trivial to change) for durable detection. (§6)

Q14. A legitimate user downloads from a signed internal path during business hours, triggering a "PowerShell" alert. Verdict? → Likely false positive (context + baseline = benign). Document as FP; recommend tuning/exclusion for that script/path. (§12)

Q15. Where in the SOC do you escalate a confirmed, complex incident, and what must accompany it? → To Tier 2 (then Tier 3/IR/manager as needed), with an escalation-ready ticket: summary, severity, timeline, IOCs, analysis, actions taken, next steps. (§3, §22)

Q16. A user authenticates from New York and, 20 minutes later, from Singapore. What detection is this, and what do you check? → Impossible travel / anomalous login (possible account compromise). Verify (VPN? both IPs enriched), check MFA, review the account's activity, and disable/reset if confirmed. (§31)

Q17. What are MTTD and MTTR, and why do they matter? → Mean Time To Detect and Mean Time To Respond — lower values mean faster detection/response and less damage; your triage speed/accuracy drives them. (§29)

Q18. You find cleartext credentials in an HTTP POST in a packet capture. Is this a finding? → Yes — credentials sent in cleartext (insecure communication) is a finding; also check whether they were captured by an attacker. (§34)

How to use these: for each, identify the concept/incident type, the evidence that proves it, the verdict (TP/FP + severity), and the action (respond/escalate) + documentation. That four-part reasoning is exactly how the exam — and the job — evaluates you.

38. Exam-Day Tips & Study Plan

Exam approach:

• Think like an analyst, not a test-taker. For every scenario, run the triage loop: understand → gather evidence → analyze → decide (TP/FP + severity) → act/escalate → document.

• Let evidence decide. Validate with logs/EDR/enrichment before concluding; don't react to an alert's scary name.

• Know the three applied scenarios cold — phishing (§23), endpoint/malware (§24), network/C2/exfil (§25). They mirror the exam and the job.

• Map to frameworks — describe findings in MITRE ATT&CK terms; frame incidents in Kill-Chain/NIST language.

• Document clearly — practice writing escalation-ready tickets (§22); a correct finding documented poorly loses points.

• Know when to escalate — Tier 1 handles routine and contains per playbook, but escalates confirmed/complex/high-impact incidents with full evidence.

• Read carefully — identify the asset, user, time, and what's normal for the environment; context changes the verdict.

Study plan (~3 weeks):

Days 1-3    SOC foundations: what a SOC is, roles/tiers, analyst mindset, security basics (§1-5)
Days 4-5    Frameworks: MITRE ATT&CK, Kill Chain, NIST, Pyramid of Pain (§6)
Days 6-8    Logging & log sources; Windows/Linux/network/cloud logs & event IDs (§7-9)
Days 9-11   SIEM fundamentals & querying; practice searches/pivots (§10-11)
Days 12-13  Alert analysis (TP/FP), correlation & investigation (§12-13)
Days 14-15  Detection, triage, severity; IR lifecycle; playbooks & response actions (§14-17)
Days 16-17  Tools: EDR, SOAR, ticketing; enrichment & OSINT (§18-21)
Day  18     Ticketing & escalation-ready reporting — practice writing tickets (§22)
Days 19-21  Applied scenarios: phishing, endpoint/malware, network/C2/exfil (§23-25)
Day  22     Threat intelligence & AI-augmented SOC (§26-27)
Day  23     Incident types, metrics, end-to-end walkthrough; review & practice (§28-30)

Common mistakes to avoid: closing alerts without understanding why they fired; reacting to alert names instead of evidence; ignoring context/baseline; forgetting to enrich indicators; poor/incomplete documentation; not knowing when to escalate; clicking suspicious links/opening samples unsafely; and treating AI output as truth without verification.

Hands-on practice (strongly recommended): use free resources — a home SIEM (Splunk Free / Elastic / Security Onion), Boss of the SOC (BOTS) datasets, Blue Team Labs Online, LetsDefend, CyberDefenders, TryHackMe SOC Level 1 path, and analyze sample phishing emails and malware reports (safely) to build real triage reps.

39. Glossary & Quick Reference

SOC & roles: SOC (Security Operations Center) · Blue Team (defenders) · Tier 1/2/3 (triage / investigation / hunting) · MSSP (managed security provider) · escalation path · SOC analyst mindset (evidence-driven triage). Security foundations: CIA triad (Confidentiality, Integrity, Availability) · threat / vulnerability / risk · defense in depth · TTPs · IOC (indicator of compromise) · IOA (indicator of attack) · attack surface · zero-day. Frameworks: MITRE ATT&CK (tactics & techniques) · Cyber Kill Chain (7 stages) · NIST CSF (Identify/Protect/Detect/Respond/Recover) · NIST 800-61 (IR lifecycle) · Pyramid of Pain (hash→IP→domain→artifact→tool→TTP). Logging: log source · Event ID (e.g., 4624 logon, 4625 failed logon, 4688 process, 1102 log cleared) · Logon Type · Sysmon · normalization · retention · time sync/NTP · blind spot. SIEM & querying: SIEM (Splunk/Sentinel/Elastic/QRadar) · correlation rule · alert / use case · SPL / KQL · pivot · UEBA · tuning. Triage & detection: alert triage · true/false positive, true/false negative · alert fatigue · severity (Critical–Info) · prioritization · incident classification · playbook/runbook. Incident response: NIST lifecycle (Prepare → Detect & Analyze → Contain → Eradicate → Recover → Lessons Learned) · containment / isolation · eradication · recovery · PICERL (SANS 6-step). Tools: EDR (endpoint detection & response; process tree, isolation) · XDR · SOAR (orchestration/automation/response) · ticketing / case management (ServiceNow/Jira/TheHive) · SLA. Enrichment & intel: enrichment · VirusTotal / AbuseIPDB / URLScan / sandbox · defang (hxxp://bad[.]tld) · WHOIS / domain age · threat intelligence (strategic/operational/tactical) · threat feed / TIP · SPF/DKIM/DMARC (email auth). Attack concepts: phishing (T1566) · malware (virus/worm/trojan/ransomware/spyware) · brute force · credential dumping (T1003) · lateral movement (T1021) · C2 (T1071) · beaconing · exfiltration (T1041/T1048/T1567) · DGA / DNS tunneling · LOLBins. AI in the SOC: AI-augmented SOC · ML triage / anomaly detection · AI copilot / summarization · human-in-the-loop · hallucination (verify AI output). Metrics: MTTD (detect) · MTTR (respond/resolve) · MTTA (acknowledge) · dwell time · false-positive rate · SLA compliance · backlog.

End of guide. The eSOC validates that you can do the real work of a Tier 1 SOC analyst: take an alert, investigate it with a SIEM and EDR, enrich the indicators, decide true vs false positive, assign severity, respond or contain per playbook, and produce an escalation-ready ticket — all while thinking in frameworks (MITRE ATT&CK, Kill Chain, NIST) and knowing when to escalate. Master the triage loop, practice the three applied scenarios (phishing, endpoint/malware, network/C2/exfil) until they're second nature, document everything clearly, and use AI and threat intelligence as force-multipliers while keeping human judgment in charge. That is operational SOC readiness — and that is what this exam rewards.