Malware / banking trojan hunting

To begin with, you need to take a step back and determine how these systems were _known_ to have been infected. I suggest this, as I've received a number of hard drives that were "known" to have been infected with Zeus, for example, and there were no traces of Zeus…but there was something else.

The fact is, particularly when it comes to this kind of work, sometimes "known" to be infected really means that there's a suspicion based on what's recently appeared in the media.

Many times, AV is great at detecting some variants of malware, but they don't clean up everything, and they definitely don't do so without a trace. For example, there're a number of AV products that write their logs to text-based files, as well as to the Application Event Log. As such, there is no such thing as an AV product detecting and deleting malware without any trace in the logs. Where this might be the case is where the installed AV does not detect the malware, but another AV product does, and deletes it.

Even so, AV rarely locates and deletes the Registry artifacts. Even if it were to do so, most AV products simply delete the keys, which can then be recovered from unallocated space within the hive file, via regslack (check out the book, "Windows Registry Forensics").

> …are there signatures which could help me find traces of the configuration file/stolen data file of these malware, in case the binary is gone ?

Sure. Based on the variants of malware, I'd suggest creating a timeline of activity on the system and looking there for indicators identified by AV writeups. I've done this quite successfully over the past 3 yrs…in fact, I just completed an exam where I used this technique to not only differentiate between AV detections and actual infections of malware, but also determine when the infections actually took place.

So, in short, this is actually a pretty trivial issue to address, but the first step is to move away from the initial statement that the system was definitely infected as being gospel.

Hope that helps…

Most AVs quarantine the file somewhere, its obfuscated and/or encrypted to avoid further detection. Look for known locations of AV quarantine folders.

If you don't even have that (quarantined file), then I would look at analyzing NTFS Indx entries, this won't give you the file, but there is a good chance you will know the location of the exe/dll. Search the disk for these names in more logs, you might find something useful, like in the prefetch files, etc..

Also, a lot of malware cause buffer overflows and crashes (usually as injection vector), look for unusual service/program crashes in the windows event logs.

Look at autorun entries, there is usually more than a single malware piece.

Not sure what exactly you intend to find, but at least you will get some clues somewhere this way.

Yogesh Khatri
Forensic Analyst
Mumbai, India

Yep. I second keydet89's comment.

We are often faced with "always", "never", "totally", and similar adverbs and adjectives.

We often have to dig into each and every such statement and get more quantifiable answers.

Dig. mrgreen

Thank you all for your comments, especially keydet89. The idea of digging into deleted keys by using regslack is very interesting, and I think I will use it very often from now on.
This is another hint that proves me that I did not read keydet89's book with enough concentration and will use it more often 😉

As for the aspect of being sure it had been infected, I think like you guys I never take for granted what a user tells me, and carefully take my time to check everything by myself.

So, nothing anymore as for the binary, nothing anymore in the registry (I am only talking about Windows systems), no trace in any AV log, nothing.

There is a lot that you didn't say. What about $UsnJrnl records? Volume Shadow Copies/System Restores? Suspicious URLs either in the browser caches or in unallocated space. Are there network log files or packet capture files?

This can be painstaking work and the amount of effort that you put into it really should be determined by what you need to know and how important is it that you know it.

I've had cases where, in the final analysis, there was no conclusive answer but the investigation did shed light on vulnerabilities to the client's infrastructure which could be mitigated to prevent further attacks. Sometimes that is enough.

I wanted to revisit this question, as I'm working on one of the chapters for my book, and reiterate the idea of secondary artifacts.

When malware infects a system, it creates primary artifacts, which are directly related to the infection itself. At the same time, as well as when the malware is actually launched, secondary artifacts are also created…these are artifacts that are the result of the malware's interaction with its ecosystem.

Primary artifacts can include files and Registry keys being created/modified. Secondary artifacts can include such things as Prefetch files, etc.

One of the interesting aspects of this…whether its malware detection by AV, or a bad guy "cleaning up" behind himself…is that many times, some of the artifacts are missed. So when I look for malware, whether known or unknown, within an image, I look for both primary and secondary artifacts and often find hints of what I was looking for in Event Log records, deleted Registry keys, etc. I have a process that I follow simply because signatures (MD5 hashes, AV sigs) often do not work, and even then, they only work to detect the malware itself, not the ancillary files, such as config or data files.

Also, I've worked a number of cases involving the theft or exposure of online banking information, and the system owner has claimed that it was Zeus…but they did so b/c that's what they read in an online blog or trade journal article. Most times, Zeus wasn't involved (there were no indications of a Zeus infection) and the issue was instead something else. I tend to think that this is an unintended, albeit fortuitous, circumstance…with Zeus in the news so much, folks look for it and don't find it, and give up. This allows the real perpetrator to either continue to collect data, or to go undetected, as the system is wiped and reprovisioned without any investigation.

Interesting…..I've spent a lot of time looking for these 'secondary artifacts'. questions Can I trust the file name && metadata? How would I search for them in an 'out of sync' situation… (ancillary data files…not logs).

cheers

Interesting…..I've spent a lot of time looking for these 'secondary artifacts'. questions Can I trust the file name && metadata? How would I search for them in an 'out of sync' situation… (ancillary data files…not logs).

Sorry, I don't follow. What do you mean by "Can I trust the file name && metadata?"

Sorry, I wasn't clear at all. What I meant is
1) Sometimes you need to employ data carving techniques to recover data of damaged file systems. How would you find 'second artifacts' of viruses when file-name and metadata are lost ?… or
2) What if the 'second artifacts' have become orphan files?… Wouldn't be the signature the only way to search for them?

Hope this makes sense….