{"id":8213,"date":"2019-04-09T12:00:00","date_gmt":"2019-04-09T09:00:00","guid":{"rendered":"https:\/\/blog.eset.ee\/et\/2019\/04\/09\/oceanlotus-macos-malware-update\/"},"modified":"2019-04-09T12:00:00","modified_gmt":"2019-04-09T09:00:00","slug":"oceanlotus-macos-malware-update","status":"publish","type":"post","link":"https:\/\/blog.eset.ee\/et\/en\/2019\/04\/09\/oceanlotus-macos-malware-update\/","title":{"rendered":"OceanLotus: macOS malware update"},"content":{"rendered":"

Early in March 2019, a new macOS malware sample from the OceanLotus group was uploaded to VirusTotal, a popular online multi-scanner service. This backdoor executable bears the same features as the previous macOS variant we looked at, but its structure has changed and its detection was made harder. Unfortunately, we couldn’t find the dropper associated with this sample so we do not know the initial compromise vector.<\/p>\n

We recently published a detailed update about OceanLotus<\/a> and how its operators employ a wide range of techniques to gain code execution, achieve persistence, and leave as little trace as possible on a Windows system. OceanLotus is also known to have a malicious macOS component. This article details what has changed from the previous macOS version analyzed by Trend Micro<\/a> and describes how, while analyzing this variant\u2019s code, you can automate string decryption using the IDA Hex-Rays API.<\/p>\n

Analysis<\/h1>\n

The following three sections of this blogpost describe the analysis of the sample with the SHA-1 hash E615632C9998E4D3E5ACD8851864ED09B02C77D2<\/span>. The file is named flashlightd and is detected by ESET products as OSX\/OceanLotus.D.<\/p>\n

Anti-debug and anti-sandbox<\/h2>\n

As usual for OceanLotus macOS binaries, the sample is packed with UPX, but most packer identification tools do not recognize it as such, probably because they mostly include a signature that relies on the presence of a \u201cUPX\u201d string, and further, Mach-O signatures are less common and not as regularly updated. This particular characteristic makes static detection more difficult. Once unpacked, one interesting thing is that the entry point is located at the beginning of the __cfstring<\/span> section in the .TEXT<\/span> segment. This section has the flag attributes seen in Figure 1.<\/p>\n<\/p>\n

\"\"<\/a><\/p>\n

Figure 1. MACH-O __cfstring<\/span> section attributes<\/i><\/p>\n<\/div>\n

As seen in Figure 2, the fact that the code is in the __cfstring<\/span> section tricks some disassembly tools to display the code as strings.<\/p>\n<\/p>\n

\"\"<\/a><\/p>\n

Figure 2. The backdoor code is defined as data by IDA<\/i><\/p>\n<\/div>\n

When run, the binary first creates a thread as an anti-debugging watchdog whose sole purpose is to continuously check if a debugger is present. In order to do that, this thread:<\/p>\n