Windows Security SEC505: vLive in January and the Orlando conference in April 2014

Comments Off on Windows Security SEC505: vLive in January and the Orlando conference in April 2014
Filed under Course SEC505

The SANS Institute’s six-day Securing Windows with the Critical Security Controls  course (SEC505) will be offered both as an Internet vLive event, every Monday and Wednesday evening, starting January 27, 2014, and again at the big conference in Orlando, starting on April 5, 2014 at the Walt Disney Dolphin Hotel.

SEC505 also prepares you for the GIAC Certified Windows Administrator (GCWN) certification exam, satisfies the Department of Defense 8570 computing environment (CE) requirement, and can be applied towards a fully accredited Masters Degree in Information Security from the SANS Technology Institute (www.sans.edu).

Download Scripts

Comments Off on Download Scripts
Filed under Course SEC505

All the SEC505 scripts are free and in the public domain:

Download the scripts and other files for the Securing Windows and Resisting Malware track (course number SEC505).

The above scripts.zip file contains many other folders and files.  Look for the files you want in the folders inside this zip.

 

Evening Talks and Other Files:

What’s New in Windows 8 and Server 2012 (SANS Evening Talk).

Windows Exploratory Surgery with Process Hacker (SANS Evening Talk).

 

 

SANS 20 Critical Security Controls for Windows

0
Filed under Course SEC505

The SANS Institute is a partner in the Critical Security Controls  project to define the most important tasks for network security.  SANS offers a great course entitled “Implementing and Auditing the Critical Security Controls (SEC566)”, but which course should one take after  attending SEC566?

Course SEC566 defines recommendations in a vendor-neutral way, but in fact most environments run Microsoft Windows and most of these Windows machines are joined to Active Directory domains.  Is there a SANS course which offers a deep dive into the Critical Security Controls as they specifically relate to Windows and Active Directory?

Yes, the six-day  Securing Windows with the Critical Security Controls   course at SANS (course number SEC505) is specifically written to provide in-depth coverage of just those Critical Controls which affect Windows servers and clients.

Which Controls Are Covered In SEC505 and Which Are Not?

For each of the Critical Controls, the following describes what’s covered in the Securing Windows  (SEC505) course that can help you implement the controls on Windows systems, not just audit them.  It also offers suggestions for other SANS courses after taking SEC566.

You might open another tab in your browser to Critical Controls page  to see a summary of the controls for comparison.

Color Highlighting

The headings below are color-coded:

  • Green means that the control is covered well in SEC505.
  • Black means the control is covered adequately or partially.
  • Red means the control is covered slightly or not at all.

Control 1: Inventory of Hardware Devices

SEC505 does not cover hardware inventory applications.  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.   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 applications, 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 just inventory, though, this control also advises locking down software configurations, 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., 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.  SEC505 specifically discusses hardening techniques for Java, Internet Explorer, Google Chrome, Adobe Reader, and Microsoft Office.

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 those provided with the  Microsoft  Security Compliance Manager.  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).

Control 4: Vulnerability Assessment and Remediation

SEC505 does not cover vulnerability scanners, which are covered in other courses, such as  Security Essentials (SEC401).  On the other hand, vulnerability remediation is covered very well in the sections on patch management, Group Policy, applications hardening, etc.

Control 5: Malware Defenses

Anti-malware techniques are discussed throughout the week, such as User Account Control, DNS sinkholes, hardening Internet Explorer and Chrome, Java, Adobe Reader, using jump servers, AutoPlay/AutoRun, etc.  But a comparison of particular AV scanning products or debate about where to install them, that is not covered.

Control 6: Application-Layer Software Security

SEC505 does not cover  secure coding,  web application testing  or  database security.    However, SEC505 does devote a half-day to server hardening (day 5), such as for IIS web servers.

Control 7: Wireless Device Control

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.  The problem of rogue access points, tethering and BYOD computers is also discussed.  SANS has a great week-long track on wireless security (SEC617), but that course isn’t for Windows networks specifically, SEC505 is.

Control 8: 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 9: Skills Assessment and Training

SEC505 does not cover security training or awareness testing in detail, please see  Securing the Human (MAN433).

Control 10: Secure Configurations for Network Devices

SEC505 does not cover firewall design or the configuration of routers and switches;  please instead see  Perimeter Protection In-Depth (SEC502).

Control 11: Control of Network Ports, Protocols and Services

Group Policy and command-line administration of IPSec and the 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.  Day four of SEC505 is devoted to IPSec, Windows Firewall, Microsoft RADIUS service for 802.1x authentication of wireless and Ethernet clients. 

Control 12: Administrative Privileges

Every recommendation in this control regarding administrative user accounts is discussed or demonstrated in SEC505 (day 2).  The PKI day of SEC505 (day 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.  Securely managing administrative credentials, which includes service accounts, is one of the most difficult and important tasks.  SEC505 spends almost an entire day on just this one control because of its importance to Windows in particular.

Control 13: Boundary Defense

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

Control 14: 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 gateways and wireless access points (in Day 4).  All of this data will need to be consolidated at a central location, usually with a third-party SIEM, but when the human touch is needed to go beyond the canned queries and reports of your SIEM, 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 SIEM products?  Not covered in SEC505.

Control 15: Controlled Access Based on Need To Know

It’s all well and good to talk about the principle of Need To Know, but where does the rubber meet the road?  How do you actually implement this principle across servers in an enterprise?  This control would be largely enforced through Windows user groups, security templates, Group Policy, and Dynamic Access Control policies.  Testing could also be automated through PowerShell scripts which authenticate over the network as different users with different privileges.  Dynamic Access Control (DAC) is something new with Server 2012 specifically for Data Loss Prevention (DLP) and enforcing need-to-know rules.  All these topics are covered in SEC505.

Control 16: Account Monitoring and Control

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

Control 17: Data Loss Prevention

SEC505 covers many of the recommendations of this control for DLP, including BitLocker whole drive encryption, “BitLocker To Go” for USB flash drives, Group Policy control of USB device usage, and something new built into Server 2012 and later called Dynamic Access Control.  Dynamic Access Control (DAC) is specifically for enforcing need-to-know rules and DLP, and it’s already built into Server 2012.  To search for Personally Identifiable Information (PII) on systems, a custom PowerShell script could be used as well.  Monitoring the network for data leakage, on the other hand, is not covered in SEC505 (try SEC503).

Control 18: Incident Response

SEC505 does not cover incident response planning, this topic is discussed in other courses, such as  Hacker Techniques, Exploits and Incident Handling (SEC504)  and also  Advanced Computer Forensic Analysis and Incident Response (FOR508).

Control 19: Secure Network Engineering

Firewall design is covered in a different course at SANS, but this control is more broad than just perimeter firewalls.  As discussed above, we have Group Policy control over IPSec and Windows Firewall settings for rapid response to attacks.  We also cover DNSSEC, DNS sinkholes, DNS secure dynamic updates, eliminating NetBIOS and LLMNR, and DHCP logging is easy to enable.  One might also use PowerShell to extract data from large DHCP/DNS logs.  Hence, most of the recommendations in this control are covered in SEC505, and then some.

Control 20: Penetration Tests

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

Australian Government Four Controls

The Australian government has determined that four of the 20 Critical Controls are the most effective in blocking intrusions.  All four are discussed and demonstrated at length in SEC505:  we use Group Policy and WSUS for software management, AppLocker for whitelisting, and devote nearly an entire day to one of the most difficult-to-implement controls, namely, controlling administrative privileges.

Automation: Group Policy + PowerShell

The 20 Critical Controls project emphasizes the importance of automation. Automation and scalability are accomplished in SEC505 by providing training on Group Policy and PowerShell. Group Policy is an Enterprise Management System (EMS) built into Active Directory that can more-or-less manage every Windows configuration setting and user application, including Chrome and Java. PowerShell is not just a scripting language, it is a remote management framework that can scale to very large networks, such as Microsoft’s own cloud infrastructure. The combination of Group Policy plus PowerShell is a force multiplier for automation of the 20 Critical Controls.  And where these fall short, SEC505 also includes recommendations for third-party products, such as vulnerability scanners, SIEM systems, and USB device blockers.

Ask The Course Author

If you have any questions about the Securing Windows (SEC505) course, the full course description  is online, and feel free to contact the course author too: Jason Fossen (jason -at- sans.org).

 

Reset Local Administrator Password Using A Different Random String On Each Computer And Recover The Passwords Securely

6
Filed under Course SEC505, Cracking Passwords, PKI, PowerShell

The passwords of local administrative accounts should be changed regularly and these passwords should be different from one computer to the next.  But how can this been done securely and conveniently?  How can it scale to thousands of computers?  And how can this be done for free?

The Securing Windows and Resisting APT Malware course at SANS (course SEC505) includes free PowerShell scripts to manage local account passwords.  Download the scripts in the SEC505 zip file, then look inside that zip archive for the \Day2-Admins\UpdatePasswords\ folder.

These PowerShell scripts are intended to be relatively easy to understand and modify, you don’t have to be a PowerShell guru, just have some basic familiarity.  Like all scripts in the SEC505 zip file, these scripts are in the public domain too.

If you would prefer a non-PowerShell commercial product to manage admin passwords, here are few to consider:

 

Solution

A trusted administrator should obtain a certificate and private key, then export that certificate to a .CER file into a shared folder (\\server\share\cert.cer).  Any certificate from any source for any intended purpose will do, but a 2048-bit RSA public key (or larger) from one’s own PKI is preferred.

Copy the Update-PasswordArchive.ps1 script into that shared folder (\\server\share).

Using Group Policy, SCCM, a third-party EMS, schtasks.exe or some other technique, create a scheduled job on every computer that runs once per week (or every night) under Local System context which executes the following command:

powershell.exe \\server\share\update-passwordarchive.ps1 `
-certificatefilepath \\server\share\cert.cer `
-passwordarchivepath \\server\share `
-localusername Administrator

This resets the password on the local Administrator account (or whatever account is specified at the command line) with a 15-25 character, random complex password. The password is encrypted in memory with the public key of the certificate (cert.cer) and saved to an archive file to the specified share (\\server\share).

When a password for a computer (for example, laptop47) needs to be recovered, the trusted administrator should run the following PowerShell script at their local computer:

recover-passwordarchive.ps1 -passwordarchivepath \\server\share `
-computername laptop47 -username administrator

This downloads the necessary encrypted files, decrypts them locally in memory using the private key of the administrator, then outputs the plaintext password within PowerShell.  The password can then be piped into other commands to open an RDP session, copy files, execute another command, etc.

 

Requirements

PowerShell 2.0 or later must be installed on both the computer with the local user account whose password is to be reset and also on the administrators’ computers who will recover these passwords in plaintext.

The Update-PasswordArchive.ps1 script, which resets the password, must run with administrative or Local System privileges.

 

Testing Example

From the SEC505 zip file, copy the \Day2-Admins\UpdatePasswords folder to your hard drive.

In File Explorer, double-click the “Password-is-password.pfx” file to import the test certificate and private key into your current user store (accept all the defaults).  The password is “password”.

Open PowerShell with administrative privileges and run this command to reset the password on the Guest account:

.\Update-PasswordArchive.ps1 -LocalUserName Guest -CertificateFilePath .\PublicKeyCert.cer

Do a “dir” listing and you will see a new file with a very long name, similar to the following:

MYCOMPUTER+Guest+635108515647128197+F5FF0247B0CF6A81148CE83D2EBA4A141CB095F3

If you open the file in Notepad or a hex editor, you’ll see that it has been encrypted with the public key in the PublicKeyCert.cer file.  The private key for this public key has already been imported into your local user certificate store, hence, you can use your private key to extract the password from the encrypted file.  Unless hackers have stolen your private key, they will not be able to decrypt the file and obtain the password inside it.

To obtain the plaintext password, run this command:

.\Recover-PasswordArchive.ps1 -ComputerName $env:computername -UserName Guest

The output is an object with the plaintext password and other properties, similar to this:

ComputerName : MYCOMPUTER
FilePath : MYCOMPUTER+Guest+635108515647128197+F5FF0247B0CF6A81148CE83D2EBA4A141CB095F3
UserName : Guest
TimeStamp : 7/31/2013 7:12:44 AM
Thumbprint : F5FF0247B0CF6A81148CE83D2EBA4A141CB095F3
Valid : True
Password : TheRandomComplexPassword

The password property can now be piped into other commands or copied into the wetware clipboard through your retina.

To see the full help for this script, run:

get-help -full .\Update-PasswordArchive.ps1

 

Notes

The password is never sent over the network in plaintext, never saved to disk in plaintext, and never exposed as a command-line argument, either when resetting the password or when recovering it later. The new password is generated randomly in the memory of the PowerShell process running on the computer where the password is reset. The process runs for less than a second as Local System as a background process.

Different certificates can be used at different times, as long as their private keys are available to the administrator. When recovering a password, the correct certificate and private key will be used automatically, even if multiple certificates are in use. A smart card can be used too. The script has been successfully tested with the Common Access Card (CAC) used by the U.S. military and DoD.

If the shared folder is not accessible to the computer when the scheduled job runs, the password is not reset.

If multiple administrators must be able to recover the plaintext passwords, export the relevant certificate and private key to a PFX file and import it into each administrator’s local profile. Because this is not a certificate used to uniquely identify a person or device (non-repudiation is not an intended feature), everyone on the help desk could have a copy of its private key.

To delegate authority to different administrators over different computers, then simply use different public/private key pairs. When using Group Policy to create the scheduled job on the machines in an organizational unit, for example, any certificate can be specified, and this does not have to be the same certificate used for all machines in a domain. The corresponding private keys can be shared with whatever subset of administrators is desired. If the private key is on a smart card, that card can be physically protected from unauthorized admins.

The password update script writes to the local Application event log on the machine where it runs (Source: PasswordArchive, Event ID: 9013).  When the password is used to log into the computer, this can also be logged if the appropriate audit policies are enabled.  The SEC505 zip file includes another script (SendTo-SysLog.ps1) if you’d like to modify the update script to also send a syslog message whenever the script runs.

The script can only be used to reset the passwords of local accounts, not domain accounts in Active Directory, though it could be modified for this purpose.

 

Threats

Keep the private key for the certificate used to encrypt the password archive files secure, such as on a smart card.  This is the most important factor.  Do not use the sample keys provided here for anything other than testing.

If the private key for the certificate is compromised, create a new key pair, replace the certificate file (.CER) in the shared folder, and immediately remotely trigger the scheduled job on all machines using Group Policy, schtasks.exe or some other technique. Once all passwords have been changed, the fact that the old private key has been compromised does not mean any current passwords are known.

Use an RSA public key at least 2048 bits in size.  The public key encrypts the random 256-bit Rijndael key in each file which is used to encrypt the password in that file.  Each archive file has a different Rijndael key.  RSA and Rijndael are used for backwards compatibility (using AES explicitly requires .NET Framework 3.5 or later).  Rijndael was selected by NIST for the AES cipher.

Prevent modification of the Update-PasswordArchive.ps1 script itself by digitally signing the script, enforcing script signature requirements, and using restrictive NTFS permissions.  Only allow NTFS read access to the script to those identities (computer accounts) which need to run it.  Use NTFS auditing to track changes to the script.

Attackers may try to corrupt the existing password archive files to prevent access to current passwords. Each archive file contains an encrypted SHA256 hash of the username, computername and password in that file in order to detect bit-flipping attacks; the hash is checked whenever a password is recovered.

To deter file deletion, it’s best to store the certificate and archive files in a shared folder whose NTFS permissions only allow the client computer accounts the following permissions:

Principal: Domain Computers
Apply to: This folder, subfolders and files
Allow: Full Control
Deny: Delete subfolders and files
Deny: Delete
Deny: Change permissions
Deny: Take ownership
Deny: Create folders/append data

Principal: Domain Computers
Apply to: Files only
Deny: Create files/write data

The trusted administrators can be granted Full Control to the archive files, certificates, and scripts as needed of course.  The above permissions are for just for Domain Computers.

An attacker might try to generate millions of spoofed archive files and add them to the shared folder.  This is possible because the script and public key would be accessible to the attacker too.  NTFS auditing on the share can log which computer(s) added the spoofed files and when.  The archive files might be digitally signed, but with what key?  We must assume the attacker can extract any signing keys from kernel memory on the computers they have already compromised.  Realistically, though, a DoS attack in which millions of new archive files are created would likely be of low value for the attacker since it would be easy to detect, easy to log the name or IP of the machine creating the new files, easy to use timestamps in the share to identify post-attack files, nightly backups of the archive files can be retained for 30+ days, and the DoS attack would not allow the hacker to expand their existing powers to new machines.  Besides, the benefit to us of managing local administrative account passwords correctly far exceeds the potential negative of this sort of DoS attack.

IPSec permissions which limit access to the SMB ports of the file server is recommended, but not for the encryption, but for restricting access to the SMB ports (TCP 139/445) based on group memberhips, e.g., domain computer, administrators, help desk personnel, etc.

 

Tips

The output of the Recover-PasswordArchive.ps1 script can be piped into other scripts to automate other tasks which require the plaintext password, such as executing commands, doing WMI queries, opening an RDP session, or immediately resetting the password again when finished.

When recovering a password, you can pipe the password into the built-in clip.exe utility to put the password into the clipboard, like this:

\\controller\password-archives\Recover-PasswordArchive.ps1 `
 -PasswordArchivePath \\controller\password-archives -ComputerName laptop47 `
 -UserName Administrator | select-object -expandproperty password | clip.exe

What prevents an endless accumulation of encrypted password archive files in the shared folder?  The CleanUp-PasswordArchives.ps1 script will remove older or obsolete archive files which are no longer needed.  Run this script as a scheduled job once per month.  See the help in that script for its command-line parameters to customize what it deletes, e.g., by default it keeps the last five password archive files for each computer and username combination, but this can be changed.

To optimize the performance of the Recover-PasswordArchive.ps1 script when there are more than 100,000 files in the folder containing the password archives, disable 8.3 file name generation and strip all current 8.3 names on the volume containing that folder.  Search the Internet on “fsutil.exe 8dot3name” to see how.

To maximize fault tolerance and scalability, use Distributed File System (DFS) shared folders across two or more servers, and back up the folder at least weekly. With DFS and Group Policy management of the scheduled jobs, the solution can scale to large networks.

The solution works on stand-alone computers as well, but the scheduled task, shared folder, and permissions will need to handled appropriately; for example, a wrapper script will likely be needed to automate the creation of the scheduled task and the copying of the encrypted password file to some kind of archival server, perhaps via FTP or secure copy.

You can also perform an immediate password update with commands like these, but wrapped in a function or placed in another script:

Copy-Item -Path .\PublicKeyCert.cer -Destination \\laptop47\c$
 Invoke-Command -ComputerName laptop47 -filepath .\Update-PasswordArchive.ps1 -argumentlist "C:\publickeycert.cer","Administrator","c:\"
 Copy-Item -Path \\laptop47\c$\laptop47+Administrator+* -Destination C:\LocalFolder
 Remove-Item -Path \\laptop47\c$\PublicKeyCert.cer
 Remove-Item -Path \\laptop47\c$\laptop47+Administrator+*

The above Invoke-Command can be done by specifying UNC paths instead, but this requires delegation of credentials to the remote computer, which is not ideal for limiting token abuse attacks, so the certificate and archive files should be copied back-and-forth manually.  Besides, wrapped in a function or script with some error-handling code, all these steps would be hidden from us anyway.

Do not use the sample certificate and private key provided with these scripts. You must obtain your own key pair and never share your private keys with outsiders.

Each password archive file name includes a ticks timestamp number.  To manually convert the ticks timestamp in the file name (e.g., 635093865618276588) to a human-readable date and time in PowerShell, run this command:

[DateTime][Int64] 635093865618276588

If all the password archive files are moved to another volume, it would be convenient to reset the NTFS LastWriteTime property of the archive files to match the ticks timestamp in the archive file names themselves, such as with this command:

dir *+*+* | foreach { $_.LastWriteTime = [DateTime][Int64] $(($_.Name -split '\+')[2]) }

Update History

24.Sep.2013: Thanks to Timothy Carroll for uncovering a formatting bug in the password generator found in Update-PasswordArchive.ps1.  The fix does not affect compatibility with earlier versions of the other scripts or with previously-created encrypted password files.

25.Sep.2013: Added support for the minimum and maximum length of the random password generated.

13.Nov.2013: This is a breaking change from the prior 2.x versions.  This update adds much improved support for keyboards and code pages outside of US-EN for international users, each encrypted archive file now includes an SHA256 hash for integrity checking, and a StatusMessage property has been added to the output for troubleshooting and easier international conversions.

16.Nov.2013: Removed a dependency on .NET Framework 3.5 which, unfortunately, also changed the file format again, hence, at version 4.0.

 

Caveats & Legal Disclaimers

The scripts are free and in the public domain, you may use it for any purpose whatsoever without restriction. However, that being said…

THESE SCRIPTS ARE PROVIDED “AS IS” WITH NO WARRANTIES OR GUARANTEES OF ANY KIND, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. ALL RISKS OF DAMAGE REMAINS WITH THE USER, EVEN IF THE AUTHOR, SUPPLIER OR DISTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF ANY SUCH DAMAGE. IF YOUR STATE DOES NOT PERMIT THE COMPLETE LIMITATION OF LIABILITY, THEN DO NOT DOWNLOAD OR USE THE SCRIPTS. NO TECHNICAL SUPPORT WILL BE PROVIDED.

PowerShell Scripts to Audit and Remove Trusted Root CA Certificates

0
Filed under PKI, PowerShell

Hackers and malware can inject fake trusted root Certification Authority (CA) certificates into victim computers. This can trick victim computers and users into trusting bad code signatures, bad SSL web sites, bad e-mail signatures, and anything else which depends on certificates or PKI.

Partial Solution

The following describes two free PowerShell scripts: one for auditing the trusted root CAs on a computer and another for removing unwanted CA certificates.  The ability to add root CA certificates is already built into Group Policy.

We must begin somewhere with a list of root CA certificates to trust, and then this list can be edited.  One possibility is to begin with Microsoft’s list.  The following URL is where Microsoft periodically publishes the hashes of their own root CA certificates and the certificates of third-party companies that  participate in Microsoft’s Root Certification Program:

http://social.technet.microsoft.com/wiki/contents/articles/3281.introduction-to-the-microsoft-root-certificate-program.aspx

Unfortunately, you’ll have to extract the hashes from the HTML yourself, e.g., save as a text file, pull out the hashes, and remove the space characters. The SEC505 zip file contains a text file of these hashes in the \Day3-PKI\AuditRootCAs\ folder, but please note that the list will eventually be out of date. Why Microsoft doesn’t just post an XLS, XML or CSV file with the complete list is a mystery (if enough of us ask, maybe someone at Microsoft could do a Save As…).

Once you have Microsoft’s latest list of trustworthy root CA hashes, add to this list the SHA1 hashes of any other root CAs you choose to trust, such as your own CA, third-party companies, the US Department of Defense, etc.  The list is just a simple text file of SHA1 hashes. Feel free to remove the hashes of any CAs you do not want to trust.

Keep this text file in a protected shared folder on the network which grants Authenticated Users read-only access.  Take care to prevent hackers from modifying the file.  Periodically update the file with any new hashes, remove hashes for root CA certificates which have been compromised, and confirm that the file has not been maliciously altered. Use NTFS auditing to track attempted changes and consider alerting on attempted changes as well with a HIDS.

Audit-TrustedRootCA.ps1

In the Securing Windows and Resisting APT Malware (SEC505) course at SANS we have an entire day on PKI.  In the course we use a PowerShell script (Audit-TrustedRootCA.ps1) to compare the list of CA hashes in the above reference file against the list of currently-trusted root CA certificates for the user and computer running the script.  The Audit-TrustedRootCA.ps1 script is in the SEC505 zip file in the \Day3-PKI\AuditRootCAs\ folder.  All the other scripts in the zip file are also in the public domain.

The output of the script is a CSV text file, which can be saved to a shared folder, whose file name indicates the name of the computer, the name of the user, and a timestamp, e.g., LAPTOP47.Administrator.634890196060064770.csv. The CSV file contains the hashes and names of any root CA certificates trusted by the user and/or computer which are NOT in the list of reference certificates. The script also writes to the Application event log (Event ID = 9017, Source = RootCertificateAudit).

The script can be distributed through Group Policy or executed through PowerShell remoting.  Don’t forget to change the default execution policy for  PowerShell too. The user account under which the script runs will also need read access to the file of reference hashes and also write access to the folder where the output CSV file will be created. The -OutputPath parameter should take a UNC network path to a shared folder to consolidate the readings from many machines. A Distributed File System (DFS) share can be used for scalability.

The script is more-or-less a skeleton script to help you get started. It’s pretty simple when you examine the code. Feel free to add error handling, logging, security, etc.  If you do not wish to begin with a list of SHA1 hashes from Microsoft, feel free to construct this list yourself; the script only requires a file with a list of hashes, the list does not have to come from Microsoft.

Once you’ve gathered the CSV output files from your desired computers, review any files whose size indicates the presence of root CA certificates which are not on your reference list, i.e., those files will be larger than the rest.

Remove-TrustedRootCA.ps1

If you discover unwanted root CA certificates, they can be deleted with the Remove-TrustedRootCA.ps1 script, which is also in the SEC505 zip file  (\Day3-PKI folder).  Edit one variable near the top of the script ($BadCerts) which will contain the SHA1 hashes of the certificates to delete.  Run the script with administrative or system privileges, perhaps as a Group Policy startup script or through PowerShell remoting.  When it deletes an unwanted certificate, it writes to the local  Application event log (Event ID = 9019).

Threats & Recommendations

Attackers may try to delete or corrupt the existing CSV files to prevent access. It’s best to store the files in a shared folder whose NTFS permissions only allow the following permissions:

Principal: Authenticated Users
Apply to: This folder, subfolders and files
Allow: Full Control
Deny: Delete subfolders and files
Deny: Delete
Deny: Change permissions
Deny: Take ownership
Deny: Create folders/append data

Principal: Authenticated Users
Apply to: Files only
Deny: Create files/write data

The trusted administrator(s) can be granted Full Control to the archive files, certificates, and scripts as needed of course.

As discussed above, also take care to protect and audit the reference list of trustworthy root CA certificate hashes.

Caveats & Legal Disclaimers

The script is free and in the public domain, you may use it for any purpose whatsoever without restriction. However, that being said…

THIS SCRIPT IS PROVIDED “AS IS” WITH NO WARRANTIES OR GUARANTEES OF ANY KIND, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. ALL RISKS OF DAMAGE REMAINS WITH THE USER, EVEN IF THE AUTHOR, SUPPLIER OR DISTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF ANY SUCH DAMAGE. IF YOUR STATE DOES NOT PERMIT THE COMPLETE LIMITATION OF LIABILITY, THEN DO NOT DOWNLOAD OR USE THE SCRIPT. NO TECHNICAL SUPPORT WILL BE PROVIDED.

 

PowerShell Script to Manage Java Browser Plug-In and Java Security Level

0
Filed under Anti-Malware, PowerShell

Oracle’s Java SE includes a browser plug-in which is often a target for hacker exploits.  Java 7 update 10 and later supports security options to 1) allow or disallow the plug-in for Java to run applets in the web browser and 2) security levels for the plug-in if browser applets are permitted to run at all.

The Configure-JavaBrowserPlugIn.ps1 PowerShell script can be used to manage these settings on local or remote computers using Group Policy startup scripts or PowerShell remoting.  This is one of the scripts used in the Securing Windows and Resisting APT Malware (SEC505) course at SANS.  It is in the SEC505 zip file in the \Day1-Hardening\Java\ folder of that zip file.  All the other PowerShell scripts in that zip file are in the public domain too.

This script will create or overwrite the system-wide Java configuration files named ‘deployment.config‘ and ‘deployment.properties‘ in C\:Windows\Sun\Java\Deployment in order to enable or disable Java browser plug-in support for all users.

The script defaults to disabling the Java browser plug-in and to set the Java browser security level to “HIGH”, but note that this does not disable standalone Java applications, it only affects the browser.  Java plug-in security options are set using various command-line parameters to the script.

To see all of the script’s options, open PowerShell and run:

get-help -full .\Configure-JavaBrowserPlugIn.ps1

Requirements

Computer must have PowerShell 2.0 or later installed with an execution policy which allows scripts to run.

Supported browsers include at least Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox. Changes take effect after closing and reopening the browser.

Script must be run with local Administrators or System privileges, such as with a Group Policy assigned startup script or through PowerShell remoting. The changes made will affect all users who log on locally at the computer.

