If you’ve been following my Memory Analysis series, you may remember that I previously covered the initial investigation steps in detail in the article: “Step-by-Step Guide to Uncovering Threats with Volatility: A Beginner’s Memory Forensics Walkthrough” https://www.cyberengage.org/post/step-by-step-guide-to-uncovering-threats-with-volatility-a-beginner-s-memory-forensics-walkthrough Volatility is one of my favorite memory forensics tools. I genuinely love working with it—it makes complex investigations much easier and provides incredible visibility into system memory. However, Volatility is not the only powerful tool available. Another tool I frequently use and really enjoy is MemProcFS. It’s an excellent memory forensics framework that approaches investigations in a more interactive and intuitive way by exposing memory artifacts through a virtual file system. So, rather than repeating the Volatility workflow: If you want to learn or revisit memory investigation using Volatility , I recommend checking out the article linked above. If you want to see how to perform a similar investigation using MemProcFS , stay with me—I’ll guide you through it step by step. Before we begin, if you’re not familiar with MemProcFS or MemProcFS Analyzer, I strongly recommend reading the following article first: 👉 https://www.cyberengage.org/post/memprocfs-memprocfs-analyzer-comprehensive-analysis-guide With that covered, let’s get started. MemProcFS Overview MemProcFS dynamically performs symbol table lookups from Microsoft servers to correctly identify the memory image profile. For best results, it’s recommended to use a system with active Internet connectivity. The -device argument specifies the path to the memory image. MemProcFS.exe -device C:\Users\Akash\Downloads\laptop.raw -forensic 1 -license-accept-elastic-license-2.0 Optionally, you can also provide paths to pagefile.sys and swapfile.sys using the -pagefile[0|1] parameters. This is considered a best practice, as MemProcFS supports pagefile parsing and can decompress compressed memory regions, which are common in Windows 10 and Windows 11 systems. These capabilities are particularly impressive and are one of the main reasons MemProcFS often extracts more forensic artifacts from memory than many other tools. On Windows systems, the default mount point is the M:  drive. This can be changed using the -mount option, which is also required when running MemProcFS on Linux to specify a mount path. An additional useful option is -forensic. This flag automatically triggers forensic plugins such as: findevil ntfs timeline While these plugins are more resource-intensive, they often complete faster than expected and immediately generate valuable forensic data. Once MemProcFS is running, keep the terminal open and navigate to the mounted drive to begin analysis. Exploring Processes with MemProcFS Once mounted, analyzing memory artifacts is as simple as browsing a file system. For example, process information can be reviewed via: M:\sys\proc\proc.txt This file provides a parent/child process tree view , similar to the windows.pstree output in Volatility. In addition to familiar information, MemProcFS includes extra details such as: The user account  running the process A flag column  indicating potential anomalies Common Process Flags 32  – 32-bit process running on a 64-bit system E  – Process not found in the EPROCESS list (possible unlinking or memory corruption) T  – Terminated process U  – User-level (non-system) process *  – Process running from a non-standard path You’ll often notice multiple output files in directories of interest. For instance, proc-v.txt provides a more verbose process listing, including full paths and command-line arguments While this format is slightly harder to read as a tree, it’s extremely valuable for deeper analysis. Processes can also be investigated directly by name or PID , which we’ll look at shortly. Deep-Diving into a Process Unlike Volatility, which relies on separate plugins to extract process details, MemProcFS consolidates all related artifacts into structured folders. For example, after identifying a suspicious process named Move Mouse.exe with PID 16032 , we can navigate to: M:\name\Move Mouse.exe-16032 Within this directory: win-cmdline.txt shows the full command line from the process PEB The token folder provides information about the security context and privileges The handles folder lists open handles The modules folder contains loaded DLLs and the process image As you explore these directories, you’ll not only see metadata but often reconstructed artifacts themselves. For instance, each DLL folder under modules includes a pefile.dll file, which attempts to reconstruct the original DLL directly from memory. These files can be opened in a hex editor, disassembler, or submitted to a sandbox for further analysis. Network Artifact Analysis Identifying network activity using MemProcFS is equally straightforward. Under: M:\sys\net you’ll find: netstat.txt – traditional network connection view netstat-v.txt – extended view with full process paths Since these are plain text files, they’re easy to search and filter. For example, you can quickly scan for known malicious IP addresses or suspicious process names using standard command-line tools like grep. ------------------------------------------------------------------------------------------------------------- Now that we understand process memory layout and behavior, we can move on to one of the most important stages of memory analysis: Identifying code injection artifacts using MemProcFS. MemProcFS currently centralizes its detection logic into a single, powerful plugin called findevil. This plugin is not enabled by default and must be activated in one of the following ways: Launch MemProcFS with the -forensic command-line argument, or -forensic 1 -license-accept-elastic-license-2.0 Write the value 1 into the file: M:\forensic\forensic_enable.txt It’s important to note that findevil only works on Windows 10 and newer systems , as this limitation helps reduce false positives caused by older memory management behaviors. Once enabled, MemProcFS generates a report at: M:\forensic\findevil.txt This report flags suspicious memory locations using a set of well-defined indicators, which we’ll break down below. Process-Level Anomaly Detections The first group of findevil detections focuses on process irregularities, many of which should already feel familiar from earlier stages of memory analysis: PROC_NOLINK : Indicates a process that is missing from the EPROCESS doubly-linked list. This may be caused by normal termination, memory corruption, or malicious unlinking (DKOM). PROC_PARENT : Flags deviations from expected parent-child relationships for known system processes. PROC_USER : Detects system-named processes running under incorrect or unexpected user tokens. These flags help establish early suspicion  before diving deeper into memory-page analysis. Memory Page Injection Indicators The next—and arguably most powerful—set of detections focuses on suspicious memory page properties. Understanding how Windows maps memory is crucial for interpreting these flags correctly. PE_INJECT : What it means: A memory region contains a valid PE header (EXE or DLL), but was not loaded from disk. NOIMAGE_RWX : RWX memory pages that are not  backed by image-mapped files. What it means: Memory pages have Read + Write + Execute permissions AND They are not backed by an image file Why this is bad: Legitimate code should never be RWX RWX memory allows: Writing shellcode Executing it immediately NOIMAGE_RX : RX memory pages outside image-mapped memory. What it means: Memory pages are Executable (RX) but not image-mapped Why suspicious: Code is executing But it didn’t come from a loaded EXE or DLL Less severe than RWX, but still suspicious: Malware may write code, then change permissions to RX Used to evade RWX detection PRIVATE_RWX : RWX permissions inside private memory regions (heap or stack). What it means: RWX memory inside private memory(heap or stack) Why this matters: Heap/stack are meant for data, not code RWX heap/stack almost always indicates: Shellcode execution Exploit payloads Memory injection PRIVATE_RX : RX permissions inside private memory. What it means: Executable memory (RX)inside private memory (heap or stack) Why suspicious: Code running from heap/stack is abnormal Often used after: Shellcode is written Permissions changed from RW → RX ------------------------------------------------------------------------------------------------------------ Indicator Executable Writable Image-Mapped Risk PE_INJECT ✅ varies ❌ High NOIMAGE_RWX ✅ ✅ ❌ Very High NOIMAGE_RX ✅ ❌ ❌ High PRIVATE_RWX ✅ ✅ ❌ Very High PRIVATE_RX ✅ ❌ ❌ Medium–High ------------------------------------------------------------------------------------------------------------ These detections are extremely valuable because injecting code is easy, but placing it correctly with legitimate characteristics is very hard. As a result, multiple detections often trigger on the same malicious memory region. For example: A PE header (MZ) located in an RX page outside image-mapped memory would trigger both PE_INJECT and NOIMAGE_RX. While false positives still exist, these detections represent a major improvement over Volatility’s malfind, particularly when layered together. Detection of Manipulated Memory Structures Beyond raw injection detection, findevil also identifies manipulated memory structures, which are often used in more advanced attacks. PEB_MASQ : Detects Process Environment Block masquerading, where malware alters the process name or file path in the PEB. PE_NOLINK : Identifies DLLs with valid PE headers present in the VAD but missing from the PEB module lists—very similar in concept to Volatility’s ldrmodules. While false positives exist, including pagefile data significantly reduces noise. PE_PATCHED : Flags executable pages that were modified after being loaded. This is common in: Advanced process hollowing AMSI bypasses In-memory patching This detection relies on page table entries (PTEs)—specifically prototype PTEs—which track modified image pages. While extremely powerful, this detection can be noisy on systems using: SysWOW64 (32-bit code on 64-bit systems) JIT compilers (e.g., .NET and PowerShell) Expect noise—but also expect ground-truth accuracy. ------------------------------------------------------------------------------------------------------------ What’s Next? In the next article, we’ll continue: Stay tuned—this is where the investigation gets really interesting

