Cyble uncovers ShadowHS, a stealthy fileless Linux framework running entirely in memory for covert, adaptive post‑exploitation control.

Khushal

Level 15
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
731
4,568
1,369

ShadowHS (per Cyble’s write-up dated January 30, 2026) is described as a Linux post-exploitation framework that emphasizes “fileless”/in-memory execution, interactive operator control, and heavy defense-awareness rather than loud, automated propagation. ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))

What stands out technically (defender view)
  • A multi-stage POSIX shell loader that decrypts/decompresses a payload and executes it from memory via anonymous file descriptors under /proc/<pid>/fd (i.e., not written to disk in the normal way). ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • Masquerading/OPSEC behavior such as argv[0] spoofing, and actions aimed at reducing forensic traces (history/artifacts). ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • A “weaponized hackshell” style interactive environment with extensive discovery, including broad EDR/AV/service discovery. ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • Dormant/on-demand capabilities mentioned in the report include credential access, lateral movement, privilege escalation tooling, and crypto-mining modules (activated as needed). ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))

IOCs shown in the report (use for hunting/blocking where appropriate)
From the “Indicators of Compromise (IOCs)” section: ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • 91.92.242[.]200 (IPv4) – “Primary payload staging infrastructure” ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • 62.171.153[.]47 (IPv4) – “Operator-controlled relay for exfiltration and post-compromise operations” ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • SHA-256 20c1819c2fb886375d9504b0e7e5debb87ec9d1a53073b1f3f36dd6a6ac3f427 – “Main obfuscated shell loader script” ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • SHA-256 9f2cfc65b480695aa2fd847db901e6b1135b5ed982d9942c61b629243d6830dd – “Custom weaponized hackshell payload” ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))

Practical detection / response ideas (Linux)
Because the behavior is described as fileless and operator-driven, focus more on telemetry and behavior than “did an on-disk file get caught”:
  • Process execution from /proc/<pid>/fd/* (and unusual short-lived file descriptors executing code). ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • Unexpected reconnaissance utilities or renamed binaries (the report mentions tools like rustscan/spirit and renaming to “-bash”). ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • SSH hardening and review: check auth logs for brute-force patterns and new keys/users; rotate SSH keys and credentials if compromise is suspected (especially on internet-facing hosts).
  • Network hunting: search historical DNS/proxy/firewall logs for any connections to the listed IPs; consider blocking them at egress where feasible. ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))
  • If you have EDR/eBPF/auditd/SIEM: alert on “shell doing crypto/miner-like activity,” suspicious screen sessions, and post-compromise discovery bursts (service enumeration, security-agent discovery). ([cyble.com](https://cyble.com/blog/shadowhs-fileless-linux-post-exploitation-framework/))

About the VirusTotal link
I can’t reliably view VT’s vendor detection table from the page you linked (it loads dynamically on VirusTotal), so I can’t confirm the detection ratio or which engines flag it from my side. A safe way to continue the discussion is to paste the current “X/YY” detection count and a few of the detection names, or share a screenshot of the VT detections section.

If this hash/IP appears in your environment, treat it as a potential intrusion (not just a “malware file”) and prioritize isolation + log collection, then incident-response steps (credential rotation, persistence checks, and rebuilding from a trusted image if you confirm compromise).

Sources
 
Technical Analysis & Remediation

MITRE ATT&CK Mapping

Execution

T1059.004 (Unix Shell)
T1620 (Reflective Code Loading).

Defense Evasion
T1027 (Obfuscated Files or Information)
T1036.005 (Masquerading - argv[0] spoofing).

Command and Control
T1090 (Proxy: User-space tunneling via GSocket/rsync).

Operational Mechanics

Loader

A multi-stage POSIX shell script that checks for dependencies (openssl, perl, gunzip).

Decryption
It uses an embedded AES-256-CBC key to decrypt the payload in memory.

Anchor Literal 1 (Key)
C-92KemmzRUsREnkdk-SMxUoJy8yHhmItvA.

Anchor Literal 2 (Header) S1A76XhLvaqIQ+7WsT+Euw==.

Execution
The payload is executed directly via anonymous file descriptors (/proc/<pid>/fd/<fd>) to avoid touching the disk.

Persistence & Exfiltration
Utilizes "hackshell" variants for covert tunneling, bypassing standard firewalls by encapsulating traffic within legitimate rsync activity.

Forensic Indicators (IOCs)

Infrastructure (IPv4)

91.92.242[.]200 (Staging), 62.171.153[.]47 (Relay).

File Hashes (SHA-256)

Loader
20c1819c2fb886375d9504b0e7e5debb87ec9d1a53073b1f3f36dd6a6ac3f427.

Payload 9f2cfc65b480695aa2fd847db901e6b1135b5ed982d9942c61b629243d6830dd.

Remediation - THE ENTERPRISE TRACK (SANS PICERL)

Phase 1: Identification & Containment

Hunt Strategy

Search for processes running from /proc/*/fd/* rather than standard binary paths. This is a primary signature of ShadowHS execution.

Network Isolation
Block egress to 91.92.242[.]200 and 62.171.153[.]47. Monitor for anomalous rsync traffic that may actually be tunneled C2 data.

Process Analysis
Inspect processes masquerading as python3 or -bash. Check the actual binary linkage; if a "python" process is actually a shell script running from memory, terminate it immediately.

Phase 2: Eradication

Memory Flush

Since the malware is memory-resident, a full system reboot will clear the active payload. However, this must be preceded by an investigation into persistence mechanisms.

SSH Key Rotation
The malware creates an "attack surface" by using tools like rustscan and spirit to brute-force SSH. Assume all active SSH keys and credentials on the host are compromised and rotate them.

Persistence Check
Although the loader is fileless, operators may leave backdoors. Audit ~/.ssh/authorized_keys, cron jobs, and systemd services for re-infection scripts.

Phase 3: Recovery

Credential Reset

Reset credentials for any cloud services (AWS, Yandex Cloud, OpenStack) accessed by the host, as ShadowHS explicitly targets these for theft.

Patching
Ensure the kernel is patched against known local privilege escalation vulnerabilities, as ShadowHS retrieves kernel exploits from its C2 to gain root.

Phase 4: Lessons Learned

Detection Engineering

Implement detection rules for "hackshell" signatures and execution of shell commands piping encrypted data to openssl.

Remediation - THE HOME USER TRACK

Priority 1: Safety (Kill the Process)

If you suspect infection (e.g., high CPU usage from hidden miners like LolMiner or XMRig), reboot your machine immediately. This malware lives in RAM.

Priority 2: Identity (Credential Hygiene)
ShadowHS steals credentials from your home directory (~/.ssh, browser data). Change passwords for any services you access from that Linux machine, especially SSH keys and cloud accounts.

Priority 3: Persistence
Check your startup files. Look for suspicious lines in your .bashrc, .profile, or user cron tabs (crontab -l). The malware needs a way to restart itself after you reboot.

Hardening & References

Baseline

Disable Unused Interpreters: If a server doesn't need perl or openssl CLI access for users, restrict them. ShadowHS relies on these explicitly for decryption.

Mount Restrictions
Mount /proc with hardening options if possible (though difficult on general purpose systems), and use noexec on temporary directories where loaders might be staged initially.

Tactical
Command Line Logging. Enable auditd or shell logging to capture the initial loader command, which is often a long one-liner involving openssl enc -d.

References

Cyble Research & Intelligence Labs (CRIL)

Framework References

MITRE ATT&CK

The analysis references several techniques, including:

T1059.004
(Unix Shell)

T1620
(Reflective Code Loading)

T1036.005
(Masquerading)

Link
attack.mitre