Assault on the Microsoft Fortress: When Phishing Walks Through the Front Gate

Javier Conejo del Cerro
hace 2 días
3 Min. de lectura

Fortresses are designed to keep enemies out, but history teaches us that the most effective assaults often exploit open gates, trusted messengers, or misconfigured defenses. In early 2026, Microsoft disclosed a wave of phishing campaigns in which attackers did not rely on malware exploits or zero-days, but instead abused misconfigurations in Microsoft 365 and Exchange Online email routing. By exploiting weaknesses in MX, SPF, DKIM, DMARC, and third-party connectors, threat actors were able to send phishing emails that appeared to originate from inside the organization itself. The result was a silent breach: emails that looked internal, bypassed user suspicion, and enabled large-scale credential theft and account takeover.

Phase 1 — Reconnaissance Outside the Walls

Before any assault, attackers study the fortress. In this campaign, phishing actors scanned organizations’ email infrastructures to identify weak or inconsistent configurations. Misaligned MX records, permissive SPF entries, missing or non-enforced DMARC policies, and improperly configured third-party mail connectors all served as indicators that the organization’s email perimeter could be impersonated. Unlike traditional phishing, this phase required no interaction with end users and left little immediate forensic footprint, allowing attackers to quietly select targets where internal spoofing would succeed.

Phase 2 — Forging the King’s Seal

Once a vulnerable configuration was identified, attackers crafted emails that spoofed the organization’s own domain within Microsoft 365. In some cases, both the sender and recipient appeared identical, creating the illusion of an internal system message or automated workflow. Because the emails passed through legitimate Microsoft 365 routing paths and lacked obvious external indicators, they bypassed user skepticism and, in some cases, email security controls. This was not a visual trick alone; it was a technical impersonation enabled by broken authentication logic, effectively forging the fortress’s seal.

Phase 3 — The Deceptive Message Inside the Courtyard

With access gained, attackers delivered familiar and trusted lures. Emails posed as HR notifications, voicemail alerts, shared OneDrive documents, password resets, or payment requests. Many campaigns leveraged phishing-as-a-service kits such as Tycoon2FA, which are specifically designed to defeat modern authentication flows and harvest credentials in real time. Because these messages appeared to originate internally, recipients were far more likely to click, authenticate, or comply, believing the request to be legitimate.

Phase 4 — Account Takeover and Data Access

Once credentials or authentication tokens were captured, attackers gained full Microsoft 365 account access. This included Outlook and Exchange mailboxes, OneDrive and SharePoint files, Teams chats and documents, calendars, contacts, and any data accessible under the compromised user’s permissions. At this stage, the breach expanded beyond phishing into operational compromise: attackers could read sensitive communications, move laterally by sending internal phishing from trusted accounts, establish persistence, and conduct financial fraud or espionage. The fortress was no longer under attack; it was occupied.

Phase 5 — Scaling the Siege

Because the technique relied on configuration flaws rather than malware, attackers were able to scale rapidly across multiple organizations and sectors, including government, education, healthcare, finance, manufacturing, and retail. The same methodology could be reused wherever email authentication controls were weak, making this a repeatable and highly efficient intrusion model. The attack demonstrated how trust in internal email remains one of the most dangerous attack surfaces in modern cloud environments.

Measures to Defend the Microsoft 365 Fortress

Enforce DMARC with p=reject, preventing attackers from spoofing the organization’s own domain.
Harden SPF records, removing overly broad includes and limiting authorized senders.
Ensure DKIM is enabled and validated across all Microsoft 365 mail flows.
Verify MX records point exclusively to official Microsoft 365 endpoints.
Audit third-party connectors and mail relays to eliminate unintended trust relationships.
Monitor email authentication signals for internal-looking messages with abnormal routing.
Apply Conditional Access and phishing-resistant MFA to limit the impact of stolen credentials.
Train users to distrust unexpected internal requests, especially those involving authentication, file access, or payments.