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

Machine Translators May Leak Confidential Information

One challenge for enterprises dealing with confidential information in conjunction with cloud-based systems is that they must exercise due diligence to ensure that it remains confidential. The steps are beyond the scope of a technical blog, but generally it involves making sure that everyone processing the confidential information understands that it is sensitive and has agreed to protect it.
For cloud services like Enterprise Resource Planning (ERP), Human Resources, Video Conferencing and so on, the confidentiality issues are very well understood, but there are exceptions like machine translation. When we think of data leaks, we rightly look primarily to malicious software (worms, viruses, customized zero-days from Advanced Persistent Threats (APT’s), etc.) when seeking to prevent confidential data from leaving a network.
 
Machine translation tools are an interesting member of the “other” category of legitimate tools that can result in confidential data leaks without malicious intent from user or developer. Machine translation tools range from simple web sites like “youdao” pictured above or Google Translate, where it is pretty clear that information is leaving, up to integrated desktop applications, where the movement of data is not nearly as obvious.
 
The Youdao Dictionary application is installed like any other and operates like any other, except that the translation engine is remote and the application sends it’s lookups in plain text via insecure HTTP GET’s. The fact that the translation tool is an application running on a user’s PC, makes it less likely that the person making use of it would realize that they are leaking information because the appearance is that their computer is doing the translation, not a web site.
In the above dissection of a URL retrieved by the tool, we see the word “information” being queried in the “q” field, but it could just as well be that someone isn’t entirely sure what “Лечение герпеса Боба Джонса не будет хорошо” means, and would highlight it and click translate. That act results in the application enerating something similar to the plaintext query above, except with that chunk of Russian. The user will then learn that the string translates to “Bob Jones’ herpes treatment is not going well.” Unfortunately, the request and the translation are transferred in plaintext form, which can be learned by passive interception.
The application that we use as an example is from Youdao (有道), a major Chinese Internet company that, according to Wikipedia (http://en.wikipedia.org/wiki/Youdao), ships an offline and free online version of their translation tool. Through some limited experimentation, Youdao’s site does seem to support the same functionality over the more secure, encrypted HTTPS protocol. We have observed insecure communication in the wild for versions ranging from 2.2.16 to 5.4.43, but it would be unfair to discuss the tool without looking at the latest version. The latest version of the Youdao tool we could find, version 6.3.66.1117, was downloaded from http://codown.youdao.com/cidian/static/6.3/20141203/YoudaoDict.exe and tested on a Windows 7 machine and there was no significant difference in behavior.
Our test version also makes use of plaintext (HTTP) communication by default and appears to automatically translate whatever word is near the mouse pointer, whenever it stops moving, between Chinese and English. It also has an option where a small button appears that you can click (or hover over) to translate a highlighted piece of text. Having used the program, it is easy to imagine why this tool is popular with users who need to translate between Chinese and English. In addition to the translation features, it also keeps users from being bored by providing extra advertisements.
What the tool provides in features, it definitely does not provide in security – while it works as intended and does not appear to be up to anything overtly nefarious, it still sends all the translation requests via the insecure HTTP protocol to a back-end server where the translation takes place.
Conclusion
The conclusion for customers is simple: translation software might send data to networks / systems outside your realm of control – if it does, then exactly as would be the case for a cloud-based ERP or Human Resources system, it is important to know where it goes, how it gets there, and that the third parties processing the information do so in a manner that is compatible with your organization’s policies and contractual obligations. Given that the messages to be translated are sent in clear text, anyone on the same network could easily intercept the communication by sniffing network traffic. Translated content could range from benign phrases to highly sensitive information.
Questions to which we do not yet have answers, like whether the translation can be “paused,” if HTTPS can be enabled through configuration, if Youdao’s privacy policy prevents disclosure, if any HTTPS functionality is implemented securely, etc. should be answered before deploying YoudaoDict or similar cloud-based translation tools in a confidential setting. Naturally, we would recommend to Youdao that they at least make use of HTTPS by default in future releases of their software, due to the risk of inadvertently disclosing their users’ confidential information.
Details
The following experiment was performed to verify whether traffic is still passed in plaintext HTTP GET requests, as it was in previous versions. The setup is a fake letter being written in notepad by an associate at the law firm of Nerd, Geek, and Spaz, LLP, who are defending a client who is being sued for some reason…
 
When the two lines were highlighted, a little blue book popped up and hovering over the book results in a translation being executed. That translation is actually performed on a remote server and the following URL is visited by the software:
 
http://dict.youdao.com/fsearch?keyfrom=deskdict.screentrans.http.0.stroke&q=Bill%20Jones%20is%20getting%20sued%20for%20some%20really%20embarassing%0D%0Aporn%20that%20was%20found%20on%20his%20work%20computer.%20%20Please%20advise&pos=-1&doctype=xml&xmlVersion=3.2&dogVersion=1.0&client=deskdict&id=8bba3b7bdf465c61b&vendor=unknown&in=YoudaoDict&appVer=6.3.66.1117&appZengqiang=0&abTest=&le=eng&fytype=AUTO&scrfrom=stroke&proc=notepad.exe
For convenience, we look at the same URL after decoding it and converting to pretty-printed JSON:
 
{
“username": null, "netloc": "dict.youdao.com", "vars": {
"appZengqiang": "0", "vendor": "unknown", "fytype": "AUTO", "keyfrom": "deskdict.screentrans.http.0.stroke", "dogVersion": "1.0", "pos": "-1", "doctype": "xml", "q": "Bill%20Jones%20is%20getting%20sued%20for%20some%20really%20embarassing%0D%0Aporn%20that%20was%20found%20on%20his%20work%20computer.%20%20Please%20advise", "le": "eng", "appVer": "6.3.66.1117", "client": "deskdict", "in": "YoudaoDict", "xmlVersion": "3.2", "proc": "notepad.exe", "id": "8bba3b7bdf465c61b", "scrfrom": "stroke"
}, "fragment": "", "scheme": "http", "hostname": "dict.youdao.com", "params": "", "query": "keyfrom=deskdict.screentrans.http.0.stroke&q=Bill%20Jones%20is%20getting%20sued%20for%20some%20really%20embarassing%0D%0Aporn%20that%20was%20found%20on%20his%20work%20computer.%20%20Please%20advise&pos=-1&doctype=xml&xmlVersion=3.2&dogVersion=1.0&client=deskdict&id=8bba3b7bdf465c61b&vendor=unknown&in=YoudaoDict&appVer=6.3.66.1117&appZengqiang=0&abTest=&le=eng&fytype=AUTO&scrfrom=stroke&proc=notepad.exe", "path": "/fsearch", "password": null, "port": null
}
We can see the variables broken apart more easily in the JSON version and the sentence in our screen-shot it clearly visible with “%20” replacing the spaces and “%0A%0D” replacing the end of line. When decoded, the following is the result:
 
Bill Jones is getting sued for some really embarassing
porn that was found on his work computer. Please advise
This is the exact content of the highlighted region of the Notepad application. Clearly, the fact that the firm cannot spell “embarassing” correctly could put some egg on their face, making this a potentially very damaging leak. The tool also passes information about the application where the translated text came from, which is indeed “notepad.exe,” version numbers, affiliate identifiers (for companies distributing the program to presumably share in ad revenues,) and other miscellaneous information.

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/machine-translators-may-leak-confidential-information

Hacking Team Leak, Flash 0day, Exploit Payloads And More

[Update – July 13, 2015]
In addition to the Flash 0day exploit that we reported earlier [CVE-2015-5119], two new Flash 0day exploits were found in the Hacking Team’s leaked data and these flaws are not yet patched:
CVE-2015-5122: valueOf use after free vulnerability during the assignment to freed TextBox
Two in-the-wild samples reported here
31d03169b9742a0ff04e3d24bb448bbf
fcecd6b624bb50301a17d5aa423e135d
CVE-2015-5123: valueOf use after free vulnerability during the assignment to freed Bitmap
Adobe acknowledged these issues over the weekend and is working on a patch. Meanwhile, ThreatLabZ has deployed additional coverage for these new exploits to protect Zscaler customers. We are continuously monitoring for new in-the-wild exploit payloads for these flaws.
Introduction
Data breaches have become a common and painful reality. Major enterprises, including retailers and financial institutions have been affected in the past few years. Even cyber criminals are not spared from breaches, with various malware code leaks, the most recent being that of the KINS 2.0 Banking Trojan family.
 
Earlier this week, we saw a large stolen information archive (400 GB) being published that belonged to the notorious Italian hackers-for-hire firm – Hacking Team. Hacking Team has been known to sell offensive surveillance technology to government agencies worldwide. The archive contains e-mails, invoices, and more importantly exploits & malware source codes. An individual that goes by the handle PhineasFisher has taken credit for the attack and if that name sounds familiar it’s because he’s done similar work before, having hacked and leaked data from Gamma International last year. His motivation for that breach was apparently similar as he accused the firm of selling surveillance tools to repressive regimes. While our assessment is far from over, in this blog, we will provide a quick run down of what we have seen in the archive related to exploits & malware thus far and we will continue to update as we discover more details.
Exploits, Remote Control System, and more
Flash 0-day exploit with Proof-Of-Concept (POC) [CVE-2015-5119] – Confirmed 0day for the latest version of Adobe Flash Player, running on Windows XP and Windows 7. The exploit did not succeed on Windows 8.1. We also saw support for targeting OS X. This is a Use-After-free vulnerability in Adobe Flash player’s built-in ByteArray class that can lead to crash or remote code execution by the attacker.
 Affected applications:
The majority of the popular browsers including Chrome, FireFox, Internet Explorer and Safari with Flash Player installed are vulnerable to this issue.
Microsoft Office 2007/2010/2013 – where the attack scenario will involve an office document with the malicious SWF file embedded in it. The document may arrive via an e-mail or as a drive-by download on the target system.
Adobe released a patch today to address this vulnerability.
Microsoft Windows Kernel code injection vulnerability exploit that can be leveraged to perform privilege escalation on the target system to bypass various security mechanisms
Support for iOS devices – They are leveraging the popular iOS Jailbreak application Cydia for iOS devices to further install malicious payloads on the target device.
Support for Android Devices – There is a separate module for Android OS (Android Webkit) that is leveraging a probable 0day exploit [we are still working on confirming this] in the Android browser and running various known root-access exploits like exynos, gingerbreak, levitator, etc. to root the target devices and further install malicious payloads. 
Support for Windows & Blackberry devices – We also saw source code for supposed exploits that will target Windows Phone 8 as well as Blackberry devices. 
MacOS Rooting exploit to enable online and offline installation of untrusted applications.
A Remote Control System (RCS) Dropper module that is capable of creating both mobile and computer system payloads for Windows and Macintosh. 
A multi-stage JAVA exploit module that contains a weaponized version as well as a two stage version with features to by pass Microsoft Security Essentials and an example Trojanized Putty.exe payload.
Multiple driver files that may contain Rootkit functionality to hide the malicious process and evade detection.
Source code of the core Remote Control System module where we can see the in-depth list of features supported by it.
core-win32:
1.) Monitoring modules for Instant messengers, Web Browsers, PC cameras & microphones, etc.
2.) Monitoring social media activities over Yahoo, Gmail, Twitter, and Facebook
3.) Hooking Outlook and getting email and contact details.
4.) Relaying infected system information including time, battery status, processor, memory, OS, user etc..
5.) Advanced keylogging capabilities
 We also observed support for 64-bit operating system target.
There are also multiple anti-VM, anti-Sandbox, and anti-AV evasion modules present in the source code archive.
We are still combing through the archive evaluating more exploits and we will continue to publish our findings as they emerge.
Loader configuration server
We saw a hardcoded IP address in the first stage shellcode payload that is supposedly hosting the configuration file as seen below
 
Hardcoded configuration file location
 
The shellcode payload is presumably used by the loader for downloading and installing the main RCS component following a successful exploitation attempt. A quick VirusTotal lookup for the IP address reveals lot of interesting activity in the past two months only:
 
VirusTotal report for the Configuration Server
Enterprises would be advised to block the aforementioned IP address if they are concerned that they may have been targeted by any of the Hacking Tools applications.
Conclusion
As has been the case in the past after any such leak, we will start seeing the leaked code being incorporated into many future spin offs as well as existing malware families as feature upgrades. Exploit Kit authors have already incorporated the Flash 0day payload in their exploit arsenal as noted here.
 
