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.


Presentation: Digital Evidence and the Information Security Manager

I had the pleasure of addressing a seminar related to forensic readiness yesterday to a co-located meeting of three Brisbane professional groups:

Thanks to the attendees for their high degree of participation – it always makes for a lively and engaging time when the audience share their experiences and questions.

Digital evidence and the information security managerUpdate: Typo fixed in slideshare link

View more presentations from blschatz.

Fraudulent email: lessons learned from the OzCar scandal

By now, all but the most naïve of us are immune to the promises of Nigerian riches and the disquieting urges to action from banks which find their way into our email inboxes. Fraudulent emails barely rate any action or consideration beyond that needed to delete them from our inbox. Why is it then that the leader of the Australian opposition, and one of Australia’s most senior lawyers besides, has been tripped up by a fake email?

Background

Australian media reporting has been dominated over the last week by the OzCar scandal. The scandal centres around claims that the Prime Minister (Kevin Rudd) has given preferential treatment to a friend and political donor, car dealer John Grant. Mr. Grant had previously given the Prime Minister a car for use in his campaign and contributed financially to his legal and political endeavours.

An apparent smoking gun in the form of an email was referred to in the senate testimony of Treasury official, Godwin Grech. Mr Grech recalled an email from the PM’s office in relation Mr. Grant and the OzCar financial bailout scheme, which Mr. Grech administered. The email was supposed to have been written by the PM’s economic adviser, Dr Andrew Charlton. The opposition leader seized on the email, calling for the PM to resign.

The PM responded by bringing in the Australian Federal Police (AFP) to investigate the email. On the Monday following Mr. Grech’s testimony, they executed a search warrant on Mr. Grech’s home, and very quickly released their preliminary investigation results. They had found the email in question sitting deleted on his computer. They concluded it was a hoax. Further reports have indicated that the email originated within Treasury.

Mr. Turnbull spent the rest of the week defending both his reliance on the fake email, and  claims that the scandal had been orchestrated. He has since suffered a large fall in public satisfaction, as revealed by today’s poll results.

On email authenticity

This matter highlights the need for a greater degree of scepticism when it comes to reliance on email evidence, as compared with its paper counterpart. Modification of text on paper leaves a trace, whereas the substance of email is modifiable without an obvious trace. Hand written signatures go a long way towards authenticating the author of mail; the email equivalent of a signature is technically possible, however its use remains a niche practice.

Email authentication requires additional corroborating evidence and technical expertise. Metadata hidden within an email can indicate, among other things, the path that the email has taken from the sender to the recipient. This data is typically stored with the email, and can be used to detect tampering or outright forgery of emails.

Each server that an email passes through usually makes a note of the receipt and handoff of the email to the next carrier along the way. Multiple copies of the email may additionally be stored in the senders “Sent Items” folder and in archival or disaster recovery backups. Such information can be used to identify which computer an email originally came from.

Gaining access to these evidence sources is time consuming and often involves the cooperation of multiple parties. Determining authenticity based on such evidence then requires a high degree of expertise.

Commentary

It is unlikely that either Mr. Grech or Mr. Turnbull would have had access to the corroborating evidence or possess the expertise required to judge the authenticity of the email. Nor for that matter would the average email user.

Day to day though, email authenticity isn’t a problem. Our society largely manages to muddle along with email as one of our primary communications mediums. The reason it works is that each of us make decisions of trust around every email we receive.

Assuming neither Mr. Grech nor Mr. Turnbull fabricated the email, whoever inside Treasury created and sent the email to Mr. Grech relied on exploiting his trust of emails appearing to come from that source. It appears that Mr. Turnbull trusted Mr. Grech in turn.

This affair may mark the end of this kind of trust in emails as concrete evidence and the general acceptance of their authenticity. Certainly you would think so in the case of politicians attempting to score points against their opponents.

More generally though, the wider implications of the increased awareness of the vulnerability of email to fraud will be felt in our courts, where emails are often cited as evidence in both criminal and civil matters.

As for the fake email which has brought all of this to the public’s attention, presumably the AFP are still investigating who the original concocter of the email was. This investigation should lead to an examination of the computer systems of Treasury, where traces of the email, and hence clues to the original concoctor of the email may well remain. In which case, we wait with bated breath to see the next twist in this political drama.


Macintosh Forensic Acquisition

Recently the Mac OS X Forensics site has been amassing a wealth of information on acquiring and analysing Macintosh OS X computers. Additionally, the “Inside the Core” podcast has made a strong start at presenting similar and related content as a podcast. Both teams deserve congratulations and encouragement for their contributions.

One problem that I have observed with acquiring Macs is a particular problem with some Apple keyboards that have a brushed aluminium appearance. They will not reliably allow one to boot to CD or target mode using option keys, due to (purportedly) a firmware bug. The result of this can be an unplanned booting of the hard disk in the computer, and resulting modification of the state of the disk.

I haven’t observed this problem with any other Apple keyboards. Forensic practitioners may want to consider making it a part of your practice to ensure that you are booting with a non aluminium keyboard.


Paper on new evidence container format accepted for presentation at DFRWS2009

Michael Cohen, Simson Garfinkel and I have been collaborating recently on the development of a new digital evidence storage container format. Today we have had notification that a paper detailing the research behind this development has been accepted at the 2009 Digital Forensics Research Workshop, to be held in Montreal Canada. The title of the paper is “Extending the Advanced Forensic Format to accommodate Multiple Data Sources, Logical Evidence, Arbitrary Information and Forensic
Workflow”.

A new evidence container is sorely needed by the computer forensics community, due to the large amount of manual work currently required in managing evidence and the closed nature of the current generation of forensic containers and tools. With this new forensic container, we provide an open and extensible container standard which promotes forensic tool interoperability and simplifies evidence sharing and management.

Technically, this new container achieves these things by enabling:

  • efficient random access storage of multiple streams of digital evidence within a single container;
  • storage of arbitrary information such as case relevant information or tool derived analysis results;
  • composition of evidence containers into a larger corpus of related evidence through an inter container referencing scheme;
  • decomposition of evidence containers into sets of smaller containers to support filesystem limitations;
  • definition of virtual evidence streams as maps of existing evidence streams.

The new format is slated to replace the current generation of Simson’s Advanced Forensic Format (AFF) and will be known as AFF4. Michael has been providing some documentation on the format over at the forensicswiki, and he has a beta quality implementation in the C language. Plans are in place for a JAVA based parallel implementation.

The abstract follows:

Forensic analysis requires the acquisition and management of many different types of evidence, including individual disk drives, RAID sets, network packets, memory images, and extracted files. Often the same evidence is reviewed by several different tools or examiners in different locations. We propose a backwards-compatible evolutionary redesign of the Advanced Forensic Format—an open, extensible file format for storing and sharing of evidence, arbitrary case related information and analysis results among different tools. The new specification was designed to be simple to implement, allowing the use of the well
supported Zip File format specifications for bit level file access.

UPDATE: The paper is now published on the DFRWS 2009 website.


dd2vmdk relocated into the cloud

A while ago I wrote a tool to convert flat disk images (which we commonly call dd images) to VMWare .vmdk disk images (the original blog post on the tool, called dd2vmdk is posted here). I have in the mean time ceased development of it, but despite its relatively archaic nature, some still find it of use.

Today I relocated hosting of it to Google’s new cloud web application service, Google App Engine. My motivations to do this were to reduce adminitrative burden, to eliminate server costs, and to increase long term availability (the Java App Engine is Beta, so there might be some short term availability issues).

The relocation took roughly one hour of my time, was dead simple, and required no code modification, just the simple addition of a new text configuration file.

dd2vmdk is still available via my personal website.


Schatz Forensic launched

Since March I have returned to practicing under my own banner. I have taken this opportunity to change the name of my company to Schatz Forensic, to better reflect the focus of the business and the personal nature of the services that I offer. Schatz Forensic is now operating out of premesis in the Brisbane CBD, and continues to offer the same computer forensics and electronic discovery services that I have provided in the past.


libewf has relocated

This won’t be news to many, but I came across a colleague today who didn’t realise that the libewf project has moved home to sourceforge.

Libewf is the only open source implementation of the Expert Witness Format (EWF) file format, which is the de facto standard for storage of forensic disk images. This open source implementation contains numerous utilities, including a faster than LinEn, UNIX based, command line EWF acquisition program, ewfacquire, and a command line validation utility called ewfverify. This latter tool I have found extremely useful in automating the evidence preservation process.

Related news is that Joachim Metz, the creator of libewf has recently released libpff, an open source implementation of the Outlook PST, OST and PAB file formats.


Stealth deployment of f-response Enterprise

In the last couple of days I have taken a few moments to familiarise myself with F-Response. The tool has been getting a lot of buzz lately amongst the forensic community, as it allows read-only raw access to the drives of remote computers, using one’s regular forensic toolset. Think encase enterprise at a lower price tag and open tool access.

For the more technical reader, it does this by setting up an iSCSI target on the remote (target, or suspects) computer.

The field kit and consultant edition of this tool require you to run a GUI agent on the target computer, which is not stealthy. The enterprise version of this tool however allows the agent to be run as a service.

Stealth Deployment
The supplied manual shows you how to install the enterprise agent using a combination of command line and GUI, but dosen’t go so far as to instruct how to do this remotely, via only the command line. This post is to document how I achieved this.

I note here that these instructions apply to a Windows Domain based setup, with firewall rules on workstations set to enable remote administration and file sharing from the investigation computer.

1. Open two windows command prompts. One is to be for work on the target machine and one on the investigation machine.

2. On the target machine command prompt, we first want to get a shell on the target computer, by using psexec, xcmd or other. I am logging in here as a user with Administrator priveleges:

C:Documents and Settingsbschatz>”c:Documents and SettingsbschatzDesktoptoolspsexec.exe” -u VINCENTSbschatz_admin \192.168.20.195 cmd

PsExec v1.94 – Execute processes remotely
Copyright (C) 2001-2008 Mark Russinovich
Sysinternals – www.sysinternals.com

Password:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:WINDOWSsystem32>mkdir f-response

3. Then in the same window, we make a directory to put the f-response agent and configuration file in.

C:WINDOWSsystem32>cd f-response

C:WINDOWSsystem32f-response>

4. On the investigator machine command prompt, we now want to copy the f-response agent and configuration file (f-response-ent.exe and NetUniKey.ini) over to the target machine, and into the directory we just created. Look out for escaping of quotes here:

C:WINDOWSsystem32>runas /user:VINCENTSbschatz_admin “xcopy “c:Program Files (x86)F-ResponseF-Response Enterprise Edition”* \192.168.20.195c$windowssystem32f-response /e /s /v /y /i”

5. Back in the target machine command prompt, we (in order of commands below) first install the f-response agent as a service, start the service, and finally, assuming that your clients firewall rules prevent connection to the f-response iSCSI target, open the windows firewall on that port:

C:WINDOWSsystem32f-response>f-response-ent -c

C:WINDOWSsystem32f-response>net start “F-Response Enterprise Service”
The F-Response Enterprise Service service is starting.
The F-Response Enterprise Service service was started successfully.

C:WINDOWSsystem32f-response>netsh firewall set portopening protocol=TCP port=3260 name=iSCSI mode=ENABLE profile=DOMAIN
Ok.

6. At this point the regular connection to f-response may be performed.

When you are done
How to undo the above?

C:WINDOWSsystem32f-response>netsh firewall delete portopening protocol=TCP port=3260
Ok.

C:WINDOWSsystem32f-response>net stop “F-Response Enterprise Service”
The F-Response Enterprise Service service is stopping.
The F-Response Enterprise Service service was stopped successfully.

C:WINDOWSsystem32f-response>f-response-ent -d

C:WINDOWSsystem32f-response>del *.*

C:WINDOWSsystem32f-response>cd ..

C:WINDOWSsystem32>rmdir f-response


Ph.D. Thesis Published

My Ph.D. thesis was accepted by my university a while ago. A result of this is that my thesis is now publically available at the Australian Digital Thesis project. The citation for the thesis is reproduced below.

This thesis addresses problems related to the complexity and volume of evidence drawn from computers and other digital devices (so-called digital evidence) in policing and legal matters. The research identifies methods for increasing the efficiency and reliability of investigations employing digital evidence, by proposing automated methods of processing and documenting such information. The research examined at a fundamental level the role of representation in interpreting and analysing digital evidence, identifying where a formal approach to representing digital investigations and digital evidence reduces the complexity and volume problems. A formal approach was shown to be of benefit in automating the identification of situations of interest from correlated event records sourced from computer security and other disparate event logs. Additionally a formal approach was shown to facilitate granular sharing of evidence and extensible documentation of investigations. Finally, the research identified flaws in the fundamental assumptions in the interpretation of time-stamped evidence, and proposed a novel method of inferring the temporal behaviour of arbitrary computers.

Many thanks to my Ph.D. supervisory team: Ajd. Prof. George Mohay, Dr. Andrew Clark, and Dr. Peter Best. Your support and encouragement have been instrumental in directing my research to this conclusion. Finally, thanks to my thesis examiners for their valued criticism and recommendations.