In this unique talk, Proofpoint’s Greg Lesnewich takes us on a tour of recent North Korean APTs targeting macOS devices and offers researchers new techniques for hunting this increasingly active cluster through similarity analysis of Mach-O binaries and linked dynamic libraries.
While many state-aligned threats have dipped their toes into macOS Malware, North Korea has invested serious time and effort into compromising Apple’s desktop operating system. Its operations in macOS environments include both espionage and financial gain. macOS malware analysis is an exciting space, but most blogs on the subject deal with functionality and capability, rather than how to find more similar samples. Analysts are forced to rely on string searching, based on disassembler output or a strings dump; in contrast, executables for Windows have “easy” pivots such as import hashing or rich headers that help analysts to find additional samples without much effort.
This talk introduces some of those easy pivots for Mach-O files, using North Korean samples as an initial case study; along the way, Greg takes us on a tour of the North Korean clusters using Mach-O samples, how those clusters intersect, how their families relate to one another, and shows how some simple pivots can link a group’s families together.
About the Presenter
Greg Lesnewich is senior threat researcher at Proofpoint, working on tracking malicious activity linked to the DPRK (North Korea). Greg has a background in threat intelligence, incident response, and managed detection, and previously built a threat intelligence program for a Fortune 50 financial organization.
About LABScon 2023
This presentation was featured live at LABScon 2023, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLabs.
While looking for avenues of injecting code into platform binaries back in macOS Monterey, I was able to identify a vulnerability which allowed the hijacking of Apple application entitlements. Recently I decided to revisit this vulnerability after a long time of trying to have it patched, and was surprised to see that it still works. There are some caveats introduced with later versions of macOS which we will explore, but in this post we’ll look at a vulnerability in macOS Sonoma which has been around for a long time, and remains an 0day, urm, to this day.
It wasn’t so long ago that malware authors, much like software developers, were concerned about the size of their code, aiming to keep it as small and compact as possible. Small binaries are less noticeable and can be slipped inside other files or shipped in benign code, attachments and even images. Smaller executables take up less space on disk, are faster to transfer over the wire, and – if they’re written efficiently – can execute their malicious instructions with less tax on the host CPU. In days of small disk drives, slow network connections and underpowered chips, such concerns made good sense and helped malware to avoid detection.
In today’s computer environments, however, storage, bandwidth and processor power are rarely in short supply, and as a result both legitimate programs and malware have increased greatly in size.
While malware executables of several megabytes are now so common they are hardly worthy of mention, some recent malicious programs have taken the invitation to bloat to a new extreme. Malware binaries weighing in at 50MB or more are now widely in use by macOS malware authors, and binaries over 100MB can also be found in some campaigns, typically those involving cryptominers. Such massive file sizes can cause detection problems for some kinds of AV solutions and create triage and reversing challenges for malware analysts.
In this post, we dig into the phenomenon of massive malware binaries on macOS, explaining why they are becoming more common, the problems they cause for detection and analysis, and how defenders can successfully deal with them.
How Widespread are Large macOS Malware Binaries?
It is possible to get a feel for how common large malicious binaries are by hunting in public malware repositories like VirusTotal and filtering by size. For example, if we search for Mach-O binaries over 35MB recognized as malware by 5 or more vendors, the search today returns 524 hits.
Increasing the file size to 50MB or more returns 113 hits, with many of the files returned being samples of Atomic Stealer.
Malicious mach-O files over 50Mb (Source: VirusTotal)
Around 7 samples in the 75MB and 100MB size range are examples of OSX.EvilQuest malware. Adjusting our search for file sizes of 100MB returns over 20 files with five or more vendors detecting as malware; many of these are miners, including a coinminer executable weighing in at 345 MB.
A macOS malware executable over 300MB (Source: VirusTotal)
However, the problem is wider than just those files that vendors currently recognize as malware. Both detection solutions and analysts have to determine whether an unknown sample is suspicious or malicious, and if we look at the number of Mach-O binaries on VT in general that are over 35MB, we find almost 100,000 samples, with the number of samples over 100MB currently at almost 50,000.
(Source: VirusTotal)
We can even find a single Mach-O binary on VirusTotal with a file size of 600MB. Are there individual binaries larger than that? Almost certainly, but VirusTotal has a file size upload limit of 650MB, so above that we have a data blindspot for both legitimate and malicious files.
From the data we do have, it is clear large executables are a widespread phenomenon, but why are threat actors turning to bloated binaries and what problems do they cause for enterprise security?
Why Are Threat Actors Turning to Supersized Binaries?
There are a number of reasons why threat actors may choose to distribute malware in oversized binaries. Some large binaries such as cryptominers like BirdMiner (aka LoudMiner) are a result of bundling emulation environments such as QEMU in the malware.
Samples of LoudMiner containing the Linux QEMU emulation environment
Other large binaries are caused by using cross-platform programming languages like Go and Rust. In order to ensure these programs will run on the intended platform, the runtime, libraries and all other dependencies are compiled into the final payload.
In addition, Apple’s switch to ARM from Intel has resurrected the Universal/FAT binary format, in which two architectures are now compiled into a single binary to ensure that the same program will work regardless of whether the user runs it on an Intel Mac or an Apple silicon Mac. Any binary compiled into the Universal format is effectively doubled in size.
As we shall see in the next section, in some cases threat actors may simply bloat files with junk code to defeat file scanners with file size limits or to thwart analysis by malware researchers.
What Problems Do Outsized Binaries Cause For Detection and Analysis?
Massive individual binaries are a relatively recent phenomenon and they cause a headache for traditional AV scanners that rely on either computing a file’s hash or scanning it for malicious content. The larger the binary the longer it takes to scan, and when scanning across numerous files on a file system, the end result can be a sluggish, unresponsive system as the AV software increasingly hogs the host CPU to complete its task.
The performance problems associated with file scanning are historically one of the most oft-cited reasons for complaints from users and something that the industry has attempted to solve in various ways.
One typical solution employed by many AV scanners is to limit the maximum file size the scanner will accept. In the days when few legitimate programs reached more than 20MB that may have seemed like an acceptable compromise, but given today’s bloated binaries, that’s clearly no longer viable: it would mean that a lot of known malware would go undetected. Threat actors have even been known to bloat files with junk code precisely to defeat file size limits of scanners and malware repositories like VirusTotal, which as we noted above has a max file size upload limit of 650MB.
Massive files are not just a problem for detection software, but also for researchers, reverse engineers and malware analysts. With tens of megabytes of code to analyze, most of which is benign, junk or part of a standard runtime like Go, analysts can have a difficult time identifying exactly which parts of a binary are malicious. This can hamper efforts to find other, possibly undetected, malware samples using the same or similar code and allow threat actors to extend their campaigns without detection.
How to Detect Malware Hidden Inside Massive Binaries
Fortunately, there are solutions to the problem of massive binaries both for detection and analysis. The problems inherent in relying solely on file scanning have been well understood by vendors such as SentinelOne and were part of the paradigm shift that caused such solutions to adopt behavioral detection.
In contrast to a file scanning engine, a behavioral engine examines what a binary does when it is executed rather than examining the file’s content prior to execution. A behavioral approach allows a solution to avoid scanning large amounts of files or files of large sizes and instead determines whether an execution process is involved in malicious activity. Solutions like SentinelOne can thus detect and kill malware regardless of how it is packaged or how large the file is.
Security software that combines multiple detection mechanisms including behavioral and machine learning detection engines is now the standard for enterprise security.
Large binaries present malware analysts with a number of challenges. In this section, we will briefly describe a useful technique for finding interesting code among hundreds of thousands of lines of disassembly leveraging YARA and radare2.
Threat hunters are most familiar with using YARA to determine if a sample file contains strings or bytes similar to other known malware families, but we can also use the same technique to find interesting code typical of malware TTPs. Take the following YARA rule, for example:
This rule returns a match if the binary contains certain strings related to disabling or modifying tools or other processes on a device, a typical anti-analysis and evasion technique. We can create a list of rules with various TTP indicators to help us to statically determine what capabilities a file has that may be related to malware behavior. Here is another example of a rule to indicate a binary that contains code related to system discovery.
We can run our YARA rule set on a given binary from within a radare2 session and, by leveraging YARA’s -m and -s switches, obtain a list of possible TTPs and their offsets for further investigation.
Possible TTPs of Malware sample 1909e84ac796730b119c44c676a730e09fce5ded
In this example we create a radare2 alias to run our YARA TTP ruleset over the file. The alias is equivalent to the command:
yara -ms ttp.yara
In radare2, the alias can be defined locally within the current r2 session or more usefully as a global alias in the .radare2rc config file as:
(ttp x; !yara -$0w <path to>/ttp.yara `o.`)
We provide a starter YARA rule set here that other macOS malware analysts can use as a base from which to develop their own more comprehensive ttp.yara file.
The SentinelLabs starter rule set for statically detecting macOS malware TTPs
Conclusion
Massive binaries are becoming increasingly common on the macOS platform and defenders need strategies for dealing with them. Malware authors have embraced the idea of distributing huge binaries in part as a tactic for defense evasion and anti-analysis and in part as a result of turning to cross-platform languages that pack a runtime, library and other dependencies in the final payload.
Organizations can detect large malicious binaries by turning to solutions that include behavioral detection and do not rely solely on file scanning. Analysts can implement techniques such as those discussed above to help them triage massive macOS malware samples faster and more efficiently.
In this blog we'll look at what it takes to construct an in-memory loader for Mach-O bundles within MacOS Ventura without using dyld. We'll walk though the lower-level details of what makes up a Mach-O file, how dyld processes load commands to map areas into memory, and how we can emulate this to avoid writing payloads to disk.
Up until recently, we've enjoyed in-memory loading of Mach-O bundles courtesy of dyld and its NSCreateObjectFileImageFromMemory/NSLinkModule API methods. And while these methods still exist today, there is a key difference.. memory modules are now persisted to disk. So in this post we'll take a look at just what was changed in dyld, and see what we can do to restore this functionality... hopefully keeping our warez in memory for a little longer.
The following is a quick and dirty companion write-up for TRA-2021–34. The issue described has been fixed by the vendor.
After being forced to use WebEx a little while back, I noticed that the URIs and protocol handlers for it on macOS contained more information than you typically see, so I decided to investigate. There are a handful of valid protocol handlers for WebEx, but the one I’ll reference for the rest of this blog is “webexstart://”.
When you visit a meeting invite for any of the popular video chat apps these days, you typically get redirected to some sort of launchpad webpage that grabs the meeting information behind the scenes and then makes a request using the appropriate protocol handler in the background, which is then used to launch the corresponding application. This is generally a pretty seamless and straightforward process for end-users. Interrupting this process and looking behind the scenes, however, can give us a good look at the information required to construct this handler. A typical protocol handler constructed for Cisco WebEx looks like this:
While there are several components to this URL, we’ll focus on the last one — ‘p’. ‘p’ is a base64 encoded string that contains settings information such as support app information, telemetry configurations, and the information required to set up Universal Links for macOS. When decoding the above, we can see that ‘p’ decodes to:
This parameter corresponds to what’s known as “Universal Links” in the Apple ecosystem. This is the magical mechanism that allows certain URL patterns to automatically be opened with a preferred app. For example, if universal links were configured for Reddit on your iPhone, clicking any link starting with “reddit.com” would automatically open that link in the Reddit app instead of in the browser. The ‘ulink’ parameter above is meant to set up this convenience feature for WebEx.
The following image explains how this link travels through the WebEx application flow:
At no point in this flow is the ‘ulink’ parameter validated, sanitized, or modified in any way. This means that a given attacker could construct a fake WebEx meeting invite (whether through a malicious domain, or simply getting someone to click the protocol handler directly in Slack or some other chat app) and supply their own custom ‘ulink’ parameter.
For example, the following URL will open WebEx, and upon closing the application, Safari will be opened to https://tenable.com:
The following gif demonstrates this functionality.
It may also be possible for a specially crafted URL to contain modified domains used for telemetry data, debug information, or other configurable options, which could lead to possible information disclosures.
Now, obviously, I want to emphasize that this flaw is relatively complex as it requires user interaction and is of relatively low impact. For starters, this attack already requires an attacker to trick a user into visiting a malicious link (providing a fake meeting invite via a custom domain for example) and then allowing WebEx to launch from their browser. In this case, we already have an attacker getting someone to visit a possibly malicious link. In general, we wouldn’t report this sort of issue due to no security boundary being crossed; that’s too silly for even me to report. In this case, however, there is a security boundary being crossed in that we are able to force the victim to open a malicious link with a specific browser (Safari), which would allow an attacker to specially craft payloads for that target browser.
To clarify, this is a pretty lame, but fun bug. While it’s tantamount to getting a user to click something malicious in the first place, it does give an attacker more control over the endpoint they are able to craft payloads for.
Hopefully, you find it at least a little entertaining as well. :)
Back in December, we wrote about attacking macOS installers. Over the last couple of months, as my team looked into other targets, we kept an eye on the installers of applications we were using and interacting with regularly. During our research, we noticed yet another of the aforementioned flaws in the Microsoft Teams installer and in the process of auditing it, discovered another generalized flaw with macOS package installers.
Frustrated by the prevalence of these issues, we decided to write them up and make separate reports to both Apple and Microsoft. We wrote to Apple to recommend implementing a fix similar to what they did for CVE-2020–9817 and explained the additional LPE mechanism discovered. We wrote to Microsoft to recommend a fix for the flaw in their installer.
Both companies have rejected these submissions and suggestions. Below you will find full explanations of these flaws as well as proofs-of-concept that can be integrated into your existing post-exploitation arsenals.
Attack Surface
To recap from the previous blog, macOS installers have a variety of convenience features that allow developers to customize the installation process for their applications. Most notable of these features are preinstall and postinstall scripts. These are scripts that run before and after the actual application files are copied to their final destination on a given system.
If the installer itself requires elevated privileges for any reason, such as setting up a system-level Launch Daemon for an auto-updater service, the installer will prompt the user for permission to elevate privileges to root. There is also the case of unattended installations automatically doing this, but we will not be covering that in this post.
The primary issue being discussed here occurs when these scripts — running as root — read from and write to locations that a normal, lower-privileged user has control over.
Issue 1: Usage of Insecure Directories During Elevated Installations
In July 2020, NCC Group posted their advisory for CVE-2020–9817. In this advisory, they discuss an issue where files extracted to Installer Sandbox directories retained the permissions of a lower-privileged user, even when the installer itself was running with root privileges. This means that any local attacker (local for code execution, not necessarily physical access) could modify these files and potentially escalate to root privileges during the installation process.
NCC Group conceded that these issues could be mitigated by individual developers, but chose to report the issue to Apple to suggest a more holistic solution. Apple appears to have agreed, provided a fix in HT211170, and assigned a CVE identifier.
Apple’s solution was simple: They modified files extracted to an installer sandbox to obtain the permissions of the user the installer is currently running as. This means that lower privileged users would not be able to modify these files during the installation process and influence actions performed by root.
Similar to the sandbox issue, as noted in our previous blog post, it isn’t uncommon for developers to use other less-secure directories during the installation process. The most common directories we’ve come across that fit this bill are /tmp and /Applications, which both have read/write access for standard users.
Let’s use Microsoft Teams as yet another example of this. During the installation process for Teams, the application contents are moved to /Applications as normal. The postinstall script creates a system-level Launch Daemon that points to the TeamsUpdaterDaemon application (/Applications/Microsoft Teams.app/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS/TeamsUpdaterDaemon), which will run with root permissions. The issue is that if a local attacker is able to create the /Applications/Microsoft Teams directory tree prior to installation, they can overwrite the TeamsUpdaterDaemon application with their own custom payload during the installation process, which will be run as a Launch Daemon, and thus give the attacker root permissions. This is possible because while the installation scripts do indeed change the write permissions on this file to root-only, creating this directory tree in advance thwarts this permission change because of the open nature of /Applications.
The following demonstrates a quick proof of concept:
# Run installer. Wait for the TeamUpdaterDaemon to be called.
The above creates a symlink to an arbitrary payload at the file path used in the postinstall script to create the Launch Daemon. During the installation process, this directory is owned by the lower-privileged user, meaning they can modify the files placed here for a short period of time before the installation scripts change the permissions to allow only root to modify them.
In our report to Microsoft, we recommended verifying the integrity of the TeamsUpdaterDaemon prior to creating the Launch Daemon entry or using the preinstall script to verify permissions on the /Applications/Microsoft Teams directory.
The Microsoft Teams vulnerability triage team has been met with criticism over their handling of vulnerability disclosures these last couple of years. We’d expected that their recent inclusion in Pwn2Own showcased vast improvements in this area, but unfortunately, their communications in this disclosure as well as other disclosures we’ve recently made regarding their products demonstrate that this is not the case.
In response to our disclosure report, Microsoft stated that this was a non-issue because /Applications requires root privileges to write to. We pointed out that this was not true and that if it was, it would mean the installation of any application would require elevated privileges, which is clearly not the case.
We received a response stating that they would review the information again. A few days later our ticket was closed with no reason or response given. After some prodding, the triage team finally stated that they were still unable to confirm that /Applications could be written to without root privileges. Microsoft has since stated that they have no plans to release any immediate fix for this issue.
Apple’s response was different. They stated that they did not consider this a security concern and that mitigations for this sort of issue were best left up to individual developers. While this is a totally valid response and we understand their position, we requested information regarding the difference in treatment from CVE-2020–9817. Apple did not provide a reason or explanation.
Issue 2: Bypassing Gatekeeper and Code Signing Requirements
During our research, we also discovered a way to bypass Gatekeeper and code signing requirements for package installers.
According to Gatekeeper documentation, packages downloaded from the internet or created from other possibly untrusted sources are supposed to have their signatures validated and a prompt is supposed to appear to authorize the opening of the installer. See the following quote for Apple’s explanation:
When a user downloads and opens an app, a plug-in, or an installer package from outside the App Store, Gatekeeper verifies that the software is from an identified developer, is notarized by Apple to be free of known malicious content, and hasn’t been altered. Gatekeeper also requests user approval before opening downloaded software for the first time to make sure the user hasn’t been tricked into running executable code they believed to simply be a data file.
In the case of downloading a package from the internet, we can observe that modifying the package will trigger an alert to the user upon opening it claiming that it has failed signature validation due to being modified or corrupted.
Failed signature validation for a modified package
If we duplicate the package and modify it, however, we can modify contained files at will and repackage it sans signature. Most users will not notice that the installer is no longer signed (the lock symbol in the upper right-hand corner of the installer dialog will be missing) since the remainder of the assets used in the installer will look as expected. This newly modified package will also run without being caught or validated by Gatekeeper (Note: The applications installed will still be checked by Gatekeeper when they are run post-installation. The issue presented here regards the scripts run by the installer.) and could allow malware or some other malicious actor to achieve privilege escalation to root. Additionally, this process can be completely automated by monitoring for .pkg downloads and abusing the fact that all .pkg files follow the same general format and structure.
The below instructions can be used to demonstrate this process using the Microsoft Teams installer. Please note that this issue is not specific to this installer/product and can be generalized and automated to work with any arbitrary installer.
When downloaded, the binary should appear in the user’s Downloads folder (~/Downloads). Before running the installer, open a Terminal session and run the following commands:
# Rename the package yes | mv ~/Downloads/Teams_osx.pkg ~/Downloads/old.pkg
# Modify the post installation script used by the installer mv ~/Downloads/extract/Teams_osx_app.pkg/Scripts/postinstall ~/Downloads/extract/Teams_osx_app.pkg/Scripts/postinstall.bak
# Repackage and rename the installer as expected pkgutil -f --flatten ~/Downloads/extract ~/Downloads/Teams_osx.pkg
When a user runs this newly created package, it will operate exactly as expected from the perspective of the end-user. Post-installation, however, we can see that the postinstall script run during installation has created a new file at ~/Downloads/exploit that contains the output of the id command as run by the root user, demonstrating successful privilege escalation.
Demo of above proof of concept
When we reported the above to Apple, this was the response we received:
…
Based on the steps provided, it appears you are reporting Gatekeeper does not apply to a package created locally. This is expected behavior.
…
We confirmed that this is indeed what we were reporting and requested additional information based on the Gatekeeper documentation available:
Apple explained that their initial explanation was faulty, but maintained that Gatekeeper acted as expected in the provided scenario.
Essentially, they state that locally created packages are not checked for malicious content by Gatekeeper nor are they required to be signed. This means that even packages that require root privileges to run can be copied, modified, and recreated locally in order to bypass security mechanisms. This allows an attacker with local access to man-in-the-middle package downloads and escalates privileges to root when a package that does so is executed.
Conclusion and Mitigations
So, are these flaws actually a big deal? From a realistic risk standpoint, no, not really. This is just another tool in an already stuffed post-exploitation toolbox, though, it should be noted that similar installer-based attack vectors are actively being exploited, as is the case in recent SolarWinds news.
From a triage standpoint, however, this is absolutely a big deal for a couple of reasons:
Apple has put so much effort over the last few iterations of macOS into baseline security measures that it seems counterproductive to their development goals to ignore basic issues such as these (especially issues they’ve already implemented similar fixes for).
It demonstrates how much emphasis some vendors place on making issues go away rather than solving them.
We understand that vulnerability triage teams are absolutely bombarded with half-baked vulnerability reports, but becoming unresponsive during the disclosure response, overusing canned messaging, or simply giving incorrect reasons should not be the norm and highlights many of the frustrations researchers experience when interacting with these larger organizations.
We want to point out that we do not blame any single organization or individual here and acknowledge that there may be bigger things going on behind the scenes that we are not privy to. It’s also totally possible that our reports or explanations were hot garbage and our points were not clearly made. In either case, though, communications from the vendors should have been better about what information was needed to clarify the issues before they were simply discarded.
Circling back to the issues at hand, what can users do to protect themselves? It’s impractical for everyone to manually audit each and every installer they interact with. The occasional spot check with Suspicious Package, which shows all scripts executed when an installer package is run, never hurts. In general, though, paying attention to proper code signatures (look for the lock in the upper righthand corner of the installer) goes a long way.
For developers, pay special attention to the directories and files being used during the installation process when creating distribution packages. In general, it’s best practice to use an installer sandbox whenever possible. When that isn’t possible, verifying the integrity of files as well as enforcing proper permissions on the directories and files being operated on is enough to mitigate these issues.
More macOS Installer Flaws was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.
For a while I've wanted to explore the concept of leveraging a virtual machine on target during an engagement. The thought of having implant logic self-contained and running under a different OS to the base seems pretty interesting. But more so, I've been curious as to just how far traditional AV and EDR can go to detect malicious activity when running from a different virtual environment. While this is a nice idea, the issues with creating this type of malware are obvious, with increased comple...
Login
