Jan 01 2018

Attacking Read-Only Domain Controllers (RODCs) to Own Active Directory

I have been fascinated with Read-Only Domain Controllers (RODCs) since RODC was released as a new DC promotion option with Windows Server 2008. Microsoft customers wanted a DC that wasn’t really a DC. – something that could be deployed in a location that’s not physically secure and still be able to authenticate users.

This post covers a few different scenarios on how to attack  Read-Only Domain Controllers in order to escalate privilege. Since RODCs are typically untrusted and viewed as not having the same level of access as writable DCs, it’s possible in many environments to compromise a RODC  to escalate privileges. Given certain scenarios, it’s possible to escalate from a Read-Only Domain Controller to a full writable Domain Controller.  This post covers these scenarios and enables Red and Blue teams to better understand and check RODC configurations for issues.

The information in this post is not from any one customer environment I have seen, but a combination of several. I have found that many AD domains that have RODCs are configured very similarly: many more accounts, both user and computer, have passwords cached on RODCs than is necessary and the ability to manage RODCs is not limited or secured appropriately. This post shows what is possible given common real world RODC deployment configuration. As part of our Active Directory security review services, we scrutinize RODC configuration and identify potential issues with the configuration. Furthermore, we find that when RODCs are deployed in an environment, they are frequently configured  with weak security settings (as noted in “RODCs in the Real World” and “Attacking RODCs” below).

The information here describes what is possible in many Active Directory environments with Read-Only Domain Controllers and doesn’t highlight a misconfiguration, but common configuration issues that could be exploited to escalate privileges in the domain since the RODC is often treated as “just another server” (or worse, as a workstation). Accounts are regularly cached on RODCs (since RODCs that don’t cache passwords aren’t very useful) and once an attacker gains access to it, these passwords are available and may include delegated Active Directory admin accounts which could be compromised.

If you want to simply know how best to “harden Read-Only Domain Controllers”, skip to the end to read the “Securing RODCs Against Attack” section.

Note that throughout this post, I use the Microsoft Active Directory PowerShell cmdlets and some of the attribute names are adjusted in the output from what they are actually named in AD.

 

Enter the Read-Only Domain Controller 

When Microsoft released Windows Server 2008, a new type of Domain Controller was added called the “Read-Only Domain Controller”. The Read-Only Domain Controller (RODC) performs similar services as a writable Domain Controller except they are “read-only”. But what does that really mean?

Continue reading

Nov 24 2017

Securing Microsoft Active Directory Federation Server (ADFS)

Many organizations are moving to the cloud and this often requires some level of federation. Federation, put simply, extends authentication from one system (or organization) to another.

Gerald Steere (@Darkpawh) and I spoke about cloud security at DEF CON in July 2017.
Presentation slides and video are here: “Hacking the Cloud”

One of the key items we covered was protecting Federation Servers, specifically  Microsoft Active Directory Federation Servers (ADFS).

Microsoft is currently updating guidance for securing ADFS.
This post describes key ADFS concepts and a short-list of security recommendations on how to properly protect ADFS.

Federation Overview

The federation server typically lives on the internal network with a proxy server in the DMZ. There are certificates installed on the Federation server.

ADFS uses the following certificates:

  • Service communication
  • Token-decrypting
  • Token-signing

ADFS terminology also includes:

  • Relying party trusts: cloud services and applications
  • Claim rules: determine what type of access and from where access is allowed.

Key Federation Points:

  • Federation: trust between organizations leveraging PKI (certificates matter)
  • Cloud SSO often leverages temporary or persistent browser cookies (cookies provide access)
  • Several protocols may be supported, though typically SAML. (protocols and versions matter)
  • Federation server (or proxy) is on public internet via port 443 (HTTPS).

Conceptual federation authentication flow Continue reading

Aug 11 2017

Gathering AD Data with the Active Directory PowerShell Module

Microsoft provided several Active Directory PowerShell cmdlets with Windows Server 2008 R2 (and newer) which greatly simplify tasks which previously required putting together lengthy lines of code involving ADSI.

On a Windows client, install the Remote Sever Administration Tools (RSAT) and ensure the Active Directory PowerShell module is installed.

On a Windows server (2008 R2 or newer), run the following commands in a PowerShell console (as an Adminsitrator):

Import-Module ServerManager ; Add-WindowsFeature RSAT-AD-PowerShell

Here’s my (poor) ADSI example:

$UserID = “JoeUser”
$root = [ADSI]''
$searcher = new-object System.DirectoryServices.DirectorySearcher($root)
$searcher.filter = "(&(objectClass=user)(sAMAccountName= $UserID))"
$user = $searcher.findall()
$user

Here’s the same thing with the AD PowerShell cmdlet:

Import-module ActiveDirectory
$UserID = “JoeUser”
Get-ADUser $UserID –property *

Note that with PowerShell version 3 and newer, you don’t need to run the first line since Powershell will identify the necessary module and auto load it.

Once you have the Active Directory PowerShell module loaded, you can do cool stuff like browse AD like a file system

 

