The ZENITH Kit

What it does

From our isolated-lab detonations (VirtualBox, network-fenced and watched) plus public sandbox data:

• Anti-analysis gate. The analyzed build does nothing unless launched with --check or --check-gui. Bare sandbox runs see a clean exit. It queries firmware tables for VM detection and watches for analysis tools while it is being watched.
• Persistent victim ID. Drops %LOCALAPPDATA%\QuartzLine\terrain.dat, an INI-looking decoy settings file whose last line carries a per-victim UUID: zenith=<uuid-v4>. Scheduled-task persistence observed by a third party.
• Beacon, then silence. HTTPS POST to a small per-build domain set, then radio silence. No User-Agent header. We never observed a tasking response in days of lab time; tasking appears to be hand-driven by an operator against chosen victims.
• Execution. Operator-driven commands via cmd.exe /e:ON /v:OFF and CreateProcessW with redirected I/O. PowerShell execution reported by a third party.
• Collection. Host profiling, browser-profile targeting (--user-data-dir= machinery and profile field tables), file reads, and an update/second-stage channel (register_setup, update_pre_download, update_post_download).
• The update channel is live in the wild. On a victim endpoint on 2026-10-15 we found the replaced binary sitting beside its own .old copy: in-place self-update, confirmed outside any lab. That endpoint also carried a previously unseen second build of the QuartzLine viewer, distinct from the sample already analyzed.
• Payload staging. One observed pull from chrome-history-backup.s3.us-east-2.amazonaws.com (third-party report).

How it's built

Rust with a Slint UI, reqwest/hyper over native TLS, serde_json, gzip-compressed update payloads, per-install UUID v4 campaign IDs. Builds run through hosted CI runners, and the source tree is deliberately obfuscated into single-letter paths.

The detail that matters for analysts: the crate manifest contains no cryptography library at all. The configuration obfuscation is hand-rolled, and the C2 configuration never exists in the file in any static encoding. It is constructed in memory at runtime. If your static analysis finds no C2 strings, that is expected. You did not miss them; they were never there.

Network grammar is https://<apex-domain>/<constant>/<word>. Constants observed: piglet and quarry. Words observed: flange, trestle, deposit, vein, with more held in config (stratum, gravel, bedrock, sandstone, seam per a third-party analysis).

Seven front doors, all painted shut

Seven apex domains, one registrar, registered in scripted batches (two of them 27 seconds apart), staged for months, then activated together with wildcard certificates in the second week of October. Six are C2 nodes: five behind Cloudflare, one behind AWS Global Accelerator. The seventh, beatramiro.com, is the delivery and referral node. It was registered in the same minute as another cluster domain, shares its nameserver pair, and it is the link that hands victims off to the Amazon-hosted payloads. Lure, payload staging, and C2 are one operator's pool end to end.

Here is what makes this infrastructure nasty to study: it hides on purpose, and it discriminates by client. Measured from three vantage points (a cloud VM, two scanner services, several countries):

who is knocking                          what they get
---------------------------------------  --------------------------------------------
bare tools (curl, scanners)              HTTP 403 + provider error page, or a
                                         TLS-layer reset on the accelerator node
browser-shaped traffic                   empty HTTP 200; the site looks dead
scanner services, manual submissions     refused outright: connection accepted,
                                         zero bytes served, even on the delivery node
the implant's exact client profile       the real answers

Read that as a defender: a 403, a timeout, or an empty 200 tells you nothing about whether this C2 is alive. The accelerator-fronted endpoint even refuses to complete TLS handshakes with non-implant clients. Stock tooling gets its handshake reset outright. If your sandbox beacon dies at the TLS layer against this family, that is expected behavior, and it is still evidence of an infection attempt.

The client-gating is deliberate anti-analysis tradecraft, and it is also a fingerprint. Infrastructure that answers exactly one TLS client shape, hands browsers empty-200 decoys, and blocks scanner ranges by IP is rare. If you see that pattern on some other cluster, look twice: it may be the same builder.

The distributed binaries carried a valid Extended Validation code-signing certificate at issuance. That certificate has since been revoked by the issuing CA (reason code: Privilege Withdrawn, backdated to the certificate's own start date), so revocation-aware tooling now flags the signature. We are watching certificate-transparency logs for a replacement identity; nothing had appeared as of this update.

The checklist

• DNS/proxy logs for the seven apex domains and the URL paths below
• Hosts carrying %LOCALAPPDATA%\QuartzLine\terrain.dat, or file content containing zenith=
• Process trees: document-viewer binaries spawning cmd.exe or powershell.exe, or creating scheduled tasks
• Viewer-branded executables in user-writable paths whose version info does not match their UI, especially X.exe + X.exe.old pairs (the in-place update artifact)
• TLS client fingerprint (JA3, observed sandbox build): 77a72092553b69e9b4c07d7be0767517
• HTTPS POSTs to these domains with no User-Agent header and text/plain content type

If you find a hit: treat it as a potential credential compromise until IR clears it. Preserve before cleaning: disk, memory, the terrain.dat file, the mail or document delivery chain, DNS and proxy logs. Rotate exposed credentials from a clean device. Then share what you found; the indicator set gets stronger every time someone does.

IOC block

Domains (C2):
  motherotters.com
  healskills.com
  westbeavers.com
  flawlessgradecheered.com
  tabbyottercub.com
  topsmagnificentgrade.com

Domains (delivery/referral):
  beatramiro.com

URL paths:
  /quarry/deposit   /quarry/vein   /quarry/sinter
  /piglet/flange    /piglet/trestle
  (config-only vocabulary: stratum, gravel, bedrock, sandstone, seam)

Payload staging:
  chrome-history-backup.s3.us-east-2.amazonaws.com

Files:
  quartzline.exe (build 1)  SHA256 7f1db334fd3302cf98dd4afddf6f90e98e2a496fe7e86bf1832b89d02f3d73c3
  quartzline.exe (build 2)  SHA256 25ea334b75beede8dcab4c4460313c3013c35e55c16cd066231d80ecfe4c0653
  caira.exe                 SHA256 74aaa6b54133bbb2e77b2ae874e9900a907c269058f798a0a1197288ba1f7124
                            MD5   66cd7c21dea2279463d0111b40bc1055

Host artifacts:
  %LOCALAPPDATA%\QuartzLine\terrain.dat
  zenith=<uuid-v4>  (persistent victim ID)
  <name>.exe + <name>.exe.old pairs (in-place self-update)
  Scheduled tasks staging viewer-branded binaries

Network:
  JA3 77a72092553b69e9b4c07d7be0767517
  HTTPS POST, no User-Agent, text/plain

A family detection rule is public on YARAify (CLOUDHAZE_Kit_RustSlint_20261014), and the domains and paths are filed on ThreatFox under the CLOUDHAZE cluster. If you have a sample, a sighting, or a question, reach out. This campaign is active, and every set of eyes shortens its life.