While the author of the popular SpyEye banking Trojan seems to have disappeared and the development of the core Trojan has stalled, it is still widely used by cybercriminals around the world. And as SpyEye contains a plugin system, botnet operators are still able to extend its functionality.
Recently, we came across an interesting SpyEye build. It uses well-known spying capabilities of SpyEye like a form grabber, a screenshot sender and an RDP server which allows the criminals to fully remote control the victim’s computer. But it also contains a new plugin called "flashcamcontrol". Using this plugin, the Trojan is able to stream the input of users’ webcams and microphones to a server controlled by the criminals!
Trojans able to record users via their webcams are known for some years. But until now, known public cases were more or less limited to creeps that peeped on teenage girls.
What’s new?
But, in this case, the criminals seem to have different interests: This current Trojan seems to be built to start the media stream as soon as the infected user starts financial transactions.
Previously, Trojans usually recorded the user as soon as the computer was turned on, or they required the criminal to manually start the record. Both methods are quite unfocused.
This SpyEye build (mis)uses Adobe Flash
The Trojan uses Adobe Flash to implement its capabilities. Besides showing videos, Flash files can contain full programs which are, for example, also able to access the user’s webcam.
Usually, Flash requires websites to get a <link file:27896 _blank the user has to grant permission for a website access cam and>user confirmation to access webcams and microphones. Once the user gives permanent permissions for a website, this permission is stored locally, in a .sol file. To overcome this obstacle and to disguise the media stream activation, the flashcamcontrol-plugin changes the Flash settings in this .sol file mentioned: %APPDATA%\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys\settings.sol
The Trojan manipulates this file to grant permanent permission for the Flash files stored on a domain owned by the criminals as well as for the initial target domains. The initial target domain list we were able to extract from the code consists solely of bank domains.
To actually start recording the user, a Flash file located on the malware domain has to be embedded into the user’s browser. To do so, the criminals used the well-known SpyEye plugin "webfakes". This plugin is able to silently redirect a HTTP request from one location to another one. The plugin configuration hints towards two flash files on the criminals’ server.
The first file, camera_test.swf, <link file:27875 _blank running without a cam>shows a Russian message which tells if accessing the camera worked out. Therefore, it was obviously used for testing purposes, and we believe the botnet owner just forgot to remove it. Interestingly, this test file is triggered when the browser requests a (non-existing) location on the webpage of a popular German bank. Although this case is just a test, it also shows that the criminals targeted banks when they started implementing the recording capability.
The full streaming functionality is provided in the second file, called <link file:27863 _blank>client.swf. It is able to start the user’s webcam and microphone and <link file:27869 _blank case a camera is the stream but remains local in our>stream the input to the criminals’ server. While a server in the local network (192.168.0.100) is used as the stream target per default, a different server can be supplied to the Flash file as an option. Also, another Flash file or graphics file that is showed can be supplied through a parameter called addswf. We’ll have a closer look at its possibilities in a second.
Something currently still unknown: when is client.swf is actually triggered? The trigger, according the configuration, is a request to "https://*/sichwebcam/client.swf*", with the asterisks referring to wildcards. As at least one parameter for the recording server has to be supplied to submit the record to the attackers (otherwise the local address 192.168.0.100 will be used, which doesn't work over the Internet), the Trojan has to inject a matching request with this parameter at some point. However, we’ve found no reference to such an injection until now.
This leaves us with two possibilities: Either this kind of attack is not yet activated, as it is still being tested. Or it is injected individually for selected victims through one of the server-loaded web injects.
What are the new functions used for?
It’s a fundamental question: Why would the attackers want to view victims while doing online banking? While the attacker may use this to get a first glance at new security mechanisms, there's still no big point in watching a victim holding his TAN list, most probably even with the backside of the list facing the camera.
What comes to mind is that the addswf property allows the attackers to also send (!) a stream back to the victim. So, actually, the attacker can start a webcam himself and start a video chat with the victim. Remember that the victim still believes he is on the secure homepage of his bank, so the attacker can easily impose as a bank employee. This would obviously be a good opportunity for the attackers to use social engineering techniques against the victim. 
Even if the bank’s security mechanisms make it impossible for the Trojan to automatically defraud the victim, via webcam, the attacker can coerce the victim to wire some money. The attacker may even tell the victim to collect all possible cash resources for a "unique opportunity investment"…….. the attackers’ account.
To put it another way, the criminals can improve their attacks from simple "machine-in-the-middle"-attacks to "human-in-the-middle"-schemes.
How massive is this attack?
Until now, there are no public reports of such attacks. But we're quite sure the attackers didn't create the technical prerequisites for entertainment only. Of course we will monitor this new technique and track the further development of SpyEye and its new spying mechanisms.
G Data protects!
Besides traditional signature- and behavior-based protection, G Data’s customers are protected additionally against this kind of attack through our G Data BankGuard technology.
G Data BankGuard does not only detect the manipulations of SpyEye and its new webcam component in the browser, but also reverts them and - as a final step - removes the malware from the computer.
Obviously, G Data BankGuard does not only protect against this new SpyEye build, but against all known and unknown banking Trojans.