There are new articles available, click to refresh the page.
Yesterday — 4 October 2022Reverse Engineering

Decrypted: MafiaWare666 Ransomware

4 October 2022 at 11:36

Avast releases a MafiaWare666 ransomware decryption tool. MafiaWare666 is also known as JCrypt, RIP Lmao, BrutusptCrypt or Hades.

Skip to how to use the MafiaWare666 ransomware decryptor.

MafiaWare666’s Behavior

MafiaWare666 is a ransomware strain written in C# which doesn’t contain any obfuscation or anti-analysis techniques. It encrypts files using the AES encryption. We discovered a vulnerability in the encryption schema that allows some of the variants to be decrypted without paying the ransom. New or previously unknown samples may encrypt files differently, so they may not be decryptable without further analysis.

The ransomware searches special folder locations (Desktop, Music, Videos, Pictures and Documents) and encrypts files with the following extensions:

3fr 7z accdb ai apk arch00 arw asp aspx asset avi bar bat bay bc6 bc7 big bik bkf bkp blob bsa c cas cdr cer cfr cpp cr2 crt crw cs css csv csv d3dbsp das dazip db0 dba dbf dcr der desc divx dmp dng doc doc docm docx docx dwg dxg epk eps erf esm ff flv forge fos fpk fsh gdb gho h hkdb hkx hplg hpp html hvpl ibank icxs indd index itdb itl itm iwd iwi jpe jpeg jpg js kdb kdc kf layout lbf litemod lrf ltx lvl m2 m3u m4a map mcmeta mdb mdb mdbackup mddata mdf mef menu mkv mlx mov mp3 mp4 mpeg mpqge mrwref ncf nrw ntl odb odc odm odp ods odt odt ogg orf p12 p7b p7c pak pdd pdf pef pem pfx php pk7 pkpass png ppt ppt pptm pptx pptx psd psk pst ptx py qdf qic r3d raf rar raw rb re4 rgss3a rim rofl rtf rw2 rwl sav sb sid sidd sidn sie sis slm sln snx sql sql sr2 srf srw sum svg syncdb t12 t13 tax tor txt upk vb vcf vdf vfs0 vpk vpp_pc vtf w3x wallet wav wb2 wma wmo wmv wotreplay wpd wps x3f xlk xls xls xlsb xlsm xlsx xlsx xml xxx zip zip ztmp

Encrypted files are given a new extension, which varies among the samples.

  • .MafiaWare666
  • .jcrypt
  • .brutusptCrypt
  • .bmcrypt
  • .cyberone
  • .l33ch

The ransomware displays a window with instructions explaining how to pay the ransom, once it completes the encryption process. The instructions tell victims to contact the attacker and pay them in Bitcoin. The ransom price is relatively low, between $50 – $300, although some of the older samples with different names demand much more, up to one Bitcoin, which is around $20,000 at the time of publishing.

Here are some examples of MafiaWare666 ransom notes:

How to use the Avast MafiaWare666 ransomware decryption tool  to decrypt files encrypted by the  ransomware

Follow these steps to decrypt your files:

1) Download the free decryptor

2) Run the executable file. It starts as a wizard, leading you through the configuration of the decryption process.

3) On the initial page, you can read the license information if you want, but you really only need to click “Next”

4) On the next page, select the list of locations you want to be searched and decrypted. By default, it contains a list of all local drives:

5) On the third page, you need to provide a file in its original form and encrypted by the MafiaWare666 ransomware. Enter both names of the files. If you have an encryption password created by a previous run of the decryptor, you can select “I know the password for decrypting files” option:

6) The next page is where the password cracking process takes place. Click “Start” when you are ready to start the process. The password cracking process uses all known MafiaWare666 passwords to determine the right one.

7) Once the password is found, you can proceed to decrypt all the encrypted files on your PC by clicking “Next”.

8) On the final page, you can opt-in to backup your encrypted files. These backups may help if anything goes wrong during the decryption process. This option is on by default, which we recommend. After clicking “Decrypt” the decryption process begins. Let the decryptor work and wait until it finishes decrypting all of your files.

Indicators of Compromise (IoCs):

IoCs are available at https://github.com/avast/ioc/tree/master/MafiaWare666.











The post Decrypted: MafiaWare666 Ransomware appeared first on Avast Threat Labs.

Before yesterdayReverse Engineering

Micropatches for Windows Kerberos Elevation of Privilege (CVE-2022-35756)

30 September 2022 at 11:14


by Mitja Kolsek, the 0patch Team

August 2022 Windows Updates brought a fix for a local privilege escalation in Windows Kerberos, discovered by Nick Landers (@monoxgas) of NetSPI. Nick and James Forshaw (@tiraniddo) presented this vulnerability at the BlackHat USA 2022 conference and subsequently published proof-of-concept scripts. This made it possible for us to create a patch for affected "security-adopted" Windows systems that no longer receive official fixes from Microsoft.

The vulnerability allows an attacker to bypass an integrity check for a security buffer of a PAC structure sent inside attacker's AP-REQ request. The flawed integrity check improperly inspects the security buffer type by comparing it to constant SECBUFFER_TOKEN while ignoring that its value can also include two bit flags in the upper byte. Nick's and James' proof-of-concept adds one such flag to the value, bypassing the integrity check, and can therefore arbitrarily modify the PAC structure - for instance, to claim the requestor is not the actual low-privileged user but a local administrator. According to Microsoft's advisory, "a domain user could use this vulnerability to elevate privileges to a domain admin."

Microsoft assigned this issue CVE-2022-35756 and fixed it by removing the execution branch that led to the bypass. Our micropatch is logically equivalent to Microsoft's:

MODULE_PATH "..\AffectedModules\kerberos.dll_6.1.7601.24545_Win7_32-bit_NoESU\kerberos.dll"
VULN_ID 7492

        push eax                  ;save the original rax value
        mov eax, [ebp-0x14]       ;get the flag location pointer +0x8 for the previous push
        bt dword[eax+0x28], 0x19  ;test the 0x19-th bit
        pop eax                   ;restore original rax value
        jb SKIP                   ;if bit is set, keep the old rcx value
        mov eax, 1                ;if bit is not set, mov 1 into rcx
        ; the value of rax here will be stored to rcx and serve as an argument
        ; in a call to KerbCreateTokenFromTicketEx      



The micropatch was written for the following Versions of Windows with all available Windows Updates installed:

  1. Windows 10 v2004
  2. Windows 10 v1909
  3. Windows 10 v1903
  4. Windows 10 v1809
  5. Windows 10 v1803
  6. Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
  7. Windows Server 2008 R2 without ESU, with year 1 of ESU and with year 2 of ESU
This micropatch has already been distributed to all online 0patch Agents with a PRO or Enterprise license. To obtain the micropatch and have it applied on your computers along with our other micropatches, create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center. For a trial or demo please contact [email protected].

We'd like to thank Nick Landers (@monoxgas) and James Forshaw (@tiraniddo) for publishing their analysis with a proof-of-concept that allowed us to reproduce the vulnerability and create a micropatch. We also encourage security researchers to privately share their analyses with us for micropatching.

Raspberry Robin’s Roshtyak: A Little Lesson in Trickery

22 September 2022 at 10:48

There are various tricks malware authors use to make malware analysts’ jobs more difficult. These tricks include obfuscation techniques to complicate reverse engineering, anti-sandbox techniques to evade sandboxes, packing to bypass static detection, and more. Countless deceptive tricks used by various malware strains in-the-wild have been documented over the years. However, few of these tricks are implemented in a typical piece of malware, despite the many available tricks. 

The subject of this blog post, a backdoor we dubbed Roshtyak, is not your typical piece of malware. Roshtyak is full of tricks. Some are well-known, and some we have never seen before. From a technical perspective, the lengths Roshtyak takes to protect itself are extremely interesting. Roshtyak belongs to one of the best-protected malware strains we have ever seen. We hope by publishing our research and analysis of the malware and its protection tricks we will help fellow researchers recognize and respond to similar tricks, and harden their analysis environments, making them more resistant to the evasion techniques described.

Roshtyak is the DLL backdoor used by Raspberry Robin, a worm spreading through infected removable drives. Raspberry Robin is extremely prevalent. We protected over 550K of our users from the worm this year. Due to its high prevalence, it should be no surprise that we aren’t the only ones taking note of Raspberry Robin. 

Red Canary’s researchers published the first analysis of Raspberry Robin in May 2022. In June, Symantec published a report describing a mining/clipboard hijacking operation, which reportedly made the cybercriminals at least $1.7 million. Symantec did not link the malicious operation to Raspberry Robin. Nevertheless, we assess with high confidence that what they analyzed was Raspberry Robin. This assessment is based on C&C overlaps, strong malware similarity, and coinfections observed in our telemetry. Cybereason, Microsoft, and Cisco published further reports in July/August 2022. Microsoft reported that Raspberry Robin infections led to DEV-0243 (a.k.a Evil Corp) pre-ransomware behavior. We could not confirm this connection using our telemetry. Still, we find it reasonable to believe that the miner payload is not the only way Raspberry Robin infections are being monetized. Other recent reports also hint at a possible connection between Raspberry Robin and Evil Corp.

A map showing the number of users Avast protected from Raspberry Robin

There are many unknowns about Raspberry Robin, despite so many published reports. What are the ultimate objectives behind the malware? Who is responsible for Raspberry Robin? How did it become so prevalent? Unfortunately, we do not have answers to all these questions. However, we can answer an important question we saw asked multiple times: What functionality is hidden inside the heavily obfuscated DLL (or Roshtyak as we call it)? To answer this question, we fully reverse engineered a Roshtyak sample, and present our analysis results in this blog post.


Roshtyak is packed in as many as 14 protective layers, each heavily obfuscated and serving a specific purpose. Some artifacts suggest the layers were originally PE files but were transformed into custom encrypted structures that only the previous layers know how to decrypt and load. Numerous anti-debugger, anti-sandbox, anti-VM, and anti-emulator checks are sprinkled throughout the layers. If one of these checks successfully detects an analysis environment, one of four actions are taken. 

  1. The malware calls TerminateProcess on itself to avoid exhibiting any further malicious behavior and to keep the subsequent layers encrypted.
  2. Roshtyak crashes on purpose. This has the same effect as terminating itself, but it might not be immediately clear if the crash was intentional or because of a bug thanks to Roshtyak’s obfuscated nature.
  3. The malware enters an infinite loop on purpose. Since the loop itself is located in obfuscated code and spans thousands of instructions, it might be hard to determine if the loop is doing something useful or not.
  4. The most interesting case is when the malware reacts to a successful check by unpacking and loading a fake payload. This happens in the eighth layer, which is loaded with dozens of anti-analysis checks. The result of each of these checks is used to modify the value of a global variable. There are two payloads encrypted in the data section of the eighth layer: the real ninth layer and a fake payload. The real ninth layer will get decrypted only if the global variable matches the expected value after all the checks have been performed. If at least one check succeeded in detecting an analysis environment, the global variable’s value will differ from the expected value, causing Roshtyak to unpack and execute the fake payload instead. 
Roshtyak’s obfuscation causes even relatively simple functions to grow into large proportions. This necessitates some custom deobfuscation tooling if one wants to reverse engineer it within a reasonable timeframe.

