Why Tenable VM Creates PowerShell Transcript Files on Windows Hosts — and What to Do About It

You get a Dtex alert — something about a suspicious filename containing what looks like credential data on a Windows host. First instinct is to treat it as a real finding. Before you go down that rabbit hole, here's what's most likely happening.

// what's actually going on

When Tenable VM runs a credentialed scan against a Windows host, it authenticates via SMB/WMI and spawns a PowerShell session to run audit checks. If your environment has PowerShell Transcription enabled via Group Policy — which most hardened federal environments do — Windows automatically writes a transcript of every PowerShell session to disk. Tenable's session included.

The file looks something like this:

PowerShell_transcript.HOSTNAME.AbCdEfGh.20260115120530.txt

That random string in the middle — AbCdEfGh — is not a password. It's a session identifier Windows generates to avoid filename collisions when multiple PowerShell sessions run simultaneously. Dtex is pattern-matching on it and flagging it as a potential credential. It's a false positive.

// is there an actual risk here

The transcript file itself does contain the audit commands Tenable ran — registry queries, service states, patch checks. That's not nothing. The real question is where the file is written and who can read it.

If the transcript output path is a shared network location visible to non-privileged users, that's a legitimate finding worth addressing. If it's writing to the local profile of the Tenable scan account with properly restricted access — that's expected behavior, document it and move on.

// what it looks like on Linux

Linux doesn't have PowerShell Transcription by default, but the equivalent behavior shows up differently depending on your logging configuration.

When Tenable authenticates to a Linux host via SSH and runs its audit commands, those commands get logged in a few places depending on what's enabled:

Bash history — if the Tenable scan account has a home directory with history enabled, every command Tenable runs gets written to ~/.bash_history. On a shared or poorly scoped scan account this is readable by anyone with access to that home directory.

# Check what Tenable's scan account history looks like
cat /home/tenable_scan/.bash_history

auditd — if auditd is running with syscall logging, Tenable's SSH session will generate audit events for every command executed. This is expected and correct — it means your audit framework is working. The events will reference the scan account and show the commands Tenable ran.

# Filter auditd logs for Tenable scan account activity
ausearch -ua tenable_scan --start today

Syslog / journald — SSH login and session events for the scan account land here. If Dtex or your SIEM is ingesting these logs, you may see alerts on the scan account's activity pattern — frequent logins, rapid command execution — which looks like automated enumeration because it is.

// how to handle it

Tune the Dtex rule — add a scoped exception for PowerShell_transcript.* files written to the expected output path. Document it as known Tenable scan behavior. This is the right call if access controls are already tight.

Restrict the transcript path — verify the GPO output path is local only, accessible to the scan account and local admins. Set a retention policy so transcripts are purged after 30–90 days.

Scope the GPO by security group — if you need transcription for everything else but want to exclude the Tenable scan account specifically, remove it from the GPO security group that enforces transcription.

On Linux — disable bash history for the scan account by setting HISTSIZE=0 and HISTFILESIZE=0 in the account's profile. Keep auditd logging — that's the right place for this activity to be recorded.

# Disable bash history for Tenable scan account
echo 'unset HISTFILE' >> /home/tenable_scan/.bash_profile
echo 'HISTSIZE=0' >> /home/tenable_scan/.bash_profile

// bottom line

A Dtex alert on a PowerShell transcript filename is almost always a false positive from Tenable credentialed scanning hitting a correctly configured GPO. Verify the transcript output path access controls, tune the detection rule, document it, and close the alert. The same logic applies on Linux — audit the scan account's bash history settings and confirm your SIEM exceptions cover expected Tenable SSH session activity.