Red Team Archives - Page 4 of 7 - Cobalt Strike Research and Development

Training Recommendations for Threat Emulation and Red Teaming

A few weeks ago, I had someone write and ask which training courses I would recommend to help setup a successful Red Team program. If you find yourself asking this question, you may find this post valuable.

First things first, you’ll want to define the goals of your red team and what value it’s going to offer to your organization. Some private sector internal red teams do a variety of offensive tasks and work like an internal consulting shop to their parent organization. If you think this is you, please don’t ignore some of the tasks that may fall on your plate such as reviewing web applications and evaluating different systems for vulnerabilities/bad configuration before they’re added to your environment. I don’t do much with this side of red team activity and my recommendations will show this gap.

When I think about red teaming, I think about it from the standpoint of an aggressor squad, a team that emulates a sophisticated adversary’s process closely to look at security operations from a holistic standpoint not just a vulnerability/patch management.

I see several private sector red teams moving towards something like Microsoft’s model. Microsoft uses one of their red teams to constantly exercise their post-breach security posture and demonstrate a measurable improvement to their intrusion response over time. Their white paper covers their process and their metrics very well.

If the above describes you, here are the courses I’d go for when building out a team:

1. I’d have everyone work to get the OSCP certification. The offsec courses are good fundamental knowledge every offensive operator should know.

2. Veris Group’s Adaptive Threat Division teaches an Adaptive Red Team Tactics course and they’ll come to your organization to teach it. The Veris Group’s red team class focuses on data mining, abusing active directory, and taking advantage of trust relationships in very large Windows enterprises.

This talk is a good flavor for how the Veris folks think:

Veris Group is teaching Adaptive Red Team Tactics and their Adaptive Penetration Testing courses at Black Hat USA 2015.

3. Silent Break Security teaches a course called Dark Side Ops: Custom Penetration Testing. Silent Break sells primarily full scope pen tests and their selling point to customers is they use custom tools to emulate a modern adversary.

This course is the intersection of malware development and red team tradecraft. They give you their custom tools and put you through 15 labs on how to modify and extend their custom tools with new capability. Their process is dead on in-parallel with how I see full scope operations [1, 2].

Silent Break Security is teaching Dark Side Ops: Custom Penetration Testing at Black Hat USA 2015.

4. I’d also consider putting your money on anything from Attack Research. I plan to eventually take their Tactical Exploitation course. Their Meta-Phish paper from 2009 had more influence on how I think about offense than anything else I’ve read. I have friends who’ve taken their courses and they say they’re excellent.

Tactical Exploitation

MetaPhish

Tactical Exploitation is available at BlackHat USA 2015 as well.

5. I’d invest in a PowerShell skillset and take a course or two along these lines. Most of the high-end red teams I see have bought into PowerShell full-bore for post-exploitation. As a vendor and non-PowerShell developer, I had to embrace PowerShell, or watch my customers move ahead without me. They’re going this way for good reason though. Using native tools for post-ex will give you more power with less opportunity for detection than any other approach. I don’t know of a specific course to point you to here. Carlos Perez (DarkOperator) teaches a PowerShell for Hackers course at DerbyCon and it gets very good reviews.

6. If you’re interested in Cobalt Strike, I do offer the Advanced Threat Tactics course. My course is primarily a developer’s perspective on the Cobalt Strike product. This course is similar to the Tradecraft course except it includes labs, an exercise, and it’s up to date with the latest Cobalt Strike capabilities.

The First Five Minutes

March and April are CCDC season. This is the time of the year when teams of college students get to compete against each other as they operate and defend a representative enterprise network from a professional red team.

CCDC events are the most interesting for the blue teams and red teams when the red team plays the role of an embedded attacker. Getting embedded into student networks doesn’t come for free though. Most CCDC events do not allow the red team to touch the networks before the students do. Often times, the students and the red team get access to the networks at the same time. Here’s a clip from one of the regional events last year:

Once the event starts, the first minutes are critical. To ensure a good competition, the red team needs to discover the vulnerable systems (or find out the default credentials), get access to these systems, and install persistence on them. These actions have to happen across 10+ networks and they have to happen before the student teams take their vulnerable systems off of the network for hardening.

I’ve seen events where the above goes off without a hitch. I’ve seen events where disaster struck right away. Last year at National CCDC, the hotel staff plugged a mini-fridge into the red team’s circuit at the start of the event. We lost all power and had a good five to ten minute setback because of it.