The fake payload is a BroAssist (a.k.a BrowserAssistant) adware sample. We believe this fake payload was intended to mislead malware analysts into thinking the sample is less interesting than it really is. When a reverse engineer focuses on quickly unpacking a sample, it might look like the whole sample is “just” an obfuscated piece of adware (and a very old one at that), which could cause the analyst to lose interest in digging deeper. And indeed, it turns out that these fake payload shenanigans can be very effective. As can be seen on the screenshot below, it fooled at least one researcher, who misattributed the Raspberry Robin worm, because of the fake BrowserAssistant payload.

A security researcher misattributing Raspberry Robin because of the fake payload. This is not to pick on anyone, we just want to show how easy it is to make a mistake like this given Roshtyak’s trickery and complexity.

The Bag of Tricks

For the sake of keeping this blog post (sort of) short and to the point, let’s get straight into detailing some of the more interesting evasion techniques employed by Roshtyak.

Segment registers

Early in the execution, Roshtyak prefers to use checks that do not require calling any imported functions. If one of these checks is successful, the sample can quietly exit without generating any suspicious API calls. Below is an example where Roshtyak checks the behavior of the gs segment register. The check is designed to be stealthy and the surrounding garbage instructions make it easy to overlook.

A stealthy detection of single-stepping. Only the underscored instructions are useful.

The first idea behind this check is to detect single-stepping. Before the above snippet, the value of cx was initialized to 2. After the pop ecx instruction, Roshtyak checks if cx is still equal to 2. This would be the expected behavior because this value should propagate through the stack and the gs register under normal circumstances. However, a single step event would reset the value of the gs selector, which would result in a different value getting popped into ecx at the end.

But there is more to this check. As a side effect of the two push/pop pairs above, the value of gs is temporarily changed to 2. After this check, Roshtyak enters a loop, counting the number of iterations until the value of gs is no longer 2. The gs selector is also reset after a thread context switch, so the loop essentially counts the number of iterations until a context switch happens. Roshtyak repeats this procedure multiple times, averages out the result, and checks that it belongs to a sensible range for a bare metal execution environment. If the sample runs under a hypervisor or in an emulator, the average number of iterations might fall outside of this range, which allows Roshtyak to detect undesirable execution environments.

Roshtyak also checks that the value of the cs segment register is either 0x1b or 0x23. Here, 0x1b is the expected value when running on native x86 Windows, while 0x23 is the expected value under WoW64.

APC injection through a random ntdll gadget

Roshtyak performs some of its functionality from separate processes. For example, when it communicates with its C&C server, it spawns a new innocent-looking process like regsvr32.exe. Using shared sections, it injects its comms module into the address space of the new process. The injected module is executed via APC injection, using NtQueueApcThreadEx.

Interestingly, the ApcRoutine argument (which marks the target routine to be scheduled for execution) does not point to the entry point of the injected module. Instead, it points to a seemingly random address inside ntdll. Taking a closer look, we see this address was not chosen randomly but that Roshtyak scanned the code section of ntdll for pop r32; ret gadgets (excluding pop esp, because pivoting the stack would be undesirable) and picked one at random to use as the ApcRoutine

A random pop r32; ret gadget used as the entry point for APC injection

Looking at the calling convention for the ApcRoutine reveals what’s going on. The pop instruction makes the stack pointer point to the SystemArgument1 parameter of NtQueueApcThreadEx and so the ret instruction effectively jumps to wherever SystemArgument1 is pointing. This means that by abusing this gadget, Roshtyak can treat SystemArgument1 as the entry point for the purpose of APC injection. This obfuscates the control flow and makes the NtQueueApcThreadEx call look more legitimate. If someone hooks this function and inspects the ApcRoutine argument, the fact that it is pointing into the ntdll code section might be enough to convince them that the call is not malicious.

Checking read/write performance on write-combined memory

In this next check, Roshtyak allocates a large memory buffer with the PAGE_WRITECOMBINE flag. This flag is supposed to modify cache behavior to optimize sequential write performance (at the expense of read performance and possibly memory ordering). Roshtyak uses this to detect if it’s running on a physical machine. It conducts an experiment where it first writes to the allocated buffer and then reads from the allocated buffer, all while measuring the read/write performance using a separate thread as a counter. This experiment is repeated 32 times and the check is passed only if write performance was at least six times higher than read performance most of the times. If the check fails, Roshtyak intentionally selects a wrong RC4 key, which results in failing to properly decrypt the next layer.

Hiding shellcode from plain sight

The injected shellcode is interestingly hidden, too. When Roshtyak prepares for code injection, it first creates a large section and maps it into the current process as PAGE_READWRITE. Then, it fills the section with random data and places the shellcode at a random offset within the random data. Since the shellcode is just a relatively small loader followed by random-looking packed data, the whole section looks like random data. 

A histogram of the bytes inside the shared section. Note that it looks almost random, the most suspicious sign is the slight overrepresentation of null bytes.

The section is then unmapped from the current process and mapped into the target process, where it is executed using the above-described APC injection technique. The random data was added in an attempt to conceal the existence of the shellcode. Judging only from the memory dump of the target process, it might look like the section is full of random data and does not contain any valid executable code. Even if one suspects actual valid code somewhere in the middle of the section, it will not be easy to find its exact location. 

The start of the shellcode within the shared section. It might be hard to pinpoint the exact start address because it unconventionally starts on an odd bt instruction.


Roshtyak makes a point of cleaning up after itself. Whenever a certain string or piece of memory is no longer needed, Roshtyak wipes and/or frees it in an attempt to destroy as much evidence as possible. The same holds for Roshtyak’s layers. Whenever one layer finishes its job, it frees itself before passing execution onto the next layer. However, the layer cannot just simply free itself directly. The whole process would crash if it called VirtualFree on the region of memory it’s currently executing from.

Roshtyak, therefore, frees the layer through a ROP chain executed during layer transitions to avoid this problem. When a layer is about to exit, it constructs a ROP chain on the stack and returns into it. An example of such a ROP chain can be seen below. This chain starts by returning into VirtualFree and UnmapViewOfFile to release the previous layer’s memory. Then, it returns into the next layer. The return address from the next layer is set to RtlExitUserThread, to safeguard execution.

A simple ROP chain consisting of VirtualFree -> UnmapViewOfFile -> next layer -> RtlExitUserThread

MulDiv bug

MulDiv is a function exported by kernel32.dll, which takes three signed 32-bit integers as arguments. It multiplies the first two arguments, divides the multiplication result by the third argument, and returns the final result rounded to the nearest integer. While this might seem like a simple enough function, there’s an ancient sign extension bug in Microsoft’s implementation. This bug is sort of considered a feature now and might never get fixed.

Roshtyak is aware of the bug and tests for its presence by calling MulDiv(1, 0x80000000, 0x80000000). On real Windows machines, this triggers the bug and MulDiv erroneously returns 2, even though the correct return value should be 1, because (1 * -2147483648) / -2147483648 = 1. This allows Roshtyak to detect emulators that do not replicate the bug. For example, this successfully detects Wine, which, funnily enough, contains a different bug, which makes the above call return 0.

Tampering with return addresses stored on the stack

There are also tricks designed to obfuscate function calls. As shown in the previous section, Roshtyak likes to call functions using the ret instruction. This next trick is similar in that it also manipulates the stack so a ret instruction can be used to jump to the desired address. 

To achieve this, Roshtyak scans the current thread’s stack for pointers into the code section of one of the previous layers (unlike the other layers, this one was not freed using the ROP chain technique). It replaces all these pointers with the address it wants to call. Then it lets the code return multiple times until a ret instruction encounters one of the hijacked pointers, redirecting the execution to the desired address.

Exception-based checks

Additionally, Roshtyak contains checks that set up a custom vectored exception handler and intentionally trigger various exceptions to ensure they all get handled as expected.

Roshtyak sets up a vectored exception handler using RtlAddVectoredExceptionHandler. This handler contains custom handlers for selected exception codes. A top-level exception handler is also registered using SetUnhandledExceptionFilter. This handler should not be called in the targeted execution environments (none of the intentionally triggered exceptions should fall through the vectored exception handler). So this top-level handler just contains a single call to TerminateProcess. Interestingly, Roshtyak also uses ZwSetInformationProcess to set SEM_FAILCRITICALERRORS using the ProcessDefaultHardErrorMode class. This ensures that even if the exception somehow is passed all the way to the default exception handler, Windows would not show the standard error message box, which could alert the victim that something suspicious is going on.

When everything is set up, Roshtyak begins generating exceptions. The first exception is generated by a popf instruction, directly followed by a cpuid instruction (shown below). The value popped by the popf instruction was crafted to set the trap flag, which should, in turn, raise a single-step exception. On a physical machine, the exception would trigger right after the cpuid instruction. Then, the custom vectored exception handler would take over and move the instruction pointer away from the C7 B2 opcodes, which mark an invalid instruction. However, under many hypervisors, the single-step exception would not be raised. This is because the cpuid instruction forces a VM exit, which might delay the effect of the trap flag. If that is the case, the processor will raise an illegal instruction exception when trying to execute the invalid opcodes. If the vectored exception handler encounters such an exception, it knows that it is running under a hypervisor. A variation of this technique is described thoroughly in a blog post by Palo Alto Networks. Please refer to it for more details. 

The exception-based check using popf and cpuid to detect hypervisors

Another exception is generated using the two-byte int 3 instruction (CD 03). This instruction is followed by garbage opcodes. The int 3 here raises a breakpoint exception, which is handled by the vectored exception handler. The vectored exception handler doesn’t really do anything to handle the exception, which is interesting. This is because by default, when Windows handles the two-byte int 3 instruction, it will leave the instruction pointer in between the two instruction bytes, pointing to the 03 byte. When disassembled from this 03 byte, the garbage opcodes suddenly start making sense. We believe this is a check against some overeager debuggers, which could “fix” the instruction pointer to point after the 03 byte.

Moreover, the vectored exception handler checks the thread’s CONTEXT and makes sure that registers Dr0 through Dr3 are empty. If they are not, the process is being debugged using hardware breakpoints. While this check is relatively common in malware, the CONTEXT is usually obtained using a call to a function like GetThreadContext. Here, the malware authors took advantage of CONTEXT being passed as an argument to the exception handler, so they did not need to call any additional API functions.

Large executable mappings

This next check is interesting mostly because we are not sure what it’s really supposed to check (in other words, we’d be happy to hear your theories!). It starts with Roshtyak creating a large PAGE_EXECUTE_READWRITE mapping of size 0x386F000. Then it maps this mapping nine times into its own address space. After this, it memsets the mapping to 0x42 (opcode for inc edx), except for the last six bytes, which are filled with four inc ecx instructions and jmp dword ptr [ecx] (see below). Next, it puts the nine base addresses of the mapped views into an array, followed by an address of a single ret instruction. Finally, it points ecx into this array and calls the first mapped view, which results in all the mapped views being called sequentially until the final ret instruction. After the return, Roshtyak validates that edx got incremented exactly 0x1FBE6FCA times (9 * (0x386F000 - 6)).

The end of the large mapped section. The jmp dword ptr [ecx] instruction is supposed to jump to the start of the next mapped view.

Our best guess is that this is yet another anti-emulator check. For example, in some emulators, mapped sections might not be fully implemented, so the instructions written into one instance of the mapped view might not propagate to the other eight instances. Another theory is the check could be done to request large amounts of memory that emulators might fail to provide. After all, the combined size of all the views is almost half of the standard 32-bit user mode address space.

Detecting process suspension

This trick abuses an undocumented thread creation flag in NtCreateThreadEx to detect when Roshtyak’s main process gets externally suspended (which could mean that a debugger got attached). This flag essentially allows a thread to keep running even when PsSuspendProcess gets called. This is coupled with another trick abusing the fact that the thread suspend counter is a signed 8-bit value, which means that it maxes out at 127. Roshtyak spawns two threads, one of which keeps suspending the other one until the suspend counter limit is reached. After this, the first thread keeps periodically suspending the other one and checking if the call to NtSuspendThread keeps failing with STATUS_SUSPEND_COUNT_EXCEEDED. If it does not, the thread must have been externally suspended and resumed (which would leave the suspend counter at 126, so the next call to NtSuspendThread would succeed). Not getting this error code would be suspicious enough for Roshtyak to quit using TerminateProcess. This entire technique is described in more detail in a blog post by Secret Club. We believe that’s where the authors of Roshtyak got this trick from. It’s also worth mentioning Roshtyak uses this technique only on Windows builds 18323 (19H1) and later because the undocumented thread creation flag was not implemented on prior builds.

Indirect registry writes

Roshtyak performs many suspicious registry operations, for example, setting up the RunOnce key for persistence. Since modifications to such keys are likely to be monitored, Roshtyak attempts to circumvent the monitoring. It first generates a random registry key name and temporarily renames the RunOnce key to the random name using ZwRenameKey. Once renamed, Roshtyak adds a new persistence entry to the temporary key before finally renaming it back to RunOnce. This method of writing to the registry can be easily detected, but it might bypass some simple hooking-based monitoring methods.

Similarly, there are multiple methods Roshtyak uses to delete files. Aside from the apparent call to NtDeleteFile, Roshtyak is able to effectively delete a file by setting FileDispositionInformation or FileRenameInformation in a call to ZwSetInformationFile. However, unlike the registry modification method, this doesn’t seem to be implemented in order to evade detection. Instead, Roshtyak will try these alternative methods if the initial call to NtDelete file fails. 

Checking VBAWarnings

The VBAWarnings registry value controls how Microsoft Office behaves when a user opens a document containing embedded VBA macros. If this value is 1 (meaning “Enable all macros”), macros are executed by default, even without the need for any user interaction. This is a common setting for sandboxes, which are designed to detonate maldocs automatically. On the other hand, this setting is uncommon for regular users, who generally don’t go around changing random settings to make themselves more vulnerable (at least most of them don’t). Roshtyak therefore uses this check to differentiate between sandboxes and regular users and refuses to run further if the value of VBAWarnings is 1. Interestingly, this means that users, who for whatever reason have lowered their security this way, are immune to Roshtyak.

Command line wiping

Roshtyak’s core is executed with very suspicious command lines, such as RUNDLL32.EXE SHELL32.DLL,ShellExec_RunDLL REGSVR32.EXE -U /s "C:\Users\<REDACTED>\AppData\Local\Temp\dpcw.etl.". These command lines don’t look particularly legitimate, so Roshtyak attempts to hide them during execution. It does this by wiping command line information collected from various sources. It starts by calling GetCommandLineA and GetCommandLineW and wiping both of the returned strings. Then it attempts to wipe the string pointed to by PEB->ProcessParameters->CommandLine (even if this points to a string that has already been wiped). Since Roshtyak is often running under WoW64, it also calls NtWow64QueryInformationProcess64 to obtain a pointer to PEB64 to wipe ProcessParameters->CommandLine obtained by traversing this “second” PEB. While the wiping of the command lines was probably meant to make Roshtyak look more legitimate, the complete absence of any command line is also highly unusual. This was noticed by the Red Canary researchers in their blog post, where they proposed a detection method based on these suspiciously empty command lines.

Roshtyak’s core process, as shown by Process Explorer. Note the suspiciously empty command line.

Additional tricks

Aside from the techniques described so far, Roshtyak uses many less sophisticated tricks that are commonly found in other malware as well. These include:

  • Hiding threads using ThreadHideFromDebugger (and verifying that the threads really got hidden using NtQueryInformationThread)
  • Patching DbgBreakPoint in ntdll
  • Detecting user inactivity using GetLastInputInfo
  • Checking fields from PEB (BeingDebugged, NtGlobalFlag)
  • Checking fields from KUSER_SHARED_DATA (KdDebuggerEnabled, ActiveProcessorCount, NumberOfPhysicalPages)
  • Checking the names of all running processes (some are compared by hash, some by patterns, and some by character distribution)
  • Hashing the names of all loaded modules and checking them against a hardcoded blacklist
  • Verifying the main process name is not too long and doesn’t match known names used in sandboxes
  • Using the cpuid instruction to check hypervisor information and the processor brand
  • Using poorly documented COM interfaces
  • Checking the username and computername against a hardcoded blacklist
  • Checking for the presence of known sandbox decoy files
  • Checking MAC addresses of own adapters against a hardcoded blacklist
  • Checking MAC addresses from the ARP table (using GetBestRoute to populate it and GetIpNetTable to inspect it)
  • Calling ZwQueryInformationProcess with ProcessDebugObjectHandle, ProcessDebugFlags, and ProcessDebugPort
  • Checking DeviceId of display devices (using EnumDisplayDevices)
  • Checking ProductId of \\.\PhysicalDrive0 (using IOCTL_STORAGE_QUERY_PROPERTY)
  • Checking for virtual hard disks (using NtQuerySystemInformation with SystemVhdBootInformation)
  • Checking the raw SMBIOS firmware table (using NtQuerySystemInformation with SystemFirmwareTableInformation)
  • Setting up Defender exclusions (both for paths and processes)
  • Removing IFEO registry keys related to process names used by the malware


We’ve shown many anti-analysis tricks that are designed to prevent Roshtyak from detonating in undesirable execution environments. These tricks alone would be easy to patch or bypass. What makes analyzing Roshtyak especially lethal is the combination of all these tricks with heavy obfuscation and multiple layers of packing. This makes it very difficult to study the anti-analysis tricks statically and figure out how to pass all the checks in order to get Roshtyak to unpack itself. Furthermore, even the main payload received the same obfuscation, which means that statically analyzing Roshtyak’s core functionality also requires a great deal of deobfuscation. 

In the rest of this section, we’ll go through the main obfuscation techniques used by Roshtyak.

A random code snippet from Roshtyak. As can be seen, the obfuscation makes the raw output of the Hex-Rays decompiler practically incomprehensible.

Control flow flattening

Control flow flattening is one of the most noticeable obfuscation techniques employed by Roshtyak. It is implemented in an unusual way, giving the control flow graphs of Roshtyak’s functions a unique look (see below). The goal of control flow flattening is to obscure control flow relations between individual code blocks. 

Control flow is directed by a 32-bit control variable, which tracks the execution state, identifying the code block to be executed. This control variable is initialized at the start of each function to refer to the starting code block (which is frequently a nop block). The control variable is then modified at the end of each code block to identify the next code block that should be executed. The modification is performed using some arithmetic instructions, such as add, sub, or xor.

There is a dispatcher using the control variable to route execution into the correct code block. This dispatcher is made up of if/else blocks that are circularly linked into a loop. Each dispatcher block takes the control variable and masks it using arithmetic instructions to check if it should route execution into the code block that it is guarding. What’s interesting here is there are multiple points of entry from the code blocks into the dispatcher loop, giving the control flow graphs the jagged “sawblade” look in IDA. 

Branching is performed using a special code block containing an imul instruction. It relies on the previous block to compute a branch flag. This branch flag is multiplied using the imul instruction with a random constant, and the result is added, subbed, or xored to the new control variable. This means that after the branch block, the control variable will identify one of the two possible succeeding code blocks, depending on the value that was computed for the branch flag.

Control flow graph of a function obfuscated using control flow flattening

Function activation keys

Roshtyak’s obfuscated functions expect an extra argument, which we call an activation key. This activation key is used to decrypt all local constants, strings, variables, etc. If a function is called with a wrong activation key, the decryption results in garbage plaintext, which will most likely cause Roshtyak to get stuck in an infinite loop inside the control flow dispatcher. This is because all constants used by the dispatcher (the initial value of the control variable, the masks used by the dispatcher guards, and the constants used to jump to the next code block) are encrypted with the activation key. Without the correct activation key, the dispatcher simply does not know how to dispatch.

Reverse engineering a function is practically impossible without knowing the correct activation key. All strings, buffers, and local variables/constants remain encrypted, all cross-references are lost, and worse, there is no control flow information. Only individual code blocks remain, with no way to know how they relate to each other.

Each obfuscated function has to be called from somewhere, which means the code calling the function has to supply the correct activation key. However, obtaining the activation key is not that easy. First, call targets are also encrypted with activation keys, so it’s impossible to find where a function is called from without knowing the right activation keys. Second, even the supplied activation key is encrypted with the activation key of the calling function. And that activation key got encrypted with the activation key of the next calling function. And so on, recursively, all the way until the entry point function.

This brings us to how to deobfuscate the mess. The activation key of the entry point function must be there in plaintext. Using this activation key, it is possible to decrypt the call targets and activation keys of functions that are called directly from this entry point function. Applying this method recursively allows us to reconstruct the full call graph along with the activation keys of all the functions. The only exceptions would be functions that were never called and were left in by the compiler. These functions will probably remain a mystery, but since the sample does not use them, they are not that important from a malware analyst’s point of view.

Variable masking

Some variables are not stored in plaintext form but are masked using one or more arithmetic instructions. This means that if Roshtyak is not actively using a variable, it keeps the variable’s value in an obfuscated form. Whenever Roshtyak needs to use the variable, it has to first unmask it before it can use it. Conversely, after Roshtyak uses the variable, it converts it back into the masked form. This masking-based obfuscation method slightly complicates tracking variables during debugging and makes it harder to search memory for a known variable value.

Loop transformations

Roshtyak is creative with some loop conditions. Instead of writing a loop like for (int i = 0; i < 1690; i++), it transforms the loop into e.g. for (int32_t i = 0x06AB91EE; i != 0x70826068; i = i * -0x509FFFF + 0xEC891BB1). While both loops will execute exactly 1690 times, the second one is much harder to read. At first glance, it is not clear how many iterations the second loop executes (and if it even terminates). Tracking the number of loop iterations during debugging is also much harder in the second case.


As mentioned, Roshtyak’s core is hidden behind multiple layers of packing. While all the layers look like they were originally compiled into PE files, all but the strictly necessary data (entry point, sections, imports, and relocations) were stripped away. Furthermore, Roshtyak supports two custom formats for storing the stripped PE file information, and the layers take turns on what format they use. Additionally, parts of the custom formats are encrypted, sometimes using keys generated based on the results of various anti-analysis checks.

This makes it difficult to unpack Roshtyak’s layers statically into a standalone PE file. First, one would have to reverse engineer the custom formats and figure out how to decrypt the encrypted parts. Then, one would have to reconstruct the PE header, the sections, the section headers, and the import table (the relocation table doesn’t need to be reconstructed since relocations can just be turned off). While this is all perfectly doable (and can be simplified using libraries like LIEF), it might take a significant amount of time. Adding to this that the layers are sometimes interdependent, it might be easier to just analyze Roshtyak dynamically in memory.

A section header in one of the custom PE-like file formats: raw_size corresponds to SizeOfRawData, raw_size + virtual_padding_size is effectively VirtualSize. There is no VirtualAddress or PointerToRawData equivalent because the sections are loaded sequentially.

Other obfuscation techniques

In addition to the above-described techniques, Roshtyak also uses other obfuscation techniques, including:

  • Junk instruction insertion
  • Import hashing
  • Frequent memory wiping
  • Mixed boolean-arithmetic obfuscation
  • Redundant threading
  • Heavy polymorphism

Core Functionality

Now that we’ve described how Roshtyak protects itself, it might be interesting to also go over what it actually does. Roshtyak’s DLL is relatively large, over a megabyte, but its functionality is surprisingly simple once you eliminate all the obfuscation. Its main purpose is to download further payloads to execute. In addition, it does the usual evil malware stuff, namely establishing persistence, escalating privileges, lateral movement, and exfiltrating information about the victim.


Roshtyak first generates a random file name in %SystemRoot%\Temp and moves its DLL image there. The generated file name consists of two to eight random lowercase characters concatenated with a random extension chosen from a hardcoded list. The PRNG used to generate this file name is seeded with the volume serial number of C:\. The sample we analyzed hardcoded seven extensions (.log, .tmp, .loc, .dmp, .out, .ttf, and .etl). We observed other extensions being used in other samples, suggesting this list is somewhat dynamic. With a small probability, Roshtyak will also use a randomly generated extension. Once fully constructed, the full path to the Roshtyak DLL might look like e.g. C:\Windows\Temp\wcdp.etl.

After the DLL image is moved to the new filesystem path, Roshtyak stomps its Modified timestamp to the current system time. It then proceeds to set up a RunOnce(Ex) registry key to actually establish persistence. The registry entry is created using the previously described indirect registry write technique. The command inserted into the key might look as follows:

RUNDLL32.EXE SHELL32.DLL,ShellExec_RunDLL REGSVR32.EXE -U /s "C:\Windows\Temp\wcdp.etl."

There are a couple of things to note here. First, regsvr32 doesn’t care about the extensions of the DLLs it loads, allowing Roshtyak to hide under an innocent-looking extension such as .log. Second, the /s parameter puts regsvr32 into silent mode. Without it, regsvr32 would complain that it did not find an export named DllUnregisterServer. Finally, notice the trailing period character at the end of the path. This period is removed during path normalization, so it practically has no effect on the command. We are not exactly sure what the author’s original intention behind including this period character is. It looks like it could have been designed to trick some anti-malware software into not being able to connect the persistence entry with the payload on the filesystem.

By default, Roshtyak uses the HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce key for persistence. However, under some circumstances (such as when it detects that Kaspersky is running by checking for a process named avp.exe) the key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx will be used instead. The RunOnceEx key is capable of loading a DLL, so when using this key, Roshtyak specifies shell32.dll directly, omitting the use rundll32.

A RunOnceEx persistence entry established by Roshtyak

Privilege escalation

Roshtyak uses both UAC bypasses and regular EoP exploits in an attempt to elevate its privileges. Unlike many other pieces of malware, which just blindly execute whatever UAC bypasses/exploits the authors could find, Roshtyak makes efforts to figure out if the privilege escalation method is even likely to be successful. This was probably implemented to lower the chances of detection due to the unnecessary usage of incompatible bypasses/exploits. For UAC bypasses, this involves checking the ConsentPromptBehaviorAdmin and ConsentPromptBehaviorUser registry keys. For EoP exploits, this is about checking the Windows build number and patch level.

Besides checking the ConsentPromptBehavior(Admin|User) keys, Roshtyak performs other sanity checks to ensure that it should proceed with the UAC bypass. Namely, it checks for admin privileges using CheckTokenMembership with the SID S-1-5-32-544 (DOMAIN_ALIAS_RID_ADMINS). It also inspects the value of the DbgElevationEnabled flag in KUSER_SHARED_DATA.SharedDataFlags. This is an undocumented flag that is set if UAC is enabled. Finally, there are AV checks for BitDefender (detected by the module atcuf32.dll), Kaspersky (process avp.exe), and our own Avast/AVG (module aswhook.dll). If one of these AVs is detected, Roshtyak avoids selected UAC bypass techniques, presumably the ones that might result in detection.

As for the actual UAC bypasses, there are two main methods implemented. The first is an implementation of the aptly named ucmDccwCOM method from UACMe. Interestingly when this method is executed, Roshtyak temporarily masquerades its process as explorer.exe by overwriting FullDllName and BaseDllName in the _LDR_MODULE structure corresponding to the main executable module. The payload launched by this method is a randomly named LNK file, dropped into %TEMP% using the IShellLink COM interface. This LNK file is designed to relaunch the Roshtyak DLL, through LOLBins such as advpack or register-cimprovider.

The second method is more of a UAC bypass framework than a specific bypass method, because multiple UAC bypass methods follow the same simple pattern: first registering some specific shell open command and then executing an autoelevating Windows binary (which internally triggers the shell open command). For instance, a UAC bypass might be accomplished by writing a payload command to HKCU\Software\Classes\ms-settings\shell\open\command and then executing fodhelper.exe from %windir%\system32. Basically, the same bypass can be achieved by substituting the pair ms-settings/fodhelper.exe with other pairs, such as mscfile/eventvwr.exe. Roshtyak uses the following six pairs to bypass UAC:

Class Executable
mscfile eventvwr.exe
mscfile compmgmtlauncher.exe
ms-settings fodhelper.exe
ms-settings computerdefaults.exe
Folder sdclt.exe
Launcher.SystemSettings slui.exe

Let’s now look at the kernel exploits (CVE-2020-1054 and CVE-2021-1732) Roshtyak uses to escalate privileges. As is often the case in Roshtyak, these exploits are stored encrypted and are only decrypted on demand. Interestingly, once decrypted, the exploits turn out to be regular PE files with completely valid headers (unlike the other layers in Roshtyak, which are either in shellcode form or stored in a custom stripped PE format). Moreover, the exploits lack the obfuscation given to the rest of Roshtyak, so their code is immediately decompilable, and only some basic string encryption is used. We don’t know why the attackers left these exploits so exposed, but it might be due to the difference in bitness. While Roshtyak itself is x86 code (most of the time running under WoW64), the exploits are x64 (which makes sense considering they exploit vulnerabilities in 64-bit code). It could be that the obfuscation tools used by Roshtyak’s authors were designed to work on x86 and are not portable to x64.

Snippet from Roshtyak’s exploit for CVE-2020-1054, scanning through IsMenu to find the offset to HMValidateHandle.

To execute the exploits, Roshtyak spawns (the AMD64 version of) winver.exe and gets the exploit code to run there using the KernelCallbackTable injection method. Roshtyak’s implementation of this injection method essentially matches a public PoC, with the biggest difference being the usage of slightly different API functions due to the need for cross-subsystem injection (e.g. NtWow64QueryInformationProcess64 instead of NtQueryInformationProcess or NtWow64ReadVirtualMemory64 instead of ReadProcessMemory). The code injected into winver.exe is not the exploit PE itself but rather a slightly obfuscated shellcode, designed to load the exploit PE into memory.

The kernel exploits target certain unpatched versions of Windows. Specifically, CVE-2020-1054 is only used on Windows 7 systems where the revision number is not higher than 24552. On the other hand, the exploit for CVE-2021-1732 runs on Windows 10, with the targeted build number range being from 16353 to 19042. Before exploiting CVE-2021-1732, Roshtyak also scans through installed update packages to see if a patch for the vulnerability is installed. It does this by enumerating the registry keys under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages and checking if the package for KB4601319 (or higher) is present.

Lateral movement

When it comes to lateral movement, Roshtyak simply uses the tried and tested PsExec tool. Before executing PsExec, Roshtyak ensures it makes sense to run it by checking for a SID matching the “well-knownWinAccountDomainAdminsSid group. If domain admin rights are not detected, Roshtyak skips its lateral movement phase entirely.

Roshtyak attempts to get around detection by setting Defender exclusions, as PsExec is often flagged as a hacktool (for good reasons). It sets a path exclusion for %TEMP% (where it will drop PsExec and other files used for lateral movement). Later, it sets up a process exclusion for the exact path from which PsExec will be executed. 

While we would expect PsExec to be bundled inside Roshtyak, it turns out Roshtyak downloads it on demand from https://download.sysinternals[.]com/files/PSTools.zip. The downloaded zip archive is dropped into %TEMP% under a random name with the .zip extension. PsExec is then unzipped from this archive using the Windows Shell COM interface (IShellDispatch) into a randomly named .exe file in %TEMP%.

The payload to be executed by PsExec is a self-extracting package created by a tool called IExpress. This is an archaic installer that’s part of Windows, which is probably why it’s used, since Roshtyak can rely on it already being on the victim machine. The installer generation is configured by a text file using the Self Extraction Directive (SED) syntax. 

Roshtyak’s IExpress configuration template

Roshtyak uses a SED configuration template with three placeholders (%1, %2, and %3) that it substitutes with real values at runtime. As seen above, the configuration template was written in mixed-case, which is frequently used in Raspberry Robin in general. Once the SED configuration is prepared, it is written into a randomly named .txt file in %TEMP%. Then, iexpress is invoked to generate the payload using a command such as C:\Windows\iexpress.exe /n /q <path_to_sed_config>. The generated payload is dumped into a randomly named .exe file in %TEMP%, as configured by the TargetName directive (placeholder %1).

Once the payload is generated, Roshtyak proceeds to actually run PsExec. There are two ways Roshtyak can execute PsExec. The first one uses the command <path_to_psexec> \\* -accepteula -c -d -s <path_to_payload>. Here, the \\* wildcard instructs PsExec to run the payload on all computers in the current domain. Alternatively, Roshtyak might run the command <path_to_psexec> @<path_to_target_file> -accepteula -c -d -s <path_to_payload>. Here, the target_file is a text file containing a specific list of computers to run the payload on. Roshtyak builds this list by enumerating Active Directory objects using API functions exported from activeds.dll.

Profiling the victim

USB worms tend to have a life of their own. Since their worming behavior is usually completely automated, the threat actor who initially deployed the worm doesn’t necessarily have full control over where it spreads. This is why it’s important for threat actors to have the worm beacon back to their C&C servers. With a beaconing mechanism in place, the threat actor can be informed about all the machines under their control and can use this knowledge to manage the worm as a whole.

