Gootloader, SolarMarker, AsyncRAT, Oh my!
What is one common thing these trojans and RATs have in common? Well, they all have a similar form of delivery! Often, users will come across these trojans, infostealers, and RATs through Search Engine Optimization (SEO) poisoning, drive-by downloads, and phishing, just to name a few. With this said, what does the delivery of these trojans look like? Typically, once the user comes across the malicious file in one of the above techniques above, they will often be delivered a zip archive. Within this archive is often a masqueraded script file, such as JavaScript, VBscript, Batch script, or HTA (HTML Application). Once double clicked, the payload will be downloaded/dropped onto the system. So, how can we prevent the payload from executing once interacted with by the user? Let's talk about it!
The Rundown:
Although there are many ways malware (generic) can be delivered, malicious scripting files have become a very common format.
Yes, yes, there are many other things to consider to minimize the successful delivery of malware such as these; however, we'll discuss a few quick wins here.
Many script files are interpreted and executed by the Windows Script Host (WSH).
WSH supports many script formats such as .bat, .js, .vbs, .wsf, .wsh
wscript.exe is used to execute these scripts (GUI)
cscript.exe is also used to execute these (command-line)
mshta.exe can be used to execute HTA files
Application Control, such as AppLocker or Windows Defender Application Control can be effective at blocking the execution of wscript, cscript and MSHTA, minimizing the likelihood a malicious script would be executed
If you're still following along here, then I have some quick wins here for you! This blog post will be short, sweet and to the point. As a note, before implementing the below controls, please ensure these are tested before implementing, as every environment is unique; assess if its normal that your users are executing wscript, cscript and MSHTA; if not, consider blocking these. At the very least, consider restricting execution to a limited number of users or groups, signed-scripts, from trusted locations.
Let's get started here! So, I discussed what we can use to block the execution of these trusted binaries (wscript.exe, cscript.exe, and mshta.exe), but how? Well, although there are many solutions, Windows has some great features built in to control Application execution. On modern systems, this is known as AppLocker or Windows Defender Application Control (WDAC). Please note that AppLocker and WDAC are available on Windows 8.1, Windows 10 and Windows 11, though 8.1 may have limited functionality. Additionally, these controls can be pushed and managed by Group Policy.
If you want to see if you have AppLocker, follow below!
First, Open the Local Security Policy Editor. Here, you'll see an option for Application Control Policies and "AppLocker". BOOM! That's what we'll use to restrict application execution of the aforementioned executables.
With this said, there's a few things we'll have to enable before we can enforce application execution. First, we'll need to make sure the "AppIDSvc" is running and enabled. According to Microsoft, this is described as "The Application Identity service determines and verifies the identity of an app. Stopping this service prevents AppLocker policies from being enforced." This can be started via GPO or manually.
Once the service is started, we'll need to begin enabling the executable enforcement policy. Please note that it's strongly recommended to enable default policies; without doing this, you may brick your system by blocking a large number of scripts/executables. From here, click "Create Default Rules". Right off the bat, you'll see the default policies are extremely powerful, though these are just starting points and should be considered a baseline. Are you thinking of some great ways to block executables from suspicious and unexpected locations?!
After this, let's create our rule to block the earlier mentioned executables. To do this, we'll right click in the empty space or click "Executable Rules" and Create New Rule. From here, we'll want to create a "Deny" rule. Provide the location of the executables; in this case, they're located in C:\Windows\System32\. Do this for cscript.exe, wscript.exe, and mshta.exe.
Once completed, you should have settings similar to the below image; please note that this is just for demo purposes. Ideally, in a production environment, you'd restrict this based off of users/groups that require this as part of normal job duties.
Now lets enforce the rules! Head back to the left side and select "Applocker" and "Configure Rule Enforcement". This will enforce the rules we created earlier.
As long as the earlier mentioned service is running (AppIDSvc), we can go ahead and do a gpupdate /force command and try executing a sample script. This should be blocked now! BOOM. We just prevented an extremely common delivery/execution technique.
Let's give it a shot! I executed my test script called 'test.vbs' (real creative here). Looks like it was blocked! JavaScript files were also blocked! Want to try and block batch scripts? Try doing the same thing for cmd.exe!
Again, this is not a silver bullet to all attacks, but is a quick win and great example of just how powerful application control can be; additionally, please remember that the idea is to limit who has access to execute these binaries, from which location, if they're signed, etc.