THREAT ALERT: Crypto miner attack involving RinBot’s server, a popular Discord bot

Watch On Demand! FIND, FOCUS, and FIX the Cloud Threats that Matter with Accenture, AWS, Expel, Snyk, Sysdig and SANS

The Sysdig Security Research team has identified crypto mining activities coming from the server hosting the popular RinBot Discord bot.

Update 2021-01-28 06:00
There is a RinBot completely unrelated to the one involved in the attack. It just happens to be a popular name.
The administrator of the affected bot server contacted us, he is investigating the issue. In the meantime he has disconnected the server.

Discord is a free app for mobile and computers that lets people chat via text, voice, or video in real time. With more than 100 million active users during 2020, Discord is extremely popular among young people and gamers, and the COVID-19 outbreak just catalyzed this success. It was only a matter of time before attackers targeted this app’s ecosystem.

The Discord community admins improve the app experience by installing third-party integrations (called bots). These integrations are hosted by particulars, outside of the Discord infrastructure.

We suspect RinBot’s server, one of those integrations, was compromised and is acting as a command and control server for the dk86 malware, deploying the xmra64 crypto miner.

This attack confirms what we’ve been seeing for quite some time: Crypto miner attacks are on the rise, and they come in many different forms. The fact that crypto currency prices are over the roof is only making things worse.

We’ve been covering cryptomining attacks in random AWS regions for a while. What sets this incident apart is that the command and control (C&C) server wasn’t a random machine, but a somehow public server hosting a Discord bot.

In this article, learn what Discord is and why it’s so popular, the details of this particular attack, and how to protect your infrastructure against it.

How to mitigate this attack?

If you are a System administrator, or are hosting a Discord bot, we recommend you familiarize yourself with the Indicators Of Compromise of this attack, and use a runtime security tool that can detect open ports and suspicious processes. Again, these C&C attacks to enable crypto mining are increasing lately.

If you are a Discord community administrator, you should check if you installed the affected bot and remove it. Although we have no proof that your users data has been leaked, the truth is that the Bot’s server is compromised, and that’s a dangerous place to be.

If you are a Discord user, you should be ok as nothing points to a leak. However, if you joined a server that is using the compromised bot, ask your admin to remove it. Also, remember that bots are not required to store your personal information in a secure manner. Be really careful on what information you share in front of a bot.

You can picture Discord as the Slack for gamers. Over the years, it has evolved into a social network for all types of communities — think of what Reddit would be if it were a chat instead of a forum.

Each Discord server is a community with several thematic channels, similar to Slack. The biggest difference is the voice and video channels. With just one click, you are already talking with your friends. There’s no need to start a call, share an invite link, troubleshoot connectivity issues, etc.

This ease-of-use, mixed with the need for remote communication during COVID-19, made Discord so popular. It grew from 56 million active users in 2019 to 100 million in 2020, so it was only a matter of time that the Discord ecosystem was targeted for a crypto mining attack.

Discord bots are hosted by third parties

As most popular chat apps, Discord can be extended with third-party services called bots. They appear as a special chat user, and they can perform tasks as simple as notifying that the admin is now live on Twitch, or as complex as full conversation-based games.

List of the most popular Discord bots

The logic behind those bots runs outside of Discord servers.

Anyone can create a bot and run it from their home computer, given that they are connected to the internet. Of course, you’ll probably run your bot from a proper server in a cloud provider. We just wanted to highlight two things with the “home computer” example:

  • This a security issue on a third-party that can contain data from Discord users, thus, data from those Discord users might be compromised. When you create a bot, there is no requirement to certify that you are protecting that data correctly.
  • Requirements to create a bot are minimal. So, many young people, unaware of the security implications of maintaining a server, are hosting such programs.

Attacks coming from the RinBot server

RinBot is one of these integrations, and we identified crypto mining activities associated with its web server.

Note that there are several Discord bots called “RinBot”! We can only speculate whether this is a popular name or a phishing tactic. Here is the website linked with this particular bot:

Homepage of the compromised RinBot server

The attack uncovered went as follows:

  1. The malware dk86 landed in our honey pot, and was quickly detected.
  2. dk86 opened the 59000 port and awaited for commands.
  3. It created a cronjob to reinstall itself if it gets deleted.
  4. Then dk86 spawned a new process called 0kuh3auhftebvtd.
    1. This new process established a connection to IP address 45.132.242.40.
    2. Navigating to that address takes us to the RinBot website https://rinbot.online
  5. dk86 received orders to install the crypto miner binary xmra64.
  6. Then the xmra64 binary starts mining cryptocurrency, connected to a pool on the 185.165.171.78 IP address.

The diagram below summarizes the attack flow:

Attack flow, xk86 spawns a child process. That process installs the miner and sends the mining information back to the c2 server

Keep reading to discover how this process works in detail, the exact commands that are run, and the communication between the servers.

At the end, we’ll cover how to detect this attack with open source Falco.

How did we uncover the attack, and link it to RinBot?

#1 The dk86 malware came first

Right when the dk86 malware landed in the Sysdig Secure honey pot, it was detected by the Sysdig Secure DevOps Platform that monitors that server, and caught our attention quickly.

There are 34 reports of the dk86 tool as malware

This binary was reported for the first time on Jan. 16 2021, and 34 intelligence sources have confirmed that it is, indeed, malware.

If this were a regular production server, we would have immediately removed the binary, investigated the source, and enhanced our security. With this being a honeypot, we followed the malware to discover its end goal.

#2 dk86 was just a backdoor

The role of the dk86 malware is to open a backdoor that can be used to further compromise the server.

The dk86 malware opens a port, and will wait and listen for commands.

We are using Sysdig Inspect, an open source tool to visualize system calls, to follow what dk86 is doing:

The dk86 malware listens to the 59000 port

There, we see that the listening port is 59000. This looks strange because normal services listen on ports with lower numbers, like 80, 443, 8080, or 3306.

#3 dk86 ensured its persistence

A typical way for a malware to continue to thrive in the victim’s environment, even after it gets deleted, is to create a cronjob for persistence.

Here we can see dk86 editing the server’s crontab:

The dk86 malware edits the system crontab so it gets reinstalled when removed

The same technique has been found in the kinsing attack.

#4 The RinBot server acts like the command and control server

The dk86 malware then spawned a new process called 0kuh3auhftebvtd. This new process establishes connections to the 45.132.242.40 IP address.

This is an indicator of a process waiting for instructions from a command and control (C&C) server. Before we dig into the actual commands that were sent over that connection, let’s investigate this suspicious server.

Navigating to this IP from a web browser takes us to https://rinbot.online, which promotes a Discord bot. It looks somehow popular, as it’s installed in ~5k Discord servers. Note that a Discord server is a Discord community, not necessarily an actual server (physical or process).

Homepage of the compromised RinBot server

So, what is RinBot, this particular Discord bot, about?

Data of the compromised RinBot, it is used in 5k servers

It looks like a card game using a Discord bot as an interface.

Is this really a malicious bot?

If so, hiding it in plain sight seems odd. Let’s search for RinBot in a Discord bot search engine to see if we can get more context.

Data of another RinBot, it is used in 15k servers

We found another bot with the same name that seems to be more popular, installed in about 16.8k servers.

Update 2021-01-28 06:00 This second bot is completely unrelated to the one involved in the attack. After a conversation with the maintainer we realized it is just a coincidence that they share the same name.

And the mystery intensifies.

Is this a phishing attack? Is RinBot just a popular name? Nothing indicates that the actual bot is malign.

Our best theory yet is that the bot site was hacked and now serves as a C&C for malwares without being aware of it.

#4 What did the C&C communication from the RinBot server look like?

We’ll table the RinBot mystery for now, as we need more information to draw conclusions.

Let’s continue with something we actually know. What commands did the server send to our honeypot?

Here is the initial communication between the process 0kuh3auhftebvtd and the RinBot web server.

Example of c2 commands

It resembles other malware and C&C protocols, capturing information about the target and communicating back with updated attack payloads.

#5 Then, with xmra64, the crypto mining started

Crypto mining is the next action the malware took.

First, the 0kuh3auhftebvtd process spinned a shell. There, it executed the wget command to download the crypto miner binary xmra64.

xmra64, the crypto miner, is downloaded an installed with wget

Once downloaded, 0kuh3auhftebvtd prepared the binary for execution. We can see how it used chmod to set the execution bit.

The execution bit is set on xmra64 so it can be executed

XMRA64 is a known crypto miner:

xmra64 has 35 reports of being malware

Two crypto miner pools were specified when launching the crypto miner binary:

  • 185.165.171.78
  • 185.86.148.14

However, only 185.165.171.78 was contacted by xmra64 while we captured the syscall activities. As with the kinsing attack, a json-rpc protocol was used:

The payload to log into the miner server pool, as well as negotiating mining mechanism, was:

data={"id":1,"jsonrpc":"2.0","method":"login","params":{"login":"x","pass":"x","agent":"XMRig/3.2.0 (Linux x86_64) libuv/1.37.0 gcc/9.3.0","algo":["cn/1","cn/2","cn/r","cn/wow","cn/fast","cn/half","cn/xao","cn/rto","cn/rwz","cn/zls","cn/double","rx/0","rx/wow","rx/loki"]}}

A payload with the job to execute the mining looked like:

data={"jsonrpc":"2.0","method":"job","params":{"blob":"0e0ee8f8ac8006718f0d677e4f85155330770e0f706692f08289a3aaec765734c3581b1206544a000000d092acba4472d8e596c7350855bd7ec044de7d8d63338a29553b69a96b719474362c","job_id":"770586838907405","target":"d4140000","algo":"rx/0","height":2280299,"seed_hash":"0514f72f2a974747530032b853d52f3220a6a575da98d9bcbeab63fba18668b9"}}

Heartbeat status updates are sent periodically:

data={"id":4,"jsonrpc":"2.0","method":"keepalived","params":{"id":"12e1cee6f72569b2"}}

And xmra64 submits back the results with:

data={"id":3,"jsonrpc":"2.0","method":"submit","params":{"id":"12e1cee6f72569b2","job_id":"231516882834987","nonce":"281d00d0","result":"f58edffae1406a45e1867cd7f758f9e71d23ddb7b29e85be45bcf4239a0b0000","algo":"rx/0"}}

We also saw how the 0kuh3auhftebvtd sends the mining information back to the RinBot web server.

The malicious process sending mining data back to the c2 server

