Zeus - thunderstorm for smart cards

    In the course of one joint investigation with Group-IB on fraud in remote banking systems, we investigated several malicious programs. Samples of these programs were obtained by computer forensics experts from Group-IB in the process of solving the crime. The picture was pretty standard: the detected malware turned out to be the Zbot Trojan, which, it would seem, has already been studied up and down, but nevertheless, we decided to dig it a little more. And the fun began. More precisely, a rather curious functionality 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 an infected machine. Well, for example, information about activity with online client banking systems. Zbot constantly checks the visited web pages by intercepting the corresponding WinAPI functions. If an SSL connection is established with resources that contain strings that are of interest to the Trojan, it takes the following actions:

    - analysis of the request string for the presence of the username =. * & Password =. *
    Template - analysis of the query string for the presence of the /bsi.dll/?T template =

    Upon successful detection of these patterns, the procedure of fixing the pressed keys on the keyboard and mouse is launched, 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 all this was noticed in other modifications of Zeus. The most interesting was revealed a bit later. When we studied the functional responsible for finding logical devices connected to the computer, in particular, the Zbot functional 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, a copy of it is sent to the server. By the way, Zeus sends a lot of things to the server:

    - information on connected smart card readers, as well as directly on the smart cards themselves
    - the results of recording keystrokes on the keyboard and mouse, information is recorded in a separate file and sent to the server
    - cookies
    - copies of any file found in the system

    And so 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 assumes a multi-level driver system:

    The basis of this functionality, which works at the SmartCard API level, is the interaction with the Resource Manager, with the help of which access is controlled to several readers 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:

    - constant monitoring and logging of the current state of readers
    - some active actions by an attacker

    Zbot monitors connected readers for reading and also records changes in these devices. In this case, the recorded data is stored in the system structure SCARD_READERSTATEcontaining 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 a random bias, and then sent via a pre-installed 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 some program of actions, which is presented as a control sequence and sent via a network channel, as mentioned above. This control sequence is stored on the infected machine and then processed. Processing a sequence consists of translating its elements into the following Winscard.dll library functions:


    Or it can be represented as the following scheme:


    The function that processes the control sequence looks rather cumbersome, but, for the most part, the


    code looks like this: :


    By combining elementary actions of the SmartCard API level, an attacker can choose the necessary reader and connect to some smart card, write and read information from a smart card, and can use special functions provided by smart cards: data encryption and decryption, electronic-digital generation signatures, generating a sequence of pseudorandom numbers of a fixed length.

    The result of processing the control sequence is saved and sent through the network channel to the attacker to adjust 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 an attacker can be composed and adapted for almost any reader. Therefore, the impact spectrum of attackers is quite large: it is suitable for desktop readers, for mobile, for readers with a PIN keyboard, for biometrics and for many others.

    But, despite the functionality we found, today smart cards remain the safest way to store key information from all existing ones.

    Also popular now: