SimWitty Internship: Week 10

Goals
This week my goal was to come up with a baseline measurement of critical areas on the machines I will be attempting to breach. I believe there are three critical areas to pay attention to:

The Event Logs
Proper control needed for audit settings/group policy
The File System
Admin must be aware of permissions and able to track changes
Performance Counters
Comparison against baseline may illuminate security problems

Event Logs
The event log system has changed greatly in the post XP world. Starting with Windows Vista there are many different log types and ways to view them. I am almost of the opinion that Microsoft has overdone it and is causing information overload. This is mainly because I am not yet used to the new system; I'm sure once an admin gets familiar with the increased granularity, the new Event system will prove to be a great tool. More visibility is a good thing. There is a good article concerning the new system at http://technet.microsoft.com/en-us/magazine/2008.03.auditing.aspx 

The security log can be of great use in trying to determine if something is going wrong on a system, but it isn't much good if you don't set your audit policy properly. Some of these settings may create too much noise for a real world scenario. The good news is that in the post XP world, you can exert really fine control over audit policy by using the command line tool auditpol.exe... try typing auditpol 
 /list /subcategory:* at the command prompt to get an idea of what's available. Since this is a lab, I am enabling almost all auditing. I will propagate the settings through group policy. I have set up a GPO in active directory to apply to the SimWitty OU that I created.




File System
The file system is another place that you can spot signs of a problem. Obviously, sudden appearance of unknown files or folders could be a sign of a breach. A little less obvious sign could be changes in permissions. You can (on Vista and later) record the file permissions by using the icacls.exe tool. The following command would record permissions for files in c:\windows and below:

  icacls c:\windows\*.* /save Baseline_ACLfile /T
 
You should then be able to redo this whenever you want, and compare against the baseline to see what may have changed (the files are sddl format listings and are unicode text). The benefit of these ACL files is that you can use them to restore permissions. Another (maybe simpler) way to get a baseline is to use a few commands such as:

  dir /s /b c:\windows\*.* > dir_plain_baseline.txt
  dir /s /b /ah c:\windows\*.* > dir_hidden_baseline.txt
  dir /s /b /as c:\windows\*.* > dir_system_baseline.txt

Vista has a new switch for the dir command (/r) that will even show alternate data streams, but it isn't very useful; it shows files with and without ADSs and it breaks when used with the /b(are) switch. Maybe it would be useful within powershell, or with some other additional filtering.

Performance Counters
The performance monitoring capabilities are worlds better in the post XP world. Now called the Reliability and Performance Monitor, this MMC snap-in is a HUGE advance. A data collector set consists of three different modules. It can be created by right clicking user defined under Data Collector Sets and choosing new. After you set some properties, the collector set will appear and you can see the three modules (Performance Counter, Configuration, and Kernel Trace) by selecting the set. Right clicking each module and choosing properties allows you to add the desired counters.

The template I used in Server 2008 adds all counters for processor by default. There were a few more that I thought would be useful, so I added

  \Memory\Available KBytes
  \Memory\Committed Bytes
  \Objects\Threads
  \Objects\Processes
  \Objects\Mutexes
  \Process(_Total)\Virtual Bytes
  \Process(_Total)\Working Set
  \Process(_Total)\Handle Count

Once the trace has been run, the snap-in automatically produces a very slick report. The report can be viewed from within the snap-in, either as a report or graphically by right clicking the report and choosing view, or as an html report with IE.

All the above tools are native to the operating system. By using these tools and setting up a good baseline, I hope to be able to detect any changes that may occur through the penetration testing.