Aug 02 2015

DEF CON 23 (2015) Red vs Blue: Modern Active Directory Attacks & Defense Talk Detail

This week at DEF CON 23, I will be speaking about Active Directory attack & defense in my talk “Red vs Blue: Modern Active Directory Attacks & Defense”. This is the 4th iteration of this talk and includes the latest updates to attack methods and defensive strategies.This DEF CON version has a new segment I call “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, August 7th, 2015, I have a Track Three talk from 1:00pm to 1:50pm.

Here’s my talk description from the DEF CON website:

Kerberos “Golden Tickets” were unveiled by Alva “Skip” Duckwall & Benjamin Delpy in 2014 during their Black Hat USA presentation. Around this time, Active Directory (AD) admins all over the world felt a great disturbance in the Force. Golden Tickets are the ultimate method for persistent, forever AD admin rights to a network since they are valid Kerberos tickets and can’t be detected, right?

This talk explores the latest Active Directory attack vectors and describes how Golden Ticket usage can be detected. When forged Kerberos tickets are used in AD, there are some interesting artifacts that can be identified. Yes, despite what you may have read on the internet, there are ways to detect Golden & Silver Ticket usage.

Skip the fluff and 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 ones that don’t) as well as the mitigation strategies that disrupts the attacker’s preferred game-plan. Prepare to go beyond “Pass-the-Hash” and down the rabbit hole.

Some of the topics covered:

  • Sneaky persistence methods attackers use to maintain admin rights.
  • How attackers go from zero to (Domain) Admin
  • MS14-068: the vulnerability, the exploit, and the danger.
  • “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.
  • Mimikatz, the attacker’s multi-tool.
  • Using Silver Tickets for stealthy persistence that won’t be detected (until now).
  • Identifying forged Kerberos tickets (Golden & Silver Tickets) on your network.
  • Detecting offensive PowerShell tools like Invoke-Mimikatz.
  • Active Directory attack mitigation.

Kerberos expertise is not required since the presentation covers how Active Directory leverages Kerberos for authentication identifying the areas useful for attack. Information presented is useful for both Red Team & Blue Team members.

While the primary components of this talk are similar to my Black Hat presentation two days earlier, key differences are in bold.

Continue reading

Jul 26 2015

Black Hat USA 2015 Red vs Blue Active Directory Attack & Defense Talk Detail

Next week at Black Hat USA 2015, I will be speaking about Active Directory attack & defense in my talk “Red vs Blue: Modern Active Directory Attacks Detection and Protection”. This is the 3rd iteration of this talk and includes the latest updates to attack methods and defensive strategies. I’m including lots of updates and now has at least two brand new attack methods and additional defense strategies.

I put this talk together because I saw that the conversation around breaches and compromises focuses on the malware and there seems to be an information gap. This gap exists between what happens after an attacker gains a foothold on a system inside the network (spear-phishing to get malware installed) to when they gain full Domain Admin rights. Approaching the subject from both an attack and defense perspective, I walk through the latest attack methods that the best ways to detect and defend against them. There are ways to mitigate and defend against these attacks which can prevent a full Active Directory compromise.

On Wednesday, August 5th, 2015, I am speaking at the Mandalay Bay room EF from 1:50pm to 2:40pm .

BHUSA2015-RedVsBlue-Schedule

 

 

 

 

 

 

Here’s my talk description from the Black Hat website:

Continue reading

Jul 15 2015

It’s All About Trust – Forging Kerberos Trust Tickets to Spoof Access across Active Directory Trusts

In early 2015, I theorized that it’s possible to forge inter-realm (inter-trust) Kerberos tickets in a similar manner to how intra-domain TGTs (Golden Tickets) and TGSs (Silver Tickets) are forged. Around the same time, Benjamin Delpy updated Mimikatz to dump trust keys from a Domain Controller. Soon after, Mimikatz gained capability to forge inter-realm trust tickets. Benjamin Delpy added “Kekeo” to Github which includes “AskTGS” which provides the capability to request TGS service tickets for targeted services in the destination domain and save them to file. With the tools enabling further research, I was able to explore what is possible with forged cross-trust Kerberos tickets.

Note that forging a Kerberos Trust Ticket is similar to forging a Golden Ticket or a Silver Ticket.

The key to the power of a Kerberos Trust Ticket within a multi-domain Active Directory forest is Enterprise Admins membership which easily crosses domain boundaries providing effective Domain Admin rights in every domain in the AD forest.

I presented on “Trust Tickets” at Shakacon in Hawaii last week. Simply put, Trust Tickets are forged inter-realm Kerberos tickets. When there are two Active Directory domains connected via trust, there is a password which is shared between them used to keep the trust active. This trust password is also used as the shared secret in Kerberos.

I also presented at Black Hat USA 2015 how I enabled Golden Tickets to work across domains in the same forest (aka Enhanced Golden Tickets).

Update 9/2/2015: I updated the screenshots to accurately show how the intra-forest trust is exploited using the current version of Mimikatz.

Continue reading

Jun 24 2015

Microsoft Advanced Threat Analytics (ATA) Overview

Introduction

There are several methods for identifying unusual or anomalous user activity. Traditionally these methods have required certain events be logged to the Windows event logs on workstations, servers, and Domain Controllers (DCs) and these events need to be forwarded to a central collection system. The drawback to this approach is numerous: the data logged may not catch certain “known bad” behavior, the sheer number of events that require logging is numerous, and the log data requires large amounts of storage for processing and recall.

Microsoft announced a new product at the Microsoft Ignite conference in May 2015. Microsoft Advanced Threat Analytics (ATA) provides real-time analysis of user activity and identifies and flags any activity considered anomalous.

Microsoft Advanced Threat Analytics (ATA) is now generally available.
If your organization has Software Assurance with Enterprise CALs, ATA may be included. Contact your Microsoft rep for details.

 

Microsoft Advanced Threat Analytics (ATA)

In 2014, Microsoft purchased a company called Aorato and the technology acquired from this purchase is now a new product Microsoft Advanced Threat Analytics (ATA) which is currently in beta. Microsoft Advanced Threat Analytics is unique among most security products in that it is placed on the network with a feed of traffic destined for Domain Controllers forwarded to ATA Gateways (sensors). The ATA Gateway parses the network traffic involving the Domain Controllers and from this builds a user activity profile for every user in Active Directory, including the computers the user typically logs onto and resources the user accesses. From this activity profile, ATA can identify when user activity falls outside of the baseline.

 

How ATA Works

The Microsoft Advanced Threat Analytics architecture is comprised of two components. The ATA Gateway uses deep packet inspection technology to review user activity data off of the network and forwards relevant data to the ATA Center (about 3% of all network data reviewed). The ATA Center receives the activity data from the ATA Gateway over a secure connection and the ATA Center builds an “Organizational Security Graph” which is a map of entity (users, computers, resources, etc) interactions and represents the context of the related activities. This data effectively includes activity profiles for every user and leverages this to alert on anomalous user behavior. Note that only “known bad” activity is alerted on and only suspicious activity (outliers from normal) are flagged.

Continue reading

May 25 2015

Summer Speaking Engagements

I am thrilled to announce I will be speaking about Active Directory security at the following security conferences:

Each talk will cover current AD attack techniques and the latest defensive methods. Additionally, I will be sharing some exciting new information at each conference!

May 11 2015

Detecting Mimikatz Use

Benjamin Delpy published some YARA rules in detecting Mimikatz use in your environment.
More information on Mimikatz capability is in the “Unofficial Mimikatz Guide & Command Reference” on this site.

YARA is described as:

YARA is a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples. With YARA you can create descriptions of malware families (or whatever you want to describe) based on textual or binary patterns. Each description, a.k.a rule, consists of a set of strings and a boolean expression which determine its logic.
…
YARA is multi-platform, running on Windows, Linux and Mac OS X, and can be used through its command-line interface or from your own Python scripts with the yara-python extension.

Based on the published data, this data enables detection of the Mimikatz exe, dll, and artifacts such as kirbi ticket files, as well as WCE.
Here’s the data:

Continue reading

May 08 2015

Microsoft Ignite 2015 Security Sessions

Microsoft retired several conferences this year (TechEd, MEC, MMC, etc) and merged them into a single mega-conference called Microsoft Ignite 2015. About 23,000 people (~29k including all staff and support personnel) converged on the McCormick Place Conference Center in Chicago, IL during the week of May 4th (May the Fourth be With You!).

I recently posted on the new Windows 10 credential system, Microsoft Passport & Microsoft Hello.

Note: Session content is still being uploaded.

Windows Security Sessions:

How to Protect Your Corporate Resources from Advanced Attacks (Microsoft Advanced Threat Analytics, formerly Aorato)
https://channel9.msdn.com/Events/Ignite/2015/BRK3870
Demi Albuz, Michael Dubinsky, Benny Lakunishok, Idan Plotnik
Slides (view online)

How You Can Hack-Proof Your Clients and Servers in a Day
Hasain Alshakarti, Marcus Murray
https://channel9.msdn.com/Events/Ignite/2015/BRK2346

Hacker Tools for Ethical Hackers to Protect Windows Clients
Raymond Comvalius, Erdal Ozkaya
https://channel9.msdn.com/Events/Ignite/2015/BRK2332
Slides (view online)

Detecting the Undetectable
Roger Grimes
https://channel9.msdn.com/Events/Ignite/2015/BRK2344
Slides (view online)

Continue reading

May 07 2015

Windows 10 Microsoft Passport (aka Microsoft Next Generation Credential) In Detail

At the Microsoft Ignite conference this week, there are several sessions covering Windows 10 features. One of biggest changes in Windows 10 is the new credential management method and the related “Next Generation Credential”, now named Microsoft Passport.

There hasn’t been much information on how the new credential system works, so I challenged myself to gather as much information and understand it as best as possible before the Microsoft Ignite conference ends this week. This post covers my understanding of this (still beta) technology.

Note that the information in this post is subject to change (& my misunderstanding). As I gain clarification, I will update this post.

1/28/2016 Update: Microsoft published a whitepaper on Microsoft Passport and Windows Hello. This post will soon incorporate this information.

Microsoft Passport

Microsoft has resurrected the Passport moniker for a new PKI credential system that requires multi-factor authentication.Most interesting about Microsoft Passport is that it fully supports the Fast IDentity Online (FIDO) Alliance standards which means it will work with many web/cloud services without modification. The plan is that users of cloud services supporting FIDO is that there will no longer be passwords associated with the user’s account.

Microsoft Passport involves a user logging onto the Windows 10 computer with multi-factor (PIN, face, iris, fingerprint, etc) and either creating a new account or associating an existing account with an IDentity Provider (IDP). Windows generates a public/private key pair with the private key stored securely outside of the Windows 10 OS. The public key is associated with the account so that a challenge can be sent that can only correctly respond to the IDP. Another key point to the Microsoft Passport credential system is that the user needs to enroll every device used to access the service (IDP).

Continue reading

May 06 2015

Windows Server 2016 Technical Preview 2 Now Available for Download

Windows Server 2016 Technical Preview 2 Now Available for Download (ISO or VHD):
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

What’s new in Active Directory Domain Services (AD DS) in Windows Server Technical Preview:

Privileged access management

Privileged access management (PAM) helps mitigate security concerns for Active Directory environments that are caused by credential theft techniques such pass-the-hash, spear phishing, and similar types of attacks. It provides a new administrative access solution that is configured by using Microsoft Identity Manager (MIM). PAM introduces:

  • A new bastion Active Directory forest, which is provisioned by MIM. The bastion forest has a special PAM trust with an existing forest. It provides a new Active Directory environment that is known to be free of any malicious activity, and isolation from an existing forest for the use of privileged accounts.
  • New processes in MIM to request administrative privileges, along with new workflows based on the approval of requests.
  • New shadow security principals (groups) that are provisioned in the bastion forest by MIM in response to administrative privilege requests. The shadow security principals have an attribute that references the SID of an administrative group in an existing forest. This allows the shadow group to access resources in an existing forest without changing any access control lists (ACLs).
  • An expiring links feature, which enables time-bound membership in a shadow group. A user can be added to the group for just enough time required to perform an administrative task. The time-bound membership is expressed by a time-to-live (TTL) value that is propagated to a Kerberos ticket lifetime.
    noteNote
    Expiring links are available on all linked attributes. But the member/memberOf linked attribute relationship between a group and a user is the only example where a complete solution such as PAM is preconfigured to use the expiring links feature.
  • KDC enhancements are built in to Active Directory domain controllers to restrict Kerberos ticket lifetime to the lowest possible time-to-live (TTL) value in cases where a user has multiple time-bound memberships in administrative groups. For example, if you are added to a time-bound group A, then when you log on, the Kerberos ticket-granting ticket (TGT) lifetime is equal to the time you have remaining in group A. If you are also a member of another time-bound group B, which has a lower TTL than group A, then the TGT lifetime is equal to the time you have remaining in group B.
  • New monitoring capabilities to help you easily identify who requested access, what access was granted, and what activities were performed.

Requirements

  • Microsoft Identity Manager
  • Active Directory forest functional level of Windows Server 2012 R2 or higher.

Azure AD Join

Azure Active Directory Join enhances identity experiences for enterprise, business and EDU customers- with improved capabilities for corporate and personal devices.

Benefits:

  • Availability of Modern Settings on corp-owned Windows devices. Oxygen Services no longer require a personal Microsoft account: they now run off users’ existing work accounts to ensure compliance. Oxygen Services will work on PCs that are joined to an on-premises Windows domain, and PCs and devices that are “joined” to your Azure AD tenant (“cloud domain”). These settings include:
    • Roaming or personalization, accessibility settings and credentials
    • Backup and Restore
    • Access to the Windows Store with work account
    • Live Tiles and notifications
  • Access organizational resources on mobile devices (phones, phablets) that can’t be joined to a Windows Domain, whether they are corp-owned or BYOD
  • Single-Sign On to Office 365 and other organizational apps, websites and resources.
  • On BYOD devices, add a work account (from an on-premises domain or Azure AD) to a personally-owned device and enjoy SSO to work resources, via apps and on the web, in a way that helps ensure compliance with new capabilities such as Conditional Account Control and Device Health attestation.
  • MDM integration lets you auto-enroll devices to your MDM (Intune or third-party)
  • Set up “kiosk” mode and shared devices for multiple users in your organization
  • Developer experience lets you build apps that cater to both enterprise and personal contexts with a shared programing stack.
  • Imaging option lets you choose between imaging and allowing your users to configure corp-owned devices directly during the first-run experience.

