Quick Background on AppLocker
First, we need to get an insight into what an Applocker is and its mechanism before going through the technical details.
AppLocker is basically a software from Microsoft that grants some users specific privileges while preventing other users from the same privileges. In other words, some users have the freedom to open some particular applications on the operating system whereas some others don’t have the rights to open these applications. For instance, one user could freely run Internet Explorer, and another cannot even open it. Most sensitive machines such as Automated Teller Machines (ATM) and computers inside important organizations all use AppLocker
AppLocker essentially covers five main categories of files:
- Executable files coming in .exe and .com extensions such as ipconfig.exe
- Installer files which are utilized by Windows to get any new software installed on the computer or the machine; such files come in .msi, .msp, and .mst extensions
- Script files which come in .ps1, .vbs, .vba, and .cmd and .js extensions
- Packaged Apps which one installs through Microsoft Store
- DLL files which come in .dll and .ocx extensions
Throughout this article, the main focus is in the common file formats used when talking about security restrictions and privileges using AppLocker. Therefore, I will mostly maintain executable files, installers, and script files.
How to activate AppLocker on your machine
- Open Administrative Tool -> Services
- Get through the Group Policy Editor which differs between one domain controller (gpmc.msc) and on (gpedit.msc) on local machines
- If the last steps did not work, type “Edit group policy” inside the search text box inside the menu bar.
- Under “Security Settings” open “Application Control Policies”
- Press “Configure Rule Enforcement” in order to choose among the five aforementioned application categories, and apply an appropriate filtering accordingly.
- Three main points should now determine the rules which should govern the usage of each of those categories:
a. Execution Path:
By default, all executable files and scripts which reside inside the following two directories “C:\Windows” and “C:\Program Files” are allowed. If this was not the case for such files in these locations, the system would not boot in the first place.
b. Information about the Publisher:
Sometimes AppLocker relies on the vendor’s public key to sign a specific executable file as binary files. Based on this, AppLocker may decide to get such file allowed or denied.–
c. File Hash:
AppLocker stores Message Digest 5(MD5) hashes of executable files, and therefore depends on them to decide whether to allow a certain file or not. Although this aspect requires a great deal of memory usage, it is essential for AppLocker in order to prevent any hazardous executable file from running.
Consider a Standard Setup
When the user doesn’t change any of the default rules over the files, we are left with all the executable files (other than those located at “C:\Windows” and “C:\Program Files”) without the ability of running them anywhere on the machine. This is a problem because for instance, we cannot run Meterpreter.exe.
There is, in fact, a way out of this problem. Think about this way; executable files aren’t allowed to run at several locations inside the machine while other locations don’t prevent running the same executable files. If these latter locations could become known by you, you as a standard user with no admin privileges will enjoy running any desired executable files inside the machine; it seems straightforward, right? Well, it is actually a tedious work to go through each location and investigate it manually to see the applied rules on it. What is the solution then?
Basically, PowerShell script is an appropriate method to automatically identify where it is accessible to write –to run our executable file— This basic installation will let “C:\Windows\Tasks” and “C:\Windows\tracing” writable by everyone.
In order to make the PowerShell show us these files, “Get-Content” and “Invoke-Expression” commands are to be used.
- Once we get to know these files are writable, copy the desired executable file “mimikatz.exe” or “meterpreter.exe” or whatever executable file you want to run on the machine.
- Run the desired executable file now. Note that the reason for having an executable file lies in it simplicity having a certain malware or a custom tool for example. However, it does not require an executable file for an attack; this could be done simply using Invoke-Expression through which we bypass any execution path restriction.
Now, consider this case instead. You have searched for writable directories, and weren’t able to find any. How would you react then? If we could store the executable file that we want somewhere in the memory and then jump to its address/location without the need for any directories, then, we would solve the problem.
- Use a PowerShell variable to store the executable file
- Make use of PowerSploit framework by using its function called Invoke-ReflectivePEInjection. It will load this file into a memory location to which you should jump in order to run the file.
Consider a more advanced Setup
What if the user was aware of the vulnerabilities of the default rules? He rather restricted the usage of cmd.exe and PowerShell.exe to get ascertained that all the previous steps which rely on these applications could never be used.
- Look for something forgotten by the user to be blocked
- In this case, the user took care of all the Windows-64 tools and applied what rules he wished for on them. Still, he overlooked Windows-32 tools, which would be the way to go instead. Simply use the “C:\Windows\SysWOW64\” location to open the PowerShell from where we could manipulate and play around with our executable file as mentioned before.
- Even if we merely search for “PowerShell.exe”, we will find several versions of PowerShell each having its unique hash. There would be still a plenty of PowerShells having hashes other than the blocked one.
- If all of the above-shown instances of PowerShell are blocked along with cmd.exe, there is still a way out.
- Use “C:\Windows\System32\wbem\wmic.exe”. This utility could make us very close to know information about the system. It will not be that easy of course as it was on the PowerShell; nevertheless, it still provides us with an alternative.
Consider a more advanced Setup
The user could be capable enough to block all of the previous methods. Even WMIC cannot run in this case. There is always a way out!
- Note the files of type DLL which are not blocked
- Search for a DLL implementation of PowerShell online
- Download it into any folder
- Run the file using the utility of “C:\windows\system32\rundll32.exe”
- To execute it: type the DLL and its entry point function. In our case, type “rundll32.exe PowerShdll.dll,main”
Try Certified Ethical Hacker for FREE!!!– https://infosecaddicts.com/course/certified-ethical-hacker-v10/
Finally, check out my other article on Transferring files from Linux to Windows (after exploit).