Event-Driven DFIR — Automating Your AWS Response

One of the most powerful capabilities AWS gives you for incident response is the ability to automate it. Unlike on-premise environments where IR automation requires complex SOAR platforms, AWS has native services that can trigger forensic actions the moment a threat is detected — no human in the loop required for the initial containment and evidence preservation steps.

Lambda — Serverless Functions for DFIR Automation

AWS Lambda lets you run code without managing any servers. You write a function, upload it, and AWS executes it in response to triggers — API calls, scheduled events, S3 uploads, GuardDuty findings, whatever you connect to it.

For DFIR, Lambda is your execution engine.

It runs the Python or Node.js code that does the actual work: isolating an EC2 instance, taking a snapshot, copying evidence to a secure bucket, notifying the security team.

Critical constraint:

Lambda has a maximum execution time of 15 minutes per invocation. For actions that take longer than 15 minutes — like imaging a large disk — you need to break the work into multiple Lambda functions chained together, or use a different compute option like AWS Fargate for longer-running tasks.

Lambda pricing: First 1 million requests per month free, then $0.20 per million requests. Compute time: $0.0000166667 per GB-second. For IR automation, the cost is essentially negligible.

Step Functions — Orchestrating Multi-Step DFIR Workflows

AWS Step Functions is a workflow orchestration service.

You define a state machine — a visual flowchart of steps — and Step Functions manages the execution, error handling, retries, and branching logic between your Lambda functions.

For complex DFIR workflows, Step Functions is essential.

A typical forensic collection workflow might look like:

(1) Receive GuardDuty finding → (2) Identify affected EC2 instance → (3) Check if instance is already isolated → (4a) If yes: take snapshot → (4b) If no: isolate instance, then take snapshot → (5) Copy snapshot to forensic account → (6) Notify IR team → (7) Create case ticket. Each of these steps is a Lambda function. 

Step Functions ties them together, handles failures, and retries steps that fail transiently.

EventBridge — The Routing Layer

AWS EventBridge is the event bus and routing service. It receives events from AWS services (GuardDuty findings, CloudTrail events, EC2 state changes) and routes them to targets (Lambda functions, Step Functions, SQS queues, SNS topics) based on rules you define.

Example

EventBridge rule — trigger isolation on any HIGH or CRITICAL GuardDuty finding of type UnauthorizedAccess:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{"numeric": [">=", 7]}],
    "type": [{"prefix": "UnauthorizedAccess"}]
  }
}

This rule pattern fires the moment GuardDuty generates any UnauthorizedAccess finding with severity >= 7 (HIGH). EventBridge passes the full finding JSON to your Lambda function or Step Functions workflow as the trigger payload.

Lambda Function: Isolating a Compromised EC2 Instance

Here's a Python Lambda function that isolates a compromised EC2 instance by replacing its security group with a 'deny all' group:

import boto3
def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    instance_id = event['detail']['resource']['instanceDetails']['instanceId']
    region = event['detail']['region']
    
    # Create isolation security group
    vpc_id = ec2.describe_instances(
        InstanceIds=[instance_id]
    )['Reservations'][0]['Instances'][0]['VpcId']
    
    sg_response = ec2.create_security_group(
        Description='IR Isolation - No Inbound/Outbound',
        GroupName=f'ir-isolation-{instance_id}',
        VpcId=vpc_id
    )
    isolation_sg_id = sg_response['GroupId']
    
    # Revoke all default outbound (allow all) rule
    ec2.revoke_security_group_egress(
        GroupId=isolation_sg_id,
        IpPermissions=[{'IpProtocol': '-1', 'IpRanges': [{'CidrIp': '0.0.0.0/0'}]}]
    )
    
    # Replace instance's security groups with isolation group
    ec2.modify_instance_attribute(
        InstanceId=instance_id,
        Groups=[isolation_sg_id]
    )
    
    return {'status': 'isolated', 'instance': instance_id, 'isolation_sg': isolation_sg_id}

💡 IR Tip: Isolation via security group replacement is the safest containment method in AWS — it doesn't terminate the instance (preserving volatile memory state), it doesn't stop the instance (preserving running processes), and it's reversible by putting the original security groups back.

Lambda Function: Enabling VPC Flow Logs Mid-Incident

If flow logs weren't enabled before the incident, you can turn them on automatically in response to a GuardDuty finding:

import boto3

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    instance_id = event['detail']['resource']['instanceDetails']['instanceId']
    
    vpc_id = ec2.describe_instances(
        InstanceIds=[instance_id]
    )['Reservations'][0]['Instances'][0]['VpcId']
    
    ec2.create_flow_logs(
        ResourceIds=[vpc_id],
        ResourceType='VPC',
        TrafficType='ALL',
        LogDestinationType='s3',
        LogDestination='arn:aws:s3:::your-dfir-evidence-bucket/flow-logs/'
    )
    
    return {'status': 'flow_logs_enabled', 'vpc_id': vpc_id}

Full Forensic Disk Collection Automation

▸ EventBridge Rule → Lambda Trigger → Step Functions → isolate + snapshot + copy to forensic bucket

Putting it all together — a complete automated forensic collection chain:

(1) GuardDuty HIGH finding → (2) EventBridge rule matches → (3) Triggers Step Functions state machine → (4) Step 1: Isolate EC2 (Lambda) → (5) Step 2: Tag instance with case number and timestamp → (6) Step 3: Snapshot all attached EBS volumes → (7) Step 4: Copy snapshots to forensic account (cross-account snapshot sharing) → (8) Step 5: Enable VPC flow logs if not already running → (9) Step 6: Send SNS notification to IR team → (10) Step 7: Create Jira/ServiceNow ticket via webhook.

The entire chain from GuardDuty finding to snapshot complete typically takes 3-8 minutes for a standard-sized instance.

By the time your IR team picks up the alert, the instance is already isolated and the disk image is already preserved.

What's Next

The final article in this series — covers in-cloud IR for complex scenarios: Linux memory acquisition with AVML, Windows memory in the cloud, container forensics for ECS and EKS, the IMDS metadata service attack, and how IMDSv2 mitigates it.

---------------------------------------------------------Dean------------------------------------------