There are a lot of people who talk about threat emulation. Use our super-duper-elitesy-neatsy-malware to emulate these tactics in your network. I say stuff like that too. It’s cool. In this post, I’d like to write about what threat emulation means to me, really.

I see a red teams as offensive operators capable of executing attacks as an advanced representative actor. By representative actor, I mean one that may have similar sophistication to what their customer faces day-to-day, but the actions of the red team are solely theirs. The red team has their own tradecraft, their own process, and their own way of doing things. They’re not really emulating anyone else [although, like all good offensive actors, they’re happy to blatantly borrow what works from others].

What is the value of these red team operations? I covered this topic in Models for Red Team Operations. I see red teams provide a lot of value when they work to exercise a security process in a comprehensive way.

So far, we’ve established: a red team is a representative actor. Fine. What’s a threat emulator then? A threat emulator is an offensive operator who emulates a specific threat in a network. What is the value of a specific threat over a representative threat? Analysis. As a representative actor, there’s little room to exercise and evaluate a training audience’s ability to analyze the incident, tie it to threat intelligence, and possibly cross-share it with others. If a team emulates a specific actor, ideally, there’s a wealth of information for incident response teams to draw on to better inform their actions and drive their process.

If threat emulation is emulating a specific threat AND the purpose behind this is to exercise analysis, then what is the threat emulation problem?

The threat emulation problem is fooling an analyst into believing they’re dealing with a real-world actor during a simulated incident.

There are a lot of approaches to this problem. One approach is to use the actor’s malware when it’s available. Another approach is to dress up a payload to have indicators that are similar to the emulated actor’s malware. This is the approach Cobalt Strike takes with its Malleable C2 technology.

I’ve had an interest in the Threat Emulation problem for a while. Here are a few resources on it:

If you’d like to learn more about Threat Emulation with Cobalt Strike, take a look at Puttering my Panda and Other Threat Replication Case Studies. This blog post shows how to dissect a threat intelligence report and use Cobalt Strike to emulate targeted attacks and indicators from three actors.

If you’d like to learn more about the Threat Emulation problem set, watch 2014’s Hacking to Get Caught. In this talk I discuss what it means to emulate a threat during a red team assessment. I go through approaches other than my own. I then discuss my thoughts on the Threat Emulation problem and potential solutions. This talk pre-dates the release of Malleable C2.

If you’d like thoughts on how Threat Emulation fits into the broader shifts taking place in our industry, watch 2015’s Hacking to Get Caught talk. The content of this talk is different from the 2014 talk. Hacking to Get Caught discusses Adversary Simulations, Cyber Security Exercises, and a trend towards using offensive assets to test and evaluate security operations. I see Threat Emulation as a way to exercise analysis (when that’s the goal). You may also want to look at Raphael’s Magic Quadrant. This blog post summarizes my thoughts on these broad shifts.

BlackHat is about to start in a few days. I think this is an appropriate time to share a non-technical, business only post.

There is a new market for offensive tools and services. Our trade press doesn’t write about it yet. I don’t believe industry analysts have caught onto these ideas yet. The leaders behind mature security programs have converged on these ideas, in isolation of each other. I see several forward-thinking consulting firms aligning in this direction as well. I also see movement towards these ideas in a variety of sectors. This isn’t limited to banks, the government, or the military.

The Sword that Hones the Shield

Today’s market for penetration testing software and services is driven by a need to find vulnerabilities in a network and build a prioritized list of things to fix to make it safe. The services and tools in this market reflect this problem set.

What happens when an attacker gets in? It happens, even in the most well maintained networks. At this point all is not lost. This is where security operations comes in. This is the part of a security program designed to detect and respond to an intrusion before it becomes a major incident.

Security Operations is a big investment. There is no lack of devices on the market that promise to stop the APT or detect 99.9% of malware that the vendor tested. When a breach happens, in the presence of these devices, the vendor usually claims the customer didn’t use their magical dust correctly. These devices are all very expensive.

Beyond the devices comes the monitoring staff. These are the folks who watch the APT boxes and other sensors to determine if there is malicious activity on their network. Some organizations outsource this to a Managed Security Services Provider. Others have an in-house staff to do this. Either way, this is an on-going cost that organizations pay to protect their business if an intrusion occurs.

Security Operations is not just passive monitoring. At the high end of the market, security operations also involves highly skilled analysts who deploy agents that collect details about user and process behavior that were previously unavailable. These agents generate a lot of data. The collection, processing, and analysis of this data is difficult to do at scale. Because of this, these analysts usually instrument systems and investigate when another form of monitoring tips them off. These highly skilled analysts have the task to find signs of an intrusion, understand it in full, and develop a strategy to delay the actor until they know the best way to remove the actor from their network altogether. This is often called Hunt.

If an organization invests into security operations in any way, they have an obligation to validate that investment and make sure these parts of their security program work. This problem set is the driver behind this new market for offensive services and tools.

Adversary Simulations

The new service I speak of has a number of names. Adversary Simulation is one name. Threat Emulation is another. Red Team-lite is a term my friends and I use to joke about it. The concept is the same. An offensive professional exercises security operations by simulating an adversary’s actions.

In these engagements, how the attacker got in doesn’t matter as much. Every step of the attacker’s process is an opportunity for security operations staff to detect and respond to the intruder. Some engagements might emulate the initial steps an attacker takes after a breach. These initial steps to escalate privileges and take over the domain are worthwhile opportunities to catch an attacker. Other engagements might emulate an attacker who owns the domain and has had a presence on the network for years. The nice thing about this model is each of these engagements are scoped to exercise and train security operations staff on a specific type of incident.

I’ve written about Adversary Simulations before. I’ve also spoken about them a few times. My recent updated thoughts were shared at Converge in Detroit a few weeks go:

Adversary Simulations focus on a different part of the offensive process than most penetration tests. Penetration Tests tend to focus on access with a yelp for joy when shell is gained. Adversary Simulations focus almost entirely on post-exploitation, lateral movement, and persistence.

The tool needs for Adversary Simulations are far different. A novel covert channel matters far more than an unpatched exploit. A common element of Adversary Simulations is a white box assume breach model. Just as often as not, an Adversary Simulation starts with an assumed full domain compromise. The goal of the operator is to use this access to achieve effects and steal data in ways that help exercise and prepare the security operations staff for what they’re really up against.

Adversary Simulation Tools

What tools can you use to perform Adversary Simulations? You can build your own. PowerShell is a common platform to build custom remote access tools on an engagement by engagement basis. Microsoft’s red team follows this approach. One of my favorite talks: No Tools, No Problem: Building a Custom Botnet in PowerShell (Chris Campbell, 2012) goes through this step-by-step.

Cobalt Strike’s Beacon has shown itself as an effective Adversary Simulation tool. My initial focus on the needs of high-end red teams and experience with red vs. blue exercises has forced me to evolve a toolset that offers asynchronous post-exploitation and covert communication flexibility. For example, Malleable C2 gives Beacon the flexibility to represent multiple toolsets/actors in one engagement. Beacon Operators rely on native tools for most of their post-exploitation tasks. This approach lends itself well to emulating a quiet advanced threat actor. Cobalt Strike 3.0 will double down on this approach:

Immunity has their Innuendo tool. I’ve kept my eye on Innuendo since Immunity’s first announcement. Innuendo is an extensible post-exploitation agent designed to emulate the post-intrusion steps of an advanced adversary with an emphasis on covert channels. Innuendo is as much a post-exploitation development framework as it is a remote access tool. Immunity also offers an Adversary Simulation service. I’m convinced, at this point, that Immunity sees this market in a way that is similar to how I see it.

One of the company’s doing a lot to push red team tradecraft into penetration tests is the Veris Group. Will Schroeder has done a lot in the offensive powershell space to support the needs of red team operators. The things Will works on don’t come from a brainstorming session. They’re the hard needs of the engagements he works on. At B-Sides Las Vegas, he and his colleague Justin Warner will release a post-exploitation agent called Empire. This isn’t yet-another-powershell post-exploitation agent. It’s documented, polished, AND it builds on some novel work to run PowerShell in an unmanaged process. This talk was rejected by other conferences and I believe the conference organizers made a mistake here. Empire is the foundation of a well thought out Adversary Simulation tool.

You’ll notice that I talk a lot about the playing field of Adversary Simulation tools today. I think each of these options is a beginning, at best. We as an industry have a long ways to go to support the needs to make professional Adversary Simulations safe, repeatable, and useful for the customers that buy them.

Adversary Simulation Training

The tools for Adversary Simulation are coming. The tools alone are not the story. Adversary Simulations require more than good tools, they require good operators.

A good Adversary Simulation Operator is one who understands system administration concepts very well. Regardless of toolset, many Adversary Simulation Tasks are do-able with tools built into the operating system.

A good Adversary Simulation Operator is also one who understands what their actions look like to a sensor and they appreciate which points a sensor has to observe and alert on their action. This offense-in-depth mindset is key to evade defenses and execute a challenging scenario.

Finally, Adversary Simulations require an appreciation for Tradecraft that simply isn’t there in the penetration testing community yet. Tradecraft are the best practices of a modern Adversary. What is the adversary’s playbook? What checklists do they follow? Why do they do the things they do?

I see some of my peers dismiss foreign intelligence services as script kiddies, equal to or beneath penetration testers in capability. This makes me cringe. This hubris is not the way forward for effective Adversary Simulations. Adversary Simulations will require professionals with an open mind and an appreciation for other models of offense.

