February 6, 2012

Lockdown Windows 7 with Simple Scripts

Back in 2007, I published a script for locking down Windows XP and Windows 2003 services, using the sc command. Recently I had need to lockdown a fresh Windows 7 image and realized the list of services needed to be updated. The below list works on my laptop. For a complete list of what each of these services does, or why you do/do not need them, please refer to Microsoft Technet.

The script could not be simpler. Take the below script and save it as a batch file on your desktop.

for /f %%b in (services.txt) do sc config %%b start= disabled
for /f %%c in (services.txt) do sc stop %%c

The list of services then goes into a text file in the same directory as the batch file, named “services.txt”. You can modify the list of services at will, based upon your unique needs. (read more…)

          Comments (0)

August 12, 2008


In a previous article, I extolled the virtues of DNS on Windows. In particular, I love the scripting interface that DNSCMD provides. In that article, I claimed: “Need to create 500 host records, both forward and reverse, in different domains and subnets? DNSCMD can do it with a 1-line script… there is no *nix alternative that is this simple or powerful.” Well, enough people have been bugging me to provide it so here is is:

REM### Copyright 2008 William L. Dougherty
REM### Script for bulk uploading DNS records into Windows DNS
REM### Script requires hosts.txt file in format: FQDN,IPADDR 1 host per line
REM### Example:
for /F “tokens=1-7 delims=,. ” %%a in (hosts.txt) do dnscmd /recordadd %%b.%%c %%a a %%d.%%e.%%f.%%g && dnscmd /recordadd %%f.%%e.%%d.in-addr.arpa %%g ptr %%a.%%b.%%c

Just put it into a batch file and you are good to go. Simple, right? Well, maybe I should explain. (read more…)

          Comments (4)

March 17, 2007

Lockdown Windows 2003 & XP with Simple Scripts

Windows Advanced ScriptingNow that DST 2007 is over, we are going to start a series of articles on securing systems and networks. I have built a lot of systems for various companies over the years. The challenge is to create repeatable processes that work in a variety of operating environments. Having a strong scripting toolkit can make all the difference, especially when you are under deadline.

The first script in the series is a Windows Services lockdown script for Windows XP & 2003. Disabling services is generally a good idea to reduce the threat profile of your computer, and to improve its performance. Every security guide out there tells you to disable unnecessary services. A few of them also give some guidance as to which services are unnecessary. Few of them tell you how to disable them consistently.

There are three ways to disable services: 1) Use the Services MMC GUI. This is a time consuming process and is prone to mistakes. 2) Use Group Policy. This works well for environments that use Group Policy, but is harder to implement for stand-alone servers, such as web servers. 3) Use the sc.exe command line utility.

If you do not know the sc command, learn it! sc is a powerful utility for controlling services on local or remote hosts. sc will let you configure how services start, change the user account and password they run under, and start/stop/pause the services. The basic syntax of sc is:

sc <server> [command] [service name] <option1> <option2>

We are going to use 2 different sc commands in our service lockdown script: config & stop. These should be self explanatory, but config will allow us to disable the service, and stop will stop the service. To make this work, we need three files: 1) The script batch file; 2) a list of servers by name called hosts.txt; 3) a list of services we want to disable called services.txt. The two text files must be in the same directory as the batch file. The code is fairly simple: (read more…)

          Comments (6)

December 1, 2006

Clean Up After Terminated Windows Administrators

win2k3.jpgLosing 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:

  1. Create a list of all servers in your environment. If you aren’t sure, check DNS and Active Directory
  2. Search Active Directory for all users with privileged (admin) group memberships
  3. Search every server for services that run under domain or local accounts instead of LocalSystem or NT
  4. Search every server for scheduled tasks that run under domain or local accounts
  5. Change the password on every privileged user account. Assume that the old admin could have had access to every account at some point.
  6. Change the password on every service and scheduled task to match the new passwords in step 5.
  7. Change any service or scheduled task that runs under the old admin’s account to run under a new service account
  8. 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.
  9. 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: (read more…)

          Comments (3)