
PhishTrace: A C# / .NET 10 Toolkit for BEC Detection in Microsoft 365
A two-tool forensic toolkit built during my I-Force internship for detecting Business Email Compromise across tenant-wide audit logs and per-mailbox content.
internship activity
The intermediate version of my I-Force internship report, documenting the design, implementation and validation of PhishTrace a C# / .NET 10 forensic toolkit for detecting Business Email Compromise in Microsoft 365.

This is the intermediate version of my internship report from my placement on the DFIR team at i-Force, a Belgian independent forensic audit firm. It documents the design, implementation and validation of PhishTrace, the toolkit I built for detecting Business Email Compromise (BEC) in Microsoft 365 environments.
You can download the full report as a PDF. The summary below outlines what it covers.
I was placed on the DFIR team as a junior digital forensics analyst, splitting my time between assisting senior analysts on active cases and building internal tooling the team could reuse. PhishTrace belongs to the second activity: a maintainable in-house toolkit for BEC investigations in Microsoft 365, written in C# on .NET 10 and able to run fully offline inside i-Force's isolated evidence environment.
The toolkit consists of two complementary command-line tools that together cover the full evidence spectrum of a BEC investigation:
UAL-Analyzer.ps1 PowerShell script by Martin Willing of Lethal-Forensics, keeping its catalogue of 73 detection rules and MITRE ATT&CK mappings while replacing the shell-style execution model with a maintainable, single-pass C# pipeline.The original PowerShell script has an excellent, battle-tested rule catalogue stapled to an awkward execution model: a single-user gate, file-as-IPC between phases, severity encoded only in Excel conditional formatting, hard-coded false-positive filters and scattered AppId literals. The port keeps the catalogue and redesigns the execution model around it.
Key additions the C# port brings:
FindingSeverity enum (Critical, High, Medium, Low, VeryLow) surfaced as a first-class columnILethalRule rule contract that can be unit-tested and later parallelisedThe pipeline runs in five strict phases — Parse → Enrich → Detect → Correlate → Export — producing a severity-routed Excel workbook whose first sheet is a dashboard. The 73 LETHAL rules are organised into fifteen functional families (inbox-rule manipulation, transport/mailbox forwarding, OAuth app abuse, anti-forensics, AiTM and session theft, SharePoint exfiltration, and more), each mapped to a MITRE ATT&CK technique.
UalBecDetector was validated against real cases from the i-Force evidence store. On a baseline case of 3,394 UAL records, it produced 454 findings (57 Critical, 55 High, 334 Low, 8 Very Low) whose severity distribution matched analyst expectations. Incident correlation reduced 454 raw findings to 20 incidents — a more than twenty-to-one reduction — and processing took 5 seconds versus 42 minutes for the equivalent PowerShell workflow. It also held up on a live case of roughly 1.35 million records, about four hundred times the baseline.
The most generalizable lesson: porting a tool between languages is not a line-by-line translation. The real work is recognising language-specific idioms that don't transfer — files as inter-phase IPC, conditional-formatting as severity, magic-number AppIds — and deciding, case by case, whether to preserve the behaviour or redesign it. Writing a porting specification up front made those decisions systematic. The hardest part throughout was tuning detection to cut false-positive noise without losing genuine signal, since every BEC case is different.
PhishTrace is now part of the i-Force DFIR toolkit and both tools are available for use on future BEC investigations.

A two-tool forensic toolkit built during my I-Force internship for detecting Business Email Compromise across tenant-wide audit logs and per-mailbox content.

An enjoyable, hands-on Tech & Meet at Howest with Kevin De Rudder, live demos, C# updates, Aspire and Blazor, and a security angle on why cleaner code makes systems easier to defend.