Archive for the ‘Red Team’ Category

h1

Windows Access Tokens and Alternate Credentials

December 16, 2015

I’d like to call your attention to the humble runas.exe program on Windows. This program allows a Windows user to spawn another program with another user’s credentials.

runas1

It’s a little painful to use runas.exe from a remote access tool. This program doesn’t accept a password as an argument. Cobalt Strike’s Beacon has a built-in runas program to give you similar functionality.

The process that runas starts has an access token populated with the same single sign-on information you would expect from access tokens made by a normal login. You can steal a token from a program started by runas and use that token to interact with local and remote resources.

The runas capability is great for situations where you want to create a process as a local user on the current system or as a domain user from a trusted domain. This covers a lot of situations, but not all.

What happens if you need to interact with a remote resource as a local user on another system? How do you interact with a remote resource as a domain user when there’s no trust relationship with that domain? These problems have a solution.

The Curious /NETONLY Flag

The runas program has a /NETONLY flag. This flag tells runas that the specified credentials are for remote access only. Windows will not try to validate these credentials. Instead, Windows will create a copy of your current access token and update it to use the new credentials when Windows interacts with a remote resource. Windows will then create the new process with this doctored token.

This has a curious effect. The new program is run as the current user. On the current system, there is no change in your rights, permissions, or identity. But, when you interact with a remote resource, you are the specified user.

runas2

Logon Sessions and other Access Token Trivia

I hope I’ve raised some questions so far. Questions like, how does runas.exe /NETONLY work?

Windows manages identity and security information in a structure known as an Access Token. These data structures contain things like: your username, groups, privileges, and other information. An Access Token may also contain information to restrict your rights. When working with Windows, it’s important to understand that an access token isn’t a single thing that represents a user’s identity. An access token is an instantiation of an identity with a lot of variables thrown in.

An easy example of this is User Account Control. A local administrator user may run most processes in a medium integrity context. The tokens associated with their processes have an Integrity level field set to 0x2000 which is SECURITY_MANDATORY_MEDIUM_RID. Processes run by the same local administrator in a high integrity context have access tokens with their Integrity level set to 0x3000. These tokens represent the same user, but different rights. The point here is that Windows may have multiple access tokens, with different configurations, for a user and that’s normal.

This blog post isn’t a deep dive into access tokens though. It’s a walk down the garden path about single sign-on information. Let’s jump into that.

An Access Token contains your identity on the current system and it states what you can and can’t do on the current system. An Access Token also references the information Windows uses to automatically authenticate to remote systems.

Now I hope you’re asking: what part of an Access Token determines who you are on a remote system? This question is the whole point of this blog post.

Each Access Token references a Logon Session. The Logon Session references credential material for single sign-on purposes. When Windows authenticates to a remote system, it uses the Logon Session’s credential material to authenticate. A Logon Session is made after authentication is successful. Logon Sessions go away when there are no more tokens that reference them.

When you use the /NETONLY flag with runas.exe, Windows will create a new Logon Session with the credential material you provide. It will then copy your current token and substitute the default logon session for the new one. The specified program is then run with this new token.

The program run by runas looks like it’s running as your current user. That’s because it is. The new program was run with a copy of your user’s access token! When you interact with a network resource, Windows does not authenticate as your Access Token’s user. Windows uses the credential information referred to by the new Logon Session. In this case, the credential material in this new Logon Session does not necessarily match the identity in your current Access Token.

If you’d like to see a list of Logon Sessions on your current system, take a look at the logonsessions utility by Mark Russinovich.

logonsessions

Implications for Beacon Users

Beacon’s runas command is similar to the default behavior of the runas program built into Windows. What about the /NETONLY flag? Beacon has something like this too. It’s the make_token command.

The make_token command uses the LogonUser function in Windows with the LOGON32_LOGON_NEW_CREDENTIALS flag. This API creates a Logon Session from the specified credentials, copies your Access Token, associates the new Logon Session with the new Access Token, and makes this new Access Token available. Beacon then impersonates this new token.

What’s the effect of this? You have a new token that is locally indistinguishable from your previous token. When you use Beacon’s getuid command to query your token’s identity, you get back the current user. When you type shell whoami, you get back the current user.

What happens when you interact with a network resource? Windows authenticates with the credentials you specified to make_token. Why? Because the Logon Session in the current Access Token references the credentials you provided to make_token. In this case, the Logon Session information does not match the local identity of your current token.

The make_token command in Beacon works this way to allow you to use a local account from another system to interact with it. This mechanism also allows you to authenticate to a system as a domain user when there’s no trust relationship with that domain.

The pth command in Beacon is a similar story. The pth command asks mimikatz to: (1) create a new Logon Session, (2) update the credential material in that Logon Session with the domain, username, and password hash you provided, and (3) copy your Access Token and make the copy refer to the new Logon Session. Beacon then impersonates the token made by these steps and you’re ready to pass-the-hash.

Again, with pass-the-hash, the side effects are similar. The new token is locally indistinguishable from your current user. That’s because you are your current user! When you interact with a network resource, Windows uses the material from the Logon Session to authenticate. In this case, it’s the information you provided to the pth command.

Frequently Asked Questions

This blog post is the result of many questions I’ve had about the make_token and pth commands in Beacon. Common questions include: Do pth and make_token work with local accounts? Yes. Do pth and make_token work with domain user credentials when there’s no trust relationship with the specified domain? Yes. Why do the make_token and pth tokens report themselves as the current user? That’s just the way it is.

Windows is a complicated animal. I appreciate that its design sometimes results in non-obvious or confusing behavior. I hope this blog post clears up some of the confusion about the make_token and pth commands for you.

If you’d like to learn more about this topic, to include how to use make_token and pth in an operation, consult the Lateral Movement lecture from the Advanced Threat Tactics course.

h1

Flying a Cylon Raider

November 18, 2015

In Season 1, Episode 5 of Battlestar Galactica, Lieutenant Kara Thrace finds herself marooned on a barren planet with a crashed Cylon Raider. To get home, Lieutenant Thrace has to apply her knowledge of flight fundamentals to control the strange platform and pilot it back to safety.

And, so it goes with hacking. You don’t always get to choose your tools. In mature environments, the combination of defenses and analysts you’re working against will dictate which tools you can use.

When your favorite toolset is taken away from you, how do you operate?

Recently, I had a chance to discuss this question with the audience at the SANS Hackfest in Washington, DC. That talk, Flying a Cylon Raider, is a guide on how to take your knowledge of Meterpreter and apply it to other toolsets.

I’ve re-recorded the presentation. Here it is:

h1

Migrating Your Infrastructure

October 21, 2015

I’ve written about infrastructure for red team operations before. Infrastructure are the servers, domains, and other assets that support your ongoing operation against a target network.

Sometimes, your infrastructure will become known and understood by the blue audience you’re working to train. At these times, it’s usually prudent to take steps to extend or change your infrastructure to stay one step ahead. That’s the subject of this blog post.

Rolling Redirectors

I highly recommend that you always use redirectors when you setup your initial infrastructure. A redirector is a server that forwards traffic to your Cobalt Strike team server. Ideally, your target network should never touch your team server infrastructure directly. It should always interact with you through a redirector.

If this is how your infrastructure is setup, then keeping ahead of your training audience is pretty easy. Simply stand up new redirectors, assign domains to these redirectors, and update your listener configuration to reference these new redirectors. Previously deployed Beacons will call home to the old configuration information but any new Beacons you spawn will call home to the new hosts.

Rolling Team Servers

Let’s say you want to re-roll an active team server to another server. Your plan is to copy Cobalt Strike to the new system, start it, configure it, and point your redirectors and domains to this new team server. This team server has Beacons calling back and you don’t want to lose them in this move. This is doable.

Early into Cobalt Strike’s life, I made the decision to design Beacon’s communication scheme to not depend on state in the team server. I did this to make sure Beacon sessions could recover in the event of a team server restart.

Beacon communication is dependent on one piece of state though: the key material for the team server. When you first create a Beacon listener, Cobalt Strike generates an asymmetric key pair for your team server. This file is .cobaltstrike.beacon_keys in the directory you ran the team server from. Copy this file to the folder you will run the Cobalt Strike team server from on the new system. If you don’t, you will not have control of any previously deployed Beacons calling home to the new team server.

When you roll team server infrastructure, it’s also imperative that you use the Malleable C2 profile. The Malleable C2 language compiles into a form that, quite literally, rewrites how Beacon and Cobalt Strike communicate with each other. If you do not bring your profile over to the new server, the team server will not know how to interpret callbacks and other messages from previously deployed Beacons.

If you move the key material over, keep the same Malleable C2 profile, and take care to point your old redirectors [or domains] at the new server–you will recover existing callbacks without trouble.

Migrating to New Team Servers

Rolling redirectors is a common task. Sometimes, I have to roll team servers, but this is more rare. I don’t like to take functional infrastructure down if I have to. My preference is to stand up new infrastructure and migrate existing accesses to it.

To migrate accesses from one team server to another:

Stand up new infrastructure. Take care to create your redirectors and assign domain names to your redirectors [or the team server itself].

Connect to the old infrastructure with your Cobalt Strike client.

If the accesses calling back to this old infrastructure are persistent, you have your work cut out for you. You will want to redeploy your persistence with new artifacts that point to the new infrastructure. A script to deploy persistence can help a great deal here.

If you just want to migrate existing callbacks, this is easy enough. Create a foreign listener on the old team server that points to your new one. Then highlight all of your Beacons, right-click, and select Spawn. This dialog will let you choose a listener to spawn on all of these sessions. Choose your foreign listener. As accesses check in on the old team server, you will see accesses show up on the new one.

The Spawn workflow is easy, but it’s not the best for OPSEC. It spawns a new process and injects your stager into it. You have the option to inject a Cobalt Strike listener into an existing process instead.

Here’s how to do that:

Highlight all of your Beacons and go to Explore -> Show Processes. This action will task all of the Beacons to send back a process list and these lists, for each of your sessions, will show up in one window. Here, you have the opportunity to sort your processes by name and mass inject your foreign listener into the same process on all of these sessions.

Parts 1 and 2 of Advanced Threat Tactics discuss infrastructure and operations. Part 4 of Advanced Threat Tactics discusses Session Passing.

h1

Advanced Threat Tactics – Course and Notes

September 30, 2015

The release of Cobalt Strike 3.0 also saw the release of Advanced Threat Tactics, a nine-part course on red team operations and adversary simulations. This course is nearly six hours of material with an emphasis on process, concepts, and tradecraft.

If you’d like to jump into the course, it’s on YouTube:

Here are a few notes to explore each topic in the course with more depth.

0. Introduction

This is a course on red team operations and adversary simulations.

To learn more about Adversary Simulations and Red Team Operations:

Advanced Threat Actors:

Tools used in this course:

1. Operations

Advanced Threat Tactics starts with a high-level overview of Cobalt Strike’s model for distributed operations and red team collaboration.

To learn more about Cobalt Strike’s model for collaboration and operations:

  • Watch Force Multipliers for Red Team Operations. This is my favorite talk I’ve given. Here, I summarize my work and insights on the red team collaboration problem. Today, I consider this a completed research project with the following blog posts capturing lessons learned on how to build infrastructure and organize a large red team to support operations (primarily in an exercise context).
  • Read A Vision for Distributed Red Team Operations to learn more about Cobalt Strike’s model for distributed operations with multiple team servers.
  • Read The Access Management Team [Shell Sherpas]. This blog post discusses the Access Manager role in depth.
  • Read about The Post Exploitation Team. These are my notes on the folks who interact with targets to complete objectives and find interesting information.
  • Read Infrastructure for Red Team Operations. Infrastructure is the foundation of any engagement. This post is my best practices for organizing infrastructure to support a long-term op with multiple targets.

2. Infrastructure

Infrastructure is the collection of domains, servers, and software that support your operation. One of Cobalt Strike’s strengths is its variety of communication channels and the flexibility you have to configure them. This lecture goes through the HTTP/HTTPS, DNS, and named pipe channels and shows you how to use special features with each. I also take you through how to stand up redirectors and test your infrastructure before an engagement.

To learn more about payload staging:

Beacon Communication:

3. Targeted Attacks

This lecture goes through a process to execute a targeted spear phishing attack to get a foothold in a modern enterprise.

To learn more about this material:

User-Driven Attacks:

4. Post Exploitation

This lecture shows how to use Beacon for post-exploitation. If you have to operate with Beacon, this is good core material to know.

To learn more about this material:

Post-Exploitation:

  • Buy the Red Team Field Manual. This is a must-own for anyone working in this space. The tips and tricks here are quite applicable for all Beacon operators.
  • Watch Flying a Cylon Raider. This talk is a platform agnostic look at how to conduct post-exploitation and lateral movement without the Metasploit Framework. Understanding the concepts in this talk will help you get the most from the material in this course.

5. Privilege Escalation

Think of this lecture as post exploitation, part 2. We dive into how to elevate privileges and use these privileges to harvest credentials and password hashes.

To learn more about User Account Control and the Bypass UAC attack:

Privilege Escalation:

  • Read Windows Privilege Escalation Fundamentals. This tutorial has a number of command-line recipes to find files with credentials and other things you should look for when trying to elevate your rights.
  • Read What you know about ’bout GPP? This blog post offers a look at the Group Policy Preferences privilege escalation vector. This is one of those issues that, while patched, remains an issue because the patch does not cleanup the problems created by this feature when it was last used. I didn’t have time to cover this problem in the course [six hours is enough!]; but this is a staple thing you should always check for.

PowerUp:

Mimikatz:

6. Lateral Movement

This lecture is the use and abuse of native Windows capability and behavior to trade-up privileges and move around a network.

To learn more about enumeration and reconnaissance in a Windows Active Directory network:

  • Watch Passing the Torch: Old School Red Teaming, New School Tactics? Here David McGuire and Will Schroeder go through their tricks to understand a Windows enterprise network the old school way (net view /DOMAIN and friends) vs. the new school way (with PowerShell).
  • Read PowerView: A Usage Guide to understand this wonderful tool from Will Schroeder to automate enumerating trusts, users, and hosts in an active directory environment.
  • Read the PowerView 2.0 post to understand the changes made to PowerView since this course was made. For example, Invoke-Netview no longer exists.
  • Print the PowerView 2.0 cheat sheet. It’s a handy reference.
  • Check out Netview by Rob Fuller. This tool enumerates systems using the Win32 Network Management API. I believe it was one of the original inspirations for PowerView and it certainly inspired Beacon’s net module as well.
  • Read Trusts You Might Have Missed by Will Schroeder for a quick primer on domain trusts in Windows Active Directory networks. You’ll really want to go through all of Will’s blog to understand this topic fully. He posts a lot about domain trusts and user hunting. Too much for me to keep up with here.
  • Also, read I Hunt Sys Admins by Will Schroeder (him, again!) to learn different ways to find where a particular user lives on the network. This is important for targeting systems that may have trust material that gets you closer to the data you want or to DA rights on the network.
  • Read Attack Methods for Gaining Domain Admin Rights in Active Directory by Sean Metcalf. This post is a survey of different techniques used to gain Domain Admin rights in Active Directory.

Remote Management without Malware:

Pass-the-Hash:

Kerberos:

Remote Code Execution:

7. Pivoting

SOCKS, SOCKS, SOCKS! This lecture is about how to pivot with Beacon. You could also think about it as using and abusing SOCKS forwards, backwards, and any other way you want it.

More on this topic:

8. Malleable C2

Malleable C2 is Cobalt Strike’s domain specific language to change indicators in the Beacon payload. This ability to make Beacon look like other malware is arguably what makes it a threat emulation tool.

More on this topic:

9. Evasion

The Advanced Threat Tactics course concludes with a deep dive into evasion. This video is my to-the-minute notes on this topic.

To learn more about phishing and e-mail delivery:

Anti-virus evasion:

Application Whitelisting:

Egress Restrictions:

  • Read An Unnecessary Addiction to DNS Communication. I often hear from folks who insist that DNS is the only way out of their network and the only way to reach servers that are otherwise isolated from the network. This post goes into depth on the evasion options with Cobalt Strike’s DNS communication scheme and it digs into the capability available in Cobalt Strike’s other Beacon variants.
  • Read HTTP Proxy Authentication for Malware to understand how Beacon’s HTTP/S stagers react to proxy authentication failures.

Active Defenders:

  • Watch Operating in the Shadows given by Carlos Perez at DerbyCon 2015. In this talk, Carlos goes over the different advancements in blue’s ability to instrument Windows and the impact it will have on red teams and penetration testers who need to challenge them. This is a sign of things to come.
  • Read Advances in Scripting Security and Protection in Windows 10 and PowerShell V5. Windows 10 will change the security game in a big way. This post from Microsoft goes through the new logging hooks to understand PowerShell activity on a system and the hooks that allow anti-virus engines to look for malicious PowerShell.
  • Take a look at Microsoft’s Advanced Threat Analytics technology. This defense tracks which systems/users pull which active directory objects, when, and how often. It’s designed to catch that awesome stuff discussed in part 6 of this course.
  • Also, check out UpRoot, an agentless host-based IDS written in PowerShell that leverages WMI subscriptions. UpRoot reports process creates, new network connections, and other host activity. Tools like UpRoot show the scrutiny red operators will need to learn to cope with when working with a mature hunt team.
  • Watch Infocyte‘s video on Enterprise Hunt Operations. While this is a product advertisement, listen closely for the information it collects. As a red operator, you need to understand what your actions look like to analysts who use these hunt platforms. Your job is to figure out how to craft your activity to grow and challenge these analysts.
h1

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

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.

h1

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.

h1

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.

hashdump

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

pth

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

stealtoken

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

admincheck

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

lateral

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.

Follow

Get every new post delivered to your Inbox.

Join 17,844 other followers