ThreatLabZ has ensured coverage for the Flash 0day (CVE-2015-5119) and other exploit payloads ensuring protection for the Zscaler customers. We will continue to monitor further developments surrounding this leak.
 
Research by: Abhay Yadav, Nirmal Singh, Deepen Desai
 
 
 

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/hacking-team-leak-flash-0day-exploit-payloads-and-more

Adobe Flash Vulnerability CVE-2015-5119 Analysis

 
With the leak of Hacking Team’s data, the security industry came to learn about multiple new 0day vulnerabilities targeting Flash, Internet Explorer, Android, etc. As always, exploit kit authors were quick to incorporate these 0day exploits into their arsenal.
In this blog, we will be looking at the CVE-2015-5119 exploit payload that we have now seen in the wild. The sample has multiple layers of obfuscation and packer routines. The malicious Flash payload is packed, XOR’ed and stored as a binary data inside a parent Flash file that dynamically unpacks a malicious Flash file and writes it to memory at run time.
 
Here is the structure of the CVE-2015-5119 exploit payload:
 
 
Packages, properties and method names are stored in variables for obfuscation:
 
 
Here we observe the calling of the unpack routine to decrypt the embedded SWF exploit payload:
 
 
An XOR key is used for unpacking and is hardcoded and assigned to the variable vari_10. This is what the unpacked content looks like:
 
 
 
Upon decompilation, it is apparent that majority of the codebase, including variable names and function names are the same as what we saw in the leaked source by the Hacking Team. The public exploit also has checks for:
 
Presence of a debugger
Operating System bitness (32-bit or 64-bit)
 
 
When the program execution starts, the ActionScript looks for the input parameters and based on it, sets a variable which is then sent to the main exploitation routine as seen below:
 
 
The TryExpl() routine allocates sequential pages of memory and begins the exploit cycle:
 
 
 
The vulnerability lies in making use of the valueOf property and corrupting the vector space so that the valueOf  property will overwrite the length field of the vector object, which will be further used to get access to vtables.
 
Here is explicit definition of valueOf function
 
 
prototype.valueOf() is setting up the length of the ByteArray to 4352
 
Once the memory allocation is done, a MyClass object is created and assigned to _ba[3]. The
valueOf()  function defines the length of ByteArray to 4352, which is greater than the length of the object created, causing reallocation of bytes inside the memory.
 
 
 
If the value of _ba[3] is set to zero after the assignment then it was successful in triggering a Use After Free vulnerability. The exploit code looks for the kernel32.VirtualProtect() (VP) function in the corrupted vector space as seen below:
 
 
A call to the VP function is made, which replaces the vtable pointer and sets the PAGE_EXECUTE_READWRITE permission before executing the final payload.
 
 
 
Hashes of  CVE-2015-5119 exploit payloads seen in the wild:
 
 
061c086a4da72ecaf5475c862f178f9d
079a440bee0f86d8a59ebc5c4b523a07
16ac6fc55ab027f64d50da928fea49ec
313cf1faaded7bbb406ea732c34217f4
6d14ba5c9719624825fd34fe5c7b4297
 
 
 
 
 
 
Conclusion
It will be a challenge for security vendors to get container file detection in place as majority of the time, the embedded content is highly obfuscated with multiple levels of packing. Adobe has already released a patch to fix this issue. We highly recommend enabling the Adobe’s auto update feature to keep the relevant plugins updated.
 
References:
 
http://malware.dontneedcoffee.com/2015/07/hackingteam-flash-0d-cve-2015-xxxx-and.html

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/adobe-flash-vulnerability-cve-2015-5119-analysis

Chinese Cyber Espionage APT Group Leveraging Recently Leaked Hacking Team Exploits To Target A Financial Services Firm

Introduction
As predicted following the leak of Hacking Team exploit codes covered here, the Zscaler security research team has recently started seeing a Chinese cyber espionage group weaponizing malware payloads using the 0-day exploits found in the leaked Hacking Team archives. As such, this new attack represents a dangerous new hybrid combining the work of a notorious cyber criminal gang with Chinese cyber espionage group to attack a financial services firm. 
 
