User Access Control (UAC) is a feature Microsoft added long time ago (initially with Windows Vista) in an attempt to limit what local administrators can do on Windows. Basically, when a user logs in that is a local administrator, his session token will only have basic privileges, even though the user is actually an administrator.

In case the user wants to perform an activity that requires administrator privileges, the UAC system will ask the user to confirm the action. With modern Windows, when UAC is triggered, all applications and the taskbar is generally dimmed indicating that something important in happening.

As I do a lot of internal penetration tests, I actually quite often see that companies disable UAC for the whole enterprise. In many cases administrators complain that UAC causes them some problems and (as always in security), the easiest way is to disable the feature.

However, in a recent test I actually had an interesting challenge where UAC practically saved the day. Here is what happened.

I received a standard, non-privileged domain user account and a standard workstation, so I was able to simulate an attack by a disgruntled employee, for example. Since in basically every penetration test, reconnaissance is one of the most important activities, in internal tests I always try to enumerate and pilfer as much as possible from any internally available Windows shares.
I many cases things one can find on SYSVOL shares on domain controllers are worth pure gold – in this case I got lucky as well – I managed to find some VBS files that contained credentials for local administrators on user workstations. Sounded like game over, but was it?

Since I now had local administrator privileges, the next logical step was to use Mimikatz to dump any locally available secrets. After a little bit of tweaking to evade the anti-virus this particular customer was using, I dumped hashes and, to my disappointment, I did not find anything valuable – apart from local administrator accounts I already had.

Now, since these are local administrators on all workstations in the enterprise, one would think that somehow, we can mass pwn them. However, thanks to UAC, this is not really possible – UAC actually prevents local administrators (note that these were not domain accounts, but local accounts on each workstation, added to the local administrator group) from mapping C$ or ADMIN$ shares effectively preventing an attacker from using typical attack vectors (psexec and similar). This was probably the first case that I saw UAC really making a difference.

Of course, there was still a way to use these accounts – one can RDP to a workstation and login with the account I had (since I had plain text passwords as well), but this is not all that stealthy. Since I was debating mass pwnage possibilities, one of my friends and a great security researcher @k0st, quickly wrote a cool AutoIt script that one can use to automatically login to remote workstations and execute arbitrary commands. So I used the script to enable WinRM and modify configuration automatically on hundreds of workstations. You can find the script at https://github.com/kost/rdpcmd

The lesson of this story was that one should not just blindly disable UAC – there are cases where it definitely helps. As with any other security control, it will not solve everything, but can slow down an attacker or make him become more visible, which in the end can help defenders.

--
Bojan
@bojanz
INFIGO IS