# Magnitude exploit kit – evolution
**securelist.com/magnitude-exploit-kit-evolution/97436/**
Authors
Boris Larin
Exploit kits are not as widespread as they used to be. In the past, they relied on the use of
already patched vulnerabilities. Newer and more secure web browsers with automatic
updates simply do not allow known vulnerabilities to be exploited. It was very different back
in the heyday of Adobe Flash because it’s just a plugin for a web browser, meaning that even
if the user has an up-to-date browser, there’s a non-zero chance that Adobe Flash may still
be vulnerable to 1-day exploits. Now that Adobe Flash is about to reach its end-of-life date at
the end of this year, it is disabled by default in all web browser and has pretty much been
replaced with open standards such as HTML5, WebGL, WebAssembly. The decline of exploit
kits can be linked to the decline of Adobe Flash, but exploit kits have not disappeared
completely. They have adapted and switched to target users of Internet Explorer without the
latest security updates installed.
Microsoft Edge replaced Internet Explorer as a default web browser with the release of
Windows 10 in 2015, but Internet Explorer is still installed for backward compatibility on
machines running Windows 10 and it has remained a default web browser for Windows
-----
7/8/8.1. The switch to Microsoft Edge development also meant that Internet Explorer would
no longer be actively developed and would only receive vulnerability patches without general
security improvements. Still, somehow, Internet Explorer remains a relatively popular web
[browser. According to NetMarketShare, as of April 2020 Internet Explorer is used on 5.45%](https://meterpreter.org/netmarketshare-april-data-windows-os-decrease-edge-was-firmly-in-second-place/)
of desktop computers (for comparison, Firefox accounts for 7.25%, Safari 3.94%, Edge
7.76%). Despite the security of Internet Explorer being five years behind that of its modern
[counterparts, it supports a number of legacy script engines. CVE-2018-8174 is a vulnerability](https://securelist.com/delving-deep-into-vbscript-analysis-of-cve-2018-8174-exploitation/86333/)
in a legacy VBScript engine that was originally discovered in the wild as an exploited zeroday. The majority of exploit kits quickly adopted it as their primary exploit.
[Since the discovery of CVE-2018-8174 a few more vulnerabilities for Internet Explorer have](https://securelist.com/delving-deep-into-vbscript-analysis-of-cve-2018-8174-exploitation/86333/)
been discovered as in-the-wild zero-days: CVE-2018-8653, CVE-2019-1367, CVE-20191429, and CVE-2020-0674. All of them exploited another legacy component of Internet
Explorer – a [JScript engine. It felt like it was just a matter of time until exploit kits adopted](https://googleprojectzero.blogspot.com/2017/12/apacolypse-now-exploiting-windows-10-in_18.html)
these new exploits.
Exploit kits still play a role in today’s threat landscape and continue to evolve. For this
blogpost I studied and analyzed the evolution of one of the most sophisticated exploit kits out
there – Magnitude EK – for a whole year.
This blogpost in a nutshell:
Magnitude EK continues to deliver ransomware to Asia Pacific (APAC) countries via
malvertising
Study of the exploit kit’s activity over a period of 12 months shows that Magnitude EK is
actively maintained and undergoes continuous development
In February this year Magnitude EK switched to an exploit for the more recent
vulnerability CVE-2019-1367 in Internet Explorer (originally discovered as an exploited
zero-day in the wild)
Magnitude EK uses a previously unknown elevation of privilege exploit for CVE-20188641 developed by a prolific exploit writer
## Introduction
Magnitude EK is one of the longest-standing exploit kits. It was on offer in underground
forums from [2013 and later became a private exploit kit. As well as a change of actors, the](https://malware.dontneedcoffee.com/2014/02/and-real-name-of-magnitude-is.html)
[exploit kit has switched its focus to deliver ransomware to users from specific Asia Pacific](https://blog.trendmicro.com/trendlabs-security-intelligence/magnitude-exploit-kit-now-targeting-korea-with-magniber-ransomware/)
(APAC) countries via malvertising.
-----
_Active attacks by Magnitude EK in 2019 according to Kaspersky Security Network (KSN)_
_[(download)](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/06/23085939/sl_magnitude_exploit_kit_01-en-2019.png)_
-----
_Active attacks by Magnitude EK in 2020 according to Kaspersky Security Network (KSN)_
_[(download)](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/06/23090011/sl_magnitude_exploit_kit_02-en-2020.png)_
Our statistic shows that this campaign continues to target APAC countries to this day and
during the year in question Magnitude EK always used its own ransomware as a final
payload.
### Infection vector
[Like the majority of exploit kits out there, in 2019 Magnitude EK used CVE-2018-8174.](https://securelist.com/delving-deep-into-vbscript-analysis-of-cve-2018-8174-exploitation/86333/)
However, the attackers behind Magnitude EK were one of the first to adopt the much newer
[vulnerability CVE-2019-1367 and they have been using it as their primary exploit since](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1367)
-----
February 11, 2020. As was the case with CVE-2018-8174, they didn t develop their own
exploit for CVE-2019-1367, instead reusing the original zero-day and modifying it with their
own shellcode and obfuscation.
CVE-2019-1367 is a Use-After-Free vulnerability due to a garbage collector not tracking a
value that was not rooted in the legacy JavaScript engine jscript.dll. By default, Internet
Explorer 11 uses Jscript9.dll, but it’s still possible to execute the script using the legacy
engine by enabling compatibility mode with Internet Explorer 7/8. This can be done with the
following script attributes:
1
2
3
4
5
[The original exploit uses JScript.Compact, a special profile defined for embedded devices.](https://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/Ecma-327.pdf)
But JScript.Encode is much more interesting because it was developed by Microsoft to
protect scripts and prevent source code from being copied. This script attribute can execute
scripts encoded with Microsoft Script Encoder (screnc.exe) and it also disables script
debugging. Basically, it’s a DRM for JavaScript. Magnitude EK changed from its original
exploit to take advantage of this feature.
-----
**_Exploit packed with JScript.Encode technique_**
**_Unpacked exploit. Shellcode, names and some strings are obfuscated_**
## Shellcode
-----
Their shellcodes piqued my interest. They use a huge number of different shellcode
encoders, from the classical Metasploit shikata_ga_nai encoder and DotNetToJScript to a
variety of custom encoders and stagers.
It was also impossible not to notice the changes happening to their main shellcode
responsible for launching the ransomware payload. The attackers are fine-tuning their
arsenal on a regular basis.
Magnitude EK has existed since at least 2013, but below you can see just the changes to
payload/shellcode that occurred over the period of one year (June 2019 to June 2020).
During this period we observed attacks happening almost every day.
**Timeline of shellcode/payload changes**
Date Description
June
2019
July 20,
2019
November
11, 2019
November
20, 2019
November
23, 2019
Shellcode downloads a payload that’s decrypted with a custom xor-based
algorithm. All strings are assembled on stack and to change payload the URL
shellcode needs to be recompiled. The payload is a PE module. The module
export function name is hardcoded to “GrfeFVGRe”. The payload is executed
in an Internet Explorer process. It contains an elevation of privilege exploit
with support for x86 and x64 versions of Windows and an encrypted
ransomware payload. After elevation of privilege it injects the ransomware
payload to other processes, spawns the wuapp.exe process and injects there
as well. If process creation fails, it also runs the ransomware from the current
process.
Payload module export function name is auto-generated.
Shellcode tries to inject the payload to other processes. If API function
Process32First fails, it spawns the process wuapp.exe from Windows
directory and injects the payload there. The injection method is
WriteProcessMemory + CreateRemoteThread.
The payload is ransomware without elevation of privilege. The payload
module export function name is hardcoded again, but now to “lssrcdxhg”.
Looks like they messed up the folder with shellcodes; in some attacks they
use a shellcode from June, and later the same day they start to use their
November shellcode with the new hardcoded export name
“by5eftgdbfgsq323”.
They start to use the elevation of privilege exploit again, but now they also
check the integrity level of the process. If it’s a low integrity process, then they
execute the payload with the exploit in the current process; if that’s not the
case, then it’s injected into other processes. The process is no longer created
from shellcode, but it’s still created from the payload. The payload module
export name is hardcoded to “gv65eytervsawer2”.
-----
January
17, 2020
January
27, 2020
February
4, 2020
February
10, 2020
February
11, 2020
February
17, 2020
February
28, 2020
March 1,
2020
March 6,
2020
March 10,
2020
March 16,
2020
It looks like the attackers had a short holiday at the beginning of the year. The
shellcode remains the same, but the payload module export function name is
hardcoded to “i4eg65tgq3f4”. The payload changed a bit. The name of the
created process is now assembled on stack. The name of the process also
changed – it no longer spawns a wuapp.exe, but instead launches the
calculator calc.exe and injects the ransomware payload there.
The payload is no longer a PE module but plain shellcode. The payload
consists of ransomware without elevation of privilege.
The payload is a PE module again, but once again the export name is autogenerated.
The shellcode comes with two URLs for different payloads. The shellcode
checks the integrity level and depending on process integrity level, it executes
the elevation of privilege payload or uses the ransomware payload
straightaway. All strings and function imports in the exploit are now
obfuscated. The payload does not spawn a new process, and only injects to
others.
Magnitude EK starts using CVE-2019-1367 as its primary exploit. The
attackers use the shellcode from January 27, 2020, but they have modified it
to check for the name of a particular process. If the process exists, they don’t
execute the payload from Internet Explorer. The process name is “ASDSvc”
(AhnLab, Inc.).
The attackers switch to the shellcode from February 10, 2020, but the
payload module export function name is hardcoded to “xs324qsawezzse”.
Shellcode encryption is removed. The payload module export function name
is hardcoded to “sawd6vf3y5”.
Strings are no longer stored on stack.
Back to the shellcode from February 17, 2020.
The attackers add some functionality implemented after February 17, 2020:
payload encryption is removed and strings are no longer stored on stack. The
payload module export function name is still hardcoded to “xs324qsawezzse”.
Functionality added so as not to inject into a particular process (explorer.exe).
The injection method is also changed to NtCreateSection +
NtMapViewOfSection + RtlCreateUserThread.
-----
April 2,
2020
April 4,
2020
April 7,
2020
May 5,
2020
May 6,
2020
The attackers add some functionality similar to that used in November 2019.
They check the integrity level of a process and if it’s a low integrity process,
they execute the payload from the current process. If that’s not the case, they
inject it to other processes (other than explorer.exe) and at the end create a
new process and inject it there as well. The created processes are
C:\Program Files\Windows Media Player\wmlaunch.exe or C:\Program Files
(x86)\Windows Media Player\wmlaunch.exe depending on whether it’s a
WOW64 process or not.
Shellcode updated to use a new injection technique: NtQueueApcThread.
The shellcode also comes with a URL for a ransomware payload without
elevation of privilege. The shellcode checks the integrity level and if it’s a low
integrity process, the shellcode calls ExitProcess(). Use of the hardcoded
export name “xs324qsawezzse” is also stopped.
Back to the shellcode from April 2, 2020.
Previously the attackers adjusted their injection method, but now they revert
back to injection via the WriteProcessMemory + CreateRemoteThread
technique.
They continue to make changes to the code injection method. From now on
they use NtCreateThreadEx.
## Elevation of privilege exploit
The elevation of privilege exploit used by Magnitude EK is quite interesting. When I saw it for
the first time, I wasn’t able to recognize this particular exploit. It exploited a vulnerability in
the win32k kernel driver and closer analysis revealed that this particular vulnerability was
fixed in December 2018. According to Microsoft, only two win32k-related elevation of
privilege vulnerabilities were fixed that month – CVE-2018-8639 and CVE-2018-8641.
Microsoft previously shared more information with us about CVE-2018-8639, so we can say
with some certainty that the encountered exploit uses vulnerability CVE-2018-8641. The
exploit has huge code similarities with another zero-day that we had found previously – CVE2019-0859. Based on these similarities, we attribute this exploit to the prolific exploit writer
known as “Volodya”, “Volodimir” or “BuggiCorp”. Volodya is famous for selling zero-day
exploits to both APT groups and criminals. In the past, Volodya advertised his services at
exploit(dot)in, the same underground forum where Magnitude EK was once advertised. We
don’t currently know if the exploit for CVE-2018-8641 was initially used as a zero-day exploit
or it was developed as a 1-day exploit through patch diffing. It’s also important to note that a
public exploit for CVE-2018-8641 also exists, but it’s incorrectly designated to CVE-20188639 and it exploits the vulnerability in another fashion, meaning there are two completely
different exploits for the same vulnerability.
## Ransomware
-----
Magnitude EK uses its own ransomware as its final payload. The ransomware comes with a
temporary encryption key and list of domain names and the attackers change them
frequently. Files are encrypted with the use of Microsoft CryptoAPI and the attackers use
Microsoft Enhanced RSA and AES Cryptographic Provider (PROV_RSA_AES). The
initialization vector (IV) is generated pseudo randomly for each file and a 0x100 byte long
blob with encrypted IV is appended to the end of the file. The ransomware doesn’t encrypt
the files located in common folders such as documents and settings, appdata, local settings,
sample music, tor browser, etc. Before encryption, the extensions of files are checked
against a hash table of allowed file extensions that contains 715 entries. A ransom note is
left in each folder with encrypted files and at the end a notepad.exe process is created to
display the ransom note. To hide the origin of the executed process, the ransomware uses
one of two techniques: “wmic process call create” or “pcalua.exe –a … -c …”. After
encryption the ransomware also attempts to delete backups of the files with the “wmic
shadowcopy delete” command that is executed with a UAC-bypass.
**_Example of Magnitude EK ransom note_**
The core of the ransomware did not undergo many changes throughout the year. If we
compare old samples with more recent versions, there are only a few notable changes:
-----
In older versions, immediately at launch the payload gets the default UI language of the
operating system using the GetSystemDefaultUILanguage API function and compares
the returned value against a couple of hardcoded language IDs (e.g. zh-HK – Hong
Kong S.A.R., zh-MO – Macao S.A.R., zh-CN – People’s Republic of China, zh-SG –
Singapore, zh-TW – Taiwan, ko-KR – Korea, ms-BN – Brunei Darussalam, ms-MY –
Malaysia). If the language ID doesn’t match, then ExitProcess() will be executed. In
newer versions, the check for the language ID was removed.
In older versions, the ransomware deletes file backups with the command “cmd.exe /c
“%SystemRoot%\system32\wbem\wmic shadowcopy delete” via UAC-bypass in
eventvwr.exe. In the newer version, the command is obfuscated with caret character
insertion “cmd.exe /c “%SystemRoot%\system32\wbem\wmic ^s^h^a^d^o^w^c^o^p^y^
^d^e^l^e^t^e” and executed via UAC-bypass in CompMgmtLauncher.exe.
## Conclusions
The total volume of attacks performed by exploit kits has decreased, but they still exist, are
still active, and still pose a threat, and therefore need to be treated seriously. Magnitude is
not the only active exploit kit and we see other exploit kits that are also switching to newer
exploits for Internet Explorer. We recommend installing security updates, migrating to a
newer operating system (make sure you stay up to date with Windows 10 builds) and also
not using Internet Explorer as your web browser. Throughout the entire Magnitude EK
campaign we have detected the use of Internet Explorer exploits with the verdict
PDM:Exploit.Win32.Generic.
[Browser](https://securelist.com/tag/browser/)
[Exploit Kits](https://securelist.com/tag/exploit-kits/)
[Malware Descriptions](https://securelist.com/tag/malware-descriptions/)
[Malware Technologies](https://securelist.com/tag/malware-technologies/)
[Ransomware](https://securelist.com/tag/ransomware/)
[Vulnerabilities and exploits](https://securelist.com/tag/vulnerabilities-and-exploits/)
Authors
Boris Larin
Magnitude exploit kit – evolution
Your email address will not be published. Required fields are marked *
-----