Archive for the ‘Cobalt Strike’ Category


Listeners: Cobalt Strike’s Glue Feature

March 27, 2014

Listeners are Cobalt Strike’s abstraction in front of the Metasploit Framework’s payload handlers. A handler is the exploit/multi/handler module. This module sets up a server that waits for a payload on a compromised system to connect to you.


Cobalt Strike’s listeners feature is a way to configure handlers that start when Cobalt Strike starts. A listener consists of a user-defined name, a payload, a host, a port, and whether or not you would like the payload to automatically migrate.

Many Cobalt Strike features let you choose a listener to quickly configure a payload. When you take advantage of this, you’re certain that the information is correct. Here are the ways you can use listeners:

  • You can quickly configure a Metasploit Framework exploit to use a pre-defined listener. Double-click the PAYLOAD option to choose one of your listeners. This action will populate the module’s options for you.
  • When you task a Cobalt Strike Beacon to spawn a session—you get to choose a listener from any of the Cobalt Strike team servers you’re connected to. This is an incredibly seamless way to pass shells to different team servers.
  • All Cobalt Strike social engineering packages allow you to choose a listener to pair with the attack.


Listeners are an abstraction. They’re the one-stop shop to set up handlers in Cobalt Strike. Given that this convention works well—Cobalt Strike’s Listener Management feature becomes the place to hook in Cobalt Strike-specific stuff.

Beacon is a good example of this. To Cobalt Strike users–Beacon feels like a first-class payload. It’s not an external tool or something that is awkwardly integrated. Beacon doesn’t exist in the Metasploit Framework though. It’s a Cobalt Strike payload that stages as the windows/dllinject/reverse_http payload when used with a Metasploit Framework feature. Listeners made it possible for me to define Beacon as a payload alongside Meterpreter’s various options.

Listeners are also my opportunity to expose some hidden functionality in the Metasploit Framework to my users. For example, not many people know that it’s possible to tunnel reverse_tcp payloads through a Meterpreter session.  Cobalt Strike helps you do this through pivot listeners.

A Pivot Listener is a listener that is set up to route back to you through a Meterpreter session. This is really an incredible feature. A lot of privilege escalation actions will spawn a new session. If I care at all about stealth—I want to make as few outbound connections from a compromised system as possible. With a Pivot Listener—I can generate Cobalt Strike EXEs and DLLs that tunnel through an existing session. This is very powerful. Once the listener is set up, I just use it without having to recall the details behind it.


Cobalt Strike’s Listeners also setup stage encoding for Windows payloads as well. Once you get code execution, the stub of code sent with the attack downloads the rest of the payload to inject into memory. This transaction is easy to catch as the downloaded payload is a DLL with a little bootstrap code prepended to it. For nearly a year now, Cobalt Strike’s Listeners have helped users avoid detection by setting up stage encoding for them.


Listeners also make it possible to enjoy a wider variety of Metasploit Framework payloads. For example, if I want to do callbacks over IPv6, I can configure an IPv6 listener and provide it the right LHOST once. I don’t have to remember my IPv6 address every time I set LHOST. Cobalt Strike’s Listener keeps track of this information for me.

Listeners make Cobalt Strike redirector friendly too. A redirector is a server with iptables rules or port forwarding software that sends traffic to your attack server. Once you have redirector infrastructure setup—you can create Cobalt Strike listeners that call home to it. Redirectors are a way to obfuscate the true location of your attack server. You may assign a different redirector to each listener you create. After this initial setup, it just works. Cobalt Strike’s Beacon payload may also stage through a redirector and call home through multiple redirectors.

One danger with an abstraction, like Cobalt Strike’s listeners, is that they hide some output and information from you. Cobalt Strike mitigates this by making it possible for you to watch the output of any Metasploit Framework handler managed this way. Go to Cobalt Strike -> Listeners, right-click the listener, and choose Debug. Cobalt Strike will stop the handler and start it again in its own console. Through this console, you may see all output associated with that handler.

Listeners are the glue that holds Cobalt Strike together. They allow seamless cooperation between team servers, use of redirectors, and they save you and your team the trouble of remembering the configuration information for these shared assets.

If you’d like to learn more about Cobalt Strike’s listeners, review the documentation or watch Part 3 of the Tradecraft course.


Cobalt Strike 03.13.14 – NECCDC Edition

March 13, 2014

I’m writing this from a New Hampshire Bed and Breakfast where I’ve apparently received the Jacuzzi suite. I’m here for a romantic weekend running psexec and managing Beacons inside of student networks for the North East Collegiate Cyber Defense Competition event. This is my seventh year with this event.

I made a lot of development progress early into my recent development cycle and I like to show up with my latest stuff, so everyone gets a Cobalt Strike update today. This release polishes the Cobalt Strike user experience and it adds a few features CCDC red teams will find very useful.

Export Staged Beacon Artifacts

You may now export an executable, service executable, 32-bit DLL, or 64-bit DLL with a fully staged Beacon. These fully staged artifacts are generated by Cobalt Strike’s Artifact Kit for anti-virus evasion.

This feature is a big win for stealthy lateral movement. Now you can copy SMB Beacon [the whole thing!] to a target host, schedule it to run, and link to it from another Beacon. This allows you to gain control of a system and control it over the SMB protocol only. You can do these things without ever lowering Beacon’s sleep time to something that could get caught.

A complete artifact is also an ideal candidate for persistence. Beacon is designed to call home to multiple sites. If one address doesn’t work, Beacon will try another one. If there’s an error, Beacon gracefully recovers from it and tries again. These are traits you want in a persistent agent.

Beacons don’t always have to call out though. Export an SMB Beacon and persist it on a host. So long as port 445 is open, you can link to that Beacon over an SMB named pipe. SMB Beacon is the perfect bind backdoor for Windows.


Beacon now includes its own timestomp command. This command will match the Modified, Accessed, and Created times for one file to another.

Cleaning House

This release also benefits from a thorough scrub of Cobalt Strike’s codebase. This cleansing changes how Cobalt Strike waits for results when it calls into the team server or requests information from the user. Now, in most cases, these actions will not block any other actions from taking place. The result is a snappier and more robust Cobalt Strike client. You will also notice that Cobalt Strike is better with large file transfers to and from the team server and that it also responds to disconnections better.

If you’re a Cobalt Strike license holder, use the built-in update program to get the latest.  A 21 day trial of Cobalt Strike is also available.


Cobalt Strike 02.27.14 – Details Matter

February 27, 2014

Cobalt Strike 1.48 (02.27.14) is now available. This release is the byproduct of a very intense development cycle. The theme of this release is: details matter. Read on for a sense of what I mean by this.

Pivot Listeners

This Cobalt Strike update introduces pivot listeners. A pivot listener is a handler for a  reverse payload that stages and tunnels through an existing Meterpreter session.

Because Cobalt Strike is built for targeted attacks, I always assume that my users are external to their target’s network. One way to keep a low profile is to limit how many connections you make to your command and control infrastructure. Unfortunately, a lot of post-exploitation actions you take will require a new session. Privilege escalation and lateral movement are prime examples.

A pivot listener allows you to spawn sessions through an existing Meterpreter session. Pivot listeners work anywhere you would use a normal Cobalt Strike listener. This gives you a way to limit your post-exploitation activity to one channel out of your target’s network.


Stager Tweaks

A topic that is near and dear to my heart is egress filtering. Cobalt Strike now uses a custom HTTP stager to deliver its Beacon. This custom stager takes steps to disguise itself as Internet Explorer. The native Metasploit Framework stager sends a blank User-Agent which is an opportunity for a proxy server to stop you or a defense team to catch you.

If you can get Beacon on a system, you’re just one step away from Meterpreter. Type ‘meterpreter’ and Beacon will act as a tunnel to stage and communicate with your session. Beacon’s ‘meterpreter’ command now uses a custom stager that avoids a popup from the Windows firewall.

Token Stealing and Privilege Escalation

This release also adds token stealing to Cobalt Strike’s Beacon payload. The usual repertoire of getuid, rev2self, and steal_token are present. The ability to steal tokens is key for lateral movement.

Before you can steal tokens, you need the ability to escalate your privileges. I’ve added getsystem to go from an administrator user to SYSTEM on a box, through Beacon.

UAC Bypass

Speaking of privilege escalation, this release adds bypassuac to Beacon as well. This command spawns a session in a process with elevated rights. This privilege escalation technique takes advantage of a loophole in the default UAC settings on Windows 7 and later. This command will not work if the current user is not in the Administrators group or if UAC is set to its highest setting.

The UAC Bypass attack has several steps to it. The last step is to get code execution through DLL search order hijacking of a program that automatically elevates itself to full rights. The public versions of this attack rely on a hijacking opportunity that works in Windows 7 only. Beacon’s UAC bypass uses different opportunities for Windows 7 and Windows 8.

Beacon’s UAC Bypass is also evasion friendly. The one DLL it drops to disk is made by Cobalt Strike’s Artifact Kit. All other UAC bypass logic happens in memory. And yes, the UAC Bypass cleans up after itself.

Details matter

Tools that succeed in production have to pay attention to details. Sometimes, new research makes it into Cobalt Strike. Other times, the work in this product is on the details. The small stuff that makes a big difference when you’re on an engagement.

You can grab a 21-day trial of Cobalt Strike. Licensed users should use the update program to get the latest. Consult the release notes file for a full list of changes.


What took so long? (A little product philosophy)

February 20, 2014

Cobalt Strike’s  January 8, 2014 release generates executables that evade many anti-virus products. This is probably one of the most requested features for Cobalt Strike.

Given the demand–why did it take so long for me to do something about it?

One-off anti-virus evasion is trivial. In 2012, I wrote a one-off stager for Windows Meterpreter. Few products caught it then. Few catch it now. Why? Because very few people use it. There’s no reason for an anti-virus vendor to write signatures against it.

When I use Cobalt Strike–I always bring a collection of private scripts to generate artifacts when I need them. I’ve never had a problem with anti-virus. Many of my users have their own process to generate artifacts. Good stuff is available publicly too. For example, Veil is a fantastic artifact generator.

If anti-virus evasion is so trivial–why didn’t I build new artifacts into Cobalt Strike until now?

Long-term Utility

Every feature I build has to have long-term utility. I want tools that will help get into networks and evade defenses five to ten years from now.

If I built short-term features, my work would hit a local optima that I may not escape. Over time, each improvement would serve only to balance the faded utility of the old things next to it. Without maintenance, a product with short-term features would decay until it’s not useful.

Long-term focus has the opposite benefit. If I do my job right, each release is more useful to my users than any previous release. New features interact well with existing ones and all features become more useful. This sounds like common sense… but it’s not a natural course for software.

Imagine a toolset built around locating known service vulnerabilities and launching remote exploits. Seven years ago–this hypothetical toolset could rule the world. Today? This toolset’s utility would diminish with each day as it’s built for yesterday’s attack surface. Even with patchwork improvements, the best days for this kit are in the past. A few client-side attacks next to a rusty Windows 2003 rootkit creates an image of a dilapidated amusement park with one ride that still works. The world does change and sometimes these changes will obsolete what was otherwise good. At this point, it’s time to reinvent. I feel this is where we are with penetration testing tools.

Expected Life

Every time I build something–I ask, how does this give my users and I an advantage today, tomorrow, and next year? Or better put–what is the expected life of this capability?

On the offense side–a lot of our technology has a comically short expected life. Exploits are a good example of this. Once the vulnerability an exploit targets is patched–the clock starts ticking. Every day that exploit loses utility as fewer opportunities will exist to use it. I don’t build exploits and it’s not a focus of my product. A single exploit is not a long-term advantage. A team or community of exploit developers? They’re a long-term advantage. I leverage the great work in the Metasploit Framework for this. But, in terms of value add, I have to find other places to provide a long-term advantage.

What types of technologies provide a long-term advantage? Reconnaissance technologies are a long-term advantage. NMap will probably have use in the hacker’s toolbag for, at least, our lifetime. A reconnaissance tool is a life extender for your existing kit of attack options. A three-year old Internet Explorer exploit isn’t interesting—except when a reconnaissance technology helps you realize that your target is vulnerable to it. This is why I put so much effort into Cobalt Strike’s System Profiler. The System Profiler helps my users squeeze more use out of the client-side exploits in the Metasploit Framework.

Can you think of other technologies that provide a long-term advantage? Remote Administration Payloads. Meterpreter is almost ten years old. Even though it’s gained features—the Windows implementation is the same core that Skape put together a long time ago. Any effort to make post-exploitation better will pay dividends to users many years from now. So long as there’s a way to fire a payload and get it on a system–it has utility. Well, almost. There’s one pain point to this.

The Big Hunt

On the offensive side–we are in the middle of a shift. My ass was kicked by it three years ago. If you haven’t had your ass kicked by this yet–it’s coming, I promise. What’s this offensive ass kicking shift? It’s pro-active network security monitoring as a professional focus and the people who are getting good at it. Our tools are not ready for this. Our tools assume we have the freedom to get out of a network and communicate as much as we like through one channel. These assumptions hold in some cases, but they break in high security environments. What’s the next move? I’ll give you mine.

I’ve built a multi-protocol payload with ways to control its chattiness, flexibility to use redirectors, peer-to-peer communication to limit my egress points, and in a pinch–the ability to tunnel other tools through it. Why did I do this? If I can’t get out of a network with my existing tools–I’m out of the game. If I can’t maintain a stable lifeline into my target’s network–I’m out of the game. If all of my compromised systems phone home to one system–I’m easy to spot and take out of the game.

We had a free pass to use a compromised network without contest. This is coming to an end. Sophisticated attackers evolved their communication methods years ago. We need tools that provide real stealth if we’re going to continue to claim to represent a credible threat.

I work on stealth communication with Beacon, because I see a long-term benefit to this work. I see Browser Pivoting as a technique with a long-term benefit as well. Two-factor authentication hit an adoption tipping point last year and it will disrupt our favored ways to get at data and demonstrate risk. Browser Pivoting is a way to work in this new world. When I look at the offensive landscape, I see no lack of problems to solve.

Anti-virus Evasion – Revisited

What’s a problem that I didn’t touch, because of the short life expectancy of any one solution? I didn’t want to build a public artifact collection to get past anti-virus.

I remember when the US pen tester community became aware of Hyperion. Researchers from wrote a paper on a novel way to defeat any anti-virus sandbox. The technique? Encrypt a payload with a weak key and embed it into an executable with a stub of code to brute force the key. Anti-virus products would give up emulating the binary before the key was brute forced–allowing the executable to pass.

This technique is a long-term advantage. Any one of us can write our own anti-virus bypass generator that uses the Hyperion technique. So long as we keep our generator and its stub to ourselves, it will last a long time. We didn’t do this though. We took the Hyperion proof-of-concept and used it as-is without changes. What happened? Eventually anti-virus vendors wrote signatures for a stub of code in the public binary and then the technique left our minds, even though it’s still valid.

Let’s go back to the original question. Why didn’t I add anti-virus evasion artifacts until now? I didn’t work on this problem because I didn’t have a sustainable plan. I do now.

I wrote an Artifact Kit. The Artifact Kit is a simple source code framework to generate executables that smuggle payloads past anti-virus. Better, the Artifact Kit is able to build DLLs, executables, and Windows dropper executables. I expect that, in the future, Artifact Kit will also build my persistence executables as well.

I updated Cobalt Strike to use the Artifact Kit to generate executables. My psexec dialogs use it. My Windows Dropper attack uses it. I even found that the Metasploit Framework’s Firefox add-on module fired with an Artifact Kit executable becomes a nice way to get a foothold on a fully patched system. This is an example of a new feature complementing existing tools and extending their life and utility.

Artifact Kit’s techniques have a limited lifetime. The more use it gets–the more likely an analyst will spend the time to write signatures and negate the utility of the Artifact Kit. One technique isn’t sustainable. What’s the plan then?

I published the source code to Artifact Kit along with different techniques to a place my customers have access to. I also provided Cortana hooks to make Cobalt Strike use any changes that I or my customers can dream up. Now, anti-virus evasion in Cobalt Strike doesn’t hinge on one technique. It’s a strategy. As soon as one kit gets burned, swap in a new one, and magically everything in the tool that uses it will work. It took some time to think up a flexible abstraction that makes sense. I’m pretty happy with what I have now.

If you’re a developer of offensive capabilities–ask a few questions before you commit to a problem. What is the shelf-life of your solution? Is there a way to extend the life of your solution–if it runs out? And, finally, does your solution have the potential to extend the life of other capabilities? These are the questions I ask to make sure my output has the most impact possible.


Four Levels of Hacking Sophistication with Beacon

January 31, 2014

Beacon is Cobalt Strike’s payload for red team actions. Beacon is a stable lifeline that can serve as a communication layer. Meterpreter is a fantastic post-exploitation agent with a lot of features.  Used together, Beacon and Meterpreter give you a lot of options for stealth and indirection. In this post, I’ll take you through different ways to use Beacon to get the most out of Meterpreter and the Metasploit Framework.

Option 0. No Beacon

Let’s start by describing life without Beacon. In this situation, you have to use Meterpreter for everything. Meterpreter becomes your payload for the first foothold. Meterpreter is your payload for persistence. And, Meterpreter is your payload for remote control of the compromised system. Meterpreter is also the payload you pivot through.


If you use Meterpreter for your foothold into a network, chances are your first action is to spawn several backup Meterpreter sessions. You do this, because if you lose your session without a backup, you’ve lost your access. This isn’t the best option for stealth, but it’s a necessity. Meterpreter sessions do drop and it’s important to fortify your access to protect against this.

Option 1. Beacon as a Lifeline

There is another option though. Use Beacon for your foothold into a network. Beacon is designed to work like any other Metasploit Framework payload. You may deliver it with a Metasploit Framework memory corruption exploit or a Cobalt Strike social engineering package. Once Beacon is in memory, it will check-in over HTTP or DNS for tasks.


Beacon tasks are commands that you’d like Beacon to execute. For example, the spawn command will request a Meterpreter session for you. Used in this way, Beacon is a quiet lifeline to gain a new Meterpreter session when you need it. If stealth is important to you, don’t request a session until you have to interact with the host.

Option 2. Beacon for Egress

Meterpreter gives you the option to egress a network as a reverse TCP connection, HTTP, or HTTPS. Meterpreter always egresses to one host. If this host is blocked or watched by a network defense team, you may find yourself on the losing end of a game of whack-a-mole. This isn’t fun.


For these situations, use Beacon as a pivot point to egress traffic out of your target’s network. Beacon gives you the option to egress a network over DNS or HTTP. You may even change between HTTP and DNS communication while you use your Beacon. This gives you the flexibility to use the right protocol for your needs at any time during the engagement.

Beacon will also egress to multiple hosts. When you setup Beacon, you provide a list of multiple domains and hosts Beacon should call back to. Beacon will rotate through these hosts in a round-robin fashion. A network defense team must block all of these hosts to disrupt your communication with their network.

Beacon exposes a SOCKS proxy server that allows you to use a beaconing host as a pivot point. This SOCKS proxy server will tunnel Metasploit Framework attacks, Meterpreter, and external tools through Beacon.

