.\Administrator - A Security Risk Analysis

Can we use the built-in Administrator account in Windows?

Ask anyone in the Security space the above question, and the immediate response you'll get will be "Absolutely not". Dig deeper and you'll have the same old arguments reeled off: "It uses a well-known SID that's easy for attackers to identify", and "It's easy to brute-force because it doesn't get locked-out".

This position is just the standard rattling off of the same position they (or someone more senior) had 15 years ago. But just how much of a risk actually is it, providing you're doing things right?

Let's start by dissecting some of those arguments against it, shall we?

The Arguments

Argument 1 - It uses a well-known SID

Well, technically it uses a well-know RID (Relative Identifier), that being 500. The actual SID of the account will always start with S-1-5-21 and end with 500, with a device-specific identifier in the middle.

But that middle part can't be assumed, so this hypothetical attacker will merely need to run either
wmic useraccount where "SID like 'S-1-5-%-500'" get name,sid
or
Get-LocalUser | Where-Object -FilterScript {$_.SID -like 'S-1-5-*-500'}
and immediately they've got both the account name and the security identifier.

So you create a different account instead, job done yeah?
Oh, it's not like I could just run
net localgroup Administrators
or
Get-LocalGroupMember -Name Administrators
and suddenly get the name of the account you've just made, right?

Oh, and both of these things can be run as a standard user. 🙃

Argument 2 - It should also be renamed

The second and accompanying "recommendation" is to rename the built-in admin account to something else.

I hope you like security by obscurity, cos this is it of the highest magnitude, and as demonstrated above, completely pointless.

Argument 3 - It has no account lockout

Well, turns out even this is only partially true:

KB5020282—Account lockout available for built-in local administrators - Microsoft Support

Microsoft Support

Devices built as of Windows 11 22H2 or devices going through OOBE after the October 2022 Windows Cumulative update will have Network Logons locked out after 10 failed attempts within 10 minutes, and be locked out for 10 minutes.
Additionally, password complexity for .\Administrator is enforced if the account is enabled.

I say partially true because "Console logons will still be allowed during the lockout period." However, it's more secure than you think, so I'm also calling this argument bunk.

The Reasoning

The historic concern about this account usually boils down to them being highly privileged accounts (making them the best target), but organisations regularly used to use the same password across devices, making lateral movement and privilege escalation ridiculously simple.

But that's basically it - Historic concern of what has frankly always been terrible practice.

Is that concern still valid in 2024 and beyond? What are our options?

The Resolution

Well, turns out that technology advances, and other solutions exist!

The Weaksauce - Create A Different Account 👎

I see many people using (or being told to use) a separate account.
The major problem with this approach is, and I'm not going to sugar-coat it:

Creating a local account in Intune SUCKS.

And it sucks because you've got one of two options:

1. Use the Accounts CSP.
2. Use a PowerShell Script.

Using the Accounts CSP sucks because a) You have to use a Custom OMA policy, and b) It will always show as failed in Intune.

Using a PowerShell script sucks because when in the history of IT have historic scripts been properly documented, managed and reverted at the end of their lifecycle? Never.

Moreover, you're going to have the password for that account the same everywhere, and neatly documented in plain text in that Intune policy. You know, perpetuating the whole issue that existed in the first place.

AWFUL! 🗑️

The GOAT - Windows LAPS! 🐐

Windows LAPS is the far superior successor to the on-prem legacy Microsoft LAPS implementation that means we can easily deploy a strong set of base configuration to devices to automatically manage, expire, rotate and escrow a strong password that's then stored directly against the device object in Entra ID.

Even better, Windows LAPS supports Entra role-based access control so the initial access to, and auditing of access of those passwords ensures that (as part of a wider "Defence-In-Depth" strategy) only people who should have and need access to those passwords is able to do so.

In Intune, and via Endpoint Security > Account Protection, we can create a LAPS policy such as the one below:

And just like that, our built-in .\Administrator account has a complex, 21-digit password that will apparently take somewhere between "centuries" and "three hundred sextillion years" to crack.

Good luck in doing that in the 7 days before it automatically expires and cycles the password...

So in my opinion, given the above mitigating factors, utilising the built-in Admin account is no worse than disabling it and using a different account, and actually much better because to create that account you'd either have to resort to a CSP that will always report a failure, or a script which can cause future issues as people just forget it exists.

And in not my opinion, the CIS agree! In their latest Intune Windows benchmark, the recommendation to create a different admin account is entirely missing (because they recommend enabling Windows LAPS), so the subsequent recommendation to "Rename administrator account" states:

(The guidance for this setting assumes that the Administrator account was not disabled, which was recommended earlier in this chapter.)

So that's settled then. Using anything other than .\Administrator secured and managed via Windows LAPS is a complete waste of your time and in fact could introduce risk rather than solve it.

Lovely.

Future Improvements

But what if "someone" in your org just refuses to accept that...

Right now, the policy manages the built-in RID 500 account (regardless of it's name) by default. You can specify a different account name there in the policy, but it will not automatically create the account.

Thanks to the LAPS CSP documentation, there is some additional configuration and functionality becoming available as of Windows 11 24H2 which you can play with right now if you've got a Windows Insider build and make a custom OMA policy:

EDIT: And as if by magic, 24H2 was released. You'll still have to use a Custom OMA for now though...

The magic comes from the following three policies:
- AutomaticAccountManagementTarget
- AutomaticAccountManagementEnabled
- AutomaticAccountManagementEnableAccount
These will do precisely what it says on the tin, and not only create a brand new admin account, but enable it and manage the password for it automagically!

The second exciting policy in the above list (for anyone who's dealt with LAPS already) is around the password complexity. LAPS passwords are rather unwieldy for those of us in IT, so the ability to use passphrases could really help if you're in a remote situation with tooling that can't easily copy/paste from the Intune UI, right?
PasswordComplexity values 6, 7 or 8 to the rescue!

You may also notice the account it creates (named WLapsAdmin by default) has a numbered suffix. There's even configuration (AutomaticAccountManagementRandomizeName) to also rotate this when the LAPS password expires, meaning not only the password, but the account name is rotated when it expires or after use!

So for an account you should be using as an absolute last resort, could this be the final nail in the coffin for the ridiculous .\Administrator arguments?

I'd bet money on it...