RedEye: How CISA Built a Time Machine for Red Team Operations

Hook

Most Red Team assessments end with a PDF nobody reads. CISA's RedEye turns Command & Control logs into an interactive replay that makes stakeholders actually understand how they got compromised.

Context

Red Team operators face a persistent communication problem: they infiltrate networks, move laterally, exfiltrate data, and maintain persistence for weeks—but their final deliverable is usually a static PowerPoint deck that reduces complex attack chains to bullet points and screenshots. Blue Team defenders inherit these reports and struggle to reconstruct what actually happened, when it happened, and why certain attack paths succeeded while others failed.

Developed through a collaboration between the Cybersecurity and Infrastructure Security Agency (CISA) and Pacific Northwest National Laboratory (PNNL), RedEye emerged from federal Red Team operations where this communication gap had real consequences. When you're assessing critical infrastructure or government networks, stakeholders need to viscerally understand attack progression—not just read about it. The tool tackles a specific workflow problem: converting raw Command & Control (C2) server logs, particularly from Cobalt Strike, into temporal visualizations that preserve context, allow annotation, and enable controlled sharing between offensive and defensive teams without exposing sensitive operational details.

Technical Insight

RedEye's architecture revolves around a parser-database-visualization pipeline that transforms unstructured C2 logs into queryable campaign data. The system is built as an Electron-based desktop application with a TypeScript backend, leveraging GraphQL for data queries and MobX for state management. What makes the architecture interesting is its dual-mode operation model and the elegant separation between Red Team operational modes and Blue Team presentation modes.

The data ingestion flow starts with parser modules that consume raw C2 framework logs. The primary parser targets Cobalt Strike's TSV beacon logs, extracting entities like beacons (compromised hosts), operators, commands executed, and temporal relationships. Here's a simplified view of how the parser structures extracted data:

interface BeaconMetadata {
  id: string;
  host: string;
  user: string;
  process: string;
  pid: number;
  startTime: Date;
  endTime?: Date;
  operatorId: string;
}

interface Command {
  id: string;
  beaconId: string;
  input: string;
  output: string;
  attackTechniqueId?: string; // MITRE ATT&CK mapping
  timestamp: Date;
  operatorId: string;
}

// Parser extracts and normalizes these entities
function parseCobalStrikeLog(logPath: string): Campaign {
  const beacons = new Map<string, BeaconMetadata>();
  const commands: Command[] = [];
  
  // TSV parsing logic that builds relational graph
  // Links commands to beacons, maps to ATT&CK techniques
  // Constructs temporal sequence of events
  
  return {
    beacons: Array.from(beacons.values()),
    commands,
    timeline: buildTimelineFromEvents(commands)
  };
}

The parsed data flows into a database layer (using TypeORM with better-sqlite3 for local storage) that models campaigns as graphs. Each campaign contains servers, beacons, operators, and commands with full relationship tracking. The schema enables queries like "show me all lateral movement from beacon X" or "what commands did operator Y execute between Tuesday and Wednesday"—questions that are painful to answer from raw logs.

The visualization layer uses React with D3.js for rendering attack graphs and timelines. The graph view represents beacons as nodes and connections (lateral movement, credential reuse) as edges, while the timeline view provides a Gantt-chart style representation of beacon lifecycles and command execution. The UI supports filtering by operator, time range, MITRE ATT&CK technique, and host characteristics.

What distinguishes RedEye architecturally is the export mechanism. Red Team mode allows full editing—you can annotate commands, hide sensitive information, tag beacons with metadata, and mark specific attack paths for emphasis. When ready to share with Blue Team or stakeholders, you export a .redeye file that's essentially a sanitized database snapshot. Blue Team mode then loads these exports in read-only fashion, providing all visualization capabilities without access to operational secrets or the ability to modify findings. This design pattern elegantly solves the OPSEC problem: Red Teams control what gets shared while Blue Teams get interactive analysis tools rather than static PDFs.

The codebase structure reflects this separation with distinct modules for parsers (parsers/), database models (server/src/models/), GraphQL resolvers (server/src/resolvers/), and the React frontend (client/src/). The GraphQL schema defines the query surface, allowing the frontend to request exactly the data needed for specific views without over-fetching. For example, the timeline view queries only beacon metadata and command timestamps, while the graph view additionally pulls relationship data.

One particularly clever implementation detail is how RedEye handles temporal replay. Rather than showing the final state of a compromise, the UI can step through time, revealing beacons as they come online and commands as they execute. This temporal replay capability transforms stakeholder presentations from "here's what we did" to "watch how the attack unfolded," providing intuitive understanding of dwell time, operational tempo, and decision points during the assessment.

Gotcha

RedEye's most significant limitation is its maintenance-only status. The repository explicitly states that no new features are being developed, with the team only accepting critical bug fixes. For a tool in the rapidly-evolving offensive security space, this essentially means it's frozen in time. If new C2 frameworks emerge or Cobalt Strike significantly changes its logging format, you're on your own to develop parsers. The community hasn't stepped up with extensive parser contributions either—the parsers directory shows primary support for Cobalt Strike with limited alternatives.

The macOS deployment experience is frustrating due to unsigned binaries. On first launch, macOS blocks execution with security warnings, requiring users to manually navigate System Preferences to grant exceptions. For a tool from CISA, the lack of code signing is surprising and creates a poor first impression. This also means you're trusting binaries without cryptographic verification, which feels ironic for a security tool. The workaround involves command-line overrides or right-click exceptions, but it's friction that shouldn't exist.

The architecture is also firmly desktop-focused with no cloud deployment option. Everything runs locally—the database, web server, and UI all bundled in an Electron app. If you want to share campaign analysis across a distributed team or provide web-based access to stakeholders, you'll need to export .redeye files and pass them around manually. There's no collaborative editing, no central campaign repository, and no API for programmatic access to campaign data. The tool was clearly designed for individual analyst workflows rather than team collaboration platforms.

Verdict

Use RedEye if: You're running Red Team assessments with Cobalt Strike and need to move beyond static reporting to interactive stakeholder presentations. The temporal replay and attack graph visualization genuinely improve communication with non-technical executives and Blue Team partners. It's particularly valuable in government or large enterprise environments where formal Red/Blue team programs exist and the handoff process between offensive and defensive teams needs structure. The CISA pedigree also helps with internal security approvals. Use it if you value post-operation analysis and presentation over real-time tracking.

Skip RedEye if: You need active development support, work primarily with C2 frameworks other than Cobalt Strike, require cloud-native or team collaboration features, or want a platform that will evolve with new attack techniques and tools. The maintenance-only status is a deal-breaker for long-term investment. Also skip it if you need real-time operation tracking rather than post-assessment analysis—RedEye is for understanding what happened, not monitoring what's happening. If your workflow centers on other C2 frameworks like Sliver, Mythic, or custom tooling, you'll spend more time writing parsers than analyzing campaigns. Consider alternatives like VECTR for broader purple team workflows or invest in building C2-specific visualization into your existing operational platforms.