CL_LoadAssembly.ps1 (Windows LOLBAS Script)

What This Technique Is Doing

CL_LoadAssembly.ps1 is a living-off-the-land PowerShell script pattern that loads a .NET assembly through a trusted Microsoft component, so execution can look like ordinary administration instead of a suspicious new program launch.

The security significance is not the assembly alone, but the execution path. By moving code through an expected component, the technique can reduce user scrutiny, complicate allow-listing decisions, and make process ancestry look more legitimate than a direct executable drop.

Why It Blends In

This pattern works because defenders often tune alerts around new binaries, unsigned executables, or obvious LOLBin abuse, while trusted Microsoft tooling, script hosts, and administrative command lines are common in normal operations. The technique therefore exploits the gap between “allowed in principle” and “expected in this context.”

Living off the Land Guide is the best broader reference point for understanding how LOLBins, LOLBAS, and script-based proxy execution fit into real-world attack chains and detection strategy.

Because the loader is a script rather than a standalone payload, analysts should pay attention to script content, command-line arguments, and whether the surrounding activity matches the system's normal management baseline. Unusual parent-child chains matter here because they often reveal the difference between legitimate administration and abuse of a trusted component.

What Defenders Should Look For

Exposure is usually visible in the execution context, not just the file name. Uncommon invocation paths, odd parent processes, abnormal script locations, and assembly loads that do not align with routine admin workflows are all strong indicators that the technique is being used for stealthy execution.

Monitoring should also correlate script activity with other signs of compromise, such as suspicious command-line switches, staged payloads, or follow-on process creation from the same host. A single trusted component may be benign; the chain of activity often is not.

MITRE ATT&CK Enterprise Matrix helps place this technique in the broader adversary workflow, especially where it overlaps with proxy execution, execution, and defense evasion patterns.

How To Reduce Its Abuse Potential

The practical defense is to narrow where trusted scripting paths can execute, not to assume that all Microsoft tooling is safe. Application control, script auditing, and hardening of management pathways all matter because the attacker is borrowing trust from a legitimate component rather than introducing an obviously malicious one.

Where business operations require the tooling, defenders should strengthen visibility around script execution and unexpected assembly loading so they can distinguish sanctioned administration from abuse. That makes the technique easier to detect even when the component itself cannot be removed from the environment.

NIST Cybersecurity Framework 2.0 is a useful high-level reference for organizing protect, detect, respond, and recover activities around this kind of execution abuse.

Risk and Threat Considerations

This technique is dangerous because it turns trusted administrative pathways into an execution channel for malicious code. The main risk is not just unauthorized code execution, but reduced visibility, slower detection, and the possibility that the activity is mistaken for normal maintenance.

Failure mechanism: An attacker abuses a trusted Microsoft component to load a .NET assembly, which helps the activity inherit legitimacy from the host process and bypass simple controls that only watch for suspicious executables.

Impact: The result can be stealthier execution, easier persistence staging, and a higher chance that follow-on compromise goes unnoticed until later investigation.

Practitioner Guidance

What to watch for: Treat this as a correlation problem, not a single-signature problem. The most useful judgment is whether the assembly load, script host, and parent-child relationship fit the normal administrative pattern for that endpoint or user.

Governance implication: Teams should decide which Microsoft scripting and management paths are truly allowed, then make sure monitoring, alerting, and response procedures are tuned to those approved use cases rather than to generic “PowerShell = bad” assumptions.

Practitioner takeaway: The more trusted the component, the more important context becomes, because attackers deliberately choose living-off-the-land paths to make malicious execution resemble routine work.

Related resources from NHI Mgmt Group

• How should security teams detect and prioritize LOLBAS activity in Windows environments before attackers turn trusted tools into delivery and execution paths?
• What signs suggest script-based malware is hiding behind normal Windows tooling?
• Windows Script File
• Logon Script (Windows)