Dissection Is My Hobby: Upatre Insights

i found the biggest problem to face with actual all my projects is not necessarily that i lack the idea of what i want to do, but that i lack documentation on how to do it and then go and have to figure out myself. would that be nice if someone had just mounted a page like.. malware reverser's frequently asked questions, arrrr well never happened.

now im not going to start a FAQ page, but in order to help that situation i produced detailed documentation of my latest reversing project

if you read this because you want to know about malware you will be a bit disappointed probably. mainly because the purpose of that malware itself is not so exciting at all. it just downloads.. stuff. but also because i myself focused not directly on the final executable but on the stony path it takes to get there. it is just awkwardly fascinating to watch malware shift bytes around in memory and trying to escape. i would recommend everyone just slightly interested to try it out himself, the according sample hashes for identification are listed in the write up doc.

for the records, the malware is detected as TrojanDownloader.Win32.Upatre, the full report can be downloaded at https://drive.google.com/file/d/0B9Mrr-en8FX4MS1HdjBjNEhYWk0/edit?usp=sharing, on a summary i will try now here. could get dirty though.

FUNCTIONALITY 

the analyzed sample is a malicious downloader with the sole purpose to connect to a remote C&C when invoked and to download and execute additional malware. it communicates via HTTPS to one of two hardcoded domains, which are believed to be legitimate websites on compromised web servers. malware execution can be parted in a protection layer, an unpacking layer with different stages and the final payload. For an initial infection the malware just copies its own image to the systems %TEMP% directory and executes that copy.

PROTECTION LAYER

the malware possesses a neat collection of anti-analysis tricks, none of them highly-sophisticated but very nice for learning purposes. 

anti-simulation

 
the first one is an anti-simulation trick targetting anti-virus simulation engines by the use of a multimedia API as seen in the picture. acmMetrics is an API call present in the msacm32.dll library. usually it is used for retrieving metrics for ACM objects (Audio Compression Manager). during the startup procedure of a malware sample it is highly likely that this was not the initial intention when placing that call. acmMetrics is part of the multimedia library since at least Microsoft Windows 2000 (according to Microsoft documentation) and in this special case called to trick AV simulation engines.

in our case acmMetrics is expected to deliver an error message for an invalid handle, which is not surprising given that the handle parameter is not initialized beforehand. in case the return value is not MMSYSERR_INVALIDHANDLE, code 5, execution continues to access the memory referenced by edx, which at this point always results in a memory access violation. edx is not initialized thus set to zero. 

the point of this check is, on a normal operating system like Windows 2000 or newer this function returns 5 in any case. Simulator engines usually don’t support media APIs due to overhead, therefor either crash on the call or later on the access violation.

implicit breakpoint detection

the protection layer performs minor decryption of a part of its own code, which results in implicit breakpoint detection. the decryption consists in subtracting a key from every opcode of a given section. the simple decryption routine iterates code on the position 40100Fh, where execution continues later on. If a software breakpoint is placed in the section to be decrypted the routine produces invalid opcodes and the malware crashes later on.

window confusion

At the end of what could be classified as protection layer stage one the malware invokes CreateWindowExA with a provided WndClass Structure. This structure defines the handler function of the dummy window, which will execute the second part of the protection layer. The created window has no graphical representation, thus can’t be seen so just only serves for executing said handler function. If the analyst does not recognize the switch of execution to the handler function and places according breakpoints control of the debugger will be lost.  

broken timing defence

interesting in the next section of the protection layer is a rdtsc-triggered timing defense. malware can utilize the system time to verify if a debugger, including a human analyst, is attached to the running process. windows offers various mechanisms to request the system time, most commonly used are rdtsc or the GetTickCount system call.  for detecting an attached debugger/human malware wants to know the time difference between two time stamps, namely if the delta is too big as if the CPU would execute without interruption.

the malware at hand issues two rdtsc instructions, wrapped around the decryption loop. the delta is calculated immediately afterwards, but never checked against any threshold. instead it is kept in eax until the next system call overwrites it with its return value. no other verification could be found, this anti-debugging trick is either broken or the first timestamp servers a different purpose that could not be identified. 



more multimedia disturbance

the windows media library is used a second time as a means of protection from analysis. the malware issues a call to mciSendStringA with the command “set waveaudio door open”. it is not perfectly clear what purpose the command “set waveaudio door open” usually fulfills, but without doubt the aim of the malware at hand is not to interfere with multimedia devices. an effect of mciSendStringA is that it starts up two additional threads for interaction with devices – the analyst could lose control of the debugger when inappropriately configured. a solution is to configure the debugger to stop on the start-up of a new thread, step back to the original code and continue execution until it returns to the malware code. 

UNPACKING LAYER

after bypassing all the protection mechanisms the unpacker executes without problems. unpacking can be parted in three steps: 

• one that compresses and decrypts the packed payload data
• second one that decompresses the same data using RtlDecompressBuffer
• third one which performs checks on the unpacked binary, patches function call offsets and reconstructs the import address table (IAT). 

details on the unpacking routine, including the IAT reconstruction, can be found in the report mentioned above. any critics on that analysis are welcome :) ou.. how did that sample actually catch my attention? it was part of a mean malware spam wave, that has been ongoing in austria for at least since november. samples are all the same size and have very similar protection/unpacking mechanisms. so some future research would be to look at the other ~100 related malwares that i have and correlate similarities on binary level. maybe..

future shines bright, you know?