L1 SOC Analyst — Alert Response Workflow

This is the day-to-day routine of a Tier 1 SOC analyst.
L1 scope ends at containment. Eradication, Recovery, and Lessons Learned are L2 / IR territory.

Phase 1 — Alert Received

Step 1 — Read the alert

Note the rule name, severity, source IP, target, and timestamp
Do not act yet — just read and understand what the alert is telling you
Where to look: SIEM → Security Events → alert details

Step 2 — Gather context

Who is the source IP? Internal or external?
Who or what is the target? Is it a critical asset?
What service or port is involved?
Where to look: SIEM → asset inventory / CMDB

Step 3 — Check for prior alerts

Has this IP or account triggered alerts before?
Is this part of a known pattern or ongoing campaign?
Where to look: SIEM → search by IP / account / timeframe

Phase 2 — Triage & Qualification

Decision point 1 — Is this a False Positive?

Ask yourself: does this activity match a legitimate business use?
Could it be a known tool, a scheduled task, or an authorized scan?

Answer	Action
Yes — False Positive	Document why. Close the alert with a clear justification. Suggest SIEM rule tuning if this FP is recurring.
No — keep going	Continue the investigation. Move to step 4.

Step 4 — Confirm the attack pattern

Analyse volume, frequency, targeted account, and timestamps
Does it match a known technique? (brute force, phishing, lateral movement, etc.)
Cross-reference with MITRE ATT&CK

Decision point 2 — Was there a successful logon or execution?

Look for: Event ID 4624 (Windows) / successful auth log / unexpected process spawned.
Any sign the attacker actually got in?

Answer	Action
Yes — escalate immediately	Stop. Write a clear summary and hand off to L2 right away. Do not attempt containment alone.
No — continue at L1	No breach confirmed. Proceed to containment within your scope.

Phase 3 — Containment (L1 scope)

Step 5 — Block the source

Block the source IP at the firewall or add a SIEM suppression rule
Document exactly what you blocked and at what time
Firewall / SIEM → block rule → log the action

Step 6 — Restrict the targeted service

Disable or limit access to the exposed service (RDP, SMB, SSH, etc.)
Only do this if it is safe and will not impact production

Important: if any containment action could affect availability of a business-critical service, stop and check with your L2 or team lead first.

Phase 4 — Documentation

Step 7 — Document everything (do this continuously, not just at the end)

Timeline of events
Source IP and target
Attack pattern and techniques observed
All actions taken and their timestamps
Verdict: True Positive / False Positive / Benign
Write it as if someone else will read it tomorrow

Ticketing system / case management → INC-XXXX

Step 8 — Set monitoring

Add a watch on the source IP and targeted account for at least 24h
Note any recurrence and link it back to the original case

Phase 5 — Close or Hand Off

If resolved at L1

Close the case with a clear verdict and summary
Make sure all actions are logged

If escalated to L2

Hand off a clean written brief including:

Source IP and target
Full timeline
Actions already taken
Open questions or uncertainties

Key Rules to Remember

Document as you go — never reconstruct from memory at the end
When in doubt, escalate — a good L1 who escalates fast is more valuable than one who guesses
Never touch production without checking with your team lead first
A clean handoff to L2 is a win — your job is to triage, contain, and brief, not to solve everything alone

Quick Reference — Windows Event IDs

Event ID	Meaning	Action
`4625`	Failed logon	Volume spike → brute force indicator
`4624`	Successful logon	Check if expected → escalate if not
`4648`	Logon with explicit credentials	Lateral movement indicator
`4720`	User account created	Persistence indicator
`4732`	User added to privileged group	Privilege escalation indicator

References: NIST SP 800-61 Rev. 2 · PICERL (SANS Institute) · MITRE ATT&CK