Chapter 5
 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
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
 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
 Example:
Ganda virus
 Kills running AV-like processes
 Examines processes run at startup
o If it appears to be AV-related…
o …replace 1st instruction with “return”
 Stealthier?
o Starve AV software by lowering priority
o Prevent AV software from connecting to
company database, etc.
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
 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…
Anti-Emulation: Outlast
 How
to “outlast” an emulator?
Lots of (disguised) do-nothing code
Only be malicious, say, 1/10th of time
o Then AV might mark code as safe
o Subsequently, virus has a free hand
Entry point obfuscation
o Emulator might assume virus will appear
early in execution of infected code
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
Anti-Emulation: Overextend
 How
to push emulator to the limit?
Use undocumented instructions
o If not handled correctly, it’s emulated
Bugs in CPU
o If handled correctly, it’s emulated
Exhaust or abuse memory
Check for differences between
system calls, e.g., check “time” twice
o Emulator might return fixed value
Anti-Emulation: Overextend
 How
to push emulator to the limit?
Import obscure libraries
Use external resources, e.g., web
o Almost impossible to emulate external
Emulator-specific checks
o E.g., a known interface to outside
 “Armor”
virus --- make analysis more
 Two types of techniques used:
1. Anti-debugging
o Examples?
o Examples?
 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
 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?
 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
 Could
be even more effective if
combined with encrypted code
o Project, anyone?
 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
 Mixing
code and data can result in
false disassembly
 Disassemblers
not so easily confused…
 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
Use the environment to “construct”
code at runtime
o How’s that?
 Constructed
 Hash stuff and extract “code” bits…
o Perhaps combine with buffer overflow?
o Project, anyone?
 Encrypted
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
 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
 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
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
 Hide
in places not searched
 Possibilities include
o USB key
o Some types of files
o New type of packer
o Etc.
 Pretty

similar documents