Modern Windows rootkits assume that analysts will: enumerate drivers using linked lists trust Windows APIs rely on “normal” system views Volatility 3’s windows.drivermodule plugin was built specifically to break that assumption. What windows.drivermodule Actually Does This plugin performs cross-view analysis for drivers , similar in spirit to: psxview → processes svcdiff → services But focused entirely on kernel drivers . Step 1: Memory Scanning Scans memory for structures associated with: DRIVER_OBJECT related kernel metadata This is a ground truth scan, independent of Windows-maintained lists Step 2: Linked-List Enumeration Enumerates drivers via: the kernel linked list used by Windows APIs This is what the OS claims  is loaded Step 3: Cross-Comparison Compares: scanned driver objects API-visible drivers Any mismatch is flagged If memory says a driver exists but Windows denies it → rootkit territory Metadata Anomaly Detection Rootkits don’t just unlink drivers — they tamper with metadata to frustrate analysis. The plugin checks for anomalies such as: Base address = 0x0 Image size = 0 bytes Missing or inconsistent path information Why Rootkits Do This Makes dumping harder Breaks naïve tools Confuses analysts looking for valid PE structures Ironically, these manipulations make the driver more suspicious, not less. Known Exceptions vs Real Red Flags Some legitimate Windows components: behave oddly violate “normal” expectations would otherwise cause false positives The plugin accounts for this by: maintaining a list of known exceptions marking them explicitly How to Interpret the Output Known Exception = True Likely benign Still reviewable, but lower priority Known Exception = False Not explained by normal OS behavior High-confidence rootkit indicator Must be investigated This dramatically reduces analyst noise. Why This Plugin Is So Effective Andrew Case (Volatility core developer) demonstrated that: windows.drivermodule detected every modern Windows rootkit sample they tested even samples that: successfully hid from driver lists avoided traditional modscan detection manipulated metadata to evade dumping This makes it one of the strongest rootkit detection plugins in Volatility 3. ----------------------------------------------------------------------------------------------------- Hidden Services: The Other Half of the Story Kernel drivers rarely load themselves magically. They are commonly loaded via: Windows Services set to: auto-start boot-start system-start Rootkits often hide both: the driver the service that loads it windows.svcdiff — Detecting Hidden Services The windows.svcdiff plugin performs cross-view analysis for services, similar to psxview and drivermodule. How It Works It compares: services listed by: services.exe (what Windows reports) services discovered via: memory scanning What It Finds services that: exist in memory are not visible to the OS are likely unlinked or hidden These hidden services are frequently: used to load malicious drivers responsible for persistence part of kernel rootkit infrastructure ------------------------------------------------------------------------------------- Putting It All Together: Rootkit Detection Workflow A practical Volatility 3 rootkit triage looks like this: windows.psxview Look for hidden processes windows.drivermodule Identify hidden or metadata-manipulated drivers windows.svcdiff Find hidden services used for persistence windows.ssdt Check for hooks pointing into suspicious drivers windows.modules / windows.modscan Correlate linked vs scanned driver data Dump and analyze Extract drivers and services for deeper analysis Each plugin reinforces the others. ------------------------------------------------------------------------------------ Why Cross-View Analysis Is So Powerful Rootkits can: hide from one view manipulate one data structure But hiding consistently from: linked lists memory scans metadata checks service tables …is extremely difficult. Volatility’s philosophy is: “Trust nothing. Compare everything.” ------------------------------------------------------------------------------------------ Key Takeaways windows.drivermodule is purpose-built for modern Windows rootkits It detects: hidden drivers unlinked drivers metadata manipulation Known exceptions are filtered for you Unknown discrepancies are high-value findings Rootkits often rely on hidden services , detectable via windows.svcdiff Cross-view analysis remains one of the most reliable rootkit detection techniques ------------------------------------Dean---------------------------------------------------

Drivers are the cleanest way for malware to own a Windows system. Once malicious code executes as a driver: it runs in kernel mode it can hook system calls it can hide processes, files, and registry keys it can tamper with security tools This is why rootkits almost always involve drivers. How Windows Tracks Drivers Windows maintains multiple views of loaded drivers, just like it does with processes. Rootkits exploit this. 1. The Linked List (Normal View) Tracks currently loaded drivers Used by: OS components administrative tools many security products 2. Raw Memory (Reality View) Driver code and data may still exist in memory: even if unlinked even if unloaded even if hidden via DKOM Volatility gives us tools for both perspectives . Key Volatility Plugins for Driver Analysis modules (Volatility 2) / windows.modules (Volatility 3) Reads the official kernel linked list of loaded drivers Shows: driver name base address size file path (if available) This is your high-level, trusted view  — and therefore the first thing rootkits lie to . If a driver is not here, it does not  mean it was never loaded. modscan (Volatility 2) / windows.modscan (Volatility 3) Scans memory for: driver pool tags remnants of DRIVER_OBJECT structures Can find: hidden drivers unlinked drivers unloaded drivers partially overwritten drivers This is the low-level truth . If something appears in modscan but not modules: strong rootkit indicator Why modscan Is Critical Modern rootkits: unlink their drivers from the kernel list overwrite list pointers erase file-backed references But: pool memory still contains artifacts code pages still exist data structures are rarely perfectly cleaned modscan catches what modules misses. windows.devicetree — Seeing Driver Relationships The devicetree plugin provides a structural view: how drivers are layered which drivers attach to which devices unexpected filters or middlemen This is especially useful for: keyboard filter rootkits disk filter rootkits network stack manipulation Unexpected drivers in the middle of known driver chains are highly suspicious. Driver Analysis Should Never Be Done Alone Kernel rootkits rarely stop at “just being loaded.” They usually: hook SSDT hook IRP handlers register callbacks manipulate processes and registry So the real power comes from correlation: suspicious driver in modscan SSDT entries pointing into that driver hidden processes revealed via psxview These findings reinforce each other. -------------------------------------------------------------------------------------------- Narrowing Down Suspicious Drivers When faced with hundreds of drivers: 1. Known-Good Comparison Compare against: a clean system same OS version and patch level Use projects like: Vanilla Windows Reference  (Andrew Rathbun) ( https://github.com/AndrewRathbun/VanillaWindowsReference ) This quickly eliminates the noise. 2. Reputable Research Search only reliable sources: Microsoft documentation vendor driver references well-known malware research blogs Ignore forums and random blog posts. 3. Dump and Analyze If doubt remains: extract the driver scan with: AV engines known IOCs perform: static analysis reverse engineering Dumping a Suspicious Driver Once identified: Volatility 2 moddump -b -D output_dir Volatility 3 windows.modules --dump This allows: string analysis signature checks RE IOC extraction What To Do After Finding a Malicious Driver Don’t stop at identification. Next steps: search SSDT for hooks into the driver look for callbacks registered by it identify persistence mechanisms: services registry entries boot loaders correlate with: hidden processes network artifacts filesystem anomalies The driver is the control center . -------------------------------------------------------------------------------------------- Key Takeaways Kernel drivers = rootkit backbone modules shows what Windows admits modscan shows what memory remembers Differences between them matter Known-good baselining is incredibly powerful Rootkits rarely clean up perfectly Correlation beats single-plugin analysis every time -------------------------------------Dean---------------------------------------------

If SSDT hooking shows you how rootkits control behavior psxview shows you how they hide existence. This plugin is one of the most important tools for rootkit detection in memory. What psxview Really Does psxview is a compound plugin. It doesn’t invent new data — it compares existing views of processes gathered using different kernel mechanisms . Why this matters: Windows tracks processes in multiple places : linked lists PID tables thread structures user-session data desktop objects A rootkit can hide from one of these. Hiding from all of them is extremely difficult. This is the core idea behind cross-view analysis. Cross-View Analysis Cross-view analysis means: Ask Windows for process information the normal way  (high-level) Independently discover processes using low-level structures Compare the results If something exists in one view but not another: someone is lying Rootkits usually lie to the high-level views. What psxview Compares psxview runs multiple plugins and builds a comparison table. Here’s what each source represents: High-Level View pslist Reads the active process doubly linked list Easiest place for DKOM rootkits to hide This is your baseline “normal” view Low-Level & Alternate Views psscan Scans memory for raw EPROCESS structures Finds terminated, hidden, and orphaned processes thrdproc(scan) Reconstructs processes via thread parent PIDs Very hard to fully clean up pspcid Uses the kernel PspCid table (PID tracking) Another place attackers forget to clean csrss csrss.exe holds handles to user processes Only valid for processes started after  csrss session Groups processes by logon session deskthrd Maps processes via desktop-attached threads How to Read psxview Output Each process gets a row. Each detection method gets a column. True  → process found via that method False  → process not found via that method What you’re looking for: Inconsistencies Especially: False in pslist True everywhere else That’s rootkit territory. Legitimate “False” Values Not every False means malware. Some examples that are expected behavior: System , smss.exe, csrss.exe Started before csrss tracking exists Will show False under csrss, session, deskthrd Terminated processes psscan may find leftover EPROCESS structures Other views show no references Real-World Example: FU Rootkit The FU rootkit uses Direct Kernel Object Manipulation (DKOM). Instead of hooking functions, it: removes its process from the active process list leaves the process alive elsewhere in memory psxview Findings Plugin Result pslist ❌ False psscan ✅ True thrdproc ✅ True pspcid ✅ True csrss ✅ True This is textbook DKOM behavior. pslist — the high-level view — has been manipulated. Low-level structures still know the process exists. That discrepancy is the detection. Why pslist Is the “Canary” pslist is the easiest place to hide. So your rule of thumb: If a process does not appear in pslist but appears elsewhere, investigate immediately. This is how most rootkit detections start. False Positive Example You’ll often see something like: psscan → True everything else → False Example: csrss.exe This usually means: process exited cleanly EPROCESS still present in memory no active references remain This is not malware — just memory artifacts. The Important Question If psscan already finds hidden processes, why do we need psxview? Because context matters. Without cross-view comparison: you might assume the process is legitimate you might miss that it was hidden from pslist you lose the evidence of DKOM manipulation psxview doesn’t just find processes —it tells you which kernel view was tampered with. That’s critical for attribution and reporting. Key Takeaways psxview is a rootkit detector, not a process lister Inconsistencies matter more than presence pslist = high-level truth psscan = raw reality ---------------------------------------Dean--------------------------------------------

Now we’re stepping into kernel territory. And once malware gets here, things get serious. One of the biggest wins for kernel malware is SSDT hooking. If you understand this, you understand how rootkits control the entire system. What Is the SSDT The System Service Descriptor Table (SSDT) is basically a lookup table used by the Windows kernel. When a process asks Windows to do something like: open a file read registry data enumerate processes allocate memory …the kernel looks up the corresponding system function in the SSDT and jumps to the code. Each SSDT entry is just a pointer to kernel code. How SSDT Hooking Works An SSDT hook does something very simple — and very dangerous: It replaces one or more SSDT pointers Redirects them to malicious code That code runs before or instead of the legitimate kernel function And because this lives in the kernel: it affects every  process it’s system-wide no user-mode security tool is safe That’s why attackers love it. Why Attackers Don’t Use It Everywhere SSDT hooking comes with a big risk. On 64-bit Windows, PatchGuard (Kernel Patch Protection) watches critical structures like: SSDT IDT GDT kernel code regions If PatchGuard detects tampering, it doesn’t log an alert. It blue-screens the system on purpose. So yes — SSDT hooks still exist, but they’re much rarer today. That said… attackers always find ways around protections . So we can’t ignore SSDT analysis. Finding SSDT Hooks with Volatility Volatility 3 gives us a plugin called: windows.ssdt Important thing to know: This plugin does not  only show suspicious entries. It dumps everything . And that’s a lot. Modern Windows systems can have 1,500+ SSDT entries . So filtering is mandatory. What the ssdt Plugin Shows For each SSDT entry, Volatility gives: Table Entry (Index) Function Offset (Address) Function Name (Module) Function Owner  (Symbol)(which kernel module owns it) And this Second last column is the key. The Simple Rule That Catches Rootkits On a clean Windows system: SSDT entries should point to only two modules: ntoskrnl.exe win32k.sys That’s it. So our job becomes very easy: Show me SSDT entries that point anywhere else. Anything outside those two is immediately suspicious. Filtering the Noise (The Practical Way) We pipe the output and remove known-good entries: python3 vol.py -f /mnt/c/Users/Akash/Downloads/laptop.raw windows.ssdt | egrep -v '(ntoskrnl.exe|win32k.sys)' Now instead of thousands of lines…you get only the interesting stuff. Small note: Some systems use: ntkrnlpa.exe ntkrnlmp.exe So adjust your filter if you ever hit that edge case. Logical Step: Dump the Driver Finding the hook is just step one. Next step: extract the malicious driver from memory Volatility gives us: moddump  (Volatility 2) modules  (Volatility 3) Once dumped: reverse engineer it extract IOCs identify capabilities confirm attribution ------------------------------------------------------------------------------------------------------------- Final Takeaway SSDT hooking is: powerful dangerous rare (but real) PatchGuard made it harder — not impossible. And when attackers do  use it, memory forensics exposes them very clearly. If a kernel function suddenly belongs to a random driver…that driver has some explaining to do. -------------------------------------------------Dean-----------------------------------------------------

This plugin is honestly one of the best examples of why Volatility still matters in memory forensics. Why? Because instead of trusting a single data source, ldrmodules does something very smart —it cross-checks multiple memory structures and looks for inconsistencies. And malware absolutely hates consistency. What ldrmodules Is Actually Doing When we’re looking for suspiciously loaded code inside a process, there isn’t just one  place to look. Windows tracks loaded DLLs in multiple ways, and ldrmodules compares all of them. Every process has a Process Environment Block (PEB ) .Inside the PEB, Windows maintains three linked lists that track loaded DLLs: InLoadOrderModule InInitializationOrderModule InMemoryOrderModule In a normal process, all three lists usually contain the same DLLs, just ordered differently. Now here’s where it gets interesting. ldrmodules doesn’t stop there. It also looks at the VAD tree , which tracks image-mapped memory pages — basically what is actually mapped into memory . So now we can ask a very powerful question: Does what Windows thinks  is loaded match what is actually  mapped in memory? When the answer is “no” — that’s where malware shows up. What Information ldrmodules Gives Us For each process, the plugin shows: PID  – Process ID Process  – Process name Base  – Base address from the VAD tree InLoad  – Present in PEB InLoad list InInit  – Present in PEB InInitialization list InMem  – Present in PEB InMemory list MappedPath  – File path from disk (from the VAD) A legitimate DLL  should: be marked True  in all PEB lists have a valid MappedPath on disk Example Look: Anything that breaks this pattern deserves attention. Important: False Positives Are Normal Before you panic over every “False”, keep these in mind: Process executable The process binary itself (like lsass.exe) will always show False in InInit . This is expected and normal. Special files Files like: .mui .fon .winmd .msstyles are mapped into memory but are not real DLLs, so they won’t appear in PEB lists. Legit DLLs not yet loaded Sometimes DLLs are mapped but not actually used yet — they’ll show in VAD but not in PEB. SysWOW64 weirdness Volatility 3 sometimes marks SysWOW64 DLLs as FALSE. This is likely due to 32-bit tracking differences. That’s why I always run ldrmodules in both Volatility 2 and 3 when possible. The Biggest Red Flag: Empty MappedPath This is huge — so don’t miss it. If a DLL has no MappedPath : it was not loaded from disk it was not loaded via LoadLibrary Windows has no idea where it came from That almost always means DLL injection . Even if the DLL still appears in one or more PEB lists. How Malware Hides DLLs: PEB Unlinking Because the PEB lives in userland, malware doesn’t need kernel access to mess with it. Administrator rights are enough. A common trick is unlinking a DLL from one or more PEB lists: Process keeps running normally DLL stays in memory Tools like Task Manager and dlllist don’t see it From the outside, it looks clean. But… The VAD tree still knows the truth. So when ldrmodules finds: memory-mapped executable code that is missing from PEB lists …it becomes very obvious something is wrong. How ldrmodules Thinks Instead of trusting the PEB, ldrmodules does this: Walk the VAD tree Find image-mapped executable memory Compare each entry with: InLoad InInit InMem Show mismatches as True / False This gives you a visual way to spot: unlinked DLLs injected memory reflective loaders process hollowing Normal Example (What “Good” Looks Like) A clean entry from wininit.exe might show: DLL: \Windows\System32\iertutil.dll InLoad = True InInit = True InMem = True MappedPath = present This is exactly what we expect. Zeus Banking Trojan Example Now let’s look at malware. Zeus injects itself into almost every running process . In ldrmodules, we see an entry with: InLoad = False InInit = False InMem = False MappedPath = empty This tells us: code exists in memory Windows loader never loaded it VAD has executable memory no backing file on disk Classic injected code. Process Executable Entry — Don’t Get Confused You’ll often see the first entry representing the process itself: \WINDOWS\system32\svchost.exe It will: be present in InLoad and InMem show False in InInit This is normal  and expected. Stuxnet & Process Hollowing Stuxnet takes things further using process hollowing . In an lsass.exe , ldrmodules shows: entries with no MappedPath missing from multiple PEB lists One section: not in any list → injected DLL Another section: missing only from InInit → looks normal BUT still has no MappedPath This is the key clue. The original lsass.exe image was unmapped and replaced entirely in memory. Since this all happened in RAM: no file on disk no mapped path nothing for AV to scan Exactly how hollowing is supposed to work. Cross-Checking With malfind If you compare: Base address from ldrmodules Base address reported by malfind You’ll see both tools pointing to the same suspicious memory regions. Two tools. Two data sources. Same conclusion. That’s confidence. Advanced Trick: ldrmodules vs dlllist One last powerful trick: dlllist → reads PEB (easy to manipulate) ldrmodules → reads VAD (kernel-side, harder to fake) If base addresses don’t match between the two? That’s a strong indicator of process hollowing. Final Thought Attackers can: unlink DLLs avoid LoadLibrary never touch disk hollow processes But they can’t escape memory structures entirely. As long as: code must execute memory must be executable Plugins like ldrmodules  will always give you something to pull on. --------------------------------------------------------Dean-----------------------------------

Let’s get into Second Plugin windows.malfind  — my favorite plugin when I want to quickly spot weird injected memory in a process. What malfind Actually Does malfind looks for two suspicious things inside process memory: Memory region is executable → PAGE_EXECUTE_READWRITE or similar permissions→ This is already a red flag because legit apps rarely need RWX memory. Memory region is NOT mapped to a file on disk → Meaning the process has code in memory that didn’t come from an EXE or DLL on the system. If malfind finds both together… boom! You have a potential injected section. And if you include --dump-dir, malfind will dump that entire memory section into files so you can reverse, scan, or investigate further. What malfind Shows You Volatility 3 gives you useful columns like: PID Process Name Start/End VPN  (basically the memory range) Protection  (this is where RWX shows up) PrivateMemory  (0 = mapped, 1 = private → injected stuff is usually private) CommitCharge Tag  (pool tag) But honestly, the real magic is the hex + assembly dump  of the first 64 bytes. This part tells you everything  if you know what you’re looking at. Checking for Real Code (The Final Injection Test) malfind purposely doesn’t confirm whether the bytes are actual code — that’s the analyst’s job. So your last check is: Does the memory actually contain real executable code? You look for: MZ header (4D 5A) → Means a PE file (EXE/DLL) was injected reflectively. Function prologue patterns When you run malfind and found  EBP and ESP   it often indicates that some part of the memory that is traditionally not executable (such as the stack) now contains executable code. On x86: PUSH EBP MOV EBP, ESP On x64 :a bunch of pushes like: push rbp mov rbp, rsp push rdi push rsi ... [rax], al) → probably false positive. malfind gives a lot of false positives, so this final step is critical. Another Example: OneDrive False Positive malfind flagged a section inside OneDrive.exe. Looked scary because permissions were RWX. But the assembly dump was: 00 00 00 00 00 00 ... Disassembler tried to interpret it as: add [rax], al add [rax], al add [rax], al ... This means garbage. Not real code. Not injection. So this is one of those common false positives that malfind throws around. The Evolution of Code Injection: LoadLibrary → Reflective Injection → Header Cleaning Load Library: - ( A load library contains programs ready to be executed) Originally, malware injected code using LoadLibrary. Easy to detect, easy to monitor. Then came frameworks like Metasploit using reflective DLL injection, which bypasses Windows loader APIs completely. Tools like malfind  were built specifically to catch reflective injection — and they did a brilliant job. So attackers adapted again. Malware started wiping its PE headers. CoreFlood botnet cleared the first 4096 bytes of its injected DLL. APT29 , APT32 , use Cobalt Strike loaders that erase headers after loading. Some newer families pad their shellcode deeper in the page so the first 64 bytes look harmless. This is a huge problem because malfind only shows you a tiny preview (64 bytes).If the malicious code sits after  the preview window, the output looks like a false positive. Bypassing RWX Detection (Attackers Getting Clever) malfind heavily relies on detecting EXECUTE_READWRITE memory. So, malware authors figured out an elegant bypass: Allocate memory as READWRITE Write payload into it Flip permissions to EXECUTE_READ only at execution time PEB Manipulation — A Common Target for Stealth Because the Process Environment Block (PEB) is userland and easy to modify, attackers love tampering with it: Unlinking entries from the loaded DLL lists Rewriting DLL names or paths Masquerading the process name Using PowerShell to patch fields directly If your detection tool trusts the PEB blindly… you’re already in trouble. Advanced Techniques: Stomping, Patching & Camouflage Newer malware families move beyond simple injections: Module Stomping Overwrite a legitimate DLL in memory with malicious code. Patching Legitimate Code Replace functions inside real modules with attacker logic. These make the injected payload look like it belongs to a real module. How We Fight Back: Dump Everything When in doubt, dump the whole region. Using --dump with malfind gives you a full memory section, not just the misleading 64-byte preview. Once dumped, you can: Run strings Scan with antivirus Use YARA rules Load into IDA/Ghidra Compare with known-good modules Reverse engineering is the most accurate option — but also the most expensive. And yes, attackers know this. Reality Check: Not All Malware Uses Fancy Techniques Don’t overthink it. Most real-world injections are still: Reflective DLL injection Process hollowing Remote thread injection Shellcode in RWX pages Why? Because these techniques are simple, tested, reliable, and still bypass many defenses . So while we prepare for the future, remember the majority of cases you’ll see are still detectable using standard techniques. ------------------------------------------------------------------------------------------------------------- The Memory Layout Matters (And Helps You Catch Stealthy Stuff) Windows process memory has three major areas: 1. Private Memory Allocated via VirtualAlloc Contains stack, heap, app data Usually READWRITE Should NEVER contain real executable code If you see RX or RWX here → high suspicion. 2. Shareable (Mapped) Memory Contains mapped files like .dat, .mui Mostly READONLY Rarely executable 3. Image Memory (Executable Section) Legit place for EXEs and DLLs Usually EXECUTE_READ or EXECUTE_WRITECOPY Rarely RWX Important insight from Forrest Orr’s memory research: Memory Type Normal RWX Rate Private 0.24% Shareable 0.014% Image 0.01% RWX almost NEVER occurs in legitimate scenarios. Even RX pages outside of image memory should raise eyebrows. Why This Matters for Injection Detection Most attacks — hollowing, reflective injection, manual mapping — end up placing executable code in the wrong part of memory: Hollowing → executable code ends up in private memory Doppelganging → ends up in shareable memory Reflective DLL → RWX pages created temporarily Your job is to understand: Where should executable code exist, and where SHOULD it never exist? If you master this, you’ll detect even advanced injection without needing heavy automation. Because memory forensics is about recognizing what is normal — and what isn't. ------------------------------------------------------------------------------------------------------------- Final Thoughts (Important) Malfind is still one of the best first-pass detectors for injections, even though attackers have more sophisticated tricks today. Use malfind to get your first leads, then: Dump the section Scan it Reverse engineer Compare patterns Check surrounding processes And always remember: malfind does NOT confirm the injection — YOU do. Your eyes + pattern recognition = the real detection engine. ---------------------------------------------Dean---------------------------------------------

So yeah… I know I already wrote a bunch of blogs on memory forensics — Volatility step‑by‑step, code injection, rootkits, all of that. And you might be wondering: “Bro, why are we still talking about memory forensics?” Well… because some Volatility plugins are actually important , a bit tricky, and very underrated. Everyone knows the basics like psscan , pslist , dlllist , etc. If not — go check my earlier guide, I won’t repeat the boring stuff here. https://www.cyberengage.org/courses-1/mastering-memory-forensics%3A-in-depth-analysis-with-volatility-and-advanced-tools In this series, we’re going deeper  — focusing on the plugins that help you confirm attacks, pivot to real artifacts, and catch sneaky malware behavior. And today’s topic? Process Handles — A Small Thing That Reveals BIG Clues Handles are basically pointers to objects that a process is using — files, registry keys, named pipes, mutants, events, threads, sections… everything. Sounds cool, right? But here’s the problem: There are SO MANY handles. And 90% of them are boring: unnamed internal things that tell you nothing. But the remaining 10%? That’s where investigations become fun. Most of the time, handles won’t start  your investigation. You usually look at handles after you’ve already identified a suspicious process.But once you’re there, handles can help you: Confirm your suspicion Find related malware components Discover persistence Spot communication channels (e.g., C2 pipes) Catch rare artifacts like injected DLLs Volatility Plugin: windows.handles.Handles By default, this plugin prints every handle from every process. python3 vol.py -f /mnt/c/Users/Akash/Downloads/laptop.raw windows.handles So yeah, it’s a mess. That's why: ✔ If you know the suspicious PID → always use --pid Example: python3 vol.py -f /mnt/c/Users/Akash/Downloads/laptop.raw windows.handles --pid < > Example 1 — DLL Handle That Should Not  Be There So imagine you’re investigating a Shell . You trace it back to its parent process — Example w3wp.exe You start checking its file/registry handles. Most are normal… until one jumps out: A DLL referenced in the handles table That's weird because: DLLs are usually listed in the PEB And appear in dlllist , not in handles So seeing a DLL via handles is suspicious by itself One little handle uncovered the entire Shell chain. This is why handles matter. Example 2 — Infostealer Investigation This is a fun one. During the investigation, Suspicious processes: powershell.exe This is classic LOLBins used heavily by modern malware. PowerShell PowerShell had large number of handles… yeah, typical PowerShell behaviour. After filtering unnamed handles, and keeping only File + Registry ones, you brought it down to 100 handles: Still many, but manageable. Inside all this noise was: A randomly named registry key Sitting somewhere under HKCM\CLASSES\... At first look it blends in, but it was actually the persistence: Random registry names Storing fileless scripts Classic modern persistence trick A lot of people miss this because it looks  normal. But handles will pick it up easily. Handles help you rewind the malware timeline. That’s why they’re gold. Named Pipes — The Secret Communication Channels Okay, named pipes are literally everywhere in attack frameworks. Tools like: PsExec Metasploit Trickbot HyperStack Empire Covenant Cobalt Strike … all use named pipes  to communicate quietly. Because unlike sockets, pipes: Don’t show up in netstat Blend into normal system behaviour Work over SMB Carry less operational noise And attackers can name them anything . Some pipes look normal Some pipes embed IPs or PIDs Some pipes follow known patterns For example, PsExec  uses names like: \Device\NamedPipe\psexecsvc---stdout Cobalt Strike uses: MSSE-****-server \\.\pipe\****** If the operator doesn't change defaults → instant IOC. And yeah, handles can catch them. Just filter for File handles containing “pipe”. python3 vol.py -f /mnt/c/Users/Akash/Downloads/laptop.raw windows.handles | grep -i pipe Mutants (Mutexes) — Malware’s Way of Saying “I Was Here First” Mutants (mutexes) are used by malware to avoid reinfecting a system. Malware sets a mutex →Before infecting again, it checks if that mutex exists. That makes mutexes: ✔ Perfect indicators of compromise ✔ Unique to specific malware families ✔ Easy to scan in memory python3 vol.py -f /mnt/c/Users/Akash/Downloads/laptop.raw windows.handles | egrep "PID|Mutant" Final Thoughts (and why this plugin matters so much) Handles might look boring at first, but they give you: Persistence clues Malware DLL loading artefacts Malicious named pipes (C2 comms) Mutexes that identify malware families File paths and registry entries to pivot on 90% of the time you find nothing .That 10%? You find GOLD. ----------------------------------------------Dean------------------------------------------------------

If you look at how cybersecurity has evolved over the past few years, one thing becomes very clear: we finally have the horsepower to see what’s actually happening on our systems in real time. Thanks to cheaper storage, faster processing, and advances in forensics, we can now monitor both live and historical activity like never before. And that visibility isn’t just for show — we can act on it, whether automatically or manually, before attackers get too comfortable. A big part of this change is due to a new generation of Endpoint Detection and Response (EDR) tools. BTW I have written complete series on Sentinel One and Carbon If you want you can check out Lin below: Sentinel One https://www.cyberengage.org/courses-1/mastering-sentinelone%3A-a-comprehensive-guide-to-deep-visibility%2C-threat-hunting%2C-and-advanced-querying " Carbon Black https://www.cyberengage.org/courses-1/carbon-black-edr Continuing where we left So these solutions don’t just sit and wait for an alert. They use pattern recognition, heuristics, and machine learning on the back end to automatically block suspicious actions. But what really sets EDR apart is that it supports both detection and response. That means security teams aren’t just watching attacks happen — they can dig into the data, hunt for threats at scale, perform historical searches, and quickly understand how far an intrusion reaches. Here’s why this matters: once you identify an indicator of attack, being able to look backward in time and see where that same behavior occurred across the network can drastically reduce the time it takes to contain a threat. It also makes life more difficult for attackers, because their methods and patterns get exposed. ------------------------------------------------------------------------------------------------------------- Why Memory Matters More Than Ever Modern threats aren’t playing by the old rules. Attackers are moving away from traditional, file-based techniques because they know security tools are watching disk activity. Instead, many attacks now live in memory — the rise of “fileless” malware is a perfect example. That means in-memory detection is no longer optional. It’s critical. EDR tools focus heavily on memory analysis and event tracing, which allows them to catch malicious activity involving PowerShell, WMI, code injection, obfuscation, and other stealthy techniques. Because many EDR platforms have kernel-level access, they can see details that traditional antivirus tools would miss. Some common data points EDR tools capture include: Process information Windows API usage Command line history Process handles and execution tracing Suspicious thread creation and memory allocation DLL injection and rootkit techniques Host network activity ------------------------------------------------------------------------------------------------------------- EDR vs Memory Forensics — They’re Not the Same It’s important not to confuse EDR with full forensic tools. No one can capture every event across every system all the time — it would be impossible. A single device can log millions of events daily. For instance, Sysinternals Process Monitor can detect over 1000+ events per second, while an EDR system might intentionally limit itself to around 20-30 events per minute to avoid slowing the machine down. EDR tools focus on scale and practicalit y . They record a carefully chosen list of data points rather than everything under the sun. You typically can’t customize that list, but you get lightweight coverage across the entire environment. On the other hand, forensic tools aim for completeness. They capture entire memory and disk images, helping analysts tell the full story of an attack — including activity that may have happened before  EDR was installed. That’s why EDR should be seen as a supplement , not a replacement, for: Network monitoring SIEM log collection Deep memory/disk forensics EDR is great for real-time detection and quick investigation, but when you need deep answers, forensic tools are still king. ------------------------------------------------------------------------------------------------------------- Tools Are Only As Good As the Analyst I always say artificial intelligence, automation, and machine learning in security — and those technologies absolutely help — but they aren’t magic. At the end of the day, human analysts are still essential. Analysts need to understand how attackers think, what techniques they use, and how to connect data from multiple sources. Strong memory forensics and process analysis skills make EDR dramatically more effective. When you know what “normal” looks like, it becomes much easier to spot what doesn’t belong. The truth is, traditional forensics might eventually uncover everything EDR can reveal, but it would take much longer. EDR brings everything together in one place, speeding up identification of malicious activity and helping analysts make faster decisions. The goal is simple: use powerful tools, but keep strong foundational knowledge. That foundation is what lets you sort normal behavior from abnormal and respond confidently when something looks off. --------------------------------------------Dean-----------------------------------------------------------

In the previous article, I explained the Dropzone AI dashboard and overall features. Now, let’s get into the real action — how Dropzone actually investigates an alert , using Panther  as the example. Let’s begin. How Alerts Flow From Panther → Dropzone Let’s say you’ve integrated: Panther data source Panther alert source This means: Every alert Panther generates will be picked up automatically by Dropzone. No manual work. No need to forward anything. Dropzone grabs the alert → starts investigation immediately. Alright, good. ----------------------------------------------------------------------------------------------------------- Dropzone Picks the Alert & Starts Investigation Once Dropzone receives the alert, it begins analysis instantly. After a short time (usually under a minute), the AI spits out: Full investigation Conclusion (benign, suspicious, or malicious) Summary Top findings And here’s the important part: If Dropzone marks an alert as “Benign,” 99.9% of the time it is actually benign. So you can safely close it. Also important: If you close the alert in Dropzone, it gets closed in Panther as well. Any note or comment you add → also gets added to Panther. Super useful. ----------------------------------------------------------------------------------------------------------- Opening the Alert – The Investigation Screen When you open the alert, this is what you see (I had to hide sensitive info in the real screenshot): Alert Summary AI Conclusion Top Findings Links to original tool (Panther button on the left side)[ It’s extremely clean and simple. From here, you have 2 choices as an analyst: Method 1: Investigate manually in Panther Click the Panther button → open the alert in Panther → do your normal manual investigation. Method 2: Use Dropzone’s full investigation This is the easier method, and I’ll explain it below. After reviewing the alert: Select your conclusion (benign/suspicious/malicious) Add your comment Save That’s it. Alert will close in both systems. ----------------------------------------------------------------------------------------------------------- Findings Tab – The Brain of Dropzone The Findings  tab is where you see exactly what questions the AI asked  during its investigation. Dropzone literally interrogates the alert: “Has this IP been used before?” “Is this user associated with risky activity?” “Does this resemble past malicious alerts?” “Is this event common for this device/user?” “Any MITRE technique indicators?” Every question → AI’s response → Final verdict. You can click on each question to see: What Dropzone checked What information it used Why it reached the verdict This transparency is what makes Dropzone so powerful. It’s like sitting inside the brain of an analyst. ----------------------------------------------------------------------------------------------------------- Evidence Locker – All Evidence in One Place This is basically a collection of everything Dropzone used during the investigation. Examples: IPInfo lookup results Geo location ASN Device/user history File reputation Prior alerts Previous analyst comments Other tools' data You can click View Response  to see details. Dropzone also checks previous 5 alerts related to this case. It looks at: What analysts concluded What comments they left Whether those alerts were benign or malicious This is where your past decisions matter — Dropzone keeps learning from your behaviour. I call this “AI learning from the past”  😂 ----------------------------------------------------------------------------------------------------------- Remediation Tab – What To Do If Malicious If the alert is malicious, Dropzone provides: Recommendations Steps to take What should be contained What needs review At top, you’ll see Containment Actions . Dropzone currently supports automatic remediation for a few integrated apps (for example: Microsoft Defender, Okta, etc.) If enabled: AI will automatically isolate the machine or disconnect the user if the alert is malicious. This is insanely powerful. ----------------------------------------------------------------------------------------------------------- Change Log – Timeline of Everything The Change Log tab shows a timeline: When alert came in When investigation started Any status change Analyst comments If alert was closed If remediation was triggered It’s a clean, readable timeline. ----------------------------------------------------------------------------------------------------------- Second Method of Investigation – “Ask a Question” Earlier, I mentioned two ways to investigate: 1. Manual investigation using Panther 2. Using Dropzone findings Here’s the third  and easiest  method: Just ask Dropzone a question. Example questions: “Has this IP been used by any other user?” “Is this user agent associated with this IP anywhere in our logs?” “Show me all events linked to this process.” Just type your question like human language → Dropzone runs a full investigation across all logs and gives you the answer. No querying. No log diving. No manual searching. One of my favourite features. ----------------------------------------------------------------------------------------------------------- False Positive Example – Benign Alert Let’s take another example: MFA disabled by user. Normally this may look suspicious. But in reality, this was normal behaviour. Dropzone marked it as benign , and if you read the investigation, it clearly tells you why. Here you don’t need to investigate — just approve and close. ----------------------------------------------------------------------------------------------------------- Why AI Saves Massive Time (Realistic SOC Example) Let’s say 10 alerts arrive: 9 are false positives 1 is true positive A human analyst — even a very good one — will take about 45 minutes  to investigate all 10. There is also the chance they may get tired or distracted and miss the true positive. Now compare this with Dropzone: It will mark 9 alerts as benign  within 10 minutes It will highlight 1 true positive  clearly You just review the 1 true positive Approve the 9 benign ones This saves enormous time. This is why AI is becoming a huge part of SOC. Not because it replaces jobs, but because: It removes the noise so analysts can focus on the real threats. ----------------------------------------------------------------------------------------------------------- Final Thoughts You’ve now seen exactly how a Dropzone AI alert looks, how it thinks, how it asks questions, and how to review it. In the next article, I will show: Sentinel One, CrowdStrike Example --------------------------------------------------Dean---------------------------------------------------- Check out next article below: https://www.cyberengage.org/post/dropzone-ai-final-conclusion-what-all-these-examples-really-show

Now that I’ve shown you investigations from Panther  — I think you can clearly see what Dropzone AI is actually doing behind the scenes. No matter which security tool generates the alert: Dropzone picks it up instantly Investigates it faster than any human Asks all the important questions automatically Pulls evidence from everywhere Checks historical behaviour Compares with analyst verdicts Correlates with MITRE framework And finally gives you a clear conclusion All of this happens in seconds , not minutes — and definitely not hours. This is why I keep saying: AI is already transforming the SOC team, whether someone believes it or not. Look at the examples again: ✔ SentinelOne → Investigation + Findings + Remediation Conclusion Findings: Remediation ✔ CrowdStrike → Investigation + Findings Conclusion Findings: ✔ Microsoft Sentinel → Investigation + Findings Conclusion Findings: ✔ Splunk → Investigation + Evidence Locker + Findings Conclusion Evidence Locker Findings: Different tools, different alert types…But Dropzone handles all of them with the same speed, same accuracy, and same style. ----------------------------------------------------------------------------------------------------------- Why This Matters (Even if People Don’t Want to Hear It) Let’s be honest: Most SOC analysts today spend 70% of their time doing: Routine triage Repeating basic checks Searching logs Closing false positives This is exactly the work that AI automates perfectly . And when AI can: Analyze 10 alerts in 2 minutes Mark 9 as benign Show you only the real threat Pull evidence from all tools Provide ready-made conclusions Recommend remediation actions Even perform automated remediation …then the role of a SOC analyst changes forever. It’s not about “AI replacing jobs.” It’s about AI replacing the boring part of the job , and you focusing on real incident response. But people who refuse to learn these tools? Those are the ones AI will replace. ----------------------------------------------------------------------------------------------------------- My Final Advice to Every SOC Analyst / IR Engineer If you takeaway one thing from all these examples, let it be this: 👉 Start learning how to work WITH AI, not against it. 👉 Become the person who understands AI-driven investigations. 👉 Learn how to verify AI decisions, not manually do everything. 👉 Focus on deeper skills: threat hunting, forensics, malware analysis. AI is not taking your job. AI is taking your old  job. Your new  job is to supervise, validate, and respond — not chase false positives. Dropzone is just one example. So the smart move? Start upgrading your skills now. ------------------------------------------------Dean------------------------------------------

Your SOC, but finally without the headache. In the previous article, I talked about how AI is changing SOC operations forever — especially tools like Dropzone AI  that automate full investigations. If you ask me which tools I enjoy working with the most, I will always say CrowdStrike , SentinelOne , and Forensic tools . But recently, one tool has impressed me so much that I genuinely feel like every SOC team should see it at least once. And that tool is Dropzone AI . This Article part is all about how Dropzone actually looks and feels  when you use it every day. --------------------------------------------------------------------------------------------------------- The Dropzone Dashboard When you open Dropzone AI, the first thing you see is the Dashboard . And trust me — I love simple dashboards . SentinelOne has one of the best UIs , and Dropzone follows the same philosophy: clean, clear, and not overloaded. The dashboard lets you filter investigations by: Conclusion  (Benign / Suspicious / Malicious) Priority Status Source This is super helpful when you have multiple log sources connected. You can instantly see: Where alerts are coming from Which tools are generating noise Which sources need tuning How Dropzone is handling everything in real-time Lifetime Metrics You also get three very important metrics: ✔ Lifetime Investigations Total number of investigations Dropzone has done for your environment. ✔ Lifetime Median TTI TTI = Time to Investigate . Humans take 30–90 minutes per alert. Dropzone does this in under 20 minutes . ✔ Time Saved This is your “why am I not doing 24/7 shifts anymore” metric. This is the reason I say AI kills alert fatigue . Response Metrics (My favourite) This section shows: The time between the event happening and Dropzone completing the investigation. This is 🔥.Because humans simply cannot  operate with this speed or consistency — especially at 3 A.M. And if you want the best results? Make sure you ingest all logs . Dropzone correlates telemetry across tools — EDR, Identity, SIEM, Cloud — and then produces a final conclusion. More logs = more accurate investigations. Finally, the dashboard also includes: MITRE ATT&CK Correlation For every alert, Dropzone maps it to relevant MITRE techniques. This is extremely helpful for understanding attacks at a glance. --------------------------------------------------------------------------------------------------------- Fleet Dashboard — One Console for All Clients This is a new feature and honestly a game changer for MSSPs. If you manage many clients with different: Domains Tenants Log sources Alert volumes You don’t need to jump into each one separately. The Fleet Dashboard  shows: Total investigations per client Priority breakdown Status breakdown High-level overview of all environments Think of it as a master SOC console . Important: You can only see dashboards here — not  individual alerts. To analyze alerts, you still open that specific client’s workspace. There’s also a search bar on top: Just type the client name → instantly jump into their console. --------------------------------------------------------------------------------------------------------- Investigation Tab — The Heart of Dropzone This is where the magic happens. Whenever an alert comes in (CrowdStrike, SentinelOne, Panther, etc.): Dropzone picks it up → Triaged It starts investigation → Running It finishes and gives a conclusion → Benign / Suspicious / Malicious It categorizes into → Urgent / Notable / Informational And then it’s your job to review it. The Review Workflow Once Dropzone gives its conclusion: If you agree→ Approve the review→ Alert moves to Reviewed If you don’t agree→ Add your own analysis→ Change the category (e.g., benign) The right side shows: Queued  alerts Running  investigations Stopped  analysis (if you manually stop one) You don’t have to babysit anything. It runs automatically in the background. This UI is very  clean — honestly easier than CrowdStrike. Dropzone feels more like SentinelOne: simple, smooth, functional. --------------------------------------------------------------------------------------------------------- Ask a Question — AI Threat Hunting for Humans This is hands down one of the best features. You can ask Dropzone anything in human language, such as: “Was this IP seen with any other user?” “Did this hash appear anywhere else in the last 30 days?” “Show me all failed logins from this user across all sources.” Dropzone will go through every  integrated data source: SIEM EDR Identity logs Cloud logs Network logs …and give you a correct answer in under a minute. I tested it. I checked the logs manually. It was 100% correct. Search Result This feature alone saves hours of manual threat hunting. --------------------------------------------------------------------------------------------------------- Context Memory — The Brain of the SOC This part makes Dropzone feel less like a tool and more like a human teammate. This is one feature I truly love. Dropzone remembers your actions and your environment context. Example: You have a user who usually works in Europe but is traveling to the USA for 7 days. You simply write this in human language: “akash@cyberengage is traveling to the USA for 7 days. Login from USA is expected.” Dropzone stores this. Now, for the next 7 days, if the user logs in from the US, the alert will be marked benign automatically. It learns from: Your comments Your decisions Your organization context Seriously… this is next-level SOC automation. And the best part? If you mark the same alert type false positive  10 times→ Dropzone will automatically mark it benign next time. In 20,000+ investigations I observed, Dropzone never missed a true positive . It only produces false positives occasionally, and those are labeled benign — which you can simply approve. --------------------------------------------------------------------------------------------------------- Settings — Custom Strategies, Integrations, and Response Actions Let’s go through the most useful settings. Custom Strategies Think of these like “If this happens → do this” rules, but in AI style. Example 1: EICAR Test File If you often run EICAR tests: You can create a strategy: “If alert contains EICAR hash → mark as benign.” Next time the EICAR test runs? Dropzone auto-marks it benign. Example 2: Critical Assets If you have crown jewels (domain controllers, VIP laptops, financial systems): Create a strategy: “Always mark alerts from this asset as suspicious.” That way, analysts always review them — no risk. Integrations Dropzone supports easy, one-click integrations with tools like: SentinelOne CrowdStrike Microsoft Defender 365 Panther Okta Slack AWS GCP Azure…and many more. There are three parts: ✔ Connected Apps Which tools you’ve connected. ✔ Data Sources Where logs are coming from. ✔ Alert Sources Which alerts Dropzone should pick up and investigate. If Alert Source  is not enabled, Dropzone won’t triage alerts — it will only analyze data. Alert Source Sentinel one configuration example --------------------------------------------------------------------------------------------------------- Response Actions This is basically notifications & automation. You can configure Dropzone to send updates to: Slack Teams Email Custom scripts Webhooks Examples: “Send me a Slack message when a malicious investigation is completed.” “Trigger a script whenever Dropzone starts analyzing a new alert.” This means you don’t have to keep Dropzone open 24/7. --------------------------------------------------------------------------------------------------------- Automatic Remediation This is extremely powerful. If integrated with tools like Okta or Microsoft Defender auto remediation action be taken. Based on Dropzone’s conclusion. Or you can trigger remediation manually from the investigation page — without opening the original tool. --------------------------------------------------------------------------------------------------------- What’s Next? Alert Analysis I know this is the part everyone is waiting for. In the next article, I will show you: 🔥 Real investigation examples 🔥 CrowdStrike alert → Dropzone output 🔥 SentinelOne alert → Dropzone reasoning ------------------------------------Dean----------------------------------------------------------- Check Out next article below: https://www.cyberengage.org/post/deep-dive-how-dropzone-ai-investigates-alerts-panther-example-explained