Right now, the best source of information on Tradecraft is the narrative portion of well written and informed Threat Intelligence reports. A good Adversary Simulation Operator will know how to read a good report, speculate about the adversary’s process, and design an operating concept that emulates that process. CrowdStrike’s Adversary Tricks and Treats blog post is an example of a good narrative. Kaspersky’s report on Duqu 2.0 also captures a lot of key details about how the actor does lateral movement and persistence. For example, the actor that operates with Duqu 2.0 uses MSI packages kicked off with schtasks for lateral movement. Why would this quiet advanced actor do this? What’s the benefit to them? A good Adversary Simulation Operator will ask these questions, come to their own conclusions, and figure out how to emulate these actions in their customer’s networks. These steps will help their customers get better at developing mitigations and detection strategies that work.

Adversary Simulations are not Penetration Testing. There’s some overlap in the skills necessary, but it’s smaller than most might think. For Adversary Simulations to really mature as a service, we will need training classes that emphasize post-exploitation, system administration, and how to digest Threat Intelligence reports. Right now, the courses meant for high-end red teams are the best options.

Adversary Simulation Services

Adversary Simulation Services [someone pick a better acronym] are driven by the need to validate and improve Security Operations. This isn’t a mature-organization-only problem. If an organization is mature enough to hire external security consultants for vulnerability assessments AND the organization invests in security operations, they will benefit from some service that validates or enhances this investment.

What makes Adversary Simulation interesting is it’s an opportunity for a consulting firm to specialize and use their strengths.

If you work for a threat intelligence company, Adversary Simulations are your opportunity to use that Threat Intelligence to develop and execute scenarios to validate and improve your customer’s use of the Threat Intelligence you sell them. iSight Partners is on the cutting edge of this right now. It’s so cutting edge, they haven’t even updated their site to describe this service yet. Their concept is similar to how I described an Aggressor at ShowMeCon in May 2014:

If you’re a penetration testing company that focuses on SCADA; you have an opportunity to develop scenarios that match situations unique to your customers and sell them as a service that others outside your niche can’t offer.

Some organizations outsource most of their security operations to a third-party provider. That’s fine. If you work with these organizations, you can still sell services to help your customers validate this investment. Look into MI SEC’s Security Exercise model and come up with scenarios that take one to two days of customer time to execute and give feedback.

If you’re an organization on the high-end working to build a hunt capability–Adversary Simulation is important to you too. You can’t just deploy Hunt Operators and assume they’re ready to tackle the scariest APT out there. An Adversary Simulation Team can play as the scrimmage team to train and evaluate your Hunt capability.

For any organization that you work with, an Adversary Simulation is an opportunity to offer them new services to validate their security operations. There are different models for Adversary Simulations. Each of these models is a fit for different organizational maturity levels.

I predict that Adversary Simulations will become the bulk of the Penetration Testing services and tools market in the future. Now’s a good time to help define it.

A friend recently made the statement that my blog posts have so many videos and links that it would take someone a week to go through all of the material. This comment was made in reference to the blog post exploring the Adversary Simulation space. This topic is near and dear to my heart, so I’d like to dissect the links and videos in the post and why I think they’re worthwhile for you to read.

Why do we need Adversary Simulation?

Penetration Testing with Honest-to-Goodness Malware [DarkReading.com]

This commentary by Gunter Ollmann describes penetration testing as a service with some value, but one that does not reflect its origin: emulating the adversary’s techniques. Maybe the advanced adversary uses Nessus from the target’s conference room and we’re both wrong? Who knows. I like this article because it discusses why adversary emulation is important, it makes a fair argument about why pen testing [still valuable] isn’t a substitute for this, and it proposes a solution to the problem.

Purple Teaming for Success [SecureIdeas]

Kevin Johnson and James Jardine took the time to put together a blog post and webcast that describes their take on purple teaming. I’m not a fan of the term purple teaming and I see it as overbroad, but Kevin and James provide good arguments about why new models for red and blue to work together make sense without prescribing a solution that’s more of the same old pen tester stuff.

How do I see Adversary Simulations?

Puttering my Panda and Other Threat Replication Case Studies [Gratuitous Self-link]

As a tool developer, I look at problems like Adversary Simulations, and ask what my tools do to support these things. Cobalt Strike has some nifty technologies for Adversary Simulations. It contains several ready-to-use user-driven attacks to get a foothold. It has a phishing tool that will ingest an existing email and repurpose it into attack. And, it has Malleable C2, a technology that lets you change what its Beacon payload looks like on the wire. You can fool an analyst into thinking they’re dealing with another piece of malware. This blog post shows three case studies to reproduce tradecraft and indicators from public reports on advanced persistent threat activity.

Hacking to Get Caught: A Concept for Adversary Replication [Yeah, me me me]

This is a May 2014 talk on the Adversary Replication concept. In this talk, I work to make a case that an Adversary Simulation is Red Teaming guided by Threat Intelligence. The model I proposed is meant to exercise a customer’s process to analyze and attribute an attack. My thoughts have evolved since this talk but I think it’s still worth watching if you’re really interested in this topic.

What are my favorite Adversary Simulation references?

Red Teaming: Using Cutting-Edge Threat Simulation to Harden the Microsoft Enterprise Cloud [Microsoft.com]

This whitepaper was sent to me at 9pm the day before I published my post on Adversary Simulation. It’s awesome! Microsoft describes the same concept in their own words. Key to their approach is what they call an innovative “Assume Breach” strategy. Of everything I reference in this post, I consider this paper the most important. I recommend that you go read it.

Threat Models that Exercise Your SIEM and Incident Response [Nick Jacob]

This talk describes how to build a threat model and derive from it a story board for a quarterly cyber security exercise. Nick goes into the nitty gritty of how they work to provide the observables that support this sequence of events and give analysts something meaningful to chase. He also digs into metrics as well.

Seeing Purple: Hybrid Security Teams for the Enterprise [Mark Kikta]

This is another talk from an MISEC member that discusses the periodic cyber security exercise and how to support it. I think Mark, Nick, and Wolfgang are dead on with their insights and if I had a magical wand, everyone who works in this space would watch these talks.

A customer reaches out to you. They’ve spent the money. They have a network defense team that innovates and actively hunts for adversary activity. They own the different blinky boxes. They have a highly-rated endpoint protection in their environment. They’re worried about these cyber attacks they see in the news. Despite this investment, they don’t know how well it works. The CEO thinks they’re invincible. The CISO has his doubts and the authority and resources to act on these doubts. They want to know where their program is at. They call you.

You run through the options. You dismiss the idea of looking at their vulnerability management program. They have this and they receive penetration testers on a semi-regular basis. They’re comfortable that someone’s looking at their attack surface. They’re still worried. What about something very targeted? What if someone finds a way that they and the myriad of vendors they worked with didn’t know about.

After discussion, you get to the heart of it. They want to know how effective their network defense team is at detecting and mitigating a successful breach. The gears start to turn in your mind. You know this isn’t the time to use netcat to simulate exfiltration of data. You can download some known malicious software and run it. Or, better, you could go to one of the underground forums and pay $20 for one of the offensive showpieces available for sale. Your minded quickly flashes to a what-if scenario. What happens if you go this way and introduce a backdoor into your customer’s environment. You shake your head and promise yourself that you will look at other options later.

Wisely, you ask a few clarifying questions. You ask, what type of breach are they worried about? Of the recent high-profile breaches, what’s the one that makes them think, “could that be us?” Before you know it you’re on a plane to New York with a diverse team. You bring an offensive expert from your team, she is a cross between operator and developer. You also bring a new hire who used to work as a cyber threat analyst within the US intelligence community. You engage with the customer’s team, which includes trusted agents from the network defense team who will not tell their peers about the upcoming engagement. The meeting is spent productively developing a threat model and a timeline for a hypothetical breach.

Your customer introduces you to another player in this engagement. Your customer pays for analyst services from a well known threat intelligence company. This company is known for working intrusion response for high-profile breaches. A lesser known service is the strategic guidance, analysis support, and reports they provide their customers on a subscription basis. This analyst briefs you on a real actor with capability and intent to target a company like your customer. The hypothetical breach scenario you made with your customer is amiable to this actor’s process. The analyst briefs your team on this actor’s capabilities and unique ways of doing business. Your customer doesn’t know what they want here, but they ask if there’s a way you can use this information to make your activity more realistic, please do so.

You and your team leave the customer’s site and discuss today’s meetings with a fast energy. The customer wants to hire you to play out that hypothetical breach in their environment, but they want to do this in a cost effective way. A trusted insider will assist you with the initial access. It’s up to you to evade their blinky boxes and to work slowly. Paradoxically, the customer wants you to work slow, but they want to put a time limit on the activity as well. They’re confident that with unlimited time, you could log the right keystrokes, and locate the key resources and systems in their network. To keep the engagement tractable, they offer to assign a trusted agent to your team. This agent will white card information to allow you to move forward with the breach storyline.

The customer’s interest is the hypothetical breach and the timeline of your activity. They don’t expect their network defense team to catch every step. But, they want to know every step you took. After the engagement, they plan to analyze everything you did and look at their process and tools. They’ll ask the tough questions. How did they do? What did they see, but dismiss as benign? What didn’t they see and why? Sometimes it’s acceptable that an activity is too far below a noise threshold to catch. That’s OK. But, sometimes, there’s a detection or action opportunity they miss. It’s important to identify these and look at how to do better next time.

You look at this tall order. It’s a lot. This isn’t something your team normally does. You know you can’t just go in and execute. Your new hire with the intel background smiles. This is a big opportunity. Your developer and analyst work together to make a plan to meet the customer’s needs. Your intent is to execute the breach timeline but introduce tradecraft of the actor the threat intelligence company briefed you on. These few tricks you plan to borrow from the actor will show the customer’s team something they haven’t seen before. It will make for a good debrief later.

This engagement will require some upfront investment from your team and it may require a little retooling. You’ll need to analyze each piece of your kit and make sure it can work with the constraints of your customer’s defensive posture. You verify that you have artifacts that don’t trigger their anti-virus product. Some of the cloud anti-virus products have made trouble for your team in the past. You look at your remote access tool options. You need a payload that’s invisible to the blinky boxes and their automatic detection. If you get caught, you want to know ingenuity and analysis made it happen. You won’t give yourself up easily. At least, not in the beginning.

You also want to know that you can operate slowly. Your favorite penetration testing tools aren’t built for this. Big questions come up. How will you exfiltrate gigabytes of data, slowly and without raising alarms? You know you’ll need to build something or buy it. You also work to plan the infrastructure you’ll need to support each phase of the breach timeline. You know, for this particular engagement, it makes no sense to have all compromised systems call home to the one Kali box your company keeps in a DMZ.

As all of this planning takes place, you pause and reflect. You got into this business to make your customers better. You built a team and you convinced your management to pay them what they’re worth. You carry the weight of making sure that team is constantly engaged. Sometimes this means taking the less sexy work. Unfortunately, your competitors are on a race to the bottom. Everyone sells the same scans and vulnerability verification as penetration tests. It keeps getting worse. You know you’ll lose your best people if you try to compete with this way. This engagement brings new energy to your team.

This mature customer is willing to pay for this service. The value to them is clear. They want to know how well their security operations stands up to a real world attack. They understand that this is a task that requires expertise. They’ll pay, but they can’t and won’t pay for a long timeline. The white carding is the compromise.

You’re excited. This is something that will use the expertise you’ve collected into a cohesive team. Your customer appreciates how real the threat is. You make plans. Big plans. You wonder who else might pay for this service. You go to your sales person and brief them on the customer and this engagement. Your sales person nods in agreement. “Yes, I see it too”.

TL;DR This is my opinion on Threat Intelligence: Automated Defense using Threat Intelligence feeds is (probably) rebranded anti-virus. Threat Intelligence offers benefit when used to hunt for or design mitigations to defeat advanced adversaries. Blue teams that act on this knowledge have an advantage over that adversary and others that use similar tactics.

Threat Intelligence is one of those topics you either love to scoff at or embrace. In this post, I’ll share my hopes, dreams, and aspirations for the budding discipline of Threat Intelligence.

I define Threat Intelligence as actionable adversary-specific information to help you defend your network. There are several firms that sell threat intelligence. Each of these firms track, collect on, and produce reports and raw indicator information for multiple actors. What’s in these reports and how these companies collect their information depends on the company and the means and relationships at their disposal.

How to best get value from Threat Intelligence is up for debate and there are many theories and products to answer this question. The competing ideas surround what is actionable information and how you should use it.

Anti-virus Reborn as… Anti-virus

One theory for Threat Intelligence is to provide a feed with IP addresses, domain names, and file hashes for known bad activity. Customers subscribe to this feed, their network defense tools ingest it, and now their network is automatically safe from any actor that the Threat Intelligence provider reports on. Many technical experts scoff at this, and not without reason. This is not far off from the anti-virus model.

The above theory is NOT why I care about Threat Intelligence. My interest is driven by my admittedly skewed offensive experiences. Let me put you into my shoes for a moment…

I build hacking tools for a living. These tools get a lot of use at different Cyber Defense Exercises. Year after year, I see repeat defenders and new defenders. For some defenders, Cobalt Strike is part of their threat model. These teams know they need to defend against Cobalt Strike capability. They also know they need to defend against the Metasploit Framework, Dark Comet, and other common tools too. These tools are known. I am quick to embrace and promote alternate capabilities for this exact reason. Diversity is good for offense.

I have to live with defenders that have access to my tools. This forces me to come up with ways for my power users and I to stay ahead of smart defenders. It’s a fun game and it forces my tools to get better.

The low hanging fruit of Threat Intelligence makes little sense to me. As an attacker, I can change my IP addresses easily enough. I stand up core infrastructure, somewhere on the internet, and I use redirectors to protect my infrastructure’s location from network defenders. Redirectors are bounce servers that sit between my infrastructure and the target’s network. I also have no problem changing my hashes or the process I use to generate my executable and DLL artifacts. Cobalt Strike has thought out workflows for this.

I worry about the things that are harder to change.

Why is notepad.exe connecting to the Internet?

Each blue team will latch on to their favorite indicators. I remember one year many blue teams spoke of the notepad.exe malware. They would communicate with each other about the tendency for red team payloads to inject themselves into notepad.exe. This is a lazy indicator, originating from the Metasploit Framework and older versions of Cobalt Strike. It’s something a red operator can change, but few bother to do so. I would expect to see this type of indicator in the technical section of a Threat Intelligence report. This information would help a blue team get ahead of the red teams I worked with that year.

If you’d like to see how this is done, I recommend that you read J.J. Guy‘s case study on how to use Carbon Black to investigate this type of indicator.

Several blue teams worry about Cobalt Strike and its Beacon payload. This is my capability to replicate an advanced adversary. These teams download the trial and pick apart my tool to find indicators that they can use to find Beacon. These teams know they can’t predict my IP addresses, which attack I will use, or what file I will touch disk with. There are other ways to spot or mitigate an attacker’s favorite techniques.

DNS Command and Control

One place you can bring hurt to an attacker is their command and control. If you understand how they communicate, you can design mitigations to break this, or at least spot their activity with the fixed indicators in their communication. One of my favorite stories involves DNS.

Cobalt Strike has had a robust DNS communication capability since 2013. It’s had DNS beaconing since late 2012. This year, several repeat blue teams had strategies to find or defeat DNS C2. One team took my trial and figured out that parts of my DNS communication scheme were case sensitive. They modified their DNS server to randomly change the casing of all DNS replies and break my communication scheme.

This helped them mitigate red team activity longer than other blue teams. This is another example where information about your adversary can help. If you know there’s a critical weakness in your adversary’s toolchain, use that weakness to protect your network against it. This is not much different from spoofing a mutex value or changing a registry option to inoculate a network against a piece of malware.

This story doesn’t end there though. This team fixated on DNS and they saw it as the red team’s silver bullet. Once we proved we could use DNS, we put our efforts towards defeating the proxy restrictions each team had in place. We were eventually able to defeat this team’s proxy and we had another channel to work in their network. We used outbound HTTP requests through their restrictive proxy server to control a host and pivot to others. They were still watching for us over DNS. The lesson? Even though your Threat Intelligence offers an estimate of an adversary’s capability, don’t neglect the basics, and don’t assume that’s the way they will always hit you. A good adversary will adapt.

To Seek Out New Malware in New Processes…

After a National CCDC event, a student team revealed that they would go through each process and look for WinINet artifacts to hunt Beacon. This is beautiful on so many levels. I build technologies, like Malleable C2, to allow a red operator to customize their indicators and give my payload life, even when the payload is known by those who defend against it. This blue team came up with a non-changing indicator in my payload’s behavior. Fixed malware behavior or artifacts in memory are things a Threat Intelligence company can provide a client’s hunt team. These are tools to find the adversary.

It’s (not) always about the Malware

The red teams I work with quickly judge which teams are hard and which teams are not. We adjust our tradecraft to give harder teams a better challenge. There are a few ways we’ll do this.

Sometimes I know I can’t put malware on key servers. When this happens, I’ll try to live on the systems the defenders neglect. I then use configuration backdoors and trust relationships to keep access to the servers that are well protected. When I need to, I’ll use RDP or some other built-in tool to work with the well protected server. In this way, I get what I need without alerting the blue team to my activity. Malware on a target is not a requirement for an attacker to accomplish their goal.

CrowdStrike tracks an actor they call DEEP PANDA. This actor uses very similar tradecraft. If a blue team knew my favored tradecraft and tricks in these situations, they could instrument their tools and scripts to look for my behavior.

A few points…

You may say, that’s one adversary. What about the others? There are several ways to accomplish offensive tasks and each technique has its limitations (e.g., DNS as a channel). If you mitigate or detect a tactic, you’ll likely affect or find other adversaries that use that tactic too. If an adversary comes up with something novel and uses it in the wild, Threat Intelligence is a way to find out about it, and stay ahead of advancing adversary tradecraft. Why not let the adversary’s offensive research work for you?

You may also argue that your organization is still working on the basics. They’re not ready for this. I understand. These concepts are not for every organization. If you have a mature intrusion response capability, these are ideas about how Threat Intelligence can make it better. These concepts are a complement to, not a replacement for, the other best practices in network defense.

And…

You’ll notice that I speak favorably of Threat Intelligence and its possibilities. I read the glossy marketing reports these vendors release to tease their services. The information in the good reports isn’t far off from the information blue teams use to understand and get an edge in different Cyber Defense Exercises.

In each of these stories, you’ll notice a common theme. The red team is in the network or will get in the network (Assume Compromise!). Knowledge of the red actor’s tools AND tradecraft helps the blue teams get an advantage. These teams use their adversary knowledge in one of two ways: they either design a mitigation against that tactic or they hunt for the red team’s activity. When I look at Threat Intelligence, I see the most value when it aids a thinking blue operator in this way. As a red operator, this is where I’ve seen the most challenge.

Further Reading

• Take a look at The Pyramid of Pain by David Bianco. This post discusses indicators in terms of things you deny the adversary. If you deny the adversary an IP address, you force them to take a routine action. If you deny the adversary use of a tool, you cause them a great deal of pain. David’s post is very much in the spirit of this one. Thanks to J.J. Guy for the link.

There is a growing chorus of folks talking about simulating targeted attacks from known adversaries as a valuable security service.

The argument goes like this: penetration testers are vulnerability focused and have a toolset/style that replicates a penetration tester. This style finds security problems and it helps, but it does little to prepare the customer for the targeted attacks they will experience.

Adversary simulation is different. It focuses on the customer’s ability to deal with an attack, post-compromise. These assessments look at incident response and provide a valuable “live fire” training opportunity for the analysts who hunt for and respond to incidents each day.

The organizations that buy security products and services are starting to see that compromise is inevitable. These organizations spend money on blinky boxes, people, services, and processes to deal with this situation. They need a way to know whether or not this investment is effective. Adversary simulation is a way to do this.

What is adversary simulation?

There’s no standard definition for adversary simulation, yet. It doesn’t even have an agreed upon term. I’ve heard threat emulation, purple teaming, and attack simulation to discuss roughly the same concept. I feel like several of us are wearing blindfolds, feeling around our immediate vicinity, and we’re working to describe an elephant to each other.

From the discussions on this concept, I see a few common elements:

The goal of adversary simulation is to prepare network defense staff for the highly sophisticated targeted attacks their organization may face.

Adversary simulation assumes compromise. The access vector doesn’t matter as much as the post-compromise actions. This makes sense to me. If an adversary lives in your network for years, the 0-day used three years ago doesn’t really matter. Offensive techniques, like the Golden Ticket, turn long-term persistence on its head. An adversary may return to your network and resume complete control of your domain at any time. This is happening.

Adversary simulation is a white box activity, sometimes driven by a sequence of events or a story board. It is not the goal of an adversary simulation exercise to demonstrate a novel attack path. There are different ways to come up with this sequence of events. You could use a novel attack from a prior red team assessment or real-world intrusion. You could also host a meeting to discuss threat models and derive a plausible scenario from that.

There’s some understanding that adversary simulation involves meaningful network and host-based indicators. These are the observables a network defense team will use to detect and understand the attacker. The simulated indicators should allow the network defense team to exercise the same steps they would take if they had to respond to the real attacker. This requires creative adversary operators with an open mind about other ways to hack. These operators must learn the adversary’s tradecraft and cobble together something that resembles their process. They must pay attention to the protocols the adversary uses, the indicators in the communication, the tempo of the communication, and whether or not the actor relies on distributed infrastructure. Host-based indicators and persistence techniques matter too. The best training results will come from simulating these elements very closely.

Adversary simulation is inherently cooperative. Sometimes, the adversary operator executes the scenario with the network defense team present. Other times the operator debriefs after all of the actions are executed. In both cases, the adversary operators give up their indicators and techniques to allow the network defense team to learn from the experience and come up with ways to improve their process. This requirement places a great burden on an adversary simulation toolkit. The adversary operators need ways to execute the same scenario with new indicators or twists to measure improvement.

Hacking to get Caught – A Concept for Adversary Replication and Penetration Testing

Threat Models that Exercise your SIEM and Incident Response

Comprehensive testing Red and Blue Make Purple

Seeing purple hybrid security teams for the enterprise

Isn’t this the same as red teaming?

I see a simulated attack as different from a red team or full scope assessment. Red Team assessments exercise a mature security program in a comprehensive way. A skilled team conducts a real-world attack, stays in the network, and steals information. At the end, they reveal a (novel?) attack path and demonstrate risk. The red team’s report becomes a tool to inform decision makers about their security program and justify added resources or changes to the security program.

A useful full scope assessment requires ample time and they are expensive.

Adversary simulation does not have to be expensive or elaborate. You can spend a day running through scenarios once each quarter. You can start simple and improve your approach as time goes on. This is an activity that is accessible to security programs with different levels of budget and maturity.

How does this relate to Cyber Defense Exercises?

I participate in a lot of Cyber Defense Exercises. Some events are setup as live-fire training against a credible simulated adversary. These exercises are driven off of a narrative and the red team executes the actions the narrative requires. The narrative drives the discussion post-action. All red team activities are white box, as the red team is not the training audience. These elements make cyber defense exercises very similar to adversary simulation as I’m describing here. This is probably why the discussion perks up my ears, it’s familiar ground to me.

There are some differences though.

These exercises don’t happen in production networks. They happen in labs. This introduces a lot of artificiality. The participants don’t get to “train as they fight” as many tools and sensors they use at home probably do not exist in the lab. There is also no element of surprise to help the attacker. Network defense teams come to these events ready to defend. These events usually involve multiple teams which creates an element of competition. A safe adversary simulation, conducted on a production network, does not need to suffer from these drawbacks.

Why don’t we call it “Purple Teaming”?

Purple Teaming is a discussion about how red teams and blue teams can work together. Ideas about how to do this differ. I wouldn’t refer to Adversary Simulation as Purple Teaming. You could argue that Adversary Simulation is a form of Purple Teaming. It’s not the only form though. Some forms of purple teaming have a penetration tester sit with a network defense team and dissect penetration tester tradecraft. There are other ways to hack beyond the favored tricks and tools of penetration testers.

Let’s use lateral movement as an example:

A penetration tester might use Metasploit’s PsExec to demonstrate lateral movement, help a blue team zero in on this behavior, and call it a day. A red team member might drop to a shell and use native tools to demonstrate lateral movement, help a blue team understand these options, and move on.

An adversary operator tasked to replicate the recent behavior of “a nation-state affiliated” actor might load a Golden Ticket into their session and use that trust to remotely setup a sticky keys-like backdoor on targets and control them with RDP. This is a form of lateral movement and it’s tied to an observed adversary tactic. The debrief in this case focuses on the novel tactic and potential strategies to detect and mitigate it.

Do you see the difference? A penetration tester or red team member will show something that works for them. An adversary operator will simulate a target adversary and help their customer understand and improve their posture against that adversary. Giving defenders exposure and training on tactics, techniques, and procedures beyond the typical penetration tester’s arsenal is one of the reasons adversary simulation is so important.

What are the best practices for Adversary Simulation?

Adversary Simulation is a developing area. There are several approaches and I’m sure others will emerge over time…

Traffic Generation

One way to simulate an adversary is to simulate their traffic on the wire. This is an opportunity to validate custom rules and to verify that sensors are firing. It’s a low-cost way to drill intrusion response and intrusion detection staff too. Fire off something obvious and wait to see how long it takes to detect it. If they don’t, you immediately know you have a problem.

Marcus Carey’s vSploit is an example of this approach. Keep an eye on his FireDrill.me company, as he’s expanding upon his original ideas as well.

DEF CON 19 – Metasploit vSploit Modules

Use Known Malware

Another approach is to use public malware on your customer’s network. Load up DarkComet, GhostRAT, or Bifrost and execute attacker-like actions. Of course, before you use this public malware, you have to audit it for backdoors and make sure you’re not introducing an adversary into your network. On the bright side, it’s free.

This approach is restrictive though. You’re limiting yourself to malware that you have a full toolchain for [the user interface, the c2 server, and the agent]. This is also the malware that off-the-shelf products will catch best. I like to joke that some anti-APT products catch 100% APT, so long as you limit your definition of APT malware to Dark Comet.

This is probably a good approach with a new team, but as the network security monitoring team matures, you’ll need better capability to challenge them and keep their interest.

Use an Adversary Simulation Tool

Penetration Testing Tools are NOT adequate adversary simulation tools. Penetration Testing Tools usually have one post-exploitation agent with limited protocols and fixed communication options. If you use a penetration testing tool and give up its indicators, it’s burned after that. A lack of communication flexibility and options makes most penetration testing tools poor options for adversary simulation.

Cobalt Strike overcomes some of these problems. Cobalt Strike’s Beacon payload does bi-directional communication over named pipes (SMB), DNS TXT records, DNS A records, HTTP, and HTTPS. Beacon also gives you the flexibility to call home to multiple places and to vary the interval at which it calls home. This allows you to simulate an adversary that uses asynchronous bots and distributed infrastructure.

The above features make Beacon a better post-exploitation agent. They don’t address the adversary replication problem. One difference between a post-exploitation agent and an adversary replication tool is user-controlled indicators. Beacon’s Malleable C2 gives you this. Malleable C2 is a technology that lets you, the end user, change Beacon’s network indicators to look like something else. It takes two minutes to craft a profile that accurately mimics legitimate traffic or other malware. I took a lot of care to make this process as easy as possible.

Malleable Command and Control

Cobalt Strike isn’t the only tool with this approach either. Encripto released Maligno, a Python agent that downloads shellcode and injects it into memory. This agent allows you to customize its network indicators to provide a trail for an intrusion analyst to follow.

Malleable C2 is a good start to support adversary simulation from a red team tool, but it’s not the whole picture. Adversary Simulation requires new story telling tools, other types of customizable indicators, and it also requires a rethink of workflows for lateral movement and post-exploitation. There’s a lot of work to do yet.

Putter Panda – Threat Replication Case Study

Will Adversary Simulation work?

I think so. I’d like to close this post with an observation, taken across various exercises:

In the beginning, it’s easy to challenge and exercise a network defense team. You will find that many network defenders do not have a lot of experience (actively) dealing with a sophisticated adversary. This is part of what allows these adversaries the freedom to live and work on so many networks. An inability to find these adversaries creates a sense of complacency. If I can’t see them, maybe they’re not there?

By exercising a network defense team and providing actionable feedback with useful details, you’re giving that team a way to understand their level. The teams that take the debrief seriously will figure out how to improve and get better.

Over time, you will find that these teams, spurred by your efforts, are operating at a level that will challenge your ability to create a meaningful experience for them. I’ve provided repeat red team support to many events since 2011. Each year I see the growth of the return teams that my friends and I provide an offensive service to. It’s rewarding work and we see the difference.

Heed my words though: the strongest network defense teams require a credible challenge to get better. Without adversary simulation tools [built or bought], you will quickly exhaust your ability to challenge these teams and keep up with their growth.