BEC Triage in 30 Minutes: A Playbook for the First Responder

The alert fires. A user has reported a suspicious email from the CEO asking for an urgent wire transfer to a new vendor. It's a classic Business Email Compromise pretext. The clock is now ticking. You have minutes, not hours, to determine if this is a real threat, assess the blast radius, and stop the bleeding. Panic is not a strategy.

Forget sprawling, multi-day forensic deep dives. The initial triage is about speed and precision. Its purpose is to answer three questions, fast: Is the threat active? Who is impacted? How do we contain it right now? Getting this right separates a minor incident from a major breach.

This is the 30-minute playbook. It’s what a senior analyst does instinctively. No fluff, just the critical path from initial alert to initial containment.

Step 0: Get the Unadulterated .eml

Before you do anything else, you need the raw source of the email—the .eml file. That forwarded email from the user with their commentary on top? It’s forensically useless. Forwarding modifies headers, strips critical metadata, and can even alter the body content, rendering it useless for a real investigation. You need the original artifact from the server.

Your EDR or mail security gateway should have a quarantine or message trace feature that lets you download the original message directly. If not, you need to guide the user to do it. Outlook and Google Workspace both have a 'show original' or 'download message' option. This isn't just about headers; it's about getting the complete, unmodified MIME-formatted file, including all parts, attachments, and encoding.

Why does this matter so much? Because the headers in the original .eml are the ground truth of the email's journey. They contain the IP addresses of every Mail Transfer Agent (MTA) that handled the message, the authentication results (SPF, DKIM, DMARC), and other clues that are scrubbed by the time a message is forwarded by a user's client. Without the .eml, you're flying blind.

The Journey In: Reconstruct the Received Chain

Once you have the .eml file, open it in a text editor or a dedicated parser. Ignore the pretty HTML rendering for now. You're here for the headers. Your primary focus is the `Received` chain. Every server that touches an email prepends a `Received` header to the top. To trace the path from sender to receiver, you must read them from the bottom up.

Reading From the Bottom Up

The bottom-most `Received` header is the first hop—the MTA that accepted the email from the sender's client or server. Each subsequent header above it shows the next step in the journey. You're looking for the handoff from the external, untrusted world to your own environment. Usually, you'll see a server you don't recognize at the bottom passing the mail to a known entity like `mx.google.com` or `protection.outlook.com`.

Pay close attention to IPs, hostnames (both the HELO/EHLO name and the reverse DNS ptr record), and timestamps. Does the originating IP belong to a residential ISP? A cloud provider like DigitalOcean or Linode where an attacker could spin up a cheap server? Is there a huge time gap between hops, suggesting a delay tactic?

Authentication is Context, Not a Verdict

Next, find the `Authentication-Results` header. This is the Rosetta Stone of email security, a summary of what your mail gateway decided about the sender's identity, as defined in RFC 8617. It's an absolute goldmine.

Authentication-Results: mx.google.com; dkim=pass header.i=@legit-sender.com header.s=selector1 header.b=xyz; spf=pass (google.com: domain of attacker@phish-domain.com designates 198.51.100.24 as permitted sender) smtp.mailfrom=attacker@phish-domain.com; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=legit-sender.com — Example Authentication-Results Header

Don't just look for a simple 'pass' or 'fail'. Context is everything. In the example above, SPF (RFC 7208) passed, but for the envelope sender (`attacker@phish-domain.com`), not the 'From' address the user sees. DKIM (RFC 6376) passed and aligned with the `header.from`. But crucially, DMARC (RFC 7489) failed because SPF was unaligned with the `header.from` domain. This is a telltale sign of a spoofed 'From' address passing through a legitimate but misconfigured sending service. The DMARC `p=REJECT` policy shows the sender intended for this to be blocked, but your gateway may have overridden it.

The Foe Inside: Checking for Compromise

A successful BEC isn't a one-and-done email. It's the beachhead for a larger attack. If the user clicked a link or entered credentials, the attacker's next move is to establish persistence inside the account. Your investigation must immediatly pivot to look for signs of account takeover.

Hunting Malicious Inbox Rules

Adversaries love inbox rules. They are the simplest way to maintain access and hide their tracks. A common tactic is to create a rule that looks for keywords like 'invoice,' 'payment,' or 'fraud alert,' forwarding them to an external attacker-controlled email address, and then immediately moving them to the Junk or Deleted Items folder and marking them as read. The user never sees the sensitive emails they are exfiltrating, nor the security warnings from your own systems.

Use your administrator console (Microsoft 365 Security & Compliance Center or Google Workspace's Admin console) to inspect the target user's inbox rules. Look for any rules that forward mail externally or delete messages. Pay extra attention to rules with vague names like '.' or a single character, as attackers often use these to avoid suspicion.

Auditing Rogue OAuth Grants

More sophisticated attackers have moved beyond inbox rules to malicious OAuth applications. If the user was tricked into granting consent to an app named something innocuous like 'MailGuard' or 'Document Scanner,' that app may now have persistent API access to their entire account—email, files, contacts, everything. This is far more dangerous than an inbox rule because access persists even if the user changes their password.

Audit the user's application permissions. In Azure AD, check 'Enterprise applications' and filter by user sign-ins. In Google Workspace, check the user's third-party app access. Look for any recently granted permissions to unknown or suspicious publishers. Revoke access immediately. This is a critical containment step.

Pivoting on Attacker Infrastructure

The initial email is just one data point. The real value in a quick triage is leveraging that data to map out the attacker's broader campaign infrastructure. This is where you go from defense to offense.

Take the IoCs you gathered from the email headers: the originating source IP, the domain in the `Return-Path` (envelope sender), and any domains in URLs within the email body. Now, pivot on them.

Plug the source IP into threat intelligence platforms like VirusTotal, AbuseIPDB, or your preferred commercial provider. What else has been seen from this IP? Is it a known TOR exit node, a compromised router, or part of a VPS provider frequently abused by threat actors? Do the same for the domains. Check passive DNS records to see what other IPs the domain has resolved to, or what other domains have resolved to that same IP. Check WHOIS registration data—was the domain registered yesterday? Are the details redacted behind a privacy guard? These are all red flags.

This clustering of infrastructure is how you find the *next* attack before it happens. An attacker rarely uses an IP or domain for a single email. By identifying their network, you can proactively block the entire range of known-bad indicators across your firewalls, web proxies, and email gateways.

Containment, Eradication, and Communication

By now, you're probably 20-25 minutes in. You've confirmed the threat, identified the entry vector, and have a good idea of the immediate internal and external blast radius. It’s time to contain.

Isolate, Remediate, and Eradicate

First, take action on the compromised account. Force a sign-out from all sessions and trigger a password reset immediately. If you identified malicious inbox rules or OAuth grants, remove them. This boots the attacker out.

Next, address the malicious email itself. Use your mail security platform to run a search-and-destroy (or search-and-purge) query to remove all instances of the email from every inbox in your organization. This prevents other users from falling victim. Finally, block the attacker IoCs you've identified—the sender's domain, IP address, and any malicious URLs. You are hardening your perimeter based on the intelligence you just gathered.

Delivering the Sit-Rep

Your final task is communication. And it must be clear, concise, and calm. Notify the appropriate stakeholders: the user who reported it (and their manager), your finance department (especially if it was a payment-related pretext), and your security leadership. Don't bury them in technical jargon.

Provide a simple situation report (sit-rep): 'We investigated a reported BEC attempt. We confirmed account X was compromised via a credential phishing link. The attacker created an inbox rule to exfiltrate mail, which we have removed. The account has been secured, and all other copies of the malicious email have been purged from the environment. We are monitoring for further activity.' This demonstrates control and preempts panic.

After Action: From Triage to Hardening

This 30-minute triage isn't the end of the investigation. It's the beginning. You've stopped the bleeding, but now the real work starts. The incident needs to be documented, the IoCs need to be fed into your security tooling, and most importantly, you need to ask *why* it succeeded.

Was DMARC not enforced, allowing the spoof to get through? Was the user undertrained on identifying phishing links? Did your existing mail security solution miss a known-bad indicator? Each incident is a free lesson on how to harden your defenses. Don't waste it.

The speed of your triage matters. An attacker moves fast, and your initial response sets the tone for the entire incident. Mastering this flow of analysis—from .eml artifact to infrastructure pivot to decisive containment—is a non-negotiable skill for any modern security analyst.

The takeaway

A 30-minute triage is an aggressive tempo, but it's achievable. It's about having a repeatable process that prioritizes containment and initial intelligence gathering over a complete forensic analysis. It's about knowing what to look for, in what order, and why it's operationally significant.

This entire workflow—header analysis, `Authentication-Results` breakdown, IoC extraction—is a candidate for automation. The faster you can move through the mechanical steps of parsing and enrichment using tools like MailSleuth.AI, the more time you have for the critical thinking that actually stops an attack.