Thursday, July 16, 2015

MMD-0037-2015 - A bad Shellshock & Linux/XOR.DDoS CNC "under the hood"

The background

Yesterday was a hectic day when we gathered to check all recent ELF threats cross-fired in the internet traffic when I was informed of a recent shellshock attack. Seeing the command pattern of the one-liner shell executed script used I knew almost instantly it was Linux/XOR.DDoS, I checked the payload and tweeted it as per below, which is obviously a PRC (people rep of China) crook product malware known as Linux/XOR.DDoS


Well.. it was past my bed time and I about to sleep so I asked our expert mates MMD ELF Team who are living in other part of our globe to check whether this one has something new.

It turned out that because of this findings I couldn't even sleep at all until almost morning, and this post is explaining you why.

The shellshock

The shellshock was fired to the victims on July 13th, 2015. I will go straight to the beautified code of the one-liner bash command injected through it:

For a summary of what this command do in a paragraph is:

Being executed under the UID of the web server, this one-liner script removed the process ID file of sftp daemon (pid files are written by some programs to record their process ID while they are starting), checking whether the file 6000.rar exists in the current directory to then delete it if exists, and then executing the download for 6000.rar file from multiple IP addresses (43.255.188.2 / 103.20.195.254 / 122.10.85.54) in their root directories by either wget or curl software, checked if the download file is there to then change the permission into executable and execute it with printing message "ExecOK". And then, even if the file wasn't downloaded successfully, it then check your distribution info, HDD status, processes (if it hits the linux box will show UID, PID, PPID, Time & Command..but in BSD will bring "different interesting" result :D) and check your ethernet connection showing local, remote address w/program that runs it. To then print message "ExecOK". Then the script will print contents of process ID of sftp, mount and gcc, following by printing message "InstallOK".

In the last part it set the download URL to one of previously mentioned IP address to download (by using either wget or curl) the g.rar file, permit executable of that file after downloaded and to execute it. To be noted, in most Linux/XOR.DDoS shellshock cases the last part was not executed but commented with sharp "#".

The Linux/XOR.DDoS payloads

Historically, MalwareMustDie is the first who detected this ELF threat variant, and we named it as Linux/XOR.DDoS, the analysis was posted in our blog on Sept 29th 2014 [link]. This malware became a big problem in early 2015 that IT media and SANS ISC made coverage of it i.e. [-1-] [-2-] [-3-] [-4-]

This threat is different to other similar Chinese ELF DDOS'ers for usage of many decoding (it used to be an encoded installation script) and encryption (XOR based) used. So our team like to crack this malware threat as if playing CTF with the malware maker. It's good to use our brain well after our day work (or schools). We open and maintain repository of this malware in kernelmode [link]. And the recent incident of Linux/XOR.DDoS can be found in our report-->[link]. The malware is always connected to a hacking effort and owning the victim's server with a rootkit.

We can pick any of the IP listed in the shellshock infection one-liner command shell script snipped above, to download the hidden payloads they're using like I did below brutes: (not all, for the idea only)

Here's the collection of the payloads collected, thanks to great team work.

We see there's two kind of sample there, unstripped & encoded+stripped one. I pick the hash 73fd29f4be88d5844cee0e845dbd3dc5 and 758a6c01402526188f3689bd527edf83 for my check..

The sample 73fd29f4be88d5844cee0e845dbd3dc5 is typical known XOR.DDoS ELF x32 variant, compiled by below project set of codes:

..and obviously a known pattern, see the decrypting way below:

..and the values of the overall decryption..

A good decrypting can show you straight to the domain used by XOR.DDoS as CNC, in this case is:
www1.gggatat456.com in 103.240.141.54
registered in ENOM under privacy protected contact ID.

   Domain Name: GGGATAT456.COM
   Registrar: ENOM, INC.
   Registry Domain ID: 1915186707_DOMAIN_COM-VRSN
   Sponsoring Registrar IANA ID: 48
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Name Server: DNS1.NAME-SERVICES.COM
   Name Server: DNS2.NAME-SERVICES.COM
   Name Server: DNS3.NAME-SERVICES.COM
   Name Server: DNS4.NAME-SERVICES.COM
   Name Server: DNS5.NAME-SERVICES.COM
   Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
   Updated Date: 31-mar-2015
   Creation Date: 31-mar-2015
   Expiration Date: 31-mar-2016
   Last update of whois database: Wed, 15 Jul 2015 00:59:06 GMT
   Tech Email: QJJLPSYSWP@WHOISPRIVACYPROTECT.COM
   Name Server: DNS1.NAME-SERVICES.COM
   Name Server: DNS2.NAME-SERVICES.COM
   Name Server: DNS3.NAME-SERVICES.COM
   Name Server: DNS4.NAME-SERVICES.COM
   Name Server: DNS5.NAME-SERVICES.COM

Different with the previous cases, in the infection analyzed we captured the sample was establishing ssh connection in communicating with CNC and downloading encrypted data by it:

Since I had many more matters to explain in this post and this malware were analyzed/discussed many times in kernelmode repositories we opened/keep on posting, in previous MMD blogs or on other research entity sites too, I will not go too details this binary now but will focus to decode the sources of this infection and infrastructure used by them for the dismantling and stopping purpose.

The g.rar with hash 758a6c01402526188f3689bd527edf83 is a bit different. It was ELF-stripped binary (just to make reverse engineering 2% more difficult), and that can be overcame by simple code-mapping:

- they included the deflate.c code (obviously ver 1.2.1.2) [link] to obfuscate data with zlib compression

[Corrected] I mixed up the above zlib part with crypted part below, thanks VT friend for heads up.
The below values of XOR encrypted combined with base64 data is also spotted, we did not see it in the others:

