Jan 01 2016

Attack Methods for Gaining Domain Admin Rights in Active Directory

There are many ways an attacker can gain Domain Admin rights in Active Directory. This post is meant to describe some of the more popular ones in current use. The techniques described here “assume breach” where an attacker already has a foothold on an internal system and has gained domain user credentials (aka post-exploitation).

The unfortunate reality for most enterprises, is that it often does not take long from an attacker to go from domain user to domain admin. The question on defenders’ minds is “how does this happen?”.

The attack frequently starts with a spear-phishing email to one or more users enabling the attacker to get their code running on a computer inside the target network. Once the attacker has their code running inside the enterprise, the first step is performing reconnaissance to discover useful resources to escalate permissions, persist, and of course, plunder information (often the “crown jewels” of an organization).

While the overall process detail varies, the overall theme remains:

  • Malware Injection (Spear-Phish, Web Exploits, etc)
  • Reconnaissance (Internal)
  • Credential Theft
  • Exploitation & Privilege Escalation
  • Data Access & Exfiltration
  • Persistence (retaining access)

We start with the attacker having a foothold inside the enterprise, since this is often not difficult in modern networks. Furthermore, it is also typically not difficult for the attacker to escalate from having user rights on the workstation to having local administrator rights. This escalation can occur by either exploiting an unpatched privilege escalation vulnerability on the system or more frequently, finding local admin passwords in SYSVOL, such as Group Policy Preferences.

I spoke about most of these techniques when at several security conferences in 2015 (BSides, Shakacon, Black Hat, DEF CON, & DerbyCon).

I also covered some of these issues in the post “The Most Common Active Directory Security Issues and What You Can Do to Fix Them“.

Continue reading

Dec 31 2015

Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain

Microsoft’s Kerberos implementation in Active Directory has been targeted over the past couple of years by security researchers and attackers alike. The issues are primarily related to the legacy support in Kerberos when Active Directory was released in the year 2000 with Windows Server 2000. This legacy support is enabled when using Kerberos RC4 encryption (RC4_HMAC_MD5) since the NTLM password hash is used extensively with this encryption type.

There are several Kerberos attacks that take advantage of Microsoft’s legacy support in Active Directory. When Microsoft released Windows 2000 and Active Directory along with it, they needed to support Windows NT and Windows 95 which meant a wide variety of security (and less secure configurations). This support meant that Microsoft needed to support several different clients and enable them to speak Kerberos. The easy way to do this was to use the NTLM password hash as the Kerberos RC4 encryption private key used to encrypt/sign Kerberos tickets. Once the NTLM password hash is discovered, it can be used in a variety of ways, including re-compromising the Active Directory domain (think Golden Tickets & Silver Tickets).

RC4 Kerberos encryption is still supported even now, 15 years later. In fact, AES encryption wasn’t available as an option on Windows until Windows Vista and Windows Server 2008. While AES Kerberos encryption is now used by default on the newer operating systems, there may still be significant use of RC4 Kerberos encryption on the network, involving some interesting network devices that have AES Kerberos encryption disabled by default.

With the introduction of AES as a Kerberos encryption option, Windows uses AES for hashing which is a break from traditional Windows password hashing methods. This means that while Kerberos RC4 encryption leveraged the NTLM password hash as encryption key, Kerberos AES encryption uses the AES hash to encrypt the Kerberos tickets. (in other words, when AES is the Kerberos encryption

Update:
Will @harmj0y Schroeder (blog.harmj0y.net) and I spoke at DerbyCon 6 in September, 2016 and demonstrated how Kerberoast works. The slides and video from our talk are now available. The other demos Will did during the talk are here.
All of the slides and most videos of my talks are on the Presentations page.
This article describes how Service Principal Names work and how to use Kerberoast to crack passwords offline. Will also posted on how to Kerberoast without using Mimikatz.

 

Active Directory Kerberos Attacks:

There are several different types of Kerberos attacks ranging from recon (SPN Scanning), to offline service account password cracking (Kerberoast), to persistence (Silver & Golden Tickets).

Here are the most popular AD Kerberos attacks:

  • SPN Scanning – finding services by requesting service principal names of a specific SPN class/type.
  • Silver Ticket – forged Kerberos TGS service ticket
  • Golden Ticket – forged Kerberos TGT authentication ticket
  • MS14-068 Forged PAC Exploit – exploitation of the Kerberos vulnerability on Domain Controllers.
  • Diamond PAC – blended attack type using elements of the Golden Ticket and the MS14-068 forged PAC.
  • Skeleton Key In-memory Malware – malware “patches” the LSASS authentication process in-memory on Domain Controllers to enable a second, valid “skeleton key” password with which can be used to authenticate any domain account.

This post covers another type of Kerberos attack that involves Kerberos TGS service ticket cracking using Kerberoast. This information is based on the presentations I gave at several security conferences in 2015 (BSides, Shakacon, Black Hat, DEF CON, & DerbyCon) and Tim Medin’s DerbyCon “Attacking Microsoft Kerberos Kicking the Guard Dog of Hades” presentation in 2014 (slides & video) where he released the Kerberoast Python TGS cracker.

 

Continue reading

Dec 28 2015

Finding Passwords in SYSVOL & Exploiting Group Policy Preferences

At Black Hat and DEF CON this year, I spoke about ways attackers go from Domain User to Domain Admin in modern enterprises.

Every Windows computer has a built-in Administrator account with an associated password. Changing this password is a security requirement in most organizations, though the method for doing so is not straight-forward. A standard method is to use Group Policy to set the local Administrator password across a large number of workstations. A major issue with this is that all of the computers have the same local Administrator password. Windows is extremely helpful when it comes to local accounts since if two (or more) computers have the same local account name and password, Windows will authenticate the account as if it is local, meaning that by gaining knowledge of the administrator credential on one system, the attacker can gain admin access to all of them (that have the same local administrator credentials).

SYSVOL

One of these methods is mining SYSVOL for credential data.

SYSVOL is the domain-wide share in Active Directory to which all authenticated users have read access. SYSVOL contains logon scripts, group policy data, and other domain-wide data which needs to be available anywhere there is a Domain Controller (since SYSVOL is automatically synchronized and shared among all Domain Controllers).

All domain Group Policies are stored here: \\<DOMAIN>\SYSVOL\<DOMAIN>\Policies\

Credentials in SYSVOL

A big challenge for administrators has been ensuring that the local Administrator account (RID 500) on all Windows computers. The traditional method for doing this (other than buying a product) has been to use a custom script to change the local administrator password. This issue with this is that frequently the password is stored in clear-text within the script (such as a vbs file) which is often in SYSVOL. Here’s an example of one of the top results when searching for a VBS script that changes the local Administrator password. The vbs script is still available on the Microsoft TechNet gallery and the password is obvious. Remember this script is stored in SYSVOL which every domain user has read access to and the password is the local Administrator password for every computer the Group Policy is applied to.

Continue reading

Dec 14 2015

Unofficial Guide to Mimikatz & Command Reference

A new page on ADSecurity.org just went live which is an “unofficial” guide to Mimikatz which also contains an expansive command reference of all available Mimikatz commands. Screenshots, descriptions, and parameters are included where available and appropriate.

This page includes the following topics:

  • Mimikatz Overview
  • Mimikatz & Credentials
  • Available Credentials by OS
  • PowerShell & Mimikatz
  • Mimikatz Mitigation
  • Detecting Mimikatz
  • Detecting Invoke-Mimikatz
  • Detecting Offensive PowerShell Tools
  • Most Popular Mimikatz Commands
  • ADSecurity Mimikatz Posts
  • Mimikatz Command Reference

View the ADSecurity Mimikatz Page: Unofficial Guide to Mimikatz & Command Reference

 

Nov 30 2015

Real-World Example of How Active Directory Can Be Compromised (RSA Conference Presentation)

At the RSA Conference in Abu Dhabi earlier this month, Stefano Maccaglia (Incident Response Consultant with RSA) presented “Evolving Threats: dissection of a Cyber-Espionage attack.” The slides for this talk are available on the RSA Conference site (UPDATE: RSA removed the slides from their site, Presentation Slides on Yumpu). This post covers and adds some additional detail to the attack that Stefano Maccaglia and RSA colleagues dealt with as described in this talk. I have no information about this attack other than what is covered in the slides since I wasn’t involved in the incident response. Since this RSA talk has great detail on the attack, I am taking the opportunity to point how what weaknesses the attacker exploited and how other organizations can learn from this breach. I don’t deal with attribution, so I leave it to the reader to follow the presenter’s narrative on who the attacker was.

The attack started, as many do, with a spear-phish email which was opened and code executed (in this case leveraging a Microsoft Word exploit). It is noted that the internet proxy blocked seven (7) out of nine (9) of the attacks. It only takes one success though for the attacker to gain a foothold inside the network. Note that there was a second wave which adjusted to the internet proxy configuration and was far more successful the second time around. Always expect that the attacker will quickly learn more about your environment than what you have documented.
I don’t cover malware, so I won’t dig into the details of what the code did other than recon, privilege escalation, and lateral movement.

It is interesting that the attacker leveraged OWA to use stolen credentials to spread the malware using internal email addresses. The benefit to the attacker is that users often are more likely to open websites and files sent from internal email addresses.

The other interesting part is that the attacker also leveraged SharePoint to expand access by distributing the malware further. Is your organization checking for malware in SharePoint? You should.
Once the attacker has access to commonly accessed/downloaded data, any of it can be updated with malware to either expand access or persist.

Continue reading

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.

Continue reading

Load more