So close to the end and a final wall presents itself in my analysis. It appears that the author of Ficker stealer was smart and made sure that the malware would only execute and perform its attack when connected to a real network. Since I have my VMs connected to an internal network that give fake web activity no attack is performed, but the malware does keep trying to connect and, in the process, uses a lot of the CPU taking up 100% of my VMs CPU. Since I can’t run the malware without sending, even the very little on the VM, my information to some C2 server out there I was planning on the disassembling the malware and analyzing the functions it should perform while running. Yeah, that plan backfired when I found that the disassembled malware is obfuscated so that all address and function names look hex gibberish. I found a python script that should be able to de-obfuscate it but I’m using IDA freeware to decompile the malware and this version does not support python scripts. I have found a few other solutions that I plan to try out later in the week and if those don’t pan out then I’ll have to try learning IDAs scripting language, which looks kinds like C, and transpose the python script into IDA script. The last thing will be me forgoing real dynamic analysis and instead infer on what the malware is doing based on the assembly code and the linked libraries being called. Thankfully, there is a lot of information that can be gleaned from the linked libraries and the assembly code also provides some useful insight. I was hoping to take it a bit easier in these last weeks and use them to write some drafts before writing up my analysis report and moving it onto my group’s capstone document. But it looks like this project decided to throw one hell of a final challenge at me. Well, challenge accepted.