How to Turn Local Admin into Domain Admin
by David Dunn (unbr34k4bl3@gmail.com)
What is a Domain Admin?
On Microsoft Windows-based hosts and networks, there are basically two kinds of user accounts: administrators and users.
Administrators can install software, create and delete users or files, and generally do whatever they want. Users, on the other hand, are restricted to a minimum set of permissions usually defined by their function within the organization.
These two roles are further divided by scope into local admins/users and domain admins/users.
Domain users are generally more privileged than local. For example, domain users typically have access to more PCs and network resources than local users. Domain admins are, by default, local administrators on all hosts joined to the domain.
Therefore, domain admins have all the power and are what we would like to become.
Because users may need to use legacy software, utilize specialized hardware, etc, it is not uncommon for domain users to be local administrators on their own PCs, if not on multiple PCs, within the organization. It is this common configuration mistake that we will exploit in order to become domain admins and further our quest for total global domination.
How Are We Going To Do That?
There are countless ways to do this (the use of hardware or software keyloggers comes immediately to mind), but to better clarify and illustrate the severity and ease of exploitation of this issue, our example will be as non-technical and unsophisticated as possible.
We require no programming knowledge, no sophisticated exploit code, and no tools to be downloaded; just a simple, three-line batch file so small that you can memorize and type it into the target machine yourself.
The Setup
In our fictitious target environment, there are four computers, all running variations of Microsoft Windows and all joined to the same domain:
TargetPC: A standard Windows XP PC on which you are a local administrator. How did you get to be local administrator? It was already set up that way (and if it wasn't, you read 2600 so obviously you know how to use things like hardware keyloggers, chntpw , and/or social engineering to get you that far, right? ;) It could be a kiosk for accessing a store catalog or for filling out a job application, a PC in an Internet cafe or library, or your regular work PC at your school or place of business.
EmployeePC: A PC to which you don't have physical access but which is used by an employee within the organization. If we were executing this attack remotely (for instance by emailing our batch file to an employee within the organization) this, rather than TargetPC, would likely be our starting point.
AdminPC: The PC of one of the organization's domain admins. You don't have physical access to this PC either. It is very likely that this PC is (at least at a basic level) set up very similarly, if not identically, to EmployeePC.
ADServer: The domain controller of the organization. You don't have physical access to this machine, and no one is likely to be logging into it any time soon.
All the PCs are running XP, the server is running Windows Server 2003, and all of them have the default administrative share C$ enabled. Even though it's 2010, this is still a common setup in many, if not most, organizations.
The Plot Thickens
So how do we turn our current local admin status into domain admin?
The easiest, most direct way would be to just create a simple, two-line batch file in the All Users startup folder:
that reads:
If this batch file was run by a domain admin, the first line would create a domain user named hacker with the password Iam31337, and the second line would add that user to the Domain Admins group, giving our hacker user access to every Windows computer joined to the domain.
Since our batch file is located in the All Users startup folder, it will be run by any user who logs into this computer.
If the organization's help desk employees are members of the domain admins group, an easy way to get our batch file executed by a domain admin is to do some kind of simple sabotage to the currently logged-in user's account (especially if this is a kiosk that is set to auto login) and then wait for the help desk to come log in with their own account to fix it.
There's always the possibility that the help desk employees aren't members of the domain admins group (some creative use of the net group /domain and net user /domain commands could provide us with that information), so instead of relying on one of the domain admins logging on to this computer, we'll expand our attack to every computer on which we are a local admin and from there exponentially throughout the organization's network until a domain admin logs onto a machine on which our batch file is active and we get what we want.
The best part is that once we set this up on one PC, the rest is entirely automatic.
The NET VIEW command will give us a list of all the computers on the domain. What we will do then is use a for loop to copy our batch file to every computer on the domain on which our user is a local admin. The new batch file that will do this looks something like this:
net user /domain /add hacker Iam31337 net group /domain "Domain Admins" /add hacker for /F %%i in ('net view') do copy /Y %0 "%%i\c$\documents and settings\all users\start menu\programs\startup"As you can see, the top two lines remain the same.
We still try to create our user and add it to the domain admins group when our batch file is executed (regardless of who executes it).
The third line then attempts to copy our batch file to every computer in the organization's domain.
For every computer with an open C$ share (enabled by default on Windows XP) and on which that user is a local admin, it will succeed.
The best part is that this will run as whichever user happens to log into the computer, so, given the following setup:
Username Local Admin On Domain Admin? MyUser TargetPC No EmployeePC EmployeeA EmployeePC No AdminPC AdminUser TargetPC Yes EmployeePC AdminPC ADServer1.) We log in as MyUser and run our batch file. It tries to create our hacker user and fails and then copies itself to TargetPC and EmployeePC.
At this point, the automation begins and we can go do something else while we wait for the following scenario to play out. We might just go home and run a Nmap scan on the organization's network to see if we can find a server where we can log in remotely once our domain user has been created.
2.) EmployeeA logs in to their PC when they get to work in the morning, and our batch file runs under the context of their user. It tries to create our hacker user and fails and then copies itself to AdminPC.
Remember, both AdminPC and EmployeePC were probably set up using the same set of criteria or maybe even the same hard disk image. There is a good possibility that regular users will be local admins on at least one PC in the organization where a domain admin will log in.
3.) The next time AdminUser logs in to AdminPC, our batch file runs as AdminUser and, when it tries to create the hacker user, it succeeds! It also copies itself to ADServer, the last remaining machine on the network where it could have done any other potentially damaging stuff we wanted it to do.
At any rate, we've got our domain admin user now, and the organization's Windows domain is ours.
We can log in and run programs on any PC on the domain, such as VNC (for remote access), keyloggers or sniffers (for continuing to expand our access or steal confidential information), servers (for sharing warez), or whatever else we want.
The Moral
While the method described here is noisy (hopefully to aid in the learning process), keep in mind that this attack could just as easily be carried out in total invisibility by a program sent to a user in an email attachment or downloaded by a vulnerable web browser from a malicious web page.
Using these same techniques (or some slightly more sophisticated ones), it could spread through a network and have the potential to do much more damage.
The moral of this story: domain admin access needs to be assigned to as few users as possible, and local admins should only be those same domain admins. Seriously, it is that big of a deal.
If one user set as a local admin downloads a file like the one we used here, the next time a domain admin logs into their PC, your network is pwned!
Shouts to The Brew Crew