The outgoing beaconing messages typically contain some information about the infected machine. This helps financially-motivated cybercriminals decide on how to best monetize the infection. Roshtyak is no exception to this, and it collects a lot of information about each infected victim. Roshtyak concatenates all the collected information into a large string, using semicolons as delimiters. This large string is then exfiltrated to one of Roshtyak’s C&C servers. The exfiltrated pieces of information are listed below, in order of concatenation.

  • External IP address (obtained during a Tor connectivity check)
  • A string hardcoded into Roshtyak’s code, e.g. AFF123 (we can’t be sure what’s the meaning behind this, but it looks like an affiliate ID)
  • A 16-bit hash of the DLL’s PE header (with some fields zeroed out) xored with the lower 16 bits of its TimeDateStamp. The TimeDateStamp appears to be specially crafted so that the xor results in a known value. This could function as a tamper check or a watermark.
  • Creation timestamp of the System Volume Information folder on the system drive
  • The volume serial number of the system drive
  • Processor count (GetActiveProcessorCount)
  • Windows version (KUSER_SHARED_DATA.Nt(Major|Minor)Version)
  • Windows product type (KUSER_SHARED_DATA.NtProductType)
  • Windows build number (PEB.OSBuildNumber)
  • Local administrative privileges (ZwQueryInformationToken(TokenGroups)/CheckTokenMembership, check for DOMAIN_ALIAS_RID_ADMINS)
  • Domain administrative privileges (check for WinAccountDomainAdminsSid/WinAccountDomainUsersSid)
  • System time (KUSER_SHARED_DATA.SystemTime)
  • Time zone (KUSER_SHARED_DATA.TimeZoneBias)
  • System locale (NtQueryDefaultLocale(0))
  • User locale (NtQueryDefaultLocale(1))
  • Environment variables (username, computername, userdomain, userdnsdomain, and logonserver)
  • Java version (GetFileVersionInfo("javaw.exe") -> VerQueryValue)
  • Processor information (cpuid to obtain the Processor Brand String)
  • Path to the image of the main executable module (NtQueryVirtualMemory(MemorySectionName))
  • Product ID and serial number of the main physical drive (DeviceIoControl(IOCTL_STORAGE_QUERY_PROPERTY, StorageDeviceProperty))
  • MAC address of the default gateway (GetBestRoute -> GetIpNetTable)
  • MAC addresses of all network adapters (GetAdaptersInfo)
  • Installed antivirus software (root\securitycenter2 -> SELECT * FROM AntiVirusProduct)
  • Display device information (DeviceId, DeviceString, dmPelsWidth, dmPelsHeight, dmDisplayFrequency) (EnumDisplayDevices -> EnumDisplaySettings)
  • Active processes (NtQuerySystemInformation(SystemProcessInformation))
  • Screenshot encoded in base64 (gdi32 method)


Once collected, Roshtyak sends the victim profile to one of its C&C servers. The profile is sent over the Tor network, using a custom comms module Roshtyak injects into a newly spawned process. The C&C server processes the exfiltrated profile and might respond with a shellcode payload for the core module to execute.

Let’s now take a closer look at this whole process. It’s worth mentioning that before generating any malicious traffic, Roshtyak first performs a Tor connectivity check. This is done by contacting 28 legitimate and well-known .onion addresses in random order and checking if at least one of them responds. If none of them respond, Roshtyak doesn’t even attempt to contact its C&C, as it would most likely not get through to it anyway.

As for the actual C&C communication, Roshtyak contains 35 hardcoded V2 onion addresses (e.g. ip2djbz3xidmkmkw:53148, see our IoC repository for the full list). Like during the connectivity check, Roshtyak iterates through them in random order and attempts to contact each of them until one responds. Note that while V2 onion addresses are officially deprecated in favor of V3 addresses (and the Tor Browser no longer supports them in its latest version) they still appear to be functional enough for Roshtyak’s nefarious purposes.

Roshtyak’s hardcoded C&C addresses

The victim profile is sent in the URL path, appended to the V2 onion address, along with the / character. As the raw profile might contain characters forbidden for use in URLs, the profile is wrapped in a custom structure and encoded using Base64. The very first 0x10 bytes of the custom structure serve as an encryption key, with the rest of the structure being encrypted. The custom structure also contains a 64-bit hash of the victim profile, which presumably serves as an integrity check. Interestingly, the custom structure might get its end padded with random bytes. Note that the full path could be pretty large, as it contains a doubly Base64-encoded screenshot. The authors of Roshtyak were probably aware that the URL path is not suitable for sending large amounts of data and decided to cap the length of the victim profile at 0x20000 bytes. If the screenshot makes the exfiltrated profile larger than this limit, it isn’t included.

When the full onion URL is constructed, Roshtyak goes ahead to launch its Tor comms module. It first spawns a dummy process to host the comms module. This dummy process is randomly chosen and can be one of dllhost.exe, regsvr32.exe, or rundll32.exe. The comms module is injected into the newly spawned process using a shared section, obfuscated through the previously described shellcode hiding technique. The comms module is then executed via NtQueueApcThreadEx, using the already discussed ntdll gadget trick. The injected comms module is a custom build of an open-source Tor library packed in three additional protective shellcode layers.

The core module communicates with the comms module using shared sections as an IPC mechanism. Both modules synchronously use the same PRNG with the same seed (KUSER_SHARED_DATA.Cookie) to generate the same section name. Both then map this named section into their respective address spaces and communicate with each other by reading/writing to it. The data read/written into the section is encrypted with RC4 (the key also generated using the synchronized PRNGs).

The communication between the core module and the comms module follows a simple request/response pattern. The core module writes an encrypted onion URL (including the URL path to exfiltrate) into the shared section. The comms module then decrypts the URL and makes an HTTP request over Tor to it. The core module waits for the comms module to write the encrypted HTTP response back to the shared section. Once it’s there, the core module decrypts it and unwraps it from a custom format (which includes decrypting it yet again and computing a hash to check the payload’s integrity). The decrypted payload might include a shellcode for the core module to execute. If the shellcode is present, the core module allocates a huge chunk of memory, hides the shellcode there using the shellcode hiding technique, and executes it in a new thread. This new thread is hidden using the NtSetInformationThread -> ThreadHideFromDebugger technique (including a follow-up anti-hooking check using NtGetInformationThread to confirm that the NtSetInformationThread call did indeed succeed).


In this blog post, we took a technical deep dive into Roshtyak, the backdoor payload associated with Raspberry Robin. The main focus was to describe how to deal with Roshtyak’s protection mechanisms. We showed some never-before-seen anti-debugger/anti-sandbox/anti-VM tricks and discussed Roshtyak’s heavy obfuscation. We also described Roshtyak’s core functionality. Specifically, we detailed how it establishes persistence, escalates privileges, moves laterally, and uses Tor to download further payloads.

We have to admit that reverse engineering Roshtyak was certainly no easy task. The combination of heavy obfuscation and numerous advanced anti-analysis tricks made it a considerable challenge. Nick Harbour, if you’re looking for something to repurpose for next year’s final Flare-On challenge, this might be it.

Indicators of Compromise (IoCs)

IoCs are available at https://github.com/avast/ioc/tree/master/RaspberryRobin.

The post Raspberry Robin’s Roshtyak: A Little Lesson in Trickery appeared first on Avast Threat Labs.

Malware Analysis Series (MAS) – Article 5

14 September 2022 at 15:21

After a break, the fifth article in the Malware Analysis Series (MAS) is available for reading on:

(PDF): https://exploitreversing.files.wordpress.com/2022/09/mas_5.pdf

I hope you like it.

Have an excellent day and keep reversing!

Alexandre Borges.


Micropatch For Memory Corruption in Microsoft Outlook (CVE-2022-35742)

14 September 2022 at 13:21


by Mitja Kolsek, the 0patch Team


August 2022 Windows Updates brought a fix for a memory corruption vulnerability in Microsoft Outlook, discovered by security researcher insu of 78ResearchLab. The vulnerability exploits a flaw in Outlook's processing of multiple Content-Type headers in a multipart/signed email, whereby a malicious email can lead to free'ing an unallocated memory address and crashing Outlook as such email is downloaded (even before one can view it). Once such email is in user's Inbox, Outlook crashes whenever the user clicks on it or it gets displayed in the Preview pane.

While Microsoft categorized this flaw as "denial of service", it seems possible it could be exploited for arbitrary code execution.

0patch has security-adopted Office 2010 in November 2020 when its support was officially terminated, but Microsoft kept providing security updates for it until April 2021. After that date, we analyzed every published vulnerability affecting still-supported versions of Office to see if Office 2010 was affected, and until now, have not confirmed any. This is the first case where we could reproduce a publicly detailed, potentially critical issue in an Office 2010 component.

Thankfully, the researcher published an analysis and a POC for this vulnerability. This made it possible for us to create a patch for Outlook 2010 that no longer receives official fixes from Microsoft.

Microsoft assigned this issue CVE-2022-35742 and fixed it by properly preserving the flag (bit) that denotes whether a Content-Type buffer needs to be free'd or not. Our micropatch is logically equivalent to Microsoft's:

MODULE_PATH "..\AffectedModules\OUTLMIME.DLL_14.0.7268.5000_Office-2010_64bit_202104\outlmime.dll"
VULN_ID 7481

    PIT outlmime!0x27db9,outlmime!0x27d7d,outlmime!0x272ac
        mov r15, 0              ; default r15 for setz command
        call PIT_0x272ac        ; rewrite original code for patch placement
        mov ebp, eax            ; rewrite original code for patch placement
        test eax, eax           ; rewrite original code for patch placement
        js PIT_0x27db9          ; rewrite original code for patch placement
        mov eax, [rdi+100h]     ; get flag from memory
        and al, 2               ; check flag state
        cmp al, 2               ; check flag state
        setz r15b               ; set r15 accordingly to flag
        jmp PIT_0x27d7d         ; jump to block where memory is copied

    PIT outlmime!0x27db9
        mov [rdi+12Ch], eax     ; rewrite original code for patch placement
        mov rax, [rbx+0F8h]     ; read value from memory
        test byte[rax+10h], 4   ; check if read memory+10h contains 4
        jnz PIT_0x27db9         ; if memory+10h contains 4 then check flags
                                ; else jump to function return block
        test r15d, r15d         ; check if flag is set
        jz AND_BLOCK            ; if set jump to AND_BLOCK
        or dword[rdi+100h], 2   ; if flag not set then set it
        jmp PIT_0x27db9         ; jump to function return block
        and dword[rdi+100h], 0FFFFFFFDh    ; reset flag
                                ; continue normal execution


This video demonstrates the effect of our micropatch. With 0patch disabled, downloading the malicious email in Outlook 2010 crashes Outlook, and restarting Outlook leads to the same result, effectively disabling user's email; with 0patch enabled, the malicious email gets downloaded and while it can't be displayed due to malformed content, it sits there doing no harm.


The micropatch was written for 32-bit and 64-bit versions of Outlook 2010, fully updated with its latest free updates from April 2021.

This micropatch has already been distributed to all online 0patch Agents with a PRO or Enterprise license. To obtain the micropatch and have it applied on your computers along with our other micropatches, create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch. 

To learn more about 0patch, please visit our Help Center

We'd like to thank insu of 78ResearchLab for publishing their analysis and providing a proof-of-concept that allowed us to reproduce the vulnerability and create a micropatch. We also encourage security researchers to privately share their analyses with us for micropatching.

Micropatches for Windows IKE Extension Remote Code Execution (CVE-2022-21849)

8 September 2022 at 13:05


by Mitja Kolsek, the 0patch Team

January 2022 Windows Updates brought a fix for a remote code execution vulnerability in Windows IKE Extension discovered by Polar Bear. Ten days ago (as of this writing), researchers from 78ResearchLab published an analysis and a POC for this vulnerability. This made it possible for us to create a patch for affected "security-adopted" Windows systems that no longer receive official fixes from Microsoft.

The vulnerability allows a remote attacker to cause memory (heap) corruption on the target computer by sending a malformed ISAKMP packet using the IKE protocol, whereby the VendorID payload is longer than the expected 10h characters. The vulnerable code namely prepares a 10-character buffer on the stack for storing this value, and in case a longer value is provided, the memcpy (memory copy) operation results in memory locations beyond the end of buffer being overwritten with attacker-chosen content. In the absence of a negative proof, such vulnerabilities are assumed to be exploitable for arbitrary code execution (although the POC at hand only results in crashing the process.)

