How to Blue Team: Detecting Weaponized Office Documents on Apple Macs (OS X)

Ryan Glynn/ March 27, 2019/ Security and Technology/ 0 comments

Introduction to How to Blue Team:

There’s a lot of documents on how to use pen testing tools, how to crack, hack and break into things. Not a lot is written on how to detect these things, especially at the “Enterprise” level where a lot of the blog posts seem to give use cases that do not scale well. So, I figured I would share the things that I learn and what I feel are important aspects of Blue Team Monitoring that do not have good resources currently.

One thing to note about these posts is that they are platform independent. What does that mean? It means that I am not going to be posting “Splunk syntax” or “Elastic Syntax” or any platform specific methods of detection but rather I will tell you how to detect it regardless of which platform you run within your enterprise. While there are cool projects like – a lot of the posts I am going to make are not supported by this project due to some platforms not having the same functions as others.

Detecting Weaponized Office Documents on Apple Macs (OS X)

Cyber Kill Chain Category: Exploit

Fidelity: 4/5 (High)

Purpose and Goal

The purpose is to detect when a Microsoft application (e.g. word, excel, or powerpoint) spawns an unusual process (e.g. shell script or python) caused by a user opening a file. The goal is to catch weaponized documents that target (or account for) Mac OS devices. Weaponized docs have been seen in the wild to start to include OS detection within the VBA scripts to perform separate actions depending on if the OS is OSX or Windows (shown below).

VBA Code of Actual Malware that Runs Different Code Depending on OS

Most excel documents do not typically spawn python or shell commands.

In order to validate this alert, a VBA script was created that called a python script to initiate outbound connections. Obviously the scripts can be more complicated than this, but as a proof of concept it worked well. (Download to document included at bottom of page).

Data source(s) needed:

  • OSQuery or endpoint monitoring equivalent for Mac hosts

Writing the Alert:

  1. cmdline starts with either “sh ” OR contains “python” anywhere in it (case insensitive is best)
  2. If the Schema Table is from “Process Events” ( ):
    1. env MUST include “” anywhere in (case insensitive)
    2. env MUST NOT include any of the following:
      1. “”
      2. “”
      3. “”
      4. “”
      5. “”
    3. cmdline MUST NOT contain any of the following:
      1. /Contents/MacOS/MendeleyWordPlugin
      2. /XLSTAT
      3. Microsoft Error
  3. If the Schema Table is from “Processes” (
    1. cwd MUST Include ‘/Users/*/Library/Containers/*/Data’
      1. * are wildcards
    2. cwd MUST NOT include:
      1. /Users/*/Library/Containers/
      2. /Users/*/Library/Containers/
      3. /Users/*/Library/Containers/
      4. /Users/*/Library/Containers/
      5. /Users/*/Library/Containers/
      6. /Users/*/Library/Containers/
      7. /Users/*/Library/Containers/
      8. /Users/*/Library/Containers/
    3. cmdline MUST NOT include:
      1. /Contents/MacOS/Microsoft
      2. Microsoft Error
      3. /Microsoft
      4. /
      5. /Contents/MacOS/Open XML for Excel
      6. /Contents/MacOS/MendeleyWordPlugin
      7. /CoreMediaAuthoring.framework/Resources/CoreMediaAuthoringSessionHelper
      8. Add-Ins.localized/XLSTAT

Breaking the logic down:

This alert forks at step 2/3 – either the schema is from “processes” or it’s from “Process Events”. Your white-list may very depending on your environment but this should be a good baseline to get you started.

The logic is pretty simple – look for any process spawns that have command lines that indicate python or shell scripts and exclude anything that is run by non Office related products. An alternative way of writing this would be to explicitly call out the Microsoft Coms (e.g. Excel, PowerPoint) but that is more dangerous in case those values change depending on version (and we almost always want to minimize False Negative over False Positive).

How to Investigate

Hopefully in your environment you have the Open Files schema logging ( ). If not, it’s more difficult and requires asset access to identify the open file (not as easy as Sysmon unfortunately).

If you do have open files, simply look for the files that were opened around the same time as the script on the host. From here continue a normal investigation into the asset – what did the script do, where did the file come from? etc.

Keep in mind, the PID here can be tied to any other actions that the VBA enabled document performs (except for the file name itself). So if the VBA script performs multiple activities, you can pull all of them back by simply searching off of the PID.

If you do not have open files, you will need asset access to run some terminal commands to find any and all files that were opened around the time the detection occurred.

Test File

To create a test file simply open a new excel document and then open the VBA editor and paste the following code and save. If you do not know how to edit VBA Code – enable the Developer Ribbon and click on Visual Basic.

NOTE: WordPress is auto-reformatting the code below, please replace the double quotes with fixed double quotes and properly indent the IF statements.

Private Sub Auto_Open()
Dim stdout As String
Dim blah As String

blah = “\””import base64; exec(base64.b64decode(‘I2JsYWhoaGhoaAppbXBvcnQgb3MKcmVzcG9uc2UgPSBvcy5zeXN0ZW0oInBpbmcgLWMgMSAxMjcuMC4wLjEiKQpwcmludCByZXNwb25zZQ==’))\”” “
stdout = MacScript(“do shell script “”/usr/bin/python -c ” & blah & ” “” “)
If Err.Number <> 0 Then
MsgBox “Something went wrong.”, vbExclamation
MsgBox “Captured output: ” & stdout, vbInformation
End If
End Sub

Share this Post

Leave a Comment

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