How To Use BitLocker With Attached VHD Drive

1
Posted by Jason Fossen on November 17, 2009 – 7:37 pm
Filed under Misc, Windows 7

You can attach a VHD image file as a drive letter and then encrypt the contents of the VHD with BitLocker.  This allows multiple users to share a computer and use BitLocker to keep their files secret from each other.  Unlike the files on a BitLocker volume, when a VHD file using BitLocker inside it is backed up or copied to a plaintext USB drive, the VHD file’s contents stay encrypted.

Requirements

To create a BitLocker VHD drive, you must have Windows 7 Enterprise or Ultimate, Windows Server 2008-R2, or later operating systems.  (Home and Professional editions of Windows 7 cannot be used to create BitLocker To Go drives, but they can use such drives after they are created on another system.)

You will likely want to install the free VHD Attach utility.  It isn’t absolutely required, but it makes working with VHD drives much more convenient.  With this utility you can simply right-click a VHD file to attach (mount) or detach (unmount) it as a drive letter.

AttachVHD

Procedures

Download and install the free VHD Attach utility, if you wish to use it (recommended).

In the Administrative Tools folder of the Start Menu, go to Computer Management > Storage > right-click Disk Management > Create VHD.  Create a VHD file larger than 64MB in size.

Scroll down in Disk Management, find the new disk > right-click its box (left side) > Initialize Disk > OK > right-click the disk’s partition area (right side) > New Simple Volume > follow the wizard to format the volume using NTFS or one of the FATs (NTFS preferred).

In Windows Explorer, right-click the new drive > Turn On BitLocker.  Encrypt the VHD drive with BitLocker To Go in the regular way with a passphrase or smart card.  Remember not to store the recovery key file on the same computer as the VHD drive!

(Optional) In Windows Explorer, right-click the new drive > Manage BitLocker > Automatically Unlock This Drive On This Computer.  This protects the BitLocker VHD drive with your desktop logon credentials.  If you want to be prompted for your BitLocker passphrase whenever you first attach the VHD drive, do not select this option (perhaps because others know your logon password).

In Windows Explorer, if you installed the VHD Attach utility, find the VHD file on the host hard drive (probably C:\) > right-click the VHD file > select Detach/Attach/Open.  Detach will unmount the drive letter.  Attach will mount the VHD file as a drive and then you’ll be prompted for your BitLocker passphrase or smart card (or neither, if you enabled the Automatic Unlock feature).  Open will show information about the VHD drive such as sector size, volume identifier, vendor ID, etc.

Command-Line Use

The VHD Attach utility installs a binary named VhdAttachExecutor.exe.  This supports two command-line switches: /attach vhdfilepath and /detach vhdfilepath.  This can be used in custom scripts or desktop shortcuts to simplify the use of VHD drives. You can also use the built-in DISKPART.EXE tool, but this is much less convenient.

Concealment

If you want to try to conceal the fact that you have a BitLocker-encrypted VHD file, keep in mind that VHD files have a binary signature which can be scanned-for and identified.  However, you might try this: 1) Install the VHD Attach tool on another computer, 2) copy the VHD Attach program files to a flash drive, 3) create a BitLocker-encrypted VHD file on the desired machine, 4) detach or unmount the VHD drive, 5) rename the VHD file and its filename extension to something which will not draw attention, perhaps moving the file as well, 6) use a shortcut or batch script on the flash drive to run VhdAttachExecutor.exe to mount the renamed VHD file when desired.

Keep in mind that installing the VHD Attach tool modifies the registry, and so does running the tool, even from a flash drive, so you cannot easily conceal its usage.  Mounting VHD drives also leaves forensic traces that are difficult to erase.  Your custom attachment script would have to try to scrub these traces.  Hence, the above concealment steps are just for a bit of weak obscurity.

Conclusion

A common question is “How can I use BitLocker to keep my files secure from other people who share my computer?”  Using BitLocker-encrypted VHD files is one possibility.  But you should also investigate using the NTFS Encrypting File System (EFS), which also supports smart card key storage, encryption of external USB drives, and encryption of VHD files with- or without BitLocker.  All this is covered in the six-day Securing Windows track (SEC505) at SANS of course.  Good luck!

WinDump Color Highlighting PowerShell Script

1
Posted by Jason Fossen on October 22, 2009 – 3:54 pm
Filed under PowerShell, Windows 7

windump-colors

SniffScreenShot2

WinDump.exe is a free command-line packet sniffer and protocol analyzer for Windows (similar in command-line options to tcpdump for UNIX/Linux).  Staring at the output of WinDump for hours can cause eye strain, especially when sniffing in verbose mode or when showing the output on a projector to an audience.

Sniff.ps1 is a PowerShell script which will colorize the fields of WinDump output and insert zero or more blank lines in between each line of output for readability.  You can download the script free from here, it’s in the public domain.

To have the script simply guess which network adapter to listen on and start sniffing:

.\sniff.ps1

To have the script ask you which network adapter to use:

.\sniff.ps1 -ask

To add one or more blank lines in between each line of output (nice for teaching):

.\sniff.ps1 -spacing 1

To specify additional WinDump command-line options (-options parameter optional) just put the arguments inside double-quotes:

.\sniff.ps1 -options "-v -t -X not arp and not port 1900"
.\sniff.ps1 "-s 500 tcp port 80" -ask
.\sniff.ps1 "-r capturefile.pcap -X -s 0" -spacing 2

If the script is in your PATH or the Sniff() function from inside the script has been copied into your profile script (see $profile), you don’t need the folder path or filename extension, and you can abbreviate the full names of the parameters:

sniff
sniff -a -s 1
sniff "-t -X not port 3389"

If you want to change the colors, they are listed in one spot inside the script, so they are easy to find and edit.

Pipe Into Colorize-WinDump() Filter Instead

If you don’t want to use the Sniff.ps1 wrapper, but you do want the color highlighting sometimes, open the script and copy out the Colorize-WinDump() filter (which is inside the Sniff() function).  Copy the filter code to another file for dot-sourcing or paste the code into your profile script, then you can pipe WinDump.exe output into the filter as desired:

windump.exe -i 2 -v -X | colorize-windump

Requirements & Caveats

Script requires PowerShell 2.0 or later.  Only Windows 7 and Server 2008-R2 and later have this by default, so for earlier operating systems you must download PowerShell 2.0 or later from Microsoft’s site (it comes as a part of the “Windows Management Framework”).

WinDump.exe and the WinPcap driver must be installed before running script.

WinDump.exe must be in the PATH or you must edit the $WindumpPath variable in the script.

Not every protocol can be colorized by the script, so the script defaults to showing in monochrome the output lines it can’t parse correctly.

WinDump’s -e switch, for showing the link-level header, is not supported, but the monochrome output will still be shown.  Other verbose switches, such as -tttt, -vvv and -X, are supported though.

The default color scheme assumes that your shell’s background color is black, which is not the PowerShell default, but you can easily change your background color (right-click the shell’s titlebar > Properties > Colors) and you can easily edit the colors defined inside the script (they are all listed in one spot in the script for easy editing).

SANS Report: Top Security Risk for Windows

0
Posted by Jason Fossen on September 16, 2009 – 7:21 pm
Filed under Anti-Malware, Course SEC505

A September 2009 report, which consolidates the data gathered by TippingPoint and Qualys from thousands of networks around the world, shows that the number one top cyber security risk today for Windows desktops are actually the client applications they run, not Windows itself.  Client applications, such as Microsoft Word, Internet Explorer, Mozilla Firefox, Apple QuickTime and Adobe Acrobat, are now generally more vulnerable to attack than the operating system itself, mainly because these applications are patched less quickly than Windows.  New zero-day exploits and known but unpatched exploits in applications are the main pathways through which attackers gain a foothold inside your network.  But what can be done about it?

As we’ve talked about for years in the Securing Windows course at SANS (SEC505), most of the tools you need to reduce your client application risk can be downloaded for free or are built into Windows and Active Directory for free.  You don’t have to spend a fortune to automate and scale-out your defenses against desktop application attacks, but it does require some know-how and elbow grease.  Here are some of the most important tasks and technologies for security personnel on limited budgets.

Inexpensive Patch Management

If you can’t afford a patch management server at all, at least turn on Windows Update in Control Panel.  If you want a local patch management server, but you think you can’t afford it, then download Windows Server Update Services (WSUS) from Microsoft.  WSUS is free and can be used to deploy hotfixes to thousands of stand-alone and domain-joined systems, including patches for Internet Explorer, Microsoft Office, and other Microsoft client-side applications.  If you’ve got the money to buy a third-party patch management system with more bells and whistles, even better!  SANS regularly polls security professionals on which products they feel work best, including patch management systems, and Windows IT Pro magazine periodically has articles comparing the most popular products too.

Patching Non-Microsoft Client Applications

Most applications either come in Windows Installer package format already (*.MSI), have an installer EXE which simply extracts and installs the Windows Installer packages, or have an installer EXE which can be re-packaged as a Windows Installer package.  This is important because 1) you can patch Windows Installer-installed applications relatively easily, 2) you can edit Windows Installer packages and their related transform files for customization, 3) you can script the installation, repair and uninstallation of these packages from the command line using MSIEXEC.EXE, and, most importantly, 4) you can do hands-free deployment of packages and their updates through Group Policy.  If you have Active Directory, then you’ve got Group Policy already.  To create or edit a Windows Installer package, or to repackage an EXE update program, you can use ORCA.EXE, which is free, or tools like InstallShield, which are not free but more capable.  If you want a taste of what’s possible, check out this article about deploying and updating Adobe Acrobat using Group Policy.  In general, you can use Windows Installer packages, Group Policy and MSIEXEC.EXE to automate a great deal of your application patching work, even if your applications aren’t from Microsoft.

Configuring Non-Microsoft Applications For Self-Update

Many third-party applications can be configured to automatically check for updates.  The user can be prompted to apply the update, or sometimes the update can be installed automatically by the application itself.  Now, these configuration settings are normally stored in the registry or in INI/XML files.  To ensure that self-update is configured correctly, you can use Group Policy to manage these registry settings (with ADM or ADMX templates) and you can use Group Policy to push out scripts which edit these INI/XML files.  If you want even more control, or if you don’t want to make any custom templates or scripts, then there are third-party Group Policy add-ons for this, such as PolicyPak (but which aren’t free).  In short, you can use Group Policy and a little bit of scripting to enable self-updates in many non-Microsoft applications.  Indeed, if you can manage the registry and INI/XML files for these applications, you can probably manage all of their other security settings too.

Blocking Unwanted Applications

Using Group Policy, you can configure AppLocker or Software Restriction Policies on all your machines to simply prevent unwanted applications from running at all.  If this is too harsh, you can usually block specific versions of these applications from running instead.  You can also push out scripts through Group Policy to seek out specific versions of dangerous applications, then the script could delete, disable or simply log the existence of that vulnerable software.

Discovering Unwanted Applications

You might not have the money for an enterprise-wide software inventory tool, but with a little elbow grease, your scripts can query remote systems for the package versions they have installed and even search their registries and hard drives for other software.  Using the Get-WmiObject cmdlet in PowerShell, for example, you can interrogate the Windows Management Instrumentation (WMI) service on remote computers to gather this information.  PowerShell is free and the scripting really is not as hard as it might sound.  Again, if you’re not comfortable with the scripting, but you still can’t afford the big-iron inventory systems, then you can still leverage Group Policy with other add-ons.

Beyond Patching: 20 Critical Controls

The (in)security of a desktop application has a lot to do with the user and computer running it.  Through proper configuration you can block many exploits, even without the relevant patches, or limit the scope of harm when an attack occurs.   Again, through Group Policy and some scripting, you can automate most of these changes for your users.  Consider: Are your users members of the local Administrators group on their machines?  Do users have the Debug Programs privilege?  Has User Account Control been disabled everywhere?  Are you using EFS or other file-based (not sector-based) encryption for sensitive files on computers shared by multiple users?  Will desktops run scripts not digitally signed by your IT staff?  Are macros disabled in Word and Excel?  Are browsers forced to go through your proxy server?  Do you allow unsigned kernel-mode device drivers to be installed?  Are you using enclave firewalls and/or host-based firewalls to limit unnecessary internal traffic?  Are you familiar with how to use IPSec on critical servers and to only allow certain global groups to authenticate with IPSec?  Are you still running…gulp…Windows 2000?  There’s much more you can do to reduce client application risk than just applying patches.  Not sure where to start?  Apply the 20 Critical Controls of the Consensus Audit Guidelines (CAG) to get going.

Conclusion

By Googling on the technologies above you can be well on your way towards teaching yourself how to manage client application risk even when working under a tight budget.  Again, if you’ve already got Active Directory, the main price to pay is time and effort.  If you’d rather get some hands-on training on Group Policy, PowerShell, IPSec, AppLocker, etc., well then SANS has a great course for all that too, but you can certainly get started for (almost) free on your own.  Good Luck!

How To Choose The Best Encryption Software For Your Organization

0
Posted by Jason Fossen on August 17, 2009 – 3:24 pm
Filed under Misc, Project Management

These are the top 10 questions you should ask yourself and your vendor(s) before choosing a file encryption or whole drive encryption product. 

Whole drive encryption is definitely not the security panacea the vendors make it out to be.  It’s not even a silver bullet for Data Loss Prevention (DLP), the latest buzzword in this field.  The vendors are often not very helpful in guiding you through these issues because they want to sell you something, and the free products might cost a lot more than you think when you include technical support and user training, so keep the following questions in mind as you search for a data encryption solution.

1.) Does The Solution Match Your Threats?

Perform a quick risk analysis and ask yourself exactly what you are trying to prevent.  Disk encryption by itself won’t stop most malware infections, network worms, password sniffing, attacks against listening TCP/UDP ports, malicious insiders, SQL injection attacks, or a hundred other bad things.  Whole drive encryption is simply not a panacea.

