APT & Targeted Attacks
New MacOS Backdoor Linked to OceanLotus Found
We identified a MacOS backdoor that we believe is the latest version of a threat used by OceanLotus, a group responsible for launching targeted attacks against human rights organizations, media organizations, research institutes, and more.
We identified a MacOS backdoor (detected by Trend Micro as OSX_OCEANLOTUS.D) that we believe is the latest version of a threat used by OceanLotus (a.k.a. APT 32, APT-C-00, SeaLotus, and Cobalt Kitty). OceanLotus was responsible for launching targeted attacks against human rights organizations, media organizations, research institutes, and maritime construction firms. The attackers behind OSX_OCEANLOTUS.D target MacOS computers which have the Perl programming language installed.
The MacOS backdoor was found in a malicious Word document presumably distributed via email. The document bears the filename “2018-PHIẾU GHI DANH THAM DỰ TĨNH HỘI HMDC 2018.doc,” which translates to “2018-REGISTRATION FORM OF HMDC ASSEMBLY 2018.doc.” The document claims to be a registration form for an event with HDMC, an organization in Vietnam that advertises national independence and democracy.
Figure 1. Graphic used by the malicious document
Upon receiving the malicious document, the user is advised to enable macros. In our analysis, the macro is obfuscated, character by character, using the decimal ASCII code. This is shown in the figure below.
Figure 2. Code snippet of the obfuscated document
After deobfuscation, we can see that the payload is written in the Perl programming language. It extracts theme0.xml file from the Word document. theme0.xml is a Mach-O 32-bit executable with a 0xFEEDFACE signature that is also the dropper of the backdoor, which is the final payload. theme0.xml is extracted to /tmp/system/word/theme/syslogd before it’s executed.
Figure 3. Deobfuscated Perl payload from the delivery document
Dropper analysis
The dropper is used to install the backdoor into the infected system and establish its persistence.
Figure 4. The main function of the dropper
All strings within the dropper, as well as the backdoor, are encrypted using a hardcoded RSA256 key. There are two forms of encrypted strings: an RSA256-encrypted string, and custom base64-encoded and RSA256-encrypted string.
Figure 5. Hardcoded RSA256 key showing the first 20 characters
Using the setStartup() method, the dropper first checks if it is running as a root or not. Based on that, the GET_PROCESSPATH and GET_PROCESSNAME methods will decrypt the hardcoded path and filename where the backdoor should be installed. The locations:
For root user
- path: /Library/CoreMediaIO/Plug-Ins/FCP-DAL/iOSScreenCapture.plugin/Contents/Resources/
- processname: screenassistantd
For regular user
- path: ~/Library/Spelling/
- processname: spellagentd
Subsequently, it implements the Loader::installLoader method, reading the hardcoded 64-bit Mach-O executable (magic value 0xFEEDFACF), and writing to the previously determined path and file.
Figure 6. The dropper installs the backdoor, sets its attributes to “hidden”, and sets a random file date and time
When the dropper installs the backdoor, it sets its attributes to “hidden” and sets file date and time to random values using the touch command: touch –t YYMMDDMM “/path/filename” > /dev/null. The access permissions will then be changed to 0x1ed = 755, which is equal to u=rwx,go=rx.
Figure 7. The magic value 0xFEEDFACF that belongs to Mach-O Executable (64 bit)
Methods GET_LAUNCHNAME and GET_LABELNAME will return the hardcoded name of the property list “.plist” for the root user (com.apple.screen.assistantd.plist) and for the regular user (com.apple.spell.agent.plist).
Afterwards, the persistence file will be created in /Library/LaunchDaemons/ or ~/Library/LaunchAgents/ folder. The RunAtLoad key will command launchd to run the daemon when the operating system starts up, while the KeepAlive key will command launchd to let the process run indefinitely. This persistence file is also set to hidden with a randomly generated file date and time.
Figure 8. Property list with persistence settings
launchctl load /Library/LaunchDaemons/filename.plist > /dev/nul or launchctl load ~/Library/LaunchAgents/ filename.plist > /dev/nul will then command the operating system to start the dropped backdoor file at login. The dropper will delete itself at the end of the process.
Backdoor analysis
The main loop of the backdoor has two main functions, infoClient and runHandle. infoClient is reponsible for collecting OS info, submitting this info to its C&C servers (the servers are malicious in nature), and receiving additional C&C communication information. Meanwhile, runHandle is responsible for the backdoor capabilities.
Figure 9. The main functions of the backdoor
infoClient fills up the variables in HandlePP class.
Figure 10. List of variables belonging to the HandlePP class
clientID is an MD5 hash derived from the environment variables, while strClientID is a hexadecimal representation of clientID. All strings below are encrypted via AES256 and base64 encoding. The HandlePP::getClientID method uses the following environment variables:
Figure 11. Serial number
Figure 12. Hardware UUID
Figure 13. MAC address
Figure 14. Randomly generated UUID
For the initial information packet, the backdoor also collects the following:
Figure 15. OS version
Running getpwuid ->pw_name , scutil - -get ComputerName, and uname –m will provide the following returns respectively:
- Mac OSX 10.12.
- System Administrator
- <owner’s name>'s iMac
- x86_64
All these data are scrambled and encrypted before sending to the C&C server. The process is detailed below:
Scrambling
Class Parser has several methods, one for each variable type – Parser::inBytes, Parser::inByte, Parser::inString, and Parser::inInt.
Figure 16. Parser::inBytes method
If clientID equals the following sequence of bytes B4 B1 47 BC 52 28 28 73 1F 1A 01 6B FA 72 C0 73, then the scrambled version is computed using the third parameter (0x10), which is treated as a DWORD. Each quadruple of bytes is XOR-ed with it, as shown in example below.
Figure 17. Parser::inByte method
When scrambling one byte, the scrambler first determines if the byte value is odd or even. If the value is odd, it adds the byte, along with one more randomly generated byte, to the array. In the case of an even value, the randomly generated byte is added first, followed by the byte being added. In the case above, the third parameter is ‘1’ = 0x31, which is an odd number. This means that it adds byte ‘1’ and one randomly generated byte to the final scrambled array.
Figure 18. Parser::inString method
When scrambling a string, the scrambler generates a 5-byte long sequence. First, it generates one random byte, followed by three zero bytes, one random byte, and finally, the byte with the length of the string. Let’s say we want to scramble string ‘Mac OSX 10.12.’ Its length is 13 = 0x0d, and the two random bytes are 0xf3 and 0x92. The final 5-byte sequence looks like F3 00 00 00 92 0D. The original string is then XOR’ed with the 5-byte sequence.
Figure 19. Scrambling ‘Mac OSX 10.12’
Encryption
The scrambled byte sequence is passed onto the constructor of the class Packet::Packet, which creates a random AES256 key and encrypts the buffer with this key.
Encoding the encryption key
In order for the C&C server to decrypt the encrypted data, the randomly generated AES256 key must be included in the packet along with the encrypted data. However, this key is also scrambled with operation XOR 0x13 followed by ROL 6 operation applied to each byte.
Figure 20. Function for scrambling AES256 key in the outgoing packet
Some screenshots taken during scrambling and encryption process:
Figure 21. The highlighted bytes represent the scrambled computer info
Figure 22. Randomly generated AES256 key
Figure 23. Scrambled AES256 key (0xC1 XOR 0x13 = 0xD2, 0xD2 ROL 6 = 0xB4) etc.)
Figure 24. Computer info encrypted with AES256 key
Figure 25. Screenshot of the final payload to be sent to C&C server. The scrambled AES256 key is marked green, while the encrypted computer info is marked red. Other bytes are just randomly generated noise.
When the backdoor receives the response from the C&C server, the final payload needs to be decoded again in a similar manner via decryption and scrambling. Packet::getData decrypts the received payload and Converter::outString descrambles the result. The received data from the C&C server include the following information:
- HandlePP::urlRequest (/appleauth/static/cssj/N252394295/widget/auth/app.css)
- HandlePP::keyDecrypt
- STRINGDATA::BROWSER_SESSION_ID (m_pixel_ratio)
- STRINGDATA::RESOURCE_ID
These data will be later used in the C&C communication, as shown in the Wireshark screenshot below.
Figure 26. Communication with the C&C server after the exchange of OS packet info
Meanwhile, the runHandle method of the main backdoor loop will call for the requestServer method with the following backdoor commands (each command has one byte long code and is extracted by Packet::getCommand):
Figure 27. The getCommand method
The figure below shows the example of two of several possible command codes. Both create one thread, and each thread is responsible for either downloading and executing the file or running a command line program in the terminal:
Figure 28. Commands used for downloading and executing, and running a command in terminal
Figure 29. Commands used in uploading and downloading file
Figure 30. Supported commands and their respective codes
Mitigation
Malicious attacks targeting Mac devices are not as common as its counterparts, but the discovery of this new MacOS backdoor that is presumably distributed via phishing email calls for every user to adopt best practices for phishing attacks regardless of operating system.
End users can benefit from security solutions such as Trend Micro Antivirus for Mac, which provides comprehensive security and multi-device protection against cyberthreats. Enterprises can benefit from Trend Micro’s Smart Protection Suites with XGen™ security, which infuses high-fidelity machine learning into a blend of threat protection techniques to eliminate security gaps across any user activity and any endpoint.
Indicators of Compromise (IoCs)
| C&C servers |
| Ssl[.]arkouthrie[.]com |
| s3[.]hiahornber[.]com |
| widget[.]shoreoa[.]com |
| SHA256 |
| Delivery document (W2KM_OCEANLOTUS.A): 2bb855dc5d845eb5f2466d7186f150c172da737bfd9c7f6bc1804e0b8d20f22a |
| Dropper (OSX_OCEANLOTUS.D): 4da8365241c6b028a13b82d852c4f0155eb3d902782c6a538ac007a44a7d61b4 |
| Backdoor (OSX_OCEANLOTUS.D): 673ee7a57ba3c5a2384aeb17a66058e59f0a4d0cddc4f01fe32f369f6a845c8f |