Thursday, November 21, 2019

Easy Wins for All…Slowing Attacks With the Basics


The below was conducted in my home lab, configurations may/may not scale to an enterprise network. A good bit of work still needs to be done to the policies and configuration files.

It seems like nearly everyday a new "NextGen" product is debuted with the latest bells and whistles to stop the next APT attack.  Not many of us have the resources to update infrastructure to the latest and greatest, nor have time for a defense team to learn the product. With a majority of attacker gaining access to networks by way of LOLBINS/LOLBAS, natively on Windows, why not protect/prevent those same attacks with native tools?

 My motivation for this post comes from two of my favorite topics: endpoint detection, and malicious documents. This seemed like a perfect opportunity to put to use some of the native defense tools Windows has to offer to the test.  Additionally, posts by @PalantirTech and @mattifestation provided me with a starting point to look further into WDEG.

Tools Used

There may be an abundance of firewalls to secure your networks, however the Windows Firewall should be right up there with the best. The biggest selling point? It's already installed and ready to defend in a few clicks.  To defend against the use of valid Windows executables used for wrong, we can block their outbound communication. 

Note, this may not apply to all cases, depending on the need of the administrators/users. Just enabling the built-in firewall is a quick win that can block PowerShell and other programs from grabbing that second stage malware download.  Along with Windows Firewall, I deployed Windows Defender Exploit Guard (WDEG), as well as Windows Defender Application Control (WDAC) to create a code integrity policy, & application whitelisting via Applocker. 

Links to helpful blog posts will be at the bottom of the post.

The Attack

A less complicated malicious document that uses wscript.exe to download malware was utilized for testing. If we can stop these native Windows tools from executing, we can worry about more advanced attacks down the road.  .

The configuration and policy creation of all the above tools will not be included, there are plenty of great articles that cover this process.  Additionally, the tuning of the tools is something you have to experiment with in your own environment first and then make changes.

*NOTE*: It is probably best to deploy your chosen policies in audit mode before attempting to block anything. I quickly learned this while trying out different options for the Set-ProcessMitigation for winword.exe.  If users can't open Microsoft Word at all, they can't click on anything bad right?

With our test document open and running, let's dig in and see what's going on.

Figure 1

Not a lot going on in the first picture, initializing variables and functions. Moving on...

Figure 2

The code in figure two is much more interesting. We see the keyword "autoopen()" which indicates some behavior will occur automatically upon opening the document. The variables "Benaj" & "Architecture" seem to do most of the heavy lifting. "CreateObject is used to allow access to the target file system. The IF statement checks first if the path C:\1 exists, and if not it is created and the script continues to create files in the same directory named "keyload216**.cmd".

The following files are dropped on the target system.

Figure 3

A majority of the .cmd files are empty or contain obfuscated garbage. The main focus here should be on keyload21128.cmd and the mystery vbs script file "RGBset.vbs". Let's take a look at the keyload file.

Figure 4

Figure 5

In between the junk commands, it is pretty easy to make out the calls to initialize wscript.exe to make a HTTP request and if the status is not 200, quit.  At the bottom of figure five, the malicious command for wscript.exe is present.  An attempted download from http[:]// to be saved as WomanLove.exe.

Again we the RGBset.vbs script is called from the created directory to grab the executable.

The Basics, Man

Upon executing the document, I was immediately greeted with error messages for the executable and wscript.

Figure 6
Normally I would ship all my logs to my SIEM of choice and start parsing to find bad. This post is focused on detection/prevention. My home lab is already ingesting logs, the next step would be to start creating rules to fire on the ingested data instead of manually searching.

Figure 7

Figure 8

Our ASR policies as seen above our very descriptive, process name: "OFFICE_VBA" from a document is about all we need to know.

Again, I have to stress tuning and playing around with the different policies to get a feel for how operations are impacted and what is logged YCMV (Your Configuration May Vary).

Figure 9

Figure 10

Figure 11

While the event message can be altered to fit your needs, I think what is provided out of the box is more than enough. In addition to a Group Policy Object rule to block wscript.exe from communicating with any network.

Figure 10 displays an example of Defender detecting and removing malicious software. For those that do not have access to the latest "next-gen (insert tool here)", every event shown above is just waiting to be enabled on Windows 10.

While the document used for testing didn't involve anything overly complicated, it shows that attempted attacks can be alerted on and remediated without the need for bells and whistles that may be out of reach for many.

Can't forget about our Sysmon logs!

Figure 12

Figure 13

Figure 14


There were plenty of other logs to share, however I think the point has been made and this post is getting a tad long. Hopefully I was able to convey how easy it is to start with the basics; firewalls, native exploit protection, and whitelisting to at least detect when bad is happening. After configuring and tuning, prevention can take precedence over detection. The harder we make it for that first step in the network, the better chances are the attacker will move on to a softer target.

Hope you enjoyed!!

Helpful Links:

Document Hash:


JPCert's Log Analysis Training

6 Aug 2020 About a week or so ago, JPCert released their Log Analysis training slides and corresponding CSV files for each hands-on exercise...