COBALT Analysis Pipeline: Dual Workflows

• COBALT Analysis Pipeline encompasses two distinct workflows: one using metadata-driven Random Forests for C2 detection and another employing a neuro-symbolic REPL for formal verification.
• The network-security pipeline leverages NetFlow metadata and adaptive model optimization to reliably distinguish malicious Cobalt Strike traffic from benign flows.
• The COBALT-TLA system iteratively refines LLM-generated TLA+ specifications with TLC feedback to autonomously uncover vulnerabilities in cross-chain bridges.

Searching arXiv for the provided COBALT-related papers to ground the article and confirm bibliographic details. The term COBALT Analysis Pipeline denotes two distinct technical workflows in the recent arXiv literature rather than a single standardized framework. One pipeline is a machine learning-based method to detect Cobalt Strike Command and Control activity based only on widely used network traffic metadata; it is organized into data collection, preprocessing, feature extraction, model training with adaptive optimization, and inference (Parssegny et al., 10 Jun 2025). The other is COBALT-TLA, a neuro-symbolic verification loop that pairs an LLM with the TLC TLA$^+$ model checker in an automated REPL for cross-chain bridge vulnerability discovery (Blain, 14 Apr 2026). Both pipelines are analytical systems, but they operate over different artifacts, optimize different objectives, and embed different notions of feedback.

1. Scope, nomenclature, and conceptual separation

In the supplied literature, the shared label COBALT refers to two unrelated analytical constructions. The first concerns Cobalt Strike masquerading Command and Control channels, where the central problem is detection of encrypted or profile-spoofed traffic through network traffic metadata-based machine learning (Parssegny et al., 10 Jun 2025). The second concerns cross-chain bridge vulnerability discovery, where the core mechanism is a neuro-symbolic verification loop coupling an LLM to TLC via structured error-trace feedback (Blain, 14 Apr 2026).

This distinction matters because the two systems instantiate very different pipeline logics. The Cobalt Strike work treats flows as observations, extracts NetFlow-style metadata features, and dispatches each flow to a Random Forest selected by protocol and domain. COBALT-TLA treats natural-language protocol descriptions as inputs, synthesizes bounded TLA$^+$ specifications, and iterates until TLC either returns a counterexample corresponding to BUG_FOUND or the loop exhausts its iterations.

A common misconception would be to read COBALT Analysis Pipeline as the name of a single reusable architecture. The record instead supports a narrower statement: the literature contains two pipelines bearing the COBALT name, one in network-security telemetry and one in formal verification. This suggests that any encyclopedic treatment must separate the two systems before comparing them.

2. Cobalt Strike detection pipeline: end-to-end workflow

The Cobalt Strike pipeline in "Striking Back At Cobalt" is explicitly organized into five stages—data collection, preprocessing, feature extraction, model training (including the adaptive optimization), and inference (Parssegny et al., 10 Jun 2025). Its malicious-traffic collection uses a virtualized lab with three VMs: Windows Server 2022 (Beacon-victim), Debian 11 (Cobalt Strike server), and Debian 11 (bind9 for DNS C2). The paper reports use of four widely used “malleable profiles” (Default, Amazon, jQuery, Smashburger) and a scripted set of C2 commands (e.g. bhashdump, blogonpassword, brun, bscreenshot) run in each flow. It also adds real-world pcap traces from Malware-Traffic-Analysis.net.

Benign traffic is assembled from two sources. First, Selenium-driven browser automation mirrors each spoofed profile’s genuine behavior, such as Amazon search and jQuery download. Second, the pipeline incorporates large open datasets (UPC, UPNA, CTU Stratosphere) filtered to the same MTU constraints ($\le 1500$ B). The use of mirrored benign behavior is central because the pipeline’s stated purpose is to distinguish genuine services from Cobalt Strike traffic that has been customized to mimic them.

Preprocessing begins with a Zeek pass over each pcap to extract “flows” (one per TCP connection or DNS exchange). The system then filters out zero-payload flows (e.g. port scans) and tags each flow with protocol (HTTP, HTTPS, DNS) and domain (from Host header, SNI, or reverse-DNS on IP). This flow-centric representation is the immediate substrate for downstream feature extraction and per-profile model assignment.

At inference time, the workflow is procedural. For each new flow, the system infers protocol by port, extracts the domain label, checks whether the domain belongs to a trained profile, and then either loads the matching $(\text{protocol}, \text{domain})$ Random Forest model or falls back to the corresponding “generic” model for that protocol. It then computes the same metadata features, applies the standard scaler, invokes model.predict(), and, if the prediction is “malicious,” flags the flow for SOC review.

3. Feature space and adaptive model optimization

The pipeline’s feature engineering is constrained to a fixed set of NetFlow-style metadata features (no DPI) (Parssegny et al., 10 Jun 2025). All features are computed from one bidirectional flow $f$ between client $c$ and server $s$, with $T_{\rm start}$ and $T_{\rm end}$ marking the first and last packet timestamps. The feature set includes packet counts, byte counts, payload-size statistics, durations, TCP flags, plus two ratios.

The paper gives the feature definitions explicitly. Flow duration is

$\Delta t = T_{\rm end}-T_{\rm start}.$

The total packet count is

$^+$0

and the total byte count is

$^+$1

Directional counts and bytes are also retained: $^+$2, $^+$3, $^+$4, and $^+$5. For each direction $^+$6, the pipeline computes packet-size statistics, including the mean

$^+$7

along with minimum and maximum packet sizes. Two directional asymmetry features are the byte-ratio and packet-ratio: $^+$8 The feature set further includes total counts of the SYN, ACK, FIN, RST, CWR, ECE TCP flags, a TCP-history represented as a categorical sequence of observed flag patterns, and the transport protocol (TCP vs UDP) & inferred service (53 $^+$9 DNS, 80 $\le 1500$0 HTTP, 443 $\le 1500$1 HTTPS).

The pipeline’s distinctive step is its adaptive model-selection / optimization. Rather than train a single global classifier, the method groups flows by $\le 1500$2, such as $\le 1500$3 or $\le 1500$4, together with a “generic” group for unknown domains. For each group, it builds a dataset of benign vs. malicious flows, applies standard scaling (zero mean, unit variance), and performs stratified 10-fold cross-validation with grid search over Random Forest hyperparameters. The search space is:

• $\le 1500$5
• criterion $\le 1500$6 {"gini", "entropy"}
• max_depth $\le 1500$7
• min_samples_split $\le 1500$8

Model selection uses the hyperparameter set maximizing the $\le 1500$9 score on held-out folds, and the training stage also records Mean Decrease in Impurity (MDI) for feature importance. The paper states that this is, to the best of our knowledge, the first of its kind that is able to adapt the model it uses to the observed traffic to optimize its performance (Parssegny et al., 10 Jun 2025). A plausible implication is that adaptation is the paper’s primary answer to heterogeneity introduced by malleable profiles and domain spoofing.

4. Evaluation, baselines, and deployment properties of the detection system

The evaluation methodology is defined over datasets with different scales. The generic benign collection consists of UPC + UPNA + CTU traces ($(\text{protocol}, \text{domain})$0 K flows), while malicious traffic per profile ranges from 200–23 000 flows (DNS) and 100–2 200 flows (HTTP/HTTPS) (Parssegny et al., 10 Jun 2025). Reported metrics include Precision, Recall, and $(\text{protocol}, \text{domain})$1, each with 95 % confidence intervals over the 10 CV folds: $(\text{protocol}, \text{domain})$2 The paper also reports box-plots of per-fold $(\text{protocol}, \text{domain})$3, learning curves ($(\text{protocol}, \text{domain})$4 vs. #training flows), and feature-importance plots (MDI with 99 % CI). The baseline comparison is the Ramos et al. RF pipeline on the same splits.

The central performance statement is that in most cases our NetFlow v9 model matches or exceeds prior work, especially when a flow’s mimicked domain is known ($(\text{protocol}, \text{domain})$5) (Parssegny et al., 10 Jun 2025). The wording is deliberately conditional: performance is strongest when the mimicked domain is part of the trained profile registry, and the fallback mechanism handles the unknown-domain case through protocol-specific generic models.

The production-deployment claims are framed in operational terms. The system uses only metadata, no DPI, and therefore scales at NetFlow/IPFIX rates (hundreds of thousands of flows/sec). The Random Forest models are compact, and inference is reported as $(\text{protocol}, \text{domain})$6 per flow ($(\text{protocol}, \text{domain})$7 total). The required observables are described as standard NetFlow v5/v9 fields (flow start/end, packet counts, byte counts) plus trivial extensions (min/max/mean packet size) that many routers/switches already export. For analysts, the paper highlights explainability via feature-importance, so that SOC operators can inspect whether “Beacon→Listener max-packet-size” or “byte-ratio” drove an alert.

A recurrent concern in such systems is false positives. The paper addresses this by stating that the false-positive rate is controlled through choice of $(\text{protocol}, \text{domain})$8-optimized threshold and periodic re-training on fresh benign traffic to accommodate drift in normal network patterns. This suggests an explicitly maintenance-oriented view of deployment rather than a claim of once-trained permanence.

5. COBALT-TLA: neuro-symbolic REPL architecture

COBALT-TLA is presented as a neuro-symbolic verification loop that pairs an LLM with TLC, the TLA$(\text{protocol}, \text{domain})$9 model checker, in an automated REPL (Blain, 14 Apr 2026). Its architecture consists of a Prompt-Engineered Spec Generator (LLM), a Bounded State-Space Enforcer, a Formal Verification Engine (TLC), an Error-Trace Parser, and an Agentic REPL Loop.

The Prompt-Engineered Spec Generator receives a natural-language description of a bridge protocol together with a system prompt that enforces a fixed .tla/.cfg template, requires that all variables must be over finite ranges $f$0, and forbids infinite sets. It produces a .tla module defining Init, Next, and invariants such as TypeOK and SafetyInvariant, plus a .cfg file with constant assignments like MaxTokens = 3. The Bounded State-Space Enforcer is implemented through this prompt discipline and specifically requires every variable to be typed over 0..MaxTokens, with a TypeOK invariant to catch unbounded or mistyped sets.

The Formal Verification Engine invokes TLC via subprocess.run in an isolated temp directory. TLC uses breadth-first search and always returns the shortest counterexample. The paper identifies three outcome classes via exit code: 0 $f$1 SAFE, 12 $f$2 Invariant violation (BUG_FOUND), and others $f$3 parse/compile error. This deterministic status coding is then consumed by the Error-Trace Parser, which classifies the run as {SAFE, VIOLATION, COMPILE_ERROR, TIMEOUT}, splits the output on regex State \d+:, extracts assignments using /\<id\> = (\S+)/, annotates each state with its bracketed action name such as [Mint], and summarizes the result as compact natural-language feedback.

The Agentic REPL Loop alternates between an LLM turn that generates a .tla/.cfg specification and a TLC turn whose structured feedback is injected as a user message. The process repeats until TLC either finds a BUG_FOUND counterexample or the system exhausts its iteration budget. The paper’s description is notable for its emphasis on boundedness and parser structure rather than unconstrained program synthesis.

6. Formal encoding, trace refinement, and empirical behavior in COBALT-TLA

The paper provides a concrete walk-through on a toy Lock-Mint bridge (Blain, 14 Apr 2026). The system prompt requires generation of a TLA$f$4 module with Init, Next, TypeOK, and SafetyInvariant, under the condition that all variables $f$5. The specification schema is written as

$f$6

For the Lock-Mint example, the initial state is

$f$7

and the next-state relation includes Lock(t) and Mint(t) actions over $f$8. The typing invariant is

$f$9

while the Safety (inverted) invariant is

$c$0

The paper states the convention explicitly: a violation of SafetyInvariant is a success, and TLC exit code 12 $c$1 BUG_FOUND.

The refinement loop is driven by structured counterexamples. In the worked example, TLC emits a shortest 4-step trace in which Reorg drives the system to locked=0, minted=3, thereby violating minted <= locked. The parser converts this into the natural-language directive: “Please refine your guard in Next to prevent pre-finality mint after a reorg.” The LLM then tightens the guard on Mint, resubmits, and the loop terminates once the returned violation matches the intended exploit pattern. The paper’s interpretation is that deterministic verifier feedback transforms generation into a constrained search procedure.

Empirically, COBALT-TLA is evaluated on three cross-chain bridge targets, including a faithful model of the Nomad \$190M exploit. The reported table gives:

• T1 Lock-Mint / Reorg-Stale Queue: Iter = 0, Depth = 4, States = 10, $c$2
• T2 Lock-Mint / Optimistic Relay: Iter = 1, Depth = 4, States = 15, $c$3
• T3 Nomad-style / Zero-Root Init: Iter = 1–2, Depth = 3, States = 8–25, $c$4

The summary statements are precise: COBALT-TLA reaches a verified BUG_FOUND state in at most 2 iterations on all targets, and TLC execution remains below 0.30 seconds in all runs (Blain, 14 Apr 2026). End-to-end times are instead dominated by LLM inference ($c$5–$c$6 s). The paper also states that the system autonomously discovers an unprompted vulnerability class -- the Optimistic Relay Attack -- not present in the human-written baseline specification. This suggests that, within a bounded state space, the verifier-guided loop can surface behaviors not explicitly seeded in the initial prompt.

7. Comparative significance, misconceptions, and plausible generalizations

The two COBALT pipelines are linked less by domain than by a shared commitment to structured, low-level signals and small, composable decision units. In the Cobalt Strike pipeline, those units are Random Forests indexed by protocol and domain. In COBALT-TLA, they are bounded TLA$c$7 specifications repeatedly corrected by TLC feedback. Both avoid end-to-end opacity in different ways: the former through standard metadata features and MDI-based feature importance, the latter through a deterministic verifier that yields explicit counterexamples.

A second misconception would be to treat metadata-only in the network-security setting, or LLM-generated specs in the formal-methods setting, as intrinsically too weak for serious analysis. The first paper argues the opposite for its threat model by reporting that the method performs equally or better than the state of the art while using standard features, and that it is therefore easier to use in a production environment and more explainable (Parssegny et al., 10 Jun 2025). The second paper argues that deterministic prover feedback is sufficient to neutralize LLM hallucination in formal methods, converting zero-shot code generation into a convergent proof-finding strategy (Blain, 14 Apr 2026). These are different claims, but both emphasize constrained observability over richer but less operationally tractable representations.

The papers also differ in what “adaptation” means. In the Cobalt Strike system, adaptation is explicit model selection over observed $c$8 traffic, with the capacity to add new profiles at any time by collecting a labeled dataset, fitting one more Random Forest, and registering it in model_registry. In COBALT-TLA, adaptation takes the form of iterative specification repair based on parse errors, TypeOK failures, or semantic counterexamples. A plausible implication is that both pipelines implement closed loops, but one closes the loop over a supervised classifier registry, while the other closes it over symbolic model synthesis.

The available literature supports a final, narrow conclusion. COBALT Analysis Pipeline is best understood as a label covering two separate analytical traditions appearing under the COBALT name: a metadata-driven C2 detection pipeline for Cobalt Strike masquerading traffic and a neuro-symbolic REPL pipeline for bounded TLA$c$9 vulnerability discovery in cross-chain bridges. Their technical overlap is minimal, but each is defined by an explicit stage structure, formalized intermediate representations, and a feedback mechanism designed to improve performance under operational constraints.