Recently, there has been a post at Fortinet's blog "SpyEye Exposes Mule" which reflects an example of analysis based on a weak base. It is always good to share analysis using differential information but it should have sound base. Understanding, the critical nature of SpyEye, it requires a complete understanding of malware framework. This type of analysis results in unclear information from technical perspective thereby raising complexity in real time environment. The purpose of this post is to raise a point about half flooded analysis of malware. There are lot of misleading points in this analysis as follows
"the most current version of SpyEye we could get our hands on (W32/SpyEye.C!tr.spy).
Which version of SpyEye has been analyzed? No information! Are they talking about signatures ((W32/SpyEye.C!tr.spy).)? That is complete different aspect of version information of malware.
"SpyEye connects to a “log server” that is different than the server where it fetches updates from, where fraudulent transactions done by the Trojan are logged"
Well, this is not new in the version. Further, the details of this process has been released in our previous post "SpyEye Backend Collector" This is a claim which is completely out of the analytical point of view because it requires an understanding of complete chronology of SpyEye development framework This feature was actually introduced in SpyEye version 1.0.75
The snapshots provided of the logs do not explain the real technical details of the actual nature of the attack and the outcome presented. In order to deliver information, We can explain a detailed post on it. Later on.
Further, down the blog post, it has been stated about "SpyEye Upper Limit". In general , there is no such upper limit of SpyEye. It depends on botmaster itself how he wants to design the stealer plugin considering the inherent SDK. Primarily, it is more of banking terms used in money laundering attacks. Most of the banking Trojans use same set of fake transaction strategy (mules and drops). In general, it is an uncompressed LZO log of successful infection.
It could have been better if technical details based on strong base is considered. We would like to see some more technical details as stated at the end of blog post.
