Was the firewall blocking traffic? Identifying active firewall rules using registry analysis.

I came across this question recently in relation to claims that access to a Windows 8 host via Windows Remote Desktop Protocol was blocked by the firewall configuration. This post describes my research into the registry artefacts related to answering the question, and provides a patch to RegRipper to assist in analysis.

Theory of operation

Windows 8 uses the same firewall configuration entries used by Windows 7. Windows ships with a number of firewall rules enabled, and these may be added to or modified by the user, for example using the windows firewall control panel applet.

image

Rules are scoped by Profile, which is either Public, Private, or Domain. Note that I am going to refer to these are a “Network Category” herein, for reasons that will become apparent. These Network Categories (profiles) are associated with particular networks: for example, in the window capture below you can see that my home wireless connection is a “Private network”. For a “Private Network”, firewall rules with a value of “Private” will be applied.

image

The firewall rules are stored in the registry at HKLM\System\CurrentlControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules\.

image

The value of the rule above for “RemoteDesktop-UserMode-In-TCP” is

v2.20|Action=Allow|Active=FALSE|Dir=In|Protocol=6|Profile=Public|LPort=3389|App=%SystemRoot%\system32\svchost.exe|Svc=termservice|Name=@FirewallAPI.dll,-28775|Desc=@FirewallAPI.dll,-28756|EmbedCtxt=@FirewallAPI.dll,-28752|

Comparing this the applet above, we can see that this corresponds to the disabled RemoteDesktop-UserMode-In-TCP rule. Looking for the second TCP related RDP, I found the following rule with the key name “{6AFE835E-629E-48DA-A87E-AB6C367D2BB7}”, which corresponds to the similar rule that is enabled for both Private and Domain.

v2.20|Action=Allow|Active=TRUE|Dir=In|Protocol=6|Profile=Domain|Profile=Private|LPort=3389|App=%SystemRoot%\\system32\\svchost.exe|Svc=termservice|Name=@FirewallAPI.dll,-28775|Desc=@FirewallAPI.dll,-28756|EmbedCtxt=@FirewallAPI.dll,-28752|

Observation: Identifying the Category

Existing theory around mapping active networks from the registry is generally accepted: network profiles are stored in HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\. The RegRipper networklist plugin interprets the contents of this registry sub tree.

What my review of the current literature didn’t reveal is how to identify whether a Network Profile is configured as “Private”, “Public”, or “Domain”. Hence, I started looking for automated ways configuring a network in such a manner, from which I hoped to identify the relevant registry keys.

The  documentation for the PowerShell “Set-NetConnectionProfile” command lists the following parameters for the “-NetworkCategory” arguments:

Specifies an array of category types of a network. You cannot set the DomainAuthenticated type by using this cmdlet. The server automatically sets the value of DomainAuthenticated when the network is authenticated to a domain controller. The acceptable values for this parameter are:
– Public
– Private

I opened up powershell and issued the following command.

PS C:\Users\bradley.SCHATZFORENSIC> Set-NetConnectionProfile -interfacealias “WiFi 3″ -NetworkCategory Public

On running this, we see the Network and Sharing Centre applet immediately updated to indicate that the network was now a Public Network.

image

Examination of the associated profile shows a registry key called Category. Based on the naming of the powershell argument “NetworkCategory”, I hypothesised that the Category key might contain the value of relevance. In this instance it was set to a value of 0.

image

I opened then issued the following command.

PS C:\Users\bradley.SCHATZFORENSIC> Set-NetConnectionProfile -interfacealias “WiFi 3″ –NetworkCategory Private

On running this, I saw the Network and Sharing Centre applet immediately update to indicate that the network was now a Private Network.

image

Refreshing the registry viewer, the value of the Category key was now 1.

image

I undertook the above for three iterations and observed the same changes every time. I additionally attempted to undertake a Remote Desktop session while both settings were in place. The outcomes were consistent with the description of the above Firewall Rules. When the network was configured as private, I was unable to establish a connection, and when it was configured as public, I was able to establish a Remote Desktop session.

Hypothesis formulation

At this point my hypothesis was that the value of the Category key corresponded to the Network Category of a network profile. That is:

0 == Public

1 == Private

Of course, this hypothesis could be wrong: what if what I was observing was just one of many configurations occurring as a result of the powershell command?

Accordingly, I undertook an experiment to confirm both these interpretations of the values, and their application of the corresponding firewall rules.

Testing

I manually edited only the Category key of corresponding Network Profile and set it to 0. I restarted the Windows Firewall Service, at which point, I saw the Network and Sharing Centre applet immediately update to indicate that the network was now a Public Network. I attempted to establish a Remote Desktop session, which failed.

I then manually edited the Category key and set it to 1. I restarted the Windows Firewall Service, at which point, I saw the Network and Sharing Centre applet immediately update to indicate that the network was now a Private Network. I attempted to establish a Remote Desktop session, which succeeded.

I undertook the preceding experiment 3 times and received the same result each time.

 

Automation

I modified the networklist.pl plugin of RegRipper to interpret the Category key per the above theory. A third value of the “Category” key was observed: the value of 2. Based on context in which it came up I have inferred that it refers to a Network Category of Domain. I have not tested this.

Conclusions

I didn’t undertake an exhaustive literature review in regard to the above research, so it may well be that this registry artefact has already been treated elsewhere. Please do let me know if I have missed any prior work that you are aware of.

The updated networklist.pl script is currently in my GitHub branch of RegRipper.

I encourage you to validate this new version of networklist.pl against your own registry and let me know if it is consistent with your running configuration, or not.

 

UPDATE: Harlan Carvey has merged this patch into the main RegRipper development tree at GitHub.