Losing an administrator is always a painful process. Even the best administrators usually forget to document something. The worst admins document nothing, create up multiple backdoor accounts, and install services to run under their own credentials. It is important to immediately check your servers when an admin leaves for several reasons: Disgruntled admins may leave backdoors in your system that they will later use to attack you; Disabling the admin’s account may cause services to stop running; Scripts may be scheduled to run that will grant the admin access weeks or months later.
Fortunately, it is possible to perform a rapid clean up if you follow a simple process, and use tools to help. This process is specific to the platform the administrator supported. The process for cleaning up after a Windows administrator is as follows:
- Create a list of all servers in your environment. If you aren’t sure, check DNS and Active Directory
- Search Active Directory for all users with privileged (admin) group memberships
- Search every server for services that run under domain or local accounts instead of LocalSystem or NT
- Search every server for scheduled tasks that run under domain or local accounts
- Change the password on every privileged user account. Assume that the old admin could have had access to every account at some point.
- Change the password on every service and scheduled task to match the new passwords in step 5.
- Change any service or scheduled task that runs under the old admin’s account to run under a new service account
- Review any scheduled tasks that are scripts, to make sure you know what they do. A clever admin could bury a script to recreate his admin account inside of another script.
- Disable the old admin account
There are many good commercial tools available for searching servers for service accounts and scheduled task accounts, but I’m a big believer in using simple scripts where possible to get the job done. If you want a commercial product to help, check out:
If like me, you hate to spend good money for tools that duplicate the built-in power of Windows, then these scripts are for you:
Code:
REM ***Script used to check for services and scheduled tasks that run under domain accounts
REM ***Script requires Windows 2003 Resource Kit (global.exe & findstr.exe). Must be run with domain admin permissions
REM ***Script requires GnuWin32 (gsar) found at http://gnuwin32.sourceforge.net/packages/gsar.htm
REM ***Script requires servers.txt file located in same directory. servers.txt should be a list of server names to be checked
REM ***The First Step is to check all the privileged admin groups in the domain
set /P domainname=Please enter domain name:
global.exe “DnsAdmins” %domainname% > checktheseaccounts.txt
global.exe “Domain Admins” %domainname% >> checktheseaccounts.txt
global.exe “Enterprise Admins” %domainname% >> checktheseaccounts.txt
global.exe “Schema Admins” %domainname% >> checktheseaccounts.txt
REM ***First step is to generate a list of services running on each server
for /f %%a in (servers.txt) do (sc \\%%a query > %%a.tx2)
dir /B *.tx2 > serverlist.tx2
findstr /f:serverlist.tx2 /c:SERVICE_NAME > servicelist.tx2
REM ***Now we need to remove the leading space in front of the service name using GSAR, to deal with multi-word service names
gsar -s”:: ” -r:: -o servicelist.tx2
REM ***Once we have our service lists, we call a subroutine to do an advanced query which will tell us what service accounts the service uses to run.
for /f “tokens=1-4 delims=.:” %%b in (servicelist.tx2) do set server=%%b&&set service=%%e&&call :ServiceScan
REM ***Now that we have the accounts, we filter out the services that run as LocalSystem or NT
for /f “tokens=1-3 delims=, ” %%m in (services.tx2) do (if not %%o==LocalSystem echo %%m,%%n,%%o >> 1stcheck.tx2)
for /f “tokens=1-3 delims=, ” %%m in (1stcheck.tx2) do (if not %%o==NT echo %%m,%%n,%%o >> checktheseservices.txt)
REM ***The final step is to go back and check each server for scheduled tasks
for /f %%a in (servers.txt) do (schtasks /query /v /FO CSV /NH /s %%a >> checkthesetasks.txt)
del /F *.tx2
goto :EOM
:ServiceScan
sc \\%server% qc “%service%” > service.tx2
findstr /c:SERVICE_START_NAME service.tx2 > servicename.tx2
for /f “tokens=1-3″ %%c in (servicename.tx2) do (echo %server%,%service%,%%e >> services.tx2)
:EOM
REM ***Now we have two files that tell us what we need:
REM ***checktheseservices.txt lists the services to check
REM ***checkthesetasks.txt lists the scheduled tasks to check
This script does a couple of basic things, but it does them well. First, it prints out the group memberships of the four Windows admin groups. This tells you which accounts need to be changed. Second, it searches every server listed in the “servers.txt” file for any services running under a domain or local account, instead of LocalSystem or NT. This tells you which services need to be changed. Lastly, it tells you every scheduled task running on every server in the “servers.txt” file. This tells you which scheduled tasks need to be changed. Once you have your lists of services and tasks that need to be updated, you can also script the update.
Code to update Scheduled Tasks:
REM ***Create a new document called tasklist.txt with 2 columns, separated by a comma.
REM ***Column 1 should be the server name. Column 2 should be the scheduled task name
REM ***EXAMPLE: server1,task1
REM ***These names can be extracted from the checkthesetasks.txt file
set /P newpassword=Enter the new password you want each scheduled task to run with:
for /f “tokens=1-2 delims=,” %%a in (tasklist.txt) do (schtasks /change /s %%a /RP %newpassword% /TN %%b)
Code to update Services:
REM ***Create a new document called servicelist.txt with 2 columns, separated by a comma.
REM ***Column 1 should be the server name. Column 2 should be the service name
REM ***EXAMPLE: server1,service1
REM ***These names can be extracted from the checktheseservices.txt fileset /P newpassword=Enter the new password you want each service to run with:
for /f “tokens=1-2 delims=,” %%a in (servicelist.txt) do (sc %%a config “%%b” password= %newpassword%)
After you have changed the services and scheduled tasks, you should be safe to disable the old admin’s account. Although the above scripts apply to Windows servers, the same concepts can be applied to other platforms: Identify any processes/services/scripts that run with privileged user access and change them; Identify all privileged accounts and change them as well; Remove the admin’s account from the system.
This process is not foolproof. A determined, disgruntled admin could install rootkits, keyloggers, trojans, and logic bombs prior to leaving. Administrators are GOD on their systems, so the only defense against this is to diligently screen your admins before you hire them. This process WILL allow you to locate and clean up access that was legitimate when it was created, even if it is not well documented. I hope you find these scripts useful.
-Bill