Microsoft assigned this issue CVE-2022-21849 and fixed it by adding a check for the length of the VendorID value: if the length isn't exactly 10h (if the size of the entire payload including the 10h-byte prologue isn't exactly 20h), it ignores this value. Our micropatch with just two CPU instructions is logically equivalent to Microsoft's:

MODULE_PATH "..\AffectedModules\ikeext.dll_10.0.17134.254_Win10-1803_64-bit_u202105\ikeext.dll"
VULN_ID 7502

    PIT IKEEXT.DLL!0x1fb64
        cmp r13d, 20h     ; is the size of the VendorID payload equal to 20h?
        jne PIT_0x1fb64   ; if not, ignore the value


The micropatch was written for the following Versions of Windows with all available Windows Updates installed:

  1. Windows 10 v2004
  2. Windows 10 v1903
  3. Windows 10 v1803
Note that Windows 7 and Server 2008 R2 are not affected by this issue, and Windows 10 v1909 was still receiving official updates in January 2022. 
This micropatch has already been distributed to all online 0patch Agents with a PRO or Enterprise license. To obtain the micropatch and have it applied on your computers along with our other micropatches, create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center

We'd like to thank Polar Bear for finding this issue, and 78ResearchLab researchers for publishing their analysis and providing a proof-of-concept that allowed us to reproduce the vulnerability and create a micropatch. We also encourage security researchers to privately share their analyses with us for micropatching.

Pro-Russian Group Targeting Ukraine Supporters with DDoS Attacks

6 September 2022 at 07:00

It has now been six months since the war in Ukraine began. Since then, pro-Russian and pro-Ukrainian hacker groups, like KillNet, Anonymous, IT Army of Ukraine, Legion Spetsnaz RF, have carried out cyberattacks. A lesser-known group called NoName057(16) is among the pro-Russian groups attacking Ukraine and the countries surrounding it and siding with Ukraine.

NoName057(16) is performing DDoS attacks on websites belonging to governments, news agencies, armies, suppliers, telecommunications companies, transportation authorities, financial institutions, and more in Ukraine and neighboring countries supporting Ukraine, like Ukraine itself, Estonia, Lithuania, Norway, and Poland. A full list of the group’s targets can be found at the end of this post. 

To carry out DDoS attacks, hacker groups utilize botnets. They control them via C&C servers, sending commands to individual bots, which essentially act as soldiers. Uncovering and tracking botnets is complex and time-consuming.

We got our hands on malware called Bobik. Bobik is not new, it’s been around since 2020, and is known as a Remote Access Trojan. Things have, however, recently changed. Devices infected with Bobik are now part of a botnet, and carrying out DDoS attacks for NoName057(16). We can confidently attribute the attacks to the group, as we have analyzed and compared what the C&C server is instructing devices infected with Bobik to do with the attacks the group claims to be responsible for on their Telegram channel.


The bots used by the botnet are infected with malware called Bobik, which is written in .NET. The malware has not been tied to a certain group in the past, and is actually a Remote Access Trojan. Its spyware functionalities include keylogging, running and terminating processes, collecting system information, downloading/uploading files, and dropping further malware onto infected devices.

Kill Chain

In the wild, one of the most monitored droppers for Bobik is RedLine Stealer, a botnet-as-a-service cybercriminals can pay for to spread their malware of choice. The usual workflow of Bobik is illustrated in the image below.

At first, an unknown group seems to have purchased RedLine Stealer to deploy – Bobik. The final DDoS module deployment is composed of two basic stages. The first executes Bobik’s Updater via a RedLine Stealer bot. In the second stage, Bobik’s Updater extracts and drops the final DDoS module (Bobik’s RuntimeBroker) and ensures the module’s persistence.

Bobik deployment

When RuntimeBroker is run, the module contacts a C&C server and downloads a configuration file defining targets for DDoS attacks. The module then starts the attacks using a defined count of threads, usually five threads.

The detailed workflow of the Bobik deployment is shown below. The RedLine Stealer Cryptic (installer) deobfuscates the .NET payload of Bobik’s Updater and injects it into the newly created process of the .NET ClickOnce Launch Utility (AppLaunch.exe); see steps 1 – 5.

Bobik deployment using RedLine Stealer Cryptic

The same process is used to execute Bobik’s RuntimeBroker (the DDoS module), because the dropped RuntimeBroker is also packaged and obfuscated via RedLine Stealer Cryptic. Therefore, the dropped Bobik’s RuntimeBroker also deobfuscates the .NET payload of Bobik’s RuntimeBroker and injects it into another AppLaunch process; see steps 6 – 8. After all these steps, the Bobik’s DDoS module is deployed, persistent, and ready to attack.

C&C Servers and Communication

Since June 1, 2022, we have observed Bobik’s network activities. Bobik bots communicate with C&C servers located in Russia and Romania. These two servers are already offline. However, another Romanian server is still active and able to send commands to the bots.

C&C Servers

Since tracking the botnet activity, we have captured three production C&C servers controlling Bobik bots and one development server. The servers run on OS Ubuntu with Nginx (v 1.18.0). RiskIQ reports all servers as malicious with self-signed certificates and servers with bad reputations that previously hosted many suspicious services.

Server 1 

The last active server is, located in Romania, and its first Bobik’s activity we saw was on June 13, 2022. We also have two DNS records for this malicious server:
v9agm8uwtjmz.sytes.net and q7zemy6zc7ptaeks.servehttp.com.

Server 2

The second server is also in Romania, but the communication with the Bobik bots was deactivated around July 14, 2022. The server is still active. Nevertheless, the server responds with a 502 HTTP code (Bad Gateway).  Based on the findings from Server 1, this server used the same v9agm8uwtjmz.sytes.net DNS record, which was reconfigured to Server 1 in the middle of June.

Server 3

The first Bobik’s C&C server we saw was in Russia. The server had opened ports 80 and 443 until June 9, 2022. It is not usable, and therefore de facto offline, by Bobik bots because there is only one opened port for OpenSSH since Bobik requires port 80 for its C&C communication.

Dev Server

One of the C&C servers is a suspected  development server at, listening on port 5001. The server has been active since April and is located in Russia; its reputation is also suspicious. Avast has not detected any hits for this server in the wild. However, one Python sample uses the server as a testing environment.

C&C Communication

The communication between Bobik bots and the C&C servers is mediated using a simple unsecured HTTP request and response via the Nginx web server. The bots obtain appropriate commands from the C&Cs utilizing a URL, see the diagram below.

HTTP communication

The request URL uses the following template:

ip: Bobik bots hardcode one of the C&C IPs or one of the DNS records, see Section C&C Servers.
request: defines the purpose of the communications; we registered three types of requests in the form of a GUID.
– notice: the bots report their states.
– admin: this request can open the admin console of the Nginx web server.
– dropper: is a path to a malicious executable representing Bobik’s RuntimeBroker followed by an exe file name.
The exact GUIDs are listed in Appendix.
id: the hash is computed from Windows Management Instrumentation (WMI) information about a victim’s machine like Win32_DiskDrive, Win32_Processor, Win32_BaseBoard, etc. The hash can provide a unique identifier for Bobik bots.
v: the Bobik version; Avast has captured sample versions ranging from 8 to 19.
pr: is a flag (0,1) representing whether the communication with C&C has timed out at least once. 

A body of the HTTP request contains one simple XML tag with information about the victim; for instance:
<client a0="1" a1="en-US" a2="en-US" a3="14:03:53" a4="600">; where

  • a0: ProductType (1: Workstation, 2: Domain Controller, 3: Server)
  • a1: CultureInfo.InstalledUICulture
  • a2: CultureInfo.CurrentUICulture
  • a3: DateTime.Now
  • a4: Default timeout for the update of the DDoS target list from the C&C server

See the examples of the notice URLs:

  • http://v9agm8uwtjmz.sytes.net/d380f816-7412-400a-9b64-78e35dd51f6e/update?id=B5B72AEBEC4E2E9EE0DAC37AC77EBFB679B6EC6D7EE030062ED9064282F404A7&v=18&pr=1
  • http://q7zemy6zc7ptaeks.servehttp.com/d380f816-7412-400a-9b64-78e35dd51f6e/update?id=BADFD914A37A1FF9D2CBE8C0DBD4C30A9A183E5DF85FCAE4C67851369C2BAF87&v=18&pr=1

The body of the HTTP response contains an encrypted and gzipped XML file configuring bots to the defined DDoS attacks. See the example below:

The bot receives the encrypted data that is decrypted using a simple algorithm, as shown below. The full script is located in the IOC repository.

HTTP response decryptor

The encrypted XML file has an elementary structure, as shown below:

Decrypted XML config

Most of the XML attributes are intuitive, so we will just explain the compound brackets in the path and body attributes. The configuration often uses dynamically generated pieces (definitions) like this: {.,15,20}. The definition dictates what long random text should be generated and in which position.

The definitions are abundantly applied in the path or body of the HTTP requests, where the attackers expect an increased load on the server. The effect is that bots flood servers with meaningless requests. For instance, the first <task> in the image directly above (decrypted XML config) uses this definition: query={.,15,20} which means that the bots generate random texts of 15 – 20 characters long as requests to, for example, the calendar of Poland’s presidential office. Similarly, the second <task> flooded the reference system of bus lines in Ukraine with requests for a password reset, as illustrated in this definition email={.,5,15}%40gmail.com.

For the most part, we captured definitions sending data to login pages, password recovery sites, and site searches; as can be seen from the XML config snippet below:

  • Login data

  • Search requests
  • Password recovery request


Consequently, the attackers try to overload a server with these requests, as they are computationally intensive. The requests require many accesses to server databases, e.g., verifying emails for password resetting, trying to login with random data (definitions), etc.

Bobik Botnet

The Avast telemetry data cannot paint a precise picture of the botnet’s size, but we can estimate the approximate representation of Bobik in the wild, see map below. The map shows where, according to Avast’s telemetry, the bots that attempt to carry out DDoS attacks for NoName057(16) are located. Avast has protected these devices from Bobik or from connecting to the C&C server. Most of the bots are located in Brazil, India, and Southeast Asia.

Distribution of users Avast protected from Bobik

According to our data, the number of Bobik bots is a few hundred. However, the total number must be much larger considering the DDoS attacks’ acute effectiveness and frequency. We, therefore, estimate there are thousands of Bobik bots in the wild.

Selection of DDoS Targets

We estimated a procedure as to how the attackers determine which web servers to DDoS attack because we have configurations of unsuccessful attacks.

The first step is looking for a target that supports Ukraine or a target with anti-Russian views. The attackers analyze the structure of the target’s  website and identify pages that can cause server overloading, especially requests requiring higher computing time, such as searching, password resetting, login, etc.

The second step is filling in the XML template, encrypting it, and deploying it to the C&C servers. The attackers monitor the condition of the target server and modify the XML configuration based on needs (modification of URL parameters, bodies, etc.) to be more effective. The configuration is changed approximately three times per day.

Suppose the configuration is successful and a targeted server is in trouble. In that case, the configuration is fixed until the web server crashes or a server admins implement anti-DDoS technique or firewall rules based on GeoIP.

If the attack is unsuccessful, a new target is selected, and the whole procedure of selection is repeated.


In the first phase, the attackers targeted Ukrainian news servers they defined as being against the war in Ukraine. Then, the attacks targeted websites belonging to Ukrainian cities, local governments, distribution of electrical power, Ukrainian companies supplying the Ukraine army with weapons, railway, bus, companies, and postal offices. 

