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.
Background
According to Wikipedia, both VBscript and Jscript first appeared in Windows back in 1996. That’s 24 years ago. Even to this day, both scripting languages are readily available and in the latest version of Windows 10. They offer both rich and featureful runtimes that provide great control of the host.
Both of these languages are commonly used in e.g. phishing campaigns as an initial payload designed to launch more featureful malware, such as Meterpreter, Cobalt Strike’s Beacon, or an Empire agent, just to name a few. This is nothing new. E.g. the Metasploit framework (first created back in 2003) has had the ability of generate HTA stagers for what seems like ages. Example payload:
Typically, what the popular post-exploitation C2 frameworks have in common, is that the use of legacy languages is mostly confined to staging, as shown above, by directly tasking powershell.exe to launch an instance of Meterpreter.
In a recent Red Team engagement, we were tasked with conducting a phishing attack against targets that we knew were well protected by capable Anti-Virus (AV) as well as Endpoint Detection and Response (EDR) products. Therefore, creating a payload that would fly “under the radar” was a challenge.
Malware design
As a solution, I implemented a very basic malware in VBscript, packaged in a HTA file, that did not stage additional malware, but instead provided full capabilities needed to execute our attack, straight from the VBScript runtime. In essence, the malware was a simple as the following (pseudo code):
Thus, 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. As a result, the malware is at the time of writing detected by only a single AV/EDR solution, among the ones tested against (although obviously I have not tested all).
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:
Moving files (e.g. for simple persistence):
Write files:
Rob van der Woude's collection on VBscript (robvanderwoude.com/vbstech.php) 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 (https://github.com/magnusstubman/demiguise), 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 analysos) 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
So, how should we defend against custom malware tailored specifically to work against your environment? It’s hard – but a sound approach is to raise the bar of difficulty, by minimizing attack surface. In this case, by disabling any type of runtime or scripting language that is not fully warranted by a business need. I have yet to come across an organisation that really needed HTA files in their production environment.