NCSAM/2011–Post 12–Don’t bother renaming Administrator

My argument here is much in the same vein as my previous post on choosing random usernames.

I’ve met a number of people who argue that renaming the built-in Windows Administrator account is a great security measure, because an attacker now has to guess the name of the Administrator account as well as its password.

Or they put it a little more scientifically, and say that renaming the Administrator account increases the entropy already present in the password.

If you want more entropy in the password, put more entropy in the password

Seems pretty obvious to me, really.

If your passwords don’t have enough entropy (more or less equivalent to “random” in the everyday sense of the word), add more entropy – use a wider range of characters, or simply make the minimum password length that much longer.

The system works against you

If you make the name of the Administrator account a secret, that’s really no good, because the system works against you. It does absolutely nothing to protect you. A simple call to “NET USER” will list the local users, including the local administrator, and a relatively simple ICACLS command will apply rights to the local administrator – no matter its name – on a file. And then you can list the file’s permissions – again using ICACLS – to see what the name is for that administrator.

The one argument in its favour

There is one argument I accept as moderately valid for renaming the Administrator – now you can go ahead and treat every attempt to use the “Administrator” account as an attack, because none of the valid uses of the renamed-Administrator account will use that user name.

But so many arguments against

So now for some arguments against – unlike the “doesn’t really add entropy” point above, these are areas in which renaming the Administrator account does actual harm:

  • You can’t reuse scripts and applications without having to reconfigure them so as not to use the Administrator name, but your “NotReallyTheAdministrator” account.
    • If that’s even possible for the app you want to use – I know, that would be a bad app, but when’s the last time you went a week without having to use an app with some bad behaviour?
  • You have to supply the new Administrator name to each person who has to use the account. [Re-training]
  • Your single Administrator account should already be treated as if every use is an attack, because individual administrators should have their own account, to allow for auditing and revocation. The Administrator account should be rarely used.
  • You have to change the Administrator account as soon as anyone who knows it leaves (and because anyone can find it out, that’s fairly frequently!)

And my favouritest argument of all:

  • There are very many things, more important than renaming the Administrator account in securing your systems, that you have not yet done, and which will take less time to do than implementing all the infrastructure and operational procedures required to rename your Administrator account and keep it correctly monitored and managed.
Published Tue, Oct 18 2011 19:55 by Alun Jones


# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

This was the cover story on a TechNet Magazine a few years ago.  Jesper Johansson vs. Roger Grimes, with sidebars by Steve Riley and me supporting Jesper and Roger.  I took the "it can be a good thing" side along with Roger.

Wednesday, October 19, 2011 10:43 AM by Aaron Margosis

# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

I used to take your position, and then my old boss convinced me otherwise. Also changes since then make it an even better move.

First, if someone just logs on as administrator and happens to do something to browse the network, you'll see a bunch of logons as administrator. It is in fact the reverse of what you say - you should treat most of these (at least on a large enterprise network) as benign.

On the other hand, if someone has sorted out your actual admin account name, and has failed logons, then that's either you with a typo, or a real attack, and you can pay attention.

Next, while it used to be trivial to get a system to tell you a lot of nice info remotely, that hasn't been the case for several versions, and starting with Win2k3, Windows won't tell you much of anything I consider useful as anonymous. So actually obtaining the new admin name isn't trivial any longer.

A further counter-argument is that the local admin account should _never_ be used if you can still log on to the domain, so most of your objections are things you ought not be doing to start with.

All that said, it isn't very high on my list of things to do when dealing with a new system. Just applying the latest patches and running the latest OS and apps gets you much more security. But I am convinced that renaming the admin account isn't really futile.

Thursday, October 20, 2011 10:38 PM by David LeBlanc

# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

You're right that the local Administrator account should generally not be used - and for this reason, I recommend disabling it and providing it with a long password that isn't readily accessible for use.

I'm not sure that I trust the operating system to avoid providing an API to reveal something that already isn't considered a secret. Similarly, I don't think it's likely that social engineering would be incapable of getting that information. After all, it's not like it's a big protected secret.

And if it is a protected secret, how do you rotate it out whenever someone leaves the company?

Sunday, October 23, 2011 10:12 PM by Alun Jones

# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

I don't think those APIs come into play when you're scanning a system that doesn't expose RPC; e.g., that exposes just HTTP/S, FTP, WebDAV, SMTP, SQL Server, ...

Monday, October 24, 2011 8:10 AM by Aaron Margosis

# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

Aaron, you missed the <sarcasm> tag on that comment.

Clearly, when you have that many services running on a box, or within a domain, you can't guarantee that one of them doesn't have a flaw, or a feature, that can be used to translate a RID (or simply a SDDL string) into a name.

I think you can guarantee that they won't have the ability to, say, provide a password for an administrative user, because the OS keeps that secret.

So, I put all my entropy into the password, rather than the name.

Tuesday, October 25, 2011 8:38 AM by Alun Jones

# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

While I don't think there are strong guarantees that the OS won't cough up the admin's real name (and BTW, I'm fairly sure this account name is localized, so a good attacker is prepared for that), it used to be dead easy - just ask it what the user name is for SID 500, and it would tell you this without being authenticated. Those days have been gone for about 8 years. Like most security countermeasures, it only provides some level of annoyance to the attacker. Annoying and slowing down attackers is a good thing, especially if it is cheap. This is about as cheap as it gets.

Next, I'm not terribly worried about an ex-employee knowing about this speedbump, but if I needed to reset my systems, there's this handy thing called domain policy, and I can reset them all with one change. If I break some scripts, they weren't supposed to be using those scripts anyway, so they shouldn't be messing with the BOFH, or I'll put the changes in a scheduled task and change it every day to something new.

The purpose of this is _not_ to gain entropy. The purpose is to be able to distinguish someone browsing the network who wasn't trying to hack you from someone who _is_ trying to hack you. If the account is renamed, then this is dead easy. If not, well, have fun sorting through the logs. Laziness isn't just a great quality of a dev, is it also a great quality of a sys admin or security admin.

Speaking of the password, make those unique to each system, derived from a hash, and truly awful to type.

Tuesday, October 25, 2011 5:21 PM by David LeBlanc

# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

No, I was serious.  If the HTTP server can be made to give up local account names, it's got a serious security bug that will get fixed after it's been discovered.  (Maybe I'm missing your point here...)

Tuesday, October 25, 2011 9:13 PM by Aaron Margosis

# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

Sorry I didn't take your post as seriously as it deserved, Aaron. I wish I had your faith in application authors' abilities and desires to fix the flaws that are found in their software.

It seems we're adequately demonstrating why this is such an interesting topic for discussion - everyone has several reasons for their opinions, and there really isn't a deciding statement that will cause one side or the other to flop over. I keep hoping to find that statement - one way or the other. Thanks for continuing with the comments, and if I get time maybe we'll have some more on this.

Tuesday, October 25, 2011 10:01 PM by Alun Jones

# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

I'm not arguing that it is *important* to change the -500 account name or that anyone's security policies are substandard if they don't.  I'm just saying that it can have *some* value, it's really easy, it's supported, and it shouldn't break anything legitimate.  

Wednesday, October 26, 2011 12:40 AM by Aaron Margosis

# re: NCSAM/2011–Post 12–Don’t bother renaming Administrator

I should probably also confess that I've never thought it important enough to fight when someone superior has suggested it - just mumbled about the process it might take to train administrators to understand the way in which they should fetch the right name for the right target machine (which should already be mostly in place for the unique password for each machine). And then made it someone else's job to make it work. That way, if it screws up, it's not because I subconsciously sabotaged it :)

Wednesday, October 26, 2011 10:38 PM by Alun Jones

Leave a Comment

If you can't read this number refresh your screen
Enter the numbers above: