Shortcuts for Understanding Malicious Scripts

You are being exposed to malicious scripts in one form or another every day, whether it be in email, malicious documents, or malicious websites. Many malicious scripts at first glance appear to be impossible to understand. However, with a few tips and some simple utility scripts, you can deobfuscate them in just a few minutes.

Capture3SANS Instructor Evan Dygert conducted a webcast on October 3rd, 2018. This webcast teaches you how to cut through the obfuscation techniques the script authors use and not spend a lot of time doing it. Evan also demonstrates how to quickly deobfuscate a variety of malicious scripts.

The samples of the scripts he provided during the webcast can be downloaded here: Please note the password for the folder is: “infected”



Capture4We hope that the techniques presented in this webcast help you to begin deobfuscating potentially malicious JavaScript.  This topic is explored in depth in the SANS FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques course.  This class offers an excellent opportunity to understand the unique and insightful perspective that malware analysis can bring to your investigations.




New CheatSheets you might be interested in:

Tips for Reverse-Engineering Malicious Code – This cheat sheet outlines tips for reversing malicious Windows executables via static and dynamic code analysis with the help of a debugger and a disassembler. Download Here

REMnux Usage Tips for Malware Analysis on Linux – This cheat sheet outlines the tools and commands for analyzing malicious software on the REMnux Linux distribution Download Here

Cheat Sheet for Analyzing Malicious Documents – This cheat sheet presents tips for analyzing and reverse-engineering malware. It outlines the steps for performing behavioral and code-level analysis of malicious software. Download Here

Malware Analysis and Reverse-Engineering Cheat Sheet – This cheat sheet outlines tips and tools for analyzing malicious documents, such as Microsoft Office, RTF and Adobe Acrobat (PDF) files Download Here


For opportunities to take the FOR610 course, consider upcoming runs and modalities: 

US & International live training : Live events offered throughout the US, EMEA & APAC regions.

 DFIR Summits :  Two days of industry expert talks plus DFIR training events

Simulcast :   Live events from anywhere in the world.

OnDemand  : Learn at your own pace, anytime, anywhere.








DFIR Resources: Digital Forensic Blog | Twitter | Facebook | Google+ | Community Listservice | DFIR Newsletter

Inhibiting Malicious Macros by Blocking Risky API Calls


Microsoft Office Macros have been the bane of security analysts’ lives since the late 1990s. Their flexibility and functionality make them ideal for malware authors to use as a primary stage payload delivery mechanism, and to date the challenge they pose remains unsolved. Many organisations refrain from blocking them completely due to the impact it would cause to their users, and instead rely on a combination of detection and mitigation technology to compensate for the risk they pose.

I have long thought that it would be ideal if Microsoft were able to implement granular controls via group policy over which activities macros were permitted to perform, for example allowing the blocking of process execution or network activity. In the interim, I have been experimenting with alternative methods to limit which functions a macro can call, either by redefining or patching the high risk API calls to prevent their intended outcome.

Below we can see a very basic example of what a malicious macro might look like. The fact that the subroutine is named “AutoOpen” means that it will be run as soon as the document is opened (and if required, macros are enabled).  The command “Shell” at the beginning of the line instructs Word to execute the process as specified in the parameter, so in this case the macro will launch the Windows calculator.




Option 1 – Using global templates to override built-in functions

Shell is the function built into VBA which is used to launch new processes, and as such, can often be found in malicious macros. Malware authors leveraging macros as a primary stage payload typically want to either download or drop a file, and then execute it. Alternatively, they could decide to execute an existing process on the system, such as powershell, with parameters which will take actions against their intended target. Common to both of these methods is the requirement for something to be run, and this is where Shell comes in. If we were able to somehow disable the Shell function, then we might be able to prevent the malicious macro from succeeding in it’s goal.

The first experiment involved redefining the Shell function, with the hope that the newly defined function would override the built-in one. We can achieve this by placing the code in the global template which is named normal.dotm or within an add-in (which is effectively a template that is loaded every time Word is opened), either way, our code will become part of the malicious macros execution.

