{"id":20932,"date":"2023-01-05T09:01:53","date_gmt":"2023-01-05T17:01:53","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2023\/01\/05\/news-14665\/"},"modified":"2023-01-05T09:01:53","modified_gmt":"2023-01-05T17:01:53","slug":"news-14665","status":"publish","type":"post","link":"https:\/\/www.palada.net\/index.php\/2023\/01\/05\/news-14665\/","title":{"rendered":"Unraveling the techniques of Mac ransomware"},"content":{"rendered":"

Credit to Author: Microsoft Security Threat Intelligence – Editor| Date: Thu, 05 Jan 2023 17:00:00 +0000<\/strong><\/p>\n

Ransomware continues to be one of the most prevalent and impactful threats affecting organizations, with attackers constantly evolving their techniques and expanding their tradecraft to cast a wider net of potential targets. This is evident in the range of industries, systems, and platforms affected by ransomware attacks. Understanding how ransomware works across these systems and platforms is critical in protecting today\u2019s hybrid device and work environments.<\/p>\n

This blog provides details from our analysis of known ransomware families affecting macOS devices. As in other platforms, the initial vector of Mac ransomware typically relies on user-assisted methods like downloading and running fake or trojanized applications. It can, however, also arrive as a second-stage payload dropped or downloaded by other malware or part of a supply chain attack. Once running on a device, ransomware attacks usually comprise gaining access, execution, encrypting target users\u2019 files, and notifying the target with a ransom message.<\/p>\n

To perform these actions, malware creators abuse legitimate functionalities and devise various techniques to exploit vulnerabilities, evade defenses, or coerce users to infect their devices. We describe these techniques in detail below, based on our analysis of four Mac ransomware families: KeRanger, FileCoder, MacRansom, and EvilQuest. In particular, we take a deeper look at EvilQuest and one of its variants that had its ransomware component removed but was further improved with additional techniques and anti-analysis logic.<\/p>\n

While these malware families are old, they exemplify the range of capabilities and malicious behavior possible on the platform. Building durable detections for these techniques will help improve defenses for devices and networks against ransomware and other threats. As with any security research in Microsoft, this in-depth analysis of malware techniques informs the protection we provide through solutions like Microsoft Defender for Endpoint on Mac. We\u2019re sharing this information with the rest of the community as a technical reference that researchers can use and build upon to understand Mac threats and improve protections.<\/p>\n

File enumeration     <\/h2>\n

Targeting which files to encrypt is the most important step for any ransomware. We have seen various ways through which ransomware families have enumerated<\/a> files and directories on Mac:<\/p>\n

Using the Find<\/em> binary<\/h3>\n

FileCoder and MacRansom use the find<\/em> utility to search for files to encrypt. find<\/em> is a common utility binary that is generally found across many Unix based systems like macOS, Linux, etc. and incorporates many features that could help attackers to search for and select files. The output of the command is then passed as an argument to the function or binary that carries out the encryption of the files.<\/p>\n

Figure 1 shows part of the command used by FileCoder. It searches the \u201c\/Users\u201d and \u201c\/Volumes\u201d directories by invoking the said command twice, with a change on the path being enumerated and excluding its README file while searching the \u201c\/Users\u201d path.<\/p>\n

\"Screenshot
Figure 1. FileCoder\u2019s enumeration logic<\/figcaption><\/figure>\n

In the case of MacRansom, it searches for files in \u201c\/Volumes\u201d and the current user\u2019s directory. It uses -type f<\/em> to include regular files, -size +8c<\/em> to select files that are greater than 8 bytes, -user `whoami`<\/em> to select files that belong to the current user, and -perm -u=r<\/em> to get files for which the current user has readable permission. The output of the command in Figure 2 is then passed to another instance of the malware.<\/p>\n

\"Screenshot
Figure 2. MacRansom\u2019s enumeration logic<\/figcaption><\/figure>\n

Using library functions opendir, readdir, and closedir<\/h3>\n

KeRanger and EvilQuest use library functions to get the directory listing. It uses a sequence of opendir()<\/em>, readdir()<\/em>, and closedir()<\/em> to get the list of files.<\/p>\n

\"Screenshot
Figure 3. Library functions used in EvilQuest<\/figcaption><\/figure>\n

First, it uses opendir()<\/em> to open a directory by specifying the dirname<\/em>. The handle returned from the opendir() <\/em>function is used by the readdir()<\/em> function to scan files. readdir()<\/em> returns NULL if it reaches the end of the directory. It uses closedir() <\/em>at the end to close the handle to the directory.<\/p>\n

Using the NSFileManager class through Objective-C<\/h3>\n

There are open-source proofs-of-concept (POCs) and scripts where Objective-C functions are used to enumerate files. For example, the Gopher POC<\/a> uses this technique to scan for .docx files in the User\u2019s Documents directory.<\/p>\n

In this technique, NSDirectoryEnumerator<\/em> object is used to enumerate the directory\u2019s contents, while the path is specified in the enumeratorAtPath:<\/em> method. The function returns the enumerator, which is used to get all the paths of files and directories.<\/p>\n

\"Screenshot
Figure 4. Gopher\u2019s use of NSFileManager<\/figcaption><\/figure>\n

This method is unique to the Gopher POC and is not found in the four ransomware families we analyzed.<\/p>\n

Anti-analysis techniques<\/h2>\n

Malware creators deploy various anti-analysis techniques to evade or prevent the analysis of files by either analysts or automated analysis systems such as sandboxes. Among the Mac ransomware we studied, KeRanger, MacRansom, and EvilQuest employ hardware-based checks or use specific code apart from the usual obfuscation of strings to avoid analysis.<\/p>\n

Hardware-based checks<\/h3>\n

Checking a device\u2019s hardware model<\/h4>\n

This technique (T1497.001<\/a>), used by MacRansom, involves getting the hardware model of the system and checking a substring to detect if the malware is running in a virtual environment. Running inside a virtual machine (VM) often indicates that the malware is being analyzed by analysts or in a sandbox.<\/p>\n

\"Screenshots
Figure 5. The command used by MacRansom (above) determines the environment it is running on. Below the command is the comparison of the results between checking the hardware model of a MacBook Pro (left) and a Mac OS running on Parallels VM (right)<\/figcaption><\/figure>\n

The result of the command on a host device contains the substring \u201cMac\u201d, whereas the result on a Parallels VM setup doesn\u2019t. The malware stops if it detects its presence in a virtual environment.<\/p>\n

Checking the logical and physical processors of a device<\/h4>\n

MacRansom uses this technique (T1497.001) to check the count of the logical and physical CPU of the device.<\/p>\n

\"Screenshots
Figure 6. The command used by MacRansom\u2019s  (above) counts logical and physical CPUs present in the device. Below that is the logical and physical processors check comparison between a MacBook Pro (left) and a Mac OS running on Parallels VM (right)<\/figcaption><\/figure>\n

In this case, a host device\u2019s logical CPU count is usually twice the physical CPU count, whereas the values are the same for a VM instance. The command above divides the values of these two counts and compares them with 2. It makes the comparison to determine if the malware is running in a virtual instance or not.<\/p>\n

Checking the MAC OUI of the device<\/h4>\n

This technique (T1497.001<\/a>), used by EvilQuest variants, involves checking the MAC organizational unique identifier (OUI) prefix, which comprises the first 24 bits of a MAC address, to determine the device vendor. Checking the OUI is another technique to determine if the malware is running in a virtual environment.<\/p>\n

\"Screenshot
Figure 7. EvilQuest code that checks the MAC OUI prefix<\/figcaption><\/figure>\n

Figure 7 shows the EvilQuest code that gets the MAC address of the en0<\/em> <\/strong>network interface, and compares the first three bytes with the OUI values hardcoded in EvilQuest. The values (v8, v7, and v6 in Figure 7) are attributed to many known virtualization platforms such as Parallels, VirtualBox, and VMware.<\/p>\n

Checking the device\u2019s CPU count and memory size<\/h4>\n

Analysis environments, specifically automated ones, are often deployed with minimal CPU and memory. EvilQuest checks the device\u2019s CPU and memory size (T1497.001) to ensure it\u2019s not running in a virtual environment.<\/p>\n

The malware uses three different methods to check the number of CPUs. The first method uses the sysctl<\/em> function by passing the MIB (Management Information Base) structure containing CTL_HW<\/em> and HW_AVAILCPU <\/em>identifiers. If this first method fails, the malware uses the second method where it replaces HW_AVAILCPU with HW_NCPU. <\/em>If the second method also fails, it uses the command \u201csysctl -n hw.ncpu\u201d<\/em> as a third method to get the CPU count. EvilQuest further checks if the value of the CPU count is less than 2, which might indicate a virtual instance deployed with minimal hardware.<\/p>\n

\"Screenshot
Figure 8. EvilQuest code that checks for CPU count<\/figcaption><\/figure>\n

EvilQuest also checks the device\u2019s physical memory size to avoid analysis environments. It uses sysctl function<\/em> with the MIB structure CTL_HW<\/em> and HW_MEMSIZE <\/em>constants to check the physical RAM size. The result is then compared further with the size of 1GB, which might indicate a virtual instance.<\/p>\n

\"Screenshot
Figure 9. EvilQuest code to check the device\u2019s physical memory size<\/figcaption><\/figure>\n

Code-related checks<\/h3>\n

Delayed execution<\/h4>\n

Malware creators often use the delayed execution (T1497.003<\/a>) technique to prevent automated analysis systems from detecting the malware\u2019s actual behavior. KeRanger uses this delayed execution technique where, upon launching, it sleeps for three days before performing its malicious routines.<\/p>\n

\"Screenshot
Figure 10. KeRanger code used to delay its execution<\/figcaption><\/figure>\n

PT_DENY_ATTACH (PTRACE)<\/h4>\n

This technique (T1622<\/a>), used by both EvilQuest and MacRansom, is a known anti-debugging trick that prevents debuggers from attaching to the current malware process. It is used to avoid the debugging of malware files.<\/p>\n

\"Screenshot
Figure 11.  Code in MacRansom where it invokes ptrace with PT_DENY_ATTACH argument<\/figcaption><\/figure>\n

As seen in MacRansom\u2019s code (Figure 11), it first opens the handle to itself, where the ptrace<\/em> symbol is searched, and the address is retrieved. It is then called with the argument 0x1F<\/em>, a constant for PT_DENY_ATTACH<\/em>.<\/p>\n

EvilQuest implements the same technique in two ways. One method is a simple call to the ptrace<\/em> function with the argument 0x1F<\/em> as above. In another variant, the logic is implemented using syscall<\/em>. This method invokes ptrace<\/em> through syscall <\/em>with the PT_DENY_ATTACH<\/em> flag.<\/p>\n

\"Screenshot
Figure 12. Code in an EvilQuest variant where it uses Syscall(ptrace) to avoid debuggers  <\/figcaption><\/figure>\n

Additionally, the EvilQuest variant also verifies if the PT_DENY_ATTACH operation is successful. To do so, it first registers a handler for the signal SIGSEGV<\/em> and calls the ptrace<\/em> method again with the argument PT_ATTACH<\/em>. <\/strong>This ptrace()<\/em> call with PT_ATTACH<\/em> flag throws a SIGSEGV<\/em> signal if it fails to attach to the process, which further invokes the handler. The handler sets a variable that is checked next to determine the success of PT_DENY_ATTACH<\/em> operation.<\/p>\n

P_TRACED flag<\/h4>\n

EvilQuest uses this technique (T1622<\/a>) to check whether it is being debugged. The technique is used to get the process structure and check for the P_TRACED<\/em> flag. If the flag is found to be set, it indicates that the process is being debugged. The malware then alters its behavior to avoid analysis.<\/p>\n

\"Screenshot
Figure 13. Code in an EvilQuest variant where it checks for the P_TRACED flag<\/figcaption><\/figure>\n

Time-based check<\/h4>\n

Malware using this technique (T1497.003) checks if it is running in a sandbox by checking if the device\u2019s sleep<\/em> function is patched. Sandboxes attempt to patch the sleep <\/em>function to avoid execution delay, which is used by some malware. Ransomware like EvilQuest sleeps for a specified time between two time()<\/em> calls. Next, the difference in the timestamp is calculated and checked with the duration specified in sleep()<\/em> call.<\/p>\n

\"Screenshot
Figure 14. EvilQuest code that checks patching of sleep function<\/figcaption><\/figure>\n

Persistence<\/h2>\n

Malware commonly uses persistence to ensure it runs even after a system restart. Among the Mac ransomware families analyzed, we\u2019ve seen persistence techniques in EvilQuest and MacRansom. The following are persistence techniques implemented by these malware families.<\/p>\n

Creating launch agents or launch daemons<\/h3>\n

Creating Launch Agents (T1543.001<\/a>) or Launch Daemons (T1543.004<\/a>) is a persistence method that uses launch items. This technique utilizes a property list (PLIST) file, which is used in macOS to specify configurations and properties in respective directories to gain persistence. EvilQuest can create both Launch Agent and Launch Daemon files, while MacRansom typically creates a Launch Agent file. <\/p>\n

\"Screenshot
Figure 15. EvilQuest\u2019s launch daemon PLIST file<\/figcaption><\/figure>\n

The ProgramArguments<\/em> key in the PLIST file (Figure 15) specifies the process to run with arguments if any, and RunAtLoad<\/em> and KeepAlive<\/em> keys are used to ensure that the process is continuously running.<\/p>\n

Using kernel queues<\/h3>\n

The kernel queue (kqueue<\/em>) provides a way for an application to get notifications based on various conditions and events. In the case of EvilQuest, it uses this method to restore itself based on notification it receives in case any modifications are made to the list of files it wants to monitor. Different EvilQuest variants use different versions of this implementation.<\/p>\n

\"Screenshot
Figure 16. EvilQuest variant\u2019s codes used to initialize file monitoring (left) and to restore files after modification (right)  <\/figcaption><\/figure>\n

It first creates the kernel event (kevent<\/em>) queue using the kqueue()<\/em> system call. Next, it forms a structure for each file containing its file handle and the required filters and flags to register the files to monitor. The pointer to this array of structures is passed in the changelist<\/em> argument to the kevent()<\/em> call. The eventlist<\/em> parameter then stores any changes observed. The malware invokes the kevent()<\/em> call in a loop. If any modifications are made to the files being monitored, EvilQuest tries to restore them.<\/p>\n

Encryption<\/h2>\n

The ransomware families we analyzed often share similar anti-analysis and persistence techniques. However, these same ransomware families differ in encryption logic. Some use AES-RSA encryptions, while others use system utilities, XOR routine, or custom encryption logic to encrypt files. These encryption methods range from in-place modification to creating a new file while deleting the original one. Common among the ransomware observed is adding a new extension or simply encrypting the file without adding any new one.<\/p>\n

FileCoder<\/h3>\n

FileCoder ransomware uses the ZIP utility to encrypt files. Files enumerated using the find<\/em> utility are passed to the ZIP utility with the flag -0<\/em> (no compression) and -P<\/em> (password), along with a randomly generated key for encryption.<\/p>\n

\"Screenshot
Figure 17. FileCoder\u2019s encryption logic<\/figcaption><\/figure>\n

FileCoder appends the .crypt<\/em> extension to encrypted files (Figure 17). It removes the original file and changes the timestamp of the newly created file, which also works as an evasion tactic. FileCoder only encrypts files present in the \/Users<\/em> and \/Volumes<\/em> directories. It invokes the command twice with the path change being enumerated. While enumerating files in the \/Users directory, it skips its dropped ransom note.<\/p>\n

KeRanger<\/h3>\n

KeRanger, on the other hand, uses AES encryption in Cipher block chaining (CBC) mode to encrypt files. It leverages the mbedtls<\/em> library for performing cryptographic functions.<\/p>\n

\"Illustration
Figure 18. KeRanger\u2019s key generation process<\/figcaption><\/figure>\n

The process begins by generating a key used for AES and hash-based message authentication code (HMAC). It generates a random number that is fed to the digest and an initialization vector, a value calculated by KeRanger and utilized in its key generation process. The result is then used as a key in the next iteration, along with the same random number. This process is done eight times, after which the result is used to set the key.<\/p>\n

\"Screenshot
Figure 19. KeRanger\u2019s encryption logic<\/figcaption><\/figure>\n

It then encrypts the random number generated earlier with the RSA key received from the server. To encrypt the files, it uses the generated AES key. It also calculates the HMAC of the original file content, which is written to the output file, along with keying information (data that can be used to decrypt the encrypted files such as key length, the encrypted random number, the initial vector, etc.) and encrypted content.<\/p>\n

MacRansom<\/h3>\n

MacRansom uses a symmetric algorithm for encrypting files and decrypting its ransom note \u201c._README_\u201d<\/em>. The ransom note contains encrypted data which MacRansom decrypts using a hardcoded key. It uses separate keys for encrypting the files and decrypting its ransom note.<\/p>\n

First, it enumerates the target files using the find <\/em>utility and passes it to another instance of the malware as mentioned in Figure 2. This new malware instance calculates the encryption key first by permuting a hardcoded key with a random number.<\/p>\n

\"Screenshot
Figure 20. MacRansom\u2019s key generation logic<\/figcaption><\/figure>\n

MacRansom reads the file\u2019s content and encrypts it with the permuted key generated earlier. In the process of encryption, if MacRansom encounters its ransom note by checking the filename which is \u201c._README_\u201d<\/em>, it uses a separate hardcoded key to decrypt its content.<\/p>\n

\"Screenshot
Figure 21. MacRansom\u2019s encryption logic<\/figcaption><\/figure>\n

EvilQuest<\/h3>\n

EvilQuest uses a custom symmetric key encryption routine to encrypt target files. For each target file, the malware creates a temporary file name using the format \u201c.<FILENAME>.e\u201d<\/em> and then checks if the file has already been encrypted by checking the presence of the marker 0xDDBEBABE<\/em>.<\/strong> If not, it reads the target file, encrypts the content, and writes the content to the temporary file. After encrypting the content, the malware encodes the file encryption key and appends the keying information to the file along with the marker. It then proceeds to delete the target file and rename the temporary file to the original target file\u2019s name.<\/p>\n

\"Screenshot
Figure 22. EvilQuest\u2019s encryption process<\/figcaption><\/figure>\n

EvilQuest\u2019s other capabilities<\/h2>\n

Further analysis of some variants of EvilQuest shows interesting capabilities on top of encrypting files. In this section, we discuss other behavior that we have observed in the two EvilQuest variants analyzed apart from their encryption routine. We noted behaviors such as file infection, keylogging, info stealing, disabling security solutions, and in-memory execution.<\/p>\n

Over the past years, we have observed many variants of EvilQuest that removed its ransomware component. Tracking behavior changes in malware is important to understand how these affect devices and data and how to prevent these attacks effectively. These additions and changes in behavior might also provide clues about EvilQuest\u2019s future attacks.<\/p>\n

File infection<\/h3>\n

EvilQuest can infect Mach-O files by inserting its code (T1554<\/a>). To identify files to infect, it scans through the \/Users<\/em> directory. It calls a routine for each file found. This routine checks the magic bytes of the file to determine whether the file is a Mach-O binary. It also skips the file if the path contains .app<\/em> or if the file size exceeds 25 MB.<\/strong><\/p>\n

\"Screenshot
Figure 23. EvilQuest\u2019s code checking for the magic bytes<\/figcaption><\/figure>\n

After scanning and finding target files, EvilQuest prepends its code to the target file and appends a trailer, which contains data such as marker and offset to the original binary code. EvilQuest uses the marker 0xDEADFACE<\/em> in the trailer data to check whether a file is infected.<\/p>\n

\"Illustration
Figure 24. Structure of a file infected by EvilQuest<\/figcaption><\/figure>\n

If any of the infected file is executed, EvilQuest has checks to identify, if it\u2019s running from an infected file and to execute the original binary using the following logic:<\/p>\n

    \n
  1. Extract the trailer to check if the current process is infected.<\/li>\n
  2. Go to the offset present in the trailer.<\/li>\n
  3. Read the original binary content from the offset of the calculated size to a buffer.<\/li>\n
  4. Format and form another path: <PATH>\/.<FILE_NAME>1.<\/em><\/li>\n
  5. The original binary content is written in the above file.<\/li>\n
  6. Provide executable permissions to this newly created file and execute the file.<\/li>\n<\/ol>\n

    Keylogging<\/h3>\n

    We observed two mechanisms of keylogging (T1056.001<\/a>) in two EvilQuest variants we analyzed. The first mechanism uses the API CGEventTapCreate<\/em><\/a>, while the second uses the IOHIDManagerCreate<\/em><\/a> API.<\/p>\n

    Using the CGEventTapCreate API<\/h4>\n

    This API creates an event tap to monitor human interface devices (HID) like keyboards. Keylogging starts upon receiving commands from a command and control (C2) server.<\/p>\n

    \"Screenshot
    Figure 25. EvilQuest code for logging keystrokes using the CGEventTapCreate API<\/figcaption><\/figure>\n

    The malware creates an event tap using CGEventTapCreate<\/em> and uses CGEventTapEnable<\/em> to activate it. The callback function seen in this EvilQuest variant converts the constant and prints it on the standard output.<\/p>\n

    Using the IOHIDManagerCreate API<\/h4>\n

    This API is used to communicate with and monitor HID devices. To achieve this, EvilQuest uses the following functions:<\/p>\n