Image composed with parts of a picture by janjf93 from Pixabay

I bet many company and consumer users out there can be hacked from remote with only a couple lines of JavaScript. In this post I use two lines to start arbitrary programs. You will be surprised how easy this is.

The other day, I saw an entities graph in MDATP that looked like that one:

I was puzzled. How can ‘Internet Explorer’ start ‘wscript.exe’, which then starts an executable on the system?

After digging deeper in the MDATP timeline, I recognized that the user visited a German free mailer website shortly before this entities graph showed up.

The puzzle pieces slowly started to make sense in my corona-locked-down brain, but to grasp the whole picture, I had to do a proof of concept.

As usually, I had to hack myself to understand what’s going on. Wanna follow me? Let’s go:

First off, I created an account at a German webmailer called “gmx.de”. It’s quite popular in Germany – at least (and that makes it worse) for the not so IT-affine people.

I then created a .js file with the following content:

var wshShell = new ActiveXObject("WScript.Shell");
wshShell.Run("calc.exe");

I saved this file and sent it via the webmailer to myself. The webmailer made sure, I know, that this was sent through the “secure german network” – E-mail made in Germany:

If you now -as the recipient- try to open this attachment, the new Edge gives you this warning:

Internet Explorer does this:

And here is Chrome:

You could now argue about the difference in the urgency with which the different browsers display the warning, however – let’s see what happens in all three cases after the user decides to open the attachment (you know, he will open it, right?).

I wouldn’t thought it is that easy to run any program or command in this workflow. Sure enough, I was aware of the danger of private web mailer services. Everybody is talking about .exe files. But those get blocked by SmartScreen:

SmartScreen does not take care of script files. I am sure you can tweak your browser security (zone) settings to prevent such attacks, but I think this should be solved at the operating system level. And SmartScreen is no longer an Edge only thing, it does come up even if you download an .exe via Firefox. So, SmartScreen should kick in here and stop the attack.

What can we do?

As you can see, this can become quite dangerous – so which options do we have to prevent this?

First there are the “Attack Surface Reduction Rules”

Check out this great article series for more info on ASR Rules: https://techcommunity.microsoft.com/t5/microsoft-defender-atp/demystifying-attack-surface-reduction-rules-part-1/ba-p/1306420

When we take a closer look on those, from the first look two rules seem to be quite useful:

• Block executable content from email client and webmail
  
• Block JavaScript or VBScript from launching downloaded executable content

After some tests (and careful reading of the rule’s name ;-)), I found out that the second rule does not apply here. This rule blocks only scripts, that try to execute downloaded content. In our case, the user starts the executable content.

Of course, this rule can still be helpful. In the demo above, I am starting the calculator. A real attacker might load executable content via the initial .js script and would be stopped by our second ASR rule.

But it does not stop the initial script from execution.

However, the first ASR rule sounds promising. But again: my tests have shown, you have to read carefully, in this case not the name, but the description of the rule:

This rule blocks the following file types from launching from email opened within the Microsoft Outlook application, or Outlook.com and other popular webmail providers:

• Executable files (such as .exe, .dll, or .scr)
• Script files (such as a PowerShell .ps, VisualBasic .vbs, or JavaScript .js file)

(Source)

So according to my tests, this rule does not prevent such downloads from all websites/webmailer. What a pity!

MDATP For The Rescue!

If we look at the initial process tree from the start of this article, we can create an Advanced Hunting query to search for such occurrences:

DeviceProcessEvents 
| where InitiatingProcessFileName in ("iexplore.exe","chrome.exe","msedge.exe","firefox.exe")
| where ProcessCommandLine contains "wscript.exe"

Check out my GitHub for other AH rules.

With that, you can create a custom detection, create an alert or start actions when things like this happen:

Conclusion

I think SmartScreen should get the ability to also block scripts. I am not sure why the webmailer-ASR rule only blocks certain sites. If I could choose, I would recommend a rule that does block all scripts from execution, that have been downloaded. But I guess with that, we will get many false/positives because this seems to be quite common in the LOB area.

However, as the name states: those ASR rules are there to reduce the attack surface. So, turn them on!

In addition, I recommend, creating a custom detection in MDATP as showed above.

Thanks to Oliver Kieselbach & Thomas Höhner, they have been excellent discussion partners on this topic!