SOC Analyst — Interview Questions.

A Security Operations Center monitors an organization's systems around the clock for signs of compromise, triages the alerts, and responds. Tier 1 analysts triage the incoming alert queue — is this real, is it urgent, does it match a known pattern — and either close it or escalate. Tier 2 investigates escalated alerts in depth: pulling logs across systems, scoping the blast radius, confirming or ruling out compromise. Tier 3 (often "threat hunters" or incident responders) handles the hardest cases, hunts proactively for threats that didn't trigger an alert, and does root-cause and post-incident work. Many SOCs also have a detection-engineering function that writes and tunes the rules everyone else works from.

A Security Information and Event Management platform (Splunk, Microsoft Sentinel, Elastic Security, QRadar) ingests logs from across the environment — firewalls, endpoints, identity providers, cloud audit trails, applications — normalizes them into a common schema, and lets analysts search and correlate across all of it in one place. Without it you'd be SSH-ing into dozens of systems to piece together one incident timeline. The SIEM also runs correlation rules that fire alerts when a pattern matches (e.g. five failed logins then one success from a new country), which is the primary feed into the analyst queue.

An Indicator of Compromise is evidence something already happened: a known-bad file hash, a malicious IP or domain, a specific registry key a piece of malware creates. IOCs are reactive and easy for an attacker to change (rotate the IP, repack the binary). An Indicator of Attack describes the behavior or technique regardless of the specific tool used — e.g. "a process spawned from Word is making outbound network connections" or "credentials dumped from LSASS memory." IOAs are harder for attackers to evade because changing tools doesn't change the underlying technique, which is why modern detection leans on behavioral (IOA) rules over static (IOC) blocklists.

An event is any recorded happening — a login, a file write, a DNS query. An alert is a system flagging a specific event or pattern of events as worth a human's attention, based on a rule or model. An incident is what an alert becomes once an analyst confirms it represents an actual security violation requiring a response. Most alerts are not incidents — the whole job of triage is separating noise from the handful that are.

A false positive fires on something benign — costs analyst time and, at scale, causes alert fatigue where real alerts get missed in the noise. A false negative misses something malicious entirely — the attacker operates undetected. Neither is "worse" in isolation: a SOC tuned only to kill false positives will raise its detection threshold and start missing real attacks (more false negatives), and vice versa. The actual job is continuously tuning that trade-off, and tracking both rates as a detection-quality metric, not just chasing a quiet queue.

Endpoint Detection and Response agents (CrowdStrike, Defender for Endpoint, SentinelOne) continuously record process, file, network, and registry activity on the endpoint and stream it to a backend for correlation, rather than only comparing files against a signature list. Antivirus mostly asks "have I seen this exact malicious file before?" EDR asks "does this sequence of behavior look malicious?" and gives analysts a process tree and timeline to investigate, plus remote response actions (isolate host, kill process, pull a file).

An Intrusion Detection System watches traffic (or host activity) and alerts on suspicious patterns — passive, out of the direct path. An Intrusion Prevention System sits inline and can actively block or drop the traffic in real time. IPS gives you automatic containment but carries the risk of false positives blocking legitimate traffic, so many teams run new IPS signatures in detect-only mode before enabling blocking.

A publicly maintained knowledge base of real-world adversary tactics (the attacker's goal, like Initial Access or Lateral Movement) and techniques (the specific method, like Phishing or Pass-the-Hash) observed across actual intrusions. SOCs use it as a common vocabulary — mapping detections to ATT&CK technique IDs so coverage gaps are visible, describing an incident's kill chain in a standard way, and prioritizing detection engineering toward techniques the team currently can't see.

Security Orchestration, Automation and Response tools (Splunk SOAR, Cortex XSOAR, Sentinel's playbooks) take the SIEM's alert as a trigger and automate the repetitive parts of response — enriching an IP against threat-intel feeds, opening a ticket, disabling a compromised account, isolating a host — via a defined playbook, instead of an analyst clicking through the same five tools by hand every time. It doesn't replace analyst judgment; it removes the mechanical toil so analysts spend time on the decisions that actually need a human.

An email designed to trick the recipient into clicking a malicious link, opening a malicious attachment, or handing over credentials/data. Signs: sender domain that looks similar but isn't (typosquatting), urgency or fear framing, a mismatch between the display name and the actual reply-to address, generic greetings, links whose visible text doesn't match the underlying URL, and unexpected attachments (especially macro-enabled Office files or password-protected zips, which evade some scanners). SOCs also check SPF/DKIM/DMARC results on the header, since a domain failing its own authentication policy is a strong signal.

How long raw and normalized logs stay searchable. Too short and you can't investigate an intrusion that dwelled for weeks before detection (median attacker dwell time is still measured in days to weeks industry-wide); too long and storage/licensing costs balloon. Most SOCs tier it: hot/searchable storage for 30–90 days for fast triage, cheaper cold/archive storage for 1+ years to satisfy compliance (PCI-DSS, HIPAA, SOC 2) and support retrospective hunts once a new IOC or technique becomes known.

A vulnerability is a weakness (unpatched CVE, misconfiguration). An exploit is the code or technique that takes advantage of that weakness. A threat is the actor or event that could exploit it — a specific ransomware group, an insider, a nation-state APT. Risk is a function of all three plus the asset's value: a critical vulnerability with no known exploit and no motivated threat actor targeting you is a lower operational priority than a medium vulnerability being actively exploited in the wild against your industry.

First, understand what the rule is actually detecting and why it fired — read the detection logic, not just the alert title. Pull the raw event and surrounding context: same host/user in the minutes before and after, related alerts, asset criticality (is this a domain controller or a kiosk laptop?). Check it against known-benign patterns (a scheduled job, a known admin's normal behavior) before assuming malice. Enrich indicators — IP reputation, file hash against VirusTotal/threat intel, is the process signed and from an expected path. Decide: close as benign/expected with a note (so the next analyst or the tuning process learns from it), or escalate with a clear summary of what you found and why it's concerning. Speed matters, but a wrong "closed, benign" on a real intrusion is far more expensive than spending two extra minutes.

This is the classic brute-force/password-spray-then-success pattern. Check the source: single IP hammering one account (brute force) vs one IP trying many accounts with a few attempts each (password spray, built to dodge per-account lockout thresholds) vs distributed IPs (credential stuffing from a breached password list, or a botnet). Check whether the successful login's source, time, device fingerprint, and impossible-travel distance from the account's normal pattern are consistent — a login from a new country nine minutes after failed attempts from that same range is a strong compromise signal. Immediate containment if confirmed: force a password reset, revoke active sessions/tokens, check what that account touched after the successful login (this is where lateral movement usually shows up), and check MFA logs — was MFA bypassed, fatigued, or not enrolled at all.

Go to raw evidence, not the alert summary. Pull the actual process tree or packet capture rather than trusting the one-line description. Cross-reference: does this correlate with anything else in the same window (an EDR alert on the same host, an unusual outbound connection, a new scheduled task)? Check context that a rule can't see — is this a known change-managed maintenance window, an approved pentest, a new tool the team just rolled out that nobody added to the allowlist. When genuinely ambiguous, the default should lean toward escalating with your uncertainty stated plainly rather than quietly closing it — a documented "I wasn't sure, here's why, escalating for a second opinion" is far better practice than a guess that turns out wrong.

A model of the stages an intrusion typically moves through: reconnaissance, weaponization, delivery, exploitation, installation, command-and-control, and actions on objectives. During an investigation it helps you reason about where in the chain you caught the attacker and, critically, what must have already happened before the stage you detected, and what could happen next if you don't act. If you catch C2 beaconing, delivery and exploitation already succeeded — the host is compromised, not just "at risk" — and your job shifts from prevention to containment and scoping how far it spread. ATT&CK has largely supplanted it for technique-level detail, but the kill chain is still useful as the high-level narrative structure for an incident timeline.

Look for authentication and access patterns that don't match a user's or service account's normal behavior: a workstation account suddenly authenticating to a dozen other hosts, use of admin protocols (RDP, WMI, PsExec, WinRM) between peer workstations rather than from a jump box, a service account logging in interactively, or the same credentials used from two geographically distant hosts within an implausible time window. Pass-the-hash and pass-the-ticket attacks specifically show up as authentication events with no matching interactive logon or password-change event. EDR process-tree data is often the clearest signal — e.g. `lsass.exe` being accessed by an unexpected process is a strong credential-dumping indicator that frequently precedes lateral movement.

Get the full original headers, not a forwarded copy that can strip or rewrite them. Check SPF/DKIM/DMARC results and whether the sending domain is spoofed or genuinely compromised. Detonate any links and attachments in an isolated sandbox rather than clicking them directly — never from a production endpoint. If malicious, search the mail platform for every other recipient of the same message or sender across the organization (not just the one report), pull it from every inbox it reached, and check whether anyone already clicked or entered credentials, in which case that's now an account-compromise investigation, not just a phishing report. Feed the confirmed IOCs (sender, URLs, hashes) into the email gateway and threat-intel platform so the same campaign is auto-blocked next time.

Start from the actual false positives, not guesswork: what specifically do they have in common — a particular host group, process, service account, time window? Narrow the rule's scope to exclude that pattern precisely (an explicit allowlist entry with a documented reason and review date) rather than broadly raising the threshold, which quietly reduces sensitivity everywhere including for real attacks that resemble the noisy pattern. Track the false-positive and true-positive rate before and after the change. If a legitimate business process keeps triggering a security-relevant rule, that's often worth raising with the process owner — sometimes the "noise" is itself a finding (e.g. a script running with more privilege than it needs).

Threat intel is contextual information about active threats — known-bad IPs/domains/hashes (tactical), adversary TTPs and campaigns (operational), and strategic trends relevant to your sector or leadership. Day to day, a SOC mostly consumes tactical intel automatically: the SIEM or SOAR platform enriches every alert's IPs, domains, and hashes against feed data in real time so an analyst sees "this IP is on three ransomware-affiliate blocklists" without a manual lookup. Operational intel (a new APT group's TTPs) feeds detection engineering — write or prioritize rules matching techniques you don't yet detect. The trap is treating every feed hit as gospel: feeds have false positives too (shared hosting IPs, expired-but-listed domains), so intel is one input to a decision, not an automatic verdict.

A documented, unbroken record of who collected a piece of evidence (a disk image, a log export, a memory dump), when, how, and who has handled it since — with hashes proving it wasn't altered after collection. It matters for two reasons: if the incident ever leads to legal action or law-enforcement referral, evidence without a clean chain of custody may be inadmissible or challengeable; and even without litigation, a documented process protects the investigation's own integrity — you can prove your findings weren't accidentally corrupted or tampered with mid-investigation.

Instead of designing detection purely around stopping the initial intrusion, you assume an attacker will eventually get an initial foothold and focus equally on detecting what they do after that — lateral movement, privilege escalation, data staging, exfiltration. It's the operating philosophy behind zero trust and behind proactive threat hunting: rather than waiting for a perimeter alert, you periodically hunt for the behavioral signs of a foothold that never tripped a rule, on the assumption that some fraction of intrusions never will.

Regular, periodic outbound connections at a suspiciously consistent interval (classic beaconing), especially to a newly registered or rare-reputation domain, over an unusual port for the protocol, or using domain fronting/DNS tunneling to hide inside traffic that looks legitimate (DNS queries with abnormally long or high-entropy subdomains are a common tunneling tell). JA3/JA3S TLS fingerprinting can flag malware families reusing the same TLS client library signature even when the destination domain changes. Beacon jitter (randomizing the interval slightly) is a common evasion, so detection usually looks for a statistical pattern across many connections rather than one exact fixed interval.

Severity alone isn't enough — combine it with asset criticality (a critical-severity alert on a test VM may matter less than a medium-severity alert on a domain controller or a system holding customer data) and confidence (a well-tuned rule with a low false-positive rate deserves faster attention than a noisy one). Alerts indicating active, ongoing action (live C2 beaconing, active data exfiltration) generally beat ones indicating something that already concluded (a completed, contained event from hours ago). Most mature SOCs encode this as an explicit priority/risk score rather than leaving it to individual judgment under pressure, precisely because triage quality degrades when the queue is long.

The standard phases (NIST SP 800-61): Preparation — playbooks, tooling, and contacts exist before you need them, not improvised mid-incident. Detection & Analysis — confirm it's real, scope what's affected, establish a timeline. Containment — short-term (isolate the host, disable the account, block the IP) to stop the bleeding without destroying evidence, then longer-term containment while you plan eradication. Eradication — remove the actual cause: the malware, the backdoor, the compromised credential, the vulnerability that let them in. Recovery — restore systems from clean backups or rebuilds, verify integrity, monitor closely for re-compromise before declaring it over. Post-Incident — a blameless retrospective: what detection gap let this happen or delayed response, what would have caught it sooner, and turn those findings into new detection rules, patched processes, or training — otherwise the same class of incident recurs.

Contain before you investigate further — every minute of analysis is more data encrypted. Isolate affected hosts from the network immediately (network isolation via EDR or switch port shutdown, not necessarily powering off, since a live memory dump for forensics is valuable and abrupt shutdown can also trigger destructive payloads in some malware). Disable or reset credentials the ransomware may be using to spread, especially any domain admin or service account showing unusual activity. Identify and isolate the patient zero and the spread vector if visible (a compromised RDP endpoint, a phishing payload, an exposed vulnerable service) so you can block that path, not just the symptom. Notify incident command/leadership early — ransomware has legal, PR, insurance, and potentially regulatory-notification implications that need to start in parallel with technical response, not after. Do not restore from backup or pay anything until scope is understood — restoring too early into a network the attacker still has a foothold in just gets re-encrypted.

Start from a hypothesis, not a fishing expedition: "if an attacker used technique X (e.g. living-off-the-land binaries for lateral movement), what would that look like in our data, and can I find it?" Ground hypotheses in ATT&CK techniques relevant to your threat model and industry, and in gaps your current detection rules don't cover. Hunts need good data first — if a technique wouldn't be visible in your current log sources at all, that's itself a finding to fix before hunting for it. Document every hunt regardless of outcome: a hunt that finds nothing still tells you a technique isn't present (or that your visibility for it is insufficient, which is a different, important finding). Anything a hunt finds manually should graduate into an automated detection rule so you don't have to manually hunt for the same thing again next quarter — that's the actual output of a mature hunting program, not just one-off findings.

Map current detection coverage against ATT&CK to find gaps — techniques relevant to threats targeting your industry that you currently can't see at all. Prioritize by a combination of how likely the technique is to be used against you, how severe it would be if it succeeded, and how feasible it is to detect reliably with your current data sources (some techniques are cheap to detect, others need a data source you don't collect yet, which becomes its own project). Write detections against behavior, not just static indicators, so they survive an attacker changing tools. Validate every new rule against both known-malicious samples (does it actually fire) and normal production traffic over a realistic period (what's its false-positive rate) before it goes live generating pages. Treat detections as living artifacts with an owner and a review cadence — techniques and normal baseline behavior both drift over time, and an untested rule six months old is a liability, not a safety net.

MTTD (mean time to detect) and MTTR (mean time to respond/remediate) are the headline pair — how long an intrusion dwells before you see it, and how fast you contain it once you do. Alert-to-incident ratio and false-positive rate per rule tell you about detection quality and analyst load, and matter more than raw alert volume. Coverage against ATT&CK (what fraction of relevant techniques you can actually detect) is a proactive metric, since MTTD/MTTR only measure what you already caught. The trap to avoid: optimizing purely for a lower MTTR by encouraging fast, shallow closures inflates the metric while quietly increasing missed or mis-scoped incidents — metrics need to be paired with quality sampling (spot-auditing closed tickets), not taken at face value alone.

Structurally, reduce the raw volume through tuning and automation before asking analysts to "just work faster" — SOAR playbooks should absorb the mechanical, repetitive triage steps so humans spend attention on judgment calls. Rotate analysts through different queue types and shift threat-hunting or detection-engineering time into the schedule so Tier 1 isn't purely reactive triage forever; that variety and growth path is itself a retention lever. Track queue backlog and per-analyst alert count as an operational health metric, not just a security metric — a sustained overload predicts both missed incidents and attrition. Culturally, a blameless review process for missed or mis-triaged alerts matters: analysts who fear punishment for an honest miss will hide uncertainty instead of escalating it, which is worse for detection than the miss itself.

An insider already has legitimate credentials and often legitimate reasons to access sensitive systems, so the signal isn't "unauthorized access" but anomalous use of authorized access: unusual data volumes downloaded or exported, access to data outside their normal role scope, access at unusual hours, use of personal cloud storage or USB devices against policy, or access shortly before a resignation date. This requires much closer coordination with HR and Legal than a typical external-attacker case — investigative steps, evidence handling, and even who on the SOC team is read in need to follow a defined, restricted process from the start, both for legal defensibility and because premature or leaked internal investigation can itself cause harm. Data loss prevention (DLP) tooling and user behavior analytics (UEBA) baselines are the primary technical inputs, more than traditional network/endpoint IOCs.

Lead with business impact and confidence level, not technical detail: what's affected, is it ongoing or contained, what's the worst-case exposure (data types, customer count, regulatory triggers) and how confident are you in that scope right now versus how it might change. Give a clear next-update time and stick to it, even if the update is "no material change" — silence during an active incident erodes trust faster than bad news delivered on schedule. Separate confirmed fact from working hypothesis explicitly ("we know X happened; we suspect but haven't confirmed Y") so decisions made on your report aren't built on a guess presented as certainty. Loop in Legal and Comms early on anything with potential regulatory notification requirements (GDPR, state breach-notification laws, sector-specific rules) — those clocks can start ticking from the moment of detection, not from when the investigation concludes.

Check the process's parent chain and file path/hash reputation immediately — a legitimate backup or monitoring tool sometimes touches LSASS for benign reasons, but an unsigned binary from a temp or user-writable directory doing it is a strong credential-dumping signal (Mimikatz and similar tools work this way). Isolate the host from the network via EDR while you confirm, since credential theft is usually a precursor to lateral movement — don't wait for full confirmation before limiting blast radius. Pull the full process tree and check for related activity: was this process itself dropped by something else (a phishing payload, a macro)? Assume any credentials cached on that host are compromised and force a reset/session revocation for accounts that logged in there recently, prioritizing anything privileged. Escalate to Tier 2/IR immediately rather than closing solo — this pattern is high-confidence enough to treat as a likely active intrusion until proven otherwise.

Don't block blind and don't ignore it either. Verify with the system/app owner whether that domain is an expected third-party dependency — check change records and existing firewall rule documentation first so you're not waking someone up for something already known-good. If it's genuinely unexplained, isolate cautiously: block outbound at the network layer while keeping the host itself running if taking it fully offline would cause unacceptable business impact, and closely monitor for any other suspicious activity from that host in the meantime. Escalate with both technical findings and business-impact context so the decision to fully contain (accepting downtime) versus continue investigating live is made with the right stakeholders, not unilaterally by whoever's on shift.

Treat the account as compromised immediately: force a password reset and revoke all active sessions/tokens, don't just change the password and assume old sessions are safe. Check MFA status — if MFA wasn't enrolled, enroll it now; if it was enrolled and somehow bypassed (an adversary-in-the-middle phishing kit that relays MFA in real time), that's a more serious finding worth escalating, since it means the phishing kit is more sophisticated than a basic credential-harvesting page. Review the account's activity since the click for any sign the attacker already used the credentials — new mail rules, unusual sent mail, new OAuth app grants, unfamiliar sign-in locations. Feed the phishing URL/sender into the email gateway and search for other recipients of the same campaign across the organization.

First, fix the pipeline and confirm ongoing ingestion is healthy — you can't investigate the gap while still bleeding it. Then treat the gap itself as a security-relevant event, not just an ops incident: 12 hours of blind spot is exactly the kind of window an attacker could exploit or that could hide the early stage of an ongoing intrusion, so once logs resume, actively look for anything suspicious in the period immediately surrounding the outage on both sides. Check whether any log sources have local retention that lets you backfill the gap (many endpoint agents and firewalls buffer locally even if the central pipeline is down) — recovering that data is worth the effort. Root-cause the outage and, importantly, add monitoring on the pipeline's own health (a "dead man's switch" alert if expected log volume drops sharply) so a future outage is caught in minutes, not discovered the next morning.

Handle the missed incident's technical fallout first — scope and remediate it like any other incident. Separately, address the process gap without making it purely a personal failing conversation: review what made the alert look benign at a glance, whether the triage runbook for that alert type was clear enough, and whether the analyst had the context (asset criticality, recent similar alerts) needed to make a good call quickly. If the queue volume or time pressure contributed, that's a staffing/tuning problem, not just a training one. Use it to improve the triage checklist or add an automated enrichment step that would have surfaced the red flag automatically next time, so the fix scales beyond one analyst's judgment.