SimWitty Internship: Week 11

Well I'm finally here with this week's post. Better late than never is what they tell me. This week and last week were sort of a combination or crossover. First I had to set up a method to monitor change, then I had to try running actual exploits and save information that might indicate a compromise. The two haven't totally come together yet because my first attempt at exploit was only able to get into a non-admin process. I could see changes in memory usage but nothing very exciting. As I research how to increase privileges and pivot from the original machines, I hope to have more to report.

The first exploits I ran were to simulate client side attacks. One involved creating a malicious pdf file with Metasploit and opening it on the victim machine. This was meant to simulate a malicious email attachment. The other involved setting up Metasploit to serve up a malicious web page. This would simulate someone clicking on a malicious link, either within an email or on a web page. The exploits that I tried were:

        pdf

• adobe_utilprintf
• adobe_flatedecode_predictor02
• adobe_geticon
• adobe_jbig2decode (process)
• adobe_jbig2decode (seh)

      browser

• ms10_002_aurora
• ani_loadimage_chunksize
• ie_createobject

The machines I am attacking are both XP Pro SP2. The browser is IE6 and the version of Acrobat reader is 8.1. The users that executed the exploits were both non-admin. The exploits that worked were the jbig2decode and ie_createobject. Since the users were not running in administrator accounts I wasn't able to accomplish much. I was able to migrate to processes that they owned. I couldn't steal any tokens to escalate my privileges, so I couldn't migrate to any other processes. I could read and write within my own directory areas. I could read the registry but not write to it (at least not hlkm).

I can now see the proof that it is a good idea to run as non-admin. This week's work will involve trying to find a way to increase my privileges and pivot the attack to other machines on the internal LAN.

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.

SimWitty Internship: Week 9

I finished the lab installation/setup documentation this week. It came in at 21 pages and hopefully will work for anyone wishing to duplicate the lab. The document can be seen here [Word doc]. I also came up with a series of 6 tasks to fulfill the lab. Here is the basic list of remaining tasks:

1. Set up exploits and get a baseline of the systems.
2. Execute the exploits and investigate results.
3. Investigate methods to pivot within the LAN.
4. Attempt to compromise other machines.
5. Investigate results of monitoring.
6. Finalize documentation of lab results.

More details on each task can be seen here [Word doc].

I also did a slight revamp of the network design. The "internet facing" domain controller is now using a VirtualBox NAT interface rather than bridged. This will make scanning of the LAN from the outside much more difficult, more accurately simulating a well firewalled corporate LAN. I also moved the database services off of the domain controller and onto the Snort server. I think this more closely mirrors the real world.

SimWitty Internship: Week 8

This week's blog isn't going to be real verbose. My two main tasks the last two weeks have been to come up with an actual plan of attack and to document a standard for the installation of all components of the lab. I am going to have to go a bit past deadline on this one, as creating good documentation is a lot of work.

The good news is that I have figured out my connectivity problems and can now reliably connect from the internal network to the external network. This bodes well for the actual successful completion of the lab.

As far as the actual attacks go, I am keeping it pretty generic. I am going to use Metasploit to produce simulated client side attacks. The internal network has two workstations. One of these will get a malicious document attached through simulated email and the other will get a malicious web link through simulated email. The goal of the attacks is to see what kind of pivot can be made into the internal network. The preferred method of attack will be through the use of meterpreter sessions due to the fact that they are the stealthiest and would be the sweetest to detect.

The documentation is the hard part. Even on a small simulated network with two servers and two workstations there is a ton to write. I have to cover installation of the server OS, the workstation OS, the installation and configuration of Active Directory and other server roles such as: DHCP, DNS, and RRAS. Once that is documented I have to install, configure, and document SQL Server 2008 and Snort.

One thing I will post up here on the blog, because it could be useful to others, concerns the Server 2008 OS and automatic activation. Microsoft offers the OS as a 60 day trial which can be legally "rearmed" three times before it has to be activated. This is a great feature, and wonderful for learning and testing. The problem with this is that the OS is set up to automatically go online and activate itself three days after the first logon. You can see this by looking at the system properties (start, right click computer, choose properties). This is very problematic in a lab environment, since you may well be wiping and reinstalling as you make mistakes and learn from them.

In searching for a solution, I saw many people who said that if you didn't enter a product key during install, then you wouldn't have the activation problem. The problem with this is that I was never presented with an opportunity to insert my product key during the OS install. Well, after lots of searching I found a solution on technet (http://technet.microsoft.com/en-us/library/cc770903%28WS.10%29.aspx). There is a registry setting that controls this behavior. The key is at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL\Activation look for the value Manual and change it from zero to one. You can see the effects immediately when you reopen system properties. The windows activation section should now show 59 days left til activation. To rearm the counter, you can use c:\windows\system32\slmgr.vbs If you read this file in notepad, you will see the different switches that can be used.