An exploit, UAC-TokenMagic, was utilized as a method of UAC bypass. This allowed Vestige to plant numerous persistence methods that require an account with administrator privileges. These methods included a scheduled task, ‘Java.exe’, with full administrator privileges that runs Vestige when the computer has been idle 2 hours with no need of the token script anymore, creation of an administrative account where the attacker has the password and can use this account to attempt lateral movement from this compromised machine, and full trust in the firewall for Vestige. Hows does this exploit work? In short, according to FuzzySecurity, a token from an elevated process is duplicated, then that token’s mandatory integrity level is lowered and used to create a new restricted token. It is then impersonated and the secondary logon service is used to spawn a process with a High integrity level.
What to do:
Implement a solution of least privileges that helps ensure users, systems, and processes only have access to resources that are necessary for their task, e.g., work, school, etc. Users should not have local administrator accounts nor domain accounts with administrative privileges that are intended for IT staff.
In the below screenshot, Vestige was run again, however, this time it was run from a domain joined user account that did not have full administrator privileges. When Vestige called the function that involved loading the UAC-TokenMagic script, the following window popped up, which prevented the attacker from numerous persistence methods. Additionally, custom MMC consoles can be made for groups or users further restricting or granting permissions by restricting access to snap-ins, so even if an account is compromised the attackers are further hindered in their abilities on the machine.
It is important to note, that this did not prevent Vestige from adding itself as a StartUp task for the logged in user, loading the encoded Powershell into a registry key, nor the reverse TCP shell from providing direct access to the machine. However, even with a functional reverse shell connecting the attacker to the target, an elevation of privileges would still likely be necessary for them to accomplish may of the tasks and additional malicious behavior that would allow further compromise. The goal is to slow and irritate attackers as much as possible, ensuring that the goal they wish to accomplish requires jumping as many hurdles as possible.
A very important part of least privileges is delegation of control. This means that certain groups are given very specific privileges that can only be used within their own organizational unit (OU) that allow them to do the functions they need to accomplish. For example, password resets are a common task that help desk employees would need to do as part of their job and these positions often have high turnover rate, a policy can be implemented that gives users within that group the ability to require password resets for accounts within the OU, yet they would be unable to require a password reset for sensitive accounts, e.g., other IT staff.
There are three aspects to consider pertaining to delegation:
- The object, whether a person, resource, domain, group, etc., something is going to be given full or limited power over it.
- The person who grants authority, typically an admin, who has the ability to change permissions for that object and grants authority to someone else over the object.
- The person who receives additional permissions over the object.
Best practices for delegation:
- Documentation for policies on how authority is granted, the names of groups and permissions for those groups, and written logs of all changes to these policies is a must.
- Audit regularly and diligently.
- When assigning permissions, assign them to groups, not individual users, and grant the least privileges needed for that group to do their task.
- Delegate by OU and design those OUs on how authority will be delegated, creating any sub-OUs as necessary.
- If authority needs to be delegated to sub-OUs, do it in a way that does not contradict the authority of the parent OU.
For information on configuring privileges, MMCs, and delegation using Active Directory:
Securing Active Directory
More information on privileges and delegation: