Credential Exposure in Memory

A Deep Dive into SecureString, PowerShell, and Windows Process Internals

Credential handling is one of those topics where abstraction hides reality. PowerShell provides SecureString, PSCredential, and high-level cmdlets, but the operating system underneath follows very strict and sometimes uncomfortable rules.

This article removes the abstraction layer and walks through what really happens, why it happens, and how to observe it yourself.

This is not a theoretical discussion. This is a hands-on exploration.

---

Table of Contents

1. Why This Topic Matters

2. The Reality of Secrets in Memory

3. Windows Security Boundaries Refresher

4. PowerShell Credential Flow (High-Level)

5. SecureString Internals

6. Crossing the Managed / Unmanaged Boundary

7. Native API Requirements

8. Step-by-Step Execution Flow

9. Building a Reproducible Lab

10. Observing Credential Exposure Live

11. Memory Dump Analysis in Practice

12. Timing, Windows, and Exposure Windows

13. Failure Paths and Cleanup

14. Advanced Memory Inspection Techniques

15. Operational Security Takeaways

16. Secure Design Lessons

17. Defensive Engineering Strategies

18. Final Thoughts

---

1. Why This Topic Matters

Many security discussions around credentials focus on storage:

• Passwords on disk

• Credential files

• Vaults

• Encryption at rest

But most credential theft happens in memory.

If you work in:

• Red Team

• Blue Team

• Malware analysis

• Secure development

• DFIR

Then understanding when and why credentials appear in memory is mandatory.

---

2. The Reality of Secrets in Memory

There is no such thing as a “never-in-memory” secret.

At some point:

• A CPU register

• A stack frame

• A heap allocation

will contain plaintext.

Security is about controlling who can see that memory, not pretending it doesn’t exist.

---

3. Windows Security Boundaries Refresher

Windows enforces security using:

• Process isolation

• Access tokens

• Privileges (SeDebugPrivilege)

• Kernel enforcement

Key principle:

If an attacker can read arbitrary memory of another process, the system is already compromised.

This principle underpins everything discussed in this article.

---

4. PowerShell Credential Flow (High-Level)

Let’s start with familiar code:

$securePassword = ConvertTo-SecureString "SuperSecret123!" -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential (
    "testuser",
    $securePassword
)

Start-Process -FilePath "notepad.exe" -Credential $credential

At a glance:

• Password is a SecureString

• Everything looks safe

• No plaintext strings are visible

Internally, however, a very different story unfolds.

---

5. SecureString Internals

SecureString works by:

• Encrypting the string in memory

• Tying encryption to the current user context

• Allowing explicit zeroing

What it does not do:

• Prevent decryption

• Prevent copying

• Prevent inspection by privileged actors

This is intentional.

SecureString is damage control, not a security boundary.

---

6. Crossing the Managed / Unmanaged Boundary

PowerShell is a managed runtime.

Windows process creation is not.

When PowerShell needs to create a process under alternate credentials, it must cross from:

• Managed (.NET)

• Into unmanaged (Win32)

This boundary is where plaintext appears.

---

7. Native API Requirements

The key Windows API involved is:

CreateProcessWithLogonW(
    username,
    domain,
    password,
    logonFlags,
    applicationName,
    commandLine,
    ...
);

This API:

• Requires a plaintext password

• Accepts no encrypted variant

• Is widely used across Windows

Because of this, PowerShell has no alternative path.

---

8. Step-by-Step Execution Flow

Internally, PowerShell performs something equivalent to:

IntPtr passwordPtr = SecureStringToCoTaskMemUnicode(securePassword);

try {
    CreateProcessWithLogonW(
        username,
        domain,
        passwordPtr,
        ...
    );
}
finally {
    ZeroFreeCoTaskMemUnicode(passwordPtr);
}

At this moment:

• The password exists in plaintext

• It resides in unmanaged memory

• It lives for a short but real time window

---

9. Building a Reproducible Lab

Requirements

• Windows 10/11

• PowerShell 5.1 or PowerShell 7

• Administrator access

• Sysinternals tools (ProcDump)

---

Step 1: Create a Test Credential

$securePassword = ConvertTo-SecureString "LabPassword123!" -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential (
    "Administrator",
    $securePassword
)

---

Step 2: Trigger Process Creation

Start-Process -FilePath "notepad.exe" -Credential $credential

Keep the PowerShell process alive.

---

10. Observing Credential Exposure Live

Open another PowerShell session as Administrator.

Identify the target process:

Get-Process powershell

Select a PowerShell PID different from your own.

---

11. Memory Dump Analysis in Practice

Dump the process memory:

procdump.exe -ma <PID> C:\temp\ps_mem.dmp

Extract strings:

strings C:\temp\ps_mem.dmp | Select-String "LabPassword"

Expected Result

• The password may appear

• It may appear multiple times

• It may appear fragmented

This confirms:

• Plaintext exposure exists

• Exposure is observable

• Exposure is memory-only

---

12. Timing, Windows, and Exposure Windows

The exposure window depends on:

• CPU scheduling

• System load

• Timing of process creation

• Speed of cleanup

On fast systems:

• The window is extremely small

• But non-zero

On slower or debug-heavy environments:

• The window may be larger

---

13. Failure Paths and Cleanup

Test a failure case:

try {
    Start-Process -FilePath "C:\does_not_exist.exe" -Credential $credential
} catch {
    Write-Host "Process creation failed"
}

Repeat the memory dump.

Observations:

• Password may still appear

• Cleanup still occurs

• Process termination releases memory

---

14. Advanced Memory Inspection Techniques

Beyond strings, advanced analysts can use:

• WinDbg

• Volatility

• Rekall

• Process Hacker

Search patterns:

• UTF-16 strings

• Heap allocations

• CoTaskMem regions

This is exactly how post-exploitation credential harvesting works.

---

15. Operational Security Takeaways

Offensive Perspective

• Memory credential access is post-exploitation

• Requires privilege escalation

• Enables lateral movement

Defensive Perspective

• Preventing memory access matters more than hiding plaintext

• Credential Guard, ASR rules, and EDR telemetry are key

• Monitoring memory dumping is critical

---

16. Secure Design Lessons

Key lessons:

• Secure abstractions do not eliminate reality

• OS APIs dictate security constraints

• Privilege boundaries matter more than encryption

• Understanding internals prevents false assumptions

---

17. Defensive Engineering Strategies

Avoid Passing Credentials

Whenever possible:

• Use Kerberos delegation

• Use managed service identities

• Use tokens instead of passwords

Reduce Exposure Time

• Spawn short-lived helper processes

• Avoid long-running credentialed processes

• Drop privileges immediately

Detect Abuse

• Monitor SeDebugPrivilege

• Detect memory dump tooling

• Alert on abnormal process creation

---

18. Final Thoughts

Plaintext credential exposure in memory is not an anomaly. It is a natural consequence of how operating systems function.

Security is not about eliminating this reality, but about controlling who is allowed to observe it.

Professionals who understand this distinction build better defenses, conduct better investigations, and avoid chasing illusions of perfect secrecy