Instead of dumping one memory segment, you have to dump all 20+ of them and then figure out how they fit together - like a big jigsaw puzzle. The fact that Poison Ivy spreads itself across more than two dozen small memory segments definitely does not make it more stealthy (now there are 20+ suspicious memory regions instead of just one), but it does make reversing/analysis more challenging. Its easy to locate, extract, and analyze. Why so many, you may ask? Malware like Zeus, Carberp, Cridex, Shylock and many others allocate a single segment large enough to hold everything (the code, strings, function call tables, etc). In the original post we briefly mentioned that malfind identified 20+ different memory segments in explorer.exe (pid 1096) that contained injected code. To do this, we'll write a custom Volatility plugin to reassemble Poison Ivy's fragmented code injection model, bypass the anti-disasm tricks, and label imported functions even in the absence of a PE header and Import Address Table (IAT). Only then will we have complete closure and reassurance. This is all pretty solid, but from a malware analysis perspective - code or it didn't happen! In this post we'll dig even deeper and find the exact instructions that reference the strings. We found strings in memory, such as the mutex name, the registry Run key, and the svchosts.exe file name then we backed up the findings by tracking the mutex to its owning process, verifying the Run key was created by looking in the cached registry hive, and checking the svchosts.exe file existed by scanning for MFT records in memory. In the initial post we covered the basics - the what, the when, and the how. This is an addendum to GrrCon Network Forensics Challenge with Volatility.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |