800+ IT
News
als RSS Feed abonnieren๐ MMD-0053-2016 - A bit about ELF/STD IRC Bot: x00's CBack aka xxx.pokemon.inc
๐ก Newskategorie: Malware / Trojaner / Viren
๐ Quelle: blog.malwaremustdie.org
Background
I received the report of the host in Google cloud network is serving ELF malware:
So I downloaded them all in secure way as per follows:
{
"ip": "130.211.127.186",
"hostname": "186.127.211.130.bc.googleusercontent.com",
"prefix": "130.211.0.0/16",
"org": "AS15169 Google Inc.",
"city": "Mountain View",
"region": "California",
"country": "USA",
"loc": "37.4192,-122.0574",
"postal": "94043"
}
ELF botnet infecting routers is a bad thing, but abusing Google cloud is another bad thing. After receiving several request on the topic I decided to write this post as awareness and indicator reference, along as some SLAPS! to the malware coder and actors behind this threat, which is linked to the previous blog post in-->here.
The first slap: First look
These are ELF malware of this post, let's pick one and see how it looks in the first sight:
The binary structure and view:
The readelf summarizes its header is as follows,
I marked places where one should pay attention with, to see the headers much better can be done in objdump:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's 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: 0xc086b8
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 0x08828 0x08828 R E 0x1000
LOAD 0x000448 0x0805f448 0x0805f448 0x00000 0x00000 RW 0x1000 '
There are no sections in this file.
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.
pty: file format elf32-i386With a good text analyzer you'll find first indicator of this threat, which is the sentence quoted from bakemonogatari anime iinchou character which was printed hard coded in this ELF in roumaji(read: ACII) Japanese as per below:
pty
architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x00c086b8
Program Header:
LOAD off 0x00000000 vaddr 0x00c01000 paddr 0x00c01000 align 2**12
filesz 0x00008828 memsz 0x00008828 flags r-x
LOAD off 0x00000448 vaddr 0x0805f448 paddr 0x0805f448 align 2**12
filesz 0x00000000 memsz 0x00000000 flags rw-
Sections:
Idx Name Size VMA LMA File off Algn
SYMBOL TABLE:
no symbols
And accordingly I strongly doubt the coder know the "true" meaning of these sentence :))
The second slap: Recognizing the packer
First, this is a packed binary, by UPX, this is the easy way to recognize it since so many trick are used for camouflage the this good known packer.
Program Header:the 0x00c01000 will store copy of the packed ELF header, and 0x0805f3a8 is start address of stubs contains the data packed. Some PoC:
LOAD off 0x00000000 vaddr 0x00c01000 paddr 0x00c01000 align 2**12
filesz 0x00008840 memsz 0x00008840 flags r-x
LOAD off 0x000003a8 vaddr 0x0805f3a8 paddr 0x0805f3a8 align 2**12
filesz 0x00000000 memsz 0x00000000 flags rw-
but if you extract it it will show this error:
> x 0xaa@0;x 0xaa@0x00c01000
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000000 7f45 4c46 0101 0103 0000 0000 0000 0000 .ELF............
0x00000010 0200 0300 0100 0000 d086 c000 3400 0000 ............4...
0x00000020 0000 0000 0000 0000 3400 2000 0200 2800 ........4. ...(.
0x00000030 0000 0000 0100 0000 0000 0000 0010 c000 ................
0x00000040 0010 c000 4088 0000 4088 0000 0500 0000 ....@...@.......
0x00000050 0010 0000 0100 0000 a803 0000 a8f3 0508 ................
0x00000060 a8f3 0508 0000 0000 0000 0000 0600 0000 ................
0x00000070 0010 0000 2efa 01da 0a00 0000 7811 0d0c ............x...
0x00000080 0000 0000 139a 0100 139a 0100 9400 0000 ................
0x00000090 5400 0000 0e00 0000 1803 003f 91d0 6b8f T..........?..k.
0x000000a0 492f fa6a e407 9a89 5c84 I/.j....\.
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00c01000 7f45 4c46 0101 0103 0000 0000 0000 0000 .ELF............
0x00c01010 0200 0300 0100 0000 d086 c000 3400 0000 ............4...
0x00c01020 0000 0000 0000 0000 3400 2000 0200 2800 ........4. ...(.
0x00c01030 0000 0000 0100 0000 0000 0000 0010 c000 ................
0x00c01040 0010 c000 4088 0000 4088 0000 0500 0000 ....@...@.......
0x00c01050 0010 0000 0100 0000 a803 0000 a8f3 0508 ................
0x00c01060 a8f3 0508 0000 0000 0000 0000 0600 0000 ................
0x00c01070 0010 0000 2efa 01da 0a00 0000 7811 0d0c ............x...
0x00c01080 0000 0000 139a 0100 139a 0100 9400 0000 ................
0x00c01090 5400 0000 0e00 0000 1803 003f 91d0 6b8f T..........?..k.
0x00c010a0 492f fa6a e407 9a89 5c84 I/.j....\.
>[0x00c086d0]> x @0x0805f3a8
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x0805f3a8 6507 7c7e 31e5 29e8 ad2e 4cd4 b883 c761 e.|~1.)...L....a
0x0805f3b8 709c 6090 b540 bb85 7ede a550 cce0 b146 p.`..@..~..P...F
0x0805f3c8 8211 fa50 5e82 d55e 2227 b678 e121 fa00 ...P^..^"'.x.!..
0x0805f3d8 f595 a5e7 5654 b02b 6c2e 4daa de34 103f ....VT.+l.M..4.?
0x0805f3e8 d119 ab5b 7c26 20e7 dd69 9df4 822b a118 ...[|& ..i...+..
0x0805f3f8 7277 8b6c fd4d ac58 49ea f06d 6611 e239 rw.l.M.XI..mf..9
The reason is simply after the UPX packed the real binary a modification was made so UPX can not find the starting point nor header (see figure below) to do the unpacking,
File size Ratio Format Name
-------------------- ------ ----------- -----------
upx: pty: NotPackedException: not packed by UPX
in other words: this binary can only be unpacked by itself or we somehow put back the original header in place to make it unpackable by UPX again. But don't worry. Many RE ways to be done dealing with this situation. One of (my favorite) way to handle this "custom" packed UPX is using ala CTF method that I announced a while ago in-->here, or using "other" method that I will not openly disclosed (OPSEC).
The third slap: Malware packer cracked!
I depacked the binary with my method and the information needed from the unpacked ELF can be seen in the virus total comment I wrote in-->here.
And the fun has began (picture?↓)
The forth slap: Indicator of the infection
1. Malware installation details
During the installation the malware will perform shell execution via execve("/bin/sh") to the various linux command line to perform the installation, as per detail picture below:
As per seen in the details, linux version of debugger and packet capture software were disabled, the DNS resolver will be set to "8.8.8.8", then the services (mostly are router specific services) will be stopped or removed its runtime files, the firewall rules will be changed for telnet (tcp/23), httpproxy (tcp/8080) and http (tcp/80) services to be opened, malware will be self-executed under owner only rwx permission (chmod 700), user crontab will be used for autostart, and several info harvesting.
Accordingly the below similar runtime libraries must needed for overall execution:
And the below configuration file will be accessed:
/etc/ld.so.cache // the elf runtime
/lib/i386-linux-gnu/i686/cmov/libc.so.6 // the elf runtime
/lib/i386-linux-gnu/libpam.so.0 // some user related calls made
/lib/i386-linux-gnu/libselinux.so.1 // selinux
/lib/i386-linux-gnu/i686/cmov/libdl.so.2
/lib/i386-linux-gnu/i686/cmov/libnss_compat.so.2
/lib/i386-linux-gnu/i686/cmov/libnsl.so.1 // malwre use these libs to resolve
/lib/i386-linux-gnu/i686/cmov/libnss_nis.so.2
/lib/i386-linux-gnu/i686/cmov/libnss_files.so.2
/usr/share/locale/locale.alias // accompany the info harverst
/usr/share/locale/en_US/LC_MESSAGES/libc.mo
/usr/share/locale/en/LC_MESSAGES/libc.mo
usr/share/locale/en_US/LC_MESSAGES/psmisc.mo
/usr/share/locale/en/LC_MESSAGES/psmisc.mo",
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
Also perform information harvesting via execution of:
/etc/rc.conf [READ]
/etc/resolv.conf [MODIFIED!]
/etc/nsswitch.conf [READ]
and drops these files:
/bin/uname
/bin/nvram
/usr/sbin/nvram
/etc/ISP_name
/etc/Model_name
The user contrab will contains:
/tmp/udevd0.pid
/var/lock/.x001804289383
/var/spool/cron/crontabs/$USER [modification of crontab -e]
Upon status of installation the malware will be able to send this message(s):
* * * * * /PATH/MALWAREFILE > /dev/null 2>&1 &
[+] Welcome to x00's cback shell %s
echo [+] you logged in at `date`
echo [+] `uname -a || cat /proc/version`
[+] you got root rights, enjoy!.
[+] Running on %s/bin/crontab./usr/bin/crontab.chmod 700 %s > /dev/null 2>&1 \
&.touch -acmr /bin/ls %s(crontab -l | grep -v "%s" | grep -v "no cron" | \
grep-v "lesshts/run.sh" > %s/.x00%u) > /dev/null 2>&1.echo "* * * * * %s > \
/dev/null 2>&1 &" >> %s/.x00%u.crontab %s/.x00%u.rm -rf %s/.x00%u.
[+] no cronnie.
[+] forget it. .
[+] you are root tho. ./etc/rc.d/rc.local./etc/rc.conf./."%s%s"a.irq.#x86.777
2. The IRC botnet
The malware will connect infected nodes to the hostname xxx.pokemon.inc:8080.
When I reversed this sample it was resolved into below DNS data:
;; QUESTION SECTION:
;xxx.pokemoninc.com. IN A
;; ANSWER SECTION:
xxx.pokemoninc.com. 845 IN CNAME bnet.pokemoninc.com.
bnet.pokemoninc.com. 845 IN A 88.198.71.83
bnet.pokemoninc.com. 845 IN A 83.143.80.227
bnet.pokemoninc.com. 845 IN A 211.103.199.98
bnet.pokemoninc.com. 845 IN A 49.231.211.193
bnet.pokemoninc.com. 845 IN A 61.156.43.106
bnet.pokemoninc.com. 845 IN A 203.141.196.145
bnet.pokemoninc.com. 845 IN A 202.103.224.85
;; AUTHORITY SECTION:
pokemoninc.com. 2644 IN NS dns1.name-services.com.
pokemoninc.com. 2644 IN NS dns2.name-services.com.
pokemoninc.com. 2644 IN NS dns3.name-services.com.
pokemoninc.com. 2644 IN NS dns5.name-services.com.
pokemoninc.com. 2644 IN NS dns4.name-services.com.
Infected node(s) will enter the IRC server after receiving the PONG:
with executing below JOIN command and using ID format like:
......PONG #[Arch] :[RangeIP]|[HOSTNAME] -xi.
.x00 localhost localhost :[DATE, i.e.:feb012016]...
and that YouTube URL is a big LOL in our community :) (picture?↓)
JOIN :#[Arch]
BotID: [Arch]:|x|1|[ID]|[hostname]|[youtubeURL][date]
NICK [BotID] USER x00 localhost localhost :%s
The youtube url is safe: https://www.youtube.com/watch?v=Jzqy6UJXpcQ [link] is a BGM of popular japanese anime "GochiUsa" about girls work in cafe.
After joined the IRC !MALICIOUS! bot commands can be executed. I dump the text list of the commands as below: 
Text mode is in-->here.
3. About the attacks..
All attack commands can be seen in the above mentioned IRC command, and all command details mostly are shared in the source code of IRC botnet ddoser that I shared a while ago. link-->here. But there are two commands that I oftenly seen recently in DDoS, which are SUDP and UNKNOWN, we disassembly and decode it into its original code as following jinxed snippet:
For the UNKNOWN was similar to the code we shared before, so I will not discuss it here.
4. The "User Agent" combination used for L7 attacks
This malware is using combination of many user agents during performing its L7 DoS. The combination is varied, in this particular case the combination is as per snipped in the below picture. Obviously to filter these headers are not recommendable idea to block such attack:
The fifth slap: What is this, really? It's ELF/STD bot.
This is the STD bot, with the heavy modified code of kaiten. People in the "industry" and some stupid skiddos are thinking that STD bot was derived from kaiten/ktx or tsunami, but actually it is not. The original STD bot was stand alone code. STD name itself came from the coder name called "stackd" (root@stackd.net), and he was the one who coded first 48 lines of STD bot.
The code was later on inspired by other IRC base codes like kaiten/tsunami and other modification in the "copypasta" land to be what we are still seeing until now. Well, who cares for this history anyway, but I prefer to keep on track on which threat coming from which roots for my analysis purpose, I suggest you should start to do the same if you are not.
Followingly, in this particular variant, the coder is overhaul the code of latest STD and combining with his own signature for the black market distribution purpose. Also the usage of the UPX trick was added to prevent with the hope to prevent sysadmins, scanners or analysts, to know what this threat really is.
But unfortunately for them...
We STILL have a much better KungFu than yours kiddo :)
The sixth slap: Network threat indicator
IP addresses:
130.211.127.186
88.198.71.83
83.143.80.227
211.103.199.98
49.231.211.193
61.156.43.106
203.141.196.145
202.103.224.85
Port numbers used:
tcp/22 (remote cnc)
tcp/80 (DoS attack)
tcp/8080 (IRC connection CNC)
tcp/23 (telnet scanning)
Domains & hostname: (do not false positive these, it's for search engine to seek for poor victims!!)
pokemoninc.com (domain)
bnet.pokemoninc.com (cname)
xxx.pokemoninc.com (hostname for round robin access)
186.127.211.130.bc.googleusercontent.com (one of payload infection server)
Hashes:
MD5 (pty) = fa856be9e8018c3a7d4d2351398192d8
MD5 (pty.1) = fa856be9e8018c3a7d4d2351398192d8
MD5 (tty0) = 7980ffb3ad788b73397ce84b1aadf99b
MD5 (tty1) = d47a5da273175a5971638995146e8056
MD5 (tty2) = 2c1b9924092130f5c241afcedfb1b198
MD5 (tty3) = f6fc2dc7e6fa584186a3ed8bc96932ca
MD5 (tty4) = b629686b475eeec7c47daa72ec5dffc0
MD5 (tty5) = c97f99cdafcef0ac7b484e79ca7ed503
Epilogue and conclusion
Sample link is in the article above.
Will add and improve this post after rest a while.
Will not expose method used for dissecting the threat outside the MMD rings.
Stay safe, friends. Hope this info helps you.
DM me message for questions in @malwaremustdie (twitter)
Thank's to ben-kow for the report, radare.org for the cool stuff! And all friends in MMD group who really supporting me get through the tough time, nice to be able to write again.
To all friends in Kumamoto prefecture in Japan, prayers for you, this post is dedicated to you.
#MalwareMustDie!
☩Non nobis Domine, non nobis, sed nomine Tuo da Gloriam (Psalm 113:9)
...