Magnitude Exploit Kit (EK) is one of the older kits in the cyber criminal market.  Over the years, it has become one of the most used EKs.  This EK continues adding new exploits, which have included recent zero-days, in its arsenal.

Earlier this month, information was posted by Kafeine at Proofpoint (link) and Genwei Jiang at FireEye (link) about Magnitude EK using CVE-2016-1019 as a zero-day Flash exploit.  Such developments put Magnitude on par with advanced EKs like Angler and Nuclear.  For this blog post, we'll look at an April 2016 infection.  A closer examination of this EK will help us understand why cybercriminals still choose Magnitude for new campaigns.

Shown above:  Fiddler dump of a Magnitude EK infection examined in the Proofpoint blog post.



On 2016-04-02, Malwarebytes posted a blog about Magnitude EK using fingerprinting gates (link).  As Malwarebytes and others have already noted, Magnitude EK includes profiling gates before it hits the actual EK domain.  These profiling gates check the victim's system for various security products.  The first profiling gate checks for Kaspersky software.  The second profiling gate checks for a list of various security or virtualization products.  The complete list of security products Magnitude checks can be found in the Appendix of FireEye's blog post mentioned earlier (link).  In the image below, we can see the first profiling gate checking for Kaspersky.

Shown above:  First profiling gate, using a debugger in IE 8 to decode the variable that checks for Kaspersky software on the victim's system.

Shown above:  Second profiling gate, using a debugger in IE 8 to decode the variable that checks for Fiddler and other software on the victim's system.



If none of those security products are found on the victim's machine, the victim's machine is sent to the Magnitude EK landing page.  The landing page calls another script that invokes a Flash file.  This Flash file acts as a redirector to the actual Flash exploit targeting the CVE-2016-1019 vulnerability.

Shown above:  Magnitude EK landing page, using a debugger in IE 8 to decode the variable that sets up the other HTTP GET requests.



The redirector Flash file has script that appends the Flash Player version from the victim's machine to the request URL for the actual Flash exploit.

Shown above:  Magnitude EK sends a Flash file that acts as a redirector.

Shown above:  Finding the action script in the Flash redirector file using the JPEX Free Flash Decompiler.



Magnitude EK uses SecureSWF for its Flash exploits.  This CVE-2016-1019 Flash exploit was no exception, and it had the same obfuscation technique as seen in other Flash exploits from Magnitude.

Shown above:  Magnitude EK sends a CVE-2016-1019 Flash exploit.

Shown above:  Code snippet from ActionScript of Magnitude EK's CVE-2016-1019 Flash exploit.



Magnitude deploys a variety of techniques to increase the chances of infection.  The shellcode is common for all exploits served by this kit.  The shellcode starts by loading wininet.dll and calling wininet.InternetOpenUrlA to download the payload.

Shown above:  The first HTTP GET request with Magnitude EK downloading a payload.

Shown above:  Magnitude EK downloading the payload and its associated shellcode.


Next, the shellcode calls wininet.HttpQueryInfoA to get the size of the payload.  The returned payload is written to the buffer using wininet.InternetReadFile.

Shown above:  Getting the downloaded size.


The downloaded payload in this case is a privileged escalation exploit from the infamous hacking team (CVE-2015-2426).  The downloaded payload looks something like this:

Shown above:  The downloaded payload (CVE-2015-2426).


The shellcode searches inside the downloaded payload for a function responsible for triggering the vulnerability.  Markers (42212f41) are used to identify the end of this function.

Shown above:  Searching the end of trigger function.


On finding the marker, the shellcode goes back one byte at a time to the find the start of this function by checking for bytes "558BEC" translating to function prologue: push ebp, mov ebp,esp.

Shown above:  Searching the start of the trigger function.


The shellcode them jump to the start of function and starts resolving APIs required to trigger the vulnerability.

Shown above:  APIs used in crafting the exploit (CVE-2015-2426).



The payload contains a small code injection stub as well.  The code traverses through all the processes currently running by calling Kernel32.Process32Next and kernel32.OpenProcessA on every process.  On getting a valid handle, the injection stub is copied to the opened process.

Shown above:  Injecting code into another process.


Magnitude has updated the injection code.  The new code does not work properly and crashes the target process!  The injected code starts with "DEADBEEF" which translates to an invalid instruction resulting in crash.

Shown above:  The injection code.

Shown above:  Fiddler entries that show the shellcode downloading a payload.


The injection code found in older instances of Magnitude EK was a straightforward download and execute stub.

Shown above:  Injection code found in older instances.


But let's go back to the April 2016 example of code injection used to download the malware.

Shown above:  The injected process wuauclt.exe downloading malware.



The code injection routine marks the end of the downloaded payload.  The shellcode then prepares it's own set of APIs to download the malware one more time!  The downloaded malware is executed using Kernel32.CreateProcessA.

Shown above:  APIs used in downloading malware.



The author is still not satisfied and executes a PowerShell script to download and execute the same malware again using Kernel32.WinExec.

Shown above:  PowerShell script downloading malware.

Shown above:  Full infection after the CVE-2016-1019 Flash exploit.




Click here to return to the main page.