The Proteus botnet emerged toward the end of November 2016. Only a few samples of it were found in the wild and, at the moment, it doesn’t seem to have a widespread campaign. So, what does it do? It launches a multi-layered attack on an infected machine where it runs several processes aimed at coin mining, credential theft, and keylogging. In addition, the bot can perform on its own; it offers the cybercriminal to send commands over HTTP to download malicious executables and execute them.
In some samples, the botnet disguises itself as a Google Chrome executable. The functionality of the botnet is highly reliant on its C&C (command and control) server, hxxp://proteus-network[.]biz or hxxp://proteus-network[.]ml (the latter is inaccessible). The URL is hardcoded in the sample and is contacted multiple times to obtain necessary credentials for the tasks the botnet performs. The host name also appears in Pastebin, under the URL hxxp://pastebin[.]com/raw/LidbEiiR, in its encrypted form, and the botnet can retrieve the domain from there as well.
The botnet starts by identifying the infected machine and obtaining the operating system’s info (whether 64 or 86 bit), the machine’s name, and the Windows version. All of the information is sent to the C&C to “register” the machine.
After the machine is acknowledged by the C&C, the botnet proceeds to perform different tasks. As the botnet contacts the C&C to receive various pieces of information, the web requests are sent along with an encrypted string specifying the purpose of the request. These encrypted strings perform the following functions:
- api/register – Register the infected machine
- api/ping – Check if the machine is already registered
- api/module – Check the mining module
- api/proxy – Use reverse proxy
- api/command – Receive commands from the C&C
- api/account – Receive an account from the C&C
- api/log – Handle the key logging document
The header section of the HTTP requests is similar throughout the different sections of the source code:
When contacting the C&C, a POST request is sent with one of the above modes appended to the domain’s name, for example, hxxp://proteus-network.biz/api/log. The C&C sends a response to this request, which is then parsed by the botnet in search for the C&C’s reply.
The CheckerTask starts by contacting the C&C with the api/account string appended to the domain’s name. After sending a POST request, it receives a four-tuple composed of an account ID, an e-mail, a password, and the account type. The botnet attempts to access and steal the user’s credentials from a number of online websites, including:
The majority of these websites are German-based and the botnet searches for German words appearing in the responses. This leads us to believe this specific sample of Proteus targets are German victims. For example, if the message received from the website includes the phrase “stimmen nicht mit den bei uns hinterlegten Daten”, which means, “This does not match the data provided by us”. The botnet attempts to change the password’s first character from lower case to upper case or to append the character “1” to the end of the password and tries to log in again after three seconds. The response from the website is then checked to harvest more information about the victim, including name, address, country, bought and sold items, seller type and the last feedback received.
Some of the websites which the CheckerTask tries to steal the credentials from may include a Captcha to prevent such automated logins. The Proteus botnet uses Death by Captcha (DBC), an API which solves any given Captcha and turns it into a text that the botnet can insert into the website, and proceeds with the login. Using DBC requires a username and a password, which are both hardcoded into the sample to enable Captcha analysis. We have managed to access the DBC account used in the sample, and found that it resolved 200 Captchas so far, which could hint to the number of successfully infected machines.
This task performs key logging on the infected machine. It starts by initializing a list of all the keyboard keys, and stores the logged keys into a file called tmpV213.txt found under the TEMP directory. When this file includes more than 250 characters, it is cleared and its content is sent to the C&C along with the api/log string.
This task receives commands from the C&C. The botnet sends a request to the C&C with the fingerprint and the api/command string. If the C&C sends a command to download a file, a new directory is created in the TEMP folder using a GUID, and a file called temp.exe is created in that directory. Alternatively, if the command is to “kill”, the process is killed. The task checks for new commands every two minutes.
The C&C determines the type of mining which the infected machine attempts, as well as the mining pool it will join. The EminingTask downloads an executable to the TEMP directory with the name loader.exe. The types of mining that appear in the sample are CPU, Zcash, Scrypt, and SHA256. During the mining task, and depending on the chosen type, the resources of the infected machine, such as the memory, CPU, and RAM, are used to provide the computing power necessary to produce the hashes accepted as a proof of work by each method. Even using a pool instead of individual mining, CPU usage soared rapidly and reached 100% in our labs when we ran the sample, which shows the processing power needed for the mining tasks.
To summarize, the botnet conducts a complex attack: it infects a machine, steals credentials, logs keys and mines for currency, causing CPU level to reach 100%. Although the botnet has many of the crucial implementation tools needed for its attack, it heavily depends on communication with its C&C server and the information it transmits for the execution of its most basic functions.