Apr 24 2016

BSides Charm Presentation Posted: PowerShell Security: Defending the Enterprise from the Latest Attack Platform

This was my second year speaking at BSides Charm in Baltimore. Last year I spoke about Active Directory attack & defense and it was my first time speaking at a conference. 🙂

The presentation slides for my talk “PowerShell Security: Defending the Enterprise from the Latest Attack Platform” are now on the Presentations tab here on ADSecurity.org. The talk was recorded, so follow @BSidesCharm on Twitter for information about video publishing.

AD Security Presentations

Here’s my PowerShell talk description:

PowerShell is a boon to administrators, providing command consistency and the ability to quickly gather system data and set configuration settings. However, what can be used to help, can also be used for less altruistic activities. Attackers have quickly learned over the past few years that leveraging PowerShell provides simple bypass methods for most defenses and a platform for initial compromise, recon, exploitation, privilege escalation, data exfiltration, and persistence.

With the industry shift to an “”Assume Breach”” mentality, it’s important to understand the impact on the defensive paradigm. Simply put, don’t block PowerShell, embrace it. Blocking PowerShell.exe does not stop PowerShell execution and can provide a false sense of security. The key is monitoring PowerShell usage to enable detection of recon and attack activity. As attack tools like the recently released PowerShell Empire become more prevalent, it’s more important than ever to understand the full capabilities of PowerShell as an attack platform as well as how to effectively detect and mitigate standard PowerShell attack methods.

The presentation walks the audience through the evolution of PowerShell as an attack platform and shows why a new approach to PowerShell attack defense is required. Some Active Directory recon & attack techniques are shown as well as potential mitigation. This journey ends showing why PowerShell version 5 should be the new baseline version of PowerShell due to new defensive capability.

This talk is recommended for anyone tasked with defending an organization from attack as well as system administrators/engineers.


BSides Charm talk outline:

  • Brief PowerShell Overview
  • Typical PowerShell defenses (and why they fail)
  • PowerShell as an Attack Platform
  • Real-world PowerShell attacks
  • PowerShell Persistence
  • PowerShell without PowerShell.exe
  • PowerShell Remoting
  • PowerShell Logging & Attack Detection
  • PowerShell Defenses
  • PowerShell v5 Security Enhancements
  • Windows 10 PowerShell Security
  • Securing PowerShell: A Layered Defense
  • Appendix: Microsoft Office Macro Security

Some of this information is in the post titled “Detecting Offensive PowerShell Attack Tools “.

As a follow-up to one of the questions regarding the Invoke-NinjaCopy powershell tool that can copy a locked file from a server (such as NTDS.dit), I refer you to the author’s blog post on his tool.

There was also a question after the talk about managing computers without leaving credentials behind. PowerShell remoting is ideal since it uses a “Network” logon where no credentials are placed on the target system. This has been a problem with RDP since logging into a server via RDP involves entering a username and password. This action usually involves placing the user credentials on the remote system and when connected to a computer via RDP, the user credentials are placed on that system. RDP /RestrictedAdmin is a new feature (now available for Windows 7 / Windows 2008 R2 and newer) which prevents the credentials from being placed on the target RDP server, so they can’t be stolen. This is great for help desk support that needs to RDP to user workstations as a workstation admin. When using standard RDP, these credentials could be stolen. With RDP /RestrictedAdmin, the credentials aren’t on the box to take.

Thanks to the BSides Charm organizers for a great event!

Follow-up note:
Test PowerShell logging levels. Someone reported to me that checking the box “Log script block invocation start / stop events” can generate a large amount of PowerShell log events, so check before deploying.

 

Mar 25 2016

DarkOperator.com: Using PowerShell to Gather Information from Active Directory

Carlos Perez (@DarkOperator) recently posted on DarkOperator.com how to use PowerShell to get data from Active Directory. He is working on an Active Directory audit PowerShell project and is documenting most of the work put into it. He also covers leveraging functions for portability and using Pester to write better PowerShell code  (as well as debug and handle error conditions better). Carlos also walks through how to properly code a PowerShell module as well as create and use a PowerShell project in GitHub (something I need to do better! 🙂 ). Anyone who uses PowerShell to gather Active Directory data should read these posts. The amount of detail he put into these posts is impressive and they are well worth reading!

 

1 Writing a Active Directory Audit Module – Creating the Project

I got in my head this week that I would like to write a Windows PowerShell module for getting information from Active Directory for the purpose of gathering information to aid in detecting miss configurations and also aid in incident response. My idea is to write the module and start publishing blog posts as I go through the process of writing the code and how I go about it. This will be my first experience with Pester also so I think it would be a fun adventure.

Requirements

I start by setting goals for the module, these are:

  • All output from each function will be objects.
  • I will assign each object a custom type so I can create custom views for the output.
  • The module must not depend on the ActiveDirectory module that ships with the different RSAT tools and use .NET and COM so as to leverage the use alternate credentials.
  • Module should be able to pull information as a base for Users, Groups, Computers, Sites, Domains, Forest, OUs and GPOs.
  • Module will be PSv3 or above so as to use new improvements int he latest versions of Windows PowerShell.

