Overview

Today's course covers what you need to know to get started using PowerShell. You do not 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. Do not worry, you will not be left behind, the PowerShell labs walk you through every step. If you already have PowerShell experience, then there will be intermediate topics for you too.

Most of the labs this week are PowerShell, while the rest of the labs use graphical security tools only when necessary, such as when there is no PowerShell equivalent.

PowerShell Core is different than Windows PowerShell. PowerShell Core is the new, cross-platform version of PowerShell for Windows, Linux, and macOS. The full source code of PowerShell Core is in GitHub. PowerShell Core has built-in integration with OpenSSH. We will use both Windows PowerShell and PowerShell Core in this course.

As more of our systems move 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. Learning PowerShell is good for managing network security, and it's also good for job security.

Your course USB drive will include over 200 PowerShell scripts written by the course author. All the PowerShell code shown in the manuals during the week will be on your USB drive. All the scripts are in the public domain for your personal or business use without restriction (they can be downloaded from https://BlueTeamPowerShell.com).

Topics

PowerShell IS Dangerous (and Fun)

• PowerShell is like simplified C#
• Piping .NET and COM objects, not text
• The backbone of Windows and Azure automation
• Graphical admin tools wrapped around PowerShell
• Built-in remote script execution

Writing Your Own Scripts, Functions, and Modules

• Passing arguments into your scripts
• Cmdlets, functions, and aliases in your profile script
• Flow control: if-then, do-while, foreach, switch
• The .NET Framework class library: a vast playground
• How to pipe data in/out of your scripts
• How to create your own module script

Up and Running Quickly with PowerShell

• Capturing the output of commands
• Parsing text files and logs with regex patterns
• Mounting the registry as a drive
• Importing third-party modules and functions
• https://www.PowerShellGallery.com

Piping Objects Instead of Text

• Classes, objects, properties, and methods
• An array of objects is like a table of SQL records
• Extracting just the properties you want
• Exporting objects to CSV, HTML, XML, and JSON files
• Filtering, sorting, and grouping objects (not text)

Overview

How can we run PowerShell scripts on thousands of systems with just a few lines of code? Today is about remote command execution using PowerShell Remoting, the SSH service on Windows, the Task Scheduler service, and boot up scripts assigned through Group Policy.

OpenSSH is not just for Linux. Windows now has built-in support for Secure Shell (SSH) as both a client and a server. PowerShell Core has native support for SSH too. You don't need PuTTY anymore.

PowerShell Remoting is encrypted remote command execution of PowerShell scripts in a way that can scale to thousands of workstations and servers. It is vastly better than PSEXEC.EXE. Remoting traffic can be encrypted with SSL/TLS, IPsec or SSH, and authenticated with a smart card or YubiKey.

But power is always a double-edged sword. PowerShell Remoting can be abused by ransomware and hackers too. Can we limit which groups may use PowerShell Remoting and restrict the commands each group is permitted to run? Yes, it is 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 for those commands you explicitly allow. Graphical applications can be built on top of PowerShell JEA too, such as Microsoft's Windows Admin Center (WAC) web application.

While PowerShell Remoting and SSH are great, they still do not scale enough. If you need to run dozens of PowerShell scripts on tens of thousands of hosts every night (or every hour), then you need the Task Scheduler service. The built-in Task Scheduler service can be remotely managed through PowerShell and Group Policy. Ransomware often uses the Task Scheduler too. We will see how to run scheduled PowerShell scripts with elevated privileges while protecting administrative credentials.

You might be familiar with Group Policy already, but today's course emphasizes the PowerShell capabilities of Group Policy. We can use Group Policy to push out PowerShell scripts to thousands of hosts and have the scripts executed hands-free, even if no one is logged on. These scripts can then return data back to us through shared folders, syslog packets, or SIEM logging.

Today's PowerShell remote command execution material is often shocking to administrators. The potential for both good and evil is enormous!

Topics

PowerShell Remoting

• Remote command shells with PowerShell
• Smart card and YubiKey authentication
• Using SSL/TLS, SSH or IPsec to encrypt traffic
• Remote command execution in scheduled tasks
• File upload and download using the PowerShell Remoting protocol
• Graphical apps can use PowerShell remoting too

OpenSSH on Windows

• Windows can be an SSH server? Yes!
• OpenSSH support is now built into Windows
• PowerShell Core integration with SSH
• Hardening SSH for Internet use
• Key-based SSH authentication and password managers

PowerShell Just Enough Admin (JEA)

• JEA is like setuid root on Linux
• Restricting PowerShell commands and arguments
• Verbose transcription logging of commands
• How to set up and configure JEA
• JEA for Privileged Access Workstations (PAWs)

PowerShell, Group Policy, and the Task Scheduler

• Deploying PowerShell startup and logon scripts
• Group Policy scheduled tasks to run PowerShell scripts
• The Task Scheduler service and admin credentials
• WMI item-level targeting of PowerShell scripts

Overview

PowerShell is deeply integrated into the Windows Management Instrumentation (WMI) service. Many PowerShell commands are just wrappers for WMI functions. Hackers love the WMI service too, but for the wrong reasons.

The WMI service is enabled by default and accessible over the network. With our PowerShell WMI scripts we can remotely execute commands, reboot machines, forcibly log users off, kill processes, and much more. Today, we will see how to do all this. WMI scripting is a bit difficult, but we'll go through all the strange namespaces and classes together.

Today we will also use PowerShell to search, manage, and secure Active Directory. With PowerShell we can find abandoned user accounts and disable them. We can enforce our desired group memberships with scheduled scripts. We can reset passwords on thousands of user accounts. And when hackers are brute-forcing passwords, our PowerShell scripts can find the accounts being targeted. Of course, malicious insiders can do much of the same, such as with the Bloodhound tool, so how can we restrict what users can see or change?

Every object in Active Directory has permissions and audit settings. 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. Whether using PowerShell or graphical tools, these Active Directory permissions are always enforced by the domain controller.

Don't use Microsoft LAPS! There are better ways to protect admin passwords. We can use PowerShell to manage domain accounts in Active Directory, but we can also use PowerShell to manage local admin accounts and passwords on servers and workstations in a way that is better than Microsoft LAPS. Today we will do a better-than-LAPS PowerShell lab, and you're welcome to use these scripts instead of LAPS on your networks after the conference.

Is PowerShell only for scripts and command shells? No! Windows Admin Center (WAC) is a free Microsoft web application for remote administration with your web browser. WAC uses both WMI and PowerShell Remoting under the hood. It's a great example of how Microsoft is wrapping PowerShell with graphical tools to manage machines both on-premises and in Azure. We will install WAC and see the PowerShell functions it exposes.

Topics

PowerShell for WMI

• What is WMI and why do hackers abuse it so much?
• Remote command execution through WMI
• Using PowerShell to query WMI namespaces and classes
• WMI service authentication and traffic encryption
• Gathering reconnaissance data from remote systems
• Microsoft Windows Admin Center (WAC) web application
• WMI logging for hacker and malware visibility

PowerShell for Active Directory

• Querying and managing Active Directory with PowerShell
• Enforcing desired Domain Admins group membership
• Disabling abandoned user accounts and resetting passwords
• Detecting password brute-force attacks
• Searching organizational units using filter criteria
• ADSI Edit and other helper tools for PowerShell
• Active Directory Administrative Center (ADAC)

Active Directory Permissions and Auditing

• Active Directory objects have permissions
• Active Directory objects have auditing
• Limit what PowerShell scripts can do in Active Directory
• Log what PowerShell scripts are doing in Active Directory
• Delegate authority at the OU level instead
• Designing Active Directory for the inevitable breach

Overview

Today we will use PowerShell and Group Policy to automate the hardening of many exploitable services and protocols, such as Kerberos, Domain Name System (DNS), Remote Desktop Protocol (RDP), and File and Printer Sharing (SMB). Think of Kerberos Golden Tickets, DNS response spoofing, the Bluekeep RDP attack, the EternalBlue/WannaCry SMB worm, and other attacks.

PowerShell is the primary tool for configuring and hardening Windows Server, Server Core, and Server Nano, 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 accomplish other security tasks. Along the way, we will learn new PowerShell techniques as well.

Host-based firewalls can block the lateral movement of hackers inside the LAN and the outbound connections of malware as that malware "beacons" or "phones home." 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 PowerShell and the built-in Windows Firewall.

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 using a PowerShell script to configure the Windows Firewall on your workstations and servers only to permit access to their RPC, RDP, or SMB ports if (1) the remote computer is pre-authenticated by IPsec to be a member of the domain, (2) the user is pre-authenticated to be a member of the Domain Admins group, (3) the packets are all encrypted with 256-bit AES, and (4) the client has an IP address from an authorized subnet. This is not only possible, today's course will show you exactly how to do it with PowerShell!

Topics

Server Hardening Automation for DevOps

• Replacing Server Manager with PowerShell
• Adding and removing roles and features
• Remotely gathering an inventory of roles and features
• Why use Server Nano or Server Core?
• Running PowerShell automatically after service failure
• Service account identities, passwords, and risks
• Tools to reset service account passwords securely

Windows Firewall Scripting

• PowerShell management of Windows Firewall rules
• Blocking malware outbound connections
• Role-based access control for listening ports
• Deep IPsec integration for user authentication
• Firewall logging to the event logs, not to text logs

Share Permissions for TCP/UDP Listening Ports with IPsec

• PowerShell management of IPsec rules
• IPsec for blocking post-exploitation lateral movement
• Limiting access to ports based on global group membership
• IPsec-based encrypted VLANs
• IPsec is not just for VPNs!

Exploitable Protocols and Services

• Kerberos Tickets
• Remote Desktop Protocol (RDP) attacks
• SMBv3 native encryption vs. Wireshark
• NTLM, NTLMv2, and Kerberos
• DNS sinkholes for malware and threat detection
• DNS DoS attacks and response rate limiting

Overview

Smart cards and smart tokens, such as YubiKeys, are the gold standard for multi-factor authentication (MFA). Today we will use PowerShell to install a certificate server that can be used to deploy smart cards and smart USB tokens. Smart cards and tokens can be used for PowerShell Remoting, signing PowerShell scripts, Remote Desktop Protocol (RDP) logons, User Account Control (UAC), ASP.NET web application logons, and more.

Everything you need to roll out a full smart card/token solution for your administrators is included with Windows, except for the cards and tokens themselves. PowerShell and Group Policy make it relatively easy.

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, similar to the security processors in Apple iPhones. TPMs also protect biometric data, encrypt BitLocker keys, and help to enhance Windows 10 Credential Guard.

PowerShell Remoting network traffic can be encrypted with SSL/TLS. The target server is authenticated with its certificate, just like a web server using HTTPS. The user can be authenticated with his or her certificate too, preferably stored on a smart card or token. Today we will configure PowerShell Remoting to use SSL/TLS and require a smart card or token from the user. These same certificates and smart cards can be used for RDP too.

Your organization will need certificates for many other purposes. In today's course we will sign PowerShell scripts, install an Online Certificate Status Protocol (OCSP) responder for revocation checking, configure auto-enrollment for hands-free certificate installation and renewals, use PowerShell to audit and manage trusted root Certificate Authentication on endpoints, and more.

Topics

Certificate Authentication and TLS Encryption for PowerShell

• Certificates for smart card authentication of PowerShell remoting
• Certificates for TLS encryption of PowerShell remoting
• Certificates to sign PowerShell scripts for AppLocker
• Certificates for TLS encryption of WMI queries with PowerShell
• Certificates to encrypt admin passwords (instead of LAPS)
• Certificates for web servers, domain controllers, and everything else

Install a Windows Certificate Server with PowerShell

• PowerShell installation script for Public Key Infrastructure (PKI)
• Managing digital certificates with PowerShell
• Custom certificate templates in Active Directory
• Controlling certificate auto-enrollment
• Setting up an Online Certificate Status Protocol (OCSP) responder web farm
• Configuring Certificate Revocation List publication

Deploying Smart Cards, Smart Tokens, and TPM Virtual Smart Cards

• The gold standard for multi-factor authentication is a smart card/token
• YubiKey smart tokens for logon, PowerShell remoting, and much more
• Trusted Platfor, Module (TPM) virtual smart cards
• Safely enroll tokens and cards on behalf of other users
• How to revoke compromised certificates
• PowerShell script to audit trusted root CAs
• PowerShell script to delete hacker certificates

Security Best Practices

• Protect the private keys of your certificates from malware
• How to use PKI smart cards and smart tokens
• How to encrypt private keys on the hard drive
• Hardware Security Module (HSM) for CAs
• How to digitally sign PowerShell scripts
• SSL is dead, long live TLS
• TLS cipher suite optimization

Overview

Today we will write a PowerShell ransomware script and unleash it inside our training VM (don't release it into the wild, you'll go to federal prison). The purpose of this ethical hacking is to discuss defenses against this kind of PowerShell abuse.

How can we secure PowerShell itself? PowerShell is not a single tool. There is no one registry value or patch to magically make PowerShell "secure," but there is a lot we can do. Today we will cover many defensive techniques to prevent future compromises, reduce the harm we suffer after a compromise, and gain visibility into PowerShell malicious activity for the sake of forensics, incident response, and threat hunting.

Because we want to automate our hardening work, we will also roll our defensive changes into a DevOps PowerShell script for building new servers or workstations, including all the networking settings. This pulls together all the PowerShell material from the prior days of the course. The aim is to be able to reconfigure a Windows machine with as little manual labor as possible. When in doubt about whether a computer has been infected with malware, we should be able to "nuke it from orbit" by rebuilding that machine from scratch.

Most importantly, we must prevent PowerShell malware from acquiring administrative credentials. Malware can scrape credentials out of memory for privilege escalation and lateral movement to other machines, such as with pass-the-hash and Kerberos Golden Ticket attacks. Once ransomware steals the credentials of a Domain Admin, it's GAME OVER.

To help defend against pass-the-hash attacks and token abuse, we will cover LSASS memory protections, Credential Guard, Remote Credential Guard, restricting network logon rights, User Account Control (UAC), RDP Restricted Admin Mode, and more. All these settings can be applied or audited with PowerShell scripts.

From a defender's perspective, PowerShell is great. In comparison to C++ hacker tools, we want our adversaries to use PowerShell. PowerShell transcription logging gives us deep visibility into the tactics of our adversaries. There is a special anti-virus scanning interface (AMSI) for examining PowerShell malware in memory, even when that malware is obfuscated. We can lock down PowerShell remoting using Just Enough Admin (JEA) sandboxes and enforce AppLocker rules to restrict PowerShell execution.

Topics

PowerShell Ransomware

• We will write a PowerShell ransomware script in a lab
• What can be done to combat ransomware?
• Just having backups is not enough

Anti-Exploitation Defenses for PowerShell

• AppLocker for PowerShell
• Scripting AppLocker with PowerShell
• PowerShell execution policy
• PowerShell constrained language mode
• Anti-Malware Scan Interface (AMSI)
• Restricting network access to block pivoting
• Hashing scripts for change detection
• How to digitally sign our PowerShell scripts
• The Principle of (Endpoint) Least Privilege
• Prevent Domain Admin credential theft at all costs!
• Windows 10 Credential Guard
• User Account Control (UAC) instead of RUNAS.EXE

PowerShell Visibility AND Detection

• PowerShell transcription logging
• WMI namespace auditing
• Windows Event Log audit policies
• Querying Windows Event Logs with PowerShell

Capstone: DevOps Automation with PowerShell

• Putting it all together with PowerShell
• How to write an all-in-one build script with OS hardening
• PowerShell for roles, features, networking, policies, etc.
• The future of IT administration is automation
• We will all need to be "full stack engineers" soon