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.




4 comments:

  1. Grayson,

    "The system has no baseline to set those registry write times to..."

    Which Registry keys are you referring to?

    Also, what are the other issues you're seeing with respect to the files?

    ReplyDelete
  2. Grayson

    Thanks for the link back to my post. Wish I could have caught the preso at Defcon but I was unable to attend this year.

    I have been able to manipulate all four $SI and $FN attributes by leveraging the default behavior of user actions on NTFS metadata. Per the wiki from Vinnie Liu's Timestomp utility, moving/renaming the file post $SI manipulation will replace all four $FN attributes with the altered $SI values. Note you have to alter the $SI attributes a second time. I updated my blog with the results of this experiment using powershell here http://securitybraindump.blogspot.com/2010/05/more-experiments-with-master-file-table.html

    Not the sexiest way of doing things but it works. There is a caveat that will allow investigators to detect this however. uSec values of the all eight time attributes are always set to zero (note: have only confirmed this with powershell and timestomp). A great example of this is included in the tech segment I did on Pauldotcom a few months back http://pauldotcom.com/wiki/index.php/Episode236#Special_Guest_Tech_Segment:_Tim_Mugherini_presents_NTFS_MFT_Timelines_and_malware_analysis

    I have seen other manipulation that alters just the dates but not the times but again as you pointed out not all the $FN values were modified. A variant of the Renocide worm I came across is one such example. I posted on it here http://securitybraindump.blogspot.com/2011/05/renocide-worm-hiding-in-plain-sight.html

    I would love to check out the slide deck from the talk. Is it available anywhere?

    Tim
    @bug_bear

    ReplyDelete
  3. @KeyDet89- This blog post has generated enough interest that I am going to write a series of entries on timeline anomalies. I will contact you offline with some examples. You will likely be able to explain them better than me anyways. Specifically I frequently see dates from 1969 and 1970 in (I think) some of the the root hives for HKLM/Security. I don't have one in front of me and I'm on the road. I will fill you in when I get back.

    ReplyDelete
  4. @bugbear - I will read the second post when I get a few minutes, thanks for the links. I'm always looking for new ways to prove myself wrong :)

    I will be posting the full slide deck after SecTor in October.

    ReplyDelete