In the screenshot above, we see that at least the miner pool IP and the mining algorithm were sent back to the RinBot web server (45.132.242.40). However, we still don’t have enough information to conclude that 45.132.242.40 (or https://www.rinbot.online/) is a malicious C&C server.

It is highly possible that the RinBot server was hacked, and their admins are unaware of this malicious activity.

One thing does stand out from other similar attacks; that server receiving back the mining information from a malware is highly suspicious.

Summary of IOC and suspicious activities

IPs & URLs

  • http://178.62.105.90:80/wp-content/themes/twentyfifteen/xmra64
  • 185.86.148.14:8081
  • 185.165.171.78:8081

MD5

  • dk86: 8b13ce9b843a5e9ee63d2df42eebd74b
  • xmra64: 497f4e24464a748c52f92de1fba33551

Suspicious activities

A few suspicious activities worth mentioning:

  • An unknown process listen on port 59000.
  • wget is launched, especially inside a container during run time (not build time).
  • A network communication to a miner pool.
  • A CPU usage surge due to an unknown process launched.

Detecting malware dk86 with Falco and Sysdig

Falco is the CNCF open-source project for runtime threat detection for containers and Kubernetes.

One of the benefits of Falco is in leveraging its powerful and flexible rules language. As a result, Falco will generate security events when it finds abnormal behaviors as defined by a customizable set of rules. Meanwhile, Falco comes with a handful of out-of-the-box detection rules.

# Note: falco will send DNS request to resolve miner pool domain which may trigger alerts in your environment.
- rule: Detect outbound connections to common miner pool ports
  desc: Miners typically connect to miner pools on common ports.
  condition: net_miner_pool and not trusted_images_query_miner_domain_dns
  exceptions:
    - name: proc_sport_sipname
      fields: [proc.name, fd.sport, fd.sip.name]
  enabled: false
  output: Outbound connection to IP/Port flagged by cryptoioc.ch (command=%proc.cmdline port=%fd.rport ip=%fd.rip container=%container.info image=%container.image.repository)
  priority: CRITICAL
  tags: [network, mitre_execution]

- rule: Container Drift Detected (chmod)
  desc: New executable created in a container due to chmod
  condition: >
    chmod and
    consider_all_chmods and
    container and
    not runc_writing_var_lib_docker and
    not user_known_container_drift_activities and
    evt.rawres>=0 and
    ((evt.arg.mode contains "S_IXUSR") or
    (evt.arg.mode contains "S_IXGRP") or
    (evt.arg.mode contains "S_IXOTH"))
  exceptions:
    - name: proc_name_image_suffix
      fields: [proc.name, container.image.repository]
      comps: [in, endswith]
    - name: cmdline_file
      fields: [proc.cmdline, fd.name]
      comps: [in, in]
      values:
        - [["runc:[1:CHILD] init"], [/exec.fifo]]
  output: Drift detected (chmod), new executable created in a container (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode event=%evt.type)
  priority: ERROR

- rule: Outbound Connection to C2 Servers
  desc: Detect outbound connection to command & control servers
  condition: outbound and fd.sip in (c2_server_ip_list)
  exceptions:
    - name: proc_proto_sport
      fields: [proc.name, fd.l4proto, fd.sport]
  output: Outbound connection to C2 server (command=%proc.cmdline connection=%fd.name user=%user.name user_loginuid=%user.loginuid container_id=%container.id image=%container.image.repository)
  priority: WARNING
  tags: [network]

You can check the full rule descriptions on GitHub.

The Sysdig Secure DevOps Platform is built on top of Falco, and was used to detect this particular attack.

With the help of Sysdig Secure image profiling, DevOps can:

  • Create a policy to detect any port bind and listen activities from random processes.
  • Create a policy to detect any destination IPs which are not in the white list (e.g., the RinBot IP).
  • Create a policy to detect any processes launched which are not in the whitelist (e.g., wget, dk86, xmra64).

With the help of Sysdig Monitor, teams can monitor resource usage closely and create alerts to be notified when a CPU usage surge is detected.

A Sysdig monitor dashboard monitoring our honeypot resources. The CPU increase related to this attack is noticeable.

In our honeypot, the CPU usage surged from 68% to about 100% in just 10 minutes. And we also were able to pinpoint the surge to the container f3d71e24c0fa.

Conclusion

This incident confirms a trend of crypto mining attacks being on the rise, and they are getting more creative as time goes on.

As a Discord user, or any chat platform user, you are affected indirectly. Your devices and accounts are safe, but the servers running bots are vulnerable. As bots have access to personal data (like user profiles and public messages), if their servers are compromised, your information might as well be. Now more than ever, chat platforms must be vigilant and gate what information is available to bots.

As a system administrator, you must use the proper tools to detect these attacks. Without deep insight into the process activities, file activities, and network activities from your cloud native environment, and the help from a smart detection engine, it will be hard to detect such an attack. It will be even more difficult to uncover it.

It is also important to note that unified security and monitoring solutions will speed up the investigation process. Once you identify a single suspicious event, it helps you trace down the event from different angles, such as resource usage, network connections, and reading sensitive files.

The Sysdig Secure DevOps Platform provides security to confidently run containers, Kubernetes and cloud services. With Sysdig you can secure the build pipeline, detect and respond to runtime threats, continuously validate compliance, and monitor and troubleshoot cloud infrastructure and services. Try it today!

Stay up to date

Sign up to receive our newest.