Improving CrowdStrike Falcon® Detection Content with the Gap Analysis Team

CrowdStrike is always looking for innovative ways to improve detection content for our customers. We believe a multifaceted approach that combines customer input, standardized testing and internal research is necessary to stop breaches today and in the future. At CrowdStrike, we never rest, because neither does the adversary. 

This is a big reason why we created a new team called the Gap Analysis Team (GAT), which implements strategies and processes to emulate malicious behavior with automation at the forefront of the team’s work. GAT’s objective is to identify detection gap areas and facilitate building robust detection coverage as efficiently as possible, creating modular solutions that dynamically configure adversary emulations at scale. GAT is unique in that it provides red team subject matter expertise to many defense-focused groups within CrowdStrike. Over the past year, GAT has focused on developing a red-team, tool-agnostic testing framework for the CrowdStrike Falcon®® platform using a variety of DevOps tools. 

Introducing RTFACT Detonation

Red Team Framework Analysis with Containerized Technology (RTFACT /ˈärdəfakt/) Detonation enables cloud-native automated testing of red team tools such as Cobalt Strike and Atomic Red Team. RTFACT Detonation aims to decrease time-to-detect by removing manual steps needed to test complex emulations. Additionally, given larger sets of execution results from a variety of tools that implement the same tactics, techniques and procedures (TTPs), RTFACT Detonation enables detection engineers to add layers of targeted and broader detection content into the Falcon platform.

RTFACT Detonation leverages DevOps tools such as Ansible, Docker, Kubernetes, Humio (a CrowdStrike company) and Splunk to scale emulation testing both vertically and horizontally as follows:

  • Docker/Kubernetes: GAT believes there are outsized advantages (flexibility and scalability) to using a microservice-based architecture that is capable of deploying prerequisite resources needed for a given emulation. In certain use cases, different tooling needs to be staged to enable callbacks or command and control (C2) for a given attack chain or TTP. RTFACT Detonation’s architecture is built on prioritizing prerequisite requirements with the idea that all standalone tools, proofs of concept (POCs) or frameworks can be easily integrated into a single tool-agnostic framework.
  • Ansible: Ansible is leveraged by RTFACT Detonation to control the execution flow between a detonation host and emulation containers. Lightweight wrappers in the form of Ansible roles are used in conjunction with microservice tools, POCs or frameworks to simplify complex multi-host/multi-tool interactions. Ansible roles written for RTFACT Detonation enable creation of standardized emulation content by exposing the features of a red team tool. Furthermore, standardizing an Ansible role’s input (similar to APIs) allows GAT to scale the automation of test creation using Ansible playbooks.
  • Humio/Splunk: RTFACT Detonation employs Humio — a purpose-built, modern log aggregation, storage and analysis tool — and Splunk to warehouse detonation result data. These database technologies are used to store RTFACT Detonation data such as execution time range, test name and sensor results. Having access to both the sensor event data and execution metadata is paramount to designing a system that can measure the effectiveness of the Falcon platform’s detection content. 

A Practical RTFACT Detonation Example

Figure 1 details an example workflow used to execute an emulation standardized in Ansible playbook YAML. Emulations can be anything from downloading a file to running complex sequential steps across multiple hosts.

In this example, an Ansible playbook is run from within a Docker container and remotely executes Atomic Red Team (ART) tests on a detonation host. Given the variety of sub-tests that exist within an ART test, RTFACT uses UUIDs to map parent-child relationships across each execution step. In doing so, an analyst can query sensor events stored in Splunk to determine the Falcon platform’s coverage for a given emulation. This removes the need to manually gather sensor results for each individual ART step or sub-step. 

The same concept can be applied to more complex adversary emulations that use a step-based approach to execute different red team techniques. By leveraging automation, CrowdStrike is able to react to adversary threats and close detection gaps at a much faster rate. This further enhances CrowdStrike’s ability to prune, modify or consolidate detection content while providing maximum protection for our customers.

Future Improvements to RTFACT Detonation

GAT is always looking for automation opportunities to reduce the amount of time and resources spent on testing new TTPs against the Falcon platform. In Figure 1, the RTFACT Detonation workflow still involves an analyst to execute tests and query Splunk for results. To further automate this workflow, GAT is expanding RTFACT Detonation to use Splunk APIs and other cloud-native tools like Jenkins to schedule test executions and gather results without the need for an analyst. These enhancements allow CrowdStrike analysts to focus primarily on creating detection content for our customers, rather than spending time on emulating TTPs to test against the Falcon platform. 

GAT sees additional automation opportunities in creating advanced emulations that require staging resources like C2 servers and integrating RTFACT Detonation to improve various internal processes within CrowdStrike. As threat actors employ more sophisticated automation solutions to build and deploy new TTPs, CrowdStrike is working tirelessly to meet this challenge and develop internal systems that are capable of outpacing our adversaries.

References

Additional Resources

 

Related Content