Proactive Security: Managing the Administrator Account
The administrator account is perhaps one of the most sacred things there is on your network. I am not talking about the Domain Administrator account however, I am referring to the local administrator account. Obviously the domain administrator account has the most power out of any account in your network, but the fact of that matter is that you shouldn’t be logging in with this account anywhere anyways, and it is something that should be nearly impossible to crack from a hackers standpoint.
The local administrator account is where it all begins. If someone is going to break into your network the first thing they will need is to gain administrative priveleges on a machine. If you can protect this account successfully then you are doing a good job of stopping internal attacks at the front line.
This being the case, how do you protect this account? Obviously, the first thing you will want to do is use a strong password. People should not be logging in to computers with this account so it is okay to make it something insanely long that nobody would really want to type. Be sure to use uppercase letters, lowercase letters, numbers, and even a few symbols when setting these passwords. In larger environments you will also want to make sure that the administrator accounts on all your computers vary by location. It is not too pratical to make a different password for every single computer, however you can make multiple passwords for various departments, locations, subnets, etc. These passwords should be changed frequently, as in monthly. If you want to get really creative you can do some scripting paired with group policy to make this task a lot easier.
One more thing you can do is to to completely disable the administrator account all together. This will make sure nobody is logging into it. However, this isn’t always feasible in some cases. Another solution I have often heard is renaming the administrator account. If you rename your administrator account to something other than “admin” or “root” that adds a completely new step of enumeration an attacker has to go through before beginning to try and compromise a system. A lot of the times you can deter an attacker just by making them jump through some extra hoops along the way.




Couldn’t agree more, especially after seeing how quickly open source tools like Ophcrack (http://ophcrack.sourceforge.net/) can crack local passwords. It’s a great tool to test out the security of your local admin passwords.
Also, don’t forget to lock down that BIOS!
I couldn’t agree more, but there are more things you can do to protect your Administrator account.
1. Don’t login to the administrator account on an untrusted machine. This includes remotely accessing your machine. I had a friend who VNCed to his box at home and used his admin account. The machine he VNCed from had a key logger installed on it and someone was able to access his machine from a remote location. No amount of password complication will protect from this.
2. Using NTLMv2 instead of NTLM. This can be changed via a group policy on a domain or a registry hack. As for the exact settings, you’ll have to google that yourself. By Default Windows uses NTLM (NT LanManager) hashes to hash the passwords. These are the types that are cracked with programs such as Ophcrack. By changing the hashing method, it’ll be much more difficult to crack a password if someone has physical access.
3. Changing the name of the Administrator account. This will cause the person to have to FIRST find the admin account name before they can crack the password. This adds much more complexity.
I’d also caution about believing that the administrator account is secure by changing the name (security by obscurity has serious limitations)… if you’ve not secured your machines well, the SID doesn’t change. Even without credentials, something like sid2user/user2sid can provide the new username.
Not to say that I don’t, I just don’t count on it meaning much. We also use the same local passwords on large banks of machines – and I’d argue that even if although some of us are forced to use common passwords – make sure a *local* workstation admin password is never the same as a *local* server admin password… and that DMZ/internet exposed servers never share passwords with other servers. Breaking it down even further is wonderful – but there are administrative trade-offs.
I heartily agree with you – Think of a worm loose on a machine where it is impersonating the admin account – which machines can it infect/harm with that username/password combination?
-aprilmj