Auteur Sujet: [FireEye]The changing battlefield in Memory  (Lu 2693 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne igor51

  • Admin
  • Mega Power Members
  • *****
  • Messages: 10419
[FireEye]The changing battlefield in Memory
« le: juillet 24, 2020, 08:00:26 »
The changing battlefield in Memory


 

Steve Davis and I gave a talk at Blackhat and at Defcon called         href="http://www.blackhat.com/presentations/bh-usa-09/SILBERMAN/BHUSA09-Silberman-MetasploitAutopsy-SLIDES.pdf">Metasploit
        Autopsy: Reconstructing the scene of the crime.
Giving
    the talk was a blast; both Steve and I were thrilled to be given an
    opportunity to give a defensive security talk on the Metasploit
    track. During our talk and in several interviews, we stated that
    some aspects of computer security are a cat and mouse game. When you
    make a technique, tool, or other knowledge public people have a
    chance to analyze what you have done. This analysis can lead to
    better code, improvements to ideas, or in some cases the breaking of
    said tools. In the case of       href="http://www.mandiant.com/software/msff.htm">Metasploit
      Forensic Framework (MSFF), the newest release of Metasploit
    flat out broke MSFF. First, let me give you some background. When we
    first started writing the tool, we quickly realized that breaking
    MSFF would take a single line change to Meterpreter. The fix is
    simple. In our talk, we discussed that when meterpreter called
    free the received/sent packets were not scrubbed and lay
    around memory for hours. MSFF capitalized on this using       href="/content/fireeye-www/en_US/services/freeware/memoryze.html">Memoryze
    to acquire the processes address space which included the
    process's freed memory. HD and crew were nice enough to wait to
    patch Meterpreter until after our talk. Meterpreter was patched
    Saturday with memset's, which zero out the packet data before
    the memory is freed.

With this fix, our current technique to
    reconstruct what Meterpreter sent or received does not work. The
    Metasploit project has broken that ability successfully (something
    we expected). Our detection will evolve, and HD discussed some ideas
    he had to make detecting the Meterpreter binary harder. Currently,
    MSFF can still be used to identify the injected binaries in a
    process's address space. The Meterpreter binary contains too much
    code and has too many features to effectively hide in memory. If and
    when HD patches the reflective loader to scrub Meterpreter's binary
    data, we'll update MSFF with some fix, more as a proof concept than
    anything else, to continue to identify the injected DLLs. Hope
    everyone's recovered from Vegas!

A huge thanks go to Ping,
    Nikita, Jeff Moss, Val Smith and HD for putting the Metasploit track
    together. It was not easy, but it went great. A huge thanks to the
    defcon speakers, who were very flexible.


Source: The changing battlefield in Memory

Tags: