{
	"id": "0402229a-dc8f-45e2-9862-604446ff2ef3",
	"created_at": "2026-04-06T01:30:01.352839Z",
	"updated_at": "2026-04-10T03:20:29.520444Z",
	"deleted_at": null,
	"sha1_hash": "2d78efe2cf647f33059438fded26b895be224ea3",
	"title": "The “Hikit” Rootkit: Advanced and Persistent Attack Techniques (Part 2)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 132975,
	"plain_text": "The “Hikit” Rootkit: Advanced and Persistent Attack Techniques\r\n(Part 2)\r\nBy by Christopher Glyer\r\nPublished: 2012-08-22 · Archived: 2026-04-06 00:22:40 UTC\r\nBy Christopher Glyer and Ryan Kazanciyan\r\nIn the first part of this series we introduced the \"Hikit\" rootkit and discussed some of its distinctive characteristics,\r\nparticularly the clever mechanisms it uses to load on a compromised system. Today, we'll take a look at some of\r\nthe counter-forensic techniques that it utilizes to stay hidden in a compromised environment, provide an Indicator\r\nof Compromise (IOC) used to find host-based evidence of the malware, and discuss how attackers took advantage\r\nof its functionality.\r\nSigned and Delivered\r\nWhen conducting triage analysis to identify unknown malware on a system, investigators often whitelist valid\r\nbinaries by comparing their MD5 hashes against \"known good\" lists such as the NIST Software Reference\r\nLibrary. Similarly, eliminating files that have been digitally signed can be another effective data reduction\r\ntechnique - but assumes a certain level of risk, depending on which certificates you choose to trust.\r\nMalware authors are well aware that digitally signed binaries are more likely to be overlooked (and may even be\r\nnecessary if attempting to install drivers on certain versions of Windows or conducting other automated operations\r\nwhere some degree of certificate validation occurs). Stuxnet and Flame are both examples of sophisticated\r\nmalware that used digital certificates, albeit from very different sources, to help achieve their objectives.\r\nSo how does this relate back to \"Hikit\"? During installation, \"oci.dll\" extracts a number of files from its resources\r\nsection:\r\nThe rootkit driver \"W7fw.sys\"\r\nSeveral requisite .INF and .CAT files for the driver\r\nA digital certificate \"GlobalSign.cer\", along with a copy of Microsoft's Certificate Manager tool\r\n\"certmgr.exe\"\r\nThe attacker self-generated \"GlobalSign.cer\" to masquerade a legitimate certificate issued by GlobalSign - it was\r\nnot stolen nor legitimate. The malware proceeds to use \"certmgr.exe\" to install the certificate to the local trust\r\nstore as a root CA and Trusted Publisher using the following two commands:\r\ncertmgr.exe -add GlobalSign.cer -c -s -r localMachine Root\r\ncertmgr.exe -add GlobalSign.cer -c -s -r localMachineTrustedPublisher\r\nIt then attempts to disable driver signing verification by tampering with several registry keys. Finally, it completes\r\nthe driver installation process and checks that it is properly loaded.\r\nhttps://web.archive.org/web/20210920172620/https://www.fireeye.com/blog/threat-research/2012/08/hikit-rootkit-advanced-persistent-attack-techniques-part-2.html\r\nPage 1 of 3\n\nWe now have enough information to build an effective host-based IOC, an example of which is shown in the\r\nfigure below, that can reliably identify this malware. The IOC includes simple traits like unique filenames, process\r\nhandles, MD5 hashes, service configuration, and the invalid digital signature information. It also has a more\r\ncomplex set of expressions to identify suspicious instances of \"oci.dll\" based on combinations of imported\r\nfunctions, resource names, version information metadata, and compilation time.\r\nFigure 1: Indicator of Compromise (IOC) for \"Hikit\" rootkit\r\n\"Hikit\" Put to Use\r\nSo what does the rootkit driver do? \"Hikit\" uses an interesting covert mechanism for command and control. It\r\ninstalls itself as a virtual network adapter layered between the NIC and overlying protocol drivers. This allows it\r\nto covertly monitor incoming packets, intercept command and control data as it enters the network stack, and then\r\nhttps://web.archive.org/web/20210920172620/https://www.fireeye.com/blog/threat-research/2012/08/hikit-rootkit-advanced-persistent-attack-techniques-part-2.html\r\nPage 2 of 3\n\nspawn user-mode threads to parse them accordingly. (And in case you're wondering, we're definitely glossing over\r\nthe technical details that our awesome malware analysts uncovered during reverse engineering).\r\nBut this should have you wondering about the context in which such a backdoor would be useful. After all, most\r\ninternal servers and workstations in a corporate environment are going to be behind several layers of firewall and\r\nNAT'ing - that's why most backdoors communicate out? So why go through all of this trouble for a rootkit that can\r\nonly listen for inbound C2?\r\nThe pattern was obvious once we saw which systems were infected with the rootkit: nearly all of them were\r\nWindows servers residing in the victim's DMZ and running web services on ports 80 and 443. The attacker was\r\nthereby able to covertly issue C2 over these same inbound ports using the backdoor client. Without knowing\r\nexactly what C2 signatures to look for, most network monitoring solutions would infer the traffic to be no\r\ndifferent than other incoming HTTP sessions.\r\nFurthermore, in addition to the typical set of backdoor features (launch a shell, run commands, transfer files, etc.),\r\n\"Hikit\" can force infected systems to operate as an open proxy. When coupled with the fact that several internal\r\nfirewalls were more permissive than necessary, this allowed the attacker to tunnel Remote Desktop and obtain\r\ninteractive access to internal systems, authenticating to each using previously compromised credentials. This also\r\nallowed them to create \"hop points\" among internal and external network segments by placing the rootkit (or\r\nrootkit client) on hosts that were multi-homed.\r\nMalware like \"Hikit\" reinforces an important lesson that digital forensic analysts should all take to heart: always\r\nquestion your assumptions and be prepared to expect the unexpected. Rapidly evolving tools and techniques will\r\nincreasingly test truisms like \"You can always trust signed binaries\" or \"Modern backdoors are always going to\r\ninitiate outbound C2\". Following your leads, generating effective IOCs, and fully scoping enterprise-scale\r\nincidents can help ensure you stay a step ahead of a sophisticated adversary.\r\nSource: https://web.archive.org/web/20210920172620/https://www.fireeye.com/blog/threat-research/2012/08/hikit-rootkit-advanced-persistent-attack-techniques-part-2.html\r\nhttps://web.archive.org/web/20210920172620/https://www.fireeye.com/blog/threat-research/2012/08/hikit-rootkit-advanced-persistent-attack-techniques-part-2.html\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://web.archive.org/web/20210920172620/https://www.fireeye.com/blog/threat-research/2012/08/hikit-rootkit-advanced-persistent-attack-techniques-part-2.html"
	],
	"report_names": [
		"hikit-rootkit-advanced-persistent-attack-techniques-part-2.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775439001,
	"ts_updated_at": 1775791229,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2d78efe2cf647f33059438fded26b895be224ea3.pdf",
		"text": "https://archive.orkl.eu/2d78efe2cf647f33059438fded26b895be224ea3.txt",
		"img": "https://archive.orkl.eu/2d78efe2cf647f33059438fded26b895be224ea3.jpg"
	}
}