SOC Analyst interview preparation

An alert is a claim that needs investigation, not a verdict. Start by restating it in observable terms: a synthetic workstation generated several failed sign-ins followed by one success. Record the alert identifier, timestamps, timezone, affected account and detection logic. Preserve the original event export before adding annotations. Your first artifact is a short case record separating observed facts from hypotheses, such as password guessing, a forgotten password or an automated service using stale credentials.

Verify that the underlying events exist and that their fields mean what the alert assumes. Compare event time with ingestion time, check whether repeated records are duplicates, and identify missing telemetry. Add asset importance and account privilege before assigning priority. A similar pattern on a disposable training account and a privileged production administrator can require different responses. The decision should explain uncertainty rather than converting a technical score or alert label directly into business impact.

In an isolated lab, create synthetic failed and successful authentication records without attacking any service. Ask a partner to review whether your evidence supports escalation, further investigation or closure. Document the next evidence request and the person authorised to approve containment. Disabling an account or isolating a device requires documented authority, even when urgency is high. Use NIST's incident-response framework to organise the handover, while keeping operational actions specific to your organisation's procedures and available telemetry.

Windows investigations depend on logging configuration as much as analyst skill. Security Event 4688 records process creation when the relevant auditing is enabled; command-line details require additional configuration and can expose sensitive arguments. Event 7045 records service installation in the System log, not the Security log. Build a collection checklist that names each channel, configuration dependency and retention limit. This prevents an absent event from being incorrectly treated as proof that an action never occurred.

Use an owned Windows virtual machine to launch a known, harmless program and inspect the resulting process records. Capture process identifiers, image paths, parent information, account context and timestamps where available. Process identifiers can be reused, so correlate them with time and other identifiers instead of joining on the number alone. Your artifact should be a small timeline explaining what launched, under which account, and which facts remain unavailable because the relevant logging was not enabled.

For service activity, inspect a synthetic 7045 record rather than installing an unknown executable. Compare the service image path and account with an approved baseline, then seek process or administrative-change evidence. A new service may be legitimate software deployment, persistence or an incomplete installation. Recommend validation with the system owner before removal. If containment is authorised, record the exact change and restoration procedure; indiscriminate service deletion can destroy useful evidence or interrupt essential business functions unnecessarily.

Identity alerts require a sequence of evidence rather than a single unusual IP address. In Microsoft Entra sign-in records, examine the account, application, authentication outcome, conditional-access result and available device details. Treat location as an investigative clue because VPNs and network routing can distort it. Preserve the original record and note access limitations. Your initial question is whether the authentication was expected, not whether an unfamiliar country name automatically establishes that an attacker controls the account.

Separate authentication evidence from administrative-change evidence. Entra SigninLogs describe sign-ins, while Entra AuditLogs cover directory changes such as directory-role assignments. AzureActivity records Azure subscription management activity and does not substitute for either dataset. Correlate a suspicious authentication with later directory or resource changes using timestamps and stable identifiers. Your artifact should label the source of every event so another analyst can reproduce the reasoning without assuming all Microsoft cloud logs contain the same operations.

Create synthetic records for an expected VPN sign-in and an unexpected sign-in followed by a privilege change. Compare what additional evidence each case needs, including user confirmation through a trusted channel and an approved change ticket. Decide whether to monitor, escalate or recommend session revocation. Perform account containment only under documented authority, and preserve relevant records first when feasible. Explain that revoking sessions may not immediately invalidate every application session or reverse changes already made elsewhere.

Preserve a suspicious email as an original .eml file before copying text into a ticket. Record collection time, mailbox context and a hash using an approved local tool. Keep confidential content within authorised evidence storage. Read the Received chain starting at your trusted mail boundary and work backwards only as far as the evidence remains trustworthy. Headers supplied before that boundary may be forged, so a visually impressive chain does not establish the sender's actual origin.

Compare the visible From address, envelope sender, Reply-To destination and link domains. Evaluate SPF, DKIM and DMARC results recorded by your trusted receiving system, including alignment with the visible From domain. SPF authorises sending infrastructure, DKIM validates a signed message under a domain, and DMARC evaluates aligned authentication. A pass is not proof of benign content: attackers can authenticate their own domains or misuse compromised legitimate accounts. Your artifact should explain each result without reducing the investigation to pass or fail.

Use a synthetic message containing a link to https://accounts.example/reset and no executable attachment. Inspect the URL as text, compare the claimed organisation with the destination, and document the requested action and urgency cues. Do not browse unknown links from a workstation or upload the message to public tools. Decide whether the evidence supports a phishing classification, a suspicious-but-unconfirmed result or legitimate communication. Any mailbox search, message removal or sender blocking must follow documented authority and approved procedures.

Detection engineering turns an investigative idea into a testable rule with known limitations. Start with a hypothesis such as repeated connections from an owned workstation to a lab service outside its normal pattern. Define the required fields, observation window and expected benign explanations. Use synthetic records or a capture from an isolated network you control. A threshold chosen for this exercise is a lab example, not an industry benchmark or a production-ready statement of malicious behaviour.

In Wireshark, inspect source and destination addresses, ports, protocol fields and timing, then correlate those observations with endpoint process and application logs. A packet capture usually cannot establish which user intended an action, and encrypted traffic limits payload visibility. DNSSEC authenticates DNS answers, while DoH and DoT encrypt resolver transport; neither prevents every form of DNS abuse. Your evidence table should distinguish directly observed packet facts from endpoint attribution and hypotheses that still need corroboration elsewhere.

Test the proposed rule against a positive synthetic case and a benign lookalike, such as an approved monitoring agent. Record which records matched, which did not, and how missing logs would change the result. Map relevant behaviour to MITRE ATT&CK only when the evidence supports the relationship; ATT&CK is not a complete compliance checklist. Deliver a detection note containing the logic, data dependencies, limitations and a reversible deployment plan, with tuning and containment decisions reserved for authorised owners.