Introducing Prelude Build: An IDE Purpose Built for Security Engineers

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:

1. The idea. Either from threat intel or our own experience, we would have a lightbulb moment of what we wanted to build.
2. The writing. We would fire up VS Code or Jetbrains and start writing the TTP. Because some TTPs are more suitable for specific languages, this meant we were constantly installing compilers and plugins in our integrated development environment (IDE).
3. The testing. We would test our TTP inside the IDE, restricting us to whatever platform we were writing the code on.
4. The deployment. We would take our TTP and plug it into Operator manually, which has a typical C2 design - meaning it is not appropriate for scaled deployments or even moderate production usage.

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.

What is 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.

Why does Build exist?

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.

Flexibility

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.

Efficacy

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:

1. Those integrated into a C2
2. Standalone scripts, executables, libraries

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:

1. Does it do what I expect?
2. What operating systems and architectures can I run it on?
3. What are the negative impacts of executing this in production?

How Build Works

Build can be broken down into the following functions:

1. Authorship
2. Storage
3. Validation
4. Deployment

Authoring Security Tests

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.

Storage and Collaboration

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:

• src/ -- your source code files, as they appear in your editor
• dst/ -- compiled files that you have published for use

Validating Security Tests

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:

• Looks at your filename to decide which compiler to use.
• Compiles your code for all applicable platforms. Your C file may work on Windows, Linux and MacOS equally, so your Compute server figures this out and builds the appropriate binaries.
• Scans each compiled binary against known malware signatures to determine if the test is likely to be caught.
• Gathers results for all compile and test steps and displays them back in your client.

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.

Deploying Security Tests

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.

Get Started with Build

The Build application is fully open source, so if you’d like to compile it from source, head to GitHub. Otherwise, the easiest way to get started with Build is by grabbing a free copy of it here.