If you are mainly worried about laptop theft, then ask your favorite vendors how well their products withstand 1) cold boot attacks and 2) attacks using a laptop’s 1394 Firewire port.  These well-known attacks often allow hackers to simply bypass the encryption entirely.  Ask your vendor if they are familiar with these techniques, and if they’ve never heard of these attacks (bad sign), then e-mail them these URLs and insist on a response:

http://en.wikipedia.org/wiki/Cold_boot_attack
http://www.net-security.org/dl/articles/windows7_firewire_physical_attacks.pdf
 
Whatever your favorite encryption product is, do a Google search on “cold boot attack <productname>” and “firewire attack <productname>“.

Be honest, are you really only worried about lawsuits and regulatory compliance, not actually protecting your data?  These are in fact separate issues.  If you are more worried about lawyers than hackers, then do you really have to buy the most expensive and user-obtrusive solution with all the bells and whistles in order to show responsible due care?  Will a jury understand the nuances of file-based vs. sector-based encryption or TPM vs. smart card or AES vs. 3DES or … ?  (Talk to an attorney, I’m only posing questions to consider.)

And something else to ponder: If your encrypted server can reboot unattended without any human interaction, and the server doesn’t have a cryptographic hardware module (like a TPM), then why can’t its boot-up process be reverse engineered in order to reveal the key?  From power-on to live listening ports, it’s just a dumb deterministic machine following coded rules, and the keying material has to be somewhere on the drive…

2.) At What Layer(s) Do You Want To Encrypt Data?

There are many different ways to encrypt data.  You can encrypt files by changing their format (which is independent of the filesystem, e.g., an GnuPG file), have a mountable encrypted file (with its own internal filesystem, e.g., a TrueCrypt drive), the encryption can be built into the “real” filesystem (like EFS or BitLocker), or the encryption could be handled by special hardware with any of these.  How does your vendor do it?  What method is best for your organization?  It’s important to at least understand the difference.

There are also some special cases, and not all products will encrypt them: the boot sector, master boot record, partition table, hibernation file, swap files, temp files, databases, database transaction logs, rendered print spool files, and the operating system’s own files.  Generally, whole-drive encryption products can encrypt all of these, but file-based products often cannot.   

And what about when files are being sent over the network?  Do they stay encrypted in transit?  Will you use IPSec?  How will you enforce these policies on all systems?

3.) How Much User Training And Technical Support Will Be Required?

If a product is obtrusive or bug-ridden, the user training and technical support will cost more in the long run than the licenses!  Make sure to perform focus group testing before wide-scale deployment.  Will users actively resist the product or just grumble a bit?  Will users install or configure the product themselves, or can it be all handled centrally?  Will users choose what gets encrypted?  Can you realistically trust users to encrypt the correct files?  Will users create and back up their own recovery keys?  How much extra training will the help desk require when users call for assistance?  Often, these expensive “soft” issues are ignored until it’s too late.

4.) Is The Product Compatible With Your Applications And Infrastructure?

To centrally manage your encryption solution, will you need a PKI, Active Directory, RADIUS, a new special-purpose server, or new cryptographic hardware?  If you don’t currently have the infrastructure or expertise for this, the solution may be more expensive than originally thought.  On the other hand, if you already have an infrastructure in place, like a PKI or Active Directory, maybe you should try to leverage these sunk costs to maximize the value of your investment. 

Are you absolutely certain your user applications are compatible with the encryption product?  Are you trusting what the vendor just says or has your own IT department done hands-on testing?  This can really burn you down the road if you’re not careful.  And what about your anti-virus scanners, can they scan encrypted files?  What about your database software which directly accesses the sectors of the hard drive, is it trying to bypass the encryption layer?  What about your IDS/DLP network sensors being unable to decipher encrypted traffic? 

Does the encryption product require physical human interaction when the machine reboots, such the entry of a PIN or passphrase?  If you have hundreds of servers scattered around the world, this can be very inconvenient and you will likely have to entrust other people with these secrets. 

5.) What Operating Systems And Platforms Are Supported?

Windows Vista is thankfully dead, but will the encryption work on Windows 7?  What about your Macintosh laptops and Linux netbooks?  All the world is migrating to 64-bit platforms, so is your favorite encryption product 32-bit only?  You might not think you have any Linux or Mac computers, but your IT and advertising departments might disagree. 

6.) Will The Product Encrypt PDAs, Backups, Portable Drives, Etc.?

Sensitive data exists not just on laptops, but on USB drives, backup tapes, user-burned CD/DVD disks, PDAs, mobile phones, iPod/Zune players, digital cameras, etc.  Will your encryption solution encrypt files on these media?  Can your DLP solution prevent the storage of data on unauthorized and/or unencrypted devices?  Will you be alerted when users attempt to save data on unencrypted USB drives or to burn plaintext files onto CD/DVD disks?  How will you force users to only save sensitive data on encrypted drives?  Will you have to manage keys or passwords for your backup tapes separately?

7.) Can You Recover Encrypted Data When Keys Are Lost?

Without a reliable recovery method, encryption is just a self-imposed denial of service attack waiting to happen.  It is inevitable that hard drives will become corrupted, TPM chips will short out, users will forget passwords or lose their USB dongles, software applications will have bugs, etc.  Can you recover data when keys or passwords are lost?  Does the recovery method scale to your size of organization?  Is the recovery method itself secure so that it won’t be the path of least resistance for hackers or malicious insiders? 

8.) How Are Keys Created, Stored, Changed and Archived?

Vendors always emphasize cipher algorithm and key length in their brochures, as though these are the most important criteria for making an encryption solution secure, but short keys and snake-oil ciphers are rarely the vulnerabilities to worry about.  Most vulnerabilities stem from key management issues. 

For example, if the encryption key is protected by (or derived from) the user’s own password, can you enforce a strong password policy?  Can the password hash be sniffed from the network, extracted from the hard drive, or stolen from the user’s computer by malware?  Is the same password also used for web applications, VPN, dial-up, RADIUS, eBay, Amazon, Facebook, etc.?  If so, then there are more opportunities for compromise (users love to recycle their favorite passwords). 

If the encryption key is on the hard drive, where is it and how is it secured?  Your vendor might not even be willing to tell you (not a good sign).

If the key is on a USB dongle, will your users simply keep the dongle in their laptop cases, to be stolen at the same time as the laptop?  Will the USB dongle also require a PIN?  If the key is in the user’s smart card or USB dongle, will the card or dongle self-erase after too many failed PIN guesses?

Can the encryption key be changed if you suspect compromise?  Will the help desk have to decrypt and then re-encrypt the entire drive to change the key?

Where are backup keys stored on the network?  Who can extract these backups?  How are they secured?  Is anyone monitoring these events?

In general, the above questions illustrate an important point: How your encryption keys are created, stored, changed, archived and otherwise managed is almost always much more important than the particular cipher or key length used.  If your keys are only 40 bits long or your cipher is some homebrew garbage, this is of course bad, but you are unlikely to be even considering these.   

