Outlaw Linux Malware: Persistent, Unsophisticated, and Surprisingly Effective

Preface

OUTLAW is a persistent yet unsophisticated auto-propagating coinminer package observed across multiple versions over the past few years [1], [2], [3], [4]. Despite lacking stealth and advanced evasion techniques, it remains active and effective by leveraging simple but impactful tactics such as SSH brute-forcing, SSH key and cron-based persistence, and manually modified commodity miners and IRC channels. This persistence highlights how botnet operators can achieve widespread impact without relying on sophisticated techniques.

To gain deeper insights into OUTLAW’s behavior and operational patterns, we deployed a honeypot designed to attract and observe the attackers in action. By carefully crafting an environment that mimicked a vulnerable system, we were able to bait the adversaries into interacting with our server. This interaction revealed automated and manual actions, with operators entering commands directly, making modifications on the fly, and even mistyping commands—clear indicators of human involvement. A captured GIF showcases these moments, providing a rare glimpse into their real-time decision-making process.

By analyzing OUTLAW, we gain new insights into the tooling used by its operators and their evolving strategies over time. This malware presents a valuable opportunity to apply detection engineering principles, as its attack chain spans nearly the entire MITRE ATT&CK framework. Examining its infection process allows us to develop effective detection strategies that capitalize on its predictable and repetitive behaviors.

This report provides a full attack chain analysis, including detailed detection rules and hunting queries. By breaking down OUTLAW’s components, we demonstrate how even rudimentary malware can maintain longevity in modern environments and how defenders can leverage its simplicity to enhance detection and response.

Key Takeaways

Persistent but unsophisticated: OUTLAW remains active despite using basic techniques like SSH brute-forcing, SSH key manipulation, and cron-based persistence.
Commodity tooling: The malware deploys modified XMRig miners, leverages IRC for C2, and includes publicly available scripts for persistence and defense evasion.
Extensive attack surface: OUTLAW’s infection chain spans nearly the entire MITRE ATT&CK framework, offering many detection and hunting opportunities.
Worm-like propagation: OUTLAW uses its compromised hosts to launch further SSH brute-force attacks on their local subnets, rapidly expanding the botnet.

OUTLAW Overview

OUTLAW follows a multi-stage infection process that begins with downloading and executing its payload, establishing persistence, and expanding its botnet through SSH brute-force attacks. The execution chain is displayed below:

1. Initial Infection & Deployment

The attack starts when tddwrt7s.sh downloads the dota3.tar.gz package from a C2 server.
The extracted initall.sh script executes, kicking off the infection chain.

2. Gaining Control & Persistence

The malware ensures dominance by killing competing brute-forcers and miners.
It then deploys:
- Modified XMRIG for crypto mining (connecting to a mining pool).
- STEALTH SHELLBOT for remote control via IRC C2.
- BLITZ to perform SSH brute force attacks.

3. Propagation & Expansion

The brute-force module retrieves target lists from an SSH C2 server and attempts SSH brute-force attacks on new machines.
Successfully compromised systems are infected, repeating the cycle.

This automated infection loop allows OUTLAW to remain active and profitable with minimal effort from attackers. Let’s take a deeper look at the entire attack chain.

OUTLAW Execution Chain

OUTLAW effectively covers a wide range of tactics and techniques in the MITRE ATT&CK framework. This section maps its behavior to provide an overview of its infection chain and methods.

Initial Access: blitz

OUTLAW gains initial access through opportunistic SSH brute-forcing, targeting systems with weak or default credentials. The malware employs its blitz component, also known under other names such as kthreadadd, to perform high-volume scanning and password-guessing attempts. It leverages lists of target IPs and credentials retrieved from its C2 servers.

OUTLAW also acts like a worm, automatically installing itself on every system that it successfully compromises. This self-propagation mechanism allows it to spread rapidly across networks, turning each newly infected device into another node for further brute-forcing and infection attempts.

We will take a deeper look into how OUTLAW performs these attacks and propagates itself later in the article.

Execution: tddwrt7s.sh

The first infections of OUTLAW seem to originate from a straightforward dropper script: tddwrt7s.sh. This shell script checks for an existing installation. If the malware is already present and unpacked, it will run the initall script, kicking off the infection chain. Otherwise, it will attempt to download the package from a list of provided staging servers. For illustration purposes, a shortened snippet of the dropper is shown below:

The extracted dota3.tar.gz package extracts its contents into a hidden folder called .rsync, and contains the following entries:

 ├── a
 │   ├── a
 │   ├── init0
 │   ├── kswapd0
 │   ├── kswapd01
 │   ├── run
 │   ├── socat
 │   └── stop
 ├── b
 │   ├── a
 │   ├── run
 │   └── stop
 ├── c
 │   ├── blitz
 │   ├── blitz32
 │   ├── blitz64
 │   ├── go
 │   ├── run
 │   ├── start
 │   ├── stop
 │   └── v
 ├── init
 ├── init2
 └── initall

Let’s deconstruct the execution chains one by one.

Main Initialization script: initall

The three init scripts control the overall execution flow and deployment of the malware. Starting with the initall script, the main initializer determines which execution path to take. It checks the system environment and decides whether to use init or init2 based on file permissions and available directories.

These init scripts all use variable-based string concatenation obfuscation, where commands are split into small variable fragments that are dynamically concatenated and executed, making static analysis more difficult. For example, the initall script looks like this:

However, by changing the eval to an echo, we can get the output without any effort:

This script will, by default, consistently execute init. This is the primary execution path that installs the malware in the hidden directory ~/.configrc6. The fallback execution path is init2, which is used when ~/.configrc6 is inaccessible. The main difference is that this path keeps all components in the current working directory. Applying the same deobfuscation principle as we did previously, we end up with the following two scripts:

The first script (init) hides its components in the hidden directory ~/.configrc6, while the second script (init2) runs directly from the working directory. Despite this difference, the execution flow remains the same, starting the binary named a in the a/ and b/ directories as background processes and establishing persistence. In both scripts, the malware installs cron jobs that execute its binaries at regular intervals and on system reboots:

5 6 * * 0   ~/.configrc6/a/upd
@reboot     ~/.configrc6/a/upd
5 8 * * 0   ~/.configrc6/b/sync
@reboot     ~/.configrc6/b/sync
0 0 */3 * * ~/.configrc6/c/aptitude

Although the scripts execute the a binary in the a/ and b/ directories nearly simultaneously, we will follow the execution flow of the a/ directory first.

Subroutine Execution of a/ directory: XMRIG

The first script that is executed is a, which removes any existing cron jobs using crontab -r and then stores the current working directory in a variable. It then creates a shell script called upd that checks if a process (stored in bash.pid) is still running. If the process is not running, it executes ./run as a background process, ensuring that the malware is continuously restarted if terminated.

Additionally, we see some commented commands, indicating that other versions of this malware may exist under names such as rsync, go, kswapd0, blitz, and redtail.

Further down the script, a function is created that checks if /sys/module/msr/parameters/allow_writes exists and sets it to "on" to enable writing to Model-Specific Registers (MSRs). If the file does not exist, it enables MSR writes through the modprobe msr allow_writes=on command.

Next, the function identifies the active CPU by checking /proc/cpuinfo and applies specific MSR register values to optimize performance.

Finally, the function optimizes memory usage by enabling hugepages for all CPU cores, increasing memory access efficiency. It calculates the number of hugepages needed based on the available processors (nproc) and sets them in the /sys/devices/system/node/node*/hugepages/ directories.

The optimize_func() function was not created by the threat actor. The threat actor used an open-source script from the XMRig repository, specifically the randomx_boost.sh script, to aid in their infection chain.

Depending on the user's privileges, it will either run the whole optimization function, or attempt to set the number of hugepages through sysctl:

All steps performed in this chain show apparent signs of cryptocurrency mining system optimization. Finally, the script grants execution permissions to the upd file and "777" permissions to all files in its folder and runs upd.

As we saw earlier in the chain, the upd file checks whether the process stored in bash.pid is still running, and if it is not, it will execute the run script:

The run script will start the stop script, which is a typical script that bring down the defenses of any known miner configurations any known miner configurations and kill any known miner processes based on name/process ID or network traffic. A shortened version of this script is illustrated below:

Interestingly enough, a second process-killing script called init0 is present, which is an open-source script for killing cryptocurrency miners in a Linux environment. This script is not being run, as the execution flow for this script was commented out in the a script.

After the stop script has been successfully run, the run script starts the kswapd01 and kswapd0 binaries in the background via nohup.

kswapd01

The kswap01 binary plays a critical role in ensuring persistent communication within the malware’s infrastructure. Its main task is to monitor and maintain a continuous socat process, which is essential for communication with the attacker’s C2 servers.

When executed, kswap01 checks for any existing socat processes running on the infected machine. If no active connection is found, it proceeds to kill any running socat processes and selects an alternative IP address from a predefined list. The binary then establishes a new connection by launching a fresh socat process to listen on the local machine and forward traffic to a remote server, typically on port 4444. This ensures the malware maintains control over the infected system and can continue receiving commands from the attacker.

However, it's important to note that not every version of the OUTLAW malware package observed includes the socat binary. In these cases, the functionality provided by socat is either replicated by other means or simply omitted, relying on alternative methods for maintaining persistence and communication.

By performing these checks and modifications, kswap01 helps maintain the persistence of the C2 connection, making it harder for defenders to interrupt the communication channel between the attacker and the compromised system.

kswapd0

The file named kswapd0 is a maliciously modified copy of the legitimate XMRig cryptocurrency miner (specifically version 6.22.1).

Two major modifications define the malware’s behavior:

1. Startup Shell Commands

The malware removes and recreates the victim’s ~/.ssh folder, injects an attacker-controlled SSH public key, and re-applies restrictive permissions (chattr +ia) to prevent modification. This grants persistent SSH access.
It also removes or locks existing XMRig configuration files (e.g., ~/.xmrig.json, ~/.config/xmrig.json) to ensure the attacker’s embedded miner settings remain intact.

2. Embedded Miner Configuration

The binary is compiled with an internal mining configuration, allowing XMRIG to run without an external config file.
Mining traffic is routed to multiple Monero pools over plaintext ports (:80, :4444), SSL (:442), and occasionally TOR addresses. Note that the port 442 here is not a typo.
The configuration optimizes performance by:
- Running the miner in the background
- Enabling large pages for RandomX
- Setting the donation level to zero
- Maximizing CPU thread usage

By locking out administrators, preventing config changes, and injecting an attacker-controlled SSH key, kswapd0 serves as a stealthy persistence mechanism — allowing for continuous Monero mining and unauthorized remote access, all while masquerading as a legitimate system process.

Subroutine Execution of b/ directory: STEALTH SHELLBOT

As we described earlier, the a binary in the b/ directory was also executed via the init scripts.

This script kicks off another stop script with the same purpose we described earlier: kill any known bad processes. Afterward, it creates a script called sync, with the sole purpose of executing the run script. This script is referenced in the cronjob we described earlier. The run script contains three base64-encoded blobs, which are piped to perl. An example of a shortened script is shown below:

Upon base64 decoding, obfuscated perl scripts are identified. These scripts leverage a public Perl Obfuscator utility to obfuscate their contents, making them harder to analyze:

Fortunately, the author left the standard comments in the obfuscated scripts. By using the publicly available deobfuscator we can deobfuscate the script through the following command:

perl decode-stunnix-5.17.1.pl < obfuscated_run.pl > deobfuscated_run.pl

After which we can view the deobfuscated contents:

This is just the first few lines of the script, for illustrative purposes. This deobfuscation technique can also be used for the other obfuscated Perl scripts used by OUTLAW. We will take a closer look at these scripts in just a moment.

The script ends off with installing its own SSH public key for persistent access, setting restrictive permissions, and making the directory immutable to prevent modification through chattr:

STEALTH SHELLBOT Scripts

The STEALTH SHELLBOT scripts used in OUTLAW are not custom-built but rather publicly available IRC bot scripts, often sourced from old GitHub repositories and underground forums. These scripts have been around for over a decade, originally designed for remote administration, automation, and botnet management. However, they have since been repurposed by malware authors for malicious activities.

SHELLBOT scripts operate as IRC-based backdoors, allowing attackers to remotely control infected machines via predefined commands sent through an IRC channel. Once connected to the attacker’s IRC server, these bots can:

Execute arbitrary shell commands
Download and execute additional payloads
Launch DDoS attacks (in older variants)
Steal credentials or exfiltrate system information
Manage crypto miners or other malware components

OUTLAW integrates these legacy SHELLBOT scripts as a secondary persistence mechanism, ensuring that even if its brute-force modules are disrupted, attackers still retain a remote foothold. The bot connects to an attacker-controlled IRC C2, where it listens for further commands, enabling on-demand execution of malicious actions.

While these scripts are not novel, their continued use highlights how attackers rely on publicly available tools rather than developing new malware from scratch.

Subroutine Execution of c/ directory: Customer Bruteforcer

As part of the third and final sub-routine, a custom bruteforce tool is deployed. This chain starts, similar to the previous sub-routines, from the init and init2 scripts. These scripts both call the start script, containing the following contents:

This script stores the current working directory, provides all permissions (777) to all files in the current directory, and creates a script named aptitude (which is also called by the previously set up cron job), to run the run script. After creating aptitude, it is granted execution permissions and is run.

The run script is used to gather CPU architecture information and count CPU cores to determine execution behavior, as shown below:

If the system is x86_64, it checks whether the CPU has fewer than 7 cores, introducing a randomized delay before executing ./go in the background. If 7 or more cores are detected, execution is skipped or altered (with a previously used binary golan now commented out). The threat actor may have been testing or working with a Golang binary that can make full use of the number of cores present in a system, but that is just a guess.

In most scenarios, the execution flow moves to the bash script called go:

The script determines the CPU architecture and assigns a thread count accordingly:

ARM-based systems → 75 threads
i686 (32-bit x86) → 325 threads
All others (default) → 475 threads

It then enters an infinite loop, executing the following actions:

Creates and cleans up temporary files (v, p, ip, xtr*, a.*, b.*).
Writes hardcoded values (257.287.563.234 and sdaferthqhr34312asdfa) into files c and d.
Waits for a random delay (1-30 seconds) before launching blitz.
Executes blitz for 3 hours with specified parameters (-t $threads suggests multi-threaded processing).
Performs post-execution cleanup, removing temporary and log files before repeating the cycle.

BLITZ

OUTLAW is a self-propagating worm that spreads laterally through SSH brute-force attacks using BLITZ, its custom-built brute-forcer. Designed for aggressive, automated credential attacks, BLITZ systematically scans for and compromises systems with weak or default SSH credentials, allowing the malware to expand its foothold with minimal attacker intervention.

BLITZ Execution Process

Upon execution, BLITZ follows a structured attack sequence:

IP Target and Credential Retrieval
- BLITZ contacts an SSH C2 server to fetch a list of target IPs and credential pairs.
Brute-Force Authentication & System Profiling
- Using multi-threaded SSH brute-forcing, BLITZ attempts to authenticate with stolen credentials.
- Once access is gained, it:
  - Changes the user’s password for persistent access.
  - Executes system reconnaissance commands, collecting:
    - User privileges
    - CPU details
    - SSH banner information
    - OS version
  - Exfiltrates gathered data to the C2 server.
Subnet Scanning & Lateral Movement
- The malware scans the local subnet of newly compromised systems, identifying additional SSH-accessible machines to attack.
Self-Replication & Malware Deployment
- Instead of downloading from an external C2, BLITZ directly transfers the dota3.tar.gz malware package from the infecting host to the new victim, reinforcing persistence and minimizing reliance on external infrastructure.

By combining automated brute-force attacks, system profiling, subnet scanning, and direct malware transfer, BLITZ maximizes infection efficiency while ensuring continued network expansion.

Binary Analysis & C2 Communication

Beyond brute-force operations, analysis reveals that BLITZ executes its tasks by interacting with system shell commands and an embedded SSH library. Once connected to a compromised system, it queries the C2 server for updated targets and relays authentication data.

Additionally, OUTLAW incorporates a hardcoded SSH key for C2 authentication, which must be unlocked using the password "pegasus". Upon successful authentication, Blitz logs attack details into a "v" file, structured as follows:

This log contains:

Original username and password used in the attack.
The victim’s IP address and the new password set by the malware.
SSH port and OS details, including CPU specifications.

Once BLITZ completes its scanning cycle, the "v" file is exfiltrated to an SSH C2 server, providing attackers with a continuously updated list of infected systems.

Post-Compromise

To analyze the attacker’s post-compromise behavior, we deliberately set up a honeypot and proactively uploaded its credentials to the same SSH C2 server used by the attacker. This effectively invited the attacker into our controlled environment, allowing us to closely monitor their subsequent actions.

A few days after BLITZ successfully brute-forced and set a new password on the honeypot system, we observed a remote login using these credentials. The login originated from 212.234.225[.]29. The attacker immediately performed basic reconnaissance by running the w command to check who was logged in and then executing ps to see what processes were running. In the course of typing commands, they made a small typo and killed the prompt with a quick Ctrl+C, indicating a manual interaction rather than an automated script at this stage. Next, the attacker pasted a series of commands to download a fresh copy of dota3.tar.gz via wget, unpacked it, and executed the newly fetched script.

This whole chain of activity can be displayed through session view, an investigation tool that allows you to examine Linux process data organized in a tree-like structure according to the Linux logical event model, with processes organized by parentage and time of execution. It displays events in a highly readable format that is inspired by the terminal. This makes it a powerful tool for monitoring and investigating session activity on your Linux infrastructure and understanding user and service behavior.

The attack chain displayed above mirrors the original infection method, suggesting that the attacker was either updating components or re-infecting the host to maintain persistence. Soon after verifying that the updated payload was running, the attacker disconnected from the host, leaving behind an environment primed for continued SSH brute-forcing, cryptocurrency mining, and remote control via IRC.

This brief login serves as a reminder that even unsophisticated campaigns can include pockets of interactive attacker activity—a manual "quality check" of sorts—underscoring the importance of timely detection and swift containment.

Detecting OUTLAW through MITRE ATT&CK

OUTLAW is a Linux malware that relies on SSH brute-force attacks, cryptocurrency mining, and worm-like propagation to infect and maintain control over systems. While not highly sophisticated, it covers a broad range of MITRE ATT&CK techniques, making it an effective case for detection engineering.

This section maps OUTLAW’s attack chain to MITRE ATT&CK, highlighting Elastic SIEM and endpoint rules and threat-hunting queries that can identify its activity at different stages.

OUTLAW follows a structured infection flow:

Initial Access – SSH brute-force against weak credentials.
Execution – Runs malicious scripts to kick off several stages of malware infection.
Persistence – Installs cron jobs and modifies SSH keys.
Defense Evasion – Hides in hidden directories, modifies file permissions, uses packing techniques, command encoding, and obfuscates scripts.
Credential Access – Modifies credentials and injects public SSH keys.
Discovery – Enumerates user, system, and hardware details.
Lateral Movement – Spreads via internal SSH brute-force and malware transfer.
Collection & Exfiltration – Collects and exfiltrates system data to its C2.
Command and Control – Uses socat and STEALTH SHELLBOT for C2 communication.
Impact – Launches XMRIG to mine cryptocurrency and leverages the infected host as a brute-force node.

The following sections detail detection strategies for each technique, helping defenders effectively identify and mitigate OUTLAW’s infections.

TA001: Initial Access

OUTLAW gains initial access through opportunistic SSH brute-forcing, targeting systems with weak or default credentials. Elastic pre-built detection rules can successfully detect this method of initial access. These include:

Additionally, there are several rules based on authentication logs to detect suspicious SSH authentications:

Besides relying on detections, it is important to incorporate threat hunting into your workflow. Elastic Security provides several hunting queries using ES|QL and OSQuery, publicly available in our Detection Rules repository, specifically in the Linux hunting subdirectory. For example, the following two hunts may help in identifying different stages of the attack:

TA002: Execution

After gaining initial access, OUTLAW executes a series of scripts and binaries to establish control. Upon downloading and unpacking, we detect:

The STEALTH SHELLBOT script is detected through:

Script Executed Through Unusual Parent Process

Additionally, the malware executes multiple suspicious system commands, triggering:

Suspicious System Commands Executed by Previously Unknown Executable

TA003: Persistence

This combination of cron-based execution and SSH key manipulation allows OUTLAW to maintain a persistent foothold on compromised systems. Both of these persistence techniques are extensively researched in our "Linux Detection Engineering - A primer on persistence mechanisms" publication. We can detect these techniques through the following SIEM and endpoint rules:

Additionally, we can hunt for these techniques through the following ES|QL and OSQuery hunts:

TA005: Defense Evasion

OUTLAW employs multiple defense evasion techniques to avoid detection. One of its primary methods is Base64 decoding, which is detected through the following pre-built rules:

Additionally, the malware's binaries are packed with UPX, reducing their size and altering their signature to evade traditional malware detection. Once the malware unpacks in memory, this is detected through our general malware detections.

Continuing down the execution chain, the malware creates several hidden files and directories and modifies them using chattr:

We can further enhance detection through the following hunting query:

Hidden Process Execution

TA006: Credential Access

OUTLAW maintains persistent access to a compromised system by manipulating credentials. Following successful SSH brute-force authentication, the malware replaces the existing SSH authorized_keys file with a new version containing a malicious SSH public key, thereby granting persistent access. This is detected through the following signals:

The malware then changes the user credentials for the authenticated account by entering a new password using the passwd utility:

Linux User Account Credential Modification

TA007: Discovery

OUTLAW gathers system information upon successful infection to profile the compromised environment. The malware executes various commands to collect details about the system’s CPU, user privileges, operating system, memory usage, and available binaries. This reconnaissance step helps the attacker assess the system’s capabilities and determine how best to utilize the compromised machine. These are all detected through several building block rules, as listed in our rules_building_block directory. Below is a short list of the most important ones triggered by OUTLAW:

The default interface settings do not include building block rules due to their relatively high noise levels. However, these rules can be enabled to assist in the identification of potential threats.

TA008: Lateral Movement

OUTLAW malware spreads through a compromised network by carrying out internal SSH brute-force attacks. We can identify this behavior through the following ES|QL rules:

Once a system is successfully brute-forced, the malware package, dota3.tar.gz, is deployed from the infected host to the new target. The local subnet is then scanned for additional targets to ensure the malware's continued propagation.

Elastic pre-built detection rules can identify these lateral movement attempts:

Additionally, upon copying the OUTLAW malware to a remote host, malware prevention alerts kick in.

TA009: Collection & TA010: Exfiltration

OUTLAW collects basic system information, credentials, and SSH details from compromised machines, primarily for tracking infected hosts and facilitating further attacks. This data is stored in a simple text file before being uploaded to a C2 server. Since this collection activity is limited to gathering system details and writing them to a file, it is not inherently suspicious on its own.

Exfiltration occurs when OUTLAW initiates an outbound SSH connection via sftp-server to transfer the collected information to a predefined C2 server. While this may resemble normal SSH activity, we can detect suspicious execution of file transfer utilities through ES|QL:

Unusual File Transfer Utility Launched

TA011: Command and Control

OUTLAW maintains communication with its C2 infrastructure through multiple channels, allowing attackers to issue commands, exfiltrate data, and manage infected systems. We can detect several of the utilities used by the malware through the following rules:

The same hunting queries that were relevant for detecting the malware’s initial access attempts, can also be used to hunt for this C2 activity. Additionally, the following hunting queries can be used:

TA040: Impact

OUTLAW impacts infected systems by consuming CPU resources for cryptocurrency mining and performing SSH brute-force attacks to propagate. Several CPU and memory optimizations are attempted before launching the modified XMRIG mining software, including enabling MSR write access and setting kernel parameters such as hugepages. These modifications can be detected through the following rules:

As OUTLAW attempts to enable MSR write access via modprobe but lacks the required permissions, kernel driver-related rules are triggered:

These rules directly monitor for init_module() and finit_module() syscalls, through Auditd. For more information on how to set up the Auditd Manager integration to capture driver events and much more, check out the Linux Detection Engineering with Auditd publication.

Simultaneously, SSH brute-force attempts are launched from the infected host, triggering:

Potential Malware-Driven SSH Brute Force Attempt

Throughout its execution, OUTLAW runs kill scripts to terminate competing malware or leftover processes from previous infections. This behavior triggers:

Indicators of Compromise (IOCs)

The complete set of indicators can be found as a bundle on Github.

Yara Signatures

