December 6, 2022
You can get started with Build in one click. The application is open source, so if you’d rather compile it yourself, head to GitHub.
For the past two years, the Prelude team has written TTPs.
In a weekly event we dubbed TTP Tuesday, we’ve released new security tests for our flagship command-and-control (C2) platform, Operator. Each week has included multiple TTPs in what we call a chain. At 52 chains a year, that’s 104 chains. If each chain included five TTPs, that’s more than 500 TTPs published in the last two years.
Prior to Operator, the Prelude team designed and wrote MITRE CALDERA, including seeding the project with the first several hundred TTPs.
What did we learn from Operator and CALDERA? Code editors are designed for software engineers, not security. And TTPs - as they’re used today - are not built for production.
When we sat down to write a new TTP we followed this workflow:
Constantly hitting these friction points prompted us to rethink what a TTP is and how we can use them at scale.
So we wrote Prelude Build.
Build is an easy-to-use IDE - purpose built for authoring, testing and verifying security tests for use in real environments. Our goal was to provide a consistent and repeatable way to write, verify and deploy tests for any scale.
Build can be used through the user interface or the Prelude CLI.
Build exists to streamline taking a security test from ideation to production. Security testing today is usually restricted to development environments and the results are extrapolated to the rest of the infrastructure.
Below, we'll outline a few of the reasons why this is and discuss how Build injects a standard software development lifecycle to overcome these friction points.
Today, security tests come in various forms and formats: TTPs, YML files, executable code, libraries, scripts, exploit code, POCs and more. Most are purpose-built around a specific command-and-control center (C2). By and large, C2 frameworks are not intended for large-scale applications and TTPs with this tight integration makes them difficult to transfer for wider use.
C2's do not refer to their actions as tests. Some use terms like BOF, COF, procedure, etc.
This is why multiple new C2 frameworks are released each year, often with overlapping functionality. People aren't trying to improve upon the behavior of the testing, but on the tooling around the testing.
The next problem arises when you want to execute an action. There is no standard approach to testing the efficacy of the test (does it work), where it can and cannot run, and gauging what the system impacts are of running it.
Consider that security tests fall into two broad categories:
A C2 is an execution framework for launching actions against remote agents. There is no concept of a development environment bundled with your C2, similar to how there is no dev environment hanging off your production system elsewhere. In order to gauge efficacy, you have to deploy agents in a fairly involved process that tests the runtime of the C2 as much as your test itself.
Extracting your tests from the C2 allows you to test them independently - and there is precedence for this in the wider technology space. However, security engineers have lacked the same tooling software engineers have enjoyed for years around continuous integration testing.
Software engineers build complex applications that have predictable runtime environments, so IDEs focus on project building and authorship. Security engineers generally build simple single file actions with unpredictable runtime environments, and therefore have been boxed into using IDEs not purpose-built for them.
When testing, there are three things you should gauge:
Build can be broken down into the following functions:
Similar to a text editor, Prelude Build allows you to manage a set of code files in tabs. Prelude Build stands out by providing a tailored experience for security engineers, including multi-language support and templates in each language for writing standard security tests.
You start by proposing an idea in question form:
Does this host have a private key I can exfiltrate?
Then you create a test for your question and build your first variant by selecting an operating system (Windows, MacOS, Linux), an architecture (x86, arm64) and a language. Prelude Build currently supports C, C#, Go and Swift.
Learn how to write security tests for production.
These selections will generate you a file named ID_platform-architecture.language so you can programmatically understand what type of system it is coded against. Each file will contain template code for writing your test.
As you write tests Build stores them in a private cloud account only you can access. You can treat this database similar to git: you can push, pull and clone your files across multiple computers. If you share your account with teammates, you can work concurrently on the same project.Your storage is broken into:
Any test can - and should - be validated in Build as you develop it.
Build's GUI and CLI act as thin clients connected to a more powerful Compute server, containing the runtime environment for compiling, scanning and publishing your code. When you fire off a test your source code is sent to a Compute server, which performs the following:
Build does all compile and validation steps concurrently, so you should experience a similar latency as compiling code locally - only your Compute server will do quite a bit more!
Test outputs are standardized, so you can easily, and objectively, understand their efficacy. Each test will display the specific status code, seconds it took to run (human not CPU) and debug information from stdout and stderr.
Once a test has been authored and verified, you can move it to a ready-for-execution state. In Build, this means generating a deployment URL for it. These URLs, which we refer to as Verified Security Tests (VSTs), are pre-signed download links to your test which are usable for up to 10 minutes. To run your VST, take a URL and plug it into any C2 or execution engine, as shown here using Prelude's probes (more on these later).
Alternatively, you can run your VST using Prelude Detect, a system for continuously running Verified Security Tests at production-scale.