9.) How Does The Product Fail When It Fails?

No security system is perfect, so we must have a response plan for when the system fails.  In general, we don’t want cascading, silent, catastrophic failures; we’d rather have self-limiting failures which are easy to detect and recover from.  For example, is the same key used on all/many systems, so that the compromise of that one key leads to the compromise of all/many systems?  Is the same poorly-secured recovery key used everywhere?  Can one bad apple administrator circumvent all security controls whatsoever?   

When a USB flash drive is stolen, a key is lost, a laptop goes missing, encrypted files are left permanently unencrypted, backups are made in plaintext or some other bad event occurs, is there a way these events can trigger an alert, be detected or at least be audited after the fact?  This is very difficult, but we want to be able to respond quickly to compromise in order to limit the scope of damage.  Silent and undetectable failure which spreads is the worst, it’s like a slow-growing metastatic cancer. 

In your own organization, do you have an incident response team?  If so, planning for the failure of your encryption/DLP solution should be a part of their training.

10.) What About The Future - Will You Be Vendor-Locked Forever?

After choosing a vendor and deploying your encryption solution, will you be vendor-locked forever?  What happens if your vendor goes bankrupt or get purchased three years from now?  Does your vendor have a history of keeping up with technological changes or do they only grudgingly adapt and then charge you for the upgrade?  Today you may not even know what a “tee pee hem” chip is, but tomorrow the use of a TPM or some other cryptographic hardware may be mandatory for your industry — yet that doesn’t mean your vendor will support it. 

If a programming bug is disclosed and a patch must be applied, can the patch be pushed out automatically or must it be applied by hand?  Can we remotely scan systems to confirm the presence of the patch?  Even if you are vendor-locked, does that mean you will also be version-locked by the difficulty of upgrading?  If your vendor’s upgrade plan is to “decrypt all laptops and USB drives, uninstall the old software, install the new stuff and encrypt again”, the time and effort required for this may be far more expensive than the new licenses themselves.

Conclusion

Please don’t let the foregoing discourage you from encrypting your sensitive data, just be aware that it’s more complicated than it first appears.  Hopefully these questions will help guide you in making the best decision for your organization.  Print this article and then start asking your vendor some questions, you might be surprised what they’ve not been telling you all along.  Good luck!

Blue Team Defender Guide (Capture The Flag)

0
Posted by Jason Fossen on August 12, 2009 – 8:00 pm
Filed under Blue Team, Course SEC505, Misc

In cyber war games the Red Team attackers try to hack into (or just kill) the computers of the Blue Team defenders while an automated scorebot keeps track of who is winning.  Sometimes the players also get to play a kind of capture the flag in (un)coordinated groups as they fight to keep or steal user accounts, secret files, listening ports, etc.  These network wargames are great fun and good practice for real life, especially when the adrenaline starts pumping and the yelling starts — or especially when the beer starts pumping and the drinking starts, whichever comes first… 

As the instructors of the Blue Team Courses at SANS for operating systems, Hal Pomeranz (UNIX/Linux) and myself (Windows) put together a one-page cheat sheet guide back in Oct’07 for new Blue Team players at conferences to help them survive the first ten minutes of gameplay without freaking out or immediately getting crushed.  The text of the guide is below and you can get it in PDF format too, but remember that it’s not intended to be a comprehensive incident handling guide, it’s just for those new to hacking and the capture the flag games, so have fun! 

Before Start of Play:

  • Who will be the team organizer?  The team organizer documents the networks, system names, OS versions, IP addresses, open ports, passwords, and updates configuration changes for everyone to see (such as on a whiteboard); helps to prioritize tasks; ensures that no systems are forgotten; reminds players to periodically check for compromise; monitors the functioning of the fictional production application(s) and otherwise maintains the “big picture” and a calm head while others are absorbed in the details and chaos of gameplay.
  • Exactly which port numbers must be available on which systems for the scorebot?  Can’t block these. 
  • How will the scorebot confirm that your other target applications are still running?  Don’t block the scorebot.
  • Which target systems are running the most vulnerable operating systems and/or services (such as IIS, RPC, SMB, and/or older unpatched software versions with known exploits)?  Important to prioritize.
  • What special tools will be available?  Process Explorer?  WireShark?  Tripwire?  PowerShell?  Best to ask.
  • Does everyone on the team know how to view listening ports and established sessions?  Does everyone know how to reset a password from the command line?  Does everyone know how to kill a process?  Does everyone know how to configure IPSec, the Windows Firewall and/or iptables for packet filtering?
  • Who are you permitted to ask for help if necessary?  What can or can’t they do for you?

When Play Begins:

  • Block all non-scorebot-required ports on all systems using IPSec/Windows Firewall/iptables.
  • Assign a different 15+ character long passphrase to every administrative account on every system. 
  • Change all default application and service passwords to a different 15+ character passphrase.
  • Remove all accounts from all administrative groups on each system except for one. 
  • Delete or disable all user accounts, including Guest, except for the one administrative account on each system.
  • Establish a baseline by saving lists of your current processes, listening ports, services, device drivers, user accounts, and all files (”dir /s /b” or “ls –lARt”) to text files on each machine.  If possible, generate a checksum database using a tool like Tripwire (or just md5sum).  Use this information to detect compromise.
  • Enable useful audit policies, clear all logs, and keep Event Viewer open (Windows) or “tail –f” critical log files (Linux).  When you look at a log, if you notice that the only new events are of no security consequence, clear that log to reduce clutter during the games (it’s not real life).
  • Continuously watch your list of established sessions, running processes, target applications and logs to try to detect malicious changes.  Write scripts or use command history (up-arrow or F7) to help automate this work.  Detect changes and respond: kill offensive processes, delete new user accounts, delete new binaries, etc.
  • Finally, focus on your plan and don’t panic!

 

Notepad++ PowerShell Script To Enable Syntax Highlighting and Auto-Completion

4
Posted by Jason Fossen on July 17, 2009 – 9:27 pm
Filed under PowerShell

This PowerShell script (download here) will query your system and generate a Notepad++ user language definition file for PowerShell syntax highlighting (userDefineLang.xml) and make an auto-completion file too (PowerShell.xml).  The XML files are built after the script queries your cmdlets, cmdlet parameters, aliases, WMI classes and other things, hence, the XML files are not static.  Re-run the script as necessary to refresh your Notepad++ settings. 

If you don’t have a user-defined language file, the script will create it for you.  If you do have that file already with definitions for other languages, the script will not overwrite the file, it will simply add a new language definition section for PowerShell.  And if you run the script again later, it will only update the PowerShell section of the file.

It’s possible to manually copy XML files to the correct locations on your system to get keyword highlighting and autocompletion, but this is a pain and the files will eventually become out of date as you import modules or upgrade to the next version of PowerShell, so the script is intended to be as easy as possible: just run it in an elevated shell.  (If you run it in a standard user process PowerShell, you’ll get an error message for the autocompletion file, but the syntax highlighting will still work.) 

