GitLab CDN Xmrig distribution campaign

Executive summary

A blocklist can't touch gitlab.com, and this attacker knew it. Instead of standing up their own C2 infrastructure, they pointed victims at GitLab's own release CDN and let a public repository do the hosting, one unmodified Xmrig build at a time, on a schedule regular enough to set a clock by.

Over a 14-day window, sensors observed an attacker using GitLab's release CDN as a malware distribution channel for Xmrig cryptominer binaries. The attacker (34.67.58.31, a Google Cloud IP, AS396982) downloads multi-arch Xmrig static builds from gitlab.com/Kanedias/xmrig-static — a public GitLab repository that maintains pre-compiled Xmrig binaries. By using the /permalink/latest/ URL path, the attacker always receives the newest build without hardcoding version numbers or maintaining their own distribution infrastructure.

This pattern represents an emerging class of supply-chain-adjacent threats where attackers weaponize legitimate software distribution platforms. Traditional IP blocklists and domain blocklists cannot block gitlab.com without disrupting legitimate development workflows. The binaries appear to be genuine upstream Xmrig static builds — fetched directly over HTTPS from GitLab's own CDN, with no evidence of attacker tampering in the delivery path. That does not make them invisible to AV: once VirusTotal indexes a build, most of these releases are flagged by roughly 40-60% of engines under generic miner/PUA signatures (see Sample inventory). Indexing lags days behind each weekly build, though, and the weekly hash rotation means a fresh release still enjoys a detection-free window right after publication — so defenders need behavioral indicators (mining pool, wallet, process name) rather than a file-hash blocklist alone.

Threat actor profile

Post-publication update (queried 2026-07-03): the same source IP and ADB delivery script produced a fourth wave on 2026-07-01 ~09:45 UTC (aarch64, x86_64, and armv7 samples confirmed; no i686 sample was captured that round). This confirms the weekly cadence continued beyond the 3-wave window this report otherwise covers; the tables and IOCs below are scoped to waves 1-3 (2026-06-10 through 2026-06-24) as originally published.

Infrastructure analysis

  ┌──────────────────────────────────────────────────────────────────┐
  │  GitLab CDN as malware distribution channel                      │
  └──────────────────────────────────────────────────────────────────┘

  Attacker 34.67.58.31 (Google Cloud)
       │
       │  ADB (Android Debug Bridge, port 5555) shell session → execute
       │  download command
       ▼
  gitlab.com/Kanedias/xmrig-static/-/releases/permalink/latest/downloads/
       │
       ├── xmrig-x86_64-static   (9.8 MB)  → /tmp/xmrig
       ├── xmrig-i686-static     (10.9 MB) → /tmp/xmrig
       ├── xmrig-aarch64-static  (8.8 MB)  → /tmp/xmrig
       └── xmrig-armv7-static    (6.1 MB)  → /tmp/xmrig

  Why this matters:
  • gitlab.com cannot be blocklisted without impacting development workflows
  • /permalink/latest/ → always gets newest build, no version pinning
  • Binaries are authentic Xmrig — not modified — so hash-based detection rotates weekly
  • The loader picks ONE architecture per victim from the target's reported ABI
    (getprop ro.product.cpu.abilist* / uname -m) rather than dropping all four

Sample inventory

Wave 3 — 2026-06-24 (latest)

Wave 2 — 2026-06-17

Wave 1 — 2026-06-10

Note: Binary sizes are identical across all three waves for x86_64, aarch64, and armv7. Only i686 differs: wave 1's build is 10,940,852 B, exactly 4 KB smaller than the 10,944,948 B i686 build shipped in waves 2 and 3, indicating a build-system change between the wave 1 and wave 2 releases. SHA256 hashes differ across all waves because the repository publishes a new build weekly, and the /permalink/latest/ URL resolves to whatever is newest at fetch time.

VirusTotal analysis

Wave 3 (2026-06-24) samples are not yet indexed by VirusTotal as of this writing (2026-07-03). Three of the four Wave 1 (2026-06-10) samples are also still unindexed — the exception is the aarch64 build (69b36a4c...), now flagged by 37 of 63 engines. Wave 2 (2026-06-17) samples were already flagged when first checked on 2026-06-23 and remain flagged on a live recheck: all four Wave 2 hashes are currently detected by roughly 25-37 of 52-64 VirusTotal engines — ca90747a... (armv7): 33/61, popular threat name miner.xmrig/abminer; 45ab548e... (i686): 33/59, miner.bitcoinmi/r002c0dfc26; 1a0b0bb8... (x86_64): 37/64, miner.xmrig/bitcoinmi; 1eb84954... (aarch64): 25/52, miner.r002c0dfb26/xmrig. Detections are generic miner/PUA signatures (Application.Linux.Miner, ELF:Miner-EQ, Multi.Cryptominer.Xmrig) rather than a named custom-malware family, which is consistent with these being genuine, unmodified Xmrig builds — but not consistent with an assumption that unmodified builds evade AV entirely. Xmrig is open-source miner software with both legitimate and malicious use cases, and most AV vendors flag it generically once a build is indexed, regardless of whether that specific binary was tampered with. The practical takeaway for defenders is unchanged: file-hash IOCs from this campaign have a short shelf life, both because the repository ships a new signed build every week and because VirusTotal indexing itself lags days behind each release.

