Archive for the ‘Red Team’ Category

h1

Pass-the-(Golden)-Ticket with WMIC

January 7, 2015

One of my favorite blog posts from last year was the Adversary Tricks and Treats post from CrowdStrike. They showed how one of the actors they track changed their tactics to cope with a more alert defender.

This actor, DEEP PANDA, sometimes injects a Golden Ticket onto their local Kerberos tray. To move laterally, this actor uses this trust to enable the RDP sticky keys backdoor on target systems. The actor then RDPs to the target and uses this backdoor to get a SYSTEM level command shell. Nothing to it.

When I read about interesting tradecraft, I like to reproduce it in a lab. According to CrowdStrike, this actor uses wmic to pass the Golden Ticket and execute their commands on the target systems.

I stood up a test system and used kerberos_ticket_use in Beacon to ingest a Golden Ticket. I then tried to execute a command on a Windows 8 system with WMIC:

wmic /node:WIN8WORKSTATION process call create “stuff I want to run”

This command failed with an access denied. Picture a Sad DEEP PANDA face here. After some digging, I found that there’s a flag I need to specify. To pass a Kerberos ticket with WMIC, use /authority:”kerberos:DOMAIN\TARGET” on your WMIC command line. So in this case:

wmic /authority:”kerberos:CORP\WIN8WORKSTATION” /node:WIN8WORKSTATION process call create “stuff”

That’s how you pass a Golden Ticket with WMIC.

h1

How did your hacking-style change in 2014?

December 30, 2014

The end of the year is always a good time for reflection. As you close out your year, I encourage you to ask: how did your style of hacking change and evolve in 2014? I suspect most of us have some answer to this question. We’re always learning and becoming informed by new tricks.

Here’s how my personal hacking-style has changed in 2014.

PowerShell for Post Exploitation

There’s a lot of enthusiasm for PowerShell in the offensive community. I feel that these enthusiasts are split into two camps though. One camp advocates PowerShell as a tool to bootstrap a payload without worrying about anti-virus. Another camp develops all of their post-exploitation tools in PowerShell and operates through these tools.

This year, I came into the second camp. I would always acknowledge that there was great capability in PowerShell. But, the difficulty using these scripts with the tools I know [Meterpreter, Beacon] prevented me from experiencing it first hand.

This year, I took the time to integrate PowerShell into Cobalt Strike’s Beacon payload and remove this hurdle. Immediately, my eyes were opened to a whole universe of post-exploitation tools I didn’t have before.

Veil PowerUp has changed how I elevate my privileges. Now, one of my standard items is to use PowerUp to find misconfigurations on the compromised target before I look at other options.

Veil PowerView has changed how I interrogate a network, enumerate trusts, and look for targets I can jump to laterally.

And, PowerSploit combined with Beacon provides a very respectable post-exploitation toolkit.

Almost all of my post-exploitation is asynchronous now. I go interactive only when I need to tunnel another tool through a Beacon.

Lateral Movement without PsExec

My tools tend to expose the Metasploit Framework’s workflow for lateral movement. Dump hashes and use the psexec module to get a session on a host. Or, steal a token and use current_user_psexec to get to that host. If current_user_psexec fails [it will], know how to run an artifact on a remote system the manual way.

The workflow for lateral movement I use today is much different. Late 2013, I introduced the named pipe communication channel into Beacon. I saw some interesting possibilities for this channel, but during use, I could tell the supporting features were missing. These came in February 2014. I added the ability to generate artifacts that contain the entire Beacon payload and Beacon gained tools to elevate privileges and steal tokens.

The above was enough to move my lateral movement workflow away from Metasploit’s workflows. I now capture a trust through Beacon [net use, steal a token, import a kerb ticket] and use wmic, at, sc, or schtasks to run an artifact I copy to the remote target. This artifact is almost always an SMB Beacon. This is the Beacon variant that waits for me to link to it over a named pipe. This is very stealthy and it’s a very powerful way to use Beacon. Almost all of my lateral movement is asynchronous now.

