Dailydave mailing list archives

By Date

By Thread

Re: Palladium, Memory Forensics, Clouds.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Certainly the CANVAS kernel rootkit is not a covert one. I think it would
be somewhat expensive to do basic adversarial testing in the kernel
space on this, although I think it would be valuable research for the
community.

Is memory forensics "testable" against userspace? Memoryze can find
hidden sockets and stuff, but I remember a paper from Peter on "finding
shellcode" or something. Is that publicly available?

Something Bill Arbaugh said is that one major advantage for memory
forensics is that a machine has a lot less memory than it does disk
space. Searching through disk space (or even storing it if you do enough
forensics) is extremely expensive.

To your credit you've released a lot of tools in the space people can
use for testing the general concepts, which is a valuable thing for
determining the overall level of effort curve of the technology itself.

Hopefully soon I'll have some real world numbers here for you. :>

Do the DD.exe and similar tools go underneath the memory handlers? I
assume modern rootkits are memory handlers (or hypervisors). I'm not
sure how acquisition really works against that.

- -dave

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkodeVAACgkQtehAhL0ghep2pQCdHp3o+dwUrMvn9zDSLJEbsqeJ
ey0AnjOkrGMGaT3aMEur8lI78bQKhO+t
=lnhV
-----END PGP SIGNATURE-----
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave

By Date

By Thread

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. 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)