Einschränken Von Applikationen Mittels Verfügbarer Werkzeuge Für Windows Systeme

Einschränken von Applikationen mittels verfügbarer Werkzeuge für Windows Systeme

Conﬁning applications by using available tools for Windows Systems

Master Thesis

Submitted in partial fulﬁllment of the requirements for the degree of

Master of Science in Engineering

to the University of Applied Sciences FH Campus Wien Master Degree Program: IT-Security - Master

Author: Martin Vaclavik

Student identiﬁcation number: 1610537016

Supervisor: Priv.-Doz. Mag. DI. DI. Dr.techn. Karl Michael Göschka

Reviewer: (optional)

Date: May 11, 2018 Declaration of authorship:

I declare that this Master Thesis has been written by myself. I have not used any other than the listed sources, nor have I received any unauthorized help.

I hereby certify that I have not submitted this Master Thesis in any form (to a reviewer for assessment) either in Austria or abroad.

Furthermore, I assure that the (printed and electronic) copies I have submitted are iden- tical.

Date: May 11, 2018 Signature: Kurzfassung In dieser Arbeit geht es um Windows Filter Treiber und wie man mit diesen, Dateizugriffe Beschränken kann anhand von Prozess-ids. Mit dieser Technik soll der Schaden einer Infek- tion durch eine Ransomware Attacke verringert werden, indem unbekannten Prozessen nicht erlaubt wird auf bestimmte Dateien zu schreiben. Der Benutzer hat dabei die Möglichkeit mit der C# Applikation auszuwählen, welche Prozesse, Zugriff auf Dateien bekommen und welche nicht. Deswegen ist eine der Fragestellungen, wie eine Ransomware Attacke abläuft, ein Fokus dieser Arbeit. Dadurch, dass es immer mehr Ransomware Attacken gibt, steigt auch der IT-Security Fokus, bezüglich diesem Threat-Modell. Dies ist vor allem durch die große Anzahl an Sicherheitssystemen zu sehen, die sich um das Eliminieren von Ransomware kümmern sollen. Diese Ransomware Tools sind in den meisten Fällen "Blackboxes" und es ist nicht wirklich klar, wie diese Systeme tatsä chlich funktionieren. Dies ist die Motivation dieser Arbeit, um ein Open-Source System zu bauen, welches Nachvollziehbar arbeitet und mit dem der Schaden einer Ransomware Attacke verringert werden kann. Windows Filter Treiber bieten einem sehr viele Möglichkeiten an, um Ransomware Attacken zu erkennen und zu verhindern. Das Problem mit dem man bei Windows Filter Treibern am meisten zu kä mpfen hat, ist das ganze System dahinter zu verstehen, da es ein sehr komplexes System ist und es nicht viele Arbeiten zu diesem Thema gibt, außer der offiziellen Microsoft Doku- mentation. Deswegen ist auch ein sehr großer Fokus dieser Arbeit, zu verstehen wie Filter Treiber funktionieren und wie sie genutzt werden können, um den Zugriff auf Dateien zu beschränken. Filter Treiber haben bewiesen, dass sie für diesen Einsatzzweck gewappnet sind. Dateizugriffe konnten Anhand von Prozess-ids verhindert werden. Das einzige Problem mit dem man als Benutzer solch eines Systems zu kämpfen hat ist, dass der Computer in den "test mode" ge- bracht werden muss, damit ein Filter Treiber erfolgreich in das System eingebunden werden kann.

i Abstract This thesis focuses on Windows Filter Drivers and how they can be programmed to restrict IO access for specific process-ids. With this in mind the restriction should help prevent access to files by unknown programs that are running on the system. Preventing access to files is used to mitigate the damage of a ransomware attack, this means if a machine gets infected, the user needs to give permission to this process via the C# configurator tool to allow access to the restricted files. That is why a big part of this thesis focuses on how a ransomware attack starts and how it works in detail. Since the ransomware attacks are rather popular nowadays there are already a lot of solutions available, however many of these tools are complete blackboxes and it is not really anywhere documented how a malicious intent is actually found and restricted. Therefore the motivation of this thesis is to create an open source tool to mitigate the damage done by ransomware attacks. Windows filter drivers are a very powerful toolset and offer functionality that can help identify and or restrict malicious intent. The main problem with filter drivers despite how powerful they are is, that the theory behind it is complex and there are not many papers available about the windows filter driver framework, except for the official Microsoft documentation. This is one of the reasons why the biggest part of this thesis focuses on understanding how filter drivers work and how they can be used to restrict access to files. Filter Drivers have proven to be very effective for this kind of approach and successful filtering by process-id was achieved, with the only downfall being, that the machine must be set into the "test mode" to allow attaching the self signed filter drivers onto Windows.

ii Key Terms

ACL - Access Control Lists CAPTCHA - Completely Automated Public Turing test to tell Computers and Humans Apart CRG - Challenge Response Generator C&C - Command & Control DRBG - Deterministic Random Bit Generator DNS - Domain Name System DLL - Dynamic-link library GUI - Graphical User Interface HSM - Hierarchical storage management HTTPS - Hypertext Transfer Protocol Secure I/O - Input/Output IOCTL - Input and Output Control OS - Operating System PED - Policy Enforcement Driver PSI - Policy Speciﬁcation Interface SCSI - Small Computer System Interface SDK - Software Development Kit TCP - Transmission Control Protocol UEFI - Uniﬁed Extensible Firmware Interface USB - Universal Serial Bus WDK - Windows Driver Kit WDTF - Windows Driver Testing Framework WPF - Windows Presentation Foundation

iii Contents

1. Introduction1 1.1. Security introduction ...... 1 1.2. Ransomware infection ...... 4 1.3. Goal ...... 5

2. Available information gathering tools and protection suites6 2.1. Investigating OS activity via Sysinternal tools ...... 6 2.2. Windows Defender Ransomware protection ...... 10 2.3. Disallow the execution of applications with policies ...... 10 2.4. Applocker ...... 11

3. Windows Filter Driver 14 3.1. Microsoft Filter Driver Deﬁnition from Microsoft ...... 14 3.2. Introduction to the windows driver model ...... 14 3.3. Windows Filter Driver features and requirements ...... 16 3.4. Getting started with the Windows Driver Kit ...... 19 3.5. Alternatives to Windows Filter Drivers ...... 23

4. Building the Program 25 4.1. Preparing the System ...... 25 4.2. Choosing the right project type ...... 25 4.3. Preparing a computer for remote deployment and debugging ...... 26 4.4. Removing remote deployment and debugging from the computer ...... 28 4.5. Configuring the Driver Project ...... 28 4.6. The final application ...... 29 4.7. typical file write operation ...... 32 4.8. Blocking mechanisms ...... 34

5. Project Overview 36 5.1. Tests ...... 36 5.2. Problems ...... 36 5.3. Filter drivers critical view ...... 36 5.4. Common errors ...... 37 5.5. Related work ...... 38 5.6. Future work ...... 41 5.7. Conclusion ...... 42

Bibliography 43

List of Figures 47

List of Tables 48

Listings 49

iv A. Appendix 49

v 1. Introduction

Security is gaining more attention every day because of current threats and events in the computer universe. Many systems on which most devices rely on are using old technologies and mechanisms to protect itself from attackers. The best example are signature based protection mechanisms in antivirus suites, which are not sufficient enough for advanced threads or specially tailored attacks. Signature based mechanisms are still used very often which is fine if it is used with different solutions simultaneously. For specially tailored ransomware not many protection mechanisms exists, due to its dynamic structure. Many security solutions are either using sand boxing or automated code-analysis. In this thesis an approach will be used that tries to restrict the operations an application can do to a specific subset of files and folders, through the usage of Windows Filter Drivers which will be explained in detail later on. The main direction of the paper, is to build a system for Windows to allow higher restric- tions against special threats. The idea is to let the user of a system gain more control of the operating system(OS) and allow better protection by being restrictive with every unknown application. This protection mechanism is used to prevent ransomware attacks by disallowing read and write operations by unknown processes. Filtering the file access with filter drivers does not prevent the infection of the device for which there are already many tools available, but it offers the user a way to restrict access to specific files by whitelisting process-ids. To whitelist the processes the user will be presented with a C# application. This thesis is split into multiple chapters which should help us to understand what the issue is, what the current available security standards are and how this approach tries to achieve similar behaviour with filter drivers. Chapter 1 - Introduction Offers a quick dive into the security issues that are arising with ransomware and some tips to mitigate the risk and the impact of a successful ransomware attack. Chapter 2 - Available information gathering tools and protection suites Shows some available information gathering sources and some already finished products that offer similar functionality that should be achieved in this paper. Chapter 3 - Windows Filter Driver Offers a good overview over the whole Windows filter system as well as all information to deploy a filter driver. Chapter 4 - Building the Program Focuses on how the project structure looks like and how calls are filtered. Chapter 5 - Project Overview shows the outcome of the system and a critical look on the filter drivers interception, as well as related and future work.

1.1. Security introduction

The security industry is a very important field at the current age. With bot-nets and ransomware being constantly in the news, security experts are having difficulties protecting users against such a dynamic threat. Zero day exploits are also a big topic in the IT-Security field.

1 Chapter 1. Introduction

The fact that our systems are growing to such a complexity where most parts cannot be checked for bugs so easily does not help this fact. On top of that, there are many bugs which are still being discovered and exploited. To put this into perspective the NASA space shuttle ﬂight control computer has over 400 000 Lines of code and each software change undergoes heavy testing(15 Months). [Sic10] Even after such heavy precautions bugs can still be found in the software. Symantec statistics show an big increase in zero days as it can be seen from 2014 to 2015 in which it has risen by 125% to 54 zero days which were discovered in that year[Woo16]. Zero-days are just one side of the problem. Sophisticated attackers are ﬁnding new methods to attack legitimate users with targeted attacks. The big rising factor in the security scene are ransom-ware attacks which encrypt user data on the target computer and then demand compensation for the decryption of their data. The rise of cryptocurrencies helped ransomware gain such a high popularity because of the possibility for anonymous money transactions.

1.1.1. Threats

Attackers are always finding ways to attack systems with either zero day exploits or with smart approaches to either disable or fool an security mechanism. Security firms are always in a race with attackers to find better solutions for their clients and to extinguish possible threats. This is in no way an easy task, due to the availability of multiple attack vectors. To give a quick overview why having a secure system is not an easy task we have to consider multiple viewpoints. The first one is the amount of various devices present in a company. On top of that this is amplified by Internet of Things devices which are embedded in many smart consumer products like TVs, Coffee machines, Thermostat and many other household devices which are also getting smarter every day. Symantec and Gartner are expecting over 20.8 billion devices in 2020[Woo16]. With these devices we have a lot of potential hazards waiting to happen with many of these devices being vulnerable to simple attacks as shown with the mirai botnet[Ant17]. However there are many other attack points available, for example the OWASP Top 10 goes in a totally different direction of application vulnerabilities with the main focus on web applications OWASP Top 10. A completely other subset of security issues are pointed out by the Microsoft-Team on a network level Microsoft Security issues with IP. These are just a few viewpoints on this whole issue, but it shows perfectly how many threats there are in a real working environment, and there are many more! This should give a perfect understanding why no security company can guarantee a 100% failproof system.

1.1.2. Security products for ransomware

There are many security consumer products available on the market, by some high tier security companies which are known to be pioneers in the security field. Here are some products that offer very good folder protection features to mitigate file encryption by ransomware: • Windows Defender: Controlled folder access • Bitdefender: Ransomware protection • Trend Micro Antivirus+ Security or Trend Micro RansomBuster: Folder Shield There are a lot of ransomware protection suites available, which makes sense since there is a lot of uproar due to attacks on a daily basis. Nonetheless ransomware programmers are getting smarter everyday and protecting folders is probably not enough to protect against upcoming trends.

2 Chapter 1. Introduction

1.1.3. Typical ransomware attack

The main focus of the efforts mentioned earlier is to mitigate ransomware attacks. This is achieved by limiting the read and write operations of a non whitelisted process. The classic ransomware focuses on encrypting personal data and only allowing decryption, by giving back the encryption key, if a ransom is paid. The attack begins with the attacker delivering the malicious code to the target. The usual ways are either through email or by visiting a website with malicious content. Then it needs to be executed on the host. After it was successfully executed the first thing the ransomware does is to inform the Command and Control server that it successfully breached the computer. Then the ransomware starts to encrypt the files with a key that was propagated from the Command & Control (C&C) server. After the computer has been taken over the user has the possibility to pay the ransom, to get the data back which can never be guaranteed to work [Meh15]. In this scenario there are a few possible protection mechanisms that should help against such an attack

Email spam checker

E-mails are a widespread form of communication that is why they are a very attractive way to spread malicious content. There are multiple ways to send out malicious content to a user. The most common ways are by either a malicious file that has scripting support like all office file types and pdf files or by malicious links that have malicious scripts embedded. The usual way to protect against this threat is to have a spam firewall that filters malicious content either by checking the signature or by using sandbox features [Meh15].

Javascript/Web threat blocker

Javascript is a very powerful scripting language and is needed for almost every web application on the Internet but it can also be misused for various attacks like cross site scripting. Cross site scripting can affect any website and it can be a big threat for a lot of users. Cross site scripting takes advantage of a vulnerable website to execute malicious content on a visiting user [Meh15]. On one hand web application firewalls are a good way to help protect against such an attack but with Hypertext Transfer Protocol Secure(HTTPS) the traffic needs to be passed through or intercepted by the firewall which on the other hand can be considered as a privacy violation from the users perspective [Meh15].

Malware scanner

If the precautions mentioned before did not work, most computers have another form of protection. To check ﬁles for malicious content and protect the operating system from intruders. This is especially an issue with zero days exploits that mostly slip through this undetected by being too new. The typical protection mechanisms are anti virus checkers or endpoint security suites that are managed by an authority [Meh15].

3 Chapter 1. Introduction

Network communication checker

Checking the network for malicious intent is complicated since there are so many protocols with so many features that it is almost impossible to test every packet in real time for anomalies. Nonetheless intercepting traﬃc is an important step to detect C&C activity in the network. Firewalls are used for this form of monitoring, also most host security suites have an equivalent feature as well [Meh15].

File protection

Protecting ﬁles from being encrypted is the last possible step to protect against a ransomware, without including backups which is important but wont help against the attack. This step wont help with the infection itself but it helps to mitigate the damage. The easiest way is to create protected folders that can only be accessed by whitelisted processes. This will be implemented and further investigated throughout this paper. Windows Defender is the most common tool for this kind of protection, however it is only available on Windows 10 systems. Since there is such a big market, there are various anti ransomware suites with similar features that are available for other operating systems as well[Meh15].

1.2. Ransomware infection

With all these protection mechanisms available, smart malicious content can still slip through all these prevention systems. Here are some tips on how to minimize impact of an attack and some general tips: Before 1. Perform regular backups of keyfiles or other important files. The backup-system should ideally not be incremental since an attacker could overwrite the wrong data to the backup storage. If the process is automated it should be regularly checked if it still works, this is especially relevant if there are major updates for the backup software. 2. Create a "golden image" of your system to which you can restore to, this approach minimizes the impact of an complete system wipe. 3. Keep your software up to date especially applications like adobe, office, flash or java where zero day exploits are very often found and are used by a large usergroup on a daily basis. 4. Disable scripting capabilities in applications like Adobe Reader and Office products. This makes it significantly harder for ransomware to activate. Javascript can also be blocked in your web browser with applications like "NoScript", this is only an option for advanced users. 5. Disable interpretation of punycode in your browser. Punycode allows the interpretation of unicode with ascii in weblinks. This means it is possible to create hyper-links that look like a link to the correct site, for example "google.at" but actually in the background, the link looks like this: "http://xn–ggle-55da.at/". As can be seen in this figure 1.1, visually there is not really a big difference. That is why it is important to disable interpretation of puny code in the browser as well as checking where the real link goes as it will be shown without the punycode on the website but the link is actually pointing to the real website link.

4 Chapter 1. Introduction

Figure 1.1.: Punycode example for fake google.at

6. Create two users for Windows, a normal and a superuser. Use the normal user without elevated privileges for daily usage. Most applications do not need elevated rights to function, it is mostly needed for updates or the installation of new software. This minimizes the impact a ransomware can have, by restricting it to the users space. After 1. Disconnect the computer from the network, in the best case shut it down completely, to either stop further encryption or infection spreading through the network. 2. Inform yourself about the ransomware that infected your computer. Some types of ransomware can be reversed, there are mostly identifiable by their design and or the text from the attacker. 3. To recover the data from the drive do not boot to the system. The best way to do this is to disconnect the hard drive from the system and either plug it into an external reader or directly mount the drive read only on another system. Read only systems can also help to mitigate tainting another system by mistake. 4. Try to find out how it happened to learn from the mistakes and to prevent another infection. This can be rather difficult in the home environment, but in enterprise infrastructures this is a must! [DFS16]

1.3. Goal

With ransomware being a big threat to many consumers the main focus of this paper is to create a mechanism that is able to lower the damage that can be done by a successful ransomware attack. To stop a ransomware from effectively destroying important data many factors need to be considered. The focus of this paper will be to restrict file io operations with Windows filter drivers to disallow newly created processes to read or write to specific files. This is the first big step on stopping the ransomware from a successful attack, but there are also other security fields that need to be hardened. Restricting network access on the host machine is also very important, but it will not be covered in this paper. As was already mentioned in chapter 1.1.2, there are already a lot of security products available on the market that offer similar features as the final program of this paper but the issue with these kind of products are either being fully closed source or not being available on all current Microsoft operating systems. With this project everything is open source and will be available to download in the appendix of this paper.

5 2. Available information gathering tools and protection suites

Collecting data from the system is a very important part to understand what is happening on the system. There are many applications which are already very good at collecting data and/or protecting a system. In this chapter the main focus will be to show which security tools are already available to download and which information can be gathered from the system.

2.1. Investigating OS activity via Sysinternal tools

The Process Explorer from sysinternals is a very powerful tool even without administrator rights, with this tool a lot of information can be extracted from a running process. This includes information like open connections which can be seen on ﬁgure 2.1. It can show the used Network protocol,the local and the remote address as well as the port. We can also see that even when just browsing to one site, in this case "microsoft.com" many ports will be opened and connections established. As can be seen in the picture there are only Transmission Control Protocol(TCP) connections open because it was used to browse a website which uses http/s via TCP to communicate. This shows that browsing one site can establish a lot of connections, from which some can be identiﬁed and some need to be further investigated to get the big picture on which site was really visited. From the users perspective it was just the Microsoft website but in the background a lot happened to deliver the website to the user. Therefore just investigating the network connections does not shed a lot of light on the actual situation and if a connection may be malicious or not. The process explorer shows another perspective. It displays information about a process. This includes the path of the executable with the start-up command and the auto-start location. It also shows if a process has a parent or more child processes. The Process Explorer is also able to show which Dynamic-link library(DLL)s are currently being used by the process. As can be seen in Figure 2.3 the process VboxTray is used which is an application from virtual box to provide tools for the virtual machine. VboxTray needs a lot of DLLs to work properly, which makes it problematic to pinpoint bad or unusual behaviour in a process. However due to the fact that every DLL has some kind of purpose, one can estimate what the application can actually do. Knowing that a process uses a DLL that can be used for malicious behaviour does not really make the process suspicious, therefore more information is needed to understand if it is used in a malicious context or not. With all the tools mentioned throughout this chapter none of them will be used for this paper but serve as an example to show what can be viewed from a users perspective with Sysinternal tools. The problem behind it that even though you are able to see much more information about a process it is still not enough to tell if it is malicious beyond reasonable doubt.

6 Chapter 2. Available information gathering tools and protection suites

Figure 2.1.: Sample output when browsing the microsoft.com website

7 Chapter 2. Available information gathering tools and protection suites

Figure 2.2.: Sample output from a Windows 8.1 System

8 Chapter 2. Available information gathering tools and protection suites

Figure 2.3.: Sample dll usage output from a VboxTray

9 Chapter 2. Available information gathering tools and protection suites

2.2. Windows Defender Ransomware protection

Windows Defender for Windows 10 offers very similar features that are "core features" of this paper. This feature is called "controlled folder access". With this feature, you are able to add restricted folders to windows defender, which can only be accessed by approved windows defender programs. With this feature only flagged application that are either malicious or suspicious are disallowed access, however false positives can be whitelisted to allow the access to these protected folders. This means it is not possible to use a "block all" rule that only allows access to whitelisted processes. The next downfall is that this feature is only available for Windows 10 version 1709, this means that Windows 7 and 8 is not supported and probably will never get this feature. Secondly it is not completely clear how this blocking works and what exactly is blocked from these requests. This is a rather important question for information leakage for example, if the program itself knows if the file even exists or if it is handled like an access violation. Without criticizing too much it is still a good software product, that allows such an easy to use restrictable file/folder access and therefore probably the easiest way to restrict folder/file access, especially for Windows 10 users.

2.2.1. Enabling Windows Defender Ransomware protection

To restrict file access, firstly this feature has to be enabled since it is disabled by default in Windows Defender. Go to the Windows Defender Security Center and go to "Virus & threat protection settings" and enable "Controlled folder access". Then just go to the Protected folders setting and add the folders that should be protected by this mechanism. Windows defender uses its own security mechanisms to determine if a request should be blocked or not, in some cases false positives will happen, therefore specific apps can be whitelisted if they have been wrongfully blocked from accessing a resource.

2.3. Disallow the execution of applications with policies

In Windows 7 and up you can whitelist and or blacklist application through the registry. With this approach you are able to create a policy that either allows or disallows the execution of a ﬁle by comparing the process name to the policy. To use this feature open the registry by searching for "regedit" in the Windows search bar and go to: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\ Policies

Create an "Explorer" folder in the "Policies" directory. Now you can choose between blocking a speciﬁc app or only allowing speciﬁc apps.

2.3.1. Blacklist

In the "Explorer" folder create a DWORD(32) with the name "DisallowRun" with the value 1, you also need to create a subfolder in "Explorer" named "DisallowRun". All rules need to be written to this folder. To create the first rule create a new string value and give them a number that enumerate on each rule. With this specification, the first element is 1 the next 2 etcetera. The value of the entry shall be the name of the file that should be restricted,

10 Chapter 2. Available information gathering tools and protection suites

Figure 2.4.: Application restriction policy for example "notepad.exe". Figure 2.4 shows how it should look like when a rule has been created.

2.3.2. Whitelist

If you want to use the whitelisting approach, do the same steps as in the blacklisting process, with the slight diﬀerence that instead of using "DisallowRun" for the dword entry and the folder entry, just use "RestrictRun" as the name for the entry.

2.3.3. Overview

With this approach you can easily create a rule to allow only a speciﬁc subset of application to run. However since it is only possible to identify a program by its name, an attacker with the knowledge of this policy could easily name an application after an allowed software to bypass these security precautions. On top of that since there is no audit mode or testing mode for these rules it is rather easy to lock yourself out of the system and without the possibility to disable these rules.

2.4. Applocker

Applocker offers features to create policies/rulesets for a specific subset of controllable entities. There are multiple conditions that can be set for the restriction mechanism with the outcome being to either allow or disallow the operation. These are the Applocker entities that can be restricted: • Executable files: .exe , .com - Restrict if a process is created. • Windows Installer files: .msi , .mst , .msp - Restrict the installation of programs. • Scripts: .ps1 , .bat , .cmd , .vbs , .js - Restrict the interpretation of script files. • DLLs: .dll , .ocx - Restrict usage of DLLs in applications. [BL17c] [BL17a] [BL17d] Applocker offers a couple of features that allow to distinguish a specific application from another and therefore restricting it according to a specific ruleset. The three primary conditions are: • Publisher - This option is only available if the software publisher signed the file with a digital signature. If a signature is available you can create a ruleset that for example only allows signed files access, or only files that are from a specific publisher or have a specific product name. With this approach a rather dynamic ruleset can be created to identify an application, even for applications that are often updated. For further information visit: "https://docs.microsoft.com/en-us/windows/security/threat- protection/applocker/understanding-the-publisher-rule-condition-in-applocker"

11 Chapter 2. Available information gathering tools and protection suites

• Path - This option can set a ruleset to a specific directory. For example that only installer files can be started when they are in "%System32%". This solution only makes sense if the directory that is restricted is not accessible by everyone, because if it is easily accessible, everyone with the knowledge of this rule can easily bypass it. This means an administrator could create a directory with allowed installers in it, and only allow the file to be read only for all other users. • File hash - The identification of an application is done via a cryptographic function, which generates a "unique" value by feeding it its properties through this mechanism. The massive downside of this approach is that, whenever the application is updated, its size and properties change, therefore the hash value changes as well. There are some use cases where this approach is a good option to use. For example with files that have no digital signature or is an application that does not change very often. For this scenario it is a rather straight forward rule however if this rule needs to be adjusted on a daily basis, for applications like your web browser, this can get pretty annoying. [BL17b] Requirements: A modern Windows system is needed this means everything from Windows 7 and up is theoretically supported, however for systems like Windows 7 and 8 the Enterprise edition is recommended, to allow enforcement from a domain controller. There are some restric- tions for some Windows versions, these can be found here: "https://docs.microsoft.com/en- us/windows/security/threat-protection/applocker/requirements-to-use-applocker"

2.4.1. How to use AppLocker

Search for the term "gpedit.msc" in your Windows searchbar and execute it. This should open up the "Group Policy Editor". In the editor go to the directory "Computer Configuration -> Windows Settings -> Security Settings -> Application Control Policies -> AppLocker". To activate rule enforcement press the "Configure rule enforcement" and activate the ruleset that you want to enable, there is a ruleset for each entity type. The type of rulesets are the same as they have been explained at the beginning of this section. Now you want to create specific rules to be enforced, this can be done by clicking on the specific ruleset. For this example click on "Executable Rules" and then right click in the empty space and press "Create New Rule". This starts a rule creation wizard, that guides you through the whole process. These are the question asked: • Permission - Should this operation deny or allow the request, if the rule is hit. The next question is to which userbase shall this rule be enforced. This can be either the whole userbase or just some specific users. • Condition - Choose one of the conditions explained earlier on(Publisher, Path, File hash), optionally you can add an exception rule with another condition. • Description - Add a description to identify the ruleset If everything was configured correctly, and an application ruleset is set to block a specific application, upon execution it will display a message box that says "This program is blocked by group policy. For more information, contact your system administrator". If that did not happen, make sure that the service "AppIDSvc" is running. AppLocker is a powerful tool and with power comes responsibility, since the ruleset is only locally enforced and not administered by a domain. In this example, it is rather easy to either destroy your Windows system or lock yourself out by blocking important features of

12 Chapter 2. Available information gathering tools and protection suites the system. Therefore it makes sense to not try this feature out on a real environment, but to start with a virtual machine or a "throwaway" system that can be wiped without much thought.

13 3. Windows Filter Driver

3.1. Microsoft Filter Driver Deﬁnition from Microsoft

"A file system filter driver is an optional driver that adds value to or modifies the behaviour of a file system. A file system filter driver is a kernel-mode component that runs as part of the Windows executive. A file system filter driver can filter Input/Output(I/O) operations for one or more file systems or file system volumes. Depending on the nature of the driver, filter can mean log, observe, modify, or even prevent." [hm].

3.2. Introduction to the windows driver model

To understand the system behind the windows filter drivers, one must firstly understand what a driver is and which driver models exist. Drivers are needed so that an operating system can communicate with a device. For example when an application wants to get data from a device it needs to call a function that is available by the operating system. In the background the operating system calls a function that was implemented by the manufacturer or from another company like Microsoft with their default drivers. This driver allows to get or process the data by the device. If the call succeeded the data is returned to the os function and then a response is forwarded to the application which created the request. This is the ideal scenario where there are no filter drivers between the device and the operating system. In a lot of cases there can be multiple filter drivers for a device, but there needs to be at least one function driver which communicates directly with the device. Multiple filter drivers are often necessary if the data from a function driver needs to be transformed to another format for a specific application or if it has to be intercepted by multiple authorities before being forwarded to the operating system. These filter drivers are not in direct communication with the function driver, but are merely passing the information along while transforming it to a specific format. This means each driver can add values, remove, record or modify the data from the previous driver, if necessary [Baz17c]. These filter drivers can be further refined to upper and lower level filter drivers. The lower level filter modifies the behaviour of a physical device, this means they can modify and/or monitor the behaviour of the hardware. The upper level filter can add or modify the behaviour after it was processed by the function driver. On top of that, there is another subset of driver types, which consists of device or class filter drivers. The device driver is for a specific device and the class filter is for a specific class of device which means multiple devices can use this driver for example a generic Microsoft audio driver which can be used by multiple vendors and or device types. With this in mind, figure 3.1 and figure 3.2 show the previously explained models [Baz17c]. To further widen the driver definition even more, there are also software drivers because there are drivers which are not associated with any physical device. A software driver can be used to access or modify core OS functionality which requires kernel level rights. They are mostly used with a second component that runs in user mode and communicates with the

14 Chapter 3. Windows Filter Driver

Figure 3.1.: Typical driver for a device [Baz17c]

Figure 3.2.: Enhanced driver model for a device [WDDDT17k]

15 Chapter 3. Windows Filter Driver

Figure 3.3.: Software driver [Baz17c]

Figure 3.4.: Bus driver [Baz17c] software driver which has kernel level rights. Software drivers are always in kernel mode and can access core functionalities as can be seen in figure 3.3 [Baz17c]. There are also bus drivers which are needed if the OS is not directly communicating with the device but through another component like a Universal Serial Bus(USB)-hub. The communication is delegated through other drivers which are available on the bus that communicate directly with the physical device as can be seen in figure 3.4. To summarize the topic, these are the available driver options for the Windows platform: 1. Device function driver 2. Device filter driver a) Bus filter driver b) Lower-level device/class filter driver c) Upper-level device/class filter driver 3. Software driver 4. File system filter driver a) Lower-level device/class filter driver b) Upper-level device/class filter driver 5. File system driver [Baz17a]

3.3. Windows Filter Driver features and requirements

3.3.1. Callbacks

To create a fully functional driver, a basic set of routines has to be implemented following Microsoft’s speciﬁcations. The driver needs:

16 Chapter 3. Windows Filter Driver

1. DriverEntry: Initializes the driver. It is called when the I/O manager loads the driver. 2. AddDevice: Adds the device object to the device stack. Is called after the Driver Entry and defines the entry point of the driver extension in the object. 3. Dispatch Routines: Receive and process at least one I/O request packet (IRPs). 4. Unload: Releases the system resources which were acquired by the driver. [WDDDT17j] [WDDDT17f] Callbacks are a very important part in the whole driver ecosystem. They are used for all kinds of communication between routines, drivers and the system. To allow the interception of a specific event like the creation of a directory (IRP_MJ_CREATE), the filter driver needs to subscribe and listen to this event to be able to intercept this call. This means the filter driver needs to register for every event which the application wants to intercept. Furthermore every intercepted call needs to be processed properly, which means either completing the request, forward to the next responsible driver, dropping the call completely or by reporting that the request was processed but nothing was done by the filter. In the creation of a directory the expected response is a handle to the file object [TS17].

3.3.2. Load Order for the drivers

Since there can be multiple filter drivers for a specific call, there has to be a priority system to define which driver gets the call first. Filters are attached to a file system driver stack and the drivers are processed from the bottom to the top. The "Load Order Group" defines in which order these drivers are attached to the stack. Since there can be multiple drivers in the order group, there still needs to be a prioritization within the group. Microsoft solves this by creating a random order in the group itself. It is recommended but not a requirement to define the load order of a filter driver, if no order is defined it is loaded after all the drivers with the same start type. The start type defines when and by whom the drivers are loaded. However load order groups can only be used by "SERVICE_BOOT_START" and "SERVICE_SYSTEM_START". The load order groups can be seen at table 3.1. Start types: • SERVICE_BOOT_START - started by the operating system loader • SERVICE_SYSTEM_START - started during os initialization • SERVICE_DEMAND_START - started during os initialization(started on demand) • SERVICE_AUTO_START - started by the Service Control Manager during start up • SERVICE_DEMAND_START - started by the Service Control Manager during start up(started on demand) • SERVICE_DISABLED - not started by the operating system or the Service Control Manager, can be used to temporarily disable a driver for debugging purposes. [WDDDT17b] [WDDDT17c] Every group in the load order group has a specified purpose which is explained in detail here: Load Order Groups

17 Chapter 3. Windows Filter Driver

Table 3.1.: Load Order, priority is from bottom to top [WDDDT17b] Filter FSFilter Top FSFilter Activity Monitor FSFilter Undelete FSFilter Anti-Virus FSFilter Replication FSFilter Continuous Backup FSFilter Content Screener FSFilter Quota Management FSFilter System Recovery FSFilter Cluster File System FSFilter Hierarchical Storage Management(HSM) FSFilter Imaging FSFilter Compression FSFilter Encryption FSFilter Virtualization FSFilter Physical Quota Management FSFilter Open File FSFilter Security Enhancer FSFilter Copy Protection FSFilter Bottom FSFilter System (internal) FSFilter Infrastructure (internal)

18 Chapter 3. Windows Filter Driver

3.3.3. IOCTL

Input and output control(IOCTL) provides the ability to communicate with a device driver. With the "DeviceloControl" function, specific control codes can be send to a driver. Here are the control code types which are available: 1. Communications Control Codes (Link) 2. Device Management Control Codes (Link) 3. Directory Management Control Codes (Link) 4. Disk Management Control Codes (Link) 5. File Management Control Codes (Link) 6. Power Management Control Codes (Link) 7. Volume Management Control Codes (Link) [Mic17a] [Mic17b] To connect to a specific driver one must know the specified port name of the driver. This specified port name is registered when calling "FltCreateCommunicationPort" on the filter driver. The client communication then uses this port to connect and communicate with the filter. Here are the functions needed for the most basic communication with a driver: 1. FilterConnectCommunicationPort function - Connect to the driver, if successful returns a valid handle. This handle is then used for every communication attempt between the driver and the other application. (Link) 2. FilterSendMessage function- Send message to the filter driver. (Link) 3. FilterGetMessage function - Receive message form the filter driver. (Link) 4. CloseHandle function - Close communication. (Link) These functions are all included in the same library "FltLib.lib", which needs to be included in the environment settings of the project. [Micb]

3.3.4. Access control list

Access control lists allow to restrict the access to a driver. To communicate with a driver a handle needs to be created by connecting to the ﬁlter. Before returning a handle, the access control procedure checks if the user which requested this handle is allowed to access this resource. This access check is enforced with every communication attempt with the driver. The access control list consists of access control entries(ACE) which describe what access rights a user has to a speciﬁc resource. [Mica]

3.4. Getting started with the Windows Driver Kit

To start implementing Windows drivers, the Windows Driver Kit(WDK) kit is needed which also includes example implementations and basic toolkits to compile drivers in visual studio [WDDDT17e]. Before starting to write some code, it is imperative to understand that there are some limi- tations and requirements, that should be known to a developer:

19 Chapter 3. Windows Filter Driver

1. System-supplied video port and Small Computer System Interface(SCSI) drivers cannot be replaced 2. The lowest-level driver needs to implement the same functionality as the driver that it replaces 3. If a new intermediate driver is put between any pair of drivers it must operate with them so that the functionality is not reduced [WDDDT17i] Furthermore, there are discrepancies between some versions of the driver model, which are not fully compatible with each other. Since it only aﬀects Windows Server 2003 and lower it will not be further investigated because this paper only focuses on the newer Windows platforms (7,8,10) [Mic17c].

3.4.1. Driver Signing

Since Windows 7, drivers are required to be signed before being able to attach them to the system. This means to deploy drivers locally for testing purposes, a security mechanism needs to be disabled to allow installation of unsigned driver. For public releases or massive roll outs, Microsoft offers certification services to allow the installation of these drivers, without needing special permission on each computer. Microsoft has requirements and policies which need to be met, to get the signature for the Microsoft systems: Certification Requirements [Hud17b]. The requirements in the document define what should and should not be done by a driver. To install a driver with a self signed certificate you have to execute this instruction in the command line as an administrator:

Microsoft Windows [Version 6.3.9600]

C:\myDrivers>bcdedit /set TESTSIGNING ON

If the command was successful just reboot the system, and everything should be ready to go. When the test signing mode was successfully activated, Windows should now display a "Test Mode" branding in the right bottom corner. From now on drivers are not checked for a valid signature from Microsoft. However a certificate is still needed but a self signed certificate is sufficient enough. To sign your driver with a self signed certificate, either generate via visual studio directly in the project setting, or with this tool provided by Microsoft "DevCon". The generated certificate file then needs to be installed to the Windows certificate storage[Hud17a].

3.4.2. Install Driver

There are two ways to install a driver to the system. Either by using a .INF file or by directly copying the compiled driver to the "C:\Windows\System32 \drivers\" folder and then telling the os to load the driver[Zwa10]. The .INF file helps automating the process and can provide additional functionality to the install process as well as to the uninstall process. Usually the .INF file consists of these parameters: 1. Version (required)

20 Chapter 3. Windows Filter Driver

a) Example: DriverVer = 1/25/1999,1.3.3.7 2. DestinationDirs (optional but recommended) - Defines to which directory the filter drivers are copied. The directory can be a static path or a dynamic path defined by a value which can be read in this Microsoft document(Directory ID’s): a) Example:

[DestinationDirs]

DefaultDestDir = 12 [12 Points to (%SystemRoot%\\system32\\drivers)] 3. SourceDisksNames (required) - Deﬁnes the distribution media which will be used to transfer data from the medium to the computer. a) Example:

[SourceDisksNames.x86]

1 = "Windows NT CD-ROM",file.tag„\x86 4. SourceDisksFiles (required) - Defines which files are copied from the medium that were defined in the "SourceDisksNames" parameter. a) Example:

[SourceDisksFiles.x86]

aha154x.sys = 1,\x86 [use source disk 1] 5. DefaultInstall (required) - Deﬁnes which ﬁles are copied and which registry entries are created. a) Example:

[DefaultInstall]

CopyFiles=MyFiles, MySysFiles, @example.exe

AddReg=MyAppRegEntries 6. DefaultInstall.Services (required) - Deﬁnes if and when services are loaded. a) Example:

[Ser_Inst.Services]

AddService = myclass„ myclass_Service_Inst, myclass_EventLog_Inst 7. ServiceInstall (required) - Deﬁnes the type of service and which binary will be used for it. a) Example:

21 Chapter 3. Windows Filter Driver

[MyLegacyFilter.Service]

DisplayName = %MyFilterServiceName%

Description = %MyFilterServiceDesc%

ServiceBinary = %12%\myFilter.sys

ServiceType = 2 ; SERVICE_FILE_SYSTEM_DRIVER 8. DefaultUninstall (optional) - Deﬁnes which ﬁles or entries in the registry need to be deleted to purge the previously installed driver. a) Example:

[DefaultUninstall]

DelFiles = MyFilter.DriverFiles, MyFilter.UserFiles

DelReg = MyFilter.DelRegistry 9. DefaultUninstall.Services (optional) - Deﬁnes which services need to be deleted to remove traces of the installed driver. a) Example:

[DefaultUninstall.Services]

DelService = MyFilter,0x200 [0x200 defines that the service should be stopped before it is deleted] 10. Strings (required) - Defines stringkey tokens to define the language used or strings that define the Manufacturer or the OID. a) Example:

[Strings]

Msft="Microsoft"

MfgAcer="Acer"

Acer404.DeviceDesc="ACER CD decoder card"

Each parameter has multiple entries which can be required or optional, for further information see the Microsoft documentation [WDDDT17a]. If the installation process is done without an .INF ﬁle, a service needs to be created and started manually for the generated driver ﬁle.

22 Chapter 3. Windows Filter Driver

To create a service for the driver this command needs to be run:

Microsoft Windows [Version 6.3.9600]

C:\myDrivers>sc create MyFilter type=filesys binPath= C:\Windows\System32\dri vers\MyFilter.sys

If the service was created successfully it now needs to be started with the command:

Microsoft Windows [Version 6.3.9600]

C:\myDrivers>sc start MyFilter

The stopping mechanism is pretty similar:

Microsoft Windows [Version 6.3.9600]

C:\myDrivers>sc stop MyFilter

[Mic12a] [Mic12b] [Mic12c]

3.5. Alternatives to Windows Filter Drivers

3.5.1. Windows Detours

Windows Detours offers a way to intercept Win32 functions in a x86 binary. This method does not need the source code of the application, since everything is done dynamically at runtime and does not modify the binary itself since the function is modified in the memory. With detours it is also possible to create a ruleset for every application. Detours replaces the jump instructions from the functions used in the application to a user provided "detour" function. The calls are then stored and processed in a "trampoline" function and after that forwarded to the real function. The current version of detours is 3.0 and offers an express and professional version. The professional version includes licensing costs, while the express edition does not. The main difference is that the express version does not support x64 applications. The price point needs to be requested and does not seem to be advertised anywhere. [GH99] Mhook offers an alternative to Microsoft detours, more information as well as the download for Mhook can be found here: "http://codefromthe70s.org/mhook24.aspx". The same can be said about EasyHook with similar features, the documentation and download link can be found here: "https://easyhook.github.io/documentation.html"

23 Chapter 3. Windows Filter Driver

Figure 3.5.: Detours Overview

3.5.2. WinAPI hook

Hooks are a mechanism to attach to a function/call with the intent to either monitor or manipulate the behaviour of calls. To filter out file access, we need to attach to function calls from kernel32.dll. Here are the biggest ones that are needed: 1. ReadFile (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467(v=vs.85).aspx) 2. WriteFile (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365747(v=vs.85).aspx) 3. CreateFile - Create or open a file (https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx) For further information on API hooking visit: "https://msdn.microsoft.com/en-us/library/windows/desktop/ms644960(v=vs.85).aspx"

3.5.3. Overview

Windows Detours and WinAPI hooks offer a good way to manipulate OS behaviour in comparison to the filter driver approach chosen here. Both approaches intercept a call on a function level basis, as it is being called in the OS. However the main difference to filter drivers are, the access level these approaches are used with. Windows Detours and WinAPI are executed with administrator rights, this means it does not run on a kernel level. Since it also runs on a "high level" basis many calls can be processed by the kernel without the hooking approach noticing. This means a filter driver or a rootkit could filter out or modify the low level calls without the hooked function noticing. This is the main reason to choose the filter driver approach since it works on such a low level, it is really hard to bypass and detect such a system.

24 4. Building the Program

4.1. Preparing the System

To create the program proposed by this paper, some prerequisites are needed. The testing environment is: • Windows 8.1 • Visual Studio 2015 • Windows Driver Kit version 1607 • Windows 10 SDK • .Net 4.5.2 Framework There is a never version of the Driver Kit available(1709) but it is only compatible with the newest version of Visual Studio 2017. The installer for the Driver Kit can be downloaded here: https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit. (Note: The Version of the Driver Kit and the Software Development Kit(SDK) must match, or it can result in unexpected behaviour in visual studio)

4.2. Choosing the right project type

There are multiple ways to communicate with a driver. The basic tools needed are to be able to use windows SDK specific libraries and to attach DLLs to the project. To explore the possibilities for this paper three approaches were investigated. • C# Windows Presentation Foundation(WPF) • C++ Win32 • C# WPF + C++ DLL For this paper the third option will be used. These are some of the reasons why this approach was used: • Marshaling - Putting everything into the C# application is possible but with marshaling a lot of work needs to be done, to communicate with the filter. For example C# does not understand pointer types, therefore they need to be marshaled so the application knows how to get the data. Since in C++ pointers are used everywhere, the conversion from one type to another and vica versa requires a lot of conversion, which results in a lot of "unnecessary" code. • Graphical User Interface(GUI) in C++ - To create a C++ GUI more time would have been required due to missing knowledge in this field. Therefore C# has been used, since GUI programming knowledge in C# was already present and .Net is already used for the other parts of the project, so there is no need to install more toolkits. This means the C# WPF application is the front end for the user and will be used to display information and allow configuring the drivers. The DLL handles the low level communication

25 Chapter 4. Building the Program with the driver and allows straight forward communication between the GUI and the driver. This approach minimises the marshalling that is needed in the c# application to communicate with the driver. Without the DLL, the c# application needs to marshal every unmanaged type to a managed type and vice versa. This results in bad performance and chaotic code due to complex marshalling routines. This is the main reason why the DLL approach was chosen. Figure 4.1 shows how the project is structured. 1. The driver application creates a "driver.sys" file that can be attached to the system. To have a functioning driver we need to fullfill the requirements which were defined in 3.3. 2. The driver needs to be loaded by the system, this includes when and how it is loaded. This is important if specific requests need to be handled before other drivers have access to it. For our purpose it makes sense to have the highest priority by being loaded as soon as possible. This means attaching in the SERVICE_BOOT_START with the priority "FSFilter Bottom" which is the lowest possible attachment point that is available. For debugging purposes the filter can be manually attached to the system during runtime with the "sc" command which was mentioned in 3.4.2. With this approach the driver has the lowest priority, since it is attached after the whole driver initialization routine. 3. The driver is loaded and maintained by the operating system, with a specific priority. 4. With our DLL application we create a "mydll.dll" file that implements the features we need for the communication with our driver. This includes connecting/disconnecting/messaging and other routines which are needed for a successful communication. 5. The WPF application uses the DLL Import service which is offered by "System. Run- time.InteropServices" to be able to use the provided functions from the DLL file. This means the c# application uses the exposed methods by the DLL for its purposes. 6. The DLL communicates on behalf of the WPF application and forwards the requests to the driver. The result is then conveyed back to the application through the defined return parameters of the function call. 7. The WPF application creates an executable which can be run on any Windows system that supports the selected .Net framework.

4.3. Preparing a computer for remote deployment and debugging

Installing drivers on a remote computer is not allowed by default due to security concerns, therefore many security features need to be disabled to allow the installation of the drivers. Firstly secure boot needs to be disabled if Unified Extensible Firmware Interface(UEFI) is used. This feature disallows installing unsigned driver, this means we would not be able to deploy the driver on the machine. Secondly the WDK kit needs to be installed on the target computer. After that the "WDK Test Target Setup x64-x64_en-us.msi" needs to be executed on the machine. The setup file is included in the WDK kit and is usually in this directory: "C:\Program Files (x86)\Windows Kits\10\Remote\x64\" Furthermore the firewall settings need to be adjusted by either completely disabling the Windows firewall or by selectively allowing the specified services. For the inbound rules you need to find all Rules that begin with "Network Discovery" and "File and Printer sharing" then under the tab scope you need to adjust the "Remote-IP-Address" to "Any IP-Address" for each rule. Note: The host machine needs to use the local Domain Name System(DNS) server, that has an association with the remote computer name of the target computer.

26 Chapter 4. Building the Program

Figure 4.1.: Project structure

The final step is to prepare the host machine that deploys the driver on the target machine. In the properties of the project in visual studio you need to go to "Properties" and then in the "Configuration Properties" to "Debugging" and then into the tab "Debugging Tools for Windows - Kernel Debugger". Then you can add a new target device to the list, where you will be guided through the wizard. The most important parameter in this configuration is the "Network host name" which is the name of the device that is known in the network. The simplest way to find out the name of the target device is by writing "hostname" into a command line interface on the target computer. This is needed to discover the target device in the network, be sure to have both devices in the same network/subnet to work properly. If everything was configured correctly, the target device should be automatically logged out and a new user named "WDKRemoteUser" should be created by the add target procedure. From that point on everything will be configured automatically by the remote debugging wizard, which means installing all needed redistributables and other software packages that are needed for this setup. After the setup has been completed, a summary should be visible that shows if everything was correctly installed and if it is ready to go. Note: This procedure should only be carried out on a test computer or virtual machine, since it opens up ports and sets debugging options on various Microsoft features that can com- promise day to day security. When the device is in this mode, the user "WDKRemoteUser" automatically logs into the system without needing to input a password, even though a password exists for this user. This is especially dangerous since it is an administrative user, which makes sense from the deployment perspective but compromises the whole security subset of the operating system. It does not seem possible to disable this "feature" without removing the whole debugging mode from the device. [Baz17b]

27 Chapter 4. Building the Program

4.4. Removing remote deployment and debugging from the computer

The probably official way, however nowhere stated, is to delete the tools via the same remote provisioning tool that was used to add the device. Go to the tab "Test" and select "Configure Computers", select the computer used for debugging and click on "Delete computer" and then on "Remove provisioning and delete computer". If the "official" way does not work, another way is to use system restore points which are conveniently created automatically before the installation of the whole process. This is also a good way to remove the provisioning efforts without needing the computer that initiated this debugging process. This can be a lifesaver if the host machine dies and the visual studio way is not an option anymore. To get to the restore point menu in Windows, type this into the commandline:

Microsoft Windows [Version 6.3.9600]

C:\>rstrui.exe

After that a restore window should pop up, where restore points will be available. Look for "Installed Test Authoring and Execution Framework" and try to restore to this snapshot. Unfortunately restoring to a speciﬁc point does not work every time, therefore another way is possible, to remove as much as possible to lower the "damage" done to the operating system. • Revert the changes in the windows ﬁrewall, close the ports again. • Remove the user: "WDKRemoteUser" to disallow automatic login. • Uninstall these packages with the Windows software manager: – WDK Test Target Setup x64 – Windows Driver Testing Framework (WDTF) Runtime Libraries – X86 Debuggers and Tools – x64 Debuggers and Tools – Test Authoring and Execution Framework x86 – Test Authoring and Execution Framework x64 • Run "netplwiz" and check the checkbox saying "Users must enter a username and password to use this computer" - This will stop the system from trying to login to the "WDKRemoteUser". This command needs to be run because Windows will still try to login as this user even though the credentials are not valid anymore. The issue with this approach is that not only were tools installed but also many features have been tampered with that are not documented. For example it is not possible to lock the computer anymore, screen saver behaviour has changed and much more. Therefore this approach should only be used in the worst case scenario when none of the approaches mentioned before worked.

4.5. Conﬁguring the Driver Project

Before starting to write code, the project needs to be conﬁgured properly. Firstly the program has to be compiled for the correct platform. These are the available options:

28 Chapter 4. Building the Program

• ARM • ARM64 • Win32 • x64 After configuring the platform we need to set the target operating system. We can choose from: • Windows 10 • Windows 8.1 • Windows 8 • Windows 7 To complete the project setup we need to reference the libraries from the Windows SDK which are usually located in Program Files x86, be sure to pick the same version as from the driver kit since it can result in compiler errors if there is a version mismatch. This path needs to be added in the project settings in the C/C++ tab under "Additional Include Directories". In the linker settings you should add "%(AdditionalDependencies)" as well as the specific library you want to use. For our project we will always include the "fltLib.lib" to the additional dependencies since we want the capability to communicate with our filter driver. This includes connecting, sending and receiving messages from the filter. Visual Studio offers a lot of different application types and use cases. For our purposes we will use "Mini-filter" type as can be seen in figure 4.2. For further information and sample project files, Microsoft has a public Github repository with many projects that explain usage of different driver types. The repository can be found here: "https://github.com/Microsoft/Windows-driver-samples"

4.6. The ﬁnal application

The application will be build after the consideration from chapter 4.2. This means there are three major parts in the project: user application, DLL communicator and the ﬁlter driver. This should give a brief overview of the tasks each application fulﬁls:

User application: • Visualize current running processes on the system • Whitelisting of processes which are allowed by the filter driver • Visualize access violation and the process responsible • Visualize allowed access by the white listed process • Filter handling as in: starting, connecting, disconnecting, stopping, sending and receiving information DLL: • filter_connect - Connect to the filter driver with a socket. The connection is established by using the unique name that is set by the filter driver during initialization. • filter_disconnect - Disconnects the connection if the user does not need to communicate with the filter driver. This will not stop the filter, this merely stops the communication socket. • filter_sendmessage - Sends a command to the filter driver. These are all the available commands that can be send to the filter. In the background these names are repre-

29 Chapter 4. Building the Program

Figure 4.2.: Windows Driver - Project types

30 Chapter 4. Building the Program

sented as a enumerable therefore just a mere number. This means GetMiniSpyLog is 0, GetMiniSpyVersion is 1 and so on. – GetMiniSpyLog - Get the last operations that happened on the file system. The number of entries depend on the buffer that is given to the filter and the actual amount of entries that are currently stored by the filter. – GetMiniSpyVersion - Returns the current version of the filter driver. – GetMiniSpyAllowedOperations - Gets the last IO operations that were allowed by the filter driver. Returns a list of processIDs. – SetMiniSpyWhitelist - Sends a whitelist of processIDs to the filter, that are allowed to do IO operations on the file system. – GetMiniSpyDisallowedOperations - Gets the last IO operations that were disallowed by the filter driver. Returns a list of processIDs. • filter_sendmessage_wparam - Sends a command to the filter driver with special parameters for the "SetMiniSpyWhitelist" instruction. • filter_attachvolume - Sets the volume on which the filter attaches and processes information. • filter_deattachvolume - Deattaches the filter from the volume. This stops all processing on the file system, but it does not stop the service. This means the filter is still loaded by the operating system but does not proceed with its operation. • filter_getprocesses - Retrieves all processes that are currently running on the operating system. Filter Driver: • Filter out every operation on the file system that is not a white listed process. This includes the most important calls that are processed by the filter driver: – IRP_MJ_CREATE: Request to open a handle for a file object or device object. Can be used to create a directory or a file, as well as open an existing file, device, directory or volume [WDDDT17l]. – IRP_MJ_CLOSE: Closes the handle to the object [WDDDT17h] – IRP_MJ_CLEANUP: Release all resources for this handle. Clears user memory that was locked by the resource. It is a typical garbage collector [WDDDT17g]. – IRP_MJ_QUERY_VOLUME_INFORMATION: Allows to request various information that are volume specific like the filesystem type, device information, space available etcetera [TH17c]. – IRP_MJ_READ: Needs a successfully created handle from IRP_MJ_CREATE and then reads data from the device [TH17e]. – IRP_MJ_WRITE: Needs a successfully created handle from IRP_MJ_CREATE and then writes data to the device [TH17f]. – IRP_MJ_DIRECTORY_CONTROL: Returns various information about the files which are stored in the directory [TH17a]. – IRP_MJ_QUERY_INFORMATION: Returns various information about a specific file object [TH17b]. – IRP_MJ_SET_INFORMATION: Sets various meta data about a file, like the file length [TH17d].

31 Chapter 4. Building the Program

– IRP_MJ_ACQUIRE_FOR_CC_FLUSH - Cache manager acquires exclusive lock for a file and also to flush the cache [Micc]. – IRP_MJ_RELEASE_FOR_CC_FLUSH - Cache manager releases exclusive lock for a file [Micc]. – IRP_MJ_NETWORK_QUERY_OPEN - Not documented by Microsoft – IRP_MJ_ACQUIRE_FOR_SECTION_SYNC - Not documented by Microsoft – IRP_MJ_RELEASE_FOR_SECTION_SYNC - Not documented by Microsoft • Implements all necessary callback functions which are specified by Microsoft 3.3.1 • Hosts a driver socket communication. This is done via IOCTLs and is necessary to communicate with the driver. • Note: The functionality of initializing and intercepting of file io calls has been provided by the "MiniSpy" example that is available on the Microsoft Github page:" https://github.com/Microsoft/Windows-driver-samples/tree/master/filesys/miniFilter/minispy" Not handled by an application but still necessary: • Installing the certificates to the Windows certificate storage. This is the certificate that is generated specifically for this driver. • Getting the Windows system into the "test mode" to allow the installation of 3rd party drivers which are not signed by the Microsoft CA. This is not needed if a driver gets verified through the Microsoft signing process which was already mentioned in chapter 3.4.1 • Starting the driver 3.4.2 • Installing and using the same version of the "Windows Driver Kit" through the whole process

4.7. typical ﬁle write operation

As already mentioned in 4.6 the filter driver listens and reacts to specific calls made on the physical drive. This should give a brief overview about which requests are needed to make a simple write operation. The call was isolated as much as possible meaning that no other unnecessary calls are displayed here. This was done by using a second partition that is not needed by the operating system and the write operation was done by a simple c# application that writes the current date into the file named "hallo.txt". Each call consists of a process-id and a thread-id which is represented by the first value("1fc8.18b0"). The second value is the call that is made and last but not least the destination/target. • 1fc8-C# application • 1374-Explorer.exe • 4-System

1fc8.18b0 IRP_MJ_CREATE \Device\HarddiskVolume5\hallo.txt 1fc8.18b0 IRP_MJ_WRITE \Device\HarddiskVolume5\hallo.txt 1374.1750 IRP_MJ_DIRECTORY_CONTROL \Device\HarddiskVolume5\ 1fc8.18b0 IRP_MJ_CLEANUP

32 Chapter 4. Building the Program

\Device\HarddiskVolume5\hallo.txt 4.2050 IRP_MJ_ACQUIRE_FOR_CC_FLUSH \Device\HarddiskVolume5\$LogFile 4.2050 IRP_MJ_WRITE \Device\HarddiskVolume5\$LogFile 4.2050 IRP_MJ_RELEASE_FOR_CC_FLUSH \Device\HarddiskVolume5\$LogFile 4.2050 IRP_MJ_WRITE \Device\HarddiskVolume5\$LogFile 4.2050 IRP_MJ_WRITE \Device\HarddiskVolume5\$LogFile 4.1a40 IRP_MJ_WRITE \Device\HarddiskVolume5\$Mft 4.1a40 IRP_MJ_WRITE \Device\HarddiskVolume5\ 4.1a40 IRP_MJ_WRITE \Device\HarddiskVolume5\hallo.txt 4.1a40 IRP_MJ_SET_INFORMATION \Device\HarddiskVolume5\hallo.txt 4.1a40 IRP_MJ_ACQUIRE_FOR_SECTION_SYNC \Device\HarddiskVolume5\hallo.txt 4.1a40 IRP_MJ_RELEASE_FOR_SECTION_SYNC \Device\HarddiskVolume5\hallo.txt 1374.8bc IRP_MJ_CREATE \Device\HarddiskVolume5\ 1374.8bc IRP_MJ_QUERY_INFORMATION \Device\HarddiskVolume5\ 1374.8bc IRP_MJ_DIRECTORY_CONTROL \Device\HarddiskVolume5\ 1374.8bc IRP_MJ_CLEANUP \Device\HarddiskVolume5\ 1374.8bc IRP_MJ_CLOSE \Device\HarddiskVolume5\ 1374.8bc IRP_MJ_NETWORK_QUERY_OPEN \Device\HarddiskVolume5\hallo.txt 4.7b4 IRP_MJ_WRITE \Device\HarddiskVolume5\$LogFile 4.7b4 IRP_MJ_WRITE \Device\HarddiskVolume5\$LogFile

As can be seen only three calls are actually made by the application. • IRP_MJ_CREATE - Get handle for a file [WDDDT17l]. • IRP_MJ_WRITE - Write data to a file [TH17f]. • IRP_MJ_CLEANUP - Return handle / done writing [WDDDT17g]. The other calls are either made by the system or explorer to register the changes. This includes changing all meta data like the filesize so the system registers the changes that were made to the file. The read process is pretty much the same with the main difference being that instead of calling "IRP_MJ_WRITE", "IRP_MJ_READ" is called.

33 Chapter 4. Building the Program

4.8. Blocking mechanisms

Since the whole driver system is build upon multiple layers of various drivers that depend on each other, they need a way to communicate between each other. Each layer can process the call and return a successful processing of the call or pass it onto the next driver to finish processing. This is where the filter driver has the ability to "sabotage" this chain by either dropping calls or by reporting that the call was processed properly without actually doing anything at all. In this scenario there are two callback types available, pre and post operation. Pre operation • FLT_PREOP_SUCCESS_NO_CALLBACK - The filter allows the operation to be processed by another filter. This does not mean that nothing was processed, but that the operation is not completely finished and requires further processing by another driver. The post callback operation is not called in this filter. • FLT_PREOP_SUCCESS_WITH_CALLBACK - Has the same properties like the first callback in this section: "FLT_PREOP_SUCCESS_NO_CALLBACK", with the difference that the post callback operation is called in this filter. • FLT_PREOP_PENDING - The driver sets the operation to "pending" this means that the operation is still not finished and that more time is needed for the processing. The filter manager waits until "FltCompletePendedPreOperation" is called by the same filter driver until the whole process is continued. • FLT_PREOP_DISALLOW_FASTIO - FastIO operations are disallowed and no other filter drivers are being called after that. Also calls the post operation callback routine of the driver. FAST I/O are specially designed to allow rapid and synchronous I/O on cached files. The data is transferred directly between a user buffer and the system cache, this means that it bypasses the file system and storage driver stack which makes the operation a lot faster than a normal I/O [WDDDT17d]. • FLT_PREOP_COMPLETE - This means the filter driver completed the IO operation and there is no need for assistance by other layers of drivers that would come behind this driver. Also calls the post operation callback routine of the driver • FLT_PREOP_SYNCHRONIZE - Only the post operation callback is called and the operation is then returned to the filter manager which forwards it to the next driver. [Mic18b] Post operation • FLT_POSTOP_FINISHED_PROCESSING - The filter driver has finished the operation and returns it to the filter manager. • FLT_POSTOP_MORE_PROCESSING_REQUIRED - The filter driver has not finished the processing of the operation and will return the operation when it has completed the job. The filter manager waits until the filter driver has called "FltComplete- PendedPostOperation" which means that the job has been finished and the control has been returned to the filter manager. [Mic18a] This means if a whitelisted process tries to access a file the application returns "FLT_PREOP_SUCCESS _NO_CALLBACK" and lets another driver process the call, so that it can be successfully accomplished. However if the process is not whitelisted "FLT_PREOP_COMPLETE" in combination with "FLT_POSTOP_FINISHED_PROCESSING" is returned. This means the call is "silently" dropped and not processed at all. This seems to be the easiest approach on how to intercept and drop a specific call.

34 Chapter 4. Building the Program

The whole process can be easily extended to other types of intercepting at this level, because the concept is always the same. With the current api information available a few conclusion based filtering decisions can be made: • Filter out specific file types - This means it is possible to completely disallow the access to specific file types. With this in mind it can be configured to disallow the execution of file types like ".exe" or ".msi" or to block the read or write calls for specific file types. With a few enhancements even specific filenames and or directories can be restricted. Through this process a key file or other types of important data could be restricted from access. • Filter out access to specific folders/volumes - Currently the filter driver needs to attach to a specific volume. In this volume access to directories can be filtered out as well. • Filter out access from specific processes/threads - This is the current configuration of the program, which gives the best protection against new unknown programs, by restricting access to all files if the process is not whitelisted • Filter out write or read calls, it is also possible to selectively change filter behaviour if the call is a read or write operation. This can be a good feature to make files read only.

35 5. Project Overview

5.1. Tests

To test out if the file IO interception works, two approaches were used. The first one was to try to access the restricted files via explorer.exe and the second was via a c# application that tries to write to files in a restricted directory. Both approaches were successfully blocked, and their requests have been blocked, therefore the desired outcome was achieved.

5.2. Problems

Filter drivers are a very interesting field but due to a lack of documentation in some fields and the relatively small community behind this topic many issues that became a problem in this project had to be resolved by brute force or by strange problem solving approaches. This was especially an issue with the first filter project that was not usable at all. This was due to version mismatches that resulted in strange behaviour as in bluescreens when loaded by the system or not being loading at all because of strange error codes that were not pointing to a specific problem. This was especially problematic since it was not possible to debug on a live system due to unresolvable error messages, even though everything was set up correctly on both machines. This was also the reason why it was not possible to intercept network traffic since the loading of the driver resulted in a bluescreen and it was just not possible to find out why the bluescreen happened or why the driver loader did not suggest any problems with the driver. The worst thing about the whole project was the badly documented driver signing which promised the ability to sign drivers and install these drivers without compromising the whole security system in Windows. In the end this did not work and without setting the system into the "test mode" and installing the self signed certificate no home made driver could be attached to the system. This fact diminishes the the whole security aspect of this project since one possible problem is solved but many more are opened due to the ability to install any driver by any administrative command line at any time. To be fair this will not be a problem for enterprise applications but wont allow a normal user to install or create such a system without compromising overall security efforts by Microsoft.

5.3. Filter drivers critical view

Windows Filter driver are a powerful toolset, however with insufficient data or tests in a running environment against current threats, there is not really a way to know how effective this approach even is. For example, from this point of view there does not seem to be a way to bypass filter capabilities, since it is a Windows low level approach, however with zero day exploits and or smart malicious behaviour one could potentially bypass this security. With this in mind, the filter driver itself is an attack vector as well and needs proper security mechanisms to not turn on the user, by flipping the security mechanism to do bad things.

36 Chapter 5. Project Overview

With this in mind there are not really many security mechanisms available, to protect the communication between the filter and the user application to restrict access to this filter. Here are some approaches that came up while working with filter drivers: • Security by obscurity - Is a much loved approach in the security field and can be effective for some time, however it is not a security mechanism that can be relied on. In this case to use a communication protocol, that is not documented and or not typical for these systems. • Encrypt communication - Encrypting the communication makes sense to disallow others to intercept the traffic, however another program cannot just listen on the same socket, but other approaches may be possible if some debugging capabilities are enabled on the system. To achieve such encrypted channel, both must share a secret to exclude access from other entities. This creates two requirements, the driver needs to have his key baked into the program and the user interface needs access to this key. Storing this key in a safe space, is crucial for this approach to be prepared against real threats. • Allow only access by whitelisted users - In a running environment it makes sense to disallow every user to have access to all resources. Access Control Lists(ACL) can be created to disallow access to specific resources, however the access to a driver should only be granted to users that are only used for special occasions and not to a user that is being used on a daily basis [Mica]. • Bake the information into the program - Baking the configuration into the software, would mean that it would not be possible to dynamically change the ruleset of the filter operations. For some approaches, dynamic rule configuration might not be necessary. Securing the communication between the filter and the user is not the only issue here, another problem is that it is rather easy to disable the security mechanism if the user has administrator rights. In a scenario where the account of an administrator is compromised, the security mechanism can be disabled without the user noticing it.

5.4. Common errors

5.4.1. Elevated rights

Everything that manipulates or changes the driver settings needs elevated rights. Sometimes strange error messages will be returned if a non administrative user tries to communicate with a ﬁlter. This also means that the application using the DLL needs elevated rights as well.

5.4.2. Using the correct platform

Visual Studio has many options on which platform and architecture the driver can be compiled. If these settings do not match, strange behaviour is imminent. When the architecture is incorrect attaching the driver to the system should fail with a proper error message, but in some cases a bluescreen will be thrown.

5.4.3. Signing

When using self signed certificates, it is recommended to use a certificate that was generated by visual studio. This certificate needs to be installed manually before attaching the driver

37 Chapter 5. Project Overview and can be found in the compiled ﬁles directory of the project. If for some reason the installation via the "sc" command fails after some time, remove the certiﬁcate and generate another one and repeat the installation.

5.4.4. Installation with INF ﬁle context menu

Sometimes the "Install" right click context menu vanishes from the explorer menu, this can happen if the standard program for opening ".inf" file changes. The easiest way to fix this is by opening the registry and removing this entry: "HKEY_CURRENT_USER \Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.inf" When you remove this entry Windows "forgets" which application should be used to open this filetype which fixes the problem and puts the installation menu back. Rebooting the machine may be necessary to change the behaviour.

5.5. Related work

5.5.1. Redemption: Real-Time Protection Against Ransomware at End-Hosts

In this paper from the year 2017 by Amin Kharraz and Engin Kirda from Northeastern University Boston, a protection mechanism that helps against current ransomware attacks without impacting the user experience is presented. The mechanism creates a transparent buffer for all I/O. It also monitors patterns of applications, if they convey signs of ransomware behaviour. The protection mechanism relies on two components, the first component is the analyser that observes the behaviour of a process and matches it to an abstract model and then determines if the process is malicious or not. The second component is a transparent buffer that stores and tracks all I/O operations. This allows the malicious process to write to a virtual buffer, therefore having a lot of information on what happens to the files, without losing data. Figure 5.1 gives a good overview on the system used for this approach. Instead of forwarding IO requests to the file system driver these requests are forwarded to the redemption monitor that as already mentioned saves and tracks these requests. Then the Behaviour monitor is invoked by updating the score of the process on how malicious it behaves. The monitor informs the user about the score/rating of the process and informs the system service manager if the operation was successful or a failure. With this approach I/O calls can be intercepted and analysed with minimal data loss. With minimal average overhead of 2.6% in IO performance and a high true positives and low false positives detection rate can be achieved and therefore many threats can be mitigated [AK17]. Comparison to this thesis Both approaches use a similar intercepting mechanism of the I/O calls to the disk. If a program wants to access a resource, it needs to poll the information from the disk which is serviced by a driver. In the "Redemption" approach I/O calls are buffered and analysed for malicious behaviour. If the behaviour of the process has been flagged as malicious, the calls will be dropped and not processed. This means the whole system depends on the detection mechanism. In the approach presented here, no intelligence or detection mechanism is needed. All read and write calls are blocked if they are from a newly created or unknown process. Therefore the user has to choose which processes are trusted.

38 Chapter 5. Project Overview

Figure 5.1.: Redemption overview [AK17]

5.5.2. Dynamic Ransomware Protection using Deterministic Random Bit Generator

In this paper from the year 2017 by HaEun Kim, Dongchang Yoo, Ju-Sung Kang and Yongjin Yeom from Kookmin University Seoul, an approach that shall not prevent the ransomware from encrypting the system but to set up tools to recover the key used for the encryption. This is done by manipulating the random number generator service used by the operating system to generate key material. In this case the CryptGenRandom function from the Windows API is modified. The mechanism works by creating a seed for a deterministic random value generator which is used to generate the keys for the CryptGenRandom function. The proposed system can be viewed in figure 5.2 The procedures done by the protection mechanism are the following: 1. Create and set a seed value to the DRBG(Deterministic Random bit generator). This is needed to know which random numbers will be generated. 2. Backup the seed to another device. Copying the seed to another device is crucial to have access to the seed values if the device is infected. 3. Modify the behaviour of the CryptGenRandom function, by hooking to it and let it use the created DRBG. 4. Save the reseed_counter and its internal state by date. In an ideal scenario the ransomware generates a key with the user-created DRBG. Then it encrypts the files with this key. The user has the seed to the DRBG and can predict which key-material was generated with the DRBG, therefore the files can be decrypted without paying any ransom[HK17]. Comparison to this thesis [HK17] shows another perspective on ransomware protection mechanisms, with a more passive approach. With this mechanism an attack will not be mitigated in any way as in the proposed approach from this paper and it depends on the fact that the ransomware will use the build in crypto functions from the system. Since this approach is not actively detecting anything, both approaches could be used simultaneously. The proposed system from this paper could be used to filter out io calls from processes and if for some reason a ransomware attack slips

39 Chapter 5. Project Overview

Figure 5.2.: Random value generation process [HK17] through, the other protection mechanism proposed in [HK17] with the DRBG approach could be used as a last chance to save the data on the system.

5.5.3. Ransomware Prevention using Application Authentication-Based File Access Control

In this paper from the year 2018 by Or Ami, Yuval Elovici and Danny Hendler from the Ben Gurion University of the Negev an authentication based access control system named "AntiBotics" to protect encryption by ransomware is presented. AntiBotics periodically enforces the authentication of the user to prevent access for bots, this is done through a biometric authentication or by the usage of Completely Automated Public Turing test to tell Computers and Humans Apart(CAPTCHA) on a periodic basis if a resource is requested. To understand human behaviour, filter drivers have been used to analyse and filter requests. The system allows read requests to be forwarded normally and mainly focuses on operations that allow to rename, modify or delete a file. AntiBotics can be configured to filter specific protected directories and file types as well as how long a user is authenticated before another permit needs to be issued by authentication. Figure 5.3 gives a quick overview on the whole AntiBotics system. As can be seen on 5.3 the system uses three major components, which will be explained in detail here: • Policy Enforcement Driver(PED) - Is implemented as a filter driver that tracks and or blocks specific IO requests. The enforcement ruleset is provided from the PSI. The PED has three actions that can be done if a IO request is detected. – Allow the call to pass through. – Block the call. – Request a challenge to the user. • Policy Specification Interface(PSI) - Allows an administrator to create a ruleset for the PED. The GUI allows the user to set the following entries: – Which directories shall be protected or excluded by the AntiBotics system. – To whom IO grants will be registered, either to a specific processid or to the path of the program. – How the user is challenged, either by biometric authentication or by a CAPTCHA.

40 Chapter 5. Project Overview

Figure 5.3.: AntiBotics system structure [OA18]

– Setting the permit scope, if an allowed process has access to all resources or just the one file on which the permit was granted. – The duration of the permit and the timeout of a challenge. – The protected file extensions like .doc, .jpg etcetera. • Challenge Response Generator(CRG) - Generates a challenge which needs to be completed by the user. The information provided in this challenge are: time, the program that wants access and the accessed resource. If the user agrees with this operation, a CAPTCHA must be solved or a biometric scan needs to be provided. If it should be blocked the user can click the "Prevent this action" button to block the access request. [OA18] Comparison to this thesis AntiBotics uses similar techniques and approaches for a ransomware protection suite, however the main difference is the inclusion of the user. Depending on how many folders are protected by the AntiBotics suite, a user could get overwhelmed with forced authentications, which could bring the user into a state where any requests are granted without questioning it. Compared to this approach proposed here, a less intrusive user experience can be created, however AntiBotics does feature better filter possibilities with the same technology used.

5.6. Future work

Filter drivers show a lot of potential in many use cases even though many potential important cases were not included in the program. This does not mean that the program and the whole ecosystem cannot be extended to ﬁlter out more information. Network traﬃc interception is one of the main intercept blocks which are essential for a good security appliance but were

41 Chapter 5. Project Overview not implemented by the software, due to unexpected issues and time constrains. This could help prevent applications from "calling home" to a C&C server . With many systems using multiple drives/volumes, it makes sense to extend the current software to not only attach to one volume but to many volumes at once. This could also be extended with specific rulesets for system volumes with critical os features or a backup drive with various personal stuff that should not be rewritten by specific processes. To enhance the convenience factor Microsoft context menus could be modified to allow quick blacklisting or whitelisting of specific files or directories on the fly. Since there were many issues with the driver signing, the next step would be to contact some Microsoft personnel, if there are other ways to sign drivers without being a certified partner to allow usage without using the "test mode".

5.7. Conclusion

Filter drivers have proven that they have a lot of potential and a lot can be done with this technique, however with self signed certificates and needing the "test mode" is in no way feasible as a real application. With the help of Microsoft or another way to certify a driver for a specific machine, this approach could be a very effective way of implementing home made security features without compromising baseline security of the system. However if some people can live with the "test mode" being activated, maybe some use cases will arise for non certified end users.

42 Bibliography

[AK17] Engin Kirda Amin Kharraz. Redemption: Real-time protection against ransomware at end-hosts. In: Dacier M., Bailey M., Polychronakis M., Anton- akakis M. (eds) Research in Attacks, Intrusions, and Defenses. RAID 2017. Lecture Notes in Computer Science, vol 10453. Springer, Cham, 2017. 38, 39, 47 [Ant17] Manos Antonakakis. Understanding the mirai botnent. 26th USENIX Security Symposium, 2017. 2 [Baz17a] Nathan Bazan. Choosing a driver mode. https://docs.microsoft.com/en- us/windows-hardware/drivers/gettingstarted/choosing-a-driver-model, 2017. 16 [Baz17b] Nathan Bazan. Provision a computer for driver deployment and testing (wdk 10). https://docs.microsoft.com/en-us/windows- hardware/drivers/gettingstarted/provision-a-target-computer-wdk-8-1, 2017. 27 [Baz17c] Nathan Bazan. What is a driver? https://docs.microsoft.com/en-us/windows- hardware/drivers/gettingstarted/what-is-a-driver-, 2017. 14, 15, 16, 47 [BL17a] Justin Hall Brian Lich. Applocker architecture and components. https://docs.microsoft.com/en-us/windows/security/threat- protection/applocker/applocker-architecture-and-components, 2017. 11 [BL17b] Justin Hall Brian Lich. Understanding applocker rule condition types. https://docs.microsoft.com/en-us/windows/security/threat- protection/applocker/understanding-applocker-rule-condition-types, 2017. 12 [BL17c] Justin Hall Brian Lich. What is applocker? https://docs.microsoft.com/en- us/windows/security/threat-protection/applocker/what-is-applocker, 2017. 11 [BL17d] Justin Hall Brian Lich. Working with applocker rules. https://docs.microsoft.com/en-us/windows/security/threat- protection/applocker/working-with-applocker-rules, 2017. 11 [DFS16] Hardeep Singh Dean F. Sittig. A socio-technical approach to preventing, mitigating, and recovering from ransomware attacks. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4941865/, 2016. 5 [GH99] Doug Brubacher Galend Hunt. Detours: Binary interception of win32 functions. https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/huntusenixnt99.pdf, 1999. 23 [HK17] Ju-Sung Kang Yongjin Yeom HaEun Kim, Dongchang Yoo. Dynamic ransomware protection using deterministic random bit generator. 2017 IEEE Conference on Application, Information and Network Security (AINS), Miri, 2017, pp. 64-68. doi: 10.1109/AINS.2017.8270426, 2017. 39, 40, 47 [hm] https://github.com/matt msft. Filter drivers microsoft github.

43 Bibliography

https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/what-is- a-file-system-filter-driver-. 14 [Hud17a] Ted Hudek. Preparing a computer for manual driver deployment. https://docs.microsoft.com/en-us/windows- hardware/drivers/develop/preparing-a-computer-for-manual-driver, 2017. 20 [Hud17b] Ted Hudek. Signing a driver for public release. https://docs.microsoft.com/en- us/windows-hardware/drivers/develop/signing-a-driver-for-public-release, 2017. 20 [Meh15] Shafqat Mehmood. Enterprise survival guide for ransomware attacks. https://www.sans.org/reading-room/whitepapers/incident/enterprise- survival-guide-ransomware-attacks-36962, 2015. 3, 4 [Mica] Microsoft. Access control. https://msdn.microsoft.com/en- us/library/windows/hardware/ff597549(v=vs.85).aspx. 19, 37 [Micb] Microsoft. Device input and output control (ioctl). https://msdn.microsoft.com/en- us/library/windows/desktop/aa363219(v=vs.85).aspx. 19 [Micc] Microsoft. Fsrtlregisterfilesystemfiltercallbacks function. https://docs.microsoft.com/en-us/windows- hardware/drivers/ddi/content/ntifs/nf-ntifs-fsrtlregisterfilesystemfiltercallbacks. 32 [Mic12a] Microsoft. Sc create. https://technet.microsoft.com/en-us/library/cc990289, 2012. 23 [Mic12b] Microsoft. Sc start. https://technet.microsoft.com/en-us/library/cc742126, 2012. 23 [Mic12c] Microsoft. Sc stop. https://technet.microsoft.com/en-us/library/cc742107, 2012. 23 [Mic17a] Microsoft. Access control. https://msdn.microsoft.com/en- us/library/windows/hardware/ff597549(v=vs.85).aspx, 2017. 19 [Mic17b] Microsoft. Devicelocontrol function. https://msdn.microsoft.com/en- us/library/windows/desktop/aa363216(v=vs.85).aspx, 2017. 19 [Mic17c] Microsoft. Ioiswdmversionavailable routine. https://msdn.microsoft.com/library/windows/hardware/ff549382, 2017. 20 [Mic18a] Microsoft. Pflt_post_operation_callback callback function. https://docs.microsoft.com/en-us/windows- hardware/drivers/ddi/content/fltkernel/nc-fltkernel- pflt_post_operation_callback, 2018. 34 [Mic18b] Microsoft. Pflt_pre_operation_callback callback function. https://docs.microsoft.com/en-us/windows- hardware/drivers/ddi/content/fltkernel/nc-fltkernel- pflt_pre_operation_callback, 2018. 34 [OA18] Danny Hendler Or Ami, Yuval Elovici. Ransomware prevention using application authentication-based file access control. In Proceedings of ACM SAC Conference (SAC’18). ACM, New York, NY, USA, Article 4, 2018. 41, 47 [Sic10] Steven Siceloff. Shuttle computers navigate record of reliability.

44 Bibliography

https://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_shuttlecomputers.html, June 2010. 2 [TH17a] Duncan MacMichael Ted Hudek. Irp_mj_directory_control. https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj- directory-control, 2017. 31 [TH17b] Duncan MacMichael Ted Hudek. Irp_mj_query_information. https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj- query-information, 2017. 31 [TH17c] Duncan MacMichael Ted Hudek. Irp_mj_query_volume_information. https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj- query-volume-information, 2017. 31 [TH17d] Duncan MacMichael Ted Hudek. Irp_mj_set_information. https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj- set-information, 2017. 31 [TH17e] Duncan MacMichael Ted Hudek, Andrew Kim. Irp_mj_read. https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj- read, 2017. 31 [TH17f] Duncan MacMichael Ted Hudek, Andrew Kim. Irp_mj_write. https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj- write, 2017. 31, 33 [TS17] Windows Driver Developer Doc Team Tim Sherer. Irp major function codes. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/irp- major-function-codes, 2017. 17 [WDDDT17a] Matt Windows Driver Developer Doc Team. Creating an inf file for a file system filter driver. https://docs.microsoft.com/en-us/windows- hardware/drivers/ifs/creating-an-inf-file-for-a-file-system-filter-driver, 2017. 22 [WDDDT17b] Matt Windows Driver Developer Doc Team. Load order groups for file system filter drivers. https://docs.microsoft.com/en-us/windows- hardware/drivers/ifs/load-order-groups-for-file-system-filter-drivers, 2017. 17, 18, 48 [WDDDT17c] Matt Windows Driver Developer Doc Team. What determines when a driver is loaded. https://docs.microsoft.com/en-us/windows- hardware/drivers/ifs/what-determines-when-a-driver-is-loaded, 2017. 17 [WDDDT17d] Matt Stroshane Windows Driver Developer Doc Team. Irps are different from fast i/o. https://docs.microsoft.com/en-gb/windows- hardware/drivers/ifs/irps-are-different-from-fast-i-o, 2017. 34 [WDDDT17e] Tim D. Sherer Windows Driver Developer Doc Team. Device configurations and layered drivers. https://docs.microsoft.com/en-us/windows- hardware/drivers/kernel/device-configurations-and-layered-drivers, 2017. 19 [WDDDT17f] Tim D. Sherer Windows Driver Developer Doc Team. Introduction to standard driver routines. https://docs.microsoft.com/en-us/windows- hardware/drivers/kernel/introduction-to-standard-driver-routines, 2017. 17 [WDDDT17g] Tim D. Sherer Windows Driver Developer Doc Team. Irp_mj_cleanup. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/irp-mj- cleanup, 2017. 31, 33

45 Bibliography

[WDDDT17h] Tim D. Sherer Windows Driver Developer Doc Team. Irp_mj_close. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/irp-mj- close, 2017. 31 [WDDDT17i] Tim D. Sherer Windows Driver Developer Doc Team. Points to consider when adding drivers. https://docs.microsoft.com/en-us/windows- hardware/drivers/kernel/points-to-consider-when-adding-drivers, 2017. 20 [WDDDT17j] Tim D. Sherer Windows Driver Developer Doc Team. Standard driver routine requirements. https://docs.microsoft.com/en-us/windows- hardware/drivers/kernel/standard-driver-routine-requirements, 2017. 17 [WDDDT17k] Tim D. Sherer Windows Driver Developer Doc Team. Types of wdm drivers. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/types- of-wdm-drivers, 2017. 15, 47 [WDDDT17l] Tim D. Sherer Windows Driver Developer Doc Team, Dun- can MacMichael. Irp_mj_create. https://docs.microsoft.com/en-us/windows- hardware/drivers/kernel/irp-mj-create, 2017. 31, 33 [Woo16] Symantec Paul Wood. Internet security threat report. Volume 21 April, https://www.symantec.com/content/dam/symantec/docs/reports/istr- 21-2016-en.pdf, 2016. 2 [Zwa10] Viviane Zwanger. An introduction to writing tdi ﬁlter drivers. http://seclab.tuwien.ac.at/papers/Writing_TDI_Drivers.pdf, 2010. 20

46 List of Figures

1.1. Punycode example for fake google.at ...... 5

2.1. Sample output when browsing the microsoft.com website ...... 7 2.2. Sample output from a Windows 8.1 System ...... 8 2.3. Sample dll usage output from a VboxTray ...... 9 2.4. Application restriction policy ...... 11

3.1. Typical driver for a device [Baz17c] ...... 15 3.2. Enhanced driver model for a device [WDDDT17k] ...... 15 3.3. Software driver [Baz17c] ...... 16 3.4. Bus driver [Baz17c] ...... 16 3.5. Detours Overview ...... 24

4.1. Project structure ...... 27 4.2. Windows Driver - Project types ...... 30

5.1. Redemption overview [AK17] ...... 39 5.2. Random value generation process [HK17] ...... 40 5.3. AntiBotics system structure [OA18] ...... 41

47 List of Tables

3.1. Load Order, priority is from bottom to top [WDDDT17b] ...... 18

48 A. Appendix

Link to the sourcecode used for this thesis: http://c4.at/master/Master_Projects.zip