I always wondered how much time is needed to get rid of all that anti-VM/crypto/protector/anti-debug stuff (without analyzing actual payload and purpose), especially if you're dealing with malware on a daily basis? I would definitely like to get answer from AV industry experts.
Based on a couple of years of performing and teaching (Malware Bootcamp at University of Bonn, Germany) reverse engineering with focus on malware analysis, I mostly try to skip any "easy" stepping stones (malware capability of detecting analysis environments, be it VM, debugger, ...) to get to an unpacked state of the malware and then focus analysis on this in IDA alongside debugging it.
Preparation of your own tools, e.g. setting up a reasonably proportioned (cores, HDD space, RAM) and concealed (removal of VM fragments) VM as explained by CrazyFrog can automagically carry a lot of load in this domain. I think I rarely spend more than minutes (i.e. native runtime of packer) to get to that unpacked state.
For understanding those protections and detections, otherwise +1 for Peter Ferrie's reference. If you want to step through those in a debugger, you can use my defanged open source implementation of those. Newer detection approaches not covered by the above source frequently involve utilizing Windows Management Instrumentation (WMI). Often to achieve the same derivation of characteristics that can lead to the conclusion you are in an analysis environment.
If there is protection in the sample itself, it's most often crypted strings or obfuscated API calls (Andromeda, Dridex, VM-Zeus come to mind), rarely execution-only decryption of code as seen in Fobber. In this case, it obviously becomes part of the analysis itself, or at least a pre-stage.
I work in AV industry for about a year now and I can tell you how I see this. How fast can you get rid of certain anti-reversing techniques depends on your experience and will to learn and understand as many of those techniques as possible.
I mostly work with PE packers and at the beginning I had problems with removing the most simple techniques like IsDebuggerPresent(). Hell, I even remember one time when I spent a whole day of work just figuring out the anti-debug with trap flag and checksum check techniques.
Today, when I have some experience under my belt, I move around these common anti-reversing techniques quite fast. You can achieve that with the help of plugins for your tools (like Olly Advanced for Ollydbg). One of the greatest (if not the greatest) piece of resource about this topic is Peter Ferries book The Ultimate Anti-Debugging Reference. Whenever I got stuck with some new anti-reversing technique, I consulted with that book and at the end found the solution.
So to sum things up, I am not an expert in the field and in the beginning it takes quite some time to get things done but it's like that in everything right? With enough practice and experience I'm sure you can avoid various anti-reversing techniques in a matter of minutes, but I would like if some of the more experienced users would back me up on this.
most (if not all) anti-VM, anti-debug tricks are well known and easy to bypass using already existing debuggger plugins e.g. ScyllaHide. Some AV company's have dedicated tools for this (emulator, sandbox, virtual machine with auto-dump and rebuild feature). If you do it manualy avg time depends on the sample obfuscation your experience and tools you have to do the job.