{
	"id": "c12747f1-7707-4558-8bfc-245d75cb5391",
	"created_at": "2026-04-06T00:19:41.011849Z",
	"updated_at": "2026-04-10T03:25:23.17527Z",
	"deleted_at": null,
	"sha1_hash": "faad696672f8e99cb30cecacf119aba363eeb367",
	"title": "Advanced Threat Research | Intel Security",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1091612,
	"plain_text": "Advanced Threat Research | Intel Security\r\nArchived: 2026-04-05 19:23:30 UTC\r\nThe examination of commercial malware developed by Hacking Team has revealed much to the security\r\ncommunity. Of particular interest to platform security researchers at Intel's Advanced Threat Research team (ATR)\r\nis the presence of what appears to be a UEFI-based persistent infection mechanism. ATR has been researching\r\nvulnerabilities related to system firmware and working with a community of firmware developers and platform\r\nmanufacturers to mitigate these threats. Others have also posted good information about this issue. Here, we will\r\nprovide some preliminary analysis of the firmware threat.\r\nFinding a Persistent Rootkit\r\nThe trail begins with the mysterious file \"Z5WE1X64.fd\" which was attached to one of the leaked emails into\r\n\"Uefi_windows_persistent.zip\" compressed file.\r\nA deeper look into the binary reveals some string constants which point toward firmware image update for UEFI\r\nBIOS platforms:\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 1 of 12\n\nThis binary appears to be a firmware update image packed by InsydeH2O tools for UEFI firmware. These tools\r\nare applicable to many (though not all) common platforms. Inside the image, we (along with Nikolaj Schlej) found\r\nsome unexpected sections:\r\nSome suspicious entries are \"Ntfs\", \"rkloader\" and a nameless UEFI application (highlighted above). The\r\ndevelopers did not hide the real name of the modules, which has a hint about module functionality and enables\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 2 of 12\n\ndetection.\r\nThe \"rkloader\" executable image name suggests a rootkit. In the same leaked archive we find the source code\r\ndirectory \"vector-edk\" which contains the code of a UEFI-based rootkit.\r\nMore than a PoC\r\nThe leaked source code goes beyond a research proof-of-concept, revealing a commercial rootkit platform called\r\n\"]HackingTeam[ UEFI Vector\" and using real attacks as a part of Hacking Team? RCS malware platform.\r\nAccording to the leaked code and emails, this hacking platform may have already been already sold to some\r\nHackingTeam customers. Some of the emails point to specific modes on which the persistent rootkit was tested.\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 3 of 12\n\nUpdating the SPI flash, where system firmware is usually stored, is usually accomplished either through\r\nphysically attaching a programmer to the chip or through a signed update mechanism built into the firmware. One\r\nof the leaked emails contains a presentation (presumably for potential customers) that describes this:\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 4 of 12\n\nHere is screenshot of slide which describing infection way with phisical access to the target n machine:\r\nBoth \"agent\" and \"soldier\" are the names of trojan horse applications also found in the leaks. The rootkit reinstalls\r\nthese applications automatically, from infected firmware. Another slide describes options to modify firmware:\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 5 of 12\n\nBased on the information we have reviewed so far, we have not identified any new vulnerability used to bypass\r\nSPI flash protections. Some of the leaked messages clearly discuss using physical access and a SPI programmer to\r\nprogram the infected image to the SPI flash. There is also mention of a USB image that installs the malware using\r\na UEFI application. This application (which appears to have been ported from an old and modified version of\r\nchipsec) erases and re-programs the SPI flash image from software. This method should only work on a system\r\nthat is not configured to protect writes to the SPI flash. This serious configuration issue has been discussed by\r\nmultiple researchers over many years, including A Tale of One Software Bypass of Windows 8 Secure Boot,\r\nDefeating Signed BIOS Enforcement, and Speed Racer. It is possible that HackingTeam (or others) could have\r\nother vulnerabilities that can be used to bypass protections and infect the SPI flash, but so far we have not seen it.\r\nThis means that physical access and insecure configuration are the most likely attack vectors.\r\nNow that we can see the threat posed by this firmware rootkit, we begin to examine the technical details of its\r\nimplementation.\r\nWhat does this malware do?\r\nThe infected BIOS image contains a DXE driver named \"rkloader\". As mentioned earlier, source code (which\r\nsomeone appears to have posted to GitHub) also appears in the leaked archive. During the DXE phase of UEFI\r\nfirmware execution, modules are enumerated and executed automatically. The main routine of this \"rkloader\"\r\nmodule just registers a callback to execute the malicious payload.\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 6 of 12\n\nThe first parameter of gBootServices-\u003eCreateEventEx() routine indicates\r\n(EFI_EVENT_GROUP_READY_TO_BOOT), which is an event that occurs before the OS boot loader has been\r\nexecuted. This allows the malicious payload to gain execution before and OS (or even the boot loader) has had a\r\nchance to run.\r\nThe callback then loads another UEFI application, which is hard coded into rkloader source code (GUID named\r\nLAUNCH_APP).\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 7 of 12\n\nThis GUID identifies a UEFI application module with the name \"fsbg\". This application contains the main\r\nmalicious functionality for stealth operations with an NTFS file system.\r\nHere is full list of functions contained in \"fsbg.c\" module:\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 8 of 12\n\nThe main workflow of fsbg dropper module is:\r\n1. Check active infection by predefined UEFI variable \"fTA\"\r\n2. Initialize Ntfs protocol\r\n3. Find malicious executables in the BIOS image by predefined sections\r\n4. Check for existing users on the machine by existing names in home directory\r\n5. Install multiple malware executable modules: scoute.exe (backdoor) and soldier.exe (RCS agent).\r\nAn important note, which we will use for detection, is the use of the UEFI variable \"fTA\" to mark an infected\r\nsystem.\r\nThe EFI_GLOBAL_FILE_VARIABLE_GUID is defined as follows:\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 9 of 12\n\nThe \"fsbg\" module implements file system operations. However the low-level code for interacting specifically\r\nwith NTFS is factored into a separate module called \"Ntfs\" which is based on modified open-source\r\nimplementations of NTFS file system drivers for UEFI. The \"fsbg\" module loads the \"Ntfs\" module as a system\r\nprotocol driver.\r\nThe \"fsbg\" module references locations for malicious OS applications in the file system:\r\nFrom the above, it is easy to see how the this rootkit fulfills the attacker? goals of persistent infection. Even if the\r\nOS is reinstalled or the hard drive is replaced, the malicious DXE module continues to execute automatically and\r\ndrops additional malicious files into the file system. While this appears to be Windows-specific, the modular\r\narchitecture would allow for other file systems or applications to be used with a different OS. (Though, so far, we\r\nhave not seen an implementation for any other OS.)\r\nFirmware Rootkit Detection\r\nWe released CHIPSEC framework, which contains various tests and tools for platform security assessment,\r\nincluding some forensic capabilities. We leverage CHIPSEC in our examples below, but other tools can also be\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 10 of 12\n\nused to accomplish the same thing.\r\nTesting UEFI Firmware Protections in Flash Memory\r\nInstalling this firmware rootkit involves rewriting SPI flash. The system firmware is responsible for securely\r\nconfiguring the protections on SPI flash in order to prevent this. CHIPSEC contains configuration checks that\r\nusers can easily run:\r\npython chipsec_main.py -m common.bios_wp\r\nIf this test fails, it may be possible for software running on the system to modify the BIOS in the SPI flash due to\r\ninsecure configuration of the hardware protections. This does not mean that the system is infected, but it would\r\nbe harder to infect a system that passes this test than one that fails.\r\nSigns of Infection\r\nAs we will detail in our next posthave explained above, the rootkit creates a UEFI variable called \"fTA\" and even\r\nuses this to check if it has already been installed. A user can list the UEFI variables on a system and search for this\r\nvariable.\r\npython chipsec_util.py uefi var-list\r\npython chipsec_util.py uefi var-find fTA\r\nAfter running the var-list command, users should look in the file efi_variables.lst for a variable with the name\r\n\"fTA\" and GUID 8BE4DF61-93CA-11d2-aa0d-00e098302288. The var-find command in chipsec will specifically\r\nlook for this variable. Presence of the \"fTA\" variable indicates a system that might have been infected.\r\nAlso, a user can read the entire image from the SPI flash and look inside it for unexpected changes. Ideally, a\r\nhardware programmer should be attached to independently capture an image of SPI flash from a suspect system.\r\nThis should avoid advanced hiding techniques. (While not recommended, the image can be read from software\r\nusing the chipsec command python chipsec_util.py spi dump spi.bin)\r\nAfter an image has been captured from a suspect system and a known-good system of the same model, offline\r\nanalysis that compares both images can begin. It helps to parse the firmware volumes and NVRAM variables that\r\nmake up the image. With CHIPSEC, this can be done using the following command:\r\npython chipsec_util.py decode spi.bin [fw type]\r\nNote that NVRAM variables often change between platforms and even between reboots of the same platform.\r\nUEFI-based firmware Experience is recommended for this analysis. However, by comparing a suspect image with\r\na known-good one, it is possible to find the extra modules added by the rootkit.\r\nFinally, on an infected Windows system, malicious files (particularly scoute.exe or soldier.exe) may be stored in\r\nthe following locations:\r\nAppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\r\nAppData\\Local\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 11 of 12\n\nAppData\\Local\\Microsoft\r\nThis should be a good start for finding persistently infected systems.\r\nSource: https://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.ht\r\nml\r\nhttps://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://web.archive.org/web/20170313124421/http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html"
	],
	"report_names": [
		"HT-UEFI-rootkit.html"
	],
	"threat_actors": [
		{
			"id": "a3687241-9876-477b-aa13-a7c368ffda58",
			"created_at": "2022-10-25T16:07:24.496902Z",
			"updated_at": "2026-04-10T02:00:05.010744Z",
			"deleted_at": null,
			"main_name": "Hacking Team",
			"aliases": [],
			"source_name": "ETDA:Hacking Team",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "e90c06e4-e3e0-4f46-a3b5-17b84b31da62",
			"created_at": "2023-01-06T13:46:39.018236Z",
			"updated_at": "2026-04-10T02:00:03.183123Z",
			"deleted_at": null,
			"main_name": "Hacking Team",
			"aliases": [],
			"source_name": "MISPGALAXY:Hacking Team",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434781,
	"ts_updated_at": 1775791523,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/faad696672f8e99cb30cecacf119aba363eeb367.pdf",
		"text": "https://archive.orkl.eu/faad696672f8e99cb30cecacf119aba363eeb367.txt",
		"img": "https://archive.orkl.eu/faad696672f8e99cb30cecacf119aba363eeb367.jpg"
	}
}