St

Strelka on Ubuntu 24.04 LTS

Azure Security

Strelka, Target's real-time file scanning and analysis system that recursively decomposes archives and documents and returns a structured event tree for threat hunting, detection engineering and incident response.

Base
Hardened build
minimal ports, security patches applied at build time
Access
Unique credentials
generated on first boot, readable only by root
Verified
Boots working
services pass a health gate before release
Support
24/7, 365 days
by email and live chat, 24 hour response SLA

Overview

Strelka is a container based file scanning system built by Target's security team for threat hunting, threat detection and incident response. Files are submitted to a Go frontend over gRPC, distributed through a coordinator to Python backend workers, and scanned by a library of specialised scanners. Its distinguishing behaviour is recursive decomposition: when a scanner extracts children from a container format, an archive, an installer, an email attachment, an embedded object in a document, each child is resubmitted and scanned in its own right, so a threat buried several layers inside a file is surfaced rather than hidden by its wrapper. Every scan returns structured JSON rather than a verdict, one event per file at every depth, carrying hashes, file type, entropy, metadata and YARA matches. That output is designed to be shipped into a SIEM or data lake and queried, so analysts can hunt across a corpus of files instead of triaging one at a time.

This image runs the full single node topology, a frontend, a coordinator, a manager, a scanning backend, an event cache and a PostgreSQL backed web interface for submitting files and browsing results. It suits detection engineers building and testing YARA rules against real samples, incident responders decomposing suspicious attachments, and security teams that want a self hosted analysis pipeline running inside their own subscription rather than uploading evidence to a third party.

Why the cloudimg image

Strelka's own web login does not verify passwords unless an LDAP server is configured, and the upstream deployment publishes its database and its unauthenticated file submission port on every interface. cloudimg does not ship it that way. The web interface is fronted by nginx with HTTP Basic authentication using a credential generated uniquely for your VM at first boot, and every other service port, the gRPC submission port, PostgreSQL and both coordinators, is bound to localhost only. No password is baked into the image: the interface credential, the database password and the session signing key are all generated on your own machine at first boot and written to a root only note, and the image is structurally unable to start the stack before that has happened. The upstream coordinator image is replaced with Valkey, which is BSD licensed, because the tag upstream pins now resolves to a release under a licence that is not appropriate to redistribute. Every container image is pinned by digest and pre pulled, so the stack starts without reaching out to a registry, and the full Apache 2.0 licence text and upstream attribution notices ship with the image.

Common uses

  • Recursively decompose suspicious archives and attachments during incident response
  • Test and tune YARA rules against real samples at scale
  • Feed structured file scan events into a SIEM for threat hunting