Earlier this year, we reported on ESET’s discovery of OSX.DazzleSpy, an information stealer and backdoor likely targeted at Hong Kong’s pro-democracy activists. As part of our own threat hunting activities into DazzleSpy and related malware campaigns such as Zuru, Macma, Gimmick and pymafka, we recently came across a new malware sample that at first sight appeared to be a DazzleSpy variant. Further analysis, however, made that attribution tough to call, but the sample’s novel characteristics and use of multiple open-source projects should make it of interest to threat hunting and detection teams.
Dropper and Persistence
On 20th April, 2022, a DMG named ‘vpn’ was uploaded to VirusTotal.
Apparently unremarkable, further analysis showed that the disk image contained an application bundle called ‘vpn.app’, an application built with Platypus, an open-source toolkit that allows developers to turn scripts into Mac applications.
Platypus applications use a launcher executable in the app bundle to run the script in the bundle’s Resources folder. Since the script is simply a plain text file, it’s easy enough to examine to see what the “application” is really intended to do.
In this case, the script file (shown below) revealed that the supposed ‘vpn.app’ was really something quite different.
The script begins by creating a hidden folder, ~/.androids, in the User’s home directory. It then checks to see if the host architecture is x86_64 or not via the uname utility.
Depending on the architecture, the script downloads one of two possible second stage Mach-Os from IP http[:]//46[.]137.201.254. Although we were only able to retrieve the x86_64 payload, we can assume that since the Platypus-built application only runs on macOS that the alternative payload would be an arm64 executable built for Apple’s M1 architecture.
The payload is installed in the invisible directory as ~/.androids/softwareupdated. This executable is the target for the persistence LaunchAgent that the script writes to ~/Library/LaunchAgents/com.apple.softwareupdate.plist.
After installing the persistence agent, the script downloads and executes a further payload, dropped with the name covid. This is written to the user’s home directory and neither attempts stealth nor persistence.
The choice of the name ‘softwareupdated’ is a masquerade of an Apple system binary of the same name that lives at /System/Library/CoreServices/Software Update.app/Contents/Resources/softwareupdated.
Our initial assumption that this may have been a DazzleSpy variant stemmed from the fact that the persistence agent uses the same filename as DazzleSpy, i.e., ~/Library/LaunchAgents/com.apple.softwareupdate.plist, and an almost identical target executable name (DazzleSpy uses ‘softwareupdate’, rather than ‘softwareupdated’.). On top of that, both use a hidden folder in the user’s home directory to house the target executable (.local in the case of DazzleSpy, .androids here). However, those indicators might easily have been chosen to deliberately confuse attribution, and it is not beyond the realms of possibility that the indicators are merely coincidental.
Things become more interesting when we look at the payload. Static analysis of the malicious softwareupdated shows it to be a Sliver implant.
Sliver is an open source red team framework written in Go that supports C2 communications over a variety of protocols, including TLS, HTTP, and DNS.
While DazzleSpy used a mixture of open-source repos for various tasks, including the tonymillion Reachability framework, YYModel, and GCDAsyncSocket, this is the first time we’ve seen Sliver used in malware masquerading as Apple binaries and using com.apple labels for persistence.
Sliver implants offer the operator multiple functions useful to adversaries, including opening a shell on the target machine. The softwareupdated binary periodically checks in with the C2 to retrieve scheduled tasks, execute them, and return the results. Sliver implants also have the ability to allow the operator to open an interactive real time session for direct tasking and exploitation.
The covid binary is also a Go executable, this time packed with UPX. After unpacking, the binary turns out to be an NSApplication built using MacDriver, another open-source project available on Github that provides a toolkit for working with Apple frameworks and APIs in Go.
As with the Sliver implant, the covid executable reaches out to http[:]//46[.]137.201.254, this time on port 8001, and checks for the number of logical cores via sysctl as a means to detect whether it is running in a virtual machine. Executing the covid binary pops a WebKit view in a standard macOS application window.
More importantly, however, the covid binary uses a “fileless” technique to execute a further payload in-memory, evidenced by the tell-tale signs of NSCreateObjectFileImageFromMemory and NSLinkModule. This technique has been seen in a few campaigns in recent years, including by North Korean-linked APT Lazarus.
While presenting a distracting interface to the user, perhaps around the supposed ‘vpn’ capabilities, the covid binary retrieves and executes a third stage payload.
As the final payload was not available to us at the time of the analysis due to the C2 being offline, we are unable to say what the ultimate purpose of the covid binary was intended to be.
The indicators around this particular malware align neatly with what we might expect to see in a red team exercise – a red-teaming framework, singular (now offline) C2 hosted on Amazon, and the use of free and readily available open source tools like UPX, Sliver, MacDriver and Platypus, and, of course, binaries built from Go source code (an increasingly popular choice for malware authors of all stripes). We also note the lack of coherence and stealth used by the actors: an unsigned ‘vpn app’ dropping a payload called ‘covid’ in the User’s home directory doesn’t, at least without more context, make much sense of itself.
However, threat actors of all kinds can now easily imitate one another, and the use of indicators recently associated directly with the DazzleSpy campaign appears to be one of an unhappy accident, deliberate misdirection, or a genuine variant in a known campaign.
We also note that thanks to the use of free, publicly available software, this entire campaign targeting macOS devices was built without using any proprietary Apple tools or software, such as the Xcode IDE. For threat hunters and detection teams, we hope that awareness of the kind of TTPs reported here will aid detection of similar infection attempts, regardless of the nature of the threat actor.
Indicators of Compromise
Open-Source or Publicly-available Software Used
Source: Read More