Behavioral significance

The threat is not in the binary itself (Xmrig is well-documented) but in the distribution method. Using GitLab's release CDN provides several advantages to the attacker:

• Blocklist evasion: gitlab.com cannot be blocked without impacting legitimate development
• TLS by default: All GitLab downloads use HTTPS — content inspection sees encrypted traffic
• Content delivery: GitLab's CDN provides fast, reliable downloads from any region
• No infrastructure to maintain: The attacker doesn't need their own C2 server for distribution
• Auto-updating: /permalink/latest/ always fetches the newest build without code changes
• Hash rotation: Weekly build publishing means hash-based IOCs rotate automatically, and VT indexing lags each release by days

MITRE ATT&CK mapping

Campaign timeline

The ~09:40 UTC timing across all observed waves suggests a scheduled task (cron) on the attacker's system. The consistent 7-day interval (Jun 10 → 17 → 24 → Jul 1) confirms weekly automation.

Indicators of compromise

Network — IPs

Network — URLs

Network — mining pool

Monero wallet

File — SHA256 hashes (Wave 3 — 2026-06-24)

File — SHA256 hashes (Wave 2 — 2026-06-17)

File — SHA256 hashes (Wave 1 — 2026-06-10)

Behavioral indicators

Detection signatures

Suricata — GitLab Xmrig distribution

# NOTE: the downloads observed in this campaign are HTTPS (port 443). The
# URI-path variant below only fires where Suricata has visibility into
# decrypted HTTP (e.g. behind a TLS-interception/SSL-bump proxy). Without
# TLS interception, use the SNI-only variant -- it is lower fidelity
# (matches all gitlab.com TLS traffic, not just this download path).

# Variant 1 -- SNI-only, works on encrypted traffic as observed in this campaign
alert tls $HOME_NET any -> $EXTERNAL_NET 443 (
  msg:"cowrAI GitLab CDN traffic (possible Xmrig static-build download, SNI-only)";
  flow:to_server,established;
  tls.sni; content:"gitlab.com";
  classtype:trojan-activity; sid:9003030001; rev:2;
)

# Variant 2 -- URI-path match, requires decrypted HTTP visibility
alert http $HOME_NET any -> $EXTERNAL_NET 443 (
  msg:"cowrAI GitLab CDN Xmrig static-build download (decrypted HTTP)";
  flow:to_server,established;
  http.host; content:"gitlab.com";
  http.uri; content:"Kanedias/xmrig-static";
  content:"permalink/latest"; distance:0;
  content:"xmrig-"; distance:0;
  content:"-static"; distance:0;
  classtype:trojan-activity; sid:9003030002; rev:1;
)

YARA — Xmrig static build identifier

rule Xmrig_Static_Build_From_GitLab {
  meta:
    description = "Xmrig static build distributed via GitLab CDN"
    author = "cowrAI"
    date = "2026-06-24"
  strings:
    $xmrig1 = "xmrig" ascii nocase
    $xmrig2 = "Donate to support the project" ascii
    $xmrig3 = "RANDOMX" ascii
    $build1 = "Kanedias/xmrig-static" ascii
  condition:
    ($xmrig1 and $xmrig2 and $xmrig3) or $build1
}

eBPF / Falco — Xmrig process detection

- rule: Xmrig Process Running (GitLab CDN campaign)
  desc: Detect xmrig matching this campaign's observed launch pattern.
        Binary is left named "xmrig" (not renamed) and invoked with a
        MoneroOcean-style pool/worker.
  condition: proc.name = "xmrig" or \
             (proc.cmdline contains "xmrig" and proc.cmdline contains "--donate-level") or \
             proc.cmdline contains "fr-zephyr.miningocean.org" or \
             proc.cmdline contains "-p vipminer"
  output: "Xmrig miner detected (pid=%proc.pid name=%proc.name cmdline=%proc.cmdline)"
  priority: WARNING

Collection methodology

Data collected by a distributed honeypot fleet running SSH, Telnet, and protocol-specific lures. This campaign was captured specifically via the fleet's ADB (Android Debug Bridge, port 5555) lure, not SSH. Post-authentication commands were captured at the application layer, including the URLs used to download malware binaries. Downloaded files were automatically hashed and archived for analysis. The GitLab distribution pattern was identified by correlating download URLs across multiple sensors (3 distinct honeypots observed the recon/download sequence in Wave 1 alone) and confirming the weekly cadence.