I’ve also seen scripts fail causing each individual red team member to scramble, gain what access they can, and try to persist or do anything they possibly can in those critical minutes.

I used to rely on scripts to scan for systems, exploit them, and install persistence. Sometimes these scripts would work great. Other times I’d miss a detail and squander the precious starting minutes troubleshooting the script. Now, I do many things by hand, but still try to stay efficient.

Here’s my process:

To quickly discover interesting hosts in a CCDC event, I run an nmap scan for two ports: 445 and 22. I setup my command to run this scan and wait until the red team lead yells go to press enter.

db_nmap -sV -O -T4 -p 22,445 [student ranges here]

Once the scan completes, the Metasploit Framework will import the results into its database. In Cobalt Strike, these hosts will show in the target area at the top of the tool. I almost always work with the table view at a CCDC event. To do this, go to Cobalt Strike -> Set Target View -> Table View.

From the table view, I can sort my discovered hosts by any of the columns. The far left column is the operating system icon. If you sort by this column, you will find that like-operating systems are now sorted together. This makes mass exploitation, without a script, rather easy.

To mass exploit the UNIX systems, I simply highlight all like UNIX systems in the interface. I right-click, go to Login -> SSH. I then put in what I think are the default credentials. The launch button will launch the Metasploit Framework’s ssh_login module against all highlighted hosts.

One pro-tip: hold down shift when you click Launch. Cobalt Strike will keep the dialog open allowing you to quickly try another username and password combination. I repeat this process until something works.

To mass exploit Windows systems, I do the same thing, except I use psexec to get my Windows accesses. When you launch psexec in Cobalt Strike, I recommend that you set it up to deliver a Beacon payload. This is Cobalt Strike’s asynchronous payload and it’s very resilient to network latency and other interruptions. You will have no shortage of either of these in the beginning of a CCDC event.

Now at this point, you should have access to some Windows and UNIX systems on all teams. The next task is to lay down persistence on these systems. This is the part I script with Cortana.

UNIX systems are easy to work with in Cortana. Cortana provides functions to issue commands and upload files through a shell. When I built these functions, I did my best to make sure each command happens in order before proceeding on to the next step. UNIX persistence scripted with these commands tends to work reliably. To build UNIX persistence scripts and backdoor droppers, I borrow heavily from int128’s infect.cna script.

What about Windows persistence? This is a sad tale of woe. In 2012 and 2013, I would use Cortana to script my Windows persistence through Meterpreter. Last year, Meterpreter would consistently crash when I issued all of my persistence commands to it. Stuck in a pickle, I put together an emergency API to automate a few things in Beacon. This API isn’t a substitute for a real Beacon scripting API (it’s coming!), but it worked in a pinch.

This emergency API allows a script to task Beacon to execute commands, upload files, and timestomp files. Beacon executes each of its task in one thread and it doesn’t move on to the next task until the previous task has had reasonable time to complete. This makes it easy to build a very reliable persistence script through Beacon. I wrote a blog post on this emergency API two weeks ago.

Another key to success is good infrastructure. I never know what to expect at a CCDC event. If the event is isolated from the internet, I make do with binding multiple IP addresses to my team server Linux boxes in red space. If the competition systems have internet access, I leverage Amazon’s EC2 quite heavily. I’ve seen some teams, knowing this factoid, block all of Amazon’s space. I think this is outside the spirit of the competition, but that’s white cell’s call and not mine. When I setup infrastructure in EC2, I tend to follow the team server organization scheme described in my infrastructure for on-going red team operations post.

And, that’s the process I use. If you’re curious about what the first hour looks like on my end, here’s my screen recording from RIT SPARSA’s ISTS event two weeks ago. In it, you’ll see the opening salvo and then my process to account for accesses, fix my scripts on the fly, and work to get into systems that I wasn’t able to get access to initially.

I’ll close this blog post with one question: should it be this way? CCDC and other events like it usually give students dated operating systems to allow the red team an easy foothold. Outside of this community, I’ve seen events where blue players defend larger networks with modern operating systems and pre-existing defenses in place. In these scenarios, the red team pre-seeds their access or relies on a click from a “user” who has access to the target’s environment. We use the access we have to play the role of an embedded attacker and execute actions or capture flags that satisfy blue training requirements. The blue teams work to detect, understand, and mitigate our activity. These types of games exercise blue team work, technical skills, and analysis in a security operations context. When I think about how I’d like to see CCDC evolve, this is a model I’m favorable to. What’s the right way forward? I’m not certain, but so long as CCDC and events like it continue to motivate students to practice critical security skills, I’m happy to work with the current model.

My Favorite PowerShell Post-Exploitation Tools

PowerShell became a key part of my red team toolkit in 2014. Cobalt Strike 2.1 added PowerShell support to the Beacon payload and this has made an amazing library of capability available to my users. In this post, I’d like to take you through a few of my favorite collections of PowerShell scripts.

beaconpowershell

PowerSploit

Let’s start with PowerSploit. This is a post-exploitation toolkit originally put together by Matt Graeber with contributions from Chris Campbell, Joe Bialek, and others. When I use Beacon, this toolset is almost a drop-in replacement for features that I would normally need Meterpreter to get to.

For example, if I want to use mimikatz to dump plaintext credentials, I simply import the Exfiltration/Invoke-Mimikatz.ps1 script and call the Invoke-Mimikatz cmdlet. Simple.

PowerSploit also features several great tools to steal credentials in other ways, log keystrokes, and take screenshots.

PowerUp

Every Christmas, I ask Santa for a privilege escalation vulnerability scanner. This has long made sense to me. When I have access to a system, I am in a good position to conduct automated reconnaissance and identify a known weakness to elevate with. Will Schroeder answered my wish with the PowerUp tool. This PowerShell script interrogates the system in several ways to find a privilege escalation opportunity. It even offers some helpful cmdlets to help you take advantage of the misconfigurations and weaknesses it finds. To use PowerUp I just import PowerUp.ps1 into Beacon and run the Invoke-AllChecks cmdlet.

PowerView

Last in my list is PowerView (also by Will Schroeder). This script is a full toolkit to interrogate a domain for hosts, users, and complex trust relationships. I probably use less than 10% of its potential capability right now. I tend to use PowerView to list hosts on a network and to quickly find out where I may have admin rights with my current token. This has become one of my first network reconnaissance tools and it has eliminated a need to scan for targets in many cases. My favorite PowerView cmdlets are Invoke-Netview and Invoke-FindLocalAdminAccess.

Another Night, Another Actor

Earlier last year, I had a frantic call from a customer. They needed to make a small change to Beacon’s communication pattern and quickly. This customer was asked to spend a week with a network defense team and train them on different attacker tactics. Each day, my customer had to show the network defense team all of their indicators and walk them through each of their activities. After a few days, this network defense team was able to zero in on Cobalt Strike’s Beacon and they were having trouble conducting other types of training activity because of this.

A blue training audience gets the most benefit from a red team’s activity when the red team shares their indicators, tactics, and knowledge with them. Clear indicator information allows the blue team to look at their sensors and see what they missed when they tried to put the story together. An open discussion of favored tactics (e.g., ways to do lateral movement, techniques like the Golden Ticket, etc.) allows a blue team to address major gaps in their defenses.

For red teams, openness comes at a cost. Tools and capabilities are expensive to buy or time-consuming to build. A red team’s effectiveness comes down to skilled operators and tools that give them freedom to work in a network. You need both. A poor operator will misuse a good tool. Depending on the maturity of the training audience and environment, a skilled operator may find themselves completely unable to operate without good tools to support them.

When a red team gives up all of their operating information, they’ve given their training audiences a gift-wrapped roadmap to detect their activity now and into the future. It’s a lot harder to play the role of an unknown adversary when your tools are well understood by the training audience.

To deal with this problem, most red teams choose to keep information about their tools and tactics close hold. They’re relying on a strategy of obscurity to protect their investment and to extend the productive life of their current technologies. This is at direct odds with what a red team should offer.

I think about this problem a lot. I sell a public solution that allows red teams to operate. I do not have the luxury of obscurity. I also don’t want obscurity. I want the training audiences I work with to get the most benefit possible from the red team activity my customers and I conduct. This means my customers need to feel safe disclosing details about their operations and their use of my tools.

I’ve made some headway on this problem and it’s one of the things in Cobalt Strike I’m most proud of.

On-disk, Cobalt Strike has its Artifact Kit. This is my source code framework to build all of Cobalt Strike’s executables and DLLs. My customers get the source code to this framework and they have the freedom to change this process and introduce other techniques to evade anti-virus. Cobalt Strike also plays nice with the Veil Evasion Framework. It’s trivial to export one of Cobalt Strike’s proprietary stagers in a Veil-friendly format too.

Network indicators are another story. Once a blue team understands what your tool looks like on the wire, it’s generally game over for that capability. Cobalt Strike has a good handle on this problem too. Malleable C2 lets Cobalt Strike’s end-users change Cobalt Strike’s indicators on the wire.

