What admins should change after Microsoft’s Storm-3119 phishing disclosure

Microsoft’s Storm‑2990 analysis shows phishing pages imitating government services, logistics companies, banks, retailers, healthcare providers and technology platforms across many countries. The recurring behavior is more stable than the brand: an urgent message directs the target to a supplied link and requests credentials, payment data or an authentication action.

Train users to open the known service independently or contact the organization through a previously verified channel. Do not use the phone number, reply address or link supplied by the suspicious message.

The presence of a brand in the disclosed templates does not mean that organization was breached. Defenders should label the impersonation and the compromised asset separately.

Microsoft observed Storm‑3119 obtaining Global Administrator access and using application credentials for durable control. Require least privilege, separate administrative accounts and phishing‑resistant MFA for privileged roles. Microsoft’s Conditional Access guidance provides a current policy template for administrator roles.

Passkeys or hardware‑backed FIDO2 methods resist common credential‑replay paths better than passwords and one‑time codes. Roll out the policy with emergency‑access accounts and a tested recovery process so a control change does not lock out the tenant.

Also restrict where authentication methods can be registered. An attacker who can add a new method after initial access may preserve control even after a password reset.

Password resets are insufficient when the attacker controls an application credential. Inventory applications with directory, app‑catalog, SharePoint or storage permissions; map each one to an owner and business purpose; and remove stale secrets and excessive grants.

Alert on new credentials, consent grants, privileged role changes, unexpected license assignments and large storage activity from non‑interactive identities. Review sign‑ins that use unfamiliar infrastructure or show impossible travel, but do not depend on one risk signal.

When compromise is suspected, revoke sessions and application credentials, review persistence across the tenant and preserve the affected identity and audit logs before normal retention removes them.

Microsoft recommends Standard or Strict preset security policies for cloud mailboxes. Its current Defender for Office 365 settings reference says to verify SPF, DKIM and DMARC for outbound domains before tuning anti‑phishing policy, because authentication errors can misclassify legitimate mail.

The threat report specifically recommends Safe Links coverage for internal recipients, network protection against malicious domains and monitoring of post‑delivery removals and risky sign‑ins. Validate the settings in your own tenant and licensing tier; a vendor checklist does not prove a control is active.

Avoid broad sender or domain allowlists. Microsoft’s baseline warns that allowed domains can let messages bypass filtering that would otherwise block them.

Run a bounded simulation that checks reporting, triage, identity containment and recovery. Confirm that users can report a lure, security staff can trace the destination, administrators can revoke compromised sessions and app credentials, and the team can restore access without weakening MFA.

Record gaps by control owner and deadline. A successful mail‑blocking test alone does not validate tenant persistence detection, and a clean identity alert does not prove users will recognize a payment lure.

Track further product changes on the Microsoft organization page on OpenTools.

Image: Real phishing‑page evidence published by Microsoft Threat Intelligence. It is shown for defensive identification and reporting, without generated content or artificial upscaling.