Hackers know how to use PowerShell for evil. Do you know how to use it for good? In SEC505 you will learn how to use PowerShell to automate Windows security management across an Active Directory enterprise. Don't just learn PowerShell syntax, learn how to leverage PowerShell as a platform for security.
You've run a vulnerability scanner and applied patches - now what? A major theme of this course is defensible architecture: we have to assume that there will be a breach, so we need to build in damage control from the beginning. Whack-a-mole incident response cannot be our only defensive strategy - we'll never win, and we'll never get ahead of the game. By the time your monitoring system tells you a Domain Admin account has been compromised, IT'S TOO LATE.
For the assume breach mindset, we must carefully delegate limited administrative powers so that the compromise of one administrator account is not a total catastrophe. Managing administrative privileges and credentials is a tough problem, so this course devotes an entire day to just this one critical task. Perhaps you've taken a hacking course at SANS and you now want to learn Windows mitigations: SEC505 is that course. SEC505 is the defense-only mirror image of SEC504 with regard to Windows and Active Directory.
Learning PowerShell is also useful for another kind of security: job security. Employers are looking for people with these skills. You don't have to know any PowerShell to attend the course, we will learn it together. About half the labs during the week are PowerShell, while the rest use graphical security tools. Many of the PowerShell scripts written by the course author are free in GitHub (just go to http://SEC505.com).
This course is not a vendor show to convince you to buy another security appliance or to install yet another endpoint agent. The idea is to use built-in or free Windows and Active Directory security tools when we can (especially PowerShell and Group Policy) and then purchase commercial products only when absolutely necessary.
If you are an IT manager or CIO, the aim for this course is to have it pay for itself 10 times over within two years, because automation isn't just good for security, it can save money too.
This course is designed for systems engineers, security architects, and the Security Operations (SecOps) team. The focus of the course is on how to automate the NSA Top 10 Mitigations, the CIS Critical Security Controls related to Windows, and the MITRE ATT&CKmitigations for Windows, especially the ones that are the difficult to implement in large environments.
SEC505 will also prepare you for the GIAC Certified Windows Security Administrator (GCWN) certification exam to prove your Windows security expertise. The GCWN certification counts towards a Master's Degree in Information Security from the SANS Technology Institute (www.sans.edu) and satisfies the Department of Defense 8140 computing environment requirement. The GCWN is also a foundational certification for soldiers in the U.S. Army's 255-S Information Protection Program. For DoD students, we will see how to apply the NSA/DISA Secure Host Baseline.
This is a fun course and a real eye-opener, even for Windows administrators with years of experience. We don't cover patch management, share permissions, or other such basics - the aim is to go far beyond that. Come have fun learning PowerShell and Windows security at the same time!
SEC505.1: Learn PowerShell Scripting
This course section covers what you need to know to get started using PowerShell. You don't need to have any prior scripting or programming experience. We have PowerShell labs throughout the week, so today is not the only PowerShell material. We start with the essentials, then go more in depth as the week progresses. Don't worry, you won't be left behind, the PowerShell labs walk you through every step.
About half the labs this week are PowerShell, the rest use graphical security tools. A six-day course on nothing but PowerShell would be too exhausting, so we mix Windows security and PowerShell together to make it more fun and practical. SEC505 has had at least one day of PowerShell since 2007, so we know how to get the right mix (for the more advanced scripters, we also talk about things like WMI and JEA later in the week). Many of the PowerShell scripts written by the course author are available in GitHub (just browse to http://SEC505.com).
PowerShell is made for SecOps/DevOps automation. PowerShell is built into Windows 7, Server 2008, and later operating systems by default. Linux and macOS users can download PowerShell from GitHub. We need cross-platform automation in order to scale out security changes and monitoring beyond a handful of hosts. For example, when a vulnerability must be remediated but there is no patch for it yet, automation is needed to quickly and consistently enact the changes necessary.
PowerShell "remoting" is encrypted remote command execution of PowerShell scripts in a way that can scale to thousands of endpoints and servers. It is vastly better than PSEXEC. Imagine being able to hunt for indicators of compromise across thousands of machines with just a few lines of PowerShell code. Or imagine having the local Administrator account password reset every night on thousands of endpoints in a secure way, and being able to retrieve that password securely too. We will show how to do these tasks and more.
We will also talk about security for PowerShell itself on Day 6 of the course, including transcription logging for forensics, strong encryption, code signing, application whitelisting of scripts, IPsec port control, and Just Enough Admin (JEA). JEA is like Linux sudoand setuid, but for PowerShell remoting.
As more and more of our systems are moved up to the cloud, PowerShell will become even more important. Amazon Web Services, Microsoft Azure, Office 365, Hyper-V, and VMware already support PowerShell administration for many tasks, and open-source PowerShell is available for Linux and macOS too. So learning PowerShell is not only good for network security, it's also good for jobsecurity.
CPE/CMU Credits: 6
PowerShell Overview and Tips
What Can We Do With PowerShell?
Write Your Own Scripts
SEC505.2: Host Hardening and Active Directory Scripting
Running a vulnerability scanner is easy, but remediating vulnerabilities in a large enterprise is hard. Most vulnerabilities are fixed by applying patches, but this course does not talk about patch management, since you're doing that already. What about the other vulnerabilities, the ones not fixed by applying patches? These vulnerabilities are, by definition, remediated by configuration changes. That's the hard part. We need a secure architecture designed for SecOps/DevOps.
So here is the challenge: How do we automate configuration changes across many endpoints and servers? How do we continuously reinforce these configuration changes to make sure that they "stick" and that the desired configuration is automatically reapplied again if the host somehow drifts away from what we want? And we want to do this all for free, using only built-in Windows and Active Directory tools. Is this possible? Yes, we can do it with PowerShell and Group Policy!
Group Policy and PowerShell are made for each other. We can use Group Policy to push out PowerShell scripts to hundreds of thousands of hosts and have the scripts executed hands-free, even if no one is logged on, then return data back to us through Server Message Block (SMB) shares, syslog packets, SIEM logging, or some other mechanism.
Are you moving to Server Core or Server Nano? PowerShell is the primary tool for configuring and hardening these systems, especially when hosted in Azure or AWS. Today we will see how to use PowerShell to install roles, manage services, apply Group Policy Objects to stand-alone servers (yes, that is possible), and other security tasks.
Group Policy can also be used to manage scheduled jobs, and these jobs can run PowerShell scripts related to forensics, monitoring, continuous configuration enforcement, or kill chain commands. For example, we can hunt for indicators of compromise, gather inventory data, reset passwords, create/delete/disable/enable user accounts, kill malicious processes, remove malicious services or drivers, remotely hash files for Tripwire-like integrity checking, search remote event logs, write to event logs or ELK, and much more. This is how we can help the Hunt Team and incident responders to fight back!
You might be familiar with Group Policy already, but today's course emphasizes the PowerShell targeting capabilities of Group Policy. How can we precisely target a security template or PowerShell script to just the machines in a particular global group, or just to the Server Core VMs, or just to the Windows 7 laptops that have Adobe Acrobat installed, or just to the Windows 10 tablets that have a particular indicator of compromise? Group Policy gives us a scalable targeting system for PowerShell and security templates.
CPE/CMU Credits: 6
Continuous Secure Configuration Enforcement
Group Policy Precision Targeting
Automating Server Hardening
PowerShell for Active Directory
SEC505.3: Smart Tokens and Public Key Infrastructure (PKI)
Don't believe what you hear on the street: Public Key Infrastructure (PKI) is not that hard to manage on Windows! You'll be pleasantly surprised at how much Group Policy, Active Directory, and PowerShell can help you manage your PKI. And we don't really have a choice anymore: running a PKI is pretty much mandatory for Microsoft security and cloud computing.
This day of the course is basically one long hands-on lab to install and configure a full Windows Server PKI. This includes a root Certification Authority (CA), Group Policy certificate auto-enrollment on endpoints, Online Certificate Status Protocol (OCSP) revocation checking, private key roaming for users, smart card certificate deployment, and, of course, more PowerShell examples.
Even if you already have a PKI, this course will still be useful for you since the hardest part of PKI is the endpoint management, not the CA installation.
Digital certificates have an essential role in Windows security. Certificates are used with smart cards, S/MIME e-mail, SSL/TLS to web servers, VPNs, PowerShell remoting, BitLocker drive encryption, the Encrypting File System (EFS), IPsec computer authentication, code signing, AppLocker process whitelisting, Windows Defender policies, user authentication to web services, and more. As we move towards the cloud and Bring Your Own Device (BYOD) mobile devices with FIDO authentication, having your own PKI will become even more important.
Everything you need to roll out a smart card solution for your administrators is included with Windows, except for the cards and readers themselves (and generic cards or YubiKeys are available in bulk for cheap). If you have a Trusted Platform Module (TPM) chip in your laptop or tablet, the TPM can also be used as a built-in smart card. TPM-based smart cards are invisible to users, requiring little or no training. Smart cards can hold other certificates too, such as for Remote Desktop Services, BitLocker, EFS, and code signing.
Because malware can inject fake root CA certificates into our machines, we will also look at PowerShell scripts to audit and manage trusted root CA certificates on endpoints. When hackers alter the trusted root CAs on our endpoints, it subverts the authentication provided by SSL/TLS and allows the attackers to create digitally-signed malware that our users will blindly trust.
The labs in today's course mostly use graphical PKI tools, but there are also PowerShell labs to delete unwanted certificates installed by malware, audit our lists of trusted CAs, perform file hashing, compare thousands of recorded file hashes at two different times (similar to Tripwire), and encrypt secret data in our own PowerShell applications, such as for encrypting admin passwords.
CPE/CMU Credits: 6
Why Is a PKI Necessary?
How to Install the Windows PKI
How to Manage Your PKI
Deploying Smart Cards, TPMs and USB Tokens
SEC505.4: Protecting Admin Credentials and PowerShell JEA
Why do submarines have pressure doors to seal off compartments? Because they are designed to assume a breach will occur. In a Windows environment, a security breach will occur, so we must design the architecture with an "assume breach" mindset as well.
If we assume that someday the computers and credentials of our administrators will be compromised, then how do we build damage control into the network from the beginning? This is not about detection and incident response. The challenge here is how to design for damage control when we delegate administrative privileges. We need to proactively design damage control into the architecture, not wait until after there is a breach (when it's too late).
Is there a Windows version of sudo, like on Linux? Yes, it's called Just Enough Admin (JEA) for PowerShell. JEA allows non-admin users to remotely execute commands with administrative privileges, but without exposing any administrative credentials to them (kind of like setuid root on Linux). With JEA, all PowerShell commands are blocked by default except those you explicitly allow, and you can even use regular expression patterns to limit the arguments to those commands. And for less-technical users who'd prefer a graphical interface, don't forget that graphical applications can be built on top of PowerShell JEA too. In this course, we will see how to set up JEA and PowerShell Remoting.
The password of the local Administrator account on every machine must be different and reset at least weekly to limit post-exploitation abuse. We will see how to use scheduled PowerShell scripts to do this in a secure way that's also convenient for the admins when they need the plaintext password (better than LAPS). To help defend against pass-the-hash attacks and token abuse, we talk about LSASS memory protections, Windows 10 Credential Guard, Server 2016 Remote Credential Guard, restricting network logon rights, User Account Control (UAC), RDP Restricted Admin Mode, and more.
Moving up to Active Directory (AD), we will see that every object in AD has a set of permissions and audit settings that we can leverage for delegation of authority. Instead of simply adding everyone in the IT department to the Domain Admins group, we can more precisely delegate authority at the Organizational Unit (OU) level. We can create an OU Admins group that is just like Domain Admins, except that its power is limited to that one OU only. Then we can create other custom groups, such as the Help Desk group or the Auditors group, and grant them the minimum powers they need for the OU too. By analogy, AD forests and OUs can be used like those pressure doors on submarines mentioned earlier for a more secure architecture.
CPE/CMU Credits: 6
Secure Architecture: Admin Privileges
Compromise of Administrative Powers
PowerShell Just Enough Admin (JEA)
Active Directory Permissions and Delegation
SEC505.5: Thwarting Hackers Inside The Network
You are already applying patches and updating anti-virus signatures. But endpoint protection is much more than that. Because most advanced malware infections start with a compromised endpoint, we want to proactively build defensibility and damage control into our systems using a "zero trust" or "assume breach" model. How?
AppLocker is an application whitelisting tool built into Windows to control which executables, scripts, DLLs and installer packages users may run. If hackers or malware attempt to launch an unauthorized process post-exploitation, the aim is to block it and log it. In the lab, we'll use PowerShell and Group Policy to manage AppLocker. Application whitelisting can be hard to manage if used too aggressively, so we'll also talk about how to get started without making the help desk phone ring off the hook.
When we adopt the assume breach mindset, we assume hackers are attacking us and sniffing packets from inside the Local Area Network (LAN). This is how they can move laterally from host to host. When we focus too much on perimeter defenses, these internal malicious actions go unchecked. We need defense-in-depth at the endpoint level. And for more data-centric security, we need to secure sensitive data not just on disk, but also while in motion inside the LAN, not just in motion across the perimeter.
Host-based firewalls can block the lateral movement of hackers inside the LAN and the outbound connections of malware. On mobile devices, we must do host-based packet filtering because mobile devices roam outside the LAN where the perimeter firewall cannot protect them. The trick is being able to apply different sets of firewall rules to different sets of machines in a scalable, repeatable, and automated way. This is what we will do with the built-in Windows Firewall through Group Policy and PowerShell.
IPsec is not just for VPNs! In fact, we won't discuss VPNs at all today. The built-in Windows IPsec driver can authenticate users in Active Directory in order to implement share permissions for our TCP/UDP listening ports based on our users' global group memberships in Active Directory. Imagine configuring the Windows Firewall on your endpoints and servers to only permit access to their RPC, RDP or SMB ports if (1) the client has a local IP address, (2) the computer is pre-authenticated by IPsec to be a member of the domain, (3) the user is pre-authenticated to be a member of the Domain Admins group, and (4) the packets are all encrypted with 256-bit AES. Not only is this possible, today's course will show you exactly how to do it!
CPE/CMU Credits: 6
IPsec Port Permissions
Windows Defender Firewall
SEC505.6: Blue Team PowerShell: WMI, DNS, RDP and SMB
SEC505 is like the defense-only mirror image of some of the hacking courses at SANS. Maybe you've learned about hacking into Windows in SEC504. What about the defenses against these attacks then?
PowerShell is being widely abused by hackers and malware. Today we will cover PowerShell security. Windows PowerShell 5.0 and later includes vastly improved transcription logging, a new anti-virus scanning interface, and other enhanced security controls. PowerShell remoting can be controlled through Just Enough Admin (JEA), firewall rules and IPsec.
Kerberos Golden Ticket attacks allow hackers to impersonate domain controllers. If this catastrophe were to happen in your environment, how would you respond? We will talk about how to reset the krbtgt password and force immediate Active Directory replication.
Wireshark can sniff SMB traffic to file shares and carve files out of the packet payloads. Hackers can also inject malware into Group Policy Objects as the endpoints download their GPOs over SMB. SMB is plaintext by default, but we'll see how to configure SMB encryption with or without IPsec. It's also time to eliminate SMB 1.0 from our LANs.
Hackers love the Windows Management Instrumentation (WMI) service, and so should we. We are the linebackers on the Blue Team and the WMI service was made to benefit us, not hackers. The WMI service is enabled by default and accessible over the network. Through WMI we can do remote command execution (without PowerShell being installed at the target), forcibly log off the user, reboot the machine, stop services, search for processes running as Administrator, kill any process, and much more. The WMI service is nearly all-powerful and it's built for remote administration. PowerShell is tightly integrated into WMI, and we'll look at several PowerShell examples.
Hackers love DNS, but for the wrong reasons. There are several things we can do to make DNS more secure though. We can do DNS sinkholing of names used by malware, use DNSSEC, require Kerberos dynamic updates, disable zone transfers, implement a split architecture, and encrypt DNS traffic with IPsec. DNSSEC is vastly easier to configure now than in the past. DNS sinkholing is also very effective in disrupting malware control channels, and sinkholing can be done for free with a PowerShell script. DNS logging helps with threat detection too.
SSL should be eliminated, there are too many flaws in this old protocol. Instead, we should use the latest version of TLS available, and optimize our cipher suites for 256-bit AES with Perfect Forward Secrecy (PFS).
Finally, the most popular way to remotely manage Windows is to use the Remote Desktop Protocol (RDP) and a thin client like MSTSC.EXE. But RDP is vulnerable to man-in-the-middle attacks! And an RDP logon can leave admin credentials in memory for malware to steal. As more virtual machines are moved up to the networks of cloud providers, RDP use over the Internet will increase. But with PKI, IPsec encryption, and proper hardening, RDP can be made safe enough to use, even for administrators.
CPE/CMU Credits: 6
PowerShell and WMI
Dangerous Protocols We Can't Live Without
Who Should Attend
What You Will Receive
You Will Be Able To