Something Fishy in the Land of Phishing Simulators
Exploiting software design: a security awareness tool turned into an attack vector
TLDR: I extracted an email header from a single phishing simulation mail sent within a organization and I was able to craft and deliver any malicious email of my choosing to any user in the domain. This bypassed (default) Microsoft 365 security measures, incl. spam filters, URL analysis, and attachment scanning, leveraging the phishing simulator as an attack vector.
🔍Introduction
In 2024, I identified a vulnerability affecting Microsoft 365 environments that utilized a phishing simulation platform. By leveraging a hidden email header, I was able to bypass default security filters and deliver emails directly to inboxes. Obtaining a single phishing simulation email was sufficient to exploit this vulnerability, as the authentication header hidden within it remained valid indefinitely.
This post focuses on the technical aspects of the vulnerability and how it was exploited. While human error or business pressures may have contributed to the issue, this write-up emphasizes the mechanics of the exploit itself to provide insights for securing similar systems.
The issue, in this specific case, stems from how the platform used an email whitelisting header (X-PHISHTEST) with lacking safeguards to ensure secure delivery of simulated phishing emails. This "key" was never rotated, meaning that anyone with access to it effectively had a persistent means to deliver emails directly into inboxes, bypassing spam filters, URL scanners, and attachment checks.
I’ll refer to the platform as SupplyChainCorp. This post explores the Header Whitelisting Key for 100% Attack Delivery Exploit (in M365), a vulnerability that leverages insider risk to steal specific email headers and guarantee email attack delivery.
🚪 The Backdoor
When Security Training Creates Security Risks
The vulnerability was enabled by the default onboarding configuration. SupplyChainCorp’s platform used the X-PHISHTEST header to ensure simulated phishing emails reached employee inboxes. This method bypassed critical security layers, including spam filters, URL scanners, and attachment checks, leaving the system vulnerable to exploitation.
Although this guaranteed delivery for training purposes, it also created a persistent backdoor. The X-PHISHTEST header effectively acted as a master key, instructing Microsoft 365 to "trust this email no matter what." If an attacker obtained the key, they could deliver malicious emails directly to user inboxes without triggering security defenses.
By bypassing the system’s real defenses, this approach introduced a significant vulnerability, exposing organizations to potential exploitation rather than reinforcing their security.
🔑 The False Security of Shared Keys
In proper 2FA implementations, security relies on multiple independent factors, typically something you know (like a password) combined with something you have (like a phone) or something you are (like a fingerprint). Each user has their own unique combination of factors, and these factors exist in separate security domains.
In this case, the use of the X-PHISHTEST key did not follow these principles. The key was shared across all users and remained active indefinitely, creating a persistent bypass mechanism. Anyone with access to a single phishing simulation email could exploit it to bypass Microsoft 365’s security controls indefinitely.
It’s important to note that the X-PHISHTEST key can be used securely by other platforms when combined with safeguards such as unique keys, IP validation, and proper key rotation.
🥷🏻 The Key Under the Doormat
In this specific implementation, embedding the X-PHISHTEST key in headers made it easily discoverable and reusable. It's like hiding a key under the doormat. It’s fine until someone knows where to look.
The Whitelisting Key Mechanism Used by SupplyChainCorp
Header Injection: Phishing simulators insert a custom email header (
X-PHISHTEST) to indicate that the email should be whitelisted.Whitelisting: Emails with these headers are trusted and allowed to bypass Microsoft 365’s spam filters and junk folder mechanisms, allowing them to reach inboxes without being blocked.
While this setup is convenient for simulations, it opens up a vulnerability for real phishing attacks if an attacker obtains the key.
Screenshot 1: A screenshot of a legitimate phishing simulation email in Microsoft 365 with the X-PHISHTEST header highlighted in the email source.
👨💻 Performing the 100% Attack Delivery Exploit
Step 1: Copying the whitelisting key
The attack begins by extracting the X-PHISHTEST header from a phishing simulation email stored as an .eml file. With this key, an attacker can inject it into crafted emails to bypass security filters.
Screenshot 2: A screenshot of the .eml file containing the whitelisting key (X-PHISHTEST), highlighting the header in the email.
Step 2: Crafting and sending emails
With the stolen whitelisting key, you could craft emails that bypass Microsoft 365’s security. Here’s a breakdown of the process:
Email crafting: You construct a phishing email to resemble a legitimate message, matching the content and sender address. Even without access to the legitimate domain or IP address, you embed the X-PHISHTEST key into the email’s header.
Header injection: You insert the X-PHISHTEST key into the email header. This tells Microsoft 365’s security system to treat the email as safe, bypassing spam, URL, and attachment filters.
Guaranteed delivery: The email successfully bypasses spam filters and junk folder mechanisms, landing directly in the target’s inbox. Even if the domain is unverified, the X-PHISHTEST key ensures delivery, making the attack effective.
Weaponized Example ⚔️
To demonstrate how this vulnerability works, I took an email from my aged and infested Hotmail inbox. This message contained malicious URLs and attachments that would normally be flagged and/or blocked by Microsoft 365 default security checks.
I tested the email in a simulated environment configured with Microsoft 365’s default settings and the default onboarding configurations provided by SupplyChainCorp. By attaching the X-PHISHTEST value to the email header, I was able to bypass all security measures. I sent the email twice — once with attachments and once without.
In both cases, Microsoft 365 delivered the email directly to the inbox, bypassing spam filters, attachment scanning, and URL analysis entirely.
The vulnerability stopped working only when the X-PHISHTEST value was removed or altered. Without the header, Microsoft’s security defenses activated as expected. However, when the key was present, the only remaining safeguard was the "Warning: Unverified sender" message displayed by the email client.
Screenshot 3: Email containing a fake GLS shipping notification (in Dutch), containing several malicious PDF attachments and URLs.
Screenshot 4: Unsubscribe page accessed via the "TRACK-PAKKET" button in the email, hosted over an insecure HTTP connection, with a deceptive form designed to harvest email addresses.
Screenshot 5: PHP code snippets showing two variations of the same email being sent through my SMTP server. One with attachments and one without, both with the X-PHISHTEST header used for guaranteed delivery.
Screenshot 6: Terminal output showing successful execution of my PHP script that sends the malicious email including the X-PHISHTEST header.
Screenshot 7: A screenshot of my inbox setup with the X-PHISHTEST whitelisting rules, showing the malicious emails successfully delivered.
The email, even with malicious attachments, was delivered to the inbox while displaying an 'unverified sender' warning, demonstrating the effectiveness of the X-PHISHTEST whitelisting.
💥 Why This Vulnerability Is Dangerous
One email = permanent access
A single phishing simulation email is all it takes. Any insider or attacker who obtains this email gains an indefinite backdoor into the system. Since the X-PHISHTEST header acts as a permanent master key, they can:
Bypass all Microsoft 365 security layers
Skip spam filters, URL checks, and attachment scanning
Deliver phishing emails without domain verification
Maintain access even after leaving the organization
The persistence of the X-PHISHTEST key provided attackers with indefinite access through a single email, effectively turning it into a permanent master key for future exploitation.
🛠️ Vendor Response & Remediation
The vulnerability was reported through the vendor's bug bounty program and verified in a controlled test environment. In response, SupplyChainCorp took the following actions:
Updated documentation: Revised technical documentation to include guidance on implementing IP validation.
Customer engagement: Organized meetings to inform customers about the changes and provide best practices for securing their email configurations.
📝 Lessons Learned
What to take away from this (as vendor):
Avoid security through obscurity: Hidden keys or untested configurations invite attackers.
Enable public testing: Open your system to bug bounties to find weaknesses before attackers do.
Whitelist domains only during active campaigns: Limit domain whitelisting to the duration of active phishing campaigns, and revoke access once the campaign ends. This minimizes the exposure window and reduces the risk of exploitation.
What can you do today (as buyer)?
Review your configurations: Check mail flow rules, look for unprotected headers, and validate IP addresses.
Control access: Limit whitelisting headers to trusted IPs (at least).
Test your defenses:
Use Whitelisting Key Exploit Checker to identify replay attack vulnerabilities.
Test spam filters with the Fake Spam Mailer to ensure you filter actual spam.