HowTo: Investigate an Online Banking Fraud Incident

A recent comment over on Google Plus caught my attention, and I thought it was important enough to incorporate into a HowTo post.  The comment was made with respect to the HowTo: Detecting Persistence Mechanisms post, and had to do with another means of persistence associated specifically with (according to the person who left the comment) online banking fraud.

Online banking fraud is a significant issue.  It's long been known that criminals go where the money is, and there are some interesting aspects with regards to this criminal activity.  For example, by targeting the computers used by small businesses to perform online banking, very often no investigation is done.  After all, a small business has just lost a significant amount of money, and possibly gone out of business...who's going to pay to have a thorough examination of the system performed?  Further, in the US, small businesses are not protected in the same manner as individuals, so once the money's gone, it's gone.

Small businesses can take a number of steps in order to protect themselves from online banking fraud; however, there is a lack of information and intel available that law enforcement can use to pursue the criminals, simply due to the fact that the systems used do not seem to be examined.  A thorough examination can be, and should be, conducted immediately so that law enforcement has the information that they need to pursue an investigation.

Whodunit?
Brian Krebs has discussed the Zeus malware quite extensively in his blog, particularly with respect to online banking fraud. More often than not, once Brian has been contacted, the systems have likely already been wiped and repurposed, without any sort of examination having been conducted.

However, there're more ways of achieving this sort of criminal activity than simply using Zeus; W32/Crimea is one example.  During the infection process, the PE header of imm32.dll is modified (for Windows XP, Windows File Protection is disabled temporarily) to point to a malicious DLL, which is loaded when imm32.dll is loaded.  Imm32.dll is associated with keyboard interaction, so it's loaded by a number of processes, including the web browser.  The malicious DLL focuses specifically on retaining information entered into browser form fields associated with specific sites (i.e., online banking sites).  The collected information is not stored locally; instead, it is immediately shuttled off of the system.  As such, the artifacts are minimal, at best.  The most significant artifacts were found through examination of the malicious DLL itself, which then led to findings in the pagefile.

Another example is one pointed out by Sandro Suffert on Google Plus...he mentioned that a "downloader" had modified two Registry settings (modified or created two values):

- Within the HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings key, the AutoConfigURL value pointed to either a local or remote .pac file

- Within the HKCU\Software\Policies\Microsoft\Internet Explorer key, the Autoconfig value was set to 0x1.

I cannot attest to these key paths or values being correct, as I have not seen the data.  However, this is an interesting technique to use, as Sandro pointed out that particularly with a remote .pac file, there's no actual malware on the system, and therefore no file for AV to alert on.  Yet, this technique allows the bad guys to capture information using a man-in-the-middle attack.

Similar techniques are used by Trojan-Banker.Win32.Banbra, Troj-MereDrop, as well as this baddie from ThreatExpert.

As Hamlet said to Horatio, "...there are more things on heaven and earth than are dreamt of in your philosophy..."; Win32\Theola is a Chrome plugin that is used to commit online banking fraud.

Examination
So...in order to investigate a potential online banking fraud issue, as soon as this issue is suspected (or a small business is notified of such an issue), immediately sit down with the employee responsible for conducting online banking and determine all of the systems that they used for this activity.  You may find that they have one system from which they conduct this activity, or you will find out that they had an issue at some point and used another system.  Immediately isolate that system, and depending upon the timeframe of the fraudulent activity, acquire a dump of physical memory from the system.  Then, acquire an image of the system and conduct a thorough examination, or contact someone who can.

If you create a timeline of system activity, it should go without saying that you should focus your attention on activity that prior to the date of the fraudulent transaction (or the first one, if there are several).

Resources
MS KB: How to reset your IE proxy settings