Proxyware installs through in-memory PowerShell and hidden startup tasks

At a glance

What this is: This incident analysis shows how freeware-bundled scripts, scheduled tasks, and in-memory PowerShell were chained to install proxyware on a compromised Windows endpoint.

Why it matters: It matters because endpoint software installation paths, PowerShell governance, and service-account privilege are identity-adjacent controls that can turn a routine user action into durable system compromise.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.

👉 Read Expel's analysis of a proxyware infection chain using PowerShell

Context

PowerShell abuse is difficult to separate from normal administration because it is part of legitimate Windows operations, but that same familiarity gives attackers cover. In this case, the concern was not a single suspicious command. It was a staged chain that used freeware installation, scheduled execution, and in-memory script execution to move from initial foothold to proxyware deployment. The primary governance gap is not just malware detection. It is the lack of control over software installation paths, script execution, and privileged automation on endpoints.

The identity angle here is real even though the attack is endpoint-led. SYSTEM-level scheduled tasks, execution-policy bypass, and service creation all depend on trusted identities and elevated context, whether human or machine. When those identities are not bounded by policy, users can unknowingly introduce persistent execution paths that later become attacker-controlled. This is typical of commodity endpoint compromise patterns, not an outlier case.

Key questions

Q: How should security teams handle suspicious PowerShell chains on Windows endpoints?

A: Treat them as an execution-chain problem, not a single-alert problem. Correlate parent processes, remote script retrieval, and in-memory execution, then verify whether the command bypassed normal policy controls. If a user endpoint is allowed to run PowerShell freely, the environment is already exposing too much trust to routine activity.

Q: Why do scheduled tasks create persistent risk when paired with user-installed software?

A: Because they let untrusted code reappear under a trusted context after the original install looks complete. A task that runs as SYSTEM can survive the user session, call back to a C2 server, and wait for a later payload. The risk is persistence plus privilege inheritance, not just automation.

Q: What do teams get wrong about proxyware and similar grey-area software?

A: They assume the issue is only nuisance bandwidth use. In practice, proxyware often sits inside a broader compromise chain that already includes hidden scripts, remote tasking, and elevated execution. Once the attacker controls the host, the same path can be reused for more harmful payloads.

Q: What should defenders do before a staged PowerShell payload completes?

A: Isolate the endpoint as soon as the chain shows scheduled persistence and remote command retrieval. That breaks the attacker’s ability to deliver the final executable, prevents follow-on task creation, and gives investigators a cleaner timeline for containment and root-cause analysis.

Technical breakdown

Download cradles and in-memory PowerShell execution

A download cradle is a script or command chain that retrieves payload content from a remote location and executes it immediately, often through PowerShell's Invoke-WebRequest and Invoke-Expression. Because the code never needs to land as a file before it runs, file-based controls lose visibility. In this incident, the chain used nested CMD and PowerShell calls, execution-policy bypass, and in-memory execution to reduce friction and delay detection. That pattern is effective because many defenders still anchor on file hashes instead of runtime behaviour and child-process lineage.

Practical implication: monitor for PowerShell download-and-execute patterns, especially execution-policy bypass and in-memory invocation from unusual parent processes.

Scheduled tasks and SYSTEM context as persistence

Scheduled tasks are a common persistence mechanism because they let an attacker re-enter the system on a timer and under a trusted security context. Here, the first stage created a task to run a JavaScript file hourly with SYSTEM privileges, which is far more durable than a one-time script launch. The later stage attempted to create service-like persistence for proxyware using another task and a renamed executable path. This shows how persistence can be staged quietly long before the final payload is delivered.

Practical implication: audit task creation, service installation, and SYSTEM-level execution paths as persistence controls, not just as administrative functions.

Living-off-the-land abuse hides malicious software installation

The chain relied on legitimate tools and plausible user activity, including freeware installation, Node.js execution, CMD, and PowerShell. That matters because defenders often whitelist the tools while missing the sequence. The attack did not need an exploit; it needed trusted binaries, an unattended install path, and enough privilege to wait. Once the attacker gained execution under SYSTEM, the same mechanism could have delivered proxyware or a more destructive payload. The technique is less about malware novelty than about control failure across software allowance, script governance, and privilege boundaries.

Practical implication: combine application control, script restriction, and least-privilege enforcement so legitimate tools cannot be repurposed into hidden execution chains.

Threat narrative

Attacker objective: The attacker aimed to convert a compromised Windows endpoint into a monetised proxyware host while preserving the option to deliver additional payloads later.

1. Entry began when a user installed a seemingly harmless disk-cleaning utility that bundled a hidden PowerShell script and staged additional components.
2. Credential or privilege abuse followed when the script created a scheduled task to run under SYSTEM and used trusted Windows tooling to contact a C2 server.
3. Impact was delayed until the attacker issued the final PowerShell command, which would have installed proxyware and enabled further payload delivery on the endpoint.

NHI Mgmt Group analysis

Software installation governance is now a hidden identity control. The attack began as a user-driven install, but the real risk was the creation of privileged execution paths that outlived the original application. When users can introduce tasks, services, and scripts that later run in SYSTEM context, endpoint governance becomes part of identity governance. Practitioners should treat software allowance, script control, and privilege scoping as one control plane, not separate concerns.

PowerShell abuse remains dangerous because the control gap is behavioural, not binary. The suspicious activity was built from legitimate components, which means file reputation alone is an incomplete defense. The more important signal is the sequence of child processes, remote retrieval, and in-memory execution under a trusted context. Teams that rely only on signature-based detection will keep missing the exact sort of chain described here.

Named concept: endpoint persistence drift. This is the gap between the time a benign-looking install occurs and the moment an attacker converts it into durable control. The drift is created by scheduled tasks, delayed C2 callbacks, and privilege inheritance that are not tied to the original user action. The practitioner conclusion is simple: shorten the window in which unauthorised execution paths can remain invisible.

Application control must be treated as an identity boundary, not just a software policy. AppLocker and Windows Defender Application Control matter here because they constrain what can execute on an endpoint, but their real value is stopping unreviewed code from inheriting trusted context. That is an access problem as much as an endpoint problem. Practitioners should align software restriction, PowerShell governance, and administrative privilege reviews under one operating model.

Proxyware is a useful reminder that monetisation abuse can sit on the same kill chain as malware. Even when the immediate payload is not overtly destructive, the attacker still wants unauthorised control of compute, network, and privilege. That means defenders cannot triage this as a low-grade nuisance if the chain shows persistence, remote tasking, and system-level execution. The governance conclusion is to close the path before the final payload, not after the abuse becomes visible.

What this signals

Endpoint persistence is now a governance signal, not just a malware signal. When scheduled tasks and service contexts can be created by user-driven installs, defenders need visibility into who can create trusted execution paths, not only what binary is running. That is where least privilege, software allowlisting, and runtime monitoring should converge, especially in environments that already struggle with service-account sprawl.

The operational lesson for security teams is to treat script governance and privilege inheritance as a single control problem. If PowerShell can be used to retrieve and execute code in memory, and if SYSTEM tasks can be created from ordinary installs, then the programme needs tighter control over both endpoint execution and administrative context. MITRE ATT&CK mapping and hardening guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls both support that approach.

For practitioners

• Restrict PowerShell execution on user endpoints Limit interactive PowerShell use to approved administrative roles and enforce constrained language or execution-policy controls where appropriate. Pair this with detailed logging so remote script retrieval and in-memory execution are visible.
• Block unapproved software installation paths Use application control such as AppLocker or Windows Defender Application Control to prevent freeware installers and bundled scripts from introducing persistent execution chains.
• Audit scheduled tasks and service creation for SYSTEM context Look for hourly tasks, renamed service binaries, and tasks that run under SYSTEM without a clear business owner or support ticket.
• Correlate parent-child process lineage around CMD and Node.js Investigate endpoint alerts where svchost, Node.js, CMD, and PowerShell appear in an unusual chain, because that sequence often indicates staged script execution rather than normal administration.
• Contain and isolate endpoints at the first persistence signal When a host shows remote script retrieval plus scheduled task persistence, isolate it before the final payload runs so the attacker cannot pivot to additional payload delivery.

Key takeaways

• The incident shows how a routine software install can become a durable endpoint compromise when hidden scripts, scheduled tasks, and SYSTEM context are allowed to persist.
• The key evidence was not a malicious file on disk but an execution chain that used PowerShell, remote retrieval, and delayed C2 tasking to hide in normal Windows activity.
• App control, PowerShell restriction, and persistence auditing would have narrowed or broken the chain before proxyware installation completed.

Key terms

• Download Cradle: A download cradle is a script or command sequence that fetches code from a remote source and executes it immediately, often without writing a file to disk. Attackers use it to reduce forensic evidence and bypass file-centric detection, especially when trusted tools like PowerShell are involved.
• Scheduled-Task Persistence: A condition where an AI agent creates or modifies recurring automation that continues after the original interaction. It matters because a one-time injection can become durable influence, making later actions look legitimate even though the underlying instruction was attacker-shaped.
• Application control: Application control is the enforcement of which software may run on a device and under what conditions. It is a key governance layer because unauthorized or unsafe code can undermine access assurance even when authentication and device enrolment are in place.
• SYSTEM Context: SYSTEM context is the highest-privilege local security context on Windows endpoints, used by core operating system services. When attackers obtain execution in this context, they can install persistence, manipulate services, and broaden their control far beyond a normal user session.

What's in the full article

Expel's full blog covers the operational detail this post intentionally leaves for the source:

• Full process tree and command-line breakdown of the PowerShell download cradle used in the intrusion.
• Indicator details for the scheduled tasks, paths, and hashes associated with the staged payloads.
• IOCs for the bundled freeware installer, JavaScript stage, and proxyware executable path.
• Step-by-step defensive recommendations for PowerShell logging, application control, and endpoint containment.

👉 Expel's full post covers the process tree, IoCs, and containment details behind the proxyware chain.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security decisions that shape endpoint, cloud, and automation risk.