Email
YouTube
Twitter
RedditDETAILS
We start by analyzing the DOC’s header and see that it is PK with XML references inside. This is indicative of Microsoft Word DOCX and DOCM files. To inspect the individual files contained within the document we simply change the DOC extension to ZIP and open the file with an archive manager.
Inside the archive we find a vbaProject.bin file which contains VBA macro code. Opening this in a text editor reveals the script which runs after opening the original document. The script will download a file from http://appenzeller.fr/aaaa
The aaaa file is a VBScript which invokes Wscript.Shell and runs Powershell to download another file. The variable to download this file is constructed from a parameter passed by the first script “amphibiousvehicle.eu/0chb7”.
An important note is that the file is downloaded to the %TEMP% folder and named petya.exe. This file IS NOT the recent Petya ransomware. It is a trojan.
The downloaded trojan comes to us packed by PECompact2. In order to unpack the file we first load it in our debugger and get to the “entry point” chosen by the debugger.
We then go to the first address put in EAX. In this case it is 0x002440e4.
Next we scroll down from 0x002440e4 to the last instruction before a lot of 0x00000000 bytes. It should be a JMP to a register. Advancing a single step will put you at the Original Entry Point (OEP). Traditional import reconstructors can be used to restore the file at this point. Unpacking the file is not necessary for execution, but it makes static analysis much easier.
After execution, petya.exe copies itself to the following Roaming\winapp directory and renames itself odsxa.exe. It also generates a client_id and group_tag file which contain victim identification strings. A modules folder is also added where additional malware/modules/addons can be downloaded later.
Once everything is copied to the new folder, petya.exe closes and odsxa.exe takes over. odsxa launches SVCHOST.EXE in a suspended state and proceeds to inject data into a new section of the file’s memory segment. This is called Process Hollowing and allows the injected code greater freedom in the Windows operating system because it is running under the security context of SVCHOST.EXE.
After the injection is complete, SVCHOST.EXE will first retrieve the user’s public facing IP by issuing a GET request to the legitimate website ipinfo.io/ip.
The trojan will then begin beaconing to 16 different IP’s using HTTPS. Mac1 was found in the group_tag document and WIN-FD… was found in the client_id file.
The malware will continue to reach out to the servers until one has data for it to download. Once new files have been downloaded, they will be placed in the modules folder of the winapp directory.
After ~30 minutes, multiple other modules were downloaded to the directory.
All data downloaded in our session appeared to be encrypted/obfuscated in some way. It is unknown at this time which routines were used to do this, however, with a bit more reversing they should be able to be found in the unpacked version of the trojan.
DETECTION
The initial document is generically detected by most major Antivirus scanners as a script downloader. The final packed file is also generically detected by Antivirus as a generic trojan downloader, however, Symantec has a unique signature identifying this malware as Trojan.Trickybot. The technical details seem to line up with the analysis in this document.Even with a proper BLUECOAT device inspecting the HTTPS traffic, the variable length parameters in the GET string make signaturing the beacon traffic difficult. The best mitigation strategy here is to block the C&C IP’s listed above.
Also a best practice is to not enable any macros in Word Documents in which the sender cannot be verified by you.