The Phishing Relay Running on Government Cloud Infrastructure

The email came from an EC2 instance running in AWS GovCloud. Not the standard commercial AWS regions that show up in phishing campaigns every week. GovCloud. The us-gov-west-1 region, reserved for government agencies and contractors handling regulated workloads under FedRAMP, ITAR, and DoD compliance frameworks.

The message was plain text. No links. No attachments. No credential forms. Just a short list of filenames formatted to look like an automated report download notification. The display name, "Ubuntu," matched a known internal system identity at the target organization.

There was nothing to scan because there was nothing malicious in the payload. The reconnaissance was the message itself.

GovCloud as a Phishing Relay

The sending IP, 56[.]136[.]38[.]135, resolved to a PTR record of ec2-56-136-38-135.us-gov-west-1.compute.amazonaws[.]com. That PTR confirms the instance was running in AWS GovCloud, not a standard commercial region. The sender address was ubuntu@aws-ec2048.aws.getcare[.]com, a subdomain configured on a domain the attacker controlled.

GovCloud regions host workloads that must comply with U.S. government security standards (FedRAMP, ITAR, DoD). Organizations that work with government agencies know these IP ranges. Traffic from GovCloud may receive less scrutiny than standard commercial cloud regions because GovCloud is associated with vetted, compliant infrastructure.

The attacker exploited that implicit trust. Once provisioned, an EC2 instance in us-gov-west-1 sends email from an IP range that carries government-grade reputation. According to CISA's cloud security guidance, cloud infrastructure is increasingly targeted because its IP reputation is higher than commodity hosting.

This maps to MITRE ATT&CK T1583.003 (Acquire Infrastructure: Virtual Private Server). The attacker provisioned cloud compute specifically to relay email through an IP range with elevated trust.

See Your Risk: Calculate how many threats your SEG is missing right now

Display-Name Impersonation Meets Automated System Framing

The display name was "Ubuntu," which matched a known internal system identity at the target organization. Many organizations run Ubuntu-based servers that generate automated reports, alerts, and notifications. When an email arrives from "Ubuntu" with a subject line like ClaimsQueue837 Download Report paceseam_ascindiana, it looks like one more automated notification in an inbox full of them.

The body reinforced the framing. A plain-text list titled "Downloaded files:" followed by eight system-style filenames with numeric prefixes and opaque suffixes. No human greeting. No signature. No call to action. The message was designed to be indistinguishable from the output of a batch processing system that dumps file manifests to a distribution list.

This is MITRE ATT&CK T1036 (Masquerading) applied to email. The attacker did not impersonate a person. The attacker impersonated a process. That distinction matters because automated notifications receive less scrutiny than human-authored messages. Recipients glance at them and move on. Or they ignore them entirely, which is equally useful to the attacker: a message that reaches the inbox and generates no security report means the delivery path is clear for the next phase.

Authentication Failed. The Email Got Through Anyway.

The authentication picture was unambiguous failure:

• SPF: none. The domain aws-ec2048.aws.getcare[.]com published no SPF record designating permitted senders.
• DKIM: none. No DKIM signature was present.
• DMARC: fail. The domain's DMARC policy evaluated and the message failed alignment.

Under normal circumstances, this triple failure should have routed the email to quarantine or junk. Instead, Microsoft's composite authentication (compauth) returned softpass with reason code 201.

Compauth is Microsoft's implicit authentication mechanism. When explicit protocols fail or return indeterminate results, compauth evaluates sender reputation and behavioral signals to make a secondary determination. A softpass result means Microsoft concluded the message was "likely legitimate" despite the explicit failures.

The result: an email with no SPF coverage, no DKIM signature, and a DMARC failure reached inboxes because implicit authentication overrode the explicit signals. For defenders relying on gateway-level enforcement, this is the gap. Compauth softpass is not a security decision your team made. It is a decision Microsoft made on your behalf, using signals you cannot inspect or override.

Reconnaissance, Not Payload

This email was not designed to steal credentials, deliver malware, or initiate a wire transfer. It was designed to answer three questions:

Does the email reach the inbox? If it does, the sending infrastructure is viable for future campaigns against this target.

Does the display-name impersonation generate a response? If someone replies to "Ubuntu" thinking the automated system malfunctioned, the attacker confirms a live, monitored mailbox.

Does the automated-report framing bypass human scrutiny? If nobody reports the message as suspicious, system-notification impersonation is a validated social engineering vector for this organization.

This is MITRE ATT&CK T1589 (Gather Victim Identity Information). The zero-payload design is deliberate. An email with links or attachments risks triggering sandboxing or content analysis. An email with nothing to scan passes cleanly through every content-based filter.

According to the Microsoft Digital Defense Report 2024, attackers are increasingly using cloud infrastructure to relay phishing emails, leveraging provider reputation to bypass IP-based blocking. GovCloud adds another layer: not just "cloud provider" but "government-approved cloud provider."

The Signal That Stopped It

Content scanners had nothing to work with. No URLs. No attachments. No embedded images. The email body was plain text that could have been generated by any batch processing system.

IRONSCALES Adaptive AI flagged the message on behavioral signals:

• Display-name impersonation. "Ubuntu" matched a known internal system identity, but the sending address came from an external, unrecognized domain with no prior sending history.
• Authentication failure cluster. SPF=none, DKIM=none, and DMARC=fail from a first-time sender domain. The compauth softpass did not suppress behavioral analysis.
• Zero-payload anomaly. An automated system notification with no actionable content from a first-time external sender fits a known reconnaissance pattern.

The message was quarantined before any recipient engaged. No reply was sent. No mailbox validation succeeded. The reconnaissance failed.

Indicators of Compromise

What Defenders Should Take From This

Treat GovCloud and government-associated IP ranges with the same scrutiny as any other cloud provider. Implicit trust based on IP origin is exploitable. Attackers provision infrastructure in elevated-trust environments specifically to bypass reputation-based filtering.

Do not rely on compauth softpass as a security signal. When SPF, DKIM, and DMARC all fail, a compauth softpass should trigger additional review, not acceptance. Audit your Microsoft 365 transport rules to understand how implicit authentication results affect message routing.

Monitor for system-identity impersonation. Display-name impersonation is not limited to executives. Attackers impersonating automated systems and service accounts exploit the fact that recipients treat machine-generated notifications with less scrutiny. Behavioral detection that compares display names against known internal identities, both human and system, is the effective countermeasure.

Build detection for zero-payload probes. Emails with no links, no attachments, and no actionable content from first-time external senders are not benign by default. They may be testing your defenses before the real attack arrives.