Blog · Dmarc
How APT Groups Use Legitimate Cloud Infrastructure for Email Attacks (And How to Detect Them)
Why APT Groups Moved From Rogue Servers to AWS, Azure, and Google Cloud
When blocklists worked, attackers used rogue SMTP servers. They sent phishing from throwaway IPs, got them listed within hours, and moved on. That model is not dead, but it has a problem: speed.
Modern blocklists and reputation feeds update faster than many security teams can act. A rogue IP that lands on a major blocklist today is useless for email delivery tomorrow. So sophisticated threat actors shifted to infrastructure that already has a trusted reputation.
AWS, Azure, and Google Cloud have been sending legitimate email for years. Their sending IPs have decades of good reputation with receivers worldwide. An email sent from an EC2 instance or a GCP compute engine looks like regular cloud service traffic to most filtering systems. It passes SPF checks because the cloud providers publish their own SPF records. It may pass DKIM if the cloud service signs the message with its own key.
This is not theoretical. Microsoft, Google, and Amazon have all published research documenting APT groups abusing their cloud infrastructure for email-based attacks. The pattern is consistent: use the cloud provider's own SMTP infrastructure, send from IPs with strong reputation, and land in inboxes that a rogue server never would have reached.
The result is an attack that traditional email blocklisting cannot stop. You cannot block AWS SES sending IPs without blocking a large fraction of legitimate cloud email in the process.
How Gamaredon Abuses Cloud Infrastructure for Email Attacks
Gamaredon Group is a well-documented APT operation with ties to Russian state interests, primarily targeting government institutions in Ukraine and NATO member states. What makes Gamaredon relevant here is their systematic abuse of legitimate cloud infrastructure for email operations.
Instead of running their own SMTP servers, Gamaredon creates accounts on legitimate cloud platforms, activates email sending capabilities, and uses those platforms to distribute phishing lures. The emails come from addresses like no-reply@amazonaws.com or no-reply@cloudgoogle.com. The sending domains are aws.amazon.com and cloud.google.com. These domains pass SPF and DKIM checks at the receiver because the cloud providers control the authentication records.
From a DMARC perspective, these messages fail alignment if the From header claims to be from yourdomain.com but the SPF and DKIM are controlled by the cloud provider. A properly configured DMARC policy at p=reject would cause these messages to fail because neither SPF nor DKIM aligns with the impostor From domain.
But Gamaredon-style campaigns do not always impersonate the victim domain in the From header. In many observed campaigns, the From header shows the cloud provider address while the body contains the impersonation content. The phishing content is there, the social engineering is there, but the From address passes DMARC because the From domain matches the cloud provider.
This is the pattern that aggregate DMARC reports are well suited to detect.
What Cloud Infrastructure Abuse Looks Like in a DMARC Aggregate Report
A DMARC aggregate report does not show message content. It shows who is sending mail claiming to come from your domain and whether that mail passed or failed authentication. This is exactly the signal you need when an APT group is using cloud infrastructure to send phishing.
When an EC2 instance sends mail claiming to be from yourdomain.com, your aggregate report will show that IP in the `
But Gamaredon-style campaigns that use the cloud provider as the From address do not trigger DMARC failures for your domain. They show up differently: mail from cloud provider IPs where the From address is the cloud provider itself. This means your domain never appears in a DMARC failure record, but it does appear in your aggregate report as a source you did not authorize sending on your behalf.
This is why monitoring matters. The signal is there whether or not DMARC fails.
A practical example: your daily aggregate report normally shows 50 source IPs. You suddenly see 200, with half from AWS IP ranges you have never authorized. The DKIM results show passes from amazon.com. Your domain does not use AWS SES. That pattern is a cloud infrastructure anomaly worth investigating.
Three Ways to Detect Cloud Infrastructure Abuse Using Your DMARC Data
These detection methods require looking at your aggregate reports with the right questions. DMARCFlow automates this analysis by continuously monitoring for the specific indicators below.
1. Monitor for cloud provider sending IPs you did not authorize
Your aggregate reports should show only IPs you control or third-party senders you explicitly authorized (marketing automation platforms, CRM systems, helpdesk tools). When you see IP addresses from AWS, Azure, or GCP that are not part of your approved sender list, that is a signal worth investigating.
DMARCFlow parses aggregate reports and flags sending sources that do not match your known sender inventory. An unfamiliar cloud provider IP appearing without a corresponding authorization record is exactly the anomaly a monitoring tool should catch automatically, not something you have to manually review.
2. Watch for sudden volume spikes from unfamiliar sending infrastructure
APT groups often send in bursts. They create a cloud account, send a campaign, and abandon the account. This pattern shows up as a spike in aggregate report volume from a source you did not authorize. If your daily report normally covers 50 source IPs and suddenly shows 200, with a significant portion from cloud provider ranges, that is a signal.
Baseline your normal sending patterns. DMARCFlow tracks sending volume by source over time, making it straightforward to spot deviations without manually comparing reports.
3. Look for DKIM signatures from cloud providers on mail that does not include your domain in From
When an attacker uses cloud infrastructure with the From header set to your domain, the DKIM signature is still from the cloud provider. Your aggregate report will show DKIM pass from the cloud provider domain while your domain is the From address. That is a DMARC fail scenario. Sophisticated attackers may avoid this by omitting DKIM, but the signal remains: DKIM passes from a cloud provider on mail that does not come from your infrastructure.
If your aggregate reports show DKIM pass results from cloud providers without corresponding SPF alignment to your domain, DMARCFlow flags that as a cloud infrastructure anomaly.
FAQ
Can I block AWS, Azure, and Google Cloud from sending email on behalf of my domain?
Not entirely. These providers operate legitimate email sending services used by millions of organizations. A blanket block on their IP ranges would break legitimate cloud-delivered email. What you can do is monitor who is sending from your domain via DMARC aggregate reports, and ensure your policy is set to reject mail that fails alignment.
Does SPF help detect cloud infrastructure abuse?
SPF alone does not prevent cloud infrastructure abuse because cloud providers publish their own SPF records. An attacker using AWS SES to send mail can include amazon.com in the envelope sender, which passes SPF. The limitation is that SPF does not tell you whether the From header matches the sending domain. That is what DMARC alignment checks for.
Does DKIM help?
DKIM is more useful for detection than prevention in this context. A DKIM signature from a cloud provider on mail that does not come from your domain is a signal. The DKIM result in your aggregate report tells you who signed the message. When the signer is a cloud provider and you have not authorized that provider to send on your behalf, that is an anomaly.
Can I detect this without a monitoring tool?
You can, but it requires manually reviewing aggregate reports daily and maintaining an inventory of authorized senders. Most organizations find this unsustainable. A monitoring tool that parses aggregate reports automatically, maintains a sender inventory, and flags deviations is the practical solution for this detection layer.
Summary
Cloud infrastructure abuse is not a theoretical threat. Named APT groups use it because it works. The mail passes reputation checks, lands in inboxes, and evades blocklists that would stop a rogue SMTP server in hours.
Traditional email security focuses on blocking known bad senders. DMARC and authentication standards focus on proving a sender is authorized. The gap is monitoring: knowing what infrastructure is sending mail claiming to come from your domain.
Your DMARC aggregate reports contain the signals. Cloud provider IPs you did not authorize. Sudden volume spikes from unfamiliar sources. DKIM signatures from providers that do not belong to your infrastructure. These patterns do not prove an attack is underway, but they tell you where to look.
Set your DMARC policy to reject mail that fails alignment. Monitor your aggregate reports for the anomalies described above. DMARCFlow automates this monitoring, continuously comparing new aggregate report data against your authorized sender inventory and flagging cloud provider anomalies before they become undetected attack campaigns.