h1

The Post Exploitation Team

September 18, 2014

I often get asked about red team skills and training. What should each team member know how to do? For exercises or long running attack simulations, I believe it’s fruitful to put junior members into the post-exploitation role first. This post describes the post-exploitation team, where they fit into the overall engagement, and their core tasks and skills.

Context

Before we dig into the post-exploitation team, let’s go big picture for a moment. The following diagram is from my 2012 Dirty Red Team Tricks II talk at DerbyCon. It shows the model for hand-off from persistent access to post-exploitation that I saw evolve during the 2011 and 2012 CCDC seasons.

teamprocess_updated2

This diagram isn’t far off from the infrastructure and access hand-off model that I recommend today. The main difference is that I recommend the use of staging servers. These servers act as an intermediary between the servers for long-haul persistence and interactive post-exploitation.

The workflow from the above diagram is still the same.

Getting to Post Exploitation

An access team works to get a foothold into a target network. There’s a lot that goes into getting a foothold–especially when it’s important to not get caught.

The next step is to escalate privileges on the network, ideally to domain administrator. Domain administrator is not always required to accomplish a specific goal. It’s a stepping stone to easily accomplish a goal on a network.

It’s important to also setup persistent payloads through the network so that the red team may regain a foothold, with privileges. These payloads should call home to the long-haul infrastructure.

These steps to get a foothold, elevate access, and execute a persistence plan are (potentially) hard. These steps depend on the target environment and may require custom code to succeed. You want your strongest people available for these tasks.

Post Exploitation

As sexy as it is to break in, take the terrain, and hold it, no one breaks into networks and holds them for no anticipated purpose. It’s important to have objectives. Depending on the engagement, these objectives may mirror those a likely adversary would go after or they should satisfy training criteria for a network defense team.

Conducting post-exploitation activity and working on objectives is something well-trained, but potentially junior, red team members can do.

What should the post-exploitation team know how to do? What are their core skills? These team members should know how to task an asynchronous agent into interactive access. I arbitrarily define interactive access as a payload that calls home on a one minute interval or faster.

Interactive control should always happen on infrastructure that is separate from the infrastructure used to receive low and slow callbacks. This helps protect the red team’s operational security. If an interactive access gets caught, you do not want to lose all of your persisted access because of it. Ideally, the tool for interactive access is different from the tool for low and slow access [or, at least, different indicators!].

Once a team member has access to a system, they have to work from that access. They must know how to navigate a file system, download files, log keystrokes, take screenshots, hijack browser sessions, and otherwise grab whatever satisfies the objective they’re out to meet. They should also know how to interpret the output from each of these tasks and act on this information. They must also know how to triage sources of information and find what’s interesting, quickly.

Team members should know lateral movement, cold. They must know how to work with credentials, tokens, and Kerberos tickets. They should know their options to touch other systems with these things. If they need to use a payload (NOT always the right answer); they should know how to bootstrap the payload with PowerShell when it’s possible. If they have to fall back to an executable, they should know how to generate an anti-virus safe artifact.

Concretely, I expect post-exploitation team members to know how to start a remote process with psexec, at, schtasks, wmic, and sc. This skill also requires the team member to understand the nuances of which artifacts they can and can’t use with each of these. For example, if I try to schedule a plain executable with sc it will fail. Why? Because sc expects an executable that responds to Service Control Manager messages. If I schedule an executable that doesn’t do this, Windows will kill it very quickly.

All red team members should have judgement. They should know that the direct route isn’t always the best way to fulfill a requirement.

Team members should understand that some post-exploitation actions will fail depending on several contextual factors. Troubleshooting these contextual factors comes with experience. It’s helpful to have a senior lead on hand to step in when a junior member gets stuck.

All red team members should know how to tunnel external tools through any interactive post-exploitation tools in use. SOCKS and proxychains are good topics of study. All red team members should also have strong knowledge of the standard clients that interact with common services.

Finally, red team members should know how to clean up after themselves. If they’re done with an interactive access, they should know to drop it.

These core skills cover most of the work a post-exploitation team will do. Train several junior members with these skills, assign them to a senior lead, and you’ll get a lot of use out of them. They’ll grow during the engagement too.

Tradecraft, parts 4 through 9, covers these topics.

h1

Infrastructure for Ongoing Red Team Operations

September 9, 2014

Recently, I’ve had several questions about how to set up infrastructure for long running red team operations with Cobalt Strike. This is an ideal use case for Cobalt Strike. In this post, I will reiterate the advice I’ve shared with these users.

System Requirements

You will need to set up infrastructure to use for your engagement. I recommend that you host each piece of attack infrastructure on a VPS. I’ve used Linode and Amazon’s EC2 for this purpose. Make sure you factor the cost for multiple VPSs into your assessment budget.

I do not recommend that you setup a reverse port forward through your office’s NAT device. It’s in your best interest to minimize the number of devices and weird configurations between you and your target. It’s enough effort to guess what their network is doing, you don’t want to add troubleshooting your devices into the mix.

Attack infrastructure, for the purpose of this blog post, comes in two flavors: team servers and redirectors.

Team Servers

A team server is the server component of Cobalt Strike. It wraps the Metasploit Framework, connects to the database, and manages Cobalt Strike’s features. Multiple people may connect to a team server at one time. I also make the Cobalt Strike client available for Windows, MacOS X, and Linux.

You will want to follow the Cobalt Strike system requirements when you spec out a team server. I recommend 2GB of RAM, but you can get away with 1.5GB or more. On Amazon’s EC2, I use the c1.medium instance with 1.7GB of RAM. I like to set it up with a 64-bit flavor of Ubuntu 12.04.

Cobalt Strike’s quick-msf-setup script makes it very easy to set up the dependencies for a team server. This script is distributed with the Cobalt Strike Linux package. Run quick-msf-setup, choose your install preference, and everything else is taken care of for you. I use quick-msf-setup’s Git option to stage my dependencies.

distops2

Redirectors

A redirector is a system that proxies all traffic from your target’s network to a team server system. Redirectors give you IP diversity. You may configure listeners for Meterpreter and Beacon that call home through different redirectors. Beacon will phone home through multiple redirector addresses if you tell it to. I get away with low powered servers for my redirectors. An EC2 micro instance is fine here.

I also recommend that you obtain several domain names to use for your engagement. You will want to assign A records that point to each of your redirectors and team servers. If you choose to use the DNS Beacon, you will want to make its team server authoritative for multiple domains.

redirectors_t

Use Multiple Team Servers

I’ve seen attack infrastructure proposals that rely on one team server supported by multiple redirectors. This could work, but Cobalt Strike lets you take it one step further. The Cobalt Strike client connects to multiple team servers at one time. Each server may have its own listeners supported by its own set of redirectors.

I recommend that you designate a role for each team server that you stand up. When I setup infrastructure, I group my servers into three categories: long-haul, staging, and post-exploitation.

Long-Haul Servers

Long-haul servers catch callbacks from hosts that you’ve setup persistence on. I call these servers long-haul because they’re meant to maintain long-term access into your target’s network.

I use Cobalt Strike’s Beacon payload for long-term persistence. Beacon will call home to multiple servers, it speaks multiple protocols, and it’s designed for asynchronous “low and slow” operations. These are nice characteristics in a persistent agent.

Cobalt Strike’s Beacon does not have a turn-key persistence mechanism. If I put one in, everyone would know what to look for. You may export Beacon, without a stager, in a variety of formats though. I recommend that you architect a persistence strategy that makes the most sense for your engagement.

Long-haul servers require discipline to use effectively. These servers are your crown jewels as an embedded attacker. If they’re found out–you may find that your engagement is over. Here are a few tips to get the most of your long-haul infrastructure:

1. Never pass a session to a long-haul server

Every access on a long-haul server should come from a persistence mechanism. This allows you to monitor the status and health of your compromised systems. If a system isn’t calling back, it means it’s down or something is wrong with the persistence. This is your cue to investigate.

2. Use high callback times

Long-haul servers are designed for long-term access to a target’s network, not necessarily convenient access. I recommend that you configure your Beacons with high callback times. Consider a 24-hour callback interval with some randomization.

3. Use unique profiles

If a staging or post-exploitation action gets caught, you don’t want an indicator from that communication to lead to your long-haul infrastructure. Cobalt Strike’s Malleable C2 is a boon for these situations.

Malleable C2 lets you redefine the indicators in Beacon’s communication for each team server. Profiles take five minutes to write and test. Make sure your long-haul profile looks different from other profiles you use.

You may configure a default sleep time and jitter [randomization] factor through Malleable C2 as well.

4. Take Advantage of Protocol Diversity

I like to run two long-haul servers. I use a DNS Beacon on one server. I use an HTTP Beacon on another. I find that the DNS Beacon with a high sleep time and multiple domains offers a great challenge to professional network defense teams. The DNS Beacon uses one A-record request to an attacker controlled domain to “phone home”. One A-record request every 24-hours is quite benign.

5. Have a Persistence Strategy

The purpose of the long-haul servers is to keep a foothold in a target network or enclave. You do not want every compromised system to call home to this infrastructure. I recommend that you architect two persistence strategies. Let workstations beacon home to your attack infrastructure. Come up with something else to maintain access to compromised servers. You do not want high-value compromised servers calling out to your long-haul infrastructure.

Staging Servers

Staging servers are an intermediate level of infrastructure between long-haul persistence and interactive post-exploitation. I use staging servers as a convenient place to hold access to systems I plan to work with in a short period of time.

I use Beacon on staging servers with a sleep time that’s high enough to avoid detection but low enough that it’s convenient to use.

When I task access from a long-haul server; I almost always task the access to a staging server. Tasking an access means asking Beacon to spawn a session on another server when it checks in next. This is something built into Cobalt Strike’s workflow.

I recommend that you set up one staging server with its own redirectors to start with. If it gets caught, that’s OK. Spin up another one in its place.

Post-exploitation Servers

Post-exploitation servers are for interactive access to a compromised host. By interactive access, I mean a payload that calls home every minute or faster. This is Meterpreter and Beacons with a low sleep time.

Interactive access has its uses. You can pivot third-party tools into your target’s network and you get immediate feedback on your actions.

Request interactive accesses from your staging servers.

When I use a post-exploitation server; I tend to tunnel my Meterpreter sessions through Beacon rather than rely on the Metasploit Framework’s native handlers.

Updates

During your long engagement you will need to manage software updates carefully. I recommend that you never update a production team server during an engagement.

I work a lot on Beacon and I regularly break backwards compatibility with Beacons from previous releases. Be aware of this!

If a Metasploit Framework or Cobalt Strike update includes compelling features; feel free to introduce new software to your engagement. Just do it through a separate team server. Post-exploitation and staging servers are very transient and there’s no reason for these to stay the same for the length of your engagement.

Make sure you’re careful with those long-haul servers! If you need to update these, create new infrastructure with updated software, and reapply your persistence with the new long-haul servers as the target. Keep the old infrastructure available until you’re 100% confident that everything is moved over.

Licensing

I get asked about licenses and team servers. Cobalt Strike is typically licensed to X users in an organization. Users with a Cobalt Strike license are allowed to use the software on as many systems as necessary to do their job. Team servers count in this. Team servers are not a new user. So, if you have one license and one user, you’re welcome to spin up as many team servers as you need. If you have thirty licenses [you’re awesome!] and thirty users, you’re welcome to spin up as many team servers as you need.

Summary

These are my notes on setting up long-running attack infrastructure with Cobalt Strike. You’ll notice a lot of Cobalt Strike features play into this scenario. The distributed operations capability allows you to manage multiple servers. Beacon is a flexible agent that works as a persistent agent, acts as a placeholder for interactive accesses, and even offers an alternate communication layer. Better–you can customize Beacon’s C2 so each of these uses have their own indicators. This isn’t by accident. Managing accesses across distributed infrastructure in a team friendly way is Cobalt Strike’s bread and butter.

Tradecraft, part 9, speaks to some of the concepts in this post.

h1

Why can’t I psexec with EXE::Custom?

September 3, 2014

Seasoned Metasploit Framework users know that it’s a bad idea to let the framework generate an executable for you.

The framework’s encoders are not a tool to get past anti-virus. By happy accident, an encoded payload would get past some anti-virus products, but that was four or five years ago. If the Metasploit Framework generates an executable for you–it will get caught.

What’s an aspiring hacker to do? Fortunately, Metasploit Framework modules that generate executables expose an option, EXE::Custom. If you set this option to your own executable the module will use it, instead of generating an executable that will get caught.

This is a good time to become familiar with a tool or framework to generate executables. The Veil Framework is a good option.

For most modules, EXE::Custom is as simple as I’ve described here. Provide your own executable and enjoy freedom from detection. That said, there are two cases where you need to pay special attention to the file you provide.

psexec

The windows/smb/psexec module will generate an executable, copy it to a target, and create a service to run it. There’s two caveats for this executable.

When you run an executable as a service, it must respond to commands from the Service Control Manager. If you provide a normal executable, Windows will automatically kill it for you and you will not get your session.

Also, beware that the PsExec module will create a service, start it, and immediately try to stop it. The module will appear to hang until the stop operation completes. This has an implication for the design of your executable. To behave as this module expects–your service executable should start another program and inject your payload into that. If you do not pay attention to this detail, you may notice that your payload will appear to die after 30 to 60 seconds. The service stop operation will force kill your program after a grace period.

Check out the source to the Metasploit Framework’s version of this executable.

bypassuac_injection

One of my favorite privilege escalation options is the UAC bypass. The Metasploit Framework’s bypassuac attack takes advantage of a loophole to write a malicious DLL to c:\windows\system32\sysprep. It then launches sysprep.exe which will load the malicious DLL. This gives us elevation because sysprep.exe automatically starts itself in a high integrity (read: privileged) context.

In early 2014, Meatballs created a variant of this attack that touches disk only when necessary. This is the bypassuac_injection module.

This module also accepts an EXE::Custom option. Do not be fooled. This option does not accept an Executable. It expects a DLL. This is the malicious DLL that sysprep.exe will load.

You want to make your custom UAC DLL spawn a new process, inject your payload into it, and immediately cause the current program [sysprep.exe] to exit. This is the least disruptive experience for the desktop user. If your target is a 64-bit system, make sure you provide a 64-bit DLL.

Check out the source to the Metasploit Framework’s version of this DLL. [Note: If you read this DLL's source code, at first read, it will look like the current program doesn't exit. It does. When the Metasploit Framework populates the compiled DLL template, it adds code to exit the current process.]

h1

Evolution of a Modern Hacking Payload

August 26, 2014

One of the most important features in Cobalt Strike is its Beacon payload. This is my capability to model advanced attackers. In this post, I’d like to share my insights and reasons for the design decisions I made. If you’re a Cobalt Strike user, this post will help you reason about Beacon and fit it into your tradecraft.

From Raven to Beacon

I built Raven, an asynchronous persistent agent, for the 2012 Collegiate Cyber Defense Competition. I wanted a quiet way to hold access to compromised hosts.

Raven would connect to a web server every six minutes, request a file, and spawn a thread to execute the contents of the requested file. To task Raven, I would manually generate shellcode for a desired payload and save it to the file Raven would check for.

