C2Looper: what seven native command paths revealed

The analyzed C2Looper variant

Zscaler ThreatLabz published C2Looper: A New Backdoor Likely Tied To Ransomware With GitHub C2 on August 17, 2026. Proofmetry independently examined one of the Windows DLL variants identified in that research.

The analyzed variant uses GitHub for command-and-control. Proofmetry ran the sample in an isolated, disposable Windows environment and redirected its network activity to internal research infrastructure. GitHub and attacker-controlled infrastructure were not contacted.

Methodology

Proofmetry first mapped the command dispatcher and eight handlers through static analysis. The sample was then exercised in an isolated, disposable Windows environment with network activity redirected to internal research infrastructure. Analyst-operated tools correlated the intended handler path with returned results and native discovery, file, process, memory, or network activity.

The exercise preserved separate claims for a statically mapped handler, a path reached during execution, an observed result, and a corroborated endpoint or network effect. Directory enumeration did not advance beyond static mapping.

Evidence vocabulary

Proofmetry Evidence Status

1. 01

   Mapped

   A behavior or handler was identified through analysis.

2. 02

   Path reached

   Execution entered the intended code path.

3. 03

   Result observed

   A meaningful intermediate or returned result was observed.

4. 04

   Terminal state observed

   The workflow reached a defined completion or stop condition.

5. 05

   Endpoint effect confirmed

   The intended native endpoint or network effect was corroborated.

Interpretation. The public research does not claim that every observed C2Looper path reached the highest evidence level.

C2Looper evidence matrix

Five findings from seven native paths

Across the observed handler paths, the original sample produced discovery, file, process, local-memory, and redirected-network activity. Five findings are especially useful when interpreting endpoint and network records.

1. Activity begins during proxy-DLL initialization

   The worker can start as the proxy library loads, before the host invokes a forwarded function. Detection logic should preserve the relationship between the host process, the non-system library, and the activity that follows.

2. Discovery stays anchored to the backdoor process

   The backdoor coordinated the sequence from one process lineage, while its discovery helper launched Windows command children to gather identity, network, domain, group, and installed-software context.

3. File direction matters more than the command label

   One handler name suggests outbound transfer, but the observed host effect was inbound retrieval followed by a temporary-file write. Detection logic should follow data direction and endpoint effects rather than operator terminology.

4. Observed payload execution remained inside the backdoor process

   The observed fallback used private memory, changed its protection from read-write to read-execute, and started a local thread inside the existing backdoor process. An alternate module-overloading path remained mapped-only. Neither path targeted another process.

5. Network completion did not prove host-side success

   A network operation could complete while the handler still reported failure. Detection records should preserve both the network event and the endpoint outcome instead of treating transport completion as proof of behavior.

Behavior-category summary

Evaluating detections against C2Looper behavior

The useful question is whether the customer’s deployed controls observed the expected sample behavior with enough timing and context to support investigation. Proofmetry does not assign a universal pass or fail to a rule.

• Sigma-derived detections. Evaluate translated analytics in the target SIEM or EDR against endpoint records collected while the supported behavior runs.
• Snort or Suricata rules. Evaluate network detections against traffic captured by customer-operated network tools.
• EDR behavioral analytics. Review process, file, discovery, and local-memory observations together rather than as isolated API events.
• SIEM correlations. Determine whether endpoint, network, and alert records can be joined into a useful investigation timeline.
• Alert quality. Measure alert presence, latency, severity, and the evidence retained for an analyst.

Using C2Looper telemetry in customer-owned datasets

Customer-operated tools—not Proofmetry—collect and retain endpoint, network, sandbox, and security-product telemetry. For behaviors included in current coverage, Proofmetry identifies the compatible sample hash, selected test, analysis-derived observations, and known evidence limits; the customer controls the sensors, records, labels, and retention.

Proofmetry context

Supported sample hash, selected native behavior, analysis-derived observations, and known evidence limits.

Customer context

Observation time, endpoint outcome, sensor and product versions, alerts, labels, and analyst decisions.

Evaluation use

Feature research, model-development experiments, holdout evaluation, and regression analysis.

Governance

Customer-controlled collection design, privacy, retention, class balance, label review, and train/test separation.

Known limitations

• The analysis covers one Windows DLL variant and the mapped or observed paths described here.
• The processor architecture is not stated in Proofmetry’s public record.
• Directory enumeration and the alternate module-overloading path remained mapped-only.
• Seven observed paths do not mean seven endpoint effects were confirmed or seven customer behavior tests are available.
• Results do not establish behavior across every C2Looper version, environment, rule, model, or security product.

How C2Looper research relates to Proofmetry

This article reports Proofmetry’s internal C2Looper research. It is not a customer deployment record, and mapping a handler does not by itself mean that every C2Looper path is available in the product.

For a behavior test listed as currently available, Proofmetry is deployed in the customer’s lab and recreates the server-side C2 interaction expected by the customer-held sample. The sample performs the corresponding behavior; Proofmetry does not substitute a generic attack simulation.

Customers supply and retain the sample, enforce containment and egress policy, and operate the telemetry tools. Public material describes research scope and defensive outcomes; implementation and protocol details remain private.

View the C2Looper coverage record →

Revision history