Why we love threat emulation exercises (and how to get started with one of your own)

Tips · 8 MIN READ · JON HENCINSKI · FEB 5, 2019 · TAGS: Get technical / Guide / How to / Security Incident / SOC

In early 2017, I joined Expel and set out on a journey to build a team of analysts who could deliver transparent managed security services 24 hours a day seven days a week, using a wide range of network, endpoint and SIEM technologies. That might sound like a fairly easy task (heck, there are plenty of computer science and engineering grads out there, right?) but if recent headlines are any indication, building a great security team and helping them grow stronger together isn’t all that simple.

TL;DR: Pulling a team of talented individuals together is just the first step in creating a great Security Operations Center (SOC). As a manager, I knew I had to build an environment that keeps the team sharp and constantly helps us improve as a group.

So how, exactly, can a manager help his or her team improve?

Allow me to introduce you to threat emulation.

If it’s still early in your cybersecurity career or your team doesn’t have lots of incident response practice under their belt (yet!), this is the best way that you can help them flex those response muscles and improve your collective detection skills.

What exactly is threat emulation?

Threat emulation is the process of simulating a realistic threat you’re likely to encounter with a heavy emphasis on what happens after an attacker breaks in. The purpose of threat emulation is to focus on analysis. It’s a “get better by doing” approach.

Threat emulation isn’t a new concept. Just ask Mark Kikta, Dave Kennedy or Raphael Mudge.

One of the (many) things that makes Expel unique is that we integrate with the security technologies our customers already use. And we do this for our customers who are running their data centers on-prem as well as for those who run apps and infrastructure in the cloud. So emulating threats is a big part of our training strategy because it helps our team gain experience detecting and responding to new attacker techniques using all of the different security products that we support.

Five steps for getting started with your own threat emulation exercise

If you’re looking to run your own threat emulation exercise, the possibilities are limitless. So where do you start?

Here are a couple ideas to get your (cybersecurity) wheels turning.

You could get your team started by running PSEXEC to establish a reverse Windows command shell on a host joined to the domain. Then, you could execute commands to enumerate domain trusts. Or perhaps you could remotely execute the built-in Windows calculator “calc.exe” on a server joined to the domain via Windows Management Instrumentation (WMI).

Do you have a few scenarios of your own now?

Awesome.

Here are five steps to get started with planning your first threat emulation exercise.

Before you start planning, think about your team’s current capabilities. Do you have analysts on the team who haven’t encountered an attacker moving laterally throughout a Windows AD domain? They’ve yet to acquire a Windows Security event log and timeline Type 3 network logons during known periods of attacker activity? Or maybe they know about attacks, but haven’t experienced the emotions associated with chasing bad guys active in an environment? No problem. Start small and keep things simple.

Or do your people have experience working in and leading enterprise incident response? Do they know how to parse shell bags and grab a copy of “default.rdp” when tracking lateral movement via remote desktop sessions? Do you have analysts who know the difference between the Shim Cache and AmCache? Sweet. Then you’ll want to dial up the complexity.

Understanding where the team’s capabilities are today will help you create the right set of threat emulation exercises to help the group improve.

You may be wondering if this blog post was written by Captain Obvious, but hear me out: creating a plan and appropriate goals is a step in your process that shouldn’t be overlooked. For example, I usually map out my team’s threat emulation exercises using the MITRE ATT&CK™ framework and provide this information to our SOC analysts a few days before the event. This allows our analysts to research and practice a bit beforehand. Also, if you’re like me and run a 24×7 team with multiple shifts, you’ll need to simulate the same incident more than once — and having a plan guarantees consistency across exercises.

Here’s a quick summary of a recent threat emulation exercise plan I created:

Scenario: The attacker gains access to a Windows 7 computer via a weaponized Microsoft Excel spreadsheet, performs some initial recon, elevates privileges using a technique to bypass UAC, steals credentials using Mimikatz, establishes persistence and then moves around the network using stolen credentials to find sensitive data and deploy additional malware.

Creating goals based on your plan is just as important as having the plan. Where do you expect to see growth? Is this the first time a SOC analyst is detecting and responding to domain fronting? Or do you want your people to gain experience detecting and responding to evidence of privilege escalation?

Here are the goals I set for my team in the above exercise: I wanted the team to know why it’s so important to understand why an attacker has to move from a medium integrity to a high-integrity context. Without that ability to escalate, the attacker can’t use Mimikatz, can’t recover password hashes and is significantly limited in actions they can take on a target.

Building a threat emulation exercise requires more than just standing up infrastructure. I think about this step of the process in three distinct parts:

Build believable infrastructure

The first order of business is architecting the environment. If you’ve got authorization to emulate threats on your corporate network, that’s great. You can also use AWS and Ravello to host the infrastructure (that’s what we do here at Expel). Pro tip: There are plenty of resources online that explain how to build a cloud-based security lab.

It’s important to make the environment look and feel like the actual environment you’re protecting. For example, if you’re building a Windows Active Directory domain, we recommend creating realistic user accounts and applying similar group policy objects. When deploying your security tech, make sure servers and agents are configured the same as those running in your enterprise.

