{"id":51253,"date":"2023-03-30T19:54:03","date_gmt":"2023-03-30T19:54:03","guid":{"rendered":"https:\/\/packetstormsecurity.com\/news\/view\/34480\/Ironing-Out-The-macOS-Details-Of-A-Smooth-Operator.html"},"modified":"2023-03-30T19:54:03","modified_gmt":"2023-03-30T19:54:03","slug":"ironing-out-the-macos-details-of-a-smooth-operator","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/ironing-out-the-macos-details-of-a-smooth-operator\/","title":{"rendered":"Ironing Out The macOS Details Of A Smooth Operator"},"content":{"rendered":"

Ironing out (the macOS details) of a Smooth Operator<\/p>\n

The 3CX supply chain attack, gives us an opportunity to analyze a trojanized macOS application<\/p>\n

by: Patrick Wardle \/ March 29, 2023<\/p>\n\n\n\n\n

\n

Objective-See’s research, tools, and writing, are supported by the “Friends of Objective-See” such as:<\/p>\n

<\/center>\n<\/div>\n
\n???? ???? Want to play along?<\/p>\n

As \u201cSharing is Caring\u201d I\u2019ve uploaded the malicious dynamic library libffmpeg.dylib<\/a> to our public macOS malware collection. The password is: infect3d<\/p>\n

\n…please though, don’t infect yourself! <\/p>\n<\/div>\n

<\/p>\n

Background<\/h3>\n

Earlier today, several vendors uncovered a massive supply chain attack, spreading malware dubbed SmoothOperator:<\/p>\n

<\/p>\n
\n

Earlier today @CrowdStrike<\/a> reported a supply chain attack targeting the 3CX Voice Over Internet Protocol (VOIP) Windows desktop client.<\/p>\n

– 600,000 companies use it
– 12,000,000 users
– @Sophos<\/a> has identified a MacOS variant infected
– Currently attributed to Lazarus Group<\/p>\n

\u2014 vx-underground (@vxunderground) March 30, 2023<\/a><\/p><\/blockquote>\n

<\/center><\/p>\n

For details on the supply chain attack, affecting 3CX, you can read the following:<\/p>\n

While these analyses were a great start, they all were missing one very important piece! Details on the macoS infection and the specific malicious component(s).<\/p>\n

Specifically, though the reports noted 3CX\u2019s macOS application may have been trojanized this was not conclusively confirmed, with one vendor noting, \u201cat this time, we cannot confirm that the Mac installer is similarly trojanized\u201d.<\/p>\n

\u2026sounds like its up to us to get to the bottom on this!<\/p>\n

Triage<\/h3>\n

The CrowdStrike report<\/a> noted that they had seen malicious macOS activity emanating from 3CX\u2019s macOS application \u2026and were kind enough to provide a name and hash of a disk image they believed was infected. This was the key to starting our investigation, so a big thanks to them!<\/p>\n

We\u2019ll start with this disk image, 3CXDesktopApp-18.12.416.dmg (SHA-1: 3DC840D32CE86CEBF657B17CEF62814646BA8E98<\/code>):<\/p>\n

Trojanized Disk Image?<\/center> <\/p>\n

As you can see, it contains a single application, named \u201c3CX Desktop App\u201d.<\/p>\n

If we check its code-signing information, we can see not only is it validly signed by the 3CX developer, but also notarized<\/strong> by Apple! The latter means Apple checked it for malware \u201cand none was detected\u201d \u2026yikes!<\/p>\n

Trojanized Application<\/center> <\/p>\n

\nNotarization means the application will be allowed to run on recent versions of macOS, with the OS not blocking it. <\/p>\n

\u2026at this point, if I\u2019m being honest, the thought crossed my mind that maybe the reason none of the vendors (with their millions of dollars and large malware analysis teams) hadn\u2019t detailed the macOS trojanization mechanism was because there wasn\u2019t one? I mean, Apple had notarized the application, which in a way is giving it their sample of approval.<\/p>\n

I brushed this thought aside and kept digging \u2026which as the application was almost 400mb, was no trivial task.<\/p>\n

\n
\n% du -h \/Volumes\/3CXDesktopApp-18.12.416\/3CX\\ Desktop\\ App.app\n... 381M \/Volumes\/3CXDesktopApp-18.12.416\/3CX Desktop App.app <\/pre>\n<\/div>\n
I (eventually) came across a binary named libffmpeg.dylib<\/code>
\nburied deep within the App\u2019s Contents\/Frameworks\/Electron\\ Framework.framework\/Versions\/A\/Libraries<\/code> directory.<\/p>\n
Its SHA-1<\/code> hash is 769383fc65d1386dd141c960c9970114547da0c2<\/code>, and it was uploaded to VirusTotal<\/a> early today where it was not flagged by any of the AV engines as being malicious:<\/p>\n
 
A malicious dynamic library?<\/center> <\/p>\n
Using the file command, we see it\u2019s a Mach-O universal binary with 2 architectures: x86_64 & arm64:<\/p>\n
\n
\n% file 3CX\\ Desktop\\ App.app\/Contents\/Frameworks\/Electron\\ Framework.framework\/Versions\/A\/Libraries\/libffmpeg.dylib libffmpeg.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64] libffmpeg.dylib: Mach-O 64-bit dynamically linked shared library x86_64\nlibffmpeg.dylib: Mach-O 64-bit dynamically linked shared library arm64 <\/pre>\n<\/div>\n
A quick triage of this binary revealed XOR loops, timing checks, dynamically resolved APIs, and string obfuscations \u2026all shady! ????<\/p>\n
Time to dig deeper!<\/p>\n
Analysis of libffmpeg.dylib<\/code><\/h3>\n
In this section we\u2019ll analyze the malicious logic of the libffmpeg.dylib<\/code> binary. We\u2019ll focus on the Intel (x86_64<\/code>) versions as the Arm version doesn\u2019t appear to be infected!<\/p>\n
At the start of the Intel version, a thread is spawned via a function called run_avcodec<\/code>
\nThis kicks off a (thread) function at 0x48430:<\/p>\n
\n
EntryPoint:\n<\/span><\/span>0<\/span>x000000000004b180<\/span> xor eax, eax <\/span><\/span>0<\/span>x000000000004b182<\/span> jmp _run_avcodec <\/span><\/span>...<\/span>\n<\/span><\/span>\n<\/span><\/span>_run_avcodec:\n<\/span><\/span>0<\/span>x0000000000048400<\/span> push rax <\/span><\/span>0<\/span>x0000000000048401<\/span> movabs rax, 0xaaaaaaaaaaaaaaaa<\/span>\n<\/span><\/span>0<\/span>x000000000004840b<\/span> mov rdi, rsp\n<\/span><\/span>0<\/span>x000000000004840e<\/span> mov qword<\/span> [rdi], rax\n<\/span><\/span>0<\/span>x0000000000048411<\/span> lea rdx, qword<\/span> [sub_48430]\n<\/span><\/span>0<\/span>x0000000000048418<\/span> xor esi, esi <\/span><\/span>0<\/span>x000000000004841a<\/span> xor ecx, ecx\n<\/span><\/span>0<\/span>x000000000004841c<\/span> call imp___stubs__pthread_create <\/span><\/span>\n<\/span><\/span>...<\/span><\/span><\/span><\/code><\/pre>\n<\/div>\n
The function at 0x48430<\/code> (named sub_48430<\/code> in the disassembly) is where things get interesting!<\/p>\n
A quick triage of this function shows that its rather massive but more importantly contains various anti-analysis approaches aimed at thwarting static analysis. For example here is a snippet of decompilation showing a string begin de-XOR\u2019d:<\/p>\n
\n
do<\/span> {\n<\/span><\/span> *<\/span>(int8_t<\/span> *<\/span>)(rsp +<\/span> rax +<\/span> 0x1b40<\/span>) =<\/span> *<\/span>(int8_t<\/span> *<\/span>)(rsp +<\/span> rax +<\/span> 0x1b40<\/span>) ^<\/span> 0x7a<\/span>;\n<\/span><\/span> rax =<\/span> rax +<\/span> 0x1<\/span>;\n<\/span><\/span>} while<\/span> (rax !=<\/span> 0x32<\/span>);<\/span><\/span><\/code><\/pre>\n<\/div>\n
Clearly, it is not trivial to understand this solely via static analysis, so let\u2019s leverage dynamic analysis (read: use a debugger).<\/p>\n
Debugging a dynamic library is a bit tricky, as it can\u2019t be executed in a standalone manner. Not to worry, we can whip up a simple loader that will load it (or any passed in dylib) via the dlopen<\/code> API:<\/p>\n
\n
#import <dlfcn.h>\n<\/span><\/span><\/span>#import <Foundation\/Foundation.h>\n<\/span><\/span><\/span><\/span>\n<\/span><\/span>int<\/span> main<\/span>(int<\/span> argc, const<\/span> char<\/span> *<\/span> argv[]) {\n<\/span><\/span> <\/span><\/span> void<\/span> *<\/span> handle =<\/span> dlopen(argv[1<\/span>], RTLD_LOCAL |<\/span> RTLD_LAZY);\n<\/span><\/span> <\/span><\/span> dispatch_main();\n<\/span><\/span>\n<\/span><\/span> return<\/span> 0<\/span>;\n<\/span><\/span>}<\/span><\/span><\/code><\/pre>\n<\/div>\n
Once this is compiled (as an x86_64<\/code> program, as we want to debug the x86_64<\/code> version of libffmpeg.dylib<\/code>), we launch it via the lldb<\/code> debugger:<\/p>\n
\n
 % lldb dlopen_x64 libffmpeg.dylib <\/pre>\n<\/div>\n
We can then run the loader (dlopen_x64<\/code>) via a debugger passing in the malicious dylib libffmpeg.dylib<\/code>.<\/p>\n
Setting a breakpoint on pthread_create<\/code> allows the debugger to break right before the thread function of interest to us, is executed. This is important as we don\u2019t know exactly where the library will be loaded in memory (and thus can\u2019t initially set a breakpoint on the address of the thread function).<\/p>\n
\n
 % lldb dlopen_x64 libffmpeg.dylib ... (lldb) b pthread_create\n(lldb) run Process 21118 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x00007ff81c81c445 libsystem_pthread.dylib`pthread_create\nlibsystem_pthread.dylib`pthread_create:\n-> 0x7ff81c81c445 +0>: xorl %r8d, %r8d <\/pre>\n<\/div>\n
Once broken we can use the image list<\/code> debugger command to find the address that the libffmpeg.dylib<\/code> library is loaded, and from this, the address of the thread function. Then, we can set a breakpoint such the debugger will break once its about to be executed.<\/p>\n
Hooray, now we\u2019re in the debugger at the start of the thread function \u2026let\u2019s start stepping through it. We won\u2019t go through all its details, but instead highlight, well, highlights!<\/p>\n
First, it de-XORs components to build the following path: ~\/Library\/Application Support\/3CX Desktop App\/.session-lock<\/code>. It then attempts to open this file via the open<\/code> API. (In the debugger the RDI<\/code> register will hold the first argument (the file name) passed to open<\/code>):<\/p>\n
\n
\nTarget 0: (dlopen_x64) stopped.\n(lldb) x\/s 0x3041946f0\n0x3041946f0: \"%s\/Library\/Application Support\/3CX Desktop App\/%s\" ... libffmpeg.dylib`___lldb_unnamed_symbol1736:\n-> 0x10a0484f5 +341>: callq 0x10a208858 ; symbol stub for: open Target 0: (dlopen_x64) stopped.\n(lldb) x\/s $rdi\n0x304193ee0: \"\/Users\/patrick\/Library\/Application Support\/3CX Desktop App\/.session-lock\"\n<\/pre>\n<\/div>\n
If this file does not exist the function will exit (so we\u2019ll create a blank file here, so we can keep debugging).<\/p>\n
The function then executes logic to query the host to get the OS version, computer name, etc, etc. On my machine (macOS 13.3), once it has gathered this information and concatenated it together it looks something like this: \"13.3;Patricks-MacBook-Pro.local;6180;14\"<\/code>.<\/p>\n
It then generates a unique identifier (UUID) and write this out to a file named .main_storage<\/code> also in the ~\/Library\/Application Support\/3CX Desktop App\/<\/code> directory:<\/p>\n
\n
\n% hexdump -C ~\/Library\/Application Support\/3CX Desktop App\/.main_storage\n00000000 49 4d 48 4f 1f 42 4b 1f 57 4a 4f 4b 43 57 4d 1c |IMHO.BK.WJOKCWM.|\n00000010 4a 43 57 4d 48 1b 19 57 49 4f 4c 4e 4b 19 43 4e |JCWMH..WIOLNK.CN|\n00000020 19 4b 19 1c 7a 7a 7a 7a 7a 7a 7a 7a 7a 7a 7a 7a |.K..zzzzzzzzzzzz|\n00000030 5e b8 46 1e 7a 7a 7a 7a |^.F.zzzz|\n<\/pre>\n<\/div>\n
This file is \u201cencrypted\u201d with the XOR key 0x7a<\/code>.<\/p>\n
After various anti-debugging logic (e.g. timing checks) it builds a URL to query. We can easily dump this in the debugger to reveal that it is https:\/\/pbxsources.com\/queue<\/code>:<\/p>\n
\n
\n...\nProcess 18702 stopped (lldb) po $rax\nhttps:\/\/pbxsources.com\/queue <\/pre>\n<\/div>\n
\nThe domain pbxsources.com is listed by various vendors as an IoC to detect the Windows variant of this malware. <\/p>\n
It\u2019s not surprising the macOS variant used the same network infrastructure.<\/p>\n<\/div>\n
After setting a static user-agent (Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/108.0.5359.128 Safari\/537.36<\/code>) and adding various host info as HTTP headers, it connects out to the decrypted URL.<\/p>\n
Unfortunately the URL the malware is trying to reach (pbxsources.com) is now offline:<\/p>\n
\n
 % nslookup pbxsources.com\nServer: 1.1.1.1\nAddress: 1.1.1.1#53 ** server can't find pbxsources.com: NXDOMAIN <\/pre>\n<\/div>\n
\u2026so the malware doesn\u2019t get the HTTP 200 OK<\/code> it wants, and thus goes off to snooze.<\/p>\n
\n
rax =<\/span> strcmp(var_23F8, \"200\"<\/span>); <\/span><\/span>\n<\/span><\/span>...\n<\/span><\/span>\/\/no match?\n<\/span><\/span><\/span><\/span>do<\/span> {\n<\/span><\/span> time(rbp);\n<\/span><\/span> if<\/span> (0x0<\/span> >=<\/span> r14) {\n<\/span><\/span> break<\/span>;\n<\/span><\/span> }\n<\/span><\/span> sleep(0xa<\/span>);\n<\/span><\/span>} while<\/span> (true);<\/span><\/span><\/code><\/pre>\n<\/div>\n
As the C&C server is offline, our dynamic analysis comes to an end. But that\u2019s ok! Continued static analysis appears to show the malware expects to download a 2nd<\/sup>-stage payload. This appears to be saved as a file named UpdateAgent<\/code> (in the Application Support\/3CX Desktop App\/ directory)<\/p>\n
In the annotated decompilation, you can see that once the file is written out, the malware sets it to be executable (via chmod<\/code>), then executes it via the popen<\/code> API:<\/p>\n
\n
\/\/write out 2nd-stage payload\n<\/span><\/span><\/span>\/\/ path (likely): \"UpdateAgent\"\n<\/span><\/span><\/span><\/span>rax =<\/span> fopen$<\/span>DARWIN_EXTSN(r13, \"wb\"<\/span>);\n<\/span><\/span>fwrite(var_23F8 +<\/span> 0x4<\/span>, 0xfffffffffffffffc<\/span>, 0x1<\/span>, rax);\n<\/span><\/span>fflush(rax);\n<\/span><\/span>fclose(rax);\n<\/span><\/span>\n<\/span><\/span>\/\/make +x <\/span><\/span><\/span><\/span>chmod(r13, 0x1ed<\/span>);\n<\/span><\/span> <\/span><\/span>\/\/add \"\"> \/dev\/null\"\n<\/span><\/span><\/span><\/span>sprintf(r12, rbp);\n<\/span><\/span>popen$<\/span>DARWIN_EXTSN(r12, \"r\"<\/span>);<\/span><\/span><\/code><\/pre>\n<\/div>\n
I don\u2019t have access to this binary, what it does is a mystery.<\/p>\n
Detection<\/h3>\n
Let\u2019s end by talking how to detect the macOS variant of the SmoothOperator malware.<\/p>\n
First some IoCs (with the caveat that I don\u2019t know what \u201c3CX Desktop App.app\u201d normally does, but as we saw, the malicious library, libffmpeg.dylib<\/code>, interacts w\/ the following files)<\/p>\n
File based IoCs (found in ~\/Library\/Application Support\/3CX Desktop App\/<\/code>)<\/p>\n