Overview

Cyble’s weekly sensor intelligence report for clients detailed new attacks on popular WordPress plugins, and IoT exploits continue to occur at very high rates.

Two 9.8-severity vulnerabilities in LightSpeed Cache and GutenKit are under attack, as WordPress and other CMS and publishing systems remain attractive targets for threat actors.

Vulnerabilities in IoT devices and embedded systems continue to be targeted at alarming rates. In addition to older exploits, this week Cyble Vulnerability Intelligence researchers highlighted an older RDP vulnerability that may still be present in some OT networks. Given the difficulty of patching these systems, vulnerabilities may persist and require additional mitigations.

Vulnerabilities in PHP, Linux systems, and Java and Python frameworks also remain under attack.

Here are some of the details of the Oct. 23-29 sensor intelligence report sent to Cyble clients, which also looked at scam and brute-force campaigns. VNC (Virtual Network Computing) was a prominent target for brute-force attacks this week.

CVE-2024-44000: LiteSpeed Cache Broken Authentication

CVE-2024-44000 is an Insufficiently Protected Credentials vulnerability in LiteSpeed Cache that allows Authentication Bypass and could potentially lead to account takeover. The issue affects versions of the WordPress site performance and optimization plugin before 6.5.0.1.

An unauthenticated visitor could gain authentication access to any logged-in users – and potentially to an Administrator-level role. Patchstack notes that the vulnerability requires certain conditions to be exploited:

• Active debug log feature on the LiteSpeed Cache plugin
• Has activated the debug log feature once before, it’s not currently active, and the /wp-content/debug.log file has not been purged or removed.

Despite those requirements, Cyble sensors are detecting active attacks against this WordPress plugin vulnerability.

CVE-2024-9234: GutenKit Arbitrary File Uploads

The GutenKit Page Builder Blocks, Patterns, and Templates for Gutenberg Block Editor plugin for WordPress is vulnerable to CVE-2024-9234, with arbitrary file uploads possible due to a missing capability check on the install_and_activate_plugin_from_external() function (install-active-plugin REST API endpoint) in all versions up to, and including, 2.1.0. The vulnerability makes it possible for unauthenticated attackers to install and activate arbitrary plugins or utilize the functionality to upload arbitrary files spoofed like plugins.

As malicious WordPress plugins are becoming an increasingly common threat, admins are advised to take security measures seriously.

IoT Device and Embedded Systems Attacks Remain High

IoT device attacks first detailed two weeks ago continue at a very high rate, as Cyble honeypot sensors in the past week detected 361,000 attacks on CVE-2020-11899, a medium-severity Out-of-bounds Read vulnerability in the Treck TCP/IP stack before 6.0.1.66, in attempts to gain administrator privileges.

Also of concern for OT environments are attacks on four vulnerabilities in the Wind River VxWorks real-time operating system (RTOS) for embedded systems in versions before VxWorks 7 SR620: CVE-2019-12255, CVE-2019-12260, CVE-2019-12261 and CVE-2019-12263. Cyble sensors routinely detect 3,000 to 4,000 attacks a week on these vulnerabilities, which can be present in a number of older Siemens devices.

New to the report this week are several hundred attacks on CVE-2019-0708, a 9.8-severity remote code execution vulnerability in Remote Desktop Services found in several older Siemens devices.

Linux, Java, and Other Attacks Persist

A number of other recent exploits observed by Cyble remain active:

Attacks against Linux systems and QNAP and Cisco devices detailed in our Oct. 7 report remain active.

Previously reported vulnerabilities in PHP, GeoServer, and Python and Spring Java frameworks also remain under active attack by threat actors.

Phishing Scams Detected by Cyble

Cyble sensors detect thousands of phishing scams a week, and this week identified 385 new phishing email addresses. Below is a table listing the email subject lines and deceptive email addresses used in four prominent scam campaigns.

E-mail Subject	Scammers Email ID	Scam Type	Description
VERIFICATION AND APPROVAL OF YOUR PAYMENT FILE	infohh@aol.com	Claim Scam	Fake refund against claims
Online Lottery Draw Reference Claim Code	annitajjoseph@gmail.com	Lottery/Prize Scam	Fake prize winnings to extort money or information
RE: Great News	cyndycornwell@gmail.com	Investment Scam	Unrealistic investment offers to steal funds or data
Re: Consignment Box	don.nkru3@gmail.com	Shipping Scam	Unclaimed shipment trick to demand fees or details

Brute-Force Attacks Target VNC

Of the thousands of brute-force attacks detected by Cyble sensors in the most recent reporting period, Virtual Network Computing (VNC, port 5900) servers were among the top targets of threat actors. Here are the top 5 attacker countries and ports targeted:

• Attacks originating from the United States targeting ports were aimed at port 5900 (30%), 22 (28%), 445 (25%), 3389 (14%) and 80 (3%).
• Attacks originating from Russia targeted ports 5900 (88%), 1433 (7%), 3306 (3%), 22 (2%) and 445 (1%).
• The Netherlands, Greece, and Bulgaria primarily targeted ports 3389, 1433, 5900, and 443.

Security analysts are advised to add security system blocks for the most attacked ports (typically 22, 3389, 443, 445, 5900, 1433, 1080, and 3306).

Recommendations and Mitigations

Cyble researchers recommend the following security controls:

• Blocking target hashes, URLs, and email info on security systems (Cyble clients received a separate IoC list).
• Immediately patch all open vulnerabilities listed here and routinely monitor the top Suricata alerts in internal networks.
• Constantly check for Attackers’ ASNs and IPs.
• Block Brute Force attack IPs and the targeted ports listed.
• Immediately reset default usernames and passwords to mitigate brute-force attacks and enforce periodic changes.
• For servers, set up strong passwords that are difficult to guess.

Conclusion

With active threats against multiple critical systems highlighted, companies need to remain vigilant and responsive. WordPress and VNC installations and IoT devices were some of the bigger attack targets this week and are worth additional attention by security teams. The high volume of brute-force attacks and phishing campaigns demonstrates the general vulnerability crisis faced by organizations.

To protect their digital assets, organizations should address known vulnerabilities and implement recommended security controls, such as blocking malicious IPs and securing network ports. A proactive and layered security approach is key in protecting defenses against exploitation and data breaches.

The post Cyble Sensors Detect New Attacks on LightSpeed, GutenKit WordPress Plugins appeared first on Cyble.

Blog – Cyble – ​Read More

Software developers tend to be advanced computer users at the very least, so you could assume they’d be more likely to spot and thwart a cyberattack. However, experience shows that no one is fully immune to social engineering — all it takes is the right approach. For IT professionals, such an approach might involve the offer of a well-paid job at a high-profile company. Chasing a dream job can make even seasoned developers lower their guard and act like kids downloading pirated games. And the real target (or rather —victim) of the attack might be their current employer.

Recently, a new scheme has emerged in which hackers infect developers’ computers with a backdoored script disguised as a coding test. This isn’t an isolated incident, but just the latest iteration of a well-established tactic. Hackers have been using fake job offers to target IT specialists for years — and in some cases with staggering success.

You might think that the consequences should remain the particular individual’s problem. However, in today’s world, it’s highly likely that the developer uses the same computer for both their main work and the coding test for the new role. As a result, not only personal but also corporate data may be at risk.

Fake job posting, crypto game, and a $540 million heist

One of the most notorious cases of fake job ads used for malicious purposes was witnessed in 2022. Hackers managed to contact (likely through LinkedIn) a senior engineer at Sky Mavis, the company behind the crypto game Axie Infinity, and offer him a high-paying position.

Enticed by the offer, the employee diligently went through several stages of the interview set up by the hackers. Naturally, it all culminated in a “job offer”, sent as a PDF file.

The document was infected. When the Sky Mavis employee downloaded and opened it, spyware infiltrated the company’s network. After scanning the company’s infrastructure, the hackers managed to obtain the private keys of five validators on Axie Infinity’s internal blockchain — Ronin. With these keys they gained complete control over the cryptocurrency assets stored in the company’s wallets.

This resulted in one of the largest crypto heists of the century. The hackers managed to steal 173,600 ETH and 25,500,000 USDC, which was worth approximately $540 million at the time of the heist.

More fake job postings, more malware

In 2023, several large-scale campaigns were uncovered in which fake job offers were used to infect developers, media employees, and even cybersecurity specialists (!) with spyware.

One attack scenario goes like this: someone posing as a recruiter from a major tech company contacts the target through LinkedIn. After some back-and-forth, the target receives an “exciting job opportunity”.

However, to land the job, they must demonstrate their coding skills by completing a test. The test arrives in executables within ISO files downloaded from a provided link. Running these executables infects the victim’s computer with the NickelLoader malware, which then installs one of two backdoors: either miniBlindingCan or LightlessCan.

In another scenario, attackers posing as recruiters initiate contact with the victim on LinkedIn, but then smoothly transition the conversation to WhatsApp. Eventually they send a Microsoft Word file with the job description. As you might guess, this file contains a malicious macro that installs the PlankWalk backdoor on the victim’s computer.

Yet another variation of the attack targeting Linux users featured a malicious archive titled “HSBC job offer.pdf.zip”. Inside the archive was an executable file disguised as a PDF document. Interestingly, in this case, to mask the file’s true extension, the attackers used an exotic symbol: the so-called one dot leader (U+2024). This symbol looks like a regular period to the human eye but is read as a completely different character by the computer.

Once opened, this executable displays a fake PDF job description while, in the background, launching the OdicLoader malware, which installs the SimplexTea backdoor on the victim’s computer.

Fake coding test with a Trojan on GitHub

A recently discovered variation of the fake job attack starts similarly. Attackers contact an employee of the target company pretending to be recruiters seeking developers.

When it comes to the interview, the victim is asked to complete a coding test. However, unlike the previous variations, instead of sending the file directly, the criminals direct the developer to a GitHub repository where it is stored. The file itself is a ZIP archive containing a seemingly innocuous Node.js project.

However, one component of this project contains an unusually long string, specially formatted to be overlooked when scrolling quickly. This string holds the hidden danger: heavily obfuscated code that forms the first stage of the attack.

When the victim runs the malicious project, this code downloads, unpacks, and executes the code for the next stage. This next stage is a Python file without an extension, with a dot at the beginning of the filename signaling to the OS that the file is hidden. This script launches the next step in the attack — another Python script containing the backdoor code.