To use Beacon as a pivot point, you must ask your Beacon to check-in multiple times each second. If you try to tunnel traffic through a Beacon with a high sleep time, you will find most tools will timeout due to the artifically high communication latency.

Beacon as a pivot point will help you walk your toolkit past a lot of border defenses. Once you’re inside of a network, with a stable channel to tunnel through, you have a lot of freedom to work without interruption.

Option 3. Beacon as a Communication Layer

Not all systems that you compromise can or should beacon out to hosts on the internet. There are times when you will want to control a system that can’t connect to you. To control these systems you might use a bind Meterpreter payload or a reverse TCP payload through a Meterpreter session. As usual, if your Meterpreter session dies, you have to re-compromise the system to run Meterpreter on it.

Optionally, you may deliver Beacon as a bind payload to gain control of these systems too. A bind Beacon payload, also called a Beacon peer, is an in-memory backdoor that you may run on a compromised system. A bind Beacon is a backdoor because you may connect to it whenever you like, disconnect from it, and reconnect to it later.

This backdoor is available as an SMB pipe. To connect to this backdoor, you must link another Beacon to it. Linked Beacons communicate over SMB, which blends in well with normal network traffic. Traffic tunneled through a Beacon peer will go through its parent Beacon to communicate with you.

On any host that has a Beacon, you may issue one command to request a Meterpreter session that stages and tunnels its traffic through that Beacon. Used this way, Beacon becomes a replacement communication layer for Meterpreter.


If you lose a Meterpreter session tunneled through a Beacon peer, you may request a new one in its place. You do not need to recompromise the target and the target does not need to connect to the internet. A Beacon peer can act as a pivot point and a lifeline to a host deep inside of a network.

Option 4. Beacon as a Remote Administration Tool

Sometimes, you will find it’s difficult to get a stable Meterpreter session out of a target’s network. A host-based defense may disrupt it. Or, your attempts to tunnel traffic into a target network may stand out—leading to the whack-a-mole game. In this situation, you’re stuck with Beacon as a remote administration tool.

If you do not tunnel traffic through Beacon, you can use it with a high sleep time. You may ask Beacon to check in once every ten minutes, every hour, or even once a day. Used in this way, Beacon will queue all commands you provide, download them on check-in, and execute them one by one after a check-in.


Beacon has some remote administration tool features. You may upload and download files through it. Beacon will track all file downloads and grab a piece of each file with each check-in. This makes it possible to exfil a large file to multiple callback hosts in a low and slow way. You may also use Beacon to execute commands.

The Metasploit Framework spoils us with a common interface for most hacking actions. That said, most of the things we do in the Metasploit Framework are do-able with a stand-alone executable or a built-in Windows command. If you have an arsenal of obfuscated post-exploitation tools and you’re comfortable doing things by hand—you can execute a majority of your engagement through Beacon without lowering the sleep time.

If you only use Beacon with a high sleep time to control compromised hosts—you will make it very hard for a network defense team to notice you.

Advanced Threat Tactics?

Each of these options represents different levels of sophistication. When you read about “advanced persistent threat” activity, try to match what you’re reading with these options. When you read about an actor’s use of an extremely simple beaconing RAT, ask—what does this actor use for post-exploitation? When you read about an actor’s use of Poison Ivy, ask—what does this actor use for their foothold and persistence? When you read about a campaign that lasted several years, ask—how did this actor preserve their freedom to regain control of any host, at any time, without raising suspicion? When you hear the tales of suspense about the actors that never get caught, ask—how did they do it? And finally, when you read about an advanced threat actor, ask “How can I help my customers understand their ability to detect and respond to this?” 


Cobalt Strike 01.08.14 – EXE Artifacts: A New Hope

January 8, 2014

Cobalt Strike has always exposed the Metasploit Framework’s tool to generate executables. Unfortunately, these executables are caught by anti-virus products. I’ve had a lot of feedback about this and I know it’s annoying.

The latest release of Cobalt Strike now generates artifacts from its own Artifact Kit.

The Artifact Kit is a proprietary source code framework to build binaries that smuggle payloads past anti-virus.

Customers have access to the Artifact Kit and its source code through the Cobalt Strike Arsenal. If the default technique gets caught–go to the arsenal, grab the Artifact Kit, and modify one of the existing techniques. Much like the Applet Kit from last year, I also provide a simple Cortana script to force Cobalt Strike to use your modifications over the built-in stuff.

The Artifact Kit generates x86 executables, x86 service executables, x86 DLLs, and x64 DLLs. This collection of output gives you a lot of flexibility for privilege escalation and backdoors.

Cobalt Strike’s psexec dialogs and Firefox add-on attack dialog now use the Artifact Kit to generate executables too.

Cryptolocker-style Social Engineering Attack

And, while we’re on the topic of executables, I’ve added a new social engineering package to Cobalt Strike—the Windows Dropper Trojan.

A common social engineering attack is to send a zip file that contains an executable designed to look like a document. When run, this executable opens a document, and silently executes the attacker’s malware. This is one of the ways Cryptolocker spread.

