Latest UPDATE incident of this threat is-->[link]
Background
I received the report of the host in Google cloud network is serving ELF malware:
{
"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"
}
So I downloaded them all in secure way like as per follows:
*) p.s.: I never use same request pattern during my encounter to any malware servers
ELF botnet infecting routers is a bad thing, but abusing Google cloud is another bad thing. Not to mention the utilization of much innocent hacked servers as CNC & the many mis-use of the anime features for badness.
After receiving several reports on incidents and requests on the topic I decided to write this post as awareness and indicator reference, along with some SLAPS! to the malware coder and actors behind this threat, which are 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,
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.I marked places where one should pay attention with, to see the headers in much better mode can be done in objdump:
pty: file format elf32-i386
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
With 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: ASCII) Japanese as per below:
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. See again the Program Header part;
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-
the 0x00c01000 will store copy of the packed ELF header, and 0x0805f3a8 is start address of stubs contains the data packed. Some PoC:
> x 0xaa@"0x000";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..9but if you extract it it will show this error:
File size Ratio Format Name
-------------------- ------ ----------- -----------
'upx: pty: NotPackedException: not packed by UPX'
The reason is simply after the UPX packed the real binary a modification was made so UPX can not find the starting upx point nor header (see figure below) to start doing the unpacking, 
(↑pic: normal UPX seeks for packer indicator)
(↑pic: PoC of the malware failed to seek unpacking indicator)
In the 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 disclose (OPSEC), as I used in this case to safe my time.
The third slap: Malware & its packer's cracked!
I depacked the binary with my own 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, below similar runtime libraries (ref:debian GNU), must be needed for overall execution:
/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.cacheAnd the below configuration file will be accessed:
/etc/rc.conf [READ] /etc/resolv.conf [MODIFIED!] /etc/nsswitch.conf [READ]Also perform information harvesting via execution of:
/bin/uname /bin/nvram /usr/sbin/nvram /etc/ISP_name /etc/Model_nameand drops these files:
/tmp/udevd0.pid /var/lock/.x001804289383 /var/spool/cron/crontabs/$USER [modification of crontab -e]The user contrab will contains:
* * * * * /PATH/MALWAREFILE > /dev/null 2>&1 &Upon status of installation the malware will be able to send this message(s):
echo [+] Welcome to x00's cback shell %s
echo [+] you logged in at `date`
echo [+] `uname -a || cat /proc/version`
echo [+] you got root rights, enjoy!.
echo [+] 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.
echo [+] no cronnie.
echo [+] forget it. .
echo [+] 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:
......PONG #[Arch] :[RangeIP]|[HOSTNAME] -xi. .x00 localhost localhost :[DATE, i.e.:feb012016]...with executing below JOIN command and using ID format like:
JOIN :#[Arch] BotID: [Arch]:|x|1|[ID]|[hostname]|[youtubeURL][date] NICK [BotID] USER x00 localhost localhost :%s <--- $DATE..and that YouTube URL in botnet protocol is a big LOL in our community :) (picture?↓)
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 often seen recently in DDoS, but I haven't discuss in my previous posts for this type of threat. which are "SUDP" and "UNKNOWN", we disassembly and decode it into its original code as following jinxed snippet:
"UNKNOWN" was in the source code we shared before, a self-explanatory, so I will not discuss it here.
4. The big variation of "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:
It's not over..The fifth slap: What's this, really? It's ELF/STD bot.
This malware is about the STD bot, with the modified code taken from kaiten/Tsunami bot. But the basic codes are STD botnet. Most 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 botnet codes like kaiten/tsunami and other modification in the "copypasta-land", to be what we are still seeing until now.
Below is a demonstration of the STDBot botnet's "CNC console" video snagged from the other bad actor (big thank's to Tw1ce) who uses STDbot, to scan new vulnerable boxes (weak/known factory set credentials) to infect them to his botnet (he pools it in the channel called #rekt). You can see in the console several message IRC used as protocol command response for the STD botnet, which those messages are different to its sister: Kaiten/Tsunami botnet. This botnet is also known for stability and endurance, many people like to use STDbot for its purpose along with fast scanning function.
OK..Well, who cares for this history anyway, but I prefer to keep on track on which threat coming from which root of its malware for my analysis purpose, I suggest you should start to do the same if you are not.
Following, in this particular variant, the coder has overhauled the source code of the latest STD IRC Bot and combining with his own signature for the black market distribution purpose. Also the usage of the UPX trick was added with the hope to prevent sysadmins, scanners or analysts to know what this threat really is during static analysis. yet from now they're failing again :)
Because 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
GeoIP information (for cleaning up purpose):
IP Address, City, Region, Country Name 130.211.127.186, Mountain View, CA, United States 88.198.71.83, , , Germany 83.143.80.227, , , Norway 211.103.199.98, Beijing, 22, China 49.231.211.193, , , Thailand 61.156.43.106, Jinan, 25, China 203.141.196.145, , , Japan 202.103.224.85, Nanning, 16, China IP address | Reversed | ASN|Prefix|ASN|CN|ISP 130.211.127.186 | 186.127.211.130.bc.googleusercontent.com. |15169 | 130.211.0.0/16 | GOOGLE | US | google.com | Google Inc. 88.198.71.83 | static.88-198-71-83.clients.your-server.de. |24940 | 88.198.0.0/16 | HETZNER | DE | hetzner.de | Hetzner Online AG 83.143.80.227 | kdb.servetheworld.net. |34989 | 83.143.80.0/21 | SERVETHEWORLD | NO | servetheworld.net | ServeTheWorld AS 211.103.199.98 | |4808 | 211.103.192.0/18 | CHINA169 | CN | gintong.com | Beijing Huaxia Unipower Network Co. Ltd 49.231.211.193 | |45458 | 49.231.211.0/24 | SBN-AWN-AS-02 | TH | sbn.co.th | 408/60 PHP Bld. 15th Fl Phaholyothin Rd Samsen Nai Phayathai 61.156.43.106 | |4837 | 61.156.0.0/16 | CHINA169 | CN | chinaunicom.com | China Unicom Shandong Province Network 203.141.196.145 | html.city.shiojiri.lg.jp. / html.city.shiojiri.nagano.jp. |17518 | 203.141.192.0/19 | SHIOJIRI | JP | city.shiojiri.nagano.jp | Shiojiri City 202.103.224.85 | |4134 | 202.103.192.0/18 | CHINANET | CN | chinatelecom.com.cn | ChinaNet Guangxi Province NetworkCNC infratructure map:
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 (tty0) = 7980ffb3ad788b73397ce84b1aadf99b MD5 (tty1) = d47a5da273175a5971638995146e8056 MD5 (tty2) = 2c1b9924092130f5c241afcedfb1b198 MD5 (tty3) = f6fc2dc7e6fa584186a3ed8bc96932ca MD5 (tty4) = b629686b475eeec7c47daa72ec5dffc0 MD5 (tty5) = c97f99cdafcef0ac7b484e79ca7ed503
The last (7th) slap: Protection from infection & mitigation
Several router models and Wifi/WiMax service was reported infected by this malware. For the infection prevention "HowTo" please follow these steps:
1. Change the default credential of admin and roots. Change the passwords. 2. Disable the telnet service or secure them with firewall by default. 3. Secure any ssh access by disable root, use latest protocol/version, limit access and if possible switch the ports. 4. Deploy firewall rules to avoid port scanning by default. 5. Monitor infection by checking in/outbound traffic to xxx.pokemon.inc:8080/80/23 6. Push updates to make above points happensFor the infected services, add the below steps:
1. Report the incident to your CERT/CSIRT, is a must. 2. Contact the owner of the device by email/phone/letter to reset the device. 3. Test & apply takeover scheme to get the devices back via botnet protocol. 4. Contact me in DM in @malwaremustdie for advisory, it is FREE *) PS: Do not offer me or my team money/donation, send us malware sample instead.
Epilogue and conclusion
Sample link is in the article above.
IOC details was uploaded to OTX (you know where).
Samples are shared (see hashes), uploaded to kernelmode-->here.
Q and A can be done in reddit in-->here, or DM me in-->twitter for infection handling advisory.
Will add and improve this post after resting for a while.
Will not expose method used for dissecting that "custom" UPX outside the MMD rings.
For the "unbeliever" (smile), here's snips to screenshot to show how this malware is actually "a lame copypasta IRC bot" which also my screenshot PoC to this analysis reported above during reversing session in my environment:
"You won't get anything from this post. skiddos, go to school, study hard, like any of decent people do. There is no such shortcut for knowledge."
*) Note: this section is to be deleted, participate in my ELF workshop and I will share a lot of goodies to you, and please support MalwareMustDie and radare2 project! :-))
Stay safe, friends. Hope this info helps you.
Thank's to ben-kow for the infection information, 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 and fellow sysadmins who work hard battling, fixing and mitigating this type of threat.
#MalwareMustDie!
Written and analyzed by @unixfreaxjp [link], April 14th-15th.2016
☩Non nobis Domine, non nobis, sed nomine Tuo da Gloriam (Psalm 113:9)