Specifically:

You get to transform and define where in a POST and GET transaction Beacon stores its metadata, output, and tasks. If you want to base64 encode an encrypted task and wrap it in HTML you’re welcome to do that. If you want to stick your encrypted tasks in the middle of an image, this is trivial to do too.

You get to dress up your transaction with extra indicators. You can add whichever client and server headers you want to HTTP POST and GET transactions. You can add arbitrary parameters to your GET and POST requests. You also get to define the URLs used for each of these.

These two pieces combined together give you a lot of control over what Cobalt Strike’s Beacon looks like on the wire. If you want, you can look like known malware. Or, you can blend in with existing traffic. Or, do something in between to adjust your activity to what your training audience is ready for.

Now, what about that customer? Sadly, Malleable C2 didn’t exist at the time of that call. We were able to figure out a one-off work-around for their situation. Today it’s a different story. Between Artifact Kit and Malleable C2, it’s quite feasible to make Cobalt Strike look like a new actor. You can do this on a weekly or even daily basis, if you need to. This flexibility is a big step towards resolving the openness versus future effectiveness conflict.

DNS Communication is a Gimmick

I added DNS Communication to Cobalt Strike in June 2013 and refined it further in July 2013. On sales calls and at conferences I get a lot of questions and compliments on this feature. That’s great.

I’ve also heard the opposite. I’ve heard folks say that DNS Command and Control is noisy. It’s “easy to detect”. I’ve had someone go so far as to say that it’s a gimmick.

I have a philosophy: I like options. I have a preferred way to work. I stay aware of how this preferred way may break down. When this happens, I like to know I can still work and get things done. Cobalt Strike’s DNS C2 is a great example of how this philosophy influences my development choices.

I released Beacon in the 27 Sept 2012 release of Cobalt Strike. This first Beacon could beacon over DNS or HTTP. The DNS beacon would periodically make an A record request to a domain that I, the attacker, am authoritative for. My server would provide a response that told the Beacon whether or not it should make an HTTP request to download its tasks. I built this Beacon for stealth. By checking for requests with DNS, I limit how often my compromised systems need to connect directly to me.

dnscomms2

The above is not easy to detect. I’ve had folks tell me that they see this behavior in production. One A record request every 24-hours or week is not trivial to find. This is scary.

In the first half of 2013 I had several opportunities to use Cobalt Strike. I took advantage of the DNS Beacon as a persistent agent. During this time I ran into a scenario I call “the child in the well”. I would see a compromised host beacon, but it would never connect to me to download its tasks. This is a terrible situation. My compromised system can call out to me. I know it’s there. But, I can’t reach it. This happened to me twice and I knew I needed to do something about it.

I added a mode command to the DNS Beacon. This command allows the end-user to state which data channel Beacon should use to download its tasks. When a tasking is available, I communicate this channel preference to the DNS Beacon in my 4-byte A record response.

I added modes to communicate over HTTP, DNS A records, and DNS TXT records. Each of these channels has their purpose and I allow the user to switch back and forth between them for each deployed DNS Beacon.

The HTTP data channel is the default. The compromised system connects to me with a GET request to download its tasks. It uses a POST request to send output when it’s available.

If I run into a child in the well scenario I have a choice between the two DNS data channels.

I used to use Beacon primarily as a lifeline to send sessions to other team servers. The A record channel is in the spirit of this original use case. I can task the Beacon and it will download its tasking 4-bytes at a time. If the system can Beacon to me, then I have some option to control it. The A record data channel isn’t efficient, but it works in a pinch.

I added the TXT record channel at the same time I built a SOCKS proxy server into Beacon. This was July 2012. I built these capabilities into Beacon to keep with an offense in depth philosophy. If I can’t get out of a network on any channel, except DNS, I need a way to continue to work. I saw pivoting as essential to this and so I built the SOCKS proxy server. The TXT record channel is suitable for tunneling some traffic through a Beacon.

I hope this post helps shine light on how I use DNS for covert communication. As a beacon with a high sleep time–it’s stealthy. As a data channel, it’s useful when there are no other options. Which option makes sense will depend on your context. The ability to rationalize context to tool comes from mature tradecraft.

Pass-the-(Golden)-Ticket with WMIC

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:172.16.48.83 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:172.16.48.83 process call create “stuff”

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

How did your hacking-style change in 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?

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

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.

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

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.

The Best DerbyCon 2014 Talks for Red Teams

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.