This case focused on unauthorized access to a Microsoft 365 account in the baker221b.co.uk tenant. The scenario involved Evilginx, an adversary-in-the-middle framework that captures credentials and session material while presenting the victim with a convincing login experience.

Filed by Sherlock Holmes. Evidence sources: Entra ID sign-in logs and Microsoft 365 Unified Audit Logs. The anomalies were subtle — the attacker's infrastructure did not present as a loud burst of malicious activity. The evidence emerged through sequence, deviation, and correlation.

Baseline Sign-In Review

The first step was establishing what normal sign-in behavior looked like before hunting for anomalous IPs. Without a behavioral frame, suspicious IPs lose meaning.

SELECT
  createdDateTime,
  userPrincipalName,
  ipAddress,
  userAgent
FROM entra_signin
ORDER BY createdDateTime ASC;

Known baseline IPs per user:

irene.adler@baker221b.co.uk       → 192.0.2.39
john.watson@baker221b.co.uk       → 192.0.2.25
mholmes@baker221b.co.uk           → 192.0.2.77
mhudson@baker221b.co.uk           → 192.0.2.62
sherlock.holmes@baker221b.co.uk   → 192.0.2.14

That baseline made it possible to spot the first unusual IP associated with the compromised account by sequence break rather than by raw frequency.

Evilginx Relay Identification

The Evilginx server was identified by locating the earliest suspicious IP that did not align with the expected login pattern. Timing and sequence mattered more than raw frequency — the suspicious infrastructure appeared early, before follow-on access from a different client platform.

Evilginx relay IP: 203.0.113.42

Attacker Workstation Pivot via User Agent

The second phase required distinguishing the attacker's actual workstation from the phishing relay. The key pivot was not just IP address — it was a user-agent change. A filtered query for non-Windows user agents surfaced the follow-on access event:

SELECT
  createdDateTime,
  userPrincipalName,
  ipAddress,
  userAgent
FROM entra_signin
WHERE userAgent NOT LIKE '%Windows NT 10%'
ORDER BY createdDateTime ASC;

That shift in client platform was the strongest clue that the second IP represented the attacker's workstation rather than the relay.

Attacker workstation IP: 198.51.100.67
Platform: macOS + Firefox
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:144.0) Gecko/20100101 Firefox/144.0

Unified Audit Log — Destructive Activity

Once unauthorized access was established, the next question was what the attacker did inside the M365 environment. The destructive action surfaced through FolderRecycled operations. Because this dataset used nested fields inside the AuditData structure, the query had to reference tuple-style fields directly:

SELECT
  AuditData.CreationTime,
  AuditData.UserId,
  AuditData.Operation,
  AuditData.SourceRelativeUrl
FROM unified_audit_logs
WHERE Operations = 'FolderRecycled'
ORDER BY AuditData.CreationTime ASC
LIMIT 50;

Deleted directory path: Documents/case_files

The Investigative Flow

This case was a strong example of how cloud investigations depend on reading order and relationship, not just isolated suspicious rows.

The sequence: establish normal sign-in context → find the first anomalous infrastructure → identify secondary access through client fingerprinting → pivot into tenant activity logs → confirm impact through file-destruction behavior.

The sign-in logs explained how access happened. The Unified Audit Logs explained what the attacker did once they had it. That division between authentication telemetry and application activity telemetry is a core pattern in Microsoft cloud investigations. The transition from suspicious sign-in to destructive folder operations happened in a tight window — which is exactly why fast triage and evidence correlation matter in identity-centric cloud incidents.

Confirmed Findings

Evilginx relay IP:       203.0.113.42
Attacker workstation IP: 198.51.100.67
Deleted directory:       Documents/case_files