Privileger: Now you’re in control of privileges in Windows

One day, during yet another pentesting audit, I realized that I have to code everything from scratch every time. To avoid this boring repetitive task, I needed a ready-made tool for manipulations with privileges. So, I wrote Privileger and, much to my surprise, it became quite popular among hackers pentesters.

This article explains the operation principle of this tool and examines its five modes that enable you to:

• add privileges to a local account by calling just one function. In the past, this could be done only via GPO and, if my memory serves me right, it also required a host reboot, which wasn’t very convenient;
• start a process with a specific privilege added to its token;
• remove the privilege from an account. Again, in the past, GPO was used for this purpose; while now you just call a function;
• detect an account with the required privilege on a given PC; and 
• examine privileges assigned to certain account on a given PC.

Adding privileges to an account

Similar to any other project written in the C language, everything starts with the main() function that receives all the required parameters. To ensure that Cyrillic (and other) characters are displayed correctly, setlocale() is called. Then the program displays a nice ASCII banner and starts validating the input data.

If you’re going to use the first operating mode (i.e. add privileges to an account), you have to provide the following input data:

• 1 (operating mode);
• username to assign a privilege to; and 
• programmatic name of the privilege (i.e. which privilege to be added).

The programmatic name of a privilege is its name per se. There is also a so-called display name that contains its description. For instance, the programmatic name of a privilege is SeDebugPrivilege; while its display name is Debug programs.

So, you execute the following command:

To prevent typos, the program validates the username and the privilege name. Validation is implemented using the ValidateAccInfo() function, which receives the username and the programmatic name of a privilege.

Username is validated using the LookupAccountName() function. Originally, it’s used to retrieve user’s SID (security identifier) by its name, but nothing prevents you from using it to validate the username: if the computer doesn’t find a user with such a name, then the function call will result in an error.

Programmatic name of a privilege is also validated by a separate function.

A similar algorithm is used: the program calls LookupPrivilegeValue(): if such a privilege exists, everything is fine; if not, an error occurs.

After making sure that the input data are correct, the tool calls InitMode1() and passes to it the username and privilege name. Inside this function, you get a handle to the LSA of the current computer (since you are dealing with local account privileges) by calling the GetPolicy() function.

The program uses the LsaOpenPolicy function to get a handle to the LSA policy. A distinct feature of LSA is that it uses its own error codes that cannot be retrieved using GetLastError(). You have to receive the NTSTATUS value from each function that works with LSA and then pass this value to LsaNtStatusToWinError() to convert it into a human-understandable error code.

Based on the error code, you can find out what’s wrong (see the official documentation).

If the system returns to you the correct handle and you don’t see the message ERROR_ACCESS_DENIED, then you can use the AddUserPrivilege() function to assign a privilege to the user.

It takes several stages to add a privilege to a user:

1. User’s SID is identified on the basis of its username;
2. LSA_UNICODE_STRING containing the name of the privilege that has to be added is generated;
3. LsaAddAccountRights() is called; and 
4. Program checks whether the privilege has been successfully added.

To identify user’s SID on the basis of its name, the above-mentioned function LookupAccountName() is used. The trick is as follows: if you pass NULL as the buffer where SID should be stored, then the function will return the buffer size required to store this SID. This is how you find out its size. Then you allocate memory for this buffer and get the SID.

ConvertSidToStringSid() can be called to convert the SID structure into a string containing this SID,.

The privilege name must be written to the LSA_UNICODE_STRING structure that looks as follows:

The structure can be filled either manually (as I did in this project) or using a separate function (as in my tool that injects Kerberos tickets).

Finally, the LsaAddAccountRights() function is called.

The if (bEnable) condition makes it possible to use the AddUserPrivilege() function not only to add, but also to remove privileges from an account (to be addressed a bit later). The function that adds a privilege doesn’t require anything special: LSA handle, user SID, and name of the privilege to be assigned to this user. If the privilege has been successfully added, then the PrintTrusteePrivs()function is called: it displays all privileges assigned to a given account.

Using the function LsaEnumerateAccountRights(), you find out the number of user privileges; while their names will be stored in the buffer PLSA_UNICODE_STRING. Then you parse them in a loop and concurrently find out their display names using LookupPrivilegeDisplayNameW().

