During a joint fraud investigation with Group-IB into a remote banking service, our colleagues in Russia analysed a number of samples passed on by the computer forensics experts at Group-IB. On the surface, what they were looking at was pretty much the standard: Zbot Trojan malware, which has been described many times, but they decided to probe a little further, and were rewarded by observing some rather unusual characteristics of the code in question, The Zeus botnet is interesting and highly adaptive malware with an unhealthy interest in various financial transactions carried out from an infected machine, such as online banking.

The Zbot agent continually checks Web pages visited from a compromised machine by intercepting the WinAPI functions. If an SSL connection is made to resources that contain data of interest, it takes the following actions:

— query string parsing for template username & password = * = *.
— query string parsing for template /bsi.dll/? T =

If successful the templates initiate a procedure for recording keystrokes and mouse clicks as well as procedures for taking screenshots (further information is written to a separate file and sent to the malicious server).

However, behaviour like this has been observed in other versions of Zeus. The really interesting discovery in this case is associated with the way in which these samples search for logical devices attached to an infected computer. Zbot searches for a file that usually contains the keys for the authorized logon client used in online banking and if the file is found, a copy will be sent to the server, along with quite a few other things that you don’t want a criminal to know about:

Information on connected devices and smartcard data
Keystrokes and mouseclick information, recorded and transferred to the server in a separate file
Cookies

Description of ZeuS smartcard support module

The ZeuS functionality has been updated with a new module which can manage information flows between smartcards and various special reader devices. Owing to the fact that the smartcard support subsystem’s architecture in the Windows operating system has a rather complicated structure, implying a multilevel system of drivers, the module is carefully and elaborately structured (fig. 1).

Figure. 1 – Smartcard support subsystem architecture

This module, which works at SmartCard API level, is based on interaction with Resource Manager. The latter can handle the access control to various reader devices and smart-cards working simultaneously. In fact, monitoring and managing of connected smart-cards could be carried out in two ways:
• inspecting and logging the current state of reader device;
• by the malefactor actively manipulating the process.

Acquisition of smart-card system information

This module determines whether a special reader device is connected or not. It also inspects and logs completed changes, storing such information in the SCARD_READERSTATE structure. This structure contains the device name, current program and hardware state, and card attributes.

This structure is stored in the process memory at a random offset, and is then sent over the network channel between the attacker’scomputer and the infected machine.

In the original form it looks like this:

Remote control of reader device

On the basis of collected information, the attacker is able to generate an escape sequence of smart-card activities, which is sent over the network channel as already described. This sequence is intended to be stored and handled on the infected machine. This means that there is an element of interpretation of the functions of Winscard.dll library: the malware converts the escape sequence into a corresponding sequence of APi calls.

SCardGetStatusChangeA
SCardStatusA
SCardDisconnect
SCardControl
SCardEstablishContext
SCardListReadersA
SCardListReadersA
SCardConnectA
SCardBeginTransaction
SCardEndTransaction
SCardTransmit
SCardGetAttrib

This is shown schematically in figure 2.

Figure 2: Module functionality on SmartCard API level

The code in its original form looks like this.

Using the SmartCard API's basic functionality, the attacker can select the appropriate reader device and connect to a certain smart-card, he can read and write data to the smart-card, and he can use some special functions provided by the smart-card, for instance, processing an input password or generating sequence of random characters.

The result of processing is saved and sent to the malefactor for the purpose of correcting the escape-sequence. Schematically such interaction might be as illustrated in the next figure.