Check Your Logs Now: A Silent Postmark Backdoor is Stealing Your Transactional Emails
By CyberDudeBivash • September 28, 2025, 3:06 AM IST • Threat Intelligence Report
This is a critical alert for every developer and organization that relies on the Postmark transactional email service. A new, stealthy campaign is underway where threat actors are actively compromising corporate servers and developer workstations to steal Postmark API keys. The goal is not to disrupt your email service, but something far more insidious: to create a silent backdoor. Using the stolen keys, attackers are programmatically adding secret BCC addresses and webhook URLs to your Postmark streams, allowing them to receive a hidden copy of every single sensitive transactional email you send—password resets, user invitations, payment receipts, and 2FA links. This is a massive data breach happening right under your nose, leveraging your own trusted infrastructure. We are tracking the malware used in the initial compromise as **MAILSPAWN**. You must **check your Postmark logs immediately** for unauthorized activity.
Disclosure: This is a technical threat report for security practitioners and developers. It contains affiliate links to best-in-class solutions for securing the software development lifecycle. Your support helps fund our independent research.
The DevSecOps & Incident Response Stack
Defending against API key theft requires a layered security model.
Chapter 1: The Threat - The Danger of Leaked Transactional Emails
Transactional emails are the automated, one-to-one messages that your application sends to users in response to their actions. Unlike bulk marketing emails, they are highly trusted and almost always opened. They are the plumbing of the modern internet application, and they are packed with sensitive information.
By using a stolen API key to silently add a BCC (Blind Carbon Copy) or a webhook to your Postmark email stream, an attacker can get a copy of every single one of these emails. This gives them access to:
- Password Reset Links: The ultimate prize. By intercepting a password reset email, an attacker can click the link before the legitimate user does and take over their account.
- New User Welcome Emails: These often contain temporary passwords or links to set an initial password.
- Two-Factor Authentication (2FA) Links: "Magic link" style 2FA is becoming more common. Intercepting this email is equivalent to stealing an OTP.
- Invoices and Payment Receipts: This provides attackers with a goldmine of information for financial fraud, including customer names, service details, and pricing.
- Private User-to-User Notifications: In a platform with messaging, this could include the content of private user communications.
This is not a spray-and-pray attack. It is a targeted, stealthy way to gain deep, privileged access to your application and your users' accounts by weaponizing your own trusted email infrastructure.
Chapter 2: The Kill Chain - How MAILSPAWN Steals Keys and Creates the Backdoor
This is a two-stage attack. The first stage is about stealing the key; the second is about using it.
Stage 1: The Initial Compromise (Deploying MAILSPAWN)
The attackers first need to compromise an asset that has access to your Postmark API key. This is typically:
- A developer's workstation.
- A CI/CD build server.
- The production application server itself.
They gain this initial access through standard methods like spear-phishing, exploiting a public-facing vulnerability on the server, or compromising a developer's credentials. Once inside, they deploy **MAILSPAWN**, a lightweight credential and secret scanner. Its only job is to scour the filesystem, environment variables, and code repositories for strings that look like API keys, with a specific focus on patterns matching Postmark server tokens.
The root cause of the theft is almost always **hardcoded secrets**, where a developer has pasted the API key directly into a source code file or a `.env` configuration file that gets committed to a Git repository.
Stage 2: Creating the Silent Backdoor
Once MAILSPAWN has exfiltrated your Postmark API key, the attacker connects to the Postmark API remotely. They are now authenticated as your application.
They then use the API to perform one of two malicious actions:
- The BCC Backdoor: For a specific transactional email stream (e.g., "Password Resets"), they use the API to add a secret BCC address: `attacker@evil-domain.com`. Now, every time your application sends a password reset email, a hidden copy is also sent to the attacker.
- The Webhook Backdoor: Even more stealthily, they can register a new webhook for your email stream. This webhook points to a server they control. Now, every time an email is sent, Postmark will also send a full JSON payload with the entire content of the email to the attacker's server.
These changes are not visible in your application's source code. They are made in your Postmark account's configuration via the API, making them very difficult to detect without specifically looking for them in your Postmark logs.
Chapter 3: The Hunt - Your Immediate Log Analysis and Detection Plan
You must immediately audit your Postmark account for signs of this backdoor.
Step 1: Audit Your Postmark Activity Logs
Log in to your Postmark account. Navigate to the **Activity** tab for your server. This is your primary source of truth.
- Filter the activity log to show only **API-based events**.
- Look for any events related to creating or modifying Servers, Domains, or, most critically, **Webhooks** or **Triggers**.
- Scrutinize the **Source IP address** for every single one of these API calls. Do you recognize them all as your own production server IPs? An API call from an IP you don't recognize is a massive red flag.
Step 2: Manually Inspect Every Stream Setting
Do not rely on the logs alone. Manually verify the settings for every single one of your transactional email streams.
- For each stream, go to the settings and look at the **BCC field**. Is there any email address there that you did not explicitly configure?
- Go to the **Webhooks** tab. Are there any webhook URLs configured that point to a domain you don't control?
If you find any unauthorized BCC address or webhook URL, you have been compromised.
Step 3: Hunt for the Initial Compromise
If you confirm a backdoor was created, you must then find out how the key was stolen.
- Scan for Hardcoded Keys: Use a tool like `git-secrets` or `trufflehog` to scan all your source code repositories for any instances of your Postmark API keys.
- Hunt on Endpoints (EDR):** Use your EDR solution, like Kaspersky EDR, to hunt for the presence and execution of the MAILSPAWN malware on your developer workstations and servers. Look for unusual file scanning activity or outbound connections from unexpected processes.
If you find evidence of compromise, or even if you don't, you should follow this plan to secure your email infrastructure.
Immediate Remediation
- Revoke and Rotate ALL API Keys: Immediately go into your Postmark settings and revoke every single server and account API token. Generate new ones.
- Update Your Application: Replace the old, compromised keys in your application with the new ones. **Do not hardcode them again.**
- Remove the Backdoor: Delete any unauthorized BCC addresses or webhooks you found during your hunt.
- Force Password Resets: Assume that password reset links were intercepted. You should consider forcing a password reset for all your users. At a minimum, closely monitor for account takeover activity.
Strategic Hardening
- NEVER Hardcode Secrets: This is the root cause. You must implement a proper secrets management solution. Use a tool like HashiCorp Vault or your cloud provider's native secrets manager (e.g., AWS Secrets Manager). Your application should fetch the Postmark API key at runtime from this secure, audited vault.
- Use Postmark's IP Allowlisting: In your Postmark account settings, you can configure an IP safelist. This restricts API access so that it is only accepted from your specific, trusted production server IP addresses. This is a highly effective control that would have blocked the attacker from using the stolen key remotely.
- Protect Your Developers: The initial compromise is often a developer. You must secure their accounts with strong, phishing-resistant MFA like YubiKeys and protect their workstations with a powerful EDR.
- Invest in Secure Coding Training: Your developers are your first line of defense against vulnerabilities. A culture of security starts with education. Invest in a continuous training program on secure coding best practices from a provider like Edureka to ensure they never make the critical mistake of hardcoding secrets again.
Chapter 5: Extended FAQ for Developers and Security Teams
Q: Is Postmark itself breached?
A: No. Based on our current analysis, this is not a breach of Postmark's own infrastructure. This is a campaign that targets Postmark's *customers* by stealing their individual API keys through other means and then abusing the legitimate Postmark API.
Q: What is a webhook and why is it a stealthy backdoor?
A: A webhook is a mechanism where an application automatically sends data to another application when an event occurs. In Postmark, you can configure a webhook to be notified every time an email is sent or delivered. It's stealthy because adding a new webhook is a less obvious change than adding a BCC address to an email stream, but it achieves the same result of exfiltrating the full email content.
Q: We use environment variables for our API keys. Are we safe?
A: Using environment variables is much better than hardcoding keys in source code, but it is not a complete solution. If an attacker gains shell access to your server, they can often easily read the environment variables of the running application process. A dedicated secrets management solution that provides short-lived, just-in-time access to secrets is the most secure architecture.
Join the CyberDudeBivash ThreatWire Newsletter
Get deep-dive reports on application security threats, supply chain attacks, and DevSecOps best practices delivered to your inbox. Protect your code, protect your company. Subscribe now.
Subscribe on LinkedIn
Related Security Directives from CyberDudeBivash
#CyberDudeBivash #Postmark #AppSec #DevSecOps #ThreatIntel #DataBreach #APIsecurity #CyberSecurity #InfoSec
Comments
Post a Comment