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.