Zscaler’s cloud sandboxes recently detected a Remote Access Trojan (RAT) being delivered by a well-known Chinese cyber espionage group using the Hacking Team’s 0-day exploits. This attack was specifically targeting a well-known financial services firm. The exploit files involved were identical to the Hacking Team’s leaked exploit HTML, JavaScript, and ShockWave Flash 0-day files. The end payload that was installed is the HttpBrowser RAT, known to be used by the Chinese group in previous targeted attacks against governments.
 
Figure 1: Chinese APT attack cycle to plant HttpBrowser RAT
 
Hacking Team Exploits
The attack involved targeted users visiting a malicious URL delivered via a spear phishing attack. The malicious URL points to a remote server located in Hong Kong (IP Address – 210.209.89.162) that downloads and executes a malicious ShockWave Flash payload through a specially crafted HTML & JavaScript. The exploit files involved are identical to the ones that we found during our analysis of the Hacking Team leaked code as seen below:
 
Figure 2: Resemblance with Hacking Team’s exploit HTML
 
Figure 3: Resemblance with Hacking Team’s SWF exploit
The Adobe ShockWave exploit (CVE-2015-5119) if successful will download and install a variant of the HttpBrowser RAT from the same Hong Kong based server which eventually also serves as the Command & Control (C&C) server.
 
Figure 4: Hong Kong based server used in the attack [credit: domaintools.com]
Malware Payload – HttpBrowser RAT
HttpBrowser is a RAT that has become extremely popular in past two years among the APT adversaries, leveraged in various targeted attacks. The RAT has been leveraged as the primary payload by the APT group that is also known to install the nasty Backdoor PlugX RAT during lateral movement in the victim environment after compromise.
 
The HttpBrowser payload used for the attack was compiled just few days before the attack as seen below:
Figure 5: HttpBrowser payload compilation time
The HttpBrowser installer archive structure is very similar to that observed in previous PlugX attacks. The installer archive in our case was svchost.exe (saved as xox.exe) that consisted of the following three files:
 
VPDN_LU.exe – A legitimate digitally signed Symantec Antivirus executable to evade detection
Figure 6: Legitimate Symantec Antivirus executable used in the attack 
navlu.dll – A fake Symantec DLL to decrypt and run the HttpBrowser RAT
navlu.dll.url – Encrypted HttpBrowser RAT payload
The HttpBrowser RAT installer is responsible for dropping the above three files and running the legitimate Symantec Antivirus binary VPDN_LU.exe. The legitimate binary contains the navlu.dll in the import table ensuring that the DLL will be loaded before it runs. The navlu.dll that gets loaded in this case will be the fake Symantec DLL file present in the same directory and it will patch the entry point of the main executable file with a jump instruction to run the DLL’s code instead. 
 
Figure 7: Legitimate executable entry point patched
This technique is also known as DLL Hijacking which ensures that the fake Symantec DLL gets loaded by abusing the Windows DLL load order. The DLL’s code is responsible for decrypting and running the HttpBrowser RAT payload from the navlu.dll.url file in the same memory space of the benign executable. The decryption routine consist of an incremental XOR as seen below:
 
Figure 8: Incremental XOR routine to decrypt RAT payload
The HttpBrowser installer structure ensures that the malware evades detection by running in the context of the legitimate signed binary. This also ensures that the malicious DLL will not run by itself in automated analysis environments.
 
The malware then deletes the original installer file and moves the dropped files to the following location:
%ALLUSERPROFILE%\%APPDATA%\vpdn\VPDN_LU.exe
%ALLUSERPROFILE%\%APPDATA%\vpdn\navlu.dll
%ALLUSERPROFILE%\%APPDATA%\vpdn\navlu.dll.dll
The malware also creates the following registry entry to ensure persistence:
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Run vpdn “%ALLUSERPROFILE%\%APPDATA%\vpdn\VPDN_LU.exe”
Command & Control communication
The HttpBrowser RAT variant was configured to connect to the following Command & Control server upon successful infection:
update.hancominc[.]com:8080
It relays the following information of the victim machine in an encrypted format over SSL:
/loop?c=

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/chinese-cyber-espionage-apt-group-leveraging-recently-leaked-hacking-team-exploits-target-financial-services-firm

