Catch the Hardcoded Credential and the Invoke-Expression Before an Attacker Does — Security Review for Privileged PowerShell

A complete review should answer:

1. What privileges does the script require?
2. What systems can it access?
3. What data does it process?
4. Where do inputs originate?
5. Which inputs are trusted?
6. Does the script execute dynamic or remote content?
7. How are credentials and secrets handled?
8. Are communications encrypted and validated?
9. Can an attacker influence commands, paths, or arguments?
10. Can the script modify security-sensitive settings?
11. Are logs protected and sanitized?
12. Can dependencies or downloaded files be tampered with?
13. Are temporary files handled securely?
14. Can the script be safely rerun?
15. Is activity attributable and auditable?
16. What happens if the script is compromised?

param(
    [string]$ComputerName,
    [string]$Command
)

$username = 'Administrator'
$password = 'P@ssw0rd123'
$securePassword = ConvertTo-SecureString $password -AsPlainText -Force
$credential = New-Object `
    System.Management.Automation.PSCredential(
        $username,
        $securePassword
    )

Invoke-Command `
    -ComputerName $ComputerName `
    -Credential $credential `
    -ScriptBlock (
        [scriptblock]::Create($Command)
    )

PSSEC-001 — Hardcoded Administrative Credential

Severity: Critical

Confidence: Confirmed

Affected Code:

$username = 'Administrator'
$password = 'P@ssw0rd123'

Evidence: A privileged username and password are embedded directly in the script.

Risk Scenario: Anyone who can read the script, a backup, a repository copy, an editor history, or a deployment package can recover the credential.

The credential may also remain available through:

• Source control history
• Endpoint-management packages
• Backups
• Email attachments
• Temporary files
• Screen sharing
• AI prompt history

Impact: Potential remote administrative access to every system where the credential is valid.

Remediation: Remove the embedded secret immediately. Rotate the exposed password and review authentication logs. Retrieve credentials from an approved secret-management system or use an identity mechanism that does not require a stored password.

Possible alternatives include:

• Managed identity
• Group Managed Service Account
• Windows integrated authentication
• Certificate-based application authentication
• Azure Key Vault
• Approved enterprise password vault
• Secret variables provided by the automation platform

Verification:

• Search current and historical repositories for the password.
• Rotate the credential.
• Confirm the script works using the approved identity mechanism.
• Verify the secret is absent from logs and deployment packages.

PSSEC-002 — Execution of Untrusted Dynamic Code

Severity: Critical

Confidence: Confirmed

Affected Code:

[scriptblock]::Create($Command)

Evidence: Caller-controlled text is converted directly into executable PowerShell.

Risk Scenario: An attacker who controls the Command parameter can execute arbitrary commands under the supplied administrative credential.

Impact: Potential remote-code execution and full compromise of the target system.

Remediation: Do not accept arbitrary PowerShell commands. Replace the free-form command parameter with a constrained action and validated parameters.

PSSEC-003 — Excessive Privilege

Severity: High

Confidence: Likely

Affected Code:

$username = 'Administrator'

Evidence: The script uses the built-in administrator account regardless of the specific operation required.

Risk Scenario: If the script or credential is compromised, the attacker receives broader access than the task requires.

Remediation: Create a dedicated automation identity with only the rights required for approved operations.

Instead of accepting arbitrary command text, define approved actions.

[CmdletBinding(SupportsShouldProcess)]
param(
    [Parameter(Mandatory)]
    [ValidatePattern(
        '^[A-Za-z0-9][A-Za-z0-9.-]{0,62}$'
    )]
    [string]$ComputerName,

    [Parameter(Mandatory)]
    [ValidateSet(
        'GetServiceStatus',
        'RestartApprovedService'
    )]
    [string]$Action,

    [Parameter()]
    [ValidateSet(
        'Spooler',
        'W32Time'
    )]
    [string]$ServiceName
)

$sessionParameters = @{
    ComputerName = $ComputerName
    ErrorAction  = 'Stop'
}

$session = $null
try {
    $session = New-PSSession @sessionParameters
    switch ($Action) {
        'GetServiceStatus' {
            Invoke-Command `
                -Session $session `
                -ScriptBlock {
                    param($Name)
                    Get-Service `
                        -Name $Name `
                        -ErrorAction Stop
                } `
                -ArgumentList $ServiceName `
                -ErrorAction Stop
        }
        'RestartApprovedService' {
            if (
                $PSCmdlet.ShouldProcess(
                    "$ComputerName\$ServiceName",
                    'Restart service'
                )
            ) {
                Invoke-Command `
                    -Session $session `
                    -ScriptBlock {
                        param($Name)
                        Restart-Service `
                            -Name $Name `
                            -ErrorAction Stop
                        Get-Service `
                            -Name $Name `
                            -ErrorAction Stop
                    } `
                    -ArgumentList $ServiceName `
                    -ErrorAction Stop
            }
        }
    }
}
finally {
    if ($session) {
        Remove-PSSession -Session $session
    }
}

This version:

• Removes the embedded credential
• Uses the caller's approved authentication context
• Rejects arbitrary command text
• Restricts available actions
• Restricts service names
• Validates the computer name
• Supports -WhatIf
• Uses argument passing rather than dynamic code construction
• Cleans up the remote session

The actual authentication model should be selected based on the deployment environment.

Unsafe:

Invoke-WebRequest -Uri $Url |
    Invoke-Expression

Safer process:

1. Restrict approved domains.
2. Use HTTPS.
3. Download to a controlled location.
4. Verify the expected hash or signature.
5. Inspect the file.
6. Execute a version-controlled approved copy.
7. Record source and version.

Example hash verification:

$expectedHash = 'APPROVED_SHA256_VALUE'
Invoke-WebRequest `
    -Uri $Uri `
    -OutFile $downloadPath `
    -UseBasicParsing `
    -ErrorAction Stop

$actualHash = (
    Get-FileHash `
        -LiteralPath $downloadPath `
        -Algorithm SHA256).Hash

if ($actualHash -ne $expectedHash) {
    Remove-Item `
        -LiteralPath $downloadPath `
        -Force `
        -ErrorAction SilentlyContinue
    throw 'Downloaded file failed integrity verification.'
}

The expected hash must come from a trusted, independently controlled source.

Do not disable certificate validation to resolve connection problems.

Unsafe patterns may include:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {
    $true
}

or custom handlers that accept every certificate.

Disabling validation enables interception and impersonation.

Correct the underlying issue:

• Trust the correct certificate authority
• Repair the certificate chain
• Use the correct hostname
• Renew expired certificates
• Update the operating-system trust store
• Configure approved proxy inspection properly

PowerShell scripts often call native executables. Review:

• Executable path
• Search-path resolution
• Quoting
• Argument boundaries
• Input validation
• Exit code
• Standard error
• Command-line secret exposure
• Working directory
• Environment variables

Prefer an explicit executable path:

$executablePath = 'C:\Program Files\Vendor\Tool\tool.exe'

rather than:

tool.exe

when path hijacking is a meaningful risk.

Avoid predictable temporary-file names.

Weak:

$tempPath = 'C:\Temp\data.txt'

Better:

$tempPath = Join-Path `
    -Path ([System.IO.Path]::GetTempPath()) `
    -ChildPath (
        [System.IO.Path]::GetRandomFileName()
    )

Also consider:

• Directory permissions
• File permissions
• Sensitive contents
• Secure cleanup
• Failure cleanup
• Race conditions
• Reparse-point attacks
• Whether a temporary file is necessary

Do not assume deletion guarantees secure erasure on modern storage systems.

Review scheduled tasks for:

• Highly privileged run-as accounts
• Stored passwords
• Writable script locations
• Writable argument files
• Unquoted executable paths
• Task modification permissions
• Interactive logon requirements
• Unnecessary RunLevel Highest
• Insecure working directories
• Missing logging
• Uncontrolled triggers
• Network-share dependencies

A low-privilege user who can modify the script executed by a privileged task may be able to escalate privileges.

Good security logging should record:

• Script name and version
• Run ID
• Execution identity
• Host
• Start and completion status
• Privileged operations
• Target resource
• Administrative changes
• Authentication failures
• Authorization failures
• Integrity-verification failures
• Dependency changes
• Security-sensitive configuration changes

Do not log:

• Passwords
• Tokens
• Credential objects
• Authentication headers
• Private keys
• Full connection strings
• Sensitive request bodies
• Entire user records without need
• Secret environment variables

Code signing can support:

• Publisher verification
• Integrity checking
• Controlled release processes
• Application-control policies

Code signing does not prove that code is safe. It establishes origin and integrity based on the trust placed in the certificate and release process.

Review:

• Certificate protection
• Signing identity
• Timestamping
• Certificate expiration
• Revocation
• Build pipeline
• Who can publish signed code
• Whether signatures are verified at execution

Potential supporting controls include:

• AppLocker
• Windows Defender Application Control
• Constrained Language Mode
• Just Enough Administration
• Controlled administrative workstations
• Repository protections
• CI/CD approvals

PowerShell's abstract syntax tree can help identify risky constructs.

Example:

$tokens = $null
$errors = $null
$ast = [System.Management.Automation.Language.Parser]::ParseFile(
    $Path,
    [ref]$tokens,
    [ref]$errors)

$invokeExpressionCommands = $ast.FindAll(
    {
        param($node)
        $node -is [
            System.Management.Automation.Language.CommandAst
        ] -and
        $node.GetCommandName() -eq 'Invoke-Expression'
    },
    $true)

AST review is more reliable than simple regular expressions for many code patterns.

Consider:

• Dedicated automation identity
• Least-privilege role
• Managed identity or gMSA
• Protected script directory
• Signed release artifacts
• Version-controlled deployment
• Approved module repository
• Version pinning
• Restricted outbound network access
• Centralized logging
• Alerting on failures and modifications
• Administrative workstation controls
• JEA endpoints
• AppLocker or WDAC
• Script integrity monitoring
• Periodic access review
• Credential rotation
• Emergency-disable procedure