The approaches you mentioned:
Scripting static analysis with IDA:
Great for removing automatically inserted bloat like PUSH EBX; add EBX, ECX; pop EBX, great for automatically finding and extracting relevant values. Sometimes a good way for decryption (if the malware just XORs stuff with 0x17 having your script do that is easier than running the decryption code in emulator).
Using emulators (scripted or not)
Great for following hyper-obfuscated code that jumps into the middle of instructions and confuses static analysis. Has limited environment model, so it will fail once the malware uses exception handling or calls APIs.
Using debugger (scripted or not):
Yes, you can do that if you are careful. Good for following the code, good for bypassing self-decryption, good for dumping. Security measures I recommend:
- Know your malware beforehand (google it, run it in cuckoosandbox, run it in VM in sandboxie with procmon running), so you know what to expect. Might also save you a lot of time. If all your malware does is extract/download stage2.exe into %TEMP% and run it, there is probably no reason to bother with it anyway. Go straight to stage2.exe
- Always work within a VM that has network connections disabled.
- Make shapshot before you start debugging, just in case. If it never returns from your F8 keypress, and you are unsure, you can return to that snapshot (but you lose your changes to IDA db!).
- Have procmon running, so you know if your malware did anything interesting.
- If you are very paranoid, have your VM run on a different host OS. Just in case the malware carries a $200.000 VMWare/VirtualBox 0day :-)