Emulating Adversaries with Prelude Operator and Elastic
In order for security platforms to be constantly under evaluation and improved it is necessary to create controlled tests for its systems to handle. To fill this need many different tools have emerged to facilitate adversary emulation. The basic premise is that although the specific methods of an attack used by adversaries may be almost infinite, the specific goals of those actions follow patterns. The MITRE ATT&CK Framework has become a standard in providing a systematic approach to identifying these goals. Using the techniques(sub-tech) that are provided in ATT&CK makes it possible to provide specific tests that seek to emulate how the attack would be undertaken. Some of the most well-known platforms are Caldera (MITRE), Atomic Red Team (Red Canary), and Red Team Automation (EndGame). Each seeks the similar goal of emulating an adversary, but obviously with various specific testing intentions. Recently I was introduced to Prelude Operator (Prelude). We all love new toys and I could not skip the chance to share this adventure with you.
Background:
Although the platform is relatively new its creator, David Hunt, is probably one of the most authoritative individuals in the field. In his article entitled ‘A History Lesson’, Hunt describes his journey as the original designer of Caldera v2 to how he decided to help build the Operator platform. While reading about the concept that brought operator into existence I was drawn to one important note in my own journey, that of needing solid platforms to train on. Prelude created Operator not to be just another possible choice amongst tools but put an emphasis on training/education that is in dire need in the industry.
Funny enough the first time I even learned about adversary emulation was because I was trying to learn how to create datasets that I could train myself and colleagues with. This was back when my ‘lab’ was a bunch of outdoor tables covered with overworked desktops/laptops, Cisco equipment bought off of craigslist, and a cadre of individuals who wanted to learn infosec. At the time I came across Red Hunt Linux and ran into adversary emulation. Bit of a tangent from David’s story on Operator’s vision, but I think there is a common thread that adversary emulation is also a strong educational tool for those needing to not only be introduced to infosec but to constantly keep those skills advancing and honed.
While using Operator for the first I could definitely feel its Caldera roots. The framework is similar in that it is more of a central command for your adversaries to run attacks through a self-implanted agent/C2 infrastructure. Where other tools like Atomic Red Team or RTA are great for straightforward emulation, Operator definitely falls in the other class of full campaign planning and advanced execution options. The training material is very accessible as the entire documentation for Operator is available in the GUI, and the training modules are right on the main tabs. I think this will prove to be its greatest strength. Anyone who has never used it before literally has a welcome mat waiting for them.
Setting up the Guinea Pig:
I typically use a Windows 10 Pro VM for my guinea pig. When using a windows system for adversary emulation you have to make sure to set things up such as network discovery, file sharing, firewall, and deactivate defender. The reason I deactivated defender is that it is not the focus of this emulation test series. I also installed the latest version of Sysmon and used a modular configuration tool to create an ATT&CK-orientated ruleset. Finally, I installed the Elastic Agent to gather all data and ship it to the Elastic Stack. In the figure below I have the integrations that I have included in a policy I labeled as ‘Windows Desktop’.
In this particular policy, I have Elastic-Endpoint, system, and windows integrations installed and operational. I could have skipped the systems integration since in reality, the other two cover a majority of that information as well. But since this is a lab environment and I have no memory budgets in my stack to consider I have included it. You actually get some neat data from the system integration and it is worth getting familiar with its dataset. Elastic Endpoint is the main EDR that this policy relies on. Beyond just providing log information it also acts on its own to malware found on the device and has kernel-level monitoring capabilities. I do like to run this concurrently with Sysmon though and not as a replacement. I like to think of it as monitoring in-depth. Let Elastic-Endpoint do its thing while I also make perfectly good use of Microsoft Security Events and Sysmon alerting. This provides me with a wealth of data on any event and provides overlapping defenses in case any of those sources are evaded/disabled by an adversary.
On the right side, I have included the Windows-1 integration settings. Notice that I never installed winlogbeat on the device. Indeed, I can now use the Windows Integration to bring in the default log sources that were once brought in by winlogbeat. This includes event logs, PowerShell, PowerShell operational, and Sysmon Operational. Now if I needed a source of events not within this set then I would need to install winlogbeat. My guess is that Elastic would add it to this configuration list if customers found some that were not covered but highly needed. With my Elastic-Agent enrolled and ready I started by activating the built-in alerts that are included in Kibana and switched back to Operator.
The Pneuma Agent:
The Pneuma Agent is a wonderfully built GO RAT(remote access trojan). Operator is meant to be operated to conduct Post-Compromise attacks and so the agent must somehow be loaded onto the target first. If this were a full exercise you could use other tools to compromise a host and make the attack more realistic, but for my purposes, I simply copied the file onto my VM.
The Pneuma Agent has a lot of fun customizing that can be done, and also some basic obfuscation methods. Following the training modules, I learned that it is best to compile the client using GO because then you can provide a key that will create a unique hash for the file. Otherwise, the hash of the standard Pneuma Agent would become an easy win for defenders. In addition, compiling the agent means you can first change things about its configuration such as the encryption key used for communications and default protocol used for communication. While completing the training I learned that it can use TCP, HTTP, and gRPC protocols for its C2. The exercises have you learn how to configure each one and confirm that the agent is able to communicate with the server.
Adversaries:
With my agent installed on my ‘red range’(you can create distinct environments for agents to be grouped by) I was ready to set up my first adversary. I always like menus that remind me of ordering food, and once again the adversary setup fits the bill. You can choose from various TTPs that will accomplish the objective of an ATT&CK Technique. There is also the ability to write your own procedures if you want something different. In addition, all those wonderful TTPs available from Atomic Red team can also be imported.
Deploying the adversary can be done instantly or scheduled for some future point in time. It is once the deployment has occurred that Operator begins to stand out amongst the crowd. “The Brain” of Operator is smart enough that it does not pretend that an attack will always go in a linear fashion. For simple adversaries with a few TTPs it can seem this way, but more complicated chains take a life of their own. This is because “the brain” is a finite state machine that is constantly evaluating what new information it has that could benefit certain procedures being run over others. As it collects facts through the time span of the attack it also creates new possible paths it will take depending on what information it receives. For me this is an exciting side of the inner workings, and I hope to have more time to watch as it advances in development.
Once an adversary has finished the attack all the information is available both on a reporting page and in the detailed logs of the agents themselves. This gives ample opportunity to check which procedures did their job and which failed miserably. The most likely reason for a failure was that particular TTP not being applicable to the system. Checking for processes or architecture that my guinea pig did not have. In the future, I hope to create much more complex adversaries but for now, the simple ones I used did the job.
A Lack of Alerts!
The most interesting part of this entire blog is the funny moment when I realized that very important alerts were not being triggered. At first, I went back and checked the logs and activation settings. Indeed the data was received and the rules were all activated. This led me to an obvious conclusion, the detection rule needed was not in the default group.
Let me rewind and explain what I launched with my adversary. I built an adversary that would conduct simple discovery on my first run. I did not expect alerts because the commands used would create a lot of noise if they were detected constantly.
But my second adversary was authorized to use destructive techniques. These techniques would seek to delete files and disable settings in an attempt to evade defenses. I noticed while studying recent breaches that this could be a real chance to bottle-neck an adversary in the detection chain. In this particular adversary, I gave it the ability to attempt to delete various logs and finally disable windows event logging. It was this last action that I expected to find a huge alert staring me in the face.
Why we need to support the Elastic Detection Rules Github
Elastic did a wonderful thing last year. They created the Elastic Detection Rules Github. This GitHub is so much more than just a dusty tome where the rules list is kept. It is an active hub of creativity and invention. The repo has a whole set of python tools just to help you write, validate and even test detection rules. Even better is the fact that this same repository is being used by Elastic’s own development team. This means an unprecedented opportunity to keep each other in the loop about what is both on the product roadmap, give active feedback and even contribute rules that we create.
The process of creating a rule starts with a conversation, which in my book is perfect. First, you make an issue in the repo explaining the rule you are proposing and show what dataset it works against. This way if someone has already written a similar rule, or is in the process, the work can be combined and no precious effort wasted. My rule is very simple and merely uses an EQL line to alert if the event logging is disabled. The current ruleset (as of 7.12) had rules about modifying or deleting logs, but it seems the act of disabling it entirely was accidentally overlooked. This is exactly why the Elastic Community(myself included) really needs to start putting this rule set through its paces, and fill in the gaps that are going to be there. When any of us take the time to throw an emulation together and report our results it makes all of us stronger. The image below is my humble EQL rule.
Concluding Thoughts:
Prelude Operator has the potential to become my mainline adversary emulation platform. The intensive training materials alone gave it a head start, but the ease of use and multiple ways to add TTPs is also a bonus. It has all the great things that Caldera built as a foundation, but with a truly inspired development road of its own. I wrote this blog with just the community license, but for a relatively inexpensive upgrade, I can unlock even more TTPs that are both preloaded and continuously added to. My aspiring hope for some time has been to contribute detection rules that fill gaps where needed. Operator is definitely a great tool that will help me get there. Down the road, I will have to revisit Operator and show off some of its more advanced decision-making functions. As well as make further contributions to the Elastic Detections depot and community projects like Sigma(a cross-platform detection repository).
