Wednesday, December 17, 2008

The Story of an Insider - Part 3. Playing at CSI

If you're reading this you may have already read the Intro, Part 1 and Part 2. If not this might make more sense if you do. I would also like to add that the techniques I use here to acquire and examine the data are those that a normal Systems Administrator might use. The practices described here are probably not forensically sound.



Playing at CSI

Okay, so my manager has explained everything to Pete and has given me written permission to look at Pete's PC. Pete has also said that he was happy for me to look around his desk area. At the moment it may be nothing more than a virus or malware that has caused the log entries, but I need to be sure. My approach is to recapture the volatile data from the PC using a script similar to what I ran before. This time I use known good executables from a CD which is Read-Only media. I save the output to a network share as I want to make as little change as possible to the PC. After getting the volatile data off I'll image the PC and then create a VM from the image to look at further.

The output was pretty similar to what I got before when I ran the tools remotely although the connections through Netstat were different but that is to be expected.

I'm pretty sure that there is no virus on the PC so now I'm guessing that the PC has been used to gain access to restricted files in the Design share on File-Server.

Now I have the volatile data off the PC I want to make an image of the drive and use that for further examination, that way I can isolate this PC off the network and get back to my office for a well earned coffee.

I insert my Helix CD and attach my Western Digital portable hard drive to allow me to capture the DD image. Going to the Live Acquisition menu I select my source and destination and give the image a name.

Now I wait till the image is copied to the Western Digital Drive.

>


As soon as that is finished I check the log and the MD5 sums in the image folder and then I pull the plug on the PC and secure it until we get to the bottom of this issue.


Back in my office I make a copy of the DD image I have created and save it somewhere safe, that's just encase I screw up the one I'm working from. Now I use Live View to create a VM from the image that I can boot into to examine further.



Before I browse to the folder where I generated the cofig and double click the VMX file to boot into the VM I point the CD to a Helix ISO so I can use some other tools from the disk.



The system boots up and straight away I see that the last user logged in was MarkP, the Design Manager. Well now I know without doubt that the last account used was Marks.



I contact Mark and get his password, this makes life a little easier for examining the registry. If Mark wasn't available to give me his password I would have logged in as a local admin and likely used RegRipper to analyse the NTUSER.dat file. Luckily at this stage I don't have too.

I examine the recently used files and can see nothing untowards, I also create a list of all the files on the PC and pipe it out to a file on the same external WD hard disk. This is done for hidden files as well.

C:\Dir /s *.* > E:\gt-buy-01-files.txt

C:\Dir /s /a:h *.* > E:\gt-buy-01-hiddenfiles.txt

After searching through the text files I find nothing from the Design Share. This is frustrating, I'm sure that data has been downloaded because the NBTSTAT data from my remote volatile data collection indicated that some pretty big data transferes had been made.

I start Helix using RunAs and kick it off with local admin privileges.



As soon as Helix is running I check the processes again using the CD tools and just as I thought it's the same as before, nothing suspicious. I run PC Inspector File Recovery from the Helix CD. This will allow me to find deleted files on the PC.

And what do you know, here are some of the GNUphone design files, I recover them and as expected they are the same as in the Design share on the server.




The thing is, at this stage I don't know if Pete has just accessed the files and deleted them, or has he emailed them somewhere or copied them? I recheck Internet logs, look through his mailbox, checking the sent emails, the deleted and the deleted-deleted emails but nothing.

Ok, I'll try another useful tool from the CD, USBdeview maybe he has copied them to a USB drive. Ah, here we go. I can see 2 devices have been attached, one is the Western Digital USB drive I have been using and another is a HP USB thumb drive that's been attached today.



I search around Pete's desk looking for a thumb drive but I find nothing. I ring my boss to update him and he asks Pete to explain why he had been logged in as Mark and why he had used a USB thumb drive which is against company policy. I can here Pete say that he has no thumb drive and he empties his pockets to prove it.

Whilst he is busy pleading his innocence I Google the product ID and Vendor ID from the device that USBdeview found and it turns out to be a HP IPAQ.



When my boss pics up the phone I tell him that were looking for an IPAQ or Smartphone. Minutes later have a HP IPAQ Smartphone sitting on my desk and permission to search it.


GAME OVER. Sys Admin Wins!


But how did this happen?  Was the Design Manager involved?  Well it would make much sense if he was.  Why wouldn't he just steal the data himself?  

After interviewing the Design Manager it seems that he was very careful with is password. He never wrote it down, changed it regularly and never gave it to co-workers.  I guess then I 'll never know.  I write up my report and recommend that we reapply the password lock-out policy and increase the password length from 8 to 10 characters to make password guessing more difficult.  I'll  also propose regular password audits to identify weak predictable passwords and I email all staff reminding them of the importance of strong passwords and attach the Staff Computer Policy.  Finally I propose that we review our stance on USB devices.  In this day and age nearly everything has some form of storage on it, we need to look at some other way of protecting our data.



I hope anyone reading this has enjoyed it, i have enjoyed writing it and I hope to do more in the new year.

7 comments:

Mike said...

Syn,

Great job! That was a very entertaining read. Please keep up the good work. Happy holidays.

-- Mike

Ken Pryor said...

As always, very good read. I enjoy your work. You do a great job of telling the story.

Regarding Helix, I've used it quite a bit. It's a very valuable resource for sure. I've used LiveView a few times as well. I love trying out these tools and learning about them for my work as well as for fun.
KP

file recovery said...

In order to ensure an effective file recovery, it is necessary to systematically scan the hard drive and the same thing is done by the powerful and efficient file recovery software. You should always opt for a powerful and the most advanced file recovery software to fully recover your data.

Anonymous said...

Great read.

SynJunkie said...

Thanks guys, I appreciate the support.

Happy holidays.

Beau Woods said...

Great series of posts! Definitely a good read and will be useful for others who need to be able to explain security threats to their bosses.

One thing that made me shudder was that the IT guy asked for his co-worker's password. d'oh!

It's usually much better to change the password with AD and then login. That leaves an audit trail as well as keeps his (former) password private. If you're afraid to connect to the network, it should be possible to change the password locally or access the account some other way. But sometimes quick and dirty is the only way to do it.

I hope to see more of these!

SynJunkie said...

Beau

very very good point regarding passwords. No biscuit for Sys Admin on that occasion! ;-)

Thanks for the comment.