Operating from your desktop
Why we decided to build the first C2 desktop application
If you’ve used a breach-and-simulation platform recently, it probably went something like this: you logged into a website, set up an account, then deployed agents on your company computers - connecting them to the site - allowing you to run an adversary emulation exercise. The process is simple and easy to follow.
Don’t get me wrong, there’s nothing wrong with website-based red teaming. But there are trade-offs when designing any software solution, both for the company building it and the technical staff relying on it. When we started designing Prelude Operator, we chose to do so as a desktop application. This wasn’t because we wanted to be the first to do so (although, that is kind of cool!); there are security, privacy and realism trade-offs that we carefully considered.
Security & Privacy
As an organization concerned with security (as you no doubt are, as you’re reading this), you should be concerned when bytes leave your network. Even if encrypted, any data leaving your network you are entrusting with the website owner. Building a desktop app C2 allows us to guarantee your data doesn’t leave your network, as agents connect to your own desktop app, not our website.
You don’t need to trust us, although we do everything in our power to earn that trust. Because we’re not storing your data by default, you don’t need to trust that we’re going to be responsible with it. We don’t have it. If someone attacks us, with the idea that they’ll gain access to your red team data, they’ll be sorely disappointed.
You may execute TTPs and adversary profiles that are sensitive or proprietary. If you have a constant pipeline to a website, that site owner knows exactly what TTPs you are writing and running. Maybe they’ll use that knowledge responsibly. Maybe not. A desktop app keeps proprietary information proprietary.
If we hire an employee and they go rogue (of course, we make every effort not to), trying to mess with data, that shouldn’t be your problem. If we’re not responsible for storing your information, this can’t impact you.
Realism
If you’re using your BAS vendor to run red team exercises (we sure hope you are!) then you’ll quickly have to whitelist the FQDN of the website you’re using. This is because your blue team will quickly identify and block it. By accepting a whitelist, you’re waving a white flag of surrender, meaning you are no longer performing a realistic threat assessment at the network layer.
If you’re connecting to a website C2, you’ll need - wait for it - access to the internet to run an exercise. This may not be a problem for everyone but knowing that you can do your exercises completely offline should be a cause for celebration.
If you want to have true control over the realism of your exercises, you will need to extend the platform you’re working on. Whether that means adding new protocols, encryption functionality or agents, you will need access. Because you can’t extend someone else’s website, you’re shoe-horned into selecting pre-configured options vs having full control.
For safety reasons, when agents connect to a website C2, they need to go through some type of validation process. This usually involves some sort of pubkey authentication or special-sauce that the website owner has encoded to ensure the agent is not malicious. These measures can be signatured and add bulk to the agents, however - which sacrifice the realism. You will likely end up whitecarding the agents on your computers after some time, as they’ll start getting caught by defenders picking up on these signatures. A desktop app C2 gives you full control over the balance of security and realism, and with the ability to go “offline”, you can veer much more toward a realistic attack. Remember, adversaries will not build in protective measures.
Training
Ever try to do training on a website? Kind of sucks, doesn't it? To conduct realistic security training, we found it much easier to do so natively within a desktop application. This ensures we can execute commands safely on your own computer vs our servers accepting arbitrary code to execute.
Now this is subjective -- but we believe that by baking training into a desktop application, you are more likely to complete it. We want you to feel a sense of ownership with your app, which is hard to replicate with someone else’s website.
Community
We hope by not putting things behind a wall, we can build trust with the security community. We’re pushing as much as possible open-source, some free but not open and a small piece paid through an advanced (Professional) license. Every release, we weigh the pros and cons of what we make open vs closed. This isn’t a business decision, this is a responsibility-driven one. If we believe making something open will create more good, we do it. If it is irresponsible to do so, we don’t.
Where do you spend most of your time on the computer? In desktop apps or websites? We’re banking that most people live in their chat and other desktop applications. We believe in this day and age, we should aim for a desktop app over a site, unless there’s a driving reason against it.
Resources
Let’s say you’re running a red team exercise. But the connection to the website C2 you’re using is slow or it crashes completely. That could impact you in a real way. A desktop application gives you full control over the software, so you can remedy the issue. This means that we cannot be a bottleneck for you.
As we developed Prelude Operator, we put a lot of effort into understanding the trade-offs outlined above. Obviously, as a business, by building a desktop application, we have extracted ourselves from your security process. We believe this is good. It means we can’t datamine your information.
But it also means we have no visibility into what is - and is not - working for you. Our hope is that you’ll engage with us, through the community we’re building, to tell us how things are going. We want to solve real-world security problems and we need you to tell us how.