Detecting Lateral Movement in AWS VPC Using Flow Logs + GuardDuty

How We Caught an Attacker Moving Across Our AWS Network Before They Reached Production

Introduction

Most AWS security incidents don’t begin with a massive breach.

They start with something small.

A forgotten IAM key.

An exposed application.

A vulnerable container.

A compromised EC2 instance.

The initial compromise is rarely what causes the biggest damage.

The real danger begins when attackers start moving laterally across your environment.

Imagine this scenario:

An attacker gains access to a development EC2 instance.

That machine doesn’t contain sensitive data.

No customer information.

No production secrets.

No critical workloads.

So what’s the problem?

The attacker uses that machine as a stepping stone.

They begin probing other systems.

Scanning internal ports.

Connecting to databases.

Attempting to discover credentials.

Enumerating services.

Eventually, they reach production workloads.

At this point, the breach becomes catastrophic.

This phase is called Lateral Movement.

And detecting it early is one of the most important responsibilities of a cloud security team.

In this article, we’ll learn:

• What lateral movement looks like in AWS
• How VPC Flow Logs help reveal suspicious east-west traffic
• How GuardDuty detects attacker behavior automatically
• How to build a practical detection pipeline
• How to investigate suspicious activity
• How to respond before attackers reach critical assets

Understanding Lateral Movement

Traditional security focuses heavily on perimeter defense.

But modern attacks assume the perimeter will eventually fail.

The question becomes:

What happens after the attacker gets inside?

That is where lateral movement begins.

Example Attack Path

Internet
    │
    ▼
Compromised EC2 (Dev)
    │
    ▼
Internal Port Scanning
    │
    ▼
Database Discovery
    │
    ▼
Credential Theft
    │
    ▼
Production Environment

The attacker may:

• Scan internal subnets
• Connect to multiple servers
• Enumerate databases
• Search for secrets
• Access internal APIs
• Attempt privilege escalation

These activities create network patterns.

Those patterns are visible in:

• VPC Flow Logs
• GuardDuty Findings

What is East-West Traffic?

Most engineers focus on:

North-South Traffic

User
 │
 ▼
Internet
 │
 ▼
Application

Traffic entering or leaving AWS.

East-West Traffic

EC2-A  ───► EC2-B
  │
  ▼
 RDS
  │
  ▼
 ECS Service

Traffic moving inside your AWS environment.

Attackers love east-west movement because:

• It is less monitored
• Often considered trusted
• Can reveal hidden services

This is why east-west visibility is critical.

Security Visibility Problem

Many organizations know:

• CPU usage
• Memory usage
• Application logs

But they cannot answer:

Which instance communicated with which instance yesterday?

Or:

Why did this web server suddenly connect to 200 internal IPs

This visibility gap allows attackers to move undetected.

Enter AWS VPC Flow Logs

AWS Flow Logs record network traffic metadata.

Think of them as CloudTrail for network connections.

Flow Logs capture:

• Source IP
• Destination IP
• Source Port
• Destination Port
• Protocol
• Bytes transferred
• Accept/Reject status

Example:

10.0.1.15
    │
    ├──► 10.0.2.10:22
    ├──► 10.0.2.11:22
    ├──► 10.0.2.12:22
    ├──► 10.0.2.13:22
    └──► 10.0.2.14:22

Immediately suspicious.

One host touches many others on SSH.

Potential lateral movement.

Architecture

+----------------+
                   | GuardDuty      |
                   +--------+-------+
                            |
                            ▼
+------------+     +---------------+
| EC2        |---->| VPC Flow Logs |
+------------+     +---------------+
                            |
                            ▼
                    +---------------+
                    | CloudWatch    |
                    +---------------+
                            |
                            ▼
                    +---------------+
                    | Security Team |
                    +---------------+

Flow Logs provide raw network evidence.

GuardDuty adds threat intelligence and behavioral analysis.

Together, they become powerful.

Enable VPC Flow Logs

Navigate to:

VPC Console
   → Your VPC
      → Flow Logs

Create Flow Log.

Recommended settings:

SettingValueResource TypeVPCDestinationCloudWatch LogsTraffic TypeALLLog FormatDefaultAggregation Interval1 Minute

Why ALL?

Because rejected traffic is often more interesting than accepted traffic.

Attackers generate many failed connections.

Creating Flow Logs Using Terraform

resource "aws_cloudwatch_log_group" "flow_logs" {
  name = "/aws/vpc/flowlogs"
}

resource "aws_flow_log" "main" {
  iam_role_arn    = aws_iam_role.flowlog_role.arn
  log_destination = aws_cloudwatch_log_group.flow_logs.arn
  traffic_type    = "ALL"
  vpc_id          = aws_vpc.main.id
}

Infrastructure-as-Code ensures every VPC gets monitored.

Sample Flow Log Analysis

Example record:

2 123456789 eni-abc123
10.0.1.10
10.0.2.15
54321
22
6
12
840
1680000000
1680000060
ACCEPT
OK

Important fields:

FieldMeaning10.0.1.10Source10.0.2.15Destination22SSHACCEPTConnection allowed

Now imagine:

10.0.1.10 → 10.0.2.10:22
10.0.1.10 → 10.0.2.11:22
10.0.1.10 → 10.0.2.12:22
10.0.1.10 → 10.0.2.13:22
10.0.1.10 → 10.0.2.14:22

That looks very different from normal application traffic.

Potential port scanning.

How GuardDuty Detects Lateral Movement

Flow Logs alone provide data.

GuardDuty provides intelligence.

GuardDuty continuously analyzes:

• VPC Flow Logs
• DNS Logs
• CloudTrail Events
• EKS Audit Logs
• S3 Events

It looks for known attacker behavior.

Common Guard Duty Findings

Port Probe

Recon:EC2/PortProbeUnprotectedPort

Meaning:

An instance is scanning multiple ports internally.

Internal Reconnaissance

Recon:EC2/Portscan

Meaning:

An EC2 instance is probing other internal hosts.

SSH Brute Force

UnauthorizedAccess:EC2/SSHBruteForce

Meaning:

Suspicious SSH login attempts detected.

Crypto Malware Activity

CryptoCurrency:EC2/BitcoinTool.B

Meaning:

Known malicious infrastructure contacted.

Real Incident Walkthrough

One of our development workloads became compromised through a vulnerable application package.

Initially, we saw:

EC2-Dev
   │
   └──► Internal Subnet Scan

GuardDuty generated:

Recon:EC2/Portscan

Investigation revealed:

10.0.1.50
    │
    ├──► 10.0.2.10:22
    ├──► 10.0.2.11:22
    ├──► 10.0.2.12:22
    ├──► 10.0.2.13:22
    └──► 10.0.2.14:22

This traffic pattern had never occurred before.

The instance normally only communicated with:

ALB
Database
Redis

Nothing else.

The deviation exposed the attacker.

CloudWatch Insights Query

Useful query for identifying scanning behavior:

fields srcAddr, dstAddr, dstPort

| stats count(*) as connections
by srcAddr, dstPort

| sort connections desc

Another useful query:

fields srcAddr, dstAddr

| stats count(*) as attempts
by srcAddr, dstAddr

| sort attempts desc

This quickly highlights noisy hosts.

Automated Alerting

Create CloudWatch alarms.

Trigger when:

• One source contacts many destinations
• A large number of rejected connections
• Unusual internal SSH activity

Example workflow:

Flow Logs
    │
    ▼
CloudWatch
    │
    ▼
Metric Filter
    │
    ▼
SNS
    │
    ▼
Slack / Email

Security teams get notified immediately.

Incident Response Playbook

When GuardDuty reports lateral movement:

Step 1: Isolate Instance

Detach Security Groups.

Or move the workload into quarantine VPC.

Step 2: Snapshot Evidence

Create:

• EBS Snapshot
• Memory dump (if available)
• System logs

Step 3: Review IAM Activity

Check:

CloudTrail

Look for:

• AssumeRole activity
• Credential usage
• Secret retrieval

Step 4: Analyze Network Activity

Review:

VPC Flow Logs

Questions:

• Which hosts were contacted?
• Which ports were targeted?
• When did the activity begin?

Step 5: Rotate Credentials

Assume compromise.

Rotate:

• IAM keys
• Database passwords
• Secrets Manager secrets
• Tokens

Security Best Practices

1. Enable GuardDuty Everywhere

Many organizations still disable it in non-production accounts.

Attackers often start in development environments.

Monitor everything.

2. Enable Flow Logs at VPC Level

Do not depend on subnet-level logging.

Capture the entire network.

3. Restrict East-West Traffic

Use Security Groups aggressively.

Bad:

10.0.0.0/8 → ALL PORTS

Good:

Web → App
App → Database
Only Required Ports

4. Build Baselines

Understand:

• Normal communication paths
• Expected ports
• Expected traffic volume

Without a baseline, anomalies are difficult to detect.

5. Use GuardDuty + Security Hub

GuardDuty
     │
     ▼
Security Hub
     │
     ▼
Centralized Findings

This provides a single pane of glass for investigations.

What Flow Logs Cannot See?

Flow Logs are powerful but not perfect.

They do not capture:

• Packet contents
• HTTP requests
• SQL queries
• Application payloads

They show:

WHO talked to WHOM

Not:

WHAT they said

For deeper visibility, combine:

• VPC Flow Logs
• GuardDuty
• CloudTrail
• WAF Logs
• Application Logs

Final Thoughts

Most cloud breaches don’t succeed because an attacker got into one machine.

They succeed because nobody noticed what happened next.

The moment a compromised workload begins exploring your environment, the network starts telling a story.

A web server is suddenly talking to dozens of internal hosts.

A development instance probing SSH ports.

An application container reaches systems it has never contacted before.

These are not random events. They are signs of lateral movement.

By combining VPC Flow Logs for visibility and GuardDuty for intelligent threat detection, security teams can identify suspicious east-west traffic long before attackers reach production resources.

In cloud security, prevention is important.

But visibility is what saves you when prevention fails.

And when it comes to lateral movement in AWS, Flow Logs and GuardDuty are often the first clues that an attacker is already inside your network.