The PoC and the more detail reversing for g.rar is to be added in this part, please take a rain check.

[Additional] Reversing information below is added via good contribution from Mr.Ivan Korolev (thank you very much for your help!) from his reversing on g.rar / 7e2280a2dff5028ef2ab37bd420af5d120dfc1d8:
1. It's backdoor specific commands list (includes "download & run", "backconnect", "download file to location", "set config parameters", "connect to specified C&C" ). And the function that handles C&C communication is located at 0x0804C46E.
2. Zlib is being used twice: (2.1.) When backdoor collects information about the infected system. Collected information XOR-ed with random 0x20-bytes-long key, encoded with base64 and finally compressed with zlib. (2.2.)When backdoor downloads compressed file (cmd id == 0x03)

Thank you Ivan! [/Additional]

A nice tool to deflate compressed zlib data I recommend this nice pipe code [link].

After you done the rest of (g.rar) binary, the result will show you the CNC hostname of GroUndHog.MapSnode.CoM in 211.110.1.32.
As a simple PoC for this hostname see the below picture, and I think together with the above mentioned IP list this is also the XOR.DDoS crook's infrastructure:

Well, this domain also registered in ENOM by the same pattern:

   Domain Name: MAPSNODE.COM
   Registrar: ENOM, INC.
   Sponsoring Registrar IANA ID: 48
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Name Server: DNS1.NAME-SERVICES.COM
   Name Server: DNS2.NAME-SERVICES.COM
   Name Server: DNS3.NAME-SERVICES.COM
   Name Server: DNS4.NAME-SERVICES.COM
   Name Server: DNS5.NAME-SERVICES.COM
   Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
   Updated Date: 11-may-2015
   Creation Date: 11-may-2015
   Expiration Date: 11-may-2016
   Last update of whois database: Wed, 15 Jul 2015 07:16:23 GMT
   Tech Email: RRRPBHYTFS@WHOISPRIVACYPROTECT.COM
   Name Server: DNS1.NAME-SERVICES.COM
   Name Server: DNS2.NAME-SERVICES.COM
   Name Server: DNS3.NAME-SERVICES.COM
   Name Server: DNS4.NAME-SERVICES.COM
   Name Server: DNS5.NAME-SERVICES.COM 

The g.rar upon executed will do self-copied in reachable **/**/[s]bin directories, and if not having permissions for those location it will be resided in /tmp or /var/tmp, under random names and flooding the system with spawn & re-spawning process to persist his way to keep alive and connect to CNC.

Below is a single process of g.rar looks like post-infected state in lsof:

COMMAND    PID USER   FD   TYPE    DEVICE SIZE/OFF    NODE NAME
qrD6E16p 12514 test  cwd    DIR       8,6     4096 1048613 /TESTDIR
qrD6E16p 12514 test  rtd    DIR       8,1     4096       2 /
qrD6E16p 12514 test  txt    REG       8,1   664896  264910 /tmp/qrD6E16p
qrD6E16p 12514 test    0u  IPv4 133785570      0t0     TCP MMD.SCREW.XOR.DDOS:37098->211.110.1.32:ssh (CLOSE_WAIT)

It does flooded your system non-stoppable:

qrD6E16p  12514              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
qrD6E16p  12514              test  rtd       DIR        8,1     4096          2 /
qrD6E16p  12514              test  txt       REG        8,1   664896     264910 /tmp/qrD6E16p
qrD6E16p  12514              test    0u     IPv4  133785570      0t0        TCP MMD.SCREW.XOR.DDOS:37098->211.110.1.32:ssh (CLOSE_WAIT)
qrD6E16p  12514 12523        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
qrD6E16p  12514 12523        test  rtd       DIR        8,1     4096          2 /
qrD6E16p  12514 12523        test  txt       REG        8,1   664896     264910 /tmp/qrD6E16p
qrD6E16p  12514 12523        test    0u     IPv4  133785570      0t0        TCP MMD.SCREW.XOR.DDOS:37098->211.110.1.32:ssh (CLOSE_WAIT)
qrD6E16p  12514 12524        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
qrD6E16p  12514 12524        test  rtd       DIR        8,1     4096          2 /
qrD6E16p  12514 12524        test  txt       REG        8,1   664896     264910 /tmp/qrD6E16p
qrD6E16p  12514 12524        test    0u     IPv4  133785570      0t0        TCP MMD.SCREW.XOR.DDOS:37098->211.110.1.32:ssh (CLOSE_WAIT)
RodiXi3   12631              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
RodiXi3   12631              test  rtd       DIR        8,1     4096          2 /
RodiXi3   12631              test  txt       REG        8,1   664896     268768 /tmp/RodiXi3
QPqitjI5x 12633              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
QPqitjI5x 12633              test  rtd       DIR        8,1     4096          2 /
QPqitjI5x 12633              test  txt       REG        8,1   664896     268769 /tmp/QPqitjI5x6nd
PR2PhLH   12635              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
PR2PhLH   12635              test  rtd       DIR        8,1     4096          2 /
PR2PhLH   12635              test  txt       REG        8,1   664896     268770 /tmp/PR2PhLH
hKE6wECZG 12637              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
hKE6wECZG 12637              test  rtd       DIR        8,1     4096          2 /
hKE6wECZG 12637              test  txt       REG        8,1   664896     268771 /tmp/hKE6wECZGs2
WuMKsp3   12831              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
WuMKsp3   12831              test  rtd       DIR        8,1     4096          2 /
WuMKsp3   12831              test  txt       REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831              test    0u     IPv4  133786107      0t0        TCP MMD.SCREW.XOR.DDOS:37112->211.110.1.32:ssh (CLOSE_WAIT)
WuMKsp3   12831 12844        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
WuMKsp3   12831 12844        test  rtd       DIR        8,1     4096          2 /
WuMKsp3   12831 12844        test  txt       REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831 12844        test    0u     IPv4  133786107      0t0        TCP MMD.SCREW.XOR.DDOS:37112->211.110.1.32:ssh (CLOSE_WAIT)
WuMKsp3   12831 12844        test    1r      REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831 12844        test    2w      REG        8,1   622592     268776 /tmp/f9Ca6W
WuMKsp3   12831 12845        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
WuMKsp3   12831 12845        test  rtd       DIR        8,1     4096          2 /
WuMKsp3   12831 12845        test  txt       REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831 12845        test    0u     IPv4  133786107      0t0        TCP MMD.SCREW.XOR.DDOS:37112->211.110.1.32:ssh (CLOSE_WAIT)
WuMKsp3   12831 12845        test    1r      REG        8,1   664896     268772 /tmp/WuMKsp3
WuMKsp3   12831 12845        test    2w      REG        8,1   622592     268776 /tmp/f9Ca6W
nZS4n     12912              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
nZS4n     12912              test  rtd       DIR        8,1     4096          2 /
nZS4n     12912              test  txt       REG        8,1   664896     268765 /tmp/nZS4n
5nCVmqNjx 12914              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
5nCVmqNjx 12914              test  rtd       DIR        8,1     4096          2 /
5nCVmqNjx 12914              test  txt       REG        8,1   664896     268766 /tmp/5nCVmqNjx
Rf8tMCwI  12916              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
Rf8tMCwI  12916              test  rtd       DIR        8,1     4096          2 /
Rf8tMCwI  12916              test  txt       REG        8,1   664896     268773 /tmp/Rf8tMCwI
8M0LORVgQ 13074              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
8M0LORVgQ 13074              test  rtd       DIR        8,1     4096          2 /
8M0LORVgQ 13074              test  txt       REG        8,1   664896     268782 /tmp/8M0LORVgQVd
8M0LORVgQ 13074              test    0u     IPv4  133786540      0t0        TCP MMD.SCREW.XOR.DDOS:37124->211.110.1.32:ssh (CLOSE_WAIT)
8M0LORVgQ 13074 13091        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
8M0LORVgQ 13074 13091        test  rtd       DIR        8,1     4096          2 /
8M0LORVgQ 13074 13091        test  txt       REG        8,1   664896     268782 /tmp/8M0LORVgQVd
8M0LORVgQ 13074 13091        test    0u     IPv4  133786540      0t0        TCP MMD.SCREW.XOR.DDOS:37124->211.110.1.32:ssh (CLOSE_WAIT)
8M0LORVgQ 13074 13092        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
8M0LORVgQ 13074 13092        test  rtd       DIR        8,1     4096          2 /
8M0LORVgQ 13074 13092        test  txt       REG        8,1   664896     268782 /tmp/8M0LORVgQVd
8M0LORVgQ 13074 13092        test    0u     IPv4  133786540      0t0        TCP MMD.SCREW.XOR.DDOS:37124->211.110.1.32:ssh (CLOSE_WAIT)
AL2RROHuq 13137              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
AL2RROHuq 13137              test  rtd       DIR        8,1     4096          2 /
AL2RROHuq 13137              test  txt       REG        8,1   664896     268780 /tmp/AL2RROHuq
ovxnJH438 13139              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
ovxnJH438 13139              test  rtd       DIR        8,1     4096          2 /
ovxnJH438 13139              test  txt       REG        8,1   664896     268781 /tmp/ovxnJH438UHem
B2xPwN    13141              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
B2xPwN    13141              test  rtd       DIR        8,1     4096          2 /
B2xPwN    13141              test  txt       REG        8,1   664896     268783 /tmp/B2xPwN
pR9QwfBw  13143              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
pR9QwfBw  13143              test  rtd       DIR        8,1     4096          2 /
pR9QwfBw  13143              test  txt       REG        8,1   664896     268784 /tmp/pR9QwfBw
auMlF6Xtv 13145              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
auMlF6Xtv 13145              test  rtd       DIR        8,1     4096          2 /
auMlF6Xtv 13145              test  txt       REG        8,1   664896     268765 /tmp/auMlF6XtvW9Q
iKk6F78   13147              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
iKk6F78   13147              test  rtd       DIR        8,1     4096          2 /
iKk6F78   13147              test  txt       REG        8,1   664896     268773 /tmp/iKk6F78
OnnSe0Asd 13149              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
OnnSe0Asd 13149              test  rtd       DIR        8,1     4096          2 /
OnnSe0Asd 13149              test  txt       REG        8,1   664896     268775 /tmp/OnnSe0AsdJW7
JHpy2Tv   13151              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
JHpy2Tv   13151              test  rtd       DIR        8,1     4096          2 /
JHpy2Tv   13151              test  txt       REG        8,1   664896     268776 /tmp/JHpy2Tv
Hl1GIXA1S 13220              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
Hl1GIXA1S 13220              test  rtd       DIR        8,1     4096          2 /
Hl1GIXA1S 13220              test  txt       REG        8,1   664896     268780 /tmp/Hl1GIXA1SVEnOY
Hl1GIXA1S 13220              test    0u     IPv4  133786857      0t0        TCP MMD.SCREW.XOR.DDOS:37132->211.110.1.32:ssh (CLOSE_WAIT)
Hl1GIXA1S 13220 13239        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
Hl1GIXA1S 13220 13239        test  rtd       DIR        8,1     4096          2 /
Hl1GIXA1S 13220 13239        test  txt       REG        8,1   664896     268780 /tmp/Hl1GIXA1SVEnOY
Hl1GIXA1S 13220 13239        test    0u     IPv4  133786857      0t0        TCP MMD.SCREW.XOR.DDOS:37132->211.110.1.32:ssh (CLOSE_WAIT)
Hl1GIXA1S 13220 13240        test  cwd       DIR        8,6     4096    1048613 /TESTDIR
Hl1GIXA1S 13220 13240        test  rtd       DIR        8,1     4096          2 /
Hl1GIXA1S 13220 13240        test  txt       REG        8,1   664896     268780 /tmp/Hl1GIXA1SVEnOY
Hl1GIXA1S 13220 13240        test    0u     IPv4  133786857      0t0        TCP MMD.SCREW.XOR.DDOS:37132->211.110.1.32:ssh (CLOSE_WAIT)
fggF0R    13290              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
fggF0R    13290              test  rtd       DIR        8,1     4096          2 /
fggF0R    13290              test  txt       REG        8,1   664896     268765 /tmp/fggF0R
KwBN6mHut 13292              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
KwBN6mHut 13292              test  rtd       DIR        8,1     4096          2 /
KwBN6mHut 13292              test  txt       REG        8,1   664896     268773 /tmp/KwBN6mHutUe
BaLWO7KCY 13294              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
BaLWO7KCY 13294              test  rtd       DIR        8,1     4096          2 /
BaLWO7KCY 13294              test  txt       REG        8,1   664896     268776 /tmp/BaLWO7KCY
MPNQT08od 13296              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
MPNQT08od 13296              test  rtd       DIR        8,1     4096          2 /
MPNQT08od 13296              test  txt       REG        8,1   664896     268781 /tmp/MPNQT08odg
6IpaJFDff 13315              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
6IpaJFDff 13315              test  rtd       DIR        8,1     4096          2 /
6IpaJFDff 13315              test  txt       REG        8,1   664896     268783 /tmp/6IpaJFDff5ZS
7IkMtxQ0d 13317              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
7IkMtxQ0d 13317              test  rtd       DIR        8,1     4096          2 /
7IkMtxQ0d 13317              test  txt       REG        8,1   664896     268786 /tmp/7IkMtxQ0dJQC9
86cG6TaT  13321              test  cwd       DIR        8,6     4096    1048613 /TESTDIR
86cG6TaT  13321              test  rtd       DIR        8,1     4096          2 /
86cG6TaT  13321              test  txt       REG        8,1   664896     268788 /tmp/86cG6TaT

To reverse is a thing, to PoC what you reversed is correct is another thing. I patched my kernel to intercept every malware activities and dropped the method of depending on system calling tracer to have better view and the result is good, it applying the method to g.rar the PoC of the CNC also can be spotted in its callback process:

// cnc
domain:
GroUndHog.MapSnode.CoM
IP: 211.110.1.32
sendto(0, "#o\1\0\0\1\0\0\0\0\0\0\tGroUndHog\10MapSnode\3CoM"..., 40, 0, 
   {sa_family=AF_INET, 
    sin_port=htons(53), 
    sin_addr=inet_addr("8.8.8.8")}, 16) = 40

Summing up the malware related IP addresses involved up to this point:

The IP addresses used in the shellshock and in the CNC was checked under the below details:

{
  "ip": "43.255.188.2",
  "country": "HK",
  "loc": "22.2500,114.1667",
  "org": "AS134176 Heilongjiang Province hongyi xinxi technology limited"

  "ip": "103.20.195.254",
  "country": "HK",
  "loc": "22.2500,114.1667",
  "org": "AS3491 Beyond The Network America, Inc."

  "ip": "122.10.85.54",
  "country": "HK",
  "loc": "22.2500,114.1667",
  "org": "AS55933 Cloudie Limited"

  "ip": "211.110.1.32",
  "country": "KR",
  "loc": "37.5700,126.9800",
  "org": "AS9318 Hanaro Telecom Inc."
}

The samples are all in the Virus Total servers, please search these hashes,

MD5 (3503.rar) = 238ee6c5dd9a9ad3914edd062722ee50
MD5 (3504.rar) = 09489aa91b9b4b3c20eb71cd4ac96fe9
MD5 (3505.rar) = 5c5173b20c3fdde1a0f5a80722ea70a2
MD5 (3506.rar) = d9304156eb9a263e3d218adc20f71400
MD5 (3507.rar) = 3492562e7537a40976c7d27b4624b3b3
MD5 (3508.rar) = ba8cc765ea0564abf5be5f39df121b0b
MD5 (6000.rar) = 73fd29f4be88d5844cee0e845dbd3dc5
MD5 (6001.rar) = a5e15e3565219d28cdeec513036dcd53
MD5 (6002.rar) = fd908038fb6d7f42f08d54510342a3b7
MD5 (6003.rar) = ee5edcc4d824db63a8c8264a8631f067
MD5 (6004.rar) = 1aed11a0cbc2407af3ca7d25c855d9a5
MD5 (6005.rar) = 2edd464a8a6b49f1082ac3cc92747ba2
MD5 (g.rar) = 758a6c01402526188f3689bd527edf83 

"Linux/killfile" ELF (downloader, kills processes & runs etc malware)

We've never seen about this before, so I will explain here a bit. Linux/XOR.DDoS through the encrypted communication will download other malware files from the remote CNC. In the CNC there is a set of ELF malware downloaders, depends on the architecture of the infected server/host, one of the set of binary (x32 or x64) below will be run in the infected machine for that purpose. These ELF binaries are ELF executable killfile module, a downloader for the config files for aiming the process to be killed and "other" malware be run. It has the logic to read strings from textual file (kill.txt or run.txt) which seperated token with the delimeter pipe "|" for the kill/run functionality mentioned.