Below we can see the redefined function used as part of this experiment. This was saved within normal.dotm (the global template), with the intention that when Shell was called, rather than calling the system function to launch the process, our redefined function would be called, resulting in a popup warning the user that the activity had been blocked.




Then, using the one line test macro that attempts to execute ‘cmd.exe /c calc.exe’, we can see that the redefined function worked well and blocked the execution of the process. Unfortunately, it only seemed to work when the malicious code was placed within the document and not when it was within a seperate module. The reason for this is unknown and warrants further research, as if solved, this would be the easiest way to achieve our goal.




Option 2 – Patching associated API in VBE7.dll to alter behaviour

For a more surgical approach we can look at API hooking the dll which is leveraged when macro code is executed. Looking through the dlls, which are loaded into Word at runtime, we can observe that VBE7.dll includes a large number of exports that appear related to the execution of macro code. Below we can see a snapshot from the list of exports with one in particular highlighted, rtcShell, that warranted further investigation.




Digging into this function we can see that it’s nothing more than a small wrapper around the CreateProcess Windows API call. The particular code block which executes the process is listed below. Looking at the parameters being passed to the API,  we can see that the EBX register is being used to hold a pointer to the name of the process to be executed.




At this point, if we want to alter the way the process is launched we can patch the instructions to alter the process creation flags, which is one of the parameters passed to the CreateProcess API. Alternatively, we could completely patch out the API call to prevent the execution from occurring.

In this case we are going to leverage the CREATE_SUSPENDED process creation flag to allow the process to launch, but immediately be frozen into a suspended state, preventing the code from running.




The patch sets the ECX register to 4, which is the numeric value of CREATE_SUSPENDED, and then this is pushed as the creation flags parameter to the CreateProcess API call, resulting in the process being instructed to launch in a suspended state.




Following this patch, a test macro that was designed to launch powershell was executed, and as we can see from the process explorer window, it was placed into a suspended state, thus mitigating any impact and allowing an opportunity for endpoint protection sensors to scan and identify any threatening behaviour.




These are just proof of concepts, and would require more research and work before they were used in a production environment. I still believe that the ideal state would be for Microsoft to implement more granular security controls against macros, allowing organisations to continue using them, but at the same time empowering them with the ability to limit their capabilities depending on individual risk appetites.


Any comments or feedback would be very welcome!


-Adam (Twitter: @CyberKramer)

Leaving the Backdoor Open: Risk of Remotely Hosted Web Scripts


Many websites leverage externally hosted scripts to add a broad range of functionality, from user interaction tracking to reactive design. However, what you may not know is that by using them you are effectively handing over full control of your content to the other party, and could be putting your users at risk of having their interactions misdirected or intercepted.

How so? Well, when you reference a script file, either locally or remotely, you are effectively adding that code into your page when it’s loaded by the user. JavaScript, as an example, is a very powerful language that allows you to dynamically add or modify content on the fly. If the location and content of the script is controlled by someone else, the other party is able to modify the code as they see fit, whenever they wish. Let’s hope they never get compromised or go rogue!


How many of you would click Yes if this warning came with a script? Not many I suspect!

Demonstration of concept

I’ve put together a small demo page on my website to show the issue ( It’s pretty straight forward, I’ve referenced a script hosted on an external site – in this case my attempt to include some old style blink tags on my page.


However, rather than the intended script, the JavaScript on the other end was replaced with the following code, which redirects the user away from the intended site to, potentially, something malicious such as a phishing page.


It’s that easy. This concept is pretty basic, but what if the script was setup to conduct keylogging, or manipulate input data before it’s submitted? Uh-oh!

Well that doesn’t sound good, any suggestions?

Firstly, use the debugging functionality of your favourite browser to identify whether your website leverages any externally hosted scripts. I’ve used Google Chrome against my website and can see that Google Analytics fits into that category.


Now consider whether you can bring the scripts in-house and store them on your server. If you can’t and must use externally hosted scripts, it may be worth keeping an eye on what is being served up. Perhaps even schedule a web content malware scan against the script files on a regular basis. Additionally, make sure the site hosting the script is still live and the domain hasn’t expired, making it available for sale!

Happy holidays!

-Adam (Twitter: @CyberKramer)