2014-05-01
Abstract
The current information landscape is pretty lacking when it comes to information about cyber investigations. Most reports on cybercrime cover only the results of an investigation, omitting the process, the investigative techniques and the specific attack scenarios. Alisa Esage uses a real‑world example to shed some light on the typical cyber investigation process.
Copyright © 2014 Virus Bulletin
One thing a responsible CISO or security professional might notice about the current information landscape is that it is pretty lacking when it comes to information about cyber investigations. Most reports on cybercrime cover only the results of an investigation, completely omitting the process, and in particular the investigation techniques and the specific attack scenarios. The main objective of this article is to shed some light on the typical cyber investigation process, using a real-world example.
The work outlined in this article was carried out a few years ago as part of a private consulting assignment. However, all the malicious techniques – and more importantly, all the technical analysis and investigation techniques – mentioned hereafter are still absolutely functional.
The case described in this article is quite significant, both in terms of the financial losses of the attacked company (estimated at a few million US$), and the scale and coordination of the attack. It is also quite typical in that the attack scenario could easily be replicated to a wide range of targets.
This article provides a high-level overview of the case in two sections: Section 1 outlines the cyber attack scenario, as it was reconstructed by the investigation process. Section 2 outlines the investigation process, as it unfolded by means of specific technical analysis measures.
A follow-up article will dive into the technical details of the investigation process, and will discuss the necessary prerequisites for a successful cyber investigation.
To better understand a cyber investigation as a technological process, it is important to clarify the differences between the various terms widely used in the IT security industry, which are often confused:
Incident response refers to the initial set of actions undertaken in reaction to a security incident. Depending on the output of the incident response process, specific other processes are prioritized and put into action, such as immediate defensive actions or incident preservation for active countermeasures, a cyber investigation, or a security audit. The primary objective of the incident response process is thus to ascertain the circumstances to allow planning of further actions.
Forensics refers to the set of highly formalized and specialized methods for the extraction, analysis and packaging of technical evidence for the law enforcement procedures. The primary objective of forensic analysis is to provide a judicially compliant technical analysis of the digital evidence. It is important to note that forensic science does not provide any apparatus for correlation of evidence between various parts of the investigation process.
Attack attribution refers to the process of discovering and proving the relations of particular attack methods, instruments and techniques, as well as the attack as a whole, to specific actors, i.e. persons, groups, nations or communities.
Cyber investigation refers to the top-level process which incorporates, coordinates and correlates various specific technical processes, such as incident response, forensics, attribution, as well as malware analysis, vulnerability analysis, website auditing, and so on. The primary objective of a cyber investigation process is to provide the most comprehensive picture of the attack, which may or may not include suggestions as to suspects.
It is important to note that cyber investigation has nothing to do with the identification or prosecution of suspects, which is the sole responsibility of law enforcement.
A money transfer provider (‘the Company’) had been suffering from a mysterious financial fraud. Random individuals had been claiming and successfully cashing money transfers at local and foreign departments of the Company; while their sender records in the Company’s central database were fine, there was nobody who actually supplied or dispatched the money they received. Thus, the Company was experiencing financial losses at a rate of dozens to hundreds of fake money transfers per day, each transfer being valued between $3,000 and $30,000. The Company called for help as soon as it had exhausted its own private measures, such as investigating the possibility of insider activity and attempting to recognize the fake transfers to block them. At the start of the investigation, the attack was still in progress.
Before we proceed to the attack scenario, it is important to understand the Company’s infrastructure. When simplified, it boils down to a centralized client-server network, which is typical for any money transfer provider.
As shown in Figure 1, there are three types of entities in the targeted infrastructure:
The Company’s HQ (represented by the server box):
Stores the money transfers database.
Serves the Company’s corporate website.
The Company’s local offices (represented by client boxes):
Run e-banking software to connect to the server’s database.
Collect money transfers from persons, to store them in the server’s database.
Cash-out claimed money transfers to persons with verified IDs, according to the server’s database.
The Company’s customers (represented by persons):
Input and output cash to the Company.
(Click here to view a larger version of Figure 1.)
Now, let’s see the Company’s operation after it had been compromised (see Figure 2):
A local office computer is compromised and controlled by the attacker.
A fake money transfer record is injected into the server database by the attacker performing a regular e-banking transaction from the compromised local office (except there is no real customer or real money input).
A money mule whose ID was included in the fake transaction visits a different (or even the same) local office to collect the money.
The attacker receives the laundered money.
(Click here to view a larger version of Figure 2.)
It all started with a mass malware infection. A small trojan was broadcast by means of a standard drive-by attack or mass-mailing, to build a common botnet. One of the features of the trojan was to detect the presence of e banking systems on the compromised host.
At some point, the Company’s compromised hosts were noticed by the botmaster as promising (e.g. 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 successful. Within the next few months, a targeted attack on the Company was planned and executed.
The attackers’ plan was to compromise as many of the Company’s local offices as possible, performing a rapid distributed attack and cashing out as much money as possible before the Company could undertake any defensive measures. How did they achieve this goal? The Company’s corporate website was infected with malware. Then, because payment operators visited their personal accounts on that website on a daily basis, the malware was planted on almost every operator’s computer in a matter of days. The attackers’ malware of choice was Zeus.
In order to infect the website, the attackers scanned it for vulnerabilities. They managed to find a script which allowed the upload of arbitrary files to a publicly accessible directory of the web server. A common web backdoor script was uploaded into that directory, which allowed remote control of the server’s shell via a regular browser. The backdoor functionality was then used to inject malicious iframes into the website’s HTML templates.
Upon execution, the malicious iframes instructed a visitor’s browser to download an exploit from the attackers’ website (one of the many). The particular exploit was selected automatically by a malicious script, depending on the visitor’s browser version. 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 Zeus when enhanced with extra plug-ins, is to provide support for custom remote desktop connections without kicking the current user off or interfering with their input. This feature was utilized by the attackers to gain remote desktop access to an operator’s computer while he/she was at work. They were then able to run the e-banking application on top of the operator’s 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 the operator’s normal working hours. The money transfer record contained the ID information for a particular money mule. The central database server happily accepted the payment due record, since it was properly authorized and had originated from a whitelisted IP address.
In the meantime, a money mule approached another local office of the Company (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, the operator paid the amount of cash stated in the database record to the claimant. The claimant then disappeared.
As the Company’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 this case, some of the faked transfers could be identified by a pattern of several similarly sized amounts of transferred money.
As soon as a number of fake transfers had been blocked, the attackers stopped the transactions and started to cover their traces. After all, they still had core control: the website file upload vulnerability, which might allow them to repeat the same attack after some time. Luckily for the Company, the website vulnerability was discovered during the investigation process.
As one might expect at this point, the output of the investigation was passed to law enforcement authorities, and the Company was given guidance on the patching of the security flaws as well as the hardening of the entire client-server infrastructure.
At the start of the investigation process there was nothing more to go on than the mysterious fake money transfers. Nobody had any idea as to exactly how the money transfers had been faked. However, by that point the Company had already done its homework and excluded the possibility of an insider attack. So we knew from the very beginning that the fake money transfers were initiated by an external attacker. But how?
Was the central server compromised, either to create fake transaction records in the database, or to allow unauthorized connections from alien clients?
Were the client computers compromised, to steal operators’ credentials for a remote attack, or even to perform the attack directly from the compromised computer on behalf of the operator?
(Please refer to Figure 3 for a visualization of the investigator’s decision-making process.)
(Click here to view a larger version of Figure 3.)
During a cyber investigation, in order to prioritize the next steps in the process and to save precious time, it is important to properly estimate the probability of each possible scenario. Later, as the investigation unfolds, the new information will enable us to re-evaluate the initial estimation, thus allowing unnecessary pieces of work to be dropped or delayed.
In this case, the server compromise scenario was the least probable because, statistically, servers are better secured than regular workstations. Because attackers always target the weakest link, we have to follow their logic when estimating the likelihood of particular attack vectors.
A quick analysis of the server’s traffic logs showed that fake transactions had been initiated by a considerable number of workstations in the Company’s local offices, as identified by their IP addresses. So our first step was to perform a forensic analysis of the compromised workstations. We started looking for traces of malicious software, since that would be the most probable finding, and only if we were unable to find any traces of malicious software would we proceed to deeper analysis.
In this case, deeper analysis proved unnecessary, as we found that every compromised computer was infected with malware. It’s worth noting that every infected computer had an anti virus product installed, and some of them even had a few anti virus products installed. This 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, a web exploit, a net worm, or a malicious Flash drive or CD, planted on the operators’ machines?
How was the malware used to fake the money transfers? Was it via stolen credentials, or a hijacked session, or something else?
Two analytical processes were considered equally necessary at this point: first, to perform an analysis of the malware, and second, to analyse 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 even the tiniest pieces of information to understand the bigger picture.
From analysing both the malware and the network logs, we learned the following:
Every compromised computer was infected with the same version of the Zeus trojan.
Every compromised computer had visited the same malicious websites at some point before the attack, and had downloaded suspicious executable modules from them.
The malicious websites were visited immediately after the browser homepage had been visited (that is, the Company’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 flow of 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. The file contained details of payments to be faked (money mules IDs, amounts of money to fake, etc.).
So, it turned out that the Company’s corporate website had been compromised to host malware, thus allowing many clients to be infected at once. However, the output of the malware analysis didn’t make it clear exactly how the money transfers had been faked, because the Zeus trojan is such a universal piece of malware that it would allow many different attack scenarios to be implemented.
The most interesting findings were the text files containing details of the faked transactions. Given that the operators had already been screened by the Company’s own security service, this finding suggested only two possibilities: either the text files were parsed automatically by malware installed on the compromised computer to perform automated e banking system transactions, or there was another person logged into the same compromised computer, who was extracting the payment information from the text files to create fake transfers by hand.
Luckily, a very tiny detail hidden in one of the network logs allowed us to determine which of the two scenarios had occurred: we noticed that a favicon.ico file was requested from the malicious web server immediately before the malicious text file request. This tiny file is downloaded automatically by the browser upon visiting a website, which suggested that there was actually someone sitting at the browser, rather than the text file being downloaded by malware via a direct HTTP request. We concluded that, at least in a number of cases, the transactions were made manually, by means of a remote desktop connection to compromised clients.
Still a number of questions remained:
How did the attackers manage to compromise the corporate website, to plant an exploit on it? Did they break into the server, or did they find a hole in web scripts, or maybe steal the administrator’s FTP password?
Stealing the web server administrator’s password with the help of a phishing exploit is an easy task, so we had to check this high-probability scenario by means of auditing the administrator’s computer. The administrator’s computer showed no traces of malware, either active or deleted. So we performed an audit of the web scripts, after considering them the most probable target for a server compromise. We located a vulnerable script in the website, subject to custom file upload, along with the uploaded malicious scripts which allowed malware to be injected into web pages.
Which scenarios of creating fake transactions would the e-banking application support? (Since we didn’t have enough evidence to assume the RDP connection was the only technology behind the fake e-banking operation, we had to assume other scenarios to provide an effective advisory.)
An audit of the e-banking application revealed a vulnerability which allowed an authorized session to be hijacked remotely, by stealing the session token. So, in some cases the attacker might perform fake transactions from his own computer, channelling the connection via a malicious proxy installed on a legitimate Company’s workstation to bypass the server’s IP address verification. In addition to that vulnerability, we 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 step of the investigation provides new information, which allows us to refine the vision, and plan further investigation.
The investigation process left us with a few observations to consider:
An attacker’s way of thinking. An attacker builds his way to his goal step by step, at each step locating and exploiting the easiest targets throughout the Company’s infrastructure.
The doubtful value of security solutions. We’ve seen a number of top-rated anti-virus products installed on compromised hosts along with the powerful – and still very common – malicious tools. We’ve also seen IPS solutions guarding the network, while the attacker gets straight inside via a client-side vulnerability in a local office computer.
The trend towards easy-to-perform attacks. Attackers are building highly professional attacks using common malware (Zeus), which is easy to get hold of (purchase) on the black market. Rarely do they bother with studying the internals of the e-banking applications, or even with stealing credentials, rather they set up a remote desktop connection to impersonate the authorized operator, and to perform the job via the same comfortable visual interface that the operator uses. Cybercrime looks easy.
Web security. Website security is even more important than one might think for a regular corporate site. Compromising a corporate site might lead to compromising the organization’s partners or clients, all at once, which can be leveraged to compromise the organization in a variety of ways.
The thoroughness of investigation. It is important to audit every system that could possibly have been involved in the attack. In this case, if we missed even a single malicious script on the web server, then the attackers could easily have replicated the attack after some time.
