Back to BlogThe Hedgehog Defense – Prevent Malware Execution with Default App Modifications
While I was trying to think up creative names for the theme of this article, I Google’d the very generic term “hedgehog defense”. It turns out this is an actual military tactic that employs the use of “mutually supportive” strongpoints. I was surprised how well the description of this strategy lends itself to the idea of cybersecurity and wholly convinced to use the term after I saw wikipedia describe it as a “defense in depth” strategy. Nailed it.
So, in this series, I’ll be detailing defensive tactics that you can utilize in your environment that will help thwart threat actors and stop them in their tracks. My aim is for many of these tactics to be relatively easy to implement with little to no risk, but high value in slowing down or even outright preventing malicious attacks.
TACTIC: Changing Windows default app associations
Why?
Threat actors use all sorts of different file types for a myriad of reasons. Most of the time, it’s to try and get around endpoint security or to confuse a user into doing something that they shouldn’t.Most typical users do not have a business need to be launching vbscript files on their computer, so why not prevent them from being able to do so? Sure, there may still be ways to launch these files, but security is all about layers. Preventing a user from being able to double click to run certain files may make them think twice aboutlaunching the file in the first place or may even force them to reach out to the help desk for assistance.
In fact, the particular strategy I’m going to demonstrate is common enough to have its own Mitre designation, known as a “Double File Extension” which is a sub-technique of Masquerading.
How?
So how does changing default app associations help in situations like this? By default, Windows is configured to see a vbscript and want to run it as a script. To prevent this from happening, we tell Windows that we would rather have it open with a text editor. This small change prevents automatic execution of the vbscript file and stops the attack flow in its tracks.
Method 1: Group Policy (recommended)
The most reliable way of accomplishing this is via a Group Policy Object. The primary benefit of using GPO is that it continuously applies to every domain-joined workstation. This means if a default app setting is reset by an app or user, it will eventually be synced up and reset to the app set in the GPO policy.
- Log on to a domain controller and open Group Policy Management.
- Create a new GPO
- Right click on your new GPO and click Edit
- The setting for default app can be found under User Configuration > Preferences > Control Panel Settings > Folder Options
- Right click on Folder Options and select “New”, then “Open With”
- For Action, leave it as “Update”. This action creates the association if it does not already exist and overwrites it if it does.
- In the File Extension field, type the extension that you want to set. In my example, we’re working with the vbs extension.
- Select the Associated Program you would like to set the default to. In my example, I’m going to set notepad.
- Make sure you check off the “Set as Default” box.
- Feel free to add additional file extensions as you see fit. Consider the extensions that your users use on a day to day basis and think about adding any extensions that they may not need to auto-execute. Some examples would be batch files (.bat), javascript (.js and .jse), HTML App (.hta), and Web Form ASPX (.aspx). It’s also worth noting that this is a user-based GPO, so you can freely assign it per user/group. You can create different and separate policies per the different types of users in your organization.
- With the new policy created, link it to the User OU (Organizational Unit) that you wish to apply it to or apply it Domain-wide. In my example, I’ll be applying to just my test user group.
- If you want to test immediately, make sure you force a gpupdate on the endpoint you’re testing with. This can be done with the command gpupdate /force. Otherwise, the group policy should automatically deploy to endpoints with in a few hours.
Method 2: Export and Import Default App Associations with DISM
Another method to achieve the same results is to use the built-in Windows tool, DISM, to perform an export of a machine’s default app associations and then import on another machine. This is also a handy method if you just want to export and audit existing associations on an endpoint.
- If you plan on importing these app associations to another machine, make sure that you set the associations before exporting.If you’re just auditing, go ahead skip to the next step. If you are unsure how to set app associations manually, see Microsoft’s documentation.
- Run the following command to export the app association configuration:
DISM /Online /Export-DefaultAppAssociations:<output_path>
Example:
DISM /Online /Export-DefaultAppAssociations:C:\Temp\AppAssociations.xml
- To import this file, save it somewhere where the target machine can access. This can be locally on the target machine itself or on a network share drive. The command to import this file is as follows (surprise, it’s the same as before, but ‘Import’ instead of ‘Export’!):
DISM /Online /Import-DefaultAppAssociations:<output_path>
Example:
DISM /Online /Import-DefaultAppAssociations:C:\Temp\AppAssociations.xml
BONUS! – If (…when) you happen to mess up default app associations and want to clear your (…or someone else’s) default app associations, use the command:
Dism.exe /Online /Remove-DefaultAppAssociations
This will remove any custom set associations and restore everything to default. I also want to note that I had some trouble getting the DISM method to work consistently. Exporting works no problem, but importing or resetting seem to be a little hit or miss. This could just be something with my lab, but just wanted to forewarn and suggest your mileage may vary with this method. Plenty of guides online suggest this method works fine so I’m just going to assume I’m the problem.
Obviously there are quite a few ways you could automate this method too (deploying via an RMM is the first that comes to my mind), but you get the idea. These are certainly not the only ways, so don’t feel discouraged if GPO or DISM are not options for you. Just do some research and find a way that works in your environment.
In action – DEMO
Video – before default app modifications:
Video – after default app modifications:
In my demo, I will use the common Command and Control platform, Sliver, to generate an executable to deploy my implant on the victim endpoint and create a Sliver session. This executable will be hosted on my malicious server alongside a fake pdf file. I have created a simple vbscript file that will download and run the malicious beacon executable as well as open the pdf. This way, the victim gets what they were expecting (a pdf) while my malware loads in the background and establishes a foothold on the victim endpoint. Another tactic I abuse here is renaming my vbscript file and ending it with ‘.pdf’. In windows, when file extensions are hidden, this makes it look like the file ends with the ‘.pdf’ extension. I tried my best to emulate an actual attack pattern that would be similar to strategies observed by real threat actors.
- Generate malicious implant with Sliver
- Renamed my implant to ‘windowsupdate.exe’ to blend in a little more.
- Created a super legitimate looking PDF file to trick the user into thinking they got what they were expecting.
- Hosted the implant, pdf file, and the vbscript on my kali server.
- Draft and sent a very, very sneaky email to my victim. This email includes a link to the malicious vbscript. I worded the email to give a sense of urgency. This tactic is used to get the victim to take action now and may push the victim into disregarding warning messages or taking time to consult with other users or IT.
- Upon clicking the link, the malicious vbscript is downloaded and run by the user. PDF file launches as does my Sliver implant.
- Going back to my Sliver C2, I can confirm that the implant was successful and I have an active session. With an active Sliver session, I now have a foothold on the victim endpoint and can begin my discovery, privilege escalation, and lateral movement.
After Implementing GPO to Change Default App Associations:
Once implemented, the attack flow stops right when the user tries to launch the vbscript file. Instead of being able to launch the file as a script, it will launch with notepad. This prevents the execution of the script and stops the attack from completing and establishing a Sliver session.
Of course, this still opens the file, just in a way that strips it of its fangs. I chose notepad just as an example, feel free to play around and see if there is a different application you would prefer to open with or would work better for your environment. The end goal is just to set it to open with something that will prevent the script from running as a script.
And that’s it! This is a great low-risk change you can make to your environment with potential for a high reward. Again, this isn’t designed to catch everything, we just want to hit the low-hanging fruit, like when would a user ever need to legitimately auto-execute a vbscript or javascript file? This article from HowToGeek shows a lot of file extensions to consider creating a policy for.
Lastly, this is a good training opportunity for your users as well. To combat the double extension tactic, Mitre specifically calls out disabling the feature to hide file extensions and training users to identify suspicious files by their double extension. Even with some basic training, users should be able to spot this nefarious attempt before even downloading or executing the file.
Want to learn about other techniques that threat actors use to deceive their victims? Take a look at this article written by Amanda Berlin that’s all about the topic!