2018-02-17 Remcos RAT from malspam

Earlier this morning I came across some emails that had a subject line that caught my attention. They were all from the same sender and all of them had the same maldoc attached to them. From what I can tell this looks to be related to the REMCOS RAT as documented by Fortinet here. The interesting tidbit with this one was the fact that it was keylogging and also taking screenshots of my desktop as well from time to time. As usual, for any of the PCAPs, ProcMon logs, and artifacts that I managed to capture, check out the Github repo located here. I also uploaded the maldoc to AnyRun which you can see here.

***Note: The last time I checked the domain telebotdb[.]tk was wide open and was allowing anyone to traverse through the site. I was not able to find anything much outside of the file “Twin.exe.”

Analysis:
=========
Below is the overview on how this malware executed on my VM.

Once the user opens the malicious Word document and enables the macro and runs it, the macro proceeds to trigger cmd.exe to run a PoSH script to get the malicious binary. Below is the original PoSH script base64 encoded:

Once the file “Payment_output2ED76B0.exe” has been downloaded, copied to the “C:\Users\%username%\” path, renamed to “bxPZAxDnDdsUBPSQmv.exe,” and finally executed, it proceeded to use the UAC bypass that SANS discussed here (https://isc.sans.edu/forums/diary/Malicious+Office+files+using+fileless+UAC+bypass+to+drop+KEYBASE+malware/22011/) in order to get the malware to run as seen below from ProcMon:

It is here that I was not able to obtain the “install.vbs” script located in the “C:\Users\%username%\AppData\Local\Temp\” folder on my VM, but using AnyRun I was able to get it. There appeared to be an attempt (perhaps) at an anti-sandbox trick at the beginning of the script (WScriptSleep 1000 – maybe fat-fingered). It then proceeded to delete the file “bxPZAxDnDdsUBPSQmvexe” and create the file (Newfileexe) in the “C:\Users\%username%\AppData\Roaming\remcos\” path.

Once the “Newfile.exe” process was up and running, it spawned a couple of other processes (iexplore.exe and svchost.exe) in what appeared to be another UAC bypass. It was also responsible for the keylogging/screengrab capability:

along with communicating back to the IP address of 84.38.135.152 using port 49195 to ship back what was in the “logs.dat” file and any screengrabs from the “C:\Users\%username%\AppData\Roaming\Screenshots” folder.

I also noticed when looking at the ProcMon logs using the FILES_WRITTEN filter that there were two different INI files that were modified. I am not sure what had been modified but found this interesting as I have never seen this before. Both files look to be exactly the same though.