matousec.com (site map)

Poll

On Windows 7 (or Vista) I use

  unlimited administrator's account (58.03%)

  limited administrator's account (16.51%)

  common user's account (13.66%)

  nothing (I do not use Win 7/Vista) (14.06%)

more

results

Blog

Proactive Security Challenge vs. real malware (2010/11/01 09:00)

Proactive Security Challenge is a project devoted mostly to testing abilities of security software to protect against actions of malware. Currently, Proactive Security Challenge consists of 148 different tests. Sometimes we hear people arguing that the techniques used in our tests do not correspond with techniques used by the real malware. In order to find out how much Proactive Security Challenge reflects the real world of malware, we have performed the following research.

We have collected a set of 20 malware samples that were not detected by two popular anti-virus engines. This means that downloading these samples to the computer and executing them would be possible even with a fully updated anti-virus installed. Then we have run the samples and analyzed the techniques they used. The results are as follows.

  • The most used technique among the tested samples was direct Internet access, which is tested by Leaktest and Yalta tests, it was performed by 50 % of the malware samples.
  • The second most used technique was registering under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run. This has been seen in case of eight malware samples. In Proactive Security Challenge this technique is implemented by Autorun3 test.
  • Similar technique of using HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run registry key in order to persist in the system was used by five malware samples. In Proactive Security Challenge this is done by Autorun1 test.
  • Exploiting registry value PendingFileRenameOperations under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager is done by FileMov2 test and also by four of the samples. In this case, however, we have to admit that FileMov2 uses the technique for attacking purposes, which has been seen only once while the other three samples used it to remove their tracks.
  • Two malware samples changed the system HOSTS file. This technique is checked by our HostsBlock test.
  • Twice we have seen an attempt to load a kernel driver. Once it was using the technique of Kernel2 test and the other time Kernel1's technique was used.
  • Disabling security related system services also appeared twice. Svckill test simulates this behavior.
  • Jumper test replaces Internet Explorer's start page and so did two malware samples in our research.
  • In case of two malware samples we have seen the technique of replacing executable of a legitimate application with a malicious one. Similar idea is implemented in Runner and Runner2 tests.
  • The Shell value under the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon was exploited twice. Autorun7 uses this.
  • Similar technique to today's very popular DLL Hijacking was used by one malware. Its technique can be found in our Inject2 test.
  • One sample encoded various information about the infected system into a long DNS query which it then resolved. This is the technique of DNStester.
  • Misusing registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce, implemented by Autorun4 test in our project, has been seen in one case.
  • Another registry key that can be misused for system infection is HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run. This was done by one malware and it is also done by Autorun19.
  • The Load value under the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon can be used for persistent system infection, and was once. Autorun15 implements this technique.
  • One of the tested malware samples started system at command and scheduled new tasks in order to be executed regularly. Similar technique is used by our Wallbreaker4 test.
  • Configuring itself as a debugger for a known executable name under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options registry key is implemented by Autorun10 test and was used by one malware sample.
  • Another attacking technique was starting a trusted application and infecting it with a malicious code. This technique is implemented in DNStest and AWFT1 tests.
  • One sample executed script using wscript.exe. This idea can be found in VBStest.
  • Another malware sample installed so called global hook in order to inject its malicious DLL into other processes in the system. FireHole test works just like that.
  • AWFT3 and AWFT4 create new thread in Windows Explorer in order to execute malicious code under its rights. This technique appeared in case of one malware sample. A similar technique is done by Thermite test. In its version the target process is Internet Explorer, and this variant has also appeared once during this research.
  • Direct disk access technique was also implemented by one malware, in our suite this is the role of FileWri4 test.
  • Print Spooler's interface was misused by one malware. Kernel5b works on this idea.

As we can see behavior of real malware samples consists of many techniques that we test in Proactive Security Challenge. We are sure that if larger set of malware was used we would see even more techniques that are implemented in our tests. If a security product is able to block techniques of our tests, it can also block most of the real malware's behavior. It is clear that Proactive Security Challenge is not a useless theoretical concept, its techniques are used by real malware. Being able to fight these techniques makes sense. It should be mentioned, however, that not all the existing attacking techniques are implemented in Proactive Security Challenge tests, but we have tried to cover the most used techniques with our testing suite.