Be the ball (or the Local System Account)

So I got a call this morning about a file on our main file server being “open” by “no one”, and of course one of my users was in dire need of access to said file.

No problem I thought to myself, I’ll just log in as the Domain Admin, find out who has the file open, and close it. Turns out it wasn’t quite so easy. Apparently the file in question was opened by the NT AUTHORITY\SYSTEM account, or in layman’s terms, the LOCAL SYSTEM account. Odd, nothing that should have been running as the LOCAL SYSTEM account should have that file locked.

This presented an interesting challenge, as the LOCAL SYSTEM account trumps the authority of the Local Administrators group (which is the group that the Domain Administrators group has membership in). Think of the LOCAL SYSTEM account as the machine itself rather than a user account, and you’ll have a pretty good grasp of why this is an issue (without an account that trumps the LOCAL SYSTEM account a reboot is pretty much the only way to release a locked file – and rebooting a production file server in the middle of business hours is a big no no here).

Finding things like this always makes me a bit nervous, so it was time to investigate. As it turns out, I had inadvertently found a way to become the LOCAL SYSTEM account. On Sunday I was testing a script in our live environment (already tested in our test environment, but I always run a test on live too, as funny things happen when you make that move to live), and had at random picked this particular file as a test file (doesn’t contain any important information, and it was the first file I happened to lay eyes on).

This particular script scheduled another script that would then read a specific file and act depending on the information contained in it. Well it seems that the scheduled script had hung (I forgot to change a variable, and what worked in our test environment could not find a folder it needed in our live environment), and locked this particular file because it had run as (you guessed it) the LOCAL SYSTEM account.

So how did all this happen, and how did I get the script running as the LOCAL SYSTEM account? The answer lies in the magic of the AT command.

Apparently when you schedule something using the AT command, it will execute in the NT AUTHORITY\LOCAL SYSTEM account context. This is actually pretty useful, as there are times when it would be extremely beneficial to be able to operate as the LOCAL SYSTEM account (like when the LOCAL SYSTEM account is locking a file). More importantly I figured out a way to gain LOCAL SYSTEM account context interactively.

Ok, so to become the LOCAL SYSTEM account, here is what we do:

  1. Start > Run > type: cmd {ENTER}
  2. Type: at 14:05 /interactive “cmd.exe” {ENTER} (replace 14:05 with a time 5 minutes from now – using the 24 hour time format).
  3. Close the command prompt.
  4. When the time you specified in the above command occurs, a command prompt will launch.

This command prompt is running in the LOCAL SYSTEM context (you can confirm this by running Process Explorer from Sysinternals)! So, now you can use this command prompt to say, relaunch Windows Explorer in the LOCAL SYSTEM account context:

  1. In the command prompt type: taskkill /F explorer.exe {ENTER}.
  2. Type: explorer.exe {ENTER}.

This will kill Windows Explorer, and relaunch it in the LOCAL SYSTEM account context. Now anything you do will be executed in the context of the LOCAL SYSTEM account (so be careful, you can easily permanently delete files or damage your system).

To get back to the context of your regular user simply log off, and log back in.

Now, I immediately started having thoughts about the security implications of this, but then realized that Microsoft had already thought of this. To run the AT command, you must be a member of the local Administrators group. So not to worry, your users are not going to start wreaking havoc on your systems if they should happen across this post (at least probably no more so than if they already have membership in the local Administrators group).

end

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: