Other issues in this category (24)
Ultimately the pros win
It's no secret to our readers that criminals work very hard to fool anti-virus software. Advanced malicious programs don't even have signatures; they alter their code in real time or don't have a body of their own at all and use pieces of other programs' code. But no matter how well the enemy hides, to accomplish its goals, it has to act. And that is when it exposes itself and can be caught red-handed.
Suppose an anti-virus detects malware by its signature. For that to happen, the signature must be generated beforehand after the code of the Trojan/virus has been examined. Of course, virus makers do their best to undermine analysts' efforts.
Let's start with code analysis. Any program is a set of CPU instructions and data that needs to be processed. Special programs, such as debuggers, can analyse instruction sequences and help analysts understand what programs do or even restore a malware program's source code.
Conversely, there are methods that complicate an analysis of this kind. Interestingly, developers of legitimate software use the same methods, too—to make sure that their software won't be cracked.
There are two approaches to code analysis—static and dynamic. Static analysis is conducted using whatever program code or fragment of code is available to analysts.
The simplest way to protect against static analysis is to encrypt malicious code using the appropriate utilities so that the code will only be decompressed during a subsequent execution. Obfuscation is the second technique. Special compilers rearrange various pieces of code, making it more difficult for humans to understand it.
What can analysts do if malicious code is well encrypted? Here dynamic analysis can help—it lets them examine how malware behaves when its code is being executed.
No matter how well a malware program conceals its code, in order to be executed it must "reveal it"— this is when it becomes vulnerable to anti-virus software. Cybercriminals understand this, too, and disrupt the operation of debugging software. Anti-viruses are known to use various technologies to detect the presence of malware on computers. But the malware can use signatures too.
Certain malicious programs, such as banking Trojans, can detect “competitors” in the system, delete them, and patch the vulnerabilities that were exploited to infect the machine. Nothing personal, just business!
Malicious programs can also detect whether debugging software is running in a system and respond by, for example, shutting down.
Trojan.MulDrop6.42771 has a somewhat complex architecture. The Trojan's code contains numerous random strings and function calls to complicate its analysis, while its main malicious library is disguised as an image file. This Trojan can detect whether virtual machine software or debugging tools, which are usually used by analysts to examine malware samples, are running in a system, and if they are, the Trojan shuts down.
How can a program tell that it is being debugged? It has many ways to do this. For example, it can control its execution time.
Having read its code from the buffer, the program can compare its checksum with the reference and if a debugger inserted the INT 3 instruction into the code, it will understand that it is being debugged or that its code has been altered. But the most reliable and versatile approach is to measure the execution time for specific pieces of code. The idea is simple: measure the time (in seconds, CPU clock cycles) between the instructions in a buffer, and any time in excess of the specified maximum indicates that the program's execution has been stopped.
Malicious programs are often analysed on virtual machines. Typical virtual machines can be detected by the type of hardware that is available to applications that run on them as well as by specific registry entries and by other system properties. Malware can look for the properties and analysts will modify a virtual machine to make its behaviour identical to that of real computers.
Once launched, the Trojan searches for the virtual environment and debugging tools by checking the names of the running processes and the corresponding branches of the Windows system registry. It will only run if it hasn't detected anything suspicious.
Trojan.Kasidet.1 first checks whether its copy and any virtual machines, emulators, and debuggers are present in the infected system. If the Trojan finds a program that can somehow hinder its operation, it terminates itself. If not, it gains administrator privileges and runs itself. Even though the User Accounts Control (UAC) system demonstrates a warning on the screen, the potential victim is thrown off guard because the running application (wmic.exe) appears to have been developed by Microsoft:
Interestingly, Windows has a means of protecting itself from debugging.
Starting with Windows 2000, the routine NtSetInformationThread has the option ThreadHideFromDebugger. This is an extremely effective anti-debugging technique included in Windows. If the option is enabled for a thread, it will stop sending debugging notifications including those about breakpoints and thus hide itself from a debugger. Applying ThreadHideFromDebugger to a main thread will significantly complicate its debugging.
Windows Vista supplements it with the routine NtCreateThreadEx. It has the option CreateFlags, which, among other things, lets the flag THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER be set. A process with this flag will be hidden from a debugger.
This year Doctor Web will launch a new online analysis service that will help IT security experts and cybercrime investigators determine whether files they are examining are malicious. The service is based on Doctor Web's automated analysis technology. Service users will be able to analyse the behaviour of suspicious files and even alter it. That is, of course, if the decrypted Trojan doesn’t realize it’s “an emperor with no clothes” and disguise itself as a nice little kitten. ☻