BRAWL

One of the challenging problems for cyber security researchers developing detection and response capabilities is finding a realistic environment in which to test their hypothesis and capabilities.

The cheapest method is to test capabilities on a small lab network. But this environment is lacking the scale of real enterprise network and the noise of real environments that makes detection much harder. In many ways, the best environment would be testing on multiple enterprise scale networks with a controlled but realistic attacker and real noise from users, system administrators, and third party software/devices. The challenge with testing in this environment is that it is expensive and in some scenarios high risk.

BRAWL seeks to create a compromise by creating a system to automatically create an enterprise network inside a cloud environment. OpenStack is the only currently supported environment, but it is being designed in such a way as to easily support other cloud environments in the future. BRAWL also builds an analysis network containing a data ingest and processing pipeline using LogStash and Kafka. As part of the analysis network, it creates an event storage and search system using Elasticsearch and Kibana. BRAWL spins up a enterprise network "Game Board" with Windows images. These images have Microsoft Sysmon and other sensors already installed and configured to forward logs into the data ingest framework.

BRAWL also has a concept of bots, which can be either Red, Blue, or Gray. Red bots are offensive, Blue bots are defensive, and Gray bots emulate legitimate user behavior in order to provide noise to make detection more difficult. When a user wants to test research hypotheses, they implement a BRAWL bot. The BRAWL bot registers itself with the BRAWL Controller, which then orchestrates games between BRAWL bots on the Game Board.

Data Release

Note: Due to issues with file sizes and GitHub quotas, we are placing all the files into a zip file instead of leaving them as plain text in the git repo. All the data is in the file

This release consists of some data from a BRAWL prototype. We created a small enterprise network, described below. We then ran a single game using the MITRE CALDERA research project as a red bot.

