In this article, we share a surprising discovery we found when studying the ASUS Live Update attack that occurred during March of 2019. Our research shows the possible presence of another malicious operation that seemingly targeted the financial sector. Below are our key takeaways.
This financial sector attack was inadvertently discovered during our investigation of Operation ShadowHammer, which was an advanced persistent threat (APT) targeting certain ASUS users. Compromising the update mechanism of the ASUS Live Update platform, the legitimate certificate and the trusted dispatch channel made it easy for the attacker to mask their malicious activities. While Operation ShadowHammer highlighted the severity of a supply chain attack, our research team dug deeper to see if there was any other malware utilizing the fake ASUS Live Update service.
Our research involved developing several Yara rules and malware hunting techniques on VirusTotal. For instance, the ShadowHammerDropper rule, which is demonstrated in Fig. 1, detected the string "ASUS Live Update" and the resource name "EXE". Another rule, ShadowHammerSigned determined if ASUS certificates were used. We also implemented several rules for detecting ShadowHammer's malware. Results revealed the detection of several malware samples, including ones unrelated to ShadowHammer. Among these unrelated samples, we were particularly interested in the following three malware. Since these malware had valid certificates, they would not be flagged by most anti-virus software.
A more detailed analysis is presented in the following sections.
According to the behavior of these samples, they can basically be classified into two types of payload, as depicted in Fig. 2 and Fig. 3. The type 1 malware was downloaded from the phishing website https[:]//pcisecuritysstandards[.]org/, tricking users to think it was https[:]//pcisecuritysstandards[.]org/. Due to this social engineering attempt, we believe these malware samples were aimed at the financial sector. The downloaded malware pretended to be Adobe Download Manager, which resulted in users downloading another type of malware from the second stage C2 statistic.data-akamai[.]com. The final payload was a Cobalt Strike backdoor. Compared to type 1, the type 2 malware did not involve a second-stage process, but directly dropped and executed the Cobalt Strike backdoor.
Basic information of the first stage dropper (31d1bc9911cdcd9af78c0a215417699a9406fcd4e7802c3d2f0e7cff4477f384) is shown in Fig. 4. Our threat intelligence platform gave it a MEDIUM threat rating. The first stage droppers was a fake Adobe Download Manager with legitimate signatures ( FOURSTAR SOLUTIONS LTD and AUSTEK CONSULTING LIMITED ), coded in C++ without obfuscation or packing.
A very important feature of the first stage dropper was that a legal certificate was used to sign this malware, causing many security vendors to treat it as a benign program, thereby increasing the likelihood of a system compromise. The malware used the name “AUSTEK CONSULTING” as a disguise for “ASUSTeK Computer Inc” to confuse victims. The inconsistency between the certificate and the program's intent highlights the risk that certificates cannot be regarded as a foolproof way to establish trust.
Fig. 5. shows the reversed code snippet of the malware. The malware extracted the second stage malware from its resource section and invoked the second stage via ShellExecuteA. The second stage malware, RC/101 and RC/102, were dropped to C:\Windows\System32. RC/102 was a service launcher that installed the RC/101 service.
The second stage payload consisted of a backdoor (RC/101) and a service launcher (RC/102), which were embedded in the resource section. Each discovered dropper dropped two files from the resource to C:\Windows\System32\ with the following names:
As an example, the main routine of the service launcher (RC/102) is shown in Fig. 6.
We found two types in the second stage payload. One of them was the downloader, while the other was the Cobalt Strike backdoor. The payload was encoded three times to evade detection.
An interesting technique employed by this malware was modifying __tmainCRTStartup in CRT for malicious behavior, which is illustrated in Fig. 7a. Meanwhile, some function calls were modified to _securityinit_cookie. As it is highly unlikely for this function to fail, even if some changes were made to the function, nothing would be triggered by the subsequent error checking. There would be no early exits, and the programs would be normally executed. Thus, the implanted malware can be more robustly executed. Since CRT is very common in a normal executable and reverse engineers usually ignore them, it increases the chances for the malware to avoid detection.
As the memory protection attribute of the .text section was modified to read-write-execute, this implied the SMC (self-modifying code) technique was applied. It used a busy-loop-liked routine to compute xor key "CCCMMM", as shown in Fig. 7b. Billions of instruction cycles were required, which caused a few seconds of delay, thereby allowing it to evade the emulation-based detection.
The first layer released a shellcode followed by a UPX packed module into the memory and a process hollowing trick to execute the UPX packed module as a second layer. The payload inside the UPX packed module released the Cobalt Strike backdoor as shellcode into the memory and was executed with ReflectiveLoader. Fig. 8 is the partial memory released from the first layer. The MZ indicates there was an embedded PE structure, which would be loaded later. The UPX0 string indicates this malware was packed with the UPX. Thus, it could be extracted from the memory and unpacked.
The Cobalt Strike backdoor, which was dropped by the previous fake Adobe Download Manager, masqueraded as the ASUS Live Update utility program. The backdoor had the ability to upload files, download files, inject shellcode, execute powershell script, etc..., as shown by our reverse result in Fig 11. In Fig. 9, which is the resource information of this malware, the "LiveUpdate" strings appears in the Version Info. Another resource also contains a dialog template similar (or identical) to the ASUS Live Update, as shown in Fig. 10.
The other way to invoke the final stage malware was via a downloader. The downloader downloaded shellcode from https[:]//statistic.data-akamai[.]com/eYVU and executed it in memory without dropping any file. From our threat intelligence platform, this domain was once bounded to 23[.]106.215.179. This IP is known to be involved in previous attacks as shown in our CTI platform, Fig 11 . The final stage shellcode (eYVU) was also a Cobalt Strike backdoor, similar to the one described above.
Since Cobalt Strike is a general backdoor, minimal information can be inferred. Thus, a more in-depth analysis was made to the C2 config to obtain further information. We developed a script, as shown in Fig. 12, to decrypt and deserialize the C2 config from the extracted shellcode. The C2 config data blob is a list, which contains many records. Each record consists of index, type, and data. There are three possible types: short, int and bytes. Tab. 1 shows the three Cobalt Strike config that appeared in this attack.
In this white paper, we share our investigation results about an attack on the financial sector. Four distinct valid certificates were utilized in this attack. We not only show how this meticulous long-term attack plan was stealthily implemented, but also highlight the dangers when certificates are taken advantage of. Some of the malware was equipped with sophisticated techniques, such as replacing a function in the commonly used CRT library to avoid detection, inserting junk instructions to frustrate signature-based and control flow-based detection mechanisms, and in-memory process hollowing. In view of the various phishing websites that were used, this paper serves as an important reminder that social engineering tricks are still an effective method to confuse victims. Finally, the related indicators of compromise (IoCs) are listed below for further investigation.
 Kaspersky GReAT, 2019, March 25, “Operation ShadowHammer,” Retrieved from https://securelist.com/operation-shadowhammer/89992/
IP / Domain