Abyssos v2.1F: from C2 tasking to endpoint evidence

The analyzed Abyssos v2.1F sample

Zscaler ThreatLabz identified Abyssos in late June 2026 and included a v2.1F sample in its August 10 report, Abyssos: Technical Analysis of a New Modular RAT. Zscaler’s detailed technical narrative examines v2.4F; the version-specific findings below come from Proofmetry’s independent analysis of the listed v2.1F binary.

Proofmetry examined the 64-bit Windows sample in an isolated research environment. Its C2 traffic was redirected to a loopback service, and neither the embedded external endpoint nor third-party profile services were contacted.

Methodology

Proofmetry mapped the v2.1F dispatcher and constructed a fixed 25-scenario research matrix. The native client ran in an isolated 64-bit Windows environment with C2 traffic redirected to a loopback service. Each scenario was evaluated separately for path reach, meaningful results, defined terminal states, and corroborated endpoint or network effects.

A reached path was not automatically counted as an endpoint effect. The 23-outcome aggregate includes a corroborated result, terminal state, or endpoint effect, while the two screen-control effects remained explicitly unclaimed.

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. Twenty-three corroborated outcomes must not be restated as 23 endpoint effects. The published aggregate spans results, terminal states, and endpoint effects.

Abyssos v2.1F evidence matrix

What the native Abyssos client revealed

The full command vocabulary and transport construction are intentionally omitted. The useful public findings are the endpoint effects, lifecycles, and evidence boundaries that detection teams can carry into their own environments.

1. One long-lived process produces several classes of telemetry

   The same sample process produced host inventory alongside recurring process and connection-owner inventories, plus file, collection, shell, and desktop activity. Treating each event in isolation loses the stronger behavioral sequence.

2. A command-family label can misstate the host effect

   One family could be mistaken for port forwarding, but its observed behavior inventoried sockets and owning processes. Its related control action terminated a process by PID; the port value described the record but did not drive the termination.

3. File operations need direction and effect, not one generic label

   Across fixed file cases, the sample returned file contents to C2, wrote C2-supplied bytes to disk, copied and deleted files, and built both memory-only and on-disk archives. Those distinctions change what endpoint and network sensors should see, and where analysts should look for corroboration.

4. Stop and disconnect paths do not share one result pattern

   Some lifecycle stops ended a worker without an ordinary command result, while the disconnect path ended the process and reset the session. A completed network exchange is therefore not enough to establish the endpoint outcome.

5. Process state can change whether C2 activity appears

   Initialization was environment-sensitive in the tested process. The sample file remained unmodified, but during validation the analyst had to load a standard Windows cryptography module into the sample process before its native transport initialized. An initial run with no network activity would have understated the sample’s capability.

6. Screen-control claims require effect-specific proof

   The remote-desktop quality task arrived in the intended sequence, but a perceptual image-quality change was not independently measured. Hidden-desktop input reached dispatch and orderly teardown, but cursor movement was not independently observed. Neither effect is claimed here.

Behavior-category summary

Evaluating detections against Abyssos behavior

The strongest evaluation joins the selected sample behavior to the records produced by the customer’s deployed controls. The goal is not a universal pass or fail; it is to determine what was observed, what alerted, and whether the evidence supports an investigation.

• Process lineage and time. Preserve one timeline across the long-lived sample process, recurring inventory, and later task-driven effects.
• Process and connection ownership. Correlate socket-owner snapshots with process control instead of assuming a network-oriented label means traffic forwarding.
• File and collection effects. Distinguish reads, writes, copies, deletes, archives, uploads, clipboard access, and collection results.
• Desktop activity. Join desktop creation, capture, image encoding, input dispatch, and lifecycle termination where the customer’s sensors expose them.
• Outcome-aware testing. Preserve task delivery, command result, terminal state, and endpoint effect as separate observations.
• Version pinning. Attach detections and test conclusions to the v2.1F hash; do not assume behavior reported for v2.4F is present here.

Using Abyssos telemetry in customer-owned datasets

Customer-operated tools—not Proofmetry—collect and retain ETW, EDR, API-sequence, packet-capture, 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.

Evidence status

Separate labels for statically mapped, path reached, result observed, terminal state observed, and endpoint effect confirmed.

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 applies to one Abyssos v2.1F sample and should not be transferred to v2.4F or another build without version-specific evidence.
• The 23-outcome aggregate spans results, terminal states, and endpoint effects; it is not a count of 23 confirmed endpoint effects.
• The remote-desktop quality change and hidden-desktop cursor movement were not independently observed and are not claimed.
• Additional statically mapped paths were not executed and are not presented as observed behavior.
• Initialization was environment-sensitive in the tested process.
• Twenty-five research scenarios do not mean 25 customer behavior tests are available. Abyssos customer availability is not currently listed.

How Abyssos research relates to Proofmetry

This article documents Proofmetry’s internal Abyssos research, not a list of currently available customer tests. The 25 scenarios are an analysis result; they should not be read as 25 product-supported workflows.

For a behavior test subsequently listed as available, Proofmetry is deployed in the customer’s lab and recreates the server-side C2 interaction expected by the customer-held sample. The original malware 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; protocol construction, command grammar, underlying research records, and product implementation remain private.

View the Abyssos v2.1F coverage record →

Revision history