How do attackers use PowerExchange?

What PowerExchange does in an attack chain

PowerExchange is not usually the final objective. It functions as a post-compromise remote administration tool, giving the intruder a way to execute commands, move data, and keep a foothold on a host after the initial intrusion has succeeded. In practice, that means its value lies in control, visibility, and persistence rather than in the first-stage break-in.

That makes it useful in the hands of an attacker because it can blend routine administration with malicious activity. A defender should think in terms of what the tool enables operationally: remote execution, staging of additional payloads, and follow-on access to the same system over time. When a tool is designed for admin-style command and control, its abuse often looks like legitimate system management until the command patterns and destinations are compared against normal baselines.

How attackers operate once PowerExchange is present

Attackers typically use PowerExchange after they already have code execution. From there, they can issue commands, enumerate the environment, pull files or data, and keep the system available for later use. That sequence matters because the malware is often part of the “hands-on-keyboard” phase, where the operator is deciding what to do next based on what the host reveals.

The practical security issue is that this stage often overlaps with legitimate PowerShell administration. As a result, defenders need to distinguish approved automation from attacker-controlled execution paths. A malicious operator can also use the same foothold to prepare for lateral movement, test privileges, or maintain persistence by repeatedly reusing the infected host as an access point.

For teams that investigate endpoint activity, the most important pattern is not just “PowerShell exists,” but whether its use is consistent with the host’s normal administrative workflow. Unusual encoded commands, abnormal parent-child process chains, and network sessions to destinations that are not part of approved tooling are all signs that remote control may be active.

What defenders should check first

The fastest way to assess exposure is to determine whether the host is running PowerExchange code in a context that should never exist on that system. That means validating whether the process tree, command line, and remote connections match expected administration patterns. If the activity is not associated with a known admin workflow, treat it as potential compromise rather than as routine automation.

Defenders should also look for the surrounding evidence that usually accompanies this kind of malware use: script obfuscation, encoded payloads, repeated outbound connections, and signs that the host is being used for command execution rather than for a one-time delivery event. If the malware has been active for any length of time, assume the attacker may have used the system to stage additional tools or collect information that should be considered exposed.

Risk and Threat Considerations

PowerExchange matters because it gives an attacker durable remote control after the initial breach, which turns a single compromised host into an operational base. The main risk is not just data theft, but the ability to keep issuing commands, maintain access, and hide inside patterns that resemble legitimate administration.

Failure mechanism: The malware abuses trusted scripting and remote administration paths, so ordinary PowerShell activity can mask malicious command execution, data collection, and persistence.

Impact: A compromised host can become a repeatable control point for follow-on intrusion, lateral movement, and continued exposure of files, credentials, or internal systems that the attacker reaches from that host.

Practitioner Guidance

What to verify: Confirm whether the host is allowed to run the observed commands at all. If the command line is encoded, the parent process is unexpected, or the destination is outside normal admin tooling, treat the event as malicious until proven otherwise.

What to prioritise: Focus on containment first, then rebuild the timeline of execution and outbound activity. A host used for remote control should be investigated as both an endpoint event and a potential staging point for wider compromise, not as an isolated malware alert.

Decision rule: If the malware has likely provided interactive access, assume the attacker may have already used the host for persistence or additional collection. In that case, review adjacent systems, rotate any secrets or session material that may have been accessible from the host, and compare the observed behaviour against approved administrative workflows.

Practitioner takeaway: The key question is not whether PowerExchange ran once, but whether it gave the attacker a controllable platform that they could return to without standing out from normal administration.

Related resources from NHI Mgmt Group

• Guide: Malware Guide
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?