SOC Promotional Prep

Walk me through how you triage a high-severity alert.

Validate alert → identify asset/user → review supporting logs → build timeline → determine scope/impact → escalate or close with justification.

Brute force followed by successful login—what first?

Check auth logs for IP, geolocation, MFA status, login type, failure pattern, and post-login activity.

What do you need before escalating to Tier 2/IR?

Evidence, timeline, scope, impacted assets/users, and initial impact assessment.

How do you prioritize multiple alerts?

Severity + asset criticality + attack stage + blast radius + time sensitivity.

Key log sources for endpoint investigations?

Process creation logs, EDR telemetry, Sysmon, PowerShell logs.

Key log sources for network/auth investigations?

AD logs, VPN logs, DNS logs, proxy logs, firewall logs.

How do you investigate suspicious PowerShell?

Check command line, encoding, parent process, script logs, network connections, and user context.

Indicators of DNS tunneling?

High query volume, long encoded subdomains, TXT records, NXDOMAIN spikes, beaconing patterns.

Signs of account compromise in auth logs?

Impossible travel, MFA anomalies, brute force patterns, unusual device/user-agent, new login locations.

How do you validate phishing email?

Check headers, sender spoofing, link analysis, attachments, sandboxing, and org-wide prevalence.

How do you use SIEM in investigations?

Correlate logs across systems to build timeline using user, IP, host, and process pivots.

Common SIEM queries

User activity, IP correlation, failed/successful logins, process execution, time-based chains.

How do you pivot from an alert?

Start from entity → expand to process tree → auth logs → network connections → related events.

When do you isolate a host?

Confirmed malware, active C2, credential dumping, lateral movement, or high-confidence compromise.

Containment vs monitor-only?

Containment = high confidence/impact risk; monitor-only = low confidence or isolated signal.

How do you handle uncertainty?

Document findings, state confidence level, escalate with evidence rather than assumptions.

Common ATT&CK techniques in SOC?

Phishing, brute force, PowerShell execution, persistence methods, lateral movement, C2 traffic.

How does lateral movement appear in logs?

Multiple system logins, SMB/RDP spikes, remote service creation, NTLM activity.

Credential dumping vs password spraying?

Dumping = extract credentials from system; spraying = try common passwords across many accounts.

Common persistence techniques?

Scheduled tasks, registry run keys, new users, services, WMI subscriptions.

Describe a complex incident you handled.

situation → task → actions → result with focus on investigation steps.

Tell me about a mistake you made.

Explain mistake → impact → what you learned → how process improved.

How do you handle feedback?

Apply it immediately and validate improvement in future investigations.

Alerts are noisy but you can’t tune them—what do you do?

Improve triage, document false positives, escalate for tuning, refine investigation filters.

No clear IOC—what now?

Expand scope, pivot on related entities, build timeline, analyze behavior.

Speed vs accuracy?

Accuracy for high severity; efficiency through structured workflow.

You receive a high severity alert for suspicious PowerShell execution on a user workstation.

First, I’d validate the alert details—what PowerShell command triggered it, whether it was encoded, and what the parent process was. Then I’d identify the user and host and determine whether PowerShell use is expected based on their role or normal activity. I’d pivot into related logs—other endpoint events, authentication logs, and network connections—to see if there’s additional suspicious behavior or broader impact. If it appears legitimate but unclear, I’d validate with the user; if malicious indicators are present, I’d escalate and begin containment recommendations

You receive an alert for multiple failed VPN logins, followed by a successful login from the same account.

How do you investigate whether this is account compromise or just a user mistyping their password?

First, I’d review the VPN logs to identify the source IP, geolocation, device, and timing of the failed attempts followed by the successful login. I’d determine whether the pattern looks like normal mistyping or a brute force attempt—for example, a few failures versus many rapid attempts. Then I’d check MFA logs and review post-login activity for unusual behavior like access to new systems or privilege changes. Finally, I’d compare it to the user’s normal login patterns and, if needed, contact the user to confirm legitimacy.

You have three alerts at once:

1. Malware detected on a workstation

2. Multiple failed logins on a shared service account

3. A phishing email reported by a user

How do you prioritize these, and why?

First, I’d prioritize the malware detection because it may represent an active compromise and could require immediate containment, such as host isolation. Second, I’d investigate the failed logins to determine whether there was a successful authentication or signs of account compromise, since credential abuse could lead to broader access. Third, I’d review the phishing report—while important, it’s lower priority unless there’s evidence the user clicked or executed something, in which case it may move higher. My prioritization is based on active threat, potential blast radius, and urgency.

You investigate an alert and there’s no obvious IOC—no bad hash, no known bad IP, no signature hit.

How do you investigate when there’s no clear indicator of compromise?

First, I’d review the alert logic to understand exactly what behavior triggered it. Since there’s no obvious IOC, I’d shift to behavioral analysis—pivoting on the user, host, process, and timeframe to build a timeline. I’d look for anomalies like unusual parent-child processes, abnormal authentication activity, unexpected network connections, or persistence mechanisms. The goal is to determine whether the behavior is malicious, suspicious, or expected based on context—not just whether it matches a known bad indicator.

A senior analyst disagrees with your alert severity. You think it’s high, they think it’s medium.

How do you handle that?

First, I’d explain my reasoning using the evidence I found—why I believe the alert is high severity, such as impact, scope, or attack stage. I’d listen to the senior analyst’s perspective and align on the facts rather than treating it like a disagreement of opinion. If immediate action is needed, I’d follow the agreed path, but afterward I’d revisit it constructively to understand the decision and improve future consistency.

A detection fires repeatedly and you suspect it’s a false positive, but you’re not allowed to tune rules yourself.

What do you do?

I’d document repeated examples showing why it appears to be a false positive—what triggers it, what makes it benign, and how often it occurs. I’d quantify the impact, like alert volume or analyst time spent, and then recommend a specific tuning change to the engineering or detection team. Until it’s tuned, I’d update my triage process so the team can handle it consistently without missing a true positive.

A user reports a phishing email and says they clicked the link.

What are your next steps?

First, I’d determine what happened after the click—whether it was just a page visit, a credential harvest, or a malware download. If credentials may have been entered, I’d immediately reset the password, revoke active sessions, and review MFA activity. I’d then check endpoint and network logs for any malicious downloads or connections, and review email logs to identify whether other users received the same message. Finally, I’d scope impact and escalate if there’s evidence of compromise.

A host shows PowerShell launching from Word.

What’s your first thought, and what do you investigate next?

My first thought is possible malicious macro execution or document-based malware because Word should not normally spawn PowerShell. I’d inspect the PowerShell command line for encoding, download commands, or execution policy bypass flags, then confirm the parent-child relationship in the process tree. Next I’d check for network connections, dropped files, persistence mechanisms, and whether the user recently opened an email attachment or downloaded a document.

You see repeated DNS requests to long random subdomains every 30 seconds.

What does that suggest, and how would you investigate it?

The regular interval suggests beaconing, and the long random subdomains raise concern for DNS tunneling or command-and-control traffic. I’d check the domain reputation, age, and threat intelligence first, then inspect the subdomains for signs of encoding or exfiltration. Next, I’d identify which host and process is generating the DNS requests, review query types like TXT records, and determine whether this is malware communication or potential data exfiltration.

Tell me about a time you missed something during an investigation. What did you learn from it?

During a phishing investigation, I initially focused too heavily on technical email authentication indicators like SPF, DKIM, and DMARC and missed that the sender was using a lookalike domain with a subtle character change—an added ‘s’ and a swapped ‘i’. That taught me not to anchor on one part of the analysis too early. Now I deliberately slow down and review the full picture—sender details, domain spelling, headers, links, and message context—before making a determination.

FTP (Data Transfer)

20

SSH (Secure Shell)

22

Telnet (Remote Login)

23

SMTP (Simple Mail Transfer Protocol)

25

DNS (Domain Resolution)

53

HTTP (Web Browsing)

80

HTTPS (Secure Web Browsing)

443

FTP (Control)

21

DHCP (Server to Client)

67

DHCP (Client to Server)

68

TFTP (Trivial File Transfer)

69

SMB (File Sharing)

445

RDP (Remote Desktop)

3389