Forem: gaurav kundu

How to Triage a Ransomware Alert Without Losing the First 15 Minutes

gaurav kundu — Mon, 27 Apr 2026 19:59:19 +0000

Most ransomware responses do not fail because the team lacked skill. They fail because the first 15 minutes had no clear order of action.

You get the alert.

Mass file modifications. Shadow copy deletion. A suspicious process spawning PowerShell. Maybe a ransom note has already appeared on a file server.

And immediately, one question matters more than almost anything else:

Is encryption still in progress, or has the damage already been done?

That question changes everything.

If encryption is still active, every minute spent organizing thoughts instead of stopping spread is a minute lost. If encryption appears complete, the priorities shift: preserve evidence, assess scope, protect recovery paths, and start planning the response properly.

The problem is not that ransomware triage is too difficult. The problem is that too many teams are still rebuilding the response path from scratch when the pressure is already highest.

This is the workflow I use now to make those first 15 minutes less chaotic — and much more repeatable.

Why the first 15 minutes go wrong

Ransomware is different from most security alerts because the cost of delay is immediate.

When a ransomware alert lands, a typical analyst is often trying to do all of this at once:

confirm whether the alert is real
work out how many systems are affected
decide whether to isolate immediately
figure out what to tell the team lead or incident manager
start documenting while the situation is still evolving

None of those actions are wrong.

The problem is doing them without a sequence.

Isolate too early and you may lose visibility into how the attack spread. Isolate too late and the encryption may move into file servers, shared drives, or backup infrastructure. Document too early and the write-up becomes outdated before the first paragraph is finished.

The first 15 minutes of ransomware response are chaotic by default. A repeatable workflow does not remove pressure, but it does give that pressure a structure.

The question that changes the response

Before anything else, I want to answer one question:

Is encryption still in progress, or does it appear complete?

That is not a minor detail. It determines the order of response.

If encryption is still active:

stopping spread becomes the priority
broad containment matters more than perfect visibility
evidence preservation becomes secondary to operational survival

If encryption appears complete:

you shift toward impact mapping, evidence preservation, and recovery planning
containment still matters, but it can be more deliberate
the response becomes less about seconds and more about sequencing

A lot of ransomware playbooks bury this distinction. I put it first because getting it wrong leads to the rest of the response being ordered the wrong way.

The workflow I use now

Step 1 — Confirm the indicators

The first thing I want to know is whether this is actually ransomware, or whether it only looks like ransomware.

Plenty of legitimate activity can resemble a ransomware signal in isolation:

backup jobs can trigger mass file modifications
admin tools can interact with shadow copies
scripted maintenance can create noisy process chains

I look for a combination of indicators:

rapid mass file modification within a short time window
file extension changes like .locked, .encrypted, or random suffixes
ransom note creation across multiple directories
shadow copy deletion via vssadmin, wmic, or bcdedit
suspicious process chains, especially cmd.exe or PowerShell spawned from unusual parents
movement into network shares or remote systems before or during encryption

One signal can be noisy. A cluster of signals is where confidence comes from.

Step 2 — Decide whether the spread is still active

Once indicators strongly suggest ransomware, I try to answer the timing question quickly: Is this still moving?

I look for:

whether file changes are still occurring
whether new hosts are starting to show the same indicators
whether suspicious processes are still running
whether SMB activity or remote execution is still active
whether backup systems or file servers are just now being touched

If yes — active containment mode. If probably not — focus shifts to blast radius, evidence, and recovery paths.

Step 3 — Assess the blast radius fast

This is the part analysts often skip under pressure, but isolating the wrong system first creates false confidence.

What I want to know:

how many systems are already showing indicators
whether shared drives, file servers, or hypervisors are involved
whether backup infrastructure has been touched
what the earliest observable indicator was
which host appears to be the likely entry point
which accounts were involved in execution or spread
whether any privileged credentials appear in the chain

That gives me: entry point → lateral movement path → affected assets

If domain admin activity appears anywhere in that chain, the entire incident changes in severity.

Step 4 — Contain in the right order

Containment is an order of actions, not a single action:

stop the spread
protect recovery paths
preserve evidence where possible
stabilize communication and ownership

The backup protection step is the one teams most often miss. Ransomware operators know backups are the recovery path. More mature actors target backup infrastructure before defenders even understand the blast radius.

Step 5 — Start the report while triage is still happening

The incident report should begin during triage, not at end of day.

A useful ransomware report needs two layers:

an executive summary for non-technical decision-makers
a technical summary for the next analyst or IR team

Writing while the situation is still moving forces one important discipline: separating evidence from inference.

What a useful ransomware triage output should include

whether ransomware is confirmed, highly likely, or still unconfirmed
whether encryption appears active or complete
blast radius summary: affected systems, accounts, shared resources, backups at risk
immediate containment actions with urgency and ownership
extracted IOCs
ransomware family if identifiable, decryptor availability if known
downstream requirements: legal, insurance, regulatory, law enforcement

A simple example

EDR alert fires at 03:17 AM on a file server: 4,847 files modified in under three minutes, all renamed .locked, HOW_TO_RECOVER.txt in every folder, vssadmin delete shadows ran five minutes earlier.

Instinct: isolate the file server now.

But scope assessment shows the earliest indicator was on a finance workstation two hours earlier. That host accessed the file server over SMB. A connection attempt hit the backup server at 03:10 AM — seven minutes before the EDR alert.

The alert landed on the file server. The entry point was the finance workstation. The backup environment may already have been targeted before the team knew anything was happening.

Isolating the visible victim first would have left the real risk path untouched.

The newer ransomware reality: exfiltration first

Encryption is not always the first or only objective anymore.

A growing number of ransomware operators now use:

exfiltration before encryption
extortion without full encryption
theft of sensitive data as leverage even when recovery is possible

Ransomware triage should include checks for:

large outbound data transfers
unusual archive creation
movement into sensitive data repositories
pre-encryption staging activity

If your workflow starts only when files begin changing, you may already be late.

If you want to use this response path

I built this workflow into SOC.Workflows so it can be used in the same order during a live incident.

socworkflows.com/ransomware

Free, no login required, designed for practical analyst use. There are also workflows and analyzers for phishing, alert triage, VPC flow logs, and credential dumping.

Final thought

Ransomware responses do not usually fail because analysts are slow.

They fail because the first 15 minutes had no clear sequence, and sequence is hardest to improvise when the pressure is highest.

If you build the order of response before the incident, you do not have to invent it during one.

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?