The Aggressor Project (Preview)

September 2, 2015

If you’ve run into me at a conference during the 2015 calendar year, there’s a strong chance you’ve heard about or saw the Aggressor project. Aggressor is a ground-up rewrite of Cobalt Strike’s team server and client to better serve its Red Team Operations and Adversary Simulation use cases. I expect to ship this work as Cobalt Strike 3.0. It’s due for release at DerbyCon 2015 (September 2015).

At first glance, Cobalt Strike 3.0’s biggest change is the absence of the Metasploit Framework. Cobalt Strike 3.0 doesn’t depend on it. Instead, Cobalt Strike 3.0 builds its process and workflows on the Beacon post-exploitation agent. Many of my customers have moved their offensive process to the Beacon payload. Cobalt Strike 3.0 caters to this shift. Cobalt Strike 3.0 is also a fresh look at reporting and logging to aid accountability, deconfliction, and training.

If you want to know what Cobalt Strike 3.0 will look like, here’s a partial preview:

To some, this may sound very foreign. What’s the point of a penetration test without scans and exploits? Not all security assessments look like this. Adversary Simulations and Red Team Operations are security assessments that replicate the tactics and techniques of an advanced adversary in a network. While penetration tests tend to focus on unpatched vulnerabilities and misconfigurations, adversary simulations benefit security operations and incident response. There are different models/best practices for these engagements. I started this company and built this product to push these practice areas forward.

I’ve had several folks ask questions about Cobalt Strike 3.0. I wanted to take a few moments to answer them:

1) Is Cobalt Strike 3.0 available to existing customers or will I need to buy new licenses?

Cobalt Strike 3.0 is the anticipated successor to Cobalt Strike 2.5. As with other Cobalt Strike updates, Cobalt Strike 3.0 will be available to those with active Cobalt Strike licenses.

2) Will the price of Cobalt Strike go up when 3.0 hits?

The price of Cobalt Strike will not change as a result of the 3.0 release. Could the price go up in the future? Absolutely. Will it go up in the next month or two? No.

3) What will happen to browser pivoting in Cobalt Strike 3.0?

Browser Pivoting is present in Cobalt Strike 3.0.

4) How will you replace all the great things in Metasploit?

Cobalt Strike 3.0 does not replace the Metasploit Framework. Cobalt Strike 3.0 complements the Metasploit Framework as a separate platform. You can fire the Beacon payload with a Metasploit Framework exploit [demo]. You can pass accesses between the Metasploit Framework and Beacon [demo]. You can also pivot Metasploit Framework attacks [demo] and Meterpreter sessions through Beacon [demo].

5) Is Cobalt Strike’s name changing?

No. Aggressor is a codename. Cobalt Strike will still be called Cobalt Strike.

6) What will happen to Cobalt Strike 2.x and Armitage?

Armitage is its own project and will continue to stay much as it is now. I consider Armitage a mature product, but will maintain it as necessary. Cobalt Strike 2.x will be replaced by Cobalt Strike 3.0. I do not plan to maintain two lines of the Cobalt Strike product.

If you’d like to learn more about Cobalt Strike 3.0, hang tight, we only have a few weeks until DerbyCon. So far, we’re on track for a release at that time.


Raphael’s Magic Quadrant

August 3, 2015

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.



Cobalt Strike 2.5 – Advanced Pivoting

July 29, 2015

I spend a lot of my red time in the Access Manager role. This is the person on a red team who manages callbacks for the red cell. Sometimes, I like to grab a Beacon and drive around a network. It’s important to get out once in a while and enjoy what’s there. Cobalt Strike 2.5 is all about cruising around networks.

Lateral Movement++

This release adds native lateral movement options to Beacon. Use the psexec_psh, winrm, and wmi commands to deliver a Beacon to a target using PowerShell to avoid touching disk. For you old school types, a psexec command is available to deliver a Beacon to a target with an Artifact Kit service executable.

You’ll likely notice that Cobalt Strike’s lateral movement options do not accept credentials, hashes, or other credential material. Keeping with Cobalt Strike’s operating philosophy, these lateral movement options rely on what’s in your access token to authenticate with a remote system. If you want to pass-the-hash with Beacon; use mimikatz to create a token that passes your hash. If you need to pass credentials, use Cobalt Strike 2.5’s make_token command to create a token to pass the credentials you provide.

Named Pipe Stager

Cobalt Strike’s best payload for lateral movement is the SMB Beacon. This Beacon uses a named pipe to receive commands from and relay output through another Beacon. A named pipe is an inter-process communication mechanism on Windows. Named pipes also work host-to-host to allow two programs to communicate with each other over the network. This traffic is encapsulated in the SMB protocol.

The SMB beacon is awesome but it had a weakness. It’s too big to use with attacks like psexec_psh. Cobalt Strike 2.5 solves this problem with its named pipe stager. This tiny stager delivers the SMB Beacon to a remote target over a named pipe. This stager works well with Beacon’s new lateral movement options that don’t touch disk. This is quite an upgrade from the previous best practices.

Pivoting Process-to-Process

Red Teams pivot, not just host-to-host, but process-to-process on the same host. This need is usually driven by egress and evasion concerns. A process run as an unprivileged user may have the ability to egress. As soon as you elevate, you may run into difficulties if that elevated process can’t communicate out.

Cobalt Strike 2.5 uses the SMB Beacon to help with this problem. Beacon features to include its Bypass UAC attack and new spawnas command [use credentials to spawn a payload; without touching disk] accept the SMB Beacon as a target payload. This greatly improves Cobalt Strike’s options to work through one egress channel.

Reverse Port Forwards

Cobalt Strike 2.5 also adds reverse port forwarding. Beacon’s new rportfwd command will bind a port of your choice on a compromised target. When someone connects to this port, Cobalt Strike’s team server will establish a connection to a forward host and port of your choosing. It will then relay traffic, via Beacon, between this new connection and the client connected to your Beacon. Now, you can use compromised systems as arbitrary redirectors. ☺

Check out the release notes to see a full list of what’s new in Cobalt Strike 2.5. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.


WinRM is my Remote Access Tool

July 22, 2015

One of my favorite blog posts last year was Adversary Tricks and Treats from CrowdStrike. In this post, CrowdStrike details the tradecraft of an actor they dub Deep Panda. In an attempt to skirt advanced malware hunting capability, Deep Panda leverages native tools to control target systems and spread laterally in a network. With the exception of their foothold, they don’t use malware to complete their objectives.

This is an important idea. One of my favorite red team tasks is to provide a credible adversary to exercise new ideas for network defense. There’s a positive shift away from the passive blinky boxes to the inquisitive analyst who has tools to ask questions at scale. As red operators, we have a neat opportunity to nurture and grow these analysts into formidable defenders.

All that future talk aside, it’s important to think about how to do this. One way I do it is by looking at different ways to operate. I think it’s important to have multiple concepts of offense and ways to simulate an on-going offensive operation. One of my favorite ways now is to play like Deep Panda and limit my use of malware as much as possible.

I’m keenly aware that skilled network defenders watch some assets more than they watch others. A domain controller is no-man’s land. A skilled team armed with techniques that don’t scale will watch their domain controller’s like hawks when they know a red team is exercising them. Workstations are… less important.

I like to live on the workstations with my malware and use native tools to interrogate and control servers as much as possible.

There are a lot of ways to abuse a trust relationship to run commands on a remote system. at, schtasks, sc, and wmic are among my favorites. I’m a WinRM fan too.

WinRM is the Windows Remote Management service. It listens on port 5985. It’s off by default, but some system administrators turn it on to enable easy remote management of their servers [hence the name, right?]

When WinRM is on, you can use PowerShell to remotely interrogate a server and control it. Or, if you’re feeling lucky, you can turn WinRM on yourself. Here’s how to enable WinRM via Beacon:

powershell Enable-PSRemoting -Force

The output will look like this:


WinRM does require a trust relationship with the target system. You’ll need a token for a domain user that is a local administrator to the target. You can steal one of these, make one with runas, or use Mimikatz to create a token to pass a password hash.

To control a target via WinRM from Beacon, here’s the syntax:

powershell InvokeCommand -ComputerName TARGET -ScriptBlock { dir c:\ }

PowerShell will run, via WinRM, whatever you specify inside of the script block. After this command completes, PowerShell will return the output to you.

The ability to run commands on a remote target AND get output back is nice. In most cases, this is enough capability to operate and achieve an objective. One of my favorite things though is the ability to run Mimikatz this way. PowerSploit’s Invoke-Mimikatz cmdlet allows you to specify a -ComputerName argument. Fun fact: this argument can be array of systems to run Mimikatz on. With this option specified, PowerSploit will run mimikatz via WinRM, in memory on the remote target, and report the output back to you.

Here’s the syntax to do it:

powershell-import /local/path/to/PowerSploit/Exfiltration/Invoke-Mimikatz.ps1
powershell Invoke-Mimikatz -ComputerName TARGET

Here’s a video of these concepts in action:

Between Mimikatz and the ability to run arbitrary commands remotely, I have a lot of operating capability right there. If you want to emulate a long-term embedded actor who does things a little differently, this is certainly a good TTP to try out.


Models for Red Team Operations

July 9, 2015

Recently, I had an email from someone asking for a call to discuss different models of red team operations. This gentlemen sees his team as a service provider to his parent organization. He wants to make sure his organization sees his team as more than just dangerous folks with the latest tools doing stuff no one understands. This is a fair question.

In this post, I’ll do my best to share different models I see for red team operations. By operations, I mean emulating the activities of a long-term embedded adversary in a network, one that works from a remote location. This ability to gain, maintain, and take action on access over a (potentially) long period of time is a different task from analyzing an application to find flaws or quickly enumerating a large network to identify misconfigurations and unpatched software.

You may ask, what’s the point of emulating a (remote) long-term embedded adversary? Two words: Security Operations. I’m seeing a shift where organizations are leveraging their red assets to validate and improve their ability to detect and respond to intrusions.

With all of that said, let’s go through a few of the different models:

Full Scope Penetration Tests

A full scope penetration test is one where a hired or internal team attempts to gain a foothold into their customers environment, elevate their rights, and steal data or achieve some desired effect. These engagements mimic the targeted attack process an external actor executes to break into an organization. When a lot of my peers think about red team operations these assessments are immediately what comes to mind.

Full scope penetration tests provide a data point about the state of a security program, when all aspects are exercised in concert against an outside attacker. Unfortunately, full scope assessments are as much a test of the assessor as they are of the organization that commissioned these tests. They are also expensive and assessors have to cope with restrictions that are not placed onto a real adversary [less time, fewer resources, compliance with the law].

Given time, resources, and competent execution, a full scope engagement can offer valuable insight about how an external actor sees an organization’s posture. These insights can help identify defensive blind spots and other opportunities for improvement. These engagements are also useful to re-educate executives who bought into the hype that their organization is un-hackable. Making this point seems to be a common driver for these assessments.

Long-term Operations

I see several red teams building long-term operations into their services construct. The idea is that no organizational unit exists in isolation of the others. The organizational units that commission engagements from their internal assets are not necessarily the organizational units that are most in need of a look from a professional red team. To deal with these situations, some red teams are receiving cart blanche to gain, elevate, and maintain access to different organizational units over long period time. These accesses are sometimes used to seed or benefit future engagements against different organizational units.

Long-term Operations serve another purpose. They allow the red team to work towards the “perfect knowledge” that a long-term embedded adversary would have. This perfect knowledge would include a detailed network map, passwords for key accounts, and knowledge about which users perform which activities that are of value to a representative adversary.

It’s dangerous to require that each red team engagement start from nothing with no prior knowledge of a target’s environment. A long-term embedded adversary with a multi-year presence in a network will achieve something that approximates perfect knowledge.

For some organizations, I’m a fan of this approach and I see several potential benefits to it. The perfect knowledge piece is one benefit, but that is something an organization could white card if they wanted to. There’s another key benefit: our common understanding of long-term offensive operations is weak at best. Maintaining and acting on access over a long period of time requires more than a good persistence script and a few VPS nodes. The organizations that take time to invest in and get good at this approach will find themselves with interesting insights about what it takes to keep and maintain access to their networks. These insights should help the organization make investments into technologies and processes that will create real pain for a long-term embedded actor.

War Games

Several organizations stage red vs. blue war games to train and evaluate network defense staff. These exercises usually take place in a lab environment with multiple blue teams working to defend their representative networks against a professional opposing force. The role of this opposing force is to provide a credible adversary to train participants and keep pressure on them throughout the event.

Each of these events is different due to their different goals. Some events white card the access step completely. Some also white card the perfect knowledge of the long-term embedded adversary. It all depends on the event’s training objectives and how the organiser’s want to use their professional red team assets.

To an outsider, large scale Red vs. Blue events look like a chaotic mess. The outsider isn’t wrong. Red vs. Blue events are a chaotic mess. They’re chaotic because they’re fast paced. Some compress a multi-year attack scenario into an event that spans days or weeks.

There’s value to these events though. These events provide a safe opportunity to exercise processes and team roles in a fast-paced setting. They’re also an opportunity to field immature or new technologies to understand the benefit they can provide. Unlike more structured tests, these events also give blue participants opportunities to observe and adapt to a thinking adversary. Done right, these events encourage full disclosure between red and blue at the end so participants can walk away with an understanding of how their blue TTPs affected the professional adversary.

Threat Scenarios / Cyber Security Exercises / Attack Simulations

Another use for red assets is to help design and execute cyber security exercises to train and assess network defense teams. These exercises usually start with a plausible scenario, a representative or real actor, and a realistic timeline.

The red asset’s job is to generate realistic observable activity for each part of the timeline. The red operator is given every white card they need to execute their observable effect. Each of these carefully executed items becomes a discussion point for later.

These exercises are a great way to validate procedures and train blue operators to use them. Each unique generated activity is also an opportunity to identify procedure and technology gaps in the organization.

While this concept is new-ish to security operations, it’s by no means new. NASA has had a concept of an Integrated Training Team led by a Simulation Supervisor since the beginning of the US space program. NASA’s lessons learned in this area is a worthwhile study for security professionals. When I think about emerging job role of the Threat Emulator, I see these folks as the equivalent of NASA’s Simulation Supervisors, but for Security Operations.

Who is doing this?

I see several red teams re-organizing themselves to serve their organizations in different ways from before. Established teams with custom tools for long-term operations are trying to retool for engagements that require full disclosure afterwards. Other teams mirror external consulting firms in their services. These teams are now trying to give their leadership a global long-term perspective on their organization’s security posture. Day-to-day these teams are working towards the credibility, capability, and skills to bring the benefits of long-term operations to their organization. I see a trend where many internal red teams are expanding their services to benefit their organization’s at the tactical and strategic levels. It’s an exciting time to be in this area.


Cobalt Strike Penetration Testing Labs (Download)

June 4, 2015

My primary conference give away is a DVD with a self-contained penetration testing lab. This DVD covers the Metasploit Framework‘s capability to target a server. It also covers the client-side attack process in Cobalt Strike. It’s a pretty neat set of labs and they don’t take too long to go through.

Cobalt Strike Boxed Set

I’ve had several requests to put these labs online. If you’re one of those interested parties, then today is your lucky day. The Cobalt Strike Pen Testing Lab DVD material is now available for download.

To start, you’ll want to grab the necessary virtual machines:

1. Morning Catch (Phishing Target)

2. Metasploitable 2

3. Xubuntu Attack VM with CS dependencies and stuff to support the labs

Next, you’ll want to download the penetration testing lab book. Last, you’ll need to grab a trial of Cobalt Strike and install it on the Xubuntu virtual machine above.

Once you have these things, you’re ready to rock. If you get stuck, here’s a video of me going through the labs:



How to Pass-the-Hash with Mimikatz

May 21, 2015

I’m spending a lot of time with mimikatz lately. I’m fascinated by how much capability it has and I’m constantly asking myself, what’s the best way to use this during a red team engagement?

A hidden gem in mimikatz is its ability to create a trust relationship from a username and password hash. Here’s the mimikatz command to do this:

sekurlsa::pth /user:USERNAME /domain:DOMAIN /ntlm:HASH /run:COMMAND

The sekurlsa:pth command requires local administrator privileges. This command spawns the process you specify and modifies its access token. The local Windows system will still think the process was run by your current user. The parts of the token designed to support single sign-on will reference the username, domain, and password hash you provide.

If you use the above to spawn another payload (e.g., Meterpreter, Beacon); your actions that attempt to interact with a remote network resource will use the username, domain, and password hash you provide to authenticate.

In practice, spawning a new payload to pass-the-hash is a pain. It’s much easier to spawn a bogus process (e.g., calc.exe) and steal its token. Beacon’s steal_token command will impersonate a token from another process. The token stolen from our bogus process will continue to reference the username, domain, and password hash you provide. Any actions to interact with a remote resource, while Beacon holds this token, will pass the hash for us.

Let’s assume I have a foothold in a target environment and I’ve elevated my privileges. Here’s how I’d use this for lateral movement with Beacon:

1) Run hashdump to dump password hashes for the local users.


2) Run mimikatz sekurlsa::pth /user:Administrator /domain:. /ntlm:… /run:”powershell -w hidden”


We do powershell -w hidden to create a process without putting a Window on the desktop. Mimikatz doesn’t hide Windows for the processes it creates.

3) Use steal_token 1234 to steal the token from the PID created by mimikatz


4) Use shell dir \\TARGET\C$ to check for local admin rights


5) Try one of the lateral movement recipes (wmic, sc, schtasks, at) from this blog post to take control of the system.


To get a feel for how this works, I’ve put together a video:

This method of pass-the-hash has several advantages over traditional pen tester methods. Which advantage resonates with you will depend on the situations you face.

When I work with a mature network defense team, I try to avoid non-asynchronous communication. This means I can not speed up my Beacon to tunnel PsExec or another Metasploit module through my Beacon. This interactive communication will get caught right away. This plays well with an asynchronous post-exploitation workflow.

This method also gives me a great deal of flexibility. I’m relying on Windows to pass my credential material for me. What I do to interact with a remote network resource is up to me. If I’m only interested in data, I can list and copy files via a UNC path to the target. If I want to execute code, I have options beyond the service control manager to do so. When dealing with a mature target, this is important.

Finally, I prefer to use native tools over hacker tools to carry out my actions. I favor native tools because they blend in better and they’re more likely to work consistently. This method of pass-the-hash caters well to this preference.


Get every new post delivered to your Inbox.

Join 16,247 other followers