Notepad++

What Is Notepad++?

If you’re not familiar with it, Notepad++ is a wonderful free text editor with support for many languages and has very useful plugs-ins.  It is one of the most popular editors in the world and is possibly the most popular Notepad replacement for Windows.  It’s what we use in the PowerShell course at SANS, but it also supports Perl, Python, ASP, XML, C/C++/C#, Java, Ruby and other languages too.  And while it’s certainly not as full-featured as a purpose-built PowerShell editor, it pops up almost instantly when you launch it, so you don’t have to wait 3-7 seconds before seeing the file.

In particular, you might want to enable auto-completion after running the script.  In Notepad++ pull down the Settings menu, go to Preferences, then the Backup/Auto-Completion tab, and (un)check the auto-completion boxes as desired (and complete from the 3rd character).  When you start typing inside a .ps1 script file, you’ll see what these options do…   

Caveats

There is no tech support for how to change the default font and colors set by the script.  You can easily edit the script to change the fonts and colors yourself:  After running the script, open Notepad++, pull down the View menu and select User Define Dialog to edit your current userDefineLang.xml file, then copy the new settings in that XML file into the script.  (If you find a bug in the script, that’s a different matter, please tell me about it.)

PowerShell scripting is a part of the week-long Securing Windows course at SANS because having scripting skills is terribly important for being able to manage security in a large environment.  So, I hope you’ll find this little script useful (download it here) and happy coding!

Practical Risk Analysis and Threat Modeling Spreadsheet

0
Posted by Jason Fossen on July 11, 2009 – 12:56 am
Filed under Project Management

risk analysis spreadsheet

[Download the spreadsheet for this article here or from the Downloads page.]

Learning to see your network through the eyes of your adversaries is an important part of the risk analysis and hardening process. Risk analysis involves identifying what you care about and the threats to these assets, hardening is about how to protect your assets.

A risk analysis and hardening process can range in character from the highly formalized (acronym soup, pseudo-mathematical formulas) to the very casual and informal (just a group of techs talking about “cool hacks” over beers and how they should “do something” about it). Practical risk analysis and hardening lies somewhere in between these two extremes.

Something near the middle of these two extremes, but tending toward the formal side, might be Microsoft’s whitepaper “Improving Web Application Security: Threats and Countermeasures“, and something near the middle, but more on the informal apply-some-commonsense side, might be Bruce Schneier’s five-step recipe in his book Beyond Fear.

For most organizations, if a risk analysis can’t be finished by a small group of network administrators in one afternoon (or at the most, a couple days), it just is not going to be done…that’s just a fact of how most organizations operate, especially when IT staff is limited. Fortunately, half of the benefit of doing a risk analysis comes from simply trying to do one, no matter how ugly and sloppy the end result is.

So what follows is a recipe for a half-dozen IT engineers to do a practical risk analysis and get a hardening plan started, all in one day. It’s not intended to be perfect or comprehensive, nothing ever is, it’s intended to be practical. There’s an associated spreadsheet for this article (get it here) which can help consolidate the notes from your brainstorming and planning, and it may help with generating a report or proposal to management afterwards.

Step 1: Make A List Of What You’re Trying To Protect

What are the good things you want to preserve (for this sake of this project, not everything whatsoever)? What are the services you want to keep available? What are the benefits you want to keep enjoying? You don’t have to use complete sentences, just single words or short phrases to describe the assets you are worried about and the benefits you want to continue getting from them; for example, “Assets: the four SQL and six IIS boxes in the DMZ, keep them up, running fast, no errors, no doing restores from backups, keep the databases in sync with the other SQL Servers inside the LAN, same for the other four SQL Servers inside the LAN too, the backup tapes for all of these boxes, the networking gear that connects them all to the LAN and the Internet, keep response times fast.”

Step 2: Draw A Diagram And Add Notes

On a big piece of paper, draw a diagram showing all the important networks, servers, virtual machines, clients, firewalls, routers, switches and other components that either are your assets or are required by your assets to stay available. Use different colored pens or markers for different types of items. Leave lots of blank areas for notes. Write in the names of devices, operating system version and service pack level, network ID numbers, running applications and their versions, names of Active Directory domains, and other important facts. If you’re good with Microsoft Visio or some other diagramming tool, feel free to use that instead, but don’t let a tool slow your group down.

Next, using different colored lines, draw and label arrows representing important network communications between devices, including their protocol names and/or port numbers, and, in the case of a client request and the server’s response, number them from beginning to end. In the margins, briefly indicate what’s going on in each numbered step. Don’t forget to add communications related to remote administration, monitoring, backups, and other maintenance tasks. Your diagram probably now includes more assets than originally conceived.

Next, if you have web, middleware and database servers, get a separate sheet of paper for each type of server and list or diagram the major components used inside each server. Just as there are flows of communication between devices at the network level, there are flows of communication within a server between its services, scripts, software, processes, databases, etc. Don’t try to be exhaustive here, we just want a list of the important components so nothing is forgotten, and the list will certainly be edited as you go along.

For example, on a sheet of paper for your web servers you might start with “IIS 7.0, ASP.NET, WebDAV, custom application X using regular ASP, custom application Y using PHP, third-party ISAPI filter Z, NLB, ARCserve backup agent”. For the database servers, you might start with the names of the databases, tables with high-risk data, third-party applications, custom stored procedures, etc. Again, don’t get too bogged down in the details, you’ll be coming back to these lists repeatedly.

Overall in this step, you don’t want details for the sake of adding details, you want a summary of the important assets and how they relate to each other, i.e., you want to be able to stand back and see The Big Picture.

Step 3: Make A List Of Your Adversaries And What They Want

Who are your actual or likely adversaries? What do they want to achieve? What are their skills and resources? How determined are they? What would they be willing to risk or give up in order to achieve their goals? What about insiders? You obviously can’t know all of these details for certain, but having rough profiles in mind of your actual/likely adversaries can be extremely useful, especially for the next step (and justifying your recommendations to others). For example, you might have “casual hackers looking for random sites to deface, skilled hackers looking for credit card numbers, botnets used for DoS attacks and extortion, XSS worms for installing spyware on random servers, paid hackers from other corporations or governments trying to secretly take control of our DMZ servers, our own disgruntled webmasters trying to steal a copy of the marketing database”.

There are research reports available which help to characterize your adversaries, their goals and their methods. For example, a 2008 Verizon report on over 500 security incidents breaks down the percentages of attacks by source (internal, external or partner), percentages of breaches caused by zero-day exploits versus simple misconfigurations, how breaches were detected, etc. Similar reports from other organizations can be found most easily by searching or subscribing to free security-related news feeds, such as at www.darkreading.com and www.sans.org/newsletters/.

Step 4: Brainstorm Threats From These Adversaries

Now, imagine you are one of your adversaries and try to see your network through their eyes. You know what you want, how would you try to get it? This assumes you have some familiarity with hacking techniques, but you don’t have to be an expert or penetration tester yourself, you can get started with just a few hacking books (or a course at SANS). Vulnerabilities and threats also usually fall into rough categories that can guide your brainstorming, so keep your chosen adversary in mind and brainstorm answers to the following questions:

  • Denial of Service: How can I crash the server? Run the CPUs near 100%? Consume all the free hard drive space? Consume free memory? Prevent legitimate users from connecting, authenticating or using the applications successfully? Prevent administrators from connecting? Prevent backups from running? Confuse the protocol stack? Overwhelm the routers, firewalls, switches or bandwidth? Distract or waste the time of the network administrators? Perform “data diddling” against databases to render their information worthless? Capture, modify and retransmit packets to corrupt data or disrupt network sessions?
  • Authentication: How can I log on as a legitimate user? Sniff credentials off the wire? Highjack a user’s existing session? Trick the server into using a less secure authentication protocol? Trick the server into not requiring credentials at all? Change my apparent source IP or MAC address? Use malware on users’ computers to steal credentials?
  • Elevation of Privilege: If I can authenticate as a regular user, how do I execute commands with elevated privileges? Even if I cannot authenticate, how do I run commands with standard and/or elevated privileges? How do I trick the server into executing commands with no authentication or authorization checks at all, such as with a buffer overflow exploit?
  • Disclosure: How do I trick the server into revealing the information I want in plaintext form? How do I get the server to reveal the location of the data I want? How do I crack the encryption? Where are the keys stored or how are they generated? How do I make the server store data insecurely? How do I make the server transmit data insecurely, such as disabling SSL or killing the IPSec driver?
  • Tampering: How do I make and save changes to my target database, file, encryption key, registry value, session, or other data structure? How do I make the change so that it will be accepted as a normal transaction? How can I repeat or replay a transaction or transmission and have it accepted as legitimate?
  • Malware Installation: How do I get malware of my choice running on the server? How do I upload files or trick the server into downloading files of my choice? How do I construct a script or binary on the target server? How do I subvert a script or binary which is already on the target?
  • Stealth and Repudiation: How do I edit or delete log data after my attack? How can I hide my packets/commands/data from inspection by firewalls, IDS/IPS sensors, or security staff who are sniffing the wire? How can I thwart auditing or forensics of the server afterwards? How do I frame other users for the crime? What do I need to change in order to deny anyone the use of data which could get me prosecuted or fired if I am identified?
  • Social Engineering: And for all categories of attack, how do I use Social Engineering (SE) tricks to make the attacks work or be even more effective? SE is often both forgotten and the most effective attack method.

List your threats in a spreadsheet and expect to revise the list. Put all the threats in one column which has been labeled “Threats”.

Step 5: Estimate Probability And Potential Damage (The Overall Risk)

In your threats spreadsheet, add the following column headers:

  • Threats: Description of the threat and/or vulnerability from Step 4.
  • Risk Score: Sum of the numbers in the following columns.
  • Legal Damage: How bad would the legal liability be if the attack succeeds?
  • Reputation Damage: How bad would the damage be to image and trust?
  • Productivity Damage: How bad would the damage be for user productivity?
  • Discoverability: How easy would it be to find the vulnerability or targets?
  • Exploitability: How easy is the attack in terms of skills and resources needed?
  • Stealthiness: How difficult would it be for IT to detect the attack?
  • Repeatability: How easy would it be to successfully repeat the attack after security personnel have learned to detect it?

Use your best guess to characterize each threat by assigning a roughly-estimated number under each column using the following guide:

  • None = 0
  • Low = 3
  • Medium = 5
  • High = 7
  • Worst = 10

Don’t worry about the exact numbers and their precise meanings, it’s not an exact science. Configure your spreadsheet so that the “Risk Score” column should be the sum of the other columns in that row, then sort on the “Risk Score” column from largest to smallest. You now have a rough prioritization of your threats in terms of potential damage and probability of occurrence. For the probability portion, the assumption is that a threat is more likely to be realized if 1) its corresponding vulnerability is easy to discover, 2) easy to exploit, 3) can be exploited without detection, and 4) can be successfully repeated even if prior such attacks have been detected and correctly characterized.

Step 6: Brainstorm Countermeasures And Their Issues

Now add two more columns to your spreadsheet:

  • Countermeasures: What will block or mitigate the threat?
  • Issues: What are the negative side effects of the countermeasure(s)?

Very briefly describe what countermeasures you intend to implement to block or mitigate the potential damage and/or probability of occurrence of each threat. Don’t use full sentences, just indicate the ideas, e.g., “apply latest updates, use IPSec for RADIUS and SQL traffic, use host-based firewall, hourly live backups, add Snort sensor, require long passphrases”, etc. If you need more space, add a new tab to the spreadsheet for that threat and make a note of this in the “Countermeasures” column.

Not sure where to start when choosing countermeasures? Well, consider starting with the 20 Critical Security Controls of the Consensus Audit Guidelines (CAG).

Most countermeasures involve a monetary price, time/effort expense, opportunity cost, negative externality, compatibility issue, or some other unwanted side effect which is not intended. Or perhaps the countermeasure is only effective when very special requirements are met. Or perhaps a countermeasure is required for compliance (PCI or SOX) even if it doesn’t do much good. The “Issues” column is where you don’t forget to consider all these things, it’s a reminder. In some cases, the negatives that comes with an effective countermeasure simply make that countermeasure not worth it, even though it’s effective, hence, it will have to be replaced with something else. In other cases, a countermeasure might be only partially effective, but because its “price” is small, you should still deploy it as long as other countermeasures are implemented too. Unfortunately, there is no formula for filling in the “Issues” column, it contents come from experience.

Step 7: Plan, Test, Pilot, Monitor, Troubleshoot and Repeat

You now have a rough guide of what threats are most important and what their countermeasures will be, so it’s time to start creating more detailed project plans, performing lab tests, pilot tests, monitoring affected systems, and getting prepared to troubleshoot issues as they arise. Along the way, don’t forget to document what you’re doing and what you’ve discovered so that others in the organization can benefit as well. Start with the threats that scored the highest and work your way down. By the time you’re done, the network will have changed or you will have learned about new vulnerabilities and attack methods, so the whole process will repeat again, but at least the next time through you won’t be starting from scratch.

Conclusion

Even a crude risk analysis and hardening plan is vastly better than just winging it, and in many ways a crude plan is better than an overly formal one if the formal one will never be completed…or even started (another case of “the perfect is the enemy of the good“). I hope this seven-step recipe will help you get your own security projects underway!

Windows 7 and IE8 CIS Security Baselines

0
Posted by Jason Fossen on July 9, 2009 – 2:05 pm
Filed under CIS, Windows 7

[From Blake Frantz at the Center for Internet Security (CIS)]

