{
	"id": "46fab3ec-1bd9-4e89-ada6-89a0172a2e91",
	"created_at": "2026-04-06T00:08:18.175192Z",
	"updated_at": "2026-04-10T03:21:17.905135Z",
	"deleted_at": null,
	"sha1_hash": "cce8943a3fbdaef8aeb3fbb2ddff569d088f0e16",
	"title": "“Fileless” UAC Bypass Using eventvwr.exe and Registry Hijacking",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 318071,
	"plain_text": "“Fileless” UAC Bypass Using eventvwr.exe and Registry Hijacking\r\nPublished: 2016-08-15 · Archived: 2026-04-05 18:57:37 UTC\r\nAfter digging into Windows 10 and discovering a rather interesting method for bypassing user account control, I\r\ndecided to spend a little more time investigating other potential techniques for getting around UAC. Currently,\r\nthere are a couple of public UAC bypass techniques, most of which require a privileged file copy using the\r\nIFileOperation COM object or WUSA extraction (Windows 7) to take advantage of a DLL hijack in a protected\r\nsystem location. All of these techniques require dropping a file to disk (for example, placing a DLL on disk to\r\nperform a DLL hijack). You can take a look at some of these public techniques here (by @hfiref0x). The technique\r\ncovered in this post differs from the other public methods and provides a useful new technique that does not rely\r\non a privileged file copy, code injection, or placing a traditional file on disk (such as a DLL). This technique has\r\nbeen tested on Windows 7 and Windows 10, but is expected to work on all versions of Windows that implement\r\nUAC.\r\nAs I mentioned in my last post on bypassing UAC using Disk Cleanup, a common technique used to investigate\r\nloading behavior on Windows is to use SysInternals Process Monitor to analyze how a process behaves when\r\nexecuted. While digging into the Windows Event Log with ProcMon opened, I noticed that eventvwr.exe was\r\nexecuting some registry queries against the HKEY_CURRENT_USER hive as a high integrity process.\r\nBefore diving in too far, it is important to understand what the HKEY_CLASSES_ROOT (HKCR) and\r\nHKEY_CURRENT_USER (HKCU) registry hives are and how they interact. The HKCR hive is simply a\r\ncombination of HKLM:\\Software\\Classes and HKCU:\\Software\\Classes. You can read more about HKCR and\r\nwhy the HKLM and HKCU hives are merged here. Since these hives are merged, you can often hijack keys in\r\nHKCR:\\ by creating them in HKCU:\\Software\\Classes. Since this relationship exists between these 2 hives, any\r\nelevated process that interacts with both HKCU and HKCR in succession are particularly interesting since you are\r\nable to tamper with values in HKCU. As a normal user, you have write access to keys in HKCU; if an elevated\r\nprocess interacts with keys you are able to manipulate, you can potentially interfere with actions a high-integrity\r\nprocess is attempting to perform.\r\nNow, as some of you may know, there are some Microsoft signed binaries that auto-elevate due to their manifest.\r\nYou can read more about these binaries and the manifests here. By using the SysInternals tool “sigcheck”, I\r\nverified that “eventvwr.exe” auto-elevates due to its manifest:\r\nhttps://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/\r\nPage 1 of 4\n\nWhile digging deeper into the ProcMon output, I noticed that “eventvwr.exe” was interacting with\r\nHKCU\\Software\\Classes\\mscfile\\shell\\open\\command, which resulted in a “NAME NOT FOUND” result.\r\nShortly after, eventvwr.exe was seen interacting with the key HKCR\\mscfile\\shell\\open\\command. Looking at\r\nHKCR\\mscfile\\shell\\open\\command, I noticed that the default value was set to call mmc.exe (Microsoft\r\nManagement Console), the program responsible for loading Management Snap-Ins:\r\nAs mentioned above, calls to HKEY_CURRENT_USER (or HKCU) from a high integrity process are particularly\r\ninteresting. This often means that an elevated process is somehow interacting with a registry location that a\r\nmedium integrity process can tamper with. In this case, it was observed that “eventvwr.exe” was querying\r\nHKCU\\Software\\Classes\\mscfile\\shell\\open\\command before HKCR\\mscfile\\shell\\open\\command. Since the\r\nHKCU value returned with “NAME NOT FOUND”, the elevated process queried the HKCR location:\r\nhttps://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/\r\nPage 2 of 4\n\nFrom the output, it appears that “eventvwr.exe”, as a high integrity process, queries both HKCU and HKCR\r\nregistry hives to start mmc.exe. After mmc.exe starts, it opens eventvwr.msc, which is a Microsoft Saved Console\r\nfile, causing the Event Viewer to be displayed. This makes sense due to the fact that the Microsoft Management\r\nConsole (mmc.exe) loads Microsoft Saved Console files (.msc). You can read more about the Microsoft\r\nManagement Console and the corresponding Microsoft Saved Console files here.\r\nWith this information, I decided to create the registry structure needed for “eventvwr.exe” to successfully query\r\nthe HKCU location instead of the HKCR location. Since the (Default) value located in\r\nHKCR\\mscfile\\shell\\open\\command contained an executable, I decided to simply replace the executable with\r\npowershell.exe:\r\nWhen starting “eventvwr.exe”, I noticed that is successfully queried/opened\r\nHKCU\\Software\\Classes\\mscfile\\shell\\open\\command:\r\nThis action effectively replaced the expected “mmc.exe” value with our new value: “powershell.exe”. As the\r\nprocess continued, I observed that it ended up starting “powershell.exe” instead of “mmc.exe”:\r\nLooking at Process Explorer, I was able to confirm that powershell.exe was indeed running as high integrity:\r\nhttps://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/\r\nPage 3 of 4\n\nDue to the fact that I was able to hijack the process being started, it is possible to simply execute whatever\r\nmalicious PowerShell script/command you wish. This means that code execution has been achieved in a high\r\nintegrity process (bypassing UAC) without dropping a DLL or other file down to the file system. This\r\nsignificantly reduces the risk to the attacker because they aren’t placing a traditional file on the file system that\r\ncan be caught by AV/HIPS or forensically identified later.\r\nTo demonstrate this attack, Matt Graeber (@mattifestation) and I constructed a PowerShell script that, when\r\nexecuted on a system, will create the required registry entry in the current user’s hive\r\n(HKCU\\Software\\Classes\\mscfile\\shell\\open\\command), set the default value to whatever you pass via the -\r\nCommand parameter, run “eventvwr.exe” and then cleanup the registry entry.\r\nYou can find the script here: https://github.com/enigma0x3/Misc-PowerShell-Stuff/blob/master/Invoke-EventVwrBypass.ps1\r\nWithin the script, we have provided an example command. This particular command uses PowerShell to write out\r\n“Is Elevated: True” to C:\\UACBypassTest. This will demonstrate that the command has executed has a high\r\nintegrity process due to the fact that “Is Elevated” equated to “True” and the text file it outputs is being written to\r\na directory that a medium integrity process is not allowed to write to.\r\nThis technique differs from the other public techniques by having a few handy benefits:\r\n1. This technique does not require dropping a traditional file to the file system. Most (if not all) public UAC\r\nbypasses currently require dropping a file (typically a DLL) to the file system. Doing so increases the risk\r\nof the attacker getting caught. Since this technique doesn’t drop a traditional file, that extra risk to the\r\nattacker is mitigated.\r\n2. This technique does not require any process injection, meaning the attack won’t get flagged by security\r\nsolutions that monitor for this type of behavior.\r\n3. There is no privileged file copy required. Most UAC bypasses require some sort of privileged file copy in\r\norder to get a malicious DLL into a secure location to setup a DLL hijack. Since it is possible to replace\r\nwhat executable “eventvwr.exe” starts to load the required Snap-in, it is possible to simply use an existing,\r\ntrusted Microsoft binary to execute code in memory instead.\r\nThis particular technique can be remediated or fixed by setting the UAC level to “Always Notify” or by removing\r\nthe current user from the Local Administrators group. Further, if you would like to monitor for this attack, you\r\ncould utilize methods/signatures to look for and alert on new registry entries in HKCU\\Software\\Classes\\.\r\nSource: https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/\r\nhttps://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/"
	],
	"report_names": [
		"fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking"
	],
	"threat_actors": [],
	"ts_created_at": 1775434098,
	"ts_updated_at": 1775791277,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cce8943a3fbdaef8aeb3fbb2ddff569d088f0e16.pdf",
		"text": "https://archive.orkl.eu/cce8943a3fbdaef8aeb3fbb2ddff569d088f0e16.txt",
		"img": "https://archive.orkl.eu/cce8943a3fbdaef8aeb3fbb2ddff569d088f0e16.jpg"
	}
}