2.2.6. Network-Based Log Sources
First Principle: Network logs capture what actually traverses your infrastructure — regardless of whether it was authorized by IAM or expected by your application. They're the ground truth for detecting lateral movement, data exfiltration, and unauthorized communication.
VPC Flow Logs capture metadata about IP traffic flowing through network interfaces:
- Capture level: VPC, subnet, or ENI (elastic network interface)
- Fields: Source/dest IP, ports, protocol, bytes, packets, action (ACCEPT/REJECT)
- Does NOT capture: Packet contents, DNS queries, traffic to/from metadata service (169.254.169.254)
- Storage: CloudWatch Logs (real-time) or S3 (cost-effective)
Transit Gateway Flow Logs extend visibility to traffic between VPCs:
- Same format as VPC Flow Logs but captures inter-VPC traffic through Transit Gateway
- Essential for detecting lateral movement between VPCs in multi-account architectures
- Critical when VPCs are connected but shouldn't communicate with each other
Route 53 Resolver Logs capture DNS queries from VPCs:
- Records which domain names resources are looking up
- Critical for detecting DNS-based C2 communication, data exfiltration via DNS tunneling
- GuardDuty analyzes these logs for domain generation algorithms (DGAs) and known malicious domains
Combining Network Logs for Investigation:
⚠️ Exam Trap: VPC Flow Logs do NOT capture DNS traffic content — Route 53 Resolver logs do. If a question asks about detecting DNS tunneling, the answer involves Resolver logs (which GuardDuty analyzes), not VPC Flow Logs.
Scenario: An EC2 instance is communicating with an IP address flagged by GuardDuty. You need to determine: what data was sent (Flow Logs show bytes transferred), what the instance was resolving (Resolver logs show DNS queries), and what API actions the instance's role performed (CloudTrail shows API calls).
Reflection Question: Why does a complete network security investigation require correlating three different log types (Flow Logs, DNS logs, CloudTrail)?
