Making life difficult for malware/pen-testers/**** without installing/paying for more agents/$$$$

I chanced upon this discussion thread: http://www.securityfocus.com/archive/101/522894/30/120/threaded while doing some Googling on Microsoft Software Restriction Policies (or SRP in short).

If you read some of these technical threat research/analysis reports, you’ll notice many intrusions are performed in a multi-stage approach so as to control a machine. After exploitation of a bug or simply execute a backdoor program (without exploiting bugs) in an unrestricted host, the next key step is to drop a file and run it to do more nasty stuffs eg. install a backdoor.

Point 5 is really interesting. In principle, whenever possible, you don’t want to let anyone run anything they please, knowingly or unknowingly. But as we know, Application Whitelisting is not exactly catchy so I was looking for other ways to make it painful for pen-testers and “not-so-advance” malware.

Before knowing about Point 5, I’d spent one day coding a simple Windows service that basically “disable” any executable or script file that the user has write-&-execute access. The idea is simple, we don’t trust any executable that can be modified. In a hardened/restricted environment, the (read-only) programs should be those that are installed by the admin for the users. By limiting privilege access, one may be able to stop users from installing into “Program Files” but there are still plenty of “portable” apps that do not require installation.

I felt a little stupid because a few ICACLS command will get half the job done, but I was glad at the same time since my idea made sense and in principle is trying to achieve what is stated in Point 5. So I started experimenting with Windows 7 DACL using ICACLS commands. Again after a few trial-&-errors, it boils down to this obscure “group” known as “Creator Owner”. Most of us will be familiar with the notion of “Everyone” but “Creator Owner”?!? There’s also something known as “Owner Rights” which I will not digress to explain.

For testing purpose, you may want to try it out with a test folder eg. C:\Test\

icacls c:\test\ /deny “Creator Owner”:(OI)(CI)(X) /T

The line effectively denies the owner execution/traversal (X) and (OI)(CI) will create inheritance of this rule for the specified path. So when you copy/drop an executable or batch file into this folder, you will not be able to execute it and traverse to the folder via command line (but able to browse with explorer).

I did the same command (as admin user of course) on C:\ , C:\Users\ , C:\ProgramData\ and so on. The general idea is to enforce this rule for any path that the user (hopefully you are not giving away privilege user rights like freebies) has write access.

I suppose this is what Point 5 is all about. This is not fool-proof as stated clearly that scripts can still run. We may consider blocking non-technical user-groups from built-in commands like Powershell, NET, CMD and so on to reduce your attack surface. Good luck!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.