2 Writing a Active Directory Audit Module – Getting Forest Info

Carlos covers several scenarios that may arise when attempting to gather Active Directory forest data using PowerShell, including connecting to the current forest as well as others.

In the last blog post we covered setting the goals for the project, general guidelines, how I set up a project in GitHub and the creation of the module manifest. In this blog post we will cover some of the API around Active Directory that we can use in Windows PowerShell to access and query it either from a host already in the domain or with alternate credentials against a specific host.

Currently when working in Windows PowerShell there are 4 main ways to interact with Active Directory:

  • Active Directory module – gets installed with RSAT or when then Domain Controller role is added to a server. Varies per version of Windows.
  • System.DirectoryServices Namespace – it is a .Net wrapper around the ADSI (Active Directory Service Interface) COM object. It represents a specific path or Object in AD allowing for the pulling of information and modification.
  • System.DirectoryServices.ActiveDirectory namespace – It provides several .Net classes that abstract AD services. Provides access to manipulating forest, domain, site, subnet, partition, and schema are part of the object model.
  • System.DirectoryServices.AccountManagement namespace provides uniform access and manipulation of user, computer, and group security principals

Each one of the namespaces have their own peculiarities and uses. The most powerful one is classes under System.DirectoryServices do to the control it provides but with it comes more complexity, this is why it is used for those cases where the other 2 do not fit a specific role or complex searches of AD are required.

 

3 Writing a Active Directory Audit Module – Getting a DirectoryEntry

Extending the information

In the previous blog post when we look at the object returned it has all of the information properly parsed and shown so I do not have to run around parsing fields and converting them but for me a critical piece of information is not shown and that is the SID of the forest domain. If you have played with analysis of some logs and with Mimikatz attacks you know the SID is of great importance. For this we will use the System.DirectoryServices namespace, specifically the DirectoryEntry class that represents a path in AD.

Designing Get-DSDirectoryEntry

We will create a helper function to generate the DirectoryEntry object, by creating the function we ensure we do not duplicate a lot of code unless we have to and will also make it easier to test.

Before we start coding lets define what we want to achieve and this is dictated in part by the APIs we want to use. in this case the Class has several constructors to create an instance of it:

We want to be able to get a DirectoryEntry int he following manners:

  • For a specified path using the current user credentials.
  • For a specified path using alternated credentials.
  • For a specified path by connecting to a server and providing credentials

 

 

Mar 14 2016

Sneaky Active Directory Persistence #17: Group Policy

The content in this post describes a method through which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for about 5 minutes.

Complete list of Sneaky Active Directory Persistence Tricks posts

This post explores how an attacker could leverage the built-in Active Directory management capability called Group Policy and how to mitigate potential security issues.

Continue reading

Mar 09 2016

Sneaky Active Directory Persistence #16: Computer Accounts & Domain Controller Silver Tickets

The content in this post describes a method by which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for about 5 minutes.

All posts in my Sneaky Active Directory Persistence Tricks series

This post explores how an attacker could leverage computer account credentials to persist in an enterprise and how to mitigate potential security issues.

Continue reading

Mar 02 2016

ADSecurity.org’s Unofficial Guide to Mimikatz & Command Reference Updated for Mimikatz v2.1 alpha 20160229

ADSecurity.org’s Unofficial Guide to Mimikatz & Command Reference page is updated for the new modules/features in Mimikatz v2.1 alpha 20160229.

According to Mimikatz author, Benjamin Delpy, the following updates are included in the most recent Mimikatz version(s):

Mimikatz Release Date: 2/29/2016
2.1 alpha 20160229 (oe.eo) edition
System Environment Variables & other stuff
[new] System Environment Variables user module
[new] System Environment Variables kernel IOCTL for Set
[enhancement] privilege::sysenv
[enhancement] Busylight
[enhancement] misc::skeleton can avoid anti-AES patching for aware clients with /letaes

2.1 alpha 20160217 (oe.eo) edition
[new] crypto::certificates /silent & /nokey flags
[new] crypto::keys /silent flag
[new] kull_m_busylight module now support protocol for new devices

Visit the Unofficial Guide to Mimikatz & Command Reference page

 

Mar 01 2016

ADSecurity.org Now Sponsored by Trimarc!

Sean has founded a new security company called Trimarc focused on providing enterprise security solutions. Launching today, Trimarc’s mission is to identify ways to better protect organizations from modern threats not effectively stopped by traditional security measures.

ADSecurity.org will continue thanks to Trimarc!

Check out Trimarc’s capabilities at TrimarcSecurity.com.

Feb 24 2016

PowerShell Version 5 is Available for Download (again)

After about two months of Microsoft PowerShell developers working around the clock (probably), the bug that wound up causing the WMF 5.0 RTM installer to be pulled is now fixed. There was an issue with the original release dealing with PSModulePath ($Env:PSModulePath) which was reset to default after installation of the original PowerShell v5 installer.

