Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
Resources Blog Threat intelligence

Open with Notepad: Protecting users from malicious JavaScript

Creating this simple Group Policy Object to open JavaScript and other specified attachments in Notepad can prevent the execution of malicious payloads.

Jeff Felling

SocGholish. Gootloader. Scarlet Goldfinch. What do these threats have in common? Aside from appearing among the top 10 most frequently observed threats in Red Canary customer environments, all of these threats are known for being introduced via malicious JavaScript lures.

The JavaScript problem

So often in security, the stories we tell are about the failures—the threats that broke through defenses and wreaked havoc in a customer’s environment. What we don’t talk about enough are the successes—attempted evil thwarted by controls and policies, leaving security teams waiting for the next event and unsuspecting users continuing their work undisturbed by an attack they never knew was there. In the case of SocGholish, Gootloader, and Scarlet Goldfinch, implementing a simple policy change can successfully stop the threat before it gets started.

SocGholish, for those not familiar, is a top 10 mainstay—in the 41 months since we began tracking our most frequently observed threats, SocGholish has cracked the top 10 a whopping 30 times. Also known as FakeUpdates, SocGholish infections begin with a compromised website luring victims by indicating that an update needs to be installed for their browser or other common software.

Trusting users who choose to download the payload are tricked into running a malicious JavaScript (JS) file that connects back to adversary infrastructure and may download and execute additional malware. This is a particularly insidious trick, as it preys on users who are trying to do the right thing by keeping their software up to date. Training users to distinguish between legitimate and malicious software updates is a difficult balancing act, and not one that is likely to be highly effective.

What other controls might we put in place?

To answer this, we might consider how user interaction leads to execution of the script. SocGholish, like Scarlet Goldfinch and Gootloader, needs the user to not just download the lure, but also to to execute the payload. Most of the time, users will double-click on the JS file to run the script. But how does Windows know how to execute a JS file when the user clicks? If you’ve ever tried to open a new file type on your machine, you have likely seen a prompt asking you which app or program you’d like to use to open the file.

 

Screenshot of Windows "Open with?" prompt

 

If the file has a common extension, Windows will use its built-in list of default software that corresponds to that file type. For .js files (and a few other common scripting languages), that default program is the Windows Script Host, wscript.exe. Once the user clicks on the malicious JS lure, they immediately launch a wscript process that executes the contents in the file. But how many users need to directly execute these types of script files? Unless the user is a developer, chances are they don’t.

Enter Group Policy Objects

This is where a quick policy change can stop the threat in its tracks. Red Canary Principal Threat Hunter Chuck Frey has been advising customers on this control for years, and keeps a quick-reference guide handy just for such occasions.

The built-in list that Windows uses to correlate a file extension to the program that will open it is stored in the Windows Registry, and it can be controlled via Group Policy. Preventing execution of the malicious JS payload from SocGholish, or any other threat, is as simple as changing the default program from the Windows Script Host to something that will not execute the code. A common option is to set potentially harmful scripts to open in a text editor by default, such as Notepad. This is exactly what Chuck’s advice helps you do.

So what happens when an organization takes this advice and tells Windows to open scripts with Notepad? Do the threats just go away? Well, not completely. But they don’t break through defenses and wreak havoc either. To explore this question, we set out looking for examples of Notepad being used to open JS files in customer environments. Sifting through those hunting results, we quickly found some interesting activity:

"C:\WINDOWS\system32\notepad.exe" 
"C:\Users\USERNAME\AppData\Local\Temp\12345678-cdef-4321-abcd-123456789abc_Update - 35129.zip.f7b\Update_123.0.6312.111.js"

The naming conventions Update - 35129.zip and Update_123.0.6312.111.js are consistent with recent Scarlet Goldfinch activity. Digging a bit deeper, we identified multiple instances in the past month of users falling for the Scarlet Goldfinch fake update lure, downloading the ZIP file, extracting the contents, and double-clicking on the JS payload. But instead of receiving a high-severity threat detection for malicious software from Red Canary, these users just saw a Notepad window displaying the complex JavaScript contents of the alleged update. The users likely closed the window and moved on with their day, unaware how close they’d come to having their machine isolated and a ticket opened to have it reimaged. Had the default program not been changed, Red Canary likely would have detected follow-on activity emanating from the malicious JavaScript payload.

Conclusion

While this solution is not a panacea, we found it noteworthy that of the environments where we observed malicious JS files opened with Notepad, none have seen successful execution of Scarlet Goldfinch, SocGholish, or Gootloader. Given the prevalence of these threats across our customers, this appears to be a successful mitigation. While changing default user behavior can often be difficult, changing default computer behavior is much easier. Sometimes mitigating a prevalent threat is just a click away.

 

Note: Implementing this policy should not interfere with other legitimate software that relies on script file execution. Executing things like JavaScript in a browser is handled within the context of that software. The Windows default “Open with” list only applies when a file is opened without specific context, such as when a user clicks on the file from Windows Explorer. If the user really wants to run the script, they can still explicitly specify which program they’d like to use to execute the file. That said, if your organization relies on users to execute scripts regularly, you may want to consider how this type of change could impact daily routines for your users before implementing the policy.

 

Intelligence Insights: May 2024

 

Intelligence Insights: April 2024

 

Holding down the Fortinet vulnerability

 

Intelligence Insights: March 2024

Subscribe to our blog

 
 
Back to Top