Beep Malware: static and dynamic analysis

Important elements of the analysis:

Anti-analysis techniques
Anti-debugging techniques
Process hollowing through the process WWAHost.exe
Advanced evasion techniques
DLL dropping and exports
Environment information gathering routines
Files gathering loops routines
Command and Control connections

Introduction

In the present analysis, a sample of Beep malware with hash ab5dc89a301b5296b29da8dc088b68d72d8b414767faf15bc45f4969c6e0874e was taken in consideration. The threat in question has become rather well known within the security community due to the fact that it uses multiple and advanced anti-VM, anti-debugging, evasion, and anti-analysis techniques. The malware performs the dropping of an additional downloaded and executed malicious DLL library and executes injection tasks through the use of process hollowing techniques, via the WWAHost.exe process. A particular and curious detail concerns the fact that Beep malware uses the system beeping function in order to identify the execution environment in case it is a virtualized environment, for example virtual machines or sandboxes. [0]

The purpose of Beep Malware is to perform, during its Cyber Kill Chain, the theft of files, personal data of the victim, details and information of the environment in which it runs (such as performance counter time intervals) and transmit them to a remote server of the malicious actor. The hardware and environment awareness details of the compromised machine are used both to identify the type of the infected machine and to deduce whether it is a virtualized environment or not.

TTPs Matrix

Static and dynamic analysis

The sample has been compiled in C++ and the entrypoint has been set to the address 10004268:

This is followed by details of the memory mapping of the PE, where the presence of the .gfids section, containing details of the compilation configuration of the PE, can be seen:

Within Beep malware exports, the following suspicious items are highlighted with their relative RVAs (relative virtual memory addresses):

In the functions detectable from the import performed by the executable there are details of file creation, thread creation and activation of execution contexts (via the functions CreateActCtxA and ActivateActCtx):

Below is a detail on the DecodePointer function, which can be used to decode previously encoded pointers in order to hide the values of pointers objects:

Checking the manifest of the PE reveals a setting requestedExecutionLevel “asInvoker”, so it uses of the user’s default security settings:

Here are some suspicious strings that can be extracted from the sample, as well as a reference to the advapi32 library, which can be used to manage the registry and control specific registry keys inherent to VirtualBox:

Through the strings extracted from the threat there are references to the bxl220wm49.dll library and export items, as well as the aforementioned evidences CreateActCtxA and ActivateActCtx:

The exported entry KRsvHAq has compare instructions and a conditional jump instruction jl, which performs a “conditional jump” with sign comparison in the event that the second operand is smaller than the first one:

There is also a xor instruction between parameters 0E4Bh and the edx register. The xor instruction is used for dynamic deobfuscation tasks, which indicates an additional element of anti-analysis in static terms:

A fundamental detail inherent in the functions called by Beep Malware lies in the fact that it uses the functions QueryPerformanceCounter, GetSystemTimeAsFileTime in order to check the type of execution environment and thus verify whether it is taking place in a virtualized environment or not.

An analysis of the entropy of the PE shows that the .text section, which contains executable CPU instructions, is in a “packed” status, so several details obtainable from an assessment or static analysis are not easily intelligible:

The function CreateActCtxA is called in the label loc_1000E861, thereafter there are references to xor operations between the edx and eax registers with the values 4Fh and 138h respectively, this is done within an execution stream previously called at the label loc_1000E861:

Here a detailed reference to the IsDebuggerPresent function, which can be used for anti-debugging and debuggers checking:

Further evidence related to exported items follows; in the item HwjP316n31 there is a call to it, this is executed based on a cmp instruction between the values edx+0BCh and the eax register

The exported entry KRsvHAq saves in the attributes arg_4, arg_8, arg_14 and arg_18 certain hexadecimal values which are used in conditional flows, after which the labels loc_1001143D or loc_1001144B respectively are called:

The PLWQ7G9 exported entry calls a number of functions, including sub_10013310 following push and lea operations, which are used in order to save certain memory addresses, for example, ebx+1DFh in the eax register, the function sub_10001160, but above all within the function sub_10001780 the exported entry Ymkg06Q0r is called

Following is an evidence of a call to the SuspendThread function within the execution context of the function sub_10011920:

The Ymkg06Q0r module has additional XOR operations inherent in the edx, ebx, ecx and edi registers. The latter with the value 17C2h:

The presence of numerous external execution contexts, exported entries, and the decentralization of certain data stored in the registries, again denotes the desire to bypass the detection phase of security solutions with an anti-analysis approach, thus making the contextualization of the entire execution flow, as well as the assessment of the Portable Executable itself, more difficult.

An analysis of Beep’s source code reveals goto instructions to memory addresses called externally outside the while loop, where the value of eax57 is incremented with an offset of 12.

