Moaaz.

internship activity

Internship Report: Designing, Building & Validating PhishTrace

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.

Back to blog
6 June 20264 min readBrugge, Belgiumi-Force
PhishTrace

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.

The assignment

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.

What PhishTrace is

The toolkit consists of two complementary command-line tools that together cover the full evidence spectrum of a BEC investigation:

Why a port was necessary

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:

Architecture

The 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.

Validation

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.

Reflection

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.

Links

Tags

BECMicrosoft 365Unified Audit LogPSTOSTC#.NET 10MITRE ATT&CKInternship Report

Related posts