This is how privileges are added to an account.

Starting a process with a privilege

A distinct feature of the second operating mode is that you have to verify not only the privilege name, but also the path (otherwise, funny exceptions might occur in the midst of a pentesting study). I implemented the validation of this information in the ValidatePathInfo() function.

The simplest way to validate the path (i.e. make sure that the file path specified by the user actually exists) is to use the PathFileExists function. It returns TRUE if the path exists and FALSE if it doesn’t.

After validating the input data, the program proceeds to InitMode2():

This process can be divided into several stages:

1. Current process token is assigned to current thread token;
2. A handle to this token is received;
3. A privilege is added to the token; and 
4. The process with the modified token starts.

The first two steps are pretty simple. A process token can be assigned to the token of the current thread using ImpersonateSelf(); then you get a handle to it using OpenThreadToken(). Again, a separate function is used to add privileges. Such modularity makes it possible to take a function from one project and simply copy it to another one.

First, the program creates a special structure and passes the privilege LUID to it. LUID is an interpretation of a specific privilege in the system; based on it, Windows understands what privilege it’s dealing with. You can use LookupPrivilegeValue() to get LUID. To add the privilege to a token, you pass the newly-created structure to the AdjustTokenPrivileges function. Note that you can pass several privileges to it at once. For instance, you can simultaneously add SeDebugPrivilege and SeImpersonatePrivilege, but in this particular case, it’s not required.

After that, the thread of execution returns to the InitMode2() function; using it, the program calls the CreateProcessWithToken() function that creates a process with the token containing the newly-added privileges.

Removing privileges from an account

Sometimes you have to perform the opposite operation: remove a certain privilege from an account. The beginning of this procedure is similar to the first operating mode: the program validates the username and the privilege. Next, you get a handle to the LSA policy of the current PC and call AddUserPrivilege(). Remember this function?

If you pass FALSE as the last parameter, the following condition will be triggered.

As a result, the privilege will be removed from the specified account by calling the LsaRemoveAccountRights function. Then PrintTrusteePrivs() is called to display the updated list of user’s privileges.

Searching for objects with certain privileges

In this mode, you have to pass to Privileger the name of privilege you are looking for and the name of computer to be searched for it. For instance, if you want to detect all accounts having the SeDebugPrivilege privilege on the WINPC workstation, use the following command:

In this mode, I decided not to validate the computer name: if you specify an invalid name, the LsaOpenPolicy() function will return error code 1722.

The entire operation has been implemented in an elegant function listed below:

First, the function tries to get an LSA policy handle on the computer whose name was specified. For this purpose, the standard LsaOpenPolicy()is used. Then the function creates special structures to be passed to LsaEnumerateAccountsWithUserRight(). The output of this function represents an array of objects that have the required privilege. Once again, LSA_UNICODE_STRING is used to store and pass privileges. The function receives an array of objects and starts parsing it. The array includes the structure LSA_ENUMERATION_INFORMATION that contains only the SID:

Then the program converts the received SID into a standard username using the above-mentioned ConvertSidToStringSid() function and passes it to the LookupAccountSid() function to retrieve the username based on its SID. The last parameter specifies the enumerable type SID_NAME_USE in order to determine the type of the object. In most cases, it’s SidTypeUser (regular user), but you never know… Accordingly, I added short notes: “this is a user” and “this is a group.”

Examining privileges assigned to an object

The last, fifth, operating mode makes it possible to view privileges assigned to a specific account on a PC. Its beginning is rather unusual:

You cannot validate the username and computer name without auxiliary RPC functions. Therefore, the program gives you 500 ms to review your input and make sure that it’s correct. This measure reduces the traffic and unnecessary noise. The main function is quite simple:

Everything revolves around the PrintTrusteePrivs()function created earlier. All you have to do is get an LSA policy handle on the target PC and then call LookupAccountName() to get the SID, which will be passed to the function that displays the existing privileges of an account. Isn’t this cool?

Conclusions

Overall, privileges in Windows represent a very broad and exciting topic. And Privileger can be easily expanded: you are welcome to elaborate, polish, and correct my divinely perfect code.

Should you have any questions or problems while using the tool, feel free to contact me. I will fix bugs (if any) and give a piece of advice.