DEV Community: gaurav kundu

How to Triage a Phishing Alert Faster — Without Rebuilding the Process Every Time

gaurav kundu — Tue, 21 Apr 2026 20:38:12 +0000

Most phishing alerts do not take long because they are difficult. They take long because the workflow is inconsistent.

You get the alert.

A user reported a suspicious email. Maybe your mail gateway flagged it. Maybe your SIEM created a case. Either way, you now have the same question every SOC analyst has asked a hundred times:

Is this real, or is this noise?

The problem is not that phishing triage is impossible. The problem is that most teams still do it in a fragmented way.

One analyst checks the headers first. Another starts with the sender domain. Someone else jumps straight to the links. Then comes the write-up, the ticket note, the escalation decision, and the inevitable feeling that you may have missed something small but important.

That is where the time goes. Not in any one check by itself. In the lack of a repeatable process.

Over time, I found that the fastest way to triage phishing was not to become "faster" at each individual step. It was to stop rebuilding the workflow from scratch every time.

This is the process I use now to move from a suspicious email to a structured triage note in minutes instead of dragging the same alert through 20 different micro-decisions.

Why phishing triage often takes longer than it should

Most analysts are doing several things at once when a phishing alert lands: checking sender and reply-to details, reviewing SPF, DKIM, and DMARC, inspecting links and domains, deciding whether the message looks like credential harvesting, malware delivery, or simple spam, and documenting findings for a ticket or escalation.

None of those steps are unreasonable. The slowdown comes from doing them in a different order every time, with different depth, and often with different output formats depending on who is on shift.

First problem: time loss. You keep re-parsing the same raw material manually — raw headers, sender path, suspicious domains, authentication results, URLs and context.

Second problem: inconsistency. Two analysts can look at the same phishing email and produce two very different summaries, severities, and next actions. That is not just a people problem. It is a workflow problem. A structured first-pass triage fixes both.

The workflow I use now

Step 1 — Get the full raw email

The first thing I want is not just the visible message body. I want the full raw email: headers, sender path, authentication results, and the message body.

In Gmail, that means opening the message and using Show original. In Outlook or other mail clients, there is usually a similar option to view the full source.

Why this matters: if you only look at the visible email, you miss some of the most useful phishing indicators — Reply-To mismatches, Return-Path differences, SPF / DKIM / DMARC results, sending infrastructure clues, and message routing signals.

The body tells you what the attacker wants you to believe. The raw email tells you how the message actually traveled. You need both.

Step 2 — Run a structured first-pass analysis

Instead of manually pulling the email apart every time, I paste the raw message into a phishing triage workflow that handles the first-pass parsing for me.

I use SOC.Workflows, which is a browser-based tool I built for exactly this kind of structured analyst workflow. The important part is not the brand. The important part is the sequence.

Paste the raw email into a structured analyzer, and let it do the first-pass breakdown:

sender and reply-to mismatch
SPF / DKIM / DMARC results
suspicious domains or lookalikes
shortened or risky URLs
urgency language and social engineering cues
severity and confidence
recommended next steps

That instantly turns a wall of raw email data into something you can actually reason about. And because the pasted email content is processed in the browser and not sent to a server, you can do that first-pass triage without shipping the raw message off somewhere else.

Step 3 — Review the signals, not just the branding

You stop asking: "Does this look polished?" and start asking: "Do the technical and contextual signals line up?"

A polished email is not trustworthy because it is polished. A passing SPF result is not trustworthy because it passed SPF. A brand logo is not proof of legitimacy. Phishing today often looks clean enough to pass a visual glance. What matters is whether the sender path, destination, and context actually make sense together.

Step 4 — Use AI only after the structure exists

Many people paste the raw email directly into ChatGPT or Claude and ask: "Is this phishing?" That can work sometimes, but it is inconsistent because the input is inconsistent. Raw data is noisy. Structured input is much more useful.

The better approach: do the first-pass parsing first, organize the evidence, then send the structured prompt into AI for deeper reasoning. Once the key signals are already extracted, AI becomes much more useful for validating the assessment, drafting a user advisory, suggesting containment steps, and writing a clean incident note.

AI works much better when it receives labeled evidence, not a wall of raw text.

Step 5 — Copy the incident note and move on

Once the findings are structured, copy the incident note into the SIEM ticket, ServiceNow, Jira, Slack, or whatever case workflow you use. A structured note fixes the write-up problem and makes handoff easier — every investigation looks more consistent across the team.

Why this matters beyond speed

Consistency. When the same type of alert gets triaged the same way every time, notes are cleaner, severity is easier to defend, escalations are more predictable, and handoffs are smoother.

Junior analyst support. A structured workflow helps less experienced analysts know what to check, in what order, and what actually matters. That reduces hesitation and helps them escalate with more confidence.

Better use of AI. AI is most useful after the evidence has already been organized — second-pass reasoning, clearer communication, faster documentation. Not as a substitute for the first-pass thinking.

What I would recommend to any SOC team

