This week, Kaspersky Lab reported initial details of a new supply chain attack on systems by computer giant ASUS. Dubbed ShadowHammer by Kaspersky, the attack leveraged a malicious version of ASUS Live Update, a utility that automatically updates system components such as BIOS, UEFI, drivers and applications.The malicious version included a backdoor trojan that reaches out to a C2 server to download additional payloads. It is estimated that at least half a million people installed the backdoored version of ASUS Live Update after an ASUS server that delivers the tool was compromised. Because the malicious file was signed with legitimate ASUS digital certificates, security tools allowed the malware through.
Interestingly, although approximately 57,000 Kaspersky customers installed the trojanized Live Update, the attackers appear to be targeting a much smaller subset. The malware included a hardcoded list of MAC addresses – about 600 unique addresses were found in the samples analyzed by Kaspersky – only those on the list would connect to the C2 server for the follow-on payloads.
The ASUS attack brings to mind the massive CCleaner supply chain attack uncovered by Morphisec in 2017. As Morphisec Labs conducted its own research into the ASUS attack, we identified several correlations to the CCleaner campaign, as evidenced in the below Technical Analysis.
Based on our research, the malicious code implements a decryption method previously used as part of a PlugX targeted malware variant, and the MAC validation method is highly tailored for a set of very specific combination of MAC addresses on the same computer. This indicates that the attack actors had already performed significant reconnaissance work (as in the CCleaner case).
Targeted MAC Addresses
According to the 360 Intelligence Center the MAC address distribution is as follows:
Similar to CCleaner, the compile machine was compromised and the CRT runtime modified. While in the CCleaner case the TLS initialization function was modified, in this case the crtExitProcess has been modified. Replacing the Exit function causes some EDR tools to fail in detection while looking the validity and integrity of the current running processes; it appears that the hacker group learned from its previous mistakes.
In this campaign, the hackers added an additional encrypted stage of shellcode which resides in the resource section. The new CorExitFunction uses VirtualAlloc from the module’s IAT by accessing it with an exact offset starting from the Module Handle (virtual address). The function then uses the first 16 bytes as a key to decrypt the rest of the shellcode.
In many of the samples investigated and mentioned in the Artifacts section, the shellcode is encrypted with a different key and the entry address for the execution start is also different.
The same decryption routine has been used by a PlugX malware variant identified as part of several targeted attacks https://www.circl.lu/assets/files/tr-12/tr-12-circl-plugx-analysis-v1.pdf .
The stage 2 shellcode starts by extracting all the required functions from memory while iterating over the InitializationOrderModuleList as part of the PEB, and looking for the kernel32.dll module based on specific characters in the module name.
Following the identification of the module, the shellcode extracts all the functions by imitating a custom GetProcAddress:
- Kernel32 – LoadLibraryExW, VirtualAlloc, GetModuleFileNameW, WritePrivateProfileStringW, GetSystemTimeAsFileTime, FileTimeToSystemTime, VirtualFree
- NTDLL – memcpy, memcmp, memset, _swprintf, sprintf, strncat, MD5Init, MD5Update, MD5Final
- IPHLPAPI – GetAdaptersAddresses
- WININET – InternetOpenA, InternetOpenUrlA, InternetQueryDataAvailable , InternetReadFile
After the function extraction, the next stage shellcode holds a long list of MD5 type structures with a flag prefix before every MD5 that indicates how to handle that specific MD5. Each MD5 represents a unique MAC address, and only if one of the target’s MAC addresses are part of the list, will the next stage payload be delivered to the target machine (the determination is more involved than a simple match, as described in the next section). If there is no match, a unique IDX configuration file is created.
As discussed in the previous section, the shellcode iterates over all the MAC addresses, including the NIC and the WiFi on the machine, and then it collects the encoded MD5s of those MAC addresses.
Following the MAC collection, the shellcodes validates if one or both MAC addresses are part of the embedded list. The function has 2 parts.
- In case one of the embedded compared MD5 addresses is prefixed with a flag equal to 1 -> if there is a match, the function immediately returns.
- In case one of the embedded compared MD5 addresses is prefixed with a flag equal to 2 -> if there is a match, compare the MAC addresses with the next in line embedded MD5 -> if they are both matches then the function immediately returns.
The second method indicates that the attackers already had significant information about their targets.
Upon successful validation of the MAC’s MD5 addresses, the shellcode downloads the next payload from asushotfix[.]com (if matched, of course).
If there was no match to the MAC addresses, the function generates configuration file idx.ini, and write timestamps into the file.
Supply chain attacks are becoming more common, more sophisticated and more difficult for detection-dependent security systems to catch. This recent campaign indicates that we should expect more to come, primarily because EDR solutions will always trust digital certificates to minimize their own false positives.
Morphisec Threat Prevention blocks this threat deterministically, without any prior knowledge or required updates.
*** This is a Security Bloggers Network syndicated blog from Morphisec Default Blog authored by Michael Gorelik. Read the original post at: http://blog.morphisec.com/asus-supply-chain-attack