Downloaded 190 times
More Related Content
Similar to Purple Teaming with ATT&CK - x33fcon 2018
![[Bucharest] Attack is easy, let's talk defence](https://cdn.slidesharecdn.com/ss_thumbnails/attackiseasyletstalkdefencev3-151026104559-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
Purple Teaming with ATT&CK - x33fcon 2018
- 1. © 2018 TheMITRE Corporation. All rights reserved. | 1 | Christopher Korban Cody Thomas x33fcon - May 2018 Threat-based Purple Teaming with ATT&CK Approved for public release. Distribution unlimited 18-0944-5
- 2. | 2 | ©2018 The MITRE Corporation. All rights reserved. ATT&CK T1033 – User Discovery Christopher Korban – Lead Cyber Security Engineer – Works on ATT&CK – Creates Adversary Emulation Plans – @ckorban Approved for public release. Distribution unlimited 18-0944-5 Cody Thomas – Senior Cyber Security Engineer – Created Mac/Linux ATT&CK – Red Teamer and Tool Developer – @its_a_feature_
- 3. | 3 | ©2018 The MITRE Corporation. All rights reserved. Traditional Offensive Testing Workflow Intel Gathering Vulnerability Assessment Target Acquisition Exploitation Privilege Escalation Lateral Movement Persistence Exfiltration Report Findings Collect Protect Detect Triage Investigate Coordinate Remediate Typical Red vs Blue event flow Approved for public release. Distribution unlimited 18-0944-5
- 4. | 4 | ©2018 The MITRE Corporation. All rights reserved. Traditional Outcomes Red – Creates report of offensive techniques and IoCs for what they did – Wants to make sure they ‘win’ again next time – Leaves for a year Blue – Deciphers Red’s report – Continues to deal with daily incident reports – Creates static detections for Red’s tools and IoCs – Might try to characterize malicious behavior Typically has small sample size No good way to keep testing Little to no collaboration Approved for public release. Distribution unlimited 18-0944-5 https://aconsciouslifenow.com/wp-content/uploads/2017/07/Health-Wealth-Purpose-and-Love-thru-Releasing-the-Adversary.jpg
- 5. | 5 | ©2018 The MITRE Corporation. All rights reserved. Purple for a Better Future What is purple teaming? – Remove win/lose mentality between red and blue One team, one goal - improve security – Continual cooperation and sharing between red and blue Transparency benefits all – Not just internal red teams, external red teams can do this too – More hands, moar secure? Approved for public release. Distribution unlimited 18-0944-5 https://media.giphy.com/media/yUlFNRDWVfxCM/giphy.gif
- 6. | 6 | ©2018 The MITRE Corporation. All rights reserved. Moving Towards Purple Workflow Intel Gathering Protect/Defend Vulnerability Assessment Protect/Defend Target Acquisition Protect/Defend Exploitation Protect/Defend Privilege Escalation Protect/Defend Lateral Movement Protect/Defend Persistence Protect/Defend Exfiltration Protect/Defend Traditional Red Team Action Traditional Blue Team Action After a traditional Red vs Blue event start blended retesting: Slide inspired by Chris Gates’ and Chris Nickerson’s presentation “Building a Successful Internal Adversarial Simulation Team”: https://goo.gl/R3yglm Approved for public release. Distribution unlimited 18-0944-5
- 7. | 7 | ©2018 The MITRE Corporation. All rights reserved. Need Common Language for Purple Communicate – To articulate test and results Repeat – To verify results and retest Measure – To gauge improvement across tests attack.mitre.org Approved for public release. Distribution unlimited 18-0944-5
- 8. | 8 | ©2018 The MITRE Corporation. All rights reserved. ATT&CK Matrix Format Adversary Tactics, Techniques and Common Knowledge Approved for public release. Distribution unlimited 18-0944-5
- 9. | 9 | ©2018 The MITRE Corporation. All rights reserved. David Bianco’s Pyramid of Pain Approved for public release. Distribution unlimited 18-0944-5
- 10. | 10 | ©2018 The MITRE Corporation. All rights reserved. ATT&CK Technique Format Approved for public release. Distribution unlimited 18-0944-5
- 11. | 11 | ©2018 The MITRE Corporation. All rights reserved. ATT&CK Technique Format Approved for public release. Distribution unlimited 18-0944-5
- 12. | 12 | ©2018 The MITRE Corporation. All rights reserved. Adversary Emulation AKA: Threat-based Red Teaming Adversary Emulation – Emulate the techniques of an adversary that’s most likely to target your environment – Focus on the behaviors of those techniques instead of specific implementations Approved for public release. Distribution unlimited 18-0944-5 https://giphy.com/explore/hackerman https://tenor.com/view/hackerman-transformation-kung-fury-kung-fury-gif-7263543
- 13. | 13 | ©2018 The MITRE Corporation. All rights reserved. Adversary Emulation with ATT&CK Prototype APT3 emulation plan on attack.mitre.org Approved for public release. Distribution unlimited 18-0944-5
- 14. | 14 | ©2018 The MITRE Corporation. All rights reserved. Test Components: – Amount of time for the emulation – Threat Intelligence Extract Actionable Techniques Extract adversary MO – Tools Determine capability to emulate Constraining the Test Intel Technical Capability Length of Test ATT&CK Techniques in Scope (Partial Matrix – APT3) Approved for public release. Distribution unlimited 18-0944-5
- 15. | 15 | ©2018 The MITRE Corporation. All rights reserved. Developing an Emulation Plan Threat Intelligence Acquisition Extract Actionable Techniques and Analyze M.O. Develop Tools Setup Infrastructure Emulate Adversary Approved for public release. Distribution unlimited 18-0944-5
- 16. | 16 | ©2018 The MITRE Corporation. All rights reserved. Developing an Emulation Plan Detail ATT&CK Tactics, Techniques, and flow Approved for public release. Distribution unlimited 18-0944-5
- 17. | 17 | ©2018 The MITRE Corporation. All rights reserved. Developing an Emulation Plan Threat Intelligence Acquisition Extract Actionable Techniques and Analyze M.O. Develop Tools Setup Infrastructure Emulate Adversary What are the COTS / Open Source tools available? Can you exhibit the right behaviors with these tools? – Can you extend them? – Can you modify them? Do you need to develop something specific? – Delivery mechanisms – Command and Control – Capabilities Approved for public release. Distribution unlimited 18-0944-5
- 18. | 18 | ©2018 The MITRE Corporation. All rights reserved. Adversary Emulation Field Manual Discovery groups net localgroup administrators net group "Domain Admins" /domain dsquery group users net user net user /domain wmic user processes tasklist qprocess * Permutations bolster effectiveness of behavior-based defensive analytics and mission capabilities Provides multiple implementations across toolsets Provides offensive command-line examples Approved for public release. Distribution unlimited 18-0944-5
- 19. | 19 | ©2018 The MITRE Corporation. All rights reserved. Developing an Emulation Plan Threat Intelligence Acquisition Extract Actionable Techniques and Analyze M.O. Develop Tools Setup Infrastructure Emulate Adversary Adjust generic plan for your environment – Is defense aware there will be red activity? Is it a Purple Team? Who are the in-scope users and boxes? Setup offensive infrastructure – Command and Control server(s), redirector(s), create payloads, buy domains, test techniques, install offensive frameworks Emulate Adversary – Don’t use known IoCs! Force detections on behavior not prior IOCs or signatured tools Approved for public release. Distribution unlimited 18-0944-5
- 20. | 20 | ©2018 The MITRE Corporation. All rights reserved. An Initial Capability Matrix for Planning Green - at least one implementation tested and detected Grey - technique in scope, but not tested Yellow - tested and weren't detected, but data collected Red - sensor gaps Approved for public release. Distribution unlimited 18-0944-5
- 21. | 21 | ©2018 The MITRE Corporation. All rights reserved. Update analytic or defensive configuration Use different implementation of same ATT&CK technique The Road to Success Approved for public release. Distribution unlimited 18-0944-5
- 22. | 22 | ©2018 The MITRE Corporation. All rights reserved. Benefits of Adversary Emulation Red gets: – Cheat sheet of many technique implementations – OPSEC considerations per implementation Blue gets: – Defensive playbook of how to detect ATT&CK technique behaviors – More data points for creating/refining analytics Both get: – A better understanding of how techniques work – An offensive and defensive perspective on how to solve problems – Faster solution to problems Approved for public release. Distribution unlimited 18-0944-5
- 23. | 23 | ©2018 The MITRE Corporation. All rights reserved. Providing a Starting Point for Red/Blue To kickstart the process for Red/Blue teams everywhere, MITRE is providing two prototypes APT3 and APT29 – All based on open-source intelligence – Breakdowns of APT tools and capabilities mapped to ATT&CK – Descriptions of how these techniques are implemented – Potential operator flows during emulations – Cheat Sheets of commands across Live off the Land binaries/scripts Open source tools Commercial toolkits APT3 is on attack.mitre.org now APT29 is Coming Soon™ Approved for public release. Distribution unlimited 18-0944-5
- 24. | 24 | ©2018 The MITRE Corporation. All rights reserved. Contact Us Chris - @ckorban, ckorban@mitre.org Cody - @its_a_feature_, cbthomas@mitre.org ATT&CK – https://attack.mitre.org – @MITREattack ATT&CK Navigator – https://github.com/mitre/attack-navigator – https://mitre.github.io/attack-navigator/enterprise/ Adversary Emulation Plans – https://attack.mitre.org/wiki/Adversary_Emulation_Plans Approved for public release. Distribution unlimited 18-0944-5
- 25. | 25 | ©2018 The MITRE Corporation. All rights reserved. MITRE is a not-for-profit organization whose sole focus is to operate federally funded research and development centers, or FFRDCs. Independent and objective, we take on some of our nation's—and the world’s—most critical challenges and provide innovative, practical solutions. Learn and share more about MITRE, FFRDCs, and our unique value at www.mitre.org
Editor's Notes
- #6 So, what can we do to address all of the issues Chris pointed out? We can start doing more purple teaming. What is purple teaming? Red and blue are working together for the same goal - making a network more secure. This ‘win/lose’ mentality between red and blue causes a lot of strife, without any benefit. Blue tries to keep red in the dark (security through obscurity), and red reports vague findings so they can make sure they ‘win’ again next year. You need both sides of the picture (red and blue) to make a really effective defense, so there needs to be benefits for a heightened level of transparency. So, what does this new cycle look like?
- #7 Red and blue need to be working together more often throughout the security process. For an internal red team, this blending of efforts can happen every stage of the way. For an external red team though, this most likely means an extra week or so at the end of an engagement to sit down with the blue team and have a mini purple team We do a similar process for development - unit testing of code. We tend to not do this for operations though. The best time to have red input into defenses is in design! The main process for purple teaming through is that it’s a quick, iterative, and collaborative workflow that benefits most from blending all parts of red and blue, but can be done at any portion. As red and blue start working more closely together, they need a common way to talk about things that’s one step above Windows Event IDs and command lines.
- #8 What is needed for this kind of language to work well for purple teaming? It means that red and blue need to be able to communicate effectively to articulate what happened in a test and the results It means that there needs to be a way to talk about what was done during a test so that it’s repeatable And it means that the language needs some way to measure improvement between tests
- #9 We like to use ATT&CK for purple teaming. ATT&CK is Adversary Tactics, Techniques, and Common Knowledge We have a small sample of it here. There are currently 11 Tactics across the top - each one refers to a ‘goal’ of the attacker. This equates to the reason why an attacker is doing any given technique. Down each column are different techniques that achieve that tactic. These techniques equate to what the adversary is doing (creating services, using WMI for persistence, dumping credentials, etc). If you just glance across the different techniques we have listed, you’ll notice something start to jump out - these are descriptions of adversary behaviors, not indicators of compromise. The same holds true for the information we capture about different threat groups on ATT&CK - we tie everything back to behaviors. We focus on adversary TTPs and behaviors because that’s the hardest thing for an adversary to change.
- #10 If you look at David Bianco’s pyramid of pain, you’ll see that it’s trivial for an adversary to change IoCs (like IP addresses, domain names, file names, hashes, etc), a bit harder for them to change tooling (but still feasible), but becomes a lot harder to change how they operate (their TTPs). If we dive into the details for a given technique … (next slide)
- #11 We get something like this. There’s a few main sections here across this slide and the next one. There’s a high level description of the technique (what it does normally and how it’s abused by the attacker). There are examples of how we’ve seen this technique used in the wild. This is an important one because ATT&CK focuses on techniques that are actually seen in use by adversaries in the wild (and cited to their respective threat intel reports). There are a few exceptions to this of course (hence the ‘Common Knowledge’) part of ATT&CK. Some techniques are known to be used by Red Teams but for some reason or another, we haven’t seen in threat intel reports. So, in an effort to make sure we’re providing the most useful information, we do include some techniques that are not backed by threat intel yet. On the right hand side you’ll see some tactic-specific information such as what the permissions are before/after executing the technique or which defenses are being evaded. On the next slide …
- #12 We include mitigations and detections opportunities for each technique. We try to refrain from mentioning specific vendor tools, and instead try to talk to the broader capabilities that are needed for mitigation and detection.
- #13 Ok, so we talked about a common language to use, but ATT&CK is getting pretty big! We’ve scoped the realm of the possible down to the realm of the probable, but can we start to prioritize a bit more from there? We sure can! This is where we start doing Adversary Emulation, or sometimes called Threat-based Red Teaming. In our case, we don’t want to just look like advanced adversaries, we want to look like a very specific adversary. We want to look like the adversary you’re most likely going to face (based on your industry, your company, your past incidents, etc) so that we can prioritize working on defenses for those techniques first. Remember, this is a prioritization mechanism to help frame where you should start working on defenses and forcing your offense and defense to work together to build stronger behavior-based defensive measures. Ok, this is cool, but how can I do this adversary emulation thing you describe?
- #14 We like ATT&CK, so we do this adversary emulation thing with ATT&CK (and we already have one example here for you). More emulation plans to come, and we welcome all community additions or edits to the emulation plans (email attack@mitre.org)
- #15 As with lots of red teaming work, part of the initial process is a rules of engagement. Adversary emulation is no exception. We also are scoping what we’re able to do by a few different variables: How much time is allotted for the test. This can of course dictate how many techniques you’re able to use Threat intelligence abundance/quality. If you can’t get the threat intel to determine which category of actors are likely to target you or what kinds of techniques they use, it’ll be hard to prioritize defenses in this way. And lastly is capability. It’s entirely possible that the adversary you’re wanting to emulate is too sophisticated for you to emulate without a lot of development. You might be thinking: “I’m hamstrung from doing technique X, which would get me Domain Admin. That’s not realistic, right?” Remember why we’re doing this. We want red and blue working together to solve a shared problem. We’re using red to help scope blue. We’re prioritizing which defenses we bolster first based on prior threat intelligence. This does not guarantee that you’ll be protected from all APTX in the future. This is looking at a snapshot in time in the past, and even that can be muddied a bit based on the quality of your threat intel. However, the prioritization is still extremely useful. This also helps with a coherent story for what defenders are spending money on and can help mitigate that ‘shiny object’ syndrome from higher level management. You might be wondering though, how do I go about this whole process?
- #16 The two big pieces of developing an adversary emulation plan are getting the threat intel and then getting the right data from that intel. For our emulation plans, since we wanted to make sure we could release them to the public, we stuck exclusively to open source data. We scoured public threat intel feeds and used some google-fu to get a big list of reports relating to APT3. Part of this involves pulling threads, so we also looked for campaigns tied to APT3 and reports on APT3’s tooling (even if they don’t call out APT3 by name) From here, we mapped APT3’s techniques and the capabilities of their tools to ATT&CK. If they had a capability that wasn’t in ATT&CK, we added it. After reading all of these reports, we were able to come up with a general MO for APT3 and a phased approach to emulating them on a network. What you see here is the phased approach to our emulation prototype that tries to keep everything generally at the ATT&CK Tactic level After you get this information …
- #17 You can take it one step further and start providing a possible ordering to techniques. Unfortunately, due to the kind of threat intel reports that are out there and when IR teams tend to get called in, there is some information that’s just not captured. We do our best to fill in these gaps just based on prior red teaming and threat intel reporting knowledge. With this, we come up with a possible technique flow (on the right). Our mapping of tool capabilities to ATT&CK techniques is here on the left. You can also see that for the sake of helping operators and defenders, we take this one step further and provide examples of doing the same ATT&CK technique with built-in commands, cobalt strike commands, and Metasploit. There are of course a lot of different frameworks that can be leveraged and a lot of different implementations of how to do these ATT&CK behaviors, but at this stage, we keep it light weight.
- #18 Now that you have an idea for the kinds of things that the adversary is capable of, you need to determine if you can do it as well. This involves looking through open source and commercial tools to see if they have the capabilities (natively or with some configuration/scripting) to do the same ATT&CK techniques as your adversary. Sometimes this is easy, but other times the technique you’re trying to emulate is extremely specific. In these cases, you might have to create your own tool. You need some diversity in this area because you want to make sure that the defense isn’t signaturing your tool or the way your tool works instead of detecting the malicious behavior.
- #19 An artifact of going through these phases is the creation of an adversary emulation field manual for the adversary you’re targeting. This breaks out very specific command lines, scripts, and tooling configurations needed to do the ATT&CK techniques you selected. This is where you start breaking out many different implementations for ATT&CK techniques to hone in on the behavior of what’s bad instead of tailoring a defense to a single implementation. The goal would be that you can even get more junior red teamers or even defenders able to pick up the field manual and start operating for testing purposes.
- #20 At this point, you’re almost ready to actually emulate the adversary on the network. You need to adjust your generic APTX emulation plan to match any restrictions placed on the engagement, and you need to setup your offensive infrastructure to match your emulation plans. When adjusting your emulation plan is where you’ll take into account this specific “rules of engagement” which will limit target users, machines, groups, etc. When you start using tools for the evaluation, remember to change the defaults!
- #21 Ok, so you emulated an adversary for a customer (or internally). Now what? What was the output of that? Remember, this is a prioritization mechanism. You can get a planning matrix like the one above. Clearly this matrix doesn’t include enough information to really tell a defender what exactly is detected, what the alerts were based on, if IoCs were involved, or anything beyond a very high level planning view. Once we start diving into this, you’ll see that there are actually many other dimensions to this that take into account the specific implementations that were used, how robust the detections/mitigations were, how noisy the collection is, etc. This planning aid’s application is described in the next slide …
- #22 This is where we go from adversary emulation to purple teaming (it’s a blurry line). Now that you have some, high level idea of what your coverage is for the subset of techniques that adversary uses, it’s time to dig into them a bit more. This is something you’ll do for all colors of the matrix, but probably prioritized red, yellow, green, grey (yes, even green). The real purple teaming cycle comes into effect to start throwing many different implementations at the defenses to see what all is detected, what isn’t, why, how that can be updated, and continue trying. When do you stop? No guaranteed stop point. Are you ever 100% sure you detect all possible implementations of a behavior? You can get to a point where you’re confident you detect it and accept the risk for not doing more testing.