{
	"id": "9e3be561-a834-4b5c-9954-db9fd40b3b31",
	"created_at": "2026-04-06T00:08:14.637425Z",
	"updated_at": "2026-04-10T13:12:51.804101Z",
	"deleted_at": null,
	"sha1_hash": "c8f6666ccfb3ea890b92758003ae243da3927846",
	"title": "RegPhantom Backdoor Threat Analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1995136,
	"plain_text": "RegPhantom Backdoor Threat Analysis\r\nBy Pierre-Henri Pezier\r\nPublished: 2026-03-30 · Archived: 2026-04-05 22:19:53 UTC\r\nExecutive Summary\r\nThis report analyzes RegPhantom, a stealthy Windows kernel rootkit designed to give attackers code execution in kernel\r\nmode while leaving very little visible evidence behind. The malware abuses the Windows registry as a covert trigger\r\nmechanism: a usermode process can send an encrypted command through a registry write, which the driver intercepts and\r\nturns into arbitrary kernel-mode code execution.\r\nWhat makes this threat notable is the combination of stealth, privilege, and trust abuse. The driver runs as a signed kernel\r\ncomponent, allowing it to operate at the highest privilege level on Windows systems. It does not rely on normal driver\r\nloading behavior for its payloads and instead reflectively maps code into kernel memory, making the loaded module\r\ninvisible to standard tools that enumerate drivers. It also blocks the triggering registry write, wipes executed payload\r\nmemory, and stores hook pointers in encoded form, which significantly reduces forensic visibility.\r\nOur analysis further shows that this is not an isolated sample. Multiple related binaries were identified across several\r\nmonths, including versions signed with valid certificates issued to Chinese companies. Combined with sample timeline\r\npatterns, submission history, and shared development traits, this supports an assessment of active maintenance by a China-nexus threat actor with moderate confidence.\r\nFor defenders, RegPhantom is dangerous because it enables kernel-level execution from an unprivileged usermode context\r\nand is built specifically to avoid common detection and triage methods. Traditional artifact-based investigation is unlikely to\r\nbe sufficient. Detection should focus primarily on the driver binary itself, related signed samples, and the underlying code\r\npatterns shared across this malware family.\r\nTechnical Overview\r\nThis report presents the analysis of a Windows kernel driver ( .sys ) signed with a Microsoft-trusted code-signing\r\ncertificate, operating as a rootkit, which we track as RegPhantom. The driver establishes a covert usermode-to-kernel code\r\nexecution pipeline by leveraging the Windows registry as a communication channel: an unprivileged usermode process\r\nwrites an XOR-encrypted command to any registry key, the driver intercepts it via CmRegisterCallback , decrypts the\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 1 of 11\n\npayload, and reflectively loads an arbitrary PE into kernel memory. This allows an attacker to execute code at the highest\r\nprivilege level while blending into legitimate system activity.\r\nThe loaded payload can further hijack the driver’s kernel callbacks, enabling persistent kernel-mode hooks without\r\nadditional driver loads. Because the PE is reflectively loaded into a raw pool allocation rather than through the standard\r\nmodule loader, it does not appear in PsLoadedModuleList and is invisible to tools that enumerate loaded drivers.\r\nThe driver binary was protected with Control Flow Guard (CFG) obfuscation, incorporating opaque predicates and\r\nduplicated basic blocks designed to impede static analysis. All findings in this report are based on the deobfuscated binary.\r\nThreat Landscape\r\nThe currently observed RegPhantom sample set spans at least 18 June 2025 through 6 August 2025, based on compilation\r\ntimestamps and VirusTotal first-submission dates. This window should be treated as the visible activity period rather than\r\nthe full lifetime of the toolchain, as earlier samples may not have been submitted publicly and later activity may not yet have\r\nbeen identified. Within that timeframe, the presence of multiple samples compiled across different dates, filenames, and\r\nenvironments indicates active development and ongoing adaptation by the threat actors.\r\nTwo samples bear valid code-signing certificates issued to Chinese companies: Guangzhou Xuanfeng Technology Co.,\r\nLtd. and Autel Intelligent Technology Corp., Ltd. The majority of first submissions originate from China, and compilation\r\ntimestamps are broadly consistent with a UTC+8 working schedule. While submission metadata alone is unreliable for\r\nattribution — as it may reflect third-party researchers or proxy infrastructure — the use of two distinct Chinese code-signing\r\ncertificates represents a stronger indicator, as obtaining such certificates requires direct access to the issuing entities or their\r\ninfrastructure. Taken together, these indicators support a China-nexus assessment at moderate confidence.\r\nSHA-256 Size Filename\r\nCreation\r\ntime\r\nSubmit from\r\n703dfb12edc6da592e3dfb951ca2d84bf349e6a16ad3a2ab32b275349956e7c4\r\n41.00\r\nKB\r\nMapDriver.sys\r\n2025-06-\r\n18\r\n12:43:05\r\nUTC\r\n CHINA\r\n006e08f1b8cad821f7849c282dc11d317e76ce66a5bcd84053dd5e7752e0606f\r\n52.21\r\nKB\r\nMyDriver-signed-20250619.sys\r\n2025-06-\r\n18\r\n13:02:00\r\nUTC\r\n CHINA\r\n5599ec1f3e1eb52a7e0f3b9dbd0c9849cf494c32ed1e50e76c43d2200daa283a\r\n58.00\r\nKB\r\nTestDriver.sys\r\n2025-06-\r\n28\r\n17:43:27\r\nUTC\r\n CHINA\r\n5650f8e0904433247a0cdc68c7b73c68291b52523dad1edb93a9bd7439273698\r\n58.50\r\nKB\r\nTestDriver.sys\r\n2025-06-\r\n28\r\n17:47:33\r\nUTC\r\n CHINA\r\n6606a963beb709da2d87d685d998e126f2a52efaad64eab8bbb5ba70c7ca5194\r\n58.50\r\nKB\r\n0629.sys\r\n2025-06-\r\n28\r\n17:54:04\r\nUTC\r\n CHINA\r\n97876c085318d8606e8478976d98dab77a7e905a87a4b0a27e20d794af25cd4c\r\n58.00\r\nKB\r\nMyDriver.sys\r\n2025-06-\r\n28\r\n17:54:26\r\nUTC\r\n CHINA\r\ncb2ed2ece12a675e19f2b537840a2b5d8bcdd1d508ec5c386178e60161d2cfe8 58.50\r\nKB\r\nTestDriver.sys 2025-06-\r\n29\r\n CHINA\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 2 of 11\n\nSHA-256 Size Filename\r\nCreation\r\ntime\r\nSubmit from\r\n03:01:11\r\nUTC\r\nb2bbdeb48f60e591d78ddc98fffc9504128e9b948fd58a54c2cfa927ff9db105\r\n58.50\r\nKB\r\nMyDriver_0629.sys\r\n2025-06-\r\n29\r\n03:01:32\r\nUTC\r\n CHINA\r\n218ab4cb7bf3622b4b8d5fa9196d817b91046e1eca84c26091f3f703ab214707\r\n58.00\r\nKB\r\nTestDriver.sys\r\n2025-07-\r\n15\r\n13:24:20\r\nUTC\r\n CHINA\r\n91860b4d03b32a4ca6e8e92856272d953999934e6316f65677a615cbfb8d31d0\r\n80.14\r\nKB\r\n–\r\n2025-07-\r\n17\r\n03:40:47\r\nUTC\r\n CHINA\r\nc55f5339abaf48b9392df67d5b6f6e011d878d7ee848724ad5dbe8c4d898ef23\r\n58.50\r\nKB\r\nTestDriver.sys\r\n2025-07-\r\n30\r\n06:25:04\r\nUTC\r\n🇸🇬\r\nSINGAPORE,\r\n USA\r\n7c9312ebe2afc299a0835a32700cdd2c5099c228799414c48058c0fb6095df9b\r\n58.50\r\nKB\r\nTestDriver.sys\r\n2025-07-\r\n30\r\n09:48:56\r\nUTC\r\n🇸🇬\r\nSINGAPORE\r\n01c3d2a947c56e16718f1f54c0820996dce1d44da25d38b2a9992eb16e6b11e6\r\n58.50\r\nKB\r\nTestDriver.sys\r\n2025-07-\r\n30\r\n09:49:32\r\nUTC\r\n CHINA,\r\n🇸🇬\r\nSINGAPORE,\r\n USA\r\nf6683adcb8a152d31ef1132ee3f4cb818dcf0b5e361f991286f9fb5d2d747afd\r\n63.00\r\nKB\r\nTestDriver.sys\r\n2025-08-\r\n05\r\n19:26:27\r\nUTC\r\n JAPAN\r\n7606a3b69488795fe2d71558caab7877ea313425e55a63aebb932d0d92b38aee\r\n63.00\r\nKB\r\nTestDriver.sys\r\n2025-08-\r\n05\r\n19:28:27\r\nUTC\r\n JAPAN\r\n32addf18477324f478bf93ac22be65550bc71450c9bc4fe49aa3be22219aae65\r\n63.00\r\nKB\r\nFsFilter.sys\r\n2025-08-\r\n06\r\n08:26:23\r\nUTC\r\n CHINA,\r\n JAPAN,\r\n RUSSIA\r\n0956ec57c3ddcd24c4d61bd6a4dd16b5f1468f701a286e46b761f5be4fc478ac\r\n63.00\r\nKB\r\nDevDriver.sys\r\n2025-08-\r\n06\r\n05:16:15\r\nUTC\r\n CHINA,\r\n RUSSIA,\r\n USA\r\nb10d8bb537ab05e51f08d0b942ee9f92f3226d118fcac794d1a7396bbc0b531f\r\n58.50\r\nKB\r\nFsFilter.sys\r\n2025-08-\r\n01\r\n05:39:36\r\nUTC\r\n CHINA,\r\n USA\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 3 of 11\n\nSHA-256 Size Filename\r\nCreation\r\ntime\r\nSubmit from\r\n77646afc50ac65756999441ff5879049c51309745fc9eb86d343174ad5601f2c\r\n58.50\r\nKB\r\nFsFilter.sys\r\n2025-07-\r\n17\r\n03:40:47\r\nUTC\r\n CHINA,\r\n USA\r\na0c291e8942c8c7fecccff3fbdb65f65c76312d384a73d3748042a319209c91c\r\n58.50\r\nKB\r\nTestDriver.sys\r\n2025-07-\r\n17\r\n03:47:20\r\nUTC\r\n CHINA\r\n6e1254e478d5b7e60a7a6c6c23943884eca59b214d5a8ecdbdea1a0bbd08df58\r\n58.50\r\nKB\r\nTestDriver.sys\r\n2025-07-\r\n15\r\n13:30:35\r\nUTC\r\n CHINA\r\naaed39996db0c5f9b7ebbda773e67aced72100af701bf2cd933c3aae6b31f9ce\r\n58.50\r\nKB\r\nTestDriver.sys\r\n2025-07-\r\n15\r\n13:29:31\r\nUTC\r\n CHINA\r\n2ece92c1b221338b0f37cc033b2a160bb03cd4d3c228f0924fcb7be6c9bbea10\r\n58.50\r\nKB\r\nTestDriver.sys\r\n2025-07-\r\n15\r\n13:27:17\r\nUTC\r\n CHINA\r\nf25784a7577f2e4fa254e93458f6c92de66c623a3029c284a39f4076bb8d7046\r\n58.50\r\nKB\r\nTestDriver.sys\r\n2025-07-\r\n14\r\n06:44:42\r\nUTC\r\n CHINA\r\n39eabd51174ae57bcaa05fc50ff7bb704464b97e315f6e03a6a447000463b261\r\n58.00\r\nKB\r\nTestDriver.sys\r\n2025-06-\r\n28\r\n17:43:59\r\nUTC\r\n CHINA\r\n836259c4475e372277b5115f8f4542c4210fd2817aaacd00f0a350b067fde165\r\n43.00\r\nKB\r\nMapDriver.sys\r\n2025-06-\r\n26\r\n20:00:44\r\nUTC\r\n CHINA\r\n8f24be8d38df0d2cec0abf78873b83d2a633b650324e99505993604909a13805\r\n43.00\r\nKB\r\nMapDriver.sys\r\n2025-06-\r\n26\r\n19:09:54\r\nUTC\r\n CHINA\r\nf06dacf7f7152c632ed435ab60bb1a8e9e9a7eb5d416eb6419eb4446f7fa821f\r\n42.00\r\nKB\r\nMyDriver.sys\r\n2025-06-\r\n18\r\n13:02:00\r\nUTC\r\n CHINA,\r\n RUSSIA\r\n1f3d90ed62bf1b4fd501cbd435d2519486b60ad91704b6e38b93da00960cd22d\r\n42.00\r\nKB\r\nMapDriver.sys\r\n2025-06-\r\n18\r\n12:43:58\r\nUTC\r\n CHINA\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 4 of 11\n\nSubmission origin heatmap\r\nRelated Samples\r\nThe following samples are signed by Guangzhou Xuanfeng Technology Co., Ltd. and exhibit the same CFG obfuscation\r\nwith opaque predicates and duplicated basic blocks observed in RegPhantom. These samples have not been fully reverse-engineered at the time of writing.\r\nSHA-256 Filename\r\ncc123e35363aeace09900bf3de76080eb46f7e04edede742dbdf2d80be129cc0 MapDriver.sys\r\na0eee7cd05ca3dbddb57414df99768c05ade18f9c13fb31e686558e636badf26 0627.sys\r\n9721430672e361eff1f92dd4cc81686635730bc9656f1542411ed2df93dea831 MapDriver.sys\r\nThe shared obfuscation technique and signing certificate reinforce the connection to the same development pipeline.\r\nTechnical details\r\nThe technical analysis below is based on sample 006e08f1b8cad821f7849c282dc11d317e76ce66a5bcd84053dd5e7752e0606f .\r\nObfuscation\r\nRegPhantom employs multiple layers of obfuscation to resist both static and dynamic analysis. The most prominent\r\ntechnique is Control Flow Guard (CFG) obfuscation: the binary’s control flow graph is inflated with opaque predicates —\r\nconditional branches whose outcome is statically determined but difficult for a disassembler to resolve — and duplicated\r\nbasic blocks. This effectively breaks decompiler output and forces the analyst to reason about each branch manually.\r\nHowever, the variety of opaque predicates used is low — the same patterns are reused across the binary — making the\r\nobfuscation vulnerable to pattern-based CFG simplification. The following graph shows the same function before and after\r\ndeobfuscation. The left side displays the original obfuscated CFG, inflated with opaque predicates and duplicated blocks; the\r\nright side shows the cleaned version produced by our deobfuscation script ( CFG_deobf.py ).\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 5 of 11\n\nCFG obfuscation — obfuscated vs. deobfuscated\r\nBeyond control flow, the driver obfuscates all function calls — both to imported APIs and to its own internal functions. The\r\nAPIs are present in the import table, but the driver never calls them directly. Instead, each call site computes the target\r\naddress by adding a global variable to a hardcoded offset, producing a pointer to the target function. The same technique is\r\napplied to internal function calls within the binary. This indirection prevents disassemblers and decompilers from resolving\r\nany call targets, making cross-references unreliable across the entire binary. The screenshot below shows an obfuscated call\r\nsite; the original API target can be recovered using our deobfuscation script ( deobfuscate_calls.py ).\r\nAPI call obfuscation\r\nCommand payloads written to the registry are XOR-encrypted, preventing signature-based detection of the data in transit.\r\nAfter a command is read and processed, the driver re-encrypts the buffer, ensuring no plaintext is ever left in memory.\r\nSimilarly, hook function pointers stored in the driver’s data structures are XOR-encoded at rest and only decoded\r\nimmediately before use, complicating memory forensics.\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 6 of 11\n\nThe driver also takes active steps to deny registry writes to the keys it monitors, preventing other processes from\r\noverwriting or tampering with its communication channel while also eliminating forensic artifacts. After executing a loaded\r\nPE payload, the driver wipes the memory region where the payload resided, leaving no trace of the executed code.\r\nFinally, the use of a valid code-signing certificate allows the driver to bypass Windows Driver Signature Enforcement\r\n(DSE), enabling it to load on systems with default security policies.\r\nTechnique Purpose\r\nCFG obfuscation with opaque predicates Hinders static analysis and decompilation\r\nAPI call obfuscation Hides calls to sensitive kernel APIs from static analysis\r\nXOR-encrypted command payloads Prevents signature-based detection of commands\r\nRe-encryption after processing No plaintext commands left in memory\r\nRegistry write denial No artifacts in the registry\r\nXOR-encoded hook pointers Obfuscates function pointers in memory dumps\r\nPost-execution memory wipe Loaded PE is erased after running\r\nSigned driver Bypasses Driver Signature Enforcement\r\nExecution Flow\r\nThe following diagram illustrates the end-to-end attack chain:\r\nAttack chain\r\nOnly the kernel driver was recovered during analysis — neither the accompanying userland executable nor the stage 2\r\nkernel module loaded by the driver were found. To validate the attack chain, we developed our own proof-of-concept: a\r\nuserland trigger ( poc_trigger.c ) named “exploit.EXE” that crafts the 56-byte XOR-encrypted command buffer and issues\r\nthe registry write, paired with a minimal “hello world” kernel module named “hello.sys” as the payload. The screenshot\r\nbelow confirms that an unprivileged usermode process can successfully load an arbitrary unsigned module into kernel space\r\nthrough RegPhantom:\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 7 of 11\n\nExploitation POC\r\nThe WinDbg trace below confirms that the injected module executes in kernel mode. Because the PE is reflectively loaded\r\ninto a raw pool allocation rather than through the standard module loader, it does not appear in the kernel module list ( lm /\r\nPsLoadedModuleList ), making it invisible to tools that enumerate loaded drivers.\r\nModule injection in kernel land\r\nNote: the module name visible in the trace was chosen for demonstration purposes; in a real deployment, the payload would\r\nuse a less conspicuous name.\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 8 of 11\n\n1. DriverEntry\r\nRegisters two kernel callbacks and sets the unload routine:\r\nCmRegisterCallback(RE_REGISTRY_CALLBACK, NULL, \u0026g_cm_callback_cookie)\r\nPsSetCreateThreadNotifyRoutine(RE_THREAD_NOTIFY)\r\nDriverObject-\u003eDriverUnload = RE_CLEANUP\r\nIf PsSetCreateThreadNotifyRoutine fails, it cleans up by calling CmUnRegisterCallback . Both callbacks are registered at\r\nload time to avoid suspicion — registering kernel callbacks in DriverEntry is normal driver behavior.\r\n2. Registry Communication Channel (RE_REGISTRY_CALLBACK)\r\nThe driver intercepts all registry operations system-wide via CmRegisterCallback . It filters for a specific write pattern:\r\nOperation = RegNtPreSetValueKey (pre-write)\r\nValue type = REG_BINARY\r\nData size = exactly 56 bytes (0x38)\r\nAny registry key works — the communication channel is path-agnostic. When a matching write is intercepted:\r\n1. Copies the 56-byte data to a local buffer\r\n2. XOR-decrypts the first 48 bytes using the single-byte key at offset 0x30\r\n3. Passes the decrypted command to RE_COMMAND_DISPATCHER\r\n4. Re-encrypts the buffer (no plaintext left in memory)\r\n5. Returns STATUS_ACCESS_DENIED (0xC0000022) to block the write\r\nThe registry value is never actually written. Monitoring tools (Procmon, ETW) only see a failed RegSetValueEx with an\r\naccess denied error — indistinguishable from a permission issue.\r\n3. Command Protocol (RE_COMMAND_DISPATCHER)\r\nThe decrypted 48-byte payload is parsed as:\r\n+0x00 QWORD command_code 0x77 = load and execute PE\r\n+0x08 QWORD usermode_pe_ptr Usermode VA of raw PE image\r\n+0x10 QWORD ntoskrnl_rva_1 ntoskrnl offset for memory allocator\r\n+0x18 QWORD ntoskrnl_rva_2 ntoskrnl offset for memory protect function\r\n+0x20 QWORD* result_ptr Usermode pointer, written to 1 on success\r\n+0x28 QWORD reserved\r\n+0x30 BYTE xor_key Single-byte XOR key (not encrypted)\r\n+0x31 7 bytes padding\r\nThe callback runs in the calling process’s context, so all usermode pointers are directly accessible from kernel mode. Only\r\ncommand 0x77 is implemented.\r\n4. Reflective PE Loader (RE_PE_LOADER)\r\nWhen command 0x77 is dispatched:\r\n1. RE_VALIDATE_SOURCE — Validates the PE at the usermode address, walks the import directory, resolves\r\nimports using RtlFindExportedRoutineByName\r\n2. RE_ALLOC_EXECUTABLE — Loads ntoskrnl.exe base, resolves allocator/protect functions from the\r\nprovided RVAs, allocates SizeOfImage bytes, zeroes it, sets PAGE_EXECUTE_READWRITE (0x40)\r\n3. Section mapping — Copies each PE section to its virtual address in the allocated buffer via memmove\r\n4. RE_APPLY_RELOCATIONS — Processes the PE relocation table to fix up addresses for the new base\r\n5. Entry point execution — Calls allocated_base + AddressOfEntryPoint with a context struct:\r\nContext struct (0x20 bytes):\r\n [0x00] → \u0026g_xor_decode_key\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 9 of 11\n\n[0x08] → \u0026g_registry_callback_hook_ptr\r\n [0x10] → \u0026g_thread_notify_hook_ptr\r\n [0x18] → \u0026g_reserved_hook_ptr\r\n1. Cleanup — memset(allocated_base, 0, 0x1000) wipes the mapped image after execution\r\n5. Hook Activation\r\nThe loaded PE receives pointers to 4 driver globals. By writing XOR-encoded function pointers to these slots, the payload\r\ncan:\r\nHijack the registry callback ( g_registry_callback_hook_ptr ) — all future registry operations are forwarded to\r\nthe payload’s handler, enabling a more sophisticated C2 protocol\r\nHijack the thread notify callback ( g_thread_notify_hook_ptr ) — the payload receives all thread\r\ncreation/destruction events without calling PsSetCreateThreadNotifyRoutine itself\r\nUse the reserved slot ( g_reserved_hook_ptr ) — available for future expansion\r\nAll hook pointers are XOR-encoded with g_xor_decode_key before being decoded at call time, adding a layer of\r\nobfuscation to memory forensics.\r\n6. Thread Notify Stub (RE_THREAD_NOTIFY)\r\nRegistered at driver load but completely dormant until a payload activates it. Once g_thread_notify_hook_ptr is set, it\r\ndecodes the handler ( g_xor_decode_key ^ g_thread_notify_hook_ptr ) and forwards (ProcessId, ThreadId, Create) to\r\nthe payload.\r\nThis depends entirely on RE_REGISTRY_CALLBACK — the only activation path is through the registry C2 → PE loader chain.\r\nConclusion\r\nRegPhantom is a purpose-built kernel rootkit that turns the Windows registry into a stealthy execution channel. By\r\nintercepting registry writes at the kernel level, it avoids leaving any persistent artifacts — no registry values are written, no\r\nfiles are dropped, and the injected code never appears in the kernel module list. The combination of a valid code-signing\r\ncertificate, CFG obfuscation, and reflective PE loading makes it difficult to detect through conventional static or forensic\r\nanalysis.\r\nThe presence of multiple samples compiled over several months, signed with two distinct Chinese certificates, and\r\nsubmitted from multiple countries points to an actively maintained tool by a China-nexus threat actor at moderate\r\nconfidence. The related samples sharing the same obfuscation and signing infrastructure suggest a broader toolkit that\r\nextends beyond RegPhantom itself.\r\nDetection should focus on the driver binary on disk rather than runtime artifacts, as the rootkit is specifically designed to\r\nleave none. The YARA rule provided below targets the driver’s unique byte-level patterns — the XOR decryption loop and\r\nthe command selector — which have remained stable across all observed samples.\r\nDetection\r\nArtifacts\r\nRegPhantom leaves no persistent artifacts on disk or in the registry. Because the driver returns STATUS_ACCESS_DENIED\r\nbefore the registry write completes, the command payload is never committed — no registry value is created or modified.\r\nThe loaded PE is wiped from kernel memory after execution. As a result, traditional forensic approaches based on registry or\r\nfilesystem analysis will not surface evidence of RegPhantom activity.\r\nyara\r\nrule MAL_Kernel_RegPhantom_Mar26 {\r\n meta:\r\n description = \"Detects RegPhantom, a kernel-mode rootkit that allows an attacker to inject arbitrary cod\r\n author = \"Pezier Pierre-Henri (Nextron Systems)\"\r\n date = \"2026-03-19\"\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 10 of 11\n\nreference = \"Internal Research\"\r\n hash = \"006e08f1b8cad821f7849c282dc11d317e76ce66a5bcd84053dd5e7752e0606f\"\r\n score = 80\r\n strings:\r\n $s1 = \"CmRegisterCallback\" fullword\r\n $s2 = \"PsSetCreateThreadNotifyRoutine\" fullword\r\n $o1 = {\r\n // xor decrypt\r\n 48 8b 09 // mov rcx, [rcx]\r\n 0f b6 14 08 // movzx edx, byte ptr [rax+rcx]\r\n 4c 31 c2 // xor rdx, r8\r\n 88 14 08 // mov [rax+rcx], dl\r\n }\r\n $o2 = {\r\n // Command selector\r\n c6 01 01 // mov byte ptr [rcx], 1\r\n 48 83 38 77 // cmp qword ptr [rax], 77h ; 'w'; Check if command_code (offset 0x00) == 0x77 ('w'\r\n 0f 94 c0 // setz al\r\n 24 01 // and al, 1\r\n }\r\n condition:\r\n uint16(0) == 0x5a4d\r\n and all of them\r\n}\r\nAbout the author:\r\nPierre-Henri Pezier\r\nPierre‑Henri Pezier is an IT Security Engineer and Threat Researcher with over a decade of experience in offensive security,\r\nreverse engineering, malware analysis and secure software development. He began reverse-engineering software in the early\r\n2010s, a passion that expanded into analyzing advanced threats, developing decryptors, and writing detection rules. With a\r\nbackground in both offensive and defensive security, Pierre‑Henri has worked on malware classification engines, sandbox\r\nenvironments, and EDR evasion techniques.\r\nSource: https://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nhttps://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.nextron-systems.com/2026/03/20/regphantom-backdoor-threat-analysis/"
	],
	"report_names": [
		"regphantom-backdoor-threat-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775434094,
	"ts_updated_at": 1775826771,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c8f6666ccfb3ea890b92758003ae243da3927846.pdf",
		"text": "https://archive.orkl.eu/c8f6666ccfb3ea890b92758003ae243da3927846.txt",
		"img": "https://archive.orkl.eu/c8f6666ccfb3ea890b92758003ae243da3927846.jpg"
	}
}