Many folks take “configure your profile properly” for granted. A profile that passes a c2lint check isn’t guaranteed to work in all circumstances you throw at it. A lot of things can go wrong. For example, the CDN may rewrite your HTTP requests in ways that break your Malleable C2 profile. That’s what this blog post is about…

The profile used by Alex’s script is amazon.profile. I’ve noticed that many red teamers opt to use this profile with their first experiments to use CloudFront as a redirector for Cobalt Strike.

An Amazon Web Service and an Amazon-like profile, what could go wrong? A lot of things can go wrong. 🙂 If you’ve tried this setup, you may have found a console message [on the team server] that looks like this:

This message means Cobalt Strike could not recover information from an HTTP transaction. Some aspect of the HTTP transaction differs from the assumptions provided by your Malleable C2 profile.

Assumption is the key word. Malleable C2 gives operators a lot of power to change what Cobalt Strike’s HTTP communication looks like. Malleable C2 is an example of a declarative programming language. You, the operator, specify what Beacon’s communication should look like. Cobalt Strike figures out how to make that happen. Specifically, Cobalt Strike compiles your specification into two different programs. One program transforms data and stores it in a transaction. The other program recovers data from a transaction and reverses the transformations made to the data. These programs are patched into the Beacon payload and its controller. If the assumptions of these derived programs break, your communication breaks.

When the above happens, it’s helpful to know how to read the output above and use it to troubleshoot your communication.

Our error message states that Malleable C2 could not recover data from the http-get -> client -> metadata transaction. Beacon provides metadata to tell Cobalt Strike about the session. This RSA-encrypted blob includes situational awareness information (e.g., username, PID, hostname, etc.) and a unique key for the session. Without metadata, Cobalt Strike knows nothing about the session. It’s important that this part of the transaction works.

To resolve this issue, it’s our job to figure out how the expectations of the Malleable C2 profile differ from the reality of the HTTP request received by Cobalt Strike.

Where should we look? The right place is to look at the parts of the HTTP transaction relevant to our failed transaction.

Here’s what the .http-get.client.metadata block looks like in the (slightly modified) amazon profile I used with CloudFront:

The metadata block base64 encodes the metadata, prepends two strings to it, appends another string, and it stores the entire thing in the HTTP Cookie header. OK.

And, here’s a screenshot of the preview generated by c2lint:

In troubleshooting this specific issue, we should ask: does the HTTP Cookie header received by Cobalt Strike differ from the HTTP Cookie header Malleable C2 expects. If so, how and why?

Let’s look at the preview Cookie and the received Cookie side-by-side:

Here, the issue becomes a little more obvious. The Cookie received by Cobalt Strike has the same information, but the parts of the Cookie are in a different order. This is a change CloudFront made to our HTTP transaction. This breaks our profile.

Malleable C2 does not know the semantics of the Cookie field. To recover data from this transaction, it knows it must recover the value of the Cookie header, remove some appended strings, remove some prepended strings, and base64 decode what’s left. Any unexpected change (e.g., spaces removed, new strings, re-arranged strings, etc.) breaks this process.

What’s the solution? In this case, we could update the structure of our HTTP Cookie to match what CloudFront will transform it to. This would work just fine. We could also store our metadata in something other than the Cookie header. Either approach is OK.

Note: This metadata block will fail a c2lint check because of the space between ; and skin=noskin. c2lint’s advice is sound, but risk averse. Here, the space is necessary to match what we will receive after passing an HTTP transaction through CloudFront.

This blog post focuses on CloudFront because I’ve answered questions about this circumstance in the past. Profile assumptions can fail for other reasons. For example, if you change a profile mid-engagement, expect to see issues like this one. If your HTTP communication fails, due to broken profile assumptions, these steps can help you diagnose the issue and correct your profile.