The second phase targeted organizations publicly supporting Ukraine financially or materially, like Ukraine banks and financial institutions, and operators of local Ukraine gas reservoirs that publicly declared help for the defenders of Ukraine.

As the political situation around the war changed, so did the targets of the DDoS attacks. Bobik performed DDoS attacks on GKN Aerospace, which is the supplier of the Northrop Grumman Corporation because the US Defense Department convened a meeting with America’s eight prime defense contractors (including Northrop Grumman Corporation) to ensure long-term readiness to meet “Ukraine’s weapons needs”. 

Another global company under attack was Group 4 Securitas (G4S), which published a document assessing and exploring key elements of the conflict in Ukraine. In terms of telecommunications companies, we observed an attack on American telco company Verizon, which declared a waiver of call charges to and from Ukraine. And so, we could continue listing companies that were under Bobik attacks due to their support for Ukraine. You can see a few screenshots from affected websites below.

Screenshots of websites supporting Ukraine

Other attacks were more politically motivated based on government declarations of a given country. Baltic states (Lithuania, Latvia, and Estonia) were the significant targets, outside Ukraine, of DDoS attacks carried out by the group. Let’s summarize targets outside of Ukraine, chronologically, since we started monitoring Bobik.

  • June 7, 2022: Significant DDoS attack on Estonia central bank; see Twitter.
  • June 18, 2022: Bobik configuration changed to target Lithuanian transportation companies, local railway, and bus transportation companies after Lithuanian authorities announced a ban on transit through their territory to the Russian exclave of Kaliningrad of goods that are subject to EU sanctions. The attackers also targeted financial sectors in Lithuania, like UAB General Financing, Unija Litas, and more.
  • July 1, 2022: Goods were stopped by Norwegian authorities destined for the roughly 400 miners in the town of Barentsburg employed by the Russian state coal mining company Arktikugol. NoName057(16)’s DDoS attacks focused on Norwegian websites as retaliation for the blockade. The main targets were transportation companies (Kystverket, Helitrans, Boreal), the Norwegian postal service (Posten), and financial institutions (Sbanken, Gjensidige).
  • July 7, 2022: There were not any specific acts by Poland that caused the group to specifically target Polish sites. However, Poland has supported Ukraine from the beginning of the Ukraine conflict, and therefore sites in the country became targets. The first wave of DDoS attacks on Polish sites was aimed at government websites like the Polish Cyberspace Resource Center, Polish 56th Air Base, Military Recruitment Center in Chorzów, and more.
  • July 9, 2022: Bobik was reconfigured back to target Lithuanian websites, focusing on energy companies (Ignitis Group, KN), transportation companies (Ingstad & Co, Asstra-Vilnius), and banks (Turto Bankas, Šiaulių Bankas, Swedbank, SEB, Kredito unija Litas).
  • July 25, 2022: Polish sites were targeted again, this time  the Polish government and airports were attacked. We observed a DDoS configuration including the Polish Sejm, Presidential Office, Ministry of National Defense, Poznań Airport, Szczecin Goleniów Airport, Gdansk Airport, Kraków Airport, and more.
  • August 5, 2022: Polish regional and district courts were targeted.
  • August 9, 2022: When Finland announced their intention to join NATO, the Bobik configuration was reconfigured to target Finnish government institutions, like the  Parliament of Finland (Eduskunta), State Council, Finnish police, and more.
  • August 14, 2022: Latvian financial sector (Latvian Payment Services and Electronic Money, Luminor Interneto bankas) was attacked.
  • August 16, 2022: The second wave of attacks on the Polish justice system began. We monitored a configuration with specific district courts in Krakow, Olsztyn, Warszawa, Poznan.
  • August 23, 2022: Estonia’s largest news portal, Delfi, was under DDoS attack because it published Russophobic content.
  • August 26, 2022: The group targeted another Estonian company, Tallink Grupp, a company providing transport services in the northern Baltic Sea region, including air transport. Tallink’s airports, such as Kärdla, Tartu, and Pärnu were targeted.
  • August 27, 2022: Lithuania’s ministries of National Defense, Culture, Education, Science and Sports, and Public Procurement Offices were targeted, along with the airports and transport companies.
  • August 29, 2022: Ukrainian banks were under DDoSed by the group after a long break. We observed Acordbank, Trust capital, JSC Poltava-Bank, and Pravex Bank under attack.
  • September 1 and 2, 2022: Ukrainian schools were under attack at the beginning of the new school year. Fortunately, none of the group’s 14 targets were taken down.
  • September 3, 2022: Polish armaments plants (Dezamet, Zakłady Mechaniczne Tarnów) and Lithuanian investment companies (Unija Litas, General Financing Bankas) were the group’s first victims after their unsuccessful attack attempts on Ukrainian school institutions.
  • September 6, 2022: The second attempt to attack Ukrainian school institutions (Athens School in Kyiv, Cherkasy National University, First Cambridge Education Center, and more).

The graph below shows a timeline of Bobik DDoS attacks, including successful and unsuccessful attacks from the beginning of June to mid-July 2022, captured by Avast telemetry.

Finally, we inspected all hosts from the XML configuration files within our three-month observation period. The pie chart below illustrates that sites from Lithuania and Poland are the main targets of the NoName057(16) group.

Looking at the distribution of attacked institutions, courts come in first, and second is logistic companies, followed by banks. The remaining targets are airports, transportation, and logistic companies, governments, and telecommunications companies. A full list of the targets can be found at Appendix.

Identifying NoName057(16)

We have tried identifying the hacker group controlling Bobik bots and C&C servers. It was evident that the group must be pro-Russia, so we looked for the most famous DDoS attacks.

Shortly after the war in Ukraine began, a pro-Russia hacking group called Killnet appeared and began carrying out DDoS attacks against companies and governments supporting Ukraine, and even targeted the 2022 Eurovision Song Contest.

Bobik initially attacked websites Killnet has marked as “undesirable”. Killnet reports their DDoS attacks on their Telegram account. At first, it looked like the attacks carried out by Bobik distantly resembled Killnet’s activity, because the timeline of attacked countries was similar to the XML configurations. However, many successful DDoS attacks by Bobik were not posted by Killnet.

On June 21, 2022, the Killnet group publicly thanked a group called NoName057(16) for their support during a “special military operation”:

When we finished analyzing NoName057(16)’s Telegram channel, we confirmed that NoName057(16) is responsible for the DDoS attacks performed by the Bobik bots. All the XML configurations we captured from the NoName057(16) C&C servers exactly match the posts on the Telegram channel.


NoName057(16) is a little-known pro-Russian hacker group. They boast about their successful attack attempts on their Telegram channel, which has more than 14K subscribers. The group was active before we began tracking them on June 1, 2022. Their Telegram channel was created on March 11, 2022. We suspect they were either using a different set of botnets before June 1, 2022, or updating the malware used to control the bots in June.

NoName057(16) has been threatening to punish “propaganda” sources that “lie” about the Russian “special operation” in Ukraine, as well as governments from neighboring countries supporting them in their fight against Russia. The group became visible in the media at the beginning of August after carrying out successful attacks on Finnish and Polish parliaments.

A Wikipedia page about NoName057(16) was created on August 17, 2022. The page summarizes the group’s main activity. It classifies the group as a pro-Russia hacker group that claimed responsibility for cyberattacks on Ukrainian, US, and European websites belonging to government agencies, media, and private companies.

NoName057(16) released a manifesto declaring cyberwar as an act of revenge for open information war against Russia:

As the group increased its activities and media profile, it became easier to determine they were behind the attacks. Therefore, we can clearly state that Bobik is controlled by the pro-Russian hacker group called NoName057(16).

Success Rate

The group only reports successful DDoS attacks on their Telegram channel. Although the reported number of successful attacks seems large, statistical information indicates the contrary.

The group exclusively concentrates on DDoS attacks. They do not try to steal data or gain access to systems like other dangerous groups. The question is if they have the necessary knowledge, strength, and infrastructure to do more. Carrying out DDoS attacks is straightforward and does not require deep technical knowledge. Furthermore, the Bobik implementation only sends a simple HTTP request.

Our three-month observation shows that the group’s attack success is around 40%. We compared XML configurations captured by Avast to the achievements the group posts on their Telegram channel. Moreover, there is a particular set of targets, making up ~20% of their posts on Telegram, NoName057(16) claimed they successfully attacked, but we did not match them to the targets listed in their configuration files. For example, NoName057(16) claims to be responsible for attacking websites belonging to Lithuanian airports on June 25, 2022:

NoName057(16) claiming to be responsible for a DDoS attack on Lithuanian airports, posted on NoName057(16)’s Telegram channel

However, we did not find any records of the attack in the configuration files. The likelihood of them not using all of their bots in attacks is slim. In addition to this outage, NoName057(16) declared the sites were under a continuous fourteen-day attack. This would require an extensive bot network, especially considering the group performed other attacks during the same time frame, and the websites were still offline. From what we have seen, it is unlikely that NoName057(16) has an extensive bot network. Moreover, most of their DDoS attacks last a few hours, maximally a few days.

Impact and Protection

The power of the DDoS attacks performed by NoName057(16) is debatable, to say the least. At one time, they can effectively strike about thirteen URL addresses at once, judging by configuration history, including subdomains. Furthermore, one XML configuration often includes a defined domain/target as a set of subdomains, so Bobik effectively attacks five different domains within one configuration. Consequently, they cannot focus on more domains for capacity and efficiency reasons.

Most of the successful attacks result in servers being down for several hours or a few days. To handle the attacks, site operators often resort to blocking queries coming from outside of their country. It is a typical and suitable solution for local servers/domains such as local ticket portals of local bus/train companies, local institutions/companies, etc. Therefore, the DDoS impact on these domains has a minimal effect on the servers of local and smaller companies. Some operators or owners of affected servers have unregistered their domains, but these are extreme cases.

The DDoS attacks carried out were more difficult to handle for some site operators of prominent and significant domains, such as banks, governments, and international companies. After a successful attack, we noticed larger companies implementing enterprise solutions, like Cloudflare or BitNinja, which can filter incoming traffic and detect DDoS attacks in most cases. On the other hand, most large, international companies expect heavier traffic and run their web servers in the Cloud with anti-DDoS solutions, making them more resilient to attacks. For example, the group was unsuccessful in taking down sites belonging to Danish bank, Danske Bank (attacked June 19 – 21, 2022), and Lithuanian bank, SEB (attacked July 12 – 13, 2022 and July 20 – 21, 2022). 

The success of DDoS attacks depends on victim selection. The more “successful” attacks affected companies with simple sites, including about us, our mission, and a contact page, for example. These types of companies do not use their web pages as the main part of their business. These servers are therefore not typically designed to be heavily loaded and do not implement anti-DDoS techniques, making them a very easy target.

The group’s  DDoS attack on Poznań-Ławica Airport in Poland took the site offline for 16 minutes. NoName057(16) configured Bobik bots based on the <tasks> shown in the screenshot below:

XML configuration for Poznań-Ławica Airport

They tried to overload the server with requests for searching, form submitting, and getting data via WordPress API. When the server started to return 502 errors, NoName057(16) did not forget to brag on their Telegram channel. They also included a link to check-host.net to prove their “revenge”.

NoName057(16)’s Telegram post related to their DDoS attack on Poznań-Ławica Airport

However, affected servers very often run back online within several minutes if they implement some anti-DDoS techniques because the algorithms learn to recognize the given type of attacks. The check-host.net report below demonstrates that the DDoS attack on Poznań-Ławica Airport had a minimal impact since the website was offline for 16 minutes.

