Backdoor Primitives

Backdoor Primitives

This is a super short post on backdoor primitives, meaning the building of the blocks of backdoors. When looking for backdoors in the network and doing things like remediating events, keep in mind that your attacker probably has these things pretty well covered. Please don't do things like assume that if there's not stuff laying all over disk that a machine isn't compromised. It's not 2005 and most *good* people have figured out and integrated reflective loading into most of their exploitation TTP's.

Backdoors always have:

• Network transport(s)
• Without a way to talk to other backdoors in the network and/or the outside world, there isn't much point of having a backdoor in a network. The unrelenting truth of network exploitation is measured in bytes in / bytes out. 
• State storage
• There has to be somewhere (in memory, on disk, reg keys, mutexs, etc.) where a backdoor keeps its state and configuration and does handy things like making sure that two copies of it aren't installed on the same host by accident (you'd be surprised how often attackers run into this scenario).

Backdoors sometimes have:

• Built-in persistence mechanisms
• making it so that you don't have to do more than type a line in a command prompt to get persistence
• Built-in lateral movement mechanisms
• making it so that you don't have to manually do service executable replacement (or other nifty tricks) by hand to execute code remotely
• "on-host kit"
• This is pretty much everything and the kitchen sink, this is all the stuff that is broken apart into a plethora of different tools that a quality backdoor has baked in, including mimikatz-like functionality to dump creds and passwords, keyloggers, etc.

Packers exist

I'm not talking about the cheesheads from Green Bay, I'm talking about the fact that there are F as in Free tools that will make an attacker binary / code not look like anything malicious to A/V and other hash-centric tools. There is a whole range from "doesn't flag A/V" to "um this is obfuscated by I can use Olly to deal with it" to "Zoinks, this is commercially packed / encrypted and I don't know what to do about it". I write this because I've seen multiple lazy and skilled defenders do stuff like "hashes" and "fuzzy hashes" as a foundational part of doing forensics, IR and threat intel. Please stop doing that (or at least please stop pretending it's a complete approach) . Modifying a PE and / or encrypting binaries is not a hard thing to do and well below HD Moore's law of skiddies.

Attackers can have more than one set of tools:

There are different tools for different purposes, I don't use a wrench and a screwdriver interchangeably, mostly because they are fairly purpose-built tools. Attackers are much the same way in that there are predominantly two types of implants (backdoors) that a semi-skilled attacker will use:

• Stage I Implants
• Lightweight
• Main purpose is download and execute
• May essentially be little more than shellcode and have no footprint on the target machine
• Will only communicate with initial (burnable / short term) C2
• "burnable" and low-cost
• Stage II Implants
• Meant for persistence / long-term deployment
• "not as burnable", higher cost implant
• May use multiple C2 methods and will use multiple C2 endpoints if it is well designed for long-term deployment
• Swiss-army knife type full of kit for...
• hash / cached cred / password dumping
• domain / network enumeration tools
• purpose-built functions 
• etc.

Malware is alive

Malware running on a system has to be executing at some level. This means that it can exist as one of the following:

• Process
• On disk 
• In memory (runs process and then deletes presence on disk)
• Thread
• DLL attachment
• CreateRemoteThread
• Detour patching
• Rootkit
• Kernel-mode/User-mode
• DKOM
• Hooking

For more information about how attackers use tools:

Check out the 3-part blog post on an intro to attacker methodology:

Intro to Attacker Methodology

Attacker Methodology Intro Part Deux (PrivEsc and Propagation)

Intro to Attacker Methodology Part III - Persistence and Entrenchment

Learn more:

Here are 3 blogs that are all by very well versed and qualified penetration tester / red team folks that develop, reverse engineer and generally know a lot of stuff about backdoors. I suggest that you check out what they have to say and if you're participating in CCDC you'll definitely want to go through the ins and outs of what they're talking about.

Read clymb3r's blog

Read @mattifestation's blog

Read Raphael Mudge's blog