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.The Maze Challenge Q&A
Note: due to the large number of Serial Maze questions, we had to skip over some of the questions. ------ The Maze is brutal, The Maze doesn't forgive... fortunately our expert lab designers are on hand to answer your questions on everything Maze related. If you've got a question about The Maze series of labs and you'd like some help or advice — or to find out more about the devious minds of our creators — click the red button above to take you to a questionnaire. Get your questions in before Thursday 10th. Then come back to this page on 12th September for a pre-recorded webinar answering all of your questions! 🕵️
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, PeteUnlock the World of AI: Introducing Our New AI Foundations Collection!
That's why we’re thrilled to announce the launch of our new AI Foundations collection, a comprehensive set of labs designed to empower you to navigate the fast-paced world of AI confidently. This seven-part lab collection is your guided tour through the core components of modern AI implementation. We've crafted this collection for everyone, breaking down complex concepts into digestible, easy-to-understand labs. Whether you're a seasoned tech professional or just starting your AI journey, this collection will provide you with a practical, hands-on understanding of how AI systems are built and how they work together to deliver powerful capabilities. NOTE: These labs are only available for customers who haven’t opted out of AI-related content. Why a new AI collection? Our customers have asked for more in-depth AI content – a demand that mirrors the explosive growth of the AI market. This new collection is our commitment to staying at the forefront of the industry and proactively addressing the needs of our community. What you'll learn The AI Foundations collection is a journey through the essential concepts of artificial intelligence. Each lab builds on the last, culminating in a holistic understanding of modern AI systems, with a special focus on agentic AI. Here's a glimpse into what you'll discover: Episode 1: Artificial Intelligence (Theory): Dive into the fundamentals of AI, exploring what it is, how it works, and the distinctions between generative AI and AGI. It also discusses AI’s limitations and demystifies the "illusion of thinking". Episode 2: Core Components (Theory): Get acquainted with the building blocks of AI, including LLMs, embedding and diffusion models, RAG, MCP, and the exciting world of agentic AI. It also touches on crucial security considerations as AI transitions from "knowing" to "doing". Episode 3: Large Language Models (Theory): Explore the power of foundational models, the importance of fine-tuning, the role of system prompts, and security considerations such as exploitable vulnerabilities and data privacy. Episode 4: Retrieval Augmented Generation (RAG) (Practical): Take a deep dive into RAG, vector databases, embedding, and chunking. In this hands-on lab, you'll create a knowledge base, chunk a file, and query a fictional company's proprietary data through an integrated AI chatbot. Episode 5: Model Context Protocol (MCP) (Practical): Understand the MCP protocol and its architecture within the broader AI landscape. You'll get hands-on experience using MCP Inspector to interact with an MCP server, and instruct an AI chatbot to organize files on your desktop, gaining insight into exactly how tools are chosen and invoked. Episode 6: Agentic AI (Practical): Immerse yourself in the world of AI agents. You'll get access to real AI agents within a safe sandbox environment. The curious can poke and edit the code and explore integrated Langfuse for a deeper look into the observability of the AI system. Episode 7: Demonstrate Your Knowledge (Theory): Put your newfound knowledge to the test and solidify your understanding of the concepts covered throughout the collection. Secure and private by design We've built our practical AI labs with your security and privacy as the top priority. When you launch a lab, you're entering a completely isolated, sandboxed environment. These sandboxes are self-contained and have no connection to any customer data or personal information. Think of it as your own private, temporary workspace that’s thoroughly purged after each use. To interact with the AI models, each lab session creates temporary user credentials. Not only are these credentials temporary, but they’re also locked to the lab environment itself. This means that even if the credentials were to be exposed, they would be useless outside of the specific lab they were created for, providing a robust layer of security. Access to the internet is also strictly controlled, which only allows connections to the minimum endpoints required for the lab to function. We utilize privacy-centric AI models designed to protect your data. The models we use don’t store or log your prompts and completions. Furthermore, your interactions are never used to train any models, ensuring that your data remains your own. We’ve also opted out of any content being used for service improvements across all the AI services we use. In some of our more advanced labs, we've implemented an additional layer of security with guardrails that preprocess user inputs and model outputs to filter for harmful or inappropriate content. These guardrails are mandatory and can’t be bypassed by users within the lab environment. These multiple layers of security work together to provide a safe and secure environment for you to learn and experiment with AI. Who is this collection for? Everyone! We've designed these labs to be a guided walkthrough, making even the more technical details accessible to anyone working with or interested in AI. Whether you're a developer, a business leader, a student, or simply a curious mind, our AI Foundations course will equip you with the knowledge and skills to thrive in the age of artificial intelligence. Join us on this exciting journey and unlock the power of AI. Get ready to build, innovate, and lead in the new era of intelligence.Labs Live: Reverse Engineering
#Recorded on September 16th 2025 Ever felt totally stuck with a lab? Getting frustrated? Maybe you could have used the helpful guidance of an expert? Join our Labs Live webinar, a ground-breaking community webinar series from Immersive! We're bringing you live, interactive lab sessions led by seasoned professionals. In each Labs Live webinar, you'll collaborate directly with an expert as they navigate a challenging lab. They'll share their techniques, answer your questions, and together, you might even discover new insights. This isn't just a demonstration; it's a hands-on learning experience. Don't miss out on this unique opportunity to elevate your cyber skills. This Labs Live session will be hosted by BenMcCarthy, Lead Cyber Security Engineer, as he tackles one of our new Reverse Engineering labs.
Enter The Maze Challenge: Immersive’s Most Advanced Collection Yet
Today marks the release of the Maze Challenge, Immersive’s most advanced and cunningly designed offensive cybersecurity collection yet. This new series of labs is more than just a test of skills. It's a puzzle, a game, and a creative brain-bender, crafted by two of Immersive’s most brilliant minds: StefanApostol and SabrinaKayaci. Stefan, known to many as the "evil genius" behind the Human Connection Challenge, and Sabrina, who recently inspired our London community meetup attendees with her predictions on AI within the AppSec space, have teamed up to create something truly unique. We sat down with them to get their insights on what makes the Maze Challenge so special, so challenging, and so much fun. What was the main inspiration behind the maze theme, and how did you translate that narrative into a collection of technical labs? The core idea for the Maze Challenge, as Stefan explained, came from a shared love of games. "Both Sabrina and I are geeks. We like games, and we wanted to create a challenge with an overarching goal that was more than about earning a completion token." While our labs have always awarded tokens for completion, Stefan and Sabrina wanted to create a narrative that would engage users on a deeper level. "A maze is the perfect example of that," Stefan said. "We wanted to include a game element in these challenges." This isn't just a series of technical scenarios. It's a cohesive puzzle where each lab is a step toward a larger objective. The maze narrative encourages participants to think creatively, connecting different skills and techniques in a way that feels more like a game than a traditional capture the flag (CTF). I’ve heard that this is the most advanced lab collection yet. So, what makes these labs more challenging than the thousands of others in Immersive's catalogue? This collection is Immersive's most advanced to date, introducing a range of techniques not yet widely covered in the platform. The labs are a combination of real-world examples drawn from the creators' past experiences and internal testing, all woven together with a good deal of imagination. While the challenge covers a broad spectrum of offensive skills, including web, Linux, Windows, and Active Directory, Stefan was quick to name binary exploitation as an obvious concept that will have participants scratching their heads. The team collaborated with BenMcCarthy on this particular lab, and Ben being Ben, he poured all his creativity into it, making even Stefan nervous to attempt this mean challenge! Sabrina added that the real difficulty lies in the type of thinking required. "Some of them will really require outside-the-box thinking," she said. "They're unusual in a way that requires not just the technical skill, but some creativity and more critical thinking." This is a key theme throughout the collection. Participants can't rely on a simple, formulaic approach. Instead, they must be flexible and resourceful. Sabrina noted that some challenges will require "multiple sets of skills," forcing users to chain together their expertise in different areas to find a solution. Without giving away any spoilers, can you describe a moment in one of the labs that you're particularly proud of designing? Sabrina beamed as she recalled the Inner Maze lab. "I really enjoyed creating Inner Maze," she said, before adding a cryptic twist. "When you break out of that maze is when you're really trapped." She was particularly proud of her ability to create and then beat her own challenge, finding the exploit even more difficult than the design itself. Can you give users any hints or tips? The Maze Challenge is designed to be tough, and you should certainly expect it to be just that. However, the creators want everyone to have a fair shot, so they’ve some advice for those who might feel intimidated. Use the platform to your advantage. Stefan noted that around 98% of concepts within this challenge can be learned in the rest of our lab catalogue. “If you get stuck on a specific skill, take a break from the maze, find the relevant labs on the platform, and then come back with your newfound knowledge.” We encourage you to learn along the way, and persistence is always rewarded! Failure can be a sign of progress. Sabrina shared a key insight: "Sometimes it's important to take note of what it is you're doing that's failing... If you're failing at the same spot in a particular approach, that could actually mean that you're doing something right." Go figure that one out! Don't go it alone. Sabrina advises anyone starting their journey to ask others for advice and help. Our community help forum is a great resource for sharing knowledge and getting tips from fellow participants. We want you to have fun, and part of that fun is collaborating with your industry peers along the way. In the end, what do you hope participants will take away from this experience, beyond the technical skills? Stefan and Sabrina both hope it's a "desire for more challenges”! They also dropped a teaser for a community Halloween challenge… That’s all you’re getting for now! 👀 Want a head start? Join Stefan and Sabrina for a Labs Live webinar on August 19th. They’ll be solving the Improbable Maze lab live on the call, in collaboration with you. Attendees are encouraged to play along, offer their suggestions, methods, and frustrations. It’s the perfect opportunity to see the creators’ thought process and gain some momentum for your own journey through the maze. See you there!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!
