The Question Nobody Asks During a Pen Test
Here's the dirty secret about most red team engagements: they end at the wrong moment.
A team of ethical hackers spends weeks probing your perimeter. They phish an employee, pivot through a misconfigured subnet, maybe drop a beacon in your DMZ. The report lands on your CISO's desk with a list of findings, a severity score, and a remediation roadmap. Everyone breathes a sigh of relief. The perimeter held... or it didn't, but you've documented the gap.
Nobody asks: what would have happened next?
That's the bet Remote Threat is making. The offensive cyber operations startup raised $11.5M in seed funding in October 2025 to push red teaming past its traditional finish line (the original Dark Reading coverage). Instead of stopping when attackers achieve initial access, Remote Threat's model assumes breach and asks the harder question: can your blue team actually detect and contain an attacker who's already inside?
This isn't just another funding announcement. It signals a maturing in offensive security — a recognition that testing detection and response is more valuable than testing initial access alone.
Why Traditional Red Teaming Stops Too Early
Traditional red team engagements typically run 3-6 weeks with a clear objective: achieve some form of compromise. Maybe that's domain admin, exfiltrating mock data, or accessing a protected system. Once the red team demonstrates they can reach the goal, the engagement wraps up. Findings get written, remediation tickets get filed, and everyone schedules the next test in 12 months.
This approach made sense when the main security challenge was keeping attackers out. Perimeter defenses were the primary control layer, and proving those defenses held was genuinely useful information.
But three things have changed:
Attackers already expect to spend time inside. Modern intrusion playbooks assume you'll need days or weeks to establish persistence, move laterally, and reach your crown jewels before anyone notices. The Crowdflake incident of late 2025 proved this publicly — attackers gained initial access on August 29 but didn't trigger a security alert until September 4. Five days to detect a nation-state actor already in your environment. The real incident timeline shows how quickly post-compromise escalation can move once initial access lands.
Cloud architecture eliminated the perimeter anyway. Your most sensitive data probably lives in AWS, Azure, or GCP. Cloud workloads spin up and down dynamically. Attack paths cross multiple AWS accounts, involve IAM role assumption chains, and depend on configurations that change daily. What does it even mean to test your "perimeter" when your critical assets are distributed across dozens of AWS accounts with no traditional perimeter at all? For a concrete example of how fast this can go in clean cloud environments, see how AI red teams exploit clean AWS environments — initial access can turn into full account takeover before any human logs in.
Compliance frameworks finally caught up. Regulations like DORA and NIST CSF 2.0 now require demonstrated incident response capabilities, not just documented policies. You can't prove your team can contain a ransomware attack by showing them a flowchart.
Against that backdrop, ending a red team exercise at initial access means testing the least important phase of an attack while ignoring the phase where your security team actually has to perform.
Post-Compromise Testing: What Actually Changes
When you shift the red team's mission from "get in" to "here you are inside, now what," the entire engagement dynamics change.
The red team's objective becomes behavioral rather than technical. Instead of checking whether they can achieve domain admin, they're asking: can we move from a compromised marketing laptop to production databases without triggering detection rules? Can we establish persistence that survives a patch cycle? Can we exfiltrate data through channels your egress filtering doesn't monitor?
Your blue team gets tested on the things that matter most. Mean time to detect. Quality of investigation questions analysts actually ask. Whether escalation procedures work under time pressure. Whether your runbooks account for cloud-native persistence mechanisms like modified Lambda execution roles or cross-account trust modifications.
The findings you get back are fundamentally different. You're not collecting a list of vulnerabilities to patch. You're discovering the specific blind spots in your detection coverage and the gaps between what your incident response plan assumes will happen and what actually happens when someone pulls the fire alarm at 2 AM on a Saturday.
Remote Threat calls this "assuming breach" operations — the idea that initial access is a given, and the interesting security work happens after that. The company's focus on continuous testing rather than annual engagements suggests an attempt to industrialize this approach, running smaller post-compromise scenarios more frequently instead of one massive yearly exercise.
The Cloud Exposure Multiplier
Post-compromise testing matters more in cloud environments than anywhere else, and that's why Remote Threat's cloud positioning makes strategic sense.
Hybrid cloud environments have what security researchers call "toxic combinations" — seemingly innocent permission grants that chain together into privilege escalation paths. Your developers need S3 write access for one project. Your CI/CD pipeline needs IAM PassRole permissions for another. Neither seems dangerous in isolation. Put them together and you've got a path from a low-privilege developer account to modifying Lambda functions in production.
Traditional vulnerability scanners won't catch these permission graph problems. They're looking for known CVEs, not logical flaws in how different cloud services interact. You need an attacker's perspective to spot the combinations that create risk.
The Crowdflake incident demonstrated how fast attackers exploit cloud-specific weaknesses once they're inside. In the first 24-48 hours post-access, attackers typically create IAM users for persistence, set up CloudTrail misdirection to hide their tracks, and build cross-account backdoors for long-term access. Each of these actions looks slightly different from on-premises persistence techniques. Each requires cloud-specific detection logic that most security teams built too late or not at all.
Remote Threat's focus on "cloud-native attack simulation" targets exactly this problem: testing whether your cloud security posture management tools, cloud workload protection, and detection rules actually catch the techniques real cloud attackers use. You can read more about the broader agentic AI offensive security landscape for why autonomous operators are compressing post-compromise timelines specifically in AWS environments.
Continuous Testing vs. Annual Theater
Most security teams run red team exercises annually. The 12-month cycle has less to do with security effectiveness than budget cycles and consulting business models. A week-long engagement generating detailed findings justifies a five-figure consulting fee better than a three-day exercise repeated quarterly.
But annual testing creates what you might call "security theater" — the feeling of being tested without actually building sustained detection capability. Your team preps for the big exercise, gets through it, fixes the immediate findings, and then detection quality slowly degrades over the following 11 months as team members rotate off the security tools team, configurations drift, and new cloud services deploy without corresponding monitoring coverage.
Continuous post-compromise testing breaks that decay cycle. By running smaller, more frequent adversarial simulations — maybe monthly exercises testing a specific attack path or detection rule set — you get immediate feedback on whether your security controls are degrading. Did that new VPC endpoint policy break your detection logic for unusual network connections? Did the new container deployment bypass your egress filtering assumptions? You find out during a controlled exercise, not during an actual incident.
Remote Threat's "always-on" positioning suggests they're betting that security teams will pay more for ongoing adversarial validation than for periodic large engagements. This aligns with how cloud security tools have evolved generally — the market has moved from point-in-time cloud security posture management scans to continuous CSPM that monitors configuration changes in real-time. Applying that same "continuous" model to offensive security testing is the logical next step.
Building the Case for Post-Compromise Validation
If you're evaluating whether to move beyond traditional red teaming, here's how to make the business case internally:
Start with what traditional testing already proved. You know initial access is possible — every red team report confirms that. Cite your most recent finding about phishing susceptibility or exposed credentials. The point isn't that attackers can get in; it's that you've already documented this and stopped caring about it.
Frame the problem around detection gaps. What happens in the five days between initial access and detection during a real incident? Which MITRE ATT&CK techniques have zero detection coverage in your environment? Can your current SIEM/SOAR stack identify lateral movement in AWS account structures, or was it configured to monitor on-premises Active Directory only?
Use compliance pressure strategically. DORA's digital operational resilience testing requirements explicitly call for threat-led penetration testing that simulates real-world attack scenarios. If you're in financial services or a regulated industry, post-compromise testing isn't optional — it's what the regulation actually asks for. NIST CSF 2.0 added an entire GOVERN function that requires organizations to understand and manage cybersecurity risk continuously, which is hard to do with annual point-in-time testing.
Quantify the incident cost differential. The difference between containing a breach in 24 hours versus 72 hours is significant across ransom payments, downtime costs, and regulatory exposure. If continuous testing reduces mean time to detect by even 20%, that improvement justifies investment when measured against incident cost scenarios. This doesn't require complex modeling — your cyber insurance carrier likely already has industry-specific breach cost data you can reference.
Propose a pilot on one cloud environment. Pick your most sensitive AWS account or Azure subscription. Run a single 3-5 day post-compromise scenario: assume initial access via compromised developer credentials, measure how long the simulated attacker operates undetected, document what detection rules would have caught the techniques used. The findings from a focused pilot make the case better than any theoretical discussion about security maturity models.
The Trade-Off Nobody Mentions
Here's the uncomfortable question about continuous red teaming: can your blue team absorb that much testing without burning out?
Annual red team exercises are exhausting but rare. Monthly or quarterly adversarial simulations mean your security analysts are constantly in "being tested" mode. The training value can become psychological weight. Detection engineering work already skews toward alert fatigue; adding continuous adversarial pressure on top of normal SOC operations could accelerate turnover in an already over-stretched field.
Remote Threat's approach implies a mature security organization with enough headcount to rotate testing pressure across team members. If you're a five-person security team supporting 2,000 employees and 300 AWS accounts, you might not have the capacity for continuous testing even if you agree it's the right model. You'd have to pick between continuous post-compromise testing and other operational priorities like vulnerability management or cloud security posture remediation. This trade-off is real and shouldn't be glossed over in vendor pitches.
The practical answer for smaller teams might be "continuous" relative to your baseline. If you currently test annually, moving to semi-annual post-compromise scenarios is meaningful progress. You don't need to become a Fortune 100 security org with a dedicated adversarial engineering team. The direction matters more than the pace.
How Post-Compromise Testing Changes What You Fix
Traditional red team findings push you toward vulnerability management: patch this CVE, fix that misconfiguration, enforce MFA here. Important work, but it's fundamentally preventive. The remediation roadmap assumes you're still trying to prevent attackers from succeeding.
Post-compromise findings push you toward detection engineering and response capability. The remediation roadmap looks different:
- Create CloudTrail detection rules for unusual IAM policy attachments and cross-account trust modifications
- Implement runtime monitoring for Lambda code modifications and S3 access pattern anomalies
- Deploy egress filtering that catches DNS tunneling and HTTP smuggling, not just blocked ports
- Build investigation runbooks that account for AWS organizations structures and resource sharing patterns
- Establish baselines for normal API call rates by principal, so anomalous activity stands out immediately
None of these are simple. They require different skills than vulnerability scanning, different tools than patch management, and different metrics than "percentage of CVEs patched within 30 days." Post-compromise testing gives you specific, prioritized detection engineering work instead of a general vulnerability backlog that never shrinks.
This reframes alert fatigue as an alert quality problem, not an alert volume problem (see this framework for evaluating SOC tooling and triage quality). When you've identified which attack techniques actually threaten your environment, you can tune detection rules for precision. If you know that cross-account role assumption is an attacker's likely lateral movement path, you can write a specific rule for that pattern and investigate when it fires with confidence, not suspicion.
The Market Context for Offensive Security Investment
Remote Threat's $11.5M seed round is small by late-stage cyber funding standards, but it reflects where early-stage offensive security investment is flowing. The seed funding patterns for offensive security startups in 2025 skew toward three models:
Platform plays that offer continuous adversarial testing integrated with cloud infrastructure — think "continuous pentesting" with post-compromise capabilities built in. These raise Series B/C rounds when they land. See the broader funding landscape analysis for how offensive security seed investments cluster around continuous testing vs. traditional engagement models.
Consulting model startups that attach post-compromise testing to existing red team offerings. They raise less because they're harder to scale beyond headcount, but they demonstrate demand for adversarial validation.
Autonomous red team startups using AI to run post-compromise scenarios without human operators. The AI red team AWS account takeover research demonstrates the technical feasibility and explains why some investors are skeptical of human-in-the-loop models. Autonomous offensive security is controversial — it's genuinely hard to constrain an AI red team from accidentally causing impact — but it addresses the capacity problem for continuous testing.
Remote Threat's positioning suggests they're closer to the first or second category: cloud-native offensive operations delivered through continuous adversarial validation. The funding size (seed, not Series A) means they're likely still building service delivery capacity and proving the continuous model works at price points that don't require enterprise security budgets.
What This Means for Your 2026 Testing Roadmap
If you're a security leader evaluating your red team strategy, here's the practical move:
Budget for post-compromise testing even if you keep your existing annual red team engagement. The annual engagement proves initial access risk. The post-compromise test proves response capability. You need both data points to satisfy DORA requirements and to actually understand your true exposure. This doesn't require a separate budget line — many MSSPs and offensive security consultancies now offer post-compromise scenarios as add-ons to existing contracts.
Expand testing scope to cloud environments specifically. If you run red team exercises only against your corporate network, you're testing 20% of your attack surface. Your cloud environments — especially AWS accounts with production data and cross-account access paths — need adversarial testing against actual cloud-native attack techniques. Start with a single account. Map the IAM permission graph. Have the red team work from a low-privilege access scenario and document every step they can take without triggering monitoring.
Build measurement around detection quality, not just vulnerability count. Traditional red team metrics (time to initial access, privilege escalation paths found) tell you about preventive controls. Post-compromise testing should measure mean time to detect, investigation path accuracy, and containment execution gaps. Create tracking for these metrics so you can show improvement over successive tests. This is how you justify continuous testing budgets — not by comparing exercise counts, but by demonstrating measurable response improvement.
Use compliance requirements as forcing functions. If you're regulated under DORA or NIS2, you already have regulatory justification for threat-led penetration testing that goes beyond perimeter testing. If you're under NIST CSF 2.0, the new GOVERN function requires understanding of your operational risk environment. Neither compliance framework is satisfied by annual phishing tests. The regulatory pressure is on your side when making the case internally.
Keep the end goal in mind: you're not testing for its own sake. You're building the operational capability to detect and contain an attacker who's already inside. That capability compounds over time. But only if you're testing the actual capability, not just the preventive controls that obviously won't stop a real breach indefinitely. See Beyond the Demo: A Framework for Pragmatic AI SOC Evaluation for how to structure adversarial evaluations that yield comparable results across exercises, and reference MITRE ATT&CK Enterprise (https://attack.mitre.org/) when defining which post-compromise techniques to include in scope.