Persistence without Malware

Another big change to my process came from Mimikatz and the Golden Ticket technique. This technique allows me to use the krbtgt hash taken from a domain controller to generate valid Kerberos tickets for any user I like. These tickets are not tied to the user’s password at all. This technique has changed how I do persistence. Now, I tend to pull the information I need to generate tickets at will and store it in an attacker-accessible Wiki. When I need access to a server or some other key asset, I generate a ticket, import it into Beacon, take the server, and then pull off of it when I’m done.

For defenders used to finding malware and cleaning it up, this is a big mental shift. They can’t just delete a bad binary and assume their network is clean. They have to think about which trusts the attacker had access to and how that might allow the attacker to reclaim control of their network at will. It’s an interesting problem.

I’ve always appreciated living on hosts without malware. In exercises, the sticky keys backdoor is useful. Periodically using Mimikatz to pull credentials to (re)use later is also a way to hold access. These techniques are fine but they carry risk [the RDP backdoor is easy to find, vigilant admins change their passwords]. The Golden Ticket allowed me to have confidence in and rely on malware-free persistence in a way that I just couldn’t before.

In terms of my tradecraft and thinking about how I “hack”, these are the three things that changed for me in 2014. What changed for you?

h1

What’s the go-to phishing technique or exploit?

December 17, 2014

This blog post is inspired by a question sent to a local mailing list. The original poster asks, what’s the go-to phishing technique or exploit in a blackbox situation? Here’s my response:

I’ve had to do this before, I sell tools to do it now, and I’ve seen how others teach and go about this particular process. First, I recommend that you read MetaPhish. No other paper or talk has influenced how I think about this process more:

You’ll notice I said the word process. Before you dig into a toolset, you’ll want to figure out the process you’re going to use. Here’s what I used and it has parallels with the processes I see others use now [regardless of toolset]:

0. Information Gathering

Find out about your target, harvest email addresses, etc. etc. etc.

1. Reconnaissance

This is the phase where you sample the target’s client-side attack surface. I used to send a few fake LinkedIn invitations across an org and direct those folks to a web app that profiles their browser. Similar information to what you see here: http://browserspy.dk/

I’ve seen some organizations use BeEF for this purpose and Black Squirrel does this as well.

2. Stand up a Test Environment

Next, I recommend that you create a virtual machine to mirror their environment as closely as possible. Install patches and other tweaks you think may be present. This isn’t the place to underestimate their posture. I’d also recommend trying out the different A/V products you expect to see at this point. Use the information from the reconnaissance step to make this as exact as possible.

3. Choose your attack

Now, you will need to select an attack to use against your target. I really recommend that you stay away from the memory corruption exploits in the Metasploit Framework. You can tweak them to get around some anti-virus products. But, you really need to pay attention to the exploit’s needs. For example, let’s say the target profile reveals a vulnerable version of IE and Metasploit has an exploit for it. What are the dependencies of that exploit? Does it also require Java 1.6 to help it get past some of Windows’ protections? You could play this game. Or, you could skip it altogether.

Many folks who execute these kinds of engagements regularly use user-driven attacks. A user-driven attack is an attack that relies on functionality and fooling the user into taking some detrimental action. The Java Applet attack is an example of a very popular user-driven attack. I’m surprised it still works today, but *shrug*. Embedding a macro into a Word or Excel spreadsheet is also effective.

The stock vba macro you can get out of MSF is also pretty good [it injects straight into memory]. I understand that BeEF has some options in this area too, but I haven’t played with them.

4. Pair your attack with a payload

Don’t take it for granted that you’ll walk out of your target’s network with a Metasploit Framework payload. I see egress as one of the toughest problems when working with a harder target. If you have to use a Metasploit Framework payload, windows/meterpreter/reverse_https is your best bet here. I recommend that you look for and consider other options though. A lot of organizations who do this kind of work have a custom payload or they buy one. If I were in a hurry to cobble up a process and didn’t have a budget, I’d look at building something in PowerShell. The main things you care about:

a. Is the payload proxy aware? Will it take the same actions that the user’s browser would take to get out to the internet?

b. Can I match the payload’s characteristics to the target environment? For example, making its User-Agent match something legitimate?

bb. If I opt to go SSL, can I use a legitimate certificate? If not, does the payload at least try to look like legitimate traffic if I communicate without SSL?

c. Is the payload asynchronous? You really want something reliable that doesn’t stand out while you figure out what to do next on your target’s network.

d. Can I pair this payload with my attack? This is an important consideration. If you have a great piece of custom malware but *can’t* pair it with your chosen attack, it’s not useful to you for this phase of your engagement.

Your custom payload [bought/built] does not need to be fully functional. Its main goal is to defeat egress restrictions and act as a lifeline while you figure out the best steps to fortify your access [if that’s what your customer wants]. The main thing it needs to be able to do is spawn another payload.

Here’s one of my favorite talks on how to pull something like this together, quickly:

I also recommend that you setup infrastructure for each piece of this attack. You should send phishes from different places. You should host your recon app on its own server. The server your user-driven stages your payload from should differ from the server the payload actually communicates with [if your payload is delivered in stages]. Ideally, your asynchronous lifeline payload should call home to multiple hosts in case one of them becomes blocked.

5. Deliver the package

The final phase is to send the package on to your target. I don’t recommend that you spray every email you found. If your goal is to demonstrate a targeted attack, be targeted.

Personally, I’m a stickler for pixel perfect phishing emails and I’m not a fan of crafting an HTML email in a hacker tool to achieve this. If in doubt, I recommend that you use the same email client that your legend [the person you’re pretending to be] would use to send the email. If your target is someone in HR and your legend is someone applying for a job, use Gmail to send your phish. Preferably, the same Gmail account noted in the resume.doc you embedded a macro inside of.

Before you phish, I recommend that you send your package to yourself, through infrastructure that mirrors your target environment as closely as possible. If your target uses a cloud email service, try to get an account on the free or low-tier paid version of this service and send your package to yourself there. If your target uses a more traditional Exchange+Outlook setup, see if you can build a lab with those pieces or rely on a friend who has access to something similar. The main point here is to make sure your lovingly crafted bundle of good isn’t going to the spam folder. It’d be a shame to go through all of this work to get stopped by that.

Even if you have a favorite “go to” user-driven attack, I recommend executing this process anyways. You don’t want to fire an attack package crafted for a Windows environment only to find that your target is a MacOS X shop.

Tradecraft parts 3, 4, and 8 cover these topics.

h1

Give me any zero-day and I will rule the world

October 30, 2014

A few months ago, I was having lunch at a favorite Italian restaurant in Washington, DC. I work in a residential area, which means lunch time is slow and there’s no crowd. This leads to many conversations with the staff. This particular conversation drifted to Time Magazine’s July World War Zero article about the sale of zero-day exploits.

What a strange world we live in. Zero-days are now common lunch conversation almost along the lines of talking about the weather.

I applaud the work our industry has done to educate the public about the risk of software vulnerabilities. That said, there is a down side. Most people, some who even work in security, only understand hacking as the exploitation of software vulnerabilities. They don’t think about the rest of the intrusion process or envision what steps the attacker takes after the compromise.

I see exploits as a small part of the hacking puzzle. If someone has an unpatched known vulnerability–bad on them and yes, they should address it. But, there are other ways to get a foothold in a network besides memory corruption exploits. Some targeted attacks involve sending documents or files that abuse known functionality. These attacks are low on the sophistication scale, but I know many penetration testers who continue to get footholds with Java Applet attacks. A memory corruption exploit might assist with the foothold, but it’s not a requirement to gain one.

