How the Constrained Language Mode is enforced

Underneath, PowerShell will create psm1 and ps1 files in AppData and prove if an AWL (application whitelisting) solution is running. It is going to be blocked from AppLocker, as AppLocker is up and running. Therefore, you will see these kinds of error in the EventLog, which are not errors at all. They just come up due to the validating mechanism. To provide better filtering for these false positives, the additional keyword __PSSCRIPTPOLICYTEST_ is added to the specific files:

After these two files have been blocked, the PowerShell session will open in ConstrainedLanguageMode. This means that if this path is excluded from the rules for specific users, they would be able to start an interactive PowerShell session in full language mode, as this mechanism would be avoided. Therefore, you can create specific whitelisting rules and allow, for example, users from the administrators group to be able to start an interactive session in FullLanguageMode. Some people argue that there are many administrators out there and they also need to be controlled. If you giving any user elevated rights, they are actually capable of accomplishing almost anything on your machine. AppLocker is working on the base of the Application Identity service (AppIDsvc) and an administrator could easily disable this service. An idea could also be to specify a dedicated group of the script developers to be able to write scripts interactively and be able to debug them. As you can see, the Principle of Least Privilege touches many topics.

Further on, we have still our problem with PowerShell version 2 on Windows 7 machines and the additional System.Management.Automation dlls. To get around this, you can specifically whitelist the use of the dlls you want to enable on your machines. The following lines of code retrieve the specific System.Management.Automation dlls for v2 and v4 (v4 will correlate to the latest PowerShell engine on the machine, which should be version 5.1, if you have updated it). You can now easily whitelist (or block) these dlls with AppLocker:

#v2 GAC MSIL 
powershell.exe -version 2 -noprofile -command "$(Get-Item ([PSObject].Assembly.Location)).VersionInfo"

#v2 Native
powershell.exe -version 2 -noprofile -command "(Get-Item $(Get-Process -id $pid -mo | Where-Object { $_.FileName -match 'System.Management.Automation.ni.dll' } | ForEach-Object { $_.FileName })).VersionInfo"

#v4 GAC MSIL
powershell.exe -noprofile -command "(Get-Item ([PSObject].Assembly.Location)).VersionInfo | Select *"

#v4 Native
powershell.exe -noprofile -command "(Get-Item $(Get-Process -id $pid -mo | Where-Object { $_.FileName -match 'System.Management.Automation.ni.dll' } | ForEach-Object { $_.FileName })).VersionInfo"
A dedicated blog article from Lee Holmes can be found at the following link: http://www.leeholmes.com/blog/2017/03/17/detecting-and-preventing-powershell-downgrade-attacks/.

In addition, Aaron Margosis just published his PowerShell scripts to establish whitelisting with AppLocker in an enterprise environment, which are named AaronLocker and are highly recommended: 

https://blogs.msdn.microsoft.com/aaron_margosis/2018/06/26/announcing-application-whitelisting-with-aaronlocker/.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.142.96.146