{
	"id": "f6ef07d6-273a-4f60-99c3-e1f9c7681e80",
	"created_at": "2026-04-06T00:09:09.779534Z",
	"updated_at": "2026-04-10T03:20:00.883335Z",
	"deleted_at": null,
	"sha1_hash": "4c857c48f1f6661cba69e59e557bd57eca9af7ea",
	"title": "Tracking driver inventory to unearth rootkits",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 77650,
	"plain_text": "Tracking driver inventory to unearth rootkits\r\nBy Brian Donohue\r\nPublished: 2019-06-28 · Archived: 2026-04-05 20:35:34 UTC\r\nOur colleague Keya Horiuchi recently described a threat detection where the Local Security Authority Subsystem\r\nService (LSASS) initiated a series of suspicious processes and attempted to install a trojan on a customer\r\nendpoint. In this post, we’re going to discuss what turned up when we pivoted off information from a very similar\r\ndetection.\r\nThreat hunting is fundamentally about pivoting and discovering new techniques or artifacts that you may have\r\nmissed previously, which is precisely how we discovered some intriguing driver activity a few months back.\r\nKernel-mode drivers function at a low level in the operating system, which can be problematic because malicious\r\nor vulnerable drivers—especially signed ones—can provide a stealthy, privileged position to conduct malicious\r\nactivity.\r\nOf course, driver and other signatures are meant to provide assurances for identity and integrity—not intent or\r\ncapability. In this case, the driver in question was signed; it was also a de facto rootkit. However, there was\r\nsuspicious activity prior to its installation, and the ancillary activity might be useful in detecting this and similarly\r\ninconspicuous threats moving forward.\r\nAn intriguing driver\r\nAn important part of incident response is to examine all of the binaries that dropped on a system around the time\r\nof a malicious event. And that’s exactly how we stumbled on this particular binary in the Carbon Black binary\r\nstore:\r\nFile MD5 hash: 2FAD0F279F7851AD6357C2DA8CE213A2\r\nThis file was particularly interesting given its filename, path, and explicitly distrusted status (its status has since\r\nchanged to revoked). Why, for example, is a .sys file with “dump” in its name being dropped in the\r\nc:\\windows\\system32\\drivers\\ path? There’s only one way to find out, so we brought the driver\r\n( dump_76af3f80.sys ) into a test environment for closer analysis.\r\nSome observations\r\nAs you can see in the following image, the file’s certificate had expired or was not yet valid.\r\nhttps://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nPage 1 of 9\n\nA closer look revealed that the certificate had been explicitly revoked:\r\nOn background\r\nThe adversary delivered the payload via a well-known exploit for a server message block (SMB) vulnerability,\r\nCVE-2017-0144, fixed in March 2017.  It’s worth noting that the research team at NSFocus seemed to have found\r\nand reported on a substantially similar threat in their NuggetPhantom report. While their write-up focused on\r\nmodules within the malware, how it attempts to evade detection, and its history, we’re going to examine how this\r\nparticular threat manifested in endpoint telemetry and why—in general—you should keep an eye on the drivers in\r\nyour environment. Below is an image from NSFocus’ report that, while blurry, might be a helpful visual cue for\r\nconceptualizing the execution timeline:\r\nhttps://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nPage 2 of 9\n\nThe process timeline\r\nThe first thing we see in the Red Canary detection is lsass.exe spawning rundll32.exe and msiexec.exe. As our\r\ncolleague Keya pointed-out a few blogs ago, it is highly unusual for LSASS to spawn rundll32, and it’s also\r\nunusual for msiexec.exe to make an external HTTP request. Both of these process relationships offer great\r\nopportunities for detection.\r\nhttps://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nPage 3 of 9\n\nHere are some Carbon Black queries that might unearth this activity in the environment you’re monitoring:\r\nparent_name:lsass.exe process_name:rundll32.exe\r\nparent_name:lsass.exe process_name:rundll32.exe childproc_name:msiexec.exe\r\nparent_name:rundll32.exe process_name:msiexec.exe\r\n(process_name:msiexec.exe cmdline:\"/i\" (cmdline:\"http:\" OR cmdline:\"https:\"))\r\nAs you can see in the above timeline, msiexec eventually makes an outbound network connection and loads\r\ndownloadupdatemakegood.jpg . In turn, that file decompresses winupdate64.log :\r\nhttps://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nPage 4 of 9\n\nThis is a bit of a sidebar, but we can also see the malicious software using netsh.exe to block ports 137, 138, 139,\r\nand 445, which prevents other adversaries from leveraging the same exploit to further compromise this host.\r\nhttps://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nPage 5 of 9\n\nAt the time we detected this threat, there wasn’t much in the way of publicly available blogs or research\r\ndiscussing this behavior, so we were largely unsure of what else may have been dropped. However, as we\r\ncontinued triaging, we discovered that the msiexec execution coincided with another file being dropped and\r\ninjected into trusted processes: ms7db53800app.dll .\r\nHere’s the first part of the timeline:\r\nhttps://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nPage 6 of 9\n\nHere’s the second part:\r\nExamining the driver\r\nA quick search for ms76af3f80app.dll in Carbon Black revealed that its underlying binary is the same as another\r\nfile, ms76af3f80app.dll , and that the MD5 hash associated with both files is\r\n4209AE0CB569EFAB29CA9D2D7F4A211B .\r\nIt’s worth noting—if only tangentially—that Carbon Black collects executables and DLLs the first time they are\r\nobserved loading or executing.\r\nUltimately, ms76af3f80app.dll then delivers the driver that we looked at in the opening of this blog\r\n( dump_76af3f80.sys ). It’s a signed binary, and it matches the digsig_subject reported by NSFocus.\r\nWe observed the adversaries updating their binaries by downloading a new *app.dll file along with a pair of .xsl\r\nfiles. According to NSFocus, those are the DDoS and monero-mining modules:\r\nhttps://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nPage 7 of 9\n\nThis driver adds persistence to live within safe mode by modifying the safeboot registry values, a technique that\r\nDidier Stevens first described all the way back in 2007.\r\nConclusion\r\nEven in cases where a driver’s signature has expired or been revoked, it will still pass Driver Signature\r\nEnforcement and the operating system might even load it in some situations.\r\nAs defenders, we need to understand, enumerate, and evaluate what drivers are in our fleet. We need to understand\r\nhow they arrived and what their intentions are. Unlike user-mode applications, we believe that kernel-mode\r\ndrivers, while certainly dynamic, will have less change over time than user-mode applications. In this way, it’s\r\nfeasible to track driver changes in order to keep an eye out for adversaries who would use kernel-mode drivers as\r\nsurreptitious rootkits.\r\nThese types of attacks are the very reason Microsoft has developed Kernel Mode Code Integrity: to give defenders\r\nassurances that even though a driver is signed, it may not be sanctioned or approved for your environment, and\r\ntherefore will not load.\r\nThe following Carbon Black queries relate specifically to the binary metadata of these drivers.\r\nobserved_filename:c:\\windows\\system32\\drivers\\ digsig_result:\"Bad Signature\"\r\ndigsig_result:\"Invalid Signature\" digsig_result:\"Invalid Chain\" digsig_result:\"Untrusted Root\"\r\ndigsig_result:\"Explicit Distrust\"\r\nhttps://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nPage 8 of 9\n\nAnd the inverse:\r\n-observed_filename:c:\\windows\\system32\\drivers\\ digsig_result:\"Bad Signature\"\r\ndigsig_result:\"Invalid Signature\" digsig_result:\"Invalid Chain\" digsig_result:\"Untrusted Root\"\r\ndigsig_result:\"Explicit Distrust\"\r\nThis may lead to a clean way to detect suspicious driver loads from ntoskrnl.exe . Very few unsigned binaries,\r\nlet alone distrusted ones, get loaded. I confirmed this theory by sweeping across our fleet of endpoints, finding\r\nthat the volume was minimal enough to sort through manually. We can further limit this output by suppressing\r\nobviously legitimate unsigned binaries. Ultimately, this should lead to us to identify true evil being loaded by\r\nntoskrnl.exe .\r\nHere’s a related query:\r\n(digsig_result_modload:“Unsigned” OR digsig_result_modload:“Explicit\\ Distrust”)\r\nprocess_name:ntoskrnl.exe\r\nOn 32 bit systems, we may expect to see an unsigned modload. However, on a 64 bit system, the Windows kernel\r\nrequires that drivers be signed.\r\nThe inverse, all signed, could be an interesting play to identify suspect signed drivers being loaded. It would take\r\nmore time to tune but could reveal some interesting behaviors.\r\nIndicators\r\n2FAD0F279F7851AD6357C2DA8CE213A2\r\nAE8EDBEA9F2106D59147A377B86B412E\r\n4209AE0CB569EFAB29CA9D2D7F4A211B\r\nSource: https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nhttps://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/\r\nPage 9 of 9\n\n  https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/     \nThis is a bit of a sidebar, but we can also see the malicious software using netsh.exe to block ports 137, 138, 139,\nand 445, which prevents other adversaries from leveraging the same exploit to further compromise this host.\n    Page 5 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/"
	],
	"report_names": [
		"tracking-driver-inventory-to-expose-rootkits"
	],
	"threat_actors": [],
	"ts_created_at": 1775434149,
	"ts_updated_at": 1775791200,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4c857c48f1f6661cba69e59e557bd57eca9af7ea.pdf",
		"text": "https://archive.orkl.eu/4c857c48f1f6661cba69e59e557bd57eca9af7ea.txt",
		"img": "https://archive.orkl.eu/4c857c48f1f6661cba69e59e557bd57eca9af7ea.jpg"
	}
}