Initial commit: establishing the cqre.net perimeter

This commit is contained in:
2026-06-15 07:59:56 +02:00
commit 7aed2b4f70
65 changed files with 5131 additions and 0 deletions
+67
View File
@@ -0,0 +1,67 @@
---
title: "Module 10 — Red Team & Adversarial Validation"
description: "Adversary simulation against the specific kill chain identified in the Brownhat Diagnostic. Validates whether hardening modules produced real security improvement or compliance dashboard improvement."
eyebrow: "Consulting Module"
lead: "The client has MFA. They have Conditional Access. They have Intune. The dashboard is green. This is the most dangerous estate to walk into — not because it is badly configured, but because everyone believes it works. Module 10 finds out which controls are real and which are representations."
actions:
- label: "Get in Touch"
url: "/about/#contact"
primary: true
- label: "View All Modules"
url: "/consulting/skills/"
---
## What It Delivers
<div class="feature-list">
<div class="feature-item">
<div class="feature-item-icon">🎯</div>
<div class="feature-item-body">
<h4>Targeted Kill Chain Validation</h4>
<p>Adversary simulation runs specifically against the kill chain identified in the Brownhat Diagnostic and modified by previous hardening modules. Not a broad-scope red team — a focused test of whether the paths we said we closed are actually closed. The attack surface is the attack surface your organisation faces, not a generic penetration test scope.</p>
</div>
</div>
<div class="feature-item">
<div class="feature-item-icon">🔐</div>
<div class="feature-item-body">
<h4>Identity and Privilege Assumption Testing</h4>
<p>Kerberoasting, DCSync simulation, PIM bypass attempts, and OAuth consent abuse — the techniques that succeed on hardened estates because the hardening is present but not tested. A control that has never been exercised is a hypothesis. This engagement converts hypotheses to evidence.</p>
</div>
</div>
<div class="feature-item">
<div class="feature-item-icon">🧪</div>
<div class="feature-item-body">
<h4>Detection Validation</h4>
<p>Security alerts deliberately triggered to test whether detection rules fire, whether alerts reach a human, and whether that human knows what to do. Many estates generate the right alert into a queue nobody reads. Detection validation distinguishes between "we detect this" and "we detect this and respond to it."</p>
</div>
</div>
<div class="feature-item">
<div class="feature-item-icon">🏗️</div>
<div class="feature-item-body">
<h4>Structural Finding, Not a CVE List</h4>
<p>Every gap found produces a structural recommendation — not "patch this CVE" but "this path exists because of this architectural condition; severing it requires this change." The output is a shorter kill chain, not a longer remediation backlog. We do not add controls. We find why the existing ones do not work.</p>
</div>
</div>
</div>
## When to Run This Module
Module 10 is a **post-hardening engagement**. It is the evidence check after the work — the test that distinguishes security improvement from compliance improvement. Run it after Modules 2, 3, 6, and 12 have had time to bed in. Running it before hardening is simply a penetration test; running it after hardening is adversarial validation.
## Scope and Prerequisites
| | |
|---|---|
| **Duration** | 15–30 days |
| **Environment** | Any |
| **Prerequisites** | Written authorisation covering all test activities; at least two hardening modules completed; initial kill chain from Module 0 documented |
| **Natural follow-on** | Update kill chain map with validated findings; feed structural gaps back into the module roadmap |
<div class="cta-strip">
<h2>Find out which controls are real</h2>
<p>Green dashboards and untested reality are the most dangerous combination in security. Module 10 converts one to the other.</p>
<div class="actions">
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
</div>
</div>