Keep Your Account Safe by Avoiding Dyzap Malware

Introduction

Dyzap belongs to a family of malware designed to steal confidential information from enormous target applications by installing a “man in the browser” attack into common browsers. FortiGuard Researchers recently discovered a new variant of this Trojan virus. Stolen information may include, but is not limited to, system information and application credentials stored on infected systems. In this blog, we will explain how the malware steals user accounts, acts as a keylogger, and communicates with its C&C server.

Stealing Routine

Dyzap targets more than one hundred applications to steal information from, including browsers, FTP applications, and more.

Figure 1: Major stealing routine

In order to steal data from different kinds of applications, Dyzap approaches each of them differently. This enables it to steal data from databases, registries and also from the files of applications installed on the infected machine. Figure 2 shows some of the targeted applications, such as Fossamail, Postbox, and others.

Figure 2: Part of applications that malware attempts to steal

To gain a better understanding of the different approaches Dyzap is able to employ, we picked four applications and analyzed how Dyzap obtains login credentials from them. All the following analysis has been conducted under Windows 7 32-bit. Referenced paths might be different in other OSs.

Chrome Family

One of the main routines of Dyzap is to steal login information from the sqlite3 database file. As an example, Chromium stores login information in a file called “Login Data” or “Web Data.” Using the code snippet and hard coded file path shown in Figure 3, it searches for possible directory containing the files just mentioned. If the file exists, it copies the content into a temp file for further operations.

To acquire login information, it first verifies that the target is a SQlite3 file. Next, it looks up a “unique” string pattern to extract login information from the “logins” table. Finally, it extracts user account using the string patterns “password_value,” “username_value,” and “original_url,” as shown in in Figure 4.

Firefox Family

For the Firefox family of browsers, Dyzap searches for the signons.sqlite and login.json files to locate and steal credentials. Despite the misleading name of login.json, it is actually a sqlite database that includes all saved usernames and passwords. These browsers include Firefox, IceDragon, Safari, K-Melon, SeaMonkey, Flok, Thunderbird, BlackHawk, Postbox, Cyberfox, and Pale Moon.

Far FTP

Other than stealing from database files, the Dyzap malware also attempts to harvest confidential information from the registry for some FTP applications. For instance, in Far FTP the malware simply searches the following paths, as shown in Figure 5:

HKCU\Software\Far\Plugins\FTP\Hosts

HKCU\Software\Far2\Plugins\FTP\Hosts

Figure 5: Stealing from Far2 registry

Upon finding them, Dyzap queries subkeys values for “Password,” “User,” and “HostName.” Table 1, below, is a list of the applications that may be targeted by their registries. Malware is then hardcoded into the registry’s path – which might contain confidential information – for each application.

Pidgin

Another capability of Dyzap is stealing confidential information from files storing login credentials that reside on the infected machine. For instance, Pidgin is a chat program, which lets the user log in to accounts on multiple chat networks simultaneously. This app saves the login information for the accounts inside an XML file in

"%AppData%\Roaming\.purple\accounts.xml." Dyzap tries to find the *.xml file by searching in possible directories (Figure 6) and then copies the file to be sent later to its C&C server.

Figure 6: Possible directories to find target file

The following table shows all the applications and associated files that the malware searches in looking for confidential information.

Table 2: List of applications which malware tries to steal from their component files

KeyLogger Feature

In its keylogger component, the malware creates a new thread to capture all keyboard inputs, clipboard data, and window titles, as shown in Figure 8. All the stolen information is saved in a file created by the malware with %RANDOM-NUMBER%.kdb in a temp folder. In order to hook to the keyboard, the malware calls SetWindowsHookExW() to capture keyboard input. The keylogger result will also be uploaded to the C&C server along with other stolen information.

C&C Communication

After collecting data from targeted applications, a packet of stolen information is prepared. Data is sent to the C&C server in a serialized binary format. The packet structure contains three major substructures, with each piece of information filled in one of the following blocks shown in Table 3:

struct Block_1 {

WORD tag;

}

hard coded tags

struct Block_2 {

WORD data_type;

DWORD data_size;

BYTE data[];

}

data_type - 00 or 01 to indicate the nickname is Unicode or Ascii

data_size - Size of following data

struct Block_3{

DWORD data_size;

BYTE data[];

}

data_size - Size of following data

Table 3:Basic structures of blocks

The packed information starts with hard coded tags. All the tags sitting in block 1 are illustrated as B1 in Figure 7. For instance, 0x12 and 0x27 in the packet appears as \x12\x00\x27\x00. Following that, a hard-coded string, “PWSBin,” is appended to tags in the block 2 format (section 1 in Table 4). In figure 7, this part is shown as Tag1, Tag2, Type, Size, and Data.

The packet continues with all the collected information from the infected machine, including respectively; Username, Computer Name, Domain name in block 2 format, Windows coordinates (top-left, bottom-right). Next, it checks to see if the current user is admin, if the security identifier for the user is enabled, and if the infected machine is 32-bit or 64-bit. It then includes the Windows major version, minor version, and product type, along with one pre-initialized byte, four tags in row (\x01, \x00, \x00, \x00\) appended to the packet in the form of block 1.

The packet continues with four bytes of size, indicating the stolen data – encrypted by malware (A*.) The mutex string type, size, and data, as well as a 5 bytes random string created by the malware using system time are also added, with block 2 format (B*.) Lastly, the stolen encrypted data and its size is appended to the packed with block 3 format (C*,D*.) Interestingly, each stolen data section starts with a byte that shows an index from an index list indicating the corresponding application.

Figure 10: HTTP request content sent to server

Section

Format

Section

Format

01

struct Register{

WORD tag1 ;

WORD tag2;

WORD nickname1_type;

DWORD nickname1_size;

BYTE nickname1[6];

}

06

struct Tags{

WORD tag3;

WORD tag4;

WORD tag5;

WORD tag6;

}

02

struct StealUserName{

WORD UserName_type;

DWORD UserName_size;

BYTE UserName[];

}

07

struct OriginalStolenSize{

DWORD SizeOfStolenInfo ;

}

03

struct StealPCName{

WORD PCName_type;

DWORD PCName_size;

BYTE PCName[];

}

08

struct Mutex{

WORD Mutex_type;

DWORD Mutex_size;

BYTE MutexName[];

}

04

struct StealDomainName{

WORD DomainName_type;

DWORD DomainName_size;

BYTE DomainName[];

}

09

struct NickName2{

WORD nickname2_type;

DWORD nickname2_size;

BYTE nickname2[5];

}

05

struct StealPCInfo{

WORD SePrivilegeIsSet;

WORD SIDIsSet;

WORD ProcessorIsAMD64;

WORD MajorVersion;

WORD MinorVersion;

WORD ProductType;

WORD Pre_initialized;

}

10

struct StolenInfo{

WORD StolenInfo_size;

BYTE StolenInfo[];

}

Table 4: Commands & Control Traffic Summary

Conclusion

Dyzap is a multi-task malware that is not limited to one way of stealing information. Neither local files of installed applications nor their registries are safe. But Dyzap not only collects data from applications. It is also curious about and can collect your keyboard entries. The current version is now powerful enough to steal from numerous applications. In this blog, we showed how data stealing occurs, as well as how the malware puts all the collected data into a decent binary format before sending it to its C&C server.