MMD-0055-2016 - Linux/PnScan ; ELF worm that still circles around

8 years ago 343

BOOK THIS SPACE FOR AD

ARTICLE AD

Background

Just checked around internet and found an interesting ELF worm distribution that may help raising awareness for fellow sysadmins. As per shown in title, it's a known ELF malware threat, could be a latest variant of "Linux/PnScan", found in platform x86-32 that it seems run around the web within infected nodes before it came to my our hand. This worm is more aiming embed platform and I am a bit surprised to find i86 binary is hitting some Linux boxes.

This threat came to MalwareMustDie ELF team task before and I posted analysis in Mon Sep 28, 2015 on kernelmode [link] along with its threat details, I thought the threat is becoming inactive now and it looks like I'm wrong, as the malware works still in infection now as worm functions and is hardcoded to aim 183.83.0.0 / 16 segment (located in network area of Telangana and Kashmir region of India), where it was just spotted. Since I never write about this threat in this blog (except in the kernelmode), it will be good to raise awareness to an active working and alive worm by this post.

Threat Indicators

For some reason we can't inform infection source, but the source is in the targeted network mentioned above. It is hard to seek the patient zero of this infection since the worm seems took a while to circle around the targeted network.

The file is having below indicator:

Filename: 'stdin'(.pnscan.x86-32.mmd) Type: 'ELF 32-bit LSB executable, Intel 80386' (GNU/Linux) statically linked, stripped Packer: 'UPX (header bit tweak) packed,' Spotted: 'Tue Aug 23 12:27:21 UTC 2016' md5: '6fb6f95546d5bdf4db11655249ee5288' sha1: '2d3e2ce680de6c13ab3236429efd4bca3bfaa79d' According to VirusTotal it's firstly spotted months ago: 'First submission 2016-01-27 05:26:45 UTC'

Static check will find the packed and tweaked UPX was used.

ELF Header: '↓typical packed one' Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - GNU ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 'Entry point address: 0xcfce38' 'Start of program headers: 52 (bytes into file)' Start of section headers: 0 (bytes into file) Flags: 0x0 ' Size of this header: 52 (bytes)' ' Size of program headers: 32 (bytes)' ' Number of program headers: 2' ' Size of section headers: 40 (bytes)'

Program Headers: ↓It's a typical UPX header as per explained in different post I made here-->[link]

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 '0x00c01000' 0x00c01000 0xfc661 0xfc661 R E 0x1000 LOAD 0x000d68 '0x08290d68' 0x08290d68 0x00000 0x00000 RW 0x1000

UPX packer traces in the original binary of this worm:

This worm is using customized UPX form of header to avoid RE / decoding↓

0x00000000 7f45 4c46 0101 0103 0000 0000 0000 0000 .ELF............ 0x00000010 0200 0300 0100 0000 38ce cf00 3400 0000 ........8...4... 0x00000020 0000 0000 0000 0000 3400 2000 0200 2800 ........4. ...(. 0x00000030 0000 0000 0100 0000 0000 0000 0010 c000 ................ 0x00000040 0010 c000 61c6 0f00 61c6 0f00 0500 0000 ....a...a....... 0x00000050 0010 0000 0100 0000'680d 0000 680d 2908' ........h...h.). 0x00000060 680d 2908 0000 0000 0000 0000 0600 0000 h.)............. 0x00000070 0010 0000 22c0 e4b8 5550 5821 3408 0d0c ...."...UPX!4... 0x00000080 0000 0000 783f 2400 783f 2400 9400 0000 ....x?$.x?$..... 0x00000090 5d00 0000 0800 0000 771f a4f9 7f45 4c46 ].......w....ELF 0x000000a0 0100 0200 0300 1b68 8104 fbaf bddf 0834 .......h.......4 0x000000b0 0ef8 3c24 2f16 2032 2800 1000 0f00 5b5c ..Figure: Modified header

There are some ways can be used to put back this ELF to its origin form, I will add howto info in here (public) after this case's handle is done.

We have several method to crack some specific made UPX base custom packed ELF, one of them that I used to dissect the ELF of the "xxx.pokemon(.)inc" a one IRC DDoS botnet ELF malware I posted in here-->[link]. The other ways to debunk these packed ELF are by different methods of cracking, which are just being shared publicly via radare.org [link] community as per below:

One of the method(s) described in tutorials above is sufficient enough to crack this ELF successfully.

A protip to sysadmins and RCE beginners (good folks only!) in dealing with difficult ELF packer: Just remember, if you stuck on something, it is only a sign for you to start to improve yourself, just keep on trying. Remember: crooks never be smarter than you, have this faith, and in time you'll figure the problem.

Video IR Guideline details of functionality of Linux/PnScan worm

Below is the detail of the forced unpacked binary of the Linux/PnScan worm version, This video was actually I made as guide to CERT and IR folks to mitigate the threat. I am using my beloved shell RE tool "radare" for this. There are heavy editing, some cuts, and parts skipped w/also some unexplanatory parts for the sake of on going case security reason. But all indicators are viewable in this video, worth to watch if you are in ISP's IR or CERT field. There are some details are not included in the video too by other security reason.

Note on video watching: Youtube may sometimes have a weird problem with initial loading video I uploaded recently, if it can not load suddenly in the middle of playing (read: stopped/stuck), if you experienced this "phenomenon" just change the resolution to bigger or smaller arte, and the video will be reloaded and run well... beats me how this problem can happen... but please don't blame the video itself. Thank you.

A bit about radare.org's r2

For the static analysis of ELF malware to specially the sysadmins (and reversing enthusiasts), I'd say radare2 (r2) is the best tool I've ever use, following by gdb, objdump and its binutils or ELF utils etc for the purpose. I've been using it for long [link] and it never fails me for works I do in UNIX shell. MalwareMustDie team members are officially using it daily for ELF analysis.

Shortly, r2 is not only a tool made by hackers to nail hackers & its bad coded bins by RCE, but it helps your IR work on static analysis for bad bins in any major NIX native architecture shell environment inside of infected systems. Not only as a static analysis tool, but r2 as forensics tool allows you to extract important IR information instantly and on the fly with its rich command features... it is flexible and fast! The analysis I made and I posted in this blog (and others) are mainly using r2.

You can follow radare2 good folks works in here [here] and here [link].

Let's continue with the analysis..

This ELF is having below dependencies..

libc-2.13.so ld-2.13.so ..and was compiled on compatibility of GCC(GNU) 4.1.x via the compiler tool Toolchains [link] with cross compiler option for i686 using the SSL enabled configuration. It seems the coder is using working desktop with the crypted disk "/media/truecrypt1" with workpath "/my/framework/" for compiling this :) ouch!

No screenshot, no PoC..here we go:

A summary of how it works

To fellow reversers, there's no specific new function spotted in these sample ELF worms I investigated, except the practical usage is different, that the x86-32 platform are specifically aimed (and this is bad) and a part of India network is now as the target. It is weird a bit on why toolchains is used for i686 compilation, but that also shows x86-32 is not the only targeted aim for this infection too. It is supported the historical data of the infection spotted from September 2015 the versions of mips, mipsel and arm were mostly the main spotted ones. To make it simple in words: This worm is not only targeting Linux with embedded for IoT device and routers, but for servers and appliances too now with, still, aiming its default password login.

Below is a summary on how it works:

1. It forked 4 times (with its main process = 5)

2. Created files with the below functionality in the work (executed) directory:

permission size date filename function ---------------------------------------------------------------- -rw-r--r-- 387 Aug 23 12:06 list2

3. Daemonizing and listening to these 2 TCP ports:

IPv4 TCP/＊:9000 (for /check command and /upload command's remote access) IPv4 TCP/＊:1337 (remote uptime or ping quick check)

4. Attacking initially to target IPs in: 183.83.0.0 / 16 (hard coded)

Country: 'India (Telangana, Kashmit region network in India)' For 'SSH services' in port: 'TCP/22' (ssh)

5. Having function to brute force login with the below auth:

root:root admin:admin ubnt:ubnt

6. SSL traffic sent via HTTP/1.1 requests to twitter.com, reddit.com, google.com, microsoft.com etc listed URL on the SSL port TCP/443↓

write(113, "\26\3\1\2\0\1\0\1\374\3\3%\254\231\25\346\263EuU\vI\26\10bc\0I_\246\262g\273\267 \342C\24\33l\327\214R\215\0\0\240\3000\300,\300(\300$\300\24\300\n\0\245\0\243\0\241\0\237\0 k\0j\0i\0h\0009\0008\0007\0006\0\210\0\207\0\206\0\205\3002\300.\300*\300&\300\17\300\5\0\23 5\0=\0005\0\204\300/\300+\300'\300#\300\23\300\t\0\244\0\242\0\240\0\236\0g\0@\0?\0>\0003\00 02\0001\0000\0\232\0\231\0\230\0\227\0E\0D\0C\0B\3001\300-\300)\300%\300\16\300\4\0\234\0To be clear in ↓PCAP :) ping EmergingThreat Lab friends!

(Note: well, actually this function is also known too way back before.. )

7. Plain and SSL encrypted CNC traffic

The CNC calls will be performed upon successful function to seek its CNC related info via the requests sent in list of SNS (+other sites too) via SSL.

The Twitter (and other SNS/sites i.e.: reddit.com, microsoft.com, google.com, my.mail.ru) requests are utilized by this worm to do one important step to perform callback the CNC, by generation files in /files/ contains the CNC IP and its ports (See the ELF video.posted above). I waited long enough to be sure that no CNC is reached, but none available at this moment, assuming the worm is moving around in circle in the targeted network and accidentally hit my trap planted in the area. The worm is responding to the known bot protocol in the port TCP/9000 if you want to try some test for communicating with this worm. Port TCP/1337 is another indicator for the success infection. Both TCP/9000 and TCP/1337 are open, and has connectable (ESTBLISHED) TCP state.

The worm, in this particular sample, when it can't reach the CNC, will keep on requesting to the next SSL media that was contacted. In this case, it will keep on contacting the twitter.com, reddit.com, google.com and etc SNS URL hardcoded in the binary (see the below embedded video for the list) with permutating wordlist posted to the request after the SSL is established. This action to then triggering initial CNC list generation and making effort to seek for the motherhost connection (which it seems unreachable or down now).

Some of the requests during the initial infection stage can be seen in the PCAP snapshot that I had collected as per below:

Initiating connection:

Client request the hello:

Server is replied with key and response:

No CNC connection found yet, it was re-trying to next.. reddit.com now:

Again, these requests will keep on going while the worm is keep on continuing scanning and listing up the successfully scanned hosts and successfully brute-targeted SSH attack list. The activity will keep on going on until the worm can connect to the CNC and the hacker can reach back to the infected host and remotely send more instruction for other attacks via port TCP/9000 (noted the inbound and outbound traffic from and to this port).

This is why the coder was using SSL configuration during the compilation, they need to use SSL certification of twitter. reddit, microsoft, google etc for the generation of data to be used for further effort in making CNC connection.

[EDIT]
I thought there might be a way for the IDS signature for blocking this twitter connection for this worm can be used for the pinpoint to mitigate the growing infection on the targeted network. For that purpose, upon consulted to the team of experts in ETLabs [link], the result is negative. Following is the explanation: Unfortunately there isn't anything we can do there, there's SSL traffic to Twitter which on a network sensor will be encrypted. It's impossible to differentiate between infection traffic and legitimate Twitter traffic from our standpoint. Also, nothing appears abnormal in the SSH scanning..
[/EDIT]

[EDIT 2]
Discussing further with the ETLabs engineer friends, collaborating to mitigate this threat and the good result came up. We found way to mitigate the infection by the ETLab's traffic filtration signature. The details for this filtration you can see in the mitigation section. Thank you for the nice discussion and great work!
[/EDIT]

Infection Symtoms

Infected node will have traces of these process running made during the initial infection:

stdin 2712 root cwd DIR 8,1 4096 131126 /test/ stdin 2712 root rtd DIR 8,1 4096 2 / stdin 2712 root txt REG 8,1 1034309 131146 /test/stdin stdin 2712 root 0u REG 8,1 0 131171 /test/daemon.log stdin 2712 root 1u REG 8,1 0 131171 /test/daemon.log stdin 2712 root 2u CHR 136,0 0t0 3 /dev/pts/0 stdin 2712 root 3r FIFO 0,8 0t0 6188 pipe stdin 2712 root 4w FIFO 0,8 0t0 6188 pipe stdin 2712 root 5u 0000 0,9 0 1185 anon_inode stdin 2712 root 6u unix 0xcda07300 0t0 6191 socket stdin 2712 root 7u unix 0xce020d40 0t0 6192 socket stdin 2712 root 8u IPv4 6193 0t0 TCP *:9000 (LISTEN) stdin 2712 root 9u 0000 0,9 0 1185 anon_inode stdin 2712 root 10u unix 0xce020ac0 0t0 6194 socket stdin 2712 root 11u unix 0xce020840 0t0 6195 socket stdin 2712 root 12u IPv4 6196 0t0 TCP *:1337 (LISTEN)

And the launched attack can be seen in the network connectivity like per shown in the list of files and connection:

stdin 2712 root 13u IPv4 6197 0t0 TCP x.x.x.x:40709->183.83.0.0:22 (SYN_SENT) stdin 2712 root 14u IPv4 6198 0t0 TCP x.x.x.x:37944->183.83.0.1:22 (SYN_SENT) stdin 2712 root 15u IPv4 6199 0t0 TCP x.x.x.x:35576->183.83.0.2:22 (SYN_SENT) stdin 2712 root 16u IPv4 6200 0t0 TCP x.x.x.x:41811->183.83.0.3:22 (SYN_SENT) stdin 2712 root 17u IPv4 6201 0t0 TCP x.x.x.x:43278->183.83.0.4:22 (SYN_SENT) stdin 2712 root 18u IPv4 6202 0t0 TCP x.x.x.x:37969->183.83.0.5:22 (SYN_SENT) stdin 2712 root 19u IPv4 6203 0t0 TCP x.x.x.x:39383->183.83.0.6:22 (SYN_SENT) stdin 2712 root 20u IPv4 6204 0t0 TCP x.x.x.x:38038->183.83.0.7:22 (SYN_SENT) stdin 2712 root 21u IPv4 6205 0t0 TCP x.x.x.x:35040->183.83.0.8:22 (SYN_SENT) stdin 2712 root 22u IPv4 6206 0t0 TCP x.x.x.x:59569->183.83.0.9:22 (SYN_SENT) stdin 2712 root 23u IPv4 6207 0t0 TCP x.x.x.x:50921->183.83.0.10:22 (SYN_SENT) stdin 2712 root 24u IPv4 6208 0t0 TCP x.x.x.x:36079->183.83.0.11:22 (SYN_SENT) stdin 2712 root 25u IPv4 6209 0t0 TCP x.x.x.x:35134->183.83.0.12:22 (SYN_SENT) stdin 2712 root 26u IPv4 6210 0t0 TCP x.x.x.x:59932->183.83.0.13:22 (SYN_SENT) stdin 2712 root 27u IPv4 6211 0t0 TCP x.x.x.x:35682->183.83.0.14:22 (SYN_SENT) stdin 2712 root 28u IPv4 6212 0t0 TCP x.x.x.x:57709->183.83.0.15:22 (SYN_SENT) : : To be more precise of the aimed network for this attack specifically, below is the PoC video of the recorded PCAP, the data is too big so the video is only covering about 3% of the recorded scanning and SSH login/bruting access:

You can imagine how hectic these traffic will be in targeted network if there are some tens or maybe hundreds infected boxes.. The actor can create a massive chain of infection if they are aiming the right network with having the right vulnerable default SSH login.

Each connected target is logged in the "list2" file:

0000 31 38 33 2e 38 33 2e 30 2e 33 33 3b 32 32 3b 0a |183.83.0.33;22;.| 0010 31 38 33 2e 38 33 2e 30 2e 38 30 3b 32 32 3b 0a |183.83.0.80;22;.| 0020 31 38 33 2e 38 33 2e 32 2e 32 36 3b 32 32 3b 0a |183.83.2.26;22;.| 0030 31 38 33 2e 38 33 2e 32 2e 34 31 3b 32 32 3b 0a |183.83.2.41;22;.| 0040 31 38 33 2e 38 33 2e 32 2e 31 31 30 3b 32 32 3b |183.83.2.110;22;| 0050 0a 31 38 33 2e 38 33 2e 32 2e 32 31 30 3b 32 32 |.183.83.2.210;22| 0060 3b 0a 31 38 33 2e 38 33 2e 33 2e 32 32 3b 32 32 |;.183.83.3.22;22| 0070 3b 0a 31 38 33 2e 38 33 2e 33 2e 31 34 38 3b 32 |;.183.83.3.148;2| 0080 32 3b 0a 31 38 33 2e 38 33 2e 34 2e 39 33 3b 32 |2;.183.83.4.93;2| 0090 32 3b 0a 31 38 33 2e 38 33 2e 34 2e 31 35 36 3b |2;.183.83.4.156;| 00a0 32 32 3b 0a 31 38 33 2e 38 33 2e 35 2e 31 36 3b |22;.183.83.5.16;| 00b0 32 32 3b 0a 31 38 33 2e 38 33 2e 35 2e 32 30 36 |22;.183.83.5.206| 00c0 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 36 2e 31 32 |;22;.183.83.6.12| 00d0 37 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 37 2e 34 |7;22;.183.83.7.4| 00e0 33 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 37 2e 31 |3;22;.183.83.7.1| 00f0 32 33 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 37 2e |23;22;.183.83.7.| 0100 31 38 37 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 31 |187;22;.183.83.1| 0110 31 2e 35 31 3b 32 32 3b 0a 31 38 33 2e 38 33 2e |1.51;22;.183.83.| 0120 31 31 2e 38 34 3b 32 32 3b 0a 31 38 33 2e 38 33 |11.84;22;.183.83| 0130 2e 31 31 2e 31 36 38 3b 32 32 3b 0a 31 38 33 2e |.11.168;22;.183.| 0140 38 33 2e 31 32 2e 31 34 35 3b 32 32 3b 0a 31 38 |83.12.145;22;.18| 0150 33 2e 38 33 2e 31 32 2e 32 34 30 3b 32 32 3b 0a |3.83.12.240;22;.| 0160 31 38 33 2e 38 33 2e 31 33 2e 31 36 32 3b 32 32 |183.83.13.162;22| 0170 3b 0a 31 38 33 2e 38 33 2e 31 34 2e 39 32 3b 32 |;.183.83.14.92;2| 0180 32 3b 0a |2;.|

And you may find the brute list trace in file "login2"

0000 72 6f 6f 74 3b 72 6f 6f 74 3b 0a 61 64 6d 69 6e |root;root;.admin| 0010 3b 61 64 6d 69 6e 3b 0a 75 62 6e 74 3b 75 62 6e |;admin;.ubnt;ubn| 0020 74 3b 0a |t;.| 0023

Noted: the PID of main process is saved in [MalwareFile].pid

0000 32 37 31 32 |2712| 0004

The origin of the threat

Regarding the source of this threat. I have discussion with my good colleague, I would like to not mention his/her identification for his/her security protection.

1. The compilation traces

The traces that lead to the cross compiling tool used, which was showing the Truecrypt was used. This method of running Truecrypt in the work directory is still seen a lot in several activities of cyber crooks on East Europe region (while in the western part or my part of area, mostly we already abandoned this technology for its insecurity). Which is suggesting the origin of this threat.
The data of the compilation traces:

0x8238ff8 102 101 OPENSSLDIR: "/media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl" 0x8248eac 96 95 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/lib/engines 0x825e294 96 95 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl/private 0x825e2f4 88 87 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl 0x825e34c 94 93 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl/certs 0x825e3ac 97 96 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl/cert.pem

2. The MY.MAIL.RU's API used

In the SNS service url list where the worm is using to start effort to reach its CNC, it was found the specific API of mail.ru, a russian big public email service. We think, only russian speaking bad actors (I don't say "nationality" here, but this shows high possibility that the actor may residing in there), who know how use specific subdomain of my.mail.ru with its API as per shown below:

0x8220f7a 11 10 my.mail.ru 0x8220f85 20 19 https://%s/mail/%s/ For these 1. and 2. forensics result we herewith inform to the legal and law enforcement to make a proper action and record accordingly.

Mitigation and detection method against PnScan worm infection

Some ways to fight this worm:

A way to prevent this worm attacking your hosting, ISP routers services or further, the IoT devices is by making sure there is no SSH default authentication box is running on your network, and please avoid using standard port for the SSH service, if possible.
To trim the infection in the large scale network you can use the port TCP/1337 and also TCP/9000 as TCP connection target. If both ports of a node is accepting your TCP connection and go to the ESTABLISHED state, there is a good chance the device is infected, to be sure you can check further. There are also several services running by using TCP/9000, you can view the possibility in this site [link].
As per explained above, it was preliminary explained, there is a difficulty for IDS/IPS to filter the SNS sent request via SSL from these worm's infected hosts, but if you see your appliance, routers. servers or IoT devices in your network that is keeping on sending connection to twitter.com or reddit.com or etc sites listed in this post, and those devices are not suppose to do so, please be aware and check the access on the TCP/1337 or TCP/9000 ports whether they are opened or not. If possible check by your tool to established connection to those both ports, a simple netcat will do. If the worm's actor/hacker sees the tcp/9000 and tcp/1337 is OPEN in a device during portscanning, he will know exactly that PnScan hit it and can conduct his evil further step further too. So, if your box has these symtoms, take it offline and try to check the inside if available, if the access is not applicable for you to check, you'd better to reset the firmware, restart the device and restore the saved setting, to then change the default passwords (and SSH port number if possible), before making it back online.
And for the servers, cleaning up the worm is not difficult, the worm doesn't rootkit the infected device at the earliest infection stage, so unless the actor/hacker(s) is not reached back yet and make extra effort to root the victim's device further, deletion of the working directory (along with /tmp saved files and related malware work directory "./files/"), with also deleting the trojan binaries and its components can clean up the box well. Before the deletion, snapshot the list of process with the networking viewable option, and then take it offline during the fixing, So far there is no persistence autostart setting for this worm, which is good, so I think the infection can be neutralized safely. Just to be sure you know the danger for not offlining your system. This worm is scanning SSH ports in TCP/22 with common SSH request, bruting it, infect it, try to reach its CNC along with its persistent continuous activity to keep on scanning to infect more infection nodes with the very fast speed, In several minutes I count more than one hundred nodes attacked during the analysis. Please, make sure that you are offline-ing the infected system as soon as possible. If one node had infection, there is a strong possibility there is another infected Linux box in the x.x.0.0/16 segment of your IP too, warn your ISP and CERT immediately for the services to be aware for this epidemic precaution. Please contact me by leaving comments for further assistance, or try to DM to our twitter account in @malwaremustdie, we will help in anyway I can. We do this after work hours so please bear the slow reply.

Signature to block the traffic of Linux/PnScan

Thank you ETLab for kindly help all of us by releasing the Snort and Suricata open rules to mitigate this threat.

The rules are complex and designed to detect any symtoms required networking activity generated from this worm, with the function that can be seen below:

2023087 - ET TROJAN PNScan.2 Inbound Status Check - set (trojan.rules) 2023088 - ET TROJAN PNScan.2 Inbound Status Check Response (trojan.rules) 2023089 - ET TROJAN PNScan.2 CnC Beacon (trojan.rules) 2023090 - ET TROJAN PNScan.2 CnC Beacon 2 (trojan.rules) To be noted: It is maybe a bit confusing you but DO NOT mix this worm with the trojan of Linux/PnScan.1 or version one, which is working in different activity (port scanner and DDOS) and not having a worm function, Additionally naming of these threat was taken from the first entity who released its announce.

Conclusion, Samples & Reference

This worm is re-infecting i86 Linux machines in the target mentioned above and all of the data posted above are important hazards to block its infection and distribution. The worm is hitting a box, scan for more and each box is hitting some more boxes too, the growth is exponentially increased if it is spread in vulnerable network. For this particular case we wrote here, I guess this happened between from 6 months ago until now, and the hacker could be sitting there in Russia network waiting for the right chance to access any accessible infected nodes. If you take a look closer to the explained auth data then you may guess which distribution of boxes that are actually aimed.

Related links and last notes

You'll see deeper detail in previous writing & thread here -->[link]
Sample is in VirusTotal [link]
Dr. Web wrote details of the threat, they correctly see what we see, good work! [link]
PS: The warning of this threat was sent to regional CERT.

Thank you very much for the internet media awareness

We, MMD thank our good friends in internet media for your fast awareness of this threat:
1. Security Affairs [link]
2. Softpedia [link]
3. Security Week [link]
4. Anti Malware .ru [link]
5. Sensor Tech Forum [link]
6. IPS Info .ru [link]
7. Romania Net [link]
8. Virus Info forum [link]
9. News Asis .IO (In Arabic) [link]