Great talk from Derbycon 2012

Some great advice from John Woods about managing an infosec team

The Analytical Process

Maybe I watched too many episodes of Sherlock on the BBC or really am too left brained for my own good. But, I wanted to create a post that served as a quick visual and written overview of how to analyze security events. The steps can be applied to just about anything, from fixing a problem on your car to investigating a murder. The steps are based loosely on Sniper Forensics by Chris Pogue

The 4 principles of analysis, based on the Alexiou Principle

1. What question are you trying to answer?
2. What data do you need to answer that question?
3. Where do you go for the data?
4. What does the data tell you?

“When selecting a hypothesis, the one that makes the fewest number of new assumptions is more likely to be correct.” -  Occam’s Razor

9 steps for analyzing events

1. Define normal
2. Recognize abnormal
3. Question
4. Study the attacker
5. Study the target
6. Analyze the data
7. Discard the irrelevant data
8. Apply logic
9. Provide analysis

  

The 9 steps in detail

1. Define Normal
 Determine what normal messages, events and alerts look like in the SIEM.

2. Recognize Abnormal
Once you can recognize normal traffic, you can filter it out. Anything left over is abnormal and is worth investigating.

3.     Question
What event or message are you seeing? Why is it abnormal? Who is the attacker? Who is the target? When did it occur?

4.     Study the Attacker
Who is the attacker? What information can we find out about them? What are they doing?

5.    Study the Target
Is the target system compromised? Is it behaving suspiciously? Is there any abnormal traffic originating from it? What OS and applications are running?

6.     Analyze Data
What do our logs and packet captures show? What was found online? What vulnerability were they attempting to exploit?

7.     Discard Irrelevant Data
What's not needed? Get rid of useless facts and noise.

8.     Apply Logic
What does our data tell us? Allow the data to form the hypothesis; don’t disregard the data for an assumption.

9.     Provide Analysis
What did the data show? Was there an event or a false positive? Form your analysis with as many facts as possible.
 

Step 5 - Escalation

Now that were on our target we need to escalate to root privileges. First step was to edit that shadow file

Now you can run John against the hash or we could just copy pirrips and overwrite the root password, which is what I did in this example

Lets see if it works

Step 4 - Penetration

We successfully logged in using pirrips private/public rsa keys. Lets take a look at the /etc/passwd file for fun

Notice that Pirrip is in a different group from magwitch and havisham. From here I was stuck for a little while. I tried unsuccessfully to download the /etc/shadow file using ssh.

So I decided to start looking around the box and see if there are any interesting directories or files. I ended up  looking at the /var/mail directory

Hmm email. Maybe theres some good stuff in there...

Hey check that out, theres pirrips password!

Step 3 - Enumeration continued

I didnt know you had to manually do this but Nikto wouldnt scan the users directories on its own, I had to manually specify this using the -r switch

Nothing too interesting right there, lets move onto the next user

Look at that! Pirrip has the .ssh directory available. Lets browse to it and see what's there.

Wow, we can download the users private and public keys. Remember our Nmap results from earlier? The server is running OpenSSH which uses RSA for cryptography. RSA uses 2 keys a public and private key. If an attacker gets a hold of your private key it is very very bad. They can assume your identity and login without needing to supply your password. Lets grab those RSA keys.

I downloaded both keys and put them in my home /.ssh directory We need to chmod the files so they have the correct permissions

Now lets try to login using pirrips keys

Step 3 - Enumeration

Now that we know there are some web servers running and other services lets see what we can find out about them.

We can use wget to download that page to our box so we can extract some of those email addresses.

Lets cut that file so we only show user id's

Great! Now we have user ID's we can test with. I also ran Nikto against this host to see what we could find out.

Nikto shows that this server might be susceptible to directory indexing. I used Dirbuster to see what I could find out.

Dirbuster didn't return anything interesting when I scanned the .100 target. But look what it showed on the .101 box

It looks like our UserID list we made earlier wasn't entirely accurate. I edited it down to only inlcude the names found in the dirbuster report - pirrip, havisham, magwitch

I tried browsing the ~pirrip directory on the web server but there were no files found

Step 2 - Scanning

Lets take a closer look at the .100 and the .101 boxes

I forgot to take a screen capture of the .101 box but it was running apache on port 80

Step 1 - Footprinting

Lets get started, the scenario just said that we are looking for boxes in the 192.168.2.X range. Lets run nmap and see what hosts pop up

As you can see we 3 hosts identified. I already know the .154 is my box so we should take a look at the .100 and the .101 boxes

De-Ice level 2

Now that I finished up the level 1 cd I decided to try the level 2 image. Heres the scenario for this one

SCENARIO 
The scenario for this LiveCD is that you have been given an assignment to test a company's 192.168.2.xxx network to identify any vulnerabilities or exploits. The systems within this network are not critical systems and recent backups have been created and tested, so any damage you might cause is of little concern. The organization has had multiple system administrators manage the network over the last couple of years, and they are unsure of the competency previous (or current) staff2 

Ill be using VMWare again to host my attacking box and the vulnerable image

Step 5 - Escalation; owning root

Now that we have a higher level account with aadams lets see if we can finally view the etc/shadow file

Hmm what did I do wrong? Oh, lets try to sudo first and see if that works

There it is. The password for root. Pretty clear isnt it? Wait, its encrypted. Of course. Lets take a look at the different fields in the shadow file, focusing just on root. Each field is separated by a colon :

Login name
Encrypted password
Days since Jan 1 1970 that the password was last changed
Days before password may be changed
Days after which password must be changed
Days before password is to expire that the user is warned
Days after password expires that the account is disabled
Days since Jan 1 1970 that account disabled
A reserve field

Now I copied the entire field for root and pasted it into Kate. Im sure you could download the shadow file to your attacking pc, but this was easier

Now that I have the encrypted password for root I needed a way to decrypt it. I used John for this

And there we go. We now have the root password for our target machine

Step 5 - Escalation

Now that we have a user name and password we can begin working on getting root access

The first step I took was checking out the /etc/passwd file. I wanted to see what other usernames were valid and to see what other information I could gather. Lets take a look at the file

We can see that the user accounts of aadams, bbanter and ccoffee all exist on this server. The passwd file might look a little intimidating at first but its pretty easy to break down. The first field contains the username followed by the password field. This is ually just a * as the passwords are encrypted and stored in the shadow file. The next field is a number which represents the User-ID. In our case bbanter has a UID of 1001

Next is the Group-ID. We see that bbanter and ccoffee both have a GID of 100. Notice the aadams account has a GID of 10.

After the group ID is the GECOS field which stores various user info followed by their home directory information.

 Lets try to gain access to aadams account

The first tool I used was BruteSSH

I let BruteSSH run for awhile but I was impatient so I killed the process and tried to use THC-Hydra

When I ran hydra I had a strange output saying it couldn't connect to port 22. I later found out that hydra was running too fast and I needed to add the -T switch and specify the number of login attempts to 8 at a time or less

I then ran into another issue with Hydra. It always quit before going through the entire wordlist and never found the password. After some research I found that Hydra version 5.9 was having a problem with its SSH module. I had to download version 6.1 to get it to work.

After installing and running version 6.1 hydra found the password in under 10 minutes