The Center for Internet Security (CIS) and Microsoft are collaborating on security baselines for Windows 7 and Internet Explorer 8.  On July 13, 2009, beta versions of these baselines will be available for review from the Microsoft Connect site. On August 5, 2009, Microsoft will host a Live Meeting session to discuss these security baselines and gather feedback from the CIS Community – and you’re invited! This is a great opportunity to get answers to your Internet Explorer 8 and Windows 7 security questions, get a head start on defining your organization’s configuration standards for these technologies, and contribute your expertise to the community.

 Here’s what you need to do to get involved:

1) Join the Microsoft Connect Beta program for the Windows 7 and Internet Explorer 8 security baseline project by following this invitation link.  (Please note: You will need a Windows Live ID to login to this site. If you do not already have one, a link is provided for you to create one.)

2) Download and review the Windows 7 and Internet Explorer 8 security compliance baselines. The following resources are included:

The Widnows 7 Security Compliance Baseline Beta includes:
• Windows 7 Security Guide
• Windows 7 Security Baseline Settings
• Windows 7 GPO Back-up Files
• BitLocker Security Baseline Settings
• BitLocker GPO Back-up Files

The Internet Explorer 8 Security Compliance Baseline Beta includes:
• Internet Explorer 8 Security Guide
• Internet Explorer 8 Security Baseline Settings
• Internet Explorer 8 GPO Back-up Files

3) Provide your feedback on the baselines using the Microsoft Connect feedback form. Instructions and a link are provided on the Beta program page.

On August 5, 2009, attend the Live Meeting session to discuss the security baselines.

Important Dates:
July 13, 2009 – Beta release of Windows 7 and Internet Explorer 8 security baselines.
August 5, 2009 – Live Meeting session to discuss and provide feedback on the security baselines.

SANS Consensus Audit Guidelines (CAG) 20 Critical Security Controls for Windows

0
Posted by Jason Fossen on June 30, 2009 – 11:19 pm
Filed under Course SEC505

The SANS Institute is a partner in the Consensus Audit Guidelines (CAG) project to define the 20 critical security controls most important for network security.  The project defines high-level recommendations, but these recommendations cannot describe in detail, of course, how to implement them in every environment because every environment is different.  But the fact of the matter is that most environments run Windows, and most of these Windows machines are joined to Active Directory domains, that’s just the way it is.

This blog is also about the Securing Windows Track (SEC505) at SANS, so the questions for this article are:  “How does SEC505 map onto the 20 critical controls?  How well does SEC505 prepare one to implement the 20 controls in a Microsoft shop?”  You won’t be surprised to hear, of course, that the answer is “Very Nicely“, but there are gaps and I’ll point them out below.  SANS also has a vendor-neutral course entitled “20 Critical Security Controls (SEC566)“, but SEC505 is specifically for Windows and has material that goes far beyond the 20 Controls, such as IIS 7.5, IPSec, PowerShell scripting and Windows PKI deployments.

For each of the 20 critical controls, the following describes what’s covered in the six-day Securing Windows course that can help you actually implement the controls on Windows systems, not just audit them, and offers suggestions for other SANS courses to fill the gaps in addition to SEC566.  (You might open another tab in your browser to the CAG page to see the summary of each control for comparison with the following.)

Note: The headings below are color-coded: Green means that the control is covered well, Black means the control is covered adequately or partially, and Red means the control is covered slightly or not at all.

Control 1: Inventory of Hardware Devices

SEC505 does not cover hardware inventory products.  However, when gathering inventory data with nmap and other tools, you inevitably run up against problems of how to organize, store, search, compare and generate reports from the mountains of data collected.  This is true even of GUI commercial tools because the vendors can’t anticipate every possible query or report you’ll want.  Whether you use databases, spreadsheets, XML or just comma-delimited text files to store the data, PowerShell is a superb command shell and scripting language for manipulating that data.  Many security tasks are not performed because the administrators lack scripting skills, and inventory tasks are perfect examples.  Because of this, SEC505 includes a full day on PowerShell scripting.

Control 2: Inventory of Software

SEC505 does not cover software inventory products, though there are third-party enhancements for Group Policy for this purpose, and PowerShell can query remote systems through the WMI interface.

More important than inventory, though, this control also advises locking down software configuration, using application whitelisting, logging application usage, and preventing unwanted application installation.  In SEC505 an entire day is devoted to Group Policy and there are many Group Policy technologies for just these sorts of problems, e.g., Software Restriction Policies, AppLocker, audit/logging policies, managing NTFS permissions, configuring almost every aspect of Internet Explorer and the Microsoft Office applications, code signing requirements for scripts/macros, restricting MSI package installation, running scripts to identify non-standard software, etc.

Control 3: Secure Configurations for Computer Systems

Windows machines are not hardened by hand, but by the application of INF/XML security templates, such as with the FDCC templates from NIST, CIS and Microsoft.  These templates are applied using Group Policy, SECEDIT.EXE, the Security Configuration and Analysis MMC snap-in, or the Security Configuration Wizard (all of which are covered in SEC505).  For the few settings that cannot be configured through a template or Group Policy, it is likely that a script would be used so that the changes could be automated (PowerShell again).  NIST’s FDCC configuration settings are distributed in the form of Group Policy Objects because this is how these settings are best deployed.  This control is very well covered in SEC505, especially in the day on Group Policy.

Control 4: Secure Configurations for Network Devices

SEC505 does not cover firewall design, please instead see Perimeter Protection In-Depth (SEC502).

Control 5: Boundary Defense

SEC505 does not cover firewall or IDS design, please see Perimeter Protection In-Depth (SEC502) and Intrusion Detection In-Depth (SEC503).

Control 6: Audit Logs

Windows audit policy and logging is configured through security templates and Group Policy, as mentioned above, since each machine has its own event logs.  SEC505 also covers how to enable logging in the RADIUS servers controlling remote access, such as for VPN, dial-up and 802.11 wireless (in Day 4).  All of this data will need to be consolidated at a central location, usually with a third-party SIM, but when the human touch is needed to go beyond the canned queries and reports of your SIM, how can that data be efficiently extracted and analyzed?  Again, PowerShell scripts using regular expressions and SQL queries work very nicely.  What about configuring third-party SIM products?  Not covered in SEC505.

Control 7: Application-Layer Software Security

SEC505 does not cover secure coding, web application testing or database security.    However, SEC505 does devote a full day to IIS web server hardening.  In that course we talk about, among other things, how to perform HTTP application-layer filtering with the URL Rewrite module and regular expressions, which can be used to implement a basic web application firewall (and the CAG does recommend using a web application firewall).  The IIS day of SEC505 is mainly concerned with locking down IIS servers, which is a special case of Control #3 above.

Control 8: Administrative Privileges

Virtually every recommendation in this control regarding administrative user accounts is discussed in SEC505, especially in the Active Directory (505.1) and Group Policy (505.2) days.  The PKI day of SEC505 (505.3) also walks the attendee through the process of setting up a Windows PKI and issuing smart cards and other certificates to administrative users for secure multi-factor authentication.

Control 9: Need To Know

