E-banking fraud has increased dramatically, as money migrates into the virtual world, the crime follows. Lets look at a typical case study.
A money transfer provider (The Victim) had been suffering a mysterious finance fraud. Random individuals claimed and successfully cashed money transfers at local and foreign departments of the Victim; while their sender records in the Victim’s central database were fine, there was nobody who actually supplied or dispatched those money.
Thus, the Victim was experiencing immediate financial losses at the rate of dozens to hundreds of fake money transfers per day, each transfer sized $3000 to $30000.
The Victim called for help as soon as they exhausted private measures, such as verifying the possibility of insider activity and attempting to recognize the fake transfers to block them. At the investigation start, the attack was still in progress.
The Victim;s Infrastructure
The Victim’s Infrastructure
The Victim’s dataflow as well as organizational topology was starlike. There was the central management entity, which also hosted the global payment information database and the website. The workstations in subsidiary offices relied upon the
centralized database to cash the money transfers in and out. A money transfer request reimbursed by a sender’s cash would be accepted by the operator at one subsidiary office, to be stored in the centralized database, to be cashed-out at another subsidiary office only to the claimant whose ID corresponded to the data which was provided by the sender. The
payments data was stored and retrieved to and from the global database by operators via a commercial thin-client e-banking application.
The network communication channel between subsidiary offices and the central server was properly secured: authorization was required, the client’s IP address was verified, and the traffic was strongly encrypted.
The scenario has been reconstructed from raw data only such as network and server activity logs, malware grabbed from compromised computers, website backups and other data. Many assumptions had to me made due to the scarceness of evidence, and thus, every assertion within the scenario is somewhat of probabilistic nature (but no less than 80-90% probability).
It all started with a mass malware infection. A small Trojan was broadcasted by means of a standard driveby attack or mass-mailing, to form a common botnet. One of the features of the Trojan was to detect the prsence of e-banking systems on the compromised host.
At some point, the Victim’s compromised hosts were noticed by the botmaster as specifically promising (Payment transfer systems attract cyber fraudsters like honey, because such systems have the major obstacle to low-risk cyber-robbery solved by design: that is, such systems allow easy and quick cashing out for unscreened individuals.) (i.e. by correlating the presence of professional e-banking software with the compromised computer’s WHOIS data). A number
of single payments were faked for the purpose of testing, which proved safe. Within the next few months, a targeted attack on the Victim was planned and executed.
The attackers’ main objective was to compromise as many Victim’s subsidiaries as possible, to perform a rapid distributed attack, to cash out as much money as possible before the Victim can undertake any defensive measures. How did they achieve this goal? The answer is that the Victim’s central website was infected with malware. Because payment operators
used to visit their personal accounts at the central website on the daily basis, the malware was planted on almost every operator’s computer in a matter of days. And the malware of the attackers’ choice was Zeus.
In order to infect the website, the attackers scanned it for vulnerabilities. They succeeded to find a script which allowed to upload custom files to the publicly accessible directory of the web server. A common web shell script was uploaded into that directory, which provided a custom control panel to the server when called from a browser. The server control panel functionality was then used to inject malicious Iframes into the website’s HTML templates.
Upon execution, the malicious Iframe instructed a visitor’s browser to download an exploit from a random one-time website. The particular exploit version was chosen automatically by a malicious script, depending on the visitor’s browser version information. The exploit then triggered remote code execution in the browser to download and execute a sample of the latest generation Zeus malware.
One of the most powerful capabilities of the Zeus enhanced with extra plugins is to provide support for custom remote desktop connection without kicking off the current user or messing with her input. This very feature was utilized by the attackers to get remote desktop access to the operator’s computer while she was at work, to run the e-banking application on top of the operator’s already authorized session (a technique known as session riding or session hijacking), and thus,
to create fake money transfer records via the e-banking application, signed with the operator’s digital signature and time-stamped with her normal working hours. The money transfer record contained ID information of a particular money mule. The central database server eagerly accepted the payment due record, since it was properly authorized and originated from a white-listed IP address.
In the meanwhile, a money mule approached a different subsidiary of the Victim (possibly even in other country) to claim the fake money transfer. The operator first checked the claimant’s ID against the centralized database. If a valid money transfer was found designated to this person, she paid the amount of cash stated in the database record to the claimant. The claimant then disappeared.
As the Victim’s central management entity became aware of the unfolding attack, they tried to distinguish and block the faked money transfers. Note that it is nearly impossible to tell a faked database record from a genuine one, as long as the stored record is complete with all the required information, authorization, and valid network connection logs. Luckily, in the described case, some of the faked transfers might be fingerprinted due to the flaw in the attackers’ strategy, who used to send the same money mules to grab similarly (and considerably) sized pieces of cash from various cashout departments of the Victim.
After a number of fake transfers were blocked, the attackers stopped their action almost immediately to avoid being caught red-handed, and started to cover up traces. After all, they still had the core control: the website file upload vulnerability, which might allow them to repeat the same attack after some time. Luckily for the Victim, the vulnerability was revealed during the investigation process.
The input to the investigation process was no more that the fact of mysterious fake money transfers. Nobody had any idea of how exactly were the money transfers faked. Luckily, the Victim have already performed the homework to explore the possibility of an insider attack, which proved false. So we could conclude from the very beginning, that fake money transfers were initiated by an external attacker. But how exactly?
• Was the central server compromised, to fake transaction records in the database, or to allow unauthorized connections from alien clients?
• Or, were the client computers compromised, to steal operator’s credentials for a remote attack, or even to perform the attack directly from the compromised computer on behalf of the operator?
In order to prioritize the choice of further expertise to save the precious time, it is important to properly estimate the probability of each possible scenario. Later, as expertise unfolds, the new information helps to re-evaluate the initial estimation, which allows to delay or to drop the unnecessary pieces of expertise.
In this case, obviously, the server compromise scenario is less probable, because organizations tend to underestimate client-side security of ordinary workstations (even those used for e-banking), by the side of the security of central servers. Note that the attacker will always target the weakest link, and we must follow his logic while performing the expertise.
A quick analysis of the central server network logs showed that the fake transactions were initiated by a considerable number of subsidiary offices workstations, recognized by their IP addresses. So the first step was to perform a forensic expertise of the compromised workstations. Again, after estimating the probability of various possible findings, we may
find it surplus to perform a full forensic analysis of compromised computers. In this case, we started from looking for bodies or traces of malicious software, since it would be the most probable finding, and in case that it proved false, then only we proceeded to deeper analysis.
In this case, a deeper analysis turned low-priority, as soon as we’ve found that every compromised computer was infected with malware. Noteworthy, that every infected computer had an antivirus product installed, or in some cases, a few antivirus products. This new information was not enough to understand the attack, of course, but it was enough to define and prioritize the next steps, guided by the new questions:
• How were the clients infected with malware? Was it a targeted attack, or a web exploit, or a net worm, or a malicious Flash drive or a CD, planted on operators?
• How, if somehow, was the malware used to fake the money transfers? Was it a credentials stealth, or a session stealth, or anything else?
Two expertise processes have been considered equally necessary at this step: first, to perform the malware analysis, and second, to analyze the workstations networking logs. The workstations were based on standard editions of Microsoft Windows, so no internal logging was available, and in some cases, even proxy/router logs were unavailable or limited. In
such cases, if the evidence is scarce, it is important to inter-correlate the tiniest pieces of information to understand the major pattern.
After performing malware analysis and network logs analysis, we learned the following:
• Every compromised computer was infected with the same version of Zeus Trojan.
• Every compromised computer have visited the same malicious website at some point before the attack, and have downloaded suspicious executable modules from them.
• The malicious websites were visited immediately after the browser homepage was visited (that is, the Victim’s corporate website).
• Immediately after a client was compromised, it started to generate all kinds of suspicious traffic to malicious servers, compromised legitimate websites, and no-name VPS hosts.
• In some cases, network log records revealed a highly intensive, extended outgoing traffic accompanied by low incoming traffic – a pattern suggesting a remote desktop connection such as VNC or RDP.
• During the attack, in some cases, a text file was downloaded and saved to the compromised computer, containing details of payments to be faked (money mules IDs, amounts of money to fake, etc.)
It turned out that the Victim’s corporate website was compromised to host malware, which allowed to infect many clients at once. However, the malware analysis output didn’t shed any light to the technical details of faking the money transactions, because the Zeus Trojan is such a universal malware that would allow to implement many different attack scenarios.
The most promising and mysterious finding were the text files, containing details of the faked transactions. Basically, given that the operators were already screened by the Victim’s own security service, thisfinding suggested only two opportunities: either the text files were parsed automatically by malware installed on the compromised computer to perform automated e-banking system transactions, or there was anotherperson logged in to the same compromised computer, who extracted the payment information from the textfiles, to fake transfers by hands.
Luckily, a very tiny detail hidden in one of the network logs allowed us to resolve the last question immediately, which saved a lot of time on the expertise. That is, we’ve noticed that, a favicon.ico file was requested from the malicious web server immediately before the malicious text file request. This nuance testified that the malicious text file was requested by someone sitting at the browser, rather than it was downloaded by malware via a direct HTTP request. So, we were able
to assume a high probability of the suggestion, that at least in number of cases the transactions were faked manually, by means of a remote desktop connection to compromised clients.
• How did the attackers manage to compromise the corporate website, to plant an exploit on it? Did they break into the server, or did the find a hole in web scripts, or maybe stole the admin’s FTP password?
Stealing web server administrator’s password via a malware is an easy task, so we had to verify this high-probability scenario by means of auditing the administrator’s computer. The administrator’s computer showed no traces of malware, neither alive or deleted. So we performed the web scripts auditing, after considering them the most probable target for a
server compromise. As the result, we’ve located a vulnerable script in the web site, subject to custom file upload, along with the uploaded malicious scripts which allowed to inject malware into website pages.
• Which scenarios of creating fake transactions would the e-banking application support? Because we had not enough evidence to assume the RDP connection was the only technology behind faking e-banking operation, we had to assume other scenarios to provide an effective advisory.
Auditing of the e-banking application revealed a vulnerability, which allowed to hijack an authorized session remotely, by stealing the session token. So, in some cases the attacker might perform fake transactions from his own computer, channeling the connection via malicious proxy installed on a legitimate Victim’s workstation to bypass the e-banking server IP address verification. Apart from that vulnerability, we’ve found that the e-banking application allowed easy stealing of the user’s key files – again, the attacker might use them to impersonate a legitimate operator remotely.
Note the dual link between the probability evaluation and the expertise: every piece of expertise provides new information, which allows to refine the vision, to plan the further expertise.