Dec 06 2014

MS14-068 Kerberos Vulnerability Privilege Escalation POC Posted (PyKEK)

As noted in previous posts on MS14-068, including a detailed description, a Kerberos ticket with an invalid PAC checksum causes an unpatched Domain Controller to accept invalid group membership claims as valid for Active Directory resources. The MS14-068 patch modifies KDC Kerberos signature validation processing on the Domain Controller.

This issue is FAR worse than the Kerberos “Golden Ticket” issue since an attacker doesn’t need the domain Kerberos service account (KRBTGT) NTLM password hash (only accessible from a Domain Controller with domain-level admin privileges) for exploit. The attacker simply modifies the existing TGT by changing the group membership to have access to everything in Active Directory and creates a specific invalid checksum for the PAC signature causing the DC to validate it.

If you haven’t installed the MS14-068 patch (released on November 18th, 2014), the exploit code is now available for all to use. Microsoft KB3011780 patches this issue.
 Patch your Domain Controllers Now!

MS14-068 References:

UPDATE: I have successfully tested this MS14-068 exploit in my lab and posted detailed information on how to exploit Kerberos on vulnerable Domain Controllers including WireShark pcaps and DC event logs.

Sylvain Monné tweeted about his Python code (Python Kerberos Exploitation Kit aka PyKEK) late Thursday, December 4th, stating it can be used to exploit the Kerberos vulnerability patched in MS14-068.

MS14068-POC-TweetNote that the POC is effective against Domain Controllers running Windows Server 2008 R2 and earlier. Microsoft noted in the patch release that “Windows Server 2012 impact is less vulnerable than previous Windows versions (i.e., it’s much harder to exploit on Windows Server 2012/2012R2)”

The POC is now in MetaSploit.

POC usage example:

ms14-068.py -u <userName>@<domainName> -s <userSid> -d <domainControlerAddr>

  [+] Building AS-REQ for dc-a-2003.dom-a.loc... Done!
  [+] Sending AS-REQ to dc-a-2003.dom-a.loc... Done!
  [+] Receiving AS-REP from dc-a-2003.dom-a.loc... Done!
  [+] Parsing AS-REP from dc-a-2003.dom-a.loc... Done!
  [+] Building TGS-REQ for dc-a-2003.dom-a.loc... Done!
  [+] Sending TGS-REQ to dc-a-2003.dom-a.loc... Done!
  [+] Receiving TGS-REP from dc-a-2003.dom-a.loc... Done!
  [+] Parsing TGS-REP from dc-a-2003.dom-a.loc... Done!
  [+] Creating ccache file 'TGT_user-a-1@dom-a.loc.ccache'... Done!

According to the PyKEK documentation, the modified TGT now has the following groups included:

  • Domain Users (513)
  • Domain Admins (512)
  • Schema Admins (518)
  • Enterprise Admins (519)
  • Group Policy Creator Owners (520)

Since the TGT is signed by the KDC Service (KRBTGT domain account), it is valid and can be used to access Active Directory resources based on the group membership (which was forged and now validated by the DC).

At this point, one can use Mimikatz to use the new TGT to connect to resources.

Two commands are all that’s necessary to exploit:

python.exe ms14-068.py -u user-a-1@dom-a.loc -s S-1-5-21-557603841-771695929-1514560438-1103 -d dc-a-2003.dom-a.loc
mimikatz.exe "kerberos::ptc TGT_user-a-1@dom-a.loc.ccache" exit`

 

Requirements:

The bar is fairly low in order to exploit MS14-068. Effectively admin rights on a single domain-joined computer is all that’s needed. The other items aren’t that difficult once this access is attained.

  • Admin access to a computer joined to the target domain
  • Access to domain credentials – a domain user account is fine.
  • Python exe’s on the computer.
  • Mimikatz on the computer

 

References:

 

 

 

 

Dec 05 2014

Windows Computer Primary Group IDs

Primary Group IDs are the RIDs for the Domain groups. The full list is here: Interesting Windows Computer & Active Directory Well-Known Security Identifiers (SIDs).

  • 515 – Domain Computers
  • 516 – Domain Controllers (writable)
  • 521 – Domain Controllers (Read-Only)

This information helps filter computer objects to return only the desired computer type.

Domain Computers (Workstation & Servers – No Domain Controllers)

Import-Module ActiveDirectory
Get-ADComputer -Filter {PrimaryGroupID -eq 515}

Domain Controllers (All)

Import-Module ActiveDirectory
Get-ADComputer -Filter {PrimaryGroupID -ne 516}

Domain Controllers (RODCs only)

Import-Module ActiveDirectory
Get-ADComputer -Filter {PrimaryGroupID -eq 521}

 

Nov 25 2014

BlueHat Security Briefings: Fall 2014 Sesions

Microsoft has posted videos and slides from the Microsoft internal “BlueHat” security conference from October 2014.

BlueHat Security Briefings educate Microsoft engineers and executives on current and emerging security threats as part of continuing efforts to help protect our customers and secure our products, devices, and services. BlueHat serves as a great opportunity for invited security researchers to informally connect with Microsoft engineers who are passionate about security, furthering a bidirectional exchange of ideas at the event.

The Following Session videos and slides are posted:

BlueHat 2014 Keynote – Chris Betz

Defining and Enforcing Intent Semantics at ABI level
(Sergey Bratus, Julian Bangert)
Dominant OS security policy designs treat a process as an opaque entity that has a “bag” of permissions to access some OS resources at any time, in any order. Now that the sensitive data that we most want to protect may never touch the filesystem or even cross a process boundary, these designs fail at their purpose. We introduce a design that has a much higher granularity of protection, yet is compatible with existing ABI, standard build chains, and binary utilities.

UEFI – Summary of Attacks against BIOS and Secure Boot
(Yuriy Bulygin)
A variety of attacks targeting platform firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, UEFI secure boot and Full Disk Encryption solutions. This talk will detail and organize some of the attacks and how they work. We will cover attacks against BIOS write protection, attacks leveraging hardware configuration against SMM memory protections, attacks using vulnerabilities in SMI handlers, attacks against BIOS update implementations, attacks bypassing secure boot, and various other issues. We will describe underlying vulnerabilities and how to assess systems for these issues. After watching, you should understand how these attacks work, how they are mitigated, and how to verify if your system has any of these problems.

Botintime – Phoenix: DGA-based Botnet Tracking and Intelligence
(Stefano Zanero)
Its common knowledge that a malicious domain automatically generated will not become popular and also an attacker will register a domain with a Top Level Domain that does not require clearance. Hence, we use phoenix which filters out domains likely to be generated by humans. The core of Phoenix is its ability to separate DGA from non-DGA domains, using linguistic features.

View the BlueHat 2014 Videos and Slides

Nov 24 2014

Microsoft Consolidated Technology Conference: Microsoft Ignite

Microsoft announced over the Summer they are merging the individual technology conferences such as the SharePoint Conference, Exchange Conference, and TechEd into a single unified technology conference.

Details are finally available for the Microsoft Ignite Conference which promises to be the conference to attend if you are interested in Microsoft technology solutions.

Who is Ignite for?

It’s for big thinkers looking for an edge. It’s for senior decision makers seeking what’s next, and who want insights on key technology trends in the industry. It’s for IT professionals who need hands-on experience to enhance their tech skills. It’s for enterprise developers and architects looking for innovative ways to maximize application development. It’s for those who want to feel inspired and enlightened. It’s for you.

Registration is now open!

Microsoft Ignite Conference
Chicago, IL
May 4 – 8, 2015

 

 

Nov 22 2014

Mimikatz and Active Directory Kerberos Attacks

NOTE:
While this page will remain, the majority of the Mimikatz information in this page is now in the “Unofficial Mimikatz Guide & Command Reference” which will be updated on a regular basis.

Mimikatz is the latest, and one of the best, tool to gather credential data from Windows systems. In fact I consider Mimikatz to be the “swiss army knife” of Windows credentials – that one tool that can do everything. Since the author of Mimikatz, Benjamin Delpy, is French most of the resources describing Mimikatz usage is in French, at least on his blog. The Mimikatz GitHub repository is in English and includes useful information on command usage.

Mimikatz is a Windows x32/x64 program coded in C by Benjamin Delpy (@gentilkiwi) in 2007 to learn more about Windows credentials (and as a Proof of Concept). There are two optional components that provide additional features, mimidrv (driver to interact with the Windows kernal) and mimilib (AppLocker bypass, Auth package/SSP, password filter, and sekurlsa for WinDBG). Mimikatz requires administrator or SYSTEM and often debug rights in order to perform certain actions and interact with the LSASS process (depending on the action requested).

After a user logs on, a variety of credentials are generated and stored in the Local Security Authority Subsystem Service, LSASS, process in memory. This is meant to facilitate single sign-on (SSO) ensuring a user isn’t prompted each time resource access is requested. The credential data may include NTLM password hashes, LM password hashes (if the password is <15 characters), and even clear-text passwords (to support WDigest and SSP authentication among others. While you can prevent a Windows computer from creating the LM hash in the local computer SAM database (and the AD database), though this doesn’t prevent the system from generating the LM hash in memory.

The majority of Mimikatz functionality is available in PowerSploit (PowerShell Post-Exploitation Framework) through the “Invoke-Mimikatz” PowerShell script which “leverages Mimikatz 2.0 and Invoke-ReflectivePEInjection to reflectively load Mimikatz completely in memory. This allows you to do things such as dump credentials without ever writing the mimikatz binary to disk.”  Mimikatz functionality supported by Invoke-Mimikatz is noted below.
Continue reading

Nov 21 2014

MS14-068: Active Directory Kerberos Vulnerability Patch for Invalid Checksum

MS14-068 References:

 

The folks at BeyondTrust have a great write-up on what the MS14-068 patch adds to mitigate the Kerberos ticket PAC validation vulnerability.
Continue reading

Nov 19 2014

Kerberos Vulnerability in MS14-068 (KB3011780) Explained

Thanks to Gavin Millard (@gmillard on Twitter), we have a graphic that covers the issue quite nicely (wish I had of thought of it!)
Kerb-MS14-068-twitterpic-BoardingPass-Pilot

Exploit Code is now on the net!
As of December 4th, 2014, there is Proof of Concept (POC) code posted that exploits MS14-068 by Sylvain Monné by using Python to interact with an unpatched DC generating the invalid Kerberos ticket and then Mimikatz to use the ticket.
UPDATE: I have successfully tested the MS14-068 exploit in my lab and posted detailed information including WireShark pcaps and DC event logs.

MS14-068 References:

I wrote up a description of the issue that should help explain MS14-068 (KB3011780) without too much Kerberos technical overhead.

For more detail, please read my earlier blog post on MS14-068 (KB3011780).
Get Domain Controller patch status with this sample PowerShell script: Get-DCPatchStatus (rename file extension to .ps1).

Note that Windows Server 2012 impact is less vulnerable than previous Windows versions (i.e., it’s much harder to exploit on Windows Server 2012/2012R2), but all Domain Controllers should be patched ASAP, starting with DCs running Windows Server 2008R2 and below. Patch servers next and workstations last to support “defense-in-depth.” Additionally, Azure Active Directory doesn’t expose Kerberos over any external interface and is not affected by this vulnerability.

Introduction:

Active Directory leverages the Kerberos protocol for authentication. The vulnerability patches an issue with how the Domain Controller validates group membership in Kerberos tickets (hint: this issues is that the ticket is always validated by the DC if the checksum is set to certain values which are invalid).

According to Microsoft: “When this security bulletin was issued, Microsoft was aware of limited, targeted attacks that attempt to exploit this vulnerability.”

This is FAR worse than the Kerberos “Golden Ticket” issue since an attacker doesn’t need the domain Kerberos service account (KRBTGT) NTLM password hash (only accessible from a Domain Controller with domain-level admin privileges) for exploit. The attacker simply modifies the existing TGT by changing the group membership to have access to everything in Active Directory and creates a specific invalid checksum for the PAC signature causing the DC to validate it.

 

MS14-068 Issue Overview:

Simply stated, the vulnerability enables an attacker to modify an existing, valid, domain user logon token (Kerberos Ticket Granting Ticket, TGT, ticket) by adding the false statement that the user is a member of Domain Admins (or other sensitive group) and the Domain Controller (DC) will validate that (false) claim enabling attacker improper access to any domain (in the AD forest) resource on the network. This is all done without changing the members of existing AD groups.
Continue reading

Nov 18 2014

MS14-068: Vulnerability in (Active Directory) Kerberos Could Allow Elevation of Privilege

Active Directory leverages the Kerberos protocol for authentication. The vulnerability patches an issue with how the Domain Controller validates group membership in Kerberos tickets (hint: the ticket is always validated by the DC if the checksum is set to certain values). Microsoft KB3011780 patches this issue.

According to Microsoft: “When this security bulletin was issued, Microsoft was aware of limited, targeted attacks that attempt to exploit this vulnerability.”

Note that Windows Server 2012 impact is less vulnerable than previous Windows versions (i.e., it’s much harder to exploit on Windows Server 2012/2012R2), but all Domain Controllers should be patched ASAP, starting with DCs running Windows Server 2008R2 and below. Patch servers next and workstations last to support “defense-in-depth.” Additionally, Azure Active Directory doesn’t expose Kerberos over any external interface and is not affected by this vulnerability.

MS14-068 References:

Get Domain Controller patch status with this sample PowerShell script: Get-DCPatchStatus (rename file extension to .ps1)

Exploiting MS14-068:

As of December 4th, 2014, there is Proof of Concept (POC) code posted that exploits MS14-068 by Sylvain Monné by using Python to interact with an unpatched DC generating the invalid Kerberos ticket and then Mimikatz to use the ticket.
UPDATE: I have successfully tested the MS14-068 exploit in my lab and posted detailed information including WireShark pcaps and DC event logs.

Kerberos TGT PAC Invalid PAC Signature Checksum validation Issues in MS14-068:

Benjamin Delpy (author of Mimikatz) describes the actual vulnerability with how the PAC signature is checked during his presentation at Passwords 2014 (2 video from the top). I extracted the relevant slide from this presentation (shown below).
There were issues with PAC signature validation in 2011, so going back and looking at MS11-013 is a good start to dig in and see what the actual issue is with MS14-068’s issue with invalid PAC signature checksum validation.

According to his presentation, Benjamin notes the following:

  • Before the MS11-013 patch, the PAC signature was valid if the checksum size was less than or equal to 20 (checksum <= 20)
  • After the MS11-013 patch, the PAC signature was valid if the checksum size was less than or equal to 20 (checksum <= 20) and the checksum is KEYED.
  • After MS14-068 patch, Microsoft added an additional verification step to ensure the checksum type is KRB_CHECKSUM_HMAC_MD5 (or AES in NT6)

py-Passwords2014Slides-PACsigVuln-MS14068

 

Here’s how Kerberos works (in a nutshell):

Ticket Granting Ticket (aka logon ticket)

1. Joe User logs on with his Active Directory user name and password to a domain-joined computer (usually a workstation). The computer takes the user’s password and runs a one way function (OWF) creating a hash of the password (typically the NTLM hash). Hashing the password is like taking a steak and running it through a meat grinder. The ground beef that is the result can never be reassembled back into the same steak we started with.
This is used to  handle all Kerberos requests for the user (as well as other authentication methods such as NTLM).

2. Kerberos authentication is initiated by sending a timestamp (PREAUTH data) encrypted with the user’s password-based encryption key (password NTLM hash).

3. The user account (JoeUser@adsecurity.org) requests a Kerberos service ticket (TGT) with PREAUTH data (Kerberos Authentication Service Request or AS-REQ).

4. The Domain Controller’s Kerberos service (KDC) receives the authentication request, validates the data, and replies with a TGT (Kerberos AS-REP). The TGT has a Privileged Attribute Certificate (PAC) which contains all the security groups in which the user is a member. The TGT is encrypted and signed by the KDC service account (KRBTGT) and only the domain KRBTGT account can read the data in the TGT.
[The vulnerability exists where the PAC is not correctly validated and the exploit requests a TGT without a PAC]

At this point, the user has a valid TGT which contains the users group membership and is used to prove the user is who they claim to be in further conversations with a Domain Controller (KDC). The TGT is sent to the Domain Controller every time a resource ticket is requested.

Ticket Granting Service ticket (aka resource access ticket)

5. When the user wants to access an AD resource (a file share for example), the user’s TGT from step 4 is presented to a Domain Controller (KDC) as proof of identity with a request for a resource ticket to a specific resource (Service Principal Name). The DC determines if the TGT is valid by checking the TGT’s signature and if valid, generates a resource access ticket (TGS) signed/encrypted with the KRBTGT account and a part encrypted with the Kerberos service account’s session key which the destination service uses to validate the TGS.
Note: The DC doesn’t validate the user has the appropriate access to the service, it only validates the TGT and builds a TGS based on the TGT information.

6. The resource service ticket (TGS) is sent to the user by the Domain Controller and is used for authentication to the resource. At this point, all communication has been between the user’s computer and the Domain Controller (KDC).

7. The user’s computer sends the user’s resource service ticket (TGS) to the service on the resource computer. If the destination service is a file share, the TGS is presented to the CIFS service for access.

8. The destination service (CIFS in this example) validates the TGS by ensuring it can decrypt the TGS component encrypted with the service’s session key. The service may send the TGS to a DC (KDC) to validate the PAC to ensure the user’s group membership presented is accurate. The service reviews the user’s group membership to determine what level of access, if any, the user has to the resource.


PAC Validation described in the blog post Understanding Microsoft Kerberos PAC Validation:

The Privilege Account Certificate (PAC) is an extension element of the authorization-data field contained in the client’s Kerberos ticket. The PAC structure is defined in [MS-PAC] and conveys authorization data provided by domain controllers (DCs) in an Active Directory-enabled domain. It contains information such as security identifiers, group membership, user profile information, and password credentials.

Note: This does not solve the Golden Ticket or Silver Ticket issues since those are technically valid Kerberos tickets.

The Kerberos Golden Ticket is a valid TGT Kerberos ticket since it is encrypted/signed by the domain Kerberos account (KRBTGT). This crafted TGT requires an attacker to have the Active Directory domain’s KRBTGT password hash (typically dumped from a Domain Controller). Mimikatz fully supports generating Golden Tickets.

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 encrypted/signed with the 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). We know from the Golden Ticket attack (described above) that the PAC isn’t validated for TGTs until they are older than 20 minutes. Most services don’t validate the PAC (by sending the TGS 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. Mimikatz fully supports generating Silver Tickets.

Since service tickets are identical in format to TGTs albeit with a different service name, all you need to do is specify a different service name and use the RC4 (NTLM hash) of the account password (either the computer account for default services or the actual account) and you can now issue service tickets for the requested service.  Note:  You can also use the AES keys if you happen to have them instead of the NTLM key and it will still work ;-)

It is worth noting, that services like MSSQL, Sharepoint, etc will only allow you to play with those services.  The computer account will allow access to CIFS, service creation, and a whole host of other activities on the targeted computer.  You can leverage the computer account into a shell with PSEXEC and you will be running as system on that particular computer.  Lateral movement is then a matter of doing whatever you need to do from there :-)

Continue reading

Nov 17 2014

PowerShell: Discover Active Directory Forest Domain Controllers

Recently I needed to find all Domain Controllers in a large Active Directory forest (and see the AD Domain Functional Level for each domain).

Here’s the PowerShell code which leverages the Active Directory PowerShell module cmdlets.

 

import-module ActiveDirectory
$ADForestInfo = Get-ADForest
$ADForestInfoName = $ADForestInfo.Name
$ADForestInfoDomains = $ADForestInfo.Domains
$ADForestInfoForestMode = $ADForestInfo.ForestMode
$AllDCs = $Null
ForEach ($DomainDNS in $ADForestInfoDomains)
{
[string]$DomainDC = (Get-ADDomainController -Domain $DomainDNS -discover -service “ADWS”).HostName
$DomainInfo = Get-ADDomain -server $DomainDC
$DomainInfoDomainMode = $DomainInfo.DomainMode
[array]$AllDomainDCs = Get-ADDomainController -server $DomainDC -filter *
$AllDomainDCsCount = $AllDomainDCs.Count
Write-Output “Discovered $AllDomainDCsCount Domain Controllers in the $DomainDNS Domain (DFL: $DomainInfoDomainMode) ”
[array]$AllDCs += $AllDomainDCs
}
$AllDCsCount = $AllDCs.Count
Write-Output “Discovered $AllDCsCount Domain Controllers in the AD Forest $ADForestInfoName (FFL: $ADForestInfoForestMode) ”
$AllDCs | select domain,name,operatingsystem,OperatingSystemServicePack | sort domain | ft -auto