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

Your DTEX alert fires on a Windows host. The suspicious filename looks something like PowerShell_transcript.HOSTNAME.AbCdEfGh.20260115120000.txt in a temp directory. Before you escalate it as a potential threat — check whether Tenable VM ran a credentialed scan against that host recently.

Tenable VM creates PowerShell transcript files on Windows hosts as a side effect of credentialed scanning. This is expected behavior, not an indicator of compromise. Here's exactly why it happens and how to handle it.

// why tenable creates transcript files

When Tenable VM runs a credentialed scan against a Windows host using WMI or PowerShell remoting, it executes PowerShell commands to collect system data — installed software, patch levels, registry values, running services. If PowerShell transcription is enabled on that host (a common CIS and STIG hardening control), Windows automatically logs every PowerShell session to a transcript file.

Tenable's scan activity triggers the transcription. The file gets created in whatever transcript output directory is configured — often $env:USERPROFILE or a central log path. The filename format is deterministic and identifiable once you know what to look for.

// confirming this is the source

Cross-reference the timestamp on the transcript file with your Tenable scan schedule. If they align within the scan window, Tenable is the source.

You can also check the transcript content directly:

# Read the first 50 lines of the transcript
Get-Content "C:\Path\To\Transcript.txt" -TotalCount 50

Tenable's commands will be visible in the transcript — typically WMI queries, Get-WmiObject calls, registry reads, and similar enumeration activity. Nothing malicious, all scan-related.

// what to do about the alert

Option 1 — Whitelist the filename pattern in DTEX

Create a DTEX exception for the PowerShell transcript filename pattern when the source process is wsmprovhost.exe (WS-Management Provider Host, the process Tenable uses for PowerShell remoting). This suppresses the alert for legitimate scan activity without disabling transcription policy.

Option 2 — Configure transcript output to a monitored security log path

Instead of user temp directories, redirect PowerShell transcript output to a centralized path that's already part of your log pipeline. This keeps the transcripts for audit purposes while removing them from paths that trigger DTEX alerts.

# Group Policy or registry — set transcript output directory
$transcriptPath = "C:\SecurityLogs\PSTranscripts"
New-Item -ItemType Directory -Force -Path $transcriptPath

Option 3 — Scope transcription exclusions to the scan account

If transcription is enabled via Group Policy, you can exclude the specific service account Tenable uses for scanning from the transcription policy. Transcription stays enabled for all other accounts — only Tenable's scan sessions are excluded.

// on linux hosts

Tenable credentialed scans on Linux do not create transcript files. The equivalent activity — SSH-based enumeration commands — does appear in /var/log/auth.log or the system journal as normal SSH session activity from the scan account. If you're seeing unexpected entries there during scan windows, that's expected and not a concern.

# Check auth log for Tenable scan account activity
journalctl _COMM=sshd --since "2026-01-15 12:00:00" --until "2026-01-15 13:00:00"

// the takeaway

PowerShell transcript files created during Tenable scan windows are a known, expected artifact of credentialed scanning with transcription policy enabled. Confirm the source before escalating, whitelist the pattern in DTEX, and redirect transcript output to a managed path. Document the behavior so the next analyst who sees the alert understands the context.