The Windows Management Framework (WMF) 5.0 RTM packages for Windows 2008 R2 SP1/2012 R2/2012 and Windows 7 SP1/8.1 are available for download in the Microsoft Download Center.

As I’ve stated before, due to the security enhancements including logging, updating to PowerShell v5 is highly recommended. More details on the advantages of enabling PowerShell logging and attack detection, including PowerShell v5 security enhancements are in two posts:

Download PowerShell version 5 aka “Windows Management Framework (WMF) 5.0 RTM”

Continue reading

Feb 23 2016

Building an Effective Active Directory Lab Environment for Testing

This post is not meant to describe the ultimate lab configuration. Instead the focus is on a lab environment that can be stood up quickly and easily as a learning tool. The best way to learn about computer networking and security is to have a home lab. The great thing is that a home lab no longer requires several physical computers as it did in the past. Virtualization enables anyone to take a computer with a decent processor and enough RAM to create a lab environment without being overly complex. Furthermore, it’s possible to build a Windows environment at minimal cost for testing.


Hosting The Lab

The Cloud:

Amazon AWS, Microsoft Azure, and others provide capability to install and configure VMs in the cloud which is helpful when traveling since the lab is available and accessible from anywhere (perhaps saving power at home).

The Server:

I have friends that buy older servers from various internet sources (ebay, etc) at a tremendous discount and run those with (potentially) massive hard drive arrays. The big drawback is the power consumption (and associated power bill). The associated components are usually more expensive, though they do last longer.

The Workstation:

This is my preference – build/buy a hefty workstation-class system with a Core i7 processor. I highly recommend using an SSD as the primary OS drive. Also highly recommended is using a separate SSD for the Virtual Machine files. SSDs are exponentially faster than traditional hard drives and the difference is obvious when running a lab on them. For example, my lab computer has 2 SSDs: a C: drive and a D: drive. I can build a new VM in ~7 minutes. Installing a new Windows Server from an ISO file on the C: drive (SSD) takes ~12 minutes. Also, the server VMs boot almost instantly! It’s extremely fast! 🙂

The key is to outfit the lab computer with as much RAM as possible. My recommendation is 16GB at a minimum, 32GB preferred, with more than that even better!
What matters in the system:

  • Processor: Does the work for the virtualization host as well as all VMs. Core i7 (or better) preferred.
  • Hard Drive: SSD all the way! Recommend at least 128GB for system drive and at least 256GB for the drive holding the VM files (preferably more!). I also use a traditional hard drive 1-3TBs in size for VM backups. I really like the Samsung EVO SSDs since they are fast and reliable. A 500GB Samsung EVO SSD runs around $300 online (possibly cheaper by the time you read this).
  • Memory: This is the one you want to put your money into. Personally, I would rather spend a little bit more upfront and have the ability to put 64GB (or more) into a system, then go cheap and have the computer max out at 16GB. The more memory you have, the more VMs you can run which means you can run more involved (& interesting!) scenarios.

I also attach external traditional hard drives (1.5TB and larger) for lab VM backups, though I tend to keep the operating system ISO files and OS template VM files (Sysprep’d operating system VMs) on a SSD for maximum install speed.

Continue reading

Feb 11 2016

Detecting Offensive PowerShell Attack Tools

At DerbyCon V (2015), I presented on Active Directory Attack & Defense and part of this included how to detect & defend against PowerShell attacks.

Update: I presented at BSides Charm (Baltimore) on PowerShell attack & defense in April 2016.
More information on PowerShell Security: PowerShell Security: PowerShell Attack Tools, Mitigation, & Detection

The most important take-away from this post: you want to log all PowerShell activity and get that data into a central logging system to monitor for suspicious and anomalous activity.

The Evolution of PowerShell as an attack tool

PowerShell is a built-in command shell available on every supported version of Microsoft Windows (Windows 7 / Windows 2008 R2 and newer) and provides incredible flexibility and functionality to manage Windows systems. This power makes PowerShell an enticing tool for attackers. Once an attacker can get code to run on a computer, they often invoke PowerShell code since it can be run in memory where antivirus can’t see it. Attackers may also drop PowerShell script files (.ps1) to disk, but since PowerShell can download code from a website and run it in memory, that’s often not necessary.

Dave Kennedy & Josh Kelley presented at DEF CON 18 (2010) on how PowerShell could be leveraged by attackers. Matt Graeber developed PowerSploit and blogged at Exploit-Monday.com on why PowerShell is a great attack platform. Offensive PowerShell usage has been on the rise since the release of “PowerSploit” in 2012, though it wasn’t until Mimikatz was PowerShell-enabled (aka Invoke-Mimikatz) about a year later that PowerShell usage in attacks became more prevalent. PowerShell provides tremendous capability since it can run .Net code and execute dynamic code downloaded from another system (or the internet) and execute it in memory without ever touching disk. These features make PowerShell a preferred method for gaining and maintaining access to systems since they can move around using PowerShell without being seen. PowerShell Version 5 (v5) greatly improves the defensive posture of PowerShell and when run on a Windows 10 system, PowerShell attack capability is greatly reduced.

Continue reading