{ "id": "5c33a077-9d0c-420e-9f5d-63c42786d955", "created_at": "2026-04-06T00:15:09.26064Z", "updated_at": "2026-04-10T03:36:13.906841Z", "deleted_at": null, "sha1_hash": "286490611018cd6b270b8d04ec1ae651ababff5e", "title": "Magnitude Exploit Kit: Still Alive and Kicking", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 3994816, "plain_text": "Magnitude Exploit Kit: Still Alive and Kicking\r\nBy Threat Research TeamThreat Research Team\r\nArchived: 2026-04-05 17:01:39 UTC\r\nIf I could choose one computer program and erase it from existence, I would choose Internet Explorer. Switching\r\nto a different browser would most likely save countless people from getting hacked. Not to mention all the\r\nheadaches that web developers get when they are tasked with solving Internet Explorer compatibility issues.\r\nUnfortunately, I do not have the power to make Internet Explorer disappear. But seeing its browser market share\r\ncontinue to decline year after year at least gives me hope that one day it will be only a part of history.\r\nWhile the overall trend looks encouraging, there are still some countries where the decline in Internet Explorer\r\nusage is lagging behind. An interesting example of this is South Korea, where until recently, users often had no\r\nchoice but to use this browser if they wanted to visit a government or an e-commerce website. This was because\r\nof a law that seems very bizarre from today’s point of view: these websites were required to use ActiveX controls\r\nand were therefore only supported in Internet Explorer. Ironically, these controls were originally meant to provide\r\nadditional security. While this law was finally dismantled in December 2020, Internet Explorer still has a lot of\r\nmomentum in South Korea today. \r\nThe attackers behind the Magnitude Exploit Kit (or Magniťůdek as we like to call it) are exploiting this\r\nmomentum by running malicious ads that are currently shown only to South Korean Internet Explorer users. The\r\nads can mostly be found on adult websites, which makes this an example of so-called adult malvertising. They\r\ncontain code that exploits known vulnerabilities in order to give the attackers control over the victim’s computer.\r\nAll the victim has to do is use a vulnerable version of Microsoft Windows and Internet Explorer, navigate to a\r\npage that hosts one of these ads and they will get the Magniber ransomware encrypting their computer.\r\nThe daily amount of Avast users protected from Magnitude. Note the drop after July 9th, which is when the\r\nattacker’s account at one of the abused ad networks got terminated.\r\nOverview\r\nThe Magnitude exploit kit, originally known as PopAds, has been around since at least 2012, which is an\r\nunusually long lifetime for an exploit kit. However, it’s not the same exploit kit today that it was nine years ago.\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 1 of 14\n\nPretty much every part of Magnitude has changed multiple times since then. The infrastructure has changed, so\r\nhas the landing page, the shellcode, the obfuscation, the payload, and most importantly, the exploits. Magnitude\r\ncurrently exploits an Internet Explorer memory corruption vulnerability, CVE-2021-26411, to get shellcode\r\nexecution inside the renderer process and a Windows memory corruption vulnerability, CVE-2020-0986, to\r\nsubsequently elevate privileges. A fully functional exploit for CVE-2021-26411 can be found on the Internet and\r\nMagnitude uses that public exploit directly, just with some added obfuscation on top. According to the South\r\nKorean cybersecurity company ENKI, this CVE was first used in a targeted attack against security researchers,\r\nwhich Google’s Threat Analysis Group attributed to North Korea.\r\nExploiting CVE-2020-0986 is a bit less straightforward. This vulnerability was first used in a zero-day exploit\r\nchain, discovered in-the-wild by Kaspersky researchers who named the attack Operation PowerFall. To the best of\r\nour knowledge, this is the first time this vulnerability is being exploited in-the-wild since that attack. Details about\r\nthe vulnerability were provided in blog posts by both Kaspersky and Project Zero. While both these writeups\r\ncontain chunks of the exploit code, it must have still been a lot of work to develop a fully functional exploit. Since\r\nthe exploit from Magnitude is extremely similar to the code from the writeups, we believe that the attackers\r\nstarted from the code provided in the writeup and then added all the missing pieces to get a working exploit.\r\nInterestingly, when we first discovered Magnitude exploiting CVE-2020-0986, it was not weaponized with any\r\nmalicious payload. All it did after successful exploitation was ping its C\u0026C server with the Windows build\r\nnumber of the victim. At the time, we theorized that this was just a testing version of the exploit and the attackers\r\nwere trying to figure out which builds of Windows they could exploit before they fully integrated it into the\r\nexploit kit. And indeed, a week later we saw an improved version of the exploit and this time, it was carrying the\r\nMagniber ransomware as the payload.\r\nUntil recently, our detections for Magnitude were protecting on average about a thousand Avast users per day.\r\nThat number dropped to roughly half after the compliance team of one of the ad networks used by Magnitude\r\nkicked the attackers out of their platform. Currently, all the protected users have a South Korean IP address, but\r\njust a few weeks back, Taiwanese Internet users were also at risk. Historically, South Korea and Taiwan were not\r\nthe only countries attacked by Magnitude. Previous reports mention that Magnitude also used to target Hong\r\nKong, Singapore, the USA, and Malaysia, among others. \r\nThe Infrastructure\r\nThe Magnitude operators are currently buying popunder ads from multiple adult ad networks. Unfortunately, these\r\nad networks allow them to very precisely target the ads to users who are likely to be vulnerable to the exploits\r\nthey are using. They can only pay for ads shown to South Korean Internet Explorer users who are running selected\r\nversions of Microsoft Windows. This means that a large portion of users targeted by the ads is vulnerable and that\r\nthe attackers do not have to waste much money on buying ads for users that they are unable to exploit. We reached\r\nout to the relevant ad networks to let them know about the abuse of their platforms. One of them successfully\r\nterminated the attacker’s account, which resulted in a clear drop in the number of Avast users that we had to\r\nprotect from Magnitude every day.\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 2 of 14\n\nMany ad networks allow the advertisers to target their ads only to IE users running specific versions of Windows.\r\nWhen the malicious ad is shown to a victim, it redirects them through an intermediary URL to a page that serves\r\nan exploit for CVE-2021-26411. An example of this redirect chain is binlo[.]info -\u003e\r\nfab9z1g6f74k.tooharm[.]xyz -\u003e 6za16cb90r370m4u1ez.burytie[.]top . The first domain, binlo[.]info , is\r\nthe one that is visible to the ad network. When this domain is visited by someone not targeted by the campaign, it\r\njust presents a legitimate-looking decoy ad. We believe that the purpose of this decoy ad is to make the\r\nmalvertising seem legitimate to the ad network. If someone from the ad network were to verify the ad, they would\r\nonly see the decoy and most likely conclude that it is legitimate.\r\nOne of the decoy ads used by Magnitude. Note that this is nothing but a decoy: there is no reason to believe that\r\nSkinMedica would be in any way affiliated with Magnitude.\r\nThe other two domains ( tooharm[.]xyz and burytie[.]top ) are designed to be extremely short-lived. In fact,\r\nthe exploit kit rotates these domains every thirty minutes and doesn’t reuse them in any way. This means that the\r\nexploit kit operators need to register at least 96 domains every day! In addition to that, the subdomains\r\n( fab9z1g6f74k.tooharm[.]xyz and 6za16cb90r370m4u1ez.burytie[.]top ) are uniquely generated per victim.\r\nThis makes the exploit kit harder to track and protect against (and more resilient against takedowns) because\r\ndetection based on domain names is not very effective.\r\nThe JavaScript exploit for CVE-2021-26411 is obfuscated with what appears to be a custom obfuscator. The\r\nobfuscator is being updated semi-regularly, most likely in an attempt to evade signature-based detection. The\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 3 of 14\n\nobfuscator is polymorphic, so each victim gets a uniquely obfuscated exploit. Other than that, there are not many\r\ninteresting things to say about the obfuscation, it does the usual things like hiding string/numeric constants,\r\nrenaming function names, hiding function calls, and more. \r\nA snippet of the obfuscated JavaScript exploit for CVE-2021-26411\r\nAfter deobfuscation, this exploit is an almost exact match to a public exploit for CVE-2021-26411 that is freely\r\navailable on the Internet. The only important change is in the shellcode, where Magnitude obviously provides its\r\nown payload. \r\nShellcode\r\nThe shellcode is sometimes wrapped in a simple packer that uses redundant jmp instructions for obfuscation.\r\nThis obfuscates every function by randomizing the order of instructions and then adding a jmp instruction\r\nbetween each two consecutive instructions to preserve the original control flow. As with other parts of the\r\nshellcode, the order is randomly generated on the fly, so each victim gets a unique copy of the shellcode.\r\nFunction obfuscated by redundant jmp instructions. It allocates memory by invoking the\r\nNtAllocateVirtualMemory syscall.\r\nAs shown in the above screenshot, the exploit kit prefers not to use standard Windows API functions and instead\r\noften invokes system calls directly. The function above uses the NtAllocateVirtualMemory syscall to allocate\r\nmemory. However, note that this exact implementation only works on Windows 10 under the WoW64 subsystem.\r\nOn other versions of Windows, the syscall numbers are different, so the syscall number 0x18 would denote some\r\nother syscall. And this exact implementation also wouldn’t work on native 32-bit Windows, because there it does\r\nnot make sense to call the FastSysCall pointer at FS:[0xC0] . \r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 4 of 14\n\nTo get around these problems, this shellcode comes in several variants, each custom-built for a specific version of\r\nWindows. Each variant then contains hardcoded syscall numbers fitting the targeted version. Magnitude selects\r\nthe correct shellcode variant based on the User-Agent string of the victim. But sometimes, knowing the major\r\nrelease version and bitness of Windows is not enough to deduce the correct syscall numbers. For instance, the\r\nsyscall number for NtOpenProcessToken on 64-bit Windows 10 differs between versions 1909 and 20H2 . In\r\nsuch cases, the shellcode obtains the victim’s exact NtBuildNumber from KUSER_SHARED_DATA and uses a\r\nhardcoded mapping table to resolve that build number into the correct syscall number. \r\nCurrently, there are only three variants of the shellcode. One for Windows 10 64-bit, one for Windows 7 64-bit,\r\nand one for Windows 7 32-bit. However, it is very much possible that additional variants will get implemented in\r\nthe future.\r\nTo facilitate frequent syscall invocation, the shellcode makes use of what we call syscall templates. Below, you\r\ncan see the syscall template it uses in the WoW64 Windows 10 variant. Every time the shellcode is about to\r\ninvoke a syscall, it first customizes this template for the syscall it intends to invoke by patching the syscall number\r\n(the immediate in the first instruction) and the immediates from the retn instructions (which specify the number\r\nof bytes to release from the stack on function return). Once the template is customized, the shellcode can call it\r\nand it will invoke the desired syscall. Also, note the branching based on the value at offset 0x254 of the Process\r\nEnvironment Block. This is most likely the malware authors trying to check a field sometimes called\r\ndwSystemCallMode to find out if the syscall should be invoked directly using int 0x2e or through the\r\nFastSysCall transition.\r\nSyscall template from the WoW64 Windows 10 variant\r\nNow that we know how the shellcode is obfuscated and how it invokes syscalls, let’s get to what it actually does.\r\nNote that the shellcode expects to run within the IE’s Enhanced Protected Mode (EPM) sandbox, so it is relatively\r\nlimited in what it can do. However, the EPM sandbox is not as strict as it could be, which means that the shellcode\r\nstill has limited filesystem access, public network access and can successfully call many API functions. Magnitude\r\nwants to get around the restrictions imposed by the sandbox and so the shellcode primarily functions as a\r\npreparation stage for the LPE exploit which is intended to enable Magnitude to break out of the sandbox.\r\nThe first thing the shellcode does is that it obtains the integrity level of the current process. There are two URLs\r\nembedded in the shellcode and the integrity level is used to determine which one should be used. Both URLs\r\ncontain a subdomain that is generated uniquely per victim and are protected so that only the intended victim will\r\nget any response from them. If the integrity level is Low or Untrusted , the shellcode reaches out to the first\r\nURL and downloads an encrypted LPE exploit from there. The exploit is then decrypted using a simple xor-based\r\ncipher, mapped into executable memory, and executed.\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 5 of 14\n\nOn the other hand, if the integrity level is Medium or higher, the shellcode determines that it is not running in a\r\nsandbox and it skips the LPE exploit. In such cases, it downloads the final payload (currently Magniber\r\nransomware) from the second URL, decrypts it, and then starts searching for a process that it could inject this\r\npayload into. For the 64-bit Windows shellcode variants, the target process needs to satisfy all of the following\r\nconditions:\r\nThe target process name is not iexplore.exe\r\nThe integrity level of the target process is not Low or Untrusted\r\nThe integrity level of the target process is not higher than the integrity level of the current process\r\nThe target process is not running in the WoW64 environment\r\n(The target process can be opened with PROCESS_QUERY_INFORMATION )\r\nOnce a suitable target process is found, the shellcode jumps through the Heaven’s Gate (only in the WoW64\r\nvariants) and injects the payload into the target process using the following sequence of syscalls: NtOpenProcess\r\n-\u003e NtCreateSection -\u003e NtMapViewOfSection -\u003e NtCreateThreadEx -\u003e NtGetContextThread -\u003e\r\nNtSetContextThread -\u003e NtResumeThread . Note that in this execution chain, everything happens purely in\r\nmemory and this is why Magnitude is often described as a fileless exploit kit. However, the current version is not\r\nentirely fileless because, as will be shown in the next section, the LPE exploit drops a helper PE file to the\r\nfilesystem.\r\nThe shellcode’s transition through the heaven’s gate\r\nCVE-2020-0986\r\nMagnitude escapes the EPM sandbox by exploiting CVE-2020-0986, a memory corruption vulnerability in\r\nsplwow64.exe . Since the vulnerable code is running with medium integrity and a low integrity process can\r\ntrigger it using Local Procedure Calls (LPC), this vulnerability can be used to get from the EPM sandbox to\r\nmedium integrity. CVE-2020-0986 and the ways to exploit it are already discussed in detail in blog posts by both\r\nKaspersky and Project Zero. This section will therefore focus on Magnitude’s implementation of the exploit,\r\nplease refer to the other blog posts for further technical details about the vulnerability. \r\nThe vulnerable code from gdi32.dll can be seen below. It is a part of an LPC server and it can be triggered by\r\nan LPC call, with both r8 and rdi pointing into a memory section that is shared between the LPC client and\r\nthe LPC server. This essentially gives the attacker the ability to call memcpy inside the splwow64 process while\r\nhaving control over all three arguments, which can be immediately converted into an arbitrary read/write\r\nprimitive. Arbitrary read is just a call to memcpy with the dest being inside the shared memory and src being\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 6 of 14\n\nthe target address. Conversely, arbitrary write is a call to memcpy with the dest being the target address and the\r\nsrc being in the shared memory.\r\nThe vulnerable code from gdi32.dll. When it gets executed, both r8 and rdi are pointing into attacker-controllable\r\nmemory.\r\nHowever, there is one tiny problem that makes exploitation a bit more difficult. As can be seen in the\r\ndisassembled code above, the count of the memcpy is obtained by adding the dereferenced content of two word\r\npointers, located close by the src address. This is not a problem for (smaller) arbitrary writes, since the attacker\r\ncan just plant the desired count beforehand into the shared memory. But for arbitrary reads, the count is not\r\ndirectly controllable by the attacker and it can be anywhere between 0 and 0x1FFFE , which could either crash\r\nsplwow64 or perform a memcpy with either zero or a smaller than desired count . To get around this, the\r\nattacker can perform arbitrary reads by triggering the vulnerable code twice. The first time, the vulnerability can\r\nbe used as an arbitrary write to plant the correct count at the necessary offset and the second time, it can be used\r\nto actually read the desired memory content. This technique has some downsides, such as that it cannot be used to\r\nread non-writable memory, but that is not an issue for Magnitude.\r\nThe exploit starts out by creating a named mutex to make sure that there is only a single instance of it running.\r\nThen, it calls CreateDCW to spawn the splwow64 process that is to be exploited and performs all the necessary\r\npreparations to enable sending LPC messages to it later on. The exploit also contains an embedded 64-bit PE file,\r\nwhich it drops to %TEMP% and executes from there. This PE file serves two different purposes and decides which\r\none to fulfill based on whether there is a command-line argument or not. The first purpose is to gather various 64-\r\nbit pointers and feed them back to the main exploit module. The second purpose is to serve as a loader for the final\r\npayload once the vulnerability has been successfully exploited.\r\nThere are three pointers that are obtained by the dropped 64-bit PE file when it runs for the first time. The first one\r\nis the address of fpDocumentEvent , which stores a pointer to DocumentEvent , protected using the\r\nEncodePointer function. This pointer is obtained by scanning gdi32.dll (or gdi32full.dll ) for a static\r\nsequence of instructions that set the value at this address. The second pointer is the actual address of\r\nDocumentEvent , as exported from winspool.drv and the third one is the pointer to system , exported from\r\nmsvcrt.dll . Once the 64-bit module has all three pointers, it drops them into a temporary file and terminates\r\nitself.\r\nThe exploit scans gdi32.dll for the sequence of the four underlined instructions and extracts the address of\r\nfpDocumentEvent from the operands of the last instruction.\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 7 of 14\n\nThe exploit extracting the address of fpDocumentEvent from gdi32.dll\r\nThe main 32-bit module then reads the dropped file and uses the obtained values during the actual exploitation,\r\nwhich can be characterized by the following sequence of actions:\r\n1. The exploit leaks the value at the address of fpDocumentEvent in the splwow64 process. The value is\r\nleaked by sending two LPC messages, using the arbitrary read primitive described above.\r\n2. The leaked value is an encoded pointer to DocumentEvent . Using this encoded pointer and the actual, raw,\r\npointer to DocumentEvent , the exploit cracks the secret value that was used for pointer encoding. Read the\r\nKaspersky blog post for how this can be done.\r\n3. Using the obtained secret value, the exploit encodes the pointer to system , so that calling the function\r\nDecodePointer on this newly encoded value inside splwow64 will yield the raw pointer to system .\r\n4. Using the arbitrary write primitive, the exploit overwrites fpDocumentEvent with the encoded pointer to\r\nsystem .\r\n5. The exploit triggers the vulnerable code one more time. Only this time, it is not interested in any memory\r\ncopying, so it sets the count for memcpy to zero. Instead, it counts on the fact that splwow64 will try to\r\ndecode and call the pointer at fpDocumentEvent . Since this pointer was substituted in the previous step,\r\nsplwow64 will call system instead of DocumentEvent . The first argument to DocumentEvent is read\r\nfrom the shared memory section, which means that it is controllable by the attacker, who can therefore pass\r\nan arbitrary command to system . \r\n6. Finally, the exploit uses the arbitrary write primitive one last time and restores fpDocumentEvent to its\r\noriginal value. This is an attempt to clean up after the exploit, but splwow64 might still be unstable\r\nbecause a random pointer got corrupted when the exploit planted the necessary count of the leak during\r\nthe first step.\r\nThe exploit cracking the secret used for encoding fpDocumentEvent\r\nThe command that Magnitude executes in the call to system looks like this:\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 8 of 14\n\nicacls \u003cdropped_64bit_PE\u003e /Q /C /setintegritylevel Medium \u0026\u0026 \u003cdropped_64bit_PE\u003e\r\nThis elevates the dropped 64-bit PE file to medium integrity and executes it for the second time. This time, it will\r\nnot gather any pointers, but it will instead extract an embedded payload from within itself and inject it into a\r\nsuitable process. Currently, the injected payload is the Magniber ransomware.\r\nMagniber\r\nMagniber emerged in 2017 when Magnitude started deploying it as a replacement for the Cerber ransomware.\r\nEven though it is almost four years old, it still gets updated frequently and so a lot has changed since it was last\r\nwritten about. The early versions featured server-side AES key generation and contained constant fallback\r\nencryption keys in case the server was unreachable. A decryptor that worked when encryption was performed\r\nusing these fallback keys was developed by the Korea Internet \u0026 Security Agency and published on No More\r\nRansom. The attackers responded to this by updating Magniber to generate the encryption keys locally, but the\r\ncustom PRNG based on GetTickCount was very weak, so researchers from Kookmin University were able to\r\ndevelop a method to recover the encrypted files. Unfortunately, Magniber got updated again, and it is currently\r\nusing the custom PRNG shown below. This function is used to generate a single random byte and it is called 32\r\ntimes per encrypted file (16 times to generate the AES-128 key and 16 times to generate the IV). \r\nWhile this PRNG still looks very weak at first glance, we believe there is no reasonably efficient method to attack\r\nit. The tick count is not the problem here: it is with extremely high probability going to be constant throughout all\r\niterations of the loop and its value could be guessed by inspecting event logs and timestamps of the encrypted\r\nfiles. The problem lies in the RtlRandomEx function, which gets called 640 times (2 * 10 * (16 + 16)) per each\r\nencrypted file. This means that the function is likely going to get called millions of times during encryption and\r\nleaking and tracking its internal state throughout all of these calls unfortunately seems infeasible. At best, it might\r\nbe possible to decrypt the first few encrypted files. And even that wouldn’t be possible on newer CPUs and\r\nWindows versions, because RtlRandomEx there internally uses the rdrand instruction, which arguably makes\r\nthis a somewhat decent PRNG for cryptography. \r\nThe PRNG used by Magniber to generate encryption keys\r\nThe ransomware starts out by creating a named mutex and generating an identifier from the victim’s computer\r\nname and volume serial number. Then, it enumerates in random order all logical drives that are not\r\nDRIVE_NO_ROOT_DIR or DRIVE_CDROM and proceeds to recursively traverse them to encrypt individual files. Some\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 9 of 14\n\nfolders, such as sample music or tor browser , are excluded from encryption, same as all hidden, system,\r\nreadonly, temporary, and virtual files. The full list of excluded folders can be found in our IoC repository.\r\nJust like many other ransomware strains, Magniber only encrypts files with certain preselected extensions, such as\r\n.doc or .xls . Its configuration contains two sets of extension hashes and each file gets encrypted only if the\r\nhash of its extension can be found in one of these sets. The division into two sets was presumably done to assign\r\npriority to the extensions. Magniber goes through the whole filesystem in two sweeps. In the first one, it encrypts\r\nfiles with extensions from the higher-priority set. In the second sweep, it encrypts the rest of the files with\r\nextensions from the lower-priority set. Interestingly, the higher-priority set also contains nine extensions that were\r\nadditionally obfuscated, unlike the rest of the higher-priority set. It seems that the attackers were trying to hide\r\nthese extensions from reverse engineers. You can find these and the other extensions that Magniber encrypts in our\r\nIoC repository.\r\nTo encrypt a file, Magniber first generates a random 128-bit AES key and IV using the PRNG discussed above.\r\nFor some bizarre reason, it only chooses to generate bytes from the range 0x03 to 0xFC , effectively reducing\r\nthe size of the keyspace from 25616 to 25016. Magniber then reads the input file by chunks of up to 0x100000\r\nbytes, continuously encrypting each chunk in CBC mode and writing it back to the input file. Once the whole file\r\nis encrypted, Magniber also encrypts the AES key and IV using a public RSA key embedded in the sample and\r\nappends the result to the encrypted file. Finally, Magniber renames the file by appending a random-looking\r\nextension to its name.\r\nHowever, there is a bug in the encryption process that puts some encrypted files into a nonrecoverable state, where\r\nit is impossible to decrypt them, even for the attackers who possess the corresponding private RSA key. This bug\r\naffects all files with a size that is a multiple of 0x100000 (1 MiB). To understand this bug, let’s first investigate in\r\nmore detail how individual files get encrypted. Magniber splits the input file into chunks and treats the last chunk\r\ndifferently. When the last chunk is encrypted, Magniber sets the Final parameter of CryptEncrypt to TRUE ,\r\nso CryptoAPI can add padding and finalize the encryption. Only after the last chunk gets encrypted does\r\nMagniber append the RSA-encrypted AES key to the file. \r\nThe bug lies in how Magniber determines that it is currently encrypting the last chunk: it treats only chunks of size\r\nless than 0x100000 as the last chunks. But this does not work for files the size of which is a multiple of\r\n0x100000 , because even the last chunk of such files contains exactly 0x100000 bytes. When Magniber is\r\nencrypting such files, it never registers that it is encrypting the last chunk, which causes two problems. The first\r\nproblem is that it never calls CryptEncrypt with Final=TRUE , so the encrypted files end up with invalid\r\npadding. The second, much bigger, problem is that Magniber also does not append the RSA-encrypted AES key,\r\nbecause the trigger for appending it is the encryption of the last chunk. This means that the AES key and IV used\r\nfor the encryption of the file get lost and there is no way to decrypt the file without them.\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 10 of 14\n\nMagniber’s ransom note\r\nMagniber drops its ransom note into every folder where it encrypted at least one file. An extra ransom note is also\r\ndropped into %PUBLIC% and opened up automatically in notepad.exe after encryption. The ransom note\r\ncontains several URLs leading the victims to the payment page, which instructs them on how to pay the ransom in\r\norder to obtain the decryptor. These URLs are unique per victim, with the subdomain representing the victim\r\nidentifier. Magniber also automatically opens up the payment page in the victim’s browser and while doing so,\r\nexfiltrates further information about the ransomware deployment through the URL, such as:\r\nThe number of encrypted files\r\nThe total size of all encrypted files\r\nThe number of encrypted logical drives\r\nThe number of files encountered (encrypted or not)\r\nThe version of Windows\r\nThe victim identifier\r\nThe version of Magniber\r\nFinally, Magniber attempts to delete shadow copies using a UAC bypass. It writes a command to delete them to\r\nHKCU\\Software\\Classes\\mscfile\\shell\\open\\command and then executes CompMgmtLauncher.exe assuming that\r\nthis will run the command with elevated privileges. But since this particular UAC bypass method was fixed in\r\nWindows 10, Magniber also contains another bypass method, which it uses exclusively on Windows 10 machines.\r\nThis other method works similarly, writing the command to HKCU\\Software\\Classes\\ms-settings\\shell\\open\\command , creating a key named DelegateExecute there, and finally running\r\nComputerDefaults.exe . Interestingly, the command used is regsvr32.exe scrobj.dll /s /u /n\r\n/i:%PUBLIC%\\readme.txt . This is a technique often referred to as Squiblydoo and it is used to run a script\r\ndropped into readme.txt , which is shown below.\r\nThe scriptlet dropped to readme.txt, designed to delete shadow copies\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 11 of 14\n\nConclusion\r\nIn this blog post, we examined in detail the current state of the Magnitude exploit kit. We described how it\r\nexploits CVE-2021-26411 and CVE-2020-0986 to deploy ransomware to unfortunate victims who browse the\r\nInternet using vulnerable builds of Internet Explorer. We found Magnitude to be a mature exploit kit with a very\r\nrobust infrastructure. It uses thousands of fresh domains each month and its infection chain is composed of seven\r\nstages (not even counting the multiple obfuscation layers). The infrastructure is also well protected, which makes\r\nit very challenging for malware analysts to track and research the exploit kit.\r\nWe also dug deep into the Magniber ransomware. We found a bug that results in some files being encrypted in\r\nsuch a way that even the attackers can not possibly decrypt them. This underscores the unfortunate fact that\r\npaying the ransom is never a guarantee to get the ransomed files back. This is one of the reasons why we urge\r\nransomware victims to try to avoid paying the ransom. \r\nEven though the attackers behind Magnitude appear to have a good grasp on exploit development, obfuscation,\r\nand protection of malicious infrastructure, they seem to have no idea what they are doing when it comes to\r\ngenerating random numbers for cryptographic purposes. This resulted in previous versions of Magniber using\r\nflawed PRNGs, which allowed malware researchers to develop decryptors that helped victims recover their\r\nransomed files. However, Magniber was always quick to improve their PRNG, which unfortunately made the\r\ndecryptors obsolete. The current version of Magniber is using a PRNG that seems to be just secure enough, which\r\nmakes us believe that there will be no more decryptors in the future.\r\nIndicators of Compromise (IoC)\r\nThe full list of IoCs is available at https://github.com/avast/ioc/tree/master/Magnitude.\r\nRedirection page\r\nCVE-2021-26411\r\nShellcode\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 12 of 14\n\nCVE-2020-0986\r\nPointer scanner/loader 64-bit module\r\nMagniber\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 13 of 14\n\nA group of elite researchers who like to stay under the radar.\r\nSource: https://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nhttps://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/\r\nPage 14 of 14", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://decoded.avast.io/janvojtesek/magnitude-exploit-kit-still-alive-and-kicking/" ], "report_names": [ "magnitude-exploit-kit-still-alive-and-kicking" ], "threat_actors": [ { "id": "f8dddd06-da24-4184-9e24-4c22bdd1cbbf", "created_at": "2023-01-06T13:46:38.626906Z", "updated_at": "2026-04-10T02:00:03.043681Z", "deleted_at": null, "main_name": "Tick", "aliases": [ "G0060", "Stalker Taurus", "PLA Unit 61419", "Swirl Typhoon", "Nian", "BRONZE BUTLER", "REDBALDKNIGHT", "STALKER PANDA" ], "source_name": "MISPGALAXY:Tick", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "c0cedde3-5a9b-430f-9b77-e6568307205e", "created_at": "2022-10-25T16:07:23.528994Z", "updated_at": "2026-04-10T02:00:04.642473Z", "deleted_at": null, "main_name": "DarkHotel", "aliases": [ "APT-C-06", "ATK 52", "CTG-1948", "Dubnium", "Fallout Team", "G0012", "G0126", "Higaisa", "Luder", "Operation DarkHotel", "Operation Daybreak", "Operation Inexsmar", "Operation PowerFall", "Operation The Gh0st Remains the Same", "Purple Pygmy", "SIG25", "Shadow Crane", "T-APT-02", "TieOnJoe", "Tungsten Bridge", "Zigzag Hail" ], "source_name": "ETDA:DarkHotel", "tools": [ "Asruex", "DarkHotel", "DmaUp3.exe", "GreezeBackdoor", "Karba", "Nemain", "Nemim", "Ramsay", "Retro", "Tapaoux", "Trojan.Win32.Karba.e", "Virus.Win32.Pioneer.dx", "igfxext.exe", "msieckc.exe" ], "source_id": "ETDA", "reports": null }, { "id": "54e55585-1025-49d2-9de8-90fc7a631f45", "created_at": "2025-08-07T02:03:24.563488Z", "updated_at": "2026-04-10T02:00:03.715427Z", "deleted_at": null, "main_name": "BRONZE BUTLER", "aliases": [ "CTG-2006 ", "Daserf", "Stalker Panda ", "Swirl Typhoon ", "Tick " ], "source_name": "Secureworks:BRONZE BUTLER", "tools": [ "ABK", "BBK", "Casper", "DGet", "Daserf", "Datper", "Ghostdown", "Gofarer", "MSGet", "Mimikatz", "Netboy", "RarStar", "Screen Capture Tool", "ShadowPad", "ShadowPy", "T-SMB", "down_new", "gsecdump" ], "source_id": "Secureworks", "reports": null }, { "id": "d4e7cd9a-2290-4f89-a645-85b9a46d004b", "created_at": "2022-10-25T16:07:23.419513Z", "updated_at": "2026-04-10T02:00:04.591062Z", "deleted_at": null, "main_name": "Bronze Butler", "aliases": [ "Bronze Butler", "CTG-2006", "G0060", "Operation ENDTRADE", "RedBaldNight", "Stalker Panda", "Stalker Taurus", "Swirl Typhoon", "TEMP.Tick", "Tick" ], "source_name": "ETDA:Bronze Butler", "tools": [ "8.t Dropper", "8.t RTF exploit builder", "8t_dropper", "9002 RAT", "AngryRebel", "Blogspot", "Daserf", "Datper", "Elirks", "Farfli", "Gh0st RAT", "Ghost RAT", "HOMEUNIX", "HidraQ", "HomamDownloader", "Homux", "Hydraq", "Lilith", "Lilith RAT", "McRAT", "MdmBot", "Mimikatz", "Minzen", "Moudour", "Muirim", "Mydoor", "Nioupale", "PCRat", "POISONPLUG.SHADOW", "Roarur", "RoyalRoad", "ShadowPad Winnti", "ShadowWali", "ShadowWalker", "SymonLoader", "WCE", "Wali", "Windows Credential Editor", "Windows Credentials Editor", "XShellGhost", "XXMM", "gsecdump", "rarstar" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434509, "ts_updated_at": 1775792173, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/286490611018cd6b270b8d04ec1ae651ababff5e.pdf", "text": "https://archive.orkl.eu/286490611018cd6b270b8d04ec1ae651ababff5e.txt", "img": "https://archive.orkl.eu/286490611018cd6b270b8d04ec1ae651ababff5e.jpg" } }