Thus, the victim’s computer ends up with malware that can maintain continuous communication with the command-and-control server, execute file system commands to locate and steal sensitive information, download additional malware, steal clipboard data, log keystrokes, and send the collected data to the attackers.

As with the other variations of this scheme, the hackers count on the victim using their work computer to complete the “interview” and run the “test”. This allows the hackers to access the infrastructure of the target company. Their subsequent actions can vary, as history shows: from trojanizing software developed by the victim’s company to direct theft of funds from the organization’s accounts, as seen in the Sky Mavis case mentioned at the beginning of this article.

How to protect yourself

As we noted above, there’s currently no bulletproof defense against social engineering. Virtually anyone can be vulnerable if the attacker finds the right approach. However, you can make the task significantly more challenging for attackers:

• Raise awareness among employees — including developers — about cyberthreats through specialized training. Setting up such training is simple with our automated educational platform, Kaspersky Automated Security Awareness Platform.
• Use a reliable security solution on all corporate devices.
• If internal resources and expertise are limited, consider using an external service like Kaspersky Managed Detection and Response.

Kaspersky official blog – ​Read More

In this article, we’ll explore the most common types of protectors—packers and crypters—along with simple ways to detect and remove them.  

We’ll also introduce some useful tools to simplify the process and improve your malware analysis skills. 

What Are Protectors and What Types Are There? 

Protectors are tools designed to complicate code analysis, making it harder to detect and examine malware. Two of the most common types of protectors are packers and crypters. 

1. Packers 

Packers are utilities that package one or more files into a single executable, often adding compression. This process makes static and dynamic detection more difficult, a tactic many types of malware exploit.  

Certain malware, like those written in scripting languages (e.g., Python or JavaScript) or relying on non-standard libraries, require packing to function properly by including interpreters and necessary libraries. 

Classic examples of packers include installers like NSI and MSI, UPX, MPress, and self-extracting archives (SFX) made with tools like 7zip or WinRAR. 

Packers generally don’t protect application data, making it relatively easy to extract them at runtime in a sandbox or remove the packer using static tools. 

2. Crypters

Crypters take protection a step further by encrypting the executable’s contents, often adding layers of packing and obfuscation. Designed to obscure code, crypters make analysis more complex and time-consuming. Examples of crypters include NetReactor, Themida, and VmProtect. 

Main Protection Methods of Crypters: 

1. Dynamic unpacking in memory to avoid leaving any disk trace. 

2. Encryption of files, data, and code, with decryption at runtime. 

3. Code Obfuscation: Changes the structure and sequence of instructions, transforming (meta)data into unreadable or meaningless characters. 

4. Virtualization: Transforms code into pseudo-instructions that are either regenerated or interpreted at runtime. 

Note that without virtualization, code is usually weakly protected and can often be restored to its original or near-original state. 

Identifying Packers: Simple Techniques and Useful Tools 

Detecting packers can be simplified with a few straightforward techniques and specialized tools like DiE (Detect It Easy). DiE notifies users when a packer is detected, making it a quick solution for initial identification. 

Let’s consider the following sample. When analyzing it with DiE v3.10, we can observe the presence of the MPRESS packer. 

Opening the sample in DiE reveals section names that indicate packing. 

Packers like UPX and MPRESS often create sections with distinctive names, such as MPRESS1 and MPRESS2, which help analysts identify their usage. 

We can also examine PE (Portable Executable) information in the Static Discovering window inside ANY.RUN sandbox. This provides further details to help identify these packers and their specific characteristics. 

Analysis of a sample with UPX sections 

We can identify UPX through section names. In certain cases, packers like VMProtect and Themida can also be identified by their distinct section names.

Sections, such as .vmp0, indicate VMProtect (see example).

Sections, such as .themida or .taggant, signal the presence of Themida (see example).

Common Indicators of Packers 

The most common indicators for packers include: 

Unusual Section Names and Placement 

For instance, packers like Themida/Winlicense often have sections with random names or blank spaces as section names (example). The image below shows that Sections #4 and #5 have random names, while sections #0 and #3 contain blank spaces instead of names.

In VMProtect, the section addresses in the file (specifically the PointerToRawData field) are often set to zero (example).

In the image above, for sections #0 through #5, PointerToRawData is set to zero, which suggests that unpacking occurs dynamically at runtime.

Unusual Imports

The absence or minimal number of imports suggests that libraries are loaded, and their function addresses are acquired dynamically at runtime. 

For .NET applications, a single import (mscoree.dll:: _CorExeMain) is typical. In some cases, a unique mix of functions can reveal the application’s intentions.  

For instance, let’s open the Static Discovering window inside the ANY.RUN sandbox for this UPX sample and go to the Imports section. 

Then, let’s search for KERNEL32.DLL.

The combination of LoadLibraryA and GetProcAddress indicates dynamic library loading, while VirtualProtect may suggest an intention to change memory page protection to executable.  

Since only four functions are present here, this combination is unlikely to be coincidental and can signal intentional manipulation for code execution. 

High Entropy 

For unpacked files, the overall entropy typically ranges from 5 to 6.5. Packed  files, however, often exhibit entropy levels above 7, approaching 8 (the maximum  entropy for 8-bit data).  

High entropy values can indicate packing or encryption, as they suggest a lack of readable patterns within the file.

This entropy level can be checked using tools like DiE (Detect it Easy). 

You can also check it right inside the ANY.RUN sandbox.

Unpacking Different Types of Packers 

There are two main types of unpacking: 

1. Static unpacking: The code is processed by the unpacker but not executed. This method relies on analyzing the packed file without running it, allowing for a safer examination. 

2. Dynamic unpacking: The code is executed and preserved by the unpacker in memory. This approach involves running the packed malware in a controlled environment, often in a sandbox, to observe the unpacked code in action. 

Dynamic unpacking is the most challenging type of unpacking, as it often requires the use of a debugger and capturing memory dumps.  

This approach allows analysts to observe how the code behaves at runtime, but it demands a controlled environment and more advanced tools to monitor and extract the unpacked code accurately. 

To make the process of the analysis easier and faster, you can utilize ANY.RUN’s Interactive Sandbox. It provides memory dumps of unpacked and decrypted data, including the decrypted executable payload. 

The sandbox generates memory dumps for various processes and makes them available for download, saving analysts significant time and simplifying the analysis process. You can download these memory dumps and analyze them locally.  

There are two options for accessing memory dumps generated inside ANY.RUN’s sandbox. 

You can access them by clicking on the DMP button in the process tree section. 

Alternatively, you can go to “Advanced Details” of a process that has the DMP icon next to it and navigate to the “Process dump” section, where you can download the dumps.

Let’s now see how you can address different types of packers.

SFX Installers 

SFX (Self-Extracting Archives) is an archive format that, when executed, extracts files and can perform specific actions. In most cases, these archives can be unpacked statically with utilities like 7zip or WinRAR. 

To see a typical SFX in action, let’s consider the following sample.

Such archives often have a distinctive icon, indicating they are self-extracting executables: 

Use WinRAR to open the archive and view the extraction settings and packed files within the SFX. 

After opening the file, on the right side, you’ll find extraction parameters, file paths, and the primary executable file. On the left, you can view all files packed within the archive. 

MSI Files

To unpack MSI files, a common method is using the command line with msiexec /a. However, this method may not work for every file and can sometimes result in errors.  

For instance, with the following sample, attempting this command in a sandbox triggers an error (see sandbox example). 

An alternative solution is LessMSI, a specialized tool for extracting files from MSI packages. 

Let’s see how it works this using the following sample.  

Upload the LessMSI archive to a virtual machine in ANY.RUN via the upload button. 

Launch the GUI version of LessMSI and select the MSI file. Next, the program will display a list of files and their paths for extraction. 

Nullsoft Installer 

Nullsoft installers are often straightforward to unpack using 7zip. By opening these files with 7zip, you can directly access the contents of the installer. 

Let’s examine this sample for more details.

Opening the archive in 7zip reveals the files packed within it, including special directories that typically start with the $ symbol. 

This approach allows you to explore the installer’s files easily. However, a limitation is that it doesn’t reveal the initial installation parameters, which may be necessary for deeper analysis. 

InnoSetup 

Unpacking InnoSetup installers requires specialized tools. The unpacking becomes more challenging because these files often contain embedded scripts that control the installation process. 

In this case, 2 useful tools can be used: 

• innoextract: A command-line tool designed to extract files from InnoSetup packages. 

• innounp: Another tool that offers similar functionality, supporting various versions of InnoSetup. 

Let’s consider this sample. 

Start a virtual machine with the necessary utilities and unpack innoextract. 

As a result, we’ll obtain several directories. The main one is appRedist, which contains the executable file. 

Additionally, files such as help documents, libraries, samples, and other related resources are extracted.

Registry data entries are extracted separately as well. 

The app directory contains files unpacked by the installer. 

The reg$HKCU directory contains data entries that are added to the registry under CURRENT_USER. 

Innounp works in a similar way. 

As a result, application and registry data are extracted.

The advantage of this utility is that it restores the installation script and saves it in a file. 

We can open this file in a notepad. 

The [Run] section contains information about the files that will be executed after unpacking. 

NSIS + ASAR 

It’s worth mentioning the SFX archives used by Electron.js. 

Let’s consider this example. 

Download the EXE file and start the unpacking process. 

When extracting with 7zip, we obtain a folder containing various files, including an archive with a renamed Chromium executable (in this case, Runtime Broker.exe) and its libraries. 

The Electron.js application data is stored in the resources directory. 

The app.asar file is an archive containing the Electron.js application data. 

To unpack it, you’ll need an npm module. 

• Install npm: sudo apt install npm 
• Run the following command to extract the archive: npx @electron/asar extract app.asar extracted 
• If the asar module isn’t already installed, npm will prompt you to install it. 

As a result of running the command, the archive will be unpacked into the extracted folder. 

The node_modules folder contains the Node.js packages, and index.js is the initial script of the application. 

UPX 

UPX (Ultimate Packer for eXecutables) is a packer for executable files. 

• Compatibility: It supports only native PE (Portable Executable) applications. 

• Unpacking: UPX-packed files are often easy to unpack statically using the same UPX utility. 

To unpack a UPX-packed file, you only need to use a single command:

upx –d <file> 

UPX can be identified by the presence of sections named UPX0 and UPX1 in the file. 

Let’s observe it with the following sample.

First, download the sample and open it in DiE (version 3.10). DiE will indicate the presence of UPX, listing specific indicators. 

Some malware samples use older versions of UPX. In such cases, you’ll need the corresponding version to unpack them. DiE suggests the recommended version, which, in this example, is 3.96. 

To analyze a sample like this, it’s essential to remove the UPX compression; otherwise, the disassembler won’t be able to interpret the code correctly. 

For instance, Ghidra—a free disassembler and decompiler—will display multiple errors when importing a compressed file. 

During analysis, Ghidra will detect only a single function. The built-in decompiler will report the incorrect code.

In the image above, on the left side, there is a Listing displaying the single function, while on the right side, the Decompiler window shows an error message.

To conduct analysis, download the latest release of UPX from GitHub.

Next, upload the sample along with the upx.exe file (it’s not necessary to upload the entire archive) to the virtual machine. 

To do this, switch to the Pro mode in the sandbox and select Tools collection. Here, you can either use previously uploaded tools or upload new ones. 

Before starting the analysis, enter the “cmd” command in the Command line field. This will prevent the sample from running automatically and will open the console at the start of the session. 

All further steps are carried out in the following analysis session. 

Unpack the UPX archive and enter the following command in the console:

<path_to_upx>upx.exe -d <filename> 

As a result of the command execution, the file will be overwritten with the decompressed version. 

To ensure the unpacked sample is functioning correctly, let‘s run it in a sandbox. 

When clicking the PE button, the Static Discovering window opens, where we can observe a different hash. 

The Static Discovering window for the unpacked file, shows the name under which it was saved to disk. We can see a decrease in entropy, an increase in file size, and a different hash value.

Now, Ghidra can handle this file without any issues.

In the Listing section, we see numerous references and functions, and the Decompiler window displays the correct code.

The same process can be done on a physical machine, as UPX does not execute code during unpacking. 

AutoIt 

AutoIt is often used as a crypter. The simplest way to detect AutoIt is by checking the file description. To do this, go to the Main tab in the Static Discovering window inside ANY.RUN and scroll down. 

You may find different mentions of AutoIt in the description. 

Let’s consider the following sample.

Here is another example. Usually, such a file is an AutoIt interpreter bundled with a script. 

In some cases, a deeper examination is required. Let’s look at the following example.

In this example, AutoIt was detected by ANY.RUN’s sandbox. Let’s confirm this in DiE. 

To extract and decompile the script, we can use AutoIt-Ripper. 

Let’s install it using pip install autoit-ripper.  

The latter is quite easy to use:

autoit-ripper <file> <output_dir> 

As a result of running the command, the restored script is saved to a file named script.au3. Besides, all the associated files were detected and saved. 

Now it’s possible to analyze the script’s actions by opening it in a text editor. 

In this example, we see the execution of CL_Debug_Log.txt with specific parameters. 

Opening CL_Debug_Log.txt in DiE reveals that it is a standalone version of 7zip.  

In this way, the malware unpacks the files necessary for its operation. In addition, the script contains checks for execution in a virtual environment. 

It also includes checks for the presence of antivirus software. 

NetReactor 

NetReactor is a packer and obfuscator for applications written in .NET. 

• Supports code virtualization. 

• Files and libraries are not saved to disk but are loaded directly into memory. 

• Changes the structure of the code, making analysis more difficult. 

Most files can be successfully unpacked using NetReactorSlayer, but for the best results, dynamic unpacking is recommended. This method executes the code within the operating system, allowing system functions to be called as needed for a more accurate unpacking process. 

Let’s look at an example with the PureHVNC payload.

Next, run the analysis session using dnSpy and NetReactorSlayer.  

dnSpy is no longer maintained; however, you can download a forked version. 

Then, open the sample in dnSpy. 

Before processing, you can see numerous namespaces. 

Let’s locate the configuration class. 

Open Type References and locate the IPAddress class. 

Right-click on it and select Analyze. 

In the opened window, click on Used by to find the method where this class is used. 

Now, open NetReactorSlayer and select the sample. 

There are multiple settings available; the default settings work well for this purpose. 

Click Start Deobfuscation and wait for the process to complete. 

The program decrypts strings, simplifies the code, and even attempts to remove virtualization. 

The file is saved with the suffix _Slayed. 

Now, open the received file in dnSpy. As a result, the unnecessary namespaces have been removed. 

The classes have been renamed too. 

Next, let’s look for the usage of IPAddress as well. 

The lengthy class names have been shortened, and the fields have been renamed according to their respective values. The code has become easier to analyze, and string literals are now included. 

Often, in addition to being packed, malware is stored in an encrypted form within a special loader (crypter). 

This analysis demonstrates the process of extracting the payload using dnSpy. 

After execution, the crypter decrypts the payload and performs an injection into the target process. 

With the help of dnSpy, let’s attach the debugger to the process. To do this, go to the Debug tab and click on Attach to Process. 

Then, choose the process you want. 

