Tuesday, August 23, 2016

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

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 details and threat, 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 kernelmode), it will be good to raise awareness to an active working and alive worm.

Threat Indicators

For some reason we can't inform infection source, but the source is in the targeted network mentioned above.

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: ↓'Typical UPX'
  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
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
Figure: UPX packer

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.

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, except the prectical usage is different, that the x86-32 platform are specifically aimed and India network is now as the target. It is weird a bit on why toolchains is used for i686, but that also shows x86 is not the only aim too.
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

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. Confusing traffic by sending HTTP/1.1 request via SSL to twitter.com on port 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\0<\0
/\0\226\0A\0\7\300\22\300\10\0\26\0\23\0\20\0\r\300\r\300\3\0\n\0\377\1\0\0013\0\0\0\20\0\16
\0\0'\vtwitter.com'\0\v\0\4\3\0\1\2\0\n\0\34\0\32\0\27\0\31\0\34\0\33\0\30\0\32\0\26\0\16\0\r
\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\1\0013t\0\0\0\20\0\v\0\t'\10http/1.1'\0\25\0\267\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
   :
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.. )
[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 experts in ETLabs, 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.. Thank you ETLab's friends!

The twitter request is utilized by this worm to one important step to perform callback the CNC, on generating files in /files. I waited long enough to be sure that no CNC is reached. 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.

The worm, in this particular sample, when it can't reach the CNC, will keep on requesting the SSL media that was contacted. In this case, this worm will keep on contacting the twitter.com to then making effort to seel for the motherhost, which is seemed unreachable. The vital request for the operation can be seen in the PCAP that I had just collected as per below:

Initiating connection:

Client request the hello:

Server is replied with key and response:

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

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:

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

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

Conclusion, Samples & Reference

This worm is re-infecting i86 Linux machines in the target mentioned above and all of the data posted above is important hazard to block its distribution. The worm is hitting a box, scan for more and hitting some more too, I guess this happened from 6 months ago until now, and the hacker is sitting there in Russia network for accessing 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.

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.

#MalwareMustDie!

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)


77fe3acda611f7706f5adca39cce8131ba1f8c531a33a4040931132ab122bbff

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.

Epilogue

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

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

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]

Background

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


{
  "ip": "130.211.127.186",
  "hostname": "186.127.211.130.bc.googleusercontent.com",
  "prefix": "130.211.0.0/16",
  "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
pty
architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
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- 

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
SYMBOL TABLE:
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 "8.8.8.8", 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/libdl.so.2
/lib/i386-linux-gnu/i686/cmov/libnss_compat.so.2
/lib/i386-linux-gnu/i686/cmov/libnsl.so.1     // malwre use these libs to resolve
/lib/i386-linux-gnu/i686/cmov/libnss_nis.so.2
/lib/i386-linux-gnu/i686/cmov/libnss_files.so.2
/usr/share/locale/locale.alias         // accompany the info harverst
/usr/share/locale/en_US/LC_MESSAGES/libc.mo
/usr/share/locale/en/LC_MESSAGES/libc.mo
usr/share/locale/en_US/LC_MESSAGES/psmisc.mo
/usr/share/locale/en/LC_MESSAGES/psmisc.mo", 
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
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:
/bin/uname         
/bin/nvram         
/usr/sbin/nvram    
/etc/ISP_name      
/etc/Model_name
and drops these files:
/tmp/udevd0.pid
/var/lock/.x001804289383
/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:

;; QUESTION SECTION:
;xxx.pokemoninc.com.         IN A

;; ANSWER SECTION:
xxx.pokemoninc.com.     845  IN CNAME   bnet.pokemoninc.com.
bnet.pokemoninc.com.    845  IN A       88.198.71.83
bnet.pokemoninc.com.    845  IN A       83.143.80.227
bnet.pokemoninc.com.    845  IN A       211.103.199.98
bnet.pokemoninc.com.    845  IN A       49.231.211.193
bnet.pokemoninc.com.    845  IN A       61.156.43.106
bnet.pokemoninc.com.    845  IN A       203.141.196.145
bnet.pokemoninc.com.    845  IN A       202.103.224.85

;; AUTHORITY SECTION:
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:

130.211.127.186
88.198.71.83
83.143.80.227
211.103.199.98
49.231.211.193
61.156.43.106
203.141.196.145
202.103.224.85 

GeoIP information (for cleaning up purpose):

IP Address, City, Region, Country Name
130.211.127.186, Mountain View, CA, United States
88.198.71.83, , , Germany
83.143.80.227, , , Norway
211.103.199.98, Beijing, 22, China
49.231.211.193, , , Thailand
61.156.43.106, Jinan, 25, China
203.141.196.145, , , Japan
202.103.224.85, Nanning, 16, China

IP address | Reversed | ASN|Prefix|ASN|CN|ISP
130.211.127.186 | 186.127.211.130.bc.googleusercontent.com. |15169 | 130.211.0.0/16 | GOOGLE | US | google.com | Google Inc.
88.198.71.83 | static.88-198-71-83.clients.your-server.de. |24940 | 88.198.0.0/16 | HETZNER | DE | hetzner.de | Hetzner Online AG
83.143.80.227 | kdb.servetheworld.net. |34989 | 83.143.80.0/21 | SERVETHEWORLD | NO | servetheworld.net | ServeTheWorld AS
211.103.199.98 |  |4808 | 211.103.192.0/18 | CHINA169 | CN | gintong.com | Beijing Huaxia Unipower Network Co. Ltd
49.231.211.193 |  |45458 | 49.231.211.0/24 | SBN-AWN-AS-02 | TH | sbn.co.th | 408/60 PHP Bld. 15th Fl Phaholyothin Rd Samsen Nai Phayathai
61.156.43.106 |  |4837 | 61.156.0.0/16 | CHINA169 | CN | chinaunicom.com | China Unicom Shandong Province Network
203.141.196.145 | html.city.shiojiri.lg.jp. / html.city.shiojiri.nagano.jp. |17518 | 203.141.192.0/19 | SHIOJIRI | JP | city.shiojiri.nagano.jp | Shiojiri City
202.103.224.85 |  |4134 | 202.103.192.0/18 | 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)
186.127.211.130.bc.googleusercontent.com (one of payload infection server)

Hashes:

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.

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

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