SHA1:
c38a04fe3c18f03c1ab910cc8c9b180102413c8e (i686, unpacked)
7feb14146ac938e5989cc0c9eda001540ef5d760 (i686, packed)
fc9651f35a50aa5139bd4877b900b922463117c6 (arm, packed)
1d5c88b1027ffa0874015b7546f144cf8ab5b5e1 (mips, packed)
be4b4f732e26d32a8d02504a252a1ab4832f2cce (mipsel, packed)
A Trojans for devices running Linux. Unlike Linux.PNScan.1, this particular modification does not exploit vulnerabilities but uses standard passwords to get unauthorized access to devices.
The Trojan is built using static linking, while debugging information and a section table are removed. For linking, the libcurl, libssh2, libevent, openssl, and janson libraries are used. All binary files have signatures created using ECDSA with the "prime192v1" elliptic curve.
The Trojan can perform the following tasks:
- Hack devices and upload its malicious files to those devices (the Trojan is distributed as a package of four files assembled for i686, ARM, MIPS, and MIPSEL)
- Open ports 9000 and 1337 on compromised devices
- Process requests on those ports
- Establish connection to the command and control server
Infecting devices
By cracking login and password combinations using a special dictionary, the Trojan infects devices via SSH on port 22. The Trojan generates the "list2" file with a list of IP addresses from the "a.b.*.*" range, where a и b are random numbers.
Moreover, it creates the "login2" file with three following login:password pairs:
root;root;
admin;admin;
ubnt;ubnt;
Then the Trojan goes through all IP addresses from the "list2" file and, using login:password pairs from the "login2" file, tries to log in to each resource via SSH. Data on all successful attempts is logged in the "good2" file.
If an authorization attempt is successful, the Trojan checks whether the device is infected or not. To do that, the malicious program sends the "IP:9000/check" request to the device and, if the device is infected, receives a JSON object in reply.
{"status":1}
If the device is not infected, the Trojan plants a set of files whose signatures are checked for validity (depending on the device model, different sets of files are used for ARM, MIPS, MIPSEL, and x86) into the "/tmp/.xs/" folder of the compromised device and runs them.
Once all IP addresses are checked, the Trojans takes a pause and then checks all addresses from the "good2" file verifying that all the devices are infected. If any of the devices does not respond to the request (IP:9000/check), the malicious copy is uploaded to that device once again.After that, the Trojan relaunches an attack on remote devices repeating all the steps starting from generating IP addresses.
Executing commands
The Trojan opens the port 9000 and uses it to receive commands. The malicious program can execute the following commands:
/check
—check the device for infection. If the device is infected, and the Trojan is operating, a JSON object is sent in the reply:
{"status":1}
/upload
—upload files to the device. A POST request should contain a JSON object as a payload with information about the downloaded file (name, architecture, data encoded in base64):
{
"upload":
{
"name" : file_name
"data" : file_data_in_base64
"arch" : file_arch
}
}
Prior to saving the file, the Trojan checks whether it has a signature or not. If successful, files are placed into "/tmp/.xs/files/" with the name specified by the JSON object, while the sender of the request gets the following JSON object:
{"status":1}
/<filename>&ver=3422792789
—send the contents of the "/tmp/.xs/files/<filename>" file if the version of the current Trojan's file is not newer than the one specified by the "ver" parameter..
Searching for command and control servers
The Trojan searches for command and control server addresses as follows:
- The malware randomly chooses a domain from the following list: google.com, twitter.com, microsoft.com. Then it sends that domain a GET request over HTTPS.
- Once a reply is received, the Trojan extracts the Date value from headers and, using that date, generates three names. During the process, the list of strings from the malware's body is used:
- The Trojan sends a request over HTTPS to a node from the following list:
- https://twitter.com/search?f=realtime&q=%s
- https://twitter.com/%s
- https://my.mail.ru/mail/%s/
- https://reddit.com/search?q=%s
where %s is replaced with one of the names generated at step 2. The Trojan goes through all combinations of domains and generated names. If the command and control server is not found, the search is repeated after 5 minutes.
- The message is located on the page between the name generated at step 1 and “@”.
- It is encoded in base64 and encrypted using XOR with the name generated at step 1 as a key.
- Received data looks as follows:
- offset 0: message
- offset n-5: version
- offset n-1: opcode
- offset n: ECDSA_r
- offset n+sizeof(ECDSA_r): ECDSA_s
For the received data, the Trojan checks the digital signature created using ECDSA. For that, SHA1 is used. The public key is hard coded in the Trojan's body.
- If the check is successful, the data is saved to "files/srv_cc".
Judging from generation algorithms, command and control servers can operate for one day, one week or one month.
Communication with the command and control server
All replies coming from the command and control server are signed. The Trojan always checks the signature.
The following is an example of the srv_cc file containing the command and control server IP:
The file has the following structure:
struct srv_cc
{
_BYTE cnclist_len;
_DWORD cnclist[cnclist_len];
_BYTE opcode;
_DWORD version;
_BYTE signature[0x30];
}
, where cnclist indicates the list of command and control sever IPs expressed in hexadecimal notation.
Starting from a random IP, the Trojan goes through all addresses from the list sending them a "cnc_ip:9000/i686?ver=0" request. The data from the reply is saved to the "files/i686" file (if the file has a valid signature). At that, depending on the Trojan's architecture, i686 can be replaced with mips, mipsel or arm. Then the Trojan sends "cnc_ip:9000/srv_report?ver=0" to the command and control server saving the data from the reply to "files/srv_report".
The srv_report file can look as follows:
This file contains one or several URL addresses to which the Trojan will send data about the infected device and from which it will receive commands. The file has the following structure:
struct srv_report
{
char cnc_report_urls[];
_BYTE opcode;
_DWORD version;
_BYTE signature[0x30];
}
The cnc_report_urls list with command and control server addresses can contain several links separated by '\n'.
The Trojan sends requests to all addresses from the list. For that, the malicious program generates a JSON object with data on the infected system and the Trojan itself:
{
"os":
{
"uname":
{
"machine" : utsbuf.machine,
"nodename" : utsbuf.nodename,
"release" : utsbuf.release,
"sysname" : utsbuf.sysname,
"version" : utsbuf.version,
}
"localaddr" : localddr,
"lip" : local_ip,
"hwaddr" : mac_addr,
"cpuinfo" : cpuinfo,
"osversion" : osver,
}
"bid" : bid,
"arch" : arch,
"ver" : version,
"ip" : extip,
"auth" :
{
"good" : good2,
"timescan" : timescan,
"timecheck" : timecheck,
"timerecheck" : timerecheck,
"countcheck" : countcheck,
"countrecheck" : countrecheck,
"countscan" : countscan,
"countcheckgood" : countcheckgood,
"countrecheckgood" : countrecheckgood,
}
}where "auth" fields contain data on hacked nodes that were infected (data from the good2 file), number of infected devices, a number of checked devices, and other data;
extip—external IP address that is checked via "checkip.dyndns.org";
bid—unique Trojan ID. The ID is generated as follows:
sha1_init(&sha1_ctx);
sha1_update(&sha1_ctx, macaddr, strlen(macaddr));
sha1_update(&sha1_ctx, utsbuf.machine, strlen(utsbuf.machine));
sha1_update(&sha1_ctx, utsbuf.nodename, strlen(utsbuf.nodename));
sha1_update(&sha1_ctx, utsbuf.release, strlen(utsbuf.release));
sha1_update(&sha1_ctx, utsbuf.sysname, strlen(utsbuf.sysname));
sha1_update(&sha1_ctx, utsbuf.version, strlen(utsbuf.version));
sha1_final(&hash, &sha1_ctx);
HexToStr(&hash, 16, outbid);The Trojan sends an encrypted JSON object via a POST request in which the first 4 bytes are the CRC32 checksum of the JSON object followed by the JSON object encrypted with RC4 (the encryption key is the CRC32 checksum of the JSON object).
A reply coming from the server is also encrypted with RC4. The first 4 bytes of the reply are simultaneously the encryption key and the checksum. If the data is successfully decrypted and has a valid signature, it is saved into "config".
A reply coming from the server is also encrypted with RC4. The first 4 bytes of the reply are simultaneously the encryption key and the checksum. If the data is successfully decrypted and has a valid signature, it is saved into "config".
{
"bid": bid
{
"upload":
{
"name" : file_name
"data" : file_data_in_base64
"arch" : file_arch
}
"exec":
{
"cmd" : cmd
}
"download":
{
"path" : path
}
}
}The Trojan executes commands specified in the configuration file (including commands to upload a file to the infected device or from the device to the server or to execute a random script) and sends the server a report in JSON format:
{
"upload":
{
"name" : file_name
"status" : status
}
"exec":
{
"cmd" : cmd
"result" : result
"status" : status
}
"download":
{
"path" : path
"result" : result
"status" : status
}
}The total number of fields depends on the number of commands issued by the server.
If the upload command is received, the Trojan verifies that a file has a valid signature; the "cmd" and "download" commands do not imply any verification procedure.