Antimalware Scan Interface

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).

from Microsoft:
The Antimalware Scan Interface (AMSI) is a generic interface standard that allows applications and services to integrate with any antimalware product present on a machine. It provides enhanced malware protection for users and their data, applications, and workloads.

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. (

Subject Alternative Name Missing

In the latest version of Google chrome (58 but maybe even in 57), Chrome requires certificates to specify the host name(s) in the SubjectAltName field (SAN). Firefox latest update is following the same method. Values in the subject field will be ignored.

Certificates that rely on this deprecated behavior will now be rejected with:

The affected certificates are often locally generated ones for development purposes, or are part of a private PKI. The solution is to re-generate the certificates to include a Subject Alternative Name extension, or to enable an option in Chrome to allow them.

Support for commonName matching in Certificates

Group Policy reset in Windows Server 2012 R2

By using group policy settings, sometimes you may experience issues on servers and desktops, and there are some cases in which you have to reset the local policy of a server.

  • registry corruption
  • policy file corruption
  • just cannot update group policy and you want to give a try

How to do it (applies to Windows Server 2012 R2) *

  1. Run this command:
    secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose
  2. Delete the registry.pol file:
    del c:\windows\system32\grouppolicy\machine\registry.pol
  3. Restart the Server

In case you have issues with firewall configuration pushed by Group Policy you should delete the key


from the registry first.

Source 1

Source 2