Introduction

The primary goal for attackers in a phishing campaign is to bypass email security and trick the potential victim into revealing their data. To achieve this, scammers employ a wide range of tactics, from redirect links to QR codes. Additionally, they heavily rely on legitimate sources for malicious email campaigns. Specifically, we’ve recently observed an uptick in phishing attacks leveraging Amazon SES.

The dangers of Amazon SES abuse

Amazon Simple Email Service (Amazon SES) is a cloud-based email platform designed for highly reliable transactional and marketing message delivery. It integrates seamlessly with other products in Amazon’s cloud ecosystem, AWS.

At first glance, it might seem like just another delivery channel for email phishing, but that isn’t the case. The insidious nature of Amazon SES attacks lies in the fact that attackers aren’t using suspicious or dangerous domains; instead, they are leveraging infrastructure that both users and security systems have grown to trust. These emails utilize SPF, DKIM, and DMARC authentication protocols, passing all standard provider checks, and almost always contain .amazonses.com in the Message-ID headers. Consequently, from a technical standpoint, every email sent via Amazon SES – even a phishing one – looks completely legitimate.

Phishing URLs can be masked with redirects: a user sees a link like amazonaws.com in the email and clicks it with confidence, only to be sent to a phishing site rather than a legitimate one. Amazon SES also allows for custom HTML templates, which attackers use to craft more convincing emails. Because this is legitimate infrastructure, the sender’s IP address won’t end up on reputation-based blocklists. Blocking it would restrict all incoming mail sent through Amazon SES. For major services, that kind of measure is ineffective, as it would significantly disrupt user workflows due to a massive number of false positives.

How compromise happens

In most cases, attackers gain access to Amazon SES through leaked IAM (AWS Identity and Access Management) access keys. Developers frequently leave these keys exposed in public GitHub repositories, ENV files, Docker images, configuration backups, or even in publicly accessible S3 buckets. To hunt for these IAM keys, phishers use various tools, such as automated bots based on the open-source utility TruffleHog, which is designed for detecting leaked secrets. After verifying the key’s permissions and email sending limits, attackers are equipped to spread a massive volume of phishing messages.

Examples of phishing with Amazon SES

In early 2026, one of the most common themes in phishing emails sent with Amazon SES was fake notifications from electronic signature services.

The email’s technical headers confirm that it was sent with Amazon SES. At first glance, it all looks legitimate enough.

In these emails, the victim is typically asked to click a link to review and sign a specific document.

Upon clicking the link, the user is directed to a sign-in form hosted on amazonaws.com. This can easily mislead the victim, convincing them that what they’re doing is safe.

The resulting form is, of course, a phishing page, and any data entered into it goes directly to the attackers.

Amazon SES and BEC

However, Amazon SES is used for more than just standard phishing; it’s also a vehicle for a very sophisticated type of BEC campaigns. In one case we investigated, a fraudulent email appeared to contain a series of messages exchanged between an employee of the target organization and a service provider about an outstanding invoice. The email was sent as if from that employee to the company’s finance department, requesting urgent payment.

The PDF attachments didn’t contain any malicious phishing URLs or QR codes, only payment details and supporting documentation.

Naturally, the email didn’t originate with the employee, but with an attacker impersonating them. The entire thread quoted within the email was actually fabricated, with the messages formatted to appear as a legitimate forwarded thread to a cursory glance. This type of attack aims to lower the user’s guard and trick them into transferring funds to the scammers’ account.

Takeaways

Phishing via Amazon SES experienced an uptick in January 2026 and has remained relatively steady through Q1. By weaponizing this service, attackers avoid the effort of building dubious domains and mail infrastructure from scratch. Instead, they hijack existing access keys to gain the ability to blast out thousands of phishing emails. These messages pass email authentication, originate from IP addresses that are unlikely to be blocklisted, and contain links to phishing forms that look entirely legitimate.

Since these Amazon SES phishing attacks stem from compromised or leaked AWS credentials, prioritizing the security of these accounts is critical. To mitigate these risks, we recommend following these guidelines:

• Implement the principle of least privilege when configuring IAM access keys, granting elevated permissions only to users who require them for specific tasks.
• Transition from IAM access keys to roles when configuring AWS; these are profiles with specific permissions that can be assigned to one or several users.
• Enable multi-factor authentication, an ever-relevant step.
• Configure IP-based access restrictions.
• Set up automated key rotation and run regular security audits.
• Use the AWS Key Management Service to encrypt data with unique cryptographic keys and manage them from a centralized location.

We recommend that users remain vigilant when handling email. Do not determine whether an email is safe based solely on the From field. If you receive unexpected documents via email, a prudent precaution is to verify the request with the sender through a different communication channel. Always carefully inspect where links in the body of an email actually lead. Additionally, robust email security solutions can provide an essential layer of protection for both corporate and personal correspondence.

A researcher has discovered a weakness called PhantomRPC that Microsoft does not consider a vulnerability it plans to patch.

PhantomRPC involves Windows Remote Procedure Call (RPC), the core of communication between Windows processes. The vulnerability lets a process with impersonation rights escalate to SYSTEM by impersonating high‑privileged clients that connect to a fake RPC server.

The researcher presented a detailed technical report outlining five exploitation paths, including coercion, user interaction, or background services. They warned that potential vectors are “effectively unlimited” because the root issue is architectural.

Microsoft, however, classified the issue as “moderate,” refused a bounty, declined to assign a CVE (a spot in the list of Common Vulnerabilities and Exposures), and closed the case without tracking. Its position is that the technique requires an already‑compromised machine and does not provide unauthenticated or remote access.

Experts disagreed with Microsoft’s assessment. Their concern is that Microsoft is downplaying a systemic local privilege escalation technique that exists in all supported Windows versions.

The issue

At the core of this issue is that the Windows RPC runtime does not sufficiently verify that the server a high‑privileged client connects to is the intended legitimate endpoint.

If a legitimate RPC server is not reachable (for example because the service stopped, was misconfigured, not installed, or due to a race condition), an attacker with SeImpersonatePrivilege can spin up a fake RPC server that “fills the gap” using the same interface and endpoint.

When a SYSTEM or high‑privileged client connects to this fake server, using an impersonation level that allows the server to impersonate the client, the attacker can call RpcImpersonateClient and immediately escalate their privileges to SYSTEM.

From Microsoft’s perspective, the ability to run a rogue RPC server in this way falls under the category of “already compromised.”

SeImpersonatePrivilege

To understand the issue better, we need to dig into what SeImpersonatePrivilege does.

Basically, SeImpersonatePrivilege is the Windows permission that lets a program “pretend to be you” after you’ve already logged in, so it can do things on your behalf using your level of access.

It’s needed because many system services and server‑type apps (file sharing, RPC servers, COM servers, web apps) have to perform actions on behalf of a user, like reading their files or applying group policy.

If an attacker gains this privilege, they can create a fake service or server and wait for a more powerful account to talk to it. When that high‑privilege service connects, the attacker can grab its security token and impersonate it, effectively upgrading from an account with lower privileges to full SYSTEM control on that machine.

Protection

A Microsoft spokesperson provided the following statement:

“This technique requires an already-compromised machine and does not grant unauthenticated or remote access. Any update is a balance between existing compatibility and customer risk, and we remain committed to continually hardening our products. We recommend customers follow security best practices, including limiting administrative privileges and applying the principle of least privilege.”

In our opinion, mitigating PhantomRPC properly would require deep changes to the RPC architecture, which is hard to do on existing Windows versions without breaking compatibility. It’s maybe something we’ll see in future versions, given the scale of change needed.

What you can do:

• As PhantomRPC is a piece in a larger chain, it is still very important to keep Windows updated.
• Use your admin account sparingly and only for the tasks that need that kind of privilege.
• Use an up-to-date, real-time anti-malware solution that can detect and block suspicious privilege‑escalation activity.
• Avoid disabling or “hardening” services blindly since a malicious service might step in their place.

To answer the question in the title: it looks like a “feature” that can be abused in many ways; one that has outlived its original threat model. Defenders have to treat them as ongoing risks, rather than one‑off CVEs.

---

---