Chapter 11: Malware Detection and Analysis with macOS Memory Forensics

Previously, attacks on macOS, as well as the development of specific malware for this operating system, were single events and were often limited to trivial adware. In 2020–2021, the main threat to macOS was still the adware Shlayer (https://redcanary.com/threat-detection-report/threats/shlayer/), but we are increasingly seeing targeted attacks with advanced threat actors behind them. A good example is APT32 or OceanLotus, a Vietnamese-linked group, which targeted macOS users with backdoors, delivered via malicious Microsoft Word documents.

The growing popularity of macOS in enterprise environments has triggered the appearance of various macOS post-exploitation tools: MacShellSwift, MacC2, PoshC2, and the Empire post-exploitation framework. Moreover, Malware-as-a-Service for macOS (https://www.computerworld.com/article/3626431/scary-malware-as-a-service-mac-attack-discovered.html) has already appeared on darknet forums.

Not surprisingly, new devices powered by M1 chips have not escaped the attention of cyber criminals either. Thus, Red Canary specialists recently discovered a new malware, Silver Sparrow, targeting Macs equipped with the new M1 processors (https://www.macworld.co.uk/news/new-malware-m1-mac-3801981/).

All this news tells us one thing: we need to know the tools and understand macOS analysis techniques. That is what this chapter will focus on.

Here are the topics that will be covered:

• Learning the peculiarities of macOS analysis with Volatility
• Investigating network connections
• Analyzing processes and process memory
• Recovering the filesystem
• Obtaining user application data
• Searching for malicious activity

Learning the peculiarities of macOS analysis with Volatility

In the previous chapter, we talked about the difficulties you may encounter when creating memory dumps and corresponding profiles for Volatility on macOS. However, that is not all. As you remember, Volatility relies on the Kernel Debug Kit to create macOS profiles in order to get all the data you need for parsing. This data is critical to the tool's performance because the data structures and algorithms used change from one kernel version to the next. At the same time, Apple no longer includes all the type information in the KDK, which leads to errors in the execution of many plugins. Another problem is that some Volatility plugins for macOS use Intel-specific data. Thus, plugins that work on memory dumps pulled from hosts on Intel may not work with dumps pulled from hosts on M1. Further on, we will use plugins that work for both Intel and M1 where it is possible, and where it is impossible, we will try to specify all the nuances. Besides, since the analysis methodology itself and searching for anomalies in macOS memory dumps will not differ significantly from those in Windows and Linux, this time we will focus on discussing tools and methods for obtaining certain information, rather than on the investigation methodology itself.

Technical requirements

To analyze macOS memory dumps, we will use both Linux and Windows systems. We will still work with Volatility 2.6.1 running on Ubuntu 21.04 (Hirsute) and programs such as Bulk Extractor will run on Windows. For the examples, we will use memory dumps from macOS Sierra 10.12.6, however, all the described manipulations can be applied to newer macOS versions as well.

Investigating network connections

Network activity analysis helps us determine which processes are establishing network connections, as well as which IP addresses and ports are being used. Since most malware and post-exploitation tools establish network connections, investigating network activity is one of our top priorities. In the case of macOS, Volatility offers a number of plugins to examine network interfaces, active network connections, and the contents of routing tables.

We can use the mac_ifconfig plugin to get information about the configuration of the network interfaces of the host under investigation:

Figure 11.1 – Volatility mac_ifconfig output

As you can see in the figure, this plugin provides information about the names of interfaces, their assigned IP and MAC addresses, as well as the set promiscuous mode.

Important Note

Promiscuous mode is a mode for a network interface controller that forces the controller to pass all the incoming traffic to the CPU, rather than passing only frames that the controller is programmed to receive.

In our case, we see the following interfaces:

• lo0 – Loopback Interface
• gif0 – Software Network Interface
• stf0 – 6to4 Tunnel Interface
• en0 – Ethernet with IPv4 and IPv6 addresses
• utun0 – VPN and Back to My Mac Interface

You can use the mac_netstat and mac_network_conns plugins to get information about network connections. The first plugin will show us information about both active connections and open sockets:

Figure 11.2 – Volatility mac_netstat output

At the same time, mac_network_conns provides information only about network connections:

Figure 11.3 – Volatility mac_network_conns output

In addition to network connection analysis, Volatility provides the possibility to study the routing table. The mac_route plugin is suitable for this:

Figure 11.4 – Volatility mac_route output

In the output of this plugin, we can see source and destination IP addresses, the name of the interface, and starting from OS X 10.7, we can also see sent/received statistics and expiration/delta times.

Another way to inspect network activity is to use the Bulk Extractor tool and the well-known net parser:

> .ulk_extractor.exe -o .output -x all -e net .MacSierra_10_12_6_16G23ax64

As a result, we get the packets.pcap file, which contains the network capture from the memory dump. To analyze this file we can, as before, use Wireshark:

Figure 11.5 – Network capture analysis

In this way, we can get information about the network activity on macOS. A natural complement to investigating the network is to look at active processes. This is what we will talk about next.

Analyzing processes and process memory

Processes can be analyzed both to look for anomalies and identify potentially malicious processes, and to observe user activity. As before, Volatility provides a number of plugins for obtaining data about processes and their memory. For example, the mac_pslist, mac_pstree, and mac_tasks plugins can be used to get a list of processes. From a practical point of view, mac_tasks is considered the most reliable source of information on active processes. This plugin, unlike mac_pslist, enumerates tasks and searches for the process objects instead of relying on a linked list of processes, which can be corrupted during macOS memory acquisition. Nevertheless, during testing on the latest versions of the operating system, the mac_pstree plugin turns out to be the most efficient, correctly displaying results for macOS on both Intel and M1 chips.

The plugins are launched in the same way as for Windows and Linux:

Figure 11.6 – Volatility mac_pstree output

In addition to the list of processes themselves, we are of course also interested in the arguments used to start these processes. To get this data, we can use the mac_psaux plugin:

Figure 11.7 – Volatility mac_psaux output

In the output of this plugin, you can find not only arguments but also full paths to executable files. However, when working with memory dumps taken from macOS on an M1 chip, this plugin can work incorrectly and cause errors.

In addition to the startup arguments of the processes, we should not forget about the history of the command line. In this case, we can use the mac_bash plugin, which retrieves commands executed in the shell, and the mac_bash_hash plugin, which displays the command alias hash table. Another way to find such information is to investigate the memory of the processes related to the Terminal application. We can extract executables and process memory for analysis with the mac_procdump and mac_memdump plugins respectively. However, at the moment, these plugins only correctly extract data for memory dumps obtained from hosts with an Intel chip. Despite this, for both Intel and M1 chips, we still have an opportunity to examine allocated memory blocks in each process, their permissions, and the names of the mapped files. This can be done with the mac_proc_maps plugin:

Figure 11.8 – Volatility mac_proc_maps output

As you can see in Figure 11.8, in the output of this plugin, we can find information about the files used by the process as well as their full path on disk. If necessary, we can also retrieve these memory blocks with the mac_dump_maps plugin. If we are interested in a particular block, we can specify its start address with the -s option, as shown next:

Figure 11.9 – Volatility mac_dump_maps results

As you can see, the contents of the first Siri process memory block have been successfully extracted and can be analyzed separately by additional tools. This way, we can try to extract executables, libraries, and other files. However, there is one more way of analyzing and extracting process-related files. Let's discuss it.

Recovering the filesystem

The methods of dealing with the filesystem in macOS memory are also not unique. First of all, we can examine the open file descriptors of a process using the mac_lsof plugin. Its launch, as well as the output format, does not differ from the corresponding plugin for Linux:

Figure 11.10 – Volatility mac_lsof output

As you see, here we can also use the -p option to identify a specific process and see the files related to it. In addition, we can collect information about all the files stored in the file cache. The mac_list_files plugin will help us with this:

Figure 11.11 – Volatility mac_list_files output

You can use the mac_recover_filesystem plugin to export files. Of course, Volatility also has the mac_dump_file plugin, for exporting specific files, but at the moment, this plugin shows poor results with the latest versions of macOS. The process for starting the mac_recover_filesystem plugin also remains the same:

$ vol.py --plugins=profiles -f /mnt/hgfs/flash/MacSierra_10_12_6_16G23ax64

--profile=MacSierra_10_12_6_16G23ax64 mac_recover_filesystem

-D /mnt/hgfs/flash/output/

The contents of the output folder in our case look like this:

Figure 11.12 – Volatility mac_recover_filesystem results

This way, we can recover the main locations and various files from the cached filesystem. Here, you can also find files related to a user's bash history:

Figure 11.13 – Recovered bash history files

The disadvantage of the plugin is that it currently does not work correctly on memory dumps collected from hosts with an M1 chip. If you work with older versions of macOS, you can also use the PhotoRec tool, which supports the HFS+ filesystem. This option is available for versions before High Sierra, since the default filesystem for mac computers using macOS 10.13 or later is APFS.

As you can see, exporting files from macOS memory is not an easy task, especially when it comes to the latest versions of the operating system. Nevertheless, there are some positive aspects. One of them is the ability to retrieve data from specific user applications quite easily.

Obtaining user application data

By default, macOS users have access to built-in applications from Apple, such as Calendar, Contacts, and Notes. Due to their quality and convenience, these applications have won the love of users, as well as the interest of investigators. Volatility provides a set of ready-to-use plugins allowing you to extract data from the above-mentioned applications. For example, to retrieve events from Calendar.app, you can use the mac_calendar plugin. To retrieve the contents of Notes messages, you can use mac_notesapp, and for contacts from Contacts.app, you can use mac_contacts:

$ vol.py --plugins=profiles -f /mnt/hgfs/flash/MacSierra_10_12_6_16G23ax64

--profile=MacSierra_10_12_6_16G23ax64 mac_contacts

Volatility Foundation Volatility Framework 2.6.1

<edited>

AppleappleAppleapple Apple ?5E

Johnyphish Johny phish Johny

Once you have this data, you can use regular expressions or YARA rules with the mac_yarascan plugin to try to find more information about the contact. For example, the email address associated with the contact.

Since we are talking about user activity, we should not forget the more general plugins that allow us to get data on what programs the user is running or what devices have been connected. In the first case, we use those same plugins to analyze the running processes. At the same time, if there is a need to associate a process with a specific user, we can use the mac_list_sessions plugin, which enumerates sessions from the session hash table. The way this plugin works is as follows:

Figure 11.14 – Volatility mac_list_sessions output

In this way, we get information about the process ID, its name, and the name of the associated user.

With connected devices, we can turn to the familiar mac_mount and mac_dmesg plugins:

Figure 11.15 – Volatility mac_mount and mac_dmesg plugins

As you can see in Figure 11.15, these plugins are full analogues to the Linux plugins of the same name.

Another interesting plugin for retrieving user data is mac_keychaindump. As the name implies, this plugin tries to recover possible keychain keys. Subsequently, if the recovery is successful, you can try to use Chainbreaker2 (https://github.com/n0fate/chainbreaker) and get the data on the name, account, password, as well as timestamps for the creation and last modification of the record in the keychain. However, it is important to keep in mind that at the time of writing the book, the last officially supported version of macOS is Catalina.

Of course, we should not forget to analyze processes related to browsers, email agents, and messengers, as they can contain a lot of useful data, including the URLs visited, email addresses, and conversations. To get this data, we can analyze the memory of relevant processes using the mac_memdump or mac_dump_maps plugins along with keyword, regular expression, or YARA rules searches. On the other hand, we can use the Bulk Extractor tool and the email parser to retrieve URLs and email addresses:

Figure 11.16 – Bulk Extractor email parser

In the output folder, we are interested in two files – email_histogram.txt and url_histogram.txt, which contain all the email addresses and URLs extracted from the memory dump, respectively:

Figure 11.17 – Extracted URLs

This way, we can analyze different user data. Our last topic of discussion will be the searching for and investigation of malicious activity.

Searching for malicious activity

Searching for malicious activity in macOS basically boils down to the basic elements we dealt with in the previous chapters: looking for suspicious network connections, looking for anomalies in processes, looking for code injection, looking for traces of hooking techniques used, and examining the commands executed in the shell. For example, Shlayer uses the shell to download the payload using the curl utility and -f0L as one of the command-line arguments, and to unpack a protected archive into a directory under /tmp using the unzip command. At the same time, running scripts and commands in the shell can be used in more sophisticated attacks when threat actors have direct access to the host.

To look for code injection, we can use the familiar mac_malfind plugin. However, please note here that running the plugin on memory dumps taken from hosts on the M1 chip may cause execution errors:

Figure 11.18 – Volatility mac_malfind output

This method comes in handy for detecting injections made with ptrace or the NSCreateObjectFileImageFromMemory API. Also, be prepared for a lot of false-positive results, which will need to be double-checked.

Do not forget about the injection of malicious libraries into processes either. In this case, the mac_proc_maps and mac_dyld_maps plugins can be useful. If the malicious library tries to hide itself, the mac_ldrmodules plugin, which compares the output of mac_proc_maps with the list of libraries obtained from libdl, can be used:

Figure 11.19 – Volatility mac_ldrmodules output

If necessary, you can also extract libraries of interest using the mac_librarydump plugin, which extracts any executable from process memory.

One of the distinguishing features of malicious activity analysis in macOS is the search for traces of persistence, because in this operating system the techniques used for persistence will be different from those discussed earlier. The most common techniques used by threat actors and malware are the following MITRE ATT&CK sub-techniques:

• T1547.011: Plist Modification
• T1547.007: Re-Opened Applications
• T1547.015: Login Items
• T1543.001: Launch Agent
• T1543.004: Launch Daemon
• T1546.004: Unix Shell Configuration Modification
• T1053.003: Cron

The first two sub-techniques can be used for both persistence and privilege escalation. To do so, attackers can modify or add paths to executables, add command-line arguments, and insert key/pair values to property list files (plist) in auto-run locations. To find traces of these sub-techniques, you can analyze plist files in ~/LaunchAgents and ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm locations. Also do not forget to check ~/Library/Preferences/com.apple.loginwindow.plist, ~/Library/Preferences/ByHost/com.apple.loginwindow.*.plist and an application's Info.plist files. You can try to extract these files from the cached filesystem or check on the host itself.

The Login Items, Launch Agent, and Launch Daemon sub-techniques use a similar approach. You should check ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm, ~/Library /Preferences/com.apple.loginitems.plist, and the application's /Contents /Library/Loginltems/ to find their traces. You should also check for new plist files in /System/Library/LaunchAgents, /Library/LaunchAgents/, /Library /LaunchDaemons/, and ~/Library/LaunchAgents/.

The Unix Shell Configuration Modification sub-technique is associated with modifying the files used when running the Terminal application. Terminal basically uses zsh, which is the default shell for all macOS versions since macOS Catalina. Please note that, for legacy programs, /etc/bashrc is executed on startup. As a result, we should check /etc/profile and /etc/profile.d, along with ~/.bash_profile, to find traces of this sub-technique. You can also check the /etc/shells file where the list of file paths for valid shells is located.

The last sub-technique is similar to the one we saw in Chapter 9, Malicious Activity Detection, so we will not go into it here in detail. However, it is worth mentioning that the T1547.006: Kernel Modules and Extensions sub-technique, which involves loading a malicious kext using the kextload command, was also popular for earlier versions of macOS. However, since macOS Catalina, kernel extensions have been deprecated on macOS systems. Nevertheless, Volatility provides plugins to explore loaded kernel modules and extensions: mac_lsmod and mac_lsmod_kext_map:

Figure 11.20 – Volatility mac_lsmod output

You can also use the mac_moddump plugin to export the specified kernel extension to disk. This sub-technique has often been used by rootkits to get persistence and escalate privileges.

In general, as with Linux rootkits, macOS rootkits are now extremely hard to come by. However, even for this rare case, we have a number of plugins that allow us to detect the different hooking techniques used by this type of malware:

• mac_apihooks – Checks for API hooks and allows you to detect inline hooking along with the Hooking Relocation Tables.
• mac_check_sysctl – Lists all sysctl values and handlers. Since sysctl is an interface that allows userland components to communicate with the kernel, it was widely used by different rootkits. Sysctl hooks provide an opportunity to hide rootkit data and create backdoors.
• mac_check_trap_table – Checks whether trap table entries are hooked. Trap table was implemented to satisfy requests to the BSD layer of OS X and macOS. Replacing trap table entries can be used for rootkit implementation, so it is also of interest to threat actors and malware.
• mac_notifiers – Detects rootkits that add hooks into I/O Kit. I/O Kit is a set of different tools and APIs that provides an opportunity to interact with hardware devices and can be abused by rootkits.
• mac_trustedbsd – Lists malicious trustedbsd policies. The TrustedBSD subsystem allows you to control access to system resources through policies that determine which processes can access which resources. Often these policies are one of the targets of rootkits.

By searching for anomalies and traces of manipulation of the aforementioned objects, we can thus detect rootkits on macOS.

Summary

The process of analyzing macOS memory dumps itself is not very different from that of Windows or Linux. However, there are a number of nuances to be considered.

First, Volatility profiles for the latest versions of macOS are hardly available, and at the moment, the only more or less adequate way to get them is to use proprietary memory dumping solutions, where profiles can be created automatically along with the dump.

Secondly, not all of the Volatility plugins that work fine on older versions of macOS show good results on the latest versions of the operating system. In addition, the performance of the plugins may depend on the architecture of the chip used on the target host from which the dump was taken.

Third, the tools that we used for file recovery from Windows and Linux, such as PhotoRec, will not be so helpful for macOS versions starting from macOS High Sierra, as they lack APFS support.

Otherwise, the methods of analysis of memory dumps themselves remain the same. When analyzing user activity, we tend to focus on running applications and the dynamic data they contain, Apple applications such as Calendar or Contacts, data from the Keychain, and mounted devices. To detect malicious activity, we focus on examining network connections, looking for anomalies in processes, detecting injected code and libraries, and detecting persistence techniques used.