Standardize the first pass — do not let every analyst invent the workflow from scratch.
Work from the full raw email — do not rely only on the visible message.
Structure the evidence before using AI — do not ask AI to do the organizing work if you can parse and label the signals first.

If you want to try this workflow

The phishing analyzer is at socworkflows.com/phishing — free, browser-based, no account needed.

If phishing is only one part of your queue, there are also analyzers for alert triage, VPC flow logs, and credential dumping — all built around the same idea: client-side triage first, AI reasoning second.

Final thought

Most phishing alerts do not become slow because the analysis is too complex. They become slow because the process is inconsistent. Fix the workflow, fix the speed. Structure the first pass properly, and you make everything after that easier — investigation, escalation, documentation, and team consistency.

That is where the real time savings come from.

Why SOC analysts get inconsistent results from ChatGPT (and how structured workflows fix it)

gaurav kundu — Thu, 02 Apr 2026 02:15:06 +0000

If you've ever handed a security alert to ChatGPT and gotten a different answer each time — you've hit the real problem.

It's not the model. It's the prompt.

Most analysts paste an alert and ask "what do you think?" That's like asking a junior analyst to investigate without a runbook. You'll get something back, but the quality depends entirely on how the question was framed.

The real problem: no structure

Experienced SOC analysts don't wing investigations. They follow a process:

Triage the alert
Map to MITRE ATT&CK
Check for lateral movement
Build a containment recommendation
Write a ticket summary

The issue is that most AI-assisted workflows skip steps 2–5 and jump straight to "is this bad?"

What I built

I spent time building SOC.Workflows — a free collection of structured investigation workflows for SOC analysts. Each workflow breaks an investigation into 4 steps, with specific prompts for each step, designed to run in ChatGPT or Claude.

Current workflows:

Phishing Email Investigation
AWS VPC Flow Log Analysis
PowerShell & Script Analysis
Credential Dumping Investigation
Ransomware Triage
Identity Compromise Investigation
URL & Domain Analysis
SOC Alert Triage
Explain This Alert

How it works

Pick a workflow matching your alert type
Copy the workflow prompt
Paste into ChatGPT or Claude
Get structured, step-by-step analysis

No login. No setup. No API keys.

Why structure matters

When I ran the same phishing alert through an unstructured prompt vs. the structured workflow, the difference was clear:

Unstructured: "This looks like a phishing email. Check the sender domain."

Structured: SPF/DKIM validation → header analysis → sender reputation → verdict with risk score → recommended response actions

Same model. Completely different output quality.

Try it

If you work in a SOC or do blue team work, I'd love feedback on which investigation types are missing.

👉 socworkflows.com — free, no login required

SOC Workflow: How I Investigate a Phishing Alert (Step-by-Step)

gaurav kundu — Wed, 01 Apr 2026 15:08:47 +0000

Phishing alerts are one of the most common — and most time-consuming — tasks in a SOC.

But the problem is not the alert itself.

The problem is lack of structured workflow.

Without a clear process, analysts:

Miss important signals
Waste time switching tools
Produce inconsistent results

So here’s the exact step-by-step workflow I use to investigate a phishing alert.

🧠 Step 1: Initial Triage

Start with the basics:

Who reported the email?
Internal or external sender?
Subject line / urgency indicators
Any attachments or links?

👉 Goal: Quickly understand if this is likely phishing or just noise

🔗 Step 2: Extract Indicators (IOCs)

Pull all possible IOCs:

Sender email address
Domain
URLs
File hashes (attachments)

👉 This becomes your investigation base

🌐 Step 3: Reputation Check

Check:

VirusTotal
MalwareBazaar
URL reputation tools

Look for:

Known malicious domains
Newly registered domains
Low reputation signals

🧪 Step 4: Email Analysis

Analyze headers:

SPF / DKIM / DMARC status
Sender spoofing
Reply-to mismatch

Check for:

Impersonation attempts
Display name abuse

🖥️ Step 5: Endpoint Impact

Did the user:

Click the link?
Download attachment?
Execute anything?

Check EDR:

Process activity
PowerShell / script execution
Network connections

🔐 Step 6: Account Activity

Check identity logs:

Suspicious login attempts
MFA prompts
Impossible travel

👉 Especially important for credential phishing

📊 Step 7: Scope & Impact

Answer:

Is it isolated or widespread?
More users affected?
Any lateral movement?

🚨 Step 8: Response Actions

Depending on severity:

Block domain / URL
Quarantine email
Reset user credentials
Isolate endpoint (if needed)

📝 Step 9: Documentation

Always document:

Timeline
Indicators
Actions taken
Final verdict

👉 This improves future detection

⚡ Final Thought

SOC work becomes easier when you stop reacting to alerts…

…and start following repeatable workflows.

This is exactly why I started building structured workflows for investigations:

👉 https://socworkflows.com

It’s a growing library of step-by-step SOC workflows designed to reduce investigation time and improve consistency.

If you're a SOC analyst, I'd love to know:

👉 Do you follow a structured workflow or investigate ad-hoc?