A (Beta)Bot in a Phish

Recently a colleague sent me a .docx which triggered on our scanning engine. Being the optimist me, I personally view such incidents positively; it either proves the accuracy of our engine if it is a true positive, or offers an opportunity to improve the detection logic if it turns out to be a false positive. The .docx comes with an accompanying email:


I am Dario Roberto Santos, President MP DO Brazil Ltd. Sao Paulo, Brazil. We are top dealers of your product in the Brasilia market. One of your customers, who is in same line of business with us, recommended your company to me when I met him in trade fair some time ago and I have decided to give your company a trial.
Please for our order samples and all the requirements and specifications, kindly refer to the attachment and unzip or open the zipped folder/file for our order samples. After studying our samples and the specifications, kindly send quotation as listed. Also fill and sign our company’s contract agreement Form attached on the zipped file and send it back to us by fax or email. Most importantly, we will need your guarantee of speedy delivery of this order and again our representative will visit your company/factory for inspection before shipment and final payment.

Please kindly reply ASAP
Street Address, Alameda Santos.
211 salas 1001/1002.
Sao Paulo. Brazil.

The odd thing to me is that nothing specific is mentioned. For example, what kind of product am I selling, or which of my customers did the sender come in contact with. In a nutshell, all the sender wants is for me to open the poorly-named attachment, Doc1.docx. Okay, so I did:




Seemingly there’s a .pdf inserted, which opens only when Protected-Mode is disabled. Once opened, Winword drops the package, “new1 (2).exe”, into the local temp directory. So this is not a .pdf as expected, and is easily achieved: Insert->Object->Package->Choose any executable. The icon image and caption (in this case, “Please Double Click To Open”) can be chosen when “Display as Icon” is checked.
The next step is to reverse the (Visual-Basic) executable to determine if this is anything new. A dynamic run is always a good starting point because you get the unpacked code (if packed) almost instantaneously. Under a debugger, it crashes at this point:


It is obvious that this is a result of ESP having the value 0xFF because [EBP-1]==1 at text.0015E754. [EBP-1] is actually a Boolean flag that indicates whether the executable is being debugged, as shown in this manually-decompiled function:


So “new1 (2).exe” uses the ZwQueryInformationProcess(…, ProcessInformationClass=ProcessDebugPort, …) technique for anti-debugging. There is another anti-debug attempt in sub_00153796() where it patches the ntdll.DbgBreakPoint(). The rest of this function collects a whole lot of information about the system, machine, installed applications, etc.

In the course of reversing, I also came across this function:


Many of these callees are interesting, and reveal the capabilities of “new1 (2).exe”. But I have gathered sufficient information from AntiDebug() and BetaBot_Commands() to achieve my aim: conclude that this is the Betabot malware. Since we already had detection for this malware in place, I didn’t reverse further (stolen files, communication encryption, C&C servers, etc).

Lastly, as with all applications, there are at least 2 bugs in Betabot:


That’s all, folks.

.docx md5: 73b14e96931b51048302784af0143945
“new1 (2).exe” md5: 2976af9b6550823b7786c2f66514902d

Topics: , , ,

Related Content


Do you have the MD5s for the original .docx file and the dropped malware?

Yong Chuan Koh
Yong Chuan Koh

.docx md5: 73b14e96931b51048302784af0143945 new1 (2).exe md5: 2976af9b6550823b7786c2f66514902d