{ "id": "4c1e8f59-69b5-44aa-923d-ff21e8abcf41", "created_at": "2026-04-06T00:14:25.166856Z", "updated_at": "2026-04-10T03:32:49.912899Z", "deleted_at": null, "sha1_hash": "4a55053fb7fabe3d473418c96d93f087e9dd20d5", "title": "C/C++ Runtime Library Code Tampering in Supply Chain", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 276637, "plain_text": "C/C++ Runtime Library Code Tampering in Supply Chain\r\nBy By: Mohamad Mokbel Apr 22, 2019 Read time: 8 min (2105 words)\r\nPublished: 2019-04-22 · Archived: 2026-04-05 20:23:54 UTC\r\nFor the past few years, the security industry’s very backbone — its key software and server components — has\r\nbeen the subject of numerous attacks through cybercriminals’ various works of compromise and modifications.\r\nSuch attacks involve the original software’s being compromised via malicious tampering of its source code, its\r\nupdate server, or in some cases, both. In either case, the intention is to always get into the network or a host of a\r\ntargeted entity in a highly inconspicuous fashion — which is known as a supply chain attack. Depending on the\r\nattacker’s technical capabilities and stealth motivation, the methods used in the malicious modification of the\r\ncompromised software vary in sophistication and astuteness.\r\nFour major methods have been observed in the wild:\r\n1. The injection of malicious code at the source code level of the compromised software, for native or\r\ninterpreted/just-in-time compilation-based languages such as C/++, Java, and .NET.\r\n2. The injection of malicious code inside C/C++ compiler runtime (CRT) libraries, e.g., poisoning of specific\r\nC runtime functions.\r\n3. Other less intrusive methods, which include the compromise of the update server such that instead of\r\ndeploying a benign updated version, it serves a malicious implant. This malicious implant can come from\r\nthe same compromised download server or from another completely separate server that is under the\r\nattacker’s control.\r\n4. The repackaging of legitimate software with a malicious implant. Such trojanized software is either hosted\r\non the official yet compromised website of a software company or spread via BitTorrent or other similar\r\nhosting zones.\r\nThis blog post will explore and attempt to map multiple known supply chain attack incidents that have happened\r\nin the last decade through the four methods listed above. The focus will be on Method 2, whereby a list of all\r\npoisoned C/C++ runtime functions will be provided, each mapped to its unique malware family. Furthermore, the\r\nShadowPad incident is taken as a test case, documenting how such poisoning happens.\r\nMethods 1 and 2 stand out from the other methods because of the nature of their operation, which is the intrusive\r\nand more subtle tampering of code — they are a category in their own right. However, Method 2 is far more\r\ninsidious since any tampering in the code is not visible to the developer or any source code parser; the malicious\r\ncode is introduced at the time of compilation/linking.\r\nExamples of attacks that used a combination of Methods 1 and 3 are:\r\nThe trojanization of MediaGet, a BitTorrent client, via a poisoned update (mid-February 2018). The change\r\nemployed involved a malicious update component and a trojanized copy of the file mediaget.exe.\r\nThe Nyetya/MeDoc attack on M.E.Doc, an accounting software by Intellect Service, which delivered the\r\ndestructive ransomware Nyetya/NotPetya by manipulating its update system (April 2017). The change\r\nhttps://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html\r\nPage 1 of 8\n\nemployed involved backdooring of the .NET module ZvitPublishedObjects.dll.\r\nThe KingSlayer attack on EventID, which resulted in the compromise of the Windows Event Log Analyzer\r\nsoftware’s source code (service executable in .NET) and update server (March 2015).\r\nAn example of an attack that solely made use of Method 3 is the Monju incident, which involved the compromise\r\nof the update server for the media player GOM Player by GOMLab and resulted in the distribution of a variant of\r\nGh0st RAT toward specific targets (December 2013).\r\nFor Method 4, we have the Havex incidents, which involved the compromise of multiple industrial control system\r\n(ICS) websites and software installers (different dates in 2013 and 2014).\r\nExamples of attacks that used a combination of Methods 2 and 3 are:\r\nOperation ShadowHammer, which involved the compromise of a computer vendor’s update server to target\r\nan unknown set of users based on their network adapters’ media access control (MAC) addresses (June\r\n2018). The change employed involved a malicious update component.\r\nAn attack on the gaming industry (Winnti.A), which involved the compromise of three gaming companies\r\nand the backdooring of their respective main executables (publicized in March 2019).\r\nThe CCleaner case, which involved the compromise of Piriform, resulting in the backdooring of the\r\nCCleaner software (August 2017).\r\nThe ShadowPad casenews- cybercrime-and-digital-threats, which involved the compromise of NetSarang\r\nComputer, Inc., resulting in the backdooring of all of the company’s products (July 2017). The change\r\nemployed involved malicious code that was injected into the library nssock2.dll, which was used by all of\r\nthe company’s products.\r\nMethods 2 and 3 were also used by the Winnti group, which targeted the online video game industry,\r\ncompromising multiple companies’ update servers in an attempt to spread malicious implants or libraries using the\r\nAheadLib tool (2011).\r\nAnother example is the XcodeGhost incident (September 2015), in which Apple’s Xcode integrated development\r\nenvironment (IDE) and the compiler’s CoreServices Mach-O object file were modified to include malware that\r\nwould infect every iOS app built (via the linker) with the trojanized Xcode IDE. The trojanized version was\r\nhosted on multiple Chinese file sharing services, resulting in hundreds of trojanized apps’ landing on the iOS App\r\nStore unfettered.\r\nAn interesting case that shows a different side to the supply chain attack methods is the event-stream incident\r\n(November 2018). Event-stream is one of the widely used packages by npm (Node.js package manager), a\r\npackage manager for the JavaScript programming language. A package known as flatmap-stream was added as a\r\ndirect dependency to the event-stream package. The original author/maintainer of the event-stream package\r\ndelegated publishing rights to another person, who then added the malicious flatmap-stream package. This\r\nmalicious package targeted specific developers working on the release build scripts of the bitcoin wallet app\r\nCopay, all for the purpose of stealing bitcoins. The malicious code got written into the app when the build scripts\r\nwere executed, thereby adding another layer of covertness.\r\nhttps://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html\r\nPage 2 of 8\n\nIn most supply chain attack cases that have been happening for almost a decade, the initial infection vector is\r\nunknown or at least not publicly documented. Moreover, the particulars of how the malicious code gets injected\r\ninto the benign software codebase are not documented either, whether from a forensics or a tactics, techniques,\r\nand procedures (TTP) standpoint. However, we will attempt to show how Method 2, which employs sophisticated\r\ntampering of code and is harder to detect, is used by attackers in a supply chain attack, using the ShadowPad case\r\nas our sample for analysis.\r\nAn In-Depth Analysis of Method 2 – Case Study: ShadowPad\r\nThere are subtle differences and observations between tampering with the original source code, as in Method 1,\r\nand tampering with the C/C++ runtime libraries, as in Method 2. Depending on the nature and location of the\r\nchanges, the former might be easier to spot, whereas the latter would be much harder to detect if no file\r\nmonitoring and integrity checks had been in place.\r\nAll of the reported cases where the C/C++ runtime time libraries are poisoned or modified are for Windows\r\nbinaries.  Each case has been statically compiled with the Microsoft Visual C/C++ compiler with varying linker\r\nversions. Additionally, all of the poisoned functions are not part of the actual C/C++ standard libraries, but are\r\nspecific to Microsoft Visual C/C++ compiler runtime initialization routines. Table 1 shows the list of all known\r\nmalware families with their tampered runtime functions.\r\nMalware Family Poisoned Microsoft Visual C/C++ Runtime Functions\r\nShadowHammer\r\n__crtExitProcess(UINT uExitCode) // exits the process. Checks if it’s part of\r\na managed app // it is a CRT wrapper for ExitProcess\r\nGaming industry\r\n(HackedApp.Winnti.A)\r\n__scrt_common_main_seh(void) // entrypoint of the c runtime library\r\n(_mainCRTStartup) with support for structured exception handling which\r\ncalls the program’s main() function\r\nCCleaner\r\nStage 1: __scrt_common_main_seh(void)\r\nStage 2 -\u003e dropped(32- bit) _security_init_cookie()\r\nStage 2 -\u003e dropped (64- bit) _security_init_cookie()\r\nvoid __security_init_cookie(void); // Initializes the global security cookie //\r\nused for buffer overflow protection\r\nShadowPad\r\n_initterm(_PVFV * pfbegin, _PVFV * pfend); // call entries in function\r\npointer table // The entry (0x1000E600) is the malicious one\r\nTable 1. List of poisoned/modified Microsoft Visual CRT functions in supply chain attacks\r\nIt’s the linker’s responsibility to include the necessary CRT library for providing the startup code. However, a\r\ndifferent CRT library could be specified via an explicit linker flag. Otherwise, the default statically linked CRT\r\nlibrary libcmt.lib, or another, is used. The startup code performs various environment setup operations prior to\r\nexecuting the program’s main() function. Such operations include exception handling, thread data initialization,\r\nhttps://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html\r\nPage 3 of 8\n\nprogram termination, and cookie initialization. It’s important to note that the CRT implementation is compiler-,\r\ncompiler option-, compiler version-, and platform-specific.\r\nMicrosoft used to ship the Visual C runtime library headers and compilation files that developers could build\r\nthemselves. For example, for Visual Studio 2010, such headers would exist under “Microsoft Visual Studio\r\n10.0\\VC\\crt”, and the actual implementation of the ShadowPad poisoned function _initterm() would reside inside\r\nthe file crt0dat.c as follows (all comments were omitted for readability purposes):\r\nThis internal function is responsible for walking a table of function pointers (skipping null entries) and initializing\r\nthem. It’s called only during the initialization of a C++ program. The poisoned DLL nssock2.dll is written in the\r\nC++ language.\r\nThe argument pfbegin points to the first valid entry on the table, while pfend points to the last valid entry. The\r\ndefinition of the function type _PVFV is inside the CRT file internal.h:\r\nThe above function is defined in the crt0dat.c file. The object file crt0dat.obj resides inside the library file\r\nlibcmt.lib.\r\nFigure 1 shows ShadowPad’s implementation of _initterm().\r\nhttps://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html\r\nPage 4 of 8\n\nFigure 1. ShadowPad poisoned _initterm() runtime function\r\nFigure 2 shows the function pointer table for ShadowPad’s _initterm() function as pointed to by pfbegin and\r\npfend. This table is used for constructing objects at the beginning of the program particularly for calling C++\r\nconstructors, which is what’s happening in the screenshot below.\r\nFigure 2. Function pointer table for ShadowPad poisoned _initterm() runtime function\r\nAs shown in Figure 2, the function pointer entry labeled malicious_code at the virtual address 0x1000F6A0 has\r\nbeen poisoned to point to a malicious code (0x1000E600). It’s more accurate to say that it is the function pointer\r\ntable that was poisoned rather than the function _initterm().\r\nFigure 3 shows the cross-reference graph of the _initterm() CRT function as referenced by the compiled\r\nShadowPad code. The graph shows all call paths (reachability) that lead to it, and all other calls it makes itself.\r\nThe actual call path that leads to executing the ShadowPad code is:\r\nDllEntryPoint() -\u003e __DllmainCRTStartup() -\u003e _CRT_INIT() -\u003e _initterm() -\u003e __imp_initterm() -\u003e\r\nmalicious_code() via function pointer table.\r\nhttps://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html\r\nPage 5 of 8\n\nFigure 3. Call cross-reference graph for ShadowPad poisoned _initterm() runtime function\r\nNote that the internal function _initterm() is called from within the CRT initialization function __CRT_INIT(),\r\nwhich is responsible for C++ DLL initialization and has the following prototype:\r\nOne of its responsibilities is invoking the C++ constructors for the C++ code in the DLL nssock2.dll, as\r\ndemonstrated earlier. The said function is implemented inside the CRT file crtdll.c -\u003e object file crtdll.obj -\u003e\r\nlibrary file msvcrt.lib.\r\nThe following code snippet shows the actual implementation of the function _CRT_INIT().\r\nhttps://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html\r\nPage 6 of 8\n\nSo, how could an attacker poison any of those CRT functions? It’s possible to overwrite the original benign\r\nlibcmt.lib/msvcrt.lib library with a malicious one, or modify the linker flag such that it points to a malicious\r\nlibrary file. Another possibility is by hijacking the linking process such that as the linker is resolving all references\r\nto  various functions, the attacker’s tool monitors this process, intercepts it, and feeds it a poisoned function\r\ndefinition instead. The backdooring of the compiler’s key executables, such as the linker binary itself, can be\r\nanother stealthy poisoning vector.\r\nConclusion\r\nAlthough the attacks for Method 2 are very low in number, difficult to predict, and possibly targeted, when one\r\ntakes place, it can be likened to a black swan event: It will catch victims off guard and its impact will be\r\nwidespread and catastrophic.\r\nTampering with CRT library functions in supply chain attacks is a real threat that requires further attention from\r\nthe security community, especially when it comes to the verification and validation of the integrity of development\r\nand build environments.\r\nSteps could be taken to ensure clean software development and build environments. Maintaining and cross-validating the integrity of the source code and all compiler libraries and binaries are good starting points. The use\r\nhttps://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html\r\nPage 7 of 8\n\nof third-party libraries and code must be vetted and scanned for any malicious indicators prior to integration and\r\ndeployment. Proper network segmentation is also essential for separating critical assets in the build and\r\ndistribution (update servers) environments from the rest of the network. Important as well is the enforcement of\r\nvery strict access with multifactor authentication to the release build servers and endpoints. Of course, these steps\r\ndo not exclude or relinquish the developers themselves from the responsibility of continuously monitoring the\r\nsecurity of their systems.\r\nSource: https://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html\r\nhttps://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.trendmicro.com/en_us/research/19/d/analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html" ], "report_names": [ "analyzing-c-c-runtime-library-code-tampering-in-software-supply-chain-attacks.html" ], "threat_actors": [ { "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": "5bbced13-72f7-40dc-8c41-dcce75bf885e", "created_at": "2022-10-25T15:50:23.695735Z", "updated_at": "2026-04-10T02:00:05.335976Z", "deleted_at": null, "main_name": "Winnti Group", "aliases": [ "Winnti Group" ], "source_name": "MITRE:Winnti Group", "tools": [ "PipeMon", "Winnti for Windows", "PlugX" ], "source_id": "MITRE", "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": "4d5f939b-aea9-4a0e-8bff-003079a261ea", "created_at": "2023-01-06T13:46:39.04841Z", "updated_at": "2026-04-10T02:00:03.196806Z", "deleted_at": null, "main_name": "APT41", "aliases": [ "WICKED PANDA", "BRONZE EXPORT", "Brass Typhoon", "TG-2633", "Leopard Typhoon", "G0096", "Grayfly", "BARIUM", "BRONZE ATLAS", "Red Kelpie", "G0044", "Earth Baku", "TA415", "WICKED SPIDER", "HOODOO", "Winnti", "Double Dragon" ], "source_name": "MISPGALAXY:APT41", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "945a572f-ebe3-4e2f-a288-512fe751cfa8", "created_at": "2022-10-25T16:07:24.413971Z", "updated_at": "2026-04-10T02:00:04.97924Z", "deleted_at": null, "main_name": "Winnti Group", "aliases": [ "G0044", "Leopard Typhoon", "Wicked Panda", "Winnti Group" ], "source_name": "ETDA:Winnti Group", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "FunnySwitch", "RbDoor", "RibDoor", "RouterGod", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null }, { "id": "2a24d664-6a72-4b4c-9f54-1553b64c453c", "created_at": "2025-08-07T02:03:24.553048Z", "updated_at": "2026-04-10T02:00:03.787296Z", "deleted_at": null, "main_name": "BRONZE ATLAS", "aliases": [ "APT41 ", "BARIUM ", "Blackfly ", "Brass Typhoon", "CTG-2633", "Earth Baku ", "GREF", "Group 72 ", "Red Kelpie ", "TA415 ", "TG-2633 ", "Wicked Panda ", "Winnti" ], "source_name": "Secureworks:BRONZE ATLAS", "tools": [ "Acehash", "CCleaner v5.33 backdoor", "ChinaChopper", "Cobalt Strike", "DUSTPAN", "Dicey MSDN", "Dodgebox", "ForkPlayground", "HUC Proxy Malware (Htran)" ], "source_id": "Secureworks", "reports": null }, { "id": "5cbf6c32-482d-4cd2-9d11-0d9311acdc28", "created_at": "2023-01-06T13:46:38.39927Z", "updated_at": "2026-04-10T02:00:02.958273Z", "deleted_at": null, "main_name": "ENERGETIC BEAR", "aliases": [ "BERSERK BEAR", "ALLANITE", "Group 24", "Koala Team", "G0035", "ATK6", "ITG15", "DYMALLOY", "TG-4192", "Crouching Yeti", "Havex", "IRON LIBERTY", "Blue Kraken", "Ghost Blizzard" ], "source_name": "MISPGALAXY:ENERGETIC BEAR", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434465, "ts_updated_at": 1775791969, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/4a55053fb7fabe3d473418c96d93f087e9dd20d5.pdf", "text": "https://archive.orkl.eu/4a55053fb7fabe3d473418c96d93f087e9dd20d5.txt", "img": "https://archive.orkl.eu/4a55053fb7fabe3d473418c96d93f087e9dd20d5.jpg" } }