1. Chapter 5 Anti-Anti-Virus

2. Anti-Anti-Virus  All viruses self-replicate  Anti-anti-virus means it’s “openly hostile” to AV  Anti-anti-virus techniques? o Aggressively attack AV software o Make analysis of virus difficult o Try to avoid being detected using knowledge of how AV works

3. Anti-Virus Virus?  Anti-anti-virus versus “anti-virus virus” o What the … ?  This chapter is about anti-anti virus  Aside: What is an anti-virus virus? o Virus attacks other viruses, or o AV software that propagates virally, or o Software that drops a virus, then offers to remove it for a fee

4. Retroviruses  Also known as “anti-antivirus viruses”  Virus with active defense  What techniques are used?  Kill AV (and related) processes o Virus lists active processes o Kills things like Avgw.exe, Scan32.exe, Navw32.exe, Regedit.exe, Zonealarm.exe o Might also do this for processes run at startup

5. Retroviruses  Example: Ganda virus  Kills running AV-like processes  Examines processes run at startup o If it appears to be AV-related… o …replace 1 st instruction with “return”  Stealthier? o Starve AV software by lowering priority o Prevent AV software from connecting to company database, etc.

6. Entry Point Obfuscation  Viruses often hijack usual entry point o But this is fairly obvious  Set entry point at random location? o Probably not a good idea --- why?  Find calls to ExitProcess API? o Used by Simile and Ganda  Look for known code sequences? o Compilers produce stereotypical code

7. Anti-Emulation  Recall that emulation is used for AV  How can virus defeat emulation? 1. Outlast 2. Outsmart 3. Overextend  AV solution to 2 & 3 is better emulator o Of course, this comes at a price…

8. Anti-Emulation: Outlast  How to “outlast” an emulator? 1. Lots of (disguised) do-nothing code 2. Only be malicious, say, 1/10 th of time o Then AV might mark code as safe o Subsequently, virus has a free hand 3. Entry point obfuscation o Emulator might assume virus will appear early in execution of infected code

9. Anti-Emulation: Outsmart  Try to counter dynamic heuristics  Example: In some cases, decryption is a good dynamic heuristic  To counter this, virus could… o Spread decryption throughout code, not all in one loop o Then emulator might never reach its “decryption” threshold

10. Anti-Emulation: Overextend  How to push emulator to the limit? 1. Use undocumented instructions o If not handled correctly, it’s emulated 2. Bugs in CPU o If handled correctly, it’s emulated 3. Exhaust or abuse memory 4. Check for differences between system calls, e.g., check “time” twice o Emulator might return fixed value

11. Anti-Emulation: Overextend  How to push emulator to the limit? 5. Import obscure libraries 6. Use external resources, e.g., web page o Almost impossible to emulate external stuff 7. Emulator-specific checks o E.g., a known interface to outside

12. Armoring  “Armor” virus --- make analysis more difficult  Two types of techniques used: 1. Anti-debugging o Examples? 2. Anti-disassembly o Examples?

13. Anti-Debugging  Look for inserted breakpoints o Like error detection/correction  Look for single-stepping o Interrupt pushed onto stack after every instruction… so push then immediately pop, or o Time the execution, or o Dynamically modify next instruction, since processors usually pre-fetch  Last 2 also anti-emulation techniques

14. Anti-Debugging  If all else fails, ask: o IsDebuggerPresent()  In Linux, request to trace a process more than once fails o How can virus take advantage of this?

15. Anti-Debugging  Speaking of threads…  Interlocking and deadlocking threads o Only small part of code appears o Different parts each time  Fairly strong for anti-debugging o Improved software activation using multithreading Improved software activation using multithreading  Could be even more effective if combined with encrypted code o Project, anyone?

16. Anti-Disassembly  Anti-disassemblymentarianism?  Goals 1. Disassembly cannot be automated 2. Code not available until it executes  For 1, one idea is to mix code and data o Once mixed, separating is unsolvable

17. Anti-Disassembly  Mixing code and data can result in false disassembly  Disassemblers not so easily confused…

18. Anti-Disassembly  How to make code unavailable for static analysis? 1. Dynamically generate code at runtime 2. Self-modifying code o A red flag for heuristic analysis 3. Use the environment to “construct” code at runtime o How’s that?

19. Anti-Disassembly  Constructed code?  Hash stuff and extract “code” bits… o Perhaps combine with buffer overflow? o Project, anyone?

20. Anti-Disassembly  Encrypted code o Decrypt in parts as needed o Flush plaintext when done o Combine with anti-debugging o Watch for MiM type of attacks  My startup company did all of this  Might do similar things with threads o Intentionally “delicate” timing

21. Tunneling  Virus traces system functions it uses o To be sure they “go to” the right place o If not, code is being monitored  How to trace code? o Static heuristic or emulation o Just like the AV stuff…  Can’t tunnel into kernel on modern OS o But still might be useful technique

22. Tunneling  AV software can hide from tunneling if it’s installed in the kernel o Unless virus is in the kernel too…  But, virus in kernel would be bad for lots and lots of other reasons

23. Integrity Checker Attacks  How to avoid integrity check? o Integrity check can detect any change  Stealth virus might hide o But only from weak integrity check  Infect when legitimate change to file  In one infamous case… o Delete integrity check database and all checksums recomputed

24. Avoidance  Hide in places not searched  Possibilities include o USB key o Some types of files o New type of packer o Etc.  Pretty lame?