For more information see, Extending Modern Experiences and Single Sign On across Company Apps on Windows with Azure Active Directory Join.

Microsoft Passport

Microsoft Passport is a new key-based authentication approach organizations and consumers, that goes beyond passwords. This form of authentication relies on breach, theft, and phish-resistant credentials.

The user logs on to the device with a biometric or PIN log on information that is linked to a certificate or an asymmetrical key pair. The Identity Providers (IDPs) validate the user by mapping the public key of the user to IDLocker and provides log on information through One Time Password (OTP), Phonefactor or a different notification mechanism.

For more information see, Password-less Authentication with Microsoft Passport

Deprecation of File Replication Service (FRS) and Windows Server 2003 functional levels

Although File Replication Service (FRS) and the Windows Server 2003 functional levels were deprecated in previous versions of Windows Server, it bears repeating that the Windows Server 2003 operating system is no longer supported. As a result, any domain controller that runs Windows Server 2003 should be removed from the domain. The domain and forest functional level should be raised to at least Windows Server 2008 to prevent a domain controller that runs an earlier version of Windows Server from being added to the environment.

At the Windows Server 2008 and higher domain functional levels, Distributed File Service (DFS) Replication is used to replicate SYSVOL folder contents between domain controllers. If you create a new domain at the Windows Server 2008 domain functional level or higher, DFS Replication is automatically used to replicate SYSVOL. If you created the domain at a lower functional level, you will need to migrate from using FRS to DFS replication for SYSVOL. For migration steps, you can either follow the procedures on TechNet or you can refer to the streamlined set of steps on the Storage Team File Cabinet blog.

The Windows Server 2003 domain and forest functional levels continue to be supported, but organizations should raise the functional level to Windows Server 2008 (or higher if possible) to ensure SYSVOL replication compatibility and support in the future. In addition, there are many other benefits and features available at the higher functional levels higher. See the following resources for more information:

Continue reading

May 03 2015

Detecting Forged Kerberos Ticket (Golden Ticket & Silver Ticket) Use in Active Directory

Over the last 6 months, I have been researching forged Kerberos tickets, specifically Golden Tickets, Silver Tickets, and TGTs generated by MS14-068 exploit code (a type of Golden Ticket). I generated forged Kerberos tickets using Mimikatz (Mimikatz Command Reference) and MS14-068 exploits and logged the results. Over the course of several weeks, I identified anomalies in the event logs that are clear indication of forged ticket use in an Active Directory environment.

Update1/5/2016:
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 the Mimikatz update dated 1/5/2016, forged Kerberos tickets no longer include a domain anomaly since the netbios domain name is placed in the domain component of the Kerberos ticket.

Mimikatz code diff:
GT-DomainFieldUpdate-20150105

More information on the difficulty of detecting forged Kerberos tickets (Golden Tickets, Silver Tickets, etc) in the in the Detecting Forged Kerberos Tickets section below.

 

Kerberos Overview & Communication Process:

Visio-KerberosComms

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.

6. If mutual authentication is required by the client (think MS15-011: the Group Policy patch from February that added UNC hardening).

Unless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to the DC.

 

Active Directory Kerberos Key Points:

  • Microsoft uses the NTLM password hash for Kerberos RC4 encryption.
  • Kerberos policy is only checked when the TGT is created & the TGT is the user authenticator to the DC.
  • The DC only checks the user account after the TGT is 20 minutes old to verify the account is valid or enabled. TGS PAC Validation only occurs in specific circumstances. When it does, LSASS on the server sends the PAC Validation request to the DC’s netlogon service (using NRPC)
  • If it runs as a service, PAC validation is optional (disabled). If a service runs as System, it performs server signature verification on the PAC (computer account long-term key).

 

Forging Kerberos Tickets:

  • Forging Kerberos tickets depends on the password hash available to the attacker
  • Golden Ticket requires the KRBTGT password hash.
  • Silver ticket requires the Service Account (either the computer account or user account) password hash.
  • Create anywhere and user anywhere on the network, without elevated rights.
  • Spoof access without modifying AD groups.
  • Once the KRBTGT account password is disclosed, the only way to prevent Golden Tickets is to change the KRBTGT password twice, since the current and previous passwords are kept for this account.

 

Golden Tickets:

Continue reading

Load more