New-Object blocked on some Constrained hosts but not others

Hi all,

I have a PowerShell script that is being distributed by Intune to a number of PCs. The script basically creates a shortcut using the commands:

$WshShell = New-Object -comObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut("$($env:APPDATA)\Microsoft\Windows\Start Menu\Programs\Startup\Word_Main_Template.lnk")
$Shortcut.TargetPath = "$($PSHOME)\powershell.exe"
$Shortcut.Arguments = "-ExecutionPolicy Bypass -WindowStyle Hidden -File `"$($scriptFolder)\$($copyScriptName)`""

The script also dumps a log file using the Start-Transcript/Stop-Transcript command pair.

All PCs are configured to be in Constrained Language mode as per the transcript output:

Language mode: ConstrainedLanguage

On most PCs (>100) the script executes without issues but on some (<10) I get the following error when executing the New-Object command:

PS>TerminatingError(New-Object): "Cannot create type. Only core types are supported in this language mode."

I have verified that all PCs are running the same versions of Windows (Microsoft Windows NT 10.0.19044.0), PowerShell (5.1.19041.2673) etc by comparing the transcript output.

Can anyone suggest a reason why I would be seeing this error?

Thanks :slight_smile:

Maybe Applocker ??

Thanks Tony. We don’t run Applocker but we do run AirLock :slight_smile: I checked the AirLock logs and nothing for the hosts having issues.

I’m not sure it should work at all.

They are blocked according to this.

What does Constrained Language constrain?

Constrained Language consists of a number of restrictions that limit unconstrained code execution on a locked-down system. These restrictions are:

  • PowerShell module script files must explicitly export functions by name without the use of wildcard characters. This is to prevent inadvertently exposing powerful helper function not meant to be used publicly.
  • PowerShell module manifest files must explicitly export functions by name without the use of wildcards. Again, to prevent inadvertent exposure of functions.
  • COM objects are blocked. They can expose Win32 APIs that have likely never been rigorously hardened as part of an attack surface.
1 Like

Ok - that’s strange. Just tried the same on my PC (Constrained mode) and got the following:

PS C:\> $ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"
Cannot set property. Property setting is supported only on core types in this language mode.
At line:1 char:1
+ $ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : PropertySetterNotSupportedInConstrainedLanguage

PS C:\> $ExecutionContext.SessionState.LanguageMode
PS C:\> $obj = New-Object -comObject WScript.Shell
PS C:\>

Tried these same commands on a PC that is in FullLanguage mode and got the same result as Doug.

Not sure what you’re trying to say. It works fine in FullLanguage mode, but it’s blocked in ConstrainedLanguage

Sorry, I wasn’t clear.

It actually works on my PC which is in Constrained mode. ie: I don’t get an error when using the New-Object command.

I do however, get an error when running the New-Object command on a PC which is normally in FullLanguage mode that has been placed in Constrained mode using the command:

$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage