Past
Challenge Lab (Medium) - by Ryan Yager
The following post by 0xb0b is licensed under CC BY 4.0
Scenario
Objective
You have been hired by Hack Smarter to perform a Penetration Test on Past Systems Inc. During your call with the client, they stated they are currently adding new machines to the network.
Initial Access
The client has provided you with VPN access to their internal network, but no credentials.
Summary
Summary
In Past, we begin with external enumeration and discover a Windows Server 2016 Domain Controller at 10.1.100.155 running the PAST.LOCAL domain. Guest authentication against SMB succeeds, revealing a readable Share and IPC$, the latter allowing RID brute-forcing. Connecting to the share, we retrieve AD_machines.txt, which lists several machines in the domain including APPDEV01, WEBDEV01, and DEV01.
With no credentials yet, we work through unauthenticated attack techniques and find success with Timeroasting, abusing Microsoft's NTP extension to extract SNTP hashes for computer accounts without authentication. Cracking the recovered hashes offline with Hashcat we recover the password for APPDEV01$.
Authenticating as APPDEV01$, we gain access to the SYSVOL share and locate a tyler_init.cmd script inside a scripts folder. The file is an auto-login helper containing cleartext credentials for the user tyler. Direct password authentication for tyler is blocked by an account restriction, so we request a Kerberos TGT instead and authenticate successfully via the ticket cache.
BloodHound enumeration reveals that tyler holds GenericAll over the domain controller machine object, enabling a Resource-Based Constrained Delegation attack. We create a new computer account, configure RBCD to grant it delegation rights over the DC, then request a service ticket impersonating Administrator via getST.py. Authenticating with the resulting ticket, we perform a DCSync to retrieve all domain hashes and use the Administrator hash to open a session via evil-winrm.
On the machine, we inspect the PowerShell history file and recover plaintext credentials for ryan, completing the scenario.
Recon
We use rustscan -b 500 -a 10.1.100.155 --top -- -sC -sV -Pn to enumerate all TCP ports on the target machine, piping the discovered results into Nmap which runs default NSE scripts -sC, service and version detection -sV, and treats the host as online without ICMP echo -Pn.
A batch size of 500 trades speed for stability, the default 1500 balances both, while much larger sizes increase throughput but risk missed responses and instability.
The target 10.1.100.155 is a Domain Controller EC2AMAZ-A5O4OL8.PAST.LOCAL running Windows Server 2016. DNS is exposed on port 53 and Kerberos on port 88, alongside Kerberos password change on port 464. LDAP and LDAPS services are available on ports 389 and 636, with the Global Catalog exposed on ports 3268 and 3269. SMB is exposed via ports 139 and 445 with message signing enabled and required. Remote management and access are available through RDP on port 3389 and WinRM on port 5985. The host also exposes a .NET Message Framing service on port 9389, RPC over HTTP on ports 593 and 49674, and several MSRPC endpoints on ports 135, 49664+, including a non-standard listener on port 61222.
We'll follow the orange-cyberdefense mindmap. Since we do not have any users yet, we try to authenticate as guest or anonymously agains SMB.
We are able to successfully authenticate as guest and immediately find a share called Share that we are authorized to read from. Furthermore we have read access to the IPC$ share, which allows us to perform a rid brute force.
We'll create an entry for our /etc/hosts file...
... and add the following line to our /etc/hosts file.
Next, we connect to the share found earlier using smbclient.py and retrieve the file AD_machines.txt which contains the names of different machines.
Access as APPDEV01$
Since we do not have any credentials yet besides the guest access we try every technique listed from the orange cyber defense mindmap. With the classics like blind kerberoasting, we get nothing. But we have some success with Timeroasting.
Timeroasting is an attack technique that abuses Microsoft's proprietary NTP extension to extract password-equivalent hashes for computer and trust accounts from domain controllers without requiring authentication. These hashes can subsequently be cracked offline.
Domain-joined computers synchronize their system clocks using NTP, with domain controllers acting as authoritative time sources. To address NTP's lack of authentication, Microsoft implemented a custom extension that cryptographically authenticates NTP responses using computer account credentials.
When a computer requests time synchronization, it includes its computer account's RID (Relative Identifier) in the NTP request. The domain controller responds with a Message Authentication Code (MAC) computed using the computer account's NTLM hash as the key. This design allows unauthenticated clients to request salted password hashes for any computer account in the domain by specifying different RID values.
A nice article about Timeroasting can be found here:
Via Timeroasting we are able to retrieve four SNTP hashes that can we try to crack using Hashcat mode 31300.
Unfortunately my version installed was too old and did not support the mode.
For convinience I switched to my Windows host wich had hashcat v7.1.2 already present. We are able to crack the hash for the user with the RID 1115.
We perform the aformentioned rid brute force and are able to enumerate some users and their corresponding RIDs.
We identify that we cracked the hash of the account PAST\APPDEV01$ with the RID 1115.
Next, we test the credentials agains SMB using NetExec and successfully authenticate. With that account we have access to the SYSVOL share.
Access as tyler
Inside the SYSVOL share we find a scripts folder containing a tyler_init.cmd file.
It appears to be a auto-login helper script that contains the cleartext credentials of the user tyler.
Next, we test the crdentials against SMB using NetExec and see that there is an account restriction in place. We might not be able to authenticate via password.
We faced a similar issue in on the CA machine in DarkHaven Technologies:
To work around this, Kerberos authentication can be used instead. By requesting a Ticket Granting Ticket (TGT), we authenticate via Kerberos, which does not enforce the same logon restrictions.
Request a Kerberos TGT for tylers account:
Set the Kerberos ticket cache environment variable:
Next, we authenticate to SMB using Kerberos and we succesfully logged in.
BloodHound Enumeration
Since we have now a machine account and a user we start to enumerate the target using BloodHound.
We can either do that by using the tyler's account via kerberos authentication...
... or with the credentials of the APPDEV01$ machine account.
We identify the Administrator account as the Domain Admin.
From the outbound object control we can see that the user tyler has GenericAll permissions over the DC machine. This allows us to perform a Resource-Based Constrained Delegation attack: add a computer, configure delegation, and impersonate a privileged user.
Shell as Administrator
Create a new computer account
First we create a new computer account, we could have also used the APPDEV01$ machine.
Add Resource Based Constrained Delegation
Next, we configure Resource-Based Constrained Delegation, granting our machine account ATTACKER_SYSTEM$ the ability to delegate to (and thus impersonate users on) the domain controller EC2AMAZ-A5O4OL8$
Next we unset our KRB5CCNAME variable and request a service ticket for the cifs/EC2AMAZ-A5O4OL8.past.local SPN while impersonating the Administrator's account, leveraging the delegation rights of our controlled machine account ATTACKER_SYSTEM$ to obtain a usable ticket as the domain admin.
We then export the resulting ccache file to the KRB5CCNAME environment variable so our tools use it for Kerberos authentication, and run NetExec against the domain over SMB with -k --use-kcache to authenticate as Administrator using the cached ticket and enumerate the available shares. We authenticate sucessfully as the Administrator.
Next, we perform a DCSync to retrieve the hashes of all users of the domain.
Now, we can use the hash of the Administrators account to get a session via evil-winrm.
Access as ryan
On the machine we find the PowerShell history file containing the credentials of Ryan.
We test those using NetExec and successfully authenticate and are able to answer the second question of the scenario.
Last updated