Later, I extended Raven to execute commands, change its sleep time, and inject arbitrary shellcode. I compiled Raven into a reflective DLL and built a user interface to generate tasks and host them on Cobalt Strike’s built-in web server. I also gave Raven a new name: Beacon.

Hybrid HTTP/DNS Communication

If you’re not familiar with Reflective DLLs, they’re significant. By compiling Beacon into a reflective DLL, I made it possible to inject the payload into memory and deliver it with a Metasploit Framework exploit.

Just before I pushed Beacon, I decided to build a variant that would use DNS. In one inspired night, I wrote Cobalt Strike’s initial DNS server. I then built the Beacon variant that would issue A record requests to check for tasks before it made a connection. I saw my DNS Beacon as an opportunity to very quietly hold access to a compromised host.

Distributed Operations

Beacon became my primary agent for persistent access to compromised systems. I noticed that I would dedicate my Cobalt Strike instance to it. When I wanted to interact with Meterpreter, I would do so from another Cobalt Strike instance. I built Cobalt Strike’s model for distributed operations to get ahead of this problem.

It’s a simple idea. Team servers have no awareness of each other. The Cobalt Strike client connects to multiple team servers and presents listeners from all of its team servers in its dialogs. This makes it trivial to task Beacon to send a session to another team server.

distops2

Cobalt Strike’s distributed operations model has shown itself as an ideal tool to organize a large red team during an exercise. The best practice is to create small cells that target each network and give each cell their own team servers. Each cell should have team servers for post-exploitation and staging. Post-exploitation servers are for noisy/interactive activity on hosts. Staging servers are where a cell holds their “low and slow” asynchronous accesses.

All cells are supported by an access management team. This team monitors health and access into target networks and works to keep these accesses alive. When a cell loses their access, an access manager connects to the cell’s staging server and passes a Beacon to it. I’ve seen Cobalt Strike provide coordination for large red teams in several exercise contexts. I realize this is a niche use case, but the fact it’s possible is quite impressive to me.

Post Exploitation

Originally, I saw Beacon as a complement to Meterpreter. I would hold access to systems with it and use Meterpreter for the heavy lifting. This model broke down on me. I saw several situations where a red operator had a Beacon on a host but they could not get or keep a Meterpreter session.

This drove a shift. I knew I would need to build a minimal set of post-exploitation tools into Beacon. It was not my intent to replace Meterpreter. I just wanted a way to work if I could not safely use an interactive agent like Meterpreter.

I decided to take advantage of Beacon’s asynchronous nature and build post-exploitation features that would benefit from it. For example, Beacon’s file download feature sends one file chunk with each check-in. Using the sleep time as a throttle, it’s possible to drip a large file out of a network without attracting attention.

DNS Command and Control

Several times, I had a Beacon on a system. I would see the A record request come in and Beacon’s check-in time would roll over. I couldn’t get Beacon to download its tasks though. I call this the child in the well situation. My compromised system would let me know it was there, but due to new egress restrictions or blocks, the Beacon couldn’t reach me.

I’ve always had interest in DNS for communication, but I did not know the best way to go about it. Initially, I thought I would build a pure DNS Beacon variant and it would always communicate over DNS. The child in the well scenario justified my interest in DNS for communication and it gave me an idea about how to do it best.

I updated the DNS Beacon to support multiple data channels. The A record response during the beacon step signals which data channel Beacon should use to download its tasks. By default, DNS Beacon uses HTTP as a data channel. When I run into a child in the well scenario, I tell Beacon to use DNS A or DNS TXT records to download its tasks.

dnscomms2

For the sake of completeness, I built a stager to download Beacon over DNS and inject it into memory. I started with the dns_txt_query_exec module by corelancod3r to do this.

After this work, I could pair Beacon’s DNS stager with a user-driven attack and use a DNS data channel to control a compromised host–without direct communication.

