
Dailydave mailing list archives
Re: Palladium, Memory Forensics, Clouds.
From: "James Butler" <butlerjr () acm org>
Date: Sun, 24 May 2009 06:13:19 -0400
Dave Aitel wrote: _________________ The other thing that keeps coming up is memory forensics. You can do a lot with it today to find trojan .sys's that hackers are using - but it has a low ceiling I think. Most rootkits "hide processes", or "hide sockets". But it's an insane thing to do in the kernel. If you're in the kernel, why do you need a process at all? For the GUI? What are we writing here, MFC trojans? There's not a ton of entropy in the kernel, but there's enough that the next generation of rootkits is going to be able to avoid memory forensics as a problem they even have to think about. The gradient here is against memory forensics tools - they have to do a ton of work to counteract every tiny thing a rootkit writer does. With exploits it's similar. Conducting memory forensics on userspace in order to find traces of CANVAS shellcode is a losing game in even the medium run. Anything thorough enough to catch shellcode is going to have too many false positives to be useful. Doesn't mean there isn't work to be done here, but it's not a game changer. ----------------- Dave, I know we spoke about this a few weeks ago, but I did not get a chance to state my disagreement with your opinion. You state that you can do a lot with memory forensics today to find trojan drivers (.sys), and you can. Last time I looked at CANVAS with MOSDEF you were hiding sockets using a TCPIP.sys IRP hook. This shows up like a red flag with memory forensics. First, you are hooking IRPs which are easy to check. Secondly, you are hiding a port by filtering a query to tcpip.sys, but with memory forensics you cannot filter because nothing is queried. Now could MOSDEF be written in a way that more subtly disguised the hook? Certainly and perhaps you already have. Is it possible to create a port for communication without creating a port object? Yes, Joanna demonstrated this with Deepdoor, but the level of effort increases tremendously. Deepdoor still used hooks to intercept packets. The hooks were just hidden deeper than anyone had looked. So yes it is an arms race to "counteract every tiny thing a rootkit writer does", but when doing detection I do not have to detect "every tiny thing" just some things. I will not argue with the fact there is no need to hide processes. Joanna, Greg, etc. have been saying that for years. However, a lot of intruders still use this technique for whatever reason. Let's use memory forensics and eliminate that problem forever. Can memory forensics find traces of CANVAS shellcode? Yes, but it is an extremely expensive operation in regard to time. Does it have false positives? Yes, but instead of looking at perhaps 100 memory sections across 100 processes memory forensics can narrow that down to four or five. Another thing that falls quickly to memory forensics is poor coding practices by the exploit writers. If a handle is left open by mistake or memory is not freed, it is quickly spotted. Peter Silberman has used this to reconstruct the command and control communications of another popular pentesting tool. Does this mean you cannot bypass this detection with proper developers? No. Don't forget though that freed does not necessarily mean gone. Using memory forensics common but stupid techniques malware author's use to prevent reinfecting a box are much easier to spot. For example, with memory forensics you can find all the mutexes a process has open. This might seem like a small thing, but memory forensics is giving us a view into what is happening on the host in ways we did not have before. Is the gradient against memory forensics? Perhaps, but it always is as your attacker evolves. I think now there is more of a gradient for the malware authors than there has been. They have been fighting the war on the disk for a long time. Now it is time they look up to memory as we sharpen our tools for the changing battlefield. Jamie Check here to play with memory forensic tools: http://mandiant.com/software/memoryze.htm to be used with http://www.mandiant.com/software/mav.htm http://www.openrce.org/articles/full_view/32 _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Palladium, Memory Forensics, Clouds. Dave Aitel (May 20)
- Re: Palladium, Memory Forensics, Clouds. Joanna Rutkowska (May 21)
- Re: Palladium, Memory Forensics, Clouds. Curt Wilson (May 21)
- Re: Palladium, Memory Forensics, Clouds. Dave Aitel (May 22)
- Re: Palladium, Memory Forensics, Clouds. Joanna Rutkowska (May 22)
- Re: Palladium, Memory Forensics, Clouds. Dave Aitel (May 22)
- Re: Palladium, Memory Forensics, Clouds. James Butler (May 25)
- Re: Palladium, Memory Forensics, Clouds. dave (May 27)
- Re: Palladium, Memory Forensics, Clouds. Matthieu Suiche (May 27)
- Re: Palladium, Memory Forensics, Clouds. Dominique Brezinski (May 27)
- Re: Palladium, Memory Forensics, Clouds. dave (May 27)