Hi Folks,
A lot of times when there is a malware problem (on your puter or fixing somebody elses) you have an idea where it came from, a lot of times you don't. If you don't, you have a recipe for a future disaster.
Malwarebytes is probably the leader in finding out info these days, SuperAntiSpyware second. Kewl.
One thing they (any company) never seem to want to study is the DATES of the files of the problems. They are not shown to you, they are not in the log, they are nowhere to be found (afaik, there could be exceptions). And once you delete the problems, all trace is gone except in backups.
Now Windows does a pretty good job documenting the date and time of when a file appears (granted the malware could try to adjust that, similarly you could have a guardian to prevent the 'adjustment'. The malware could also fudge the issue some if it is the type that replicates and deletes, however what I am sharing will apply in MOST cases.)
So if you had two things :
1) The ORIGINAL PUTER DATE of the problem issues (I'm not sure if that extends to registry entries, whether they log .. or could be easily logged .. in that manner). On files Windows keeps a couple of dates, sometimes the names are confusing, but the original "onboard" date is one of them.
2) A decent log .. not just the event viewer, but a real log-file of web-pages, downloads, java loads, .exe and .dll file creations, stuff like that.
You would be able to backtrack and get a good fix on the original source. And log files are "no big deal" .. 100 or 1000 entries a day or so is simply nothing in terms of computer processing.
And note: until there is more .. actually the windows file dates gives you a pretty decent defacto log today, simply by searching on the date and time.
Then #3
And most of this could checking be automated ! Then a little program could fish out what happened right before the file install. So it is a lot easier than even looking at the famous "event viewer". A lot of time you would then look at the data and have an "aha" moment, or at least find a likely culprit or benign cause.
Why do I mention this ? I fished out the data for a false positive from Emsi very easily in that way (I could link to the threads). First I checked the suspect file date itself, then I searched on Locate32 (I think that is what I used, maybe Total Commander did not have that date search handy, or maybe vica versa) by the file dates to see what was new at the time of the suspect. And I found out that a potential "keylogger" was simply part of a respected task manager package that I had installed that gave me the .dll. And a phone call to the developer put all the dots together, very simple. (Emsi showed no interest at all in this method of discovery .. none .. zilch. ) Yet if I did not have the dates available, very unlikely that I would have found anything.
(Well, later I discovered McAfee also had a second lead, far less exacting, one that helped confirm my research. The file was documented as coming from the task manager package -- on a page where they show what was involved in the installs, surprisingly nice from McAfee). For the afficianados, the Convar "PC Inspectpor Task Manager" program used a Dart library component .. one that had been used in an earlier version a decade ago by a parental-control keylogger .. such is the sad state of modern malware analysis. In fact Emsi had previously been informed about this false positive of this .dll on an earlier thread, but their bureaucrcatic methodology was in the way.
The malware industry does not like to revamp their thinking very easily .. heuristics and all ... they are an entrenched and somewhat stagnant crew, at least in some ways.
Your thoughts on this 'new paradigm' possibility for discovering the malware sources ? It is actually all quite trivial on a technical level, mostly it simply needs a bit of coordinated action. Basically, it seems like an important component, a very simple and strong weapon, is simply ignored in the malware prevention world. (When was the last time you heard a security vendor, or even a Wilder's techie, recommending to check the file date and match it against the files on your system ? )
The simplest aspect of this could be implemented very simply. Here is the file(s) in question .. here are any installs at that time. At the very least, you would start with things like .. this .dll or this .sys links to this .exe and these files, they were installed at the same time. The more overarching log defense structure is the higher level recommendation.
Shalom,
Steven Avery
