SHARE
DarkHaven Technologies - Range (Medium) - by Ryan Yager
The following post by 0xb0b is licensed under CC BY 4.0
Entry Point
Continue here if you were able to gain access as showard on SQL.EXT.DARKHAVEN.LOCAL.
Reference:
Recon
We use rustscan -b 500 -a share.ext.darkhaven.local --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.
SMB services 139/445 are exposed with message signing enabled but not enforced. Multiple MSRPC endpoints 49666+ are also open. Remote access is also available via RDP 3389 and WinRM 5985.
Access as showard
We recall the data we obtained from compromising the SQL host.
We were able to extract a KeePass file from the SQL host, including the README file that contained the master key. From this, we extracted a list of usernames and passwords and performed a password spray using NetExec.
Using the Password Spray, we were able to confirm that we had access as sql_svc, svc_backup, and showerd.
We're trying to list the shares using these user accounts, and we've found what we're looking for using Showard's credentials. In addition to the default shares, we also have two additional shares with read access: DarkhavenData and DarkheavenData.
Access as svc_netops
We connect to the shares using impackets smbclient. From there, we extract all the files we find.
We find some interesting files. Among them is it_security_wordlist.txt, which is maintained by the IT department. It contains common patterns and passwords from previous audits. A real treasure trove.
We also find the Core_Switch_Backup_Procedure.txt file. It contains a description of the manual and automatic procedures for creating the core switch backups. It was authored by the user kwarrren, and the backups are saved to C:\DarkhavenData\IT\Systems\Backups, the share we were in earlier. In the automated process, this is performed by the svc_netops service account.
In Network_Infrastructure_Runbook_v3.txt, we find the credentials for the network provisioning service account.
According to the description the user is a local administrator on the share server.
We test the credentials found using NetExec.
We couldn't find the user svc_netops in our BloodHound data. From the runbook file, we know the user is a local administrator. Therefore, we attempt authentication using --local-auth, since authentication without it will fail for local accounts. We are able to authenticate.
Next, we try to establish a RDP session...
... and are also here successful.
Spawing a normal shell won't give us all permissions.
So, we spawn cmd shell in administrator context
From there we are able to identify the flag on SHARE.EXT.DARKHAVEN.LOCAL at C:\Users\Administrator\Dekstop\root.txt.
Post Compromise
Recalling the backup procedures we previously identified, we know that there is a manual process where users connect to a network share. This presents an opportunity to capture authentication attempts.
Since we have RDP access as svc_webpool, we can try tp leverage this foothold to intercept NTLM hashes from users who may access the share, especially if a backup service or other users are actively interacting with it.
To achieve this, we can use Inveigh, a Windows-based tool similar to Responder, designed for capturing NTLM authentication attempts on internal networks.
Access as svc_webpool
We will use Inveigh.
On the first attempts the general versions get detected by Microsoft Defender. Other versions like the following one from the release section does not get detected. Alternatively the PowerShell Version of Inveigh could be used if AMSI got bypassed beforehand.
We setup a web server and download Inveigh to the target machine.
Next we just run it. And see a negotiation being detected. In some cases the hash does not get printed to the console...
..., but we can find the hash inside the file located in the same folder as the binary placed.
Heres another exampe with the hash printed to the console. We were able to retrieve the NTLMv2 hash of svc_webpool.
We fail trying to crack the hash using rockyou.txt.
Recalling the wordlist we found earlier it_security_wordlist.txt we give it another shot, and are successful.
We try to authenticate as svc_webpool and are succeful.
And we see, the user is local administrator on the WEB.EXT.DARKHAVEN.LOCAL machine.
From here, we can head back to WEB.EXT.DARKHAVEN.LOCAL.
Last updated