Introducing CTRL: ARMO’s Cloud Threat Readiness Lab

Nov 20, 2025

Ben Hirschberg
CTO & Co-founder

If you are dealing with securing cloud infrastructure, containers and applications, you probably have several security tools in place including cloud posture (CSPM/CNAPP), container security and runtime security. Tool coverage might look good on paper, but how can you know they work against real attacks?

ARMO CTRL (Cloud Threat Readiness Lab) helps you test your cloud security tools by deploying a safe, controlled attack lab that mimics real attack behaviors end‑to‑end. Unlike other attack simulations, CTRL starts with a web exploit before pivoting deeper into your cloud environment to simulate what real attacks look like.

ARMO CTRL runs curated attack scenarios against deliberately vulnerable sample services that model realistic flaws (e.g., command injection, LFI, SSRF, SQLi) that we expect to see attackers targeting. The goal is not to “find a bug,” but to validate whether your cloud and container controls detect, alert, and prevent as designed.

With ARMO CTRL, security and platform teams can:

Validate detections across layers (WAF/API gateway, Kubernetes admission/runtime policy, EDR/IDS, logging/ SIEM, CNAPP)
Exercise response paths and playbooks with realistic but safe signals
Baseline coverage and quality, then measure improvements over time
Train blue/red/purple teams using consistent, repeatable scenarios

Scenarios are narrowly scoped to produce meaningful artifacts—logs, process starts, network egress, query anomalies—without destructive side effects. Everything runs in a lab you control, so you can tune policies, test rule updates, and compare outcomes consistently.

What it is

A curated set of practical attack scripts covering common web and container attack paths: command injection, local file inclusion (LFI), server-side request forgery (SSRF), and SQL injection
Ready-to-run Kubernetes manifests for a lab with intentionally vulnerable services
Simple, parameterized Bash scripts that exercise the included vulnerable services (not your production apps)
Clear guidance on expected outcomes and what to monitor in your security stack

Who it’s for

Security and detection engineering teams are validating their detections, alerts, and response playbooks.
Blue, red, and purple teams are running realistic exercises and training
Platform/SRE/DevSecOps teams hardening container platforms and CI/CD guardrails

What you should use it for

Measuring detection coverage and alert quality across common attack techniques
Tuning EDR/IDS/WAF/Kubernetes policies with real signals
Regression testing after policy, agent, or rule changes
Hands-on training and tabletop exercises grounded in realistic telemetry

How it works (at a glance)

Each attack lives in its own directory with a focused attack.sh. You deploy the lab and run the scripts against the included services. The payloads are designed to be realistic yet contained, producing artifacts your tools should detect (logs, process starts, network calls, query anomalies).

Example invocation:

cd command-injection
export TARGET_URL=http://localhost:8081
./attack.sh

You can also enable additional variants via environment flags (see the repository README.md).

A quick example: Command Injection

The command injection scenario targets apps that forward user input to shell commands without proper validation.

What the script does:

Sends crafted inputs to a “ping-like” endpoint
Tries payloads that chain a harmless command (for example, listing a directory)
Reports whether the app appears vulnerable and what evidence was observed

How to run it against the sample lab:

# After deploying the Kubernetes lab (see Installation Guide), port-forward the Ping App:
kubectl port-forward -n attack-suite service/ping-app 8081:80 &

# Run the attack
cd command-injection
TARGET_URL=http://localhost:8081 ./attack.sh

What to monitor while it runs:

Application logs for suspicious inputs and errors
Process monitoring (unexpected shell utilities being invoked)
File system access patterns from the app container
WAF/IDS/EDR detections, and Kubernetes audit or policy violations

Expected outcome signals:

If vulnerable: directory listings or system info appear in responses/logs
If protected: input validation blocks payloads; controls raise alerts without impact

Getting started

Run the suite in a lab that simulates a cloud environment:

Deploy the included vulnerable services to Kubernetes
Port-forward the services locally (or expose them inside your test VPC)
Run the attacks and observe detections in your cloud and container security stack

See the repository README.md and INSTALLATION.md for step-by-step instructions.

Safety, scope, and ethics

This project is for authorized, educational, and testing use only. Always run in isolated environments you control, with explicit permission. The suite aims to produce realistic telemetry without causing destructive side effects, but you are responsible for where and how you run it. It is not intended to test your own application code; its purpose is to validate detection and protection mechanisms in cloud environments using deliberately vulnerable applications.

Final thoughts

Effective security isn’t just about having tools—it’s about proving they work. Use CTRL to continuously validate your defenses, tighten your detections, and train your teams with confidence.

Get a demo