Nov 22 2015

Dump Clear-Text Passwords for All Admins in the Domain Using Mimikatz DCSync

The two key goals of any attack is access and persistence. This post covers elements of each.
In a post-exploitation scenario where the attacker has compromised the domain or an account with delegated rights, it’s possible to dump the clear-text passwords of admins without being a Domain Admin*. This method requires the Active Directory Domain Functional Level (DFL) to be Windows Server 2008 or higher and a patient attacker (as well as appropriate rights).
* depending on existing AD delegation or attacker configured delegation. Required rights are described at the end of this post

I spoke about some of this information at several security conferences in 2015 (BSides, Shakacon, Black Hat, DEF CON, & DerbyCon).

Mimikatz DCSync Capability:
The Mimikatz DCSync capability is pretty amazing from an offensive perspective since it provides the capability to pull domain account password data remotely from the Domain Controller. The account that runs DCSync needs to have the proper rights since DCSync pulls account data through the standard Domain Controller replication API. Prior to this Mimikatz capability, added in late August, dumping all or selective account password hashes from Active Directory required code execution on the Domain Controller, pulling the AD database (ntds.dit) and dumping the contents, or running something like Invoke-Mimikatz over PowerShell Remoting.

With DCSync, and the proper rights, the attacker can pull useful password data on the account including (potentially):

  • SAM Account name
  • Account Type
  • User Account Control options
  • Account Expiration
  • Password last set date
  • Security ID (SID)
  • RID
  • Current and previous (password history) NTLM password hashes which shows the password history, at least in NTLM hash format.
  • Current and previous LM password hashes which shows the password history in LM hash format.
  • Clear text password (requires reversible encryption)

FGPP-DCSync-Standard-NoClearTextPassword

 

User Account Password Encrypted, Not Hashed:

There’s a legacy feature for Active Directory accounts called “reversible encryption”. Normally a user’s password is hashed using the NT one-way function to create the NTLM password hash. The NTLM password hash can’t be reversed it would have to be cracked, meaning that a tool would have to be used to create passwords and perform the NT hash function to get the NTLM password hash. If the user’s password hash matches the generated one, then the password was successfully guessed (known as brute force password guessing). If reversible encryption is enabled, then the user’s password is stored using encryption which means the encrypted data can be reversed back to the user’s password. The password stored with reversible encryption is not a hash since a function can be called to get back to the original clear-text password.

Continue reading

Nov 17 2015

How Attackers Use Kerberos Silver Tickets to Exploit Systems

Usually Golden Tickets (forged Kerberos TGTs) get all the press, but this post is about Silver Tickets and how attackers use them to exploit systems.
I have talked about how Silver Tickets can be used to persist and even re-exploit an Active Directory enterprise in presentations at security conferences this year. This post continues this research.

Typical Kerberos Authentication Flow:

User logs on with username & password.

1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ).
1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT).

2. The TGT is encrypted, signed, & delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the domain can open and read TGT data.

3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket.

4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).

5.The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.

 

Silver Ticket Overview:

Silver Tickets are forged Kerberos Ticket Granting Service (TGS) tickets, also called service tickets.
As shown in the following graphic, there is no AS-REQ / AS-REP (steps 1 & 2) and no TGS-REQ / TGS-REP (steps 3 & 4) communication with the Domain Controller. Since a Silver Ticket is a forged TGS, there is no communication with a Domain Controller.

Visio-SilverTicket-Comms

  • Alluded to at BlackHat during the “Golden Ticket” presentation (Duckwall/Delpy) and discussed partly during Tim Medin’s DerbyCon 2014 talk. Skip & Benjamin have provided additional information on Silver Tickets since, but confusion remains.
  • The Kerberos Silver Ticket is a valid Ticket Granting Service (TGS) Kerberos ticket since it is encrypted/signed by the service account configured with a Service Principal Name for each server the Kerberos-authenticating service runs on.
  • While a Golden ticket is a forged TGT valid for gaining access to any Kerberos service, the silver ticket is a forged TGS. This means the Silver Ticket scope is limited to whatever service is targeted on a specific server.
  • While a Golden ticket is encrypted/signed with the domain Kerberos service account (KRBTGT), a Silver Ticket is encrypted/signed by the service account (computer account credential extracted from the computer’s local SAM or service account credential).
  • Most services don’t validate the PAC (by sending the PAC checksum to the Domain Controller for PAC validation), so a valid TGS generated with the service account password hash can include a PAC that is entirely fictitious – even claiming the user is a Domain Admin without challenge or correction.
  • The attacker needs the service account password hash
  • TGS is forged, so no associated TGT, meaning the DC is never contacted.
  • Any event logs are on the targeted server.

In my opinion, Silver Tickets can be more dangerous than Golden Tickets – while the scope is more limited than Golden Tickets, the required hash is easier to get and there is no communication with a DC when using them, so detection is more difficult than Golden Tickets.

Continue reading

Oct 14 2015

The Most Common Active Directory Security Issues and What You Can Do to Fix Them

The past couple of years of meeting with customers is enlightening since every environment, though unique, often has the same issues. These issues often boil down to legacy management of the enterprise Microsoft platform going back a decade or more.

I spoke about Active Directory attack and defense at several security conferences this year including BSides, Shakacon, Black Hat, DEF CON, and DerbyCon. These talks include information about how to best protect the Active Directory enterprise from the latest, and most successful, attack vectors.

While the threats have changed over the past decade, the way systems and networks are managed often have not. We continue with the same operations and support paradigm despite the fact that internal systems are compromised regularly. We must embrace the new reality of “Assume Breach.”

Assume breach means that we must assume that an attacker has control of a computer on the internal network and can access the same resources the users who have recently logged on to that computer has access to.
Note that when I describe risks and mitigations of Active Directory,this includes overall enterprise configuration.

Here are some of the biggest AD security issues (as I see them). This list is not complete, but reflects common enterprise issues.
I continue to find many of these issues when I perform Active Directory Security Assessments for organizations.

Continue reading

Sep 26 2015

Sneaky Active Directory Persistence Tricks

The content in this post links to several methods through which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for 5 minutes.

While there are an infinite number of actions an attacker can perform after compromising an enterprise, there are a finite number of pathways. In this series, I attempt to bring these methods out of the darkness and describe how the escalation, exploitation, persistence, and detection work. Yes, some of these may seem obvious – despite this, many organizations have these issues.

I presented on many of these AD persistence methods in Las Vegas at DEF CON 23 (2015) and DerbyCon V (2015) in Kentucky.

This post includes all of the “Sneaky Active Directory Persistence Tricks” posted on ADSecurity.org:

 

 

Sep 25 2015

Sneaky Active Directory Persistence #15: Leverage AdminSDHolder & SDProp to (Re)Gain Domain Admin Rights

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 5 minutes.

I presented on this AD persistence method at DerbyCon (2015).

Complete list of Sneaky Active Directory Persistence Tricks posts 

AdminSDHolder Overview

AdminSDHolder is an object located in the System Partition in Active Directory (cn=adminsdholder,cn=system,dc=domain,dc=com) and is used as a security template for objects that are members of certain privileged groups. Objects in these groups are enumerated and any objects with security descriptors that don’t match the AdminSDHolder ACL are flagged for updating. The Security Descriptor propagator (SDProp) process runs every 60 minutes on the PDC Emulator and re-stamps the object Access Control List (ACL) with the security permissions set on the AdminSDHolder.

SneakyADPersistence-AdminSDProp-AdminSDHolder-ADObject

Objects protected by AdminSDHolder have the attribute “AdminCount” set to 1 and security inheritance is disabled.

Note that when an object is removed from one of the protected groups, AdminCount is not set to another value. This is due to early feedback when Windows 2000 was released.

Note that this article by Jim Sycora clarifies the interaction of AdminSDHolder and SDProp, including misconceptions.

Continue reading

Sep 25 2015

Sneaky Active Directory Persistence #13: DSRM Persistence v2

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 5 minutes.

I presented on this AD persistence method at DerbyCon (2015).
I also presented and posted on DSRM as a persistence method previously.

Complete list of Sneaky Active Directory Persistence Tricks posts

Special thanks to Benjamin Delpy since the research highlighted on this page wouldn’t have been possible without his valuable input.

 

The Directory Restore Mode Account

Every Domain Controller has an internal “Break glass” local administrator account to DC called the Directory Services Restore Mode (DSRM) account. The DSRM password is set when a new DC is promoted and the password is rarely changed.

The DSRM account name is “Administrator” and is the Domain Controller’s local admin account.
We can confirm this with Mimikatz by dumping the local SAM credentials on a Domain Controller.

Mimikatz “token::elevate” “lsadump::sam” exit

SneakyPersistence-DSRM-v2-Dump-DSRM-Local-DCAdministrator-Account

Using DSRM Credentials (standard methods)

Once you know the DSRM account password (local Administrator account on the DC), there are a few tricks to how it can be used.

Logging on to a DC with the DSRM account:

  1. Restart in Directory Services Restore Mode (bcdedit /set safeboot dsrepair)
  2. Access DSRM without rebooting (Windows Server 2008 and newer)
    1. Set the registry key DsrmAdminLogonBehavior to 1
    2. Stop the Active Directory service
    3. Logon using DSRM credentials on the console.
  3. Access DSRM without rebooting (Windows Server 2008 and newer)
    1. Set the registry key DsrmAdminLogonBehavior to 2
    2. Logon using DSRM credentials on the console.
  4. Remote Desktop Client when connecting to the “Console” which is “mstsc /console” prior to Windows Server 2008 and “mstsc /admin” with Windows Server 2008 and newer. Tested on Windows Server 2008 R2. Windows Server 2012R2 seems to refuse DSRM logon via RDP console.

The DSRM Account is a local admin account, so let’s see what else is possible…

Continue reading

Sep 25 2015

Mimikatz DCSync Usage, Exploitation, and Detection

Note: I presented on this AD persistence method at DerbyCon (2015).

A major feature added to Mimkatz in August 2015 is “DCSync” which effectively “impersonates” a Domain Controller and requests account password data from the targeted Domain Controller. DCSync was written by Benjamin Delpy and Vincent Le Toux.

The exploit method prior to DCSync was to run Mimikatz or Invoke-Mimikatz on a Domain Controller to get the KRBTGT password hash to create Golden Tickets. With Mimikatz’s DCSync and the appropriate rights, the attacker can pull the password hash, as well as previous password hashes, from a Domain Controller over the network without requiring interactive logon or copying off the Active Directory database file (ntds.dit).

Special rights are required to run DCSync. Any member of Administrators, Domain Admins, or Enterprise Admins as well as Domain Controller computer accounts are able to run DCSync to pull password data. Note that Read-Only Domain Controllers are not  allowed to pull password data for users by default.

Mimikatz-DCSync-UserRights-DCR-Administrator-500-Dump2

The credentials section in the graphic above shows the current NTLM hashes as well as the password history. This information can be valuable to an attacker since it can provide password creation strategies for users (if cracked).

Continue reading

Sep 19 2015

Sneaky Active Directory Persistence #14: SID History

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 5 minutes.

I presented on this AD persistence method in Las Vegas at DEF CON 23 (2015).

Complete list of Sneaky Active Directory Persistence Tricks posts

SID History is an attribute that supports migration scenarios. Every user account has an associated Security IDentifier (SID) which is used to track the security principal and the access the account has when connecting to resources. SID History enables access for another account to effectively be cloned to another. This is extremely useful to ensure users retain access when moved (migrated) from one domain to another. Since the user’s SID changes when the new account is created, the old SID needs to map to the new one. When a user in Domain A is migrated to Domain B, a new user account is created in DomainB and DomainA user’s SID is added to DomainB’s user account’s SID History attribute. This ensures that DomainB user can still access resources in DomainA.

The interesting part of this is that SID History works for SIDs in the same domain as it does across domains in the same forest, which means that a regular user account in DomainA can contain DomainA SIDs and if the DomainA SIDs are for privileged accounts or groups, a regular user account can be granted Domain Admin rights without being a member of Domain Admins.

Continue reading

Sep 16 2015

Sneaky Active Directory Persistence #12: Malicious Security Support Provider (SSP)

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 5 minutes.

I presented on this AD persistence method in Las Vegas at DEF CON 23 (2015).

Complete list of Sneaky Active Directory Persistence Tricks posts

 

The Security Support Provider Interface (SSPI) enables Windows authentication methods to be easily extended allowing new Security Support Providers (SSPs) to be added without additional coding.

Some of the standard Windows authentication SSPs:

Mimikatz supports DLL/registry (scenario 1) & in-memory updating of SSPs (scenario 2).

Continue reading

Sep 15 2015

Microsoft Local Administrator Password Solution (LAPS)

The Issue
The real problem with local accounts on a computer in an enterprise environment is that the term “local” is a misnomer. If 50 computers on a network have the local administrator account of “Administrator” and a password of “P@55w0rd1!”, first of all that’s a HORRIBLE password. Second of all and more to the point, if one of those computers is compromised, they will all be compromised. Windows is very helpful. So helpful that if you pass the local admin credentials to another computer with the same local credentials, access is granted as if you logged on with the target system credentials. Dump administrator credentials on one to get admin on all! The best way to mitigate this issue is to ensure every computer has a different local administrator account password that is long, complex, and random and that changes on a regular basis.

The earlier attempt to provide a method for regularly changing the local administrator password from Microsoft was less than ideal (see Group Policy Preferences password storage security issue). You should also never, ever use a script that includes a clear-text password to change the local admin password since these scripts tend to be placed in easily accessible locations like SYSVOL (to leverage Group Policy).

Even if you deploy LAPS or some other local Administrator account password management solution, it’s still recommended to install KB2871997 (if required) and configure a Group Policy to block local accounts from authenticating across the network. KB2871997 adds two new local SIDs including LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP (S-1-5-114) for any local account that is a member of the administrators group. Configuring this SID in a Group Policy with the settings “Deny access to this computer from the network” and “Deny log on through Remote Desktop Services” prevents local accounts from connecting over the network (for workstations, test carefully before deploying to servers).

I also posted about “Microsoft LAPS Security & Active Directory LAPS Configuration Recon” in August 2016 which covers some of the more interesting LAPS security scenarios.

 

Microsoft Local Administrator Password Solution (LAPS) Overview
Microsoft Local Administrator Password Solution (LAPS) provides automated local administrator account management for every computer in Active Directory (LAPS is best for workstation local admin passwords). A client-side component installed on every computer generates a random password, updates the (new) LAPS password attribute on the associated AD computer account, and sets the password locally. LAPS configuration is managed through Group Policy which provides the values for password complexity, password length, local account name for password change, password change frequency, etc.

Continue reading

Load more