Full Report
In order to learn about serverless architecture, I experimented with implementing a quick proof of concept crash triaging tool using AWS Lambda Functions. There are many benefits of serverless architecture when you really don’t want to manage underlying infrastructure components and often cost saving advantages which can be made. These concepts lend themselves well to certain components of a continuous fuzzing architecture (such as Google’s Clusterfuzz).
Analysis Summary
# Tool/Technique: Serverless Crash Triage Tool (Proof of Concept using AWS Lambda)
## Overview
This document describes a proof-of-concept implementation of a crash triaging tool leveraging **AWS Lambda Functions** within a continuous fuzzing architecture (similar to Google's Clusterfuzz). The primary goal is to automatically extract vital crash metadata (registers, stack frames, faulting instruction, crash type) from fuzzing results shortly after they are recorded in **Amazon DynamoDB**, enabling rapid prioritization of potentially exploitable crashes without manual inspection of every event.
## Technical Details
- Type: Technique / Custom Tool Implementation
- Platform: AWS Cloud (Lambda, DynamoDB, CloudWatch Logs, IAM)
- Capabilities: Event-driven post-processing of crash data, metadata extraction (stack hash, error line), and database updates.
- First Seen: April 9, 2020 (Date of publication)
## MITRE ATT&CK Mapping
Since this describes a defensive/research implementation using cloud technology for automation rather than malicious activity, direct offensive TTP mapping is limited. However, the underlying technologies relate to Infrastructure as Code (IaC) and Cloud Service utilization.
- **T1543.003 - Create or Modify System Process: Windows Service** (Analogous concept of initiating automated background processes, though here applied to cloud events)
- *Note: A more direct offensive mapping for abusing similar services would need to be constructed based on how an adversary might misuse these cloud components.*
## Functionality
### Core Capabilities
- **Event-Driven Triggering:** Uses **DynamoDB Streams** to trigger an **AWS Lambda Function** upon data insertion into the 'Crashes' table.
- **Crash Metadata Extraction:** The Python-based Lambda processes incoming crash logs (assumed to be in a field like `asan_log`) to extract critical triage information such as registers, stack frames, and crash type.
- **Data Enhancement:** Calculates a SHA1 hash of the first few lines of the symbolized stack trace (`stack_hash`).
- **Database Persistence:** Updates the original crash record in the DynamoDB 'Crashes' table with the extracted metadata (`stack_hash`, `error_line`).
### Advanced Features
- **Idempotency Handling:** The Lambda logic explicitly checks `record['eventName'] == "INSERT"` to prevent re-processing of crashes due to subsequent `MODIFY` events caused by the Lambda's own update operation.
- **Scalable Architecture:** Leverages serverless components (Lambda, DynamoDB) for cost-effective, scalable infrastructure management, analogous to components used in large-scale fuzzing systems like Clusterfuzz.
- **Custom Parsing Logic:** Utilizes a custom class (`asanlogparse`) for detailed parsing of crash reports (implied to be AddressSanitizer (ASAN) logs).
## Indicators of Compromise
As this is a defensive/research implementation, no typical malicious IoCs are generated. The indicators listed below relate to the *infrastructure setup* described.
- File Hashes: N/A (Focus is on infrastructure configuration)
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: (AWS Service Endpoints - Defanged)
- `aws.amazon.com/lambda`
- `aws.amazon.com/dynamodb`
- Behavioral Indicators:
- DynamoDB stream producing `INSERT` events triggering Lambda execution.
- Lambda function interacting with DynamoDB `update_item` operations targeting the 'Crashes' table.
## Associated Threat Actors
None identified, as this represents security research/tool development in a defensive context.
## Detection Methods
Detection methods would focus on monitoring the designated AWS resources for expected behavior or unauthorized changes.
- Signature-based detection: Monitoring AWS CloudTrail logs for unexpected modifications to IAM roles, DynamoDB Stream definitions, or Lambda code deployments.
- Behavioral detection: Alerting on Lambda functions showing high execution frequency originating from DynamoDB streams, especially if the processing logic deviates from the expected crash triage workflow.
- YARA rules: N/A
## Mitigation Strategies
The primary mitigation here relates to securing the cloud application infrastructure used for fuzzing.
- Prevention measures: Employing the Principle of Least Privilege via fine-grained **IAM Roles** assigned to the Lambda function, restricting its write access strictly to the 'Crashes' DynamoDB table.
- Hardening recommendations: Implementing strict deployment pipelines (IaC) to ensure Lambda code integrity and using appropriate stream view types (`NEW_AND_OLD_IMAGES` used here, but might be restricted if only new data is needed to optimize reads).
## Related Tools/Techniques
- **Google Clusterfuzz:** Mentioned as the inspiration for the continuous fuzzing architecture.
- **AWS Lambda Functions:** The core computational mechanism.
- **Amazon DynamoDB:** Used as the high-throughput data store and stream source.
- **Browser Fuzzing Tools:** The context driving the need for automated triage.