SummitCTF 2024
Tier: Beginner
Last updated
Tier: Beginner
Last updated
SummitCTF is an annual Capture the Flag (CTF) competition hosted by the Cybersecurity Club at Virginia Tech (CyberVT). This year the competition had two competition tiers: One for experienced students and one for beginners. The main difference between the two tiers is that the lab network for experienced players had Windows Defender active and blue teamers roaming around.
The Jeopardy Style CTF was setup to include categories such as Cryptography, Forensics, Reverse Engineering, Web etc. There were also KOTH(King of the Hill) challenges setup towards the end of the competition, which was pretty fun to do as well.
The social engineering challenge this year was called "Let's Get Physical" worth 600 points. The objective was to get physical access to a computer at registration and read a flag on the computer without the CTF admin noticing. Our team of 3 was unable to attempt this challenge successfully. But from what i heard, the CTF admin was very suspicious after someone ran off with the computer 🤣.
Most of the teams were able to successfully social engineer their way to the flag, while others waited for the CTF admin to go to the restroom and took a picture.
This year an external web server was set up to imitate a real external penetration testing engagement where an initial foothold is gained externally to move into the internal network. Once a team was able to read the flag on the back end of the web server, the competition organizers enabled the machines in the internal active directory environment, where teams could connect using openvpn files provided by the competition organizers.
I was unable to get the foothold, i was close, i was able to identify that some sort of command injection existed, but i was not able to get the right payload to retrieve the flag needed to advance into the internal network.
Here is how far i got.
We were given a public ip http://<IP> to the target, and the first thing that i was met with was a login page, i first registered for an account and i also inspected the source code and found a comment:
This portion of the source code for the web app definitely does look interesting, specifically the exec(cmd) portion where a command injection may be possible via the URL:
This reveals some interesting directories already revealed in the source code leakage, at this point i wanted to analyze the /share endpoint even further because of the exec(cmd) portion of the source code.
After logging in with the account i registered, a user was able to make posts, view posts, and share posts on the main page's dashboard. After doing a few of these things myself i noticed:
So i tried:
This returned a python error, which means i was able to inject something, but it just wasn't in the right format unfortunately. At this point i went off in a tangent in trying to find a sql injection via a post functionality when i should have further investigated the error 😂
Looking back after completing the CBBH path on HTB, this would have been much easier now 😭
Our team was firstly unable to attempt the lab environment because we were unable to get the foothold on the external site. But there was also a resource limitation at the time, so even if we did, we wouldn't be able to connect. But it was announced after the CTF that everyone would get a shot at trying to compromise the domain. Here is my attempt and how far i was able to get:
Scope: 172.31.16.1/20
Given the scope we started off by identifying live hosts in the network using fping and nmap. Also note that this was after the competition, meaning we can treat this as a CTF and be as loud as we want, but on a real pentest this may not be the stealthiest way to identify live hosts. In a real pentest we could have identified the hosts using more passive methods like wireshark and responder in analyze mode.
We can copy and paste the output into a text file "hosts.txt", then we can use this file in a nmap scan to get a general idea about what ports are open on each host and save it in all formats.
From this output it looks like 172.31.17.2 is the domain controller because port tcp/389 ldap is open, and all other hosts could be workstations. Let's take a look at 172.31.17.3 first which has a ftp service running on it.
Given our first nmap scan where we identified the open ports on each host, let's do a targeted port and service scan on this machine to see what we are dealing with.
Here we identify some pretty important information such as:
Computer Name: Workstation01
DNS Computer Name: Workstation01.summit.corp
Domain Name: summit.corp
ftp-anon login is allowed and has the SummitCorpPasswordReset.exe executable
Let's go ahead and login and download the executable:
Some of the first things i do when reverse engineering is using file and strings to see if i can get an idea of what this executable is and what it's usage is.
Using strings gives a possible user in the internal network, this also reveals the user schema as first.last. Which could be useful when trying to identify users. I also tried analyzing the executable in ghidra, i think the password is somehow encrypted/encoded somewhere, but i never got to it.
Knowing that smb is also open i tested for a smb null session. In this case it was not possible to authenticate via a smb null session. If it was possible we could have enumerated users,shares, or the password policy using tools like smbclient, rpcclient, and crackmapexec, or even netexec.
Now we could try to identify possible users using kerbrute and a wordlist of users, in this case rockyou.txt was mangled to match first.last. You could download the kerbrute amd64 binary here at https://github.com/ropnop/kerbrute/releases/tag/v1.0.3. We can do this by specifying the domain, domain controller ip, and wordlist of possible users.
We got a user! debera.anabel@summit.corp
Great we got a valid user, but what is their password?
I was able to get debera's password by bruteforcing for smb creds debera.anabel:pyramid9001. In a real pentest, this would not be advised due to account lockout and detection. Instead you could do a targeted and slow bruteforce with a smaller password list and a limit on how often you try passwords.
Now that we got some creds, maybe we can identify kerberoastable users? But unfortunately, we did not find any.
We got creds, even though they may not work using psexec.py in this case, we must remember that there are other services that may use this password. Let's try evil-winrm.
Now that we are authenticated as debera we can first check what privs our user has, and it turns out debera has the SeImpersonatePrivilege enabled which determines which programs are allowed to impersonate a user or other specified accounts and perform actions on behalf of the user, in this case we want to perform actions on behalf of the nt authority\system user.
Perfect, this can be exploited in a number of ways. Here i will be using PrintSpoofer64.exe executable found here, https://github.com/itm4n/PrintSpoofer
After downloading the PrintSpoofer64.exe we can upload it to the machine via evil-winrm's upload command.
We will also need nc.exe to create a reverse shell to our ngrok C2.
Now, according to the PrintSpoofer github README we can create a reverse shell. Here we want to execute PrintSpoofer64.exe and create a reverse shell connection which will be caught on a listener we setup.
This blog post really helped in the setup of the ngrok c2, https://drxh3kr.medium.com/using-netcat-with-ngrok-ip-for-receiving-reverse-shell-25ba7a498aab
After creating an account and adding my auth token to my config file, i could now setup my ngrok IP to serve as a c2 to catch the reverse shell.
Running the command above starts a tcp tunnel. Note any traffic going to our public ip on port 10473 will be redirected to our local host on 443, so when setting up our listener we should specify port 443.
We can run the following to figure out our public ip which we will specify when creating the reverse connection.
Now that we have the public ip 3.132.159.158 and the port 10473, we can setup a listener. Recall that any traffic going to our public ip on port 10473 will be redirected to our local host on 443, so when setting up our listener we should specify port 443.
Now that we have escalated privileges we can dump lsass to try and get any NTLM hashes or cleartext passwords of any other users.
We can do this using mimikatz.exe found here https://github.com/ParrotSec/mimikatz/tree/master/x64
Like we did with PrintSpoofer64.exe and nc.exe we can upload it via our low priv user evil-winrm session.
Once uploaded, i switched to the tmux pane where i caught the privileged reverse shell and ran mimikatz to dump lsass.
From here we got some pretty interesting credentials for another user.
I was given plenty of time to get this far, started at about 12pm-8pm, but this is as far as i got 😂. Given that we found other credentials we could have possibly used them on this machine and the services running on it. Given my initial nmap scan, my next step would have been this:
After scanning the ports and their service versions i would have followed this checklist using brooks.eloise creds:
SMB Credentialed Enumeration?
shares,files with hardcoded credentials,users, password policy etc.
Auth via Evil-Winrm,psexec.py, crackmapexec etc.
internal services?
RDP session w xfreerdp?
interact with internal services?
find config files with hardcoded credentials?
