{
	"id": "e7f76385-08a3-43b0-9ebd-1f0e070a9ffe",
	"created_at": "2026-04-06T01:32:33.373747Z",
	"updated_at": "2026-04-10T03:21:30.260839Z",
	"deleted_at": null,
	"sha1_hash": "68bf06d7d495c06cc0396c86301f68e80c9a72ab",
	"title": "Veletrix Loader Infection: A Look from a Digital Forensic Perspective - 0x0d4y Malware Research",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2407333,
	"plain_text": "Veletrix Loader Infection: A Look from a Digital Forensic\r\nPerspective - 0x0d4y Malware Research\r\nBy 0x0d4y\r\nPublished: 2025-08-18 · Archived: 2026-04-06 00:37:31 UTC\r\nThis analysis serves as a complementary study to my previous research on the reverse engineering of Veletrix\r\nLoader and the infrastructure analysis of the China-nexus threat actor operating this campaign. In this post, I’ll\r\nexamine the Veletrix Loader infection from a digital forensics perspective, analyzing volatile memory captured\r\nfrom an infected system.\r\nThe rationale behind this approach lies in the additional detection capabilities that memory forensics can provide,\r\nparticularly when malware employs sophisticated evasion techniques such as shellcode injection and execution\r\nthrough DLL Side-Loading of legitimate software – in this case, Wondershare software.\r\nOur reverse engineering findings establish a foundation for what digital forensics analysts should investigate when\r\nexamining systems exhibiting similar infection patterns. This cross-disciplinary approach ensures that our threat\r\nresearch delivers actionable intelligence for DFIR practitioners, ultimately strengthening the defensive capabilities\r\nacross both malware analysis and incident response domains.\r\nBy bridging the gap between malware reverse engineering and digital forensics, we aim to provide comprehensive\r\ndetection methodologies that enhance the overall security posture against advanced persistent threats employing\r\nsuch sophisticated techniques.\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 1 of 12\n\nBelow you can see the flow of my analysis.\r\nMethodology and Evidence Collection\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 2 of 12\n\nOur forensic evidence (Memory Dump) consists of a memory dump obtained from a Windows 10 Professional\r\nvirtual machine environment. The infection scenario was replicated by executing the Wondershare DLL Side-Loading attack vector, followed by immediate capture of the system’s volatile memory to preserve the malware’s\r\nruntime artifacts.\r\nThe memory acquisition process was performed using VirtualBox management tools with the following sequence\r\nof commands:\r\n# Pause the virtual machine to preserve memory state\r\n\u0026 \"C:\\Program Files\\Oracle\\VirtualBox\\VBoxManage.exe\" controlvm \"Windows10\" pause\r\n# Extract the complete memory dump\r\n\u0026 \"C:\\Program Files\\Oracle\\VirtualBox\\VBoxManage.exe\" debugvm \"Windows10\" dumpvmcore --filename \"C:\\Users\\0x0d4y\r\nBelow you can see the integrity of the evidence, through the SHA256 hash. This dump it will be in my Github, so\r\nyou can validate the checksum.\r\n# Generate cryptographic hash for evidence integrity\r\nGet-FileHash \"C:\\Users\\0x0d4y\\Desktop\\Research\\Malware-Research\\China-Nexus\\Veletrix\\infection_veletrix.mem\" -Al\r\nAlgorithm: SHA256\r\nHash: FAA50B87AEDB603CB2A3F8EE0D88DAB9ADF317E8D5A3A4534E108AADB993FA45\r\nPath: C:\\Users\\0x0d4y\\Desktop\\Research\\Malware-Research\\China-Nexus\\Veletrix\\infection_veletrix.mem\r\nWith our forensic evidence properly collected and verified, we proceed to analyze the memory dump using the\r\nVolatility Framework to identify malicious artifacts and behavioral indicators consistent with our reverse\r\nengineering findings.\r\nBelow we can see the output of the verification of the memory dump collected.\r\nVolatility 3 Framework 2.26.0\r\nProgress: 100.00 PDB scanning finished\r\nVariable Value\r\nKernel Base 0xf80547e00000\r\nDTB 0x1aa000\r\nSymbols file:///C:/Users/0x0d4y/AppData/Local/Programs/Python/Python313/Lib/site-packages/volatility3/symbols/wi\r\nIs64Bit True\r\nIsPAE False\r\nlayer_name 0 WindowsIntel32e\r\nmemory_layer 1 Elf64Layer\r\nbase_layer 2 FileLayer\r\nKdVersionBlock 0xf80548a0f398\r\nMajor/Minor 15.19041\r\nMachineType 34404\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 3 of 12\n\nKeNumberProcessors 4\r\nSystemTime 2025-08-12 16:09:22+00:00\r\nNtSystemRoot C:\\Windows\r\nNtProductType NtProductWinNt\r\nNtMajorVersion 10\r\nNtMinorVersion 0\r\nPE MajorOperatingSystemVersion 10\r\nPE MinorOperatingSystemVersion 0\r\nPE Machine 34404\r\nWith this, let’s start our analysis.\r\nIdentification of Malicious Process\r\nThe first step to begin a more in-depth analysis is to identify a target process for our analysis. Below, we can\r\neasily see this target, simply by the binary name, which completely deviates from the standards of the others with\r\nPID 1724.\r\nBut of course, we can look for other indicators that this process is suspicious, to ensure we’ve chosen the correct\r\nprocess for our analysis. Fortunately, when we identified processes that were making connections, we observed\r\nthe same process with PID 1724 making a connection to IPv4 address 62.234.24.38, on TCP port 9999.\r\nWell, the high TCP port itself is suspicious, but if we go back to the research we did previously, or if we just throw\r\nthis IPv4 address into VirusTotal, we will validate the indicator of compromise being the process with PID 1724.\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 4 of 12\n\nDiving Deeper into Windows Memory\r\nNow we’ll delve deeper into the Windows memory dump to identify the details of this infection, such as the\r\ndetection, extraction, and analysis of malicious code directly from memory. Therefore, let’s start with the DLLs\r\nimported and used by the binary of the malicious process with PID 1724. Below, we can see that the process\r\nimports several standard libraries, but four are noteworthy because they are located within the same directory as\r\nthe main binary (delivered via Phishing).\r\nThey’re noteworthy simply because they contain DLLs within the main binary directory, but the drstat.dll DLL is\r\nthe prime suspect, as the others are known to be standard libraries for the Visual Studio C++ Runtime. To validate\r\nthis information, we simply need to look at the APIs that process PID 1724 imported when it ran. All functions\r\nrelated to the MSVCP140 and VCRUNTIME140 DLLs are standard, but those in drstat.dll are noteworthy\r\nbecause they’re unusual.\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 5 of 12\n\nTo validate our suspicion, we simply need to extract the drstat.dll DLL artifact to conduct reverse engineering to\r\nvalidate the artifact’s maliciousness.\r\nWhen opening the PE extracted from the memory dump using Volatility, when checking the Exports (since it was\r\na DLL) it is possible to observe that all Exports had the same address, except for the dr_data_stop Export.\r\nIf we access every Export that points to the same address, we will find a dead function, which just returns 0.\r\nBelow, you can see that the dr_data_stop function, specifically, contains malicious code identified in my latest\r\nresearch. In this example, we’re viewing the snippet of malicious code responsible for dynamically loading\r\nkernel32.dll and certain APIs required for shellcode decryption, allocation, and execution in memory.\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 6 of 12\n\nTo validate the existence of this code in the infected system’s memory, we can use volshell.exe to print the\r\nDisassembly code from the previously identified address, and thus, we can observe the exact code described in the\r\nprevious image using Binary Ninja.\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 7 of 12\n\nWell, we already know that the drstat.dll DLL loaded via DLL-Sideloading is malicious, and that through the\r\ndr_data_stop function, the malware loads kernel32.dll and certain APIs to decrypt shellcode and execute it in\r\nmemory. Therefore, now we need to detect the shellcode in memory, which is responsible for connecting to the\r\npreviously identified C\u0026C server.\r\nTo do this, we need to take a deeper look at VADs. VADs (Virtual Address Descriptors) are Windows data\r\nstructures that describe regions of virtual memory allocated to each process, including permissions, protection\r\ntype, and commit status. Therefore, if we only look for regions with Execute permission, we won’t get anywhere,\r\nas only the regions containing DLLs have such permissions. However, by looking at the number of pages reserved\r\nfor use, that is, the number of Committed regions in a VAD, we can observe that a specific region contains a\r\nsignificant number with this characteristic, different from the remaining VADs for that process, serving as an\r\nanomaly indicator.\r\nSo let’s extract this VAD to statically analyze it through reverse engineering.\r\nBy opening the suspicious data block extracted from the memory dump, we can quickly identify the shellcode.\r\nBelow, we can see a snippet of code that implements the LoadLibrary API’s hashing technique to dynamically\r\nload the DLLs user32.dll, ws2_32.dll, and others.\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 8 of 12\n\nAlso in this same code snippet, we can observe the IPv4 address identified previously, which is the address of the\r\nC\u0026C server that will be contacted.\r\nAlso using Volshell, we can detect exactly the code snippets described in the images above, with the aim of\r\nvalidating their presence in the memory dump, as we can see in the sequence of images below.\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 9 of 12\n\nTherefore, we can observe that through forensic analysis of a memory dump from an infected system (in this case,\r\nby Veletrix Loader), combined with reverse engineering of artifacts extracted directly from the memory dump, we\r\ncan arrive at the same analysis result, however, through the perspective of a DFIR Analyst.\r\nThe Importance of Threat Intelligence\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 10 of 12\n\nAnd this is a good case where quality threat intelligence takes on significant importance. In this analysis, I\r\npretended not to have the Yara rules at my disposal, trying to reach the same conclusion I reached when I had the\r\nmalware itself on hand to reverse engineer it.\r\nBelow, we can see how much the use of Yara rules would automate our time, but a DFIR Analyst does not always\r\nhave this at their disposal, and therefore, the analyst is required to have expertise in identifying, analyzing and\r\nextracting malicious code, and from this analysis, extracting intelligence.\r\nFinal Conclusion\r\nThis deepening of the memory forensic analysis perspective allows us to understand the same threat, but from a\r\ndifferent perspective that enriches the overall context surrounding this threat. I believe I will incorporate these\r\nanalyses whenever possible in future researches.\r\nWith this perspective, in addition to identifying the patterns identified during reverse engineering, we are also able\r\nto extract unique patterns from this analysis, which can help in categorizing the Tactics, Techniques, and\r\nProcedures identified during the analysis, and thus enrich the intelligence produced about this campaign.\r\nTactics Technique Details Observed in the Analysis\r\nInitial\r\nAccess\r\nSpearphishing\r\nAttachment\r\n[T1566.001]\r\nThe Threat Actor delivers, through Spear Phishing, a\r\nZIP file targeted at the Telecom company context,\r\ncontaining benign software from Wondershare,\r\nwhich, when executed by the user, executes the\r\nmalicious DLL that was placed by the adversary,\r\nexecuting the DLL Side-Loading technique.\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 11 of 12\n\nTactics Technique Details Observed in the Analysis\r\nExecution\r\nUser\r\nExecution: Malicious\r\nFile\r\n[T1204.002]\r\nUpon receiving Spear Phishing, the victim is tricked\r\ninto executing the payload delivered to them.\r\nDefense\r\nEvasion\r\nEmbedded Payloads\r\n[T1027.009]\r\nInside the Malicious DLL, it contains an encrypted\r\npayload, which is the Veletrix Loader Shellcode.\r\nDefense\r\nEvasion\r\nDynamic API\r\nResolution\r\n[T1027.007]\r\nBoth the malicious DLL and Shellcode implement\r\nthis technique to evade static detection of their\r\ncapabilities.\r\nDefense\r\nEvasion\r\nProcess Injection\r\n[T1055]\r\nTo be executed by the benign PE, the malicious DLL\r\ninjects a Shellcode that will initiate communication\r\nwith the C\u0026C server.\r\nDefense\r\nEvasion\r\nEncrypted/Encoded\r\nFile\r\n[T1027.013]\r\nThe Shellcode present in the malicious DLL is\r\nencrypted and obfuscated using the IPV4Fuscated\r\ntechnique.\r\nCommand\r\nand Control\r\nNon-Standard Port\r\n[T1571]\r\nShellcode Communicates with the C\u0026C Server via\r\nTCP Protocol on port TCP/9999.\r\nCommand\r\nand Control\r\nIngress Tool Transfer\r\n[T1105]\r\nShellcode connects to the C\u0026C Server to download\r\nand execute in VShell memory\r\nI hope you, the reader, enjoyed this new perspective on Veletrix Loader research. Until next time!\r\nSource: https://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nhttps://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://0x0d4y.blog/veletrix-loader-infection-a-look-from-a-digital-forensic-perspective/"
	],
	"report_names": [
		"veletrix-loader-infection-a-look-from-a-digital-forensic-perspective"
	],
	"threat_actors": [],
	"ts_created_at": 1775439153,
	"ts_updated_at": 1775791290,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/68bf06d7d495c06cc0396c86301f68e80c9a72ab.pdf",
		"text": "https://archive.orkl.eu/68bf06d7d495c06cc0396c86301f68e80c9a72ab.txt",
		"img": "https://archive.orkl.eu/68bf06d7d495c06cc0396c86301f68e80c9a72ab.jpg"
	}
}