Note that to debug 32-bit processes, you should run dnSpy x86, and for 64-bit processes, use dnSpy x64. 

Pause the process and open the Modules window. 

Right-click on the main module, then select Open Module from Memory.

After opening the module, obfuscation can be observed. 

Click Save Module and transfer the saved file to the console version of NetReactorSlayer. 

As a result, we get the following output. 

NetReactorSlayer corrected the entry point, removed unnecessary code, and saved result to disk as InstallUtil_Slayed.exe. 

The associated library MessagePack.dll has been saved as a separate file. 

Now, the payload InstallUtil_Slayed.exe can be run separately and analyzed through debugging (See sample analysis). 

SmartAssembly and Other .NET Packers 

Another popular packer for .NET applications is SmartAssembly. 

Check out this example.

Besides obfuscating the code (which makes the execution order unclear and renames identifiers to unreadable terms), SmartAssembly complicates analysis with a large number of delegates that are resolved at runtime, including those used for decrypting strings. 

Let’s open the sample in DiE and confirm the presence of the protector.  

We can see how DiE detects Protector Smart Assembly. 

In the US (User Strings) tab, there is an abnormally small number of strings.

Let’s switch to dnSpy. 

Upon opening the sample, you will immediately notice an attribute indicating the presence of the SmartAssembly protector.

You will also notice the characteristic namespaces associated with SmartAssembly.

These artifacts are quite common among protectors, particularly in .NET applications. 

Next, click on Go to Entry Point. 

In this case, while the code (control flow) is not obfuscated, the strings are obtained through a delegate call with a numeric argument. 

Earlier, we used NetReactorSlayer to remove the protector. 

While it is a specialized tool, it can also be used for general purposes, such as simplifying code, though with some limitations. 

Let’s try to simplify the code using NetReactorSlayer. 

While this tool simplified the code readability, it was unable to decrypt the strings. 

Now, let’s use another tool—de4dot—which is also part of what NetReactorSlayer uses for code simplification. You can also utilize de4dot-cex, which is the improved version of de4dot. 

For this case, we will use de4dot to remove SmartAssembly. 

As a result, the file is processed in a similar way. 

However, the string encryption has also been removed. 

The GetString delegates have been replaced with string literals. 

In DiE, you can view all the decrypted strings. 

The processed file often retains functionality and can make runtime analysis easier. 

de4dot works with many other protectors and can simplify code analysis. 

If de4dot doesn’t succeed, try using NetReactorSlayer, which may be more effective at further simplifying complex code. 

However, for older versions of NetReactor (below 6.0), de4dot remains the preferred option. 

Themida, VMProtect 

Themida and VMProtect are packers and obfuscators for applications that support virtualization and code mutation. 

• Virtualization: This feature protects the malware code at runtime, not just in static analysis. 

• Extracting Samples: In most cases, virtualization is not applied, allowing an unpacked sample to be extracted from memory, though it may be partially modified. 

• Static Unpacking: This is generally unlikely, as these commercial packers adapt quickly to new analysis methods. 

For a more detailed analysis, refer to our article: VMProtect and Themida Malware Analysis. 

About ANY.RUN  

ANY.RUN helps more than 500,000 cybersecurity professionals worldwide. Our interactive sandbox simplifies malware analysis of threats that target both Windows and Linux systems. Our threat intelligence products, TI Lookup, YARA Search and Feeds, help you find IOCs or files to learn more about the threats and respond to incidents faster.  

With ANY.RUN you can: 

• Detect malware in seconds. 
• Interact with samples in real time. 
• Save time and money on sandbox setup and maintenance 
• Record and study all aspects of malware behavior. 
• Collaborate with your team 
• Scale as you need. 

Request free trial → 

The post Packers and Crypters in Malware <br>and How to Remove Them appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

In June 2024, security researchers published their analysis of a novel implant dubbed “MuddyRot”(aka “BugSleep“). This remote access tool (RAT) gives operators reverse shell and file input/output (I/O) capabilities on a victim’s endpoint using a bespoke command and control (C2) protocol. This blog will demonstrate the practice and methodology of reversing BugSleep’s protocol, writing a functional C2 server, and detecting this traffic with Snort. 

Key findings 

• BugSleep implant implements a bespoke C2 protocol over plain TCP sockets. 
• BugSleep operators have demonstrated multiple file-obfuscation techniques to avoid detection. 
• BugSleep implements reverse shell, file I/O, and persistence capabilities on the target system. 

Sending and receiving data 

This blog will use sample b8703744744555ad841f922995cef5dbca11da22565195d05529f5f9095fbfca for analysis. Two of the lowest functions in the C2 stack, referred to as SendSocket (FUN_1400034c0) and ReadSocket (FUN_140003390), are very light wrappers for the send and receive API functions and handle payload encryption. They include some error handling by attempting to send or receive data 10 times before failing.  

This protocol uses a pseudo-TLV (Type Length Value) structure with only two types: integer or string. Integers are sent as little-endian 4- or 8-byte values, and strings are prepended with the 4-byte value of its length. Payloads are then encrypted by subtracting a static value from each byte in the buffer (in this sample it is three).  

