VPC peering: six ways an attacker abuses it

Why I learn how a feature is enabled before I learn how to secure it. Lateral movement, permissive NACLs, DNS spoofing, exfiltration, privilege escalation and configuration abuse.

Here's why:

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.

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:

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

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

Tip

Peering does not grant access on its own — security groups and NACLs still decide what actually flows. Which is also why over-permissive rules are so dangerous here: they turn a controlled link into an open one.

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:

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.

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

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:

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.

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.

Contents

Originally posted