SEC505 does not discuss need-to-know access control methodology or testing per se, but, again, such controls would be largely enforced through Widnows user groups, security templates and Group Policy.  Testing could be automated through PowerShell scripts which authenticate over the network as different users with different privileges.

Control 10: Vulnerability Scanning

SEC505 does not cover vulnerability scanners, which are covered in other courses, such as Security Essentials (SEC401).

Control 11: Account Monitoring and Control

Most recommendations in this control would be implemented through a combination of Active Directory ACLs, Group Policy settings, and custom AD queries, perhaps with PowerShell scripts.  And all of these topics are nicely covered in SEC505.

Control 12: Malware Defenses

SEC505 does not cover tarpits or honeypots, which are covered in other courses, including Security Essentials (SEC401).  Anti-malware techniques are discussed throughout the week, such as User Account Control benefits and managing Internet Explorer settings, but a comparison of particular AV scanning products or debate about where to install them, that is not covered.

Control 13: Control of Network Ports, Protocols and Services

Group Policy and command-line administration of IPSec and the new Windows Firewall is covered in SEC505 in great detail.  The combination of IPSec + Windows Firewall + Group Policy grants very precise and flexible control over which users and computers are permitted to access which ports/services on which machines; it is possible, for example, to configure something like per-user “roaming VLANs” with these technologies and what Microsoft calls “domain isolation“.  Day four of SEC505 is devoted to IPSec, the new Windows Firewall, the Microsoft RADIUS service, RRAS VPNs (IPSec/SSL/PPTP) and 802.11 wireless security.

Control 14: Wireless

Day four of SEC505 walks you through the steps of setting up a PKI, pushing out wireless certificates (or smart cards), installing RADIUS servers, configuring the wireless settings on laptops through Group Policy, and enforcing the use of WPA2, AES encryption and PEAP authentication at the RADIUS servers.  Through Group Policy you can also lock down and then hide the other wireless options from non-administrative users, e.g., you can prevent them from connecting to ad hoc networks.  Other recommendations in this control unrelated to Windows configuration, such as scanning for rogue access points, are not covered in the course.  SANS has a great week-long track on wireless security (SEC617), but that course isn’t for Windows networks specifically, SEC505 is.

Control 15: Data Loss Prevention

SEC505 covers many of the recommendations of this control for DLP, mainly in day three.  This includes BitLocker whole drive encryption, “BitLocker To Go” for USB flash drives, EFS file encryption, and Group Policy control of USB device usage.  To search for Personally Identifiable Information (PII) on systems, a custom PowerShell script could be used, but this is not discussed per se in the course.  Monitoring the network for data leakage is not covered in SEC505 (try SEC503).

Control 16: Secure Network Engineering

Firewall design is covered in a different course at SANS, Perimeter Protection In-Depth (SEC502), but this control is more broad than that.  As discussed for Control 13, we have Group Policy control over IPSec and Windows Firewall settings for rapid response to attacks.  And in day one of SEC505, DNS security is covered because DNS is the Achilles’ heel of Active Directory.  DHCP logging is easy to enable, so it’s mentioned too, and one might use PowerShell to extract data from large DHCP logs.  Hence, most of the recommendations in this control are covered in SEC505.

Control 17: Penetration Testing

SEC505 does not cover penetration testing, which is discussed in other courses, such as Network Penetration Testing and Ethical Hacking (SEC560).

Control 18: Incident Response Capability

SEC505 does not cover incident response planning, this topic is discussed in other courses, such as Hacker Techniques, Exploits and Incident Handling (SEC504).

Control 19: Data Recovery Capability

SEC505 does not cover how to perform backups and recovery, please see Security Essentials (SEC401) or contact your backup solution vendor.

Control 20: Skills Assessment and Training

SEC505 does not cover security training or awareness testing, please see Security Policy and Awareness (MAN524).

Dump Windows Event Logs To CSV Text Files (VBScript)

10
Posted by Jason Fossen on June 30, 2009 – 9:21 pm
Filed under VBScript

There are a number of tools available for dumping Windows event logs to text files, but there always seems to be a problem or missing data or weird formatting or license issues or…something!

This DumpEventLog.vbs script hopefully is better or at least sucks less, it’s features are:

  • Writes output to well-formed CSV text file (one line per log entry, crazy Microsoft formatting cleaned out).
  • Works against local and remote systems running Windows 2000 or later (if you have admin privileges).
  • Can output all the data from each log entry, even the “insertion strings” and binary attachments (in hex).
  • Dump one, some or many event logs on a system by name, or use /all switch to dump them all.
  • Events from all the logs are first sorted by time to maintain chronology, then appended to the CSV file.
  • CSV data can be directly opened in a spreadsheet or easily imported into a database.
  • Script uses asynchronous WMI queries (SWebmSink object) so it’s relatively fast for not being a binary.
  • Written in VBScript, so it’s easy to edit if you want to change the output or otherwise modify it.
  • Public domain, do with it as you wish!

The intent of the script is to be able to consolidate event log data from multiple machines at one location for local analysis using PowerShell, grep, Excel or whatever your favorite tools are, then to compress the CSV files with gzip for archival.  In the zip file with the script are some sample batch scripts for extracting events of different types.  (If you want a PowerShell version of the script, I’ll get around to it eventually!)

Switches

In a command shell, run “cscript.exe dumpeventlog.vbs /?” to see the help for the script.

DumpEventLog.vbs target file.csv "logname(s)" [/clear] [/v] [/dumphex]
DumpEventLog.vbs target file.csv /all [/clear] [/v] [/dumphex]

Target is the name or IP address of the system from which to extract event log data.

File.csv is the name or full path to a text file, to which the extracted data will be appended.

“Logname(s)” is a comma-separated list of event log names to be dumped (not case sensitive).

/All will dump all the event logs, whatever their names are (not limited to System, Security and Application).

/Clear will clear each log afterwards.

/V for verbose output with entry message text.

/DumpHex implies /V and will also dump insertion strings and any binary attachments.

Target machine must be Windows 2000 or later, running the Windows Management Instrumention (WMI) service, without firewall restrictions for the necessary RPC traffic.  Authentication is single sign-on, so you’ll likely need to log on locally as a Domain Admin in order to dump any log from any remote machine in your domain.  If you schedule the script, it must run under the context of an account (probably a global account) with the necessary privileges to extract/clear the Security event log.

(On a side note, the script was originally written for a scripting course for the sake of discussing WMI, synchronous vs. asynchronous WMI queries, regular expressions, and how to use a connectionless recordset with ADO, so you might find the badly-written code interesting if you’re learning VBScript.)

The Batch Scripts

The other batch scripts in the zip download, such as Last_50_Failed_Logons_In_Excel.bat, are simply to demo how fast and convenient it is to analyze event log data from the command line using free tools like findstr.exe, grep.exe, tail.exe, etc.  Run the AutoDumpAndClearEventLogs.bat first on a test machine to get rolling.

Download the zip file here or from the Downloads page of this blog.

[Updated 17.Nov.09: Script changed to more aggressively clean out unicode characters which cause problems in 64-bit Windows.]