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.
https://twitter.com/mattifestation/status/889446662866743296
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!
Now, the battleground is the functions we use to get our payloads into memory. Creating a new thread? Make sure its start address is tied to a loaded module, avoid RWX pages, and for the love of your favorite deity… don’t look like a PE file!
My advice to Cobalt Strike users?
- Ditch stagers, when you can. Their memory OPSEC is terrible. It’s possible to operate stageless with Cobalt Strike.
- 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.