Atrax is a malware discovered during the summer of 2013. It includes some basic features like distributed denial-of-service, keylogging, the ability to steal banking credentials, to send spam or to install a Bitcoin miner for crafting bitcoin money. The particularity of Atrax is that it communicates with command and control server over TOR, which is a protocol that enables online anonymity. An ESET blog post has been made to give more information about this tor based botnet: http://www.welivesecurity.com/2013/07/24/the-rise-of-tor-based-botnets/.
Atrax’s specification highlight us about anti-analyzer technics:
- Anti-Analyzer (Protection against e.g. anubis.iseclab.org, malwr.com)
- If you need: Anti-VM (Please request it explicitly)
- Anti-Debug/Anti-Hook Engine
The sample we studied was seen in the wild in April 2014 and submitted to the VirusTotal web site (https://www.virustotal.com/en/file/adf246a57baecef5c8c85c60152e9b2f5060bf2e720ad1623cc95177e7259401/analysis/).
We choose to analyze the Atrax botnet in the process of our permanent security monitoring, in order to be sure that our best of breed HIPS engine is able to block new technics used by hackers. This article is not a full analysis of the malware, it chooses to focus on the capabilities to do not be detected or analyzed.
We started by looking at the anti-sandbox capability. To obtain a fast dynamic analysis of a potential malware, many online services provide sandbox capabilities to give you a deeper look of what the application is doing on the operating system: the principle is to start the malware execution in a virtual machine to trace its behavior. At the end of the timeout the service provides a report and sets the virtual machine to its initial state for the next analysis. In this way, we can quickly know if a binary file is malicious or not. Malwares now try to detect this kind of sandbox to be sure that people couldn’t analyze the behavior of the malware or that security solution couldn’t block it proactively.
To test the protection mechanism of Atrax, the sample was submitted to multiple online sandboxes:
- Anubis http://anubis.iseclab.org/: when executing, the binary file crashes (STATUS_ACCESS_VIOLATION) preventing behavioral analysis. It is a normal behavior of Atrax when it detects online sandbox. The virtual machine was not infected.
- Malwr http://malwr.com: the binary file runs normally, the virtual machine was infected.
- JoeBox (CWSandbox / File-analyzer) http://file-analyzer.net/: The binary file runs normally, the virtual machine was infected.
- Comodo http://camas.comodo.com: the binary file runs normally, the virtual machine was infected.
Except Anubis, it becomes clear that the detection of sandbox is not fully functional. This dysfunction is due to the method used for environment fingerprinting. Atrax simply looks for the
ProductId of the operating system.
ProductId is a unique value of 20 digits which is derived from the product key and the hardware configuration. This key is just displayed to user for information. It can be used when you contact the Microsoft Support. This key is stored in the registry key located here:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId. You can display it by right-clicking My Computer and selecting Properties:
Because it is unique, this key enables identifying the computer. However it is possible to alter this key without having any instability.
Atrax has an hardcoded list of ProductId keys:
- 1: 76487-640-1457236-23837
- 2: 76487-644-3177037-23510
- 3: 55274-640-2673064-23950
- 4: 76497-640-6308873-23835
- 5: 76487-640-1464517-23259
If it finds one these values, its means that the actual environment is an online sandbox and Atrax process exits with an access violation.
In order to check the correspondence of these values, we developed a test program that display the ProductId value of the sandboxes available on Internet.
Some sandboxes report screenshots of the virtual machine, so it is easy to check the ProductId with a MessageBox. For sandboxes which do not report screenshot, the binary file creates a text file with the ProductId as filename.
long lResult =
RegOpenKeyEx(HKEY_LOCAL_MACHINE,L"Software\\Microsoft\\Windows NT\\CurrentVersion",0,KEY_QUERY_VALUE,&hkey );
if(ERROR_SUCCESS == lResult)
if(ERROR_SUCCESS == lResult)
// Key found
found = _tfopen(data, TEXT("w"));
With this trick, we have determined that the first key (76487-640-1457236-23837) is the ProductId of Anubis sandbox. This is why the execution inside this sandbox turns into STATUS_ACCESS_VIOLATION.
The second and third keys do not work due to updated sandboxes. These keys are some kind of signature that matches CWSandbox and JoeBox.
76487-644-3177037-23510: matches CWSandbox.
55274-640-2673064-23950: matches JoeBox.
CWSandbox and JoeBox now appear to be a single product: JoeSecurity is accessed through the URL http://file-analyzer.net/. JoeSecurity now automatically generates a new key for each run, making the two previously known keys obsolete. But strangely they are a recognizable pattern easy to detect. For example:
Funny fact, during our tests we have to submit several times our fingerprint executable to be sure that the ProductId is unique at each run. This apparently did not please JoeSecurity and our IP address was simply banned from the server.
The last two keys
76487-640-1464517-23259 are less common and seem to be related to old instances of Malwr sandbox. Today Malwr generates a unique key for each run with no identifiable pattern:
In addition, although it is not implemented into Atrax, it is possible to detect if an executable file has been uploaded to VirusTotal; the sandbox associated to the “Behavioral information” section has always the same ProductId:
As we can see, this technique is not really efficient for multiple reasons. First, because it is easy to implement a mechanism to auto generate a ProductId for each run. We tried to edit the ProductId of Windows 7 and Windows Update was fully functional. Moreover, looking at this registry key can be detected as a malicious behavior. It is not common for an executable file to look for the ProductId of the operating system.
Security products detection
Atrax also checksif security productshaveinjectedcode in therunning process of the malware.
To do this check, it uses a well-documented technics:
- It finds PEB (Process Environment Block address) (instruction
mov eax, fs :0x30)
- It looks for
Ldr(LoaderData) in PEB (instruction
mov ecx, [eax+0x0C])
- It finds the
InLoadOrderLinkslist which contain all the module loaded by the running process (instruction
mov edi, [ecx+0x0C])
- It browses
InLoadOrderLinksand compares it to some values.
For more information about this method: http://phrack.org/issues/65/10.html,
Atrax looks for the following loaded binary files to detect if a security product monitors the current application:
Sbiedlldll: Sandboxie (http://www.sandboxie.com/);
Snxkh.dll: Avast! (http://www.avast.com/en-us/index);
Dgbhelp.dll: ThreatExpert (http://www.threatexpert.com/);
This technique is limited to a few security products but does not prevent detection by antivirus.
Atrax uses 3 different technics to check the presence of a debugger.
The first way to do it involves using the
NTSYSAPI NTSTATUS NTAPI ZwSetInformationThread(
IN HANDLE ThreadHandle,
IN THREADINFOCLASS ThreadInformationClass,
IN PVOID ThreadInformation,
IN ULONG ThreadInformationLength
ThreadInformationClass is set to 0x11 (
ThreadHideFromDebugger), any debugger becomes blind to actions performed by this thread.
The second way to bypass debug involves using
ZwQueryInformationProcess in order to find a debugger.
TSTATUS WINAPI ZwQueryInformationProcess(
_In_ HANDLE ProcessHandle,
_In_ PROCESSINFOCLASS ProcessInformationClass,
_Out_ PVOID ProcessInformation,
_In_ ULONG ProcessInformationLength,
_Out_opt_ PULONG ReturnLength
ProcessInformationClass is set to
ProcessInformation is set to
-1 when the process is being debugged.
Finally, Atrax uses the classical
IsDebuggerPresent function call which looks for the
BeingDebugged flag inside the PEB. If
BeingDebugged equals 1, the process is debugged.
Malware’s specifications refer to VM detection. This functionality seems not to be included into the sample that has been studied but we can find some significant strings inside the binary file:
It looks like some codes about VM detection is present but after static analysis we saw that this part of code is never called.
In this post we have seen that an effort was made to detect security products but the detection of analysis environment are not really well implemented. One year after malware launch, it’s fully detected by the sandboxes and the tricks used here are not efficient.Yet there are a huge number of tricks documented on the Internet for anti-debug, anti-VM and anti-analysis. Atrax uses only the most basics tests.