1. When a Legitimate Windows Tool Becomes Suspicious

Imagine an EDR alert identifies PowerShell running with a hidden window on an employee's workstation. The process command line contains an encoded command, and the parent process is an unfamiliar application.

Initially, the event may appear to be a routine administrative script. However, further investigation reveals that the process contacted an external domain shortly after execution.

The SOC analyst now needs to determine whether the activity belongs to an authorised automation task or represents an attempt to execute malicious code.

This is a common challenge in Windows security monitoring.

PowerShell is not inherently malicious. Administrators use it to manage users, configure services, automate repetitive tasks, and troubleshoot systems. Attackers exploit the same capabilities because PowerShell can interact with the operating system and other Windows components.

The key to investigating suspicious PowerShell activity is to analyse the complete execution context, not just the command name.

2. Why Do Attackers Abuse PowerShell?

PowerShell provides access to Windows management capabilities, scripting functionality, and .NET components. When misused, these features can help attackers perform activities without immediately introducing an obvious standalone executable.

Common malicious uses include:

• Executing commands after a phishing incident.

• Downloading additional files or scripts.

• Running commands with encoded arguments.

• Discovering users, processes, services, and system configuration.

• Accessing or manipulating files and registry settings.

• Attempting to weaken security controls.

• Establishing persistence through other Windows mechanisms.

• Supporting lateral movement or other post-compromise activity.

Some attacks use PowerShell directly, while others invoke it through Office applications, script interpreters, scheduled tasks, management tools, or other processes.

Not every suspicious command is malicious, and attackers do not always use PowerShell. Investigation should be driven by observed behaviour and supporting evidence.

3. Common Signs of Suspicious PowerShell Execution

1. Encoded commands

PowerShell supports encoded command-line arguments, including the -EncodedCommand parameter.

Encoding can be used for legitimate automation, but attackers may use it to make command-line activity less readable during initial inspection.

Example indicator:

powershell.exe -EncodedCommand [encoded-content]

The placeholder above is illustrative, not a runnable command.

Investigation focus: Decode the captured content safely and inspect what it does. Encoding alone does not prove malicious intent.

2. Hidden or non-interactive execution

PowerShell can be launched with options that reduce visible interaction, such as -WindowStyle Hidden or -NonInteractive.

These options can appear in legitimate automation as well as malicious scripts.

Investigation focus: Examine the parent process, user context, command-line arguments, execution time, and whether the activity matches an approved task.

3. Remote script or payload retrieval

PowerShell may be used to retrieve content from a remote server or URL.

Unexpected network requests from PowerShell are particularly relevant when they occur alongside suspicious command-line arguments or unusual process ancestry.

Investigation focus: Review DNS, proxy, firewall, and EDR network telemetry. Determine the destination, requested resource, and whether a file was downloaded or executed.

4. Suspicious parent processes

PowerShell launched by an unexpected process may indicate that another application initiated the activity.

Potentially suspicious examples include a document-processing application, an unfamiliar executable in a temporary directory, or a process associated with a recent phishing alert.

The parent process alone is not proof of compromise. Software installers, management tools, and authorised automation can legitimately launch PowerShell.

Investigation focus: Reconstruct the process tree and examine the events that occurred immediately before PowerShell started.

5. Unusual script content

Scripts that combine system discovery, credential-access attempts, suspicious network communication, or security-control modification deserve closer attention.

Investigation focus: Analyse the script's behaviour and correlate it with endpoint, identity, and network evidence.

4. How SOC Analysts Investigate Suspicious PowerShell

A structured investigation should establish the execution source, the command's purpose, and the activity that followed.

Step 1: Validate the EDR or SIEM alert

Start with the original alert and collect:

• Hostname and device identifier.

• Username and logon session.

• Process name and process ID.

• Parent process and parent process ID.

• Full command line.

• Process start time.

• File path and hash, where available.

• Related network connections and security alerts.

Determine whether the alert was triggered by a detection rule, a known malicious indicator, or suspicious behaviour.

Step 2: Examine the full command line

Review all available arguments and parameters.

Look for encoded commands, hidden execution, unusual script paths, remote content retrieval, or combinations of parameters that are unexpected for the host.

If an encoded payload is present, preserve the original command line before decoding it. Decode the content in a controlled environment and treat the result as untrusted.

Do not execute suspicious scripts simply to understand them.

Step 3: Reconstruct the process tree

Identify the parent process that launched PowerShell and any child processes that PowerShell subsequently created.

Ask:

• Was PowerShell launched by a known management tool?

• Did an unexpected application initiate execution?

• Did PowerShell launch additional interpreters or executables?

• Did the process run under an unusual account?

• Was there a related phishing, download, or exploit alert?

Process ancestry can provide important context that is absent from the PowerShell command line alone.

Step 4: Review PowerShell logging

Where enabled, PowerShell logging can provide additional detail about executed commands and script content.

Useful sources include:

• PowerShell Operational log, Event ID 4103: Module logging information, depending on configuration.

• PowerShell Operational log, Event ID 4104: Script block logging.

• Windows Security Event ID 4688: Process creation, when the appropriate auditing is enabled.

Also review EDR process telemetry and any centralised logs collected by the SIEM.

Logging availability depends on PowerShell version, audit configuration, policy, and the telemetry product. Missing events do not necessarily mean that no suspicious activity occurred.

Step 5: Investigate network activity

Determine whether PowerShell made outbound connections during or shortly after execution.

Examine:

• Destination domains and IP addresses.

• DNS queries and proxy requests.

• Downloaded files and their hashes.

• Connections to unfamiliar hosting infrastructure.

• Whether other endpoints contacted the same destinations.

Correlate the network activity with the command's purpose and the process timeline. A network connection from PowerShell is not inherently malicious.

Step 6: Check for post-execution activity

Investigate whether the process was followed by additional suspicious behaviour, such as:

• Unexpected executable or script creation.

• Registry or scheduled-task changes.

• Unusual account or privilege changes.

• Security-tool tampering.

• Credential-access alerts.

• Additional remote connections.

• Access to sensitive files or systems.

This step helps determine whether the event was an isolated script execution or part of a broader intrusion.

Step 7: Determine the incident severity

Classify the activity according to the available evidence.

Likely benign: The command matches an approved script, the execution source is expected, and supporting activity is consistent with normal administration.

Suspicious: The command or process context is unusual, but the available evidence does not establish malicious intent.

Confirmed malicious: The investigation identifies malicious script behaviour, unauthorised payload execution, or corroborating evidence of compromise.

Document the evidence supporting the classification and update it as new information becomes available.

Step 8: Contain and remediate

If the activity is confirmed malicious or presents a significant and immediate risk, follow the organisation's incident response procedures.

Actions may include isolating the endpoint, blocking confirmed malicious destinations, terminating malicious processes, preserving forensic evidence, and investigating potentially compromised accounts.

Remove persistence mechanisms only after identifying them and preserving the relevant evidence. Recover the system according to organisational procedures and monitor for repeated activity.

5. Important Windows Event IDs and Logs

Event sourceEvent IDInvestigation valuePowerShell Operational4103Module logging information, when enabledPowerShell Operational4104Script block content, when enabledWindows Security4688Process creation, when auditing is enabledWindows Security4624Successful logon and session contextWindows Security4625Failed logon activitySystem log7045Service installation events that may be relevant to persistence investigations

These events provide different perspectives on the incident. Correlate them using timestamps, hostnames, users, process identifiers, and other available fields.

Event ID 4104 can be particularly useful because it may record script block content, but logging configuration and collection gaps can limit visibility.

6. Example SIEM Queries for Investigation

The following examples are starting points. Adapt the indexes, table names, and field mappings to your environment.

Splunk: Find PowerShell process executions

index=wineventlog EventCode=4688 | search NewProcessName="*\\powershell.exe" OR NewProcessName="*\\pwsh.exe" | table _time Computer SubjectUserName NewProcessName Process_Command_Line Creator_Process_Name | sort 0 - _time

This query looks for process-creation events involving Windows PowerShell or PowerShell 7, assuming the relevant fields are extracted.

Splunk: Search PowerShell script block logs

index=wineventlog EventCode=4104 | table _time Computer UserID ScriptBlockText | sort 0 - _time

Review the script content for suspicious behaviour and correlate it with the process tree and associated alerts. Do not label a script malicious based solely on an isolated keyword.

Microsoft Sentinel: Review PowerShell-related Windows events

For Windows event data collected in the SecurityEvent table:

SecurityEvent | where TimeGenerated > ago(24h) | where EventID == 4688 | where Process has_any ("powershell.exe", "pwsh.exe") | project TimeGenerated, Computer, Account, NewProcessName, CommandLine, ParentProcessName | order by TimeGenerated desc

Field availability and naming depend on the collection configuration. If the expected fields are not populated, inspect the table schema and the raw event before adjusting the query.

Investigation tip: Start with the host and timestamp from the alert, then expand the search to include related process, script, network, and authentication activity.

7. Indicators and Evidence to Look For

Suspicious PowerShell execution has no single universal indicator. Investigators should correlate several evidence sources.

Evidence sourceWhat to investigateProcess telemetryCommand line, parent process, child processes, user context, and execution timePowerShell logsScript blocks, module activity, and suspicious command sequencesNetwork logsUnexpected outbound connections, DNS queries, and download activityFile-system evidenceNewly created scripts, executables, and suspicious filesRegistry and task logsUnauthorised persistence or configuration changesIdentity logsSuspicious logons, privilege changes, or account activityEDR alertsPayload execution, credential-access behaviour, and security-control tampering

A hidden PowerShell window or encoded command is an investigation clue, not proof of compromise. The strongest conclusions come from correlating command content, process ancestry, and observed behaviour.

8. MITRE ATT&CK Mapping

The following techniques may be relevant when supported by the investigation evidence.

TechniqueIDRelevancePowerShellT1059.001Execution of commands or scripts using PowerShellObfuscated Files or InformationT1027Concealing or obfuscating malicious contentIngress Tool TransferT1105Transferring tools or files into an environmentSystem Information DiscoveryT1082Collecting operating system or system informationImpair DefensesT1562Attempts to weaken or bypass security controlsScheduled Task/JobT1053Relevant when a scheduled task is used for execution or persistence

These mappings describe possible behaviours, not a claim that every suspicious PowerShell event uses all of these techniques.

9. How Organisations Can Reduce PowerShell Abuse

Enable appropriate logging. Configure PowerShell script block and module logging according to security and privacy requirements, and forward relevant events to centralised monitoring.

Use endpoint detection and response. Monitor process ancestry, suspicious command lines, script execution, network connections, and post-execution activity.

Apply least privilege. Limit administrative privileges and use separate administrative accounts where appropriate.

Use application control. Apply supported controls to restrict unauthorised scripts and applications while preserving legitimate administration.

Consider PowerShell security features. Evaluate constrained language mode, application control integration, and other supported safeguards based on operational requirements.

Monitor outbound traffic. Restrict unnecessary access to external destinations and investigate unusual downloads initiated by scripting processes.

Protect privileged accounts. Use strong authentication and monitor for suspicious administrative activity.

Investigate behavioural combinations. Correlate encoded commands, unexpected parent processes, remote downloads, and suspicious follow-on activity instead of relying on a single command-line pattern.

Test detections safely. Validate detection rules using approved test procedures and controlled simulations to measure visibility and false-positive rates.

10. Lessons for Modern SOC Teams

PowerShell is a powerful administrative technology, which makes indiscriminate blocking impractical in many Windows environments.

A mature SOC should distinguish legitimate automation from suspicious execution using command content, process ancestry, user context, network behaviour, and follow-on activity.

Investigators should also recognise that attackers may use other interpreters or execution mechanisms when PowerShell is restricted. Detection engineering should therefore focus on the wider behaviour of the intrusion rather than a single executable name.

When a suspicious PowerShell alert appears, the objective is not merely to identify an unusual command. It is to establish what executed, why it executed, what it accessed, and whether the system or its user was compromised.

Conclusion

Suspicious PowerShell execution can indicate anything from legitimate administrative automation to a significant security incident. Encoded commands, hidden execution, unexpected parent processes, and unusual network activity deserve investigation, but none should be treated as conclusive proof in isolation.

Effective analysis combines process telemetry, PowerShell logs, network evidence, identity records, and the activity that follows execution.

The key lesson: Do not investigate PowerShell in isolation. Reconstruct the execution chain, validate the command's purpose, and follow the evidence to determine whether a compromise occurred.

Further Reading

• Microsoft Learn — PowerShell logging and security features.

• MITRE ATT&CK — PowerShell and command execution techniques.

• Microsoft Learn — Windows process creation auditing and event collection.