UACMe: a method table for AutoElevate UAC bypasses on Windows

What UACMe is for and who should touch it

UACMe addresses a narrow problem: showing that a standard administrator account, with UAC on its default setting, can start a process with elevated rights without the consent dialog. The README frames the project as a demonstration of UAC bypass techniques and "an educational resource for understanding Windows security mechanisms". That framing matters. The tool is not a privilege escalation exploit against a patched system in the sense of memory corruption; it drives binaries that Windows itself marks as auto-elevating, and it is the method table, not the executable, that carries the knowledge.

The intended audience is people who already understand Windows integrity levels and want a working reference implementation of each known technique. The README lists system requirements as Windows 7, 8, 8.1, 10 and 11 on x86-32 and x64, client editions, with the note that some methods work on server versions too. It also states the account requirement plainly: an administrator account with UAC at default settings. A standard user account is not the target case, and nothing in the README suggests UACMe escalates from one.

The method table is the product

The core mechanism is a numbered list of bypass methods compiled into one binary. Each entry in the README documents an author or malware family the technique is attributed to, a type such as Dll Hijack, AppCompat or Elevated COM interface, the method name, the target executable or registry key, the component involved, the internal implementation name, the Windows build where it starts working, the build where it was fixed, and how it was fixed. Method 1, for example, is attributed to Leo Davidson, is a Dll Hijack against \system32\sysprep\sysprep.exe using cryptbase.dll, implemented as ucmStandardAutoElevation, works from Windows 7 (7600) and was fixed in Windows 8.1 (9600) because sysprep.exe hardened its LoadFrom manifest elements.

That structure is the reason the project is worth reading even if you never run it. The fixed-in and how fields turn the table into a timeline of Microsoft's hardening work: manifest changes, DLLs moving into \KnownDlls, the removal of the WUSA /extract option, changes to the ISecurityEditor interface method, and AppInfo elevated application path control hardening. The tool itself is thin by comparison. A method number selects an entry, the entry performs its sequence, and the elevated process starts.

Installing UACMe and running a first method

The repository has no installer and no package manager entry. The README documents usage only, and the top-level layout shows a Bin directory alongside Source, so the practical route is the prebuilt executables in Bin or a build from Source. The README gives no build instructions, so treat the binaries as the path of least resistance and check the appveyor.yml build configuration if you need to compile.

Run the tool from a command line. The syntax is a method number followed by an optional executable path:

akagi64.exe 61

With no command argument, the README states the program launches an elevated command prompt at %systemroot%\system32\cmd.exe. If the method applies to your build, you get a new console running elevated without a consent prompt. If it does not, you get nothing useful, which is the expected outcome on a patched system.

To run a specific program instead of the shell, pass its full path as the second argument:

akagi64.exe 61 c:\windows\system32\charmap.exe

The README's own examples use method 23 with akagi32.exe and method 61 with akagi64.exe, so those two numbers are the ones to start with. The 32-bit and 64-bit binaries are separate; pick the one matching the target process architecture you care about.

Removed methods and why the branches exist

UACMe prunes itself. The README states that since version 3.5.0 all previously fixed methods are considered obsolete and have been removed, and that since version 3.7.0 methods fixed between 3.5.0 and 3.7.0 were also removed from the methods table. The code for the later batch is still present in the current branch for historical purposes, but it is no longer reachable through the table.

This is a real constraint, not a footnote. If you are testing a Windows 8.1 machine, the methods that worked there have been deleted from the current release, and the README points you to the v3.2.x branch instead. If you need anything fixed between 3.5.0 and 3.7.0, the pointer is the v3.6.x_plus branch. Pinning a modern release and expecting the full historical set is the most common way to be surprised by this project. The method numbering in the README also reflects the removals, so a number quoted in an older write-up may not correspond to the same technique in the current table.

Where UACMe is the wrong tool

UACMe assumes an administrator account. That single requirement disqualifies it for the scenario people most often imagine: a standard user on a locked-down machine trying to reach administrator rights. The README says the user account must be an administrator with UAC at default settings, and it says nothing about working from a lower-privileged context.

The second limitation is coverage. Each method carries a works-from and fixed-in range, and the README's own table shows many entries fixed across Windows 8.1, Windows 10 TH1, TH2 and later builds. A method that worked on 7600 may be dead on a current release, and the table is the only place that tells you so. There is no runtime capability probe described in the README; you select a number and observe the result.

The third is operational. The README carries a warning that the tool demonstrates security vulnerabilities that could be exploited maliciously and instructs the reader to use it responsibly and only in controlled environments. There is no documented rollback, no cleanup command and no uninstall procedure in the README. Whatever a method changes on the target, the README does not describe how to undo it.

How this differs from a general privilege escalation framework

The natural comparison is a post-exploitation or privilege escalation framework such as Metasploit, or a UAC-focused module inside one. Those frameworks bundle exploitation, payload delivery, session management and reporting, and a UAC bypass is one module among hundreds. UACMe does one thing: it holds a catalogue of AutoElevate bypass methods and executes the one you name.

That difference is the point. A framework module is usually written against a specific target build and is validated as part of a larger chain. UACMe's contribution is the annotated table itself, with attribution, the exact target binary or registry key, and the fix that killed each technique. If you want a reproducible single-step test on a known build, the standalone binary is easier to reason about. If you want a full engagement toolchain with logging and payload handling, UACMe is not trying to be that and the README does not present it as one.

Maintenance, licensing and upgrade cost

The repository is not archived and its last push was on 2026-07-24, the same date as the v3.7.1 release. The two prior releases, v3.7.0 and v3.6.9, landed on 2026-05-22 and 2025-07-08, so the cadence is irregular rather than continuous, and each release has historically coincided with methods being removed from the table. When you upgrade, the release notes and the README method table are the two things to read, because an upgrade can silently drop the method number you depend on.

The licence is BSD-2-Clause, per the repository's LICENSE.md. That is a permissive licence, and it is worth noting that a permissive licence on a tool of this kind says nothing about whether using it is lawful or authorised in your environment. The README's controlled-environment warning is the operative guidance; the licence only governs redistribution and modification of the code.

Editorial conclusion

UACMe suits administrators, red teamers and Windows internals students who work in controlled environments and need a reproducible way to exercise AutoElevate bypasses on a test machine. It is the wrong tool for production hardening work, for anyone who wants a documented rollback path, and for older Windows builds where the methods shipped today no longer apply: the removed techniques live in the v3.2.x and v3.6.x_plus branches. Before adopting it, check the README method table for the method number you intend to use and confirm that the entry lists your Windows build as a supported range, because the table is the only compatibility statement the project publishes.

Frequently asked questions

Official sources

1. hfiref0x/UACME on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases