Simulation — Full Phishing Triage Prior to Disclosure
Multiple genuine phishing emails reported by users via the M365 phishing report button were escalated to the SOC. Full triage confirmed a credential-harvesting URL resolving to a convincing Microsoft login spoofing page on a .tz ccTLD. Emails hard-deleted, URL blocked, zero clicks confirmed. Separately, the client's IT lead proactively disclosed an authorised internal security awareness campaign and shared campaign infrastructure for whitelisting. The previously escalated emails were genuine phishing threats — not part of the campaign. Classified as true positive: real phishing, fully remediated.
Phishing remains the dominant initial access vector in Microsoft 365 environments, and user-reported phishing via the built-in M365 report button is one of the most reliable first-layer detection mechanisms available. When a user reports an email, Microsoft Sentinel generates an alert that routes directly to the SOC for triage.
This incident introduces a complicating contextual factor: the client had recently introduced an internal security awareness campaign — a deliberate exercise to test employee vigilance using simulated phishing emails. The SOC was not notified of this campaign in advance. The key principle this incident establishes: full triage must be completed before any client context is sought or received. A live phishing campaign could plausibly be represented as an awareness exercise if the analyst stopped investigation upon first client contact.
The awareness campaign's sending infrastructure used deliberate lookalike domains ([CAMPAIGN_DOMAIN_1], [CAMPAIGN_DOMAIN_2], [CAMPAIGN_DOMAIN_3]) — intentionally designed to simulate real-world phishing. This means the whitelisting step at the end of this incident is not trivial: these domains are, by design, indistinguishable from real threats without the client's prior disclosure.
The phishing email was delivered from a temporary sending address using infrastructure associated with a commercial email sending provider. The envelope-from and header-from addresses were mismatched — a common technique in real phishing campaigns used to evade automated header inspection tools that rely on address matching.
The email body contained a single primary hyperlink where the displayed URL text did not match the underlying href value — a deceptive technique to bypass visual inspection and URL-based filtering rules that rely on visible text rather than the actual href attribute.
The link was submitted to an isolated sandbox environment. Upon execution, the URL redirected through a chain of two hops before landing on a spoofed Microsoft account login page hosted at a domain on the .tz ccTLD (Tanzania). The page was a high-fidelity replica of Microsoft's credential harvesting template: full Microsoft branding, a fake user avatar populated with a realistic display name, and a password input field.
The sending IP was enriched via Recorded Future and returned an RF Score of 5 — consistent with commercial bulk email infrastructure (Amazon SES) that has not yet been flagged for malicious use. This is expected: newly registered phishing infrastructure or first-use of legitimate bulk sending platforms will not appear in threat feeds immediately. The RF Score 5 is not exculpatory.
A tenant-wide URL click report via Microsoft Defender for Office 365 confirmed zero clicks across all users during the full delivery window — no credential exposure occurred. The Network Message ID was used to confirm precise hard-deletion of the specific message from both the primary inbox and the recoverable items folder.
Upon receiving the awareness campaign infrastructure list from the client (25+ IPs and domains), all assets were reviewed and whitelisted. The campaign's lookalike domains were deliberately designed to simulate phishing — confirming that the whitelisting action is correctly scoped to the campaign context only, and does not affect the classification of the genuine phishing incidents already worked.
| Type | Indicator | Notes |
|---|---|---|
| URL | hxxps://gust0beau[REDACTED][.]com[.]tz/documents/ | Credential harvesting — sandbox confirmed redirect, .tz ccTLD (Tanzania) |
| Sending IP | 168[.]245[.]56[.]XXX | Amazon SES bulk infrastructure — RF Score: 5 |
| Sending IP | 198[.]21[.]6[.]XXX | Campaign secondary MTA |
| Sending IP | 99[.]80[.]168[.]XXX | Campaign secondary MTA |
| Domain | [CAMPAIGN_DOMAIN_1] | Awareness campaign lookalike domain — whitelisted post-confirmation |
| Domain | [CAMPAIGN_DOMAIN_2] | Awareness campaign lookalike domain — whitelisted post-confirmation |
| Domain | [CAMPAIGN_DOMAIN_3] | Awareness campaign lookalike domain — whitelisted post-confirmation |
| Message ID | [REDACTED_MESSAGE_ID] | Network Message ID — M365 admin audit trail |
| Tactic | Technique | ID | Observed |
|---|---|---|---|
| Initial Access | Phishing: Spearphishing Link | T1566.002 | Link embedded in genuine phishing email reported by user |
| Credential Access | Credentials from Web Browsers / Phishing | T1539 / T1056 | Spoofed Microsoft login portal designed to harvest password |
| Defense Evasion | Masquerading | T1036 | Display URL mismatch; mismatched From headers |
// Confirm zero URL clicks across tenant
UrlClickEvents
| where Timestamp > ago(24h)
| where Url contains "gust0beau"
| project Timestamp, AccountUpn, Url, ActionType, IsClickedThrough
// Confirm hard-delete via Network Message ID
EmailPostDeliveryEvents
| where NetworkMessageId == "6afa526e-[REDACTED]-709b-08de32aba63d"
| project Timestamp, RecipientEmailAddress, Action, ActionResult
// Scope check: other recipients of same campaign sender IPs
EmailEvents
| where SenderIPv4 in ("168.245.56.XXX","198.21.6.XXX","99.80.168.XXX")
| where Timestamp > ago(24h)
| project Timestamp, RecipientEmailAddress, Subject, SenderMailFromAddress, DeliveryActionFull triage was completed before client context was received — this is the correct approach. The emails escalated were genuine phishing threats; the client's awareness campaign disclosure was additional context, not a reclassification trigger.
The credential-harvesting page was technically convincing: a two-hop redirect chain, spoofed Microsoft login portal, high-fidelity branding, fake user avatar with realistic display name, and a password input field. The .tz ccTLD was the strongest pre-context indicator of malicious intent.
The client's proactive sharing of campaign infrastructure was exactly the right approach — it ensures the SOC has context for future campaign detections. Reinforces the value of sandbox detonation as a first-line technical confirmation step before any client communication.