Neutrino Campaign Leveraging WordPress, Flash For CryptoWall

Overview
Neutrino Exploit Kit (EK) appeared on the scene around March of 2013 and continues to remain active and incorporate new exploits. In the beginning of July, Neutrino reportedly incorporated the HackingTeam 0day (CVE-2015-5119), and in the past few days we’ve seen a massive uptick in the use of the kit. The cause for this uptick appears due to widespread WordPress site compromises.
ThreatLabZ started seeing a new campaign where WordPress sites running version 4.2 and lower were compromised, and the image below illustrates the components involved in this campaign.
 
Fig 1. Complete Neutrino WordPress campaign
In analyzing the infection cycle, there are multiple recent changes in the Neutrino code, some that are normally characteristics of Angler Exploit Kit, but others that remain unique to Neutrino.
WordPress Compromises
Similar to Angler Exploit Kit, the new wave of Neutrino is targeting outdated versions of WordPress. In fact, we have seen over 2600 unique WordPress sites being used in this campaign where more than 4200 distinct pages have been logged with dynamic iframe injection in the last month. As mentioned, all the targeted websites were running WordPress version 4.2 and lower.
 
Fig 2. Event timeline overview
The goal of this campaign is to completely and fully compromise the site, which includes adding a webshell, harvesting credentials, and finally injecting an iframe that loads a Neutrino landing page. The iframe is injected into the compromised site immediately after the BODY tag, and is almost identical to recent Angler samples. Compare these recent Neutrino and Angler samples below.
 
Fig 3. Neutrino on the left, Angler on the right
The code specifically targets Internet Explorer, so those using other browsers won’t be served the iframe, and a cookie is used to prevent serving the iframe multiple times to the same victim.
The actual Neutrino landing pages are retrieved on the backend through the injected php code, a sample of which is below:
 
Fig 4. Injected php code
Note the base64 encoded value boxed in red above; this decodes to the URL below, where X, Y, and Z are integers:
http://93.171.205.64/blog/?bf4z&utm_source=XXXXX:YYYYYY:ZZZ
This URL is used to retrieve an updated landing page URL, and we’ve noted that the URLs change very frequently. Additionally, the primary IP hosting the majority of landing page domains is ‘185.44.105.7’ which is owned by VPS2DAY.com. We reached out to them via email briefly explaining what we were seeing and received no response.
Neutrino Landing Page
The landing page has been updated and contains some JavaScript that only declares variables, and then a flash loader:
 
Fig 5. Neutrino landing page
If flash isn’t installed on the victim machine, an old flash cab is pushed to the user prior to serving the malicious SWF. Note the departure from using base64 encoded data blobs, or really using very much code at all on the landing page.
 
Neutrino SWF
Past versions of the Neutrino SWF contained multiple exploit payloads encrypted via RC4. Examining this SWF shows that things have apparently changed as the structure is very different:
 
Fig 6. SWF structure
Taking a look at the code shows that instead of RC4, there is a decode function that uses the input of one binary data blob to decode a second binary blob; the decoded data reveals a second SWF:
 
Fig 7. Decode function for embedded SWF
Detection results for the SWF are very poor with only one vendor detecting it:
 
Fig 8. Poor detection results on SWF
Carving out the embedded SWF and analyzing it shows a much more familiar structure for Neutrino, with some additional enhancements. Notably similar is the use of multiple embedded binary blobs that are RC4 encrypted:
 
Fig 9. Binary data inside embedded SWF
 
Fig 10. Script data inside embedded SWF – characteristic of Neutrino
These binary blobs contain multiple payloads, and this has been analyzed and documented in the past, notably by Kafeine and Dennis O’Brien on Malwageddon. However, unlike past Neutrino SWFs, the RC4 keys are no longer in cleartext and decoding them requires tracing through multiple function calls. The ActionScript structure is still very recognizable though:
 
Fig 11. Decoder for one binarydata ‘exploitWrapper’ blob
Detection on the embedded SWF is also quite poor.
Fig 12. Embedded SWF VT detection
 
Payload
Successful exploitation of a victim leads to an encrypted executable download. The binary is decrypted and begins beaconing almost immediately:
 
