Skip to content

Latest commit



20 lines (16 loc) · 1.58 KB


File metadata and controls

20 lines (16 loc) · 1.58 KB


BinaryAlert utilizes a serverless architecture which is low-cost and easy to scale and maintain. While it's helpful to understand how BinaryAlert works, keep in mind that Terraform manages all of these components so you don't have to!

BinaryAlert Architecture

Analysis Lifecycle

  1. The organization collects files and delivers them to their BinaryAlert S3 bucket. Files of interest could include executable binaries, email attachments, documents, etc.
  2. Every file uploaded to the S3 bucket is immediately queued for analysis (using S3 event notifications).
  3. The SQS queue automatically batches files and invokes many analyzers in parallel.
  4. Each analyzer scans its files using a list of pre-compiled YARA rules.
  5. YARA matches are saved to DynamoDB and an alert is sent to an SNS topic. You can subscribe to these alerts via StreamAlert, email, or any other supported SNS subscription.
  6. For :ref:`retroactive analysis <retro_scan>`, the CLI will enqueue the entire S3 bucket to be re-analyzed.
  7. Configurable :ref:`CloudWatch alarms <metric_alarms>` will trigger if any BinaryAlert component is behaving abnormally. This will notify a different SNS topic than the one used for YARA match alerts.