What is a Daemon Process? And Rosetta 2 Artifacts in macOS

Not Lost in Translation: Intrusions of Rosetta 2 Artifacts in macOS

Overview

In 2020, macOS 11 (Big Sur) launched Rosetta 2, sometimes known internally as OAH, which allowed binaries developed for x86-64 architectures to operate on Apple Silicon (ARM64) architectures. At the moment of execution, Rosetta 2 can translate both signed and unsigned x86-64 binaries either in advance or just in time. Over the past year, Mandiant has discovered a number of new, extremely complex macOS malware variants, particularly those that are coded for the x86-64 architecture.

According to Mandiant, this architecture choice was probably the result of more lenient execution policies and a higher likelihood of compatibility on victim systems. Unsigned ARM64 binaries are more challenging to run because macOS has more stringent code signing requirements for ARM64 binaries than x86-64 binaries running Rosetta 2. Nevertheless, all of the recently discovered APT malware families that Mandiant had seen in the previous 12 months were self-signed, most likely in an effort to circumvent additional compensatory security measures that were in place on macOS.

What is a daemon process?

An operating system’s daemon is a computer software that executes operations in the background without requiring direct user input. The Linux and Unix operating systems frequently contain daemons.

How are daemons operated?

Certain events or actions cause daemons to become active.

• When the computer boots up, they frequently open automatically.
• Since daemons don’t need user input, they don’t have a graphical user interface.
• Even when no one is using the computer, they still run.

What are daemons used for?

• Control the system’s resources
• Manage connections to networks
• Offer assistance to other programs.
• Automate repetitive processes.
• Make sure that essential services are available.
• Boost computer systems’ overall dependability and efficiency

Daemon examples include:

• System logging is implemented by syslogd.
• Incoming SSH connections are served by sshd.
• Database server: MySQL
• Web server (httpd)
• The Common Unix Printing System, or CUPS, controls how print jobs are distributed and queued.
• Low memory killer, or lmkd daemon, which keeps track of an Android system’s memory condition

Rosetta 2 Cache

The Rosetta 2 Daemon process (oahd) verifies whether an ahead-of-time (AOT) file for the binary is present in the Rosetta 2 cache directory on the Data volume at /var/db/oah/<UUID>/ when an x86-64 binary is run on a system that has Rosetta 2 installed. It looks like the UUID value in this file location is created at random during installation or update. Writing translation code to a.in_progress file and then renaming it to a.aot file with the same name as the original binary will create an AOT file if one doesn’t already exist. The translated binary is subsequently executed by the Rosetta 2 Daemon process.

The OAH Daemon user account _oahd is the owner and guardian of the /var/db/oah directory and its offspring. Only when System Integrity Protection (SIP) is turned off which necessitates starting in recovery mode can other user accounts interact with these files.

The directories located under /var/db/oah/<UUID>/ represent translated binaries with binary UUID values. These binary UUID numbers are specifically SHA-256 hashes that are produced by combining the Mach-O header, the binary file path, timestamps (made, modified, and altered), size, and ownership details. A fresh Rosetta AOT cache directory and file are produced if the same program is run with any of these parameters altered.

Changing the content of a file on an APFS file system will update the timestamp, which essentially means that content changes can result in the generation of a new binary UUID and AOT file, even though the content of the binaries is not included in this hashing process. In order to lower the chance of AOT poisoning, the mechanism is ultimately made to be extremely sensitive to any changes made to x86-64 binaries at the byte and file system levels.

Until macOS system updates, the Rosetta 2 cache binary UUID directories and the AOT files they hold seem to remain in place. It has been discovered that the cache directory (the Random UUID directory) is deleted as a result of system updates. When x86-64 binaries are launched for the first time following the upgrade, new Binary UUID folders and AOT files are created, along with a directory with a different UUID value.

Universal Binaries and Translation

AOT files are created when an x86-64 process undergoing Rosetta 2 translation executes universal binaries (which contain both x86-64 and ARM64 code). This causes the x86-64 version of these binaries to be executed.

Mandiant saw an x86-64 version of the POOLRAT macOS backdoor being set up and the attacker using it to run universal system binaries like ping, chmod, sudo, id, and cat during an investigation into a crypto theft in the Democratic People’s Republic of Korea (DPRK). As a result, AOT files were produced, which showed that the virus had allowed the attacker to interface with the system.

Legitimate x86-64 code that runs malware provided as universal binaries has occasionally been the initial infection vector in macOS incursions. The x86-64 versions of malicious universal binaries are executed since the original x86-64 code runs under Rosetta 2, leaving behind AOT files and other Rosetta 2 Artifacts. In one instance, a malicious Python 2 script caused a malicious universal binary to be downloaded and run. Since there was no ARM64 version of the Python 2 interpreter, it operated under Rosetta 2. As a result, the system ran the malicious universal binary in x86-64, which produced AOT files. Google is able to examine the AOT file and comprehend its operation even though the attacker eventually removed the malicious program.

Unified Logs

The binary name values are declared as private, however the Rosetta 2 Daemon sends logs to the macOS Unified Log. If a custom profile is installed, these values can be set up to appear in the logs. AOT file lookups, the availability and use of cached AOT files, and the occurrence and completion of translation are all documented in informative logs. In certain instances, this was discovered to be the only indication of execution in the Unified Logs for binaries that are not set up to log to the Unified Log and are not started interactively. It is not always easy to correlate execution with other supporting Artifacts.

FSE Events

Even in cases when files in the Rosetta 2 Cache or Unified Logs are either unavailable or have been cleared, FSEvents can be used to determine the historical execution of x86-64 binaries. These records will demonstrate how folders are created inside the Rosetta 2 cache directory, how.in_progress files are created, and how the file is renamed to the AOT file in accordance with the original binary’s name.

Analysis of AOT Files

The Rosetta 2 cache’s AOT files can offer important information on past x86-64 binary execution evidence. Over the course of the previous year, Mandiant discovered that APT groups targeting bitcoin organisations frequently used macOS systems as their first point of access. Mandiant found evidence in most of these situations that the attackers removed the malware from these computers within minutes of committing a cryptocurrency heist. But because of SIP’s protection and the relative obscurity of this forensic artefact, the AOT files were preserved.

From a forensic standpoint, these AOT files’ creation and modification timestamps show when a certain binary was first run on the system using a particular set of characteristics that were used to create the SHA-256 hash. To create a more comprehensive picture of infection and potential attacker activity if child processes were executed, these timestamps can be verified with additional binary execution artifacts (such as Unified Logs or ExecPolicy, XProtect, and TCC Databases) when they are available, as well as file system activity through FSEvents records.

When the content (file hashes) of several AOT files for the same origin binary under various Binary UUID folders in the Rosetta 2 cache is identical, it usually indicates a change in the file data sections, or more frequently, the file system metadata alone.

Mandiant has demonstrated in the past that AOT files may be examined and utilised to identify malware by comparing their symbols. Mach-O binaries called AOT files are made up of translated x86-64 instructions from the original ARM64 code. They don’t have any API calls to refer to, but they do have jumpbacks into the original binary. Reverse engineering AOT files can reveal some functionality, but it is usually not possible to retrieve any static data, such as network-based indicators or configuration data.

Mandiant noticed developer file path strings as part of the fundamental Mach-O metadata in the AOT file of one macOS downloader seen in a well-known DPRK bitcoin robbery. This offered valuable information to support threat actor attribution and malware family evaluation, since the attacker erased the original binary after the heist, making it impossible to retrieve.

In any event, since the AOT file lacks a lot of the contextual information found in the original binary, it is more efficient to use the original entire binary rather than the AOT file to determine malware functionality. Static data and full Mach-O headers are included in this.

AOT File Poisoning

The possibility of introducing or altering AOT files to contaminate the Rosetta 2 cache has been extensively discussed in the industry. This is a legitimate attack vector in cases where SIP is turned off. Although Mandiant has not yet observed this method in action, it is wise to remain alert for signs of AOT poisoning when hunting or conducting investigations.

Comparing the contents of the ARM64 AOT files with what would be anticipated from the original x86-64 executable is the most effective method for doing this. This can be accomplished by creating a known-good AOT file with the original x86-64 executable and comparing it to the cached AOT file. AOT poisoning may be indicated by discrepancies, especially if injected shellcode is present.

In conclusion

On macOS, a number of forensic artifacts could preserve past proof of binary execution. However, combining FSEvents, Unified Logs, and most importantly remaining AOT files on disc has produced residual proof of intrusion on a macOS system in circumstances of advanced intrusions with forensically informed attackers, original binaries being erased, and no further security monitoring solutions.

AOT files and the artifacts associated with them should be examined in the analysis of any suspected macOS intrusion and used for hunting opportunities wherever feasible, even though signed macOS ARM64 binaries may be the way of the future.

The behaviour seen in the scenarios given was observed on different macOS versions ranging from 13.5 to 14.7.2. Rosetta 2 and macOS versions may act differently in the future or in the past.