Want the full story? Go get the whitepaper here.
Tool testing is a big deal, particularly in forensics where a malfunctioning tool can lead investigators to seriously wrong conclusions. In the area of memory forensics, we need to acquire memory using a tool that has a very minimal footprint. Memory can't be acquired without displacing other memory. We want to displace the minimal amount possible to retain as much unallocated memory as possible.
WinPmem has been a "go to" tool for many investigators performing memory acquisition. It's free, open source, lightweight, and command line. I love open source tools for forensics. Gives me confidence that I can always understand what the tools is doing. WinPmem is everything I'm looking for in a memory acquisition tool and I teach it in the SANS FOR526 memory forensics course (I co-author that course with Alissa Torres). I also do a lot of memory forensics in investigations for clients. I'll highlight all of the reasons another time, but for now just let me say that it's a real game changer.
Upgrade Immediately? Not here...
When WinPmem recently updated to version 2.x, we didn't immediately update at Rendition Infosec. I was excited about the compression that it offered, but it also output in AFF4 and the only tool that really reads that is rekall. It's not that I don't love rekall - I do (in fact, I'll be publishing a new rekall plugin this week or early next week, so stay tuned). But sometimes I need other tools and we just didn't have the bandwidth to update all of our scripts to account for the AFF4 difference. Also (and very critically), we don't deploy forensics tools without testing. This has saved our butts more than once, but in this case the implications could have been huge.
Testing Thy Tools
After reviewing a presentation by Brent Muir on Windows 10 forensic artifacts yesterday, we noted that Brent made some pretty lofty claims about memory usage in WinPmem. Specifically, he noted the difference in memory usage between WinPmem 1.6.2 and WinPmem 2.x was pretty substantial. This wasn't really the theme of the presentation, more of a footnote. But it caused us to step up our game and prioritize WinPmem testing. I engaged Brandon McCrillis, an awesome Senior Infosec Analyst who works with me, to help out with some testing.
Wow. With WinPmem 1.6.2 we see memory use of 1.8MB. With WinPmem 2.0.1 we see memory use of 94.81MB. These came from the same machine. That's 93MB of memory you'll lose just by using a newer version of WinPmem for acquisition. It turns out that newer isn't always better.
Some testing with ELF output format (thanks to Alissa Torres for the idea and initial testing) shows that when the output format is set to ELF, the memory usage is substantially lower. But lower doesn't mean good. Even with ELF, we're still looking at pretty substantial memory usage compared to the 1.6.2 build (22.6 MB vs 1.8MB). Note that we're not comparing apples to apples here. WinPmem 1.6.2 allowed for raw output formats but that ability was removed in WinPmem 2.x. It appears that the formatted output impacts the memory usage (and pretty dramatically at that).
But WinPmem 1.6.2 supports output in ELF format too. Does using ELF output format in 1.6.2 cause increased memory usage? Testing showed that this condition was unique to WinPmem 2.0.1.
Conclusion
We were pretty amazed at what we found. WinPmem 2.0.1 uses a LOT more memory than 1.6.2. Although we began investigating this thinking it was a Windows 10 issue, we quickly discovered that it was present on all OS versions. For the time being, we recommend using 1.6.2. There's plenty more information in the whitepaper we put together, but this is enough to get the gist.
Blatant Disclaimer
I am in no way indicating that you should not use WinPmem. I personally love the tool and thank Michael Cohen for making it available. He's been made aware of the issue and will hopefully patch in the very near future.
Tool testing is a big deal, particularly in forensics where a malfunctioning tool can lead investigators to seriously wrong conclusions. In the area of memory forensics, we need to acquire memory using a tool that has a very minimal footprint. Memory can't be acquired without displacing other memory. We want to displace the minimal amount possible to retain as much unallocated memory as possible.
WinPmem has been a "go to" tool for many investigators performing memory acquisition. It's free, open source, lightweight, and command line. I love open source tools for forensics. Gives me confidence that I can always understand what the tools is doing. WinPmem is everything I'm looking for in a memory acquisition tool and I teach it in the SANS FOR526 memory forensics course (I co-author that course with Alissa Torres). I also do a lot of memory forensics in investigations for clients. I'll highlight all of the reasons another time, but for now just let me say that it's a real game changer.
Upgrade Immediately? Not here...
When WinPmem recently updated to version 2.x, we didn't immediately update at Rendition Infosec. I was excited about the compression that it offered, but it also output in AFF4 and the only tool that really reads that is rekall. It's not that I don't love rekall - I do (in fact, I'll be publishing a new rekall plugin this week or early next week, so stay tuned). But sometimes I need other tools and we just didn't have the bandwidth to update all of our scripts to account for the AFF4 difference. Also (and very critically), we don't deploy forensics tools without testing. This has saved our butts more than once, but in this case the implications could have been huge.
Testing Thy Tools
After reviewing a presentation by Brent Muir on Windows 10 forensic artifacts yesterday, we noted that Brent made some pretty lofty claims about memory usage in WinPmem. Specifically, he noted the difference in memory usage between WinPmem 1.6.2 and WinPmem 2.x was pretty substantial. This wasn't really the theme of the presentation, more of a footnote. But it caused us to step up our game and prioritize WinPmem testing. I engaged Brandon McCrillis, an awesome Senior Infosec Analyst who works with me, to help out with some testing.
 |
| WinPmem 1.6.2 memory usage - pay special attention to Peak Private Bytes |
 |
| WinPmem 2.0.1 memory usage - pay special attention to Peak Private Bytes |
Some testing with ELF output format (thanks to Alissa Torres for the idea and initial testing) shows that when the output format is set to ELF, the memory usage is substantially lower. But lower doesn't mean good. Even with ELF, we're still looking at pretty substantial memory usage compared to the 1.6.2 build (22.6 MB vs 1.8MB). Note that we're not comparing apples to apples here. WinPmem 1.6.2 allowed for raw output formats but that ability was removed in WinPmem 2.x. It appears that the formatted output impacts the memory usage (and pretty dramatically at that).
 |
| WinPmem 2.0.1 ELF output memory usage - pay special attention to Peak Private Bytes |
Conclusion
We were pretty amazed at what we found. WinPmem 2.0.1 uses a LOT more memory than 1.6.2. Although we began investigating this thinking it was a Windows 10 issue, we quickly discovered that it was present on all OS versions. For the time being, we recommend using 1.6.2. There's plenty more information in the whitepaper we put together, but this is enough to get the gist.
Blatant Disclaimer
I am in no way indicating that you should not use WinPmem. I personally love the tool and thank Michael Cohen for making it available. He's been made aware of the issue and will hopefully patch in the very near future.
one more great post from Jake Williams
ReplyDeleteVolatility can read Rekall dumps, just need to decompress
ReplyDeleteI meant winpmem dumps*
DeleteVolatility can read Rekall dumps, just need to decompress
ReplyDelete