Source IP Spoofing in Cloud Logs: A Hands-On Look Across AWS, Azure, and GCP

Source IP Spoofing in Cloud Logs: A Hands-On Look Across AWS, Azure, and GCP

Speakers: Eliav Livneh, Security Researcher, Token Security

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=wzr2EIBuYqU

Overview

Eliav Livneh, a security researcher at Token Security, presented a deep technical exploration of a defense evasion technique that allows attackers to spoof the source IP address recorded in cloud provider logs. Originally discovered in AWS in 2021, Livneh systematically tested the technique across all three major cloud providers—AWS, Azure, and GCP—revealing that each handles the scenario differently, with varying levels of exploitability and defensive capability. The research demonstrates that the source IP field in cloud audit logs should never be trusted blindly, as attackers with stolen credentials can manipulate what appears in victim logs by routing API calls through their own cloud infrastructure.

Background

▶ Watch: Shows spoofed IP '1.3.3.7' from a Chinese ISP appearing in AWS and GCP audit ... (1:30)

The technique was born from an observation Livneh made while investigating customer CloudTrail logs, where he noticed API calls with internal IP addresses as the source. This anomaly led him to discover that VPC endpoints—which route AWS API calls through internal backbone infrastructure without touching the internet—log the private IP address of the calling resource rather than a public IP. Three components combine to make the full spoofing technique possible: making API calls from within a VPC without internet egress, using credentials from one tenant within the network of another tenant, and the ability to assign arbitrary IP addresses (including publicly routable ones) as private IPs within a VPC. Livneh first published this research for AWS in 2021, but it took four years before he tested the technique on Azure and GCP—an effort he humorously described as "vibe researching" using ChatGPT to power through unfamiliar cloud platforms.

Key Findings

▶ Watch: Reveals AWS allows any publicly routable IP as a private VPC address, enablin... (5:30)

The research reveals a stark contrast in how each cloud provider handles source IP spoofing. In AWS, the technique works comprehensively—attackers can control any IP address and target virtually any service—but AWS has implemented strong defensive controls including the new VPCEndpointAccountId CloudTrail field and IAM condition keys (aws:VpcAccount and aws:VpcOrId) released just three weeks before the talk. In Azure, the technique requires victim approval for cross-tenant private endpoints, significantly limiting attacker feasibility, but if established, the logs contain absolutely no indication that the call came through a private endpoint or from a different tenant. Microsoft acknowledged the issue and committed to addressing it. In GCP, cross-tenant calls via Private Google Access result in the source IP being redacted to the generic string "GCE internal IP" rather than displaying the attacker's chosen IP, so attackers cannot spoof to arbitrary addresses but can effectively hide their origin. Google declined to treat it as a security issue, suggesting a feature request instead.

Technical Deep Dive

▶ Watch: Discovers Azure RMPL bug where approval API demands access token from the wro... (12:00)

The technique relies on three fundamental components present across cloud platforms. The first is VPC-internal API routing: mechanisms that allow API calls to traverse cloud backbone infrastructure without internet exposure—VPC endpoints in AWS, private endpoints in Azure, and Private Google Access in GCP. The second is cross-tenant credential usage: taking credentials from a victim tenant and using them within an attacker-controlled environment. The third is customizable private IP addressing: all three clouds allow assigning publicly routable IP addresses as private IPs within virtual networks (with only four restricted subnets in AWS).

For Azure, Livneh explored both service endpoints and private endpoints. Service endpoints do not support cross-tenant calls, leaving private endpoints as the only viable path. Cross-tenant private endpoints require explicit approval from the target tenant, and they must target specific resources. Control plane access requires a special construct called Resource Management Private Link (RMPL). During testing, Livneh discovered a bug where the RMPL approval process demanded an access token from the attacker's tenant rather than the victim's—a validation misalignment that Microsoft dismissed as non-security-relevant. Data plane operations via cross-tenant private endpoints to storage accounts worked successfully, with zero log indicators of the cross-tenant flow.

For GCP, the situation proved simpler technically but less useful for attackers. Private Google Access is a simple subnet-level checkbox that routes API calls through Google's internal backbone. However, GCP's documentation explicitly states that when a VM with only internal IP addresses makes calls using credentials from a different organization, the source IP is redacted to "GCE internal IP." No organizational, project, VPC, or instance information is logged—only the fact that the call originated from a different organization.

An important side finding in Azure: the technique does not bypass network security groups or firewall rules, as Azure's infrastructure is private-endpoint-aware even though the logs are not.

Demo / Proof of Concept

▶ Watch: Azure cross-tenant private endpoint succeeds with zero forensic indicators in... (14:00)

Livneh demonstrated the full attack chain across all three providers. For AWS, he created a VPC with the CIDR block containing IP address "1.3.3.7," assigned that IP to a VM, created a VPC endpoint, and made API calls using victim credentials through the endpoint—resulting in "1.3.3.7" appearing as the source IP in the victim's CloudTrail logs. For Azure, he successfully created a cross-tenant private endpoint to a storage account (with victim approval), made calls with a victim service principal, and showed the resulting logs contained no indication of the cross-tenant private endpoint flow. For GCP, he demonstrated that Private Google Access results in "GCE internal IP" appearing in audit logs with no identifying information about the attacker's organization.

Defensive Implications

▶ Watch: AWS announces new VPCEndpointAccountId field and IAM condition keys — stronge... (20:00)

Defenders should take different approaches depending on their cloud provider. For AWS, the situation is most favorable: use the new VPCEndpointAccountId field in CloudTrail to detect calls from unknown account IDs or unexpected public IPs appearing alongside VPC endpoint usage. Deploy SCPs using the new aws:VpcAccount and aws:VpcOrId condition keys to deny API calls through VPC endpoints from untrusted accounts or organizations. For Azure, audit all incoming cross-tenant private endpoints and verify their legitimacy. Restrict private endpoint approval to a small set of authorized personnel and treat it as a sensitive operation. Wait for Microsoft's forthcoming log enrichment fix. For GCP, monitor for the "GCE internal IP" string in audit logs to detect potential cross-tenant abuse, though actionable intelligence from this indicator is limited. Explore VPC Service Controls as a partial preventive measure. Across all clouds, the core lesson is: never trust the source IP field in cloud logs as definitive evidence of caller identity.

Key Takeaways

• Source IP addresses in cloud logs can be spoofed by attackers who route stolen credentials through their own cloud infrastructure using VPC-internal API routing mechanisms
• AWS has the strongest defenses with new CloudTrail fields and IAM condition keys, while Azure and GCP currently offer limited detection and prevention capabilities
• Azure requires victim approval for cross-tenant private endpoints, significantly limiting attacker feasibility, but successful exploitation leaves zero forensic indicators in logs
• GCP redacts the source IP to "GCE internal IP" for cross-organization calls, preventing full spoofing but also providing defenders with almost no attribution data
• Cloud security knowledge does not transfer directly between providers—each platform implements networking, logging, and security controls differently
• Defenders should utilize all available log fields, not just source IP, when investigating cloud security events

About the Speaker(s)

Eliav Livneh is a security researcher at Token Security. He originally discovered the AWS source IP spoofing technique in 2021 and has been researching cloud security internals, including CloudTrail logging mechanisms. Outside of security research, he describes himself as a dad, cyclist, and amateur mineral collector. He previously presented on CloudTrail logging internals at fwd:cloudsec.