Dr. Richard Ford

 Szor 12  Virus Scanners – why they need to scan memory and what issues there are in this area

 Look for “known” viruses  But they also must scan memory for viruses… why?  Why isn’t just using an “on-access” scanner good enough?

 Speed of spread (more infection opportunity)  Longevity of infection: active stealth  Imagine an integrity checker or virus scanner operating with a virus in memory…

 DOS uses the Intel Processor in Real Mode!  Which means what?  DOS does not protect or differentiate memory from any process  No support for “virtual” memory

 Can scan memory byte by byte  Effective  Not too slow (not much memory)  Direct access by the virus scanner (no OS involvement)  Problem is false positive rate – so scans using MCBs to reduce memory coverage  Safe?

 Later versions of MS OSes changed things around a lot  Virtual memory (basically, unlimited memory) makes life much harder  To understand why, need to understand how Windows NT and above manages memory

 Not a requirement for an OS  But…  Allows an application to not worry about usage (i.e. makes overlays uneccessary)  Provides process isolation  Provides memory protection  No memory limitation  Really needs dedicated CPU support – and Intel provides it

 In NT, memory is broken down into pages, each 4096 bytes in size  The operating system handles how these pages are stored and translates into physical memory  This means that two processes can access the “same” address but two totally different physical pieces of memory  Introduces the idea of a “page fault”

 If Process A is isolated from Process B how can you scan memory globally?  One solution: ReadProcessMemory()  API used by Debuggers, requires a “Handle” to a particular process  How to list processes… non-trivial!  Problem: requires us to basically provide global access to the user doing the scanning – that’s foolish!  Better to use kernel-mode… but this is hard too!

 A virus can hook itself into the OS in a few different ways  User-mode and kernel-mode  Infect a DLL that’s used everywhere (like KERNEL32.DLL)

 In order to scan memory in user-mode, the OS will have to generate a page fault for swapped memory pages  Slow!  Tempting to enumerate process and scan the disk images – why is this not a good idea?

 How?  Yeah, really… it’s not easy at all  Terminate the process that is infected  Detect and terminate remote threads  Patch “in memory” to deactivate (useful when the virus is loaded into every process)  Think carefully how memory protection on shared DLLs works

 Let’s think about a virus which is a File System Filter Driver  Can’t unhook safely  How to disinfect?

 Can now mark memory as “Read Only”  How to disinfect?  Can use assembly within the kernel – but requires us to be kernel-mode

 Encryption!  In-memory polymorphic code  Metamorphic in-memory  Code which “moves about” in memory (ouch)  Inject into multiple processes at once  In-memory stealth techniques

 Many ways to detect malware “generically”  Checksummers  Behavioral analysis  However, both have issues with false positives  Can create a more “optimistic” set of rules  Both these detection techniques appeared VERY early in the game

 Not confined to static analysis, but most common there  Typically, we define a heuristic as a rule of thumb  Heuristic analysis was also used pretty early on in the detection game  If you think about it, a heuristic to detect our polymorphic hello world programs isn’t a bad idea…

 Botnets and other loose ends