In reviewing some of the available materials on Stuxnet, I've started to see somethings that got me thinking. Actually, what really got me thinking was what I wasn't seeing...
To begin with, as I mentioned here, the .sys files associated with Stuxnet are apparently signed device drivers. So, I see this, and my small military mind starts churning...device drivers usually have entries in the Services keys. Thanks to Stefan, that was confirmed here and here.
Now, the interesting thing about the ThreatExpert post is the mention of the Enum\Root\LEGACY_* keys, which brings us to the point of this post. The creation of these keys is not a direct result of the malware infect, but rather an artifact created by the operating system, as a result of the execution of the malware through this particular means.
We've seen this before, with the MUICache key, way back in 2005. AV vendors were stating that malware created entries in this key when executed, when in fact, this artifact was an indirect result of how the malware was launched in the testing environment. Some interesting things about the LEGACY_* keys are that:
1. The LastWrite time of the keys appear to closely correlate to the first time the malicious service was executed. I (and others, I can't take all of the credit here) have seen correlations between when the file was created on the system, Event Log entries showing that the service started (event ID 7035), and the LastWrite time of the LEGACY_* key for the service. This information can be very helpful in establishing a timeline, as well as indicating whether some sort of timestomping was used with respect to the malware file(s).
2. The LEGACY_* key for the service doesn't appear to be deleted if the service itself is removed.
So, in short, what we have is:
Direct - Artifacts created by the compromise/infection/installation process, such as files/Registry keys being created, deleted, or modified.
Indirect - Ancillary (secondary, tertiary) artifacts created by the operating system as a result of the installation/infection process running in the environment.
So, is this distinction important, and if so, how? How does it affect what I do?
Well, consider this...someone gets into a system or a system becomes infected with malware. There are things that can be done to hide the presence of the malware, intrusion or the overall infection process itself. This is particularly an issue if you consider Least Frequency of Occurrence (LFO) analysis (shoutz to Pete Silberman!), as we aren't looking for the needle in haystack, we're looking for the hay that shouldn't be in the haystack. So, hide all of the direct artifacts, but how do you go about hiding all of the indirect artifacts, as well?
So, by example...someone throws a stone into a pool, and even if I don't see the stone being thrown, I know that something happened, because I see the ripples in the water. I can then look for a stone. So let's say that someone wants to be tricky, and instead of throwing a stone, throws a glass bead, something that is incredibly hard to see at the bottom of the pool. Well, I still know that something happened, because I saw the ripples. Even if they throw a stone attached to a string, and remove the stone, I still know something happened, thanks to the ripples...and can act/respond accordingly.
Also, indirect artifacts are another example of how Locard's Exchange Principle applies to what we do. Like Jesse said, malware wants to run and wants to remain persistent; in order to do so, it has to come in contact with the operating system, producing both direct and indirect artifacts. We may not find the direct artifacts right away (i.e., recent scans of acquired images using up-to-date AV do not find Ilomo...), but finding the indirect artifacts may lead us to the direct ones.
Another example of an indirect artifact is web browsing history and Temporary Internet Files associated with the "Default User" or LocalService accounts; these indicate the use of the WinInet API for off-system communications, but through an account with System-level privileges.
Thoughts?
5 comments:
Write detection/logging to the file system and registry will catch everything - irrespective of intent. It just becomes a matter of filtering out the good and the bad.
Artifacts of compromise are also present in network activity. Take a look at this and see how this might apply to what you're talking about:
http://misterreiner.wordpress.com/2010/06/04/how-to-catch-hackers-security-sensors-dont-see-part-1/
Harlan -- sorry to jump in on this post off topic but I'm curious if you can tip me as to the source of your "Blog List" code/widget.
I've just done a major update to the GSD blog (for the better I hope) and having been inspired by yours (a constant source of leads) decided to add one of my own to GSD blog.
I'm currently using the default "Blogger" widget but for some reason I can't get MS TechNet blog sites to drop in. While I see they seem to work on yours (example "Microsoft Malware Protection Center" item).
Is your the stock Blogger one as well or did you use a custom source/code to do so?
Thanks for the recent link-backs in your posts! I'm glad my humble chatter is finding a wider audience!
Cheers!
--Claus V.
Claus,
Yes, it's the default widget from Blogger. You may be using a different one, based on the template you're using...
Hi Harlan
Apologies for posting this here but I have been reading a number of your articles in relation to timelines, which I have found very interesting. I am currently researching (as a part of a college project) into the area of Visualising timelines and how useful this is and will be. You have mentioned this in some of your previous posts. I would be interested in hearing more on your thoughts in this area, and where you think it is going?
Thanks
Dee
Dee,
Contact me at my email address...keydet89 at yahoo dot com
Post a Comment