Hackers Are Using AWS Infrastructure to Bypass All Email Security Systems
Summary of the campaign
Since the beginning of 2026, Kaspersky has noted a significant increase in phishing campaigns and Business Email Compromise (BEC) exploiting Amazon Simple Email Service (SES) — not through software vulnerabilities, but via leaked AWS IAM access keys. By hijacking a third party's key, attackers send thousands of phishing emails without the cost of building their own infrastructure. What sets this campaign apart: emails are sent from Amazon's infrastructure — bypassing SPF, DKIM, DMARC, originating from non-blocklisted IPs, and containing redirect links through amazonaws.com. From a technical standpoint, the emails appear completely legitimate.
Two main attack branches have been identified:
Regular phishing — impersonating DocuSign notifications, leading victims to a fake login page on amazonaws.com to steal credentials.
BEC/Invoice Fraud — impersonating internal email threads about payment invoices, including a PDF without malicious URLs to bypass scanners, aiming to trick the finance department into transferring money.
Timeline & Background
| Time | Event |
|---|---|
| 2024–2025 | Phishing through legitimate cloud services (Microsoft 365, Google Workspace) becomes a popular trend. |
| Early Q1 2026 | Kaspersky noted a significant spike in phishing campaigns sent through Amazon SES. |
| 04/05/2026 | Kaspersky publishes a detailed analysis report on Securelist. |
| Currently | Trend shifts from isolated incidents → steady, ongoing campaign |
This campaign is not a sudden phenomenon—it's a natural progression of the trend where attackers shift towards "Living off Trusted Services" (LoTS): instead of building their own easily blockable domains, they rent or hijack the infrastructure of major providers with high reputations.
Attack chain
Phase 1 — Reconnaissance & Credential Harvesting (T1552.001)
Attackers use automated tools, most commonly TruffleHog (open-source, scans for secrets in git history and code), to hunt for exposed AWS IAM access keys in public sources.
GitHub repositories — developer mistakenly commits a file containing a key into a public repo
ENV files — .env file with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY pushed to a repo
Docker images — credentials hardcoded in Dockerfile or baked into the image layer
Configuration backups — config file mistakenly uploaded to a public S3 bucket
Exposed S3 buckets — bucket misconfigured, allowing anonymous read
Attackers don't need to target Amazon directly—they exploit operational errors by developers and admins.
Phase 2 — Validation & Preparation
After collecting the key, the attacker performs:
Verify the key is still active and has permission to use SES
Check the sending limit (SES sandbox vs. production) and sending rate
Verify the target list (email harvesting from LinkedIn, data breach, etc.)
Prepare an HTML email template impersonating reputable brands (DocuSign, Microsoft, etc.)
Prepare a phishing landing page on an amazonaws.com subdomain or a separate domain
Phase 3 — Weaponization (T1566.002)
The attacker configures the email campaign with technical elements to maximize delivery and phishing effectiveness:
SPF/DKIM/DMARC pass: Emails sent via SES are automatically signed by Amazon, meeting all email authentication standards
Message-ID header contains .amazonses.com — appears completely legitimate to email security tools
Redirect chain: Link in the email points to amazonaws.com → then redirects to the actual phishing page
Custom HTML template: SES supports full HTML templates, allowing for professional-looking emails
Phase 4 — Delivery (T1566.001)
Emails are blasted in large volumes via the SES API:
Source IPs belong to the Amazon AWS range—aren't blocklisted by any reputation service (blocking would cause false positives for millions of legitimate Amazon SES users)
Emails pass all standard spam filter checks
Volume isn't limited by individual sending reputation due to using Amazon's shared IP pool
Phase 5A — Exploitation: Standard Phishing (T1056.003)
In a typical phishing campaign, the victim receives a fake email notification from an eSign service (DocuSign was the most common topic in Q1/2026). The email requests the signing of a document. When clicking the link:
The initial URL leads to a subdomain on amazonaws.com (the victim recognizes the domain and feels secure).
It automatically redirects to a fake sign-in page, which may be hosted on amazonaws.com or a separate domain.Trang giả render form đăng nhập Microsoft/Google/Office 365
All credentials entered are sent directly to the attacker.
No malware, no attachments—just pure credential harvesting through a web interface.
Phase 5B — Exploitation: BEC / Invoice Fraud (T1534)
The BEC branch is much more sophisticated. The attacker impersonates an internal email, often from senior staff or the accounting/purchasing department, and sends it to the finance department. The email includes:
Fabricated email thread: A manually crafted thread presented as a legitimate exchange between employees and a supplier about an invoice awaiting payment
PDF attachment: Contains payment information and "supporting documents"—no malicious URLs or QR codes in the PDF
This is a crucial evasion point: most email security gateways scan attachments for malicious URLs/macros. The PDF only contains payment information → clean. The attachment passes through the scanner without being flagged. Objective: convince the finance department to transfer money into the attacker's bank account, presented as a legitimate supplier account.
Phase 6 — Collection
Phishing: Real-time credential collection allows the attacker to use them immediately (account takeover, lateral phishing).
BEC: There is no technical "collection" phase—success occurs when the victim transfers money themselves.
Detailed technical analysis
Why Amazon SES is More Dangerous Than Regular Phishing Most email security gateways operate on reputation-based and signature-based principles. Amazon SES breaks through both these defenses:
| Conventional defense mechanisms | Effectiveness vs. SES abuse |
|---|---|
| SPF check | ❌ Fail — email qua SES pass SPF của Amazon |
| DKIM signature | ❌Fail — Amazon signs the email with their key, making the DKIM valid. |
| DMARC alignment | ❌Fail — alignment passes when the From domain aligns with Amazon |
| IP reputation blocklist | ❌ Fail — Amazon SES IPs cannot be blocklisted (too many false positives) |
| Domain reputation | ❌ Fail — amazonaws.com is the most trusted domain on the internet |
| URL scanner | ⚠️ Partial — if the link points directly to a phishing domain; but redirecting through amazonaws.com might bypass |
| Attachment scanner | ❌ Fail (with BEC) — PDF does not contain malicious payload |
Only behavioral analysis and AI-based content analysis can detect this, but not every organization implements these layers.
The most common leak vectors in order of occurrence:
GitHub public repo — developers push .env files or configs containing credentials; even if deleted, GitHub history remains
Docker Hub — image public with credentials baked into the layer; docker history or layer extraction can recover
Public S3 bucket — config file or backup mistakenly uploaded to a bucket without access control
CI/CD log — pipeline log exports key to stdout, log stored publicly
Paste sites and forums — developers share code for debugging without sanitizing credentials
TruffleHog automatically scans all these sources with pattern matching for AWS key formats. This tool is completely legal and widely used in DevSecOps, but attackers use it for malicious purposes.
Real phishing example — DocuSign Notification
Email headers of a sample analyzed by Kaspersky confirm the source sent via SES:
All authentication checks: pass. Nothing suspicious in the header. The email content falsely notifies of a document awaiting signature. Link in the email:
The victim sees amazonaws.com → clicks → phishing landing page requests login.
Real BEC Example — Invoice Fraud
A carefully crafted BEC email: the thread is fabricated to include a fake exchange between "employee" and "supplier" from a few days earlier, detailing a specific invoice, amount, and urgent payment reason. The final email in the thread — sent to the finance department — requests "urgent processing as the supplier needs payment before the deadline." The attached PDF contains:
Invoice Number
Replacement Bank Account Number (of attacker)
Fake "Supporting Document"
No malware. No malicious links. All scanners are clean. The only bait is social engineering—time pressure, fake authority, and email formatting that looks legitimate.
MITRE ATT&CK Mapping
| Tactic | Technique ID | Technique Name | Note |
|---|---|---|---|
| Resource Development | T1552.001 | Credentials in Files | Scan GitHub/Docker/S3 for IAM key |
| Resource Development | T1583.006 | Web Services | Exploiting SES instead of building a mail infrastructure |
| Initial Access | T1566.001 | Spearphishing Attachment | BEC with PDF attachment |
| Initial Access | T1566.002 | Spearphishing Link | Phishing via redirect link |
| Collection | T1056.003 | Web Portal Capture | The credential via fake login form |
| Impersonation | T1534 | Internal Spearphishing | Internal BEC Impersonation |
| Defense Evasion | T1036 | Masquerading | Use legitimate domain (amazonaws.com) |
| Defense Evasion | T1027 | Obfuscated Files | Redirect chain hides the actual destination |
| Exfiltration | T1041 | Exfiltration Over C2 Channel | Credential sent to attacker server |
Nhận định
"Living off Trusted Services" — Defensive weapons neutralized This trend isn't new — we've seen attackers abuse Microsoft 365 SMTP relay, Google Workspace, and SendGrid before. Amazon SES is just the next step in the same playbook: exploiting the trust that organizations and vendors have built over many years. The concern isn't the attacker's technique — it's the fundamental limitation of reputation-based defense. SPF/DKIM/DMARC are designed to authenticate who is sending the email, not whether the email has malicious intent. When attackers use Amazon's infrastructure to send, these three layers of authentication lose all distinguishing significance.
Why BEC via SES is particularly dangerous
BEC does not rely on malware or exploit techniques. It targets business processes and people. The PDF does not contain malicious payloads—this is intentional design, not a flaw. Attackers understand that current email scanners cannot distinguish between a PDF with fake account numbers and a legitimate one if the format looks professional. Organizations without procedures for verifying financial transactions through a secondary channel (such as a phone call or dedicated app) are ideal targets.
Risk level for organizations in Vietnam
There are three factors that make organizations in Vietnam more susceptible than usual: First, AWS adoption is rapidly increasing among Vietnamese developers, along with immature operational habits: hardcoding credentials in code, allowing long-term IAM keys to exist indefinitely, and not rotating keys regularly. Our observations from pentest and red team engagements show a significant rate of finding AWS credentials in the git history of enterprise clients. Second, the finance departments at Vietnamese SMEs often lack procedures for verifying transfers through a secondary channel. An "urgent email from the boss with an attachment" is enough to trigger action.
Third, many organizations still use email security gateways that only provide basic anti-spam/anti-virus protection—lacking behavioral analysis or AI content scoring. With SES abuse, this is a dangerous gap.
Pattern larger: Zero-cost Credential Weaponization
The attacker is engaging in what is known as credential arbitrage—collecting exposed keys from third-party sources (for free) to launch phishing attacks at nearly zero cost, with unlimited scale. If a key is revoked, the scanning tool automatically finds the next key. This attack model offers extremely high margins and low risk for the attacker.
Recommendations
Do not fully trust "legitimate" emails
Carefully check the email context
Verify the actual sender
Do not immediately click on login links
Do not open suspicious attachments even if the email seems "official"
Always verify financial requests through another channel.
Always verify through a phone call or in-person meeting
Do not change bank accounts based solely on email
Implement a dual approval process for transfers
Set up callback verification for large transactions
Be cautious of fake login pages
Check the actual domain before entering your password
Do not log in from links in emails
Access the website directly using a bookmark
Carefully observe unusual URL redirects
Enable Multi-Factor Authentication (MFA) Do not store AWS Keys in source code Monitor anomalies on AWS SES Apply Zero Trust to internal email Conduct regular phishing awareness training, currently implemented:
Regular phishing simulations
Red team email exercises
Incident reporting culture
Refer to
https://securelist.com/amazon-ses-phishing-and-bec-attacks/119623/
https://cyberpress.org/attackers-abuse-amazon-ses/
https://gbhackers.com/attackers-exploit-amazon-ses/
https://www.bleepingcomputer.com/news/security/researchers-report-amazon-ses-abused-in-phishing-to-evade-detection/
