There has been a lot of excitement recently as news broke about a new M/S Office malware dropper that targets Apple Mac OSX. The Opening U.S. Allies Rivals Digest Trump’s Victory – Carnegie Endowment for International Peace.dcom document is reported to be the first example of an Microsoft Office malware dropper discovered in the wild to target OSX. Microsoft Office malware droppers in general have become commonplace, but, one that targets Mac OSX… this is interesting news. Are Mac users safe from this type of attack? Let’s answer that question by taking a look inside this malware dropper and see how it works.



M/S Office droppers tend to follow a similar attack vector. Their goal is to entice a user into opening the document in order to discretely download and install malware on the end user’s machine. To accomplish this task, the dropper typically follows six common steps similar to the workflow described below:

Typical Microsoft Office Dropper Steps

  1. The document is named in a way that attracts a victim to open the file to read it.
  2. The document contains Microsoft’s Visual Basic for Applications (VBA) module streams. These are typically named ThisDocument, Module1, Module2, etc.
  3. As the document first opens, VBA scripts are automatically run via built-in functions such as AutoOpen, Workbook_Open, and Document_Open.
  4. As the VBA scripts run, malware is downloaded from the Internet via M/S components/functions such as Microsoft.XMLHTTP, System.Net.WebClient, MSXML2.XMLHTTP, and URLDownloadToFile.
  5. The downloaded malware is then saved to disk via components/functions such as Adodb.Stream and URLDownloadToFile.
  6. The malware is started using components/functions such as WScript.shell, cmd.exe, Scripting.FileSysstemObject, Shell.Application, and VBA shell().

The techniques described in Steps 4-6 above are specific to the Microsoft Windows platform.  They do not work on Mac OSX.  Typically, we have not seen OSX alternatives to these techniques, which have allowed the Mac User community a false sense of security from Microsoft Office-based malware droppers.



So… How is this new dropper distinguished from the common techniques outlined above? Why does it work on Mac OSX given that the techniques described were effective only on Microsoft Windows? Lets dive deeper and examine the document… First of all, it conforms to the initial dropper step outlined above. The document name ‘Opening U.S. Allies Rivals Digest Trump’s Victory – Carnegie Endowment for International Peace.dcom’ is intriguing and timely. Based on the name of the document, a potential victim may be tempted to open it to read more about Trump’s victory in the US elections. The next step is to examine any embedded scripts that may be in the document. To do so, we need to decode the document and extract the VBA Module Streams based on the MS-OVBA specification published by Microsoft. There are several good open source tools that are available to extract these streams (e.g., oledump written by Didier Stevens). Decoding the document reveals that it contains three VBA module streams as shown below (ThisDocument, FU5, and Module1). So far, the document conforms to our expected set of malware dropper steps. It is named interestingly and it contains VBA module streams. Looking at the ThisDocument VBA module stream below shows that the code leverages autoopen() to automatically run the Fisher() function as the document is opened. This is the function where we need to focus our analysis. Any malicious behavior most likely will be contained or called from within this function.


This satisfies the first three dropper steps outlined above. The document is interestingly named, contains VBA module streams, and leverages the built-in autoopen() function to automatically run VBA code as the document opens. So far, nothing is unusual about this malware dropper from the many other droppers that have been seen. Looking at the FU5 VBA module stream shown below doesn’t reveal anything interesting. It appears to be a module void of any logic. The only interesting attribute of this module stream is in the name itself. Typically, VBA module streams are named ThisDocument, Module1, Module2, etc. The name FU5 is not a default name that would be assigned to a module stream. Instead, the author chose it. Interesting choice…


Looking at the Module1 module stream shown below reveals what we are looking for.  It contains the Fisher() function referenced by autoopen() in the first module stream that we examined.  This is the function that is automatically run as the document is opened.


Examining the function, we see that the author is building a payload into the cmd variable and then piping it into a python command to execute it.  To be more specific, the author is building a Base64 encoded payload into the cmd variable, and then Base64 decoding and executing the payload via a tiny python script that is piped into python via the system call shown below. When this line of code runs, it dynamically builds a Python program similar to what is shown below and executes it.  The code shown below illustrates what the resulting python code would look like as constructed via the echo of the hard-coded script in the above line concatenated with the cmd variable that was built in the previous lines of code.  As you can see, the resulting code simply base64 decodes the payload and executes it. So, the real question is… What’s in the payload? If you remember from the six typical malware dropper steps we outlined earlier, so far, this dropper has only satisfied the first three steps (interesting file name, contains VBA streams and automatically launches the code). It still needs to perform the last 3 steps (download malware from the Internet, save it to disk and run it). Our guess is that this payload does just that. Lets decode the payload and see if our theory is correct… There are several easy ways to decode a Base64 encoded payload. One easy way is to paste the payload into one of the many online base64 decoding web sites. Instead, we are going to leverage the malware author’s idea and use Python to do it for us. If we remove the ‘exec()’ function from the Python script pasted above, the resulting script simply decodes the Base64 payload without actually running it. That technique seems pretty useful to me… let’s do it. Running the python listed above yields the decoded Python payload as shown below.  To make it easier to read and understand, we can paste the resulting payload into a code editor and reformat it as shown below (white-spacing, syntax colorization, etc.). Looking at the code above, the logic is fairly straightforward.

  • It checks to see if “Little Snitch” is running on the system. If so, it exits. Little Snitch is a host-based application firewall for OS X. Interesting… If you are running it, the dropper gives up and quits.
  • If Little Snitch is not running, the code establishes a connection to the website https://www.securitychecking.org:443/index.asp and downloads an RC4 encrypted payload.
  • It then decrypts the payload using the key fff96aed07cb7ea65e7f031bd714607d and runs it via the exec function.

Our hunch was correct!! The Python payload downloads malware from the Internet and launches it. The dropper has now satisfied each of the six typical malware dropper steps as outlined earlier. Albeit, it accomplished the last three steps using a technique that would work on OSX systems and avoided using the Microsoft Windows techniques typically seen in Microsoft Office droppers.



At the time of this writing, the www.securitychecking.org website was taken offline and the malware sample itself was not available. Not having a copy of the actual malware was limiting. However, what we didn’t see earlier in the analysis was that the VBA Module Streams included many commented out code artifacts as shown in the Module1 snippet below. In fact, more code was commented out, than was left active.


What if we Google for some of the more obscure text patterns (e.g., Pisechka_RH) to see if we can find if this code has been used by previous malware samples? Lets try it… The Google results reveal that VirusTotal is already aware of previous malware samples containing similar text patterns. Without the actual malware from our sample, it is difficult to make any conclusions as to its intended purpose. However, seeing artifacts that tie two samples together begs some questions:

  • Did the same author write these two droppers?
  • Did the author simply grab an existing working dropper and repurpose it?
  • Do both droppers target the same malware to download?
  • Does understanding one dropper give more insight into the other sample’s intent?

Does the name Pisecka give us any insight into the country of origin for this malware dropper? Interesting questions… what else can we find out from Google searches of other text patterns found in the code?  What about searching for the VBA code block that launched the original Python payload as shown below? Lets assume that this technique has been used before and try searching for it… Success!  Google points to the Empyre open source project shown above.  Scanning through the stagers.py module identified in the search results, reveals that much of the Python code in the malware dropper has been pirated from this GitHub project. The stagers.py code shown below lists logic almost identical to the base64 decoded payload we reviewed earlier. As described in the Empyre readme.md file, “EmPyre is a pure Python post-exploitation agent built on cryptologically-secure communications and a flexible architecture”. Seeing that Empyre is a multi-stage exploitation framework that allows the attacker continued access to its exploited hosts, begs some additional questions:

  • Since the malware author leveraged the first stage of the Empyre project, did they also use the second stage from Empyre?
  • Does studying Empyre give us further insight into the intent of the malware?
  • Did the author simply leverage the first stage from Empyre in order to download a newly developed second stage?



Overall, this Malware Dropper conforms to the same pattern seen in most other Microsoft Office droppers. It is named such that a victim is intrigued to open the document to read its contents. Once opened, the document contains VBA module streams that automatically launch in order to download malware from the Internet and run it. This dropper is distinguished in that it is specifically targeting Mac OSX platforms. Since it is unable to leverage the Microsoft Windows techniques to download and install malware from the Internet, it instead simply leverages Python (pre-installed on Mac OSX) to Base64 decode a payload and run it. This payload accomplishes the same tasks that were previously accomplished using Windows-specific techniques such as MSXML2.XMLHTTP, Scripting.FileSystemObject, and URLDownloadToFile. Simple, but effective…

Moral of this story:

“An ounce of prevention is worth a pound of cure.” – Ben Franklin

Mac users should no longer be complacent, believing that Microsoft Office documents can only be used to infect Windows platforms. This is a myth. Security best practices need to be followed by users on both Mac and Windows platforms.

  • Don’t open documents from untrusted sources.
  • Don’t configure Microsoft Office products to allow embedded Macros (VBA Code) run automatically.
  • When prompted with the Microsoft Office prompt “This document contains macros. Do you want to disable macros before opening the file?”, the correct answer is “Disable Macros”.


Thanks for reading…

You can also connect with me on Twitter at @kd_cybersec.


Written by 

Leave a Reply

Your email address will not be published. Required fields are marked *