Everhart,Glenn
From:	Woeltje, Donald [Donald.Woeltje@anheuser-busch.com]
Sent:	Friday, April 24, 1998 11:59 AM
To:	'NT Security'
Subject:	[NTSEC] My Turn

TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net
Contact ntsecurity-owner@iss.net for help with any problems!
---------------------------------------------------------------------------

This is for all those that attempted to give me assistance on my "admin password
problem".

I really appreciate everyone that responded. Here is how I solved the problem,
which only takes a few minutes and can be applied to any NT system with slight
modifications.

On the system in question, we have one service that starts using the LocalSystem
account. That service runs SRVANY, which in turn runs a program that we'll call
abcd.exe.

With the administrator password lost, the only other account with admin
privileges is the LocalSystem account, which is used (as far as I'm concerned
for this discussion) primarily to start services.

IF I had admin privileges, I could use the NET USER administrator password
command to change the administrator password to password. But I don't have those
privileges. But LocalSystem does........., so by extension SRVANY does.......,
and by extension abcd.exe does.

And the Power Users group, of which one account is a member of, can stop and
start services.

So here is what I did.

I created a batch file called netuser.bat and put it in the
%systemroot%\system32 directory.

In that batch file is NET USER administrator password.

Then, using the WinBatch programming language (any language could be used), I
wrote a program that has just one line of code. In this case that code would be;

Run("c:\%systemroot%\system32\netuser.bat","") 

The %systemroot% would not be there; it would be the actual directory name.

Then when I compiled this program, I gave it the name abcd.exe. Thus, I
basically created a form of Trojan Horse program.

Then I sent these two files to the user via overnight mail. I had them log in
with the account that is a member of the Power Users group. I had them stop the
service that starts abcd.exe. Then I had them go into the directory were
abcd.exe is stored and rename it abcd.old. Then I had them copy the batch file
into the %systemroot%\system32 directory and copy MY NEW abcd.exe file into the
same directory where the old one was. Now that the files were in place, I had
them restart the service which starts abcd.exe. This caused SRVANY to start with
the authority of the LocalSystem Account, which in turn ran my new abcd.exe with
the authority of the LocalSystem Account, which in turn ran the batch file with
the authority of the LocalSystem Account, which in turn fixed the administrator
account password.

Then I had them stop the service, delete my version of the abcd.exe, and rename
the abcd.old back to abcd.exe, then I had them restart the service.

At this point, they were back to normal and the administrator account's password
was fixed.

There is potential for abuse of this procedure. There are many services on NT
that run using the LocalSystem account. And with NT up and running, a lot of the
executables are not actually being held open. If someone could get full access
to the %systemroot%\system32 directory (or any directory where there is an
executable that starts as a service with the LocalSystem account), they could
write a "replacement" program that when run would run the NET USER command to
change the admin password and then run the intended executable (so that the
computers adman's wouldn't know anything had happened). At this point, that
person could log in as administrator and have full access to the computer.

Anyway, the actual procedure at the affected site only took a couple of minutes.
It was just a matter of getting the two files to the site.