Amazon Password Reset Callback Campaign Exploits Legitimate Notification Infrastructure

7 April 2026

By Ankit Gutpa, Andrew Gosney, Hiwot Mendahun, Samantha Clarke and the Mimecast Threat Research Team

Campaign Overview

In March 2026, the Mimecast Threat Research team identified a callback phishing campaign that weaponized Amazon's own password-recovery notification system. Unlike traditional phishing that relies on lookalike domains or link-based attacks, this campaign leveraged legitimate Amazon infrastructure to deliver high-trust social engineering messages at high speed. Threat actors controlled an Amazon account used to trigger password-recovery notifications and injected malicious content including instructions to callback phone number into the username fields that appear in the notification template. The result: messages pass all authentication checks and display as genuine Amazon communications.

The Lure: Engineered Urgency

Recipients received what appeared to be a legitimate alert indicating someone had requested a password reset on their Amazon account. Rather than embedding a malicious link, the message created urgency around a phone number, instructing recipients to call if they had not requested the reset.

This callback pattern deliberately shifts the attack off email security controls and URL reputation systems onto voice channels, where verification is harder and impostors can adapt their approach in real time. When paired with an authenticated Amazon template, the likelihood of recipient trust increases significantly.

 

 

 

Technical Process Flow: Forwarding as Amplification

The campaign's volume and speed stemmed from a multi-hop forwarding chain that turned one accepted message into mass delivery:

1. Create Amazon account: Threat actor registers for an Amazon account using a Proton Mail Group Address and a username such as [Not You ? Call Now : 1-(805) 334 9416]. This manipulation of the username is what allows automated notifications to include the malicious content set by the threat actor.
2. Password recovery: Once the Amazon account has been created, the threat actor initiates a password recovery process.
3. Initial notification delivery: The password recovery notification is sent to the Proton Mail Group Address with the manipulated username within the notification. This email is sent from the legitimate Amazon notification service and includes all the authentication headers such as SPF, DKIM and DMARC from Amazon services.
4. Proton forwarding: Emails sent to the Proton Mail group Address then forwards the email notification into a Microsoft 365 hub tenant owned or compromised by the threat actor which would include a number of external recipients.
5. Microsoft Amplification: When Microsoft receives the fully authenticated forwarded message it prepares it for delivery to the final list of external recipients. Microsoft SRS (Sender Rewrite Scheme) service is used in these campaigns which rewrites the envelope-sender, making Microsoft the sender of record and adding its own valid authentication (SPF/DKIM) to ensure delivery. It also has the authentication of Amazon intact in the headers.
6. External Broadcast: The external recipients' systems will then check the email’s authentication. The visible ‘From’ address would be the legitimate Amazon email address. However, the envelope address would be an address associated with Microsoft such as [bounces+srs=v1zju=bn@[customer].onmicrosoft.com] and with a valid authentication from Microsoft via SRS would be identified allowing this email to pass all authentication checks.

This amplification relied on Sender Rewriting Scheme (SRS), a legitimate email forwarding mechanism. When email is forwarded, the original envelope sender is often rewritten so delivery failures return to the forwarding system rather than the upstream sender. In legitimate use, SRS enables proper mail flow through mailing lists. In this abuse scenario, a hub that accepts one message can send it out to many recipients within seconds, with each delivery leg potentially showing rewritten sender metadata. Additional information on the Microsoft SRS service can be found here.

Why Authentication Isn't Enough

This campaign exposes a critical gap in email security understanding. Strong DKIM signatures and aligned domains confirm who signed the mail, they do not validate every word within the message body. When a service allows user-supplied text inside system-generated mail, that text becomes attacker-controlled content inside a high-trust envelope. For defenders, the lesson is clear: authentication mechanisms describe message provenance, not message safety. Organizations must layer behavioral analysis, content inspection, and user education alongside authentication protocols.

Victim Callback

The primary objective of these campaigns is to manipulate victims into calling the phone number provided in the notifications. Once contact is made, threat actors can employ advanced social engineering tactics to exploit the victim. These tactics may include:

• Convincing users to download remote monitoring and management (RMM) tools.
• Directing users to malicious websites.
• Extracting sensitive personal information.
• Coercing users into making fraudulent payments.

Such callback campaigns are highly dangerous as they bypass traditional email security measures by moving the attack to voice-based channels, where verification is more challenging.

Indicators of Compromise (IOCs)

Header Email address - (legitimate Amazon notification sending addresses)

account-update@amazon[.]com
account-update@amazon[.]co[.]uk

Header Recipient Email Address

updates_a_ccs@groups[.]proton[.]me
notifications_a_dd@groups[.]proton[.]me
updates_a_bb@groups[.]proton[.]me
notifications_acc@groups[.]proton[.]me
updates_a_b@groups[.]proton[.]me
notifications_a_bb@groups[.]proton[.]me
notifications_a_b@groups[.]proton[.]me
membership-09293@groups[.]proton[.]me
user-09838@groups[.]proton[.]me
user-00837@groups[.]proton[.]me
notifications_a4@groups[.]proton[.]me
notifications_a3@groups[.]proton[.]me
notifications_a2@groups[.]proton[.]me

Subjects

amazon.com: Password recovery
amazon.com: Account data access attempt

Targets

Geographic Focus: Campaigns exhibited targeting across a number of regions with high concentrations in the US.

Industry Vertical: Across many industries slightly higher levels seen in Legal and manufacturing businesses.

Recommendations

• Educate employees on the specific characteristics of this campaign, along with implementing best practices around calling phone numbers provided in unsolicited emails. Instead, they should navigate directly to the service provider's official website or use previously verified contact information.
• Search email receipt logs for messages from Amazon and subject lines listed

Long-Term Considerations

Organizations should recognize that legitimate services with user-supplied content fields create potential abuse vectors. Evaluate which trusted senders allow personalization and educate users that authentication alone does not guarantee safety. As threat actors continue to weaponize legitimate infrastructure, detection strategies must evolve from "who sent this" to "what is this message trying to accomplish."