Zeus - Thunderstorm for Smart Cards
In the course of a single investigation with Group-IB, an investigation into fraud in e-banking systems, we conducted a study of several malicious programs. Samples of these programs were obtained by computer forensics experts from Group-IB in the process of solving a crime. The picture was pretty standard: the Zbot Trojan was found to be a malware which, it would seem, has already been studied far and wide, but still, we decided to pick it up in more detail. And the fun began. Or rather, a rather curious functional was noticed, which will be discussed below.
The version of Zeus that came into our hands is interested in information about various financial transactions carried out on the infected machine. Well, for example, information about activity with online client-banking systems. Zbot constantly checks the visited web pages by intercepting relevant WinAPI functions. In the case of an SSL connection with resources that contain strings of interest to the Trojan, it takes the following actions:
- analysis of the query string for the presence of the template username =. * & Password =. *
- analysis of the query string for the presence of the template /bsi.dll/?T=
')
If the specified templates are successfully detected, the procedure for capturing the pressed keys on the keyboard and the mouse is started, as well as the procedure for taking a screenshot of the screen (hereinafter, the information is recorded in a separate file and sent to the server).
But this was all noticed in other modifications of Zeus. The most interesting was found a little later. When we studied the functionality responsible for finding logical devices connected to a computer, in particular, the Zbot functionality was discovered, which searches for the file A: \ key.dat . This file, as a rule, contains keys for authorized login to the client online banking system and if the file is found, its copy is sent to the server. By the way, Zeus sends a lot of things to the server:
- information on the connected smart card readers, as well as directly on the smart cards themselves
- the results of fixing keystrokes on the keyboard and mouse, information is recorded in a separate file and sent to the server
- cookies
- copies of any file detected in the system
And here we are very interested in the functionality associated with monitoring connected smart cards. The architecture of the smart card support subsystem in MS Windows operating systems has a rather complex structure, which implies a multi-level driver system:
The basis of this functionality, which works at the SmartCard API level, is interaction with the Resource Manager, which controls access to several reading devices and smart cards directly working on the same machine. In fact, the control and management of connected smart cards is carried out in two directions:
- continuous monitoring and logging of the current state of the reading devices
- some active actions by the attacker
Zbot monitors connected devices for reading, and also registers changes in these devices. In this case, the logged data is stored in the SCARD_READERSTATE system structure, which contains current information about the device name, current software and hardware status, as well as the attributes of the card used. This structure is stored in the process memory at random offset, and then sent over a pre-established network channel between the infected computer and the attacker's computer.
In decompiled form, it looks like this:
Based on the information collected, the attacker generates a program of actions, which is presented as a control sequence and sent over a network channel, as mentioned above. This control sequence is saved on the infected machine and then processed. The sequence processing consists in translating its elements into the following functions of the Winscard.dll library:
SCardGetStatusChange
SCardStatus
SCardDisconnect
SCardControl
SCardEstablishContext
SCardListReaders
SCardConnect
SCardBeginTransaction
SCardEndTransaction
SCardTransmit
SCardGetAttrib
Or it can be presented in the form of the following scheme:
The function that handles the control sequence looks rather cumbersome, but, for the most part, comes down to the calls given in WinAPI:
Part of the code in decompiled form is as follows:
By combining the elementary actions of the SmartCard API level, an attacker can select the required reader and connect to some smart card, write and read information from the smart card, can use special functions provided by smart cards: encryption and decryption of data, generation of digital data signatures, generating a sequence of fixed-length pseudo-random numbers.
The result of processing the control sequence is saved and sent over the network channel to the attacker to correct his actions. Schematically, this interaction can be represented as follows:
An important feature of the implementation of this functionality is the fact that the control sequence emanating from the attacker can be compiled and adapted for almost any reader. Therefore, the range of attackers is large enough: it is suitable for desktop readers, for mobile, for readers with a PIN-keyboard, for biometrics and for many others.
But, despite the functionality found by us, today smart cards remain the safest way to store key information from all existing ones.
The version of Zeus that came into our hands is interested in information about various financial transactions carried out on the infected machine. Well, for example, information about activity with online client-banking systems. Zbot constantly checks the visited web pages by intercepting relevant WinAPI functions. In the case of an SSL connection with resources that contain strings of interest to the Trojan, it takes the following actions:
- analysis of the query string for the presence of the template username =. * & Password =. *
- analysis of the query string for the presence of the template /bsi.dll/?T=
')
If the specified templates are successfully detected, the procedure for capturing the pressed keys on the keyboard and the mouse is started, as well as the procedure for taking a screenshot of the screen (hereinafter, the information is recorded in a separate file and sent to the server).
But this was all noticed in other modifications of Zeus. The most interesting was found a little later. When we studied the functionality responsible for finding logical devices connected to a computer, in particular, the Zbot functionality was discovered, which searches for the file A: \ key.dat . This file, as a rule, contains keys for authorized login to the client online banking system and if the file is found, its copy is sent to the server. By the way, Zeus sends a lot of things to the server:
- information on the connected smart card readers, as well as directly on the smart cards themselves
- the results of fixing keystrokes on the keyboard and mouse, information is recorded in a separate file and sent to the server
- cookies
- copies of any file detected in the system
And here we are very interested in the functionality associated with monitoring connected smart cards. The architecture of the smart card support subsystem in MS Windows operating systems has a rather complex structure, which implies a multi-level driver system:
The basis of this functionality, which works at the SmartCard API level, is interaction with the Resource Manager, which controls access to several reading devices and smart cards directly working on the same machine. In fact, the control and management of connected smart cards is carried out in two directions:
- continuous monitoring and logging of the current state of the reading devices
- some active actions by the attacker
Zbot monitors connected devices for reading, and also registers changes in these devices. In this case, the logged data is stored in the SCARD_READERSTATE system structure, which contains current information about the device name, current software and hardware status, as well as the attributes of the card used. This structure is stored in the process memory at random offset, and then sent over a pre-established network channel between the infected computer and the attacker's computer.
In decompiled form, it looks like this:
Based on the information collected, the attacker generates a program of actions, which is presented as a control sequence and sent over a network channel, as mentioned above. This control sequence is saved on the infected machine and then processed. The sequence processing consists in translating its elements into the following functions of the Winscard.dll library:
SCardGetStatusChange
SCardStatus
SCardDisconnect
SCardControl
SCardEstablishContext
SCardListReaders
SCardConnect
SCardBeginTransaction
SCardEndTransaction
SCardTransmit
SCardGetAttrib
Or it can be presented in the form of the following scheme:
The function that handles the control sequence looks rather cumbersome, but, for the most part, comes down to the calls given in WinAPI:
Part of the code in decompiled form is as follows:
By combining the elementary actions of the SmartCard API level, an attacker can select the required reader and connect to some smart card, write and read information from the smart card, can use special functions provided by smart cards: encryption and decryption of data, generation of digital data signatures, generating a sequence of fixed-length pseudo-random numbers.
The result of processing the control sequence is saved and sent over the network channel to the attacker to correct his actions. Schematically, this interaction can be represented as follows:
An important feature of the implementation of this functionality is the fact that the control sequence emanating from the attacker can be compiled and adapted for almost any reader. Therefore, the range of attackers is large enough: it is suitable for desktop readers, for mobile, for readers with a PIN-keyboard, for biometrics and for many others.
But, despite the functionality found by us, today smart cards remain the safest way to store key information from all existing ones.
Source: https://habr.com/ru/post/107520/
All Articles