Following the foothold is post-exploitation. A common attacker goal is to escalate privileges and capture a trust relationship that allows them to move within a domain. Here’s another place a memory corruption exploit may help. A memory corruption exploit against the local system may give me a free pass to elevated rights. Again, there are other ways to get this control. If the user is a local administrator, the attacker has full control of the current system. UAC is not a security boundary and in many cases, it’s trivial to bypass. And yes, the bypass can work on Windows 8.1. Let’s say the user isn’t a local administrator. Surely, one must have a memory corruption exploit to work, right? Wrong. Take a look at harmj0y’s PowerUp. This is a PowerShell script to search for opportunities to elevate based on weak permissions or configuration mistakes. A memory corruption exploit might assist with privilege escalation, but it’s not a requirement to escalate privileges.

Let’s discuss lateral movement and domain privilege escalation.

Lateral movement is the process where an attacker abuses trust relationships to gain control of other systems on the same domain. Lateral movement has its challenges. The attacker has to impersonate a user that a target system recognizes as an administrator. This trust information comes in many forms. An attacker might dump the encrypted passwords of local users associated with the system. If the Administrator account password is the same on another system, the attacker may use this password hash to authenticate to that system and carry out privileged actions. This is the pass-the-hash attack and it does not involve memory corruption. Another form of trust is an access token. This is a data structure, managed by Windows, that contains everything needed to allow a seamless single sign-on experience. An attacker can capture one of these tokens and apply it to their current session. Now, the attacker has the rights spelled out in this token and they may use it to interact with another system [if the target sees the user as an administrator]. This process does not require a memory corruption exploit.

Domain Privilege escalation is the process where an attacker takes systems to capture new trusts until they find a trust that gives them full control of the domain or get the data they’re after. If an attacker captures a token for a Domain Administrator user, it’s game over. The attacker has access to all systems joined to that domain. If the attacker captures a token for a domain user with administrator rights to some systems, the attacker may leverage that token to take control of those systems. This process does not require a memory corruption exploit.

It gets worse. With full control of the domain, the attacker can steal the secret that the domain’s security rests on. This is the password hash of the krbtgt user on a domain controller. If the attacker captures this information, the attacker has the freedom to leave your network for weeks, months, or years at a time. The attacker may come back through a phishing attack and apply a self-generated Kerberos ticket to their current session. With this shared secret in hand, the attacker may create a ticket that allows them to gain the rights of any domain user–without knowledge of that user’s password. In effect, this means the attacker may regain domain administrator rights at any time. This is the Golden Ticket Attack in Mimikatz and it does not require a memory corruption exploit.

I think memory corruption is cool, but hacking goes far beyond it. Hacking is understanding a system well enough to make it do things others didn’t intend. When I teach hacking now, I don’t cover memory corruption exploits. Too many people are stunted by this idea that they must scan for vulnerabilities, find one, and exploit it. This is old thinking. We should teach people that a well-built memory corruption exploit is one access or privilege escalation technique of many. By far, it’s not the whole game.

A penetration test that focuses on vulnerabilities and ignores most of the attack process doesn’t help a customer defend their network better. As offensive professionals, it’s on us to know the steps attackers take and to arm ourselves with knowledge and tools to reproduce them. If we can’t persist, move laterally, steal data, and defeat defenses in a credible way, what use are we to help customers understand their security posture? Creative thinking about these problems won’t happen if we focus too much on one (optional) piece of the hacking process.

h1

The Best DerbyCon 2014 Talks for Red Teams

October 6, 2014

DerbyCon is one of my favorite conferences. I think its review committee does a good job choosing talks that are relevant, not just novel for the sake of novel. I worked my vendor table the whole weekend, but thanks to Irongeek’s amazing speed at putting videos online, YouTube’s 2x playback feature, and post-con insomnia–I went through a lot of DerbyCon material. Here’s my list of talks that are most relevant to red team operations.

Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades

This is probably my favorite DerbyCon 2014 talk. Tim Medin demonstrates how to request Kerberos service tickets, dump them from memory, and crack the passwords of these service accounts. He then demonstrates how to forge new tickets with the cracked password and give yourself elevated rights in some service contexts. It’s a pretty amazing talk and it’s something I plan to play with in my lab.

