Malwares often use Mutex to avoid re-infecting a system more than once. Recently, I was analyzing a Bazar Backdoor sample which is using a hard-coded mutex to prevent re-infection.
As we know Bazar Backdoor and Loader is now being associated with popular Trickbot malware family. The first instance was discovered in April 2020 and based on the initial infection vector, they are leveraging pandemic situation to target users working remotely. In this blog, I am sharing my findings by reversing a Bazar Backdoor sample:
Hash: 5974d938bc3bbfc69f68c979a6dc9c412970fc527500735385c33377ab30373a
In a summary, here are few actions this sample performs:
- Four or more anti-debugging techniques used.
- kernel32.Sleep used to suspend the state of a system.
- Environment variable set to ‘VERS’.
- Mutex is created with hard-coded value: ‘mn_185445’.
- Checks the language used on the system. Checks for text ‘United States_English’ and ’Russia’.
The compile time of this PE sample matches to the timeline of the initial discovery of this malware family i.e. April 2020. The output from the PEStudio shows the original compile time of the sample:
Just by glancing quickly at the list of API calls, it can be confirmed that the sample is using four or more anti-debugging mechanisms:
As usual, I loaded the sample in x64dbg and starting looking at interesting API calls piggy backed with Breakpoints to see process memory around these API calls. This sample seems to be difficult one as at some point while debugging the code, my malware analysis VM gets suspended abruptly.
During first few instances, I could not figured out the reason behind it but soon I stumbled upon a code as shown below which implements kernel32.Sleep.
You can read more about the function here:
I had to patch the code to prevent VM getting suspended. Moving further, it also creates an Environment variable(SetEnvironmentVariableA()) with value ‘VERS’. I am suspecting that it might use this value later down the road.
At some point during debugging, I noticed that the sample is calling an API function named CreateMutexExA(). As you can see in the below screenshot, it assigns the value as ‘mn_185445’. I was quite amused to see a mutex used by an advanced sample. To confirm if I get the same value every time, I re-ran the sample in several VMs and it gives the same value.
This can act as an Indicator of Compromise (IOC) since it is constant with this sample. We can also do hunting based on the mutex. This finding was also confirmed by CyberReason:
On the side note, I found that the sample is also checking which language is being used on the system. It checks for the strings are listed below. It might be targeting victims in very specific areas only.
Russia
United States_English
Surely a tough one!
Debugging this sample certainly seems to be a tough one. I am still trying to get the network based IOCs for this sample. Please feel free to share the findings if you were able to progress further than this point.
Thank you!
