Re: Palladium, Memory Forensics, Clouds.

["James Butler" <butlerjr () acm org>]

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