Windows NT/2K/XP/2K3 manual removal of the Administrator account (Technology) By esrever Mon Jul 5th, 2004 at 02:28:12 PM EST
	Or, how to remove the power of the builtin Administrator account without deleting it (delete it if you like ;-).

Introduction 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. DISCLAIMER 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: HKLMSAMSAMDomainsBuiltinAliases00000220 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: 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. 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: HKLMSAMSAMDomainsAccountUsers 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: HKLMSAMSAMDomainsAccountUsersNames<insert-name-of-user-here> The default value in this key will be 0x<whatever> and this is the number of the key under: HKLMSAMSAMDomainsAccountUsers 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: HKLMSAMSAMDomainsAccountUsers000001F4 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. TO ADD A MEMBER: You can simply copy&paste all 28 bytes of the user's SID data to the bottom of the C value under: HKLMSAMSAMDomainsBuiltinAliases00000220 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. TO REMOVE A MEMBER: (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: HKLMSAMSAMDomainsBuiltinAliases00000220 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. SOME FOOTNOTES: 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: HKLMSAMSAMDomains... 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... Wrap-up 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. esrever_otua 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

Managed Servers Managed Clusters Virtual Hosting www.johncompanies.com Looking for a hosted server? We provide Dedicated, Managed and Virtual servers with unparalleled tech support and world-class network connections. Starting as low as $15/month Linux and FreeBSD No set-up fees and no hidden costs Tier-one provider bandwidth connections

Poll

I read the article and tried it out Yes 2% No 45% Are You Crazy?!? 52% Votes: 42 Results | Other Polls

Related Links

Kuro5hin Google hits I get from google Microsoft Knowledge Base 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 More on Software Also by esrever