Understanding MAC D...
 
Notifications
Clear all

Understanding MAC Dates in Malware case

12 Posts
8 Users
0 Reactions
1,269 Views
(@bdmeyer)
Eminent Member
Joined: 15 years ago
Posts: 36
Topic starter  

I am analyzing an NTFS drive on a machine trying to discover when the malware 'actually' first appeared.

So in the spirit of 'Bottom line up front' I believe that the important date will be for the creation of the folder at 5/13/2011 13246 PM. My reasoning is below for anyone that wants to follow through it.

The malware was initially found via snort and identified as Zeus.
Looking at these MAC dates of the folder and it's two containing files (Zbot and SpyEye) left me somewhat confused


Name Created Accessed Modified
config.bin 5/13/2011 13246 PM 5/17/2011 84635 AM 5/13/2011 13246 PM
usxxxxxxxx 8/11/2004 60025 PM 5/17/2011 84634 AM 5/13/2011 13246 PM
usxxxxxxxx.exe 8/11/2004 60025 PM 5/17/2011 84634 AM 12/9/2010 101509 AM

The 'bin' and 'exe' file are inside the directory.

After reading the Wikipedia and Microsoft explanation of file/folder properties with regards to the date and time stamps
http//support.microsoft.com/kb/299648

I have to suspect that the folder creation date is fake.
I also firmly suspect that the modified date of the exe is not indicative of when the file had a property change on this machine.

I guess the bottom line to my question is, so I don't repeat this confusion on every case where I have to state to the best of my ability when a specific file appeared on a machine would be, What resource might I read that is very straightforward without getting deep into the bowels of the NTFS API where I can determine this?

I have white boarded this, created, copied, and moved files and folders and looked at the resultant changes, and am just not certain.

My conclusion so far, which will probably change in the morning after I clear my head is

Explanation of dates above
Name Created Accessed Modified
usxxxxxxxx 8/11/2004 60025 PM 5/17/2011 84634 AM 5/13/2011 13246 PM
This folder must exist prior to files being placed inside it.
The folder is created at 5/13/2011 13246 PM

A file dropped into this folder is
Name Created Accessed Modified
usxxxxxxxx.exe 8/11/2004 60025 PM 5/17/2011 84634 AM 12/9/2010 101509 AM
The File 'Create Date' is likely bogus and can't be determined with this info.
The files was likely copied for distribution on the 'Modified' date.
The file was likely dropped into the usxxxxxxxx folder on the 'modified date of the containing folder.'

The next file was likely created at the 'created' date.
It was likely last accessed in the 'Accessed' date, one second after the executable which would make
sense as it is described as the configuration file for EyeSpy, a file dropped by Hiloti (The executable.)
Name Created Accessed Modified
config.bin 5/13/2011 13246 PM 5/17/2011 84635 AM 5/13/2011 13246 PM

Things i don't quite get are
Why dates in 2004? My Guess Malware author thought that would be funny.

Why does the exe have this modified date ? 12/9/2010 101509 AM
My guess, it is when the file was originally created on the malware author's machine or perhaps the date on the server that it was pulled from before it was dropped onto this machine.

Thanks for any guidance.

–Bruce


   
Quote
(@xennith)
Estimable Member
Joined: 15 years ago
Posts: 177
 

I am analyzing an NTFS drive on a machine trying to discover when the malware 'actually' first appeared.

Find .exe file, find prefetch data, find registry key for persistance, check dates.

Oh, and windows PE files have a compilation date inside the file header which might help.


   
ReplyQuote
(@corey_h)
Eminent Member
Joined: 15 years ago
Posts: 43
 

I am analyzing an NTFS drive on a machine trying to discover when the malware 'actually' first appeared.

The NTFS file system contains two sets of timestamps Standard Information Attribute (SIA) & the Filename Attribute (FNA). When files are stomped it only changes the SIA timestamps which means the FNA timestamps can still help determine the "real" time a file showed up on a system.

Other artifacts (prefetch files, registry modifications, exploit artifacts, etc) can then be used to collaborate when the malware first appeared. I've found this is an area where timeline analysis excels.

Here are a few blog posts explaining how timestomping effects the SIA and FNA timestamps and how to identify the real date

http//www.forensickb.com/2009/02/detecting-timestamp-changing-utlities.html

http//thedigitalstandard.blogspot.com/2011/02/time-stomping-is-for-suckers.html

HTH

Corey Harrell
"Journey into Incident Response"
http//journeyintoir.blogspot.com


   
ReplyQuote
pbobby
(@pbobby)
Estimable Member
Joined: 16 years ago
Posts: 239
 

5/13/2011 13246 PM is the date and time of infection (provided that those executables are the initial drop).


   
ReplyQuote
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
 

I wouldn't presume to make any definitive statements such as "this is the date of the infection" without more information; rather, I would suggest looking to Corey's response above, and collecting additional information.


   
ReplyQuote
pbobby
(@pbobby)
Estimable Member
Joined: 16 years ago
Posts: 239
 

Well he identified the malware. And like I said, provided that those files are the initial droppers - that's the time of infection.

Sometime's the answer is straightforward like that and really doesn't have to be complicated by looking for all sorts of artifacts. When you have 100s of these under your belt you start looking for signs that things are different rather than treating every one as your very first malware compromise - and this one appears to be cut and dry (and those signs just come from experience).

As for definitive statements - I get paid to make definitive statements. This one was for free )


   
ReplyQuote
(@ffcom)
New Member
Joined: 14 years ago
Posts: 4
 

I second pbobby.
I have personally done over 50 Zeus investigations. This is standard Zeus m.o.

That being said, if this is your first encounter with Zeus perhaps it would be beneficial for your records to document any supporting artifacts you can find. Solely to give your employer peace of mind that you are accurate. After the first dozen they will probably tell you to stop spending the extra time/effort(money) and believe you without all the extra digging.


   
ReplyQuote
(@twjolson)
Honorable Member
Joined: 17 years ago
Posts: 417
 

Well he identified the malware. And like I said, provided that those files are the initial droppers - that's the time of infection.

As for definitive statements - I get paid to make definitive statements. This one was for free )

While I agree that particular time is a good candidate for the date and time of the infection, it is incredibly foolish to take one piece of evidence, especially as limited as a MAC time, and declare such a definitive conclusion. That time stamp could be tampered with so easily, and if you went into court and stated your conclusion based solely on the time stamp, any lawyer worth his salt would be able to rip you apart.

Bottom line, you need more proof. As Xennith pointed out, find prefetch entries, find registry keys (services key?), find other files and folders that were modified at that time.

As for the 2004 time stamp, that may be an artifact of the delivery. I have noticed that zip files and unpacking exe files can retain the original date. So, it is possible that this malware was packed on a computer with its time set to 2004. But, and this maybe more likely, it maybe time stamp manipulation. One quick check of that would be finding out when the OS was installed. The Event Logs may give a clue as well.


   
ReplyQuote
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
 

The original question was

I am analyzing an NTFS drive on a machine trying to discover when the malware 'actually' first appeared.

Based solely on the information provided, I would suggest that this is impossible to determine. As suggested by others, there is other data that needs to be examined…the $FILE_NAME attribute within the MFT for the file, Registry keys, etc.

I, too, have performed a number of exams where Zeus was found. In most all of those exams, the Zeus persistence mechanism has been the UserInit key. Interestingly, Zeus is also capable of installing itself and maintaining persistence if it doesn't have Administrator privileges…it simply uses a key within the NTUSER.DAT, rather than the Software hive.

I have also seen where malware has been updated, or reinstalled. Given the file system tunneling capabilities of both NTFS and FAT, it's entirely possible that the malware presented in the original post isn't the first, but simply the most recent incarnation.

So all I'm suggesting is that based solely on the information presented, I (personally and professionally) would not be so quick to say, "That's definitely it."

Interestingly, the collection and analysis of the necessary data could have been accomplished in the time it took to write the original post.


   
ReplyQuote
(@bdmeyer)
Eminent Member
Joined: 15 years ago
Posts: 36
Topic starter  

Wow! What a great response.
I am unfamiliar with the FNA and SIA. I will be reading the links provided and learning about these today. Thank you for the registry key to look at. Also, I will examine the prefetch data as advised. Each of your comments are valuable and greatly appreciated.
Thank you each.
–Bruce


   
ReplyQuote
Page 1 / 2
Share: