Category Archives: Tools

Malicious PowerPoint Documents Abusing Mouse Over Actions

A new type of malicious MS Office document has appeared: a PowerPoint document that executes a PowerShell command by hovering over a link with the mouse cursor (this attack does not involve VBA macros).

In this blogpost, we will show how to analyze such documents with free, open-source tools.

As usual in attacks involving malicious MS Office document, the document is delivered via email to the victims.
(MD5 DD8CA064682CCCCD133FFE486E0BC77C)

Using (a tool to analyze MIME files), we can analyze the email received by the user:


The output indicates that the mail attachment is located in part 5. We select part 5, and perform an HEX/ASCII dump of the first 100 bytes to get an idea which type of file we are dealing with:


A file starting with PK is most likely a ZIP file. So let’s dump this file and pipe into (a tool to analyze ZIP files):


It is indeed a ZIP file. Judging from the filenames in the ZIP file, we can assume it is a PowerPoint file: .pptx or .ppsx.

Using zipdump and option -E (the -E option provides extra information on the type of the contained files), we can get an idea what type of files are contained in this PowerPoint files by looking at the headers and counting how many files have the same header:


So the ZIP files (.pptx or .ppsx) contains 1 JPEG file (JFIF), 11 empty files and 36 XML files.

As said at the beginning, malware authors can abuse the mouseover feature of PowerPoint to launch commands. This can be done with an URL using the ppaction:// protocol to launch a PowerShell command.

To identify if this document abuses this feature, we can use YARA. We defined 2 simple YARA rules to search for the strings “ppaction” and “powershell”:

rule ppaction {
$a = "ppaction" nocase
<p style="text-align: justify;">rule powershell {
$a = "powershell" nocase

We use to apply the YARA rules on each file contained in the ZIP file:


As shown in the screenshot above, file 19 (ppt/slides/slide1.xml, that’s the first slide of the presentation) contains the string ppaction string, file 21 (ppt/slides/_rels/slide1.xml.rels) contains the string powershell.

Let’s take a look at file 19:


We can see that it contains a a:linkMouseOver element with an action to launch a program (ppaction://program). So this document will launch a program when the user hovers with his mouse over a link. Clicking is not required, as is explained here.

The program to be executed can be found with id rId2, but we already suspect that the program is Powershell and is defined in file 21. So let’s take a look:


Indeed, as shown in the screenshot above, we have a Target=”powershell… command with Id=”rId2″. Let’s extract and decode this command. First we use to extract Target values with a regular expression:


This gives us the URL-encoded PowerShell command (and a second Target value, a name for an .xml file, which is not important for this analysis). With and a bit of Python code, we can use module urllib to decode the URL:


Now we can clearly recognize the PowerShell command: it will download and execute a file. The URL is not completely clear yet. It is constructed by concatenating (+) strings and bytes cast to characters ([char] 0x2F) in PowerShell. Byte 0x2F is the ASCII value of the forward slash (/), so let’s use sed to replace this byte cast by the actual character:


And we can now “perform the string concatenation” by removing ‘+’ using sed again:


We can now clearly see from which URL the file is downloaded, that it is written in the temporary folder with .jse extension and then executed.

To extract the URL, we can use again:


A .jse file is an encoded JavaScript file. It’s the same encoding as for VBE (encoded VBScript), and can be decoded using this tool.


It’s rather easy to detect potentially malicious PowerPoint files that abuse this feature by looking for string ppaction (this string can be obfuscated). The string powershell is also a good candidate to search for, but note that other programs than PowerShell can be used to perform a malicious action.


We produced a video demonstrating a proof-of-concept PowerPoint document that abuses mouse over actions (we will not release this PoC). This video shows the alerts produced by Microsoft PowerPoint, and also illustrates what happens with documents with a mark-of-web (documents downloaded from the Internet or saved from email attachments).

“Zusy” PowerPoint Malware Spreads Without Needing Macros:
Tools used:

Using to detect files touched by malware

Yesterday, we released – a tool you can use to detect unwanted changes to the file sytem. The tool and documentation is available here:

Binsnitch can be used to detect silent (unwanted) changes to files on your system. It will scan a given directory recursively for files and keep track of any changes it detects, based on the SHA256 hash of the file. You have the option to either track executable files (based on a static list available in the source code), or all files. can be used for a variety of use cases, including:

  • Use to create a baseline of trusted files for a workstation (golden image) and use it again later on to automatically generate a list of all modifications made to that system (for example caused by rogue executables installed by users, or dropped malware files). The baseline could also be used for other detection purposes later on (e.g., in a whitelist);
  • Use to automatically generate hashes of executables (or all files if you are feeling adventurous) in a certain directory (and its subdirectories);
  • Use during live malware analysis to carefully track which files are touched by malware (this is the topic of this blog post).

In this blog post, we will use during the analysis of a malware sample (VirusTotal link:

A summary of options available at the time of writing in

usage: [-h] [-v] [-s] [-a] [-n] [-b] [-w] dir

positional arguments:
  dir               the directory to monitor

optional arguments:
  -h, --help        show this help message and exit
  -v, --verbose     increase output verbosity
  -s, --singlepass  do a single pass over all files
  -a, --all         keep track of all files, not only executables
  -n, --new         alert on new files too, not only on modified files
  -b, --baseline    do not generate alerts (useful to create baseline)
  -w, --wipe        start with a clean db.json and alerts.log file

We are going to use to detect which files are created or modified by the sample. We start our analysis by creating a “baseline” of all the executable files in the system. We will then execute the malware and run again to detect changes to disk.

Creating the baseline


Command to create the baseline of our entire system.

We only need a single pass of the file system to generate the clean baseline of our system (using the “-s” option). In addition, we are not interested in generating any alerts yet (again: we are merely generating a baseline here!), hence the “-b” option (baseline). Finally, we run with the “-w” argument to start with a clean database file.

After launching the command, will start hashing all the executable files it discovers, and write the results to a folder called binsnitch_data. This can take a while, especially if you scan an entire drive (“C:/” in this case).


Baseline creation in progress … time to fetch some cheese in the meantime! 🐀 🧀

After the command has completed, we check the alerts file in “binsnitch_data/alerts.log”. As we ran with the “-b” command to generate a baseline, we don’t expect to see alerts:

Capture 2.PNG

Baseline successfully created! No alerts in the file, as we expected.

Looks good! The baseline was created in 7 minutes.

We are now ready to launch our malware and let it do its thing (of-course, we do this step in a fully isolated sandbox environment).

Running the malware sample and analyzing changes

Next, we run the malware sample. After that, we canrun again to check which executable files have been created (or modified):


Scanning our system again to detect changes to disk performed by the sample.

We again use the “-s” flag to do a single pass of all executable files on the “C:/” drive. In addition, we also provide the “-n” flag: this ensures we are not only alerted on modified executable files, but also on new files that might have been created since the creation of the baseline. Don’t run using the “-w” flag this time, as this would wipe the baseline results. Optionally, you could also add the “-a” flag, which would track ALL files (not only executable files). If you do so, make sure your baseline is also created using the “-a” flag (otherwise, you will be facing a ton of alerts in the next step!).

Running the command above will again take a few minutes (in our example, it took 2 minutes to rescan the entire “C:/” drive for changes). The resulting alerts file (“binsnitch_data/alerts.log”) looks as following:


Bingo! We can clearly spot suspicious behaviour now observing the alerts.log file. 🔥

A few observations based on the above:

  • The malware file itself was detected in “C:/malware”. This is normal of-course, since the malware file itself was not present in our baseline! However, we had to copy it in order to run it;
  • A bunch of new files are detected in the “C:/Program Files(x86)/” folder;
  • More suspicious though are the new executable files created in “C:/Users/admin/AppData/Local/Temp” and the startup folder.

The SHA256 hash of the newly created startup item is readily available in the alerts.log file: 8b030f151c855e24748a08c234cfd518d2bae6ac6075b544d775f93c4c0af2f3

Doing a quick VirusTotal search for this hash results in a clear “hit” confirming our suspicion that this sample is malicious (see below). The filename on VirusTotal also matches the filename of the executable created in the C:/Users/admin/AppData/Local/Temp folder (“A Bastard’s Tale.exe”).

Screen Shot 2017-05-17 at 00.28.05.png

VirusTotal confirms that the dropped file is malicious.

You can also dive deeper into the details of the scan by opening “binsnitch_data/data.json” (warning, this file can grow huge over time, especially when using the “-a” option!):


Details on the scanned files. In case a file is modified over time, the different hashes per file will be tracked here, too.

From here on, you would continue your investigation into the behaviour of the sample (network, services, memory, etc.) but this is outside the scope of this blog post.

We hope you find useful during your own investigations and let us know on github if you have any suggestions for improvements, or if you want to contribute yourself!

Squeak out! 🐁