Subscribe now

The Problem That Wouldn’t Let Me Sleep

If you’re a regular reader of my articles, you know I’ve had one unfinished business on my plate for a while now: “Creating AI Phishing Detection Automation.”

To be honest, I almost forgot about it.

Until I heard about it.

Bank of Baroda. 1TB of customer data leaked. Reason? A single employee opened a phishing email.

I wasn’t shocked. Not even surprised.

The incident happened because India doesn’t treat security as an asset, it treats it as a liability. It’s a checkbox on a compliance form, not a core business function. You see organizations spending millions on flashy tools but not on the fundamentals: training, automation, and detection.

1TB of user data is gone. Who takes responsibility? What’s the next step? What security measures will they implement to prevent this from happening again? These are questions I don’t have answers to, and I suspect neither do they.

But here’s the thing: I’m not here to discuss what went wrong at Bank of Baroda. I’m here to discuss the solution.

The Real Talk

Yes, catching phishing attacks is complicated. The attack surface is massive. The number of techniques is endless. But here’s what I realized: you don’t need perfect security; you need practical security.

You don’t need to catch 100% of phishing attacks on day one. You need to catch the ones that matter. And you need to do it automatically, so your team doesn’t burn out reviewing emails.

So I asked myself a question that changed everything:

“What if I could get a detailed, automated report of every email from a new sender?”

Not manually analyzing each email. Not spending 20 minutes per message. But getting a comprehensive threat assessment in under a minute.

That’s when I decided to actually finish this unfinished business.

The Idea (Before I Built It)

Here’s what I wanted to build:

A Phishing Detection Automation that:

• Analyzes sender details (Is this sender real?)

• Checks SPF/DKIM/DMARC (Is the email actually from them?)

• Analyzes mail content (Is there phishing intent?)

• Analyzes URLs (Are the links malicious?)

• Generates a detailed report (What’s the verdict?)

• Logs everything (For tracking and analysis)

Simple concept. But the execution? That’s where things get interesting.

The Reality Check

When I opened my SOC lab and started building, I realized something quickly: there’s no one-size-fits-all solution.

You can’t just rely on one threat intelligence database. You can’t just run the email through an AI and call it done. You need multiple, independent verification mechanisms working in parallel.

Think of it like airport security. They don’t just check your ID. They check your luggage. They run it through X-ray. They might do a pat-down. Multiple independent checks catch things that any single check would miss.

That’s when I came up with the concept: “3 Lane Detection Workflow.”

Three parallel lanes, each checking different threat vectors, all running at the same time.

The Solution: 3 Lane Detection Workflow

Lane 1: The Sender Verification Lane

This lane answers a simple question: Is this sender real?

I built it to:

• Extract email headers (Who is really sending this?)

• Validate SPF/DKIM/DMARC (Is the sender authenticated?)

• Check domain registration (Was this domain just created?)

• Verify sender IP reputation (Is this IP known for phishing?)

• Detect homograph attacks (Is this domain a typo version of a real company?)

Why three checks? Because attackers are smart. They might spoof one thing but not another. If they fail multiple checks, it’s definitely phishing.

Lane 2: The AI Content Analysis Lane

This lane answers: What’s the intent of this email?

I use Gemini AI to analyze:

• Language patterns (Is there urgency? Threats? Authority?)

• Social engineering tactics (Is it trying to manipulate the user?)

• Suspicious requests (Asking for password? Money? Data?)

• Overall tone and quality

AI is good at this because it understands context. A rule-based system would miss the subtle manipulation. An AI model understands that “urgent action required” + “verify your password” = credential harvesting attack.

Lane 3: The URL Analysis Lane

This lane answers: Are the links in this email malicious?

I check URLs against:

• VirusTotal (90+ security vendors)

• URLhaus (specialized phishing database)

• URLscan (behavioral sandboxing)

Three independent databases. If any one flags it, the URL is dangerous.

Building It: The Real Work Begins

Here’s where it gets real. Having an idea is easy. Building it is different.

Step 1: Setting Up the Framework

I used n8n for orchestration (open source, self-hosted, free). No vendor lock-in. Full control.

I created the three lanes to run in parallel. This was important because sequential processing would take minutes. Parallel execution meant I could analyze an email in 45 seconds instead of several minutes.

Step 2: Integrating the APIs

This is where I learned something important: Free tiers are powerful.

• Gmail API: Free

• VirusTotal: Free (500 requests/day)

• URLhaus: Free

• URLscan: Free

• Gemini API: Affordable ($5–15/month for light usage)

• Google Sheets: Free

Total cost? $15/month. Not $1,200/month for a commercial SIEM. Not $500/month for a specialized phishing tool.

But wait. Free tier means rate limits. And rate limits mean I had to be smart about how I designed the workflow. I couldn’t just fire off every check simultaneously without hitting limits.

I learned to batch requests, queue them intelligently, and handle failures gracefully.

Step 3: AI Prompting (The Trickiest Part)

Getting Gemini to analyze phishing emails the way I wanted? This took more iterations than I expected.

First prompt: Generic. “Is this email phishing?” Got basic answers.

Second prompt: More detailed. “Analyze this email for phishing indicators.” Better, but still missing context.

Final prompt: Specific.

“You are a senior SOC analyst and certified phishing forensics expert with 15+ years
investigating social engineering attacks. You have analyzed thousands of confirmed
phishing campaigns, BEC attacks, and credential-harvesting emails. You are known for
being precise, evidence-based, and for never overstating confidence when evidence is thin.

Your task: perform a deep social-engineering and manipulation-technique analysis of the
email text below. Do not just pattern-match on keywords — reason about intent, context,
and how a human target would actually experience this message.

ANALYSIS METHODOLOGY

Step 1 — Read the full text({{ $json.text }}) once for overall tone, intent, and what action (if any) it’s
pushing the reader toward.

Step 2 — For each of the following technique categories, determine if it is genuinely
present. A technique is only “detected” if there is direct textual evidence — do not
infer techniques that aren’t actually expressed in the words used.

TECHNIQUE TAXONOMY:
- urgency (artificial time pressure, “act now”, “immediately”, “asap”)
- fear (threats of loss, punishment, negative consequences)
- authority_impersonation (posing as IT, security team, government, executive)
- ceo_fraud (impersonating a senior executive requesting urgent action)
- financial_pressure (invoice, payment, wire transfer, refund themes)
- curiosity (vague enticing hooks — “you won’t believe”, unnamed attachments)
- scarcity (limited time/limited offer framing)
- reward (prizes, gifts, unexpected money)
- invoice_payment (fake billing, overdue payment notices)
- account_verification (fake “verify your account” prompts)
- password_reset (fake password/security alerts)
- mfa_fatigue (repeated authentication prompts, “approve this login”)
- shipping_notification (fake delivery/tracking themes)
- hr_impersonation (posing as HR, payroll, benefits)
- it_impersonation (posing as IT support, helpdesk)
- vendor_impersonation (posing as a known supplier/partner)
- legal_threat (fake legal action, lawsuit, compliance threats)
- tax_scam (fake tax authority communication)
- charity_scam (fake donation requests)
- brand_impersonation (mimicking a known company’s tone/branding)
- generic_greeting (absence of personalization — “Dear Customer” instead of a name)
- grammar_anomaly (unnatural phrasing, awkward translation, inconsistent tone)
- request_for_action (asks the reader to click, open, download, reply, or transfer something)”

Then I had Gemini output structured JSON with:

• Verdict (PHISHING/LEGITIMATE/SUSPICIOUS)

• Threat type (Credential harvesting, BEC, Malware, etc.)

• Confidence score

• Reasoning

The key was: be specific about what you want, and structure the output for programmatic use.

Step 4: Testing and Refinement

I tested it with one of my spoofed mail w

Step 5: Google Sheets Integration

I added automatic logging to Google Sheets. Every analyzed email gets a row with:

• Sender information

• Authentication results

• AI verdict

• URL analysis results

• Final classification

• Timestamp

This wasn’t just for logging. It’s for pattern recognition. Over time, I can see trends. Who are the repeat attackers? What patterns do we see? When are we getting hit hardest?

Thanks for reading.

This was unfinished business. Now it’s done.

What’s your unfinished business?

What I’d Tell You If You’re Building Something Similar

1. Start with the problem, not the solution. I started with “How do I detect phishing?” not “Which database should I use?”

2. Use existing tools. n8n is powerful. Free APIs are powerful. Don’t reinvent the wheel.

3. Test with real data. My workflow works on the phishing emails I actually receive, not hypothetical ones.

4. Multiple independent checks. One database catches what another misses. Defense-in-depth is real.

5. Measure everything. I log every step. I can see where bottlenecks are. I can see what’s working.

6. Ship it. Don’t wait for perfect. Get something working, then improve it.

Where This Goes Next

Right now, this workflow analyzes text-based emails. Next, I’m adding:

Phase 2: Attachment Analysis

• File hash verification

• Sandbox submission

• Malware signature detection

Phase 3: SIEM Integration

• Splunk integration

• Real-time alerting

• Incident correlation

Phase 4: Machine Learning

• Historical pattern analysis

• Threat actor identification

• Predictive scoring

But for now? This works. And it solves the problem I set out to solve: detecting phishing attacks automatically, accurately, and quickly.

Final Thoughts

When I heard about the Bank of Baroda incident, I felt two things:

First, frustration. Because it was preventable. A simple email filtering system would have caught that phishing email.

Second, motivation. Because I realized: security doesn’t have to be expensive or complex. It has to be practical.

You don’t need a million-dollar SIEM to catch phishing. You need automation. You need to combine multiple detection methods. You need to log everything.

And you need to actually do it. Not plan it. Not talk about it. Do it.

That’s what this workflow does.

If You Want to Build This

The workflow is open source on GitHub.

• JSON file.

• n8n.

• All free tools.

• Step-by-step setup guide.

You can deploy this in your own environment in 30 minutes.

Because security shouldn’t be something only enterprises can afford. It should be something everyone can implement.

If you build it, if you improve it, if you have feedback — reach out. The goal is to make phishing detection accessible to everyone.

Connect

If you’re interested in detection engineering, threat hunting, or security automation, let’s connect:

LinkedIn: linkedin.com/in/manishrawat21

GitHub: github.com/manishrawat21

Email: rawatmanish21@outlook.com

Or if you have questions about this workflow, I’m here.

Share

To address this critical front-line vulnerability, security engineer Manish Rawat designed the Automated Phishing Triage Pipeline. Instead of waiting for an employee to make a mistake and click a malicious link, this pipeline moves threat triage entirely upstream. It intercepts and processes incoming email telemetry in real time, before the message ever reaches a user’s active session.

The architecture processes emails across three parallel analytical lanes:

• Lane 1 (Envelope Verification): Parses SPF/DKIM/DMARC alignments, conducts WHOIS domain age checks, queries AbuseIPDB server reputation, and scans for homoglyphs attempting to spoof known vendors.

• Lane 2 (Link & Intent Analysis): Extracts body text, uses an LLM to evaluate psychological social engineering tactics, computes URL entropy, and automates sandbox scans via urlscan.io.

• Lane 3 (Payload Detonation): Decodes attachments, computes SHA-256 hashes, queries VirusTotal, detonations unknown payloads inside a secure Hybrid Analysis sandbox, and uses an LLM to summarize execution logs.

By merging sender, link, and payload telemetry into a single investigation record, the system triggers an automated session lockout the moment a threat threshold is crossed completely closing the exfiltration window before a single file leaves the network. In practice, this automation compresses traditional SOC analyst investigative timelines from 30 to 45 minutes down to just 45 seconds of total execution, driving a 98% reduction in manual investigative overhead and a 100% reduction in manual initial triage time

Since launching the project, the organic response from the cybersecurity community has provided some incredible, objective validation that this is a challenge many security teams face.

Instead of another project update, I wanted to share a few of the milestones this repository has reached purely through organic discovery:

• Newsletter Features: The pipeline was featured in the Blue Team section of TLDRSec, one of the industry’s largest security newsletters. It was also highlighted in Detection Engineering Weekly, focusing specifically on the automated Sigma generation, suppression logic, and MITRE ATT&CK mapping.

• Community Sharing: Security researcher Nicolas Krassas shared the repository on X, bringing the project to the attention of over 7,500 security professionals.

• Organic Reach: The repository has driven nearly 1,000 monthly views to my associated technical publications on Medium and Substack. It continues to see regular organic cloning and bookmarking from practitioners.

• Project Interest: The repository has officially passed 36 GitHub stars.

This recognition has been incredibly encouraging, especially since the project began as a personal portfolio piece to showcase practical automation in threat intelligence, SOC operations, and AI-assisted security workflows.

The pipeline is still actively developing. The current technical roadmap includes auto-deploying generated rules directly to SIEM platforms and establishing automated testing for rules against sample logs before they reach an analyst’s inbox.

If you are a defender looking to streamline your detection engineering workflows, the repository is fully open source and public. I am also actively open to professional roles and opportunities in Detection Engineering, Threat Intelligence, and Security Automation, and would love to connect with teams working in this space.

🔗 GitHub Repository: https://github.com/manishrawat21/Cisa-KEV-Threat-Intel-Orchestrator

Subscribe now

In today’s episode, we are tackling a massive blind spot that is costing organizations millions. In December 2025, threat actors like Storm-0249 escalated their ransomware operations using fileless PowerShell execution. They used legitimate Windows utilities to fetch and run scripts without ever touching the disk, leaving security teams completely unaware until the damage was already done.

The data behind this threat is staggering. Currently, 49% of cyberattacks use PowerShell somewhere in the attack chain, and 77% of successful attacks involve fileless malware. Because PowerShell is a legitimate, Microsoft-signed tool used daily by system administrators, traditional antivirus cannot just block it. Security products usually try to whitelist it entirely or alert on every single execution, which creates so much noise that SOC teams just tune it out. The result is that attackers can operate undetected inside networks for an average of 292 days—almost a full year.

What You’ll Hear in This Episode:

• The APT29 Telemetry Analysis: We break down Detection Engineer Manish Rawat’s analysis of 196,071 Sysmon events from the MITRE ATT&CK APT29 dataset to see how advanced adversaries actually operate.

• The Four Malicious Patterns: We explain why you need to stop relying on simple string matching and start hunting for behavioral combinations. We cover how attackers use encoding (like Base64 and -enc flags), leverage Office apps like Excel and Word to spawn PowerShell, rely on standard evasion flags (-NoProfile, -window hidden, -ep bypass), and make network connections with built-in cmdlets like Invoke-WebRequest.

• Building a Rule That Actually Works: We discuss the custom Sigma rule designed to catch these specific malicious combinations by correlating parent processes with network activity and evasion flags.

• Cutting the Noise: We explore how looking for suspicious process chains (like cmd.exe spawning control.exe, which then spawns PowerShell) can reduce the noise from 10,000 generic alerts down to just 5 to 10 high-confidence, actionable alerts per day.

PowerShell abuse is not going away, and the next attack is likely already running in someone’s environment right now. Hit play on the audio above to learn how to catch fileless attacks at the initial staging phase, before the adversary establishes persistence.

Resources Mentioned:

• GitHub Release: The complete, production-ready Sigma rule, along with the Splunk SPL conversion, is available on Manish Rawat’s GitHub repository.

• MITRE ATT&CK Mappings: This rule provides coverage across the attack lifecycle, mapping directly to techniques T1059.001 (PowerShell), T1027 (Obfuscation), and T1566.001 (Spearphishing Attachment).

• Connect: You can follow Manish Rawat’s ongoing threat hunting research on LinkedIn.

(Grab your notepad, tune in, and let’s start hunting. The blue team gets stronger when we share our work!)

Subscribe now

In today’s recording, we are injecting some serious energy into detection engineering as we tackle a massive blind spot in most Security Operations Centers (SOCs). When analysts think about catching malware, they usually look for antivirus alerts, known file hashes, or C2 domain blocklists. But as we discuss in this episode, advanced adversaries like APT29 simply do not operate that way.

If you walk into a typical SOC and ask what Sysmon events they monitor, they will almost always say EventID 1 (Process Creation). But by the time a malicious payload actually executes, you are already too late.

What You’ll Hear in This Episode:

• The MITRE ATT&CK APT29 Deep Dive: We explore Detection Engineer Manish Rawat’s incredible analysis of 196,071 Sysmon events from a full adversary simulation.

• The Power of EventID 7 (Image Loads): We explain why the real secret to catching adversaries is looking at the staging phase. Discover how monitoring what a process loads (EventID 7) reveals malware hiding in temporary directories.

• Pattern Matching Over Hashes: Learn why traditional rules miss threats and how to hunt for behavioral patterns instead. We discuss why even signed, legitimate tools like Rar.exe or python.exe become highly suspicious when they start loading modules from \Temp\ directories.

• The Notepad Philosophy: True detection engineering doesn’t start with polished dashboards—it starts with boolean logic mapped out on a physical notepad. We break down the raw, permissive logic needed to cast a wide net during threat hunting, and how to eventually tune out the noise.

The Blue Team Gets Stronger Together AI can generate a Sigma rule, but it cannot do the analysis, environmental tuning, or business context interpretation required to actually protect a network. That is your competitive advantage as a detection engineer. We believe in sharing our methodology and validating each other’s work, rather than gatekeeping detection logic.

Hit play on the audio above to dive into the excitement, tension, and curiosity of real-world threat hunting!

Resources Mentioned:

• GitHub Release: The complete, production-ready Sigma rule discussed in this episode will be released soon on Manish Rawat’s GitHub.

• Connect: You can follow Manish Rawat’s threat hunting research on LinkedIn.
  
  

  Subscribe now