1

A developer managed to open a console application with NT Authority/System rights at the startup screen before logging in.

From that command prompt it is possible to execute arbitrary programs like Notepad, Internet Explorer and even Explorer to get a start menu.

With those local System rights, is it easy to acquire domain admin rights?

OS: Windows 7 SP1 x64

Update

This is how the "hack" was done. If you google for it, it seems quite well-known. To do it, you need admin rights, which were granted to our developer.

  • Take ownership of Utilman.exe
  • Replace Utilman.exe by a copy of cmd.exe
  • Restart the PC to get to login screen
  • Click on the accessibility icon

Why the hell do all the websites list "browse the web without logging in" as one of the use cases? None of the top 10 websites provides a way to fix this "security issue" (or whatever we should call this).

Improve this question
1
  • It's a backdoor, is what it is. You fix it by formatting and reinstalling the OS (since you have no real way of knowing what was done by whom), then NOT giving admin rights to this negligent developer... (or at least give him some training on some basic security awareness....)
    – AviD ♦
    Commented Mar 18, 2014 at 10:11

3 Answers 3

Reset to default
4

In addition to the other answers there is actually a way to grab domain admin credentials. One of the functions of Windows is to cache credentials for a while when opening a login. With Local/System rights you are actually able to extract these from memory (out of the LSASS process) using a tool like Mimikatz.

The catch is that someone who has Domain Administrator rights needs to have logged in onto the system recently. From there you just steal his credentials and poof domain admin.

Improve this answer
2
  • Excellent point. And as long as you're on that, he can then easily install a rootkit in the GINA / CredProv, so any domain admin that logs in in the future will also have his password stolen....
    – AviD ♦
    Commented Mar 18, 2014 at 10:43
  • Ok, domain admins should not have logged on. Thanks for the reference. It seems that our IT department should not only think about admin rights but also about the debugging privilege.
    – Thomas Weller
    Commented Mar 20, 2014 at 21:27
5

What kind of application is this, and how does it get executed before logging in?
Actually, scratch that, a better question would be: WHY is this application allowed to run.

Yes, it is very dangerous.
This allows arbitrary users to run any system command. The process account is known as LocalSystem, which is the only local account with more privileges than the Administrator.
This application can do a.n.y.t.h.i.n.g. Anything at all on this system: change the admin's password, install services, attach to memory of any process, anything anything. On this system.

Additionally, depending on configuration, the LocalSystem application could probably authentication to other machines in the domain as the machine's computer account. E.g. for registering changes in ActiveDirectory, etc.

However, one thing specifically you asked about - acquiring domain admin rights. This is not so simple (assuming the application is not running on the DC), since we are talking about local privileges.
So, while that machine is completely violated (as in, nuke it from orbit), the rest of your domain is (relatively) safe. (well, at least from this application).

Improve this answer
3
  • Of course I'm working on the how and why question as well. I specifically asked for the domain because if that is easily compromised, I probably need to consider disconnecting the servers and checking for intrusion.
    – Thomas Weller
    Commented Mar 17, 2014 at 21:24
  • Of course, I assumed you would be - didn't mean to imply otherwise :-) Like I said, the domain admin accounts are not going to be compromised (assuming this is not on the DC), however the domain computer account for this machine is. So, it's a question what "privileges" this computer account has across the domain. Assuming "more than nothing", if you believe that arbitrary anybodys had complete access to it, I think you should disconnect it. Though if you have reason to believe that only e.g. trusted sysadmins had access, then it's a risk management decision...
    – AviD ♦
    Commented Mar 17, 2014 at 21:29
  • FYI: I've updated the question with background info. The Utilman.exe hack seems to be old and known well.
    – Thomas Weller
    Commented Mar 18, 2014 at 9:45
0

This exploit gives the user a way to get LocalSystem permission, which is a bit more than an admin can do on that machine, but still only affects the system on which that hack was performed.

In order to use this hack to gain more rights on your domain controller, an attacker would have to do this on the domain controller, which requires admin rights. That means the attacker would already need to know the admin password of the DC. When the attacker has admin access on the DC, they can already do all sorts of evil stuff anyway, so this is the least thing to worry about.

The "fix" for that hack is simple: Don't give users admin rights. Give them normal user accounts and use permissive group policies which allow them to do whatever they need to be doing, but not to change system files. But keep in mind that any software-enforced permission system can be circumvented when you have physical access to the machine. So the "real fix" is not to hire people you can't trust.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .