Bad News for Black Hats: Why Our New Dynamic Threat Range Is Bound to Ruin Their Day
Welcome back to our series, “Behind the Scenes of Immersive One”! The following is a conversation with DaveSpencer, Immersive Product Manager for Technical Exercising, and RebeccaSchimmoeller Lead Product Marketing Manager. “Getting your SOC team off their desks for a multi-day drill is tough. Then, having them practice on a generic SIEM when your entire team lives and breathes in Splunk? I mean, practice is supposed to make perfect … That set-up is … flawed.” Rebecca: No kidding, Dave. It sounds like you heard from a lot of SOC Managers that their teams were running straight into what we call the ‘relevance gap.’ Can you break down what that actually means for hands-on analysts? Dave: Think of that 'gap' as the frustrating space between theory and reality. It’s when you force an analyst to practice on a generic, made-up tool, but their actual job is 100% in Splunk. It’s running an exercise on a simple, flat network when your real corporate network is a complex, segmented beast. Rebecca: So, the skills they're learning just don't transfer to the real world. Dave: Exactly. It’s why a team can get a 100% pass rate on a training module and still be completely unprepared when a real incident hits. It’s not just wasted time; it’s a false sense of security. Rebecca: So, how does our new Dynamic Threat Range capability solve that? How do we close that gap for good? Dave: By blowing it up entirely. We built this from the ground up to be hyper-realistic. Dynamic Threat Range is the only capability on the market that lets teams run live-fire exercises in a high-fidelity replica of an enterprise environment, using licensed security tools. At launch this November, we’re talking native support for Splunk and Elastic. This isn't just replaying logs; it's an authentic, full-chain adversary attack, built by our elite C7 threat team, running on the exact tools teams use every single day. Rebecca: Okay, so that’s a game-changer for the hands-on user and, no doubt, from managers too. They’re struggling to prove where their team is at in order to help them improve. How do we help them with this? You know, move beyond a pretty unhelpful "pass/fail"? Dave: Right. That's actually a core pillar we’ve built against. With Dynamic Threat Range, customers move beyond arbitrary scores. Our design is all about objective proof of readiness. We're giving managers the hard data they need to prove their team’s capability and justify their security spend. Rebecca: Oh … tell me more! Dave: At launch, we’re measuring key metrics like Time to Detect, Time to Escalate, and Investigation Accuracy. It’s the only way to get verifiable, evidence-based data on performance. “In a real attack, the platform doesn’t tell you if you’re right or wrong. So why should your exercise?” Rebecca: Running full-chain attacks on a replica of a customer's environment sounds incredibly complex. I can just hear the IT and Ops teams groaning about setup, VPNs, and operational overhead. Dave: (Laughs) Yeah, we heard that, too. And that’s why we made it 100% browser-based. No VPNs. No operational headaches. You get into the exercise and start learning in seconds. We also designed the exercises to be practical. Getting a SOC team offline for a multi-day drill is really hard. So, these default to 4 hours—intense, focused, and easy for a manager to schedule. You can extend it to 24 hours if you want to practice handovers between shifts, but the goal is zero friction. Rebecca: I love that. So, as an analyst, what can I actually do in these 4-hour exercises at launch? Dave: We’re launching with two critical exercise types. First is Digital Forensics and Incident Response (DFIR), where you join after the attack has happened and you have to use your Splunk or Elastic instance to piece together what went wrong. The second is Threat Hunting, which I love. You're in the environment as the attack itself is kicking off, and you have a detailed threat intelligence pack to work from, allowing you to proactively detect the threat before it causes real damage. It’s the difference between being a digital archaeologist and being the hunter on the ground. Rebecca: So cool! This is already huge, Dave. Knowing you, though, the team is just getting started. What’s the long-term vision? Dave: We're moving fast. We’re already working on Microsoft Sentinel support for Q1 2026. After that, we’re building out exercises for the entire security lifecycle—Containment, Recovery, Red Team, and Purple Team drills. The vision is to let you exercise every part of your security function and then benchmark your performance against your industry peers. That’s the real holy grail: knowing exactly where you stand. Rebecca: Dave, this is incredible. The passion you and the team have for solving this real-world problem is clear. Thanks so much for geeking out with me today. Dave: Any time. We're just excited to get it in people's hands. Final Thought The days of generic, classroom-style training are over. Dynamic Threat Range finally bridges the gap between practice and reality, allowing your teams to build muscle memory on the actual technology they are paid to protect. It moves your entire security function from ‘we think we’re ready’ to ‘we know we’re ready’—with the data to prove it. Want to see how it works? Don’t miss this demo.Transforming Bug Triage into Training: Inside the Making of Immersive AppSec Range Exercises
“We all know the pain of bug reports clogging up a sprint—we thought, what if we could transform that drain on time and morale into a challenge developers are excited to tackle?” Rebecca: Oh, I love that—turning bug backlog dread into bite-sized victories is brilliant. I’m excited to hear more, but first, congratulations on launching Immersive AppSec Range Exercises! This is a BIG deal! No one else does anything like this for developers. Naomi: Thanks! What can I say? My love for cybersecurity goes back to university capture-the-flag events. Pushing yourself outside your comfort zone with hands-on challenges is by far the fastest way to learn. My main goal was to bring that same energy to application security—there are loads of CTFs for pentesters, but not really for developers who need to sharpen their defensive and remediation skills. I also wanted this to be inherently team-friendly. Our individual AppSec labs are built for individual learning, but group dynamics demand different pacing and collaboration tools. Rebecca: Makes total sense. Offensive skills get the headlines, but developers need a solid, team-centric defensive playground too. So how did you translate that vision into the actual structure of our AppSec Range Exercises? Naomi: I anchored everything in the maintenance phase of the software lifecycle: Receive bug → Triage → Fix → Test → Merge. That mirrors real dev workflows, so participants don’t just patch vulnerabilities—they live the ticket management, version control, and testing cadence they’ll face on the job. [Inside scoop: When we build any security exercise, our team maps it to a real-world experience. In Immersive AppSec Range Exercises, a common SDLC workflow—teams learn best when they see exactly how it will play out in their daily sprints. ] Rebecca: I love that you’re training both mindset and muscle memory—jumping through the same process you’d use in production. Once you had that flow, what were the first steps to bring the framework to life? Naomi: Well, I knew that this project was going to need quite a few applications to house the functionality for the exercises, so I audited what we’d need from scratch versus what open source could handle. For ticketing, most OSS Kanban tools were overkill, so I built a lightweight app called Sprinter. Then for version control, we leaned on GitLab—it was quick to stand up and gave a familiar UI for branching and merges. Once those pieces clicked—vulnerabilities surfacing in Sprinter, code pushes in GitLab, and test runs in the Verification view—we had a minimally viable range exercise in action. Rebecca: A smart “build-what-you-must, borrow-where-you-can” approach. Seeing that prototype come together must’ve been so cool. Naomi: Absolutely. It was one thing to design on paper, but watching the pipeline live—tickets flow in Sprinter, GitLab merge requests, automatic test feedback—was a genuine “wow” moment. Rebecca: Speaking of “wow,” let’s talk scenarios. How did you land on “Blossom,” your vulnerable HR app in the Orchid Corp universe? Naomi: Well, we needed something with enough complexity to showcase the framework. HR apps hit three sweet spots: business logic richness, varied user roles, and sensitive data. Tying it into Orchid Corp—our fictional corporation for Immersive Cyber Drills—gave it narrative depth, especially for returning users of our Immersive One platform. Rebecca: And when you designed the actual vulnerabilities inside Blossom, what guided your choices? Naomi: I started with the OWASP API Top 10—that’s our gold standard for spotting the biggest threats. Then I looked at what slips through most scanners and frameworks—nuanced business-logic flaws and edge-case logic bugs—and made those the core of the challenge. To keep things well-rounded, I also added a few classics—things like IDOR, SSRF, and command injection—so every player gets a taste of both modern pitfalls and time-tested exploits. [Inside scoop: Mixing modern, real-world API flaws with a few known “gotchas” keeps Immersive AppSec learners guessing and builds confidence when they spot the unexpected.] Rebecca: I know you’re busy working on the next exercises we’ll release, but before we wrap, how did you test Blossom among developers and engineers? No doubt you wanted to make sure it delivered the right experience! Naomi: Yes, absolutely! We ran a pilot with our own Immersive engineers and a third party, creating a realistic dev team. Watching them collaborate—triaging, patching, merging—validated every piece of the design. Their feedback on pacing and hint levels let us polish the final release. It was one of my favourite days—seeing months of work click into place. After that, we shipped it to customers knowing it was battle-tested. Rebecca: This has been fantastic—thank you for sharing your full planning and development journey, Naomi! From initial vision to a live, collaborative exercise … I’m awed. You certainly put incredible thought and care into developing this revolutionary approach to AppSec training. Final Thought Security is a team sport, and training like Immersive AppSec Range Exercises is the fast track to confident, resilient DevSecOps teams. If you’re a developer or engineer looking to level up your remediation skills, have your team lead reach out to your Account Manager for a demo. In the meantime, watch a sneak peek of what your experience would be like in this demo below:
CVE-2022-26134 (Confluence) – OGNL Injection
For Question 6. Look at the first exploit attempt by this attacker. What command did they run? I am wondering about why when sharing the commands found in the logs, it still outputs wrong. even if typing in "X-Cmd-Response" as the command as well as the entire string found. Wondering if they are exepecting a different format/snippet of the code, or the GET requests instead?
CVE-2024-23692 (Rejetto HFS Template Injection) – Offensive
I'm stuck on the last question, number 8. Any help would be appreciated. I feel like I have tried numerous combinations with the query they provide, with no success. What's the full file path to the executable used to run the Rejetto server on the victim machine?
