If you are planning to Disable SMBv1 with Group Policy, Microsoft has made it even easier for you. In the latest Security Baseline,“Creators Update” (v1703), Microsoft released “MS Security Guide” ADMX template, with which you can configure SMBv1 for Client and Server, via Group Policy. In order to set it to work, copy SecGuide.admx into your Central Store PolicyDefinitions directory, and SecGuide.adml into the en-us subdirectory.
Warning: Do not disable SMBv1 if you are using old OS, like Windows XP and Windows 2003 in your environment (If you are using those old and expired OS, you are not secure anyway!).
Read Microsoft’s article for Disabling SMBv1 through Group Policy , before changing anything and please notice the BIG warning about the Configure SMBv1 client extra setting, WARNING: DO NOT SELECT THE “DISABLED” RADIO BUTTON UNDER ANY CIRCUMSTANCES!
SMBv1 is very old, almost 30 years old and is used only by old OS, Windows XP / Windows Server 2000 and older. Since Windows Vista / Windows Server 2008, Microsoft introduced SMB 2.0 version and then SMB 2.1 with Windows 7 / Windows Server 2008 R2. With Windows 8 / Windows Server 2012 SMB 3.0 made its appearance and then SMB 3.0.2 in Windows 8.1 / Windows Server 2012 R2. The latest version of SMB is SMB 3.1.1, which was introduced with Windows 10 and Windows Server 2016.
SMBv1 is not secure at all and even its owner, Ned Pyle, is begging you to stop using it in his article, Stop using SMB1
PowerShell Execution Policy can be used as a control policy, to protect the administrators, or even the users, from accidental script execution. Do not think of it as a security measure, because it will not protect you from copy/paste the content of any script in the command line or run each script command by hand.
The Get-ExecutionPolicy cmdlet will show you the current policy on the machine and you can change the policy with the Set-ExecutionPolicy cmdlet and choose one of the following execution policies:
Restricted: No scripts can be run. Windows PowerShell can be used only in interactive mode.
AllSigned: Only scripts signed by a trusted publisher can be run.
RemoteSigned: Downloaded scripts must be signed by a trusted publisher before they can be run.
Unrestricted: No restrictions; all Windows PowerShell scripts can be run with a confirmation prompt.
Bypass: No restrictions, all Windows PowerShell scripts can be run
You can set the execution policy across your domain, using group policy. Create a new group policy (or add to an existing one), expand Computer Configuration\Policies\Administrative Templates\ Windows Components\Windows PowerShell and edit the Turn on Script Execution policy.
The recommended policies for a controlled enterprise environment, are AllSigned or RemoteSigned. In case you set the Execution Policy to one of these policies, you need to sign PowerShell scripts, in order for things to run smooth.
In this article I will describe the full procedure with all the steps, to sign PowerShell scripts in your environment, assuming that you have at least a domain controller in your environment and a Public Key Infrastructure (PKI).
Step 1. First we need to create the code signing certificate template, which we will enable on the Issuing Certificate Server.
On your CA Issuing server, open Certificate Authority tool, right click on Certificate Templates container and select Manage
Locate the Code Signing template in the Certificate Templates Console and right click, Duplicate Template
Set the properties of the new template, according to your environment. Below are the settings of my Code Signing template on my test environment. Leave the rest properties on default settings if you are not sure what to change. Notice the Security tab, I have allowed enroll permission for the PKI_Enroll_redmad.com_Code_Sign_24M security group (this is a global security group created in the AD, which its members will be authorized to enroll for a code sign certificate)
Close the Certificate Templates Console. In the Certificate Authority Tool, right click on the Certificate Templates, once again and select New-Certificate Template To Issue
In the Enable Certificate Templates window, select the template we have just created and click ok
Step 2. Add your users in the members of the group with certificate enrollment permission
The group I created above is PKI_Enroll_redmad.com_CodeSign_24M, which will be able to sign PowerShell scripts. I will add my user espresso
Step 3. Request a code signing certificate from the Issuing CA
Login with the user who is member of the above group and request the certificate
Open Microsoft Management Console (mmc.exe), and go to File – Add/Remove Snap-in… Select Certificate from the Available snap-ins, click Add and select My user account, to open the store of the current user. Click ok
Go to the Personal Container and right click, All Tasks, Request New Certificate
Next, Select Active Directory Enrollment Policy and Next. A List with the available certificate templates will appear. Select the one we created above and click Enroll (If you do not see the certificate template we created, logoff and logon again)
You should see STATUS: Succeeded
Click Finish. In the Personal container you should now see the certificate to sign PowerShell scripts.
Step 4. Deploy the code signing certificate in the Trusted Publishers Store
Export the code signing certificate
You will export only the public part of the certificate (not the private)
In the file format, choose Base-64 encoded (or DER)
Specify the file name of the file you want to export, Next, Finish
Open Group Policy Management to create a new policy object, to deploy the code signing certificate across your domain
Name the new policy
And then edit the policy and expand Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Trusted Publishers, Right click on Trusted Publishers and select Import
Certificate Import Wizard will pop up, click Next and locate the certificate you exported
Continue, with Next, notice that the wizard will place the selected certificate in the Trusted Publishers
Make sure that group policy object you made previously, is applied on the machine you are logged on (also on the machines you are going to run the signed PowerShell scripts) run gpupdate /force to enforce the policy settings
So, now we have the certificate to sign PowerShell Scripts and also we trust this certificate as a Publisher.
STEP 5. Signing the script
I will use the following script version.ps1
For signing the certificate, we will use the Set-AuthenticodeSignature cmdlet
First we need to save the code signing certificate in a variable
Then sign the script
You can now check your script ans see it is signed
Your script is now signed. Repeat Step 5 for all your scripts.
PowerShell version 5.0 and later includes a low-level programming API designed just for anti-malware scanners. The AntiMalware Scan Interface (AMSI) allows AMSI capable scanners to examine PowerShell code, even when the code is Base64-encoded. AMSI works also with WSCRIPT executables (VBScript, Jscript).
I have tested a script on Windows 10 machine with Windows Defender (AMSI capable scanner) enabled and as you can see below, it won’t run:
I have tested the same script on a Windows 10 machine with a non AMSI capable scanner (Windows Defender disabled) and it doesn’t block the “malicious” code:
Note: In order to benefit from the AMSI capable scanner, you need of course PowerShell version 5.0 or later, which is the default version for Windows 10 and Windows Server 2016. PowerShell version 5.0 and 5.1 is available for Windows Server 2012 R2, Windows Server 2012, Windows server 2008 R2 SP1, Windows 8.1 and Windows 7 SP1 and should be installed, since there are security enhancements, JEA (Just enough admin) support, new cmdlets, etc. (https://msdn.microsoft.com/en-us/powershell/wmf/5.1/release-notes).