Thread by @NinjaParanoid

A lot of times when I provide Brute Ratel demos, I get a tonne of questions on detection, so here goes a rant on how detections are usually built. First and the most basic detections are static signature based. (1/15)

These are built on atop of yara rules which search for a specific set of opcodes in your binary/exe file. If your payload contains any strings from known payloads,you are bound to get caught. These also include detections of randomness in your PE to search for encrypted (2/15)

shellcode/dll buffers. Signatures are not just built on strings, but also functions. When you compile a file, it generates opcodes and bytes which get stored in different sections of the PE. So, if your payload contains copy-pasted functions from known malicious payloads, (3/15)

Yara rules will catch them too. Yaras also search for Import Table hashes, known as ImpHashing. Its recommended not to use static libraries in your IAT. Dynamic resolution is the key here. Evading Yara rules are not worth it, since they can be easily modified to detect the (4/15)

next modified binary your drop on disk. Unique Initial access technique is the key here. If you've evaded everything till here, then the next detection is sandbox. Sandboxes check the domain/Ip ur payload communicates to. This is not exactly behavior based, as some people (5/15)

like to think. Sandboxes usually check for known malicious domains/IP alongisde identifying the API your payload calls. Any unsigned binary will get caught and blocked here. Any binary that directly calls Valloc+ThreadExecution without verifying if its in a sandbox will (6/15)

also get caught. Evading automated sandboxes aren't hard. You just have to check for user interaction with the host or known artifacts from virtual machines which validates its not a valid host. (7/15)

Once you evade all of this, then the EDR detection starts here. This fairly includes a mixture of yara rules+userland hooks and telemetry generation in the kernel land using drivers and ETW. (8/15)

The userland hooks check the WINAPI being called. Some also check callstacks. These hooks specifically monitor known API calls and check the parameters passed to the API and where the call execution was initiated from. If the call was initiated from any unbacked RX region, (9/15)

you might get caught. Buffer values passed as parameters to the API calls for memory allocation or memory execution are also scanned again with Yara rules to check for known shellcode opcodes. These hooks mostly hook NTAPI calls and callstack to check the last caller (10/15)

region on stack. The key to avoid this detection is basically to use obfuscated syscalls, since direct syscalls can be detected with callstack analysis. Reversing EDR userland hooks can help a lot. Some userland ETW telemetry can be avoided by patching known API calls (11/15)

with ret (\xC3) values to disable the telemetry, although not everything can be patched. If you have evaded everything till here, then you are left with final 2 detection mechanisms: 1. ML Detections on the telemetry generated by the kernel and ETW, 2. The THREAT HUNTER (12/15)

The first part isn't hard to evade. This is where parent-child process anomalies, valid cmdline args for fork&run, PE metadata come into picture. This is the core to behavior analytics and knowing whats normal and whats not in your target environment can help a lot. (13/15)

I usually check softwares installed and inject my payloads into them, rather then the windows executable, coz windows executables are heavily hunted these days. Finally the last part of detection is to evade the Threat Hunter who can analyze the logs. (14/15)

If u are lucky, the hunter might just be a new L1 SOC analyst with not much experience in hunting. If you are dealing a really good malware analyst-turned threat hunter or red teamer-turned threat hunter, then your only way out is to bribe them. GOOD LUCK :) (15/15 END)