A finance department employee clicked a spoofed "verify your mailbox" link impersonating Microsoft IT Support and entered their Microsoft 365 credentials on a lookalike page. The attacker authenticated from a foreign IP within two minutes — no MFA existed to stop it — then set up silent auto-forwarding to exfiltrate mail. I traced the chain from a single SIEM alert back through the full kill chain, confirmed true positive, and drove containment to closure in roughly 35 minutes.
- Root cause was a stack of missing controls, not attacker sophistication — no MFA, no DMARC/DKIM/SPF enforcement, no security awareness training
- SIEM geo-velocity correlation ("impossible travel") caught the intrusion 20 minutes after the credential click, before major damage occurred
- The attacker's first action after login was establishing silent mail forwarding — the highest-value early detection point for BEC-style compromise
- Full containment (session revocation, forwarding rule removal, MFA enforcement) closed in under an hour of the first unauthorized login
The Problem
On March 3rd 2026 at 09:10, a spoofed Microsoft IT Support email landed in a finance employee's inbox with the subject "Action Required: Verify Your Mailbox Storage Immediately." The sender domain — microsoftsupportalert[.]com — closely mimicked Microsoft's legitimate domain, and the email used urgency language designed to bypass careful verification. At 09:17 the employee clicked through to a credential-harvesting page styled to match the M365 login screen and entered their password.
The account had no multi-factor authentication. A harvested password alone was sufficient for the attacker to log in.
The Approach
My investigation followed a structured L1 → L2 SOC workflow rather than reactive alert-checking:
- Alert triage — the SIEM fired an "Impossible Travel" alert at 09:37: a login from Nigeria followed by a login from Eastern Europe within under five minutes, a physical impossibility that flags account compromise
- Log correlation — pulled Azure AD sign-in logs to confirm the successful foreign-IP authentication, then cross-referenced email gateway logs to locate the original phishing delivery at 09:10
- Mailbox audit — checked for post-compromise persistence and found an active auto-forward rule silently redirecting mail to an external ProtonMail address, created three minutes after the attacker's login
- Classification — confirmed True Positive and escalated to L2 with a full evidence package: timeline, IOCs, and affected-account scope
The mailbox rule check is the step most junior analysts skip after confirming a suspicious login. It's often where the actual attacker objective — silent, ongoing data exfiltration — is hiding.
Technical Analysis
The kill chain compressed almost the entire attack into fifteen minutes:
09:17 Victim clicks link → redirected to credential harvesting page
09:18 Credentials entered — captured by attacker-controlled server
09:19 Attacker authenticates from foreign IP — no MFA gate
09:22 Successful M365 login — attacker now inside the mailbox
09:25 Auto-forward rule created → attacker@protonmail[.]com
09:37 SIEM alert fires — Impossible Travel, Nigeria → Eastern Europe
09:45 L1 triage — logs reviewed, IOCs confirmed, escalated
09:52 Account suspended, sessions revoked
10:05 Forwarding rule removed
10:30 Password reset + MFA enforced
Challenges
Distinguishing legitimate travel from compromise. Impossible-travel alerts have a real false-positive rate — VPN use and business travel both trigger them. I corroborated the alert against three independent signals (email delivery log, mailbox rule creation, and the geo-velocity itself) before escalating, rather than acting on the SIEM alert alone.
Scoping the blast radius quickly. Once the forwarding rule was found, the priority shifted to determining what had already left the mailbox during the compromise window (09:19–09:52) — a full mailbox audit was required before the account could be safely re-enabled, not just a password reset.
Geolocation lookup on the attacker's authentication IP during triage
| Type | Indicator | Description |
|---|---|---|
| URL | verify-mailboxms365[.]com/login | Credential harvesting page mimicking M365 login |
| IP | 185.220.101.47 | Eastern Europe — first authenticated attacker login |
| IP | 45.153.160.2 | Tor exit node — secondary session |
| Sender | support@microsoftsupportalert[.]com | Spoofed lookalike domain |
| Rule | attacker@protonmail[.]com | Malicious auto-forward, created post-compromise |
Results
- Confirmed True Positive within 8 minutes of alert firing, escalated with full evidence package
- Attacker sessions revoked and forwarding rule stripped within 15 minutes of L1 handoff
- Full containment — password reset, MFA enrollment, IOCs blocklisted, Finance department threat-hunted for matching indicators — closed inside 35 minutes of the first unauthorized login
- Produced seven prioritized recommendations, led by org-wide MFA enforcement and DMARC/DKIM/SPF implementation
Lessons Learned
The alert that caught this — impossible travel — only works if geo-velocity correlation rules are tuned and MFA gaps are known in advance. This incident became the case for prioritizing MFA rollout to Finance and HR before any other control, since a single missing gate turned a routine phishing click into an account takeover.
I'd now build a lightweight mailbox-rule audit into every credential-compromise triage as a standard step, rather than something I check only after finding other suspicious activity — it should be first, not incidental.
What I'd Improve
- Automate the mailbox-rule check as a SOAR playbook step triggered directly by any confirmed credential-compromise alert
- Add a secondary detection layer for auto-forward rule creation events specifically, independent of the geo-velocity trigger
- Push IOC enrichment (sender domain, attacker IPs) to the email gateway blocklist automatically rather than as a manual L2 step
References
- MITRE ATT&CK — T1566.001 Spearphishing Link
- MITRE ATT&CK — T1078 Valid Accounts
- Full repository — github.com/Cyber-Nate/SOC-Phishing-Credential-Compromise