Secrets of DNS

In this talk, Ron Bowes shows some interesting uses of DNS. All of this was just a warm up though. Towards the end he introduces DNScat 2, a post exploitation agent that uses DNS to communicate. He talks about some of the lessons learned from the original DNScat and goes through his roadmap to build up DNScat 2, including a planned SOCKS pivoting feature. He also took the time to share the challenges of building a communication channel on top of DNS. Things like queries sent multiple times, queries that arrive out of order, and caches that hold on to things forever. I know, first-hand, the amount of work it takes to pull something like this off and this talk is a must-watch for anyone who (ab)uses DNS as a data channel.

Passing the Torch: Old School Red Teaming and New School Tactics

In this talk David McGuire goes through “old school” ways to interrogate a domain, abuse trust relationships, and steal interesting data. These topics and this process don’t get enough attention in our community. David woke me up to this and it has had a major impact on how I hack over the past two years. To see this influence, compare the lateral movement videos I’ve cut over the past four years: 2011, 2012, 2013, and 2014.

Will Schroeder is one of the developers of the Veil Framework. He also writes a lot of awesome stuff [1, 2] in PowerShell. Like me, Will hates doing things a computer could do better. Will has worked to automate a lot of David’s tradecraft and develop some of his own.

The talk covers a lot of information very quickly. The big pay off is at the end when David and Will each execute their methodologies to show the Old School vs. New School way of hacking. Now that Cobalt Strike’s Beacon supports PowerShell, I expect that my process will evolve to rely on these new school tactics.

Et tu Kerberos

This talk is a great survey of the Golden Ticket attack in Mimikatz. Chris Campbell goes through recent history about pass-the-hash, talks about the Golden Ticket attack and where it came from, and offers some pointers on which mitigations do and don’t work.

Red Teaming Back and Forth 5ever

I used to work for Automattic, the company behind WordPress.com. Almost everyone in the company had an Apple computer. I’m Windows focused in my product and I’ve wondered what tactics work in a MacOS X environment. Fuzzynop provides the answer. In this talk, he goes through his quick and dirty C&C for MacOS X. He also digs into quick and dirty post-exploitation tricks for MacOS X as well. If you have to go against a MacOS X environment or you just want to watch an entertaining talk from a hacker who has to think different, I highly recommend this one.

Getting Windows to Play with Itself: A Pen Tester’s Guide to Windows API Abuse

This last talk comes from Brady Bloxham at Silent Break Security. I’ve known Brady since 2011 and he’s scary brilliant. In this talk, Brady challenges the audience to expand their capability-level beyond that of the casual attacker. This is an important call to arms and I agree with what Brady says here. This talk starts out with some advanced Windows persistence techniques, a primer on process injection, and tips to build on this material. The real pay off happens at the end. Brady introduces Throwback, a stealthy beaconing persistent-agent that’s now open source. You’ll want to check it out as a possible tool for your arsenal. If you want to learn to build your own tools, Brady Bloxham and Bryce Kunz are teaching Dark Side Ops: Custom Penetration Testing at BlackHat Trainings DC in December 2014.

If you watched these videos, you’ll notice there’s a theme. Each of these talks is a post-exploitation talk. Attackers will get in. We can’t just enumerate the ways this may happen. We have to help our customers understand their ability to slow down, detect, or frustrate a motivated and well-resourced attacker, post-compromise. Each of these talks operates with this fundamental assumption.

Each of these talks also demonstrates new tools and new approaches. You can’t represent a credible threat with commodity capability only. If you’re going to play at this level, you’ll need to  retool and rethink your approach. You can build capability or buy it.

Final note, trust relationships matter. There are many ways to attack and abuse trust. We’re just scratching the surface here. The best talks are going deep into this subject. This is the present and future of hacking modern enterprises.

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.

Follow

Get every new post delivered to your Inbox.

Join 14,458 other followers