Aug 01 2019

AD Reading: Windows Server 2019 Active Directory Features

Windows Server 2019 has several new features, though nothing in this list is related to AD. Note that there is no Windows Server 2019 AD Forest/Domain Functional Level.

There are no new features for Active Directory in Windows Server 2019 except one performance update which doesn’t affect most deployments. This update is related to an updated algorithm that better supports the ESE version store on DCs. Ryan Ries describes this on the Ask DS blog:

The intent of the first section of this article is to discuss how Active Directory’s sizing of the ESE version store has changed in Server 2019 going forward. The second section of this article will discuss some basic debugging techniques related to the ESE version store.

Active Directory, also known as NT Directory Services (NTDS,) uses Extensible Storage Engine (ESE) technology as its underlying database.

One component of all ESE database instances is known as the version store. The version store is an in-memory temporary storage location where ESE stores snapshots of the database during open transactions. This allows the database to roll back transactions and return to a previous state in case the transactions cannot be committed. When the version store is full, no more database transactions can be committed, which effectively brings NTDS to a halt.

In 2016, the CSS Directory Services support team blog, (also known as AskDS,) published some previously undocumented (and some lightly-documented) internals regarding the ESE version store. Those new to the concept of the ESE version store should read that blog post first.

In the blog post linked to previously, it was demonstrated how Active Directory had calculated the size of the ESE version store since AD’s introduction in Windows 2000. When the NTDS service first started, a complex algorithm was used to calculate version store size. This algorithm included the machine’s native pointer size, number of CPUs, version store page size (based on an assumption which was incorrect on 64-bit operating systems,) maximum number of simultaneous RPC calls allowed, maximum number of ESE sessions allowed per thread, and more.

Since the version store is a memory resource, it follows that the most important factor in determining the optimal ESE version store size is the amount of physical memory in the machine, and that – ironically – seems to have been the only variable not considered in the equation!

The way that Active Directory calculated the version store size did not age well. The original algorithm was written during a time when all machines running Windows were 32-bit, and even high-end server machines had maybe one or two gigabytes of RAM.

As a result, many customers have contacted Microsoft Support over the years for issues arising on their domain controllers that could be attributed to or at least exacerbated by an undersized ESE version store. Furthermore, even though the default ESE version store size can be augmented by the “EDB max ver pages (increment over the minimum)” registry setting, customers are often hesitant to use the setting because it is a complex topic that warrants heavier and more generous amounts of documentation than what has traditionally been available.

The algorithm is now greatly simplified in Server 2019…”
Deep Dive: Active Directory ESE Version Store Changes in Server 2019



Mar 21 2019

There’s Something About Service Accounts

Service accounts are that gray area between regular user accounts and admin accounts that are often highly privileged. They are almost always over-privileged due to documented vendor requirements or because of operational challenges (“just make it work”).

We can discover service accounts by looking for user accounts with Kerberos Service Principal Names (SPNs) which I call SPN Scanning. Service accounts without SPNs can also be discovered by querying AD accounts for ‘SVC’, or ‘Service’, or common vendor product names.

The following PowerShell commands require the Active Directory PowerShell module.

Discover service accounts (user accounts with SPNs): 

get-aduser -filter {ServicePrincipalName -like “*”} -Properties PasswordLastSet,LastLogonDate,ServicePrincipalName,TrustedForDelegation,TrustedtoAuthForDelegation

Discover probable AD Admin accounts (user accounts with AdminCount set to 1):

get-aduser -filter {AdminCount -eq 1} -Properties Name,AdminCount,ServicePrincipalName,PasswordLastSet,LastLogonDate,MemberOf

While Domain Admins is the most commonly used AD admin group, there are several others that could be used.

Common privileged AD groups that may contain Service Accounts: 

  • Administrators
    • Full administrative rights to the AD domain and Domain Controllers.
  • Domain Admins
    • Full administrative rights to computers joined to the domain (default) and full administrative rights to the AD domain and DCs (through membership in the Administrators group).
  • Backup Operators
    • Default rights to backup and restore Active Directory and Domain Controllers.
  • Server Operators
    • Able to logon to Domain Controllers and provides ability to perform some administrative actions on Domain Controllers.
  • Enterprise Admins
    • Full administrative rights to all domains and Domain Controllers in the AD forest (through membership in the Administrators group). Also has special forest admin rights such as DHCP. In a single domain forest, this group should remain empty until needed.
  • Schema Admins
    • Able to modify the AD schema for the forest. This group should remain empty until needed.
