{"id":26201,"date":"2022-07-27T13:11:05","date_gmt":"2022-07-27T13:11:05","guid":{"rendered":"https:\/\/kalilinuxtutorials.com\/?p=26201"},"modified":"2022-07-27T13:11:06","modified_gmt":"2022-07-27T13:11:06","slug":"frostbyte","status":"publish","type":"post","link":"https:\/\/kalilinuxtutorials.com\/frostbyte\/","title":{"rendered":"Frostbyte : FrostByte Is A POC Project That Combines Different Defense Evasion Techniques"},"content":{"rendered":"\n

FrostByte<\/strong> Is A POC Project That Combines Different Defense Evasion Techniques. In the past few days I’ve been experimenting with the AppDomain manager injection technique had a decent success with it in my previous Red Team engagements against certain EDRs. Although, this is really good for initial access vector, I wanted to release a POC which will help hiding your shellcode elsewhere. No more shellcode embedded DLL files!<\/p>\n\n\n\n

<\/a>The Problem!<\/h2>\n\n\n\n

Although it is an excellent technique when used independently, but when coupled with a delivery technique like sending a C# ClickOnce inside an ISO\/ZIP\/VHD\/VHDX file. The real problem is 1 out of 10 times the DLL for the appdomain was detected by AI\/ML heurestics of the AV\/EDR. This is because the DLL file needs to be dropped on the disk before initializing the appdomain. Ignoring the remote DLL loads for the time being (UNC paths in .config), the DLL for the appdomain would contain the shellcode and I strongly felt that is the reason for a probable static detection, because the rest of the code which is WINAPI calls can be dynamically resolved and pretty well obfuscated.<\/p>\n\n\n\n

I wanted to enhance this technique in terms of minimizing what the DLL would initially hold. I started by dropping encrypted shellcode in a separate file on disk along with the injector DLL but then I came across this amazing blog from Checkpoint on Zloader’s Campaign<\/a><\/p>\n\n\n\n

TLDR version: We can embed arbitrary data into some fields within the PE in a way that would not break the files Signature. So our data will get embedded and the exe will still remain digitally signed.<\/p>\n\n\n\n

More info on this – https:\/\/www.blackhat.com\/docs\/us-16\/materials\/us-16-Nipravsky-Certificate-Bypass-Hiding-And-Executing-Malware-From-A-Digitally-Signed-Executable-wp.pdf<\/p>\n\n\n\n

So the idea is to embed an encrypted shellcode stub into a known signed executable and still manage to keep it signed like how the Zloader malware did. By doing so the AppDomain Manager DLL will no longer contain the shellcode within itself, but will just have the logic to parse the shellcode from the PE binary that loads it to decrypt and execute as a seperate thread. Doing this might decrease the static detection rate for the DLL while your shellcode is nicely placed inside a signed binary.<\/p>\n\n\n\n

I was trying to achieve this by manually tampering with the ZLoader samples I got from VirusTotal, but later found about a project which had already implemented all of these techniques pretty well – Sigflip. In this POC I leveraged Sigflip’s loader code to build the AppDomain DLL and SigFlip injector to embed the encrypted shellcode into our C# exe.<\/p>\n\n\n\n

<\/a>Advantages<\/h2>\n\n\n\n

Large blobs of shellcode like Cobalt Strike’s Stageless shellcode will no longer reside on an unsigned DLL on disk, irrespective of the obfuscation \/ encoding techniques used. The DLL is cleaner, smaller and stealthier with minimal code thereby reducing the changes of detection.<\/p>\n\n\n\n

<\/a>Working<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Steps to build Signed Shellcode Executable<\/h2>\n\n\n\n