What do you know about Sality?
Sality is one of the most well-known malware families. In its development, VPO Sality went through several stages.
The first mention of it dates back to July 2003. In its original version, Sality infects executable files by adding its own code, packaged with UPX. The keylogger was used as a payload, the intercepted data was sent via SMTP protocol 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 - gave the name in the classification of the company Dr.Web. At that time, Sality was of no technical interest, the author used rather primitive mechanisms - the file infector was relatively simple compared to other samples of the malware of that time, the SMTP server address was hard coded inside the code and could not be changed, just could not be changed payload.
From 2004 to 2008, the author worked a lot on improving Sality. The method of infection has significantly changed, and the virus became polymorphic without changing the entry point (entry-point obscuring technique), thereby making it difficult to detect and treat. Malicious functions were allocated to separate modules, which could be additionally loaded from a number of URLs fixed in the code. Also included were procedures for countering protection mechanisms: blocking or disabling some firewalls, utilities, and anti-virus programs. Beginning in 2008 (perhaps the end of 2007), the author radically changed the distribution scheme, instead of predetermined addresses that could be easily blocked by anti-virus companies, the peer-to-peer module updates and third-party malicious programs were implemented for later launch.
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.
')
Injection module (injecting into the address space of another process)
Sality tries to inject its copy into all running processes, with the exception of those running on behalf of the 'system', 'local service' and 'network service' accounts. For privileged processes, it exposes itself Debug privileges, and tries to root again. To prevent re-injection, use mutex with the name of the application. This is one of the signs of computer infection.
Protection module
This module protects Sality against antivirus software. To prevent the OS from booting in fail-safe mode (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 work of many anti-virus programs is blocked. Early versions of Sality behaved even more aggressively and simply removed these services from the system.
The virus also injects 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, and the objects are:
For antivirus files (from the list), instead of an infection, an attempt is made to overwrite the entry point code with “GSSS GSSS GSSS GTSZ” 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 a vdb or avc extension (anti-virus signatures from Symantec and Kaspersky).
An interesting feature of the infection module: the infection procedures are disabled if the peer list is empty. This reflects a kind of distribution strategy - there is no need to infect files if there is no connection to the P2P network and downloading additional malicious modules is impossible.
EPO (entry-point obscuring) technique is used for infestation:
Sality checks its presence in the system by a specific mutex, which is different for different variants. When launched from the root directory of the drive, the Explorer window opens.
Download module
The download module is responsible for downloading and launching additional malicious modules from URLs obtained by the peer-to-peer module. The downloaded files are encoded with the RC4 cipher, the key of which is written in the code. Most likely, Sality and its malicious modules were created by the same author. However, malicious modules work in the traditional way and are connected to control servers located throughout the world.
List of malicious modules distributed by Sality:
spam generators and spam gateways (spam relay), the content of spam is usually associated with casino advertising or pharmaceuticals;
HTTP proxy is used to mask network activity and achieve anonymity;
collectors of information , collect passwords, accounts and personal data, including data from web forms (implementation in Internet Explorer);
website infection. This malicious module intercepts FTP accounts, then connects to FTP data and infects HTML files. Infection occurs by implementing an IFRAME pointing to a third-party resource or using scripts that are executed on the server side. The goals 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 that have been launched, apparently, to test the technology. The first module is the Facebook auto-registration script. The module is an information collector embedded in Internet Explorer through a standard COM interface, collects registration data from web forms, sends it to a C & C server and stores it locally in an encrypted form. The experimental module performs a script with the following sequence of actions: open Internet Explorer in visible (!) Window, go to facebook.com, log in using captured registration data, go to the Slots VIP application page (# 11908467418), allow access to the application, close window. The application uses access at the level of 'Basic information' - name, gender, photo and list of friends. At the moment, this module does not produce any malicious actions (therefore, it is called experimental), but the very possibility of this kind of activity allows attackers to use a hacked Facebook account to spread spam (postings) or to purchase virtual credits.
Another script, distributed by Sality, did the following: launch Internet Explorer in invisible mode, go to google.com; start the search for “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 URLs to malicious modules. P2P network has no fixed C & C servers. In the case of Sality, an attempt or blocking of the botnet network would mean the need to block all superpeers, which is theoretically possible, but difficult to implement. The primary connection to the network is performed using the bootstrap list of the peers contained in the infected files and including the public IP and port of a number of already existing peers. In all variations of the virus, the size of the list is limited to 1000 entries.
When 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 later this local list is updated by adding new active peers and removing inactive peers.
There are at least four protocol versions:
Differences between V2 and V3 protocol protocols are minimal. Since each infected file contains a public key used to check the list of URLs, 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 that the private key used to sign the list of URLs was compromised.
In the 3rd version protocol there was a potential vulnerability in the operation algorithm, which allowed to take control of the botnet (anti-virus companies or other attackers) - after downloading and checking the list of URLs, no other checks are made on the addresses themselves or on the files downloaded from them. That is, it was possible to change the DNS records and / or replace the module files with your own, which led to the interception of control. Information about this possibility in order to destroy the botnet was published by an unknown person under the pseudonym of law-abiding citizen (law-abiding citizen). In order to eliminate the indicated weaknesses of the 3rd version, the author seems to have developed the 4th version, in which all uploaded files must be digitally signed and verified before launch with the RSA public key with a length of 2048 bits.
Our days
Currently, Sality continues to be one of the most common malware in the world. A group of researchers from the University of California at San Diego and the University of Napoli (Italy) in October 2012 published a report (pdf, eng) with an analysis of Sality activity. Information was collected using the UCSD Network Telescope passive traffic monitoring system. Researchers say that in a 12-day period in February 2011, 3 million IP addresses received packets to initiate a SIP connection. According to the authors of the report, the botnet owners tried to brute force SIP servers to create fake accounts to use 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 came to initialize the connection, then these addresses were not used. The range of scanned IP addresses varied along the Hilbert fractal curve to make it difficult to detect the fact of scanning. Researchers believe that the entire range of IPv4 was scanned, that is, the entire Internet, but this traffic could not be detected by any threat detection system, since requests were sent from different IP. These facts help to understand the scope of the Sality botnet and assess the intellectual abilities of its creators.
This text is an incomplete Russian translation of the report of the Symantec company “Sality: Story of a Peer-to-Peer Viral Network” , ver.1, July 2011 (pdf, eng).
The first mention of it dates back to July 2003. In its original version, Sality infects executable files by adding its own code, packaged with UPX. The keylogger was used as a payload, the intercepted data was sent via SMTP protocol 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 - gave the name in the classification of the company Dr.Web. At that time, Sality was of no technical interest, the author used rather primitive mechanisms - the file infector was relatively simple compared to other samples of the malware of that time, the SMTP server address was hard coded inside the code and could not be changed, just could not be changed payload.
From 2004 to 2008, the author worked a lot on improving Sality. The method of infection has significantly changed, and the virus became polymorphic without changing the entry point (entry-point obscuring technique), thereby making it difficult to detect and treat. Malicious functions were allocated to separate modules, which could be additionally loaded from a number of URLs fixed in the code. Also included were procedures for countering protection mechanisms: blocking or disabling some firewalls, utilities, and anti-virus programs. Beginning in 2008 (perhaps the end of 2007), the author radically changed the distribution scheme, instead of predetermined addresses that could be easily blocked by anti-virus companies, the peer-to-peer module updates and third-party malicious programs were implemented for later launch.
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.
')
Injection module (injecting into the address space of another process)
Sality tries to inject its copy into all running processes, with the exception of those running on behalf of the 'system', 'local service' and 'network service' accounts. For privileged processes, it exposes itself Debug privileges, and tries to root again. To prevent re-injection, use mutex with the name of the application. This is one of the signs of computer infection.
Protection module
This module protects Sality against antivirus software. To prevent the OS from booting in fail-safe mode (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 work of many anti-virus programs is blocked. Early versions of Sality behaved even more aggressively and simply removed these services from the system.
The virus also injects 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:
- Process Killer — Sality continuously scans the running processes, and if the process name is on the list of security software, the process stops. The list itself is hard coded. To bypass antivirus 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 test IOCTL_PF_SET_EXTENSION_POINTER request 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 was able to discard IP packets that matched the patterns of the addresses of the manufacturers of the antivirus software. As a result, the user could not go, for example, to the site Symantec.com;
- blocker blocking incoming and outgoing SMTP traffic. This functionality was implemented by a user-mode module 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, and the objects are:
- files listed in the registry branch 'HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ ShellNoRoam \ MUICache'. This thread contains the names of the applications that Explorer uses when grouping icons in the taskbar. As a side effect - MUICache is a repository of almost all applications installed on the system;
- files in the launch keys of the 'HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Run' and 'HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows \ CurrentVersion \ Run' branches;
- scans (enumerate) files exe and scr on mounted drives from B to Z;
- 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. Also, the autorun.inf file is created or modified to automatically launch the generated infected files when mounting the disk. When you run 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 an infection, an attempt is made to overwrite the entry point code with “GSSS GSSS GSSS GTSZ” 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 a vdb or avc extension (anti-virus signatures from Symantec and Kaspersky).
An interesting feature of the infection module: the infection procedures are disabled if the peer list is empty. This reflects a kind of distribution strategy - there is no need to infect files if there is no connection to the P2P network and downloading additional malicious modules is impossible.
EPO (entry-point obscuring) technique is used for infestation:
- entry point does not change;
- at the entry address, the jmp transition command to the virus code is recorded; the code is located at the end of the last section, which is specifically expanded for this. In addition to the section flags, the permission for recording and execution is added;
- after decryption, the contents of the file, erased with the jmp command, are restored, the main virus code is launched in a separate thread, and control is transferred to the original entry point.
Sality checks its presence in the system by a specific mutex, which is different for different variants. When launched from the root directory of the drive, the Explorer window opens.
Download module
The download module is responsible for downloading and launching additional malicious modules from URLs obtained by the peer-to-peer module. The downloaded files are encoded with the RC4 cipher, the key of which is written in the code. Most likely, Sality and its malicious modules were created by the same author. However, malicious modules work in the traditional way and are connected to control servers located throughout the world.
List of malicious modules distributed by Sality:
spam generators and spam gateways (spam relay), the content of spam is usually associated with casino advertising or pharmaceuticals;
HTTP proxy is used to mask network activity and achieve anonymity;
collectors of information , collect passwords, accounts and personal data, including data from web forms (implementation in Internet Explorer);
website infection. This malicious module intercepts FTP accounts, then connects to FTP data and infects HTML files. Infection occurs by implementing an IFRAME pointing to a third-party resource or using scripts that are executed on the server side. The goals 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 detection: & 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 (the functionality is not fully implemented);
- hacking accounts: C & C sends the module a list of accounts and a list of passwords for brute force. Detected correct login pair - the password 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, as a rule, financial. You can register a paid number and make a call to it from each of the detected SIP-accounts. Hacking FreePBX can have more serious consequences, since an attacker gains control over the authentication and billing of users, as well as the routing of calls;
Experimental modules , to date, only two experimental modules are known that have been launched, apparently, to test the technology. The first module is the Facebook auto-registration script. The module is an information collector embedded in Internet Explorer through a standard COM interface, collects registration data from web forms, sends it to a C & C server and stores it locally in an encrypted form. The experimental module performs a script with the following sequence of actions: open Internet Explorer in visible (!) Window, go to facebook.com, log in using captured registration data, go to the Slots VIP application page (# 11908467418), allow access to the application, close window. The application uses access at the level of 'Basic information' - name, gender, photo and list of friends. At the moment, this module does not produce any malicious actions (therefore, it is called experimental), but the very possibility of this kind of activity allows attackers to use a hacked Facebook account to spread spam (postings) or to purchase virtual credits.
Another script, distributed by Sality, did the following: launch Internet Explorer in invisible mode, go to google.com; start the search for “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 URLs to malicious modules. P2P network has no fixed C & C servers. In the case of Sality, an attempt or blocking of the botnet network would mean the need to block all superpeers, which is theoretically possible, but difficult to implement. The primary connection to the network is performed using the bootstrap list of the peers contained in the infected files and including the public IP and port of a number of already existing peers. In all variations of the virus, the size of the list is limited to 1000 entries.
When 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 later this local list is updated by adding new active peers and removing inactive peers.
There are at least four protocol versions:
- no instances of the protocol version V1 implementation were found;
- version V2 was first discovered at the beginning of 2008, but is no longer used at the moment;
- The V3 protocol version and the network based on it is by far the most common and extensive. The first mentions of this protocol occur since 2009;
- V4 based network is noticeably smaller than V3 network. It was first discovered at the end of 2010.
Differences between V2 and V3 protocol protocols are minimal. Since each infected file contains a public key used to check the list of URLs, 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 that the private key used to sign the list of URLs was compromised.
In the 3rd version protocol there was a potential vulnerability in the operation algorithm, which allowed to take control of the botnet (anti-virus companies or other attackers) - after downloading and checking the list of URLs, no other checks are made on the addresses themselves or on the files downloaded from them. That is, it was possible to change the DNS records and / or replace the module files with your own, which led to the interception of control. Information about this possibility in order to destroy the botnet was published by an unknown person under the pseudonym of law-abiding citizen (law-abiding citizen). In order to eliminate the indicated weaknesses of the 3rd version, the author seems to have developed the 4th version, in which all uploaded files must be digitally signed and verified before launch with the RSA public key with a length of 2048 bits.
Our days
Currently, Sality continues to be one of the most common malware in the world. A group of researchers from the University of California at San Diego and the University of Napoli (Italy) in October 2012 published a report (pdf, eng) with an analysis of Sality activity. Information was collected using the UCSD Network Telescope passive traffic monitoring system. Researchers say that in a 12-day period in February 2011, 3 million IP addresses received packets to initiate a SIP connection. According to the authors of the report, the botnet owners tried to brute force SIP servers to create fake accounts to use 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 came to initialize the connection, then these addresses were not used. The range of scanned IP addresses varied along the Hilbert fractal curve to make it difficult to detect the fact of scanning. Researchers believe that the entire range of IPv4 was scanned, that is, the entire Internet, but this traffic could not be detected by any threat detection system, since requests were sent from different IP. These facts help to understand the scope of the Sality botnet and assess the intellectual abilities of its creators.
This text is an incomplete Russian translation of the report of the Symantec company “Sality: Story of a Peer-to-Peer Viral Network” , ver.1, July 2011 (pdf, eng).
Source: https://habr.com/ru/post/159055/
All Articles