Saturday, February 22, 2014

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?

Saturday, February 8, 2014

Taming Dragons On A Daily Basis

hello world, happy you found here :]
welcome to some new blog on tech, travel, fun and $cool_things. 

wait.. new blog.. does the world seriously need another blog? ah no i didn't ask that question for real. don't quite care about the answer actually - i got my reasons.

first of all, i like to write and i like to share. so a blog is the perfect symbiosis :) pro practical approaches.

second, and virtually most important, my grandma still hasn't seen my awesome pictures of singapore, las vegas and seoul :( err.. long story short: last year i spent a lot of time on international conferences, but since i started work 24/7/365 my family has barely seen more of me than postcards. meh.. can't even remember sending postcards. so i want to compensate a bit by putting my globetrotter impressions in words and pictures. poor compensation? yes i know. but i also heard some university is already working on teleportation, so probably we get better on that end pretty soon :)


third, and interesting for the others besides grandma, i want a platform to write about my research when i find the time. i learn most when writing about stuff and i can re-read it when its written and re-think and any interested reader is highly welcome to think with me. but don't worry if you are not willing to think, i can kill my dragons myself. like.. last week i finished reversing a cute little.. malicious dropper. who'd have thought..

so FINALLY, the post title :) i taimed a dragon. its name is my-personal-inability. once it was big, scary and fire spitting. could have taken me years more to stand my (wo)man against that beast, but then - someone challenged me. that someone was halvar flake, writing a post that read to me like 'you kill that beast and i get you to singapore'. looked at the dragon, googled singapore, thought awww don't know.. fuck it.. lets do it. and know what? me 1 - dragon 0! 

the challenge happened now exactly a year ago. it costed me time, nerves, grey hair, you name it. it was about reverse engineering a 'thorny' piece of malware, as halvar called it. that thing was a file-infecting spy-bot, multi-threaded, a bit obfuscated, some anti-debugging; challenging indeed. but obviously not impossible!

who ever tried on reverse engineering, it's captivating. it's you against your debugger of choice, life is happening elsewhere, and after a weekend you find out you CAN spend days in your pyjamas and actually forget to eat, sleep or shower. but let me tell you, any of these three are overrated when you have to stand up against a dragon :)

long story short, did it, won. but what does winning mean? that challenge didn’t actually just mean I got to go to singapore. it did not only mean I got to meet the most awesome people of that infosec-hacking-whatnot-community. it was a strikingly awesome experience, but not. only. that.

what this whole project did was showing me that i can achieve more than i had ever imagined. i am no hacker today, i was no hacker back then. just saw challenge - girl - malware and smelled a chance. thinking, what if it would have been for any motivated participant? i wouldn’t have imagined it as possible to do. no worries about winning, even impossible to finish.

why? because i thought i could never be good at this. whole scary IDA Pro was a mystery to me. dragon, if you will.

SOOU what did that challenge give me? a new perspective. courage. it made me learn A LOT in a short time. it pointed out new possibilities, one can learn a lot in some time – let alone one takes a LOT of time, imagine that?! 

and it gave me a tame little dragon, that now jumps happily at any other challenge that pops up.

more about that dragon challenge you find on halvar's blog.

more about my personal challenges you will soon find here: a write up of that malicious dropper, pictures that grandma hasn't seen, write up of my highschool talk on why girls should do more reverse engineering - stay tuned.