What might get borked if I apply this "no language" tweak, besides powershell becoming useless?
How do you secure PowerShell?
- Thread starter Andy Ful
- Start date
The associated guide may contain user-generated or external content.
Everything that uses PowerShell.
It is like running applications in Comodo Sandbox with Untrusted setting (most restrictive).
Edit.
NoLanguage also uses System.Management.Automation
Last edited:
I found out that information included in 'Group Policy Settings Reference for Windows and Windows Server'
Download Group Policy Settings Reference for Windows and Windows Server from Official Microsoft Download Center
is not quite correct for the 'disabling script execution' reg tweak:
[HKEY_LOCAL_MACHINE \Software\Policies\Microsoft\Windows\PowerShell]
"EnableScripts"=dword:00000000
From the above reference, the reg tweak should work for Windows 7+, but it works for Windows XP(SP3)+ with PowerShell 2.0+. Of course, that is also true for Windows 7+ because starting from Windows 7 all Windows versions have built-in PowerShell 2.0 or higher.
Post edited.
Download Group Policy Settings Reference for Windows and Windows Server from Official Microsoft Download Center
is not quite correct for the 'disabling script execution' reg tweak:
[HKEY_LOCAL_MACHINE \Software\Policies\Microsoft\Windows\PowerShell]
"EnableScripts"=dword:00000000
From the above reference, the reg tweak should work for Windows 7+, but it works for Windows XP(SP3)+ with PowerShell 2.0+. Of course, that is also true for Windows 7+ because starting from Windows 7 all Windows versions have built-in PowerShell 2.0 or higher.
Post edited.
Last edited:
I discovered another way to block powershell scripts.
In Creators Update, there is a bug with the rendering of non-Unicode scripts.
So if you change your system locale to a non-Roman character set, such as Hebrew, then powershell can't even get a path. It becomes pitifully useless.
In Creators Update, there is a bug with the rendering of non-Unicode scripts.
So if you change your system locale to a non-Roman character set, such as Hebrew, then powershell can't even get a path. It becomes pitifully useless.
That is how smart people exploit the problem to solve another one.
Edit.
Maybe it is not a bug, but the new Microsoft mitigation?
Last edited:
They say they are trying to fix it, so I guess it is a bug.That is how smart people exploit the problem to solve another one.
Edit.
Maybe it is not a bug, but the new Microsoft mitigation?
I think so. It is a long shot, but maybe the problem with your fonts is related to blocking untrusted fonts mitigation? It should not, but who knows?
D
Deleted member 178
Don't try to blindly block Powershell because it will replaces Cmd in the future.
Right roflIt's fun searching for the PowerShell infos - innit ?
It is so much fun that I would rather set "No Language" mode and risk borking the system. Clean installing the OS is a whole lot faster than finding PowerShell infos that make sense.
Not a long shot, in fact, I also thought like that, at first.
But after a lot of complaining on the microsoft forum, a company rep finally came on the forum and wrote like this:
The issue is a regression in GDI that affects legacy, non-Unicode apps. The bug is understood, and the owning team is working on a fix.
I did some tests with fake PowerShell executable known as 'p0wnedShell'. I compiled it including original System.Management.Automation.dll .
Tests were done with active default deny SRP to force ConstrainedLanguage mode. So, I copied original powershel.exe and custom made p0wnedShell.exe into whitelisted folder and run as standard user.
The Language mode solutions require original powershell.exe to work properly.
Tests were done with active default deny SRP to force ConstrainedLanguage mode. So, I copied original powershel.exe and custom made p0wnedShell.exe into whitelisted folder and run as standard user.
- The executable p0wnedShell.exe worked in FullLanguage mode, while powershell.exe worked in ConstrainedLanguage mode.
- Both executables respected Registry settings: ExecutionPolicy and EnableScripts.
The Language mode solutions require original powershell.exe to work properly.
Last edited:
It seems that NoLanguage mode trick with the profile.ps1, works for p0wnedShell too. So, my final conclusion must be corrected:
Antivirus scan for 7692e08b48d4d58d3160f4f87fec2bd60ee91ff36b8c8b0fd98c1414ab4cff79 at 2017-05-06 07:52:04 UTC - VirusTotal
AhnLab-V3..........................Malware/MSIl.MS16-032.C1616313....20170505
Kaspersky...........................HEUR:Exploit.MSIL.MS16-032.gen.....20170506
ZoneAlarm by Check Point.......HEUR:Exploit.MSIL.MS16-032.gen.....20170506
- ConstrainedLanguage mode related to active Default Deny SRP, can be forced only by original PowerShell executables.
- PowerShell Language mode is built into the System.Management.Automation.
- System.Management.Automation seems to be aware of the Registry settings (ExecutionPolicy, EnableScripts) and the commands included in profile.ps1 .
Antivirus scan for 7692e08b48d4d58d3160f4f87fec2bd60ee91ff36b8c8b0fd98c1414ab4cff79 at 2017-05-06 07:52:04 UTC - VirusTotal
AhnLab-V3..........................Malware/MSIl.MS16-032.C1616313....20170505
Kaspersky...........................HEUR:Exploit.MSIL.MS16-032.gen.....20170506
ZoneAlarm by Check Point.......HEUR:Exploit.MSIL.MS16-032.gen.....20170506
Last edited:
Yes, they do, so I run a removal script every day to make sure it stays that way. I use this:
Code:
takeown /f "%ProgramFiles%\WindowsPowerShell" /a /r /d y
icacls "%ProgramFiles%\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%ProgramFiles%\WindowsPowerShell" /s /q
takeown /f "%ProgramFiles(x86)%\WindowsPowerShell" /a /r /d y
icacls "%ProgramFiles(x86)%\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%ProgramFiles(x86)%\WindowsPowerShell" /s /q
takeown /f "%WinDir%\System32\WindowsPowerShell" /a /r /d y
icacls "%WinDir%\System32\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%WinDir%\System32\WindowsPowerShell" /s /q
takeown /f "%WinDir%\SysWOW64\WindowsPowerShell" /a /r /d y
icacls "%WinDir%\SysWOW64\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%WinDir%\SysWOW64\WindowsPowerShell" /s /qThe above cure is similar to blocking powershell.exe and powershell_ise.exe .
I am afraid that this does not remove PowerShell from the system, because of several instances of System.Management.Automation.dll outside 'WindowsPowerShell' folders. The PowerShell can still be executed from the memory or by the custom made executable.
PowerShell v6.1.0 preview 1 : PowerShell v6.1.0 preview 1 | Richard Siddaway's Blog
Published March 28, 2018
The first preview release of PowerShell v6.1 is available at PowerShell/PowerShell
There are a few breaking changes you should check out.
Most of the changes are minor engine updates and bug fixes.
There are no big new features in this preview release
Richard Siddaway blog: blogs.msmvps.com/RichardSiddaway/: Richard Siddaway's Blog
5
509322
I know all about Richard Siddaway's site.
People should not have to go to Richard's or Don Jones' or Michael F Robbins' websites or anywhere other than Microsoft's official documentation. But anyone who has any experience knows Microsoft's documentation is atrocious.
The best approach for me is using all sources of information and re-test them by myself.
You may also like...
-
Orion Malware Cleaner (OMC) - By Trident- Started by Trident
- Replies: 23
-
Easy Application Control on Windows- Started by Andy Ful
- Replies: 39
-
[Tutorial] Update Kaspersky when starting the system automatically
- Started by Guilhermesene
- Replies: 9
-
How to Get Rid of “Managed by Your Organization” in Chrome- Started by lokamoka820
- Replies: 7
