VPC peering: six ways an attacker abuses it

I was working through "Implementing VPC Peering on AWS" — lab 11 of 38 in my A Cloud Guru run — and you might reasonably ask why a security person cares how VPC peering gets enabled.

Here's why:

Because I want to understand its weakness, understand how to exploit it, and then secure against it.

That order matters. You cannot defend a feature you only know from the happy path. So every time I learn how something is set up, I immediately ask what someone would do with it if they got in.

Here is what I came up with for VPC peering.

1. Lateral movement and network access#

If someone gains access to a host inside one of the peered VPCs, they can potentially move sideways across the peering connection.

Which means they can:

• Access resources in the peered VPC
• Compromise other resources from there

The peering connection is a legitimate, trusted path. That is exactly what makes it useful to an attacker — the traffic looks normal.

2. Improper security group and NACL configuration#

If security groups or network ACLs are too permissive, someone can push malicious traffic between the VPCs using:

• Inappropriate security group rules
• Unrestricted NACLs

3. Subdomain and DNS spoofing#

Peering connections rely on DNS resolution so instances in different VPCs can reach each other by private DNS name.

That dependency is the attack surface:

• DNS spoofing
• Man-in-the-middle

4. Data exfiltration and unauthorised access#

A peering connection is a private channel between two VPCs. With access to one side, an attacker can use it to move data to the other.

• Extract sensitive data
• Establish persistence

Private does not mean safe. It means unmonitored, if you are not watching it.

5. Privilege escalation#

If IAM roles or policies are overly permissive or misconfigured, someone can escalate privileges in the compromised VPC and reach the peered one. Typically by:

• Assuming cross-account roles
• Exploiting EC2 instance metadata

6. Abusing the peering configuration itself#

And if an attacker has administrative access to the AWS environment, they do not need to abuse an existing peering connection at all.

They can create one.

What did we learn?#

1. Learn how a feature is enabled before you try to secure it.
2. Peering is a trusted path, which is exactly why lateral movement hides in it.
3. Security groups and NACLs still gate the traffic — keep them tight.
4. Private DNS resolution brings DNS attacks with it.
5. IAM misconfiguration turns one compromised VPC into two.
6. Admin access means an attacker can build their own peering connection.

If you are studying AWS security, try this exercise on whatever you learn next. Set it up, then write down six ways you would abuse it. It changes how you read documentation.