CALDERA is a related MITRE research project that automates adversary emulation activity based on the information in Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) model. It implements a set of ATT&CK tactics and techniques and uses a planning system (https://dl.acm.org/citation.cfm?id=2991111) to automate the actuation of those techniques and generate post-compromise adversary behavior within an enterprise network.

This data is released under the Creative Commons BY License

Network & Sensor Description

Our small enterprise network is a flat network that consists of a Domain Controller (dc.brawlco.com) and 16 workstations. Each PC has the name of the primary user in the pc name (e.g. user beane typically logs into beane-pc). That user has Local Administrator privileges on the computer.

All the PCs are running Windows 8.1. The Domain controller is running Windows Server 2012 R2.

On the Windows 8 PCs, we made changes to enable WDigest to keep plaintext passwords in LSASS's memory using the following registry command: reg ADD HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\ /v UseLogonCredential /t REG_DWORD /d 1 /F

Scenario Description

For this exercise, CALDERA was the only BRAWL bot participating. While conceptually BRAWL can be used to test a variety of attacker behaviors and detection, many of MITRE's research efforts follow an "assume breach" philosophy. Therefore we give CALDERA a starting point as a Local Administrator on a box on the network at the beginning of the exercise.

Also, without a Grey bot performing logon across different hosts, the BRAWL Game Board is sterile from the perspective of credentials that can be stolen and used by Red bots. To enable lateral movement, the BRAWL Controller uses psexec to create logon events on hosts with the credentials of other users from the network.

CALDERA Performed the following ATT&CK Techniques during the exercise:

• Account Discovery
• Credential Dumping
• Local Network Configuration Discovery
• Permission Groups Discovery
• PowerShell
• Registry Run Keys / Start Folder
• Remote File Copy
• Remote System Discovery
• Windows Admin Shares
• Windows Management Instrumentation

Data

There are five types of data in this repository. Each is contained in its own file in the data/ folder.

BRAWL Shared Format

Red bots and blue bots are encouraged to log information about their activities or detections in BRAWL Shared Format (BSF). The goal of this is to make it easier to compare blue bot detection/actions with red bot actions.

The format is currently in development and could change in future data sets.

The fields for BSF are described below in the Data Sources Detail section.

Notes About Time

Different event sources in BRAWL handle time differently. The time is either the time that an event hit our logging ingest framework, the time the event was generated on the host/endpoint, or the time recorded by a bot on the network. In general those times should be within a few milliseconds of each other. When possible the logging ingest framework uses the event time stored in the event instead of the time of the event hitting the ingest nodes. The table below details the method used for each data type.

Data Sources Detail

game_metadata

sysmon

We are using Sysmon v3.11. sysmon_config.txt contains the output of the sysmon -c command detailing our configuration.

Sysmon generates many different kinds of events, that map to different CAR object/action pairs. The fields for each type are explained in more detail on the CAR website: https://car.mitre.org/wiki/Data_Model

The object/action pairs that are generated by Sysmon in our configuration are:

• driver/load
• file/attr_modify
• flow/start
• module/load
• process/create
• process/terminate
• thread/create
• threat/remote_create

Use the CAR data model to determine the field names and semantics for fields contained in data_model.fields.* for each object/action pair above.

win_event

computer_properties

This data was collected periodically using the unified_json.ps1 module from MITRE's PowerShell Utilities for Security Situational Awareness. The userinfo field can be useful in determining which credentials may have been compromised if a credential dumper such as Mimikatz was run on the system.

bsf

The objects inside of the bsf array field are of type operation, step, or event. All objects have a nodetype field that can be used to determine the object type

event BSF Object

Object/Action/Fields Information for Event Objects

You can read more about the semantics of the Required and Optional Fields by finding the associated object in the CAR Data Model

step BSF Object

Step objects connect one or more events together into a higher level grouping of activity. Step objects also present a place for BSF emitters to label activity with ATT&CK labels.

operation BSF Object

Operation objects connect multiple step objects together. However there are no Operation objects present in this data set.

General BSF Notes

Descriptions and Notes for Event Fields (especially "At least one of"s):

1. Time fields.
2. Punctiliar Time. Activities such as a file deletion are essentially punctiliar, having a single time of occurrence which can be provided via the time field. However, it is possible that neither red nor blue will know this exact timestamp. For example, red bots may spawn a process to accomplish some action within a time window, but the exact time the action occurs is unknown. Blue bots can use sensors which may involve detection delays. Thus, BSF also provides two time fields happened_after and happened_before as temporal left and right brackets respectively, defining bounds on an uncertainty interval for the actual event. At least one of these three fields (i.e., time, happened_after, happened_before) must be reported with each event object. The other fields are optional, but should be reported as they are known. In particular, bots are encouraged to report a value for "time" which is their best guess, even if they do not have an exact time.
3. Durative Time. Activities such as a flow are durative in nature, spanning a time period. BSF generally addresses durative activities by recording the end points of their interval as punctiliar times. Thus a flow start event requires one of {time, happened_after, happened_before}, as does the flow end event. However, some blue sensors may detect a durative activity in mid-course (e.g., a scanner which periodically scans the state of all processes, and determines one has become malicious). For flows, mid-course flow detections can be reported as "flow, message, time, ... (other fields)". For processes, mid-course flow detections can be reported as "process, scanned, time, ... (other fields)".
4. Process identification. Ideally, a pid is used to identify a process, however the pid is not always known, especially by the red bot. Alternatively, the command_line spawning the process, or the exe / image_path which was executed can be provided.
5. Flow ports. The source and destination ports in flows can be described by either a hostname or an IP address.
6. In this data set, the only bot participating is CALDERA, therefore the only BSF records present are from CALDERA.

Appendix

Hosts on our BRAWL network for this game:

• beane-pc.brawlco.com
• colgan-pc.brawlco.com
• dc.brawlco.com
• escue-pc.brawlco.com
• fulco-pc.brawlco.com
• harley-pc.brawlco.com
• kressierer-pc.brawlco.com
• mims-pc.brawlco.com
• minahan-pc.brawlco.com
• ostermeyer-pc.brawlco.com
• peele-pc.brawlco.com
• platten-pc.brawlco.com
• santilli-pc.brawlco.com
• sespinosa-pc.brawlco.com
• sounder-pc.brawlco.com
• teston-pc.brawlco.com
• zissler-pc.brawlco.com