Fig 13. Initial beacon summary
Fig 14. Full beacon/response sample
 
 
Looking at the traffic, we can immediately see this is CryptoWall 3.0. Sure enough, a couple minutes later we see the all too familiar ‘HELP_DECRYPT’ page and see connections out to the payment servers:
 
Fig 15. Payment server connections
 
Fig 16. CryptoWall 3.0 HELP_DECRYPT page
To read more about CryptoWall, please see our previous writeup here.
 
Campaign Information
As stated, the primary IP for the observed Neutrino landing pages is ‘185.44.105.7’ which is owned by VPS2DAY.com. Many of the domains pointing to that IP utilize ‘xyz’, ‘ga’, ‘gq’, and ‘ml’ TLDs. Taking a look at the whois data for some of these domains, a common attribute seems to be the name ‘Max Vlapet’ for .XYZ domains. Full whois domain sample for completeness:
WHOIS MOHGROUP.XYZ
Domain Name: MOHGROUP.XYZ 
Domain ID: D9543161-CNIC 
WHOIS Server: whois.alpnames.com 
Referral URL: 
Updated Date: 2015-08-18T08:34:04.0Z 
Creation Date: 2015-08-18T08:34:03.0Z 
Registry Expiry Date: 2016-08-18T23:59:59.0Z 
Sponsoring Registrar: AlpNames Limited 
Sponsoring Registrar IANA ID: 1857 
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited 
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited 
Domain Status: addPeriod https://icann.org/epp#addPeriod 
Registrant ID: ALP_44867689 
Registrant Name: Max Vlapet 
Registrant Organization: N/A 
Registrant Street: Mausoleum str, pl.13 
Registrant City: Moscow 
Registrant State/Province: Moscow 
Registrant Postal Code: 123006 
Registrant Country: RU 
Registrant Phone: +7.4959826524 
Registrant Phone Ext: 
Registrant Fax: 
Registrant Fax Ext: 
Registrant Email: maxvlapet@gmail.com 
Admin ID: ALP_44867689 
Admin Name: Max Vlapet 
Admin Organization: N/A 
Admin Street: Mausoleum str, pl.13 
Admin City: Moscow 
Admin State/Province: Moscow 
Admin Postal Code: 123006 
Admin Country: RU 
Admin Phone: +7.4959826524 
Admin Phone Ext: 
Admin Fax: 
Admin Fax Ext: 
Admin Email: maxvlapet@gmail.com 
Tech ID: ALP_44867689 
Tech Name: Max Vlapet 
Tech Organization: N/A 
Tech Street: Mausoleum str, pl.13 
Tech City: Moscow 
Tech State/Province: Moscow 
Tech Postal Code: 123006 
Tech Country: RU 
Tech Phone: +7.4959826524 
Tech Phone Ext: 
Tech Fax: 
Tech Fax Ext: 
Tech Email: maxvlapet@gmail.com 
Name Server: NS2.MOHGROUP.XYZ 
Name Server: NS1.MOHGROUP.XYZ 
DNSSEC: unsigned 
Billing ID: ALP_44867689 
Billing Name: Max Vlapet 
Billing Organization: N/A 
Billing Street: Mausoleum str, pl.13 
Billing City: Moscow 
Billing State/Province: Moscow 
Billing Postal Code: 123006 
Billing Country: RU 
Billing Phone: +7.4959826524 
Billing Phone Ext: 
Billing Fax: 
Billing Fax Ext: 
Billing Email: maxvlapet@gmail.com 
>>> Last update of WHOIS database: 2015-08-19T00:44:12.0Z < Unfortunately, very little information is available for the other TLDs in use. The backend IP serving new landing page URLs is registered to a company called 'VDS INSIDE' located in Ukraine. A dump of the 700+ malicious domains and/or landing pages we've collected is on pastebin: http://pastebin.com/946rPaGx Conclusion WordPress, being a widely popular and free Content Management System (CMS), remains one of the most attractive targets for cyber criminals.  WordPress compromises are not new, but this campaign shows an interesting underground nexus starting with backdoored WordPress sites, a Neutrino Exploit Kit-controlled server, and the highly effective CryptoWall ransomware. This campaign also reconfirms that Neutrino Exploit Kit activity is on the rise and is still a major player in the exploit kit arena. ThreatLabZ is actively monitoring this campaign and ensuring that Zscaler customers are protected.   Acknowledgement Special thanks to Dhruval Gandhi for profiling compromised WordPress sites Write-up by: John Mancuso, Deepen Desai  

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/neutrino-campaign-leveraging-wordpress-flash-cryptowall

An Update On Nuclear (Reverse) Engineering

 
Introduction
Although Angler continues to be the leading exploit kit, Nuclear is a significant threat to web surfers and seems to have been very active lately. ThreatLabZ recently encountered a Nuclear campaign originating from a variety of compromised sites. These compromises continue the trend of WordPress sites serving malcode, and in this case included the web-presence of a UK-based healthcare organization.
 
Example of recent Nuclear landing page to exploit cycle
 
The execution flow of this campaign is typical: an infected site includes an embedded iframe that loads the exploit kit landing page. The landing page checks the browser family and version and tests the available Flash version before choosing one of several exploit payloads. From here, multiple possible payloads may be downloaded, particularly Fareit Infostealer Trojan and Troldesh Ransomware Trojan.
 
Nuclear Landing
As covered recently, WordPress continues to be one of the most effective traffic sources for exploit kits. However, the majority of traffic we have seen does not feature the visitorTracker component, but merely includes a hidden iframe in the footer of the WordPress page.
 
 
The malicious iframe is preceded by a large number of blank lines
The iframe loads the landing page, which features obfuscated JavaScript and random-looking text blocks. It turns out that some of the random looking text blocks are actually obfuscated components that the JavaScript eventually deobfuscates and executes.
 
Lines 7 and 9 are overlaid with the script invocations that decode the HTML blocks
 
Nuclear Exploit Payloads
The landing pages we evaluated led to two possible Flash exploits as well as one Internet Explorer exploit. Specifically, we saw CVE-2015-5122 and CVE-2015-5560 exploits for Flash, and a highly obfuscated CVE-2014-6332 exploit for IE.
 
The first Flash payload stage checks Flash Player version and prepares the appropriate exploit
As noted by Kafeine, Nuclear has integrated the same Diffie-Hellman Angler first pioneered, only now it is implemented in Flash to protect the CVE-2015-5560 payload. This campaign also features an XTEA function with modified constants.
 
A Diffie-Hellman key exchange implementation is used to protect the new Flash payload
Besides making reverse engineers lives harder, the authors have also decided to include some friendly shoutouts to those analyzing their code. In the case of the featured Flash payloads, the string “fuckAV" is used as a special constant.
 
This function returns an XOR key when "fuckAV" is supplied as a parameter
Nuclear Fallout
Once the browser is exploited, Nuclear first drops a Fareit payload. Fareit is an infostealer, and as can be seen in the strings below, is looking to steal user credentials for multiple applications and websites as well as BitCoin wallet information.
 
A sample of the files and paths Fareit checks for user credentials
While stealing users information, Fareit attempts to hide its command and control communication by sending its check-in request in the midst of a batch of HTTP requests to innocuous looking websites.
 
After checking connectivity on MSN.com, multiple POSTs are performed
In addition to the Fareit payload, a Troldesh ransomware payload was also seen. Troldesh is yet another in the line of ransomware families that encrypt user files and attempt to extract a ransom payments in exchange for decryption keys. This campaign is using the email addresses files100005(at)gmail.com and files100006(at)gmail.com and the Tor address a4yhexpmth2ldj3v.onion.
 
Troldesh bundles a Tor proxy to protect its communication
 
Although they might prefer to infect the machines of non-analysts, the Troldesh author does take the opportunity to greet their reverse engineer friends. This message is less aggressive than the greeting in the Nuclear flash payload.
 
Thanks, but I don’t drink coffee!
 
Conclusion
While Nuclear may not be the exploit kit that regularly debuts the latest advances, the authors certainly make an effort to keep up with new exploits and new obfuscation techniques. ThreatLabZ will continue to monitor Nuclear (and Fareit and Troldesh) for any new developments or greetings.
 
Appendix:
Indicators:
 
Recent landing page IP addresses
Recent landing page hostnames
Recent compromised sites and redirectors
 

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/update-nuclear-reverse-engineering