Note that the script does run Java’s ssvagent.exe tool, just like when using the Java Control Panel, but Oracle could change this binary or its command-line switches at any time, hence, the script can be brittle to new updates.  Test the script first.

Caveats & Legal Disclaimers

The script is free and in the public domain, you may use it for any purpose whatsoever without restriction. However, that being said…

THIS SCRIPT IS PROVIDED “AS IS” WITH NO WARRANTIES OR GUARANTEES OF ANY KIND, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. ALL RISKS OF DAMAGE REMAINS WITH THE USER, EVEN IF THE AUTHOR, SUPPLIER OR DISTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF ANY SUCH DAMAGE. IF YOUR STATE DOES NOT PERMIT THE COMPLETE LIMITATION OF LIABILITY, THEN DO NOT DOWNLOAD OR USE THE SCRIPT. NO TECHNICAL SUPPORT WILL BE PROVIDED.

Script to Configure PowerShell Remoting to Use SSL

0
Filed under PowerShell

PowerShell remoting can use SSL encryption when the -UseSSL switch is used with the Enter-PSSession or Invoke-Command cmdlets.  But simply installing an SSL-compatible certificate is not enough to enable remoting with SSL.  The WS-Management (WSMAN) listener for PowerShell must be configured correctly to use an SSL certificate, and this isn’t very much fun to do by hand.

