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.Building Your First Practical Lab (Part 2)
This is the second blog in a 2 part series that will walk you through the entire process of building your first custom practical lab. You’ll learn how to do everything from launching and configuring an EC2 instance in your AWS account to imaging it and seamlessly integrating it into our platform. In part 1 we showed you how to create and import your own machine. You can read part 1 here. In this blog, we’ll walk through building a simple Linux privilege escalation scenario as a working example. Our goal is to give you the foundational steps so you can confidently design scenarios tailored to your own creativity, environment, and organizational needs. The lab objective Ensure you are connected to the machine via the Ubuntu user for the steps below and not our lab user (lab-user). The objective of this lab is to read a token file. To do so, the user will need to escalate privileges via a misconfiguration. We will create a flag.txt file inside /root/ that contains a string that the user must read in the lab. sudo nano /root/flag.txt Add some content inside the file. This will act as a flag that can be used later to complete the lab. w3ll_don3_h4ck3r Save the file The lab challenge Now let’s set up the challenge! The goal is for lab-user to find a way to read the /root/flag.txt which is owned by root and not accessible to the lab-user by default. They will do this by exploiting a world-writable script that is executed as the root user in cron job. Create a directory to hold the script that lab-user can exploit. For this example, it's going to be a simple script that outputs the current time to a file (not very creative). sudo mkdir /opt/date_printer This script will be executed by root, but lab-user will have write permissions to it. The initial content will be benign, but the purpose of this lab is for the lab-user to identify the misconfiguration that allows them to modify it to read the /root/flag.txt file to retrieve the flag. Create a file for the script: nano /opt/date_printer/printer.sh Add the following content: #!/bin/bash echo "Running date_printer: $(date '+%Y-%m-%d %H:%M:%S')" >> /var/log/date.log Save the file. Next, set the misconfigured permissions that allow lab-user to write to the script, enabling privilege escalation. sudo chmod +x /opt/date_printer/printer.sh sudo chown root:root /opt/date_printer/printer.sh sudo chmod 666 /opt/date_printer/printer.sh Additionally, we want to configure the folder to ensure root owns it, but other users on the machine have access to it. sudo chown root:root /opt/date_printer sudo chmod 777 /opt/date_printer Now, let’s add a cron job to run the script we just created. For this scenario, we are going to edit the /etc/crontab file. Cron jobs in this file are generally used for system-wide cron tasks and are readable by anyone. This is good as it adds some breadcrumbs to our lab! If the user reads this file (a common check when looking for privilege escalation on Linux), they will see a script gets run every minute, and it will point them to investigate that script file. Edit the file nano /etc/crontab Add the following line at the end of the file. This line tells cron to execute /opt/date_printer/printer.sh every minute, as the root user * * * * * root /opt/date_printer/printer.sh Save the file. At this point, we have a configured image with a low-privilege lab-user account, which we will use to connect to the lab machine. We also have a cronjob vulnerability that our users attempting the lab have to exploit as the lab-user! For this lab, all the user has to do is find the script that is run by the cronjob and edit it to print the token in the file we added at /root/flag.txt. They could do this by easily updating the /opt/date_printer/printer.sh script to replace the contents with #!/bin/bash cat /root/flag.txt >> /var/log/date.log This one-liner will cat the contents of the /root/flag.txt file to the /var/log/date.log file, which the user can then read to get the token (there are other things we could do here as well, but for the purposes of this lab, let's keep it simple). Imaging and sharing the lab AMI Go back to the EC2 dashboard and find the running instance you just configured. Right-click on the EC2 machine, select Image and templates, and then Create image. Image name: Provide a descriptive name, e.g., “MyFirstCyberLab-AMI” or “Linux-PrivEsc-Lab-AMI”. Image description: Add a brief description, e.g., “Custom lab with lab-user password SSH and cron job privesc scenario.” Leave other settings at their default values. Click Create image. This will now create an AMI from the configured EC2 lab machine. Adding your custom AMI to your lab Navigate to Lab Builder and go to your custom lab via Manage > Create Lab. If you haven’t created one yet, go ahead and do so by selecting Create a new custom lab. On the Lab details page, we can give our lab a name and configure various other settings. For the purposes of this example, we’ll call it Linux CTF Challenge, and we’ll fill out the rest of the information to ensure our users know what the lab is all about. Lab description: This is a Linux CTF machine designed to test your ability in privilege escalation! Estimated Time Required: 30 Minutes Difficulty: 3 Learning outcomes: Understand how to exploit a common Linux misconfiguration What’s involved: Investigate the machine and find the misconfiguration that allows for privilege escalation. Next, we want to fill in the briefing panel. The briefing panel is the learning material that lets our lab users understand a bit about the topic and anything else they need to know to answer the questions. Since this is a CTF, we’ll give them limited information: Linux CTF This is a CTF lab scenario designed to test your ability to exploit a common misconfiguration in Linux that could result in privilege escalation. Your task in this lab is to read a flag located at /root/flag.txt. Good luck! Next, we want to add a Task. Tasks are what the user has to solve to complete the lab. For this example lab, we want to add a question to verify that they’ve read the flag in the /root/flag.txt file. Select Add task, which will bring up a library of task types. From the library, select Question. This will add a question to the lab task list, which we can then edit by selecting Edit. Update the question settings to the following: Question text: What is the flag found in the /root/flag.txt file? Answer: w3ll_don3_h4ck3r The next stage is to import our custom image. Select Systems and then click Add under the Virtual machine—EC2 type. This will add a new machine to your lab. Once the machine has been added, we want to configure it. Selecting Edit at the top right will open the machine's configuration editor. In the blue information box, we provide which region and, most importantly, which AWS account to share your image with so that our platform can use it in a lab. Within your own AWS account where you created your AMI for the lab image, click on the AMI, and at the bottom of the screen, you will see Permissions. Select Edit AMI permissions and Add account ID. This will open a box where you enter the Account ID that is displayed in Lab Builder. Click Share AMI. Now, copy the AMI ID of the machine you just shared and add it to the Lab Builder machine AMI ID section: Set the following configuration for the other sections in this editor: System Name: Your chosen name for the system you’re configuring. For this example, let's call it “Linux Machine”. Instance Type: t3.medium Connection Type: SSH Username: lab-user (or the username you set) Password: lab-user (or the password you set) Once you’ve configured your system, you can easily use it in Lab Builder by selecting Preview System on the system view. Assuming you’ve built everything correctly, you’ll get a shiny preview of your newly configured machine! This is a good time to run through your lab scenario to ensure it's working correctly. And that’s it—congratulations on building your first practical lab! At this point, you can spruce up your lab by adding additional questions or details to the briefing panel and publish your lab to your organization for them to enjoy. This powerful new feature puts the control directly in your hands, allowing you to create incredibly specific and challenging learning environments. These range from simple privilege escalation scenarios like this one to complex, multi-machine attack simulations. We can’t wait to see the innovative labs you'll create. In the meantime, if you need more ideas or support, use our Help Centre docs for Lab Builder.
Hasta La Vista, Passive Defense: Why Blue Teams Need an Offensive Edge
In a world of ever-evolving tactics, techniques, procedures (TTPs) and relentless adversaries, it’s no longer enough for defenders to simply monitor, detect, and respond. You can’t wait for next-gen threats to come to you – you must go on the offensive to stay ahead. I’m not saying you need to send an advanced cyborg back in time to test yesterday’s defenses, but your blue team does need to adopt offensive mindsets and methods to stay ahead today. Now, as Arnold once said, come with me if you want to live. Adapting to a threat-led world Traditional Security Operations Center (SOC) roles were built for known threats and predefined signatures. Attackers don’t play by those rules anymore. Understanding offensive tactics helps defenders anticipate attacker behaviors, prioritize real risks, and reduce alert fatigue. This proactive approach leads to more effective incident response and a threat-informed defense strategy. Defensive teams that understand offensive logic are better at: Anticipating lateral movement Introduction to Detection Engineering includes labs that analyze logs generated during lateral movement and use tools like Process Monitor and Sysmon. APT29: Threat Hunting with Elasticsearch can help you understand attacker tactics and techniques, which is crucial for anticipating lateral movement. Recognizing attacker tradecraft Attacking the Active Directory is a critical skill in any offensive security professional's arsenal, involving setting manipulation and intentional misconfigurations to gain unauthorized access. Exploitation, Weaponization, and Delivery focuses on payload creation, obfuscation techniques, delivery methods, and communication techniques used in cyberattacks, providing hands-on experience with tools like Metasploit. Prioritizing real risk over alert fatigue Threat Hunting covers essential topics like threat research, digital forensics, and malware analysis, which are crucial for understanding and prioritizing alerts. The labs include a variety of tools like Wireshark, Process Monitor, and Volatility to analyze network traffic and investigate incidents, helping users to identify and respond to suspicious activities effectively. If your blue team thinks like a red team, your incident response becomes threat-informed and dynamic. Offensive skills that matter for defenders Not everyone needs to have the skills of a full-time red teamer, but they do need to think critically about attacker behavior to protect critical assets cough cough John Connor We suggest focusing on these areas: Understanding how common tools behave in the wrong hands (C2 frameworks, privilege escalation chains) PoshC2 provides training on command and control frameworks, credential harvesting, system enumeration, and privilege escalation, all of which are crucial for operating under the assumption that a breach has occurred. Scenario-based threat modeling and adversarial emulation Threat Modeling Fundamentals explores threat modeling, attack trees, and tools like Threat Dragon. These labs help teams identify vulnerabilities, understand different methodologies, and implement effective countermeasures. Reconnaissance is important for understanding and employing reconnaissance techniques essential to offensive operations. Exploit walkthroughs to reinforce detection and log analysis, recent campaigns, and the heavy-hitter offensive TTPs. BadSuccessor: Offensive CVE-2025-35433 (Erlang SSH): Offensive CVE-2025-31161 (CrushFTP): Offensive Water Gamayun: (CVE-2025-26633) Campaign Analysis Threat Actors: Salt Typhoon - SNAPPYBEE Campaign Analysis Command and Scripting Interpreter (T1059) Valid Accounts (T1078) Lateral Movement via Remote Services (T1021) You should also think about: Cyber incident simulations with “adversary POVs” For hands-on training, explore our Pen Test CTF labs to build penetration testing and exploitation skills in a capture-the-flag format. Want to take exercising your teams to the next level? Talk to your account team about Cyber Range Exercises. Engaging in offensive security training raises awareness among employees about potential threats and attack vectors. This awareness fosters a security-first culture, encouraging proactive behaviors and vigilance across the organization. Prove and improve: planning for sustainable upskilling The cybersecurity skills gap isn’t just a hiring problem - it’s a strategic opportunity. Building offensive awareness within defensive teams deepens technical expertise, sharpens detection logic, speeds up incident response, and improves threat prioritization. Success doesn’t happen by accident – it requires a plan. If you're John Connor maybe that plan is sending a Terminator back in time to protect your critical PI... but maybe your plan is partnering with Immersive to design a custom security program 😉 Sustainable upskilling starts with three core elements: Baseline where you are today Engage with Immersive Premium Support to conduct an Immersive assessment, or use Demonstrate labs across key tools and capabilities to baseline current skills. You can also reference threat simulation results, or incident retrospectives to identify practical knowledge gaps. From there, define your target skills and security outcomes (e.g. improving lateral movement detection or reducing false positives), then build and execute a plan to get from A to B. Design learning journeys, not one-offs Structure development plans across 6-, 12-, and 18-month checkpoints. We recommend tailoring these to role-specific needs, but in the context of today’s blog, you also should consider use cases like: Have your Tier 1 SOC analysts start by learning scripting and alert triage logic. Challenge senior analysts to complete red team shadowing or participate in a DTF to strengthen threat hunting skills and hypotheses they can use in detection engineering. Prove value through applied learning Build defenders who can think and act with offensive context. Encourage applied projects like: “Hack-your-fist” systems to better understand attacker behavior. Logging analysis with an “assume breach” lens. Injecting adversary POVs into tabletops or indecent retrospectives. The new defender DNA Defensive security is evolving. It’s no longer about who can triage the fastest – it’s about who can think like the threat and adapt in real time. Upskilling your blue team with red principles isn’t about turning defenders into pentesters. Give them the tools they need to defend with intent. Share your thoughts Have you been leveling up your team’s offensive instincts? Is your blue team ready to terminate threats before they take root? Share your story in the comments below! Don’t let your cyber resilience go offline this summer – stay sharp and threat-ready. Get updates on posts like this by following the Human Connection Blog!
Modern Encryption: Demonstrate Your Skills
Hi there, I have completed all questions except for Q.10 which involves the decryption of an RSA-encrypted file. To the best of my knowledge, a private key is required to decrypt this asymmetrically encrypted file, but I only see a public "public.pem" key in the "~/Desktop/Lab-Files" directory. Am I missing something? I have completed all the other questions so I believe all necessary files/tokens should have already been generated. Any help would be much appreciated. Many thanks, Pete
Threat Research: Dependency Confusion Lab
Hello Community, I am almost finished Threat Research: Dependency Confusion Lab, but I am stuck with the last question "What is the token found in /root/token.txt on the target server?". I have followed all instructions, setup listener, up to python reverse shell (setup.py) but at the end, I don't know how to access token.txt file. Any help would be appreciated. Below are the screenshots from terminal listener and terminal where all commands are executed. Thanks so much Octavio
Practical Malware Analysis: Static Analysis question 18
for finding the exact name of the executable file. After dynamically overriding the function as shown in the briefing I cant seem to find any meaningful creation of the filename matching the patter provided in sprintf. I am wondering if I should be overriding a different function? as I cant seem to find any meaningful leads when searching for references or traveling to the next data. I also cant seem to find any leads from searching specifically for local_104 and unaff_EDI references as well.Foundational Static Analysis: API Analysis
Hi all, I'm stuck in this part, where using Ghidra, I have to find where the Windows API GetModuleHandleA is used, in the binary called exercise_two.exe, and once located, find the parameter of this function. Taking a look about GetModuleHandleA, there's no references or calls to API in any part of the code. Also tried to look for references to GetProcAddress or LoadLibrary and nothing. Am doing something wrong? Any idea to find the "parameter" of the function that calls to the API?. Is the only question from this part remaining... Thanks and regards.
