{
	"id": "0c9648ab-be64-47c3-aecc-55f2ea76d476",
	"created_at": "2026-04-06T00:21:53.093789Z",
	"updated_at": "2026-04-10T13:13:00.549836Z",
	"deleted_at": null,
	"sha1_hash": "20870415b2073a9e650e1b141dd12aa14264b41f",
	"title": "AppUNBlocker: Bypassing AppLocker | Tripwire",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 42489,
	"plain_text": "AppUNBlocker: Bypassing AppLocker | Tripwire\r\nBy Editorial Staff\r\nPublished: 2016-10-27 · Archived: 2026-04-05 23:46:12 UTC\r\nWindows AppLocker is a powerful whitelisting technology built into modern Windows operating systems. It\r\nprovides the ability to lock down installers, scripts and executables on the local machine via either a white list or a\r\nblack list of file data. For many organizations, this is a great technology to reduce the attack surface of the\r\nendpoint by limiting what can run to a specific set of known files. To make this decision on what is able to\r\nexecute, AppLocker can inspect the file’s path, hash, or publisher information. Each of these has their pros and\r\ncons, which I will discuss here. Stating which paths can execute on a file system is the easiest step for an\r\norganization to lock down an endpoint. Using the golden image as a reference system, the expected Windows and\r\ninstalled applications can be profiled and imported into AppLocker relatively easily. This prevents mainly\r\nunwanted software from running, as it would be installed in an “unknown” location on the operating system.\r\nAdditionally, this is the easiest to maintain, as expected locations for applications to execute from will maintain\r\nfairly static. However, for a malicious attacker, simply placing the malware in a “known” location can bypass the\r\nAppLocker’s intended function. The next option is to import a list of known hashes into AppLocker and block\r\nanything else from running. This also has the benefit of preventing unwanted software from running on the\r\nendpoint, be it in a known or unknown location. While daunting at first, it’s easy to use PowerShell scripts to scan\r\na reference system, format an AppLocker XML policy and import directly into the endpoint’s AppLocker\r\nconfiguration. For static environments, this is a great option, as causing a hash collision is incredibly difficult.\r\nMost IT endpoints are not static, causing this AppLocker configuration to be difficult to manage at scale. Each\r\nPatch Tuesday will require the new hashes to be imported into the AppLocker configuration on each endpoint.\r\nWithout doing this first, unexpected and potentially catastrophic results could ensue from AppLocker blocking\r\ncritical system processes. This leaves the final option of validating the publisher information of system files.\r\nWindows system files are signed by a valid Microsoft certificate, while most software vendors are switching to\r\nsigning their software, as well. Any remaining files which aren’t signed can be inspected manually via either the\r\npath or hash functionality. There are two methods to bypass publisher verification in AppLocker. Both methods do\r\nrequire inserting a malicious trusted certificate into the root certificate trust store. While this may sound difficult,\r\nthe trust store is simply in a predictable point within the registry. On any Windows operating system, the root trust\r\nstore is located in HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SystemCertificates\\ROOT\\Certificates.\r\nThere’s a Key for each trusted certificate on the machine. Injecting a malicious certificate here allows the system\r\nto trust a file an attacker signed with the appropriate certificate. In order to bypass AppLocker, the attacker can\r\nalso create an additional AppLocker rule in the AppLocker configuration. This can potentially be very noisy from\r\na logging perspective. The better method would be to inspect the AppLocker configuration by pulling the active\r\nconfiguration from a PowerShell command, such as “Get-AppLockerPolicy –Effective –XML”. If the system is\r\ntrusting the signed Windows files, for example, this is easily bypassed. The first step is to create a malicious\r\ncertificate authority and associated certificate to sign the piece of malware. In my example, I am using a\r\nMeterpreter Reverse TCP Shell intended to look like Windows Calculator. When creating the CA and certificate,\r\nuse the following information:\r\nhttps://www.tripwire.com/state-of-security/off-topic/appunblocker-bypassing-applocker/\r\nPage 1 of 2\n\nCountry: US\r\nState: Washington\r\nLocality Name: Redmond\r\nOrganization Name: Microsoft Corporation\r\nCommon Name: Microsoft Windows Operating System\r\nNext, sign the file with the created certificate. While there are many tools out there, using Microsoft’s SignTool is\r\na simple and easy way to accomplish this. Execute “Signtool.exe sign /f \u003ccertificate_file\u003e /p\r\n\u003ccertificate_password\u003e \u003cmalicious_file_name\u003e” to sign the file with the new certificate. The next step, getting the\r\nnew CA to be trusted by the victim, is more difficult. If you have physical control over the device, you can double-click the CA file to install or use Microsoft’s CertMgr tool to inject the new CA. These are obviously not ideal in a\r\nreal-world scenario, but they are available should you find yourself in that predicament. More likely, you’ll want\r\nto inject the CA data blob into the registry directly. If you can gain Meterpreter beforehand, the inject_ca module\r\ncan do this for you with a few modifications. Without Meterpreter, injecting directly into the registry works great,\r\nas the certificate looks the same on any machine, meaning you can inject the certificate into a machine you control\r\nand export the registry key from there to be used later on the victim. Once the malicious certificate authority has\r\nbeen injected into the victim, the signed piece of malware will bypass the publisher verification checks for\r\nWindows system files. AppLocker first checks that the executable is signed by a trusted certificate, which is why\r\nthe malicious CA had to be injected. After this, AppLocker will do a string comparison on the publisher data.\r\nSince the certificate was created using Microsoft’s information, the string characters match and the file is allowed\r\nto execute. Even though this bypass seems dangerous on the surface, it does require administrative privileges to\r\ninject the malicious certificate authority into the registry. Grant local administrative privileges to end users only if\r\nabsolutely necessary. If there is a business justification for local administrative privileges, monitoring the registry\r\nentries at HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SystemCertificates\\ROOT\\Certificates is\r\nabsolutely necessary. The certificates stored here will rarely change, if ever, over the life of a typical endpoint.\r\nIncluded below is a list of expected Windows certificates, which ship with various Windows platforms. Many\r\nenterprises will have additional trusted certificates on their endpoints which can only be identified by the\r\nenterprise which minted the certificate; however following this list can reduce the overall workload of validating\r\nthe various trusted certificates across the enterprise. The following keys are located in\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SystemCertificates\\ROOT\\Certificates\\\r\n18F7C1FCC3090203FD5BAA2F861A754976C8DD25 245C97DF7514E7CF2DF8BE72AE957B9E04741E85\r\n3B1EFD3A66EA28B16697394703A72CA340A05BD5 7F88CD7223F3C813818C994614A89C99FA3B5247\r\n8F43288AD272F3103B6FB1428485EA3014C0BCFE A43489159A520F0D93D032CCAF37E7FE20A8B419\r\nBE36A4562FB2EE05DBB3D32323ADF445084ED656 CDD4EEAE6000AC7F40C3802C171E30148030C072\r\nUsers of Tripwire Enterprise and CCM can download policies from the Tripwire Customer Center to both monitor\r\nthe installed certificates, as well as verify they are part of the trusted certificates which Microsoft provides.\r\nDownload the TE_AppUnBlocker.zip file located on the Threat Rules tab for Tripwire Enterprise content.\r\nSource: https://www.tripwire.com/state-of-security/off-topic/appunblocker-bypassing-applocker/\r\nhttps://www.tripwire.com/state-of-security/off-topic/appunblocker-bypassing-applocker/\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.tripwire.com/state-of-security/off-topic/appunblocker-bypassing-applocker/"
	],
	"report_names": [
		"appunblocker-bypassing-applocker"
	],
	"threat_actors": [],
	"ts_created_at": 1775434913,
	"ts_updated_at": 1775826780,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/20870415b2073a9e650e1b141dd12aa14264b41f.pdf",
		"text": "https://archive.orkl.eu/20870415b2073a9e650e1b141dd12aa14264b41f.txt",
		"img": "https://archive.orkl.eu/20870415b2073a9e650e1b141dd12aa14264b41f.jpg"
	}
}