MD5 (killfile32) = e98b05b01df42d0e0b01b97386a562d7  15282 Apr  3  2014 killfile32*
MD5 (killfile64) = 57fdf267a0efd208eede8aa4fb2e1d91  20322 Apr  3  2014 killfile64*
I will explain some important functions of this module.

killfile malware was coded in C, and these are the source files used:

 'crtstuff.c'
 'btv1.2.c'
 'http_download.c'
 'libsock.c'
It fakes itself as the bluetooth process:

Faking Microsoft too..(try to read the code below, it's a self-explanatory)

In the first two samples we grabbed, it kills the listed process name which was downloaded from the below hostname AND IP:

kill.et2046.com 
sb.et2046.com
115.23.172.31
below is the reversing sheet for the killing list:

The IP is located in Korea Telecom, which it seems the bad actor hacked the server:
{
  "ip": "115.23.172.31",
  "hostname": "kill.et2046.com",
  "city": Seoul,
  "country": "KR",
  "loc": "37.5700,126.9800",
  "org": "AS4766 Korea Telecom"
}
And the et2046.com domain used can't be good one, is registered in GoDaddy under below information:
   Domain Name: ET2046.COM
   Registrar: GODADDY.COM, LLC
   Sponsoring Registrar IANA ID: 146
   Whois Server: whois.godaddy.com
   Referral URL: http://registrar.godaddy.com
   Name Server: A.DNSPOD.COM
   Name Server: B.DNSPOD.COM
   Name Server: C.DNSPOD.COM
   Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
   Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
   Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
   Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited
   Updated Date: 21-dec-2014
   Creation Date: 27-nov-2012
   Expiration Date: 27-nov-2016
   Last update of whois database: Thu, 16 Jul 2015 22:17:47 GMT <<<
With the contact email address of tuhao550@gmail.com:
   Registry Registrant ID:
   Registrant Name: smaina smaina
   Registrant Organization:
   Registrant Street: Beijing
   Registrant City: Beijing
   Registrant State/Province: Beijing
   Registrant Postal Code: 100080
   Registrant Country: China
   Registrant Phone: +86.18622222222
   Registrant Email: "tuhao550@gmail.com"
this domain and this email address also found by our friend Dr. DiMino in DeepEndResearch [link]

The activity of the domain above according to passive DNS shows as per below:

Back to what Linux/KillFile ELF malware does. It then downloads & executes the other malicious software described in the run.txt downloaded from the URL described above, and in this case the contents of run.txt is the infamous "IptabLes|x" ELF DDoS'er malware!! Wow, so Xor.DDoS is also "merging" with IptabLes|x too.. I thought that only ChinaZ who was just starting to "collaborate" with IptabLes|x. Is IptabLes|x becoming open source in China malware underground now? Why recent dangerous actors are starting to switch their tools here? This is the fact to be checked further..

The binary is clean and you can see the download source, files to download, and the fake user-agent set (noted string: "TencentTraveler" ), that can be used to quick mitigate the threat:

These first two Linux/KillFile ELF malware were compiled in 2014 it was old binaries, but seems to be used many times already in several infection too. yet the VT score for these modules are still zero, see--> [-1-] and [-2-]. There is another Linux/KillFile prepared by the crook for THIS infection, inside the "job package", we will discuss it in Under the Hood part.

We are adding the new ELF Linux/killfile on category downloader in in our beloved repository at kernelmode.

Under the hood

Maybe you read many similar reports like previous parts of this post so many times. Maybe you get bored by information about China malware..CNC..IP..DDOS..with same stories and reports. This time we have a new report of what's Under the Hood of those CNC actually. Beforehand, everything that is posted here is done by remote legit access via HTTP protocol ONLY, so I am sorry if you expect more than that, no hacking, no offensive method were applied. And all of these efforts from this section are done by the team work of our ELF Team.

We've been hit by XOR.DDoS many times without knowing much what are they up to actually. Curiosity kills, so we randomly select the reachable IP to check what can be legally collected. And from one of the IP announced above we collected these "specific" passworded archives:

Some archives is passworded by the crooks, but it's crackable :-) We won't reveal the password in here in here since it contains rootkits, vulnerability scanner, CNC program, ELF VIRUS and trojans (downloader/backconnect) a set used by this bad actor(s) to attack us. And the file is still up and alive:

The RDP scanner set rdp.rar

This is a literally ELF RDP scanner set, the engine scanner (rdp ELF executable binary) is scanning the defined range of IP to alive hosts that runs the RDP to be bruted with the dictionary attack for the user's login and password. It has the control parameter to set the thread used for scanning and the termination condition for the first matched user. It is obviously the coder is not native English speaking person, we saw a lot of these in windows version but we think this ELF version tool is being used by the very limited people only. Below is the screenshot of it's CLI (command line user's interface):

The rdp binary program is the main engine of rdp's hacktool set, in order to automate an attack the crook is using the accompanied scripts for that purpose, we found the shell script "a" and "start" for that purpose, with the snip as per below snapshot. Noted, without the "rdp" binary these scripts are just useless.

The XOR.DDoS bad actor left some data in the text files used in this ELF hacking set, you can see the snips of the data contains: user name used to brute, wordlist to brute, and there is some result for the scanning done by crook in suspected output file vuln.txt, picture as PoC

Seeing the screeshots above I think it is very clear to explain of what rdp can do, and how it was used by the Linux/XOR.DDoS actor to brute some windows networks for their hacking activity, so I don't make any video of it. This rdp ELF is new to us, we will call it as Linux/rdp as ELF hacktool from now on and making a new repository for this variant in beloved kernelmode.

Is that all for what's in rdp.rar? No, there is a binary named as "psc", it's an ELF executable with the below details:

16840 Nov 24 psc fcd078dc4cec1c91ac0a9a2e2bc5df25
psc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
     dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
If you just check this psc into the Virus Total [link] it is shown with a full verdict (37/56) from AV companies as a Linux ELF Virus, a known nasty variant called Linux/RST who infect to other ELF & opening backdoor [link]. This looks very bad isn't it...

The ELF "psc" is supposedly a hacktool the port scanner called "pscan" that is used a lot by blackhats for scanning and hacking the server by scanning the victim's SSH ports, I know whitehats that's using it for good purpose too, like for penetration test. MMD blog is actually discussed about this hacktool in case MMD-0023-2014 [link].
We test-run it. It showed what "pscan" does, looks like the XOR.DDoS is shortened he name into "psc".

The pscan strings inside is as below...and some code reversing shows that many of pscan functions are there too.

Now..why it was called infected by virus? Thank's to Miroslav Legen for advising me to check the entry point part. The actual entry point of "psc" was "patched" to 0x08049364 and malicious entry point is taking over the real one (0x080487a8), for the purpose to run the malicious commands and then go to the original entry point that has being saved in some values. The picture below is explaining reversing note I did while checking this entry point shifting phenomenon.

For the update information, the "rdp" ELF binary above is also has the entry point shifted too..

The fact is..We found many samples of malware or hacktools detected in the IP in China's hosts are infected also with another malware, so this could be just one of such case, it's not a trusted environment anyway, and we suggest please don't run anything that coming from untrusted environment. I am not so sure if the XOR.DdoS actor are noticing this or are in purpose for putting this virus infected ELF hacktool into their archive or not (naah..I think they don't know about this..considering they pout password to the archive), But I really hope they had been infected by this badness instead :D

The set of .IptabLes botnets inside of Xor.DDoS CNC

In the package called "job.rar", the actor wrapped everything needed to perform an attack to our networks into this one single file archive. It has the download modules of "killfile" with the pair of text files contain of processes to kill (kill.txt) and the malware binary name to be executed post downloads (run.txt). We explained this module in Modular "killfile" ELF section in previous section.

There is a rootkit too which I will explain and show the codes in a video it in the last section, but the point that I want to explain now is: there a set of the .IptabLes|x clients (ELF) and its server botnet CNC in side of the job.rar, these are actually files spotted inside of the job.rar archive, to be clear here's the archive:

The .IptabLes|x ELF client binaries (ELF bot malware) we already covered in previously posted analysis like in--> [-1-] and [-2-]. And these binaries has nothing new and it was set to connect to the IP where the CNC botnet (Windows PE) software is running. We move on straight to the botnet CNC software itself..

The binary is the .NET one. We uploaded it to VirusTotal here-->[link]. And I made a video of running test this CNC tool to give you the idea how is it work, as per video below:

For the details of what this botnet CNC tool can do, can be studied by reading the reversed source code we reproduced, we modified the code a bit (for can not be re-used..but is very readable) click the below snapshot picture for access (to our pastebin):

Below is the MD5 list of the IptabLes|x client and CNC botnet tool:

MD5 (777.hb) = "e2a9b9fc7d5e44ea91a2242027c2f725"
MD5 (888.hb) = "ff1a6cc1e22c64270c9b24d466b88540"
MD5 (901.hb) = "c0233fc30df55334f36123ca0c4d4adf"
MD5 (903.hb) = "f240b3494771008a1271538798e6c799"
MD5 (905.hb) = "603f16c558fed2ea2a6d0cce82c3ba3a"
MD5 (Control.exe) = "315d102f1f6b3c6298f6df31daf03dcd"

The "Linux/KillFile" set: xxz.rar, kill.txt, run.txt

In the job package [link] there is a set of Linux/KillFile malware, with the binary faking as rar file called "xxz.rar". This Linux/KillFile is exactly work with the same logic with the previously explain in above section [link] , the difference is, the previous two samples was used by the bad actor for etc purpose unrelated to this infection, but this xxz.rar is there to be used on this campaign. The role of the Linux/KillFile is the downloader and installation of the Linux/IptabLes|x client malware botnet described previously.

In this version of Linux/KillFile, after execution the downloaded file, it uses fake "version"(in this case it was downloaded .IptabLes|x) into "Microsoft"..

The other big difference is in the data of remote hosts they use to connect and fetch data from remote:

Accordingly we have a new infrastructure IP of: 61.33.28.194 and 115.23.172.47 which is also located in Korea:

{
  "ip": "61.33.28.194",
  "hostname": "No Hostname",
  "city": null,
  "country": "KR",
  "loc": "37.5700,126.9800",
  "org": "AS3786 LG DACOM Corporation"
}
I am pretty sure that et2046.com domain is under control if the bad actor and below chronological IP data linked to this case /et2046.com, must be linked to the actor:
115.23.172.31 (current)
115.23.172.6 (May 2014)
115.23.172.47 (current)
This is strange since many of the Korea IP addresses was used in his infrastructure, I think S. Korea cyber law enforcement has to notice this matter..

The "xwsniff rootkit" source code

For this part, I made a video to show what "xwsniff rootkit" source code is, which showing all of the source code and that is more than words..and this is an evidence of cyber crime. This rootkit is found in the CNC in several places, including in the job.rar, a package which is used to aim the target. Undoubtedly that one of their objective is to root the infected server. This is the safest way for you to peek and study what this rootkit does for mitigation purpose ..and yes we secured this source code.

This "xwsniff rootkit" package installer is including the FTP daemon (now we know WHY they stopped the ftp pid isn't it?), OpenSSH, and PAM source code, to be compiled together with the rootkit parts combined with the "stealth rootkit" and it has its own kernel's source code too. The NIX system who got infected by this rootkit will be badly damaged, no easy way to clean this rootkit manually, so I suggest you to reinstall the box. This rootkit is designed to aim the Linux platform only, but with a little modification all NIX boxes can be aimed too.

For the functionality, it has the invincible function designed to make the victims didn't know whether the server was infected, backdoor with shell, and http-downloader, with additional some several functions. Ok ok..enough of "promotion"..let's go straight to see the below video, enjoy!

Botnet CNC infrastructure

Below is the the list of overall IP of hosts used for this infection campaign:

"43.255.188.2" (shellshock landing)
"103.20.195.254" (shellshock landing)
"122.10.85.54"  (shellshock landing)
"103.240.141.54" (Xor.DDoS CNC server)
"211.110.1.32" (Xor.DDoS CNC server)
"115.23.172.31" (.IptabLes|x download server)
"115.23.172.47" (.IptabLes|x download server)
"61.33.28.194" (.IptabLes|x download server)
"115.23.172.6" (Iptables|x previous IP record)
Their location is in:

Below is the list of overall hostnames used for this infection:

kill.et2046.com
sb.et2046.com
www1.gggatat456.com
GroUndHog.MapSnode.CoM

Follow up & prologue

A lot of follow up has to be done for this case. For the samples, we uploaded them all to VT, including the killfile XOR.DDoS downloader ELF module. But we don't share the rootkit except to antivirus/filtration industries and to law enforcement. It's a dangerous tool. Please read our LEGAL DISCLAIMER for that matter here-->[link] .Give us time to prepare the package for sharing, so bear the slow follow. Send us your request in the comment part with using your entity's domain's email addresses.

We will share samples to kernelmode for researchers only, and Virus Total.
The Linux/KillFile was added to kernelmode [link] and VirusTotal [link]
.IptabLes|x botnet CNC tool WInPE(.NET) is limited shared in kernelmode [link]
The others are in the VirusTotal (check for hashes) & not shared in kernelmode because infected by dangerous other virus.
The rootkit source code is shared started from July 20th 2015, and accepting request from now.

Emerging Threat good folks was releasing the open IDS signature for protecting the users for product/open source that uses it:

The blog will be added with additional information here and there, it is a very tiring work to wrote & test these non-stop, I will improve this post step by step after released. I apologize for the misspell & bad typing.

This project is team work of MalwareMustDie ELF team mates who did a good work supporting the case. And to fellow researchers who were helping is with support. findings, advise and information, You guys rock! We can not be here this long if you're not around. Special thank's to folks in DHA/Dallas Hackers Association [link], they're very cool guys, listen up to their latest interesting podcast (DHAfter Hours), it's mentioning MMD [link]. Respect!

Follow up

The attacks are still coming, detected in August 4th 2015, using SAME infrastructure to infect since the payloads are still in there.

#MalwareMustDie

Sunday, July 5, 2015

MMD-0036-2015 - KINS (or ZeusVM) v2.0.0.0 tookit (builder & panel source code) leaked.

This sharing has been closed due to time limit (60days) - Thank you

The background

KINS (or ZeusVM to be precised) v2.0.0.0 tookit (builder & panel source code) was leaked and spread in all over the internet. On Jun 26th 2015 we were informed (thank you Xylit0l) about this and after several internal discussion, considering that: "Still so many bad guys know about this than good guys.." today we decided to raise warning about this matter by this post. So this is an information to those who may not know about the leaked package yet, and/or maybe want to have the archive of what has leaked from the trusted source.

Together with this warning also we would like to inform that KINS version 3 is on the black market now with the price of 5k according to a certain crook's affiliated forum.

This is a team work, two friends Xylit0l [link] and unixfreaxjp [link] are on the case building this report, testing, recording, screenshots, takedown sites that spread the leaked packages as much as possible..

What was leaked exactly?

What was leaked is NOT KINS version 2.0.0.0 source code but the KINS version 2.0.0.0 builder binary, as per seen in the below screenshot (taken by Xylit0l)..

..and the panel's source code as per shown in the video embedded to this post. Pictures of KINS used web panels are as the below images (taken by Xylit0l). It shows the classic style of ZeuS botnet panel:

Pictures/info posted are MMD research material bound to legal disclaimer-->[link]

Eventhough the name used by the coder is KINS 2.0.0.0. the builder configuration and the binary generated by the builder is of ZeusVM (version 2.0.0.0) and is a completely different to previous KINS version we announced in here-->[link].

Previous KINS version don't use steganography (way of hiding information by embedding messages within other, seemingly harmless messages, in this case Zeusvm hides configuration codes embedded in JPG file) while this one do, and the generated ZeusVM bot binary is similar to ZeusVM v1 and v2 samples posted in kernelmode repository-->[link] This is why we put ZeusVM in the title of the post, an evidence that KINS has adapted ZeusVM technology in their malware. This is maybe a bit confusing if you don't follow recent ZeuS malware evolution time frame, but it's the fact of what had been found & analyzed by experts.

Enough talking, show us the package!

Below is the video of what has been leaked. The video shows you: (1) the archive information and some leak sources, (2) the builder and its general demonstration (JPG config demo is in the next video), (3) the panel and its code, and the (4) ZeusVM web injection proof of concept screenshots after tested by Xylit0l in the latest version of the Firefox browser (yes, it is working fine in IE). I took the video during testing.

PoC Video #1:
PS: The comment in 2:34 has a mistake. It supposed to be "The binary & crypted module files"

Where is that Steganography PoC?

Below is the video demonstrating the Steganography technique used by the KINS/ZeusVM 2.0.0.0. The demonstration is showing us that builder can inject encrypted configuration code of KINS2/ZeusVM2 to any JPG file feed to the builder to camouflage the config. We compare the "before" and "after" code injection data of the JPG files used & generated in hex editor for comparison detail. Xylit0l and I discussed a lot to get the right injecting test scheme with correct template of its configuration..finally made it right. Sorry, we break malware apart but not using them.

PoC Video #2:

As additional information to these videos:

1. This is list of blocked IP by KINS/ZeusVM 2.0.0.0 panel's .htaccess-->[link]
2. The mod files built in hex (head):

3. The log of correct configured building:

4. The SHA256 of the builder: 7b6cc23d545dea514628669a1037df88b278312f495b97869b40882ca554fa9a [VT]
5. In Botconf [link] 2014 conference our friend @MAK of CERT Polska [link] presented a good research paper of ZeusVM threat that can be used as reference to ID the binary built-->[link]

Snapshot of important codes

The version, template built date and default config items:

The "kinsdb" was clearly stated in MySQL database name of the botnet panel too:

The PHP encryption function spotted in panel's source code to encrypt the database:

So what does it mean?

(1) We will see more of ZeusVM (version 2.0.0.0_) botnet operated in our internet since its malware & configuration builder is "FREE as air" and is "go public" now, not only from usual cyber crime crooks, but anyone with this toolkit in hand can generate ZeusVM 2.0.0.0 binaries and set it to botnets via its panel; and ; (2) We also we can expect to see a KINS/ZeusVM new version (version 3) soon too.

This is a very important information for the security community. The archive is wide spreading now, we tried very hard to take down some leaked package shared in download sites one by one but it is just way out of hand. Please help us to not letting this archive spread and distributed in the internet.
It is better for all anti malware and all threat filtration industry to know and request the leaked archive and start to research the blocking and mitigation methods, if you haven't started it yet. You can get archive or builder from here or VirusTotal or from other trusted sources.

The ITW (in the wild) emerge of many KINS 2.0.0.0 leaked tookit botnets threat has been started..

This is the update of the latest information, current date is: Mon Jul 6 23:41:30 JST 2015

As per shown in the video above, in the default configuration of the KINS 2.0.0.0 there is the image file of "server.jpg" provided by the malware coder for creating a steganographic KINS2.0.0.0 JPG injected crypted configuration file, with the graphic physical look as per below:

We follow the current detected KINS botnet up and alive operated in the internet and we found that at least 10 botnets are using the same default configuration picture and 6 of them are up and alive in the below URLs!

The bove listed URLs are KINS 2.0.0.0 steganographic config files online, generated from the builder shown in the demonstration video of leaked KINS2 toolkit in the previous section. Those URLs are currently accessible UP and ALIVE in the internet, spotted as per now..

So the new botnets using the leaked package of KINS 2.0.0.0 are actually start popping up in the internet ..running by crooks or blackhats and actively in action to infect KINS 2.0.0.0 bot PC clients to some victims..are used for the bad purpose only..

Xylit0l was advising me to add this section for security folks to notice that the leaked KINS2" toolkit is actually has started to be used and emerged into new threat wave, and I decided the best way to convince all of you is by the video.. so I recorded the confirmation I made in video below to be used as PoC evidence of the mushroomed of usage for KINS 2.0.0.0 leaked toolkit, aand (maybe) can be used for the crime evidence..

FYI..we are not happy nor proud to write this.. This is sad, to know that something bad will happen and it is actually happened in front of our own eyes.. FYI, we are still trying hard to spot and to take down new shared downloaded archive of leaked toolkit distributed in several "blackhat" forums,to do whatever we can to reduce this threat, please help us to do so. And thank you very much to many media download service for your kindly cooperate to help us to delete the shared malicious malware toolkit, you are the true heroes for this cause.

How to get the archive? (for the case from MalwareMustDie, NPO)

Please post the comment with your email address informed for the full archive request and we will send you the download link. Your post will not be published and your email address will not be shared. But please be patient for the sharing process. All follow up will be done manually and will be logged. We will prioritize requests coming from anti virus companies and threat filtration products. Then the governments' CERT & law enforcement related research entities. We will not share to individual or unnamed request, this is a very dangerous malware building tool, a crimeware and NOT sample of malware or toys to play with.
Noted: We have every right also to not sharing the archive and not responding to any untrusted/suspicious requests.

For more information of our sharing policy please read our legal disclaimer here-->[link]

Additional section

Several takedown efforts we made: (there are more of these effort than we posted here)

The bad actors who spread this leak are ↓not noticing being taken down↓ :-)

The surge of "freeware" KINS2 leaked botnets is on..

The fact: We monitored the surge of this leak-basis KINS 2.0.0.0 botnets, to found that since we start monitoring on July 7th 2015 (around midnight JST) and now..July 9th around 10am (JST), 16 new botnets are up and 11 of them are actively infecting. These detected botnets were built by the default setting of the leaked botnet toolkit. Below are two proof videos (you can see what I mean by default setting in that videos), I took them in July 7th 2015 and July 9th 10am.

The point: Please ask yourself..if less than 2 days the (known only) 16 botnets were popping up .. how many botnets we can expect within a month operated and infecting us with the same surge pace?

The Plan to mitigate this surge:

- takedown EVERY shared archives that spread by crooks in the internet
- release blocking sigs soon (if you are not yet)
- block default toolkit configuration object used download web traffic filtration scheme
- seek & clean up infrastructure used by surged botnets before it gets too many

Thank you for reading, please help to spread this awareness and stay safe!
Thank Xylit0l, he is doing very hard effort to fight, detect and act against this threat for YEARS.

MalwareMustDie!