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

Sep 10 2015

DerbyCon V (2015): Red vs. Blue: Modern Active Directory Attacks & Defense Talk Detail

In a couple of weeks, I will be speaking at DerbyCon about Active Directory attack & defense in my talk Red vs. Blue: Modern Active Directory Attacks & Defense”. This is the 5th iteration of this talk and includes the latest updates to attack methods and defensive strategies. This DerbyCon version is a blend of my Black Hat & DEF CON talks and includes several new updates including new “Sneaky AD Persistence” which covers difficult to detect methods an attacker could retain Domain Admin level access after having admin rights on a Domain Controller for 5 minutes.

On Friday, September 25th, 2015, I have a Track 1 (Break Me) talk from 3:00pm to 3:50pm.

Here’s my talk description:

This talk explores the latest Active Directory attack vectors including useful Red Team recon tactics and provides effective defensive techniques for the Blue Team.
Dive right into the technical detail describing the latest methods for gaining and maintaining administrative access in Active Directory, including some sneaky AD persistence methods. Also covered are traditional security measures that work (and some that don’t) as well as the mitigation strategies that disrupts the attacker’s preferred game-plan.
Some of the topics covered:
– “SPN Scanning” with PowerShell to identify potential targets without network scans (SQL, Exchange, FIM, webservers, etc.).
– Exploiting weak service account passwords as a regular AD user.
– How attackers go from zero to (Domain) Admin.
– MS14-068: the vulnerability, the exploit, and the danger.
– Mimikatz, the attacker’s multi-tool.
– Using Silver Tickets for stealthy persistence.
– Sneaky persistence methods attackers use to maintain admin rights.
– Detecting offensive PowerShell tools like Invoke-Mimikatz.
– Active Directory attack mitigation.

While the primary components of this talk are similar to my Black Hat & DEF CON presentations, key differences/updates are in bold.

DerbyCon talk outline:

  • Advanced Red Team Recon Tactics
  • From PowerSploit to Empire: modern PowerShell attack tools.
  • Red Team Remote Execution Methods
  • SPN Scanning: service discovery without network port scanning
  • Cracking service account passwords as a domain user (with no elevated permissions).
  • Group Policy Preferences – detecting credential theft from GPP
  • Several methods showing how attackers go from domain user to Domain Admin.
  • Mimikatz DC Sync Usage & Detection
  • Converting an NTLM password hash to a Kerberos ticket (no need to Pass-the-Hash).
  • The one vulnerability to rule them all! (AD domains).
  • Sneaky AD Persistence Tricks
  • How my security research made Golden Tickets more powerful.
  • Silver Tickets can be more dangerous than Golden Tickets.
  • Forging Trust Tickets to expand access.
  • Detecting offensive PowerShell tools including Invoke-Mimikatz
  • Mitigating PowerShell attacks.
  • PowerShell v5 security enhancements
  • Active Directory defense and mitigation techniques that work.
DerbyCon Edition – “Red vs. Blue: Modern Active Directory Attacks & Defense” (v5)
  – New Sneaky Active Directory Persistence Methods, Advanced Red Team Recon Tactics, Remote Execution Methods, Mimikatz DC Sync Usage & Detection, & Detecting offensive PowerShell tools including Invoke-Mimikatz
DerbyCon V (September 2015)
DerbyCon V Slides (PDF)
DerbyCon Presentation Video (YouTube)

 

Sep 10 2015

Sneaky Active Directory Persistence #11: Directory Service Restore Mode (DSRM)

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 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 set when DC is promoted and is rarely changed. The primary method to change the DSRM password on a Domain Controller involves running the ntdsutil command line tool.

Beginning with hotfix KB961320 on Windows Server 2008, there is now the option to synchronize the DSRM password on a DC with a specific domain account. Note that this must be performed every time the password is changed; it does not create an automatic sync partnership.

Continue reading

Sep 02 2015

Windows Server 2016 Technical Preview 3 Download & Release Information

Looks like we are getting closer to Windows Server 2016 RTM!

Microsoft released Windows Server 2016 Technical Preview 3 in late August (Download & Release Notes).
Continue reading

Aug 19 2015

Great Active Directory Attack & Defense Resources

I have found the following resources to be excellent when it comes to attacking & defending an enterprise with Microsoft products (Active Directory, Windows, etc). This was created in response to the many questions regarding who to follow (Twitter) or what blogs to read. 🙂

Microsoft Platform Security Resources:

Continue reading

Aug 13 2015

Active Directory Security Risk #101: Kerberos Unconstrained Delegation (or How Compromise of a Single Server Can Compromise the Domain)

At Black Hat USA 2015 this summer (2015), I spoke about the danger in having Kerberos Unconstrained Delegation configured in the environment.

When Active Directory was first released with Windows 2000 Server, Microsoft had to provide a simple mechanism to support scenarios where a user authenticates to a Web Server via Kerberos and needs to update records on a back-end database server on behalf of the user. This is typically referred to as the “Kerberos double-hop issue” and requires delegation in order for the Web Server to impersonate the user when modifying database records.

Visio-KerberosDoubleHop-Visio
Graphic: Kerberos “double-hop issue”

 

Kerberos Unconstrained Delegation:

Microsoft implemented Kerberos “unconstrained delegation” in Windows 2000 that enables this level of delegation. A Domain Admin can enable this delegation level by checking the middle box. The third box is for “constrained delegation” which requires listing of specific Kerberos services on computers to which delegation is enabled.

KerberosUnConstrainedDelegation-Delegation-Config
Graphic: Computer configured with Kerberos Unconstrained Delegation

 

Discovering computers with Kerberos unconstrained delegation is fairly easy using the Active Directory PowerShell module cmdlet, Get-ADComputer.

  • Unconstrained Delegation: TrustedForDelegation = True
  • Constrained Delegation: TrustedToAuthForDelegation = True

KerberosUnConstrainedDelegation-PowerShell-DiscoverServers2
Graphic: PowerShell to find Kerberos Unconstrained Delegation

 

How does Kerberos Unconstrained Delegation really work?

Continue reading

Load more