**TL;DR:** This blog post tackles the intersection of digital forensics and penetration testing, sometimes refered to as 'Offensics' or 'OffFOR'. We then highlights the importance of Windows crash dump analysis in cybersecurity. After outlining the architecture of Windows crash dumps and explores various techniques to extract Windows credentials from RAM dumps, the post introduces 'Forensike,' a custom PowerShell tool I wrote. It combines forensics and debugging techniques to enhance credential extraction, demonstrating its application and benefits in the realm of offensive security **Introduction:** In the ever-evolving landscape of cybersecurity, the fusion of digital forensic techniques and penetration testing emerges as a interesting strategy for bypassing and strengthening defense mechanisms. This blog post aims to shed light on the pivotal role of Windows crash dump analysis in this context. We start by unraveling the architecture of Windows crash dumps, understanding how they store system information that can be a goldmine for cybersecurity professionals. We then explore methods for extracting Windows credentials from RAM dumps, in order to perform lateral movement within internal and Active Directory environment. To cap it off, I will introduce 'Forensike,' a PowerShell tool I've developed. This script exploits admin rights and automatizes known debugging techniques over a pwned machine ![[forensic kermit.jpg]] ## I : Windows Crash Dumps Windows crash dumps are files that contain a snapshot of a system's memory at the moment of a crash, failure, or in some cases, as part of a scheduled capture. These dumps are significant for diagnosing and understanding the reasons behind a system crash or failure. Originally used for troubleshooting, threat actors quickly understood that those files (manually generated or found on victim systems) could also serve malicious purposes. An occurrence of digital forensics techniques used for offensive (malicious) goals is this ransomware case from [Lorenz ransomware gang](https://arcticwolf.com/resources/blog/lorenz-ransomware-getting-dumped/) Crash dumps generated by Windows can be : 1. **Complete Memory Dump**: Captures all content of the system memory. 2. **Kernel Memory Dump**: Contains all the memory in use by the kernel at the time of the crash. 3. **Small Memory Dump**: A much smaller dump file, usually around 256 KB, which includes basic information such as the stop code, parameters, list of loaded drivers, process and thread information, and a part of the kernel-mode call stack. This type of dump is often refered to as ***Minidump*** ![[image-2.png]] Source : *https://www.magnetforensics.com/blog/full-memory-crash-dumps-vs-raw-dumps-which-is-best-for-memory-analysis-for-incident-response/* Windows Crash dumps are often considered superior to classic raw RAM dumps in the sense that they are more structured and contain more information in their header sections. **RAW Dumps** are preferred for a comprehensive forensic analysis where every bit of memory might be relevant, offering wide compatibility with forensic tools but requiring more effort to parse and analyze. On the other hand, **Crash Dumps** are tailored for crash analysis and debugging in Windows environments, providing structured information that can simplify the analysis of system crashes. Their creation and analysis are more straightforward for the intended purpose but are less versatile for general forensic analysis outside crash debugging scenarios. ## II : Extracting Credentials from Windows RAM dumps To perform movement within environments, attackers' fastest way of progressing between systems is [OS Credential Dumping](https://attack.mitre.org/techniques/T1003/001/) . By dumping critical processes' memory on compromised systems, threat actors get their hands on more Windows and Active Directory user/machine accounts to abuse their rights within the infrastructure : Yes, I am looking at you LSASS ![[bernie_wants_lsass.jpg]] LSASS.exe (Local Security Authority Subsystem Service) is probably one of the most famous Windows process in cybersecuritys, as it acts as the main actor in Windows and AD authentication by managing and storing credentials. Please read this nice [article](https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication) about LSASS.exe if you want to understand the way it works As LSASS is fundamental to the way Windows works and to its security, it is probably the most heavily monitored process by EDRs. An never-ending cat and mouse game has been engaged by attackers who always try to find new ways to dump LSASS.exe memory as it contains Windows passwords and hashes. Some of these techniques involves performing RAM dumps : 1. ***Volatility + MRC*** Volatility is the most famous digital forensics framework when it comes to memory analysis. As it is written in Python, its portability and simplicity are great to retrieve interesting artefacts from dump files. However, Volatility does not make the difference between dump files that were generated by Incident Response professionals or threat actors. Here, a dump file was created with [MAGNET RAM CAPTURE](https://www.magnetforensics.com/resources/magnet-dumpit-for-windows/) by an attacker who obtained admin rights on an Internet facing server and then retrieved for offline credential extraction. Through the use of the **volatility3.plugins.windows.hashdump** [module](https://volatility3.readthedocs.io/en/latest/volatility3.plugins.windows.hashdump.html), Volatilty3 can be leveraged for malicious purposes. Here, the attacker extracted the SAM and SYSTEM registries from the target dump, but other useful Volatility plugins can be leveraged to extract other types of Windows credentials, such as the **windows.cachedump.Cachedump** to grab domain cache hashes. ![[volatility1.png]] 2. ***Volatility Mimikatz plugin*** During the days of Volatility2, community used to regularly develop and post new plugins to implement more functionalities to the tool. The [Mimikatz](https://github.com/volatilityfoundation/community/blob/master/FrancescoPicasso/mimikatz.py) plugin was written by FrancescoPicasso in order to replicate the decypher work of the original mimikatz `sekurlsa::LogonPasswords` module. By specifying an input dump file and an associated Windows profile, Volatility2 users can read the LSASS.exe segment of the RAM dump file ![[volatility_mimikatz.png]] 3. ***Physmem2Profit*** Physmem2profit was an innovative LSASS extraction tool that was composed of 2 main components : - A C# agent (server) to be executed on a target system. Once running, the agent loads the Winpmem driver in order to capture live memory and exposes it to the attacker machine through a TCP port. - A python client, connecting from the attacker machine to the TCP port in order to mount the target exposed physical memory. The client then performs a process dump on the exposed LSASS process to read it : - ![[physmemlayout 1.png]] https://github.com/WithSecureLabs/physmem2profit/blob/public/docs/physmemlayout.png The analysis and dump operations are performed by Rekall (Volatility fork) plugins that were reimplemented in the tool code. Unfortunately, Rekall development is no longer maintained and using Physmem2profit may have become really tricky due to dependence issues. However, the Winpmem driver (which also originated from Rekall) does have its [own repository](https://github.com/Velocidex/WinPmem) and could still be used for memory acquisition/defense evasion purposes (for a long time, Winpmem remained one of the only reliable method for RAW format memory acquisition). 4. ***Conversion attack*** The 'conversion attack' terminology designates the process of turning a specific memory dump extension into a readable, and more precisely exploitable, format to extract Windows credentials. Here, the Magnet Forensics/Comae Toolkit will come in handy again, as it offers the possibility to convert more **exotic** file extension generated by unique technologies such as VMWare vmem files or the Windows hibernation files. Most of the time, those extensions are only RAW format dumps in disguise, and they can be easily converted into good old familiar Crash dump format .dmp. If not, they can still be converted into RAW, and then converted again into .dmp Numerous tools allow this type of conversion, such as the Hibr2Dmp or Bin2Dmp (Comae Toolkit) or even Volatility2. Here is a very nice conversion path explanation from Diverto's blog : ![[conversion-paths.png]] Source : https://diverto.hr/en/blog/en-2019-11-05-Extracting-Passwords-from-hiberfil-and-memdumps/ Hibernation files used to represent invaluable sources of information about systems from a forensic perspective. Indeed, Windows uses the hiberfil.sys file to store a copy of the system memory on the hard disk when the hybrid sleep setting is turned on. The main goal being Windows resuming a powered-off system to its previous state. If this file is not present, the computer cannot hibernate. However, the most recent versions of Windows came with a new format for the hyberfil.sys file (architectural as well as pages amount differences) breaking existing analysis tools and methodologies. This 2016 [paper](https://www.cct.lsu.edu/~golden/Papers/sylvehiber.pdf) by Joe T. Sylve, Vico Marziale and Golden G. Richard II is the best free resource you will find online if you want to know about system hibernation and memory analysis. This academic work is the perfect follow-up to this classic Matt Suiche [presentation](https://www.blackhat.com/presentations/bh-usa-08/Suiche/BH_US_08_Suiche_Windows_hibernation.pdf) at Blackhat USA 2008. 5. WinDBG + mimilib.dll The last extraction technique is already mentioned on some of the other blog posts above, but we are going to explain the big idea. Benjamin Delpy a.k.a GentilKiwi (the GOAT) developed an extension called mimilib.dll (available on the official repository for mimikatz). Once you loaded the crash dump file you previously created or retrieved in your WinDBG session, you can then load the mimilib.dll file to expands the set of available commands and basically perform what mimikatz does with `sekurlsa::LogonPasswords`module, on a crash dump file. ![[windbg 1.png]] You can then search for LSASS process address with `!process 0 0 lsass.exe` and get into its context with `.process /r /p <LSASS adress>`. The extension can then read lsass process, parse the results and display it back with `!mimikatz` ![[windbg2.png]] ## III : Forensike : Remotely dump lsass by generating a Crash Dump ![[forensic_smart.jpg]] When I first read about the Lorenz attack described at the beginning of this article, one of my first question was : Could I do the same in a remote manner, in a pentest/red team engagement ? In other words, I wanted to automatize this TTP that I found fascinating. The final tool needed to overcome a number of obstacles : - **Storage** : The very principle of a RAM dump is capturing volatile computer memory to write on a disk. If I needed to write a large file, where do I do it ? On the target machine ? On the attacker machine ? Elsewhere ? - ** Crash Dump** : The main pro of a crash dump is its structure. As it is the best dump type for Windows environment, I prefer to use it, but how do we generate a crash dump without crashing the target system in the end ? - **Acquisition** : The whole crash dump process needs to be performed remotely - **Debugging** : The extraction/debugging process also needs to be performed remotely as I did not want the crash dump to be transferred from the target to the attacker machine (not interesting time, storage and stability wise) - **Defense** : How do EDRs react VS a crash dump generation ? VS debugging tools ? (spoiler alerts, EDRs do not like mimilib.dll...) Here are the solutions I came up with : - **Storage** : Decided to store the final crash dump file on the target machine. As debugging can be performed remotely, no need to retrieve the dump file through the network - **Crash Dump** : I will be using the most stable and performant tool : DumpIt from Magnet FORENSICS (previously from the ComaeToolkit). It is easy to deploy, fast and never causes BSOD. Matt Suiche going at it again ! - **Acquisition** : Creation of a temporary PSDrive for tool transferring - **Defense** : At the time of writing, I have not encountered a specific EDR technology that has a default policy against the generation of Windows Crash dumps. The EDR I have worked against in my engagements and personal tests never blocked the writing of DumpIt on the target's disk nor the generation of final crash dump file. As the signatures of RAM acquisition tools are not blocked by EDRs, they never prevent them from acquiring memory. The only trace left on the target system is probably the loading of the said drivers. In the end, it seems logical that EDRs cannot really prevent these tools from dumping RAM, as I feel most of them simply don't watch physical memory. I like to consider this attack as an extension of BYOVD attacks (Bring Your Own Vulnerable Driver) Also, LSASS memory is never directly read by DumpIt. And this attack does not consist in dumping one or two critical processes, so EDRs probably end up letting it be without considering it a threat. ![[blind_EDR 1.gif]] One last thing I like about Forensike is that it operates on a sort of hybrid basis. As Forensike relies on the mimilib.dll extension of mimikatz to extract NT hashes from the crash dump LSASS process, it cannot be written on the target disk, therefore it needs to remain on the attacker machine. On the other hand, retrieving the final crash dump files is too complicated due the size of the file, so it needs to remain on the target machine. In the end, Forensike invokes WinDBG with admin rights over the compromised system, which allows loading the crash dump remotely over SMB, by specifying a UNC path. The debugging process is 100% done remotely (debugged file is still on the target's disk) while the debugging extension remains on the local attacker machine. The end NT hashes are then written on a txt file on the attacker machine. However, Forensike remains a very situational tool. As it creates crash dumps and plays with full RAM dumps, please consider risks of crashing/drastically slowing down the target machine you try to retrieve lsass memory from. Please do not forget you basically dump the full haystack in order to retrieve a single needle. It can appear as overkill, but it remains free of the EDR obstacle. ![[Forensic.jpg]] For simplicity, I wanted to make it a SharpHound-like tool, as you need to launch the script from a domain user session that has admin rights over the target machine. Once you get your hands on the appropriate account credentials, you can `runas /netonly /user:DOMAIN\USERNAME powershell.exe` to start a powershell session that you will launch Forensike from. Or use mimikatz.exe to (Over)Pass-the-hash first and then launch Forensike. The whole project is written in Powershell and requires some prerequisites : - WinDBG installed on local machine - DumpIt executable - mimilib.dll file Code and usage details are available on this [repo](https://github.com/y00ga-sec/Forensike) Thank you for reading !