Test your SOC · about a minute

Can your SOC see someone reading what you typed last week?

One real attacker move, a safe way to run it on a machine you own, and the detection that closes the gap — in that order, so you leave with better coverage than you arrived with.

technique T1552.001 · Credentials In Filesseen in Fox Kittenwhere any Windows box

What this is about

Can your SOC see an attacker reading your typed passwords?

PowerShell writes every command you type to a plain text file, forever, with no permissions on it beyond your own account. Most people have never opened it. An intruder opens it first, because people put passwords, connection strings and keys on command lines and the file keeps all of them exactly as typed.

This is not a credential attack in the usual sense — nothing is cracked, dumped or elevated. It is one file read. The detection watches for the file being located or opened from a command line, because that is a very specific thing to go looking for.

The detection watches one thing: the PowerShell console history file being opened or located from a command line.

This is not hypothetical

The intrusion set tracked as Fox Kitten is documented harvesting credentials from files on the systems it reaches. Credentials found in a file need no cracking and set off none of the alarms that a credential dump does — they are simply used, and the use looks legitimate.

No admin rights are needed to read your own history, and nothing is modified. The same lines you are about to run, against your own file.

The actor above is named in MITRE ATT&CK’s own Procedure Examples for this technique; the link is where you can read it. Nothing on this page discloses a move an attacker does not already have — it just makes sure the defender has it too.

Sources · MITRE ATT&CK T1552.001

It is a plain text file

No encryption, no special permission, no expiry. Whatever was typed at a prompt is still sitting there in the clear.

A found password raises no alarm

Nothing is dumped and nothing is cracked. The credential is simply read and then used, and the use looks like the person it belongs to.

Almost nobody reads it legitimately

That is what makes this worth alerting on: the file has very few honest reasons to be opened from a command line.

The test

Run the real thing. Safely. On a box you own.

Read your own history file the way an intruder reads it, then open your alerts.

Find where your history is kept

The first line asks PowerShell for the path of its own history file. This is already the lookup an intruder makes.

Read the last lines of it

The second line prints the end of that file — your own typed commands. Look at them honestly: is there anything in there you would not want an intruder to read?

Check your alerts

Open your SOC or EDR. Did console history access fire — or can that file be read without anyone knowing?

test-your-soc-credentials-in-files.ps1 · PowerShell · a machine you own

# test-your-soc-credentials-in-files.ps1 — run on a machine you own.
# Safe: reads your own PowerShell history file. Read-only, nothing changed, nothing to undo.
# STEP 1 - ask PowerShell where its own console history is kept.
powershell -NoProfile -Command "(Get-PSReadLineOption).HistorySavePath"
# STEP 2 - the actual technique: read that file, the way an intruder harvests typed secrets.
powershell -NoProfile -Command "Get-Content (Get-PSReadLineOption).HistorySavePath -Tail 20"
# STEP 3 - open your SOC / EDR. Did console history access alert?

Both lines are read-only and they read only your own account's history file. Nothing is deleted, modified, copied off the machine or sent anywhere, so there is nothing to undo and no admin rights are needed. If you would rather not see the contents at all, run only the first line — locating the file is enough to test the detection.

Reading the result — honestly

Something fired

Your tooling watches for the console history file being read

Good — you would see an intruder harvesting typed secrets before they used one. On to the next one.

Silence

The file was read unseen — now you know

Not a verdict on your team; a specific, fixable gap you just found in a minute. The detection below closes it. While you are here: whatever you saw in step two is worth rotating.

Straight with you: we never see your alerts — you’re the judge, which is also why we never touch your data. And a lab isn’t production; a test box often logs differently than the real fleet. "It fired" means your EDR flagged the history file being located or read from a command line — note that a file-access rule on the same path catches the quieter case where the file is opened without ever naming it on a command line, so the two rules are worth having together. Treat a pass as a reason to go check prod, not a finish line.

How to catch it

Missed it? Here’s the fix — take it straight to your SOC.

The logic is public and every major SIEM already supports it. Here it is in Sigma, the open, vendor-neutral format your team can translate into whatever you run.

proc_creation_win_powershell_console_history_file_access.yml

title: Potential PowerShell Console History Access Attempt via History File
id: f4ff7323-b5fc-4323-8b52-6b9408e15788
status: experimental
description: |
    Detects potential access attempts to the PowerShell console history directly via history file (ConsoleHost_history.txt).
    This can give access to plaintext passwords used in PowerShell commands or used for general reconnaissance.
references:
    - https://0xdf.gitlab.io/2018/11/08/powershell-history-file.html
author: Luc Génaux
date: 2025-04-03
tags:
    - attack.credential-access
    - attack.t1552.001
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|contains:
            - 'ConsoleHost_history.txt'
            - '(Get-PSReadLineOption).HistorySavePath'
    condition: selection
falsepositives:
    - Legitimate access of the console history file is possible
level: medium

Potential PowerShell Console History Access Attempt via History File · SigmaHQ rule f4ff7323-b5fc-4323-8b52-6b9408e15788

Author Luc Génaux · quoted in full and unmodified under the Detection Rule License 1.1 (DRL 1.1)

https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_powershell_console_history_file_access.yml

Retrieved 2026-09-11 · file sha256 37e30936d9e4de3099c9502626204928f697d6eaea2a00f6a8e4ee5b2907e348

If your test came back silent, that rule is the whole fix. Drop it into your SIEM, or send your provider this page — “we ran this, nothing fired, here’s the detection.” Either way your coverage is better tonight than it was this morning. That’s the point.

A new one every week

This is technique 13 of many.

Each one is a real attacker move, a safe way to try it, and the detection to close the gap. Run them over a few weeks and you’ll learn more about your real coverage than any dashboard has told you.

Curious how a system catches all of these at once, out of the box? That’s what we build — meet Mobula →

Credit & sources

The technique and the incident are documented by MITRE ATT&CK (T1552.001) and the sources linked above. The detection is expressed in Sigma, the open detection format maintained by the SigmaHQ community, so any team can use it freely; its author is credited above under DRL 1.1.

We show you public attacker tradecraft and public detection logic, and hand you both. Nothing here reveals anything an attacker doesn’t already have — it just makes sure the defender has it too.

CYRAY · MOBULA — SECURITY OPERATIONS, ORCHESTRATED BY AI