Memory Forensics for Incident Response: Tools and Methodology Guide
The adversary techniques that most commonly evade detection today share a common characteristic: they avoid touching disk. PowerShell payloads executed from a malicious document, reflective DLL loaders that inject code directly into process memory, and credential harvesters that read LSASS memory and export results over an encrypted channel leave little to no recoverable artifact on the file system. Disk forensics alone cannot find what was never written to disk.
Memory forensics closes that gap by capturing the live execution state of the system: every running process, every loaded module, every active network connection, every region of executable code, and every credential loaded into the authentication subsystem. This guide covers the complete incident response workflow for memory forensics, from acquisition methodology through Volatility 3 analysis, process injection and hollowing detection, credential artifact recovery, and the extension of these techniques to Linux, macOS, and cloud environments.
Why Memory Forensics Matters: Fileless Attacks and Living Off the Land
The shift toward fileless and living-off-the-land techniques is not an accident of threat actor preference; it is a deliberate response to the improvement of file-based detection capabilities. As endpoint security tools became increasingly effective at detecting malicious executables through signature matching, behavioral analysis, and machine learning on file content, sophisticated attackers pivoted to techniques that deliver and execute payloads entirely within memory, using operating system features and legitimate tools rather than custom executables that can be scanned and flagged.
Living-off-the-land (LotL) attacks use native Windows binaries and scripting environments, including PowerShell, WMI, mshta.exe, certutil.exe, and rundll32.exe, to execute attacker-controlled code. Because these are legitimate, signed Microsoft binaries, signature-based detection cannot flag them as malicious; only behavioral analysis of what they are doing, which requires runtime observation, can detect abuse. Reflective DLL injection loads attacker-supplied DLLs into the address space of a legitimate process without writing the DLL to disk first, making the payload invisible to file-based scanners. Process hollowing creates a legitimate process in a suspended state, replaces its memory content with attacker shellcode, and resumes execution, resulting in a process that appears legitimate by name and signature but executes malicious code.
The types of evidence found exclusively in memory are extensive: decrypted payloads that a loader decrypted in memory but never wrote to disk, injected shellcode living in the memory space of a legitimate process, command-line arguments passed to processes that have since exited, network connections and DNS resolutions that occurred during the session, Kerberos tickets and NTLM hashes in LSASS memory, cleartext passwords for browser-stored credentials in Chrome or Firefox process memory, and registry key values loaded into memory that differ from their on-disk representation due to rootkit modification.
Memory forensics should be triggered in an IR workflow whenever the initial indicators suggest a sophisticated actor, when endpoint detection tools report process injection or in-memory execution, when a credentialed access event is suspected and disk analysis does not explain it, or when the timeline of infection cannot be reconstructed from disk artifacts alone. Building memory acquisition into IR playbooks as a standard step rather than an escalation option ensures that the decision to capture memory is made proactively during the first responder's arrival rather than after valuable volatile evidence has been lost to a reboot.
Memory Acquisition: Capturing RAM Without Contaminating Evidence
The order of volatility principle establishes that the most volatile evidence should be captured first, since it is most likely to be modified or lost. In digital forensics, RAM is at the top of the volatility hierarchy: it changes with every process execution, every network packet, and every user interaction, and it is completely destroyed by a system reboot or power cycle. CPU registers and cache are even more volatile but are impractical to capture in a forensic context; RAM is the practical starting point, followed by network state (active connections, ARP table, routing table), then running processes and open files, and finally disk content.
Acquisition tools for Windows include WinPmem (open source, outputs raw or AFF4 format), DumpIt (single executable, reliable on most Windows versions), Magnet RAM Capture (graphical interface, useful for field responders), and FTK Imager (includes memory acquisition alongside disk imaging, widely used in enterprise IR). All of these tools require administrator privileges and load a kernel driver to access physical memory pages; the driver itself modifies the memory image minimally by loading its own code. For this reason, acquire memory as early in the response process as possible, before running additional diagnostic tools that add more contamination.
Remote acquisition is preferable to on-site whenever the network path allows, because it minimizes physical access to the compromised system and reduces the risk of the attacker detecting the response activity through local process monitoring. Both WinPmem and DumpIt can be executed via remote administration tools like PSExec, Windows Remote Management, or endpoint management platforms, with output written to a network share on the investigation infrastructure. Verify that the network share path does not traverse the production network segment being investigated, to prevent introducing additional risk.
Acquiring memory from cloud VM instances requires platform-specific techniques. On AWS, Systems Manager Run Command can execute acquisition tools on a Windows or Linux instance and write output to S3; the equivalent on Azure is Azure Run Command. For Linux VMs in cloud environments, the LiME (Linux Memory Extractor) kernel module can be loaded via SSH or run command and used to dump memory to a file or network socket. Memory image formats include raw (a flat binary dump of physical memory in address order), LiME format (Linux-specific with a header), and AFF4 (a structured container format supporting compression and metadata). Volatility 3 can process raw and LiME format images natively; AFF4 images require conversion or the aff4-volatility plugin.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Volatility 3: Core Workflow and Essential Plugins
Volatility 3 is the current version of the Volatility memory forensics framework and represents a significant architectural improvement over Volatility 2. It is written in Python 3, uses type-based symbol tables rather than OS profiles for portability, and includes an improved plugin API that allows structured output piping between plugins. Installation requires Python 3.7 or later, the Volatility 3 repository from GitHub, and the dependencies listed in requirements.txt. Symbol tables for Windows analysis are downloaded automatically from Microsoft's symbol server on first use, or can be pre-downloaded and staged for offline environments by following the Volatility documentation.
The basic analysis workflow follows a consistent progression from system identification to process listing to network state to anomaly investigation. Begin with windows.info to confirm the OS version, build number, and basic system metadata, which also validates that the symbol tables loaded correctly. Follow with windows.pslist for a flat list of all processes with their PID, parent PID, creation time, and exit time (if applicable), then windows.pstree for the hierarchical parent-child view that makes anomalous process relationships visible at a glance. A PowerShell process spawned by a web server, a cmd.exe with a SYSTEM-level process as parent, or a legitimate process name running from an unexpected path are the types of anomalies that pstree surfaces immediately.
Essential plugins for initial triage are windows.cmdline (shows the full command line for each process, revealing encoded PowerShell payloads and unusual arguments), windows.netscan (enumerates current and recent network connections and sockets, including those from processes that have since exited), windows.malfind (identifies memory regions with read-write-execute permissions not backed by a mapped file, the primary indicator of injected shellcode), and windows.dlllist (lists loaded DLLs for a specified process, revealing injected DLLs that do not match the expected load list). Supplementary plugins include windows.handles (lists open handles for a process, useful for identifying accessed files and registry keys), windows.dumpfiles (extracts PE files or other files from memory to disk for further analysis with a disassembler or AV scanner), and windows.registry.hivelist with windows.registry.printkey for examining in-memory registry content.
A critical technique for detecting hidden processes is comparing the output of windows.pslist against windows.psscan. Windows.pslist walks the doubly-linked list of EPROCESS structures that the Windows kernel maintains; a rootkit can hide a process by unlinking it from this list. Windows.psscan scans physical memory for the EPROCESS structure pattern regardless of list membership, finding processes that have been unlinked from the active process list. Any process that appears in psscan output but not pslist output is hidden by a rootkit and requires immediate investigation. The reverse, a process appearing in pslist but not psscan, can indicate a very recently terminated process that was removed from the pool before the scan reached that memory address.
Detecting Process Injection and Hollowing
Process injection is the technique of loading and executing malicious code within the address space of a legitimate running process. It is used to evade process-based detection (the malicious code runs under a trusted process name), bypass application whitelisting (the host process is whitelisted), and avoid firewall rules (network connections appear to come from a trusted application). The major injection techniques each have characteristic memory artifacts that Volatility plugins can identify.
Classic DLL injection uses a sequence of VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread API calls to allocate memory in the target process, write a DLL path into it, and create a remote thread that calls LoadLibrary with the injected path. The injected DLL appears in the target process's DLL list and is backed by a file on disk (the malicious DLL), making it visible to windows.dlllist. Reflective DLL injection uses a custom loader embedded in the DLL itself to map the DLL into memory without involving LoadLibrary or the Windows loader, resulting in memory regions that contain PE content but are not backed by a file in the standard module list. Process hollowing creates a legitimate process in PROCESS_CREATE_SUSPENDED state, unmaps its main executable from memory with NtUnmapViewOfSection, writes malicious code into the now-empty address space, and resumes the process; the process tree shows a legitimate process name but its memory content is replaced.
The windows.malfind plugin is the primary tool for identifying injected memory regions. It flags VAD (Virtual Address Descriptor) entries that have PAGE_EXECUTE_READWRITE permissions, that contain content starting with the MZ magic bytes indicating an embedded PE file, and that are not associated with a file-backed mapping. Because PAGE_EXECUTE_READWRITE is an unusual permission combination for legitimate code (normal PE sections are typically either executable or writable, not both), malfind catches a high proportion of injected shellcode and reflectively loaded DLLs. Not all malfind results are malicious: JIT compilers (Java, .NET, JavaScript engines) legitimately create executable writable memory regions, so filter these known-benign sources before investigating remaining hits.
Manual validation of malfind results involves examining the flagged memory region content using windows.memmap and windows.vadinfo for the specific process, confirming the presence of an MZ/PE header, and using windows.dumpfiles to extract the region for analysis with a disassembler or AV engine. For process hollowing, examining the VAD tree of a suspicious process with windows.vadinfo and comparing the base address of the main executable to the memory content at that address (which should match the legitimate executable but instead shows attacker shellcode) confirms the hollowing. The windows.pstree output provides the parent-child relationship context: a legitimate process created by an unusual parent is a strong secondary indicator of hollowing combined with suspicious memory content.
Credential Harvesting Artifacts in Memory
The Local Security Authority Subsystem Service (LSASS) is the primary target for credential theft on Windows systems because it maintains credentials for every interactively logged-on user in a format that tools like Mimikatz can extract. On systems without Credential Guard enabled, LSASS stores NTLM password hashes, Kerberos ticket-granting tickets (TGTs) and service tickets, and in some configurations (including older Windows versions with WDigest enabled), cleartext passwords. Accessing LSASS memory is the most reliable path to credential material for lateral movement, and it is among the most common techniques in modern intrusions.
Detecting Mimikatz execution and similar credential harvesting tools in memory involves several approaches. The most direct is examining the LSASS process's handle list with windows.handles; any external process holding a handle to LSASS with permissions including PROCESS_VM_READ is suspicious, since legitimate software rarely needs to read LSASS memory. If the Mimikatz process itself was running at the time of memory acquisition, it will appear in process listing output, though sophisticated operators rename the executable or use reflective loading to avoid a named process being visible. String searching in memory for known Mimikatz output strings, function names, or error messages can identify Mimikatz artifacts even when the process has exited.
Credential Guard, introduced in Windows 10 and Windows Server 2016, addresses LSASS dumping by running the credential storage portion (LSAIso) inside a virtualization-based security (VBS) enclave that even a process running as SYSTEM cannot access. With Credential Guard enabled, Mimikatz can still read the LSASS process but the credential material it finds is encrypted by the VBS enclave and cannot be decoded without access to the isolated environment. Deploying Credential Guard is one of the highest-impact single controls for reducing credential theft risk in Windows environments.
Kerberos ticket artifacts in memory are accessible through windows.cachedump and through third-party Volatility plugins that parse Kerberos ticket structures from LSASS memory. TGTs (Ticket-Granting Tickets) are particularly valuable to attackers because they can be used for Pass-the-Ticket attacks without knowing the account password. Cached domain credentials (the encrypted hashes stored locally to support domain authentication when a domain controller is unreachable) are stored in the registry under HKLM\Security\Cache and can be examined in memory using registry analysis plugins. Browser credential artifacts appear in the memory of the browser's main process or renderer processes: Chrome encrypts stored passwords using the DPAPI (Data Protection API), but the decryption key is accessible in browser process memory during an active session.
Network Connections and C2 Detection from Memory
Memory forensics provides a network connection view that complements but differs from network log analysis. The windows.netscan plugin enumerates TCP and UDP endpoints by scanning memory for the data structures Windows uses to track socket state, including connections that may no longer appear in live network tool output because the connection has since closed or because a rootkit has removed it from the visible connection list. Connections in ESTABLISHED, TIME_WAIT, CLOSE_WAIT, and LISTEN states all appear in netscan output along with the owning process ID.
The most immediately valuable netscan output for IR purposes is established connections to external IP addresses from processes that have no legitimate reason for external connectivity. A svchost.exe instance connecting to an IP address in an unusual geographic region on port 443 deserves investigation, particularly if other svchost instances in the process listing do not have network connections. A legitimate process like notepad.exe or explorer.exe with an established connection is almost always indicative of process injection. Note the local port, remote IP, remote port, and PID for each suspicious connection, then cross-reference the PID against the process listing to confirm the process name and examine its cmdline and DLL list.
DNS resolution artifacts appear in memory in multiple locations: the Windows DNS client cache (accessible through windows.registry plugins targeting the DNSCache key), the process heap of the DNS client service, and the resolver cache in the browser or application process that initiated the lookup. Reconstructing the DNS queries a compromised system made during an intrusion from memory can reveal C2 domain names even when network logs are unavailable, because the DNS client caches responses for the duration of the TTL, and low-TTL C2 domains (a common technique to complicate blocklisting) often have entries in the cache from recent resolution.
Listening sockets in the LISTEN state visible in netscan output identify backdoors that an attacker installed to accept inbound connections. A process listening on an unusual high-numbered port or on a port that conflicts with its expected network role (a document viewer listening on a TCP port) is an immediate red flag. Comparing the listening socket list from the memory image against baseline documentation of expected listening services on the system type quickly surfaces anomalous listeners that represent implants or bind shells.
Correlating memory-derived network artifacts with firewall logs, proxy logs, and DNS logs from the network infrastructure creates a complete picture of C2 communication that neither data source alone can provide. Memory gives you the process-to-connection mapping that network logs lack; network logs give you the volume and timing of communication that memory cannot capture after the connections close. The combination is particularly powerful for characterizing beaconing behavior and estimating the duration of the compromise.
Memory Forensics for Linux and macOS
Linux memory forensics requires a different acquisition approach because Linux does not have a stable kernel-level interface for reading physical memory equivalent to Windows. The LiME (Linux Memory Extractor) kernel module is the standard acquisition tool: it is compiled as a loadable kernel module for the specific kernel version and configuration of the target system, loaded with insmod, and dumps memory to a file path or network socket. The requirement to compile for the specific kernel version means that pre-staging LiME modules for your common Linux distributions and kernel versions before an incident is important; compiling on the fly during an incident under time pressure with potential attacker observation is not ideal. On cloud Linux instances, the task is simplified by using the platform's run command capability to load a pre-staged module from a trusted S3 bucket or similar location.
Volatility 3 supports Linux memory analysis through its linux namespace of plugins, which require symbol files generated from the target system's kernel debug symbols. The equivalent of the Windows process analysis workflow on Linux uses linux.pslist (running processes), linux.pstree (process hierarchy), linux.netstat (network connections), linux.bash (reconstructed bash command history from process memory, which can recover commands even if the attacker cleared the bash history file), and linux.malfind for anomalous memory regions. Linux malware frequently uses LD_PRELOAD injection to intercept library calls by preloading a malicious shared library before the legitimate ones; this appears in memory as a shared library loaded by a process that has no corresponding entry in /proc/pid/maps backed by the expected library path.
MacOS memory forensics faces additional challenges introduced by Apple Silicon and T2 security chip hardware. Modern Macs with Apple Silicon running macOS in their default security configuration use Secure Boot and System Integrity Protection in ways that make kernel-level memory acquisition from user space impossible without disabling security features that Apple has made increasingly difficult to disable. Volatility does support macOS memory analysis with mac namespace plugins when an image can be obtained, but the acquisition problem on modern hardware is the primary constraint. Intel-based Macs without T2 chips remain more practical for memory forensics using traditional kernel extension approaches.
Container memory forensics involves acquiring memory from the host kernel (since containers share the host kernel on Linux), then using the process namespace and cgroup information in the memory image to identify which processes belong to which container. Docker container processes appear in the Linux process listing with their container ID visible through namespace inspection. Cloud workload memory forensics increasingly uses agent-based approaches where a security agent running inside the workload continuously captures process and memory metadata, providing forensic artifacts without requiring physical memory acquisition after the fact.
The bottom line
Memory forensics has moved from a specialist capability used in nation-state intrusion investigations to a core skill required for any incident response team dealing with sophisticated threats. The reason is straightforward: attackers have moved there. When 77% of intrusions use fileless or memory-only techniques, an IR team without memory forensics capability is systematically blind to the majority of advanced attack activity.
Volatility 3 is the accessible entry point for any analyst willing to invest the time. The core plugin workflow covering pslist, pstree, netscan, malfind, and cmdline handles the triage phase of almost every memory investigation involving Windows systems, and the investment in learning those plugins pays dividends on nearly every intrusion involving an advanced threat actor. Organizations should build memory acquisition into IR playbooks as a standard step triggered by any suspicion of sophisticated compromise, stage acquisition tools on response infrastructure before an incident rather than improvising during one, and evaluate Credential Guard deployment as the single highest-impact control for reducing the credential theft risk that memory forensics so consistently reveals.
Frequently asked questions
What is the difference between memory forensics and disk forensics?
Disk forensics analyzes persistent storage artifacts: files, filesystem metadata, deleted file remnants recoverable through unallocated space analysis, registry hives, event logs, and prefetch files. These artifacts survive power-off and reboots, allowing forensic analysis days or weeks after an incident. Memory forensics analyzes volatile RAM content, which is lost permanently when the system is powered off or reboots. Memory holds artifacts that disk forensics cannot find: running processes that never wrote an executable to disk, network connections that are active or were recently active, decrypted payloads that a loader decrypted in memory and never wrote out, injected code living inside a legitimate process's address space, and credentials loaded into LSASS that exist nowhere on disk. The two disciplines are complementary rather than competitive in an incident response workflow. A complete investigation uses both: disk forensics for timeline reconstruction, file recovery, and persistence mechanism analysis, and memory forensics for live process state, injected code recovery, credential theft evidence, and network connection mapping. In intrusions involving sophisticated threat actors who operate without touching disk, memory forensics often provides the only evidence of what the attacker executed.
How do I capture memory from a live Windows system?
Memory acquisition from a live Windows system requires a kernel-level driver to read physical memory, since user-mode processes cannot access the full physical address space. The most commonly used free tools are WinPmem, DumpIt, and Magnet RAM Capture. WinPmem is open source and produces raw or AFF4 format images; DumpIt is a single-executable tool that produces a raw memory image with minimal interaction; Magnet RAM Capture has a graphical interface and is practical for non-technical responders. The acquisition process is straightforward: copy the tool to a USB drive, plug it into the target system, run the tool as an administrator, and write the output image to the USB drive or a network share on your investigation infrastructure. Time the acquisition carefully; a 16 GB RAM system takes roughly 3 to 5 minutes to image, during which you should minimize all other activity on the system to reduce contamination of the memory image. Every tool you run during a live response modifies memory by loading its own code and data, so minimize the number of tools you run before acquisition and document everything you ran before it. Record the system time, running processes as seen in Task Manager, and active network connections using netstat before and after acquisition to provide context for the analysis.
What is Volatility and how do I get started with it?
Volatility is an open-source Python framework for memory forensics, maintained by the Volatility Foundation, and is the de facto standard tool for analyzing memory images from Windows, Linux, and macOS systems. Volatility 3 is the current version and uses a plugin architecture where each analysis capability is a separate plugin producing structured output. To get started, install Python 3, clone or download Volatility 3 from GitHub, and install its dependencies with pip. Before you can analyze a Windows memory image, you need the symbol table for the specific Windows build the image came from; Volatility 3 can download these automatically from Microsoft's symbol server on first use, or you can pre-download them for offline environments. The basic starting workflow is: run windows.info to confirm the OS version and basic system metadata, then windows.pslist to list running processes, then windows.netscan to enumerate network connections, then windows.malfind to flag memory regions with executable permissions not backed by a file on disk. From there, investigate specific processes flagged by those initial plugins using windows.cmdline to see command-line arguments, windows.dlllist to see loaded DLLs, and windows.dumpfiles to extract suspicious executables or DLLs to disk for further analysis. The Volatility documentation and the SANS FOR508 course materials are the best structured resources for building proficiency beyond these initial plugins.
What is fileless malware and why does it require memory forensics to detect?
Fileless malware is malicious code that executes entirely in memory without writing a traditional executable file to disk. Common delivery mechanisms include malicious PowerShell or WMI commands that are executed directly from a script or command line, reflective DLL injection where a DLL is loaded into a process's memory space without being written to disk first, and process injection where shellcode is allocated and executed within the memory space of a legitimate process like explorer.exe or svchost.exe. Because no executable file is written to disk, endpoint security tools that rely on file scanning miss the payload entirely. After execution completes or the system reboots, the payload is gone with no recoverable artifact on disk. Memory forensics captures the active execution state, revealing the injected code in process memory, the network connections it established, the commands it executed, and the credentials it accessed, all of which are invisible to disk-only forensic methods. The growth of fileless techniques correlates with the improvement of endpoint detection tools: as file-based detection became more reliable, attackers shifted to memory-only techniques specifically to evade it. This shift is why memory acquisition has become a standard step in IR playbooks rather than a specialist escalation.
Can Mimikatz artifacts be detected in a memory dump?
Yes, Mimikatz execution leaves multiple detectable artifacts in a memory image. The most direct evidence is the presence of the Mimikatz binary itself in memory if it was run as a standalone executable: Volatility's windows.cmdline plugin shows the command line used to launch any process, and windows.pslist or windows.pstree shows the process if it was still running at acquisition time. Even if the Mimikatz process exited before acquisition, strings associated with Mimikatz are often present in the memory of the process that launched it, such as cmd.exe or PowerShell, and can be recovered through memory string searching. When Mimikatz dumps credentials from LSASS, it reads LSASS process memory; this activity is logged by Windows Event ID 4656 and 4663 if object access auditing is enabled for the LSASS process handle. In memory analysis, examining the LSASS process memory image directly using windows.lsadump or similar plugins can reveal whether the LSASS address space was accessed by an external process, and the LSASS process's handle table may show handles opened by other processes that have since exited. Credential Guard, when enabled, moves credential material into a separate isolated process (LSAIso) that runs in a virtualization-based security environment, preventing even a LSASS dump from revealing usable credential material.
How do I perform memory forensics on a cloud VM in AWS or Azure?
Memory acquisition from cloud VMs requires platform-specific approaches since you cannot plug a USB drive into a cloud instance. In AWS, the primary option for Windows instances is to use the SSM Run Command to remotely execute a memory acquisition tool like DumpIt or WinPmem on the target instance and write the output to an S3 bucket; for Linux instances, the LiME kernel module can be loaded via SSM Run Command and memory dumped to an attached EBS volume or S3. AWS also supports creating an EBS snapshot of a running instance's volume, though this captures disk state rather than memory. Azure provides similar capabilities through Azure Run Command on Windows VMs, again executing acquisition tools remotely and writing output to Azure Blob Storage. For both platforms, pre-staging acquisition tools and confirming permissions before an incident is critical; attempting to install tools and configure IAM permissions during an active incident under time pressure increases the risk of errors and contamination. Some managed detection and response providers and IR platforms have cloud-native memory acquisition capabilities built into their agent software, which is preferable to ad-hoc acquisition when it is available. Document all commands executed on the instance before and during acquisition as part of the chain of custody record.
What should I look for first in a memory image during incident response?
The most productive initial triage sequence for a Windows memory image in an IR context is to start with windows.pslist and windows.pstree to identify unusual processes: look for processes with names that mimic system processes but run from unexpected locations (svchost.exe outside System32, lsass.exe with multiple instances), processes with no parent or an unexpected parent (cmd.exe spawned by a web server process), and processes running as SYSTEM that are not expected system services. Follow immediately with windows.netscan to enumerate all network connections and sockets: look for established connections to external IPs on unusual ports, listening sockets on non-standard ports, and connections from processes like notepad.exe or mspaint.exe that have no legitimate reason for network activity. Then run windows.malfind to flag memory regions with read-write-execute permissions that are not backed by a file on disk, which is the primary indicator of injected shellcode or reflective DLL loading. Finally, run windows.cmdline on all suspicious processes to see the exact command-line arguments used to launch them, which often reveals encoded PowerShell payloads, unusual file paths, or attacker tooling invocations. These four plugins together with windows.pstree constitute the minimum viable triage for a Windows memory image and typically surface the primary indicators of compromise within the first 20 to 30 minutes of analysis.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.