{
	"id": "181cbadb-7189-441d-9b9b-b02af5ec96c9",
	"created_at": "2026-04-06T00:14:20.618926Z",
	"updated_at": "2026-04-10T13:12:53.117843Z",
	"deleted_at": null,
	"sha1_hash": "d244fb95c84cc481e8c1313e7462625b22cf346c",
	"title": "Operation ShadowHammer: a high-profile supply chain attack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2744121,
	"plain_text": "Operation ShadowHammer: a high-profile supply chain attack\r\nBy GReAT\r\nPublished: 2019-04-23 · Archived: 2026-04-05 20:35:34 UTC\r\nIn late March 2019, we briefly highlighted our research on ShadowHammer attacks, a sophisticated supply chain\r\nattack involving ASUS Live Update Utility, which was featured in a Kim Zetter article on Motherboard. The topic\r\nwas also one of the research announcements made at the SAS conference, which took place in Singapore on April\r\n9-10, 2019. Now it is time to share more details about the research with our readers.\r\nAt the end of January 2019, Kaspersky Lab researchers discovered what appeared to be a new attack on a large\r\nmanufacturer in Asia. Our researchers named it “Operation ShadowHammer”.\r\nSome of the executable files, which were downloaded from the official domain of a reputable and trusted large\r\nmanufacturer, contained apparent malware features. Careful analysis confirmed that the binary had been tampered\r\nwith by malicious attackers.\r\nIt is important to note that any, even tiny, tampering with executables in such a case normally breaks the digital\r\nsignature. However, in this case, the digital signature was intact: valid and verifiable. We quickly realized that we\r\nwere dealing with a case of a compromised digital signature.\r\nWe believe this to be the result of a sophisticated supply chain attack, which matches or even surpasses the\r\nShadowPad and the CCleaner incidents in complexity and techniques. The reason that it stayed undetected for so\r\nlong is partly the fact that the trojanized software was signed with legitimate certificates (e.g. “ASUSTeK\r\nComputer Inc.”).\r\nThe goal of the attack was to surgically target an unknown pool of users, who were identified by their network\r\nadapters’ MAC addresses. To achieve this, the attackers had hardcoded a list of MAC addresses into the trojanized\r\nsamples and the list was used to identify the intended targets of this massive operation. We were able to extract\r\nmore than 600 unique MAC addresses from more than 200 samples used in the attack. There might be other\r\nsamples out there with different MAC addresses on their lists, though.\r\nTechnical details\r\nThe research started upon the discovery of a trojanized ASUS Live Updater file (setup.exe), which contained a\r\ndigital signature of ASUSTeK Computer Inc. and had been backdoored using one of the two techniques explained\r\nbelow.\r\nIn earlier variants of ASUS Live Updater (i.e. MD5:0f49621b06f2cdaac8850c6e9581a594), the attackers replaced\r\nthe WinMain function in the binary with their own. This function copies a backdoor executable from the resource\r\nsection using a hardcoded size and offset to the resource. Once copied to the heap memory, another hardcoded\r\noffset, specific to the executable, is used to start the backdoor. The offset points to a position-independent\r\nshellcode-style function that unwraps and runs the malicious code further.\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 1 of 29\n\nSome of the older samples revealed the project path via a PDB file reference:\r\n“D:\\C++\\AsusShellCode\\Release\\AsusShellCode.pdb“. This suggests that the attackers had exclusively\r\nprepared the malicious payload for their target. A similar tactic of precise targeting has become a persistent\r\nproperty of these attackers.\r\nA look at the resource section used for carrying the malicious payload revealed that the attackers had decided not\r\nto change the file size of the ASUS Live Updater binary. They changed the resource contents and overwrote a tiny\r\nblock of the code in the subject executable. The layout of that patched file is shown below.\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 2 of 29\n\nWe managed to find the original ASUS Live Updater executable which had been patched and abused by the\r\nattackers. As a result, we were able to recover the overwritten data in the resource section. The file we found was\r\ndigitally signed and certainly had no infection present.\r\nBoth the legitimate ASUS executable and the resource-embedded updater binary contain timestamps from March\r\n2015. Considering that the operation took place in 2018, this raises the following question: why did the attackers\r\nchoose an old ASUS binary as the infection carrier?\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 3 of 29\n\nAnother injection technique was found in more recent samples. Using that technique, the attackers patched the\r\ncode inside the C runtime (CRT) library function “___crtExitProcess”. The malicious code executes a shellcode\r\nloader instead of the standard function “___crtCorExitProcess”:\r\nThis way, the execution flow is passed to another address which is located at the end of the code section. The\r\nattackers used a small decryption routine that can fit into a block at the end of the code section, which has a series\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 4 of 29\n\nof zero bytes in the original executable. They used the same source executable file from ASUS (compiled in\r\nMarch 2015) for this new type of injection.\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 5 of 29\n\nThe loader code copies another block of encrypted shellcode from the file’s resource section (of the type “EXE”)\r\nto 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\r\noffset of +8.\r\nWe believe that the attackers changed the payload start routine in an attempt to evade detection. Apparently, they\r\nswitched to a better method of hiding their embedded shellcode at some point between the end of July and\r\nSeptember 2018.\r\nShadowHammer downloader\r\nThe compromised ASUS binaries carried a payload that was a Trojan downloader. Let us take a closer look at one\r\nsuch ShadowHammer downloader extracted from a copy of the ASUS Live Updater tool with\r\nMD5:0f49621b06f2cdaac8850c6e9581a594. It has the following properties:\r\nMD5: 63f2fe96de336b6097806b22b5ab941a\r\nSHA1: 6f8f43b6643fc36bae2e15025d533a1d53291b8a\r\nSHA256: 1bb53937fa4cba70f61dc53f85e4e25551bc811bf9821fc47d25de1be9fd286a\r\nDigital certificate fingerprint: 0f:f0:67:d8:01:f7:da:ee:ae:84:2e:9f:e5:f6:10:ea\r\nFile Size: 1’662’464 bytes\r\nFile Type: PE32 executable (GUI) Intel 80386, for MS Windows\r\nLink Time: 2018.07.10 05:58:19 (GMT)\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 6 of 29\n\nThe relatively large file size is explained by the presence of partial data from the original ASUS Live Updater\r\napplication appended to the end of the executable. The attackers took the original Live Updater and overwrote it\r\nwith their own PE executable starting from the PE header, so that the file contains the actual PE image, whose size\r\nis only 40448 bytes, while the rest comes from ASUS. The malicious executable was created using Microsoft\r\nVisual C++ 2010.\r\nThe core function of this executable is in a subroutine which is called from WinMain, but also executed directly\r\nvia a hardcoded offset from the code injected into ASUS Live Updater.\r\nThe code uses dynamic import resolution with its own simple hashing algorithm. Once the imports are resolved, it\r\ncollects MAC addresses of all available network adapters and calculates an MD5 hash for each of these. After that,\r\nthe hashes are compared against a table of 55 hardcoded values. Other variants of the downloader contained a\r\ndifferent table of hashes, and in some cases, the hashes were arranged in pairs.\r\nIn other words, the malware iterates through a table of hashes and compares them to the hashes of local adapters’\r\nMAC hashes. This way, the target system is recognized and the malware proceeds to the next stage, downloading\r\na binary object from https://asushotfix[.]com/logo.jpg (or https://asushotfix[.]com/logo2.jpg in newer samples).\r\nThe malware also sends the first hash from the match entry as a parameter in the request to identify the victim.\r\nThe server response is expected to be an executable shellcode, which is placed in newly allocated memory and\r\nstarted.\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 7 of 29\n\nOur investigation uncovered 230 unique samples with different shellcodes and different sets of MAC address\r\nhashes. This leads us to believe that the campaign targeted a vast number of people or companies. In total, we\r\nwere able to extract 14 unique hash tables. The smallest hash table found contained eight entries and the biggest,\r\n307 entries. Interestingly, although the subset of hash entries was changing, some of the entries were present in all\r\nof the tables.\r\nFor all users whose MAC did not match expected values, the code would create an INI file located two directory\r\nlevels above the current executable and named “idx.ini”. Three values were written into the INI file under the\r\n[IDX_FILE] section:\r\n[IDX_FILE]\r\nXXX_IDN=YYYY-MM-DD\r\nXXX_IDE=YYYY-MM-DD\r\nXXX_IDX=YYYY-MM-DD\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 8 of 29\n\nwhere YYYY-MM-DD is a date one week ahead of the current system date.\r\nThe code injected by the attackers was discovered with over 57000 Kaspersky Lab users. It would run but remain\r\nsilent on systems that were not primary targets, making it almost impossible to discover the anomalous behavior\r\nof the trojanized executables. The exact total of the affected users around the world remains unknown.\r\nDigital signature abuse\r\nA lot of computer security software deployed today relies on integrity control of trusted executables. Digital\r\nsignature verification is one such method. In this attack, the attackers managed to get their code signed with a\r\ncertificate of a big vendor. How was that possible? We do not have definitive answers, but let us take a look at\r\nwhat we observed.\r\nFirst of all, we noticed that all backdoored ASUS binaries were signed with two different certificates. Here are\r\ntheir fingerprints:\r\n0ff067d801f7daeeae842e9fe5f610ea\r\n05e6a0be5ac359c7ff11f4b467ab20fc\r\nThe same two certificates have been used in the past to sign at least 3000 legitimate ASUS files (i.e. ASUS GPU\r\nTweak, ASUS PC Link and others), which makes it very hard to revoke these certificates.\r\nAll of the signed binaries share certain interesting features: none of them had a signing timestamp set, and the\r\ndigest algorithm used was SHA1. The reason for this could be an attempt at hiding the time of the operation to\r\nmake it harder to discover related forensic artefacts.\r\nAlthough there is no timestamp that can be relied on to understand when the attack started, there is a mandatory\r\nfield in the certificate, “Certificate Validity Period”, which can help us to understand roughly the timeframe of the\r\noperation. Apparently, because the certificate that the attackers relied on expired in 2018 and therefore had to be\r\nreissued, they used two different certificates.\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 9 of 29\n\nAnother notable fact is that both abused certificates are from the DigiCert SHA2 Assured ID Code Signing CA.\r\nThe legitimate ASUS binaries that we have observed use a different certificate, which was issued by the DigiCert\r\nEV Code Signing CA (SHA2). EV stands for “Extended Validation” and provides for stricter requirements for the\r\nparty that intends to use the certificate, including hardware requirements. We believe that the attackers simply did\r\nnot have access to a production signing device with an EV certificate.\r\nThis indicates that the attackers most likely obtained a copy of the certificates or abused a system on the ASUS\r\nnetwork that had the certificates installed. We do not know about all software with malware injection they\r\nmanaged to sign, and we believe that the compromised signing certificates must be removed and revoked.\r\nUnfortunately, one month after this was reported to ASUS, newly released software (i.e. md5:\r\n1b8d2459d4441b8f4a691aec18d08751) was still being signed with a compromised certificate. We have\r\nimmediately notified ASUS about this and provided evidence as required.\r\nUsing decrypted shellcode and through code similarity, we found a number of related samples which appear to\r\nhave been part of a parallel attack wave. These files have the following properties:\r\nthey contain the same shellcode style as the payload from the compromised ASUS Live Updater binaries,\r\nalbeit unencrypted\r\nthey have a forgotten PDB path of “D:\\C++\\AsusShellCode\\Release\\AsusShellCode.pdb”\r\nthe shellcode from all of these samples connects to the same C2: asushotfix[.]com\r\nall samples were compiled between June and July 2018\r\nthe samples have been detected on computers all around the globe\r\nThe hashes of these related samples include:\r\n322cb39bc049aa69136925137906d855\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 10 of 29\n\n36dd195269979e01a29e37c488928497\r\n7d9d29c1c03461608bcab930fef2f568\r\n807d86da63f0db1fc746d1f0b05bc357\r\n849a2b0dc80aeca3d175c139efe5221c\r\n86A4CAC227078B9C95C560C8F0370BF0\r\n98908ce6f80ecc48628c8d2bf5b2a50c\r\na4b42c2c95d1f2ff12171a01c86cd64f\r\nb4abe604916c04fe3dd8b9cb3d501d3f\r\neac3e3ece94bc84e922ec077efb15edd\r\n128CECC59C91C0D0574BC1075FE7CB40\r\n88777aacd5f16599547926a4c9202862\r\nThese files are dropped by larger setup files / installers, signed by an ASUS certificate (serial number:\r\n0ff067d801f7daeeae842e9fe5f610ea) valid from 2015-07-27 till 2018-08-01).\r\nThe hashes of the larger installers/droppers include:\r\n0f49621b06f2cdaac8850c6e9581a594\r\n17a36ac3e31f3a18936552aff2c80249\r\nAt this point, we do not know how they were used in these attacks and whether they were delivered via a different\r\nmechanism. These files were located in a “TEMP” subfolder for ASUS Live Updater, so it is possible that the\r\nsoftware downloaded these files directly. Locations where these files were detected include:\r\nasus\\asus live update\\temp\\1\\Setup.exe\r\nasus\\asus live update\\temp\\2\\Setup.exe\r\nasus\\asus live update\\temp\\3\\Setup.exe\r\nasus\\asus live update\\temp\\5\\Setup.exe\r\nasus\\asus live update\\temp\\6\\Setup.exe\r\nasus\\asus live update\\temp\\9\\Setup.exe\r\nPublic reports of the attack\r\nWhile investigating this case, we were wondering how such a massive attack could go unnoticed on the Internet.\r\nSearching for any kind of evidence related to the attack, we came by a Reddit thread created in June 2018, where\r\nuser GreyWolfx posted a screenshot of a suspicious-looking ASUS Live Update message:\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 11 of 29\n\nThe message claims to be a “ASUS Critical Update” notification, however, the item does not have a name or\r\nversion number.\r\nOther users commented in the thread, while some uploaded the suspicious updater to VirusTotal:\r\nThe file uploaded to VT is not one of the malicious compromised updates; we can assume the person who\r\nuploaded it actually uploaded the ASUS Live Update itself, as opposed to the update it received from the Internet.\r\nNevertheless, this could suggest that potentially compromised updates were delivered to users as far back as June\r\n2018.\r\nIn September 2018, another Reddit user, FabulaBerserko also posted a message about a suspicious ASUS Live\r\nupdate:\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 12 of 29\n\nAsus_USA replied to FabulaBerserko with the following message, suggesting he run a scan for viruses:\r\nIn his message, the Reddit user FabulaBerserko talks about an update listed as critical, however without a name\r\nand with a release date of March 2015. Interestingly, the related attack samples containing the PDB\r\n“AsusShellCode.pdb” have a compilation timestamp from 2015 as well, so it is possible that the Reddit user saw\r\nthe delivery of one such file through ASUS Live Update in September 2018.\r\nTargets by MAC address\r\nWe managed to crack all of the 600+ MAC address hashes and analyzed distribution by manufacturer, using\r\npublicly available Ethernet-to-vendor assignment lists. It turns out that the distribution is uneven and certain\r\nvendors are a higher priority for the attackers. The chart below shows statistics we collected based on network\r\nadapter manufacturers’ names:\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 13 of 29\n\nSome of the MAC addresses included on the target list were rather popular, i.e. 00-50-56-C0-00-08 belongs to the\r\nVMWare virtual adapter VMNet8 and is the same for all users of a certain version of the VMware software for\r\nWindows. To prevent infection by mistake, the attackers used a secondary MAC address from the real Ethernet\r\ncard, which would make targeting more precise. However, it tells us that one of the targeted users used VMWare,\r\nwhich is rather common for software engineers (in testing their software).\r\nAnother popular MAC was 0C-5B-8F-27-9A-64, which belongs to the MAC address of a virtual Ethernet adapter\r\ncreated by a Huawei USB 3G modem, model E3372h. It seems that all users of this device shared the same MAC\r\naddress.\r\nInteraction with ASUS\r\nThe day after the ShadowHammer discovery, we created a short report for ASUS and approached the company\r\nthrough our local colleagues in Taiwan, providing all details of what was known about the attack and hoping for\r\ncooperation. The following is a timeline of the discovery of this supply-chain attack, together with ASUS\r\ninteraction and reporting:\r\n29-Jan-2019 – initial discovery of the compromised ASUS Live Updater\r\n30-Jan-2019 – created preliminary report to be shared with ASUS, briefed Kaspersky Lab colleagues in\r\nTaipei\r\n31-Jan-2019 – in-person meeting with ASUS, teleconference with researchers; we notified ASUS of the\r\nfinding and shared hard copy of the preliminary attack report with indicators of compromise and Yara\r\nrules. ASUS provided Kaspersky with the latest version of ASUS Live Updater, which was analyzed and\r\nfound to be uninfected.\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 14 of 29\n\n01-Feb-2019 – ASUS provides an archive of all ASUS Live Updater tools beginning from 2018. None of\r\nthem were infected, and they were signed with different certificates.\r\n14-Feb-2019 – second face-to-face meeting with ASUS to discuss the details of the attack\r\n20-Feb-2019 – update conf call with ASUS to provide newly found details about the attack\r\n08-Mar-2019 – provided the list of targeted MAC addresses to ASUS, answered other questions related to\r\nthe attack\r\n08-Apr-2019 – provided a comprehensive report on the current attack investigation to ASUS.\r\nWe appreciate a quick response from our ASUS colleagues just days before one of the largest holidays in Asia\r\n(Lunar New Year). This helped us to confirm that the attack was in a deactivated stage and there was no\r\nimmediate risk to new infections and gave us more time to collect further artefacts. However, all compromised\r\nASUS binaries had to be properly flagged as containing malware and removed from Kaspersky Lab users’\r\ncomputers.\r\nIn our search for similar malware, we came across other digitally signed binaries from three other vendors in Asia.\r\nOne of these vendors is a game development company from Thailand known as Electronics Extreme Company\r\nLimited. The company has released digitally signed binaries of a video game called “Infestation: Survivor\r\nStories”. 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\r\ngames of all time“. The game servers were taken offline on December 15, 2016.”\r\nThe history of this videogame itself contains many controversies. According to Wikipedia, it was originally\r\ndeveloped under the title of “The War Z” and released by OP Productions which put it in the Steam store in\r\nDecember 2012. In April 4, 2013, the game servers were compromised, and the game source code was most\r\nprobably stolen and released to the public.\r\nIt seems that certain videogame companies picked up this available code and started making their own versions of\r\nthe game. One such version (md5: de721e2f055f1b203ab561dda4377bab) was digitally signed by Innovative\r\nExtremist Co. LTD., a company from Thailand that currently provides web \u0026 IT infrastructure services. The\r\ngame also contains a logo of Electronics Extreme Company Limited with a link to their website. The homepage\r\nof Innovative Extremist also listed Electronics Extreme as one of their partners.\r\nNotably, the certificate from Innovative Extremist that was used to sign Infestation is currently revoked. However,\r\nthe story does not end here. It seems that Electronics Extreme picked up the video game where Innovative\r\nExtremist dropped it. And now the game seems to be causing trouble again. We found at least three samples of\r\nInfestation signed by Electronics Extreme with a certificate that must be revoked again.\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 15 of 29\n\nWe believe that a poorly maintained development environment, leaked source code, as well vulnerable production\r\nservers were at the core of the bad luck chasing this videogame. Ironically, this game about infestation brought\r\nonly trouble and a serious infection to its developers.\r\nSeveral executable files from the popular FPS videogame PointBlank contained a similar malware injection. The\r\ngame was developed by the South Korean company Zepetto Co, whose digital signature was also abused.\r\nAlthough the certificate was still unrevoked as at early April, Zepetto seems to have stopped using the certificate\r\nat the end of February 2019.\r\nWhile some details about this case were announced in March 2019 by our colleagues at ESET, we have been\r\nworking on this in parallel with ESET and uncovered some additional facts.\r\nAll these cases involve digitally signed binaries from three vendors based in three different Asian countries. They\r\nare signed with different certificates and a unique chain of trust. What is common to these cases is the way the\r\nbinaries were trojanized.\r\nThe code injection happened through modification of commonly used functions such as CRT (C runtime), which\r\nis similar to ASUS case. However, the implementation is very different in the case of the videogame companies.\r\nIn the ASUS case, the attackers only tampered with a compiled ASUS binary from 2015 and injected additional\r\ncode. In the other cases, the binaries were recent (from the end of 2018). The malicious code was not inserted as a\r\nresource, neither did it overwrite the unused zero-filled space inside the programs. Instead, it seems to have been\r\nneatly compiled into the program, and in most cases, it starts at the beginning of the code section as if it had been\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 16 of 29\n\nadded even before the legitimate code. Even the data with the encrypted payload is stored inside this code section.\r\nThis indicates that the attackers either had access to the source code of the victim’s projects or injected malware\r\non the premises of the breached companies at the time of project compilation.\r\nThe payload included into the compromised videogames is rather simple. First of all, it checks whether the\r\nprocess has administrative privileges.\r\nNext, it checks the registry value at HKCU\\SOFTWARE\\Microsoft\\Windows\\{0753-6681-BD59-8819}. If the\r\nvalue exists and is non-zero, the payload does not run further. Otherwise, it starts a new thread with a malicious\r\nintent.\r\nThe file contains a hardcoded miniconfig—an annotated example of the config is provided below.\r\nC2 URL: https://nw.infestexe[.]com/version/last.php\r\nSleep time: 240000\r\nTarget Tag: warz\r\nUnwanted processes:\r\nwireshark.exe;perfmon.exe;procmon64.exe;procmon.exe;procexp.exe;procexp64.exe;netmon.exe\r\nApparently, the backdoor was specifically created for this target, which is confirmed by an internal tag (the\r\nprevious name of the game is “The War Z”).\r\nIf any of the unwanted processes is running, or the system language ID is Simplified Chinese or Russian, the\r\nmalware does not proceed. It also checks for the presence of a mutex named Windows-{0753-6681-BD59-8819},\r\nwhich is also a sign to stop execution.\r\nAfter all checks are done, the malware gathers information about the system including:\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 17 of 29\n\nNetwork adapter MAC address\r\nSystem username\r\nSystem hostname and IP address\r\nWindows version\r\nCPU architecture\r\nCurrent host FQDN\r\nDomain name\r\nCurrent executable file name\r\nDrive C: volume name and serial number\r\nScreen resolution\r\nSystem default language ID\r\nThis information is concatenated in one string using the following string template:\r\n“%s|%s|%s|%s|%s|%s|%s|%dx%d|%04x|%08X|%s|%s”.\r\nThen the malware crafts a host identifier, which is made up of the C drive serial number string XOR-ed with the\r\nhardcoded string “*\u0026b0i0rong2Y7un1” and encoded with the Base64 algorithm. Later on, the C: serial number\r\nmay be used by the attackers to craft unique backdoor code that runs only on a system with identical properties.\r\nThe malware uses HTTP for communication with a C2 server and crafts HTTP headers on its own. It uses the\r\nfollowing hardcoded User-Agent string: “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36\r\n(KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36”\r\nInterestingly, when the malware identifies the Windows version, it uses a long list:\r\nMicrosoft Windows NT 4.0\r\nMicrosoft Windows 95\r\nMicrosoft Windows 98\r\nMicrosoft Windows Me\r\nMicrosoft Windows 2000e\r\nMicrosoft Windows XP\r\nMicrosoft Windows XP Professional x64 Edition\r\nMicrosoft Windows Server 2003\r\nMicrosoft Windows Server 2003 R2\r\nMicrosoft Windows Vista\r\nMicrosoft Windows Server 2008\r\nMicrosoft Windows 7\r\nMicrosoft Windows Server 2008 R2\r\nMicrosoft Windows 8\r\nMicrosoft Windows Server 2012\r\nMicrosoft Windows 8.1\r\nMicrosoft Windows Server 2012 R2\r\nMicrosoft Windows 10\r\nMicrosoft Windows Server 2016\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 18 of 29\n\nThe purpose of the code is to submit system information to the C2 server with a POST request and then send\r\nanother GET request to receive a command to execute.\r\nThe following commands were discovered:\r\nDownUrlFile – download URL data to file\r\nDownRunUrlFile – download URL data to file and execute it\r\nRunUrlBinInMem – download URL data and run as shellcode\r\nUnInstall – set registry flag to prevent malware start\r\nThe UnInstall command sets the registry value HKCU\\SOFTWARE\\Microsoft\\Windows\\{0753-6681-BD59-\r\n8819} to 1, which prevents the malware from contacting the C2 again. No files are deleted from the disk, and the\r\nfiles should be discoverable through forensic analysis.\r\nAlthough the ASUS case and the videogame industry cases contain certain differences, they are very similar. Let\r\nus briefly mention some of the similarities. For instance, the algorithm used to calculate API function hashes (in\r\ntrojanized games) resembles the one used in the backdoored ASUS Updater tool.\r\n1\r\n2\r\n3\r\n4\r\n5\r\nhash = 0\r\nfor c in string:\r\n    hash = hash * 0x21\r\n    hash = hash + c\r\nreturn hash\r\n1\r\n2\r\n3\r\n4\r\n5\r\nhash = 0\r\nfor c in string:\r\n    hash = hash * 0x83\r\n    hash = hash + c\r\nreturn hash \u0026amp; 0x7FFFFFFF\r\nASUS case Other cases\r\nPseudocode of API hashing algorithm of ASUS vs. other cases\r\nBesides that, our behavior engine identified that ASUS and other related samples are some of the only cases where\r\nthe IPHLPAPI.dll was used from within a shellcode embedded into a PE file.\r\nIn the case of ASUS, the function GetAdaptersAddresses from the IPHLPAPI.dll was used for calculating the\r\nhashes of MAC addresses. In the other cases, the function GetAdaptersInfo from the IPHLPAPI.dll was used to\r\nretrieve information about the MAC addresses of the computer to pass to remote C\u0026C servers.\r\nShadowPad connection\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 19 of 29\n\nWhile investigating this case, we worked with several companies that had been abused in this wave of supply\r\nchain attacks. Our joint investigation revealed that the attackers deployed several tools on an attacked network,\r\nincluding a trojanized linker and a powerful backdoor packed with a recent version of VMProtect.\r\nOur analysis of the sophisticated backdoor (md5: 37e100dd8b2ad8b301b130c2bca3f1ea) that was deployed by the\r\nattackers on the company’s internal network during the breach, revealed that it was an updated version of the\r\nShadowPad backdoor, which we reported on in 2017.\r\nThe ShadowPad backdoor used in these cases has a very high level of complexity, which makes it almost\r\nimpossible to reverse engineer:\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 20 of 29\n\nThe newly updated version of ShadowPad follows the same principle as before. The backdoor unwraps multiple\r\nstages of code before activating a system of plugins responsible for bootstrapping the main malicious\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 21 of 29\n\nfunctionality. As with ShadowPad, the attackers used at least two stages of C2 servers, where the first stage would\r\nprovide the backdoor with an encrypted next-stage C2 domain.\r\nThe backdoor contains a hardcoded URL for C2 communication, which points to a publicly editable online\r\nGoogle document. Such online documents, which we extracted from several backdoors, were created by the same\r\nuser under a name of Tom Giardino (hrsimon59@gmail[.]com), probably a reference to the spokesperson from\r\nValve Corporation.\r\nThese online documents contained an ASCII block of text marked as an RSA private key during the time of\r\noperation. We noticed that inside the private key, normally encoded with base64, there was an invalid character\r\ninjection (the symbol “$”):\r\nThe message between the two “$” characters in fact contained an encrypted second-stage C2 URL.\r\nWe managed to extract the history of changes and collected the following information indicating the time and C2\r\nof ongoing operations in 2018:\r\nJul 31: UDP://103.19.3[.]17:443\r\nAug 13: UDP://103.19.3[.]17:443\r\nOct 08: UDP://103.19.3[.]17:443\r\nOct 09: UDP://103.19.3[.]17:443\r\nOct 22: UDP://117.16.142[.]9:443\r\nNov 20: HTTPS://23.236.77[.]177:443\r\nNov 21: UDP://117.16.142[.]9:443\r\nNov 22: UDP://117.16.142[.]9:443\r\nNov 23: UDP://117.16.142[.]9:443\r\nNov 27: UDP://117.16.142[.]9:443\r\nNov 27: HTTPS://103.19.3[.]44:443\r\nNov 27: TCP://103.19.3[.]44:443\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 22 of 29\n\nNov 27: UDP://103.19.3[.]44:1194\r\nNov 27: HTTPS://23.236.77[.]175:443\r\nNov 29: HTTPS://23.236.77[.]175:443\r\nNov 29: UDP://103.19.3[.]43:443\r\nNov 30: HTTPS://23.236.77[.]177:443\r\nThe IP address range 23.236.64.0-23.236.79.255 belongs to the Chinese hosting company Aoyouhost LLC,\r\nincorporated in Los Angeles, CA.\r\nAnother IP address (117.16.142[.]9) belongs to a range listed as the Korean Education Network and likely belongs\r\nto Konkuk university (konkuk.ac.kr). This IP address range has been previously reported by Avast as one of those\r\nrelated to the ShadowPad activity linked to the CCleaner incident. It seems that the ShadowPad attackers are still\r\nabusing the university’s network to host their C2 infrastructure.\r\nThe last one, 103.19.3[.]44, is located in Japan but seems to belong to another Chinese ISP known as “xTom\r\nShanghai Limited”. Connected to via the IP address, the server displays an error page from Chinese web\r\nmanagement software called BaoTa (“宝塔” in Chinese):\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 23 of 29\n\nPlugX connection\r\nWhile analyzing the malicious payload injected into the signed ASUS Live Updater binaries, we came across a\r\nsimple custom encryption algorithm used in the malware. We found that ShadowHammer reused algorithms used\r\nin 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\r\nsamples we found (i.e. md5:5d40e86b09e6fe1dedbc87457a086d95) were created as early as 2012 if the\r\ncompilation timestamp is anything to trust.\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 24 of 29\n\nApparently, both pieces of code share the same constants (0x11111111, 0x22222222, 0x33333333, 0x44444444),\r\nbut also implement identical algorithms to decrypt data, summarized in the python function below.\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\nfrom ctypes import c_uint32\r\nfrom struct import pack,unpack\r\ndef decrypt(data):\r\np1 = p2 = p3 = p4 = unpack(\"\u0026lt;L\", data[0:4])[0];\r\npos = 0\r\ndecdata = \"\"\r\nwhile pos \u0026lt; len(data): p1 = c_uint32(p1 + (p1 \u0026gt;\u0026gt; 3) - 0x11111111).value\r\n    p2 = c_uint32(p2 + (p2 \u0026gt;\u0026gt; 5) - 0x22222222).value\r\n    p3 = c_uint32(p3 - (p3 \u0026lt;\u0026lt; 7) + 0x33333333).value\r\n    p4 = c_uint32(p4 - (p4 \u0026lt;\u0026lt; 9) + 0x44444444).value\r\n    decdata += chr( ( ord(data[pos]) ^ ( ( p1%256 + p2%256 + p3%256 + p4%256 ) % 256 ) ) )\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 25 of 29\n\n12\r\n13\r\n    pos += 1\r\nreturn decdata\r\n\u003c//pre\u003e\r\nWhile this does not indicate a strong connection to PlugX creators, the reuse of the algorithm is unusual and may\r\nsuggest that the ShadowHammer developers had some experience with PlugX source code, and possibly compiled\r\nand used PlugX in some other attacks in the past.\r\nCompromising software developers\r\nAll of the analyzed ASUS Live Updater binaries were backdoored using the same executable file patched by an\r\nexternal malicious application, which implemented malware injection on demand. After that, the attackers signed\r\nthe executable and delivered it to the victims via ASUS update servers, which was detected by Kaspersky Lab\r\nproducts.\r\nHowever, in the non-ASUS cases, the malware was seamlessly integrated into the code of recently compiled\r\nlegitimate applications, which suggests that a different technique was used. Our deep search revealed another\r\nmalware injection mechanism, which comes from a trojanized development environment used by software coders\r\nin the organization.\r\nIn late 2018, we found a suspicious sample of the link.exe tool uploaded to a public malware scanning service.\r\nThe tool is part of Microsoft Visual Studio, a popular integrated development environment (IDE) used for creating\r\napplications for Microsoft Windows. The same user also uploaded digitally signed compromised executables and\r\nsome of the backdoors used in the same campaign.\r\nThe attack is comprised of an infected Microsoft Incremental Linker, a malicious DLL module that gets loaded\r\nthrough the compromised linker. The malicious DLL then hooks the file open operation and redirects attempts to\r\nopen a commonly used C++ runtime library during the process of static linking. The redirect destination is a\r\nmalicious .lib file, which gets linked with the target software instead of the legitimate library. The code also\r\ncarefully checks which executable is being linked and applies file redirection only if the name matches the\r\nhardcoded target file name.\r\nSo, was it a developer from a videogame company that installed the trojanized version of the development\r\nsoftware, or did the attackers deploy the Trojan code after compromising the developer’s machine? This currently\r\nremains unknown. While we could not identify how the attackers managed to replace key files in the integrated\r\ndevelopment environment, this should serve as a wakeup call to all software developers. If your company\r\nproduces software, you should ask yourself:\r\n1. 1 Where does my development software come from?\r\n2. 2 Is the delivery process (download) of IDE distributions secure?\r\n3. 3 When did we last check the integrity of our development software?\r\nOther victims\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 26 of 29\n\nDuring the analysis of samples related to the updated ShadowPad arsenal, we discovered one unusual backdoor\r\nexecutable (md5: 092ae9ce61f6575344c424967bd79437). It comes as a DLL installed as a service that indirectly\r\nlistens to TCP port 80 on the target system and responds to a specific URL schema, registered with Windows\r\nHTTP Service API: http://+/requested.html. The malware responds to HTTP GET/POST requests using this\r\nschema and is not easy to discover, which can help it remain invisible for a long time.\r\nBased on the malware network behavior, we identified three further, previously unknown, victims, a videogame\r\ncompany, a conglomerate holding company and a pharmaceutical company, all based in South Korea, which\r\nresponded with a confirmation to the malware protocol, indicating compromised servers. We are in the process of\r\nnotifying the victim companies via our local regional channels. Considering that this type of malware is not\r\nwidely used and is a custom one, we believe that the same threat actor or a related group are behind these further\r\ncompromises. This expands the list of previously known usual targets.\r\nConclusions\r\nWhile attacks on supply chain companies are not new, the current incident is a big landmark in the cyberattack\r\nlandscape. Not only does it show that even reputable vendors may suffer from compromising of digital\r\ncertificates, but it raises many concerns about the software development infrastructure of all other software\r\ncompanies. ShadowPad, a powerful threat actor, previously concentrated on hitting one company at a time.\r\nCurrent research revealed at least four companies compromised in a similar manner, with three more suspected to\r\nhave been breached by the same attacker. How many more companies are compromised out there is not known.\r\nWhat is known is that ShadowPad succeeded in backdooring developer tools and, one way or another, injected\r\nmalicious code into digitally signed binaries, subverting trust in this powerful defense mechanism.\r\nDoes it mean that we should stop trusting digital signatures? No. But we definitely need to investigate all strange\r\nor anomalous behavior, even by trusted and signed applications. Software vendors should introduce another line in\r\ntheir software building conveyor that additionally checks their software for potential malware injections even after\r\nthe code is digitally signed.\r\nAt this unprecedented scale of operations, it is still a mystery why attackers reduced the impact by limiting\r\npayload execution to 600+ victims in the case of ASUS. We are also unsure who the ultimate victims were or\r\nwhere the attackers had collected the victims MAC addresses from. If you believe you are one of the victims, we\r\nrecommend checking your MAC address using this free tool or online check website. And if you discover that you\r\nhave been targeted by this operation, please email us at shadowhammer@kaspersky.com.\r\nWe will keep tracking the ShadowPad activities and inform you about new findings!\r\nIndicators of compromise\r\nC2 servers:\r\n103.19.3[.]17\r\n103.19.3[.]43\r\n103.19.3[.]44\r\n117.16.142[.]9\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 27 of 29\n\n23.236.77[.]175\r\n23.236.77[.]177\r\nMalware samples and trojanized files:\r\n02385ea5f8463a2845bfe362c6c659fa 915086d90596eb5903bcd5b02fd97e3e\r\n04fb0ccf3ef309b1cd587f609ab0e81e 943db472b4fd0c43428bfc6542d11913\r\n05eacf843b716294ea759823d8f4ab23 95b6adbcef914a4df092f4294473252f\r\n063ff7cc1778e7073eacb5083738e6a2 98908ce6f80ecc48628c8d2bf5b2a50c\r\n06c19cd73471f0db027ab9eb85edc607 9d86dff1a6b70bfdf44406417d3e068f\r\n0e1cc8693478d84e0c5e9edb2dc8555c a17cb9df43b31bd3dad620559d434e53\r\n0f49621b06f2cdaac8850c6e9581a594 a283d5dea22e061c4ab721959e8f4a24\r\n128cecc59c91c0d0574bc1075fe7cb40 a4b42c2c95d1f2ff12171a01c86cd64f\r\n17a36ac3e31f3a18936552aff2c80249 a76a1fbfd45ad562e815668972267c70\r\n1a0752f14f89891655d746c07da4de01 a96226b8c5599e3391c7b111860dd654\r\n1b95ac1443eb486924ac4d399371397c a9c750b7a3bbf975e69ef78850af0163\r\n1d05380f3425d54e4ddfc4bacc21d90e aa15eb28292321b586c27d8401703494\r\n1e091d725b72aed432a03a505b8d617e aac57bac5f849585ba265a6cd35fde67\r\n2ffc4f0e240ff62a8703e87030a96e39 aafe680feae55bb6226ece175282f068\r\n322cb39bc049aa69136925137906d855 abbb53e1b60ab7044dd379cf80042660\r\n343ad9d459f4154d0d2de577519fb2d3 abbd7c949985748c353da68de9448538\r\n36dd195269979e01a29e37c488928497 b042bc851cafd77e471fa0d90a082043\r\n3c0a0e95ccedaaafb4b3f6fd514fd087 b044cd0f6aae371acf2e349ef78ab39e\r\n496c224d10e1b39a22967a331f7de0a2 b257f366a9f5a065130d4dc99152ee10\r\n4b8d5ae0ad5750233dc1589828da130b b4abe604916c04fe3dd8b9cb3d501d3f\r\n4fb4c6da73a0a380c6797e9640d7fa00 b572925a7286355ac9ebb12a9fc0cc79\r\n5220c683de5b01a70487dac2440e0ecb b96bd0bda90d3f28d3aa5a40816695ed\r\n53886c6ebd47a251f11b44869f67163d c0116d877d048b1ba87c0de6fd7c3fb2\r\n55a7aa5f0e52ba4d78c145811c830107 c778fc8e816061420c537db2617e0297\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 28 of 29\n\n5855ce7c4a3167f0e006310eb1c76313 cdb0a09067877f30189811c7aea3f253\r\n5b6cd0a85996a7d47a8e9f8011d4ad3f d07e6abebcf1f2119622c60ad0acf4fa\r\n5eed18254d797ccea62d5b74d96b6795 d1ed421779c31df2a059fe0f91c24721\r\n6186b317c8b6a9da3ca4c166e68883ea d4c4813b21556dd478315734e1c7ae54\r\n63606c861a63a8c60edcd80923b18f96 dc15e578401ad9b8f72c4d60b79fdf0f\r\n63f2fe96de336b6097806b22b5ab941a dca86d2a9eb6dc53f549860f103486a9\r\n6ab5386b5ad294fc6ec4d5e47c9c2470 dd792f9185860e1464b4346254b2101b\r\n6b38c772b2ffd7a7818780b29f51ccb2 e7dcfa8e75b0437975ce0b2cb123dc7b\r\n6cf305a34a71b40c60722b2b47689220 e8db4206c2c12df7f61118173be22c89\r\n6e94b8882fe5865df8c4d62d6cff5620 ea3b7770018a20fc7c4541c39ea271af\r\n7d9d29c1c03461608bcab930fef2f568 eac3e3ece94bc84e922ec077efb15edd\r\n807d86da63f0db1fc746d1f0b05bc357 ecf865c95a9bec46aa9b97060c0e317d\r\n849a2b0dc80aeca3d175c139efe5221c ef43b55353a34be9e93160bb1768b1a6\r\n8505484efde6a1009f90fa02ca42f011 f0ba34be0486037913e005605301f3ce\r\n8578f0c7b0a14f129cc66ee236c58050 f2f879989d967e03b9ea0938399464ab\r\n86a4cac227078b9c95c560c8f0370bf0 f4edc757e9917243ce513f22d0ccacf2\r\n8756bafa7f0a9764311d52bc792009f9 f9d46bbffa1cbd106ab838ee0ccc5242\r\n87a8930e88e9564a30288572b54faa46 fa83ffde24f149f9f6d1d8bc05c0e023\r\n88777aacd5f16599547926a4c9202862 fa96e56e7c26515875214eec743d2db5\r\n8baa46d0e0faa2c6a3f20aeda2556b18 fb1473e5423c8b82eb0e1a40a8baa118\r\n8ef2d715f3a0a3d3ebc989b191682017 fcfab508663d9ce519b51f767e902806\r\n092ae9ce61f6575344c424967bd79437 7f05d410dc0d1b0e7a3fcc6cdda7a2ff\r\neb37c75369046fb1076450b3c34fb8ab\r\nSource: https://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nhttps://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/\r\nPage 29 of 29",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/"
	],
	"report_names": [
		"90380"
	],
	"threat_actors": [
		{
			"id": "1f3cf3d1-4764-4158-a216-dd6352e671bb",
			"created_at": "2022-10-25T15:50:23.837615Z",
			"updated_at": "2026-04-10T02:00:05.322197Z",
			"deleted_at": null,
			"main_name": "APT19",
			"aliases": [
				"APT19",
				"Codoso",
				"C0d0so0",
				"Codoso Team",
				"Sunshop Group"
			],
			"source_name": "MITRE:APT19",
			"tools": [
				"Cobalt Strike"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "1c97ccfd-1888-492c-b7b9-bb52c4c3809b",
			"created_at": "2023-01-06T13:46:38.940529Z",
			"updated_at": "2026-04-10T02:00:03.152806Z",
			"deleted_at": null,
			"main_name": "Operation ShadowHammer",
			"aliases": [],
			"source_name": "MISPGALAXY:Operation ShadowHammer",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "0639667a-fb3f-43d9-a38c-6c123fd19c7f",
			"created_at": "2022-10-25T16:07:23.335869Z",
			"updated_at": "2026-04-10T02:00:04.547702Z",
			"deleted_at": null,
			"main_name": "APT 19",
			"aliases": [
				"APT 19",
				"Bronze Firestone",
				"C0d0so0",
				"Checkered Typhoon",
				"Codoso",
				"Deep Panda",
				"G0009",
				"G0073",
				"Operation Kingslayer",
				"Red Pegasus",
				"Sunshop Group",
				"TG-3551"
			],
			"source_name": "ETDA:APT 19",
			"tools": [
				"Agentemis",
				"C0d0so0",
				"Cobalt Strike",
				"CobaltStrike",
				"Derusbi",
				"EmPyre",
				"EmpireProject",
				"Fire Chili",
				"PowerShell Empire",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "ba9fa308-a29a-4928-9c06-73aafec7624c",
			"created_at": "2024-05-01T02:03:07.981061Z",
			"updated_at": "2026-04-10T02:00:03.750803Z",
			"deleted_at": null,
			"main_name": "BRONZE RIVERSIDE",
			"aliases": [
				"APT10 ",
				"CTG-5938 ",
				"CVNX ",
				"Hogfish ",
				"MenuPass ",
				"MirrorFace ",
				"POTASSIUM ",
				"Purple Typhoon ",
				"Red Apollo ",
				"Stone Panda "
			],
			"source_name": "Secureworks:BRONZE RIVERSIDE",
			"tools": [
				"ANEL",
				"AsyncRAT",
				"ChChes",
				"Cobalt Strike",
				"HiddenFace",
				"LODEINFO",
				"PlugX",
				"PoisonIvy",
				"QuasarRAT",
				"QuasarRAT Loader",
				"RedLeaves"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "c7d9878a-e691-4c6f-81ae-84fb115a1345",
			"created_at": "2022-10-25T16:07:23.359506Z",
			"updated_at": "2026-04-10T02:00:04.556639Z",
			"deleted_at": null,
			"main_name": "APT 41",
			"aliases": [
				"BrazenBamboo",
				"Bronze Atlas",
				"Double Dragon",
				"Earth Baku",
				"G0096",
				"Grayfly",
				"Operation ColunmTK",
				"Operation CuckooBees",
				"Operation ShadowHammer",
				"Red Kelpie",
				"SparklingGoblin",
				"TA415",
				"TG-2633"
			],
			"source_name": "ETDA:APT 41",
			"tools": [
				"9002 RAT",
				"ADORE.XSEC",
				"ASPXSpy",
				"ASPXTool",
				"AceHash",
				"Agent.dhwf",
				"Agentemis",
				"AndroidControl",
				"AngryRebel",
				"AntSword",
				"BLUEBEAM",
				"Barlaiy",
				"BlackCoffee",
				"Bladabindi",
				"BleDoor",
				"CCleaner Backdoor",
				"CHINACHOPPER",
				"COLDJAVA",
				"China Chopper",
				"ChyNode",
				"Cobalt Strike",
				"CobaltStrike",
				"Crackshot",
				"CrossWalk",
				"CurveLast",
				"CurveLoad",
				"DAYJOB",
				"DBoxAgent",
				"DEADEYE",
				"DEADEYE.APPEND",
				"DEADEYE.EMBED",
				"DEPLOYLOG",
				"DIRTCLEANER",
				"DUSTTRAP",
				"Derusbi",
				"Destroy RAT",
				"DestroyRAT",
				"DodgeBox",
				"DragonEgg",
				"ELFSHELF",
				"EasyNight",
				"Farfli",
				"FunnySwitch",
				"Gh0st RAT",
				"Ghost RAT",
				"HDD Rootkit",
				"HDRoot",
				"HKDOOR",
				"HOMEUNIX",
				"HUI Loader",
				"HidraQ",
				"HighNoon",
				"HighNote",
				"Homux",
				"Hydraq",
				"Jorik",
				"Jumpall",
				"KEYPLUG",
				"Kaba",
				"Korplug",
				"LATELUNCH",
				"LOLBAS",
				"LOLBins",
				"LightSpy",
				"Living off the Land",
				"Lowkey",
				"McRAT",
				"MdmBot",
				"MessageTap",
				"Meterpreter",
				"Mimikatz",
				"MoonBounce",
				"MoonWalk",
				"Motnug",
				"Moudour",
				"Mydoor",
				"NTDSDump",
				"PACMAN",
				"PCRat",
				"PINEGROVE",
				"PNGRAT",
				"POISONPLUG",
				"POISONPLUG.SHADOW",
				"POTROAST",
				"PRIVATELOG",
				"PipeMon",
				"PlugX",
				"PortReuse",
				"ProxIP",
				"ROCKBOOT",
				"RbDoor",
				"RedDelta",
				"RedXOR",
				"RibDoor",
				"Roarur",
				"RouterGod",
				"SAGEHIRE",
				"SPARKLOG",
				"SQLULDR2",
				"STASHLOG",
				"SWEETCANDLE",
				"ScrambleCross",
				"Sensocode",
				"SerialVlogger",
				"ShadowHammer",
				"ShadowPad Winnti",
				"SinoChopper",
				"Skip-2.0",
				"SneakCross",
				"Sogu",
				"Speculoos",
				"Spyder",
				"StealthReacher",
				"StealthVector",
				"TERA",
				"TIDYELF",
				"TIGERPLUG",
				"TOMMYGUN",
				"TVT",
				"Thoper",
				"Voldemort",
				"WIDETONE",
				"WINNKIT",
				"WINTERLOVE",
				"Winnti",
				"WyrmSpy",
				"X-Door",
				"XDOOR",
				"XMRig",
				"XShellGhost",
				"Xamtrav",
				"ZXShell",
				"ZoxPNG",
				"certutil",
				"certutil.exe",
				"cobeacon",
				"gresim",
				"njRAT",
				"pwdump",
				"xDll"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "46a151bd-e4c2-46f9-aee9-ee6942b01098",
			"created_at": "2023-01-06T13:46:38.288168Z",
			"updated_at": "2026-04-10T02:00:02.911919Z",
			"deleted_at": null,
			"main_name": "APT19",
			"aliases": [
				"DEEP PANDA",
				"Codoso",
				"KungFu Kittens",
				"Group 13",
				"G0009",
				"G0073",
				"Checkered Typhoon",
				"Black Vine",
				"TEMP.Avengers",
				"PinkPanther",
				"Shell Crew",
				"BRONZE FIRESTONE",
				"Sunshop Group"
			],
			"source_name": "MISPGALAXY:APT19",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "04b07437-41bb-4126-bcbb-def16f19d7c6",
			"created_at": "2022-10-25T16:07:24.232628Z",
			"updated_at": "2026-04-10T02:00:04.906097Z",
			"deleted_at": null,
			"main_name": "Stone Panda",
			"aliases": [
				"APT 10",
				"ATK 41",
				"Bronze Riverside",
				"CTG-5938",
				"CVNX",
				"Cuckoo Spear",
				"Earth Kasha",
				"G0045",
				"G0093",
				"Granite Taurus",
				"Happyyongzi",
				"Hogfish",
				"ITG01",
				"Operation A41APT",
				"Operation Cache Panda",
				"Operation ChessMaster",
				"Operation Cloud Hopper",
				"Operation Cuckoo Spear",
				"Operation New Battle",
				"Operation Soft Cell",
				"Operation TradeSecret",
				"Potassium",
				"Purple Typhoon",
				"Red Apollo",
				"Stone Panda",
				"TA429",
				"menuPass",
				"menuPass Team"
			],
			"source_name": "ETDA:Stone Panda",
			"tools": [
				"Agent.dhwf",
				"Agentemis",
				"Anel",
				"AngryRebel",
				"BKDR_EVILOGE",
				"BKDR_HGDER",
				"BKDR_NVICM",
				"BUGJUICE",
				"CHINACHOPPER",
				"ChChes",
				"China Chopper",
				"Chymine",
				"CinaRAT",
				"Cobalt Strike",
				"CobaltStrike",
				"DARKTOWN",
				"DESLoader",
				"DILLJUICE",
				"DILLWEED",
				"Darkmoon",
				"DelfsCake",
				"Derusbi",
				"Destroy RAT",
				"DestroyRAT",
				"Ecipekac",
				"Emdivi",
				"EvilGrab",
				"EvilGrab RAT",
				"FYAnti",
				"Farfli",
				"Gen:Trojan.Heur.PT",
				"Gh0st RAT",
				"Ghost RAT",
				"GreetCake",
				"HAYMAKER",
				"HEAVYHAND",
				"HEAVYPOT",
				"HTran",
				"HUC Packet Transmit Tool",
				"Ham Backdoor",
				"HiddenFace",
				"Impacket",
				"Invoke the Hash",
				"KABOB",
				"Kaba",
				"Korplug",
				"LODEINFO",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"MiS-Type",
				"Mimikatz",
				"Moudour",
				"Mydoor",
				"NBTscan",
				"NOOPDOOR",
				"Newsripper",
				"P8RAT",
				"PCRat",
				"PlugX",
				"Poison Ivy",
				"Poldat",
				"PowerSploit",
				"PowerView",
				"PsExec",
				"PsList",
				"Quarks PwDump",
				"Quasar RAT",
				"QuasarRAT",
				"RedDelta",
				"RedLeaves",
				"Rubeus",
				"SNUGRIDE",
				"SPIVY",
				"SharpSploit",
				"SigLoader",
				"SinoChopper",
				"SodaMaster",
				"Sogu",
				"TIGERPLUG",
				"TVT",
				"Thoper",
				"Trochilus RAT",
				"UpperCut",
				"Vidgrab",
				"WinRAR",
				"WmiExec",
				"Wmonder",
				"Xamtrav",
				"Yggdrasil",
				"Zlib",
				"certutil",
				"certutil.exe",
				"cobeacon",
				"dfls",
				"lena",
				"nbtscan",
				"pivy",
				"poisonivy",
				"pwdump"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "ba3fff0c-3ba0-4855-9eeb-1af9ee18136a",
			"created_at": "2022-10-25T15:50:23.298889Z",
			"updated_at": "2026-04-10T02:00:05.316886Z",
			"deleted_at": null,
			"main_name": "menuPass",
			"aliases": [
				"menuPass",
				"POTASSIUM",
				"Stone Panda",
				"APT10",
				"Red Apollo",
				"CVNX",
				"HOGFISH",
				"BRONZE RIVERSIDE"
			],
			"source_name": "MITRE:menuPass",
			"tools": [
				"certutil",
				"FYAnti",
				"UPPERCUT",
				"SNUGRIDE",
				"P8RAT",
				"RedLeaves",
				"SodaMaster",
				"pwdump",
				"Mimikatz",
				"PlugX",
				"PowerSploit",
				"ChChes",
				"cmd",
				"QuasarRAT",
				"AdFind",
				"Cobalt Strike",
				"PoisonIvy",
				"EvilGrab",
				"esentutl",
				"Impacket",
				"Ecipekac",
				"PsExec",
				"HUI Loader"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434460,
	"ts_updated_at": 1775826773,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d244fb95c84cc481e8c1313e7462625b22cf346c.pdf",
		"text": "https://archive.orkl.eu/d244fb95c84cc481e8c1313e7462625b22cf346c.txt",
		"img": "https://archive.orkl.eu/d244fb95c84cc481e8c1313e7462625b22cf346c.jpg"
	}
}