These automated systems consist of a sandbox - a virtual testing ground for untrusted and potentially malicious code - that lets the programs do their thing and logs their behavior.
Unfortunately, malware developers are aware of this and are always trying out new tricks for making their wares seem harmless.
Among the techniques they have used in the past are making the malware able to check for registry entries, drivers, communication ports and processes whose presence indicates the virtual nature of the environment in which they are run, and well as executing special assembler code or enumerating the system service list with the same goal in mind.
If these tests prove that is indeed the case, the malware stops itself from running.
But all of these techniques require specific skills and knowledge from the malware makers, and not all of them possess them, so they have turned towards less technical approaches.
According to Symantec researchers, one consists of making the malware run only if it detects mouse movement or clicking, and the other of inserting delays between the execution of the various malware subroutines.
The rationale behind the first test is that automated threat analysis systems don't use the mouse, while regular computer users do, and so the lack of this movement signals to the malware that it is probably being run in a sandbox.
The reason for the subroutine execution delays - often spanning over 20 minutes for each - is that given the number of files the system must test, it usually spends only a small amount of time on each file, and chances are the file will be categorized as harmless and discarded before the first subroutine is even run.