Hackers Are Mining GitHub for Amazon Credentials—Then Spamming the World From Your Own Domain

A new Kaspersky writeup published on May 4, 2026 details a phishing pipeline that has very little to do with email security and everything to do with cloud secrets management. Attackers are scanning public code, finding AWS Identity and Access Management keys with permission to send mail through Amazon Simple Email Service, and using those keys to broadcast phishing from inside Amazon's own infrastructure.

The trick is that the resulting messages pass every standard email authentication check. SPF, DKIM, and DMARC all return clean. The headers carry an amazonses.com identifier. The sending IP belongs to AWS, not a residential botnet. By the time a spam filter looks at the message, every signal it normally relies on says "this is a legitimate corporate email."

The numbers attached to this technique are not small. One independent analysis recorded a single SES tenant emitting over 50,000 phishing messages a day before being shut down.

The Attack Starts in a Git Push You Did Not Mean to Make

An IAM access key is a pair of strings. The first looks like AKIA followed by sixteen characters. The second is a 40 character secret. Together they grant whatever permissions the IAM policy attached to that key allows. If the policy includes ses:SendEmail, anyone holding the key can send mail from any verified domain in that AWS account.

Developers leak these keys constantly. They live in .env files that get committed by accident. They sit inside Docker images that get pushed to public registries. They appear in configuration backups uploaded to S3 buckets without a bucket policy. They show up inside open source project commits where someone forgot to redact a line before submitting a pull request.

GitGuardian, the company that monitors for secret exposure across public Git repositories, has published recurring reports showing tens of thousands of AWS credentials leak every year. The Wiz cloud security team says it observes "tens of newly compromised cloud access keys each month, fueling hundreds of exploitation attempts."

TruffleHog and the Industrialization of Secret Hunting

The tool that turns scattered leaks into a phishing platform is TruffleHog, an open source secret detector originally built by red teamers and defenders to find credentials in Git history before attackers did. The same scanning logic works just as well in reverse. Phishers run TruffleHog, or automated forks of it, against the public GitHub event firehose, against PyPI and npm package contents, and against Docker Hub images. The moment a key surfaces, a script grabs it.

Once the attacker has a candidate key, the validation flow is well documented. Kaspersky describes it in three calls:

1. GetCallerIdentity confirms the key works and reveals the AWS account ID.
2. GetSendQuota reveals whether this account is in the SES sandbox or has production sending limits, and what those limits are.
3. GetAccount exposes the verified sender identities and reputation status.

Wiz documented an additional clever step. The attackers fire PutAccountDetails requests across every AWS region simultaneously, all within ten seconds. The goal is to have at least one region grant production sending privileges before AWS's behavioral monitoring catches the burst.

What the Phishing Looks Like in Your Inbox

Two themes dominate the campaigns Kaspersky has tracked in early 2026.

Fake DocuSign or Adobe Sign notifications. The email mimics the styling of a real document signing request. The "review document" link redirects to a phishing page hosted at an amazonaws.com subdomain. Because the email itself was sent through SES and the landing page is hosted on AWS, both halves of the lure inherit Amazon's reputation. Most enterprise filters that scan link reputation see the AWS domain and wave the message through.

Business email compromise. The more sophisticated variant Kaspersky describes is a fabricated email thread. The message body reproduces what looks like a multi message conversation between an employee and a vendor, complete with quoted replies and a forged invoice PDF. There is no malicious link, only payment routing details. The intended victim is somebody in finance who reads the thread and processes the payment.

Wiz separately observed a 2024 tax form scam that fired during the spring filing window with subject lines like "Your 2024 Tax Form(s) Are Now Ready to View and Print" sent from attacker registered domains such as managed7.com, street7news.org, and street7market.net.

Why Email Security Tools Cannot Block It

Standard anti spam techniques mostly fail against this attack class. The message is sent through the same Amazon SES infrastructure that legitimate brands like Netflix, DoorDash, Slack, and Zoom rely on for billions of transactional emails per month. Block AWS sending IPs and you take down legitimate email for half the internet at the same time.

Domain reputation does not save you either. The attacker is sending from a verified domain owned by the compromised AWS account. From the recipient's vantage point, the message comes from a real company that has been sending real transactional email for years. The fact that this particular email was generated by an attacker who hijacked the company's SES API access is invisible at the inbox layer.

Microsoft and Google can sometimes detect anomalies in sending patterns, but only in aggregate. Microsoft's Q1 2026 numbers showed 8.3 billion phishing messages blocked in 90 days, and the trend is accelerating. The volume that gets through is what fills inboxes.

What Companies Are Supposed to Do

Both Kaspersky and Wiz published mitigation lists. They look almost identical because the underlying problem is the same:

• Stop using long lived IAM access keys. Move workloads to IAM roles where the credentials are temporary and rotate automatically. Where keys are unavoidable, rotate them on a schedule and never check them into source control.
• Apply least privilege religiously. An IAM policy that only needs to read from one S3 bucket should not also grant ses:SendEmail. Most leaked keys have far more permissions than the application needs.
• Block SES at the Service Control Policy layer for AWS accounts that do not actually send email. Any subsequent SendEmail call from those accounts is automatically blocked, regardless of which key the attacker has.
• Watch CloudTrail for dormant key reactivation and for the multi region PutAccountDetails burst Wiz documented. Both are high signal indicators that a leaked key is being weaponized.
• Run TruffleHog against your own repositories. The tool that attackers use to find your secrets is the same tool you can run against your own org and your own developers' personal GitHub accounts.

None of those defenses help the people receiving the resulting phishing. They protect the AWS customer whose key got stolen, not the millions of inboxes the stolen key was used to spray.

The Bigger Pattern

SES abuse is not a new technique, but the volume has shifted significantly. Robinhood was used in April as a phishing relay through legitimate user account flows. Apple's own email servers have been weaponized in the same way. Hackers compromised Vercel through one stolen Google account at an AI startup. The common thread is that the attacker no longer needs to set up infrastructure. They borrow yours.

For phishing specifically, the practical implication is that "trusted sender" is becoming a meaningless category at the SMTP layer. The headers say a message came from a real domain at a real company because in a narrow technical sense, it did. The fact that an attacker briefly held the keys to that infrastructure is invisible until the message lands in your inbox.

What Recipients Can Actually Do

For end users, the implication is that traditional sender verification cues, the green padlock, the "verified" sender badge, the corporate logo, the official sounding domain, are no longer enough. A phishing email coming through a hijacked Amazon SES tenant will pass every visual check that an inbox provides.

A few practical habits help:

• Never trust a "review document" or "verify your account" link inside an email. Open the service directly in a new tab and check from your account dashboard.
• Treat invoice changes and payment routing requests as inherently suspicious, regardless of how convincing the conversation thread looks. Confirm out of band, by phone or in person.
• Be especially skeptical of email signed by services you have no relationship with. A DocuSign notification you were not expecting is almost certainly bait.
• Block tracking pixels and remote content where possible. The pixels do not deliver the phishing payload, but they confirm to the attacker that your address is live, which causes them to send more.

Gblock blocks tracking pixels and known phishing beacons inside Gmail. It cannot stop a malicious link from arriving, but it does prevent the attacker from learning that you opened the message, which removes you from the active targeting list these phishing operators sell. In a world where every credential leak inside someone else's AWS account becomes another phishing campaign in your inbox, removing yourself from the high engagement list is one of the few moves that compounds in your favor.