Videojaking: Hijacking IP Video Calls
Videojaking: Hijacking IP Video Calls
Have you ever wondered about the hacking technologies used in Hollywood movies like Ocean’s twelve or The Thomas Crown Affair to steal valuables like diamonds or sculptures?
Author: FLORIAN EICHELBERGER
Source: Hakin9 3/2010 http://hakin9.org
Although auto-update functionality is widespread, having the behavioral pattern of a malware sample aids in its removal. In this article I want to cover commonly used Auto- Analysis Systems and how they can be fooled to raise awareness on this topic and how to treat their output.
Can you trust the output of those online systems or your Sandboxie[2] software ?
During my current and past jobs I encountered and analyzed an uncountable number of malware samples and lately found some in the wild that actively alter their behavior depending if they’re detecting the presence of one of those analysis systems. The two samples I want to explain in more detail show different approaches to produce innocent looking output concealing their malicious nature. The systems those samples have been tested on are:
- CWSandbox[3]
- JoeBox[4]
- Anubis[5]
- Vmware[6]
- Sandboxie
Detections explained
The first sample I want to dissect here was recently detected and handed over to me for a short analysis. In most of the cases, only the malware itself was captured, missing any installers or exploits that deployed them. The sample showed a very effective way of producing a total innocent-looking output when it was run as-is thus defeating the purpose of all tested and later explained systems. I tried to highlight and comment the Figure directly, so they should speak somehow for themselves. Figure 1 shows the beginning of the trojan horse malware (see Table 1 for Filename/ MD5 hash). On address 0040996A you see the trojan is checking the length of a string (in our case it turns out to be the command line arguments) and if this length is > 0 it executes the highlighted conditional jump at 00409980. We well come back to this jump later on. Following the code we end up at the the address shown on Figure 2 and starting at 00890A09 we see a primitive string obfuscation used so the command line arguments could not be detected by the means of any kind of string extraction utility like the unix strings [7] and it’s derivates. If you look at the memory (near the bottom of the screenshot) you see the constructed string -update. The same obfuscation is used several more times for more different arguments, but it is clear that without the proper command line argument, the trojan will not inflict it’s damages. Coming back to the jump in the beginning, following the other execution branch (no/wrong command line argument) results in a jump at 00409A6D jumping near the end of the function and exiting the trojan (This part is not shown for the sake of length and because it’s pretty much standard code).
If you’d read this article in full version use link bellow for download (only for subscribers)
































