Which LSASS dumping variants does a sweep of Sysmon Event ID 10 process access miss?

## What the record actually is Sysmon **Event ID 10** is `ProcessAccess`: it is written when one process opens a handle to another. The fields that carry the meaning are `SourceImage` (who asked), `TargetImage` (what they asked for), `GrantedAccess` (the rights the kernel actually granted, as a bitmask) and `CallTrace` (the stack of modules the request came through). It is not a record that memory was read. It is a record that a handle with certain rights was granted. The mask is the discriminating field. The bits that matter for reading another process's memory are `PROCESS_VM_READ` (`0x0010`), usually alongside `PROCESS_QUERY_INFORMATION` (`0x0400`) or `PROCESS_QUERY_LIMITED_INFORMATION` (`0x1000`), which is why masks such as `0x1010` and `0x1410` recur in this hunt. A handle granted only `PROCESS_QUERY_LIMITED_INFORMATION` cannot read memory at all, so filtering on the read bit rather than on any access to the target is what keeps the result set finite. ## What the sweep does cover Run across the estate, a `TargetImage` / read-bit filter covers most of the procedure list at once: - **`rundll32` invoking the `MiniDump` export of `comsvcs.dll`.** Nothing is dropped on the host and the calling binary is a Microsoft one, so nothing about the *tool* is suspicious — but the handle is still opened, and `CallTrace` shows `comsvcs.dll` in the stack. - **A renamed dumping utility.** The name in `SourceImage` is whatever the operator chose. It does not matter: the handle open is the same. - **An implant issuing direct syscalls.** This is the variant people expect to evade the record, and it usually does not. Direct syscalls exist to bypass **user-mode API hooks** that some products place in `ntdll.dll`. Sysmon's ProcessAccess telemetry comes from a kernel-registered object-access callback, which sits below that. The record still appears, and the `CallTrace` is itself informative: a stack returning into unbacked memory rather than into a known module is unusual on its own. ## What it misses, and this is the point of the leaf **The kernel-driver variant.** If an operator loads a signed but vulnerable driver and has it read the target's memory from kernel mode, there is no user-mode handle request, so no ProcessAccess record is ever written. This is not a tuning problem or a coverage gap you can filter your way out of; the observable simply does not exist. It needs different records — driver load (Sysmon **Event ID 6**), the service creation that installed the driver, and the dump file's appearance on disk (Sysmon **Event ID 11**, FileCreate). **The clone variant.** Some implementations snapshot or fork the target and dump the copy. The read that matters then targets a child object whose image is not `lsass.exe`, so a filter pinned to `TargetImage` never matches it. The handle open that *created* the clone may still be visible, which is why the smarter sweep also looks for unusual access masks against the credential process rather than only read masks — but you should treat this variant as partially covered and say so. ## Pair the observable, do not trust it alone A mature version of this hunt runs the handle-access sweep and, alongside it, looks for the artefacts the dump has to leave elsewhere: a large file written by an unexpected process, a driver loaded on a workstation that loads no drivers, a service created and immediately deleted. Each of those is individually noisier; together with the handle record they discriminate far better than any one of them. ## Getting the direction of the claim right The most common wrong answer in this area is to read a ProcessAccess hit as evidence that credentials were stolen. It is not. It is evidence that a handle with read rights was granted. Whether memory was read, whether a dump was produced, whether it left the host — each of those is a separate question needing separate evidence. Conversely, a benign hit is extremely common: endpoint protection agents, backup and inventory software, performance tooling and the built-in task manager all legitimately open read handles to that process, and several do it on a timer. Those are **benign true positives** — the behaviour genuinely occurred and is genuinely not malicious — not false positives, and calling them the wrong thing leads people to try to fix the sweep instead of filtering it. ## The takeaway shape of the answer Name the record and its fields, name the mask bit that carries the meaning, list which variants the sweep covers and *why* direct syscalls do not escape it, then name the two it cannot see and the records that would. An interviewer is checking whether you know that choosing one observable is choosing a specific set of blind spots, and whether you can enumerate yours rather than assuming full coverage.