Tuesday, August 23, 2016

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


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 / 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  ..<$/. 2(.....[\
0x000000c0  e59d 1d80 4607 c807 2200 0527 db76 7fcf  ....F..."..'.v..
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..

..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            <-- connected hosts
-rw-r--r--    4 Aug 23 12:02 MalwareFile.pid  <-- pids
-rw-r--r--    0 Aug 23 12:02 daemon.log       <-- malware log
-rw-r--r--   35 Aug 23 12:02 login2           <-- brute auth
drwxr-xr-x 4096 Aug 23 12:02 files/           <-- updates/downloads/C2 data

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: / 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:


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
\v\0\f\0\t\0\n\0\r\0 \0\36\6\1\6\2\6\3\5\1\5\2\5\3\4\1\4\2\4\3\3\1\3\2\3\3\2\1\2\2\2\3\0\17
0\0\0\0\0\0\0", 517)
To 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.

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 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!

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-> (SYN_SENT)
stdin 2712 root  14u  IPv4 6198  0t0 TCP x.x.x.x:37944-> (SYN_SENT)
stdin 2712 root  15u  IPv4 6199  0t0 TCP x.x.x.x:35576-> (SYN_SENT)
stdin 2712 root  16u  IPv4 6200  0t0 TCP x.x.x.x:41811-> (SYN_SENT)
stdin 2712 root  17u  IPv4 6201  0t0 TCP x.x.x.x:43278-> (SYN_SENT)
stdin 2712 root  18u  IPv4 6202  0t0 TCP x.x.x.x:37969-> (SYN_SENT)
stdin 2712 root  19u  IPv4 6203  0t0 TCP x.x.x.x:39383-> (SYN_SENT)
stdin 2712 root  20u  IPv4 6204  0t0 TCP x.x.x.x:38038-> (SYN_SENT)
stdin 2712 root  21u  IPv4 6205  0t0 TCP x.x.x.x:35040-> (SYN_SENT)
stdin 2712 root  22u  IPv4 6206  0t0 TCP x.x.x.x:59569-> (SYN_SENT)
stdin 2712 root  23u  IPv4 6207  0t0 TCP x.x.x.x:50921-> (SYN_SENT)
stdin 2712 root  24u  IPv4 6208  0t0 TCP x.x.x.x:36079-> (SYN_SENT)
stdin 2712 root  25u  IPv4 6209  0t0 TCP x.x.x.x:35134-> (SYN_SENT)
stdin 2712 root  26u  IPv4 6210  0t0 TCP x.x.x.x:59932-> (SYN_SENT)
stdin 2712 root  27u  IPv4 6211  0t0 TCP x.x.x.x:35682-> (SYN_SENT)
stdin 2712 root  28u  IPv4 6212  0t0 TCP x.x.x.x:57709-> (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  |;22;.|
0010  31 38 33 2e 38 33 2e 30  2e 38 30 3b 32 32 3b 0a  |;22;.|
0020  31 38 33 2e 38 33 2e 32  2e 32 36 3b 32 32 3b 0a  |;22;.|
0030  31 38 33 2e 38 33 2e 32  2e 34 31 3b 32 32 3b 0a  |;22;.|
0040  31 38 33 2e 38 33 2e 32  2e 31 31 30 3b 32 32 3b  |;22;|
0050  0a 31 38 33 2e 38 33 2e  32 2e 32 31 30 3b 32 32  |.;22|
0060  3b 0a 31 38 33 2e 38 33  2e 33 2e 32 32 3b 32 32  |;.;22|
0070  3b 0a 31 38 33 2e 38 33  2e 33 2e 31 34 38 3b 32  |;.;2|
0080  32 3b 0a 31 38 33 2e 38  33 2e 34 2e 39 33 3b 32  |2;.;2|
0090  32 3b 0a 31 38 33 2e 38  33 2e 34 2e 31 35 36 3b  |2;.;|
00a0  32 32 3b 0a 31 38 33 2e  38 33 2e 35 2e 31 36 3b  |22;.;|
00b0  32 32 3b 0a 31 38 33 2e  38 33 2e 35 2e 32 30 36  |22;.|
00c0  3b 32 32 3b 0a 31 38 33  2e 38 33 2e 36 2e 31 32  |;22;.|
00d0  37 3b 32 32 3b 0a 31 38  33 2e 38 33 2e 37 2e 34  |7;22;.|
00e0  33 3b 32 32 3b 0a 31 38  33 2e 38 33 2e 37 2e 31  |3;22;.|
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  |;22;.|
0160  31 38 33 2e 38 33 2e 31  33 2e 31 36 32 3b 32 32  |;22|
0170  3b 0a 31 38 33 2e 38 33  2e 31 34 2e 39 32 3b 32  |;.;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;.|

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

0000  32 37 31 32  |2712|

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.

    Threat alerts raised on internet IT media posts from this awareness (Thank you!)

    We, MMD thank our good friends in internet media for your fast awareness of this worm:
    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]


  • Tuesday, June 7, 2016

    MMD-0054-2016 - ATMOS botnet facts you should know

    The background

    This post is about recent intelligence and sharing information of the currently emerged credential stealer and spying botnet named "Atmos", for the purpose of threat recognizing, incident response and may help reverse engineering. This report is the third coverage of online crime toolkit analysis series that we disclose in MalwareMustDie blog, on previous posts we disclosed about PowerZeus/KINS [link] and ZeusVM/KINS2 [link]

    About Atmos botnet, for the the historical reference, first publicity and thorough technical analysis of the threat was posted by Xylit0l [link] in Xylibox blog [link]. His post contains good technical details with screenshots of the botnet functions. I strongly recommend you to take a look at his post first before reading this, or before you "google" other posts about Atmos botnet, to have you a good correct basic background & know-how on this threat beforehand, specially to the sysadmins and incident response team.

    To add a few words, as a known threat expert in this field, Xylit0l is having strong dedication to follow the growth of the cyber criminal used stealer tools from Zeus, SpyEye, Carberp to Citadel with its variants, then KINS and ZeusVM to now.."Atmos". He knows exactly which version and what is needed to decode each encrypted configuration per version. You can follow his research on those mentioned threats in Xylibox blog post.

    Personally I feel his man deserves acknowledgement and respect of what he contributes, openly and freely, to help all folks in security community securing our cyber space from real crime acts. He doesn't know I am writing this, since if he knows he will yell to me not to.

    Okay, so why I posted this for?

    Our team bumped into this threat in the field, as along with investigation taken we found it's emerged too rapidly by now on some aggressive campaigns. Some recent facts of Atmos botnet was found in real incidents may need to bring up to the surface some additional facts to support IR handle on the issues. The importance raised since this threat is successfully bypassing some client security perimeters, literally. You will see snips of PoC campaign and infection details we handled in the following sections.

    What is this? And where Atmos name came from?

    If I may to make a short definition: Atmos is an evolution of credential stealer toolkit, build with the complete facility meant for a crimeboss herder to operate. Period.

    By function or origin

    Atmos is having a web panel with a strong nuance of Citadel colors, a server to handle the remote requests for its infection functionality, and a binary builder facility.

    Atmos can be used as hacktool, or as RAT, but it is built based from form credential grabber leaked codes, as added with screenshot/video capture surveillance center, or, Atmos can be used as deployment center for further distribution of malware payloads too.

    PoC of Atmos herder executed in infected clients to download other malware:

    Proof that the remote command was executed in a "report":

    In the above two screenshots a Pony malware was being pushed to Atmos bot client.

    Originated from multiple leak codes (dragged from Zeus/Carberp/Citadel/KINS etc), the author managed to combine and wrap all of the bad functions from previous "brands" into a new package and new name, with a bit additional handy crime tools as "add-values" such as: crypter interface, scan4you interface, jabber interface, and even an interface for balance management in some group management, and so on (again, read Xylibox post for the details of these functions).

    As per Zeus or Citadel banking credential stealer botnet, Atmos is sold basically on license basis scheme to its trusted distributors, yet apparently the distributors also fetch re-sellers on their campaign. We will go to the scheme of selling this threat in the end of the post.

    The name of Atmos, how to ID the threat

    The name of "Atmos" came from the author of this package. It is visually recognizable if you meet this threat based on identification as per shown in each screenshots below:

    In the the server console:

    In the builder:

    In the WebUI interface:

    Or, in the infection intercept module original names:

    This name wasn't known in the AntiVirus ("AV" in short) industry when it was around 1 or 2 months after initially spotted..by Xylit0l. Many AV marked the detected Atmos client malware as Trojan.Agent.something or even as Citadel or Zeus variants, etc. I recalled it well that Xylit0l was making some contact effort to advise the correct names to the AV vendors during late 2015, that was the first time appears. He also did the same on pushing the correct names to the industry during firstly spotted KINS in the wild.

    How Atmos bot client malware binary looks like in PEStudio (winitor.com)


    The campaign & new version release plan in June 2016

    Atmos distributors are recently on steroid pushing their campaign in several monitored blackhat forums since the early 2016. Some of the latest detail is about the new version that is released in this month, June 2016. Surprisingly, there is no "fix price" on these offers by the distributors/sellers, as per seen in the various prices offered. Okay, to cut the crap, I am sharing some taken screenshots of the campaign below:

    This is complete list of feature of Atmos in a page:

    Other campaigns mushroomed too, recent ones:

    The "spoiler" of new features for Atmos-new-release version in June 2016

    Several facts of Atmos that we all need to know

    This is the boring part unless you love to crack encryption of credential grabber series. Some facts posted here might help you in figuring its crypted data.

    Russian language comments:

    "Online" encryption functions:

    Where the goodies are:

    The "config" download traffic is something like this:

    About this configuration data, this is spotted in the campaign aiming USA, we reported all data accordingly, we found that majority Desktop and Servers accounts of US network nodes was hacked by actors in Turkey, and the name of this config is one evidence of the targeted effort.

    Atmos interception modules

    In an infection process, Atmos CNC serves the module to intercept spying traffics from the victims to then being installed in the compromised Windows system. Like these three modules:

    PoC of the traffic during downloading, noted the module and file type used:

    And no AV can detect these modules yet, even-though some AV made research publicity about Atmos botnet, the hashes are:

    74e7744a8660940da4707c89810429780d23f9ea6650be3d270264743835f39a video module
    40160debd0a3b6a835e003ecf49c712c1ecd356d1037bcd46c8930ca206f6867 RAT/VNC module
    58b44c86e77461c4df3fc44c98890e30675d6ece3df07a69c30590bd7953e7d9 Firefox cookie module
    Zero detection PoC:

    Noted1: VT result is not showing actual detection of Windows Antivirus, okay.
    Noted2: The below botnet CNC screenshot shows infected clients are infected with these modules even their PCs are installed with the below AntiViruses:

    To be more precised, the evidence of the almost 80 installment sessions of the Atmost malware client that successfully bypassed above listed AntiVirus in grapgical mode is shown well too in the CNC:

    And additionally one known third party (non-OS base) firewall was bypassed too:

    In other case too:

    And in a fresh NEW panel found a live "competition" on bypassing antivirus by Atmos bot client..

    Explanation on low detection for the Atmos modules:

    The modules are in the Atmos encrypted form (please read Xylit0l's blog for encryption detail). The coder made it this way to make it difficult to be detected by AV's signature. Decryption will be done in the Atmos client's workspace, so theoretically it is up to the Windows OS security setting (depends on Windows OS version I guess) for allowing these modules to be installed or not. In these mentioned cases, the modules were successfully installed on Windows7.

    If you take a look to the Atmos post initially published in Xylibox blog by Xylit0l, it was mentioned a good tool released by friends in JP-CERT/CC, that can be used to decode these modules before they reached the Atmos client decryption space, that may raise some chance to be detected, or blocked.

    PoC of Atmos botnet as a cybercrime tool with RAT function

    Following the last line of the previous section, this PoC is showing so many windows PC and servers with the recorded video session from the CNC server. The detail of information in this PoC video is in law enforcement accordingly.

    The movie is showing to you how evolution of crime tool is becoming more sophisticated today, not to only infect the victims, but spying them too by logging victims activity in a video recording sessions. Again, almost all of victims are installed with AntiVirus products, yet bypassed well by Atmos botnet to make this capture module installation.

    Note: Some sensitive information was cropped.

    After released the above video, some says the correlation between the video and the screenshots of the AV bypassed looks unclear, true, I took them from different browsers since I had no plan to expose that far before. But well, in order to assure you there is nothing fake stuff on facts of Atmos bot client & video intercept module is fully undetected by AntiViruses, I just recorded the PoC #2 that will show you EXACTLY one panel with the bot client infecting victims, connected to panels, saving captured movie of victim's PC and you can see yourself with WHICH antiviruses the victims are installed with. See below & get some popcorn, friends :)

    More accurate facts of Atmos botnet sales for law enforcer

    I read somewhere a bit incorrect statement about Atmos distribution which says: "..there is at least one group of cyber criminals who is using Atmos in its attacks" ..yet after we checked ourself in "darkweb", the statement seems to be "outdated", the valid/correct one is as below:

    "Atmos botnets are rented on VPS by its few trusted distributor(s) and mostly player-crooks are just buying access to that VPS, so it's not limited to one group but to anyone who have enough money and "trust" can start using it" - I made confirmation about this too to Xylit0l.
    The statement is backed up by at least we collect more than ten blackhats are now on deploying (or started to deploy) Atmos botnet as the effect of the campaign shown in the above screenshots.
    There is also recent incident shows that a hacked site was used to serve Atmos botnet panel.

    Several countries targeted by Atmos

    There is no "specific country" to be targeted by Atmos. It practically all depends on the actors objectivity. Since most of actors are crooks or thiefs, they are mainly aiming our pocket for online money/card info we do in our PC in anywhere. Atmos provides many scheme for getting those, and to push more scheme of infection to the infected botnet further too, therefore for crime crooks who are familiar in using previous era of crime toolkits like Zeus, Citadel or KINS before, can use Atmos in a snap. In the field,we saw varied scheme of infection, few are spam campaigns and some are web driven infecion methods. On several Atmos CNC panels, which their information are "safe" to be shared (several panels were taken down though), they are showing country basis victims in graphical modes as per data below:

    Speaking of countries, there are many character encoding used for handling the PC data saved to be grabbed by Atmos bad actors. This botnet is handling the encoding character very well, i.e. double bytes encoding Chinese(Simplify/not) or Japanese, were perfectly grabbed and stored in its user's interface:

    So this botnet toolkit is designed to compromise anyone, anywhere, to perform any desirable method in online data stealing. A pure evil toolkit.
    There is a minority usage for a specific target/purpose too, but this info is classified :)

    How incident response team recognizing the country victims?

    In the Atmos panel, just like Citadel, there is no sorting function for gathering data of bot ID per listed countries, they have only the summary, so the crooks should click ID per bot one by one too I guess for checking details. But it is important to warn victims who got infected by this botnet, and we are doing that too. So, in order to get list of evidence on Atmos infection during "securing" their panel, don't waste your time, and go to the botlist and grab the textual data listed in that panel. Just grab it all page per page and safe into a select-able text file. To then you can aim any desired country victims as per real cases we handled below. This way you won't spend too much time in that evil environment.

    You can later on divide each IP's network by ISP for them to contact their users for the alert to their customers, or pass the list to your coordinated CERT/CSIRT.

    One more thing that IR team should be aware is, the GeoIP indicator used by Atmos just sucks. Atmos used own outdated database to locate infected IP to be showned in the botlist like this one (see the marked one):

    It is said the location is in Japan, but actually is in India. So you must re-check the list of IP first before you make any action.

    Atmos setup tutorial & full package overview

    This video is the latest version, it was said, which is planned to be pushed in the market this month (June 2016), yet apparently it is the version 1.01 (for sure: it is the current ITW version actually), and an idiotic distributor was sharing its video tutorial :)

    So, would it be the best of interest for security community to see how the setup process of this botnet goes, as per crooks do it? I share this for everyone involved (and specially law enforcement too) to take a notification on many facts can be taken from recent Atmos botnet. See how it is installed, builder's usage, and panel configuration, etc. This video should be "genuine" artifact made by crime actor himself, it would be better in presenting than either me or Xylit0l made it. PLEASE use the information exposed for taking down this actor and the further Atmos botnet. DO NOT use this information for the bad purpose! (the most important part of this setup video was cropped for security purpose)

    In the below video is snagged from another cyber crook who was trying to promote Atmos (also version 1.01) in late May 2016, he demonstrated the full Atmos package list in his PC that I think will give all of us better idea about how this threat distribute. These two videos are coming from two distributors of Atmos botnet:

    Atmos "Tango Down"

    The main reason of whitehat hackers, IR professionals and malware researchers gather together in MalwareMustDie is to takedown the malware services. This goes the same to the Atmos botnet, with the solid coordination of good folks and friends in incident response chains, WE ALL took chain of efforts in taking them down. Below are some examples:

    Many thanks to friends who involved to this action. Special thank you to Xylit0l.


    We hope the information shared here will help to battle the threat better.

    A small announcement from me:

    I may update or add or delete information, as usual. You know where to reach us.
    Bravo Xylit0l for the good work & thanks for the previous share to all of us!

    Don't be that serious :-)

    Firstly it was a joke from me to tease this Atmosseller..

    Well, he took it very seriously..so I played it along :)
    Obviously there's no such new version bragged by some sellers, but there are some cracked versions with the builders that some of them are not working. Well, don't ever trust of what these crooks say.

    #MalwareMustDie! Analyzed by @unixfreaxjp, all reference: @Xylit0l
    This report along with overall blog posts are bound to our legal disclaimer-->[link]

    Sunday, May 8, 2016

    [Slide|Video] Kelihos & Peter Severa; the "All Out" version

    Tag: Kelihos, Khelios, P2P, FastFlux, Botnet, CNC, C2, Clickfraud, Traffic Redirection, Spambot, DNS Poison, Botnet as Service, Affiliate, Severa, Peter Severa, Petrushakov, Saever, Saushkin

    We yanked this page off along with the slides & its video links from public view to support cyber crime investigation to stop the botnet for good. It's a good will from our investigation team and there's no such force of power involved.

    All of the material and evidence of Kelihos Operation from MalwareMustDie from 2012 to 2016, were handed over to the United States law enforcement and we are not holding anything back.
    If you are from other law enforcement agencies and interested to see what was in this page, please directly contact to the mentioned organization accordingly.

    For the previous viewers, we are terribly sorry for the inconvenience, thank you for all of your great support to this matter.


    Friday, April 15, 2016

    MMD-0053-2016 - A bit about ELF/STD IRC Bot: x00's CBack aka xxx.pokemon(.)inc

    Latest UPDATE incident of this threat is-->[link]


    I received the report of the host in Google cloud network is serving ELF malware:

      "ip": "",
      "hostname": "",
      "prefix": "",
      "org": "AS15169 Google Inc.",
      "city": "Mountain View",
      "region": "California",
      "country": "USA",
      "loc": "37.4192,-122.0574",
      "postal": "94043"
    So I downloaded them all in secure way like as per follows:

    *) p.s.: I never use same request pattern during my encounter to any malware servers

    ELF botnet infecting routers is a bad thing, but abusing Google cloud is another bad thing. Not to mention the utilization of much innocent hacked servers as CNC & the many mis-use of the anime features for badness.
    After receiving several reports on incidents and requests on the topic I decided to write this post as awareness and indicator reference, along with some SLAPS! to the malware coder and actors behind this threat, which are linked to the previous blog post in-->here.

    The first slap: First look

    These are ELF malware of this post, let's pick one and see how it looks in the first sight:

    The binary structure and view:

    The readelf summarizes its header is as follows,

    ELF Header:
      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 - Linux
      ABI Version:                       0
      Type:                              EXEC (Executable file)
      Machine:                           Intel 80386
      Version:                           0x1
      Entry point address:               0xc086b8
      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)
      Number of section headers:         0
      Section header string table index: 0
    'Program Headers:'
      Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
    ' LOAD           0x000000 0x00c01000 0x00c01000 0x08828 0x08828 R E 0x1000   '
    ' LOAD           0x000448 0x0805f448 0x0805f448 0x00000 0x00000 RW  0x1000   '
    There are no sections in this file.
    There are no sections in this file.
    There is no dynamic section in this file.
    There are no relocations in this file.
    There are no unwind sections in this file.
    No version information found in this file.
    I marked places where one should pay attention with, to see the headers in much better mode can be done in objdump:
    pty:     file format elf32-i386
    architecture: i386, flags 0x00000102:
    start address 0x00c086b8
    Program Header:
    '   LOAD off    0x00000000 vaddr 0x00c01000 paddr 0x00c01000 align 2**12'
             filesz 0x00008828 memsz 0x00008828 flags r-x
    '   LOAD off    0x00000448 vaddr 0x0805f448 paddr 0x0805f448 align 2**12'
             filesz 0x00000000 memsz 0x00000000 flags rw- 
    Idx Name          Size      VMA       LMA       File off  Algn
    no symbols
    With a good text analyzer you'll find first indicator of this threat, which is the sentence quoted from bakemonogatari anime iinchou character which was printed hard coded in this ELF in roumaji (read: ASCII) Japanese as per below:

    And accordingly I strongly doubt the coder know the "true" meaning of these sentence :))

    The second slap: Recognizing the packer

    First, this is a packed binary, by UPX, this is the easy way to recognize it since so many trick are used for camouflage the this good known packer. See again the Program Header part;

        LOAD off    0x00000000 vaddr 0x00c01000 paddr 0x00c01000 align 2**12
             filesz 0x00008840 memsz 0x00008840 flags r-x
        LOAD off    0x000003a8 vaddr 0x0805f3a8 paddr 0x0805f3a8 align 2**12
             filesz 0x00000000 memsz 0x00000000 flags rw-
    the 0x00c01000 will store copy of the packed ELF header, and 0x0805f3a8 is start address of stubs contains the data packed. Some PoC:
    > x 0xaa@"0x000";x 0xaa@"0x00c01000"
    - offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
    0x00000000  7f45 4c46 0101 0103 0000 0000 0000 0000  .ELF............
    0x00000010  0200 0300 0100 0000 d086 c000 3400 0000  ............4...
    0x00000020  0000 0000 0000 0000 3400 2000 0200 2800  ........4. ...(.
    0x00000030  0000 0000 0100 0000 0000 0000 0010 c000  ................
    0x00000040  0010 c000 4088 0000 4088 0000 0500 0000  ....@...@.......
    0x00000050  0010 0000 0100 0000 a803 0000 a8f3 0508  ................
    0x00000060  a8f3 0508 0000 0000 0000 0000 0600 0000  ................
    0x00000070  0010 0000 2efa 01da 0a00 0000 7811 0d0c  ............x...
    0x00000080  0000 0000 139a 0100 139a 0100 9400 0000  ................
    0x00000090  5400 0000 0e00 0000 1803 003f 91d0 6b8f  T..........?..k.
    0x000000a0  492f fa6a e407 9a89 5c84                 I/.j....\.
    - offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
    0x00c01000  7f45 4c46 0101 0103 0000 0000 0000 0000  .ELF............
    0x00c01010  0200 0300 0100 0000 d086 c000 3400 0000  ............4...
    0x00c01020  0000 0000 0000 0000 3400 2000 0200 2800  ........4. ...(.
    0x00c01030  0000 0000 0100 0000 0000 0000 0010 c000  ................
    0x00c01040  0010 c000 4088 0000 4088 0000 0500 0000  ....@...@.......
    0x00c01050  0010 0000 0100 0000 a803 0000 a8f3 0508  ................
    0x00c01060  a8f3 0508 0000 0000 0000 0000 0600 0000  ................
    0x00c01070  0010 0000 2efa 01da 0a00 0000 7811 0d0c  ............x...
    0x00c01080  0000 0000 139a 0100 139a 0100 9400 0000  ................
    0x00c01090  5400 0000 0e00 0000 1803 003f 91d0 6b8f  T..........?..k.
    0x00c010a0  492f fa6a e407 9a89 5c84                 I/.j....\.
    >[0x00c086d0]> x@"0x0805f3a8"
    - offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
    0x0805f3a8  6507 7c7e 31e5 29e8 ad2e 4cd4 b883 c761  e.|~1.)...L....a
    0x0805f3b8  709c 6090 b540 bb85 7ede a550 cce0 b146  p.`..@..~..P...F
    0x0805f3c8  8211 fa50 5e82 d55e 2227 b678 e121 fa00  ...P^..^"'.x.!..
    0x0805f3d8  f595 a5e7 5654 b02b 6c2e 4daa de34 103f  ....VT.+l.M..4.?
    0x0805f3e8  d119 ab5b 7c26 20e7 dd69 9df4 822b a118  ...[|& ..i...+..
    0x0805f3f8  7277 8b6c fd4d ac58 49ea f06d 6611 e239  rw.l.M.XI..mf..9
    but if you extract it it will show this error:
            File size         Ratio      Format      Name
       --------------------   ------   -----------   -----------
    'upx: pty: NotPackedException: not packed by UPX'
    The reason is simply after the UPX packed the real binary a modification was made so UPX can not find the starting upx point nor header (see figure below) to start doing the unpacking,

    (↑pic: normal UPX seeks for packer indicator)

    (↑pic: PoC of the malware failed to seek unpacking indicator)

    In the other words: this binary can only be unpacked by itself or we somehow put back the original header in place to make it unpackable by UPX again. But don't worry. Many RE ways to be done dealing with this situation. One of (my favorite) way to handle this "custom" packed UPX is using ala CTF method that I announced a while ago in-->here, or using "other" method that I will not openly disclose (OPSEC), as I used in this case to safe my time.

    The third slap: Malware & its packer's cracked!

    I depacked the binary with my own method and the information needed from the unpacked ELF can be seen in the virus total comment I wrote in-->here.
    And the fun has began (picture?↓)

    The forth slap: Indicator of the infection

    1. Malware installation details

    During the installation the malware will perform shell execution via execve("/bin/sh") to the various linux command line to perform the installation, as per detail picture below:

    As per seen in the details, linux version of debugger and packet capture software were disabled, the DNS resolver will be set to "", then the services (mostly are router specific services) will be stopped or removed its runtime files, the firewall rules will be changed for telnet (tcp/23), httpproxy (tcp/8080) and http (tcp/80) services to be opened, malware will be self-executed under owner only rwx permission (chmod 700), user crontab will be used for autostart, and several info harvesting.

    Accordingly, below similar runtime libraries (ref:debian GNU), must be needed for overall execution:

    /etc/ld.so.cache  // the elf runtime
    /lib/i386-linux-gnu/i686/cmov/libc.so.6  // the elf runtime
    /lib/i386-linux-gnu/libpam.so.0    // some user related calls made
    /lib/i386-linux-gnu/libselinux.so.1  // selinux
    /lib/i386-linux-gnu/i686/cmov/libnsl.so.1     // malwre use these libs to resolve
    /usr/share/locale/locale.alias         // accompany the info harverst
    And the below configuration file will be accessed:
    /etc/rc.conf [READ]
    /etc/resolv.conf [MODIFIED!]
    /etc/nsswitch.conf [READ]
    Also perform information harvesting via execution of:
    and drops these files:
    /var/spool/cron/crontabs/$USER [modification of crontab -e]
    The user contrab will contains:
    * * * * * /PATH/MALWAREFILE > /dev/null 2>&1 &
    Upon status of installation the malware will be able to send this message(s):
    echo [+] Welcome to x00's cback shell %s
    echo [+] you logged in at `date`
    echo [+] `uname -a || cat /proc/version`
    echo [+] you got root rights, enjoy!.
    echo [+] Running on %s/bin/crontab./usr/bin/crontab.chmod 700 %s > /dev/null 2>&1 \
        &.touch -acmr /bin/ls %s(crontab -l | grep -v "%s" | grep -v "no cron" | \
        grep-v "lesshts/run.sh" > %s/.x00%u) > /dev/null 2>&1.echo "* * * * * %s > \
        /dev/null 2>&1 &" >> %s/.x00%u.crontab %s/.x00%u.rm -rf %s/.x00%u.
    echo [+] no cronnie.
    echo [+] forget it. .
    echo [+] you are root tho. ./etc/rc.d/rc.local./etc/rc.conf./."%s%s"a.irq.#x86.777

    2. The IRC botnet

    The malware will connect infected nodes to the hostname xxx.pokemon.inc:8080.
    When I reversed this sample it was resolved into below DNS data:

    ;xxx.pokemoninc.com.         IN A
    xxx.pokemoninc.com.     845  IN CNAME   bnet.pokemoninc.com.
    bnet.pokemoninc.com.    845  IN A
    bnet.pokemoninc.com.    845  IN A
    bnet.pokemoninc.com.    845  IN A
    bnet.pokemoninc.com.    845  IN A
    bnet.pokemoninc.com.    845  IN A
    bnet.pokemoninc.com.    845  IN A
    bnet.pokemoninc.com.    845  IN A
    pokemoninc.com.  2644   IN   NS dns1.name-services.com.
    pokemoninc.com.  2644   IN   NS dns2.name-services.com.
    pokemoninc.com.  2644   IN   NS dns3.name-services.com.
    pokemoninc.com.  2644   IN   NS dns5.name-services.com.
    pokemoninc.com.  2644   IN   NS dns4.name-services.com.

    Infected node(s) will enter the IRC server after receiving the PONG:

    ......PONG #[Arch] :[RangeIP]|[HOSTNAME] -xi.
    .x00 localhost localhost :[DATE, i.e.:feb012016]...
    with executing below JOIN command and using ID format like:
    JOIN :#[Arch] 
    BotID: [Arch]:|x|1|[ID]|[hostname]|[youtubeURL][date]
    NICK [BotID] USER x00 localhost localhost :%s <--- $DATE
    ..and that YouTube URL in botnet protocol is a big LOL in our community :) (picture?↓)

    The youtube url is safe: https://www.youtube.com/watch?v=Jzqy6UJXpcQ [link] is a BGM of popular japanese anime "GochiUsa" about girls work in cafe.

    After joined the IRC !MALICIOUS! bot commands can be executed. I dump the text list of the commands as below:
    Text mode is in-->here.

    3. About the attacks..

    All attack commands can be seen in the above mentioned IRC command, and all command details mostly are shared in the source code of IRC botnet ddoser that I shared a while ago. link-->here. But there are two commands that I often seen recently in DDoS, but I haven't discuss in my previous posts for this type of threat. which are "SUDP" and "UNKNOWN", we disassembly and decode it into its original code as following jinxed snippet:

    "UNKNOWN" was in the source code we shared before, a self-explanatory, so I will not discuss it here.

    4. The big variation of "User Agent" combination used for L7 attacks

    This malware is using combination of many user agents during performing its L7 DoS. The combination is varied, in this particular case the combination is as per snipped in the below picture. Obviously to filter these headers are not recommendable idea to block such attack:

    It's not over..The fifth slap: What's this, really? It's ELF/STD bot.

    This is the STD bot, with the heavy modified code of kaiten. People in the "industry" and some stupid skiddos are thinking that STD bot was derived from kaiten/ktx or tsunami, but actually it is not. The original STD bot was stand alone code. STD name itself came from the coder name called "stackd" (root@stackd.net), and he was the one who coded first 48 lines of STD bot.

    The code was later on inspired by other IRC base codes like kaiten/tsunami and other modification in the "copypasta" land to be what we are still seeing until now. Well, who cares for this history anyway, but I prefer to keep on track on which threat coming from which roots for my analysis purpose, I suggest you should start to do the same if you are not.

    Following, in this particular variant, the coder has overhauled the source code of the latest STD IRC Bot and combining with his own signature for the black market distribution purpose. Also the usage of the UPX trick was added with the hope to prevent sysadmins, scanners or analysts to know what this threat really is during static analysis. yet from now they're failing again :)

    Because unfortunately for them...

    We STILL have a much better KungFu than yours kiddo :)

    The sixth slap: Network threat indicator

    IP addresses: 

    GeoIP information (for cleaning up purpose):

    IP Address, City, Region, Country Name, Mountain View, CA, United States, , , Germany, , , Norway, Beijing, 22, China, , , Thailand, Jinan, 25, China, , , Japan, Nanning, 16, China
    IP address | Reversed | ASN|Prefix|ASN|CN|ISP | |15169 | | GOOGLE | US | google.com | Google Inc. | static.88-198-71-83.clients.your-server.de. |24940 | | HETZNER | DE | hetzner.de | Hetzner Online AG | kdb.servetheworld.net. |34989 | | SERVETHEWORLD | NO | servetheworld.net | ServeTheWorld AS |  |4808 | | CHINA169 | CN | gintong.com | Beijing Huaxia Unipower Network Co. Ltd |  |45458 | | SBN-AWN-AS-02 | TH | sbn.co.th | 408/60 PHP Bld. 15th Fl Phaholyothin Rd Samsen Nai Phayathai |  |4837 | | CHINA169 | CN | chinaunicom.com | China Unicom Shandong Province Network | html.city.shiojiri.lg.jp. / html.city.shiojiri.nagano.jp. |17518 | | SHIOJIRI | JP | city.shiojiri.nagano.jp | Shiojiri City |  |4134 | | CHINANET | CN | chinatelecom.com.cn | ChinaNet Guangxi Province Network
    CNC infratructure map:

    Port numbers used:

    tcp/22 (remote cnc)
    tcp/80 (DoS attack)
    tcp/8080 (IRC connection CNC)
    tcp/23 (telnet scanning)

    Domains & hostname: (do not false positive these, it's for search engine to seek for poor victims!!)

    pokemoninc.com (domain)
    bnet.pokemoninc.com (cname)
    xxx.pokemoninc.com (hostname for round robin access) (one of payload infection server)


    MD5 (pty) = fa856be9e8018c3a7d4d2351398192d8
    MD5 (tty0) = 7980ffb3ad788b73397ce84b1aadf99b
    MD5 (tty1) = d47a5da273175a5971638995146e8056
    MD5 (tty2) = 2c1b9924092130f5c241afcedfb1b198
    MD5 (tty3) = f6fc2dc7e6fa584186a3ed8bc96932ca
    MD5 (tty4) = b629686b475eeec7c47daa72ec5dffc0
    MD5 (tty5) = c97f99cdafcef0ac7b484e79ca7ed503 

    The last (7th) slap: Protection from infection & mitigation

    Several router models and Wifi/WiMax service was reported infected by this malware. For the infection prevention "HowTo" please follow these steps:

    1. Change the default credential of admin and roots. Change the passwords.
    2. Disable the telnet service or secure them with firewall by default.
    3. Secure any ssh access by disable root, use latest protocol/version, 
       limit access and if possible switch the ports.
    4. Deploy firewall rules to avoid port scanning by default.
    5. Monitor infection by checking in/outbound traffic to xxx.pokemon.inc:8080/80/23
    6. Push updates to make above points happens
    For the infected services, add the below steps:
    1. Report the incident to your CERT/CSIRT, is a must.
    2. Contact the owner of the device by email/phone/letter to reset the device.
    3. Test & apply takeover scheme to get the devices back via botnet protocol.
    4. Contact me in DM in @malwaremustdie for advisory, it is FREE
    *) PS: Do not offer me or my team money/donation, send us malware sample instead.

    Epilogue and conclusion

    Sample link is in the article above.
    IOC details was uploaded to OTX (you know where).
    Samples are shared (see hashes), uploaded to kernelmode-->here.
    Q and A can be done in reddit in-->here, or DM me in-->twitter for infection handling advisory.
    Will add and improve this post after resting for a while.
    Will not expose method used for dissecting that "custom" UPX outside the MMD rings.

    For the "unbeliever" (smile), here's snips to screenshot to show how this malware is actually "a lame copypasta IRC bot" which also my screenshot PoC to this analysis reported above during reversing session in my environment:

    "You won't get anything from this post. skiddos, go to school, study hard, like any of decent people do. There is no such shortcut for knowledge."
    *) Note: this section is to be deleted, participate in my ELF workshop and I will share a lot of goodies to you, and please support MalwareMustDie and radare2 project! :-))

    Stay safe, friends. Hope this info helps you.
    Thank's to ben-kow for the infection information, radare.org for the cool stuff! And all friends in MMD group who really supporting me get through the tough time, nice to be able to write again.
    To all friends in Kumamoto prefecture in Japan, prayers for you, this post is dedicated to you and fellow sysadmins who work hard battling, fixing and mitigating this type of threat.

    Written and analyzed by @unixfreaxjp [link], April 14th-15th.2016

    ☩Non nobis Domine, non nobis, sed nomine Tuo da Gloriam (Psalm 113:9)