rule Linux_Hacktool_Outlaw_cf069e73 {
    meta:
        author = "Elastic Security"
        description = "OUTLAW SSH bruteforce component fom the Dota3 package"
        reference_sample = "c3efbd6b5e512e36123f7b24da9d83f11fffaf3023d5677d37731ebaa959dd27"
      
    strings:
        $ssh_key_1 = "MIIJrTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQI8vKBZRGKsHoCAggA"
        $ssh_key_2 = "MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAECBBBC3juWsJ7DsDd2wH2XI+vUBIIJ"
        $ssh_key_3 = "UCQ2viiVV8pk3QSUOiwionAoe4j4cBP3Ly4TQmpbLge9zRfYEUVe4LmlytlidI7H"
        $ssh_key_4 = "O+bWbjqkvRXT9g/SELQofRrjw/W2ZqXuWUjhuI9Ruq0qYKxCgG2DR3AcqlmOv54g"
        $path_1 = "/home/eax/up"
        $path_2 = "/var/tmp/dota"
        $path_3 = "/dev/shm/ip"
        $path_4 = "/dev/shm/p"
        $path_5 = "/var/tmp/.systemcache"
        $cmd_1 = "cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'"
        $cmd_2 = "cd ~; chattr -ia .ssh; lockr -ia .ssh"
        $cmd_3 = "sort -R b | awk '{ if ( NF == 2 ) print } '> p || cat b | awk '{ if ( NF == 2 ) print } '> p; sort -R a"
        $cmd_4 = "rm -rf /var/tmp/dota*"
        $cmd_5 = "rm -rf a b c d p ip ab.tar.gz"
    condition:
        (all of ($ssh_key*)) or (3 of ($path*) and 3 of ($cmd*))
}

SIEM and Endpoint Rules Overview by MITRE ATT&CK Tactic

Technique ID	Description
TA001: Initial Access	Potential External Linux SSH Brute Force Detected Potential Successful SSH Brute Force Attack Successful SSH Authentication from Unusual SSH Public Key Successful SSH Authentication from Unusual User Successful SSH Authentication from Unusual IP Address
TA002: Execution	File Downloaded from Suspicious Source by Web Server Linux.Trojan.Pornoasset Script Executed Through Unusual Parent Process Suspicious System Commands Executed by Previously Unknown Executable
TA003: Persistence	Cron Job Created or Modified SSH Authorized Keys File Modification Potential Persistence via File Modification
TA005: Defense Evasion	Base64 Decoded Payload Piped to Interpreter Unusual Base64 Encoding/Decoding Activity
TA006: Credential Access	SSH Authorized Keys File Modification SSH Authorized Keys File Deletion Linux User Account Credential Modification
TA007: Discovery	Linux System Information Discovery
TA008: Lateral Movement	Potential Port Scanning Activity from Compromised Host
TA009 & TA010: Collection & Exfiltration	Unusual File Transfer Utility Launched
TA011: Command and Control	Socat Reverse Shell or Listener Activity
TA040: Impact	Suspicious Kernel Feature Activity

Conclusion

OUTLAW exemplifies how even unsophisticated malware can persist and scale effectively in modern environments. Despite lacking advanced evasion techniques, its combination of SSH brute-force attacks, self-replication, and modular components allows it to maintain a long-running botnet. OUTLAW ensures continuous expansion with minimal attacker intervention by leveraging compromised hosts to propagate infections further.

Our honeypot experiment provided a rare glimpse into the attacker's real-world behavior, confirming that while much of OUTLAW’s operation is automated, there are moments of direct human interaction. The ability to observe manual commands, reconnaissance attempts, and even simple typographical errors highlights an often-overlooked aspect of botnet maintenance—operator-driven quality control. These insights reinforce the need for detection strategies that account not just for automated attacks but also for manual post-compromise activity.

By understanding how OUTLAW operates, spreads, and monetizes infections, defenders can develop robust detection strategies to mitigate its impact. This report provides actionable SIEM rules, threat-hunting queries, and forensic insights, enabling security teams to stay ahead of similar evolving threats.

References

[1] CounterCraft, DOTA3 Malware Again and Again

[2] Juniper Networks, DOTA3: Is Your Internet of Things Device Moonlighting?

[3] SANS ISC, Hygiene Hygiene Hygiene

[4] Darktrace, Outlaw Returns: Uncovering Returning Features and New Tactics