I have updated the analysis with a quick overview of the function used to decrypt "OfficeCookies.exe"
An interesting sample that I was able to locate on Hybrid-Analysis (https://www.hybrid-analysis.com/sample/7a6a0d6aa923227f2f64e655253f4db9cb87073be397a04060d7e627e154b7da?environmentId=100) based on a search methodology which uses certain keywords translated into other languages. In this particular case, I searched for the terms "armed forces" and "Ukraine", translated into Ukrainian. Based on the current situation in Ukraine, and the powers that attempt to influence the activity within that country, this seemed like a good set of terms to yield interesting results. Other methodologies that I have not explored as of yet are also related to geopolitical issues. Some examples which may yield interesting malware results are translating "South China Sea" into Japanese or Korean, and translating "Catalan independence" into Spanish, and using some Google dorking skills to narrow results down to a sandbox-type site, like Hybrid-Analysis.
In this case, the search results contained an analysis of a .lnk file, named "Витяг із наказу командувача Сухопутних військ Збройних Сил України.txt.lnk" (https://www.hybrid-analysis.com/sample/68fee3628598f7a8b95e46b41ed82a5dae718fd0f750e405bddf24087e51b928?environmentId=100&lang=en), which translates to "Extract from the order of the Commander of the Land Forces of the Armed Forces of Ukraine.txt.lnk". Dumping the strings in the file yields the following output:
%comspec%
/c start /b 7.10.01.2019.docx
%WINDIR%\System32\cmd.exe
The system cannot find the file 7.10.01.2019.docx.
The strings in this file pointed me to another file, as it seemed unusual that a .lnk file would invoke a DOCX explicitly from cmd.exe in a .lnk file. Searching for the filename "7.10.01.2019.docx" in Hybrid-Analysis yielded one result, and sure enough, despite its extension, it was a PE file. While a filename is usually not a good indicator to pivot on, and in most cases it would be a mistake to link the two files based solely on a filename found in string data, the fact that a purported DOCX found on the same site was an executable which would have been successfully invoked by the lnk file made me want to look further into the sample.
The first step in my analysis was to upload it to a local instance of Cuckoo which uses some custom Windows 7 VMs that I add anti-anti-analysis measures to as I find them. In this case, the executable appears to have no qualms about initiating a lot of processes on the victim host. It appears to show an interest in proxy servers listed in the registry, and invokes chcp to change the output language to Russian/Cyrillic.
In a virtual environment, I used PEID to determine that the executable was written in C++, and also appears to have a few different files packed into it. These files are:
When run, "5087.cmd" first changes the command line text encoding to 1251, ANSI Cyrillic, and sets some variables. In particular, "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\", which is a common persistence mechanism, as each file in the directory is run on login of the user in question. Variables are also set for an executable, "OfficeCookies.exe", and a document, "Document Microsoft Office.docx". The PE file "24125" is renamed to to "cr.exe", and then run with the parameters "enc_10814" dec "blbntdgbplerfhfgepbrb", which, according to a December 2018 article by Olexandr Kravchenko (https://kharkivobserver.com/ukraine-as-testing-ground-for-russian-cyber-attacks-deterrence/), is an obscene phrase when typed on a Cyrillic keyboard. The executable decrypts "enc_10814" using the key "blbntdgbplerfhfgepbrb", which outputs an executable, named "dec_enc_10814". Any processes named "OfficeCookies.exe" are killed, and "dec_enc_10814" is moved to the userprofile directory, renamed "OfficeCookies.exe". The newly moved binary is executed, and the .lnk file, "2330", is renamed "Cookies.lnk" and moved to the startup directory in order to establish persistence.
051A054233312EFFF949583CF100C305 OfficeCookies.exe/dec_enc_10814
Cr.exe and OfficeCookies.exe Decryption
Cr.exe is used to decrypt "enc_10814", however it appears to be a full command line tool which can also be used to encrypt, and even has a help function, so long as one can read Cyrillic. The syntax of cr.exe is cr.exe [infile] [enc | dec] [key]. The algorithm for decrypting the files is actually very simple. The first character of the key argument in the command line is ignored, and the key is used to XOR the encrypted file in reverse. This means that if the key for "OfficeCookies.exe" is "blbntdgbplerfhfgepbrb", the following (poorly written) Python script would decrypt the file:
key = "blbntdgbplerfhfgepbrb"
//given key
key = key[1:][::-1]
//removes first value and reverses key
decfile = ''
i = 0
z=open('outfile','wb')
with open('enc_10814','rb') as f:
while True:
try:
decfile += chr(ord(f.read(1)) ^ ord(key[i]))
//XOR operation
i += 1
if i == len(key):
i = 0
except TypeError:
print "\n\nDone.\n\n"
break
z.write(decfile)
z.close()
OfficeCookies.exe runs several commands, which is unusual, as it would seem easier for a binary to use the Windows API to perform certain activities that OfficeCookies offloads to different commands, such as searching the registry. It also uses some novel techniques to decode the data to be run from the command line.
Decode Function
The decode operation uses a series of arithmetic operations and compare instructions to determine the final value of each decoded byte to be used in the command-line subprocesses. This is in contrast to more common decode or decrypt operations in that there is no "blob" of encoded or encrypted data to be deciphered, but rather the plaintext output is constructed in the registers based on comparisons of two values supplied as arguments. For the most part, general registers have static functions within the context of the loop, and hold values that serve the same purpose throughout. The value assigned to EDX is manipulated and checked against ESI in conditional jumps, and based on the result, the value of EBP (the register which, at the end of the loop, will hold the decoded byte) is manipulated. At the end of each iteration of the loop, the low byte from EBP is added to the decode buffer by moving EBP to ECX, and CL to buffer.
In the example above, the most important arguments passed to the decode loop are as follows:
testVal - a value manipulated throughout the loop and compared to pilotVal to determine the value of decByte
pilotVal - value which remains static throughout an iteration, used for comparison with testVal
outBuf - a buffer where decoded bytes are stored
decByte - the register which holds the decoded byte values, modified based on the result of comparison between testVal and pilotVal
imulArray - a byte array which stores multipliers used to modify testVal
The loop is complex, and it branches off in several different directions based on the value of the testVal, but the bulk of the decoding is accomplished through the above algorithm. There are additional arguments which have also been omitted for simplicity.
Command-Line Subprocesses
Several commands are executed via cmd.exe subprocesses. The most complex of which, 487.cmd, is used as a downloader for the next stage of the infection. The first operation performed in the script is a query of the registry for the following values to gather information for proxy settings:
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyUser
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyPass
The serial number of the drive is gathered by running vol, and processor architecture is determined.
Additional variables are set, including several partial domain names, file paths, and some random integers.
The following directory is then created, and MicrosoftCookies.exe is copied to it, renamed to ie_cash.exe:
C:\Users\[user]\AppData\Local\Temp\MicrosoftCookies.exe
C:\Users\[user]\AppData\Roaming\Microsoft\IE\ie_cash.exe
BD126A7B59D5D1F97BA89A3E71425731
BD126A7B59D5D1F97BA89A3E71425731 is in fact a copy of WGet version 1.11.4. This binary is invoked with a callback domain parameter in a scheduled task created by the script. The task reaches out to "torrent-bits.ddns[.]net/[COMPUTER NAME]_[SERIAL NO]/setup.exe" every 30 minutes indefinitely, and saves the retrieved file directly under the user profile. In this case the script defined the saved file as "C:\[user]\setup.exe". The next scheduled task created runs setup.exe every 31 minutes indefinitely. If the proxy user registry key variable defined at the beginning of the script exists (meaning the victim is behind a proxy), the third task is created, which includes the proxy address, username, and password. This task runs every 32 minutes.
The script then pings Google's DNS server, 8.8.8.8, presumably to determine whether the system is online or not, however this does not affect the flow of execution. The previously defined random integers are used as parameters to a timeout command, to slow the execution of the script, and presumably to make it less predictable for automated antivirus detection. MicrosoftCookies.exe, another copy of WGet, is then called to post host information out to a different domain, "torrent-videos.ddns[.]net". This post data is the entire output of the systeminfo command, and the server response is saved in the following file:
C:\Users\[user]\AppData\Local\Temp\Richtime.exe
Note that due to server availability, the intended contents of Richtime.exe and setup.exe were unable to be downloaded or located online.
Network Connections
The data sent out in the HTTP posts is not encoded or encrypted in any way. Post data sent to "torrent-videos.ddns[.]net" includes the victim computer name, an ID number, the output from the systeminfo command, and the version number of the malware, seen in the field "versiya", a transliteration of the Russian word for "version". In this case, the version was "arm_14.01". The ID assigned to the victim is the computer name and the C drive serial number, joined with an underscore.
Traffic to "torrent-bits.ddns[.]net" was a GET request for the file "setup.exe", with the computer name as part of the URI string.
File MD5 Sums
78fbe76e3845ae6c431e0a6ff85d22be 2330.lnk
f010ea1b09401c6b5e02b048029d7980 cr.exe
1cfac2a5bc8497299a1b4eab04ae5ff2 5087.cmd
c8efdff17bfe482a834fdb141127cd13 enc_10814
051a054233312efff949583cf100c305 OfficeCookies.exe
Directory Indicators
C:\users\[user]\AppData\Local\Temp\7ZipSfx.000\
C:\users\[user]\AppData\Local\Temp\7ZipSfx.001\
C:\users\[user]\AppData\Roaming\Microsoft\IE\
Scheduled Tasks
ie_cash_[C drive serial number]_01
ie_cash_[C drive serial number]_02
ie_cash_[C drive serial number]_03
Network Indicators
torrent-bits.ddns[.]net
torrent-videos.ddns[.]net
Comentários