Type	Value	Plain text	Cipher text
IntegerMsg	6	06 00 00 00	03 FD FD FD
StringMsg	Talos	05 00 00 00 48 65 6C 6C 6F	02 FD FD FD 51 5E 69 6C 70

Figure 1: Example of data encryption used by BugSleep

There are two main functions for handling C2 communications: C2Loop (FUN_1400012c0) and CommandHandler (FUN_1400028a0). C2Loop is responsible for setting up socket connections with the server and sending a beacon, while CommandHandler is responsible for processing and executing commands from the server. 

After setting up the socket connection, the implant beacons (FUN_140003d80) to the C2 server for a command. The beacon is a StringMsg in the form ComputerName/Username. If the server responds with an IntegerMsg equal to 0x03, BugSleep will terminate itself. We suspect this is remnants of an old kill command or an emergency kill without the overhead of reading the real kill command later. 

Each BugSleep command is sent as an IntegerMsg after the beacon response. The following enumeration defines all the command IDs discovered. 

Phoning home 

The implant communicates using plain TCP sockets, which can be seen using a Netcat listener and Wireshark. 

Recalling the message encryption demonstrated in Figure 1, the beacon can be decrypted with a little bit of Python (Figure 4). This will be used again when building the rest of the C2 server.  

Python C2 server 

With an understanding of the protocol basics, it is time to start building the C2 server. Full source code can be found here. 

Beacon 

As mentioned earlier, the BugSleep beacon function sends a StringMsg and reads an IntegerMsg response from the server. Since the IntegerMsg returned can be anything but 0x03, we returned the length of the Computer Name/Username string received by the server.

Ping command 

The simplest command to implement is the Ping command. It has the command ID of 0x63 (BugSleep subtracts one from whatever ID it receives). The code is simple: send back 4 bytes.  

Once the beacon comes in, the server is responsible for: 

1. Sending 4 bytes for beacon response 
2. Sending 4 bytes for Ping command ID 
3. Reading 4 bytes of Ping data 

The ping command was observed sending back 4 bytes recently allocated on the heap, so it’s not guaranteed to know what that data looks like. To validate things are really working, a breakpoint can be set in WinDbg and memory set manually before being sent. 

File commands 

The next set of commands are responsible for downloading files onto the compromised system or uploading files to the C2 server (PutFile and GetFile, respectively). These commands are inverses of each other, so only the GetFile command will be discussed in detail. The methodology was to trace each call to SendSocket or ReadSocket and implement the response for that call in Python. In CommandHandler, the implant reads the length and value off the wire. This is the file to be retrieved.  

The CmdGetFile function opens the target file and chunks it over the socket one page at a time. The list of SendSocket calls is as follows: 

The PutFile command differs slightly from the GetFile command with how it uses pointer math to process incoming pages. 

This translates to each page starting with a 4-byte page number followed by 1020 bytes (or 0x3fc) of file data, which the GetFile command does not do; it sends full 1024-byte pages of file data without page numbers. 

Reverse shell 

The last command is the reverse shell. This is the most complex because it requires many reads and writes over the socket. The disassembly is rather long and difficult to keep track of the socket calls, so we have omitted it. Effectively, the implant spawns a cmd.exe process (FUN_1400016e0) and reads the command to execute from the socket. The shell command and its output are marshaled between the processes via pipes during the session. The complexity of this operation comes from BugSleep incrementally reporting return values from pipe API calls while attempting to read shell output (FUN_140003840). The implant will enter this loop of reading commands and sending output until it receives the string “terminaten”.  

The rest of the commands are less complex but have been implemented and are viewable here. 

Snort detection 

This server gives Talos the ability to emulate any number of conversations between BugSleep and its operators. This traffic is crucial for writing and validating our detections’ performance in the wild. 

The initial candidate for detection would be the beacon. It is the first opportunity to shut down communications, isolating any BugSleep instance from receiving commands. It was observed that each beacon has the form of <len><data>, where data is sub_string(COMPUTER_NAME + “/” + USERNAME, 3). This string is not long or static, which makes it a poor candidate for a fast_pattern; however, recall that each beacon is prepended with a 4-byte length of this string. A Computer Name/Username string from any given victim is unlikely to be longer than 255 characters. This means most length fields are going to look like |XX 00 00 00| or |XX FD FD FD| when encoded. This could be a quick match, early in the stream, at a static offset, making it a decent fast_pattern candidate. 

 This will work but is likely to cause false-positives (FP) in the wild. Every sample of BugSleep was seen using port 443. The implant is also reaching outside the network to a C2 server, so traffic to be inspected by this rule can be reduced using the following header: 

The flow:to_server,established option can be used to restrict Snort to data coming from a client over established TCP streams. The FP-rate on this rule still isn’t great. Any TCP traffic leaving the network on port 443 with |FD FD FD| at offset 1 will alert. That might sound unique, but it does not indicate with confidence that the traffic is a BugSleep beacon. 

One powerful tool in Snort to add more logic or state to rules is flowbits. These allow a writer to have a sense of state within a stream across multiple rules. In this case, the beacons aren’t enough to reliably alert on. What if we use flowbits to chain beacons with the commands being sent back? The commands themselves don’t provide much content, as they are variable length non-deterministic strings (e.g., get, put, etc.) or a nondeterministic 4-byte integer (e.g., heartbeat, increment timeout, etc.). They do, however, all start with a 4-byte command ID. Setting a flowbit when a beacon leaves the network will allow another rule down the line to alert with higher confidence if it sees a command ID come back in the same stream. 

