Part 1 of a 3-part series on building a modern Breach and Attack Simulation platform
Why We Built Our Own
The offensive security tool market isn’t short on options. Industry-standard frameworks have dominated the space for over a decade. Newer platforms have emerged with enhanced evasion capabilities. The list of available tools grows every year.
So why build another one?
The Problems We Couldn’t Solve with Existing Tools
1. Compliance Requirements
When you’re building for enterprise customers with strict compliance requirements, “it works” isn’t enough. You need validated cryptography, aligned architecture, complete audit trails, and data residency guarantees.
Most offensive tools treat compliance as an afterthought. We needed it as a foundation.
2. Multi-Tenancy Done Right
Existing platforms assume a single team operating against a single target. But enterprise BAS requires multiple concurrent operations, operator isolation, per-operation cryptographic separation, and disposable infrastructure per engagement.
Bolting multi-tenancy onto a single-tenant design creates security gaps. We needed it architected from day one.
3. Intellectual Property Concerns
Using frameworks with murky licensing or leaked source code creates legal exposure. Clean room implementation means 100% IP ownership, no license encumbrances, no leaked code contamination, and clear provenance for every line.
4. Modern Architecture
Many tools carry 10+ years of technical debt. We wanted cloud-native deployment, horizontal scaling, memory-safe language choices, and API-first design.
Architecture Decisions
Language Selection
The biggest decision was choosing a backend language that met our security and compliance requirements. We evaluated based on memory safety, performance, concurrency, compliance support, and security auditability.
Industry guidance mandating memory-safe languages validated our approach. For a security product, eliminating entire vulnerability classes at compile time is worth the investment.
Database Architecture
For the control plane, we needed ACID compliance, time-series capabilities for audit logs, encryption at rest, and mature operational tooling. We selected an enterprise-grade solution with time-series extensions that efficiently handle millions of audit events.
Message Queue Architecture
Task distribution required high-performance messaging. We evaluated based on throughput, memory footprint, clustering, and operational simplicity. For a platform coordinating thousands of agents, the message queue’s performance characteristics are critical.
Frontend Architecture
The operator interface is built with modern web technologies: component-based framework with server-side rendering, type-safe development, utility-first CSS, lightweight state management, and fast build tooling.
The Two-Tier Architecture
Our most significant architectural decision was the isolated operation model. The platform separates into two tiers:
Tier 1: Control Plane – Manages operators, orchestrates operation lifecycle, and provides the API gateway and operator UI. The control plane never stores operational data.
Tier 2: Operation Servers – Each operation runs in its own isolated environment with unique cryptographic keys, an isolated database, separate network addressing, and disposable infrastructure. One operation’s compromise cannot affect another.
This separation means:
- Agents from one operation cannot communicate with another operation’s server
- No data mixing between operations
- Different traffic profiles per operation
- “Burn” an operation = destroy the isolated environment and all data
Cryptographic Foundation
Security tools should exemplify security. Our cryptographic implementation uses validated algorithms and meets enterprise compliance requirements. All cryptographic operations use implementations aligned with federal standards.
Agent configurations are encrypted at build time and verified before any parsing. Signature verification happens before any data is processed. This prevents malformed configuration attacks – we don’t even look at the data until we’ve verified its authenticity.
The Agent Architecture
Our agent is designed as position-independent code with a minimal footprint:
- Minimal dependencies – Core functionality implemented from scratch
- Runtime resolution – System interactions resolved dynamically
- Position independent – Can execute from any memory location
- Configurable behavior – Multiple operational modes based on the engagement scenario
The core agent is small. Capabilities load dynamically as needed – this keeps the initial footprint minimal and allows capability expansion post-compromise.
Scaling Considerations
Agent Management at Scale
The isolated operation model means each operation server handles its own agents. The platform uses asynchronous I/O for high concurrency, persistent task queuing, and efficient state management.
Scaling levers: Horizontal scaling of operation servers, read replicas for query load, and distributed messaging for task distribution.
Payload Building
Payload generation is CPU-intensive. We handle this via background build tasks, configurable build queues, and cached base artifacts to minimize recompilation.
What We Learned
1. Start with Compliance, Not Features
It’s tempting to build the cool evasion features first. But retrofitting validated cryptography and audit logging is painful. Build the boring compliance stuff first.
2. Isolation is Worth the Complexity
The two-tier model adds operational complexity. But the security guarantees – no cross-operation data leakage, disposable infrastructure, cryptographic separation – are worth it for enterprise customers.
3. Memory Safety Pays Off
Choosing a memory-safe language meant a steeper initial learning curve, but the long-term benefits are clear: no memory safety bugs, no data races, and confident refactoring.
4. API-First Enables Automation
Every feature is an API endpoint first, UI second. This enables CI/CD integration, scripted operation management, and integration with other security tools.
What’s Next
In Part 2, we’ll dive deep into compartmentalization – how we isolate operations, operators, and data to meet strict compliance requirements.
In Part 3, we’ll cover the automation layer – payload generation, stage transforms, and how the platform integrates with threat intelligence.