PowerShell Add-Type

What Add-Type Changes in a PowerShell Session

Add-Type expands what a script can do by letting it compile source code or load an assembly at runtime. That shifts a script from ordinary command composition into a form of in-session code execution, which matters because the script can gain access to managed .NET APIs, custom types, and native functions that are not visible from the PowerShell surface alone.

In practice, that means the cmdlet is not just a convenience feature. It can materially broaden the reachable attack surface inside a session, especially when script content is accepted from external inputs, pulled from untrusted locations, or run in environments where execution policy is treated as a control rather than a boundary.

How Add-Type Works Under the Hood

Add-Type can take inline C# or a referenced assembly, compile or load it, and make the resulting types available to the current process. Because the code runs inside PowerShell’s host process, it inherits the session context, available modules, and any authority already present in that process.

This design is useful for automation, but it also means the boundary is thinner than with a standalone binary. A script may look like ordinary PowerShell while actually introducing compiled logic that is harder to inspect, audit, or restrict with simple text-based review.

The security implication is straightforward: the feature is often legitimate, but it also creates a place where code review, allowed-language policy, and runtime restrictions need to be more precise than "this is only a script".

Why Add-Type Is Attractive in Abuse Scenarios

Attackers and red teams value Add-Type because it can bridge PowerShell into richer runtime capabilities without dropping an obvious executable to disk. That can help with living-off-the-land style activity, custom in-memory logic, or calling lower-level APIs when script-only techniques are too limited.

The feature can also be used to wrap native functionality, which may bypass assumptions defenders make about what a PowerShell command line can and cannot do. If the environment treats PowerShell as low-risk because it is “just scripting,” Add-Type can undermine that assumption.

For that reason, defenders should treat it as a capability that can change detection, not merely as a developer convenience. A script using Add-Type can warrant more scrutiny than one that stays within ordinary cmdlets.

Controls That Matter for Add-Type

Mitigating risk depends on controlling who can run PowerShell, what sources scripts can use, and how much trust is granted to dynamically compiled code. Script block logging, module logging, constrained language modes, application control, and tight administrative boundaries all help reduce the room for abuse.

Visibility is also important. PowerShell telemetry that captures script content, compilation-like behaviour, and process ancestry helps security teams distinguish normal administration from suspicious runtime code generation. Where Add-Type is used legitimately, documenting the business reason for it makes review much easier.

For broader defensive baselines, see NIST Cybersecurity Framework 2.0 for governance and detection coverage, and NIST SP 800-53 Rev 5 Security and Privacy Controls for access control, audit, and system integrity practices that support script and runtime hardening. When PowerShell is used to access APIs or wrap sensitive operations, MITRE ATT&CK Enterprise Matrix is useful for mapping how in-session code execution fits into credential access and defence evasion patterns.

Risk and Threat Considerations

Add-Type increases risk when organisations assume PowerShell is constrained by text-based inspection or script policy alone. Dynamically compiled code can hide functionality, expand runtime capability, and make malicious activity look like routine automation until deeper telemetry is reviewed.

Failure mechanism: An attacker or insider uses Add-Type to introduce compiled logic or load code that bypasses simple script review, extends the session’s capabilities, or enables native API calls that support stealth, persistence, or additional execution paths.

Impact: The result can be deeper host compromise, harder detection, broader post-exploitation capability, and a larger investigation scope because the effective behaviour of the session may not be obvious from the PowerShell text alone.

Practitioner Guidance

Why practitioners should care: Treat Add-Type as a capability that deserves explicit approval in high-trust environments, not as an incidental scripting convenience. If it is needed for legitimate automation, define where it is permitted, what sources it may compile or load, and how its use is monitored.

What to watch for: Review PowerShell activity that suddenly introduces inline C#, loads unusual assemblies, or appears to pivot from ordinary administration into custom runtime behaviour. Those patterns often deserve closer triage than standard cmdlet usage.

Practitioner takeaway: The key question is not whether Add-Type is allowed in principle, but whether your environment can still see, govern, and explain what that dynamically added code is doing.

Related resources from NHI Mgmt Group

• When do passkeys reduce risk, and when do they just add another credential type?
• When should organisations add continuous controls for AI agents?
• When does an independent control layer add more value than native controls?
• When should organisations add risk signals to cryptographic authorization flows?