The Evolution of Magniber Ransomware

Recent Changes in Magniber Ransomware

Recent Changes in Magniber Ransomware Magniber is one of the most well-known fileless malware that is distributed via Magnitude Exploit Kit. It commonly exploits web browser vulnerabilities, such as Internet Explorer (IE) vulnerability.

Magniber underwent sudden changes between September 2019 and February 2020. During September and November 2019, Magniber exploited vulnerability (CVE-2019-1367). However, the vulnerability exploited for attacks has changed over the past few months. According to a recent proof of concept (PoC) revealed by Virus Total, Magiber has been exploiting an IE vulnerability (CVE-2019-1367). Immediately after the discovery, it was confirmed that the exploit kit was also exploiting the same vulnerability. CVE-2019-1367 was first discovered by Google Threat Analysis Group and is known as a vulnerability that occurs in jscript.dll of the IE script engine. In October 2019, Microsoft released a security update to address the vulnerability.

At the same time, the newest version of Magniber has undergone additional changes, such as changing the API factor or changing the ransomware injection process, as shown in Figure 1 and Figure 2. This change was insignificant compared to the change in the exploited vulnerability that occurred in February this year. It can be assumed that the decision to change the vulnerability was to hide the ransomware process and bypass the detection of security solutions, such as anti-virus solutions.

Figure 1. Attack Flow Diagram of Magniber, September 2019 (09/19/2019)

Figure 2. Attack Flow Diagram of Magniber, November 2019 (11/11/2019)

Figure 3. Attack Flow Diagram of Magniber, February 2020 (02/18/2020)

1. Changes in Attack Method

Changes in the vulnerability exploited, and the attack flow occurred in February 2020. Figure 4 shows the HTML script that is downloaded upon connecting to the newest Magniber distribution website with all versions before and after the change encoded.

Figure 4. Encoded CVE-2019-1367 Vulnerability Script

Upon decoding the encoded script, as shown in Figure 4, the script that exploits CVE-2019-1367 vulnerability appears, as shown in Figure 5. Like the previous methods, CVE-2019-1367 script, which is distributed by Magnitude Exploit Kit, uses the same technique to obfuscate both variable name and shellcode. One notable change is that JavaScript (JS) engine vulnerability (CVE-2019-1367) was used instead of the Visual Basic Script (VBS) engine vulnerability (CVE-2018-8174).

Figure 5. Decoded CVE-2019-1367 Vulnerability Script

2. Analysis of CVE-2019-1367 Vulnerability

CVE-2019-1367 vulnerability is a Use After Free (UAF) vulnerability that occurs when the garbage collector of the Sort method, which is the callback function of JavaScript array object, fails to free the factor that was sent to the argument object.

Figure 6 shows a decoded portion of the CVE-2019-1367 vulnerability of Magnitude Exploit Kit, and the order of the activity is demonstrated in numbers to explain why this vulnerability occurs.

First, when the script code is executed (1) the UAF callback function is called by sort method of u array object. Afterward, (2) argument object from the callback function is saved into the t array object, and (3) mass number of spray objects are pre-assigned for UAF vulnerability

Figure 6. Magnitude Exploit Distribution Script (CVE-2019-1367)

In (4), the t object refers to the p object. After (5), p object, along with spray object, becomes memory-disabled by the garbage collector. However, because the garbage collector could not disable the argument object, the t object (arguments) becomes a dangling pointer. Figure 7 shows the overall summary of this process.

Figure 7. Summary of UAF (Use After Free) Process

In the (6) of Figure 7, 1 is assigned to B property of v object, and as a result, specially modified value overwrites the already-disabled memory area where the p object existed. At this moment, regular expression (Regex) object with integer variant type (0x03) is saved to the disabled p object address due to type confusion. Usually, the variant type of a regular expression object must be 0x81, not 0x03. Figure 8 demonstrates memory with a variant type, which is changed by type confusion. Lastly, on (7), t object is saved to q object, and memory modification takes place accordingly.

Figure 8. Variant Type (0x03) Modified by Type Confusion

The attacker grants run property to malware shellcode area (memory), which they aim to run through CVE2019-1367 vulnerability and ramify the execution flow in shellcode. As shown in Figure 9, the attacker also changed the factor value of VirtualProtect function, which is API that grants property of memory for a short time. This is a way to bypass the behavior-based detection method of V3, which is AhnLab’s anti-malware solution.

Figure 9. Granting of Run Property to Shellcode (Before and After Change)

3. Shellcode Analysis

The fundamental role of the malicious shellcode is to download ransomware payload, as shown in Figure 10. Through this method, the ransomware is not created as a file form within the system, but rather, as an encoded form in the IE process memory area.

Figure 10. Function of Shellcode 1 – Downloading Encoded Ransomware Payload

The second role of the shellcode is to decode the ransomware, and as shown in Figure 11, a customized XOR method is utilized. Only the variable that is affected by the size of the downloaded payload is changed, and the attacker continues to use the decoding method mentioned above.

Figure 11. Function of Shellcode 2 – Decoding Ransomware

The third role of the currently distributed shellcode is injecting the ransomware into the running user process. The injected process then proceeds with file encryption. This is the most recently confirmed change. As shown in Figure 12, if a process related to AhnLab’s V3, called ASDSvc.exe, exists, a code will be added to skip the process of self-injection. This is another way to prevent the detection of V3.

Figure 12. Function of Shellcode 3 – Injecting Ransomware to User Process

Conclusion

This analysis report covered the significant changes made to the latest Magniber Ransomware. The most notable change is that the exploited vulnerability has been changed.

In the past, Magnitude Exploit Kit, which is responsible for distributing Magniber Ransomware, used the vulnerability of VBS engine called CVE-2018-8174 within weeks of its exposure. Moreover, at the end of January this year, Magniber utilized PoC of a vulnerability of JS(CVE-2019-1367) within two weeks of its exposure. This means that Magniber does not hesitate to abuse newly discovered vulnerability of programs, such as IE and Flash Player, to advance their attack methods.

Users must apply the latest security update of all software and applications to prevent and minimize damage caused by cybersecurity attacks. For security administrators, it is equally important to develop and implement efficient methods to keep track of all PC and endpoints to reduce the attack surface.

Categories:Malware Information

Tagged as:

0 0 votes
Article Rating
guest

0 Comments
Inline Feedbacks
View all comments