Operator is a desktop application which allows easy execution of red team assessments without requiring your own internal security team. You simply open the app up on your computer, start agents on remote computers you want to test, build an adversary and click deploy. Then sit back and enjoy the results and recommendations as they flow in.
But what if you don't want to click the buttons yourself?
There are two primary reasons to apply full-scale automation:
You want your security to be completely hands-free.
You want to integrate with other security products.
If you're paid to red, blue or purple team, you work at an organization that can afford resources to protect itself. Hands-free security is probably not what you're looking for; you want to leverage Operator for writing advanced TTPs, building custom adversary profiles, training on the latest attacks... you know, advanced security work.
But what if you're in IT or InfoSec and running adversary emulation exercises is not your primary job? In this case, you're a prime candidate for automation. You want to download a security product, configure it within minutes, and then forget about it.
Integrate with security products
If you are looking to create a cyber range for education or simulated attack-and-defend practice, you may be looking for a red team tool to "plug-and-play."
There are many automated blue team tools on the market, commercial as well as free and open-source. There are far fewer red team tools which can simulate adversaries with any realism. Realism is hard to achieve. It takes deep knowledge of offensive security, combined with great software engineering. Because most working in cybersecurity are on the defensive side, there is naturally less knowledge about offensive strategies and therefore less realism built into the solutions available.
If a solution tells you to turn off your defenses to test your security - turn around and run the other way. They will not give you a realistic security assessment - unless you think the adversary will also ask you for that before attacking.
MITRE CALDERA has been the prominent free red team tool for the past few years. Our core development team was responsible for writing up to version 2.8.0 of that software, when we turned our attention to Operator.
If you fall in this camp, you may just need to add a tool to your environment which can replicate red team actions because you already have the blue side covered.
Going autonomous: Option #1
If you're still reading, you probably fall into one of the categories above. Good. Let's get started turning Operator into a fully autonomous attacker.
Have you completed the 3-minute installation? If not, start with this as you'll need a base Operator installation to configure.
Would you like to automate the download, registration and installation of Operator? If you're comfortable with scripting, you can automate this process as well using most programming languages. Need to do this whole thing offline? Operator is designed to run offline but it requires a special license. Reach out at email@example.com to learn more.
When you open Operator, click over to the Emulate section where you'll be greeted with an empty list of adversaries and a home range.
By default, Operator will contain a single range, home, which holds your local ThirdEye agent. If you want to run your exercises against your current computer you can skip ahead to step #4.
If you want to execute against remote computers, you'll need to add some agents.
Copy the agent files to the computers you want to test and start them. The agents should populate immediately in whichever range you chose. You can automate this step as well with some simple scripting to start/stop your agents.
Next, click to add a new adversary and again to add TTPs. From here, you can build your threat profile. What you build depends on your objectives. Note the filter for tags. An adversary tag is a category of attack that goes together. For instance, all the TTPs under ransomware mix-and-match in various combinations to conduct that type of attack.
With your adversary built, you can then optionally add a goal, or a stopping point for the adversary, if successful. A goal represents a fact (key/value pair) the adversary is looking to collect. For example, this goal means the adversary will stop if it collects a file path containing "passwords.txt" from running a T1005 technique. Goals are optional, so feel free to skip this for now.
Finally, add a schedule. This is the real magic for autonomous execution.
A schedule is the day/time you want to execute your adversary on. This uses a cron schedule under-the-covers and when enabled, the scheduler will execute any time your computer is on (even when it's sleeping).
You may want to check in frequently to review your security recommendations, available in the reporting section. Accessing these is not yet automated.
Now you're done. Go ahead, ensure the range you want is visible, and deploy your adversary. You can now close the lid to your computer and step away, your autonomous red team will run on auto-pilot.
Going autonomous: Option #2
Maybe Option #1 still involved too much clicking around for you. You want a repeatable automated process and the one-time configuration of adversaries and schedules is too laborious.
If this sounds like you, you'll be happy to know we put in "shortcuts" for doing the configuration. You don't think we'd show you that first though, do you?!
Instead of building adversaries and schedules from the desktop interface, you can add YML files to your workspace before starting Operator.
Your Operator workspace is a directory in your installation directory which contains all your TTPs, adversary profiles, schedules, payloads, results and more.
Let's start in the workspace/adversary directory. In here, you can add a YML file
id: 51dd0c4b-49f9-46dc-b8a3-c4f50f0e08ce name: Hacker I am not ttps: - 85341c8c-4ecb-4579-8f53-43e3e91d7617 - ed71b093-fa66-4f06-86a0-ba4e514e4b28 goals: 
The file must be named after the ID itself. Above, that would mean 51dd0c4b-49f9-46dc-b8a3-c4f50f0e08ce.yml.
Your adversary file simply needs a random UUID for an ID, a name, a list of TTP IDs and an empty list of goals. If you want to replicate the adversary from Option #1, you can add goals like this:
goals: key: file.T1005 criteria: contains val: passwords.txt
You can do the same with a schedule. Find the schedules.yml file (at the same directory level as your workspace) and add a new YML file that looks like this:
- range: home stealth: 'no' adversary: 51dd0c4b-49f9-46dc-b8a3-c4f50f0e08ce dayOfWeek: '2' hour: '14' minute: '50'
If you followed Option #1, these fields will look familiar. These are:
range: the range of agents you to want test against
stealth: this can be any stealth module from the Emulate section. Right now, this is either 'no' or 'base64'
adversary: the ID of the adversary to run
dayOfWeek: Sunday is 0, Monday is 1...
hour/minute: when the adversary should run
schedules.yml is a list of all cron jobs, so to add multiple, just append new entries to this file.
Just start Operator and the schedule will be applied. Add more in the future following the same process and simply restart Operator for them to take effect.
Whether you're automating Operator to have true hands-off security or to integrate with another tool in your environment, we hope this walk through was able to get you there. Reach out to our team with any thoughts, questions or general comments on the process.