MMD-0055-2016 - Linux/PnScan ; ELF worm that still circles around
24 Aug 2016Background
Just checked around internet and found an interesting ELF worm distribution that may help raising awareness for fellow sysadmins. As per shown in title, it's a known ELF malware threat, could be a latest variant of "Linux/PnScan", found in platform x86-32 that it seems run around the web within infected nodes before it came to my our hand. This worm is more aiming embed platform and I am a bit surprised to find i86 binary is hitting some Linux boxes.
This threat came to MalwareMustDie ELF team task before and I posted analysis in Mon Sep 28, 2015 on kernelmode [link] along with its threat details, I thought the threat is becoming inactive now and it looks like I'm wrong, as the malware works still in infection now as worm functions and is hardcoded to aim 183.83.0.0 / 16 segment (located in network area of Telangana and Kashmir region of India), where it was just spotted. Since I never write about this threat in this blog (except in the kernelmode), it will be good to raise awareness to an active working and alive worm by this post.
Threat Indicators
For some reason we can't inform infection source, but the source is in the targeted network mentioned above. It is hard to seek the patient zero of this infection since the worm seems took a while to circle around the targeted network.
The file is having below indicator:
Filename: 'stdin'(.pnscan.x86-32.mmd)
Type: 'ELF 32-bit LSB executable, Intel 80386' (GNU/Linux) statically linked, stripped
Packer: 'UPX (header bit tweak) packed,'
Spotted: 'Tue Aug 23 12:27:21 UTC 2016'
md5: '6fb6f95546d5bdf4db11655249ee5288'
sha1: '2d3e2ce680de6c13ab3236429efd4bca3bfaa79d'
According to VirusTotal it's firstly spotted months ago:
'First submission 2016-01-27 05:26:45 UTC'
Static check will find the packed and tweaked UPX was used.
ELF Header: '↓typical packed one'Program Headers: ↓It's a typical UPX header as per explained in different post I made here-->[link]
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 - GNU
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
'Entry point address: 0xcfce38'
'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)'
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 '0x00c01000' 0x00c01000 0xfc661 0xfc661 R E 0x1000
LOAD 0x000d68 '0x08290d68' 0x08290d68 0x00000 0x00000 RW 0x1000
UPX packer traces in the original binary of this worm: 
This worm is using customized UPX form of header to avoid RE / decoding↓
0x00000000 7f45 4c46 0101 0103 0000 0000 0000 0000 .ELF............Figure: Modified header
0x00000010 0200 0300 0100 0000 38ce cf00 3400 0000 ........8...4...
0x00000020 0000 0000 0000 0000 3400 2000 0200 2800 ........4. ...(.
0x00000030 0000 0000 0100 0000 0000 0000 0010 c000 ................
0x00000040 0010 c000 61c6 0f00 61c6 0f00 0500 0000 ....a...a.......
0x00000050 0010 0000 0100 0000'680d 0000 680d 2908' ........h...h.).
0x00000060 680d 2908 0000 0000 0000 0000 0600 0000 h.).............
0x00000070 0010 0000 22c0 e4b8 5550 5821 3408 0d0c ...."...UPX!4...
0x00000080 0000 0000 783f 2400 783f 2400 9400 0000 ....x?$.x?$.....
0x00000090 5d00 0000 0800 0000 771f a4f9 7f45 4c46 ].......w....ELF
0x000000a0 0100 0200 0300 1b68 8104 fbaf bddf 0834 .......h.......4
0x000000b0 0ef8 3c24 2f16 2032 2800 1000 0f00 5b5c ..<$/. 2(.....[\
0x000000c0 e59d 1d80 4607 c807 2200 0527 db76 7fcf ....F..."..'.v..
There are some ways can be used to put back this ELF to its origin form, I will add howto info in here (public) after this case's handle is done.
We have several method to crack some specific made UPX base custom packed ELF, one of them that I used to dissect the ELF of the "xxx.pokemon(.)inc" a one IRC DDoS botnet ELF malware I posted in here-->[link]. The other ways to debunk these packed ELF are by different methods of cracking, which are just being shared publicly via radare.org [link] community as per below:
One of the method(s) described in tutorials above is sufficient enough to crack this ELF successfully.
A protip to sysadmins and RCE beginners (good folks only!) in dealing with difficult ELF packer: Just remember, if you stuck on something, it is only a sign for you to start to improve yourself, just keep on trying. Remember: crooks never be smarter than you, have this faith, and in time you'll figure the problem.
Video IR Guideline details of functionality of Linux/PnScan worm
Below is the detail of the forced unpacked binary of the Linux/PnScan worm version, This video was actually I made as guide to CERT and IR folks to mitigate the threat. I am using my beloved shell RE tool "radare" for this. There are heavy editing, some cuts, and parts skipped w/also some unexplanatory parts for the sake of on going case security reason. But all indicators are viewable in this video, worth to watch if you are in ISP's IR or CERT field. There are some details are not included in the video too by other security reason.
Note on video watching: Youtube may sometimes have a weird problem with initial loading video I uploaded recently, if it can not load suddenly in the middle of playing (read: stopped/stuck), if you experienced this "phenomenon" just change the resolution to bigger or smaller arte, and the video will be reloaded and run well... beats me how this problem can happen... but please don't blame the video itself. Thank you.
A bit about radare.org's r2
For the static analysis of ELF malware to specially the sysadmins (and reversing enthusiasts), I'd say radare2 (r2) is the best tool I've ever use, following by gdb, objdump and its binutils or ELF utils etc for the purpose. I've been using it for long [link] and it never fails me for works I do in UNIX shell. MalwareMustDie team members are officially using it daily for ELF analysis.
Shortly, r2 is not only a tool made by hackers to nail hackers & its bad coded bins by RCE, but it helps your IR work on static analysis for bad bins in any major NIX native architecture shell environment inside of infected systems. Not only as a static analysis tool, but r2 as forensics tool allows you to extract important IR information instantly and on the fly with its rich command features... it is flexible and fast! The analysis I made and I posted in this blog (and others) are mainly using r2.
You can follow radare2 good folks works in here [here] and here [link].
Let's continue with the analysis..
This ELF is having below dependencies..
libc-2.13.so..and was compiled on compatibility of GCC(GNU) 4.1.x via the compiler tool Toolchains [link] with cross compiler option for i686 using the SSL enabled configuration. It seems the coder is using working desktop with the crypted disk "/media/truecrypt1" with workpath "/my/framework/" for compiling this :) ouch!
ld-2.13.so
No screenshot, no PoC..here we go:
A summary of how it works
To fellow reversers, there's no specific new function spotted in these sample ELF worms I investigated, except the practical usage is different, that the x86-32 platform are specifically aimed (and this is bad) and a part of India network is now as the target. It is weird a bit on why toolchains is used for i686 compilation, but that also shows x86-32 is not the only targeted aim for this infection too. It is supported the historical data of the infection spotted from September 2015 the versions of mips, mipsel and arm were mostly the main spotted ones. To make it simple in words: This worm is not only targeting Linux with embedded for IoT device and routers, but for servers and appliances too now with, still, aiming its default password login.
Below is a summary on how it works:
1. It forked 4 times (with its main process = 5)
2. Created files with the below functionality in the work (executed) directory:
permission size date filename function
----------------------------------------------------------------
-rw-r--r-- 387 Aug 23 12:06 list2 <-- connected hosts
-rw-r--r-- 4 Aug 23 12:02 MalwareFile.pid <-- pids
-rw-r--r-- 0 Aug 23 12:02 daemon.log <-- malware log
-rw-r--r-- 35 Aug 23 12:02 login2 <-- brute auth
drwxr-xr-x 4096 Aug 23 12:02 files/ <-- updates/downloads/C2 data
3. Daemonizing and listening to these 2 TCP ports:
IPv4 TCP/＊:9000 (for /check command and /upload command's remote access)
IPv4 TCP/＊:1337 (remote uptime or ping quick check)
4. Attacking initially to target IPs in: 183.83.0.0 / 16 (hard coded)
Country: 'India (Telangana, Kashmit region network in India)'
For 'SSH services' in port: 'TCP/22' (ssh)
5. Having function to brute force login with the below auth:
root:root
admin:admin
ubnt:ubnt
6. SSL traffic sent via HTTP/1.1 requests to twitter.com, reddit.com, google.com, microsoft.com etc listed URL on the SSL port TCP/443↓
write(113, "\26\3\1\2\0\1\0\1\374\3\3%\254\231\25\346\263EuU\vI\26\10bc\0I_\246\262g\273\267To be clear in ↓PCAP :) ping EmergingThreat Lab friends!
\342C\24\33l\327\214R\215\0\0\240\3000\300,\300(\300$\300\24\300\n\0\245\0\243\0\241\0\237\0
k\0j\0i\0h\0009\0008\0007\0006\0\210\0\207\0\206\0\205\3002\300.\300*\300&\300\17\300\5\0\23
5\0=\0005\0\204\300/\300+\300'\300#\300\23\300\t\0\244\0\242\0\240\0\236\0g\0@\0?\0>\0003\00
02\0001\0000\0\232\0\231\0\230\0\227\0E\0D\0C\0B\3001\300-\300)\300%\300\16\300\4\0\234\0<\0
/\0\226\0A\0\7\300\22\300\10\0\26\0\23\0\20\0\r\300\r\300\3\0\n\0\377\1\0\0013\0\0\0\20\0\16
\0\0'\vtwitter.com'\0\v\0\4\3\0\1\2\0\n\0\34\0\32\0\27\0\31\0\34\0\33\0\30\0\32\0\26\0\16\0\r
\v\0\f\0\t\0\n\0\r\0 \0\36\6\1\6\2\6\3\5\1\5\2\5\3\4\1\4\2\4\3\3\1\3\2\3\3\2\1\2\2\2\3\0\17
\0\1\0013t\0\0\0\20\0\v\0\t'\10http/1.1'\0\25\0\267\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
:
0\0\0\0\0\0\0", 517)
(Note: well, actually this function is also known too way back before.. )
7. Plain and SSL encrypted CNC traffic
The CNC calls will be performed upon successful function to seek its CNC related info via the requests sent in list of SNS (+other sites too) via SSL.
The Twitter (and other SNS/sites i.e.: reddit.com, microsoft.com, google.com, my.mail.ru) requests are utilized by this worm to do one important step to perform callback the CNC, by generation files in /files/ contains the CNC IP and its ports (See the ELF video.posted above). I waited long enough to be sure that no CNC is reached, but none available at this moment, assuming the worm is moving around in circle in the targeted network and accidentally hit my trap planted in the area. The worm is responding to the known bot protocol in the port TCP/9000 if you want to try some test for communicating with this worm. Port TCP/1337 is another indicator for the success infection. Both TCP/9000 and TCP/1337 are open, and has connectable (ESTBLISHED) TCP state.
The worm, in this particular sample, when it can't reach the CNC, will keep on requesting to the next SSL media that was contacted. In this case, it will keep on contacting the twitter.com, reddit.com, google.com and etc SNS URL hardcoded in the binary (see the below embedded video for the list) with permutating wordlist posted to the request after the SSL is established. This action to then triggering initial CNC list generation and making effort to seek for the motherhost connection (which it seems unreachable or down now).
Some of the requests during the initial infection stage can be seen in the PCAP snapshot that I had collected as per below:
Initiating connection:
Client request the hello:
Server is replied with key and response:
No CNC connection found yet, it was re-trying to next.. reddit.com now:
Again, these requests will keep on going while the worm is keep on continuing scanning and listing up the successfully scanned hosts and successfully brute-targeted SSH attack list. The activity will keep on going on until the worm can connect to the CNC and the hacker can reach back to the infected host and remotely send more instruction for other attacks via port TCP/9000 (noted the inbound and outbound traffic from and to this port).
This is why the coder was using SSL configuration during the compilation, they need to use SSL certification of twitter. reddit, microsoft, google etc for the generation of data to be used for further effort in making CNC connection.
[EDIT]
I thought there might be a way for the IDS signature for blocking this twitter connection for this worm can be used for the pinpoint to mitigate the growing infection on the targeted network. For that purpose, upon consulted to the team of experts in ETLabs [link], the result is negative. Following is the explanation: Unfortunately there isn't anything we can do there, there's SSL traffic to Twitter which on a network sensor will be encrypted. It's impossible to differentiate between infection traffic and legitimate Twitter traffic from our standpoint. Also, nothing appears abnormal in the SSH scanning..
[/EDIT]
[EDIT 2]
Discussing further with the ETLabs engineer friends, collaborating to mitigate this threat and the good result came up. We found way to mitigate the infection by the ETLab's traffic filtration signature. The details for this filtration you can see in the mitigation section. Thank you for the nice discussion and great work!
[/EDIT]
Infection Symtoms
Infected node will have traces of these process running made during the initial infection:
stdin 2712 root cwd DIR 8,1 4096 131126 /test/
stdin 2712 root rtd DIR 8,1 4096 2 /
stdin 2712 root txt REG 8,1 1034309 131146 /test/stdin
stdin 2712 root 0u REG 8,1 0 131171 /test/daemon.log
stdin 2712 root 1u REG 8,1 0 131171 /test/daemon.log
stdin 2712 root 2u CHR 136,0 0t0 3 /dev/pts/0
stdin 2712 root 3r FIFO 0,8 0t0 6188 pipe
stdin 2712 root 4w FIFO 0,8 0t0 6188 pipe
stdin 2712 root 5u 0000 0,9 0 1185 anon_inode
stdin 2712 root 6u unix 0xcda07300 0t0 6191 socket
stdin 2712 root 7u unix 0xce020d40 0t0 6192 socket
stdin 2712 root 8u IPv4 6193 0t0 TCP *:9000 (LISTEN)
stdin 2712 root 9u 0000 0,9 0 1185 anon_inode
stdin 2712 root 10u unix 0xce020ac0 0t0 6194 socket
stdin 2712 root 11u unix 0xce020840 0t0 6195 socket
stdin 2712 root 12u IPv4 6196 0t0 TCP *:1337 (LISTEN)
And the launched attack can be seen in the network connectivity like per shown in the list of files and connection:
stdin 2712 root 13u IPv4 6197 0t0 TCP x.x.x.x:40709->183.83.0.0:22 (SYN_SENT)To be more precise of the aimed network for this attack specifically, below is the PoC video of the recorded PCAP, the data is too big so the video is only covering about 3% of the recorded scanning and SSH login/bruting access:
stdin 2712 root 14u IPv4 6198 0t0 TCP x.x.x.x:37944->183.83.0.1:22 (SYN_SENT)
stdin 2712 root 15u IPv4 6199 0t0 TCP x.x.x.x:35576->183.83.0.2:22 (SYN_SENT)
stdin 2712 root 16u IPv4 6200 0t0 TCP x.x.x.x:41811->183.83.0.3:22 (SYN_SENT)
stdin 2712 root 17u IPv4 6201 0t0 TCP x.x.x.x:43278->183.83.0.4:22 (SYN_SENT)
stdin 2712 root 18u IPv4 6202 0t0 TCP x.x.x.x:37969->183.83.0.5:22 (SYN_SENT)
stdin 2712 root 19u IPv4 6203 0t0 TCP x.x.x.x:39383->183.83.0.6:22 (SYN_SENT)
stdin 2712 root 20u IPv4 6204 0t0 TCP x.x.x.x:38038->183.83.0.7:22 (SYN_SENT)
stdin 2712 root 21u IPv4 6205 0t0 TCP x.x.x.x:35040->183.83.0.8:22 (SYN_SENT)
stdin 2712 root 22u IPv4 6206 0t0 TCP x.x.x.x:59569->183.83.0.9:22 (SYN_SENT)
stdin 2712 root 23u IPv4 6207 0t0 TCP x.x.x.x:50921->183.83.0.10:22 (SYN_SENT)
stdin 2712 root 24u IPv4 6208 0t0 TCP x.x.x.x:36079->183.83.0.11:22 (SYN_SENT)
stdin 2712 root 25u IPv4 6209 0t0 TCP x.x.x.x:35134->183.83.0.12:22 (SYN_SENT)
stdin 2712 root 26u IPv4 6210 0t0 TCP x.x.x.x:59932->183.83.0.13:22 (SYN_SENT)
stdin 2712 root 27u IPv4 6211 0t0 TCP x.x.x.x:35682->183.83.0.14:22 (SYN_SENT)
stdin 2712 root 28u IPv4 6212 0t0 TCP x.x.x.x:57709->183.83.0.15:22 (SYN_SENT)
: :
You can imagine how hectic these traffic will be in targeted network if there are some tens or maybe hundreds infected boxes.. The actor can create a massive chain of infection if they are aiming the right network with having the right vulnerable default SSH login.
Each connected target is logged in the "list2" file:
0000 31 38 33 2e 38 33 2e 30 2e 33 33 3b 32 32 3b 0a |183.83.0.33;22;.|
0010 31 38 33 2e 38 33 2e 30 2e 38 30 3b 32 32 3b 0a |183.83.0.80;22;.|
0020 31 38 33 2e 38 33 2e 32 2e 32 36 3b 32 32 3b 0a |183.83.2.26;22;.|
0030 31 38 33 2e 38 33 2e 32 2e 34 31 3b 32 32 3b 0a |183.83.2.41;22;.|
0040 31 38 33 2e 38 33 2e 32 2e 31 31 30 3b 32 32 3b |183.83.2.110;22;|
0050 0a 31 38 33 2e 38 33 2e 32 2e 32 31 30 3b 32 32 |.183.83.2.210;22|
0060 3b 0a 31 38 33 2e 38 33 2e 33 2e 32 32 3b 32 32 |;.183.83.3.22;22|
0070 3b 0a 31 38 33 2e 38 33 2e 33 2e 31 34 38 3b 32 |;.183.83.3.148;2|
0080 32 3b 0a 31 38 33 2e 38 33 2e 34 2e 39 33 3b 32 |2;.183.83.4.93;2|
0090 32 3b 0a 31 38 33 2e 38 33 2e 34 2e 31 35 36 3b |2;.183.83.4.156;|
00a0 32 32 3b 0a 31 38 33 2e 38 33 2e 35 2e 31 36 3b |22;.183.83.5.16;|
00b0 32 32 3b 0a 31 38 33 2e 38 33 2e 35 2e 32 30 36 |22;.183.83.5.206|
00c0 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 36 2e 31 32 |;22;.183.83.6.12|
00d0 37 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 37 2e 34 |7;22;.183.83.7.4|
00e0 33 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 37 2e 31 |3;22;.183.83.7.1|
00f0 32 33 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 37 2e |23;22;.183.83.7.|
0100 31 38 37 3b 32 32 3b 0a 31 38 33 2e 38 33 2e 31 |187;22;.183.83.1|
0110 31 2e 35 31 3b 32 32 3b 0a 31 38 33 2e 38 33 2e |1.51;22;.183.83.|
0120 31 31 2e 38 34 3b 32 32 3b 0a 31 38 33 2e 38 33 |11.84;22;.183.83|
0130 2e 31 31 2e 31 36 38 3b 32 32 3b 0a 31 38 33 2e |.11.168;22;.183.|
0140 38 33 2e 31 32 2e 31 34 35 3b 32 32 3b 0a 31 38 |83.12.145;22;.18|
0150 33 2e 38 33 2e 31 32 2e 32 34 30 3b 32 32 3b 0a |3.83.12.240;22;.|
0160 31 38 33 2e 38 33 2e 31 33 2e 31 36 32 3b 32 32 |183.83.13.162;22|
0170 3b 0a 31 38 33 2e 38 33 2e 31 34 2e 39 32 3b 32 |;.183.83.14.92;2|
0180 32 3b 0a |2;.|
And you may find the brute list trace in file "login2"
0000 72 6f 6f 74 3b 72 6f 6f 74 3b 0a 61 64 6d 69 6e |root;root;.admin|
0010 3b 61 64 6d 69 6e 3b 0a 75 62 6e 74 3b 75 62 6e |;admin;.ubnt;ubn|
0020 74 3b 0a |t;.|
0023
Noted: the PID of main process is saved in [MalwareFile].pid
0000 32 37 31 32 |2712|
0004
The origin of the threat
Regarding the source of this threat. I have discussion with my good colleague, I would like to not mention his/her identification for his/her security protection.
1. The compilation traces
The traces that lead to the cross compiling tool used, which was showing the Truecrypt was used. This method of running Truecrypt in the work directory is still seen a lot in several activities of cyber crooks on East Europe region (while in the western part or my part of area, mostly we already abandoned this technology for its insecurity). Which is suggesting the origin of this threat.
The data of the compilation traces:
0x8238ff8 102 101 OPENSSLDIR: "/media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl"
0x8248eac 96 95 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/lib/engines
0x825e294 96 95 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl/private
0x825e2f4 88 87 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl
0x825e34c 94 93 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl/certs
0x825e3ac 97 96 /media/truecrypt1/my/framework/../toolchains/cross-compiler-i686/i686-unknown-linux/ssl/cert.pem
2. The MY.MAIL.RU's API used
In the SNS service url list where the worm is using to start effort to reach its CNC, it was found the specific API of mail.ru, a russian big public email service. We think, only russian speaking bad actors (I don't say "nationality" here, but this shows high possibility that the actor may residing in there), who know how use specific subdomain of my.mail.ru with its API as per shown below:
0x8220f7a 11 10 my.mail.ruFor these 1. and 2. forensics result we herewith inform to the legal and law enforcement to make a proper action and record accordingly.
0x8220f85 20 19 https://%s/mail/%s/
Mitigation and detection method against PnScan worm infection
Some ways to fight this worm:
Signature to block the traffic of Linux/PnScan
Thank you ETLab for kindly help all of us by releasing the Snort and Suricata open rules to mitigate this threat.
The rules are complex and designed to detect any symtoms required networking activity generated from this worm, with the function that can be seen below:
2023087 - ET TROJAN PNScan.2 Inbound Status Check - set (trojan.rules)To be noted: It is maybe a bit confusing you but DO NOT mix this worm with the trojan of Linux/PnScan.1 or version one, which is working in different activity (port scanner and DDOS) and not having a worm function, Additionally naming of these threat was taken from the first entity who released its announce.
2023088 - ET TROJAN PNScan.2 Inbound Status Check Response (trojan.rules)
2023089 - ET TROJAN PNScan.2 CnC Beacon (trojan.rules)
2023090 - ET TROJAN PNScan.2 CnC Beacon 2 (trojan.rules)
Conclusion, Samples & Reference
This worm is re-infecting i86 Linux machines in the target mentioned above and all of the data posted above are important hazards to block its infection and distribution. The worm is hitting a box, scan for more and each box is hitting some more boxes too, the growth is exponentially increased if it is spread in vulnerable network. For this particular case we wrote here, I guess this happened between from 6 months ago until now, and the hacker could be sitting there in Russia network waiting for the right chance to access any accessible infected nodes. If you take a look closer to the explained auth data then you may guess which distribution of boxes that are actually aimed.
Related links and last notes
You'll see deeper detail in previous writing & thread here -->[link]
Sample is in VirusTotal [link]
Dr. Web wrote details of the threat, they correctly see what we see, good work! [link]
PS: The warning of this threat was sent to regional CERT.
Thank you very much for the internet media awareness
We, MMD thank our good friends in internet media for your fast awareness of this threat:
1. Security Affairs [link]
2. Softpedia [link]
3. Security Week [link]
4. Anti Malware .ru [link]
5. Sensor Tech Forum [link]
6. IPS Info .ru [link]
7. Romania Net [link]
8. Virus Info forum [link]
9. News Asis .IO (In Arabic) [link]
A nice alert (thanks!) and guide line to prevent the threat by EScan, PocketAlert and ItVarNews in India [link] [link] [link]
#MalwareMustDie!
Reversed, analyzed and written by @unixfreaxjp [link], August 23-24, 2016.