What happens when your advantages become a disadvantage? That’s the theme of Fighting the Toolset. This lecture discusses Offensive PowerShell, staging, memory-injected DLLs, and remote process injection as technologies that deliver(ed) a universal advantage to attackers. Today, that’s not always the case. In some contexts, these technologies are the tell that gives you away. In other contexts, they continue to deliver as advertised. This lecture is all about how to adapt when your advantages are your weakness.

Many analysts and automated solutions take advantage of various memory detections to find injected DLLs in memory. Memory detections look at the properties (and content) of processes, threads, and memory to find indicators of malicious activity in the current process.

In-memory Evasion is a four-part mini course on the cat and mouse game related to memory detections. This course is for red teams that want to update their tradecraft in this area. It’s also for blue teams that want to understand the red perspective on these techniques. Why do they work in some situations? How is it possible to work around these heuristics in other cases?

Part 1 of In-memory Evasion introduces Memory Detections. This lecture walks through the observable properties of Processes, Threads, and Memory with Process Hacker. Common heuristics, the in-memory indicators we want to evade, are covered too.

Part 2 of In-memory Evasion goes through A Payload’s Life. This lecture discusses the heuristics in Part 1 and where they interact with actions taken by a representative offense platform (in this case, Cobalt Strike). This lecture makes the case that offense toolsets do strange things, but in some cases, these deviations from normal program behavior are optional.

Part 3 of this course discusses Evasion. General tips to avoid the strange behavior these detections find are discussed. This lecture then gets into the meat: options to configure how Cobalt Strike’s Beacon payload lives in memory are explained and demonstrated. This lecture also shows how to conduct an OPSEC review of your configuration prior to action on a target. Finally, this lecture concludes with a discussion on process context and how it influences the amount of suspect actions/indicators an automated solution will allow.

Part 4 concludes the course with a brief discussion of Threat Emulation. Cobalt Strike’s flexibility in this area is demonstrated to steer an analyst to believe they’re dealing with a specific real-world actor in a simulated incident.

Part 5 is an April 2018 addendum to this course. This video covers the memory-related threat emulation and evasion features in Cobalt Strike 3.11.

I’m a big believer that red teams should know the defenses they work with and know how their tools interact with these defenses. The area of memory detections has developed considerably over the past several years. Whether you’re on the red or blue side, I hope you find this perspective helpful.

Part 9 of Advanced Threat Tactics covers a lot of my thoughts on evasion. The ideas in that lecture are still relevant, the defenses discussed there didn’t go away! That said, there are other defenses and realities offensive operators must contend with today. This blog post discusses some of these and provides tips for adjusting your operations.

Think Plausible

I used to describe host evasion as smuggling known bad (your payload and its stager) into memory. The real worry, after that, was egress. If you could get an agent into memory AND establish positive control of it, you were usually safe to operate.

Today, things are a little different. It’s no longer enough to control a process on a target and work. You have to think about the process you live in and the actions acceptable from it. notepad.exe (and for that matter, rundll32.exe) has no business phoning home to some controller on the internet. A savvy operator will hide their Beacon in a browser process or an updater for some application (*cough* jupdate.exe *cough*).

Infrastructure Matters

A successful call out doesn’t mean you’re safe. Some defenders watch for malicious infrastructure indicators. How old is that domain you phone home to? Is that site categorized? Have others from this same organization visited that domain? Techniques like domain fronting help here. Beacon, configured to only use HTTP GETs may look less like a C2 channel (especially when used with domain fronting).

Mind Your Processes

Still, a safe channel doesn’t buy you too much. Every process you launch is a risk. Why is cmd.exe a child of firefox.exe? Some defenders have the ability to ask this question. For the operator, the trick is to know your tools. Some commands launch a process. Others don’t. You should favor commands and actions that map to APIs, when possible. If you must launch a process, careful session prepping can help that action blend in.

Session prepping is configuring how Cobalt Strike’s Beacon payload spawns new processes and temporary jobs. Here’s how I session prep:

Use the ps command to understand which programs are running. This command maps to an API.

Use the ppid [pid] command to request that Beacon spoof the specified PID as the parent process for the programs it runs. explorer.exe is a personal favorite.

Use spawnto x86 c:\path\to\program.exe to configure the x86 program Beacon should spawn for its temporary x86 jobs. Many Beacon post-exploitation actions spawn a temporary process, inject a capability into it, retrieve results, and kill the temporary process. spawnto x64 configures the x64 variant of this setting. Pick a plausible program.exe that fits well with your chosen parent process.

These steps do a lot to make your new processes (and post-exploitation jobs) blend in with normal activity.

Avoid Process Injection

The rabbit hole goes deeper though. It’s not enough to work only with APIs. You have to know which APIs are considered unsafe. Process injection stands out as an unsafe action. It’s helpful to know which commands do it and to know their alternatives.

For example, I often inject into a remote process to spawn a payload in another desktop session. An alternative is drop an executable to disk and use runu to run that executable as a child to a process in another desktop session. Same effect, except one depends on remote process injection, the other does not.

Do you absolutely need to run a Beacon command that injects into something? Inject into your current process. Beacon will treat this situation differently from a remote process injection. Beacon knows to use CreateThread instead of CreateRemoteThread (and other similar functions) in these cases.

If you need to discipline yourself to working this way: set the Malleable C2 option create_remote_thread to false. This will disable remote process injection in Beacon. Set hijack_remote_thread to false to disable Beacon’s method of process hollowing for its temporary jobs.

Avoid PowerShell

Other dangerous actions include any and all use of PowerShell. Once a major boon for offensive operations, PowerShell is now one of the most well instrumented technologies on the Windows platform (We love you Lee). If you depend on PowerShell for your operations, it’s time to brush up on working without it.

Many Beacon commands that use PowerShell have simpler primitives that don’t rely on it (e.g., spawnas -> runas, spawnu -> runu, etc.).

Some Beacon commands for lateral movement (winrm, wmi, and psexec_psh) use PowerShell too. Don’t don’t limit yourself to these. There are so many options for lateral movement, get creative!

Of course, I rely on a lot of PowerShell scripts to automate various offensive tasks. These same things would work well as .NET assemblies too. Payload developers, such as myself, would do well to embrace the use of .NET assemblies in their platforms.

#PowerShell IMO is too noisy to remain a "living off the land" technique. The new hotness: .NET assembly loading via insecure methods.

In-memory OPSEC

All of this assumes you have an agent that safely resides in memory. That’s not a given anymore either. I think of host-based prevention technologies in terms of touchpoints. A traditional anti-virus product might look at my payload when I touch disk or load content in a browser. If I defeat that, I win. Not so today!

Become familiar with the Malleable PE options I’ve added to Cobalt Strike. These, combined with stageless payloads, can land you in memory in a way that’s OPSEC-safe (in some instances).

I also recommend x64 payloads on x64 systems. Functionally, an x86 and x64 Beacon do similar things. In reality, they take different paths to achieve the same results (especially when it comes to things like process injection).

Avoid remote process injection. Process hollowing, in some cases, might be OK. Beacon uses a form of process hollowing for its post-ex jobs that depend on temporary processes.

And, finally, remember… context matters. An unsigned executable may find itself subject to aggressive hooks and heuristics to detect malicious behavior. A signed executable may receive some extra leeway. An executable signed by a trusted entity may get a free pass altogether.

Closing Thoughts

Defenses are evolving and that’s a good thing. As blue TTPs gain ground, it’s on us to adjust our operations and find ways to challenge these TTPs. This is how both sides get better.

A good operator knows their tools and has an idea of how the tool is accomplishing its objectives on their behalf. This blog post surveys Beacons commands and provides background on which commands inject into remote processes, which commands spawn jobs, and which commands rely on cmd.exe or powershell.exe.

API-only

These commands are built-into Beacon and rely on Win32 APIs to meet their objectives.

House-keeping Commands

The following commands are built into Beacon and exist to configure Beacon or perform house-keeping actions. Some of these commands (e.g., clear, downloads, help, mode, note) do not generate a task for Beacon to execute.

Post-Exploitation Jobs (Process Execution + Remote Process Injection)

Many Beacon post-exploitation features spawn a process and inject a capability into that process. Beacon does this for a number of reasons: (i) this protects the agent if the capability crashes, (ii) this scheme makes it seamless for an x86 Beacon to launch x64 post-exploitation tasks. The following commands run as post-exploitation jobs:

Process Execution

OPSEC Advice: The ppid command will change the parent process of commands run by execute. The ppid command does not affect runas or spawnu.

Process Execution: Cmd.exe

The shell command depends on cmd.exe.

The pth and getsystem commands get honorable mention here. These commands rely on cmd.exe to pass a token to Beacon via a named pipe. The command pattern to pass this token is an indicator some host-based security products look for.

OPSEC Advice: the shell command uses the COMSPEC environment variable to find the preferred command-line interpreter on Windows. Use Aggressor Script’s &bsetenv function to point COMSPEC to a different cmd.exe location, if needed. Use the ppid command to change the parent process the command-line interpreter is run under. To pth without cmd.exe, execute the pth steps by hand. Don’t use getsystem. There are other ways to acquire a SYSTEM token.

Process Execution: PowerShell.exe

The following commands launch powershell.exe to perform some task on your behalf.

elevate uac-token-duplication
powershell
spawnas
spawnu
winrm
wmi

OPSEC Advice: Use the ppid command to change the parent process powershell.exe is run under. Be aware, there are alternatives to each of these commands that do not use powershell.exe:

The uac-token-duplication privilege escalation exploit has runasadmin. This command runs a command of your choosing with the same UAC bypass.

spawnu has runu which runs an arbitrary command under another process.

spawnas has runas which runs an arbitrary command as another user.

powershell has powerpick, this command runs powershell scripts without powershell.exe.

Working on Cobalt Strike, I get some insight into what folks are trying to do with it. Recently, the use of domain fronting for redirectors has come on my radar.

A redirector is a server that sits between your malware controller and the target network. Domain fronting is a collection of techniques to make use of other people’s domains and infrastructure as redirectors for your controller.

A trivial form of domain fronting is to stand up a node in Amazon’s EC2 and configure it as a redirector for your controller. The FQDN of your EC2 instance is an amazonaws.com subdomain. Your payloads may call home to this. While this is beneficial in some cases, this isn’t where things get interesting.

Domain fronting becomes interesting when used to appropriate high-reputation domains as redirectors for your controller.

Domain Fronting with Alternate Hosts

How is it possible to use a high-reputation domain that you don’t control? Let’s use Amazon’s CloudFront as an example.

CloudFront is a Content Delivery Network service. It provides its users a globally distributed cache for files hosted on their servers. This reduces load on the customer’s servers and allows the CDN to serve cached content from data centers close(r) to the requester. Each CloudFront configuration is called a “distribution”.

CloudFront identifies distributions by the FQDN used to request resources. Each CloudFront distribution has a unique cloudfront.net subdomain. CloudFront’s users also have the option to serve CloudFront cached objects via their own sub-domain. This is done by creating a DNS record that points to CloudFront and telling CloudFront to associate that DNS record with a specific distribution. Easy enough.

When a client connects to CloudFront, the DNS name that led there is lost information. CloudFront relies on other parts of the request to extract which DNS name the client wants resources from. In an HTTP request, this is the Host header.

One way to domain front is to configure a payload to call home to one host (e.g., media.startupunicorn.com) and set the Host header to something else (e.g., mydistribution.cloudfront.net). If the Host header is set right (and nothing else changes it), your cloudfront.net configuration will dictate what happens next.

a0.awsstatic.com is a domain name that points to CloudFront. I know about this domain because other resources on domain fronting use it as an example. If I request /foo.txt from this host, naturally it’s not going to give me anything.

root@kali:~# wget -U demo -q -O - http://a0.awsstatic.com/foo.txt

Let’s modify that slightly. We’ll use the a0.awsstatic.com domain (it all goes to the same place, right?)—but, we’ll forge the Host header to the FQDN of my CloudFront distribution. In this case, I get back the text file.

Once this is setup, you’ll want to decide which domain(s) you will use as redirectors. Let’s say a popular blog service uses CloudFront to serve static images. You may decide it makes sense to use this domain for your C2. Fine!

Make sure you do this in both the http-get -> client and http-post -> client Malleable C2 blocks. During a conversation, a friend remarked that they were stuck for awhile because they set the Host header in the http-get block, but not the http-post block. You have to set this in both places.

Once this is setup, you can configure your Beacon payload to call home to different domains that point to CloudFront.

One limitation: there’s no option to set the Host header in Cobalt Strike’s stagers. You can work with stageless payloads though. Go to Attacks -> Packages -> Windows EXE (S) to export a Cobalt Strike stageless artifact. If you want to stage, I recommend that you configure the stager to connect to your cloudfront.net distribution directly or use another redirector.

This video walks through all of this, end-to-end:

Finding High-reputation Domains for Use

My examples here use a0.awsstatic.com as an alternate host. Think of it as the Hello World of Domain Fronting. Vincent Yiu from MDSec took this a step further. He wrote a script to check likely CDN subdomains from a list of popular websites. His initial work found over three thousand subdomains that point to CloudFront and demonstrated that they work as alternate hosts with the technique discussed here.

A Note About RFC 2616, Section 14.23

So far, this blog post focuses on domain fronting over HTTP. If the target system goes through a proxy server, you’re in trouble. An RFC-compliant HTTP proxy server will rewrite the Host header in an HTTP request to match the domain in the URL it’s asked to retrieve. The Squid proxy documentation talks about this behavior. For many some networks, this means HTTP is a non-option.

Update 7 Feb 2017: This behavior matches my experiments with a Squid proxy locally, but don’t take it for granted that your target’s appliance(s) work this way. After I made this post live, Vincent Yiu took a look at a commercial secure web appliance and its behavior with these techniques. This appliance didn’t rewrite the Host header as expected. If you’re curious about how an appliance that enforces site categorization behaves with these techniques, Vincent’s latest video is worth a look:

My Thoughts

Domain Fronting is an interesting technique to use high-reputation domains for callbacks. It’s not the right tool for all situations though. An RFC compliant proxy will defeat HTTP requests. A proxy server that terminates and inspects SSL/TLS sessions will might handily defeat this as well. There’s probably wiggle room using this technique with whitelisted high-reputation domains. This makes locating domain options even more important! Remember, these are not CloudFront-only techniques.

I finally had a chance to sit down and play with BloodHound. This was an item on my hacker todo list for awhile now. In this blog post, I’ll take you through my initial steps setting up and using this tool. It’s my hope that this information will help you get started with BloodHound too.

What is BloodHound?

BloodHound is a tool to analyze and understand Active Directory Trust Relationships. For an offensive practitioner, this tool can highlight the hops you might take to reach a goal within a network. For a defensive practitioner, this tool is gold as it can show you the most likely paths an attacker might take. It’s a good exercise to decide which of these trust paths needs to exist and which you can eliminate.

Use

Once BloodHound is running, you’ll want to bring some data into it and give it a spin. There is an example database, but I chose to pull BloodHound data from my test environment and import it into the tool instead.

BloodHound comes with a PowerShell script with several cmdlets that make this process easy. Get-BloodHoundData collects the data BloodHound needs. This cmdlet will return a PowerShell object. It’s necessary to pipe this object to another cmdlet to take some action on it. The Export-BloodHoundCSV cmdlet will dump the BloodHound data into three CSV files.

Summary

I think BloodHound is one of the neatest things to come into the red teamer’s arsenal this year. While my demo network is easy to go through by hand, imagine the use of this tool in a much larger environment with more complex trusts. There’s a lot of power here.