Finding Useful Commands (Cmdlets):

Discover available PowerShell modules: Get-Module -ListAvailable

Discover cmdlets in a PowerShell module: Get-Command -module ActiveDirectory

 PowerShell AD Module Cmdlets:

  • Windows Server 2008 R2: 76 cmdlets
  • Windows Server 2012: 135 cmdlets
  • Windows Server 2012 R2: 147 cmdlets
  • Windows Server 2016: 147 cmdlets
(Get-Command -module ActiveDirectory).count

 

Finding Active Directory Flexible Master Single Operation (FSMO) Roles:

Active Directory Module:

  • (Get-ADForest).SchemaMaster
  • (Get-ADForest).DomainNamingMaster
  • (Get-ADDomain).InfrastructureMaster
  • (Get-ADDomain).PDCEmulator
  • (Get-ADDomain).RIDMaster

.NET Calls:

  • ([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()).SchemaRoleOwner
  • ([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()).NamingRoleOwner
  • ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).InfrastructureRoleOwner
  • ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).PdcRoleOwner
  • ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).RidRoleOwner

 

Active Directory PowerShell Module Cmdlet Examples:

Continue reading

Aug 10 2017

Beyond Domain Admins – Domain Controller & AD Administration

Active Directory has several levels of administration beyond the Domain Admins group. In a previous post, I explored: “Securing Domain Controllers to Improve Active Directory Security” which explores ways to better secure Domain Controllers and by extension, Active Directory. For more information on Active Directory specific rights and permission review my post “Scanning for Active Directory Privileges & Privileged Accounts.”

This post provides information on how Active Directory is typically administered and the associated roles & rights.

  • Domain Admins is the AD group that most people think of when discussing Active Directory administration. This group has full admin rights by default on all domain-joined servers and workstations, Domain Controllers, and Active Directory. It gains admin rights on domain-joined computers since when these systems are joined to AD, the Domain Admins group is added to the computer’s Administrators group.
  • Enterprise Admins is a group in the forest root domain that has full AD rights to every domain in the AD forest. It is granted this right through membership in the Administrators group in every domain in the forest.
  • Administrators in the AD domain, is the group that has default admin rights to Active Directory and Domain Controllers and provides these rights to Domain Admins and Enterprise Admins, as well as any other members.
  • Schema Admins is a group in the forest root domain that has the ability to modify the Active Directory forest schema.

Since the Administrators group is the domain group that provides full rights to AD and Domain Controllers, it’s important to monitor this group’s membership (including all nested groups). The Active Directory PowerShell cmdlet “Get-ADGroupMember” can provide group membership information.

Default groups in Active Directory often have extensive rights – many more than typically required. For this reason, we don’t recommend using these groups for delegation. Where possible, perform custom delegation to ensure the principle of least privilege is followed. The following groups should have a “DC” prefix added to them since the scope applies to Domain Controllers by default. Furthermore, they have elevated rights on Domain Controllers and should be considered effectively Domain Controller admins.

  • Backup Operators is granted the ability to logon to, shut down, and perform backup/restore operations on Domain Controllers (assigned via the Default Domain Controllers Policy GPO). This group cannot directly modify AD admin groups, though associated privileges provides a path for escalation to AD admin. Backup Operators have the ability to schedule tasks which may provide an escalation path. They also are able to clear the event logs on Domain Controllers.
  • Print Operators is granted the ability to manage printers and load/unload device drivers on Domain Controllers as well as manage printer objects in Active Directory. By default, this group can logon to Domain Controllers and shut them down. This group cannot directly modify AD admin groups.
  • Server Operators is granted the ability to logon to, shut down, and perform backup/restore operations on Domain Controllers (assigned via the Default Domain Controllers Policy GPO). This group cannot directly modify AD admin groups, though associated privileges provides a path for escalation to AD admin.

To a lesser extend, we’ll group Remote Desktop Users into this category as well.

  • Remote Desktop Users is a domain group designed to easily provide remote access to systems. In many AD domains, this group is added to the “Allow log on through Terminal Services” right in the Default Domain Controllers Policy GPO providing potential remote logon capability to DCs.

We also see that many times the following is configured via GPO linked to the Domain Controllers OU:

  • Remote Desktop Users: often granted “Allow log on through Terminal Services” right via Group Policy linked to the Domain Controllers OU.
  • Server Operators: granted “Allow log on through Terminal Services” right via Group Policy linked to the Domain Controllers OU.
  • Server Operators: granted “Log on as a batch job” right via GPO providing the ability to schedule tasks.

Review the GPOs linked to the Domain and the Domain Controllers OU and ensure the GPO settings are appropriate.
We often find that a servers GPO is also linked to the Domain Controllers OU and it adds a “Server Admins” group to the local Administrators group. Since Domain Controllers don’t have a “local” Administrators group, the DC updates the domain Administrators group by adding Server Admins. This scenario makes all members of Server Admins Active Directory admins.

Any group/account granted logon locally rights to Domain Controllers should be scrutinized.

Server Operators & Backup Operators have elevated rights on Domain Controllers and should be monitored. The Active Directory PowerShell cmdlet “Get-ADGroupMember” can provide group membership information.

 

Other default groups with elevated rights:

Continue reading

May 30 2017

AD Reading: Windows Server 2016 Active Directory Features

The following are useful resources for Windows Server 2016 Active Directory Features.

 

Windows 2016 Features

 

Privileged Access Management (PAM)

 

Azure AD Join

 

Microsoft Hello for Business (formerly Microsoft Passport)

 

 

 

May 01 2017

BSides Charm (2017) Talk Slides Posted – Detecting the Elusive: Active Directory Threat Hunting

I recently presented my talk  “Detecting the Elusive: Active Directory Threat Hunting” at BSides Charm in Baltimore, MD.
Slides are now posted in the Presentations section.

I cover some of the information I’ve posted here before:

 

On Sunday, April 30th, 2017, I spoke at BSides Charm in Track 2 at 2pm.

Here’s the talk description from the BSides Charm website:

Detecting the Elusive: Active Directory Threat Hunting
Attacks are rarely detected even after months of activity. What are defenders missing and how could an attack by detected?

This talk covers effective methods to detect attacker activity using the features built into Windows and how to optimize a detection strategy. The primary focus is on what knobs can be turned and what buttons can be pushed to better detect attacks.

One of the latest tools in the offensive toolkit is “”Kerberoast”” which involves cracking service account passwords offline without admin rights. This attack technique is covered at length including the latest methods to extract and crack the passwords. Furthermore, this talk describes a new detection method the presenter developed.

The attacker’s playbook evolves quickly, defenders need to stay up to speed on the latest attack methods and ways to detect them. This presentation will help you better understand what events really matter and how to better leverage Windows features to track, limit, and detect attacks

This presentation covers the type of log data required to properly

For the curious, here’s an outline of the talk:

Continue reading

May 01 2017

Sp4rkCon (2017) Talk Slides Posted – Active Directory Security: The Good, the Bad, & the UGLY

I recently presented my talk “Active Directory Security: The Good, the Bad, & the UGLY” at Sp4rkCon in Bentonville, AR in April 2017.
Slides are now posted in the Presentations section.

I cover some of the information I’ve posted here before:

Here’s the talk description:

Active Directory Security:The Good, the Bad, & the UGLY

While security of the enterprise has been laid bare for years, exploitation techniques targeting  Active Directory were relatively rare. In recent years, attackers have focused on more than passing hashes and getting Domain Admin. From SPN Scanning for services to Kerberoasting for credentials to Golden Tickets for persistence, there are multiple methods for attacking Active Directory. Active Directory is the primary identity and management infrastructure for most enterprises and properly securing the AD forest has never been more important.

Some of the topics covered:

* PowerShell attacks

* Active Directory recon

* Credential theft

* Kerberos delegation

This talk is an update of Sean’s talk from 2015 entitled: “Red vs. Blue:
Modern Active Directory Attacks & Defense” where he covered various attack methods and related mitigation. This update explores the current attack techniques and the latest detection.

The presented Information is useful for both Red & Blue Team members.

This presentation is a remix of talks I did last year with some additional information mixed in. New to this talk is coverage of Kerberos delegation issues (not just unconstrained) and how to detect Kerberoasting.

For the curious, here’s an outline of the talk:

Continue reading

Feb 05 2017

Detecting Kerberoasting Activity

Introduction

Kerberoasting can be an effective method for extracting service account credentials from Active Directory as a regular user without sending any packets to the target system. This attack is effective since people tend to create poor passwords. The reason why this attack is successful is that most service account passwords are the same length as the domain password minimum (often 10 or 12 characters long) meaning that even brute force cracking doesn’t likely take longer than the password maximum password age (expiration). Most service accounts don’t have passwords set to expire, so it’s likely the same password will be in effect for months if not years. Furthermore, most service accounts are over-permissioned and are often members of Domain Admins providing full admin rights to Active Directory (even when the service account only needs to modify an attribute on certain object types or admin rights on specific servers).

Tim Medin presented on this at DerbyCon 2014 in his “Attacking Microsoft Kerberos Kicking the Guard Dog of Hades” presentation (slides & video) where he released the Kerberoast Python TGS cracker.

This is a topic we have covered in the past in the posts “Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain” & “Sneaky Persistence Active Directory Trick #18: Dropping SPNs on Admin Accounts for Later Kerberoasting.”
Also Will Schroeder, aka Will Harmjoy (@harmj0y), and I spoke at DerbyCon 2016 about how to Kerberoast to escalate privileges.

Note: This attack will not be successful when targeting services hosted by the Windows system since these services are mapped to the computer account in Active Directory which has an associated 128 character password which won’t be cracked anytime soon.

Part 2 of this post describes effective detection of Kerberoasting with no false positives.

Let’s quickly cover how Kerberos authentication works before diving into how Kerberoasting works and how to detect Kerberoast type activity.

Continue reading

Load more