Command rules 

The pcre rule option can be used to reduce 11 rules down to one. Like the beacon rule, the three zero bytes, encoded as |03|, can be used as a fast_pattern. Once the rule has entered, the bugsleep_beacon flowbit check can be performed to help the rule exit quickly in the event of a false positive. After the three |03| bytes are confirmed to be at offset five, a PCRE can verify one of the command IDs is present.  

Sharp edges 

Sometimes, we are reminded that Snort can handle or interpret data differently than expected. Conveniently, this sample’s traffic was a perfect example and opportunity to peek under the hood and see what Snort sees. Originally, our beacon rule looked like this, trying to catch the encoded forward-slash that is always present in the Computer Name/Username string (encoded as a comma).  

Recall that the implant will: 

1. Connect to the server 
2. Send a string length (4 bytes) 
3. Send the PC/User string N bytes 
4. Read 4 bytes back to ensure a response 
5. Read 4-byte command ID and N command data bytes 
6. Start sending command responses 

As Snort is reading data over the wire, it is interpreting it and sorting it into different buffers (pkt_data, file_data, js_data, http_*, etc.). In this case, as TCP data is being chunked along the wire, Snort is looking at those individual TCP segments. Only after it has enough data will it flush into the larger “TCP stream” buffer so a rule can parse the entire stream sent from a client or server. 

Initially, the get command traffic was alerting while the put command traffic was not. Fortunately, Snort 3 comes with a tracing module to help debug these issues. The buffer option will print out Snort’s different buffers as they are filled and rule_eval will trace the rule as it is evaluated. The following screenshots are output from individual runs of Snort against each PCAP. “snort.raw” represents an individual packet, while “snort.stream_tcp” represents a reassembled TCP stream. 

At the start of the working GetFile command, the beacon size and data can be seen as two separate packets (Figure 17).  

Further down, the reassembled TCP stream can be seen being inspected and alerted on. Moving from the top to bottom in Figure 18, the cursor position and state of the buffer can be observed changing as the rule is evaluated. At the end, the flowbit is set and made available for the command rule.

Further down, the TCP stream for the command data is processed. The higher-order zeroes of the command are found, the flowbit checked, the PCRE performed, and the SID alerts as expected.  

When the results of the put file command traffic are inspected, a different behavior is observed. The individual packets for beacon length and beacon data are seen coming in; however, the first reassembled TCP stream that Snort is inspecting is the command being sent back to the implant. Figure 20 shows the command ID being found and then the flowbit check failing. 

Scrolling further in the log reveals the TCP stream for the beacon data is eventually populated and Snort sets the flowbit as expected. The stream for the command ID, however, has already passed and failed analysis because of the unset flowbit, resulting in no alert. The cause of this issue is the raw packets coming from the client not being reassembled into a TCP stream by the time the server packets are reassembled and inspected. This happens because Snort only reassembles when it has enough data, and 20 bytes is not enough yet. 

The fix 

Unfortunately, the beacon rule must be tweaked so it can alert as soon as possible and not rely on the TCP reassembly. Recall that the beacon function invokes SendSocket twice, once for 4-length bytes and again for the beacon data. This means the first packet Snort sees will only be 4 bytes long. Adding “bufferlen:=4” restricts Snort to only look at 4-byte packets, significantly reducing any FP rate. Our solution ended up being this:  

 Now the rules work as expected!  

Conclusion 

Since BugSleep is a new implant and weekly releases were observed being deployed, this protocol might change and bypass these rules. However, two things have been accomplished: 

1. This variant will no longer communicate over our customers’ networks. 
2. Attackers must invest development time and money to use BugSleep again. 

The published Snort SIDs covering this traffic are 63937 and 63938.  

Indicators of compromise 

Hosts: 

• 1[.]235[.]234[.]202 
• 146[.]19[.]143[.]14 
• 46[.]19[.]143[.]14 
• 5[.]239[.]61[.]97 

Hashes 

The following Windows executables were collected during our research. Assuming these have not been manipulated, the compilation time for this set of binaries indicates weekly releases of BugSleep. 

SHA256	Compile Time
b8703744744555ad841f922995cef5dbca11da22565195d05529f5f9095fbfca	Wed., May 8 00:55:53 2024 UTC
94278fa01900fdbfb58d2e373895c045c69c01915edc5349cd6f3e5b7130c472	Wed., May 22 21:56:39 2024 UTC
73c677dd3b264e7eb80e26e78ac9df1dba30915b5ce3b1bc1c83db52b9c6b30e	Fri., May 31 23:29:21 2024 UTC
5df724c220aed7b4878a2a557502a5cefee736406e25ca48ca11a70608f3a1c0	Sun., Jul 07 21:09:49 2024 UTC
960d4c9e79e751be6cad470e4f8e1d3a2b11f76f47597df8619ae41c96ba5809	Sat., Jul 15 09:15:20 2079 UTC

 

Cisco Talos Blog – ​Read More