I use the DNS Beacon for persistence and sometimes to evade tough egress restrictions. With a high sleep time and multiple beacon domains, DNS Beacon is hard to stop.

Communication Layer

With the DNS data channel built into Beacon, I had to revisit my post-exploitation feature set. I wanted to know that I could work even if Beacon is the only payload that can get out of a network. I decided that pivoting was the missing feature. If I could pivot through Beacon, I could do most things I would want to do on a network.

To support pivoting, I built a SOCKS proxy server into Beacon. This generic interface would allow the Metasploit Framework and third-party tools to tunnel through a Beacon. This led to a lot of wins.

beaconpivot

I had a chance to use SOCKS pivoting in one engagement and I quickly saw a gap. There were many situations where I would want, but could not get, Meterpreter onto the pivot host. My work-around was to drop the host-based firewall and tunnel psexec with a bind payload through Beacon. This inspired Beacon’s meterpreter command.

With one command Beacon will setup a one-time use SOCKS proxy server and tunnel a Meterpreter session through it. I took care to build a bind stager that binds to localhost, to avoid interference from a host-based firewall. This feature is a big deal. It transforms Beacon into an alternate communication layer for Meterpreter and the Metasploit Framework. As Beacon gains new data channels and communication innovations, Meterpreter and the Metasploit Framework benefit from it.

Named Pipes

Beacon’s SOCKS proxy and post-exploitation tools made it suitable for most tasks. I ran into two problems. First, I found myself putting Beacon on almost all compromised systems. This is really stupid. If I make all compromised systems Beacon out to the same infrastructure with the same indicators, I’m easy to catch. Second, I had no way to put Beacon onto systems that could not reach my command and control infrastructure. I needed a solution to these problems.

I opted to abuse named pipes, an inter-process communication mechanism, for a communication channel. Fun fact: you may use named pipes for inter-process communication between hosts. This traffic is encapsulated within the SMB protocol. This channel blends in well with normal traffic.

smbc2

I implemented this data channel and quickly ran into the killjoy that negates most covert communication options: I didn’t have a way to stage a Beacon over a named pipe. I created a payload listener that could stage over a reverse tcp connection. I also added a pseudo-listener to my psexec dialogs to stage SMB Beacon over a bind connection. Both solutions are awkward. A host-based firewall on the target disrupts the bind stager. Egress filters tend to negate reverse TCP payloads too. I added pivot listeners to Cobalt Strike to ease this, but a host-based firewall on the pivot host can create problems too.

Privilege Escalation and Lateral Movement

I found a solution to my woes with staged SMB Beacons. Why not deliver SMB Beacon without a stager? This makes a lot of sense for the phase of the engagement where you’re most likely to use an SMB Beacon: lateral movement.

I added an option to generate executables, DLLs, and other artifacts that contain Beacon in one file. This negated the need for an SMB stager.

I then added token stealing and privilege escalation to Beacon. I focused on the standard stuff: getsystem and bypassuac. The UAC Bypass Attack was a lot of fun to dig into. I even made Beacon’s version of this attack work against Windows 8.1.

Privilege escalation, token stealing, and SMB Beacon gave me the raw materials for covert lateral movement with Beacon. It’s simple, really. Steal a token to gain the network rights of a user. Generate an SMB Beacon artifact. Use the rights of an admin user to copy the SMB Beacon artifact to a target and run it. Link to the SMB Beacon from another Beacon to assume control of it. Better, you can do these steps from a Beacon with a high sleep time. This is how I do lateral movement now. I don’t use Metasploit’s psexec modules unless I’m in a hurry.

Malleable C2 Profiles

There’s one problem left. I use Beacon for all phases of post-exploitation. I use it as a communication layer, as a temporary placeholder, and as a persistent agent. It’s dangerous to use common indicators for each of these phases. Getting caught once could lead to the discovery of other attack infrastructure and compromised systems.

This led to several questions: Could I decouple Beacon’s network indicators from its built-in functionality? Could I provide a non-developer full control over these indicators? This thought process led to Malleable C2.

Cobalt Strike ingests Malleable C2 profiles. A C2 profile specifies what Beacon’s communication should look like. From a profile I derive how to send and receive data. If you want to evade detection, you can craft a profile that looks like something that blends in.

malleablec2

Malleable C2 solves the indicators problem. Now, each set of attack infrastructure gets its own profile. The Beacons for post-exploitation, staging, persistence, and other purposes do not need to look the same. Each team server can host Beacons with different profiles.

Malleable C2 also allows Beacon to look like other malware. It takes less than five minutes to write a profile. This allows for threat replication during an assessment. Use your adversary’s indicators to test your customer’s ability to analyze and attribute the attack. It’s an interesting idea.

Summary

The concepts in this blog post represent two and a half years of development and lessons learned on my part. I hope you enjoyed reading about Beacon’s journey from asynchronous placeholder for Meterpreter, to alternate communication layer, to a flexible capability to replicate advanced threats.

h1

That was a fun fire drill…

August 18, 2014

Last week saw the release of Metasploit 4.10. Those who use Armitage and Cobalt Strike noticed that neither tool worked after running msfupdate on Kali Linux. That’s resolved now. Last night, I pushed Armitage and Cobalt Strike updates to fix the database.yml not found issue AND to make both tools compatible with Metasploit 4.10’s new database scheme for credentials. The latter was not a one-day change.

In this post, I’d like to share how I manage Metasploit Framework updates, my expectations for you, and what to expect from me the next time an incompatibility arises.

The Metasploit Framework is a core dependency for Armitage and Cobalt Strike. Some of you like to update this dependency very regularly. I don’t fault you for this. Know that with each update, there’s a possibility that Armitage and Cobalt Strike could break. This doesn’t happen often, but the possibility is still there.

To protect against this, I bless a particular Metasploit version with each release of Cobalt Strike and Armitage. I document this in the Cobalt Strike release notes and Armitage change log. This is the version of the Metasploit Framework that I QA’d Cobalt Strike against and certify as functional. I don’t always certify the latest version of the Metasploit Framework either. Sometimes, I find a framework bug that I consider a show stopper. At those times, I dig to find out which commit caused that bug. I report it to the Metasploit Framework team. I then QA an older version of the Metasploit Framework and certify my tools against it.

In general, if you use Cobalt Strike, you should use the version of the Metasploit Framework that I last blessed. This will help you avoid surprises. The quick-msf-setup script included with Cobalt Strike sets up an environment that went through my QA process.

Kali Linux users are a special case. Kali Linux users update the framework with msfupdate. This pulls the latest stable build of the Metasploit Framework blessed by Rapid7. Generally, this isn’t a problem and these updates work great. Last week was an exception.

If a Metasploit update impacts Cobalt Strike in a big way, I will communicate with you as soon as I know about it. My vehicle to do this is the Cobalt Strike Technical Notes mailing list [signup at the top]. I published a note about Metasploit 4.10 to the list on Thursday. I also announced my 4.10-compatible update to this list today. If you want to hear from me, I recommend that you sign up for that list.

If you’re an Armitage user, know this: I keep Armitage and Cobalt Strike’s codebases in sync. I have a good process to do this. If there’s a Metasploit change that affects both tools, I will update both tools at the same time. The latest Armitage version works with Metasploit 4.10 as well. The package is in Kali Linux now. Use apt-get update to get it.

h1

Puttering my Panda and other Threat Replication Case Studies

August 14, 2014

Cobalt Strike 2.0 introduced Malleable C2, a technology to redefine network indicators in the Beacon payload. What does this mean for you? It means you can closely emulate an actor and test intrusion response during a penetration test.

In this blog post, I’ll take you through three threat replication case studies with Cobalt Strike. In each case study, we will emulate the attacker’s method to get in, we will use a C2 profile that matches their malware, and we will analyze what this activity looks like in Snort and Wireshark.

Putter Panda

Putter Panda is an actor described by a June 2014 Intelligence Report from CrowdStrike. In this video, we replicate Putter Panda’s HTTP CLIENT malware and use a Document Dropper attack to deliver it.

String of Paerls

String of Paerls is an intrusion set described by Sourcefire’s Cisco’s VRT. In this video, we replicate the actor’s C2 with Beacon and use a macro embedded in a Word document to attack a target. We also reproduce the attacker’s phish as well.

Energetic Bear / Crouching Yeti / Dragonfly

This actor, known by many names, allegedly targets the energy sector. The best information on this actor came from pastebin.com without a slick PDF or PR team to back it up. In this video, we replicate this actor’s havex trojan with Beacon and use a Java drive-by exploit to attack a target.

With the right technologies, threat replication isn’t hard. Read about and understand the actor’s tradecraft. Craft a profile that uses the actor’s indicators. Launch an attack and carry out your assessment. Threat Replication is a way to exercise intrusion response and see how well a security program stands up to these actors.

h1

Introducing Morning Catch – A Phishing Paradise

August 6, 2014

Morning Catch is a VMware virtual machine, similar to Metasploitable, to demonstrate and teach about targeted client-side attacks and post-exploitation.

On this virtual machine, you will find: a website for a fictitious seafood company, self-contained email infrastructure to receive phishes, and two desktop environments. One desktop environment is a vulnerable Linux client-side attack surface. The other is a vulnerable Windows client-side attack surface.

Morning Catch uses a bleeding edge version of WINE to run a few vulnerable Windows applications AND experiment with post-exploitation tools in a fun and freely re-distributable environment.

You can download it via this torrent.

Login Screen

Your use of Morning Catch starts with the login screen.

Boyd Jenius is the Systems Administrator and his password is ‘password’. Login as Boyd to get to the vulnerable Linux desktop.

Richard Bourne is Morning Catch’s CEO and his password is also ‘password’. Login as Richard to get to the vulnerable Windows desktop.

You can also RDP into the Morning Catch environment.

logon

Windows Desktop

Richard’s desktop includes the Windows’ versions of Firefox, Thunderbird, Java, and putty. Open up Thunderbird to check Richard’s email.

You can send a phish to him too. This VM includes a mail server to receive email for users at the morningcatch.ph domain. Open up a terminal and find out the IP address of the VM. Make sure you relay messages through this server. Use [email protected] as the address.

Are you looking for some attacks to try? Here are a few staples:

Morning Catch’s WINE environment runs post-exploitation payloads, to include Windows Meterpreter and Beacon, without too much trouble.

theattack

Linux Desktop

Boyd’s desktop is the vulnerable Linux attack surface. Boyd has the Linux versions of Firefox, Java, and Thunderbird. Boyd also has an SSH key for the Metasploitable 2 virtual machine. Try to ssh to Metasploitable 2 as root and see what happens.

Webmail

Morning Catch also includes RoundCube webmail for all of its users. Use this as a target to clone and harvest passwords from.

roundcube

Hopes and Dreams

Morning Catch isn’t a replacement for a vulnerable Windows lab. It’s a safe and freely redistributable target to experiment with phishing and client-side attacks. It’s my hope that this environment will help more people experiment with and understand these attacks better.

Are you in Las Vegas for BlackHat USA or DEF CON? Stop by the Black Hat Arsenal on Wednesday at 10am for a demo of this new environment and a Morning Catch sticker. I’m also giving away DVDs with a revised Cobalt Strike pen testing lab that uses Morning Catch. Find me at the Cobalt Strike kiosk in the Innovation City portion of the Black Hat USA Exhibitor Hall. I will also give away these DVDs at the Cobalt Strike table in the DEF CON vendor area.

Follow

Get every new post delivered to your Inbox.

Join 13,049 other followers