Check-host.net report for the DDoS attack on Poznań-Ławica Airport, which took the site offline for 16 minutes

On June 23, 2022, NoName057(16) reported on Telegram that Lithuanian authorities lifted a ban on the transit of Russian cargo to Kaliningrad. The group attributes the lifting of the ban, amongst other things, to the efforts of their cyber attacks on Lithuania’s infrastructure, which is debatable at best. However, the attacks on Lithuanian servers have continued.


The botnet went into an idle state on September 1, 2022, at 6 PM UTC, and remained idle persisted for 12 hours. The botnet was reactivated on September 2, 2022, at 4 AM UTC. The XML file sent to the bots contained empty <tasks>, like in this example: <config><tasks delay="0" thread_count="-6"/></config>

A decline in the botnet’s performance may be a possible explanation for this. The group only posted two general posts to their Telegram channel on September 1 and 2, 2022, instead of boasting about successful attacks, our first indication the botnet might not be performing well.  

The first post was about the beginning of the new school year and day of knowledge. The group also mentioned being on the defense of the cyber front for their country and the for the safety of the younger generation. The second post was about “information guns and DDoS tanks” that worked quietly on very difficult and important work.

In fact, NoName057(16) changed targets ten times each day in the XML configurations, which is abnormal. We monitored the targets for these days, and none of the attacks were successful. Therefore, it is evident that the botnet had some trouble.

Most of the sites attacked by the group have implemented anti-DDoS protections. This slowdown  implies that the botnet is relatively static without many changes, such as recruiting new bots or dynamically changing bots’ IPs. A static botnet is an advantage for anti-DDoS protections, because malicious traffic can be easily identified.

NoName057(16) has continued to attack other easier targets since September. Only the future will reveal the Bobik botnet’s successes and failures. However, the attack’s success rate has been only around 25% since the beginning of September.


We investigated and analyzed malware used to carry out DDoS attacks on sites in and around Ukraine, starting in June, 2022. We identified the malware as a .NET variant of a RAT called Bobik, including a DDoS module, and spreading via a bot-net-as-a-service, RedLine Stealer.

The first technical part of this investigation uncovered C&C servers and the HTTP communication protocol used by the Bobik bots. We also successfully decrypted the HTTP protocol, including its parameters. This allowed us to monitor the C&C servers and collect information about the botnet architecture and XML configurations defining the DDoS targets.

The second aim was to determine the bad actors behind the attacks. We identified a pro-Russian hacker group called NoName057(16), as the users or possibly even the authors of Bobik, based on the XML configurations and what the group posts to their Telegram channel.

NoName057(16) focuses exclusively on DDoS attacks and looks for companies and organizations that support Ukraine or are “anti-Russian”. They do not try to steal data or gain access to the system like other dangerous groups. Therefore, we can declare that their activities are only harmful in the sense that they can lose companies’ business while their sites are offline, but attacked sites that have gone offline have luckily recovered quickly. Their activities are more annoying than dangerous. 

We found that the successful attacks defined by NoName057(16) make up just ~ 40% of all of their attack attempts. The success of their attacks depends on the quality of the targeted infrastructure. The evidence suggests that well-secured and designed servers can withstand the group’s DDoS attacks. 

The group focuses on servers/domains as retaliation for cyber-attacks and sanctions on Russia. All successful attacks, and even successful attacks the group is not responsible for (but claims to be), are posted to their Telegram channel.

If you are concerned your device might be infected with Bobik and supporting NoName057(16)’s efforts, we highly recommend you install security software, like Avast Antivirus, which detects, blocks and can remove Bobik.


The full list of IoCs is available in the IOC repository




[request] value
notice bcaa8752-51ff-4e35-8ef9-4aefbf42b482
admin 27bff71b-42c0-4a47-ba39-04c83f2f40bb
dropper fb82275d-6255-4463-8261-ef65d439b83b/<file_name>

Bobiks’ Targets
Full list of the targets can be found in the IOC repository


[1] Threat Encyclopedia
[2] US Defense Department convened a meeting with America’s eight prime defense contractors
[3] Ukraine Conflict Overview And Impact To Security In The UK
[4] Verizon Waives Calling Charges to and From Ukraine
[5] Kaliningrad sanctions to take effect, Lithuania says
[6] Norway Greenlights Blocked Goods for Russian Arctic Miners
[7] Hacker wars heat up as the pro-Russian Killnet attacks Italy
[8] What is known about the Russian hacker group NoName057(16), which hacked the website of the Finnish Parliament?
[9] Russian hacker group NoName057 (16) attacks Poland and Finland
[10] Wikipedia – NoName057(16)

The post Pro-Russian Group Targeting Ukraine Supporters with DDoS Attacks appeared first on Avast Threat Labs.

Windows Kernel Introspection (WKI)

2 September 2022 at 00:00
Table of contents Table of contents Introduction User-Mode Application Kernel-Mode Driver Example: Listing Kernel Memory Pool Tag Final Thoughts Introduction Over the last few years that I spent learning more and more about Microsoft Windows, it has been more and more apparent that studying the NT kernel is an incredibly deep and vast subject, nevertheless particularly interesting. A lot of research exists online and Windows Internals books are probably the best allies for this journey.

Context IS Memorabilia - Common Language Runtime Hook for Persistence

13 May 2022 at 00:00
Archive of https://www.contextis.com/en/blog/common-language-runtime-hook-for-persistence from 22 AUG 2019. Table of contents Table of contents Introduction .Net Overview Common Language Runtime Application Domain and Application Domain Manager Assembly and Global Assembly Cache Wrapping Everything Up Identifying .Net Framework-Based Application Introduction This blog post explains how it is possible to execute arbitrary code and maintain access to a Microsoft Windows system by leveraging the Common Language Runtime application domain manager. During scenario-based assessments or digital-based Red Team assessments, gaining initial access to the internal network of an organisation is challenging, requires time, and effort.

Context IS Memorabilia - DynamicWrapperEx – Windows API Invocation from Windows Script Host

13 May 2022 at 00:00
Archive of https://www.contextis.com/en/blog/dynamicwrapperex-windows-api-invocation-from-windows-script-host from 01 FEB 2021. Table of contents Table of contents Introduction COM and OLE Automation Basics Leveraging OLE Automation x86_64 Standard Calling Convention Registration-Free Activation Limitations and Operational Security Considerations Example of Shellcode Execution References Introduction The Component Object Model (COM) was a revolutionary specification when it first appeared in 1995, despite this, there is still a large veil of mystery surrounding it. Those who have worked closely with Microsoft Windows systems may have heard of it, but probably in negative terms.

Context IS Memorabilia - AMSI Bypass

13 May 2022 at 00:00
Archive of https://www.contextis.com/en/blog/amsi-bypass from 12 JUN 2019 Table of contents Table of contents Introduction How AMSI Operates Enumerating AMSI Functions Finding the Function’s Address Egg Hunter Patching Final Notes Introduction AMSI stands for Anti-Malware Scan Interface and was introduced in Windows 10. The name is reasonably self-explanatory; this is an interface that applications and services are able to utilise, sending “content” to an anti-malware provider installed on the system (e.g. Windows Defender).

Context IS Memorabilia - Bring your own .NET Core Garbage Collector

13 May 2022 at 00:00
Archive of https://www.contextis.com/en/blog/bring-your-own-.net-core-garbage-collector from 19 JUN 2020. Table of contents Table of contents Introduction .NET Core Configuration Knobs Standalone Garbage Collector Environment Variable Path Traversal Building a Custom GC Application Whitelisting Bypass Scenario Remediation Timeline Introduction This blog post explains how it is possible to abuse a legitimate feature of .Net Core, and exploit a directory traversal bug to achieve application whitelisting bypass. The .NET Core is an open-source software framework based on the .

SSE and AVX Mutation Idea (xlate)

5 January 2022 at 00:00
Table of contents Table of contents SSE and AVX Mutation Idea (xlate) Streaming SIMD Extensions (SSE) Advanced Vector Extensions (AVX) AVX and the new VEX Translation between Legacy SSE to AVX Example 1: Basic 2-byte VEX Encoded Instruction Example 2: Basic 3-byte VEX Encoded Instruction with 64-bit Example 3: 3-byte VEX Encoded Instruction with SIB Example 4: With Non-Destructive Operand WIB and Synonymous Mutation Final Notes Appendix A : Non-Destructive Operands Instructions Appendix B : AVX Only Instructions Appendix C : VSIB Instructions Appendix D : VEX.

Simple Mutation Ideas (substitution) with REX Prefix

18 December 2020 at 00:00
Table of contents Table of contents Abstract Case 1 Case 2 Case 3 Case 4 Case 5 Case 6 Case 7 Operand-Size Override Legacy Prefix Abstract On an Intel or AMD processor, when executing code from a 64-bit code segment (i.e., CS segment descriptor CS[L] bit = 1b and CS[D] = 0b), the 1-byte REX (i.e., Register eXtended) prefix can be used to modify operand addressing and selection. This can be for one of the following reasons:

AppLocker Policy Enumeration in C

3 August 2020 at 00:00
0x00 Abstract Application whitelisting and blacklisting is an interesting topic because depending on how it has been configured this can drastically increase the difficulty of an attacker to gain initial code execution. With Windows XP and Windows Server 2013, Microsoft released Software Restriction Policy (SRP), which was a great idea but a massive pain to configure with little to no flexibility. This is where AppLocker is coming into play, this is the successor of SRP.

Cobalt Strike Aggressor Scripts-Ception

29 July 2020 at 00:00
0x00 Abstract Over the past few months I have been using Cobalt Strike (CS) quite extensively, both during Simulated Attack engagements and for R&D and offensive security projects. I subsequently used more than what I expected the famous Aggressor script engine. Throughout the different versions of CS, Raphael Mudge developed multiple features that allow operators to extend the standard capabilities of CS: C2 malleable profile, to modify the behaviours of the implant (e.

GitHub Actions - Doxygen Documentation Deployment

30 June 2020 at 00:00
0x00 Abstract I used to be a Java/PHP/PolymerJS developer for 2 years before joining the wonderful information security industry and developing in C/C++ and C#. I’m probably not a great programmer but a least I’m documenting my code! Trust me, well documented code will save your butt. I have subscribed to a professional GitHub account few weeks back, which gave me access to the 3000 minutes of GitHub Actions per months.

Journey Into the Object Manager Executive Subsystem: Handles

6 June 2020 at 00:00
0x00 Abstract Allowing direct access to named or un-named executive objects to user mode and kernel mode applications would be extremely dangerous as it would interfere with, and render the duty of the executive subsystems obsolete. As a result, this would put the whole system at risk and make the management of executive objects almost impossible. Additionally, executive objects resides in kernel memory, which means that if user mode applications could directly modify data structure in kernel memory this would also be extremely dangerous and chances of a BSOD would be high.

Journey Into the Object Manager Executive Subsystem: Object Header and Object Type

17 March 2020 at 00:00
0x00 Abstract Almost all the actions carried out by user mode applications and Windows executive subsystems (e.g. I/O Manager, Memory Manager) have to deal with Windows resources (aka objects). These actions can be related to physical objects like devices or logical objects such as processes, threads, tokens and files. For this specific reason, the Object Manager, which is a executive subsystem, is responsible for providing a standardised, uniform and singular way to manage, create, release and access objects.