A few weeks ago I started looking at Windows Software Restriction Policy (SRP) and using it to stop client side attacks. This is going to go over some of the options, setup and the results once enabled.
SRP is easy to setup via Group Policy Object (GPO). Inside GPO editor create New Software Restriction Policy. Once create the default will be setup. You can look around to see basic options. Here is my tested setup.
Under Designated File types: Remove type LNK – this will make sure that shortcuts placed outside of the designated execution directories will run. When I initially tested what I thought would work none of the shortcuts on the toolbar or desktop would launch an application and I found this to be the issue.
Ignore trusted publishers, this is used if we are limiting applications based on the certificate authority.
The default execution directories will be selected.
Security level for these are all going to be “Unrestricted” I want them to be able to execute as normal.
Now back under “Security Levels” the default setting is Unrestricted, since we are changing users over to defined execution directories I want to set anything not specifically allowed in the Additional Rules section to “Disallowed.” So we change the default to Disallowed.
Save this and run gpupdate /force on the target machine.
Fire it up and wait till it starts the payload handler.
Once the handler is started you are ready to test the attack. Go ahead and run the unsafe java applet.
You will notice that the the site is responding but the java applet is unable to execute the payload.
After attempting this and being successful, I tried running SET with PowerShell Injection and to my surprise the attack succeeded. I realized with PowerShell the payload was running from the C:\Windows\sysWOW64\WindowsPowerShell directory which by default is explicitly allowed. To defeat this attack I added the path to the list of Additional Rules and set it to “Basic User”, retested the attack with PS Injection and the attack failed as expected. I tested this with multiple payloads and encoding methods and everyone of them did not result in a successful attack. On 32bit systems PowerShell is located in C:\Windows\System32\WindowsPowerShell\v1.0\ so that directory will need to be accounted for as well.
I ran two other tests, the first was using EXE embedded PDF and an older version of Adobe Reader (9.3). SRP was able to successfully stop this attack.
Finally I tested a physical attack using a USB Rubber Ducky Human Interface Device (HID) from the folks over at hak5 (www.hak5.com). I used a great little payload generator found over on google code (https://code.google.com/p/simple-ducky-payload-generator/ ) It is pretty slick and simple, I used a meterpreter powershell injection payload that didn’t attempt to elevate privileges. SRP was able to successfully stop this attack. If the user had admin privileges and entered in creds in the UAC window it would have worked since I allow Local Admins unrestricted access.
In Production the are likely other directories where code needs to execute, those will need to be added to the allow list. As the config is done, administrators will be able to bypass these rules for installation of software etc. Administrators will also need to ensure that ACLs are properly set since a curious user could move executables into the approved directories and run them. While this is like a bit tough to implement in a very large organization this is a very effective method for stopping client side attacks.
This will log the executable and the directory it was run from a little data mining can determine were applications need to execute from. Also Inventory Collector from Application Compatibility toolkit can assist in this task.
A few weeks back I was looking for a solution to push backup files off a linux box and push them to google drive. All I could seem to come across was apps to sync with google drive on linux. While this would have worked, I didn’t really need nor want any of the files in my Google Drive on a linux server. So I decided to write my own. This is my first foray into a python application of sorts, I have been doing development in PERL for most of my career. This is also my first attempt at interfacing with an API, and I couldn’t have picked a better project since the Google API docs are excellent!
The code is published on my github account. You will need your own developer API key for it to work since sharing publicly isn’t an option and I haven’t come up with a way to securely pull the API key.
Currently you need to create a file with the API information to connect to google drive. Once you have that, initialize with google to proved authorization to your google drive and it will then allow you to specify a file or directory to push up.
Keep in mind I am a admin not a developer so the code will be written as such. I am working on going back to clean it up.
Do proper verification that upload completed successfully.