I’d call this low on the sophistication spectrum—but hey, it works!

Cobalt Strike’s Windows Dropper attack lets you generate an executable that stages a payload and opens a document to fool the user into thinking everything is OK. This attack also ties into Cobalt Strike’s Artifact Kit to generate the executable.

Fresh Paint for the MS Office Macro Attack

A long time favorite red team tactic is to embed a macro into a Word or Excel document. This release of Cobalt Strike updates the MS Office Macro Attack to automatically spawn your listener into an external 32-bit process. This way, if your target closes Office or if they’re using the 64-bit version of Office—your attack will still work.  This is an example of how Cobalt Strike goes beyond proof-of-concepts to launch attacks that succeed against real targets.

These items are the highlights that fit together in a theme. This release of Cobalt Strike is also redirector friendly (expect a blog post on this later). Check out the release notes for a full list of changes. If you’d like to give Cobalt Strike a try—grab the 21-day trial.


Man-in-the-Browser Session Hijacking

December 23, 2013

Malware like Zeus and its variants inject themselves into a user’s browser to steal banking information. This is a man-in-the-browser attack. So-called, because the attacker is injecting malware into the target’s browser.

Man-in-the-browser malware uses two approaches to steal banking information. They either capture form data as it’s sent to a server. For example, malware might hook PR_Write in Firefox to intercept HTTP POST data sent by Firefox. Or, they inject JavaScript onto certain webpages to make the user think the site is requesting information that the attacker needs.

Cobalt Strike offers a third approach for man-in-the-browser attacks. It lets the attacker hijack authenticated web sessions–all of them. Once a user logs onto a site, an attacker may ask the user’s browser to  make requests on their behalf. Since the user’s browser is making the request, it will automatically re-authenticate to any site the user is already logged onto. I call this a browser pivot–because the attacker is pivoting their browser through the compromised user’s browser.


Cobalt Strike’s implementation of browser pivoting for Internet Explorer injects an HTTP proxy server into the compromised user’s browser. Do not confuse this with changing the user’s proxy settings. This proxy server does not affect how the user gets to a site. Rather, this proxy server is available to the attacker. All requests that come through it are fulfilled by the user’s browser.

For a penetration tester, this approach to a man-in-the-browser attack is interesting. Here’s why:

  • It’s site agnostic. You don’t have to customize the attack for each site you want to target. This is good, because penetration tests are time constrained.
  • The browser pivot is a very visual demonstration. You open your browser and go to a sensitive site. Voila, you’re there as the user. This is a very powerful way to demonstrate risk to an executive and convey what an advanced threat actor could do once they compromise a system.
  • It’s hard to detect. All of the attacker’s activity is mixed in with the user’s legitimate activity. All requests come from the same browser. How do you sort this out? If you’re a penetration tester replicating an advanced actor, you want capability in your kit that challenges your customers.

If your work involves stealing data to demonstrate risk and highlight a viable attack path, the utility of browser pivoting is apparent. This tool is a quick and seamless way to steal browser sessions. If the session is secured with a cookie, think of this tool as a convienence. If the session is secured by a client SSL certificate, whose private key is stored on a smartcard, then browser pivoting may be your only opportunity to steal that session. [Yes, this works.]

If you’d like to see Browser Pivoting in action, take a look at this new video. It demonstrates how to browser pivot into a webmail account, a local Wiki secured with HTTP server authentication, and a local Wiki secured with a client SSL certificated stored in a password protected keystore.


Why do I always use 32-bit payloads?

December 12, 2013

Yesterday, one of my customers asked about x64 payloads in Cobalt Strike. Specifically, he wanted to know why Cobalt Strike doesn’t expose them. I’ve already replied to the question, but I think it makes an interesting blog post.

Cobalt Strike’s listener management feature pretends that 64-bit payloads don’t exist. Beacon is a 32-bit payload with no 64-bit equivalent. This raises a question. Can I use Cobalt Strike to attack 64-bit Windows systems? Of course, the answer is yes.

Attacking 64-bit Applications on 64-bit Windows

If my attack will land in a 64-bit process, my approach is to make the attack smart enough to “do the right thing” and stage a 32-bit payload. Here are some examples of this:

Cobalt Strike’s Java Attacks inject shellcode into memory through a JNI DLL. The attacks ship with both 32-bit and 64-bit JNI DLLs. This allows the attacks to work from a 32-bit or 64-bit JVM. It doesn’t matter. The DLL is smart enough to spawn a 32-bit process and inject the 32-bit payload stager–even from a 64-bit process.

Cobalt Strike’s PsExec with PowerShell dialogs let you state whether the target system is 32-bit or 64-bit. When the target is a 64-bit system, Cobalt Strike will set the proper Metasploit Framework option to use the 32-bit version of PowerShell to stage the desired payload.

If you’re using psh_web_delivery to stage a payload (a new favorite module), change the one-liner to include the path to 32-bit PowerShell when you’re targeting a 64-bit system. It’ll work.

c:\windows\syswow64\WindowsPowerShell\v1.0\powershell.exe [blah]

While it’s not technically an attack that delivers a payload, Cobalt Strike’s Browser Pivoting feature is smart enough to detect a 32-bit or 64-bit Internet Explorer process. It will inject the right DLL to enable the activity.

Attacking 32-bit Applications on 64-bit Windows

On the flip side, if the application I’m targeting is a 32-bit application, I have to deliver a 32-bit payload to it anyways. 32-bit applications in a 64-bit world are more common than you may initially think.

The default Microsoft Office package is 32-bit. A 64-bit package is available, but Microsoft makes the user jump through a lot of hoops to grab it. Why? According to Microsoft, the 64-bit package offers little benefit to the user at the expense of breaking compatibility with existing add-ons.


The Microsoft Office 64-bit Download screen. You must skillfully find and click two small links, away from the normal Download page to even get here.

Similarly, modern versions of Windows include both 32-bit and 64-bit versions of Internet Explorer. The 32-bit version of Internet Explorer is the default for Windows 7. It looks like it’s this way for Windows 8 too. Defaults are one thing, but ground truth reality on your customer’s network is what matters most. Cobalt Strike’s System Profiler will detect if a 32-bit or 64-bit Internet Explorer is in use and make that information available to you.


Cobalt Strike’s System Profiler run against 64-bit Internet Explorer on 64-bit Windows 7. Notice the *64 next to these applications.

Exploits that target 64-bit Applications

All of that said, you may still want a 64-bit payload to deliver when you attack a 64-bit application. Let’s take a look at the list of Metasploit Framework Windows exploits that support 64-bit targets:

# pwd
# grep -r ARCH_X86_64 .
./smb/psexec_psh.rb:          [ 'Windows x64', { 'Arch' => ARCH_X86_64 } ]
./postgres/postgres_payload.rb:        [ 'Windows x86_64',    { 'Arch' => ARCH_X86_64 } ],
./local/ms13_005_hwnd_broadcast.rb:        [ 'Windows x64', { 'Arch' => ARCH_X86_64 } ]
./local/wmi.rb:            [ 'Windows x64', { 'Arch' => ARCH_X86_64 } ]
./local/ms10_092_schelevator.rb:      'Arch'          => [ ARCH_X86, ARCH_X86_64 ],
./local/always_install_elevated.rb:      'Arch'          => [ ARCH_X86, ARCH_X86_64 ],
./local/ikeext_service.rb:          [ 'Windows x64', { 'Arch' => ARCH_X86_64 } ]
./misc/psh_web_delivery.rb:          [ 'Windows x64', { 'Arch' => ARCH_X86_64 } ]
./http/oracle_endeca_exec.rb:      'Arch'        => [ ARCH_X86_64, ARCH_X86 ],
./winrm/winrm_script_exec.rb:      'Arch'          => [ ARCH_X86, ARCH_X86_64 ],

Most of these attacks can deliver a 32-bit payload on a 64-bit system with the right options set (e.g., EXE::Custom, RUN_WOW64, etc.)

Post Exploitation Considerations

There is one place where you need a 64-bit payload though. Some post-exploitation tasks will fail if you attempt them from a 32-bit payload on a 64-bit system. For example, when you run mimikatz from Meterpreter, the current process’s architecture must match the native architecture. That said, you have the option to migrate a 32-bit Meterpreter to a 64-bit process and it’ll magically work.

Now, let’s get back to the original question: why do I always use 32-bit payloads? I use 32-bit payloads because they work in most situations. I’m either targeting a 32-bit application or I’m using an attack that’s smart enough to adjust accordingly. There are few attacks in the Metasploit Framework that exclusively require a 64-bit payload. I can migrate to a 64-bit process if I need to. Right now, I don’t see a benefit to adding 64-bit listeners into Cobalt Strike’s workflow. What are your thoughts?


Stealthy Peer-to-peer C&C over SMB pipes

December 6, 2013

Beacon is my payload for low and slow control of a compromised system. Recently, I added peer-to-peer communication to Beacon. When two Beacons are linked, the child Beacon will get its tasks from and send its output through its parent. Linked Beacons use SMB pipes to communicate. This is a big win for stealth. If a workstation Beacon communicates with a domain controller Beacon over SMB, who would notice?

I invested in this feature for several reasons: I wanted the ability to control an internet isolated host with Beacon. I also wanted to control many compromised systems through one or two egress hosts. And, I thought it would be really cool to tunnel a Meterpreter session over SMB. These things are all doable now.


Cobalt Strike‘s Beacon isn’t the only offensive tool to use named pipes in this way. The Red October malware (see the Kaspersky report) has this feature. The Duqu malware that Symantec analyzed has this ability too. If you want to replicate the C&C styles of advanced threats, Cobalt Strike has you covered.

SMB Named Pipes

Let’s go through how this communication mechanism works. It’s actually pretty easy. A named pipe is an inter-process communication mechanism on Windows.

The CreateNamedPipe function will set up a named pipe. The PIPE_ACCESS_DUPLEX flag makes the named pipe into a bi-directional channel.

HANDLE server;
server = CreateNamedPipe("\\\\.\\pipe\\crack", PIPE_ACCESS_DUPLEX, ...);

The CreateFile function connects to a named pipe.

HANDLE client;
client = CreateFile("\\\\.\\pipe\\crack", GENERIC_READ | GENERIC_WRITE, ...);

Use the ReadFile and WriteFile functions to read data from and send data through a named pipe.

Named pipes become interesting when they communicate between processes on separate hosts. Change the period in the pipe name to an IP address. Now the client will communicate with the pipe on the remote system.

HANDLE client;
client = CreateFile("\\\\\\pipe\\crack", GENERIC_READ | GENERIC_WRITE, ...);

Named pipe communication between hosts is encapsulated in SMB. Here’s what it looks like in Wireshark.


This communication method is not without its constraints. Any system I link to must have port 445 open. If I use a Beacon peer to control a key server, like a domain controller, this isn’t unreasonable. Any Beacon that connects to another Beacon must have an access token or it must establish an SMB session with the target first. This is because Beacon does not create an anonymous pipe. An anonymous pipe would require a change in the registry.

In-Memory Backdoor

For Beacon users, this peer-to-peer technology isn’t just a new data channel. It’s also an opportunity to use Beacon as an in-memory backdoor for Windows hosts.

Once you deliver a Beacon peer to a host (or use mode smb to turn a Beacon into a peer), it creates a named pipe and waits for a connection from another Beacon. You may link to it right away. You don’t have to though. After you link to a Beacon, you may unlink it at any time. When you unlink a Beacon peer, it waits for a connection from another Beacon.

Flexible Tunnels

Tunneling traffic through linked Beacons works like you’d expect. If I create a Meterpreter session, tunneled through a Beacon peer, that traffic will reach Cobalt Strike through the peer’s parent Beacon.

Let’s say I unlink a Beacon peer while tunneling a Meterpreter session through it. Then I quickly link that Beacon peer to another Beacon. What happens to my tunneled session? Nothing. My tunneled session will continue to work. Its traffic will go through the new parent Beacon. This is quite neat. You’re redefining a tunnel’s egress host, on the fly.

There’s a lot of possibility here.


Cobalt Strike 1.48 – Peer-to-peer C&C

November 21, 2013

I’m pleased to announce Cobalt Strike 1.48. This release introduces a peer-to-peer data channel for Beacon, improves browser pivoting, and updates the signed applet attack with options the latest Java 1.7 updates require.

Peer-to-Peer Beacon

It’s hard to stay hidden when many compromised systems call out to the internet. To solve this problem, Beacon now supports peer-to-peer command and control. This feature lets you link Beacons to each other. Linked Beacons download tasks and send output through their parent Beacon. To blend in with normal traffic, linked Beacons use SMB pipes to communicate.

What if you need to control a system that can’t connect to the internet? Use the “beacon (connect to target)” listener in the PsExec and PsExec (PowerShell) dialogs. This will run a ready-to-link Beacon on a host, without the need to connect to the internet to stage.

All Beacon features work through this peer-to-peer scheme, including the ability to tunnel Meterpreter and Metasploit Framework attacks through Beacon.

Beacon’s peer-to-peer feature is a quiet way to hold systems and limit your network egress points to one or two hosts.

This feature is similar to the peer-to-peer command and control found in advanced threat malware [12]

Browser Pivoting Updates

Browser Pivoting now works with 64-bit Internet Explorer.

The browser pivoting tab now displays the output of the process injection step too. If your browser pivot setup didn’t work, failed process injection is probably the culprit. If you see the process injection step fail, migrate Meterpreter to explorer.exe and try again.

If you’re not familiar with browser pivoting yet, it’s worth your time to look at it. Once your target authenticates to a website, browser pivoting allows you to inherit their access through your browser. Some dismiss this as equal to simple cookie stealing. This is far from the truth. Browser Pivoting uses your target’s browser to re-authenticate to a site, grab a resource, and display the results in your browser. This method works even when a session is secured with a client SSL certificate or HTTP authentication. Cookie stealing? Pshaw!

Java Applet Updates

New versions of Java 1.7 show a big scary warning for signed applets that lack a few manifest options. This update adds these manifest options to the signed applet in Cobalt Strike. The Applet Kit source in the arsenal is up to date as well. If you use a custom applet with Cobalt Strike, I recommend that you sync changes to avoid this warning.

To learn more about what’s new in Cobalt Strike 1.48, read the release notes. A 21-day trial of Cobalt Strike is available at Licensed users simply need to run the update program to get the latest.


Get every new post delivered to your Inbox.

Join 11,412 other followers