Thursday, December 22, 2016

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 185.35.139.92 and executes it.

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 (8.8.8.8) to resolve
the C2 domain (zugzwang.me).

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 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,

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 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 malware-traffic-analysis.net (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.

Monday, August 29, 2016

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.

Friday, July 29, 2016

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

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!.

Thursday, June 23, 2016

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.

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.