If you’ve ever taken a training course for the AWS Certified Solutions Architect you’ve likely had it drilled into your mind that
security groups are “stateful”. What does that mean exactly? It means that, for example, if an EC2 instance makes an outbound request to a web server the response traffic is allowed back through the security group regardless of the configuration of the inbound rules. Similarly, if your EC2 instance receives inbound traffic it is allowed to respond regardless of the outbound rules. This capability is enabled by
connection tracking.
So far that sounds pretty reasonable, but in this post I’d like to describe a methodology for penetration testers, red teamers, and cloud malware (is that a thing yet?) to persist connections on a host, even when a more restrictive security group is put in place as a result of incident response.
Practical ExampleLets take a real world scenario. You, as a bad actor, gain code execution on an EC2 instance in FriendCo’s VPC. You poke around a bit over a
basic reverse shell. Maybe steal some credentials, escalate privileges, exfil data, etc. Eventually you trigger some kind of alert. Defenders (either automated or human) are on their way to ruin your fun. If they are following the
AWS whitepaper on incident response, they will likely change the security group on the EC2 instance to one that doesn’t allow any inbound or outbound traffic. This process is typically automated using something like a
CloudWatch Event Rule to automatically box you in. From here the defender can clone the EBS volume for forensics, manually interact with the host, or perform network traffic and memory collection for analysis. The following image comes from the AWS incident response whitepaper and illustrates the scenario.
While the intention of changing the security group is to isolate the EC2 instance, not all traffic is blocked. In fact, if this example scenario played out in real life your reverse shell would be allowed through the new security group. Changing the security group did not drop your session.
Based on that last sentence you may be confused. Let’s talk about it.
Read the full article @
https://frichetten.com/blog/abusing-aws-connection-tracking/