In the Securing Windows and Resisting APT Malware (SEC505) course at SANS, we use a PowerShell script to configure the WSMAN listener with a certificate automatically, or, if there are multiple available computer certificates, to list the available certificates and simply ask the user which one to use.  The script is named Configure-RemotingForSSL.ps1.  It is located in the SEC505 zip file in the \Day6-PowerShell\Remoting\ folder.  All the other scripts in the zip file are in the public domain too.

Command-Line Use

There are no command-line parameters for the script, just run it to have a certificate selected automatically or to be prompted which certificate to use.  If you already have an SSL certificate configured for remoting, the script will prompt whether to replace those settings (not the certificate, just the settings) or to exit without changes.  The script is deliberately simple so that it is appropriate for teaching and easy to edit.  Feel free to customize for your environment.

Requirements

Note that the script will not install PowerShell, enable remoting, or install a certificate from your PKI.  There are plenty of guides for these tasks on the Internet, and the SEC505 course has a day on PKI too.  Remoting requires PowerShell 2.0 or later, and the user must be a member of the Administrators local group to manage WSMAN settings.  The about_Remote_Requirements file also has more information about these prerequisites (in PowerShell, run “get-help about_Remote_Requirements”).  Cheers

Caveats & Legal Disclaimers

The script is free and in the public domain, you may use it for any purpose whatsoever without restriction. However, that being said…

THIS SCRIPT IS PROVIDED “AS IS” WITH NO WARRANTIES OR GUARANTEES OF ANY KIND, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. ALL RISKS OF DAMAGE REMAINS WITH THE USER, EVEN IF THE AUTHOR, SUPPLIER OR DISTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF ANY SUCH DAMAGE. IF YOUR STATE DOES NOT PERMIT THE COMPLETE LIMITATION OF LIABILITY, THEN DO NOT DOWNLOAD OR USE THE SCRIPT. NO TECHNICAL SUPPORT WILL BE PROVIDED.

 

 

Webcast: What’s New in Server 2012 and Windows 8?

0
Filed under Course SEC505

Free SANS webcast: What’s New in Server 2012 and Windows 8?   Hear the recording of the webcast  here  and download the slide deck here.

The webcast is not a sales presentation for Microsoft, it’s an objective overview of what’s good, bad and bizarre in Windows 8 and Server 2012.

The Securing Windows and Resisting Malware course at SANS (SEC505) is fully updated for Server 2012 and Windows 8.  The webcast is by the SEC505 course author and instructor, Jason Fossen, a SANS Institute Fellow (not a Microsoft employee).

 

Windows Exploratory Surgery with Process Hacker

0
Filed under Anti-Malware, Course SEC505

A popular evening talk I’ve given at a number of SANS conferences is entitled Windows Exploratory Surgery with Process Hacker.  I’ve obtained permission to redistribute it in electronic form, so you can now get the PDF here if you wish.

Process Hacker is a free, open source, graphical process investigation and management tool for Windows.  It is similar to Sysinternals Process Explorer, but a bit more fun (both tools are simply great).  Process Hacker is useful for analyzing malware, troubleshooting, and understanding how Windows works at a deeper level.

The Exploratory Surgery talk is an introduction to Process Hacker, an overview of some Windows internals as background information for many SANS courses, and some examples how one might analyze malware with the tool.  The talk was also a trial balloon (a successful one) to guage how much interest there would be for me to write a Windows Internals for Security Professionals course for SANS where you’d get the manuals plus a copy of the latest version of the Windows Internals book by Russinovich, Solomon and Ionescu.  If you’d like a course like this, feel free to contact SANS with your request (or for any new course you’d like).

As always, if you find a technical error in the PDF, please let me know!

Cheers,
Jason Fossen
Securing Windows (SEC505) at SANS

 

Windows Firewall Script To Block IP Addresses And Country Network Ranges

5
Filed under Blue Team, PowerShell

The host-based Windows Firewall is easily managed through scripts and the NETSH.EXE command-line tool.  This article is about a simple PowerShell script which can create rules to block inbound and outbound access to thousands of IP addresses and network ID ranges, such as for attackers and unwanted countries.

To get the script, download the SEC505 zip file here or from the Downloads page, open the zip and look in the “\Day4-IPSec\Firewall” folder for the script named Import-Firewall-Blocklist.ps1 (and the sample BlockList.txt file too).  Like all the other scripts in the zip file, this script is free and in the public domain.

The script can also create firewall rules which apply only to certain interface profile types (public, private, domain, any) and/or only to certain interface media types (wireless, ras, lan, any); for example, you might wish to only block packets going through an 802.11 NIC (wireless) but only while not at home or at the office (public).  The script is just a convenient wrapper around the built-in NETSH.EXE tool.

Requirements

The script requires PowerShell 1.0 or later.

You must be a member of the local Administrators group.

The script runs on Windows Server 2008, Windows Vista, and later operating systems.

A text file containing addresses to block must be passed into the script as an argument.  This file must have one entry per line, each line containing either a single IP address, a network ID using CIDR notation, or an IP address range in the form of StartIPEndIP, for example, “10.4.0.0-10.4.255.254”.  Both IPv4 and IPv6 are supported.  Blank lines and comment lines are ignored; a comment line is any line that does not begin with a number or hex letter.  Even if the input file was originally created for Apache or iptables, it can still be used as long as the formatting is compatible (or made compatible with a bit of scripting).

Note: If you want similar scripts for Windows XP and Server 2003, that same zip file above also contains VBS and BAT scripts that all begin with the word “Firewall_*”.  Look in the \VBScript directory.

Block Countries, Attackers, Spammers and Bogons

You can obtain lists of IP addresses and network ID ranges to block from a variety of sources for a variety of purposes.

Here are a few sources to try:

Note: If you also want to block the resolution of unwanted hostnames in DNS, there is another script for that here.

Examples

To create rules to block all inbound and outbound packets to the IP addresses and CIDR networks listed in a file named iptoblock.txt:

import-firewall-blocklist.ps1 -inputfile iptoblock.txt

To block addresses only on public network interfaces:

import-firewall-blocklist.ps1 -inputfile iptoblock.txt -profiletype public

To block addresses only on wireless network adapter cards:

import-firewall-blocklist.ps1 -inputfile iptoblock.txt -interfacetype wireless

To delete the firewall rules created by the script whose names start with “iptoblock*”:

import-firewall-blocklist.ps1 -rulename iptoblock -deleteonly

The script defaults to looking for an input file named “blocklist.txt”, so you can also simply create that file in the same directory as the script and then run the script with no arguments:

import-firewall-blocklist.ps1

Note: By default the script will create rules which are named after the input file; for example, with an input file named “Attackers.txt”, the script will create rules named like “Attackers-#001”.  If you wish to override the default rule name, use the -RuleName parameter with the script when both creating and deleting the rules.

Caveats & Legal Disclaimers

For NETSH.EXE compatibility reasons, each firewall rule will contain only 200 IP addresses or network ID ranges; hence, when importing 5000 IP addresses or network ranges to block from a file named “Attackers.txt”, the script will create 25 inbound rules and 25 outbound rules, each rule named “Attackers-#001” through “Attackers-#025”.  Don’t worry, the script creates or deletes all of them at once, but do take care to use a unique input file name or a unique -RuleName argument.

Blocking large numbers of IP addresses or network ID ranges (10,000 for example) appears to have relatively little performance impact, but it does take longer to launch or refresh the Windows Firewall MMC snap-in, and it does take longer to disable/enable network interfaces.  This testing was done informally, however, so no hard numbers are available.  Please do some testing yourself when importing large input files.

The script is free and in the public domain, you may use it for any purpose whatsoever without restriction. However, that being said…

THIS SCRIPT IS PROVIDED “AS IS” WITH NO WARRANTIES OR GUARANTEES OF ANY KIND, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. ALL RISKS OF DAMAGE REMAINS WITH THE USER, EVEN IF THE AUTHOR, SUPPLIER OR DISTRIBUTOR HAS BEEN ADVISED OF THE POSSIBILITY OF ANY SUCH DAMAGE. IF YOUR STATE DOES NOT PERMIT THE COMPLETE LIMITATION OF LIABILITY, THEN DO NOT DOWNLOAD OR USE THE SCRIPT. NO TECHNICAL SUPPORT WILL BE PROVIDED.

Please test the script on non-production servers first, then test on a production server only during off-peak hours and only after having made a full backup.

The SANS Institute hopes you will find the script useful, so best wishes and good luck!