What do you know about Sality?
Sality is one of the most famous malware families. Sality has gone through several stages in its development.
The first mention of it dates back to July 2003. In its initial version, Sality infected executable files by adding its own UPX-packed code. A keylogger acted as a payload, intercepted data was sent via SMTP to one of the servers located in Russia. The name is derived from the English name of the city - “Salavat City” (Salavat, Republic of Bashkortostan). Presumably the nickname of the developer - Sector - was given the name in the classification of Dr.Web. At that time, Sality was not technically interesting, the author used rather primitive mechanisms - the file infector was relatively simple compared to other malware samples of that time, the SMTP server address was hard-coded inside the code and could not be changed, nor could it be payload changed.
From 2004 to 2008, the author worked hard to improve Sality. The method of infection has changed significantly, and the virus has become polymorphic without changing the entry point (entry-point obscuring technique), thereby complicating the process of detection and treatment. Malicious functions were isolated in separate modules, which could be additionally loaded from a number of URLs that were hardcoded in the code. Also included were procedures to counteract protection mechanisms: blocking or disabling some firewalls, utilities, and antivirus programs. Since 2008 (possibly late 2007), the author has radically changed the distribution scheme, instead of predefined addresses that could be easily blocked by antivirus companies,
Architecture The
following describes the operation of one of the latest versions of Sality (after 2008). All components are independent and run in separate threads.
The injection module (injection into the address space of another process)
Sality tries to embed its copy in all running processes, with the exception of those that run on behalf of the accounts 'system', 'local service' and 'network service'. For privileged processes, exposes Debug privileges, and tries to infiltrate again. To exclude reimplementation, uses mutex with the application name. This is one of the signs of a computer infection.
Protection module
This module protects Sality from antivirus software. To prevent the OS from loading in Safe boot mode, the virus deletes keys and values from the registry in the following branches: 'HKEY_CURRENT_USER \ System \ CurrentControlSet \ Control \ SafeBoot' and 'HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SafeBoot'.
The services of many anti-virus programs are blocked. Early versions of Sality were even more aggressive and simply removed these services from the system.
The virus also introduces a kernel driver. This driver is added under a pseudo-random name in the% System% \ drivers folder. A service is created with the name "amsint32". The driver performs three different functions:
Infection
module The infection module is responsible for the reproduction of the virus, as objects are:
For antivirus files (from the list), instead of infection, an attempt is made to rewrite the entry point code with the bytes “СССЗ СССЗ СССЗ СССЗ” (repeated instructions int 3 and ret). If this operation fails, Sality attempts to delete the file. The infection module also scans directories and deletes files with the extension vdb or avc (signatures of antivirus companies Symantec and Kaspersky).
An interesting feature of the infection module: infection procedures are disabled if the peer list is empty. This reflects a peculiar distribution strategy - there is no need to infect files if there is no connection to a P2P network and downloading additional malicious modules is not possible.
For infection, the EPO (entry-point obscuring) technique is used:
Sality checks its presence in the system for a specific mutex, different for different options. When launched from the root directory of the disk, the Explorer window opens.
Download
module The download module is responsible for downloading and launching additional malicious modules from the URLs received by the peer-to-peer module. The downloaded files are encoded with the RC4 cipher, the key of which is registered in the code. It is most likely that Sality and its malicious modules were created by the same author. However, malicious modules work in a traditional way and connect to management servers located around the world.
The list of malicious modules distributed by Sality:
spam generators and spam relays, spam content is usually associated with casino advertising or pharmaceuticals;
HTTP proxies are used to mask network activity and achieve anonymity;
information collectors , collect passwords, accounts and personal data, including data from web forms (implementation in Internet Explorer);
website infection. This malicious module intercepts FTP accounts and then connects to FTP data and infects HTML files. Infection occurs by embedding an IFRAME that points to a third-party resource or using scripts that run on the server side. The objectives of such infections can range from drive-by downloads and infection of user computers to spam mailings;
distributed hacking system, in February 2011, a module was distributed that could work in several modes depending on the C&C server commands:
experimental modules, to date, only two experimental modules are known, which were apparently launched to test the technology. The first module is a script for automatically registering a Facebook application. The module is a data collector implemented in Internet Explorer via the standard COM interface, collects registration data from web forms, sends it to the C&C server and saves it locally in encrypted form. The experimental module executes a script with the following sequence of actions: open Internet Explorer in a visible (!) Window mode, go to facebook.com, log in using intercepted registration data, go to the VIP Slots application page (# 11908467418), allow access to the application, close window. The application uses access at the level of 'Basic information' - name, gender, photo and friend list.
Another script distributed by Sality performed the following actions: launch Internet Explorer in invisible mode, go to google.com; run a search for the string "auto insurance bids"; close a window. The script serves experimental purposes and allows you to promote certain topics in Google Trends.
Peer-to-peer module
The peer-to-peer module is responsible for distributing URL links to malicious modules. The P2P network does not have fixed C&C servers. In the case of Sality, an attempt to block a botnet’s network will mean the need to block all superpeers, which is theoretically possible but difficult to implement. The initial connection to the network is via the bootstrap list of peers contained in infected files and including the public IP and port of a number of existing peers. In all variations of the virus, the list size is limited to 1000 entries.
At the time Sality is first launched, a local copy of the initial list is created in the Windows registry (in the HKEY_CURRENT_USER branch under a pseudo-random name), and then this local list is updated by adding new active ones and removing inactive peers.
There are at least four protocol versions:
The differences between the protocol versions V2 and V3 are minimal. Since each infected file contains a public key used to check the list of URL links, each new version of the protocol requires the use of a new key. It can be assumed that the transition from version V2 to V3 was dictated by the fact of compromising the private key used to sign the list of URLs.
The protocol of the 3rd version contained a potential vulnerability in the operation algorithm, which allowed it to take control of a botnet (anti-virus companies or other intruders) - after downloading and checking the list of URLs, no other checks are performed on the addresses themselves or on the files downloaded from them. That is, you could change the DNS records and / or replace the module files with your own, which led to an interception of control. Information about this possibility in order to destroy the botnet was published by an unknown person under the pseudonym law-abiding citizen (law-abiding citizen). In order to eliminate the indicated weaknesses of the 3rd version, it seems that the author developed the 4th version, in which all the downloaded files must contain a digital signature and are verified before starting using an RSA public key with a length of 2048 bits.
Nowadays
Currently Sality continues to be one of the most widespread malicious programs in the world. A group of researchers from the University of California at San Diego and the University of Napoli (Italy) published a report in October 2012 (pdf, eng) with an analysis of Sality activity. Information was collected using the passive traffic monitoring system UCSD Network Telescope. Researchers say that in a 12-day period in February 2011, packets came from 3 million IP addresses to initiate a SIP connection. According to the authors of the report, the botnet owners tried to brute force the SIP server to create fake accounts in order to use them for free telephony, anonymous calls, fraud, etc.
Interestingly, a number of techniques were used to mask the scan as much as possible. For example, from 1 million IP addresses, only one packet was sent to initialize the connection, then these addresses were not used. The range of scanned IP addresses was varied along the Hilbert fractal curve to make it difficult to detect the fact of scanning. Researchers believe that the entire range of IPv4, that is, the entire Internet, was scanned, but no threat detection system could detect this traffic, since requests came from different IPs. These facts help to understand the scope of the Sality botnet and evaluate the intellectual abilities of its creators.
This text is an incomplete Russian translation of Symantec 's Sality: Story of a Peer-to-Peer Viral Network report, ver. 1, July 2011 (pdf, eng).
The first mention of it dates back to July 2003. In its initial version, Sality infected executable files by adding its own UPX-packed code. A keylogger acted as a payload, intercepted data was sent via SMTP to one of the servers located in Russia. The name is derived from the English name of the city - “Salavat City” (Salavat, Republic of Bashkortostan). Presumably the nickname of the developer - Sector - was given the name in the classification of Dr.Web. At that time, Sality was not technically interesting, the author used rather primitive mechanisms - the file infector was relatively simple compared to other malware samples of that time, the SMTP server address was hard-coded inside the code and could not be changed, nor could it be payload changed.
From 2004 to 2008, the author worked hard to improve Sality. The method of infection has changed significantly, and the virus has become polymorphic without changing the entry point (entry-point obscuring technique), thereby complicating the process of detection and treatment. Malicious functions were isolated in separate modules, which could be additionally loaded from a number of URLs that were hardcoded in the code. Also included were procedures to counteract protection mechanisms: blocking or disabling some firewalls, utilities, and antivirus programs. Since 2008 (possibly late 2007), the author has radically changed the distribution scheme, instead of predefined addresses that could be easily blocked by antivirus companies,
Architecture The
following describes the operation of one of the latest versions of Sality (after 2008). All components are independent and run in separate threads.
The injection module (injection into the address space of another process)
Sality tries to embed its copy in all running processes, with the exception of those that run on behalf of the accounts 'system', 'local service' and 'network service'. For privileged processes, exposes Debug privileges, and tries to infiltrate again. To exclude reimplementation, uses mutex with the application name. This is one of the signs of a computer infection.
Protection module
This module protects Sality from antivirus software. To prevent the OS from loading in Safe boot mode, the virus deletes keys and values from the registry in the following branches: 'HKEY_CURRENT_USER \ System \ CurrentControlSet \ Control \ SafeBoot' and 'HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SafeBoot'.
The services of many anti-virus programs are blocked. Early versions of Sality were even more aggressive and simply removed these services from the system.
The virus also introduces a kernel driver. This driver is added under a pseudo-random name in the% System% \ drivers folder. A service is created with the name "amsint32". The driver performs three different functions:
- “Killer” of processes (process killer) - Sality continuously scans running processes, and if the process name is included in the list of security software, then this process stops. The list itself is hardcoded in code. To bypass anti-virus self-defense, all processes are destroyed by the driver at the kernel level;
- packet filter - the driver registers the 'IPFilter Callback routine' function by sending a control request IOCTL_PF_SET_EXTENSION_POINTER to the IPFilter driver (this function worked in Windows XP / 2003/2000, but is no longer used in Vista and later versions). Thanks to this feature, Sality could drop IP packets that corresponded to the address patterns of antivirus software vendor sites. As a result, the user could not go, for example, to Symantec.com;
- blocker (blocker) of incoming and outgoing SMTP traffic. This functionality was implemented by a module operating in user mode, and was launched upon a command from the botnet operator. In later versions, this module was not used, although its code was preserved.
Infection
module The infection module is responsible for the reproduction of the virus, as objects are:
- Files listed in the registry branch 'HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ ShellNoRoam \ MUICache'. This branch contains the names of the applications that Explorer uses when grouping icons in the taskbar. As a side effect - MUICache is the repository of almost all applications installed on the system;
- files in the run keys of the branches 'HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Run' and 'HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows \ CurrentVersion \ Run';
- scans (enumerate) exe and scr files on mounted drives from B to Z;
- the root directories of disks other than the Windows partition are infected by creating an infected copy of the Calculator or Minesweeper programs. The file is created with an arbitrary name and extension exe, cmd or pif. The autorun.inf file is also created or modified to automatically launch the created infected files when mounting the disk. When starting such a file, instead of starting the corresponding program (“Calculator” or “Minesweeper”), the Explorer window opens;
- network resources are scanned for executable files.
For antivirus files (from the list), instead of infection, an attempt is made to rewrite the entry point code with the bytes “СССЗ СССЗ СССЗ СССЗ” (repeated instructions int 3 and ret). If this operation fails, Sality attempts to delete the file. The infection module also scans directories and deletes files with the extension vdb or avc (signatures of antivirus companies Symantec and Kaspersky).
An interesting feature of the infection module: infection procedures are disabled if the peer list is empty. This reflects a peculiar distribution strategy - there is no need to infect files if there is no connection to a P2P network and downloading additional malicious modules is not possible.
For infection, the EPO (entry-point obscuring) technique is used:
- entry point does not change;
- the jmp command for switching to the virus code is recorded at the input address, the code is located at the end of the last section, which is expanded specifically for this. In addition to section flags, recording and performance permission is added;
- after decryption, the contents of the file deleted by the jmp command are restored, the main virus code is launched in a separate stream, control is transferred to the original entry point.
Sality checks its presence in the system for a specific mutex, different for different options. When launched from the root directory of the disk, the Explorer window opens.
Download
module The download module is responsible for downloading and launching additional malicious modules from the URLs received by the peer-to-peer module. The downloaded files are encoded with the RC4 cipher, the key of which is registered in the code. It is most likely that Sality and its malicious modules were created by the same author. However, malicious modules work in a traditional way and connect to management servers located around the world.
The list of malicious modules distributed by Sality:
spam generators and spam relays, spam content is usually associated with casino advertising or pharmaceuticals;
HTTP proxies are used to mask network activity and achieve anonymity;
information collectors , collect passwords, accounts and personal data, including data from web forms (implementation in Internet Explorer);
website infection. This malicious module intercepts FTP accounts and then connects to FTP data and infects HTML files. Infection occurs by embedding an IFRAME that points to a third-party resource or using scripts that run on the server side. The objectives of such infections can range from drive-by downloads and infection of user computers to spam mailings;
distributed hacking system, in February 2011, a module was distributed that could work in several modes depending on the C&C server commands:
- SIP and HTTP server discovery: C&C sends the module a list of IP addresses to scan. The scan result is reported to the C&C server;
- registration of accounts on the target server (functionality is not fully implemented);
- hacking accounts: C & C sends the module a list of accounts and a list of passwords for enumeration. The detected valid login-password pair is sent back to the C&C server;
- hacking Asterisk FreePBX, server lists and password lists found in the previous step or obtained from other sources are used to detect and select passwords for Asterisk FreePBX servers. The objectives of this kind of attack are usually financial. You can register a paid number and make a call to it from each of the detected SIP accounts. Hacking FreePBX can have even more serious consequences, since an attacker gains control over the authentication and charging of users, as well as call routing;
experimental modules, to date, only two experimental modules are known, which were apparently launched to test the technology. The first module is a script for automatically registering a Facebook application. The module is a data collector implemented in Internet Explorer via the standard COM interface, collects registration data from web forms, sends it to the C&C server and saves it locally in encrypted form. The experimental module executes a script with the following sequence of actions: open Internet Explorer in a visible (!) Window mode, go to facebook.com, log in using intercepted registration data, go to the VIP Slots application page (# 11908467418), allow access to the application, close window. The application uses access at the level of 'Basic information' - name, gender, photo and friend list.
Another script distributed by Sality performed the following actions: launch Internet Explorer in invisible mode, go to google.com; run a search for the string "auto insurance bids"; close a window. The script serves experimental purposes and allows you to promote certain topics in Google Trends.
Peer-to-peer module
The peer-to-peer module is responsible for distributing URL links to malicious modules. The P2P network does not have fixed C&C servers. In the case of Sality, an attempt to block a botnet’s network will mean the need to block all superpeers, which is theoretically possible but difficult to implement. The initial connection to the network is via the bootstrap list of peers contained in infected files and including the public IP and port of a number of existing peers. In all variations of the virus, the list size is limited to 1000 entries.
At the time Sality is first launched, a local copy of the initial list is created in the Windows registry (in the HKEY_CURRENT_USER branch under a pseudo-random name), and then this local list is updated by adding new active ones and removing inactive peers.
There are at least four protocol versions:
- no instances of the implementation of protocol version V1 were detected;
- V2 was first discovered in early 2008, but is no longer in use;
- the version of the V3 protocol and the network based on it are by far the most widespread and branched. The first mention of this protocol is found since 2009;
- the network based on the V4 protocol is noticeably smaller than the V3 network. It was first discovered at the end of 2010.
The differences between the protocol versions V2 and V3 are minimal. Since each infected file contains a public key used to check the list of URL links, each new version of the protocol requires the use of a new key. It can be assumed that the transition from version V2 to V3 was dictated by the fact of compromising the private key used to sign the list of URLs.
The protocol of the 3rd version contained a potential vulnerability in the operation algorithm, which allowed it to take control of a botnet (anti-virus companies or other intruders) - after downloading and checking the list of URLs, no other checks are performed on the addresses themselves or on the files downloaded from them. That is, you could change the DNS records and / or replace the module files with your own, which led to an interception of control. Information about this possibility in order to destroy the botnet was published by an unknown person under the pseudonym law-abiding citizen (law-abiding citizen). In order to eliminate the indicated weaknesses of the 3rd version, it seems that the author developed the 4th version, in which all the downloaded files must contain a digital signature and are verified before starting using an RSA public key with a length of 2048 bits.
Nowadays
Currently Sality continues to be one of the most widespread malicious programs in the world. A group of researchers from the University of California at San Diego and the University of Napoli (Italy) published a report in October 2012 (pdf, eng) with an analysis of Sality activity. Information was collected using the passive traffic monitoring system UCSD Network Telescope. Researchers say that in a 12-day period in February 2011, packets came from 3 million IP addresses to initiate a SIP connection. According to the authors of the report, the botnet owners tried to brute force the SIP server to create fake accounts in order to use them for free telephony, anonymous calls, fraud, etc.
Interestingly, a number of techniques were used to mask the scan as much as possible. For example, from 1 million IP addresses, only one packet was sent to initialize the connection, then these addresses were not used. The range of scanned IP addresses was varied along the Hilbert fractal curve to make it difficult to detect the fact of scanning. Researchers believe that the entire range of IPv4, that is, the entire Internet, was scanned, but no threat detection system could detect this traffic, since requests came from different IPs. These facts help to understand the scope of the Sality botnet and evaluate the intellectual abilities of its creators.
This text is an incomplete Russian translation of Symantec 's Sality: Story of a Peer-to-Peer Viral Network report, ver. 1, July 2011 (pdf, eng).