How do attackers use Invoke-PSImage?

How Invoke-PSImage Changes the Attack Path

Invoke-PSImage is a file-hiding technique, not a new payload type. It lets an attacker bury PowerShell code inside an image and recover it at execution time, which reduces the chance that a quick scan or casual review will notice the script. The technique is most useful when the goal is quiet delivery, staged execution, or hiding the real script from defenders who only look at obvious script files.

What matters operationally is that the image is acting as a carrier, while the PowerShell runtime becomes the real execution environment. That means the suspicious activity may appear only when the content is decoded or loaded into memory, rather than when the file is first written to disk.

For defenders, that shifts attention from file extension alone to content provenance, script execution behaviour, and memory-loading patterns. A benign-looking image can still be part of a script chain if it is being read by PowerShell or by another loader that extracts hidden content.

What Attackers Rely On When They Use It

Attackers usually depend on inspection gaps: file triage that trusts the extension, controls that do not inspect embedded or hidden content, and environments where PowerShell usage is broad enough that malicious script execution blends into normal administration. The technique is especially effective when scripts are passed around as part of a staged workflow and the image is only one step in the chain.

The value to the attacker is not stealth by itself, but PowerShell security weaknesses that let hidden code reach execution with limited scrutiny. If PowerShell execution is loosely governed, hidden content can be decoded, unpacked, and launched before standard endpoint controls notice the real intent.

It also fits well with broader staged delivery patterns. The image can be transported through routine channels, then used later to reconstruct a script, retrieve a second-stage payload, or trigger a follow-on action that makes the original file look harmless in transit.

What Defenders Should Look For Instead of the File Extension

Start with the relationship between the file and the process that consumes it. If an image is being accessed by a script, opened by automation, or referenced from an unusual PowerShell command line, that is more important than whether the file visually resembles a normal picture. Defenders should also look for script activity that reads bytes from image files, decodes embedded content, or loads content directly into memory.

PowerShell detections are strongest when they combine process context, script content, and execution telemetry. In practice, that means monitoring for suspicious encoding behaviour, unusual image paths, child processes launched from PowerShell, and scripts that repeatedly touch media files without a legitimate business reason.

At a broader threat level, MITRE ATT&CK Enterprise Matrix is a useful reference for mapping the activity to credential access, execution, and lateral-movement style behaviours once the hidden script is active. For detection engineering, the key point is to tie the hidden payload to the behaviour it enables, not just to the carrier file.

Risk and Threat Considerations

Invoke-PSImage is risky because it helps malicious code evade simple content inspection and makes staging easier in environments where PowerShell is already trusted. The threat is less about the image format itself and more about the attacker gaining a low-friction way to move script logic into a place where analysts may not expect it.

Failure mechanism: The hidden content survives casual inspection, is recovered only at runtime, and then executes under a process path that may look normal if telemetry is shallow. That creates a detection gap between what is stored and what is actually run.

Impact: Defenders can miss early-stage execution, lose visibility into the real script body, and give an attacker a cleaner path to deliver additional tooling, run discovery commands, or stage follow-on payloads.

Practitioner Guidance

What to verify: Treat any script that reads from image files as suspicious until you can explain the business purpose. Confirm whether the file is part of a known workflow, whether the PowerShell command line is expected, and whether the image is being accessed for a genuine operational reason.

What good looks like: PowerShell use is constrained, script execution is logged, and image files are not accepted as opaque carriers for executable content without a clear control or validation step. That makes hidden-code delivery harder to conceal and easier to investigate.

Common mistake: Focusing only on file type blocking. Blocking obvious script extensions helps, but it does not catch hidden payloads if PowerShell can still read, decode, and execute content from seemingly benign files.

Practitioner takeaway: The important decision is not whether the file looks like an image, but whether the environment can prove what content PowerShell extracted from it and what the process did next.

Related resources from NHI Mgmt Group

• 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?