port22

mdrfckrs – part two

mdrfckrs – part two

The contents of this post takes place from December 2022 and continues as of the time of publishing.

Preface

Please go read part one of this series for context.

Continuation with the new commands

The mdrfckr-saga continues with changes in methodology from the mdrfckr-botnet. The purpose of this post is to once again provide a way to fingerprint the botnet via hassh.

Initially, a change is observed on 2022-12-07 18:07:32. Two new commands are included in the replacement of the ssh keys on the system. The first looks like this:

cd ~ && chattr -ia .ssh && lockr -ia .ssh && rm -rf .ssh && mkdir .ssh && 
 "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7V
vAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0E
pZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgL
Muakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmP
ecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGP
K5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWY
YjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr"
>>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~

Compared to the previously observed command from part one, the ‘chattr’ and ‘lockr’ commands are added.

‘chattr’ is a tool used to change attributes on files (meaning directories as well) on linux systems. The switches ‘-ia’, do different things;

First, the switch ‘-i’ removes the immutable attribute on the directory. If the directory was immutable, it would have the following features enabled:

  • Cannot be deleted
  • Cannot be renamed
  • Cannot be modified in any manner, unless super user privileges are provided

The ‘-a’ switch removes the ‘no append’ flag from the directory. If the directory was appendable, it would be possible to append an ssh key into the authorized_keys file to enable passwordless login via ssh.

Together, if these two commands are allowed to execute with the right permissions, enable the threat actor to:

  • Delete the .ssh directory
  • Rename the .ssh directory
  • Modify the directory

As the command above states, the threat actor is doing this to delete the directory and write a new authorized_keys file. This is why the commands ‘chattr’ and ‘lockr’ are positioned in the beginning of the command run, prior to the deleted of the .ssh folder (with rm -rf).

It has not been possible to verify what ‘lockr’ exactly is. However, seeing as the switches used are the same and that the positioning of the command is before the main command observed in part one, it is feasible to believe it is a tool similar to ‘chattr’.

Observations of the new variant(s)

This is where things get odd.

The first new variant has been observed 37 times from a mere 12 unique IPs, and only between 07-12-2022 and 22-12-2022. This is the variant initially described above and visualized below on a per-day basis.

However, the second and third version of the command are split versions of the first one.

The second new version appears as such:

cd ~; chattr -ia .ssh; lockr -ia .ssh"

Using Splunk, the following command is run to establish how many unique IPs are seen using this per day: 

input="cd ~; chattr -ia .ssh; lockr -ia .ssh"
| dedup src_ip
| timechart span=1d count

Over the period, a total of 28970 unique IPs have been seen running this command.

The third new version runs ‘lockr’ alone:

lockr -ia .ssh

Using Splunk again, the following command is run to establish how many unique IPs are seen using this per day: 

input="lockr -ia .ssh"
| dedup src_ip
| timechart span=1d count

Over the period, a total of 28978 unique IPs have been seen running this command.

The two new variants of ‘chattr’ and ‘lockr’ are run next to the original version covered in part one of this saga.

Last, a new method of removing security features enabled on the system is added.

Briefly, in the early days of december 2022, the following command was observed as being run:

rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh; pkill -9 secure.sh; pkill -9 auth.sh; echo > /etc/hosts.deny; pkill -9 sleep;

And visualized by running:

input="rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh; pkill -9 secure.sh; pkill -9 auth.sh; echo > /etc/hosts.deny; pkill -9 sleep;"
| dedup src_ip
| timechart span=1d count

The file ‘secure.sh’ is a possible reference to https://github.com/ChrisTitusTech/secure-linux/blob/master/secure.sh.

First, the command executes ‘rm -rf’ on the file /tmp/secure.sh to forcefully remove it. Next, it does the same to the file located in /tmp/auth.sh.

Furthermore, ‘pkill -9’ is run on both files to ensure any PID related to the names ‘secure.sh’ and ‘auth.sh’ are killed immediately. After removing the scripts and killing the associated processes, an empty entry is made into the /etc/hosts.deny file, creating it if it does not already exists, or overwriting all data in it with nothing, if the file already exists.

Last, any running process currently using ‘sleep’ is killed.

As seen in the graph above, this methodology fell off quickly.

hassh

The newly observed sessions of the new variant has a new hassh fingerprint. Instead of it being 51cba57125523ce4b9db67714a90bf6e, matching SSH-2.0-libssh-0.6.3 and SSH-2.0-libssh-0.6.0, used previously, it has now changed to f555226df1963d1d3c09daf865abdc9a, matching SSH-2.0-libssh_0.9.6 and SSH-2.0-libssh_0.9.5.

A simple Splunk query is made to get the number of unique source IPs associated with the hassh vaue.

hassh = f555226df1963d1d3c09daf865abdc9a
| dedup src_ip

A little over 30000 unique IPs. The timeline covering the last post, and the previous hassh, it peaked at a little under 13000.

In part one, the risk of getting a mdrfckr with only the hassh as an identifier was 99.1%. Now, with more data, it is not as clear. It is now at 94.5%, based on the data above, for the new hassh.

Closing thoughts

It is observed that the new commands splitting the first new version observed are run in unison, even though that means ‘lockr’ is run twice.

The ‘authorized_keys’ file is unchanged from part one.

In conclusion, the botnet has changed the ssh client used and split the commands executed into multiple commands run, which now include ‘chattr’ and ‘lockr’.

Indicators (from part one as well)

Commands run:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr
cd ~; chattr -ia .ssh; lockr -ia .ssh
lockr -ia .ssh
rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh; pkill -9 secure.sh; pkill -9 auth.sh; echo > /etc/hosts.deny; pkill -9 sleep;

Files observed:

authorized_keys  a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2
hosts.deny 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b (empty file)

Clients observed:

SSH-2.0-libssh-0.6.3 and SSH-2.0-libssh-0.6.0 51cba57125523ce4b9db67714a90bf6e 
SSH-2.0-libssh_0.9.6 and SSH-2.0-libssh_0.9.5 f555226df1963d1d3c09daf865abdc9a
←
→