Continue reading

Feb 12 2019

Mitigating Exchange Permission Paths to Domain Admins in Active Directory

This article is a cross-post from TrimarcSecurity.com
Original article: https://www.trimarcsecurity.com/single-post/2019/02/12/Mitigating-Exchange-Permission-Paths-to-Domain-Admins-in-Active-Directory

The Issue 
Recently a blog post was published by Dirk-jan Mollema titled “Abusing Exchange: One API call away from Domain Admin ” (https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/)which highlighted several issues with Exchange permissions and a chained attack which would likely result in a regular user with a mailbox being able to become a Domain Admin in the AD forest. Tools have been released to take advantage of this issue.

He highlights the key components of the issue in the blog post introduction:

This blog combines a few known vulnerabilities and known protocol weaknesses into a new attack. There are 3 components which are combined to escalate from any user with a mailbox to Domain Admin access:

  * Exchange Servers have (too) high privileges by default
  * NTLM authentication is vulnerable to relay attacks
  * Exchange has a feature which makes it authenticate to an attacker with the computer account of the Exchange server
…
The main vulnerability here is that Exchange has high privileges in the Active Directory domain. The Exchange Windows Permissions group has WriteDacl access on the Domain object in Active Directory, which enables any member of this group to modify the domain privileges, among which is the privilege to perform DCSync operations. Users or computers with this privilege can perform synchronization operations that are normally used by Domain Controllers to replicate, which allows attackers to synchronize all the hashed passwords of users in the Active Directory.

Exchange Permissions in Active Directory 

At the Microsoft Blue Hat in 2017, Sean Metcalf, Trimarc founder and Active Directory Subject Matter Expert (SME) highlighted issues with Exchange permissions. Some slides from this presentation are shown here as representative samples (the full presentation slide deck is in the Presentations section.

More information about this issue has been highlighted in presentations by Andy Robbins (@_wald0) and Will (@Harmj0y), including at Black Hat USA 2017.

The Bloodhound tool written by Andy Robbins, Rohan Vazarkar, and Will can identify attack paths involving Exchange permissions configured in Active Directory.

Microsoft recently published an article (https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190007) on how to configure EWS throttling which will mitigate the issue(s) that Dirk-jan Mollema raised. The issue with this is that EWS throttling could negatively impact applications like Outlook for Mac and doesn’t resolve the escalation path with Exchange permissions configured in AD.

Trimarc has discovered Exchange having elevated permissions in AD in many customer environments while performing Active Directory Security Assessments (ADSAs).

Continue reading

Oct 11 2018

From DNSAdmins to Domain Admin, When DNSAdmins is More than Just DNS Administration

It’s been almost 1.5 years since the Medium post by Shay Ber was published that explained how to execute a DLL as SYSTEM on a Domain Controller provided the account is a member of DNSAdmins.
I finally got around to posting here since many I speak with aren’t aware of this issue.

Shay describes this issue as follows (bolded text addedby me):

In addition to implementing their own DNS server, Microsoft has also implemented their own management protocol for that server, to allow for easy management and integration with Active Directory domains. By default, domain controllers are also DNS servers; DNS servers need to be reachable and usable by mostly every domain user. This, in turn, exposes quite some attack surface on domain controllers — on one part, the DNS protocol itself and on the other, the management protocol, which is based on RPC.

We will shallowly delve into the protocol’s implementation and detail a cute feature (certainly not a bug!) which allows us, under some circumstances, to run code as SYSTEM on domain controllers, without being a domain admin. Although this is certainly not a security vulnerability (so no panic is needed), as confirmed with Microsoft, it’s still a cute trick which can be useful as an AD privilege escalation in red team engagements.

So, how is this possible?
I will summarize Shay’s excellent technical review of this issue (this assumes DNS runs on Domain Controllers, which is the most common configuration).

Continue reading

Oct 10 2018

Domain Controller Print Server + Unconstrained Kerberos Delegation = Pwned Active Directory Forest

At DerbyCon 8 (2018) over the weekend Will Schroeder (@Harmj0y), Lee Christensen (@Tifkin_), & Matt Nelson (@enigma0x3), spoke about the unintended risks of trusting AD. They cover a number of interesting persistence and privilege escalation methods, though one in particular caught my eye.
Overview
Lee figured out and presents a scenario where there’s an account with unconstrained delegation configured (which is fairly common) and the Print Spooler service running on a computer, you can get that computers credentials sent to the system with unconstrained delegation as a user.

Continue reading

Aug 12 2018

Black Hat & DEF CON Presentation Slides Posted

I just uploaded the slides from my Black Hat & DEF CON talks from the past week in Vegas.  They are a bit different with the BH talk more Blue (defensive) and the DC talk mostly Red (Offensive) in focus. Also note that the only real overlap in content is the MFA & password vault sections and those were updated in my DEF CON talk to focus on the attack aspect.

An important note: The methods I show are real and work well in many real-world customer deployments. The issues with MFA and password vaults I highlight are often deployment issues and not necessarily vendor best practices. With that noted, I have seen enterprise password vaults deployed with poor security so often that I don’t think customers are very familiar with the vendor security best practices.

Slides are in the Presentations section.

Black Hat USA 2018 Talk:  “From Workstation to Domain Admin: Why Secure Administration isn’t Secure and How to Fix it”


This talk walks the audience through how AD administration has evolved over time with newer, more “secure” methods and the potential ways to exploit modern AD administration. I explore some methods to exploit current implementation weaknesses in many deployments of multi-factor authentication (MFA) and enterprise password vaults. The latter third of the talk dives into the best defenses and how to employ and deploy them appropriately.
[Slides]

Black Hat Talk Agenda:

  • Current State
  • Evolution of Administration
  • Exploiting Typical Administration
  • Common Methods of Protecting Admins (& bypassing them)
  • MFA
  • Enterprise Password Vaults
  • Admin Forest
  • Building the Best Defenses

DEF CON 26 Talk: “Exploiting Active Directory Administrator Insecurities”


This talk repeats the slide concepts from my Black Hat talk specific to exploiting current implementation weaknesses in many deployments of multi-factor authentication (MFA) and enterprise password vaults.  The talk adds in some challenges in properly discovering AD admins and some additional methods of exploiting current AD environments. I also cover how in many environments it may be possible to compromise a Read-Only Domain Controller to compromise the AD forest. This talk also includes a special, new sneaky AD persistence method which only the DEF CON audience was privy to (not in the slides, at least not directly). I will post a blog article as time allows. 🙂
[Slides]

DEF CON Talk Agenda:

  • Evolution of Admin Discovery
  • Exploiting Typical Administration
  • Multi-Factor Authentication (MFA)
  • Password Vaults
  • Admin Forest
  • Attacking RODCs

Thank you all for your support and your kind words!
– Sean

May 20 2018

NolaCon (2018) Active Directory Security Talk Slides Posted

I recently presented my talk  “Active Directory Security: The Journey” at Nolacon in New Orleans, LA.
Slides are now posted here.

On Sunday, May 19th, 2018, I spoke at NolaCon at 11am.

Here’s the talk description:

Active Directory is only the beginning.
Attackers have set their sights squarely on Active Directory when targeting a company, though this typically isn’t the primary objective. The motivation and end goals range from stealing data to impacting corporate operations. In this regard, gaining control of Active Directory is a means to an end; compromising Active Directory is an easy way to gain access to all critical corporate resources. Effectively protecting Active Directory has become critical in limiting the impact of a breach.

This talk takes the audience on a journey covering the various security milestones and challenges with Active Directory. A variety of  AD security posture are highlighted along with the challenges they encounter with securing their systems. Key elements involve how enterprise “”AD aware”” applications can weaken Active Directory security and how leveraging cloud services complicate securing infrastructure. Also explored is what an attacker can do in an environment without having Domain Admin rights. 

This talk covers the critical issues affecting organizations today, as well as the biggest challenges; current attack techniques; and the most effective defensive techniques to prevent and mitigate compromise (including limitations to these approaches).

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

Continue reading

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