---
name: co-fita-red-team-blue-team
type: analysis
title: "Red Team to Blue Team: The 9-Phase Operational Cycle"
description: "The Red-to-Blue loop methodology: recon through monitor recurrence, mapped to ClickFix IR (160s containment) and CAMDOM threat modeling."
tags: [red-team, blue-team, operational-methodology, incident-response, threat-modeling, clickfix, camdom, appsec, pentesting]
timestamp: 2026-07-22
---

# Red Team to Blue Team: The 9-Phase Operational Cycle

> **Source:** `SDLC_PROTOCOL_REPORT.md` (2026-07-22), `playbook_bairesdev_appsec_alefita.md`
> **Cross-references:** [[co-fita-sdlc-protocol]], [[co-fita-green-mile]], [[clickfix-incident-response]], [[clickfix-attack-chain]], [[camdom-architecture]], [[co-fita-harness]]

---

## The Complete Cycle

The Red Team to Blue Team loop is the mature operational workflow that connects offensive security findings to durable defensive controls. It is not a linear sequence -- it is a cycle where each iteration feeds the next.

```mermaid
graph LR
    R1[1. Recon] --> R2[2. Hypothesis]
    R2 --> R3[3. Exploit Safely]
    R3 --> R4[4. Prove Impact]
    R4 --> R5[5. Isolate Root Cause]
    R5 --> R6[6. Propose Layered Fix]
    R6 --> R7[7. Retest]
    R7 --> R8[8. Encode Control]
    R8 --> R9[9. Monitor Recurrence]
    R9 -.->|"cycle"| R1
```

---

## Phase 1: Recon

Passive and active reconnaissance to understand the target system's architecture, endpoints, authentication mechanisms, and trust boundaries.

**Output:** Attack surface map.

### Techniques

| Technique | What It Reveals |
|:---|:---|
| API contract review (OpenAPI/Swagger) | Endpoint inventory, parameter types, auth requirements |
| Traffic interception (Burp Suite) | Runtime request/response patterns, hidden parameters |
| Binary inspection (JADX, Hopper) | Hardcoded secrets, API base URLs, obfuscation level |
| Process instrumentation (Frida) | Runtime behavior, certificate validation, auth flow |
| DNS and infrastructure enumeration | Service topology, third-party dependencies |

### CAMDOM Recon

For [[camdom-architecture]], the recon phase mapped:
- BLE advertising capabilities on Android and iOS
- Cross-platform protocol differences (Android BLE vs. iOS CoreBluetooth)
- Physical proximity detection accuracy via RSSI
- Existing consent apps and their failure modes (cloud dependency, software locks, single-device)

### ClickFix Recon

For [[clickfix-incident-response]], the recon happened in real time:
- Decoded the base64 clipboard payload (`curl -s URL | bash`)
- Identified the domain hijack pattern (expired `idetools.dev` -> redirect to phishing page)
- Mapped the 4-stage attack chain from initial payload to stealer exfiltration

---

## Phase 2: Hypothesis

Formulate specific, testable claims about exploitable weaknesses. The hypothesis must be precise enough that a proof-of-concept either confirms or refutes it.

**Output:** Test plan.

### Hypothesis Structure

A good hypothesis follows the pattern: **"If [condition], then [exploitable consequence]."**

| Project | Hypothesis |
|:---|:---|
| Green-Mile | "If the gateway does not propagate ownership context, then the service cannot verify object-level authorization" |
| CAMDOM | "If proximity detection operates at the hardware (BLE) layer, software manipulation cannot bypass it" |
| ClickFix | "If the attacker's C2 uses blockchain dead-drops, DNS takedowns will not disrupt operations" |
| Kaggle | "If urgency framing is combined with context pressure, models will execute destructive actions" |

### The Hypothesis Must Be Falsifiable

The hypothesis is not a guess. It is a testable claim. If the exploit fails, the hypothesis is refuted and the red team must formulate a new one. This prevents confirmation bias in security testing -- you are trying to prove yourself wrong, not right.

---

## Phase 3: Exploit Safely

Execute the hypothesis in a controlled manner. Proof, not damage.

**Output:** Proof of concept.

### Safe Exploitation Techniques

| Technique | Purpose | Safety Constraint |
|:---|:---|:---|
| Frida hooks | Intercept and modify runtime behavior | Test environment only; never production |
| Burp Suite | Intercept and replay HTTP traffic | Use authorized test accounts |
| Certificate pinning bypass | Access encrypted traffic | Document the bypass method |
| APK decompilation | Extract client-side logic | Read-only analysis |
| Modified client | Test authorization bypass | Document every modification |

### The "Safely" Constraint

The exploitation phase is constrained: **prove the vulnerability exists without causing harm.** This means:
- Use test data, not real customer data
- Document every step for reproducibility
- Do not exfiltrate data beyond what is needed to prove impact
- Do not modify production state
- Report immediately if accidental damage occurs

### Green-Mile Exploitation

The IDOR exploitation at RD Saude was performed by:
1. Intercepting an address request with Burp Suite
2. Substituting the `address_id` parameter with a different user's ID
3. Observing that the API returned the other user's address without error
4. Documenting the request/response pair as proof of concept

This is a read-only operation. No data was modified. The proof was the response itself.

---

## Phase 4: Prove Impact

Demonstrate what an attacker could achieve. Show the data that could be accessed, the actions that could be performed, the business consequences.

**Output:** Impact evidence.

### Impact Evidence Requirements

| Dimension | Evidence Type |
|:---|:---|
| Data exposure | Actual data returned by the exploit (redacted in reports) |
| Scope | Number of affected users, endpoints, or objects |
| Business consequence | Account takeover, financial fraud, regulatory violation |
| Regulatory exposure | LGPD, PCI DSS, SOC 2 implications |
| Reputational risk | Customer trust impact, media exposure potential |

### ClickFix Impact Proof

The [[clickfix-incident-response]] produced devastating impact evidence:
- `~/.passphrase` -- the user's real password, stolen via a fake system dialog
- `~/.txid` -- a tracking identifier linking the victim to the attacker's C2
- Blockchain dead-drop contract -- immune to DNS takedowns
- 50+ cryptocurrency wallet extensions targeted by the stealer
- Apple Notes exfiltration, Desktop/Documents file sweep

The impact was not theoretical. It was demonstrated with actual artifacts on the compromised system.

### CAMDOM Impact Proof

For [[camdom-architecture]], the impact proof worked differently:
- Demonstrated that existing consent apps (cloud-based, software-only) could be bypassed by:
  - Killing the app process (`kill -9`)
  - Disabling network (airplane mode defeats cloud-dependent solutions)
  - Using a modified APK without the lock functionality
- Showed that CAMDOM's BLE proximity alarm could NOT be bypassed by software means
- The alarm fires at the hardware layer, synchronized across devices in ~200ms

---

## Phase 5: Isolate Root Cause

Determine why the vulnerability exists. Is it a missing control, a misconfigured gateway, an architectural gap, or a process failure?

**Output:** Root cause diagnosis.

### Root Cause Categories

| Category | Example |
|:---|:---|
| Missing control | No ownership verification at service layer |
| Misconfigured gateway | Authentication enforced but authorization context not propagated |
| Architectural gap | Client treated as trusted component |
| Process failure | No security review for new API endpoints |
| Dependency vulnerability | Third-party library with known CVE |
| Design flaw | Security model depends on client-side enforcement |

### Green-Mile Root Cause

The root cause of the IDOR vulnerability was **architectural**: the system lacked object-ownership verification as a service-layer invariant. This was not a bug in one endpoint -- it was a systemic gap that would manifest in every endpoint that served user-specific data.

The diagnosis chain:
1. IDOR exists in address endpoint -> missing ownership check
2. Missing ownership check -> service trusts gateway authentication as authorization
3. Service trusts gateway -> no authorization context propagation pattern
4. No pattern -> no API standard encoding ownership verification
5. No standard -> no security review process catching missing ownership checks

Each link in this chain is a separate root cause. Fixing only link 1 (patching the endpoint) leaves links 2-5 intact, guaranteeing recurrence.

### ClickFix Root Cause

The root cause of the ClickFix compromise was a **supply chain trust model failure**: a link in an official GitHub repository README pointed to an expired domain that was hijacked. The trust chain was:

1. User trusts the `redhat-developer/lsp4ij` repository
2. Repository README links to `idetools.dev`
3. Domain expired and was re-registered by an attacker
4. Attacker sets up a 302 redirect to a phishing page
5. Phishing page injects clipboard payload via fake CAPTCHA

The root cause was not the user's behavior. It was the absence of domain-expiry monitoring in the repository maintenance process.

---

## Phase 6: Propose Layered Fix

Design remediation at each layer: client, gateway, service, data, process. The fix must address the system, not just the symptom.

**Output:** Remediation plan.

### The Layered Fix Model

See [[co-fita-green-mile]] for the complete 5-layer fix model. The principle: fix at every layer because no single layer is sufficient.

| Layer | Role | Sufficient Alone? |
|:---|:---|:---|
| Client | Friction (slow down casual attackers) | No |
| Gateway | Control plane (enforce decisions once) | No |
| Service | Authorization boundary (verify ownership) | Yes, but defense-in-depth requires others |
| Data | Minimize exposure (reduce what can leak) | No |
| Process | Prevent recurrence (encode the lesson) | No |

### ClickFix Layered Fix

The ClickFix remediation applied the same layered thinking:

| Layer | Fix |
|:---|:---|
| Client | Browser terminal paste warnings; clipboard content inspection |
| Gateway | Domain expiry monitoring in CI/CD pipelines |
| Service | Repository link validation (check domain liveness before merge) |
| Data | Minimize credential storage; rotate immediately after compromise |
| Process | Encode the monitoring protocol (18h cycles) as a reusable control |

---

## Phase 7: Retest

Verify the fix works and has not introduced new vulnerabilities.

**Output:** Regression evidence.

### Retest Requirements

| Requirement | Method |
|:---|:---|
| Original exploit no longer works | Re-execute proof of concept against fixed system |
| No regression | Test related functionality for unintended breakage |
| No new vulnerabilities | Scan/check the modified code for new issues |
| Edge cases | Test boundary conditions (shared objects, admin override, concurrent access) |

### Verification Is Not Optional

The playbook states clearly: **"The finding is not closed until proof exists that the fix works and has not introduced new issues."** A finding without retest evidence is an open finding, regardless of whether a code change was merged.

---

## Phase 8: Encode Control

Turn the lesson into a reusable control, standard, template, pipeline check, or design pattern.

**Output:** Durable control.

### Control Encoding Methods

| Method | Example | Persistence |
|:---|:---|:---|
| Standard | "The server always verifies ownership" | Documentation + review checklist |
| Template | API contract template with ownership fields | Project scaffolding |
| Pipeline check | CI/CD rule: "every endpoint must have ownership annotation" | Automated enforcement |
| Design pattern | Gateway -> Service authorization context propagation | Architecture guide |
| Governance proposal | [[co-fita-governance]] proposal from failure observation | Automated deployment to `.agents/` |

### CAMDOM: The Protocol IS the Control

In [[camdom-architecture]], the BLE proximity protocol itself is the encoded control. The packet format (`c:0:125`, `s:a|session1`, `a:f|1|u`), the leader election algorithm, the session handshake, the mutual disconnection protocol -- these are reusable patterns, not one-off implementations. Anyone building a proximity-based consent system can reuse these patterns.

### Co-Fita: Governance as Control Encoding

The [[co-fita-governance]] system automates control encoding. When the orchestrator encounters a failure:
1. `RedTeamAuditor` detects the violation (Phase III)
2. `GovernanceIntegration` creates a proposal from the failure
3. Congress debates the proposal via Elo tournament
4. After chancela, the fix is deployed as a skill, rule, or hook to `.agents/`
5. The fix is now part of the system's permanent behavioral repertoire

This is Phase 8 automated and made recursive.

---

## Phase 9: Monitor Recurrence

Track whether similar vulnerabilities appear in new code. Measure the control's effectiveness over time.

**Output:** Metrics and feedback.

### Monitoring Methods

| Method | What It Monitors |
|:---|:---|
| Automated scanning | New endpoints for missing ownership checks |
| Code review checklists | Manual verification at merge time |
| Incident tracking | Recurrence of similar vulnerability classes |
| Regression testing | Previously fixed issues remain fixed |
| Longitudinal observation | Adversary infrastructure evolution (ClickFix model) |

### ClickFix: 18-Hour Monitoring Cycles

The [[clickfix-incident-response]] monitoring protocol represents the most intensive form of recurrence monitoring:

| IOC | Monitoring Method | Frequency |
|:---|:---|:---|
| `sj98xe4.xyz` (C2 domain) | DNS resolution, HTTP headers, TLS cert | Every 18 hours |
| `0xA3a603F8a454a9c905b4c579Bb72628F7C15C2A0` | Polygon `eth_call` with selector `0x2686ecea` | Every 18 hours |
| `62.60.226.50` (fallback IP) | HTTP probe via Tor proxy | Every 18 hours |
| Phishing pages | Domain liveness check | Every 18 hours |

This monitoring produced a predictive model: the attacker operates on calculated 40-day campaign windows with pre-emptive infrastructure rotation. The monitoring phase became a longitudinal threat intelligence study.

---

## The Full Cycle: Three Case Studies

### Green-Mile: API Authorization

| Phase | Execution |
|:---|:---|
| Recon | API contract review, traffic interception, binary inspection |
| Hypothesis | "Gateway does not propagate ownership context to services" |
| Exploit | IDOR via `address_id` parameter substitution |
| Impact | Personal data exposure, PCI DSS violation, account manipulation |
| Root Cause | Missing ownership verification at service layer |
| Layered Fix | 5-layer model (client through process) |
| Retest | Frida, Burp, manual testing confirming ownership checks |
| Encode | Ownership verification pattern as API standard |
| Monitor | Code review checklist for new API endpoints |

### ClickFix: APT Incident Response

| Phase | Execution | Time |
|:---|:---|:---|
| Recon | AI decoded base64 payload, identified attack chain | +1 second |
| Hypothesis | "Persistent threat -- LaunchAgent or login item" | +71 seconds |
| Exploit | Listed LaunchAgents, identified plist | +101 seconds |
| Impact | Found `~/.txid` and `~/.passphrase` -- password stolen | +145 seconds |
| Root Cause | KeepAlive: true + RunAtLoad: true = process respawns after kill | +122 seconds |
| Layered Fix | Unload LaunchAgent first, then kill; rotate password | +132 seconds |
| Retest | Verified no respawn, no SSH backdoors, no new users | +137 seconds |
| Encode | 7 technical docs, simulation scripts, IOC database, monitoring protocol | ~2 hours |
| Monitor | 18-hour cycles: DNS, WHOIS, server headers, Polygon contract, TLS | Ongoing |

### CAMDOM: Physical Safety

| Phase | Execution |
|:---|:---|
| Recon | Mapped threat surface: BLE range, cross-platform differences, existing app failures |
| Hypothesis | "Hardware-level BLE proximity detection cannot be bypassed by software" |
| Exploit | Tested BLE advertising ranges, cross-platform interop, RSSI reliability |
| Impact | Alarm fires at configurable distance; synchronized across devices in ~200ms |
| Root Cause | Traditional consent apps depend on cloud (blockable), software locks (killable), single-device (bypassable) |
| Layered Fix | BLE mesh with leader election, mutual session agreement, volume-forced alarm, no network dependency |
| Retest | 429 commits of iteration; cross-platform BLE interop validated |
| Encode | The protocol itself is the reusable pattern for proximity-based consent |
| Monitor | The alarm system IS the monitoring -- breach of proximity boundary triggers synchronized response |

---

## The Through-Line

The same cycle operates at every level of abstraction:

| Level | Red Team | Blue Team | Control Encoded |
|:---|:---|:---|:---|
| API endpoint | Pentester finds IDOR | Engineer adds ownership check | API standard requiring ownership verification |
| Mobile app | Researcher bypasses app lock | Engineer builds BLE proximity protocol | CAMDOM protocol specification |
| AI agent | Adversary exploits agent tooling | Engineer builds governance system | [[co-fita-governance]] proposal lifecycle |
| Supply chain | Attacker hijacks expired domain | Engineer builds monitoring protocol | 18-hour IOC monitoring cycle |
| Research | ELO-RANKER identifies weak hypothesis | Research Director refines approach | [[unit-distance-methodology]] Generate-Debate-Evolve loop |

The methodology is medium-agnostic. Whether you are fixing an API endpoint, building a BLE protocol, containing an APT, or improving a mathematical proof -- the cycle is the same: understand the threat, test the hypothesis, prove the impact, fix the system, encode the lesson, monitor for recurrence.

---

## Operational Security in Practice

### The ClickFix IR Was Not Improvised

The 160-second containment was possible because the operational methodology was internalized. The response was not a panicked reaction -- it was a trained application of the cycle compressed into real time:

1. The AI identified the threat (recon + hypothesis, 1 second)
2. The response understood the persistence mechanism before acting (root cause, 122 seconds)
3. The unload-before-kill strategy prevented respawn (layered fix, 132 seconds)
4. Verification confirmed containment (retest, 137 seconds)
5. The incident became a longitudinal study (encode + monitor, ongoing)

**The critical insight:** the loop did not stop at containment. The incident was transformed into a threat intelligence study with predictive models (40-day campaign window, BDDR blockchain C2). The finding became infrastructure. This is Phase 8 operating at its highest level.

### Probing Guidelines

When probing live adversary infrastructure during the monitoring phase:

| Rule | Implementation |
|:---|:---|
| Default proxy | Tor SOCKS5 (`localhost:9050`) |
| Fallback | Rotating proxy |
| Direct connection | Passive DNS/WHOIS only; never HTTP to adversary IPs |
| Kill after session | `docker stop tor-proxy` |
| Data sensitivity | Redact credentials, PII, identifying information with `[REDACTED]` |
| Ethical boundaries | Read-only recon only; no exploitation, no victim interaction |

---

*This document is alive. It evolves as the research evolves. Challenge it. Improve it. That is the protocol.*