Why you should never run an unknown PowerShell script

PowerShell is one of the most powerful tools in a Windows system administrator's arsenal — and that power cuts both ways. A single script can provision hundreds of users, configure network settings across an entire domain, delete files, disable security software, or exfiltrate data. The same capability that makes PowerShell invaluable for automation makes it a favorite vector for attackers and a liability for anyone who runs a script without understanding it first.

In IT support environments, scripts arrive from many directions: a vendor provides an onboarding automation, a colleague shares something from their GitHub, a user pastes something from a forum thread. The professional habit — and the safe one — is to read before you run. ScriptSense makes that practical by translating technical PowerShell syntax into plain English with a risk assessment.

How to read a PowerShell script safely

1. Check the execution policy first

Before a script can run, Windows checks its execution policy. Run Get-ExecutionPolicy in a PowerShell window to see your current setting. Common values are Restricted (no scripts), RemoteSigned (downloaded scripts must be signed), and Unrestricted (all scripts run). If someone asks you to run Set-ExecutionPolicy Bypass as part of their instructions, treat that as a significant red flag.

2. Look for these high-risk patterns

• Invoke-Expression (IEX) — executes a string as code. Often used to run encoded or downloaded payloads.
• DownloadString / DownloadFile — fetches content from the internet. Could pull additional malicious code.
• -EncodedCommand — runs Base64-encoded commands. Always decode and inspect what's inside.
• Disable-WindowsOptionalFeature or touching Windows Defender settings — security software modifications.
• net user /add or Add-LocalGroupMember — creates accounts or elevates privileges.
• Remove-Item -Recurse -Force — mass file deletion. Check the path carefully.

3. Understand the scope

Pay attention to whether a script targets -ComputerName parameters, loops through AD objects with Get-ADUser -Filter *, or uses -Scope Global. Scripts that operate on "all" objects in a domain or loop through every computer in a site carry far more risk than those targeting a single resource.

# Example: This looks innocent but could delete everything in a path
$path = "C:\Users\$env:USERNAME\Downloads"
Get-ChildItem $path | Remove-Item -Recurse -Force
# Always verify what $path resolves to before running

Common PowerShell commands explained

Here are the most frequently encountered PowerShell commands and what they actually do — useful reference when reviewing an unfamiliar script.

• Get-ADUser — retrieves user objects from Active Directory. Read-only unless piped into a modification command.
• Set-ADUser — modifies AD user attributes. Changes are immediate and affect live directory objects.
• Import-Module — loads a PowerShell module. Verify the module source; modules can contain arbitrary code.
• Start-Process — launches an application or command. Check what it's launching and with what arguments.
• New-ScheduledTask — creates a Windows scheduled task. Scripts that do this persist beyond their initial run.
• Invoke-WebRequest — makes HTTP requests. Can be used to send data out or pull payloads in.
• ConvertFrom-SecureString — converts encrypted password data. Watch for credential handling.
• Register-PSRepository — registers a PowerShell repository. Could point to a malicious package source.

PowerShell security best practices for IT teams

Beyond reviewing individual scripts, IT teams should establish baseline PowerShell security hygiene across their environment.

• Enable Script Block Logging — Group Policy: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging. This logs all script block content to the event log (Event ID 4104), giving you visibility into what actually ran.
• Use Constrained Language Mode — Limits PowerShell to a safe subset of commands. Combine with AppLocker or WDAC policies for enforcement.
• Require code signing for production scripts — Use a trusted internal PKI to sign scripts your team writes. Set execution policy to AllSigned in production environments.
• Audit execution with Intune or SCCM — If you're deploying scripts at scale via Microsoft Endpoint Manager, use the reporting features to track execution success/failure and what ran on which devices.
• Test in a sandbox first — Spin up a VM (or use Windows Sandbox) to test unfamiliar scripts before running them in production. Take a snapshot before testing so you can roll back.