From an offensive perspective, Cobalt Strike is the backbone of our threat emulation capability. Cobalt Strike’s post-exploitation BEACON agent and its malleable command and control (C2) profiles allow us to mimic lots of different threats. If you’re looking for free options to get started, try PowerShell Empire and the Metasploit Framework (check out the METERPRETER payload).

The sample environment we built in Ravello consists of a small Windows Active Directory domain named “Evil Corp,” a mix of workstations and servers joined to the domain, realistic user accounts, multiple endpoint and network security technologies, a Nagios box for monitoring and two Linux Kali virtual machines running Cobalt Strike. The box labeled “Assembler” is the virtual appliance we’ve built at Expel that allows us to integrate with the technology our customers use. So deploying an Assembler in this environment allows our SOC analysts to respond using Expel Workbench in conjunction with the tech the customers are already using.

Make it feel real!

Create a storyline that’s realistic enough for you to share with your team.Craft something that could happen to one of your customers, or maybe replay a previous incident so the entire team can learn from the experience.

Here’s an example:

A targeted threat group has breached Evil Corp! Their objective is to identify and steal intellectual property about a new widget scheduled for release later this year. If the data is lost, the company will be at risk.

Your team’s objective would then be: Identify the source, scope and timing of attacker activity and provide remediation recommendations intended to remove the attacker’s access to the Evil Corp environment.

We’ll need an initial lead as a starting point.

Something like:

On January 30, 2019, between 17:30 and 17:50 UTC, an Evil Corp network administrator reported suspicious login activity on ECIADSV5, an Internet-facing Linux web server running Apache Tomcat. They also identified a Darktrace alert for suspicious HTTP POST requests during this timeframe.

Finally, consider your operational model.

When an incident occurs, how does your team communicate status and next steps? Do you communicate with external customers or is your focus entirely internal? Do you expect key stakeholders to call a 1-800 number for status updates? Consider all of these factors when you build the threat emulation.

For example, you could have another colleague who’s not on your team call your security operations 1-800 number and ask for a status update during the simulation.

Bonus: Here’s a script you can steal and use for this part.

Hi, this is Jon from EVIL CORP. I’m hoping to get a quick update about the ongoing incident.

1. What’s the current scope?
2. Do we know the initial entry point into the organization yet?
3. Do we know what domains or external IP addresses the attacker is using for command and control?
4. Anything I can be doing right now to reduce risk for my organization?

Communication has to be part of the simulation. Your team will get experience communicating statuses in high pressure situations and they’ll thank you for it later.

Define your deliverables

This is another area where you’ll want to consider your operational model. Do you report and track incidents through a ticketing system? Or do you provide incident “findings” reports via a customer portal? If you’re just getting started, follow your existing processes. It’s a good stress test.

Later on, consider adding a Google Form where you can ask questions that are more focused on an investigative concept. Asking questions is a really great way to teach. For example, if the team is new to tracking lateral movement, ask questions that will shape how the team thinks about and responds to that activity. Here are some sample questions along with a sample Google Form to get you started.

1. What account did the attacker use to move laterally from ECIADWS2 to EVILCORPSERVER?
2. How did the attacker move laterally from ECIADWS2 to EVILCORPSERVER?
3. The attacker mounted the C$ share on EVILCORPSERVER. What logon type would this activity generate?
4. Did the attacker mount the ADMIN$ share on EVILCORPSERVER?
5. The ADMIN$ share is linked to what path on Windows?
6. The attacker authenticated to EVILCORPSERVER from ECIADWS2 under the context of a different account. What logon type would this activity generate?
7. How did the attacker infect EVILCORPSERVER?

Now it’s go time! With your plan in hand, infrastructure at the ready and expectations set for communications and deliverables, you’re ready to bring it all together and run your threat emulation exercise. Schedule time with the team and run them through it. If you run a 24X7 team, we’ve found that nights and weekends at the start of any shift work best.

Don’t forget to collect feedback once your exercise wraps. It lets you know if the team thinks it’s a good use of their time and if they’re growing as a result. It also allows you as a manager to get ideas on how you can improve future exercises.

The first few times you run a threat emulation it will be obvious where you need to improve. Things will break or you won’t have a backup plan or you’ll receive feedback that something was confusing. That’s okay. Learn from those surprises. Not only does threat emulation planning get easier with practice, but it’ll also improve your team’s agility and response time — all of which help when something really does go wrong.

Here’s what I’ve learned from running threat emulation exercises with my team:

• Less is more. Most exercises don’t need to be overly difficult.
• Build it once but use it again (and again). Reuse infrastructure. When you make a change, take a snapshot.
• Make it feel real. Generate legitimate network traffic and user activity before you emulate the threat.
• Encourage teamwork and collaboration. You want your people to succeed!

Better security teams = happy customers

Threat emulation exercises are a great way to create experiences for your SOC analysts. Don’t just wait for bad things to happen, make them happen. It’ll make your team better, faster and stronger.

Emulating threats is also a great way to improve your detection capability. Thought you’d have more alerting when the threat emulator dumped credentials with MIMIKATZ and then moved laterally via WinRm to the PDC? Or maybe you want to answer a “what if” question like, “What if we enabled PowerShell constrained language mode?”

Is your team ready for surprises like that?

There’s only one way to find out. And as the old saying goes, “practice makes perfect.”