Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Windows NT/2K/XP/2K3 manual removal of the Administrator account

By esrever in Technology
Mon Jul 05, 2004 at 02:28:12 PM EST
Tags: Software (all tags)

Or, how to remove the power of the builtin Administrator account without deleting it (delete it if you like ;-).


The following is an article that I wrote some time ago after doing some testing and research with a VMware Windows Server install I had set up.  It answered some questions I had and proved useful on at least one occasion.  I have had it posted on my homepage for some time now, and given the number of hits I get from google from variations on 'hack administrator XP', I thought it might be of interest to the kuro5hin crowd.


Before I begin, I am obliged to point out that editing the Registry in Windows is risky at the best of times, and that following the steps in this article is downright nuts. Microsoft surely will not help you if you touch your registry even following one of their KB articles (Microsoft Knowledge Base). If you mess this up you have every chance of rendering your system completely unusable (I ought to know, I did it a good dozen+ times getting this sorted out). Even if you follow these steps perfectly you could still render your system mangled by unintentionally removing all administrative accounts. Read the entire article first, then, if you're still really keen, try it out on a non-production, development box ONLY until you are satisfied that you understand exactly what you are doing and why. After that you're on your own ;-) Please understand that this is not an escalation-of-privileges exploit or anything like it; with the exception of the one instance that I mention at the end of this article, you need to already have administrative privileges to perform these steps.

First a rather lengthy backgound...

I ran into a situation several years or ago where I was presented with the problem that for a truly high-security machine --where security trumps other concerns (like always being able to access a machine no-matter-what, etc)-- that it was necessary to be able to either remove or disable the builtin Administrator account in NT. This is a problem because NT doesn't provide you with any way to do this.

So, I spent a rather lengthy amount of time working my way around the SAM (the Security Accounts Manager, a piece of the Windows Registry database that holds user security information) and was able to finally make sense of how it controls access to its security groups. I took this approach, as NT grants privileges based on group membership, rather than individually (that is; if you create a new local user account and put it in the local Administrators group, it is effectively as good as the builtin Administrator account).

Based on that reasoning, I decided that the easiest way to achieve my purpose was not to try and delete the Administrator account, but to simply remove it from the local Administrators group (thus removing its privileges). Armed with an understanding of how NT controls its groups in the SAM, I removed the builtin Administrator account from the local Administrators group, and voilà! I have a builtin Administrator account that now can't even log in to the server/workstation/whatever. It is effectively a member of no groups, and thus has utterly no rights (less even than a Guest).

An explanation of the issues and technical details

NOTE: You can follow through these steps in real life on a test computer to see what I'm talking about and it will be a lot easier to understand.

Make sure that the Scheduler service (Task Scheduler) is running as the LocalSystem account and that it is allowed to Interact with the Desktop (this information is accessible via the Administrative Tools applet in the Control Panel). Then open a cmd console and type the command:

at <some-point-in-the-near-future> /interactive cmd

This will launch a cmd.exe window running under the security context of the LocalSystem account. Any program you then launch from this window will run as LocalSystem.  This is highly desirable as LocalSystem processes on Windows run in ring0, or kernel space. Use it to run regedit.exe (it's easier to follow what's happening with this tool than regedt32.exe...). Drill down to:


It will hold a single value of type REG_BINARY labelled C. Double-click to modify this (by the way, each number under Aliases references one of the local groups on the system, 00000220 is the local Administrators group). On row 0028 the 5th byte of data (each row should be arrayed with 8 bytes of data in hex) is a simple checksum that records (in hex) how many bytes of data there are at the end of the binary record that holds user sids (I'll explain more in a moment).

As you add and remove users normally, the system appends and removes 28-byte blocks of data to the end of the binary information in this registry key. Thus, the value held in this byte of data will always be a multiple of 28, which in hex will show as either 1C, 38, 54, etc (or 00 if there is no-one in the Administrators group ;-). On row 0030 the first byte of data holds the number of users in the group currently. Or, to put it another way, if you divide the number present at row 0028 byte 5 by 28 (decimal), you should get the number of users in the group, and that's the number that should be in row 0030, byte 1. I'm sure you get it, but just to be sure, some examples are thus:

  1. If one user is in the local Administrators group, then row 0028 byte 5 should read 1C and row 0030 byte 1 should read 01.
  2. If there are 5 people in the local Administrators group, then row 0028 byte 5 should read 8C and row 0030 byte 1 should read 05.

Finally, at the end of the binary data (probably starting from about row 0168 byte 5, it starts recording the SIDs (Security Identifiers) of all the members of the group (these are the 28 byte blocks of data that get added and removed as users are added and removed, and that the first two items I talked about refer to). They are all padded at the start with 12 bytes of data that look like:

01 05 00 00 00 00 00 05 15 00 00 00

followed by 16 bytes of data that record the actual unique SID. Getting a SID is trivial; there are so many ways that I will only deal here with local-machine accounts (because they're interesting). To find the SID of an account on the local machine, drill down to:


Under here are the numbered keys holding the data about each local user. The key for the builtin Administrator account is 000001F4. You can cross-reference what number relates to what account by drilling to:


The default value in this key will be 0x<whatever> and this is the number of the key under:


that holds their details and SID.

In other words, to find the local Administrator's SID, go to:

HKLMSAMSAMDomainsAccountUsersNamesAdministrator The default value under this key is 0x1f4, thus, the key that holds the data about the builtin Administrator is:


Once you've found the right key for the user you want to add/remove double click on the REG_BINARY value labelled V and scroll to about the middle of the data. With a bit of practice you should be able to spot the padding sequence of:

01 05 00 00 00 00 00 05 15 00 00 00

This is followed by the 16 bytes of data that hold the unique SID.

Finally, using all this information to perform the "hack"

From here, you're on the home straight, so here's how you actually perform the hack.


You can simply copy&paste all 28 bytes of the user's SID data to the bottom of the C value under:


Then adjust the checksum and counter values (at rows 0028 and 0030)up by 28 (+1C in hex) and 1 respectively, and you've added a user to the Administrators group.


(Even the builtin Administrator) You simply cut the 28 bytes of data that correspond to the user that you want to remove from the bottom of the C value under:


Then adjust the checksum and counter values (at rows 0028 and 0030)down by 28 (-1C in hex) and 1 respectively, and you've removed a user from the Administrators group.


Actually doing this is simple, understanding why is a little harder. Hopefully my (rather lengthy) discussion of whats-what above will help you to find your way around. If you manually remove external security principals (say, Domain accounts) from the Administrators group, you also need to remove the appropriate key under:

HKLMSAMSAMDomainsBuiltinAliasesMembers<SID of modified Group>

I can't really explain this one easily - just add and remove a Domain Account through the GUI while watching this key and you should see what I mean. Don't worry about this if you're adding accounts or only working with local accounts. Finally, be aware that every action taken through the GUI increments a counter in one of the values under:


It's been a long time since I personally did this, and I can't remember now exactly where it is, but you don't need to be bothered with it when doing things manually. I assume it is used with SAM versioning for PDC's that replicate with BDC's etc, but I've never tested it.  Bonus points for anyone who goes and finds it and reports back to the class ;-)

And finally, the escalation of privileges exception I mentioned at the start

Microsoft include several default groups in a Windows Server installation. One of these is the Server Operators group; a relatively trusted group with physical access to the server. This group has permissions for adding printers, performing maintenance etc, but they are not Administrators; they can't make other accounts and give them privileges like their own.

However, Microsoft included a special privilege that can be switched on for this group (it is disabled by default, thank goodness) to allow them to Schedule Tasks. In light of what you've just read above, I'm sure you can see that this presents nearly limitless possibilities for an enterprising young Server Operator. If they are given the rights to Schedule Tasks and the Task Scheduler service is left running as LocalSystem (almost always the case), then a Server Operator can perform the steps (or similar ones) described in this article and add themselves to the Administrators group, thus escalating their privileges beyond what was originally intended. Additionally of course, they can remove the builtin Administrator account. Food for thought...


So that's it.

It took me about 2 weeks to make sure that I understood everything that was being changed and to replicate it manually. Have fun hacking around.


Other articles that relate and may be of interest:

The canonical copy of this whitepaper

A whitepaper on the SAM that references this work, by NullAck

Manual uninstallation of a Windows 2K/2K3 Active Directory


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


I read the article and tried it out
o Yes 2%
o No 45%
o Are You Crazy?!? 52%

Votes: 42
Results | Other Polls

Related Links
o Kuro5hin
o Google
o hits I get from google
o Microsoft Knowledge Base
o The canonical copy of this whitepaper
o A whitepaper on the SAM that references this work, by NullAck
o Manual uninstallation of a Windows 2K/2K3 Active Directory
o Also by esrever

Display: Sort:
Windows NT/2K/XP/2K3 manual removal of the Administrator account | 75 comments (62 topical, 13 editorial, 1 hidden)
Interesting but... (3.00 / 4) (#4)
by onealone on Sun Jul 04, 2004 at 09:09:22 AM EST

does this really give much extra security over simply renaming the administrator account and giving it a hugely long random password?

In short, yes, it does :) (none / 0) (#11)
by esrever on Sun Jul 04, 2004 at 04:58:45 PM EST

See this comment over here for a link that renders hard passwords useless :)

Audit NTFS permissions on Windows
[ Parent ]
Accounts are irrelevent... (none / 1) (#23)
by onealone on Sun Jul 04, 2004 at 05:56:14 PM EST

if the attacker has physical access. He can just boot into DOS and load up an ntfs reader.

[ Parent ]
Of course (none / 1) (#24)
by esrever on Sun Jul 04, 2004 at 06:03:49 PM EST

I'm talking about software access, not really hardware.

I can easily boot any machine with a Knoppix CD and have access to the data on the machine, that's not the issue at question.

Please don't misunderstand me; this article is not designed to be some sort of crack or exploit; more an educational piece.  SANS recommends 'Defense in Depth' and this is just one very small piece of the securiy puzzle for the very, very serious.  For the rest, this is (I think) an interesting insight into the 'impossible' things that Microsoft say can't be done :)

Audit NTFS permissions on Windows
[ Parent ]

yeah, I already gave +1 for the interest factor... (none / 0) (#25)
by onealone on Sun Jul 04, 2004 at 06:28:30 PM EST

but, just for a bit more interest, what was the situation that demanded such security?  

I assume you were using an efs as well, so the operation you describe is quite risky, one slip and you'd have some serious work getting your data back at all. Was security valued over data retention as well?

[ Parent ]

A: security over data retention (none / 0) (#26)
by esrever on Sun Jul 04, 2004 at 06:45:41 PM EST

I won't say any more ;)

Interestingly, anecdotally a few years ago when I was at on of the Microsoft TechEd conferences they related how they had received so much feedback from big customers demanding the ability to completely turn off the recovery key for EFS in Win2k that in Win2k3 they would be shipping a system that could completely disable the generation of recovery keys.

Microsoft's reasoning had been 'but if employee X leaves, you might lose all their data', and the big Corp's responses were basically: we don't care, better that than allow the risk of a competitor or cracker getting it.

Interesting, eh?  :)

Audit NTFS permissions on Windows
[ Parent ]

As usual, MS thinks it's smarter than you [nt] (none / 0) (#48)
by Dwonis on Mon Jul 05, 2004 at 10:39:23 PM EST

[ Parent ]
Nah. (none / 0) (#52)
by Anonymous Hiro on Tue Jul 06, 2004 at 11:23:11 AM EST

That story goes to show MS does listen to its customers even if MS thinks they're wrong.

That's partly why they have more customers though some people think their software sucks - it's coz the people who making the purchasing decisions like the way the software works.

[ Parent ]

Not as crazy as it sounds (none / 0) (#33)
by duffbeer703 on Mon Jul 05, 2004 at 12:18:37 AM EST

The need for security is directly proportional to the page of the newspaper that a story about a breach would appear on.

If a "hacker" or internal user with a big mouth leaked that a politician was being investigated or revealed that a prominent baptist minister was HIV positive, you as an IT manager would have some difficult questions to ask.

[ Parent ]

Best way to remove the Administrator account (1.00 / 9) (#5)
by b1t r0t on Sun Jul 04, 2004 at 10:39:13 AM EST


-- Indymedia: the fanfiction.net of journalism.
Caveats (none / 2) (#6)
by CaptainSuperBoy on Sun Jul 04, 2004 at 11:15:37 AM EST

Windows XP and 2003 allow you to diable the local administrator account through the local users and groups snapin. I'm pretty sure that Windows 2000 lets you do this as well. Is this article only relevant to NT4? I mean it's nice to know, but you're about 5 years late on the info.

Anyway as another user pointed out, why not just rename the account and give it a very tough password?

jimmysquid.com - I take pictures.

The down-low :) (none / 1) (#10)
by esrever on Sun Jul 04, 2004 at 04:57:12 PM EST

In XP, the Administrator that you can disable isn't actually the Administrator (if that makes sense).  Underneath it is the 'Safe Mode' Administrator, which is actually the account being talked about here.  It can't be disabled.  In 2000 the Administrator can't be disabled, although it can be somewhat crippled with system policies.  In 2K3 the Administrator (the real one, the one we're talking about here) can actually be disabled (finally!) but I'm not sure (haven't been able to test) if that still holds true for Safe Mode and the System Restore Console.

Anyhow, the point is that renaming the Admin and setting a hard password doesn't save you from a bootdisk like this one that knows how to reset the password on the Admin account (which it can always find because admin is always key 0001f4  :)

Thanks for the feedback.

Audit NTFS permissions on Windows
[ Parent ]

Bootdisks (none / 1) (#13)
by CaptainSuperBoy on Sun Jul 04, 2004 at 05:23:02 PM EST

Wouldn't it be futile to try and defend against an attacker with a bootdisk? Generally, once an attacker has physical access all is lost. Someone with a bootdisk could easily give another local user or domain user local administrative rights on a PC.

jimmysquid.com - I take pictures.
[ Parent ]
Depends on the level of savvy; (none / 0) (#19)
by esrever on Sun Jul 04, 2004 at 05:44:22 PM EST

Bootdisks are easy to find, and many kiddies I'm sure could probably download one; but the functions they offer are limited, and whilst a savvy user can probably work around this, savvy users don't need the bootdisk in the first place :)

Audit NTFS permissions on Windows
[ Parent ]
I think that's naive (none / 1) (#27)
by CaptainSuperBoy on Sun Jul 04, 2004 at 06:55:37 PM EST

But I guess disabling local admin doesn't do much harm, even if the benefits are negligible.

jimmysquid.com - I take pictures.
[ Parent ]
WTF WHY? (3.00 / 6) (#31)
by Run4YourLives on Sun Jul 04, 2004 at 07:18:26 PM EST

What's wrong with the damn administrator account? Do you normally remove the root account in Linux too? I mean seriously, this is just doing something for the sake of doing something.

Just give the damn thing an enourmously ridiculous password and let it be.

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown

When you have a fully locked down computer (none / 1) (#34)
by jeremyn on Mon Jul 05, 2004 at 01:45:51 AM EST

Such as a school computer lab computer, it's set up alright and you don't want any accounts with Administrator privileges around to come back and bite you in the ass when some little prick cracks the SAM file that holds all the local Windows NT passwords in 4 hours or less with L0phtcrack. Man, isn't NT secure?

[ Parent ]
um, dude... (none / 0) (#35)
by Run4YourLives on Mon Jul 05, 2004 at 01:59:07 AM EST

If you can crack the password to the Admin account, odds are you can crack the password to any other account too...

Again I ask... WHY?

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]

And the answer is... (none / 0) (#42)
by mirleid on Mon Jul 05, 2004 at 03:34:30 PM EST


Chickens don't give milk
[ Parent ]
huh? (none / 0) (#44)
by Run4YourLives on Mon Jul 05, 2004 at 04:30:29 PM EST

If I can crack one password, I can crack them all... removing root does nothing except piss me off a little.

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]
I think (none / 1) (#65)
by starsky on Fri Jul 09, 2004 at 11:30:45 AM EST

the point is that NO USER HAS ADMINISTRATIVE PRIVELEGES, so the little tyke can crack into any account they want, they won't be able to do anythign with any of them - they'd need to do some uber-hard registry hacking to create a new user in the admin group.

[ Parent ]
lol... (none / 0) (#68)
by Run4YourLives on Sun Jul 11, 2004 at 06:04:43 PM EST

yeah, but you can do any admin level things either then.

Really stupid.

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]

Yeah (none / 0) (#36)
by CaptainSuperBoy on Mon Jul 05, 2004 at 03:04:41 AM EST

That's where the 'enormously ridiculous password' comes into play. It's easy to pick an NT password that can't be cracked in a reasonable amount of time.

Anyway if they can touch the SAM file, they already have physical access which means they could just install some low level backdoor, change passwords, etc. If you have a lab situation where local security matters you're going to want the PCs physically locked down to prevent boot disks and tampering.

jimmysquid.com - I take pictures.
[ Parent ]

Remote Login (none / 0) (#54)
by Xoder on Tue Jul 06, 2004 at 02:20:56 PM EST

In Windows, Administrator can always login remotely (although I may be misinformed on that... I haven't adminned a Windows system in a few months). It is trivial to add ONE line to your /etc/sshd/sshd.conf that prohibits root from logging in remotely. If you are running other daemons, well, that's your own problem.

Lately I've been hearing that god's on our side But rumor has it, there's one on their side too So what I'd like to know is, when it comes down to it, can my god kick their god's ass or what?
[ Parent ]
um.. (none / 0) (#55)
by Run4YourLives on Tue Jul 06, 2004 at 03:39:34 PM EST

it's also trivial to remove administrator from "can log in remotely" in the local security policy settings.

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]
Peanut! (none / 0) (#74)
by Xoder on Sat Jul 24, 2004 at 04:44:40 PM EST

Okay. Thanks for the info, I was not sure.

Lately I've been hearing that god's on our side But rumor has it, there's one on their side too So what I'd like to know is, when it comes down to it, can my god kick their god's ass or what?
[ Parent ]
RIng 0 ? (none / 2) (#38)
by blackpaw on Mon Jul 05, 2004 at 08:42:35 AM EST

I *really* don't think LocalSystem accounts run in kernel space - they just have very high access priviliges, a different kettle of fish I could be wrong of course, but I don't think so.

That's what I thought too... (none / 0) (#39)
by Ranieri on Mon Jul 05, 2004 at 10:12:06 AM EST

I was under the distinct impression that the only "user" (if you can still call it that) code that is allowed to reside in ring0 are (device) drivers.

Not that it changes the gist of the article in any significant way though.
Taste cold steel, feeble cannon restraint rope!
[ Parent ]

All I know (none / 0) (#41)
by CheezyDee on Mon Jul 05, 2004 at 03:31:02 PM EST

is that System and LocalSystem are higher than Admin and are able to kill any process. I saw a trick a few months back to bring up taskmgr as the System user in W2K and kill a misbehaving process that you couldn't kill as Admin.

I see no point in disabling Administrator. Rename Administrator, give it a rediculously long password, keep the machine physically secured, and fire anyone who installs unauthorized software.

[ Parent ]
Correct, but not ring 0 (none / 0) (#49)
by blackpaw on Mon Jul 05, 2004 at 11:26:17 PM EST

is that System and LocalSystem are higher than Admin and are able to kill any process. I saw a trick a few months back to bring up taskmgr as the System user in W2K and kill a misbehaving process that you couldn't kill as Admin.

This just means they have higher *local* priviliges. Admin can kill anytask, its just that with protected processes (such as services) admin needs to open the process token with extra flags, which the task manager does not do. Process Explorer from sysinternals.com allows the admin to do this.

A side note - System & LocalSystem accounts have no rights on the network, which is why they cannot access networks shares etc.

[ Parent ]

Odd.. (none / 0) (#40)
by tzanger on Mon Jul 05, 2004 at 03:11:08 PM EST

On my Win2kServer box I go HKLM/SAM/SAM and there's absolutely NOTHING under it aside from (Default) REG_SZ (value not set).

I'm logged in as a domain admin (not a local admin) -- is my system already secure?  :-)

You need to be LocalSystem, admin (none / 0) (#45)
by esrever on Mon Jul 05, 2004 at 05:04:28 PM EST

doesn't have rights to anything under those keys.

Audit NTFS permissions on Windows
[ Parent ]
Did you follow the steps involving "at"? (none / 0) (#46)
by Dotcher on Mon Jul 05, 2004 at 05:08:24 PM EST

By default, Administrators don't have rights to view the data in the SAM. That's why you need to (ab)use at to give yourself a shell running as SYSTEM.

I don't think the instructions in this article will work on an Active Directory domain, as account data there is stored in the AD, not in the SAM. (However, the SAM shouldn't be empty even on a DC - the information there will relate to local accounts used when booted in directory services restore mode).

[ Parent ]

how to secure the NT administrator account (none / 1) (#50)
by the77x42 on Tue Jul 06, 2004 at 04:14:56 AM EST

Modifying the registry on security accounts on a machine that you want to be secure is not a good idea.
  1. Rename the account
  2. Set a random password with extended ASCII chars (alt-###, etc.)
  3. Put a piece of paper with the administrator password on it in the bank or a safe

"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

and... (none / 1) (#51)
by the77x42 on Tue Jul 06, 2004 at 04:17:04 AM EST

have physical security setup so someone can't just boot off a copy of NT Locksmith or Winternals ERD and be on their way.

Maybe change the BIOS settings for boot disks and set a BIOS password. Maybe lock the damn thing in a cabinet.

In short: don't mickey mouse with the registry.

"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

[ Parent ]

Easy (none / 0) (#61)
by jolly st nick on Wed Jul 07, 2004 at 06:49:49 PM EST

It's easy to get around this with one of the Linux bsaed live CD password recovery distros.

Pop the CD in, reboot. Browse the user database and find the administrator (or someone you suspect is the administrator). set the password to blank, remove the CD and reboot. Bingo. you have admin control of the box. I've done this many times to help users who've lost their passwords under NT, 2000 and XP.

Now what you can do is use file system encryption on your sensitive data. This password blanking procedure will cause that data to be permanently lost.

[ Parent ]

And (none / 0) (#67)
by IntlHarvester on Sun Jul 11, 2004 at 03:14:41 PM EST

1a) Change the Description field

Or else the entire effort is pointless.

[ Parent ]

4. Create dummy "administrator" account. (none / 0) (#72)
by Ipslore on Thu Jul 15, 2004 at 04:56:15 PM EST

4. Create a dummy disabled account named "Administrator" with the same description info as the built-in admin. Turn auditing on for this account. (You are using audit collection, reduction and analysis software, aren't you?)

Now you'll have another check in place to know when someone is knocking.

[ Parent ]

Madness (2.83 / 6) (#56)
by pmc on Tue Jul 06, 2004 at 06:51:38 PM EST

Anyone that does this is a production environment (as you claim to have done) should get shot.

But if you are (lord knows why) willing to indulge in such lunacy, do it the easy way. Want to edit the SAM registry entries - log in as administrator and run regedt32 and give yourself full control over the key (see the fifth menu along, the one labelled security, guess what that does).

I had a look at your forcible AD removal tool (you might want to remove the ring 0 stuff from this article to, it being wrong). Very interesting, but there is a much, much easier way: http://www.petri.co.il/reset_domain_admin_password_in_windows_2000_ad.htm

What else? Ah - you were talking about EFS with no recovery agent, which you claim is impossible in W2k. It is possible - export the recovery agents accounts' certificates with private key and delete them (instead of doing the normal thing and storing them in the safe) and you're set: you can never use the recovery accounts to recover data as they (you) no longer have their private key. Well done, you have put your company's data at risk of being irretreviable for absolutely no gain, but there is nothing to stop you doing such a stupid thing.

Really guys, do this at home, not at work. If you want to lockdown a Windows system properly there are loads of sites telling you how. Start with http://www.nsa.gov/snac/downloads_os.cfm?MenuID=scg10.3.1.1 and look at MS site too - they have good guides too.

And remember the goal of security is to make sure you can access your data but the bad guys can't - going to great lengths to make a system flakey in the misguided belief that this will make it harder for the bad guys isn't security. Ditto other approaches with the  "if we can't read it they can read it either" philosophy.

Some responses (none / 0) (#58)
by esrever on Wed Jul 07, 2004 at 02:22:52 AM EST

Hi pmc,

    Thanks for taking the time to provide some constructive feedback.  Some of the items that you have raised demand a response, so please indulge me for a moment

  1.  In the article I specifically make mention that I did not perform this in a production environment, I did my research on a VMware virtual machine to answer some questions that I had.  VMware allows for easy rollback of snapshot points when everything breaks.  As it turns out, it did turn out useful for one, very specific situation, as I mention in an attached comment.  Irregardless, I'm sure you'll agree that 'lunacy' is hardly the right word to use when you are not familiar with the individual circumstances and requirements of a particular situation.
  2.  With regards to regedt32.  I believe that I have already answered this in the article when I specifically mention that we are using regedit instead of regedt32 because it's much easier to see what's going on, and, by extension, much harder to make an error.  Something that I'm sure you'll agree is a worthy goal when undertaking such a 'flaky' procedure.
  3. Ring0.  Perhaps I am guilty of attempting to simplify things to the point that I have made it overly simplistic and conveyed wrong information.  Nevertheless, LocalSystem does have access to Ring0 kernel space because it can load Device Drivers at runtime.  Certainly it lives at the top of the user stack as far as security rights go, and it's more than sufficient for any task conceivable on a Windows system.
  4. EFS.  I stand by the comments I made about EFS.  Bear in mind that it wasn't me complaining about the inability to turn off the recovery agent, it was many of MS's own very large corporate customers.  Your solution was specifically offered by MS, but was deemed unacceptable by the customers they related it to.  In any event, the results speak for themselves; in Win2K the recovery agent cannot be turned off, in Win2K3, it can.
PS, you imply that I prevaricated and that win2k with no recory agent is possible, and then proceed to demonstrate that it isn't.  Just because you have destroyed the private key doesn't mean that windows doesn't continue to go ahead and generate a second encrypted copy of the symmetric encryption key for a file.
  1.  Regarding Forcible Active Directory uninstallation.  I have read the google cache of the site you reference, as it appears to be down at the moment.  Interesting that it also uses the LocalSystem account to perform its work.  Also, you may like to read Microsoft's own instructions for this.  They are utterly different to mine, and certainly no more easy.  Obviously Microsoft either didn't know about and/or did not intend for the method that I describe to be used.  This alone I believe 'justifys the existence' of the publishing of my method.  Certainly neworder.box.sk agreed when they published my article on the 08/08/2002.  Incidentally, it's a shame that Microsoft don't make available a 'this article first published on' date for their KB, as I looked very hard before investing the time into discovering that method.  I believe that at the time that it was published it's likely that it was the only method documented on the Internet.  I could be wrong; and I'm interested in checking the forums of the site you mention once it's back up, to see when they first mentioned resetting the DA password.  Certainly it is clear, if you read through the comments attached to my article on neworder that were posted at the time, you will see that several very smart people couldn't find any other way documented.
  2. Finally, I find it interesting that you're willing to take issue with things that I have written in comments attached to this article as a top-post, but then completely ignore the comments I make over here (in a thread that you clearly read), that SANS recommend 'Defense in Depth' and that this is just one small piece of the puzzle for the very, very serious.

Audit NTFS permissions on Windows
[ Parent ]
Just a few quick comments (none / 0) (#60)
by pmc on Wed Jul 07, 2004 at 06:22:11 AM EST

  1. You mention, or at least strongly imply, that you did do this in a production environment - from the article: "It answered some questions I had and proved useful on at least one occasion", and in another comment "Security over data retention" you strongly imply that you had used it in a production environment.
  2. Give yourself full control over the registry key with regedt32 then edit it in regedit.
  3. Localsystem cannot access HKCU, or is this inconceivable? Access the network with other than null credentials, or is this incenceivable too?
  4. I not sure there is a difference, other than symantics, between "Broken", and "Broken by design".
Your paragraph between 4 and 5 - I can't see what you are trying to say. EFS on 2k will happily go on adding a file recovery key to each encrypted file using the RA's public key to encrypt it. You cannot decrypt these recovery keys because you no longer possess the private key. If they - the corporate powers that be - think that the encrypted RA key is vulnerable then so is the user's encrypted key, and the system should not be used at all as it is weak. (This sort of approximates my opinion - I do not believe that it should be used as it has not been shown to be strong.)
  1. The nt-unlock method is easier and better (unless you actually want to remove active directory and not just have access to the machine/domain). But your work is still interesting (really!). So please do not put words in my mouth - "justifys [Sic] the existence" I never said.
  2. I disagree for the reasons mentioned in the last paragraph of my post - this is NOT a piece of the security puzzle, and anyone doing this in a production environment should get shot. It is like putting super-glue into the lock of a safe - it just inconveniences you: the bad guys are going to nick the whole safe, not carefully (but incredibly detectably) pick the lock.

[ Parent ]
Lunacy (none / 1) (#70)
by loteck on Mon Jul 12, 2004 at 02:56:42 PM EST

a nitpick...

irrespective of what you think... and regardless of what anybody else might have said...

Irregardless will never be acceptable.
"You're in tune to the musical sound of loteck hi-fi, the musical sound that moves right round. Keep on moving ya'll." -Mylakovich

[ Parent ]

Fascinating (none / 0) (#71)
by esrever on Mon Jul 12, 2004 at 05:17:26 PM EST

In all honesty, thank you for bringing that to my attention.  I had never seen nor bothered to look up a definition for irregardless, having only ever come across it in oral language.  Well, regardless of my past usage, I will be making an effort to avoid it from hereon it...

Audit NTFS permissions on Windows
[ Parent ]
We shall see next saturday... (none / 2) (#57)
by Maljin Jolt on Tue Jul 06, 2004 at 10:27:00 PM EST

It's a real gem. I mean, both method of adding and removing a user to/from admin group. And publishing this subtlety with such a nice and clever cover story is an excercise of wits and social skills. Bravo, esrever.

So, for those who does not see the connection between facts, I speak a prophesy: Finally, the nightmare will come to it's end. Because after next wave of windows worms no admins will be able to patch anything.

I am glad I abandoned that foul platform long ago.

Not quite good enough. (none / 1) (#62)
by jolly st nick on Wed Jul 07, 2004 at 06:57:08 PM EST

If you have physical access to the machine, you can either boot linux or an NT recovery CD and fix the SAM, or simply poke around.

If the issue here is that you don't want somebody with physical access to be able to get to data, it's child's play to get around this. Encrypting sensitive data is a must.

However, if the point is to make the machine secure over the network, this procedure could conceivably gum up some remote "root' exploits.

Registry (none / 1) (#64)
by Armada on Fri Jul 09, 2004 at 02:46:10 AM EST

The thing that has always boggled my mind is how susceptible Windows is to registry edits.

Windows Firewall in the way of connecting to your homemade trojan? Simple, just write a script to disable it. My roommate does this with little effort. He's even coded something and installed it on his compromised boxen in anticipation of XP SP2.

By the time people flip over, he's already using new "features" to find even more about them than they want. All because he had a chance to screw around with RC1 and RC2 for the latest SP.

If you want more info on how to do this I suggest you check out his post here: (registration and approval required):


Re: Registry (none / 0) (#69)
by BCoates on Sun Jul 11, 2004 at 09:39:14 PM EST

I'm sorry, but your script-kiddie roommate isn't defeating anything.  Firewalls don't do anything to protect already compromised machines unless the trojan/rootkit/worm/whatever is dependent on opening a listening socket (which is just a flaw in the trojan).

Editing the registry isn't some clever hacker trick; it's the standard mechanism for configuring a windows machine (that, and a set of front-end GUI tools that edit it for you)

[ Parent ]

Boy (none / 0) (#75)
by Armada on Thu Aug 12, 2004 at 11:19:10 AM EST

Firewalls don't do anything to protect already compromised machines unless the trojan/rootkit/worm/whatever is dependent on opening a listening socket (which is just a flaw in the trojan).

Boy are you an idiot. Is your only experience with Windows Firewall the crappy-ass XP SP1a one? You do realize there are Firewalls both hardware and software that will alert on egress?

Which means that the trojan (which comprises the majority of them right now, save for the rootkit based ones) gets noticed the second it tries to establish a connection.

[ Parent ]

Windows NT/2K/XP/2K3 manual removal of the Administrator account | 75 comments (62 topical, 13 editorial, 1 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!