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.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.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!ISO 27001 and the Immersive One Platform: Strengthening Your Information Security Posture
The importance of continuous evidence When audits or investigations happen, it’s not enough to say you’ve got things under control – you need to prove it. That means having solid evidence of your security posture, how it’s been implemented, and a continued commitment to it. Without that, the risk of fines and reputational damage goes up. Being able to demonstrate continuous evidence is crucial for staying in line with the latest directives and regulations. How Immersive can help Immersive helps organizations implement compliance frameworks like ISO 27001 by providing evidence of due diligence, simplifying the human element of security, and enabling gradual expansion of security measures. Depending on your priorities, or where you perceive your biggest gaps to be, these are some of the areas you can leverage in the Immersive platform: Improving the speed and quality of response to emerging threats. Increasing efficacy in recruitment, retention, and career development. Reducing cloud and application vulnerabilities early in the Software Development Life Cycle (SDLC). Here are three practical ways Immersive supports ISO 27001 compliance: 1. Hands-On Labs These labs ensure people across different roles get the right training and skill development. Security and technical teams have varying needs, and our labs help meet those needs by aligning practical learning to specific job functions. A general theme is how failing to provide proper training isn’t just a missed opportunity – it can be seen as negligence. An organization is responsible for providing training tools, which should be aligned with specific roles. Here are some of the ISO 27002 sections that our Hands-On Labs align with: 5.4, 5.7, 6.1, 6.3, 8.7, and 8.27. For more details, see the ISO 27002 implementation guide. 2. Crisis Sim All frameworks emphasize properly exercising staff and those with decision-making responsibilities. This covers everything from traditional tabletop exercise (TTX) at the board level to hands-on scenarios for teams further down the organization. Proving these exercises are happening effectively can be challenging. Traditional exec-level sessions are expensive, time-consuming, and hard to scale. Crisis Sim helps to solve this. It offers a practical, scalable way to run structured exercises across different teams and roles, including the supply chain. Here are some of the ISO 27002 sections that our Crisis Sim solution addresses: 5.4, 5.20, 5.24, 5.34, and 8.16. For more details, see the ISO 27002 implementation guide. 3. Workforce Plenty of areas in the ISO 27001 framework apply to the entire organization, not just technical teams. In some cases, we already have content such as labs and workforce exercises that can be used right away. But often, the focus is on your own internal policies and procedures – and that’s where our customizable templates and lab-building tools come in. The Immersive Workforce methodology gives you a structured way to train your people and show that they truly understand and can apply those policies in real-world scenarios. It’s all about making security awareness practical, measurable, and tailored to your organization. Our Workforce methodology meets the following ISO 27002 sections: 5.10, 5.17, 5.27, 5.34, 6.3, 6.7, and 8.1. For more details, see the ISO 27002 guide. Turning compliance into confidence By tapping into the full power of the Immersive platform, organizations can go beyond just checking compliance boxes. They can actively show due diligence, streamline compliance efforts, and proactively strengthen their information security posture. From hands-on training and crisis simulations to workforce assessments, Immersive provides the tools and methodologies needed to ensure that individuals at all levels are equipped to understand, apply, and uphold robust security practices. Ultimately, this leads to a more secure environment, reduced risk, and clearly demonstrates an organization's commitment to protecting its valuable information assets. Share your thoughts How is your organization approaching ISO 27001 compliance? Drop a comment below and let us know what’s worked, or what you’re still figuring out. For more details on strengthening your information security posture, check out these sources: ISO 27001 framework ISO 27002 implementation guide (for ISO27001) NIS2 DORADecoding Coding: Picking a Language
These days, more and more jobs can benefit from being able to write simple scripts and programs, especially in cybersecurity. For example, pulling data from an API, scraping web pages, or processing large data files to extract information – the list of uses is virtually endless! Tempting as it is to dive right in, there are several things worth thinking about before you begin. This article will discuss one of the most important choices – selecting a language. What to consider when choosing a language A basic understanding of programming languages can make your life easier, increasing your adaptability and finesse in different environments. But with tons of languages like Python, Java, JavaScript, Go, Rust, and more, which one should you choose? Here are the crucial factors to consider: What's available Can you install whatever language you like to run your code, or are there limitations? If you have an enterprise-managed computer, you might not be able to install new software or languages, and you may need to use the default options. For Windows, this is PowerShell. Bash Script is the equivalent for Mac and Linux devices, and Python is often available too. Your personal experience and interest This one might sound obvious, but it does matter. We learn better and faster when we're invested in the subject. Look at your previous experiences. Have you worked with any programming languages before? Did you enjoy them? For example, if you had a good experience working with Python, let that guide your decision! That said, don't shy away from learning something new if there's a good reason or you’re curious to do so. What's trending in your organization Does your organization or team predominantly use a specific language? Not only would learning that one help you communicate better with your colleagues, but it could also give you an edge while working with systems developed in that language. Plus, there’ll be plenty of people to talk to if you get stuck! The language's capabilities and nature Like people, different languages have different strengths. Some are fantastic for web development (like JavaScript), while others are better suited for system-level programming (like C). Python is often an excellent choice. It's considered easy to learn, incredibly flexible, and powerful due to the huge catalog of packages available. While it isn't as fast as many other languages, for most purposes, it's usually more than fast enough. Java is a very widely used object-oriented programming language and can be extremely fast. The learning curve is steeper than Python, but there are loads of learning resources available. JavaScript (not to be confused with Java!) isn’t as useful for quick standalone scripts or applications, but it's the dominant language for websites and browsers, so understanding it is practically a superpower for testing and manipulating websites and applications. C and C++ allow low-level access to memory and offer a lot of flexibility – incredibly helpful when evaluating systems with these languages at their core. Available tools and training Great tools can make tough jobs easier. Certain programming languages have robust toolsets that can help automate your tasks. For instance, Python has a wide array of libraries and frameworks that make handling big projects a cinch while saving you time and effort – why reinvent the wheel when you can just import it? Take a look at what training is available for the language you’re interested in. Older and more popular languages are likely to have more to choose from, but there’s loads out there and a lot of it is free! Also, consider what tools you might already have access to within your organization. Community and support If a programming language has a large active community, it means help is readily available when you get stuck. Languages like Python, JavaScript, and Java have strong communities and plenty of online resources available. Scope for growth If you're planning to learn a language, why not pick one that's in demand? Check job boards, look at industry trends, and see if learning a particular language can give your professional growth a boost! Summary Remember, no language is “the best". The best is the one that suits your needs and circumstances. You might even find mastering multiple programming languages useful over time. Just like speaking multiple languages, the more you know, the better you can communicate in different environments! Once you understand some of the basic programming concepts, like variables and loops, it’s easier to learn a second or third language. Learning a programming language may initially seem like climbing a steep mountain. But once you get the hang of it, you'll realize that the view from the top was well worth the hike! Want to take the next step? Here are some lab collections that may help you learn a bit more about PowerShell and Python: PowerShell Basics Offensive PowerShell Introduction to Python Scripting Share your thoughts If you’re new to coding, tell us what language you’re trying out! Why did you pick it, and would you make the same choice again? Are there any specific challenges you found or any relevant experiences you’d like to share?Secure Code Comments: One Easy Way to Steward Your Application Security Culture
While traditional code comments focus on explaining the code's functionality, security-focused comments are crucial to promoting secure coding practices throughout the development lifecycle (SDLC). By making this simple tactic part of your natural workflow, you can assert your knowledge and become a security champion. Let's explore how integrating security comments into your code can benefit you and the security team. Leading Forward Using Secure Code Comments Integrating security into your daily coding isn't just about ticking requirement boxes; it's about building a security mindset that makes you indispensable. Secure-code comments are low-hanging fruit for sharing knowledge, learning from others, and making security a seamless part of your day. Senior developers and application security champions can quickly and effectively educate other developers about best practices without leaving the comfort of their Integrated Development Environment (IDE). Best practice for code comments suggests emphasizing the why, not the what. Security-focused comments are no different. Meanwhile, they play a crucial role in promoting secure coding practices, enabling teams to: Explain Key Security Moves: Share the rationale behind specific security measures, such as input validation, encryption, and access control mechanisms. Flag Red Flags: Spot potential weaknesses in your code, like SQL injection, cross-site scripting (XSS), and unprotected data. Share Knowledge: Link to relevant security standards, guidelines, and resources and facilitate efficient code reviews. Enhancing Code with Security Comments–Two Examples Example 1: Preventing SQL Injection with Parameterized Queries (Python) Let’s consider a simplified Python function, which performs a simple insert operation into a database: def insert_user(conn, name, email): """ Inserts a new user into the 'user' table. Args: conn: A sqlite3 connection object. name: The name of the user. email: The email address of the user. Returns: None This function uses a parameterized query to prevent SQL injection vulnerabilities. See: CWE-89 https://cwe.mitre.org/data/definitions/89.html By using placeholders (e.g., `?`) and passing the actual values as separate arguments, we avoid direct string concatenation. This ensures that user-supplied input cannot be manipulated to modify SQL commands. """ sql = """INSERT INTO user (name, email) VALUES (?, ?)""" cur = conn.cursor() cur.execute(sql, (name, email)) conn.commit() cur.close() As you can see, in addition to the regular docstring, we succinctly mention why we’re using parameterized queries over string concatenation. We also reference a CWE and provide a link for anyone who wants to learn more. With just three extra sentences in a function comment, we’ve given less experienced developers who are code spelunking a quick lesson (or reminder) about why and how to prevent SQL injection. Example 2: Mitigating XSS Vulnerabilities with DOMPurify (React) Let’s take a look at another example, this time on a React frontend. Here, we’re knowingly doing something potentially dangerous but effectively communicating to other developers the mitigations applied. /** * Displays user-generated HTML content, sanitizing it with DOMPurify to prevent XSS vulnerabilities. * * This component uses `dangerouslySetInnerHTML` because the content being displayed *must* include HTML markup. * Alternatives like rendering plain text or using a limited subset of HTML tags are not sufficient for this use case. See: https://kanban.system/t/123 * **Security Considerations:** * * **CWE-79 (Improper Neutralization of Special Elements used in an HTML Page): https://cwe.mitre.org/data/definitions/79.html * This code directly addresses CWE-79 by sanitizing the user-provided HTML before rendering it. Without sanitization, malicious * users could inject JavaScript code that would be executed in the context of the website, leading to * XSS attacks. * * **Why not just use textContent?** If we used `textContent` or similar methods, any HTML tags in the user * input would be treated as plain text and displayed as-is. This would prevent XSS, but it would * also defeat the purpose of allowing users to input HTML in the first place. * * **Why DOMPurify?** DOMPurify is a widely used and well-maintained library specifically designed for * sanitizing HTML. It's more robust and secure than attempting to create a custom sanitization * solution. It handles a wide range of potential XSS attack vectors. * * @param {string} htmlContent The user-generated HTML content. This is assumed to be untrusted. * @returns {JSX.Element} The sanitized HTML rendered within a div. */ function SafeHTMLDisplay({ htmlContent }) { const sanitizedHTML = DOMPurify.sanitize(htmlContent); return ( <div dangerouslySetInnerHTML={{ __html: sanitizedHTML }} /> ); } This time we go into more detail about the why. Let’s break it down: First, it’s important to acknowledge that the original approach isn’t best practice. Second, you can level up developer awareness about alternative options.Then, connect the dots for maximum impact, sharing why this approach is required to satisfy product requirements. Finally, it’s important to detail security considerations with CWE IDs, codifying the weakness you’re proactively mitigating; yes, you can even justify the introduction of another dependency compared to a custom implementation. Any future developer tasked with modifying the comment feature will quickly understand the importance of keeping this mitigation rather than “cleaning up the code” because it still functions “the same” without it. As an AppSec developer or security champion, you’ve just avoided another security report being raised because of a regression introduced by an over-eager junior developer. It's well worth the 15 lines of extra code. Even better, any security engineer performing a secure code review will be much more confident that their developer understands why they wrote the code the way they did. This knowledge, in turn, expedites that coveted ‘approve’ on their pull request, reducing the time to get the code safely into production. Identifying and codifying vulnerabilities with Find the Flaw Setting the tone with security-focused comments largely falls to the lead developer or security champion, presenting an easy opportunity for aspiring champions to stand out. Remember, the goal is to identify and codify weaknesses in code before or as it is being written; this approach ensures others can craft easy-to-understand security comments too. Whether you’re just starting out or looking to grow your skillset, Immersive AppSec’s Find the Flaw collections provide ample opportunities to build critical DevSecOps muscle memory. You’ll learn to identify various common vulnerabilities in code and recognize what CWE IDs they correspond to. Writing security-focused comments will feel like second nature when you're coding up a storm! Beyond Code Comments: Empowering Your Manager to Recognize the Power of AppSec Training Code comments are a valuable AppSec tool, albeit only one piece of the puzzle. To cultivate a developer-led security culture, organizations need managers who recognize the power of comprehensive training programs for their elite developers. These programs support proactive developers with the knowledge and skills to build secure applications from the ground up. As a result, the organization achieves development velocity SLAs and application security simultaneously. Remember to share your experience learning by doing, gaining the attackers’ perspective, which Immersive Labs AppSec offers. Your manager and teammates should recognize the value of using safe, real-world scenarios and interactive exercises, such that the training you do (now) targets the problems you have (now). Share your thoughts Check out this Find the Flaw collection and then share your thoughts with The Human Connection community: For developers: Does adding security rationale to your comments feel like an ‘easy enough' lift? For security champions: Are you already using this technique or something similar? How have you convinced other developers to adopt this style of commenting?An Ounce of Prevention Beats a Pound of Postmortem with Supply Chain Security
Supply chain security is all about protecting your organization from risks and threats that come from external parties and processes you rely on. But trust, like code, is a dependency. And risk? That’s a side effect. Case in point: this month, a widely used GitHub Action, tj-actions/changed-files, was compromised, proving that when the Git hits the fan, it can blow secrets across thousands of repos (CVE-2025-30066). It was a textbook case of a supply chain attack: a legitimate, trusted tool hijacked and used to compromise downstream users. Now, don’t get me wrong, we all love GitHub and a secure CI/CD pipeline. But when attackers injected malicious code into the action, stealing secrets like personal access tokens, npm tokens, and private RSA keys from affected CI/CD pipelines, over 23,000 repositories were exposed to cyber risk. This wasn’t a breach caused by a missed patch or weak password - it was a breach of inherited trust. It highlights a pressing truth: supply chain security isn’t just a technical problem. It’s a cultural one. It demands dynamic cyber resilience. And I know you’re tired of hearing about SolarWinds, Logs4Shell, and Kaseya. But it’s not just your security at stake – it’s everyone you rely on and everyone who relies on you. Even right now, we are watching The Biggest Supply Chain Hack Of 2025: 6M Records Exfiltrated from Oracle Cloud affecting over 140k Tenants 🙀 That’s why dependency monitoring, minimal permissions, and source validation are critical to securing your supply chain. In today’s software-driven world, trust is embedded in every layer of how we build and ship technology. We trust the tools, the teams, the platforms, the packages. To mitigate risks effectively, we need a clear understanding of them. Let’s explore approaching this with Immersive. Third-party risk management Business stakeholder lens: Procurement and vendor management teams must understand that security isn't just a checkbox during onboarding. Ongoing third-party risk reviews and SLAs with teeth are essential. Security leaders should train these teams to ask the right questions and recognize red flags. Risk ISO 28000 – Security Management Systems for Supply Chains NIST 800-53: Ep.20 – Supply Chain Risk Management Technical stakeholder lens: Security teams must know how to evaluate vendor security postures, monitor for changes, and validate that data flows are compliant and secure. Training should focus on threat modeling integrations and validating trust assumptions in vendor tooling. Secure Fundamentals: Security Patching Mobile Application Security Fundamentals: Inadequate Supply Chain Security Software supply chain Business stakeholder lens: Non-technical leaders should understand that open source and third-party code aren't free – they come with ongoing maintenance, monitoring, and potential exposure. Funding and prioritization decisions should reflect this risk. NCSC Cloud Security: Ep.9 – Supply Chain Security Stack Overflow Secure Fundamentals: Least Privileges Introducing the Cyber Kill Chain Technical stakeholder lens: Developers and AppSec teams need to understand transitive dependencies (a.k.a. shadow dependencies), know how to interpret Software Bill of Materials (SBOMs), and be trained to look beyond their own code. CI/CD workflows must be hardened, with guardrails baked into the process. CVE-2024-3094 (xz) – Supply Chain Compromise Events & Breaches: Monero Wallet Supply Chain Compromise Sunburst Supply Chain Compromise Collection Hardware and physical supply chain Business stakeholder lens: Especially in regulated or critical industries, leaders must ensure that logistics and sourcing teams are trained to recognize risks around counterfeit or tampered hardware. Business Continuity 101 NIST 800-53: Ep.11 – Physical and Environmental Protection IST 800-53: Ep.1 – Access Control Technical stakeholder lens: IT and SecOps teams should be trained on verifying hardware provenance, firmware integrity, and secure provisioning practices. This is often an overlooked area in cyber training programs. IoT & Embedded Devices: Supply Chain Hardware Tampering Data handling in the chain Business stakeholder lens: Legal and compliance teams must understand how data moves across vendors and jurisdictions. Training should focus on recognizing data sovereignty issues, breach notification responsibilities, and contractual risks. Compliance Data Handling Secure Fundamentals: The CIA Triad Secure Data Handling Technical stakeholder lens: Data engineers, architects, and security teams should be trained on protecting data in transit and at rest, especially when working with third-party platforms or integrations. Zero trust principles also apply. OWASP 2021: Ep.8 – Software and Data Integrity Failures Modern Encryption Operational resilience Business stakeholder lens: Executives and business continuity teams must recognize that vendor outages or upstream compromises can impact downstream. Tabletop exercises should incorporate supply chain attack scenarios. Recommended reading: House of cards: surviving a supply chain attack Labs: Cyber for Board Members: Ep.8 – Supply Chains Cyber for Executives: Ep.7 – Supply Chain Security NIST 800-53: Ep.6 – Contingency Planning NIST 800-53: Ep.8 – Incident Response Technical stakeholder lens: Incident response and engineering teams should be trained to detect and contain incidents involving third parties. This includes monitoring dependencies, rotating credentials, and updating playbooks for modern attack chains. No Labs this time! Exercising becomes critical: Cyber Training Essentials for Supply Chain Resilience Supply Chain: Template for Technical Teams You may not cause the vulnerability, but you'll own the breach. You can’t wait until the postmortem to start training your teams to see beyond the perimeter. A resilient cyber culture ensures that your people are ready to respond when trust is compromised. Supply chain security is a shared responsibility, but it starts with recognition and increasing cultural buy-in. At the end of the day, an ounce of prevention beats a pound of postmortem. Share your thoughts Did you learn anything surprising about the interconnectedness of supply chain risks? What do you think is the biggest hurdle to strong supply chain security? Share a practical tip or strategy that worked for you! Big thanks to ZacharyAbrams for assisting with content reviews and recommendations in today’s blog! Want laser-focused recommendations for your unique program needs? Chat with your CSM about Premium Support to work with legends like Zack! Get updates in your inbox on posts like this by following the Human Connection Blog!Cyber Drills and Outcome-Based Programs: A Hands-On Approach to Cyber Resilience
What are cyber drills and outcome-based programs? Cyber drills vs. outcome-based programs Cyber drills Prove Outcome-based programs Improve Simulate a realistic cyberattack to test response capabilities Ongoing, structured programs to build and improve security operations Benchmark security preparedness at a given point in time Measure progress over time with defined success metrics Team-based exercises that focus on immediate response Tailored multi-year programs that address specific security gaps One-off or periodic events Continuous learning and improvement The key difference is that cyber drills test and prove preparedness and expose improvement areas; outcome-based programs address the improvement areas and enhance an organization’s ability to detect, respond, and recover from cyber threats. Combined, these approaches provide sustainable, robust cyber resilience. Designing an effective outcome-based program To implement an outcome-based program successfully, organizations must consider the following factors: 1. Understanding business objectives and risk tolerance Before designing a program, it’s crucial to understand: Business goals – what is the organization trying to achieve? Risk appetite – how much risk is the company willing to take? Regulatory requirements – what compliance standards must be met? 2. Defining measurable outcomes Success should be based on quantifiable improvements, such as: Reduced incident response time Fewer security breaches Improved threat detection capabilities More substantial alignment with regulatory requirements 3. Tailoring the program to the organization Organizations are unique, and outcome-based programs must be customized to fit: Risk assessment results Threat landscape Technology stack and processes Security team capabilities 4. Implementing and monitoring progress A phased approach ensures better adoption: Pilot phase – test the program with a small team before full deployment Phased rollout – implement step-by-step to ensure success Continuous reporting – regularly track metrics and adjust the program as needed 5. Demonstrating ROI and business value To gain leadership buy-in, organizations must: Showcase case studies of successful implementations Use data-driven insights to highlight improvements Demonstrate long-term value beyond compliance Example: A multi-year cybersecurity resilience program A well-structured outcome-based program can span multiple years, evolving as threats change. Year 1 – Conduct cyber drills, crisis and incident response exercises and assessments, and document response plans. Develop improvement plans and program scope. Year 2 – Technical and executive training, incident handling exercises. Year 3 – Advanced cybersecurity drills, scenario-based threat modeling, multi-team exercising. Process and policy stress testing. Year 4 – Purple teaming, improving collaboration between defense and offense teams. Year 5 – Full-scale red teaming and supply chain cyber drills. This approach ensures that organizations continuously prove and improve rather than just react to incidents. Final thoughts: The future of cybersecurity training Moving from traditional cybersecurity upskilling to cyber drills and outcome-based programs requires: A shift in mindset – focus on long-term resilience, not just one-time testing. Cross-department collaboration – security is not just IT’s responsibility; leadership buy-in is crucial. Expertise in design and delivery – outcome-based programs must be well-structured and measurable. By embracing cyber drills and outcome-based cybersecurity training programs, organizations can stay ahead of threats and build a stronger, lasting security culture. Share your thoughts Is your organization ready to move beyond traditional cyber upskilling? Where do you feel the biggest challenge lies, out of the three points mentioned above? Have you had success in overcoming these challenges? If so, share how with the community. Let’s build a cybersecurity strategy that delivers accurate, measurable results.Understanding CVE-2024-21412: A Zero-Day Exploit Targeting Windows Users
What is CVE-2024-21412? CVE-2024-21412 is a security feature bypass vulnerability in Windows Defender SmartScreen. SmartScreen typically evaluates the safety of downloaded files and displays warnings for unrecognised or suspicious ones. But this vulnerability allows attackers to circumvent warnings and install malware on unsuspecting systems. Which systems are affected? CVE-2024-21412 impacts a broad range of Windows systems, including: Windows 10 (various versions) Windows 11 (various versions) Windows Server 2019 and later versions How can this vulnerability be used against your systems? Attackers exploited CVE-2024-21412 by crafting a Windows Internet shortcut (.url file) that pointed to another .url file on a remote SMB share. This technique tricked the system into automatically executing the file at the final location, bypassing SmartScreen's security warnings. Researchers even created a proof-of-concept exploit, demonstrating how easy the vulnerability is to exploit. Attackers also abused the Microsoft Search Protocol (MSP) to deceive users. They crafted malicious links that appeared to point to local files, but in reality, connected to an attacker-controlled server. This tricked users into opening malicious files without realising they were downloading them from an external source. How to protect your organisation Microsoft addressed CVE-2024-21412 with a patch released in mid-February 2024. Installing this patch is crucial to mitigate the risk associated with this vulnerability. In addition to patching, organisations should implement comprehensive monitoring and detection systems to identify and mitigate threats across all stages of an attack. This includes using intrusion detection systems, firewalls, and security information and event management (SIEM) tools to monitor network traffic and system activity for suspicious behaviour. Organisations should also consider employing advanced real-time behaviour analytics to monitor unusual activity and identify potential threats, even when they bypass traditional security measures. This involves analysing user and system behaviour patterns to detect anomalies that could indicate an attack. Conclusion CVE-2024-21412 highlights the importance of cybersecurity awareness and proactive measures, which can be mitigated with improved organisational cyber resilience and regular patching policies. As always, staying informed about potential vulnerabilities is a crucial step in reducing the risk of your organisation being attacked. Recommended content To learn how to detect this vulnerability in a sandboxed environment, check out the following lab: CVE-2024-21412 (SmartScreen Bypass) – Elastic Log Analysis. In this lab, you'll use ElasticSearch to detect the presence of malicious URL files in logs. Share your thoughts Have you seen this vulnerability being exploited in the wild? Have you patched your systems yet? Share your thoughts by commenting in the thread below.Breaking Down Walls to Make Way for AI
The rapid rise in the popularity and application of AI has been unprecedented. We are actively experiencing the dawn of a revolutionary chapter in technology and innovation, but it also feels a little like this, don't you think? AI is everywhere. Even where you didn’t ask for it, or frankly may not want it. Its rise brings security risks that require comprehensive, strategic management. Are you training your teams on AI security risks? Are you reviewing procedures to protect your business as the threat surface expands? You’re not alone. Let’s get into how we’re guiding customers through these challenges. Immersive can provide knowledge, skills building, and engaging challenges for your teams to address risks from different angles. Artificial intelligence foundations To protect an organization, you need to know what you’re protecting from. These are some of our core recommendations: AI for Business Gain an understanding of various risks associated with implementing and integrating AI in a business context. These risks include understanding the challenges of implementation, potential issues in day-to-day AI utilization, and the broader implications of AI on operations. These labs will equip individuals with the knowledge to effectively leverage AI, while being mindful of these risks. AI Fundamentals Learn about emerging threats, generative AI models, and prompt injection attacks. Gain a comprehensive understanding of AI's implications in cybersecurity, AI-related security risks, and gain practical experience mitigating those risks. Build knowledge around internal risks AI often enters businesses through productivity tools or internal chatbots, like ChatGPT, for HR or finance queries. Using internal AI apps creates risks around data access, data handling, privilege management, improper use of LLM, and compliance considerations (or consequences). Some of these considerations are also relevant for external risks with AI. Here are some collections to get your team’s gears turning around AI-adjacent considerations and internal risk: Cloud Security Identity and Access Management Secrets and Encryption in AWS NIST – Guidelines on Security and Privacy in Public Cloud Computing (800-144) Risk and Compliance ISO 22381 – Security and Resilience for Identification Systems ISO 27014 – Governance of Information Security ISO 27018 – Protecting Private Data in Public Clouds ISO 28000 – Security Management Systems for Supply Chains ISO 31000 – Risk Management Let’s not forget – with new tools comes new access and alerting patterns. You’ll need to ensure your Digital Forensics and Incident Response (DFIR) teams are ready for new signal analysis and identifying corresponding indicators of compromise (IoCs) with new technologies. Digital Forensics Introduction to Digital Forensics Digital Forensics Threat Hunting – Theory Threat Hunting Introduction to Incident Response and Forensics in AWS Upskill to protect your business from external risk As customer-facing AI expands, so does your threat surface. The risks remain rooted in attacks humans conduct today; they’re just becoming more sophisticated with AI. If threat actors use AI maliciously against your business, you might see advanced social engineering attacks. This could include sophisticated phishing attacks or AI-generated voice, image, or video to manipulate users into disclosing credentials. Here are a few hands-on content recommendations that will keep your team response ready: Events and Breaches Gain familiarity with some of the biggest cyber events and most infamous data breaches in hacking history. Buckle up for interactive labs that will get you thinking about real-world events and how AI could affect these types of scenarios. Events and Breaches: Data Exposure Events and Breaches: Phishing Fraud Events and Breaches: Data Leaks Emerging Threats Attackers are quick to adopt new tools and tactics, giving them a first-mover advantage. Labs in this collection will get you hands-on with the latest methods used by threat actors around the globe. These labs aren’t explicitly focused on AI threats, but since AI threats are rooted in legacy techniques, this collection will help your team prepare for the variations AI may introduce. There are also increased risks with publicly facing AI tools that are integrated into internal databases or systems. These non-human identities have access to potentially sensitive databases, making them inherently open to prompt injection attacks in addition to legacy techniques. Here are some of our content recommendations to prepare your teams explicitly for these types of AI challenges: Fundamental AI Algorithms Gain a deep understanding of various AI algorithms and their practical applications in cybersecurity. Engage with labs on machine learning, deep learning, specific algorithms, and complete tasks such as implementing algorithms and analyzing results. Practitioners will gain hands-on experience in applying AI techniques to enhance cybersecurity measures and mitigate cyber threats. AI Challenges Test your knowledge and skills around AI security risks such as AI plugin injections, function calling, and prompt injection attacks. Complete hands-on exercises to find vulnerabilities in AI systems, beat the bot, and actively exploit vulnerable LLM implementations. Staying ahead in a rapidly evolving tech landscape requires continuous learning and skill-building. But readiness doesn’t just stop there. You must also be well-practiced in handling new and challenging situations. Regular exercises, like prompt injection attack detection and AI-driven social engineering tabletop drills, are essential for keeping your teams prepared. As threats evolve, Immersive will continue to deliver integrated labs and industry-leading exercising capabilities so your teams are ready to protect your business. Share your thoughts What skills are critical for your team to mitigate AI risks? Did you beat our AI Challenges? Are you hungry for another byte 👾? Comment below! Stay ready in the face of increased risks – bot or not. Get updates in your inbox on posts like this by following the Human Connection Blog!
