New SOC Analyst Survival Guide: SIEM Queries, Alert Triage, and Your First 90 Days
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The first 90 days as a SOC analyst feel like information overload by design. The alert queue is never empty. Every investigation opens five new browser tabs. Other analysts seem to know at a glance whether an alert matters while you are still figuring out where to look. The gap between what you learned in training and what the job actually requires feels enormous.
This is normal. The skill gap is real, and it closes through repetition — but repetition without a framework produces slow learning. This guide gives you the framework: how to think about triage decisions, the specific SIEM queries that answer the most common investigation questions, how to write an escalation that earns respect from L2 analysts, and the deliberate practice habits that compress the experience curve.
The triage mindset: context over signatures
The foundational mental model shift for new SOC analysts is recognizing that security alerts are not self-contained verdicts. The same detection rule can fire on both a legitimate IT administrator running a routine task and an attacker executing the same command, and the alert itself contains no information that distinguishes between them. Context is what distinguishes the two: who ran the command, from which host, at what time, following what prior activity, on a system with what level of criticality. New analysts who treat alerts as binary pass-or-fail tests spend significantly more time per alert than experienced analysts who immediately reach for contextual information. Building the habit of checking user role, host criticality, historical behavior, and change management records before forming a hypothesis is the highest-leverage skill improvement available in the first 30 days.
Three questions that determine triage outcome
Before looking at any alert details: (1) Who is the subject? Pull up the user or host in your asset inventory — what is their role, their department, and what systems they normally access? A PowerShell execution by a developer is different from the same execution by an executive whose job does not involve IT tools. (2) Is this behavior normal for them? Check the same user's or host's history for the same alert type over the past 30 days — if the same alert fires on this user every Tuesday during the maintenance window, it is almost certainly not a threat. (3) What is the business context today? Check your organization's change management calendar for scheduled maintenance, deployments, or penetration tests — a port scan alert during a scheduled pentest is not an incident. Most FP alerts fail all three tests: the user's role fits the activity, the activity matches their history, and there is a business reason for it.
Asset criticality: the triage multiplier
The same alert on a guest WiFi kiosk and on a domain controller warrants completely different response urgency. Build a mental (or documented) model of your organization's most critical assets: domain controllers and Active Directory servers, servers that store customer data or payment data, developer machines with production deployment access, executive laptops that may be targeted for VIP phishing, and network devices that have privileged routing or VPN access. An alert on any of these warrants faster response and lower false-positive tolerance. When overwhelmed with queue depth, apply asset criticality as your first sort key — critical asset alerts move to the front regardless of alert type.
Foundational investigation workflows
Two alert types account for the majority of L1 SOC analyst investigations: suspicious authentication events (unusual login location, failed login followed by success, login at an unexpected hour) and suspicious process execution (known-malicious binary name, anomalous parent-child process relationship, encoded command execution). Each has a repeatable investigation sequence that, once learned, can be executed in 10-15 minutes rather than the 45-60 minutes a new analyst typically spends when improvising. The authentication investigation centers on SIEM queries against Windows Security EventCode 4624 and 4625 combined with IP reputation checks and user behavior baseline comparison. The process execution investigation centers on parent-process analysis in EDR, command-line content inspection, network connection correlation, and file hash lookup on VirusTotal. Memorize both sequences before your first week is over.
Suspicious login investigation
Alert: authentication from an unusual location, failed logins followed by success, or login at an unusual hour. Investigation sequence: (1) Pull all authentication events for the user in the past 24 hours (EventCode 4624/4625 for Windows, sign-in logs for Entra ID or Google Workspace). (2) Check the source IP — is it a known VPN exit node, a corporate IP, or a residential/datacenter IP in an unusual country? Use WHOIS and IP reputation databases (VirusTotal, Shodan). (3) Check what the user did after login — if they immediately accessed sensitive data, changed their profile, or set up email forwarding rules, escalate immediately. (4) Contact the user if available — a 30-second Slack message asking 'Are you working from [location] today?' often resolves ambiguous cases instantly. Document your findings before closing or escalating.
Malicious process execution investigation
Alert: detection of known-malicious process name, execution of unsigned binary, or anomalous parent-child process relationship. Investigation sequence: (1) Look at the parent process — legitimate software has predictable parent processes (explorer.exe launches user applications, svchost.exe launches services). If powershell.exe was launched by winword.exe, that is a macro execution and almost certainly malicious. (2) Look at the command line of the process — EDR and Windows Security event logs capture the full command line. Base64-encoded commands, -EncodedCommand flags, and bypass flags in PowerShell are high-confidence malicious indicators. (3) Look at the network connections from the process — EDR tools show which network connections were made by the process. An external connection from a system process is usually malicious. (4) Check VirusTotal with the process hash — most EDR tools show the file hash. A 10/70 VirusTotal detection rate is very different from 0/70.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Writing escalations that get results
The quality of your escalation note directly determines how quickly an L2 analyst can act on your finding and how your analytical capability is perceived by senior team members. A note that contains only 'this looks suspicious' forces the L2 analyst to repeat most of your investigation from scratch, which erodes trust in your judgment and delays the response. A note that answers all seven contextual questions outlined in the FAQ section turns an L2 analyst's 30-minute re-investigation into a 5-minute confirmation step. Senior analysts consistently report that escalation quality is the single biggest factor in how quickly new analysts earn the autonomy to handle more complex alerts. Developing a personal escalation template in your first week and using it on every escalation, even when it feels unnecessary, builds the discipline that separates methodical analysts from reactive ones.
The five-element escalation structure
Every escalation note should contain: (1) Alert summary: what fired, when, on what asset or user. (2) Context gathered: what you found about the user/host background, historical behavior, and business context. (3) Corroborating evidence: log lines or SIEM query results that support the escalation (paste 2-3 relevant log lines, not 200). (4) Your hypothesis: what attack technique or threat category this looks like, with a MITRE ATT&CK technique reference if applicable. (5) Your confidence and recommended action: 'High confidence this is a real threat, recommend host isolation' or 'Medium confidence, recommend verification with user before containment.' An escalation with all five elements earns a reputation as a thorough analyst. An escalation with just 'this looks suspicious' creates re-work for the L2 analyst and a follow-up to you asking for the context you should have gathered.
The bottom line
Your first 90 days as a SOC analyst are about building mental models, not just technical skills. The most important models: context determines maliciousness (not alert signatures alone), asset criticality determines response urgency, and every investigation should end with a documented hypothesis regardless of whether you close or escalate. Use MITRE ATT&CK to look forward (what comes next in the attack chain?) during investigations, not just to categorize what you already found. Write escalation notes that include your thinking, not just your observations — L2 analysts who see your analytical process will teach you more, review your work faster, and trust your escalation judgment sooner. The experience gap closes through deliberate repetition with reflection, not just volume of alerts processed.
Frequently asked questions
How do I decide whether an alert is a true positive, a false positive, or a benign true positive?
The three-way classification: True positive (TP) — the alert fired correctly and the activity is genuinely malicious. False positive (FP) — the alert fired but the activity is legitimate (a security scanner running a test, an IT admin using an admin tool, a developer testing their own code). Benign true positive (BTP) — the alert fired correctly (the activity matches the detection logic), but the activity was authorized and expected (antivirus update running an unusual process that matches a malware detection rule). To determine which: (1) Who did this action? Is it an expected user for this activity? (2) When? Is this time-of-day and day-of-week normal for this user and asset? (3) What other context surrounds this event in the logs 5 minutes before and after? (4) Does this match any recent change management tickets or expected maintenance windows? An activity that has no context explanation after 10 minutes of investigation should be escalated, not resolved as FP.
What are the most important SIEM queries a new analyst should know?
Foundational SIEM queries by investigation type (using KQL-style pseudocode, adapt to your SIEM): User login investigation: index=windows EventCode=4624 user="username" | table time, src_ip, workstation, logon_type — shows all successful logins for a user including source IP and workstation. Failed authentication analysis: EventCode=4625 | stats count by user, src_ip | sort -count — shows login failures by user and source, useful for brute force detection. Process execution by host: EventCode=4688 | search host="target-host" | table time, user, process, parent_process, cmd_line — shows all process executions on a specific host with parent-child relationships. Network connections from host: index=network src_ip="10.1.2.3" | table time, dst_ip, dst_port, bytes — shows all outbound connections from a host, useful for C2 callback investigation. PowerShell execution: EventCode=4688 process_name="powershell.exe" | table time, host, user, cmd_line | where match(cmd_line, "encoded|bypass|hidden|noprofile") — flags suspicious PowerShell invocations.
What context should I always gather before escalating an alert?
Before escalating, have answers to these questions in your escalation note: (1) What triggered the alert? (specific event details: user, host, time, action). (2) Who is the user involved, what is their role, and is this activity expected for their role? (3) What is the asset involved, what is its business function, and how critical is it? (4) What happened in the 30 minutes before and after the alert? (related events on the same host or by the same user). (5) Is there any threat intelligence context? (known malicious IP, known malware hash, IOC match). (6) What is your hypothesis? (this looks like [X attack technique] because [Y evidence]). (7) What is your confidence level that this is malicious, on a 1-10 scale, and why? An escalation note with these answers turns a 30-minute senior analyst investigation into a 5-minute confirmation and response decision.
How do I investigate a potential malware infection alert?
Malware investigation workflow for a new analyst: (1) Identify the initial alert: what triggered it? Antivirus detection, EDR behavioral alert, network sandbox alert? (2) Look at the infected host: what process was the malware? What parent process launched it (the parent tells you the initial access vector — was it launched by Outlook attachment, a browser download, a Word macro, or a scheduled task)? (3) Check network connections from the infected host: any outbound connections to unusual IPs or unusual ports (high numbered ports, known C2 ports 4444, 8080, 443 to non-CDN IPs)? (4) Check lateral movement: did the infected host make any authentication attempts to other internal hosts after the infection? EventCode=4624 with the infected host as the source IP. (5) Check for persistence: were any scheduled tasks, registry run keys, or new services created around the time of infection? EDR tools show these automatically. Document findings, isolate the host if you find C2 communication or lateral movement, and escalate to L2.
What is the MITRE ATT&CK framework and how do I use it during alert investigation?
MITRE ATT&CK is a matrix of adversary tactics (the why — initial access, execution, persistence, privilege escalation, lateral movement, exfiltration) and techniques (the how — specific methods attackers use to achieve each tactic). Use it during investigations: when you see an alert for a specific behavior (PowerShell with Base64-encoded commands), look it up in ATT&CK (T1059.001: Command and Scripting Interpreter: PowerShell). The ATT&CK technique page tells you: why attackers use this technique, what to look for in other log sources to confirm or rule out malicious use, and what techniques commonly follow this one (the attacker's next steps). Using ATT&CK during investigation means you are looking for the next step in the attack chain in your logs, not just reacting to the current alert. This is the key mental shift from reactive alert processing to proactive threat investigation.
How do I build investigation skills faster in my first 90 days?
Skill-building activities that experienced analysts recommend: (1) Read every escalated case your team closes, including the L2 analysis that was added — this teaches you what experienced analysts found that you missed and why it mattered. (2) Review false positive cases your team marks as FP and understand the specific evidence that made them FP — this builds pattern recognition faster than any course. (3) After completing each alert investigation, write a one-paragraph explanation of what you found, why you made the decision you did, and what you would look for next time — the act of writing forces precision in thinking. (4) Set up a personal lab with free trial accounts of SIEM products and generate your own alerts by simulating attack techniques against VMs — investigating alerts you generated teaches the detection-to-log correlation that takes months to develop otherwise. (5) Follow threat intelligence sources (CISA advisories, Microsoft MSRC, Mandiant blog) to stay current on active threat actor TTPs that your alerts may be detecting.
What should I do when I am overwhelmed by alert volume and do not know where to start?
Alert prioritization framework when the queue is full: (1) Sort by asset criticality first: if you have 200 alerts and 5 of them are on domain controllers, critical servers, or privileged user accounts, investigate those 5 first regardless of the alert type. (2) Look for correlated alerts on the same host or user across multiple alert types — two or three different alert types firing on the same host or user within the same hour is almost always more interesting than a single alert on a non-critical asset. (3) Check for any CRITICAL severity alerts first — most SIEMs auto-assign severity, and critical severity alerts should have a human look at them within 15 minutes of creation in most SOC SLAs. (4) Communicate with your team lead when queue depth is unmanageable — the right answer to an overwhelming queue is to escalate queue depth to a supervisor, not to investigate at lower quality to keep up with volume. Missed incidents are worse than longer response times.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.