In the function DllRegisterServer(),is possible to identify the use of the variable v2 with the hexadecimal value 0x1636 for the external call of the function named fun_10003c30 for the purpose of recording exported modules.

At the same time as the ActivateActCtx function is called, the GetModuleFileNameA function is used, which can be called in order to obtain the path details of a module loaded by the current process.

Portable Executable assessment

By examining the most suspicious indicators of the Beep Malware sample, it is possible to become aware of several attributes: the export table, the presence of the DLL bxl220wm49.dll, registry management functions, file management, discovery, reckoning, and environment information discovery.

About the compilation metadata there is the evidence of “Export1400”, which is relating to Visual Studio 2015:

The sample has been compiled on 7th February 2023:

Here further references to the functions already mentioned above: in particular the functions SuspendThread, VirtualAlloc, QueryPerformanceCounter, GetSystemTimeAsFileTime, IsDebuggerPresent:

Big.dll uses the SetFilePointerEx function, which can be used in the context of file gathering loops without having problems with overlapped operations.

By analyzing the assembly listing of the malware, we can see numerous calling functions and concurrent JE (Jump Equal) instructions in order to create conditional flows:

Here are some details on the sections of the executable, where, by disassembling the .rdata section, some references to the functions CreateFileA (which can be used during malware dropping) and CreateActCtxA can be deduced.

A further assessment of the big.dll library reveals metadata information that can be associated with Borland Delphi 3.0:

Following are some references to the number of RVAs (Relative Virtual Addresses), the value of which is 10:

An inspection of the hexadecimal code of the Portable Executable reveals references to the library bxl220wm49.dll, the DLLs registration function DllRegisterServer and the function CreateFileA.

Debugging

Performing a debugging session of Beep reveals calls to the functions LoadLibraryExW, LoadLibraryExA and LoadLibraryA in order to load the main module into the running process:

By making calls to DLL Exports, the debugging process obtains details of the operating system’s folders.

In the screenshot below, several INT3 assembly instructions are observed, often related to anti-debugging contexts, as well as debugging checking:

Next, the ConvertThreadToFiber function is executed in order to initialize the thread management of competing malicious executions:

By dumping the running .text section during the debugging phase, we can see XOR operations of the EAX, EBX, EDX registers; as well as the execution of the SetFilePointerEx file pointing function:

The purpose of Beep Malware is to obtain, by means of file gathering cycles (through the use of functions such as SetFilePointerEx), the victim’s data and steal it through Command and Control connections, as evidenced by network communications in dynamic sandboxes detonations:

The IP address contacted by the sample is 37.1.215[.]220, which was registered by “3NT Solutions LLP” in the United States. It is associated with the domain webcam-inverted[.]holydithers[.]com and has numerous open ports and protocols used, including OpenSSH and Exim Smtpd (Mail Transfer Agent protocol):

IOCs:

ab5dc89a301b5296b29da8dc088b68d72d8b414767faf15bc45f4969c6e0874e
4f1c2f80f58c4730e37b445504018bb6
6132dc571dbc11298635e034d98b463c4edeb305
37.1.215[.]220
bxl220wm49.dll

Regola YARA:

rule BeepRule{

strings:

$beepString = ” bxl220wm49″

$beepHex = {62 78 6c 32 32 30 77 6d 34 39 }

$beepString1 = “KRsvHAq”

$beepHex1 = {4b 52 73 76 48 41 71}

$beepIP = “37.1.215.220”

condition: $beepString or $beepHex or $beepString1 or $beepHex1 or $beepIP }

CONCLUSIONS:

Beep Malware appears to be a very decentralized threat in terms of execution modules. It exploits DLL dropping and export operations in order to guarantee a deeper evasion phase. The malware uses both techniques common with other threats, such as anti-debugging and anti-analysis operations, and more sophisticated evasion and execution techniques that are difficult to detect. In the latter case, one cannot fail to mention Beep Malware’s ability to carry out process hollowing through instances of the WWAHost.exe process. This makes detection by an anti-malware or EDR solution more complex, as well as during logs inspection. Another important and unusual evidence relates to the fact that Beep malware uses the beeping system function to identify the virtualized execution environment; this could alternatively be done by checking specific executables within the C:\Windows\System32 system folder, or specific processes, services and registry keys. However, the choice made by Beep’s authors could be associated with the fact that the environment information gathering methodology used is more generalized and efficient in order to detect more types of virtualized execution environments.

It is not difficult to think that future threats may take their cue from the evasion methodology used by Beep and, at least potentially, this could open the door to the development of new threats that are even more advanced in terms of the infection chain, while using the same level of undetectable ability, making them increasingly effective and difficult to detect and contain.