Ctrlk
Page cover
For the complete documentation index, see llms.txt. This page is also available as Markdown.
ChatGPT

HTB APT

10.10.10.213 | 50 pts

PART 1 : INITIAL RECON

1.1 NMAP scan

$ nmap --min-rate 3000 -oN nmap-tcp.initial -p- -Pn -T4 -v 10.10.10.213

  Host is up.
  All 65535 scanned ports on 10.10.10.213 are filtered

  Read data files from: /usr/bin/../share/nmap
  Nmap done: 1 IP address (1 host up) scanned in 65.54 seconds

No open port was found but scanning using IPv6 might yield a different result. But first, the IPv6 of the machine needs to be determined. It could be done using IOXIDResolver :

$ git clone https://github.com/mubix/IOXIDResolver.git

$ python3 IOXIDResolver/IOXIDResolver.py -t 10.10.10.213

  [*] Retrieving network interface of 10.10.10.213
  Address: apt
  Address: 10.10.10.213
  Address: dead:beef::b885:d62a:d679:573f
  Address: dead:beef::cda5:800b:148e:6594

Adding the recovered IPv6 addresses to the /etc/hosts file then attempting to scan using the new hostname:

Open ports have now been determined and it seems like the machine is part of an Active Directory.

1.2 Updating /etc/hosts

This might be essential when enumerating/connecting to the machine.

PART 2 : PORT ENUMERATION

2.1 TCP PORT 80 (HTTP)

2.2 TCP PORT 445 (SMB)

Enumerating available shares from anonymous login:

There is a backup.zip file publicly available in the backup share.

The backup.zip file was successfully downloaded from the file share but trying to extract the contents requires a password. Luckily, the password was susceptible to a dictionary attack which returned the password as iloveyousomuch. Successfully extracting the contents reveals the following files:

There’s an ntds.dit file which is a database file storing Active Directory data especially user objects and password hashes; however, it’s encrypted. Along with this are Windows Registry files.

PART 3: EXPLOITATION

3.1 Search for valid users

The extraction is only possible since the password encryption key used for ntds.dit is encrypted using the BOOTKEY which could be found on the SYSTEM registry hive. Otherwise, if the SYSTEM hive is not available, the bootkey could be provided as an argument to secretsdump module of impacket.

The usernames were trimmed from the password hashes recovered in ntds.dit via impacket-secretsdump. The usernames were then passed through kerbrute to check if they were still valid/active users in the domain controller. As for that, three users were found — Administrator, APT$, and henry.vinson.

3.2 Generating a Kerberos Ticket for henry.vinson

The hashes found for the valid users doesn’t seem to work when attempting to login via winrm. Since this box seems to be part of an Active Directory, maybe forging a kerberos ticket will work for authenticating into the machine.

The shell script below was the one-liner used to brute force the generation of the ticket:

A password spray (in this case, hashes extracted from ntds.dit were used) was attempted for the user, henry.vinson, and one of the hashes (not his own) was found to be able to forge a krbtgt ticket. However, this still does not seem to work for authentication via WinRM.

3.3 Dumping HKEY_USERS

The HKU registry hive contains all configurations set for all active users.

In this case, since there is already a cached ticket for henry.vinson, all contents from his user registry hive will be extracted.

And within the extracted information are stored credentials for the deployed service, GiganticHostingManagementSystem.

PART 4 : USER SHELL (henry.vinson_adm)

It seems like the reason why the other users cannot authenticate via WinRM even though a valid hash has been found is that they are not part of the Remote Management Users group:

PART 5 : PRIVILEGE ESCALATION (henry.vinson_adm → Administrator)

5.1 The console history of henry.vinson_adm

Checking the console history of the current user:

The DWORD value for lmcompatibilitylevel was set to 2 and based on the Microsoft documentation for LAN Manager authentication level:

DWORD
Setting
Description

2

Send NTLM response only

Client devices use NTLMv1 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

With this the machine should only repond with NTLMv1 hashes during authentication.

5.2 Intercepting NTLMv1 Hashes

Setting up responder with a custom challenge, "1122334455667788"

Then forcing the target machine to force NTLM authentication:

Looking back in the running responder, the NTLMv1 hash for the computer account was retrieved:

Going to crack.sh and submitting the value, NTHASH:95ACA8C7248774CB427E1AE5B8D5CE6830A49B5BB858D384, will return the following if the hash was successfully cracked:

5.3 impacket-secretsdump

5.4 Shell as Administrator

REFERENCES

PreviousHTB AttendedNextHTB Unbalanced

Last updated