AWS VPC Flows for DFIR Part 1 - Introduction
Introduction
This is the first in a small collection posts about using AWS VPC Flows during incident response. One of the big benefits is the ability to save the data to an S3 bucket or Athena so even if the EC2 is no longer in existence, the flow data is still available to help piece together what might have taken place (lateral movement, exfil, etc.). For example if an actor has created and then deleted their own EC2 instance to stage their attack it could still be possible to identify lateral movement, what actions they might have taken based on port numbers.
What Are VPC Flows?
VPC flows are the AWS equivalent of NetFlow data and can be a valuable resource when investigating a variety of incident scenarios.
Although called VPC flows, there are three options for where to collect the flow data from:
- VPC - This will collect data from all of the interfaces in the subnet.
- Subnet - This will collect from all interfaces that are within the same subnet.
- Interface - Used for single EC2 hosts where you might be limited on logging or targeting single instances.
To illustrate this the following diagram shows how each layer works and where you can capture from
 |
Demonstrating the difference between a VPC, Subnet and Interface |
What to Flow
In an ideal world flow data would be collected from every VPC but this isn't always going to be possible. Whilst your main focus may be on security, the person paying the AWS bill might not be as sympathetic to your ideas.
Knowing what to collect flow data from is very much dependant on how busy the VPC is and if you can cover the storage costs. If you have concerns about the costs the hard and fast rule is to cover your crown jewels (hosts that hold significance within the network) or hosts that are externally facing and are more vulnerable to compromise where you can capture flows on the internal interface, identifying lateral movement.
Example Log
In the example below we have a Windows server that has been compromised. It is domain joined and the actor has a set of domain credentials that they have used to move laterally to another server within the same VPC.
We can see that there was an initial entry via RDP from the 188.107.251[.]85 IP address and then subsequent lateral movement to another internal host 172.31.51.87.
This log is a customised format to include the fields that will be covered in Part 2. There is no intermediary device so the pkt-srcaddr and pkt-dstaddr show the same values as the srcaddr and dstaddr fields.
