Through the Looking Glass

Introduction

AWS traffic mirroring is a feature introduced by Amazon Web Services (AWS) on June 25th, 2019. After the release, Mike LoSapio of Palantir identified that it might pose a risk, and suggested that I research the feature as part of the partnership between our two companies. Huge thanks to him and the entire team at Palantir for being an inspiration for this post, and overall excellent people.

In this post I am going to provide details on how this new feature works, legitimate use cases, and possible avenues of abuse.

Two years later, after further research in this topic — the likelihood of this being used as in an attack is incredibly low. I am leaving the post up as a technical resource for the feature.

This post assumes that the reader has an introductory level of knowledge regarding AWS, but each new AWS term I introduce I have linked to the relevant documentation just in case.

AWS feature announcements

When cloud-sourcing capability, administrators lose some level of control over their environment. New features and abilities may be rolled out without warning or permission so it is important to stay on top of new releases and updates to enhance the security posture of the cloud-sourced environment. The official AWS blog is an excellent resource for announcements regarding new features that may introduce attack paths to your organization, and should be monitored by anyone who is responsible for the security of an AWS environment. The AWS Twitter account posts similar announcements, as well as many industry experts who monitor cloud feature releases.

When new features are introduced, often permissions are added to default roles that are already in use. In the case of traffic mirroring, permissions were added to roles such as EC2:AllAccess under the Elastic Compute Cloud (EC2) moniker. If you aren’t aware of these changes, you may have unnecessary permissions granted to users which make the organization more vulnerable to attack.

How Traffic Mirroring Works

AWS traffic mirroring provides the capability to create a traffic mirror session. The session consists of the three parts outlined below:

1. Traffic Mirror Source:

The network interface is the traffic mirror source, and the source’s traffic is then mirrored and forwarded to the traffic mirror target — currently, this is limited to an EC2 instance Elastic Network Interface (ENI), but capability might expand in the future. Only instances based on the Nitro system are supported, which are listed here.

2. Traffic Mirror Target

The traffic mirror target is the Network Load Balancer (NLB) or EC2 ENI that receives the mirrored traffic. The target must be in the same Virtual Private Cloud (VPC) as the source, unless you utilize peered VPCs (a way of creating intra-vpc routes between your VPCs without additional hardware or resources) or routing via a transit gateway (a virtual router to handle traffic between your VPCs). In addition, if you choose to connect two VPCs using one of these methods — they do not have to reside in the same account.

3. Traffic Mirror Filter

The traffic mirror filter is a set of rules defining which traffic will be mirrored, and how much of the traffic. The options include specific subnets, ports, and packet sizes. Note: If no filter is set, then no traffic will be mirrored — the filter is a definitive list of everything that will be mirrored to the target. In this sense, the filter is more of a configuration than an actual filter.

After setting these options, you can create the traffic mirror session. Each ENI can participate as a traffic mirror source up to three times at once, while the traffic mirror target can accept as many sessions as is needed.

Once the session is established, a copy of all traffic (inbound or outbound) that matches the filter, is duplicated from the source to the target. The traffic is sent as VXLAN encapsulated packets via UDP port 4789.

Legitimate Use

There are a variety of legitimate uses for AWS traffic mirroring. These uses are similar to the use of a mirror/span port on a physical switch, premier among them are Intrusion Detection System/Intrusion Prevention System (IDS/IPS) type devices where you might want to monitor the traffic of devices in your network. The advantage of using these mirror sessions is offloading the workload of making the mirrored traffic from a network device such as a router or load balancer, and having AWS absorb the workload in the back end.

These legitimate use cases show single VPC and multiple VPC examples, but are centered around usage of multiple accounts within the same organization. The abuse cases in the next section rely on a slightly different layout, because the accounts used are not linked in any way. This procedural change will help differentiate legitimate and illegitimate usage of the feature when we start trying to detect this behavior.

Intra-VPC usage:

Within a single VPC, you can forward traffic from all instances to a central NLB or EC2 ENI.

Inter-VPC usage:

Using the cross-account capability of AWS traffic mirroring, you can collect the data from all subordinate accounts across an organization, and forward them to a central VPC for inspection using multiple methods.

Methods of Abuse

Despite there being legitimate uses for AWS traffic mirroring, AWS opened several avenues to steal traffic by introducing this capability. These types of attacks are loosely mapped to Mitre ATT&CK’s Cloud Matrix under Exfiltration/Transfer Data to Cloud Account.

Why would someone want to steal traffic from a VPC? With many organizations leaning heavily on AWS resources for internal and external services, often critical traffic can be found in these VPCs. In addition, many organizations utilize TLS/SSL termination to reduce the workload of internal systems. SSL termination has been available on Elastic Load Balancers (ELBs) since 2010. In January 2019, AWS introduced the ability to terminate TLS/SSL on NLBs as well, increasing the probability of unencrypted backend traffic in many AWS environments.

If an attacker was able through stolen AWS credentials to mirror and exfiltrate traffic, this could lead to massive exposure of private information. With this in mind, I comprised two methods I thought were significant risks and came across another that was created by Rhino Security Labs (detailed in Method 3). All of these methods are centered around removing traffic from a source (or victim) AWS account, and exfiltrating it to a second attacker account. Each one requires stolen or compromised AWS credentials. I have listed the necessary permissions for each of the attack methods to simplify testing.

In testing each of these methods, my account was used as the victim, and my coworker David Polojac acted as the attacker account.

Method 1: Shared resources using AWS Resource Access Manager

This method uses an ENI and Transit Gateway that has been shared from one account to another as the target for the mirrored traffic in Luke’s AWS account. The result of the mirror is sent directly to an instance in David’s account.

Required AWS Permissions:

• ec2:DescribeInstances (to identify EC2 instances to mirror)
• ec2:CreateTrafficMirrorTarget (to specify our load balancer/EC2 instance as a VPC mirror target)
• ec2:CreateTrafficMirrorSession (to create mirror sessions for each EC2 instance we want to mirror)
• ec2:CreateTrafficMirrorFilter (to create the traffic filter for our mirroring sessions)
• ec2:CreateTrafficMirrorFilterRule (to specify we want all traffic mirrored to our EC2 instance)
• ram:GetResourceShareInvitations (to view pending invitation to share load balancer/EC2 instance from David’s account)
• ram:AcceptResourceShareInvitation (to accept the invitation from David’s account)
• INSERT NEW PERMS WE USED HERE

Note: The target shared from David’s account may be an EC2 ENI or NLB, as depending on how the target is defined before it is shared.

Method 2: Peered VPC

This method uses a peering connection between the VPC in Luke’s account to the VPC in David’s account, giving the instances the ability to mirror their traffic directly to an NLB or EC2 instance in David’s account.

Required AWS Permissions:

• ec2:DescribeInstances (to identify EC2 instances to mirror)
• ec2:CreateTrafficMirrorTarget (to specify our load balancer/EC2 instance as a VPC mirror target)
• ec2:CreateTrafficMirrorSession (to create mirror sessions for each EC2 instance we want to mirror)
• ec2:CreateTrafficMirrorFilter (to create the traffic filter for our mirroring sessions)
• ec2:CreateTrafficMirrorFilterRule (to specify we want all traffic mirrored to our EC2 instance)
• ec2:CreateVpcPeeringConnection (to create the VPC peering between Luke’s account and David’s)

Method 3: Local instance (MalMirror)

This final method uses a tool from Rhino Security Labs known as MalMirror (link for the blog post introducing it is here). MalMirror is a python script that accepts AWS credentials and stands up a malicious EC2 instance with the intent to create a traffic mirror session between itself and every eligible instance in the VPC. Every 100mb of data that is captured, the EC2 instance uploads a PCAP to an S3 bucket that resides in David’s AWS account.

Required AWS Permissions (borrowed from the blog post mentioned above):

• ec2:DescribeInstances (to identify EC2 instances to mirror)
• ec2:RunInstances (to create an EC2 instance that will be the VPC mirror target)
• ec2:CreateSecurityGroup (to create a security group for our EC2 instance)
• ec2:AuthorizeSecurityGroupIngress (to allow inbound access to our EC2 instance)
• ec2:CreateTrafficMirrorTarget (to specify our EC2 instance as a VPC mirror target)
• ec2:CreateTrafficMirrorSession (to create mirror sessions for each EC2 instance we want to mirror)
• ec2:CreateTrafficMirrorFilter (to create the traffic filter for our mirroring sessions)
• ec2:CreateTrafficMirrorFilterRule (to specify we want all traffic mirrored to our EC2 instance)