LSASS Memory Access Detection in Windows Environment

Purpose

The goal of this exercise was not to simulate an attack for demonstration value, but to engineer and validate a behavioral detection for LSASS memory access on a Windows endpoint. Specifically, I wanted to understand:

• How LSASS access is represented in endpoint telemetry.
• Whether a detection can be built around that representation without depending on a specific dumping tool.
• What context is available to support triage when such an alert fires.

The focus was detection design, not red team tradecraft.

Threat Model

Attacker Type: Post-compromise adversary with local administrative privileges.

Assumed Capabilities:

• Arbitrary code execution on the endpoint
• Administrative token
• SeDebugPrivilege enabled
• Ability to spawn processes and interact with LSASS

Objective: Extract credentials from LSASS memory (MITRE ATT&CK T1003.001 – LSASS Memory).

Detection Goal: Identify behavioral indicators of credential dumping by detecting sensitive handle access to the LSASS process, independent of specific tooling.

MITRE ATT&CK Mapping

• TA0006 – Credential Access
• T1003 – OS Credential Dumping
• T1003.001 – LSASS Memory

The detection is specifically engineered to identify behavior aligned with T1003.001.

Environment

The lab consisted of:

• Windows 10 endpoint
• Sysmon with SwiftOnSecurity configuration
• LimaCharlie sensor
• Ubuntu host running Sliver C2

Defender was disabled to prevent interference with dumping activity. That reduces realism but ensured the telemetry I observed came from the behavior I triggered, not from defensive countermeasures. The Windows machine was not domain joined. There was no SIEM. All visibility came from Sysmon and the LimaCharlie sensor.

This constraint was intentional. I wanted to isolate endpoint-level telemetry without adding cross-host noise.

Architecture Overview

The environment consists of two virtual machines connected via a NAT network:

1. Windows 10 Endpoint - Sysmon installed with SwiftOnSecurity configuration - LimaCharlie sensor installed - Acts as compromised host 2. Ubuntu Server - Hosts Sliver C2 framework - Receives HTTP callbacks from the implant

Data Flows: 1. Command & Control Traffic The Sliver implant running on the Windows endpoint establishes an outbound HTTP session to the Ubuntu server. 2. Telemetry Flow The LimaCharlie sensor streams endpoint telemetry and Sysmon logs outbound to the LimaCharlie cloud platform over HTTPS.

Detection logic is executed within the LimaCharlie cloud detection engine.

Establishing Execution Context

The Sliver implant was generated and executed on the Windows endpoint.

After the session came online, I verified execution context using:

• whoami
• getprivs

The session had administrative privileges and included SeDebugPrivilege. This matters because LSASS dumping requires elevated rights. Without sufficient token privileges, handle access to LSASS will either fail or produce different telemetry. From a detection standpoint, this clarifies something important: LSASS dumping detection assumes the attacker has already escalated privileges. If you see LSASS access, you are not at initial compromise, you are at credential access stage.

Baseline Telemetry Before Dumping

Before triggering the dump, I reviewed the process tree and network view inside LimaCharlie.

The implant stood out for predictable reasons:

• Executed from Downloads directory
• Unsigned
• Running under admin context
• Maintaining outbound HTTP connection

This reinforces that LSASS dumping is rarely isolated. It typically follows suspicious execution and command-and-control activity.

From a detection layering perspective, this means LSASS detection should be considered high-confidence but not standalone. It benefits from surrounding context.

Triggering LSASS Dumping

From the C2 session, I executed:

procdump -n lsass.exe -s lsass.dmp

The intent was simply to cause a handle open operation against LSASS with sufficient access rights to allow memory dumping.

Immediately afterward, the timeline showed a SENSITIVE_PROCESS_ACCESS event.

This event is critical. It is not raw Windows API output. It is an abstraction provided by the sensor indicating that a process attempted to access a protected process in a way considered sensitive.

The raw event data included:

• Source process path
• Target process path
• Process IDs
• User SID
• Access attempt metadata

The target file path resolved to lsass.exe.

Understanding the Telemetry

Under the hood, LSASS dumping involves opening a process handle with specific access rights (typically including PROCESS_VM_READ and related flags).

Rather than parsing low-level access masks directly, the sensor classifies certain combinations of access rights targeting sensitive processes as SENSITIVE_PROCESS_ACCESS.

This abstraction simplifies detection logic but introduces dependency on the sensor’s classification engine. If the sensor fails to label an event correctly, the detection will not fire. And that tradeoff is important.

The advantage:

• Cleaner detection logic.
• Reduced need to interpret access masks manually.

The limitation:

• Dependence on vendor-defined sensitivity logic.

Detection Design Decisions

I considered three possible detection anchors: 1. Command-line detection (match lsass in arguments). 2. Process name detection (match procdump.exe). 3. Behavioral detection (match sensitive access to LSASS).

Options 1 and 2 were rejected immediately because they are trivial to bypass. Renaming the binary or using another dumping utility would evade both.

The behavioral anchor was stronger:

Any process generating a SENSITIVE_PROCESS_ACCESS event where the target is LSASS.

The implemented rule:

event: SENSITIVE_PROCESS_ACCESS
op: ends with
path: event/*/TARGET/FILE_PATH
value: lsass.exe

I deliberately did not:

• Filter by source process name
• Restrict by specific access mask
• Filter by parent process
• Tie detection to a specific user context

The goal was to validate the core behavioral anchor first before tightening logic.

Validation Process

Before enabling the rule fully, I tested it using LimaCharlie’s event replay feature.

This step confirmed that the rule logic matched the captured event exactly as expected. After saving the rule, I re-ran the dumping command live, and the detection triggered again.

Reproducibility confirmed that the rule was not accidentally tied to a single instance of telemetry.

Investigation Context

When the alert fires, the immediate triage questions are:

• What process initiated the access?
• What is its parent?
• What is the execution path?
• What user context was involved?
• What network connections followed?

Because this was a lab environment, the parent process chain traced back to the Sliver implant. In a production environment, this would be the most critical pivot point. Legitimate tools may interact with LSASS. The parent process lineage determines whether the event is malicious or expected.

This reinforces that detection without investigation context is incomplete.

Why I did not implement automatic termination?

For shadow copy deletion later in the project, I implemented automatic process termination.

I did not do that for LSASS access.

There are legitimate scenarios where security software or backup agents interact with LSASS. Automatically killing processes that access LSASS could destabilize the endpoint or interfere with defensive tooling.

Credential dumping detection is high confidence, but not automatically safe to remediate blindly. This was a deliberate response design decision, not an oversight.

Limitations & False Positive Considerations

This environment does not represent enterprise reality, because:

• Defender was disabled
• No domain services
• No legitimate LSASS access noise
• No enterprise security stack running

In enterprise environments, LSASS access is not exclusively malicious. Legitimate access patterns may include:

• Endpoint security products performing memory inspection
• Backup or credential protection agents
• System processes interacting with LSASS under protected modes (e.g., RunAsPPL)

In production deployments, this detection would require:

• Allowlisting trusted signed binaries
• Filtering known security tooling
• Potentially refining logic based on access mask severity
• Correlating with parent process lineage and execution context

This lab validates behavioral feasibility, not production-grade tuning.

Conclusion

This case study demonstrates that LSASS memory access can be reliably detected using behavior-based telemetry anchored to sensitive process access events.

More importantly, it demonstrates the full detection lifecycle:

• Generating real attacker behavior.
• Observing how telemetry represents that behavior.
• Selecting a detection anchor based on semantics, not tooling.
• Validating rule logic against raw events.
• Re-testing under live conditions.
• Evaluating response strategy.
• Acknowledging environmental limitations.

The strength of this project is not that LSASS dumping was detected. It is that the detection was engineered from telemetry upward, rather than from tool signature downward.