I'm proud to announce that I was invited to deliver I'm your MAC(b) Daddy at SecTor 2011 as well as take part in a full day of training for the Royal Canadian Mounted Police. If you haven't heard about SecTor, read here. It's Canada's largest security conference and is described as "The Canadian DEFCON"
I feel honored to have my talk accepted and I'm looking forward to meeting new peeps.
Hope to see you there!
Saturday, October 15, 2011
Tuesday, August 16, 2011
I'm your MAC(b) Daddy at DEFCON 19
It's hard for me to believe that I haven't updated this blog sine March 26th. The last 5 months may have been the busiest of my entire life. Three members of my team(including me) worked a nationwide breach on over 80 locations all using the same Point of Sale software. I also submitted to, and was accepted for two conferences. DEFCON 19 and SecTOR in Toronto. I have been working diligiently to make sure my presentation slides were clear and up to date and to make sure I was ready to get up there and speak in front of hundreds of people. I'm making excuses for myself here, the better thing is probably just to get on with it.
For a little background on Timestomping and why attackers are doing it, see Chris's post "Timestomping is for Suckers".
I presented a talk on Supertimelines and identifying anti-forensics at DEFCON this year. Aside from some minor issues trying to pull off a live demo, the talk went pretty well. I had the unceremonious duty of sharing a time slot with Dan Kaminsky so I’m very happy that I managed to fill 2/3 of the room. I’ve already started receiving a number of questions, links to others research and a number of other queries related to MAC(b) Daddy. Keep them coming, I’m more than happy to help out where I can.
I am presenting MAC(b) Daddy again at SECTor in October. Once that conference is over I will post the full content here on my blog.
The first communication I received was a link to a blog that was exploring different Timestomping methods using the Windows Powershell and the timestomp utility I mentioned in my talk. There is some great research and concise info about manipulating timestamps. The link was sent to me as a “Hey, this guy was able to modify the $MFT, and you said that couldn’t be done” Well, sort of. What I’m saying is that the $File_Name attribute can’t be modified by anything known, the blog above proves my point. Manipulation of the $Standard_Info attribute is, dare I say, easy?, at this point. The second set of attributes in the $MFT is still untouched by timestomp, powershell, perl scripts….anything. By comparing the two you can see the changes made to the system by these measures.
Directly after the talk I was approached by two Chinese gentleman that had a number of questions about trying to modify the $MFT with a kernel mode driver. I asked, “Why, what are you working on?” They replied with a smile and said “nothing”. This is DEFCON after all. This is certainly an interesting project but one that would require extreme caution. Modifying the $MFT on the fly could be extremely detrimental to a system. Move the file table entries by one block and you just turned your system into a brick. Not to mention that you would gave to query a protected file, make the change, leave the sequence number undisturbed and release the $MFT before the system itself tried to write to it again. Past experience suggests that you have 10 – 15 milliseconds to perform these actions.
Third, and maybe the most fulfilling for me, I was contacted by another forensicator who is working on a homegrown utility for parsing the $MFT and auto-comparing the entries for time anomalies. This functionality is included in the latest version of Log2Timeline as well. I have not used this particular module yet but I plan to in the next couple of weeks. His questions related to some anomalies in a number of the core OS files (like ntldr). I am by no means an expert here, but the way I understand the anomalies in these files follows: One of the only ways to actually pull off any “manipulation” of the $F_N attribute is to create a file on a second volume (D:\), modify the $S_I timestamps, and then move that file to the main volume (C:\). In this case the M attribute of $F_N will match the M attribute of the moved file. The same does not hold true for the B attribute, which creates a whole other anomaly in of itself. When we are talking about these core OS files, I think there are two things going on here.
1) The system isn’t a system yet, it has not gotten to the point where the system time has been determined. This is the same reason that you see registry entries in a supertimeline start in 1969 and 1970. The system has no baseline to set those registry write times to and the possibility exists for the same issue with the $MFT.
2) These files are not being created out of thin air, they are being moved from another volume (The install CD/DVD) and some of the timestamps from when this code was written is being maintained.
I promised the crowd to start updating my blog more frequently in support of MAC(b) Daddy. So here I am, a man of my word.
More as the questions and comments flow in.
Saturday, March 26, 2011
Windows Registry Forensics-Review
I read Harlan Carvey's "Windows Registry Forensics" on a flight to Florida last week so I thought I'd write up a little review.
If you haven't already read "Windows Forensic Analysis" I highly recommend you do so.
First of all I have a tremendous amount of respect for someone who is willing to put their thoughts to paper when it comes to digital forensics. It's a very difficult topic because things are always evolving. It also takes a tremendous amount of time to write a book, I'm trying to help a buddy with just a few chapters in a book he started and it's extremely difficult.
I will admit that I was expecting a little more book when I first purchased it, the registry is such a large piece of the Windows OS that I really thought the book would be encyclopedic. That being said, I was not disappointed by the content.
The book is layed out in 4 chapters: Analysis, Tools, Case Studies:System and Case Studies: User tracking.
The Analysis chapter covers the binary structure of the registry as well as it's main purpose to the operating system and to the users. A considerable amount of this section was review for me (ten years of sysadmin work) but I've never read anything that tears down into the physical on-disk structure of the registry at the lowest level. Harlan obviously spent some time in this section tearing the registry down to it's nuts and bolts.
The tools chapter: If you don't read Harlan's blog or keep up with who is doing what in the industry you'll be expecting him to spend 50 pages talking about EnCase. Instead he uses the chapter to talk about a myriad of other tools which are just as useful if not more so than EnCase. He spends a fair amount of time explaining his own Perl tool "Regripper" and how it came to be as well as encouraging readers to develop their own plugins for regripper. I personally use regripper on every case I work so I know how useful it is and have spent a fair amount of time trying to figure out how it odes what it does. The book helped explain a little bit of the "behind the curtain" thought process that went into it's design.
Case Studies: System. Here's where the book starts to really pick up. 72 pages of nuts and bolts and "Here's why I've spent the last 150 pages explaining all this crap to you." I read this section twice. The registry contains so much information about the state of a given system that it is imperative a good investigator knows what they are looking at, what is normal, and why. After reading Harlan's case studies I have a better understanding of the pieces I already knew about and some insight into other chunks of the registry that have never caught my eye. Excellent chapter.
Case Studies: Tracking user activity. The most useful chapter in the book! I am familiar with registry artifacts found during an investigation. For the most part I know how to use those artifacts to forward or disprove a theory. Even with that knowledge this section caught me off guard with how little I really know. Especially good was the dissection of all the areas of the registry that can be used for malware persistence and the write up on "shellbags". I have run across these artifacts a dozen or more times in my supertimelines but never payed them all that much attention, I knew that they represented user activity of some kind, but it didn't seem related to any type of malicious activity. Now I know that I was correct in my assumption but I also know that those shellbags are definitive proof of an interactive session.
All in all, I enjoyed reading the book. Harlan keeps it personable while maintaining an air of technicality. So many books like this are so dry that they can't be read for more than 15 minutes. Not so in this case. I have absolutely no regrets on the purchase price and just like "Windows Forensic Analysis" I will be referring to this book for years to come and I'm glad I have it as a resource.
If you haven't already read "Windows Forensic Analysis" I highly recommend you do so.
First of all I have a tremendous amount of respect for someone who is willing to put their thoughts to paper when it comes to digital forensics. It's a very difficult topic because things are always evolving. It also takes a tremendous amount of time to write a book, I'm trying to help a buddy with just a few chapters in a book he started and it's extremely difficult.
I will admit that I was expecting a little more book when I first purchased it, the registry is such a large piece of the Windows OS that I really thought the book would be encyclopedic. That being said, I was not disappointed by the content.
The book is layed out in 4 chapters: Analysis, Tools, Case Studies:System and Case Studies: User tracking.
The Analysis chapter covers the binary structure of the registry as well as it's main purpose to the operating system and to the users. A considerable amount of this section was review for me (ten years of sysadmin work) but I've never read anything that tears down into the physical on-disk structure of the registry at the lowest level. Harlan obviously spent some time in this section tearing the registry down to it's nuts and bolts.
The tools chapter: If you don't read Harlan's blog or keep up with who is doing what in the industry you'll be expecting him to spend 50 pages talking about EnCase. Instead he uses the chapter to talk about a myriad of other tools which are just as useful if not more so than EnCase. He spends a fair amount of time explaining his own Perl tool "Regripper" and how it came to be as well as encouraging readers to develop their own plugins for regripper. I personally use regripper on every case I work so I know how useful it is and have spent a fair amount of time trying to figure out how it odes what it does. The book helped explain a little bit of the "behind the curtain" thought process that went into it's design.
Case Studies: System. Here's where the book starts to really pick up. 72 pages of nuts and bolts and "Here's why I've spent the last 150 pages explaining all this crap to you." I read this section twice. The registry contains so much information about the state of a given system that it is imperative a good investigator knows what they are looking at, what is normal, and why. After reading Harlan's case studies I have a better understanding of the pieces I already knew about and some insight into other chunks of the registry that have never caught my eye. Excellent chapter.
Case Studies: Tracking user activity. The most useful chapter in the book! I am familiar with registry artifacts found during an investigation. For the most part I know how to use those artifacts to forward or disprove a theory. Even with that knowledge this section caught me off guard with how little I really know. Especially good was the dissection of all the areas of the registry that can be used for malware persistence and the write up on "shellbags". I have run across these artifacts a dozen or more times in my supertimelines but never payed them all that much attention, I knew that they represented user activity of some kind, but it didn't seem related to any type of malicious activity. Now I know that I was correct in my assumption but I also know that those shellbags are definitive proof of an interactive session.
All in all, I enjoyed reading the book. Harlan keeps it personable while maintaining an air of technicality. So many books like this are so dry that they can't be read for more than 15 minutes. Not so in this case. I have absolutely no regrets on the purchase price and just like "Windows Forensic Analysis" I will be referring to this book for years to come and I'm glad I have it as a resource.
Sunday, February 27, 2011
PCAnywhere or "Here Hacker, Hacker"
Let me start by apologizing to anyone that was enjoying fresh, regular content from my blog. I haven't written a new post in several months
I am not without reason. Starting a new job and getting used to the way things are done on a new team is time consuming and can require a lot of focus. A wise man once said: "If you don't know what you're doing, do it neatly" It doesn't fit entirely, but the learning curve has been steep, and my first few cases were worked through slowly, carefully and methodically.
This is not to say that my next cases will be worked any less carefully, but I've found you develop a rhythm in an investigation and you have to let the evidence lead you down the path to the answer.
Case in point:
I have already had a number of POS breach cases where PCAnywhere was the point of intrusion. I will focus on 2 for the purpose of this blog. These 2 cases were similar in that they were both running the same type of POS software and it was set up by the same integrator.
PCAnywhere is a 2 part remote administration utility that has been around for a number of years. I don't know exactly when it came out but I remember running into it as a system administrator at least 7 years ago. It has gone through a number of version upgrades over the years and the latest stable version is v 12.5. The 2 parts are the client, which is usually used by the remote administrator to make a connection to a remote PC or server for maintenance. The second part is the listener which (obviously) resides on the client machine that is to be remotely managed. Here's a list of the versions and the port usage (by version) from Symantec:
I have used numerous pieces of PCAnywhere evidence in my cases.
The first is the connection logs. By default they are located in %SystemRoot%\Program Files\PCAnywhere and have a .pl9 extension. These logs are extremely configurable in the software itself. They are easily viewed by using a registered copy of PCAnywhere or by downloading a trial from Symantec. These logs could contain anything from a basic timestamp and a connection attempt ,to full Windows Event Logging and verbose connection details to include connecting IP, user id info, files transferred, etc. For a full list of logging options, see this site. Obviously these logs are very useful to an investigation. Unfortunately, they are rarely verbose and in many cases I have found that logging is not even enabled.
I have a problem with this. ADMINISTRATORS: IF YOU ARE GOING TO OPEN A GAPING HOLE INTO YOUR CLIENT"S ENVIRONMENT, AT LEAST HAVE THE DECENCY TO PUT IN A STRONG PASSWORD AND SWITCH ON THE LOGS! Yer killin' me. You're also costing your clients tens of thousands of dollars.
There are also a number of vulnerabilities related to the older versions of PCAnywhere. Search the CERT website to read further on them all. US-CERT Site. One of these older vulnerabilities allowed you to pass the listener a message that says your login type is "0" Which allows you to log in with full admin credentials using a null username and password. That's Kwality there.
A bit more in depth is a file that I have found extremely useful that you probably don't know about. When you log in using the graphical interface a file called aw.swp is generated. This file is a cachefile that is created to speed up Windows operation. It is used every time you use the remote desktop via PCAnywhere. This leaves a nice trail of birth, modified and access times in the system timeline. I even found evidence of card-holder data being moved in the aw.swp file. My assumption is that the built-in PCAnywhere file transfer button was used to move a file containing captured data. No one at Symantec ever contacted me back on this issue.
Nothing ground-breaking here. It just goes to show that some of the most common applications leave behind some very definitive evidence. Sometimes you just have to dig around a little bit for an explanation of why.
I'm putting the finishing touches on a presentation for this years round of conferences. It's called "I'm your MAC(b) Daddy" and focuses on using super timelines to solve breach cases. I will post it here if I don't get accepted. I also have a post on generating timelines for filesystems that are not supported by fls and mactime.
New updates soon. Thanks for stopping by.
Subscribe to:
Posts (Atom)