3 years ago a friend of mine asked me about how to enhance FCIV.exe utility functionality with PowerShell. Microsoft is not developing this tool anymore and you have to write your own tools or wrappers for fciv.exe to get required functionality.

I decided to write completely new tool from scratch by using only native PowerShell code. First version of PsFCIV was released about 3 years ago only for Russian-language audience. However there are many requests from English-language visitors. For example, users request new hashing algorithm support (SHA2 family) and other checking options, like file size and last modification timestamp checking. I made a lot of performance and reliability improvements, so new version works much faster than PsFCIV 1.0. Also I added support for SHA2 hashing algorithms. As the result, I was able to release a new updated PsFCIV 2.0 tool on TechNet Gallery:

Hello folks, CryptoGuy is here again. Today I’ll talk about the most common ways to violate default SRP configurations and how to protect SRP against them.

System folders with write access

It is generally correct that regular users haven’t write permissions on system folders and we can safely allow to run any program from these folders (C:\Windows). However this statement is not fully correct. This is because there are folders where regular users have write and execute permissions. There are at least two default folders:

1. System temp folder: C:\Windows\Temp
2. Print spooler folder.

Here is a screenshot of Temp folder ACL:

Hello everyone! Last time I was busy on other stuff and haven’t enough time to continue the topic. Today I want to talk about SRP rule ordering and how rule conflicts are resolved.

When you define SRP rules, you may have 2 or more conflicting rules. For example, you have a rule that allows to run any software signed by a certain certificate. For some reasons you decided to block one or more specified applications that are signed by the allowed certificate. Or you have two path rules that points to the same file, but have opposite security levels. It is important to understand how SRP processes rules and decides resulting action (allowed or blocked).

Multiple policies

The first thing we should learn is how multiple policies are applied. As you already know (at least, I assume that you know, because you have to know this), in a domain environments you can define multiple policies at various levels. Normally, such policies are applied by following the following sequence: LSDOU (local, site, domain and GPO linked to an OU). The latest policy object applied becomes effective. However this is not true for SRP. When you look at RSOP (Resultant Set Of Policies) for other settings (for example, account lockout settings), you can see which policy wins:

Today we will talk about rule types, their characteristics and some best practices.

When we open Additional Rules section, we will see two predefined rules:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

They doesn’t look as usual path rules, instead they refer to registry keys. If you open Regedit and check these keys you will see that registry key values contains corresponding folders paths: C:\Windows and C:\Program Files. This means that SRP can read file paths from registry keys and values. In the default state, SRP allows to run anything that is stored in system folders and anything from other folders (say, from user profile) is prevented. In most cases it is enough. However, certain business applications are not installed in the default program folders (C:\Program Files). for example, they can be installed in the system drive root, different drive or in the network folder. As the result, you may have to create additional rules.

In previous post I gave a short intro to Software Restriction Policies (SRP) and today we will talk about basic principles and management UI.

As already said, SRP is a whitelisting technology, therefore it works under the following principle: you are not allowed to run (launch) anything that is not explicitly allowed. Although, SRP can work in blacklist mode, it is not so efficient as in a whitelist mode.

How to launch SRP console?

SRP is a part of group policy and is configured by the Group Policy Editor. In order to launch SRP on a standalone machine, run the following:

• Start –> Run… –> type”secpol.msc”

to edit SRP in a domain environment, do the following: