volatilityfoundation
Feature Request: Support Live Shimcache Data Extraction via Winpmem
Is your feature request related to a problem? Please describe. Shimcache is a critical piece of file execution/modification evidence during incident response. However, because Shimcache entries are typically written to disk only on system shutdown, memory-based evidence of Shimcache might not be captured if there is no shutdown event. Additionally, for large-scale environments (with tens or hundreds of machines), it is often impractical to perform a full RAM capture from each system just to preserve the Shimcache data in memory. As a result, traditional disk-based collectors might miss recent or in-memory Shimcache entries.
Describe the solution you'd like I propose adding a data layer or functionality within Volatility that can interact with live Windows memory (via the Winpmem driver). Then, when an analyst runs a plugin—e.g., something like shimcachemem—with a --live (or similar) flag, Volatility would connect to the live system’s memory and extract in-memory Shimcache data.
Because Volatility is Python-based and relies on multiple dependencies, this feature would ideally include a self-contained binary build (e.g., via PyInstaller) to facilitate deployment on endpoints without requiring a full Python environment.
Describe alternatives you've considered
- Full Memory Capture: While capturing a full memory dump from each machine would work, it’s not scalable for large infrastructures, where obtaining a complete dump from each system may be impractical (due to time, bandwidth, or impact on operations).
- Traditional Disk-Based Collection: Relying on existing disk-based collectors misses any Shimcache entries that have not yet been flushed from memory to disk.
Additional context I’ve begun experimenting and writing code that interacts with the Winpmem driver to read memory in real time. I’d appreciate input from the Volatility team about feasibility, design considerations, or other suggestions. If there are known barriers to implementing live analysis (e.g., forensic soundness, driver maintenance, etc.), let me know—maybe we can collaborate on ways to address them.
Thank you for your time and consideration!
Hiya, there's a few points in here:
First off, rather than tasking volatility to read your memory, it might be better to get a different tool specifically designed to check for such things. This feels slightly like trying to use a lawn mower to cut a single blade of grass. It might work, but it's probably an overpowered tool for the specific use case you've got. If you're going to be running winpmem on the live system, you might as well run any other tool to access the registry (or even pull it from raw memory if you don't trust the API calls).
Secondly, in order to get Volatility 3 working at the speed it works, it makes assumptions and caches a number of structures (such as page tables and similar), meaning you're more like to get memory smear and less likely to get robust results that could live up to the stringent requirements of most forensic tools. To try to undo these speedups would drastically slow volatility down (as evidenced by volatility 2). This again suggests another piece of software would be better placed to achieve this goal. Volatility 3 is not designed to analyze memory that can change.
Lastly, we have implemented the infrastructure to start shipping a self-contained executable version of volatility (and volshell) for the next release (we were hoping to get it in the December release, but it just missed the testing cut-off unforutnately). However, we're unlikely to ship external tools along with volatility, because people would likely report bugs with the other tools to our team and we already have a difficult enough time servicing the requests we get.
I believe winpmem comes with an adaptor that can expose the memory as if it were a file (certainly https://github.com/ufrisk/LeechCore and similar come with this) and you could then direct volatility to read that file. The aforementioned provisos would still come into play though, changing memory fundamentally affects the assumptions volatility 3 makes about the image it is analyzing.
