Foundational Static Analysis: API Analysis step 10
Step 10 of this lab says to go to the command line and run xelfviewer. In my virtual machine, that is not found. I see a directory for the building of it, but I don't find the binary anywhere to be able to execute it, and I don't have permissions to be able to do the build. Anyone have any suggestions about that?Snort Rules: Ep.9 – Exploit Kits
I am pulling my hair with question number 8 Create a Snort rule to detect the third GET request in the second PCAP file, then submit the token. This one should do it but it is not working. alert tcp any any -> any any (msg:"detect the third GET request"; content:"e31e6edb08bf0ae9fbb32210b24540b6fl"; sid:1000001) I tried so many rules base on the first GET header and still unable to get the token. Any tips?
Help with Introduction to Python Scripting: Ep.7 – Demonstrate Your Skills
Hello all, I am stuck with the last question on this Immersive lab . Below is my question Using Python, build a web scraper to scrape the website for 12-digit phone numbers beginning with + (e.g., +123456789012). The requests and BeautifulSoup4 (BS4) libraries are available to you. How many extracted phone numbers are returned? I created the following python script import requests from bs4 import BeautifulSoup import re url = "http://10.102.35.108:4321" try: response = requests.get(url) response.raise_for_status() # Raise an exception for bad status codes except requests.exceptions.RequestException as e: print(f"Error fetching the page: {e}") exit() soup = BeautifulSoup(response.text, 'html.parser') phone_pattern = r"\+\d{12}" found_numbers = re.findall(phone_pattern, soup.get_text()) num_found = len(found_numbers) print(f"Found {num_found} phone numbers:") for number in found_numbers: print(number) The value is 0, but I am getting an incorrect solution. please help
CSP Hash Incorrect Despite Correct Script and Hash (CSP Lab Issue?)
Hello all! I'm working on Introduction to Content Security Policy (CSP) Lab: Content Security Policy: Hashes exercise that requires generating the correct hash for an inline script like: <script>document.body.style.backgroundColor = "#ADDADE";</script> I’ve used both CyberChef and the SHA-256 JavaScript snippet to generate hashes like: sha256-+BWzTX+GJrse8ifajvHg6QFPdmE+JjXYmrYBn+kLITo= sha256-Msn/9dD1zBN7LGZyQyglKL9JMVyCsVqvZ7MAkmm/BpU= I've accounted for trailing newlines and whitespaces (CRLF, LF), used View Source (not dev tools), and verified that I'm hashing the exact script content. However, the lab continues to mark the answer as “incorrect.” Is this likely a glitch in the lab setup, or is there a common mistake I might be overlooking? Would appreciate any help or confirmation from someone who’s completed this lab or run into a similar problem
Web App Hacking (Lab series): CVE-2022-2143 (iView2)
Hello all, I have spent way to long trying to complete the iView2 exploit. I was expecting a text box on the page for command entry, but I cannot get anything like that. I have been able to send a post request to the NetworkServlet page using the provided exploit string and I know that the test.jsp is created because I can use the query parameter ?cmd=whoami and I get the mysqldump output showing "nt authority \system". I cannot get any other query parameters to execute, even simple ls or dir commands. I found y4er's blog post and everything I see in terms of the syntax of the exploit appears to be identical to the lab. Any directions/suggestions/hints would be greatly appreciated! Thanks in advance. JThreat 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 OctavioBuilding 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.Building Your First Practical Lab (Part 1)
This is the first 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 this blog, we’ll walk through the process of creating and importing your own machines. In part 2 we’ll walk you 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. Building your machine in AWS The first step is to log into your AWS account and provision your first EC2 machine to be configured. Access to AWS will depend on your organization and its access rules (e.g., logging in via console.aws.amazon.com). Provision an EC2 Once logged in, the first step is to launch an EC2 instance. Search for “EC2” in the top search bar and click “EC2” under Services. In the EC2 Dashboard, click on “Launch instance”. The lab will use a standard Linux distribution. It’s recommended to start with a clean slate. Select Ubuntu Server 22.04 LTS (HVM), SSD Volume Type, or a similar recent Ubuntu LTS version. This is a widely used and well-documented distribution. It’s also in the free tier, which means we can keep costs as low as possible. The next step is to select the instance type. Lab Builder supports t3.micro, t3.medium, and t3.large. You can select whichever CPU type and associated resources your machine needs in the lab that best suits your needs. Since this is a reasonably straightforward Linux privilege escalation lab, we are going to use t3.micro. Now, we’ll need to configure the instance details. You can generally leave most of these settings as the default for the current purpose. Network: Ensure your default VPC and a subnet are selected. Auto-assign Public IP: Check this is enabled so you can SSH into the instance from the internet and configure it. Security Groups control the machine's inbound and outbound access. Since you need to configure the machine, make sure you have SSH open to SSH into it (alternatively, you can use AWS Systems Manager to control access without the need for SSH or direct network access). When using Security Groups, it's a good practice only to allow sources from trusted IPs. Select “Create Security Group.” Select Allow SSH traffic from For the source, it is recommended to select a trusted IP range or your own IP. The storage you’ll need will depend on the machine you’re building. However, the default storage (8 GiB General Purpose SSD gp2) is usually sufficient unless you're installing and configuring large applications. Note: We do not currently support encrypted EBS volumes. Now you’re ready to launch your machine! Review all your settings carefully and click Launch. You’ll be prompted to add an SSH key to the machine. You’ll use this key to connect to the instance and configure it. To create a new key pair, choose a name like my-lab-key and click Download Key Pair. Keep the downloaded .pem file secure—you’ll need it to SSH into your instance. If you’re using an existing key pair, select it. Once you have your key sorted, select Launch Instance. Your EC2 instance will now start to launch. It might take a few minutes for it to be ready. Configuring the instance for use as a lab Once your EC2 machine is launched and ready, it’s time to connect to and configure it, ready to be used in a custom lab! Connect to the running instance via SSH, using the key you downloaded previously when you provisioned the EC2. ssh -i <key>.pem ubuntu@<public_ip></public_ip></key> Note: You may need to change the permissions on the key first by running chmod 400 .pem Next, update the system packages. sudo apt update sudo apt upgrade -y Note: Depending on the future labs you create, you may not want to update system packages if you need specific versions of software or libraries installed. Setting up SSH for the lab user With Lab Builder, labs can be configured to have a session open when the lab loads. This session can be SSH, RDP, or HTTP. For this lab, we want the lab to load in the platform with the lab user already SSH’d into the machine, so they can get to work on the scenario straight away without needing to worry about connecting to a machine themselves. Many default Ubuntu AMIs disable SSH password authentication and only allow key-based authentication by default, but this can be changed. Password authentication needs to be enabled to allow our lab user to connect with a password (Lab Builder does not support key-based authentication). To do this, we can update the configuration for SSH. In the examples below, we use nano, but you can use whichever file editing tool you are comfortable with (Vi/Vim, etc.) sudo nano /etc/ssh/sshd_config Find the line that says: #PasswordAuthentication no or PasswordAuthentication no. We want to change this to allow our users to connect via a password: PasswordAuthentication yes Make sure ChallengeResponseAuthentication no is set to no (it usually is). Save the file. While this will work for most distributions, certain images provided by AWS can have additional config for SSH that needs to be changed. For our image that we are using in this example (Ubuntu Server 22.04 LTS (HVM), SSD Volume Type), we also need to change the file at the location below: /etc/ssh/sshd_config/60-cloudimg-settings.conf Open this file and make the same change we did for the other sshd_config file PasswordAuthentication yes For the changes to SSH to take effect, restart the SSH service: sudo systemctl restart ssh Next, let's create a dedicated user account for our lab participants. sudo adduser lab-user When prompted: Enter a password that will be used for lab-user (make sure you remember this, as we will need it later!) Re-enter the password to confirm. You can press Enter for all the full name, room number, etc., prompts. Confirm with Y when asked if the information is correct. Note: We recommend changing the password above to something unique to you and this machine. At this point, we recommend logging out of the existing SSH session as the Ubuntu user and logging in as the newly created lab-user to verify that the SSH configuration has been updated and that you can successfully connect to the machine via password-based SSH authentication. ssh lab-user@<ec2-ip></ec2-ip> You should be prompted to enter the user's password, which will connect you to the machine. ssh lab-user@52.18.126.144 lab-user@52.18.126.144's password: >Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-1029-aws x86_64) >lab-user@ip-172-31-17-115:~$ Ready to create the lab challenge? Read part 2 here.
