Operation ShadowHammer: a high-profile supply chain attack

In late March 2019, we briefly highlighted our research on ShadowHammer attacks, a sophisticated supply chain attack involving ASUS Live Update Utility, which was featured in a Kim Zetter article on Motherboard. The topic was also one of the research announcements made at the SAS conference, which took place in Singapore on April 9-10, 2019. Now it is time to share more details about the research with our readers.
At the end of January 2019, Kaspersky Lab researchers discovered what appeared to be a new attack on a large manufacturer in Asia. Our researchers named it “Operation ShadowHammer”.
Some of the executable files, which were downloaded from the official domain of a reputable and trusted large manufacturer, contained apparent malware features. Careful analysis confirmed that the binary had been tampered with by malicious attackers.
It is important to note that any, even tiny, tampering with executables in such a case normally breaks the digital signature. However, in this case, the digital signature was intact: valid and verifiable. We quickly realized that we were dealing with a case of a compromised digital signature.
We believe this to be the result of a sophisticated supply chain attack, which matches or even surpasses the ShadowPad and the CCleaner incidents in complexity and techniques. The reason that it stayed undetected for so long is partly the fact that the trojanized software was signed with legitimate certificates (e.g. “ASUSTeK Computer Inc.”).
The goal of the attack was to surgically target an unknown pool of users, who were identified by their network adapters’ MAC addresses. To achieve this, the attackers had hardcoded a list of MAC addresses into the trojanized samples and the list was used to identify the intended targets of this massive operation. We were able to extract more than 600 unique MAC addresses from more than 200 samples used in the attack. There might be other samples out there with different MAC addresses on their lists, though.
Technical details
The research started upon the discovery of a trojanized ASUS Live Updater file (setup.exe), which contained a digital signature of ASUSTeK Computer Inc. and had been backdoored using one of the two techniques explained below.
In earlier variants of ASUS Live Updater (i.e. MD5:0f49621b06f2cdaac8850c6e9581a594), the attackers replaced the WinMain function in the binary with their own. This function copies a backdoor executable from the resource section using a hardcoded size and offset to the resource. Once copied to the heap memory, another hardcoded offset, specific to the executable, is used to start the backdoor. The offset points to a position-independent shellcode-style function that unwraps and runs the malicious code further.

Some of the older samples revealed the project path via a PDB file reference: “D:C++AsusShellCodeReleaseAsusShellCode.pdb“. This suggests that the attackers had exclusively prepared the malicious payload for their target. A similar tactic of precise targeting has become a persistent property of these attackers.
A look at the resource section used for carrying the malicious payload revealed that the attackers had decided not to change the file size of the ASUS Live Updater binary. They changed the resource contents and overwrote a tiny block of the code in the subject executable. The layout of that patched file is shown below.

[2-Pack] iPhone X XS XR XS Max Privacy Anti-Spy Tempered Glass Screen Protector

$4.45
End Date: Wednesday Aug-21-2019 3:29:19 PDT
Buy It Now for only: $4.45
Buy It Now | Add to watch list

[2-Pack] iPhone X XS XR XS Max Privacy Anti-Spy Tempered Glass Screen Protector

$4.45
End Date: Wednesday Aug-21-2019 3:29:19 PDT
Buy It Now for only: $4.45
Buy It Now | Add to watch list

We managed to find the original ASUS Live Updater executable which had been patched and abused by the attackers. As a result, we were able to recover the overwritten data in the resource section. The file we found was digitally signed and certainly had no infection present.
Both the legitimate ASUS executable and the resource-embedded updater binary contain timestamps from March 2015. Considering that the operation took place in 2018, this raises the following question: why did the attackers choose an old ASUS binary as the infection carrier?

Another injection technique was found in more recent samples. Using that technique, the attackers patched the code inside the C runtime (CRT) library function “___crtExitProcess”. The malicious code executes a shellcode loader instead of the standard function “___crtCorExitProcess”:

This way, the execution flow is passed to another address which is located at the end of the code section. The attackers used a small decryption routine that can fit into a block at the end of the code section, which has a series of zero bytes in the original executable. They used the same source executable file from ASUS (compiled in March 2015) for this new type of injection.

The loader code copies another block of encrypted shellcode from the file’s resource section (of the type “EXE”) to a newly allocated memory block with read-write-execute attributes and decrypts it using a custom block-chaining XOR algorithm, where the first dword is the initial seed and the total size of the shellcode is stored at an offset of +8.

We believe that the attackers changed the payload start routine in an attempt to evade detection. Apparently, they switched to a better method of hiding their embedded shellcode at some point between the end of July and September 2018.
ShadowHammer downloader
The compromised ASUS binaries carried a payload that was a Trojan downloader. Let us take a closer look at one such ShadowHammer downloader extracted from a copy of the ASUS Live Updater tool with MD5:0f49621b06f2cdaac8850c6e9581a594. It has the following properties:
MD5: 63f2fe96de336b6097806b22b5ab941a
SHA1: 6f8f43b6643fc36bae2e15025d533a1d53291b8a
SHA256: 1bb53937fa4cba70f61dc53f85e4e25551bc811bf9821fc47d25de1be9fd286a
Digital certificate fingerprint: 0f:f0:67:d8:01:f7:da:ee:ae:84:2e:9f:e5:f6:10:ea
File Size: 1’662’464 bytes
File Type: PE32 executable (GUI) Intel 80386, for MS Windows
Link Time: 2018.07.10 05:58:19 (GMT)
The relatively large file size is explained by the presence of partial data from the original ASUS Live Updater application appended to the end of the executable. The attackers took the original Live Updater and overwrote it with their own PE executable starting from the PE header, so that the file contains the actual PE image, whose size is only 40448 bytes, while the rest comes from ASUS. The malicious executable was created using Microsoft Visual C++ 2010.
The core function of this executable is in a subroutine which is called from WinMain, but also executed directly via a hardcoded offset from the code injected into ASUS Live Updater.
The code uses dynamic import resolution with its own simple hashing algorithm. Once the imports are resolved, it collects MAC addresses of all available network adapters and calculates an MD5 hash for each of these. After that, the hashes are compared against a table of 55 hardcoded values. Other variants of the downloader contained a different table of hashes, and in some cases, the hashes were arranged in pairs.

In other words, the malware iterates through a table of hashes and compares them to the hashes of local adapters’ MAC hashes. This way, the target system is recognized and the malware proceeds to the next stage, downloading a binary object from https://asushotfix[.]com/logo.jpg (or https://asushotfix[.]com/logo2.jpg in newer samples). The malware also sends the first hash from the match entry as a parameter in the request to identify the victim. The server response is expected to be an executable shellcode, which is placed in newly allocated memory and started.

Our investigation uncovered 230 unique samples with different shellcodes and different sets of MAC address hashes. This leads us to believe that the campaign targeted a vast number of people or companies. In total, we were able to extract 14 unique hash tables. The smallest hash table found contained eight entries and the biggest, 307 entries. Interestingly, although the subset of hash entries was changing, some of the entries were present in all of the tables.

For all users whose MAC did not match expected values, the code would create an INI file located two directory levels above the current executable and named “idx.ini”. Three values were written into the INI file under the [IDX_FILE] section:
[IDX_FILE]
XXX_IDN=YYYY-MM-DD
XXX_IDE=YYYY-MM-DD
XXX_IDX=YYYY-MM-DD
where YYYY-MM-DD is a date one week ahead of the current system date.
The code injected by the attackers was discovered with over 57000 Kaspersky Lab users. It would run but remain silent on systems that were not primary targets, making it almost impossible to discover the anomalous behavior of the trojanized executables. The exact total of the affected users around the world remains unknown.
Digital signature abuse
A lot of computer security software deployed today relies on integrity control of trusted executables. Digital signature verification is one such method. In this attack, the attackers managed to get their code signed with a certificate of a big vendor. How was that possible? We do not have definitive answers, but let us take a look at what we observed.
First of all, we noticed that all backdoored ASUS binaries were signed with two different certificates. Here are their fingerprints:
0ff067d801f7daeeae842e9fe5f610ea
05e6a0be5ac359c7ff11f4b467ab20fc
The same two certificates have been used in the past to sign at least 3000 legitimate ASUS files (i.e. ASUS GPU Tweak, ASUS PC Link and others), which makes it very hard to revoke these certificates.
All of the signed binaries share certain interesting features: none of them had a signing timestamp set, and the digest algorithm used was SHA1. The reason for this could be an attempt at hiding the time of the operation to make it harder to discover related forensic artefacts.

Although there is no timestamp that can be relied on to understand when the attack started, there is a mandatory field in the certificate, “Certificate Validity Period”, which can help us to understand roughly the timeframe of the operation. Apparently, because the certificate that the attackers relied on expired in 2018 and therefore had to be reissued, they used two different certificates.

Another notable fact is that both abused certificates are from the DigiCert SHA2 Assured ID Code Signing CA.

The legitimate ASUS binaries that we have observed use a different certificate, which was issued by the DigiCert EV Code Signing CA (SHA2). EV stands for “Extended Validation” and provides for stricter requirements for the party that intends to use the certificate, including hardware requirements. We believe that the attackers simply did not have access to a production signing device with an EV certificate.
This indicates that the attackers most likely obtained a copy of the certificates or abused a system on the ASUS network that had the certificates installed. We do not know about all software with malware injection they managed to sign, and we believe that the compromised signing certificates must be removed and revoked. Unfortunately, one month after this was reported to ASUS, newly released software (i.e. md5: 1b8d2459d4441b8f4a691aec18d08751) was still being signed with a compromised certificate. We have immediately notified ASUS about this and provided evidence as required.

ASUS-related attack samples
Using decrypted shellcode and through code similarity, we found a number of related samples which appear to have been part of a parallel attack wave. These files have the following properties:
they contain the same shellcode style as the payload from the compromised ASUS Live Updater binaries, albeit unencrypted
they have a forgotten PDB path of “D:C++AsusShellCodeReleaseAsusShellCode.pdb”
the shellcode from all of these samples connects to the same C2: asushotfix[.]com
all samples were compiled between June and July 2018
the samples have been detected on computers all around the globe
The hashes of these related samples include:
322cb39bc049aa69136925137906d855
36dd195269979e01a29e37c488928497
7d9d29c1c03461608bcab930fef2f568
807d86da63f0db1fc746d1f0b05bc357
849a2b0dc80aeca3d175c139efe5221c
86A4CAC227078B9C95C560C8F0370BF0
98908ce6f80ecc48628c8d2bf5b2a50c
a4b42c2c95d1f2ff12171a01c86cd64f
b4abe604916c04fe3dd8b9cb3d501d3f
eac3e3ece94bc84e922ec077efb15edd
128CECC59C91C0D0574BC1075FE7CB40
88777aacd5f16599547926a4c9202862
These files are dropped by larger setup files / installers, signed by an ASUS certificate (serial number: 0ff067d801f7daeeae842e9fe5f610ea) valid from 2015-07-27 till 2018-08-01).
The hashes of the larger installers/droppers include:
0f49621b06f2cdaac8850c6e9581a594
17a36ac3e31f3a18936552aff2c80249
At this point, we do not know how they were used in these attacks and whether they were delivered via a different mechanism. These files were located in a “TEMP” subfolder for ASUS Live Updater, so it is possible that the software downloaded these files directly. Locations where these files were detected include:
asusasus live updatetemp1Setup.exe
asusasus live updatetemp2Setup.exe
asusasus live updatetemp3Setup.exe
asusasus live updatetemp5Setup.exe
asusasus live updatetemp6Setup.exe
asusasus live updatetemp9Setup.exe
Public reports of the attack
While investigating this case, we were wondering how such a massive attack could go unnoticed on the Internet. Searching for any kind of evidence related to the attack, we came by a Reddit thread created in June 2018, where user GreyWolfx posted a screenshot of a suspicious-looking ASUS Live Update message:

The message claims to be a “ASUS Critical Update” notification, however, the item does not have a name or version number.
Other users commented in the thread, while some uploaded the suspicious updater to VirusTotal:

The file uploaded to VT is not one of the malicious compromised updates; we can assume the person who uploaded it actually uploaded the ASUS Live Update itself, as opposed to the update it received from the Internet. Nevertheless, this could suggest that potentially compromised updates were delivered to users as far back as June 2018.
In September 2018, another Reddit user, FabulaBerserko also posted a message about a suspicious ASUS Live update:

Asus_USA replied to FabulaBerserko with the following message, suggesting he run a scan for viruses:

In his message, the Reddit user FabulaBerserko talks about an update listed as critical, however without a name and with a release date of March 2015. Interestingly, the related attack samples containing the PDB “AsusShellCode.pdb” have a compilation timestamp from 2015 as well, so it is possible that the Reddit user saw the delivery of one such file through ASUS Live Update in September 2018.
Targets by MAC address
We managed to crack all of the 600+ MAC address hashes and analyzed distribution by manufacturer, using publicly available Ethernet-to-vendor assignment lists. It turns out that the distribution is uneven and certain vendors are a higher priority for the attackers. The chart below shows statistics we collected based on network adapter manufacturers’ names:

Some of the MAC addresses included on the target list were rather popular, i.e. 00-50-56-C0-00-08 belongs to the VMWare virtual adapter VMNet8 and is the same for all users of a certain version of the VMware software for Windows. To prevent infection by mistake, the attackers used a secondary MAC address from the real Ethernet card, which would make targeting more precise. However, it tells us that one of the targeted users used VMWare, which is rather common for software engineers (in testing their software).
Another popular MAC was 0C-5B-8F-27-9A-64, which belongs to the MAC address of a virtual Ethernet adapter created by a Huawei USB 3G modem, model E3372h. It seems that all users of this device shared the same MAC address.
Interaction with ASUS
The day after the ShadowHammer discovery, we created a short report for ASUS and approached the company through our local colleagues in Taiwan, providing all details of what was known about the attack and hoping for cooperation. The following is a timeline of the discovery of this supply-chain attack, together with ASUS interaction and reporting:
29-Jan-2019 – initial discovery of the compromised ASUS Live Updater
30-Jan-2019 – created preliminary report to be shared with ASUS, briefed Kaspersky Lab colleagues in Taipei
31-Jan-2019 – in-person meeting with ASUS, teleconference with researchers; we notified ASUS of the finding and shared hard copy of the preliminary attack report with indicators of compromise and Yara rules. ASUS provided Kaspersky with the latest version of ASUS Live Updater, which was analyzed and found to be uninfected.
01-Feb-2019 – ASUS provides an archive of all ASUS Live Updater tools beginning from 2018. None of them were infected, and they were signed with different certificates.
14-Feb-2019 – second face-to-face meeting with ASUS to discuss the details of the attack
20-Feb-2019 – update conf call with ASUS to provide newly found details about the attack
08-Mar-2019 – provided the list of targeted MAC addresses to ASUS, answered other questions related to the attack
08-Apr-2019 – provided a comprehensive report on the current attack investigation to ASUS.
We appreciate a quick response from our ASUS colleagues just days before one of the largest holidays in Asia (Lunar New Year). This helped us to confirm that the attack was in a deactivated stage and there was no immediate risk to new infections and gave us more time to collect further artefacts. However, all compromised ASUS binaries had to be properly flagged as containing malware and removed from Kaspersky Lab users’ computers.
Non-ASUS-related cases
In our search for similar malware, we came across other digitally signed binaries from three other vendors in Asia.
One of these vendors is a game development company from Thailand known as Electronics Extreme Company Limited. The company has released digitally signed binaries of a video game called “Infestation: Survivor Stories”. It is a zombie survival game in which players endure the hardships of a post-apocalyptic, zombie-infested world. According to Wikipedia, “the game was panned by critics and is considered one of the worst video games of all time“. The game servers were taken offline on December 15, 2016.”

The history of this videogame itself contains many controversies. According to Wikipedia, it was originally developed under the title of “The War Z” and released by OP Productions which put it in the Steam store in December 2012. In April 4, 2013, the game servers were compromised, and the game source code was most probably stolen and released to the public.
It seems that certain videogame companies picked up this available code and started making their own versions of the game. One such version (md5: de721e2f055f1b203ab561dda4377bab) was digitally signed by Innovative Extremist Co. LTD., a company from Thailand that currently provides web & IT infrastructure services. The game also contains a logo of Electronics Extreme Company Limited with a link to their website. The homepage of Innovative Extremist also listed Electronics Extreme as one of their partners.
Notably, the certificate from Innovative Extremist that was used to sign Infestation is currently revoked. However, the story does not end here. It seems that Electronics Extreme picked up the video game where Innovative Extremist dropped it. And now the game seems to be causing trouble again. We found at least three samples of Infestation signed by Electronics Extreme with a certificate that must be revoked again.
We believe that a poorly maintained development environment, leaked source code, as well vulnerable production servers were at the core of the bad luck chasing this videogame. Ironically, this game about infestation brought only trouble and a serious infection to its developers.
Several executable files from the popular FPS videogame PointBlank contained a similar malware injection. The game was developed by the South Korean company Zepetto Co, whose digital signature was also abused. Although the certificate was still unrevoked as at early April, Zepetto seems to have stopped using the certificate at the end of February 2019.
While some details about this case were announced in March 2019 by our colleagues at ESET, we have been working on this in parallel with ESET and uncovered some additional facts.
All these cases involve digitally signed binaries from three vendors based in three different Asian countries. They are signed with different certificates and a unique chain of trust. What is common to these cases is the way the binaries were trojanized.

The code injection happened through modification of commonly used functions such as CRT (C runtime), which is similar to ASUS case. However, the implementation is very different in the case of the videogame companies. In the ASUS case, the attackers only tampered with a compiled ASUS binary from 2015 and injected additional code. In the other cases, the binaries were recent (from the end of 2018). The malicious code was not inserted as a resource, neither did it overwrite the unused zero-filled space inside the programs. Instead, it seems to have been neatly compiled into the program, and in most cases, it starts at the beginning of the code section as if it had been added even before the legitimate code. Even the data with the encrypted payload is stored inside this code section. This indicates that the attackers either had access to the source code of the victim’s projects or injected malware on the premises of the breached companies at the time of project compilation.
Payload from non-ASUS-related cases
The payload included into the compromised videogames is rather simple. First of all, it checks whether the process has administrative privileges.

Next, it checks the registry value at HKCUSOFTWAREMicrosoftWindows{0753-6681-BD59-8819}. If the value exists and is non-zero, the payload does not run further. Otherwise, it starts a new thread with a malicious intent.
The file contains a hardcoded miniconfig—an annotated example of the config is provided below.
C2 URL: https://nw.infestexe[.]com/version/last.php
Sleep time: 240000
Target Tag: warz
Unwanted processes: wireshark.exe;perfmon.exe;procmon64.exe;procmon.exe;procexp.exe;procexp64.exe;netmon.exe
Apparently, the backdoor was specifically created for this target, which is confirmed by an internal tag (the previous name of the game is “The War Z”).
If any of the unwanted processes is running, or the system language ID is Simplified Chinese or Russian, the malware does not proceed. It also checks for the presence of a mutex named Windows-{0753-6681-BD59-8819}, which is also a sign to stop execution.
After all checks are done, the malware gathers information about the system including:
Network adapter MAC address
System username
System hostname and IP address
Windows version
CPU architecture
Current host FQDN
Domain name
Current executable file name
Drive C: volume name and serial number
Screen resolution
System default language ID
This information is concatenated in one string using the following string template: “%s|%s|%s|%s|%s|%s|%s|%dx%d|%04x|%08X|%s|%s”.
Then the malware crafts a host identifier, which is made up of the C drive serial number string XOR-ed with the hardcoded string “*&b0i0rong2Y7un1” and encoded with the Base64 algorithm. Later on, the C: serial number may be used by the attackers to craft unique backdoor code that runs only on a system with identical properties.
The malware uses HTTP for communication with a C2 server and crafts HTTP headers on its own. It uses the following hardcoded User-Agent string: “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36”
Interestingly, when the malware identifies the Windows version, it uses a long list:
Microsoft Windows NT 4.0
Microsoft Windows 95
Microsoft Windows 98
Microsoft Windows Me
Microsoft Windows 2000e
Microsoft Windows XP
Microsoft Windows XP Professional x64 Edition
Microsoft Windows Server 2003
Microsoft Windows Server 2003 R2
Microsoft Windows Vista
Microsoft Windows Server 2008
Microsoft Windows 7
Microsoft Windows Server 2008 R2
Microsoft Windows 8
Microsoft Windows Server 2012
Microsoft Windows 8.1
Microsoft Windows Server 2012 R2
Microsoft Windows 10
Microsoft Windows Server 2016
The purpose of the code is to submit system information to the C2 server with a POST request and then send another GET request to receive a command to execute.
The following commands were discovered:
DownUrlFile – download URL data to file
DownRunUrlFile – download URL data to file and execute it
RunUrlBinInMem – download URL data and run as shellcode
UnInstall – set registry flag to prevent malware start
The UnInstall command sets the registry value HKCUSOFTWAREMicrosoftWindows{0753-6681-BD59-8819} to 1, which prevents the malware from contacting the C2 again. No files are deleted from the disk, and the files should be discoverable through forensic analysis.
Similarities between the ASUS attack and the non-ASUS-related cases
Although the ASUS case and the videogame industry cases contain certain differences, they are very similar. Let us briefly mention some of the similarities. For instance, the algorithm used to calculate API function hashes (in trojanized games) resembles the one used in the backdoored ASUS Updater tool.

hash = 0
for c in string:
hash = hash * 0x21
hash = hash + c
return hash

hash = 0
for c in string:
hash = hash * 0x83
hash = hash + c
return hash & 0x7FFFFFFF

ASUS case
Other cases
Pseudocode of API hashing algorithm of ASUS vs. other cases
Besides that, our behavior engine identified that ASUS and other related samples are some of the only cases where the IPHLPAPI.dll was used from within a shellcode embedded into a PE file.

In the case of ASUS, the function GetAdaptersAddresses from the IPHLPAPI.dll was used for calculating the hashes of MAC addresses. In the other cases, the function GetAdaptersInfo from the IPHLPAPI.dll was used to retrieve information about the MAC addresses of the computer to pass to remote C&C servers.
ShadowPad connection
While investigating this case, we worked with several companies that had been abused in this wave of supply chain attacks. Our joint investigation revealed that the attackers deployed several tools on an attacked network, including a trojanized linker and a powerful backdoor packed with a recent version of VMProtect.
Our analysis of the sophisticated backdoor (md5: 37e100dd8b2ad8b301b130c2bca3f1ea) that was deployed by the attackers on the company’s internal network during the breach, revealed that it was an updated version of the ShadowPad backdoor, which we reported on in 2017.
The ShadowPad backdoor used in these cases has a very high level of complexity, which makes it almost impossible to reverse engineer:

The newly updated version of ShadowPad follows the same principle as before. The backdoor unwraps multiple stages of code before activating a system of plugins responsible for bootstrapping the main malicious functionality. As with ShadowPad, the attackers used at least two stages of C2 servers, where the first stage would provide the backdoor with an encrypted next-stage C2 domain.
The backdoor contains a hardcoded URL for C2 communication, which points to a publicly editable online Google document. Such online documents, which we extracted from several backdoors, were created by the same user under a name of Tom Giardino (hrsimon59@gmail[.]com), probably a reference to the spokesperson from Valve Corporation.
These online documents contained an ASCII block of text marked as an RSA private key during the time of operation. We noticed that inside the private key, normally encoded with base64, there was an invalid character injection (the symbol “$”):

The message between the two “$” characters in fact contained an encrypted second-stage C2 URL.
We managed to extract the history of changes and collected the following information indicating the time and C2 of ongoing operations in 2018:
Jul 31: UDP://103.19.3[.]17:443
Aug 13: UDP://103.19.3[.]17:443
Oct 08: UDP://103.19.3[.]17:443
Oct 09: UDP://103.19.3[.]17:443
Oct 22: UDP://117.16.142[.]9:443
Nov 20: HTTPS://23.236.77[.]177:443
Nov 21: UDP://117.16.142[.]9:443
Nov 22: UDP://117.16.142[.]9:443
Nov 23: UDP://117.16.142[.]9:443
Nov 27: UDP://117.16.142[.]9:443
Nov 27: HTTPS://103.19.3[.]44:443
Nov 27: TCP://103.19.3[.]44:443
Nov 27: UDP://103.19.3[.]44:1194
Nov 27: HTTPS://23.236.77[.]175:443
Nov 29: HTTPS://23.236.77[.]175:443
Nov 29: UDP://103.19.3[.]43:443
Nov 30: HTTPS://23.236.77[.]177:443
The IP address range 23.236.64.0-23.236.79.255 belongs to the Chinese hosting company Aoyouhost LLC, incorporated in Los Angeles, CA.
Another IP address (117.16.142[.]9) belongs to a range listed as the Korean Education Network and likely belongs to Konkuk university (konkuk.ac.kr). This IP address range has been previously reported by Avast as one of those related to the ShadowPad activity linked to the CCleaner incident. It seems that the ShadowPad attackers are still abusing the university’s network to host their C2 infrastructure.
The last one, 103.19.3[.]44, is located in Japan but seems to belong to another Chinese ISP known as “xTom Shanghai Limited”. Connected to via the IP address, the server displays an error page from Chinese web management software called BaoTa (“宝塔” in Chinese):

PlugX connection
While analyzing the malicious payload injected into the signed ASUS Live Updater binaries, we came across a simple custom encryption algorithm used in the malware. We found that ShadowHammer reused algorithms used in multiple malware samples, including many of PlugX. PlugX is a backdoor quite popular among Chinese-speaking hacker groups. It had previously been seen in the Codoso, MenuPass and Hikit attacks. Some of the samples we found (i.e. md5:5d40e86b09e6fe1dedbc87457a086d95) were created as early as 2012 if the compilation timestamp is anything to trust.

Apparently, both pieces of code share the same constants (0x11111111, 0x22222222, 0x33333333, 0x44444444), but also implement identical algorithms to decrypt data, summarized in the python function below.from ctypes import c_uint32
from struct import pack,unpack
def decrypt(data):
p1 = p2 = p3 = p4 = unpack(“<L”, data[0:4])[0];
pos = 0
decdata = “”
while pos < len(data): p1 = c_uint32(p1 + (p1 >> 3) – 0x11111111).value
p2 = c_uint32(p2 + (p2 >> 5) – 0x22222222).value
p3 = c_uint32(p3 – (p3 << 7) + 0x33333333).value
p4 = c_uint32(p4 – (p4 << 9) + 0x44444444).value
decdata += chr( ( ord(data[pos]) ^ ( ( p1%256 + p2%256 + p3%256 + p4%256 ) % 256 ) ) )
pos += 1
return decdata
 

While this does not indicate a strong connection to PlugX creators, the reuse of the algorithm is unusual and may suggest that the ShadowHammer developers had some experience with PlugX source code, and possibly compiled and used PlugX in some other attacks in the past.
Compromising software developers
All of the analyzed ASUS Live Updater binaries were backdoored using the same executable file patched by an external malicious application, which implemented malware injection on demand. After that, the attackers signed the executable and delivered it to the victims via ASUS update servers, which was detected by Kaspersky Lab products.
However, in the non-ASUS cases, the malware was seamlessly integrated into the code of recently compiled legitimate applications, which suggests that a different technique was used. Our deep search revealed another malware injection mechanism, which comes from a trojanized development environment used by software coders in the organization.
In late 2018, we found a suspicious sample of the link.exe tool uploaded to a public malware scanning service. The tool is part of Microsoft Visual Studio, a popular integrated development environment (IDE) used for creating applications for Microsoft Windows. The same user also uploaded digitally signed compromised executables and some of the backdoors used in the same campaign.
The attack is comprised of an infected Microsoft Incremental Linker, a malicious DLL module that gets loaded through the compromised linker. The malicious DLL then hooks the file open operation and redirects attempts to open a commonly used C++ runtime library during the process of static linking. The redirect destination is a malicious .lib file, which gets linked with the target software instead of the legitimate library. The code also carefully checks which executable is being linked and applies file redirection only if the name matches the hardcoded target file name.
So, was it a developer from a videogame company that installed the trojanized version of the development software, or did the attackers deploy the Trojan code after compromising the developer’s machine? This currently remains unknown. While we could not identify how the attackers managed to replace key files in the integrated development environment, this should serve as a wakeup call to all software developers. If your company produces software, you should ask yourself:
Where does my development software come from?
Is the delivery process (download) of IDE distributions secure?
When did we last check the integrity of our development software?
Other victims
During the analysis of samples related to the updated ShadowPad arsenal, we discovered one unusual backdoor executable (md5: 092ae9ce61f6575344c424967bd79437). It comes as a DLL installed as a service that indirectly listens to TCP port 80 on the target system and responds to a specific URL schema, registered with Windows HTTP Service API: http://+/requested.html. The malware responds to HTTP GET/POST requests using this schema and is not easy to discover, which can help it remain invisible for a long time.
Based on the malware network behavior, we identified three further, previously unknown, victims, a videogame company, a conglomerate holding company and a pharmaceutical company, all based in South Korea, which responded with a confirmation to the malware protocol, indicating compromised servers. We are in the process of notifying the victim companies via our local regional channels. Considering that this type of malware is not widely used and is a custom one, we believe that the same threat actor or a related group are behind these further compromises. This expands the list of previously known usual targets.
Conclusions
While attacks on supply chain companies are not new, the current incident is a big landmark in the cyberattack landscape. Not only does it show that even reputable vendors may suffer from compromising of digital certificates, but it raises many concerns about the software development infrastructure of all other software companies. ShadowPad, a powerful threat actor, previously concentrated on hitting one company at a time. Current research revealed at least four companies compromised in a similar manner, with three more suspected to have been breached by the same attacker. How many more companies are compromised out there is not known. What is known is that ShadowPad succeeded in backdooring developer tools and, one way or another, injected malicious code into digitally signed binaries, subverting trust in this powerful defense mechanism.
Does it mean that we should stop trusting digital signatures? No. But we definitely need to investigate all strange or anomalous behavior, even by trusted and signed applications. Software vendors should introduce another line in their software building conveyor that additionally checks their software for potential malware injections even after the code is digitally signed.
At this unprecedented scale of operations, it is still a mystery why attackers reduced the impact by limiting payload execution to 600+ victims in the case of ASUS. We are also unsure who the ultimate victims were or where the attackers had collected the victims MAC addresses from. If you believe you are one of the victims, we recommend checking your MAC address using this free tool or online check website. And if you discover that you have been targeted by this operation, please email us at shadowhammer@kaspersky.com.
We will keep tracking the ShadowPad activities and inform you about new findings!
Indicators of compromise
C2 servers:
103.19.3[.]17
103.19.3[.]43
103.19.3[.]44
117.16.142[.]9
23.236.77[.]175
23.236.77[.]177
Malware samples and trojanized files:
02385ea5f8463a2845bfe362c6c659fa
915086d90596eb5903bcd5b02fd97e3e
04fb0ccf3ef309b1cd587f609ab0e81e
943db472b4fd0c43428bfc6542d11913
05eacf843b716294ea759823d8f4ab23
95b6adbcef914a4df092f4294473252f
063ff7cc1778e7073eacb5083738e6a2
98908ce6f80ecc48628c8d2bf5b2a50c
06c19cd73471f0db027ab9eb85edc607
9d86dff1a6b70bfdf44406417d3e068f
0e1cc8693478d84e0c5e9edb2dc8555c
a17cb9df43b31bd3dad620559d434e53
0f49621b06f2cdaac8850c6e9581a594
a283d5dea22e061c4ab721959e8f4a24
128cecc59c91c0d0574bc1075fe7cb40
a4b42c2c95d1f2ff12171a01c86cd64f
17a36ac3e31f3a18936552aff2c80249
a76a1fbfd45ad562e815668972267c70
1a0752f14f89891655d746c07da4de01
a96226b8c5599e3391c7b111860dd654
1b95ac1443eb486924ac4d399371397c
a9c750b7a3bbf975e69ef78850af0163
1d05380f3425d54e4ddfc4bacc21d90e
aa15eb28292321b586c27d8401703494
1e091d725b72aed432a03a505b8d617e
aac57bac5f849585ba265a6cd35fde67
2ffc4f0e240ff62a8703e87030a96e39
aafe680feae55bb6226ece175282f068
322cb39bc049aa69136925137906d855
abbb53e1b60ab7044dd379cf80042660
343ad9d459f4154d0d2de577519fb2d3
abbd7c949985748c353da68de9448538
36dd195269979e01a29e37c488928497
b042bc851cafd77e471fa0d90a082043
3c0a0e95ccedaaafb4b3f6fd514fd087
b044cd0f6aae371acf2e349ef78ab39e
496c224d10e1b39a22967a331f7de0a2
b257f366a9f5a065130d4dc99152ee10
4b8d5ae0ad5750233dc1589828da130b
b4abe604916c04fe3dd8b9cb3d501d3f
4fb4c6da73a0a380c6797e9640d7fa00
b572925a7286355ac9ebb12a9fc0cc79
5220c683de5b01a70487dac2440e0ecb
b96bd0bda90d3f28d3aa5a40816695ed
53886c6ebd47a251f11b44869f67163d
c0116d877d048b1ba87c0de6fd7c3fb2
55a7aa5f0e52ba4d78c145811c830107
c778fc8e816061420c537db2617e0297
5855ce7c4a3167f0e006310eb1c76313
cdb0a09067877f30189811c7aea3f253
5b6cd0a85996a7d47a8e9f8011d4ad3f
d07e6abebcf1f2119622c60ad0acf4fa
5eed18254d797ccea62d5b74d96b6795
d1ed421779c31df2a059fe0f91c24721
6186b317c8b6a9da3ca4c166e68883ea
d4c4813b21556dd478315734e1c7ae54
63606c861a63a8c60edcd80923b18f96
dc15e578401ad9b8f72c4d60b79fdf0f
63f2fe96de336b6097806b22b5ab941a
dca86d2a9eb6dc53f549860f103486a9
6ab5386b5ad294fc6ec4d5e47c9c2470
dd792f9185860e1464b4346254b2101b
6b38c772b2ffd7a7818780b29f51ccb2
e7dcfa8e75b0437975ce0b2cb123dc7b
6cf305a34a71b40c60722b2b47689220
e8db4206c2c12df7f61118173be22c89
6e94b8882fe5865df8c4d62d6cff5620
ea3b7770018a20fc7c4541c39ea271af
7d9d29c1c03461608bcab930fef2f568
eac3e3ece94bc84e922ec077efb15edd
807d86da63f0db1fc746d1f0b05bc357
ecf865c95a9bec46aa9b97060c0e317d
849a2b0dc80aeca3d175c139efe5221c
ef43b55353a34be9e93160bb1768b1a6
8505484efde6a1009f90fa02ca42f011
f0ba34be0486037913e005605301f3ce
8578f0c7b0a14f129cc66ee236c58050
f2f879989d967e03b9ea0938399464ab
86a4cac227078b9c95c560c8f0370bf0
f4edc757e9917243ce513f22d0ccacf2
8756bafa7f0a9764311d52bc792009f9
f9d46bbffa1cbd106ab838ee0ccc5242
87a8930e88e9564a30288572b54faa46
fa83ffde24f149f9f6d1d8bc05c0e023
88777aacd5f16599547926a4c9202862
fa96e56e7c26515875214eec743d2db5
8baa46d0e0faa2c6a3f20aeda2556b18
fb1473e5423c8b82eb0e1a40a8baa118
8ef2d715f3a0a3d3ebc989b191682017
fcfab508663d9ce519b51f767e902806
092ae9ce61f6575344c424967bd79437
7f05d410dc0d1b0e7a3fcc6cdda7a2ff
eb37c75369046fb1076450b3c34fb8ab






Click here for best antivirus and antispyware software

Powered by WPeMatico