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.
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.
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).
future shines bright, you know?