{ "id": "5d4101b9-7ef5-4383-b99e-b20bf849a856", "created_at": "2026-04-06T00:08:18.393838Z", "updated_at": "2026-04-10T03:31:17.87073Z", "deleted_at": null, "sha1_hash": "81286d3674bc17131c71aadc3007c174b4d8045d", "title": "Bypassing UAC using App Paths", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 600735, "plain_text": "Bypassing UAC using App Paths\r\nPublished: 2017-03-14 · Archived: 2026-04-05 21:21:52 UTC\r\nOver the past several months, I’ve taken an interest in Microsoft’s User Account Control (UAC) feature in\r\nWindows. While Microsoft doesn’t define UAC as a security boundary, bypassing this protection is still\r\nsomething attackers frequently need to do. The recent Vault7 leak confirms that bypassing UAC is operationally\r\ninteresting, even to nation states, as several UAC bypasses/notes were detailed in the dump. On the purposefully\r\npublic side, check out the UACME project by @hfiref0x for a great collection of existing techniques.\r\nMicrosoft seems to have a renewed interest in UAC, finally fixing many of the issues highlighted by publicly\r\ndisclosed bypasses. While these fixes are only in newer versions of Windows, the active response from Microsoft\r\ndrives me to continue searching for UAC bypasses. I’ve previously blogged about two different bypass\r\ntechniques, and this post will highlight an alternative method that also doesn’t rely on the IFileOperation/DLL\r\nhijacking approach. This technique works on Windows 10 build 15031, where the vast majority of public bypasses\r\nhave been patched.\r\nAs some of you may know, there are some Microsoft signed binaries that auto-elevate due to their manifest. You\r\ncan read more about these binaries and their manifests here. While searching for more of these auto-elevating\r\nbinaries by using the SysInternals tool “sigcheck“, I came across “sdclt.exe” and verified that it auto-elevates due\r\nto its manifest:\r\n*Note: This only works on Windows 10. The manifest for sdclt.exe in Windows 7 has the requestedExecutionLevel\r\nset to “AsInvoker”, preventing auto-elevation when started from medium integrity.\r\nhttps://enigma0x3.net/2017/03/14/bypassing-uac-using-app-paths/\r\nPage 1 of 4\n\nWhen observing the execution flow of sdclt.exe, it becomes apparent that this binary starts control.exe in order to\r\nopen up a Control Panel item in high-integrity context:\r\nI became curious how sdclt.exe obtains the path to control.exe. Looking again at the execution flow, sdclt.exe\r\nqueries the App Path key for control.exe within the HKEY_CURRENT_USER hive.\r\nCalls to HKEY_CURRENT_USER (or HKCU) from a high integrity process are particularly interesting. This\r\noften means that an elevated process is interacting with a registry location that a medium integrity process can\r\ntamper with. In this case, I saw that “sdclt.exe” was querying\r\nHKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\control.exe. If you aren’t familiar with App\r\nPaths in Windows, you can read more about the topic here.\r\nAs it stands, sdclt.exe looks for the App Path of control.exe in the HKCU hive. Essentially, this binary is asking\r\n“what is the full path of control.exe?”. If that key isn’t found, it continues the typical Windows search order. Since\r\nit is searching in a place that can be modified, we can populate the key.\r\nhttps://enigma0x3.net/2017/03/14/bypassing-uac-using-app-paths/\r\nPage 2 of 4\n\nGuess what happens once sdclt.exe is started again? You guessed it. Sdclt.exe queried our newly created App\r\nPaths key for control.exe, resulting in cmd.exe getting returned.\r\nLooking at Process Explorer (or whoami /groups), I was able to confirm that cmd.exe is indeed high integrity:\r\nIt is important to note that this technique does not allow for parameters, meaning it requires your payload to be\r\nplaced on disk someplace. If you try to give the binary any parameters (e.g, C:\\Windows\\System32\\cmd.exe /c\r\ncalc.exe), it will interpret the entire string as the lpFile value to the ShellExecuteInfo structure, which is then\r\npassed over to ShellExecuteEx. Since that value doesn’t exist, it will not execute.\r\nTo demonstrate this technique, you can find a script here: https://raw.githubusercontent.com/enigma0x3/Misc-PowerShell-Stuff/master/Invoke-AppPathBypass.ps1\r\nhttps://enigma0x3.net/2017/03/14/bypassing-uac-using-app-paths/\r\nPage 3 of 4\n\nThe script takes a full path to your payload. C:\\Windows\\System32\\cmd.exe is a good one to validate. It will\r\nautomatically add the keys, start sdclt.exe and then cleanup.\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\r\nHKCU\\Microsoft\\Windows\\CurrentVersion\\App Paths\\Control.exe.\r\nCheers,\r\nMatt\r\nSource: https://enigma0x3.net/2017/03/14/bypassing-uac-using-app-paths/\r\nhttps://enigma0x3.net/2017/03/14/bypassing-uac-using-app-paths/\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://enigma0x3.net/2017/03/14/bypassing-uac-using-app-paths/" ], "report_names": [ "bypassing-uac-using-app-paths" ], "threat_actors": [ { "id": "23dfc9f5-1862-4510-a6ae-53d8e51f17b1", "created_at": "2024-05-01T02:03:08.146025Z", "updated_at": "2026-04-10T02:00:03.67072Z", "deleted_at": null, "main_name": "PLATINUM TERMINAL", "aliases": [ "APT-C-39 ", "Longhorn ", "The Lamberts ", "Vault7 " ], "source_name": "Secureworks:PLATINUM TERMINAL", "tools": [ "AfterMidnight", "Assassin", "Marble Framework" ], "source_id": "Secureworks", "reports": null } ], "ts_created_at": 1775434098, "ts_updated_at": 1775791877, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/81286d3674bc17131c71aadc3007c174b4d8045d.pdf", "text": "https://archive.orkl.eu/81286d3674bc17131c71aadc3007c174b4d8045d.txt", "img": "https://archive.orkl.eu/81286d3674bc17131c71aadc3007c174b4d8045d.jpg" } }