Looking through the email filters yesterday, I saw numerous emails from the sender “secure@hsbcdocuments.com” with the subject of “We need to confirm your details.” The email was a well laid out phish with a malicious Word document attached. This Word document led to a Trickbot banking malware infection via the use of a malicious macro instead of the use of the DDE attack vector. Initially when I was looking into these emails yesterday I was not seeing anything online about them. As part of my daily morning reading, I went to @dvk01uk‘s site this morning and saw that it was already reported and written about. Looking over at Twitter, I saw Vitali Kremez (@VK_Intel) had looked into this as well as you can see here. The emails that I saw where primarily sent from the IP addresses of 185.106.121.47 and 185.2.81.202 and all of them had the same attachment to them as well – a Word document called “secure.doc.”
What I was seeing from the emails matched exactly what they were seeing on their end (group_tag = ser1101). The only thing that stood out to me was the fact that the injectors used a folder called “services” in the “C:\Users\%username%\AppData\Roaming\” folder where in the past it had used a folder called “winapp.”
Since Trickbot is fairly well known and pretty well documented, I am not going to discuss it in depth. If you want some more information, then check out thee following links for some good reading/insight:
http://www.zdnet.com/article/dyre-successor-trickbot-attacks-australian-banks/
http://blog.malwarebytes.com/threat-analysis/2017/08/trickbot-comes-with-new-tricks-attacking-outlook-and-browsing-data/
http://blog.fortinet.com/2016/12/06/deep-analysis-of-the-online-banking-botnet-trickbot
And if you are wanting to figure out how to reverse engineer Trickbot, then check out the links below:
http://www.vkremez.com/2017/09/lets-learn-reversing-trickbot-banking.html
http://www.vkremez.com/2017/09/lets-learn-trickbot-banking-trojan-adds.html
http://qmemcpy.io/post/reverse-engineering-malware-trickbot-part-1-packer
As usual, the PCAP, ProcMon logs, and artifacts from this investigation, please see my Github repo here.
IOCs:
=====
217.194.212.248 / rifweb.co.uk (GET /ser1101.png)
94.23.230.159 / pizza24.fr (GET /ser1101.png)
79.106.41.23 (TCP 449)
78.155.206.233 (TCP 447)
79.106.41.23 (TCP 449)
Artifacts:
==========
File name: secure.doc
File size: 72KB
File path: NA
MD5 hash: d6c7a690eac1009881ec6b43e09e3000
Virustotal: http://www.virustotal.com/en/file/594bf62f52df202225eeda2903d5d7d2aa818e2b4d37085fc79704f7ac257969/analysis/
Detection ratio: 21 / 59
First Detected: 2017-11-01 10:36:12 UTC
Payload Security: http://www.hybrid-analysis.com/sample/594bf62f52df202225eeda2903d5d7d2aa818e2b4d37085fc79704f7ac257969?environmentId=100
File name: Lb-ua-cjtd.bat
File size: 1KB
File path: C:\Users\%username%\AppData\Local\Temp
MD5 hash: 90bca1b6075bdb075eaba0c92af4263a
Virustotal: NA
Payload Security: NA
File name: q_kf7.exe
File size: 454KB
File path: C:\Users\%username%\AppData\Local\Temp
MD5 hash: 2486a420f3918a2a1909992a88a87244
Virustotal: http://www.virustotal.com/en/file/16446557906844e7c8b8e1f6481198e4b3d104eef6e269d43c7cedcf3f742dab/analysis/
Dectection ratio: 25 / 68
First Detected: 2017-11-01 10:58:51 UTC
Payload Security: http://www.hybrid-analysis.com/sample/16446557906844e7c8b8e1f6481198e4b3d104eef6e269d43c7cedcf3f742dab?environmentId=100
File name: q_kf7.exe
File size: 454KB
File path: C:\Users\%username%\AppData\Roaming\services
MD5 hash: 2486a420f3918a2a1909992a88a87244
Virustotal: http://www.virustotal.com/en/file/16446557906844e7c8b8e1f6481198e4b3d104eef6e269d43c7cedcf3f742dab/analysis/
Dectection ratio: 25 / 68
First Detected: 2017-11-01 10:58:51 UTC
Payload Security: http://www.hybrid-analysis.com/sample/16446557906844e7c8b8e1f6481198e4b3d104eef6e269d43c7cedcf3f742dab?environmentId=100
Analysis:
=========
As I stated above, this infection was a pretty standard infection for Trickbot. One thing that I would like to comment on is the lack of persistence on my VM. Looking through the ProcMon logs, I did not see anything written to the registry or to Windows Task Scheduler to maintain persistence. I rebooted the VM to see if I could spot a SVCHOST.exe process that would be running and calling out over ports 447/449 but I was not able to find anything. None of the files in the “services” folder were updated either (even after waiting 30+ minutes).