Active Directory Recon Without Admin Rights

A fact that is often forgotten (or misunderstood), is that most objects and their attributes can be viewed (read) by authenticated users (most often, domain users). The challenge is that admins may think that since this data is most easily accessible via admin tools such as “Active Directory User and Computers” (dsa.msc) or “Active Directory Administrative Center” (dsac.msc), that others can’t see user data (beyond what is exposed in Outlook’s GAL). This often leads to password data being placed in user object attributes or in SYSVOL.

There is a lot of data that can be gathered from Active Directory which can be used to update documentation or to recon the environment for the next attack stages. It’s important for defenders to understand the different types of data accessible in AD with a regular user account.

Attacks frequently start 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).

This post shows how an attacker can recon the Active Directory environment with just domain user rights. Many people are surprised when they learn how much information can be gathered from AD without elevated rights.

Note: Most of the examples in this post use the Active Directory PowerShell module cmdlets. A good alternative is HarmJ0y’s PowerView (now part of PowerSploit).

I spoke about some of these techniques 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 in the Press!

IT World Canada reached out to me recently to help with an article on Active Directory attack & defense.

Read the article: “IT not doing enough to secure Active Directory, says expert.”

IIT World Canada also requested comments for a second story titled: “22 tips for preventing ransomware attacks“.

So You Want to Speak at a Security Conference?

After performing research at the end of 2014 on Microsoft enterprise security, specifically Active Directory, I realized that others may be interested in this information – my customers certainly were! So, I decided to submit a talk to the various security conferences and see what happened. I certainly didn’t expect to be accepted at 5 out of 5 of the conferences I submitted to!

In 2015, I spoke at the following security conferences:

  • BSides Charm (Baltimore)
  • Shakacon (Hawaii)
  • Black Hat USA 2015 (Las Vegas)
  • DEF CON 23 (Las Vegas)
  • DerbyCon (Kentucky)

This post is my attempt to note the approaches that worked for me, and share with others the key items involved in my talk being accepted. By no means do I think I have struck on some sort of magic “formula” that ensures success, but I do want to share some important items that reviewers will look for and appreciate.

How did I get accepted to speak?
I think it was a combination of the following:

  • Compelling, relevant, & current material
  • Well-written CFP response submitted soon after the CFP opened (the earlier the better).
  • Matching content to the conference focus (if a conference focuses on new content and you are submitting a version 2 of your talk, it’s likely you won’t be accepted).

Note: I have been rejected to speak at conferences since speaking at Black Hat & DEF CON. Don’t think that speaking at one conference means you will speak at others. Again, I don’t have the special CFP formula for acceptance. I just want to help others with the CFP process. Good CFP responses tend to get accepted and speaker slots are limited, so take the time to develop a really great response!

If you have tips and/or other information helpful for those going through the CFP process, please send them my way. Special thanks to Jericho (@attritionorg) for his input (any mistakes are mine alone).

Continue reading

Mimikatz Update Fixes Forged Kerberos Ticket Domain Field Anomaly – Golden Ticket Invalid Domain Field Event Detection No Longer Works

In late 2014, I discovered that the domain field in many events in the Windows security event log are not properly populated when forged Kerberos tickets are used. The key indicator is that the domain field is blank or contains the FQDN instead of the short (netbios) name and depending on the tool used to generate the Kerberos tickets, other domain field anomalies may be present in the events.
The likely reason for the anomalies is that third party tools that create Kerberos tickets (TGT & TGS) don’t format the tickets exactly the same way as Windows does.

Around this time last year (early January 2015), I shared with customers these indicators for detecting forged Kerberos tickets and subsequently presented this information at BSides Charm 2015. Soon after, Mimikatz was updated with a domain field that was set to static values, usually containing the string “eo.oe”.

As of 4/16/2015: Mimikatz generated tickets may include the string “ : ) ” in the domain field.
As of 6/29/2015: Mimikatz generated tickets may include the string “<3 eo.oe – ANSSI E>” in the domain field.

Few things in life are as consistent as the guarantee that things will change. In infosec, that means the attack tools will continue to evolve to evade detection and the defensive tools need to constantly evolve and improve.

If you protect your Active Directory admins (and service accounts), you will likely not have to deal with forged Kerberos Tickets since they require prior admin access. The problem is that Active Directory & Enterprises are often not secured to protect against modern threats and often, gaining Domain Admin rights to an AD domain is often too easy in many enterprises.

Continue reading

How Attackers Dump Active Directory Database Credentials

I previously posted some information on dumping AD database credentials before in a couple of posts: “How Attackers Pull the Active Directory Database (NTDS.dit) from a Domain Controller” and “Attack Methods for Gaining Domain Admin Rights in Active Directory“.

This post covers many different ways that an attacker can dump credentials from Active Directory, both locally on the DC and remotely. Some of this information I spoke about at several security conferences in 2015 (BSides, Shakacon, Black Hat, DEF CON, & DerbyCon).

The primary techniques for dumping credentials from Active Directory involve interacting with LSASS on a live DC, grabbing a copy of the AD datafile (ntds.dit), or tricking a Domain Controller into replicating password data to the attacker (“I’m a Domain Controller!”).
The methods covered here require elevated rights since they involve connecting to the Domain Controller to dump credentials.
They are:

Note that if a copy of the Active Directory database (ntds.dit) is discovered, the attacker could dump credentials from it without elevated rights.
The last topic on this page shows how to extract credentials from a captured ntds.dit file (with regsitry export).

Remote Code Execution Options

There are several different ways to execute commands remotely on a Domain Controller, assuming they are executed with the appropriate rights. The most reliable remote execution methods involve either PowerShell (leverages WinRM) or WMI.

  • WMI
    Wmic /node:COMPUTER/user:DOMAIN\USER /password:PASSWORD process call create “COMMAND“
  • PowerShell (WMI)
    Invoke-WMIMethod -Class Win32_Process -Name Create –ArgumentList $COMMAND –ComputerName $COMPUTER -Credential $CRED
  • WinRM
  • PowerShell Remoting
    Invoke-Command –computername $COMPUTER -command { $COMMAND}
    New-PSSession -Name PSCOMPUTER –ComputerName $COMPUTER; Enter-PSSession -Name PSCOMPUTER

Continue reading

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

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

Will @harmj0y Schroeder ( 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

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).


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

Unofficial Guide to Mimikatz & Command Reference

A new page on 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


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