Sality virus modifies the DNS service of routers
The Win32 / Sality file infector family has been known for a long time and has been using a P2P-based botnet since 2003. Sality can act both as a virus and as a downloader of other malicious programs that are used to send spam, create DDoS, generate ad traffic or hack VoIP accounts. Commands and files transmitted over the Sality network are encrypted using RSA (the so-called digital signature). The modular architecture of the malicious program, as well as the longevity of the botnet, show how well the attackers approached the creation of this malicious code.
We tracked the Win32 / Sality botnet for a long time and observed more than 115,000 available IP addresses that were instructed by “super peers” to maintain the botnet in working condition and coordinate them. We saw similar Sality components that he downloaded onto infected computers. Some of them were similar and differed only in behavior. However, recently, we have discovered a new component with previously unnoticed properties. Unlike the already known Sality components, which are used to steal passwords from FTP accounts and send spam, it has the ability to substitute the address of the router’s primary DNS server (DNS hijacking). According to our telemetry data, this component appeared at the end of October 2013. It was named Win32 / Rbrute .
')
The Win32 / RBrute component adds truly new features to the work of Win32 / Sality. The first module, detected by ESET as Win32 / RBrute.A , searches the webpages of the router's control panels by scanning a specific set of IP addresses to change the record of the main DNS server. The new fraudulent DNS server redirects users to a fake Google Chrome browser installation webpage when they access websites containing the words “google” or “facebook” in the domain name. Instead of a browser, the user is downloaded a malicious Win32 / Sality file itself. Thus, the attackers secure their new installations and the expansion of the botnet of this malware family.
The IP address that is used as the primary DNS server on the compromised router is actually part of the Win32 / Sality network. There is another modification of the malware, Win32 / RBrute.B , it installs Sality on compromised computers and can act as a DNS or HTTP proxy server to deliver a fake Google Chrome browser installer to users who have been redirected through a malicious router.
We can say that the modification technique of the main DNS router is already quite common for various purposes, starting with the purpose of stealing online banking data and ending with blocking client connections to security vendors' websites. This was especially true in connection with the recent discovery of vulnerabilities in the firmware of various models of routers. Win32 / RBrute.A tries to find the administrative web pages of routers by scanning a range of IP addresses received from the C & C server. In the future, a report on this operation will be sent back to the C & C server. At the time of our analysis, Win32 / RBrute.A was used to gain access to the following router models:
If a web page is found, the C & C server sends the bot a small list of ten brute force passwords. In the case when the bot picked up the desired password and can log into the account of the router, it will begin to change the settings of the DNS server. It is interesting to note that to gain access to the administrative panel account, only the password search method is used without exploiting any vulnerability. Authentication can be done with the usernames “admin” or “support”, although previous versions also tried to use “root” and “Administrator”. Below is a list of passwords that were transmitted from the C & C server to the bot:
In case of successful login, the malicious code changes the address of the main DNS server to a fake one, reports a successful infection operation to C & C and continues scanning the range of IP addresses. After such a DNS modification has been made, all requests for address resolvers will go through this server to malicious users, who will relay them to web pages with fake Google Chrome browser installers, in the case of the presence of the “facebook” or “google” domains in the original request.
Fig. The webpage if the domain is successfully redirected, which contains the word "google."
This malware is somewhat similar to the well-known DNSChanger, which redirected users to install malware through advertising fake software. On the advertising sites themselves, the user is redirected through a malicious DNS.
In the case of Sality, as soon as the computer is exposed to infection through a fake Google Chrome browser installer launched by a user, the configuration of the DNS server in Windows is changed to 8.8.8.8 by malicious code by modifying the NameServer registry value to the specified value in HKLM \ SYSTEM \ ControlSet001 \ Services \ Tcpip \ Parameters \ Interfaces \ {network interface UUID}. This IP address is not malicious and belongs to Google's alternative DNS server .
After the installation of the DNS server is completed, the DNS record of the router for this PC becomes useless and the OS will use the server explicitly specified in the registry. On the other hand, other computers that will try to connect to this router will be subjected to malicious redirections, since the router's DNS record is still modified.
The Win32 / Sality malware, which modifies the router's DNS service, consists of two executable files: a router address scanner and a DNS / HTTP server.
The address scanner is detected by ESET as Win32 / RBrute.A . At the beginning of his work, he creates a mutex with the name "19867861872901047sdf", which allows him to keep track of an already running instance of malware. Then every minute he checks the hard-wired IP address in the code to get the command. The command can be of two types: check the range of IP addresses or try to log into the account of the control panel of the router to modify the DNS service. The instruction for checking the range of addresses comes with the IP address of the beginning of the range and the number of addresses. Win32 / RBrute.A will send an HTTP GET request to TCP port 80, hoping to get an error 401 - Unauthorized. The router model will be extracted from the HTTP protocol's realm attribute (more precisely, see its authentication scheme ). If a router is found, the malicious program sends its IP address back to C & C.
Fig. A block diagram of the work of Win32 / RBrute.A.
After the IP address is sent to C & C, the bot receives a command to enter the control panel of the router. It uses the login and password issued by C & C. In case of successful login, the malicious code modifies the address of the main DNS server, which will now point to another computer infected with another modification of RBrute - Win32 / RBrute.B .
Earlier we mentioned a component of a malicious program that acts as a DNS / HTTP server. It is detected as Win32 / RBrute.B. and the execution of its code is divided into three streams: a control flow, a DNS server flow and an HTTP server flow. Although this malicious component can simultaneously run both DNS and HTTP services, in fact, it selects one of them to run using a randomly generated value. A special constant in the formula is used to ensure that in 80% of the cases the bot will act as a DNS server, although in the initial period of tracking the operation using this malicious program, we observed a constant that guaranteed 50% of the cases as DNS.
Fig. Code to select a DNS or HTTP server to start.
RBrute.B has another branch of the code, which is executed when the above code worked incorrectly.
Fig. Another mechanism for launching HTTP / DNS server streams in malicious code.
RBrute operators can manually start the above streams by sending a specially crafted DNS or HTTP request. Like RBrute.A, RBrute.B uses a special mutex named "SKK29MXAD" to prevent its second copy from running on an infected system.
The control thread is used to send data collected by the malware back to the C & C server. Every two minutes RBrute.B sends a data packet to a hard-wired IP address. This package contains information about the system in which the bot is running. The managing server will then provide the bot with an IP address that will be used to deliver the fake Google Chrome installer. If the bot is running in DNS server mode, the IP address of the C & C server will be the same as the address you want to use as a distribution server of a fake browser installer. Otherwise, the management server will send the IP address that is outside the Sality P2P infrastructure and will be used to distribute fake Chrome installers.
The following is information about the system that is sent by the control flow to a remote server.
Information package has the following format:
Below is a screenshot of the package information sent to C & C.
Fig. Package sent by the bot to the remote server. Blue is the checksum field, red is the payload size field, black is the encrypted server operation mode constant, and green is the encrypted system information.
Information about the system can be (in the package encrypted using RC4):
9BC13555 | 03.24.2014 21: 56: 27 | United States | C: \ WINDOWS | Microsoft Windows XP | proc # 0 QEMU Virtual CPU version 1.0 | 1 | 358 | 511 | 1117 | 1246 | 0 | 2 | 0 | 0 |
The management server will then respond with a packet that contains the IP address to use. The package has the form.
The DNS server component stream is waiting for requests that contain the words “google” or “facebook” in the domain name. If it detects a similar request, an IP address of the HTTP server required by the attackers, which they previously sent to this bot (Win32 / Rbrute.B) via C & C, is sent to the unsuspecting client. If the request does not contain these two words, it will be redirected to the Google DNS service ("8.8.8.8" or "8.8.4.4"), and then to the client.
A bot sending a request to the server via the UDP protocol on port 53 of a packet with the constant “0xCAFEBABE” in the payload field will result in the setting of the “udme” flag in the HKEY_CURRENT_USER \ SOFTWARE \ Fihd4 registry section. This flag ensures that the DNS server stream will be started after a reboot. The server must respond with the constant "0xDEADCODE" to confirm that this action is completed.
We mentioned a separate HTTP service stream in Win32 / RBrute.B. Consider it in more detail. This service serves users who have been redirected through a malicious DNS router to download a fake Google Chrome browser distribution. When receiving a request via HTTP, the service flow will first analyze the User-Agent parameter in the header. Further service behavior depends on what is in this parameter.
If the User-Agent parameter contains the string "linux" or "playstation", the service will simply break the connection. If the User-Agent contains information that the browser is used on a mobile device (there are "android", "tablet", "Windows CE", "blackberry" or "opera mini"), then the service may respond with a fake browser installer . Also, a fake Chrome installer will be delivered if the User-Agent contains “opera”, “firefox”, “chrome”, “msie”, or something else.
As in the case of the DNS service, the operator can itself influence the behavior of the HTTP service by sending a specially formed HTTP packet. He can do this by sending a GET or POST request with a special User-Agent "BlackBerry9000 / 5.0.0.93 Profile / MIDP-2.0 Configuration / CLDC-2.1 VendorID / 831", which will cause the bot to set the "htme" flag in the HKEY_CURRENT_USER \ SOFTWARE registry key \ Fihd4. This ensures that the HTTP server starts after a reboot. The server (bot with Win32 / RBrute.B) must respond with the message “kenji oke” to confirm the execution of the command.
All Sality components that need to receive connections from the network incorporate the same code to add a special Windows Firewall rule that allows inbound connections for the malware process. Such an operation is performed by adding the parameter " harmful_file_program_name: *: Enabled: ipsec " to the registry key HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ SharedAccess \ Parameters \ FirewallPolicy \ StandardProfile \ AuthorizedApplications \ List. Below is the function code add_to_firewall_exception Sality , which performs this operation.
In the Win32 / RBrute.B component, this function is called at the beginning of the execution of the malicious program.
Fig. From here, the add_to_firewall_exception function is called .
A similar code is in the spam bot component, which belongs to Sality.
Fig. Spam bot code Sality, in which add_to_firewall_exception is called .
Our telemetry data shows that Win32 / Sality activity is currently declining, or at least remains at the same level as in 2012. We believe that the reduction in the number of detections is due to the low efficiency of current users' infection vectors. This could explain the fact that attackers are looking for new ways to spread Win32 / Sality.
If we look at the statistics of Sality detections over the last year, we will see a slight increase in the number of detections, approximately in December 2013. This date coincides with the time of the first activity of the RBrute component, which replaces the router's DNS service.
We are not sure whether the RBrute component is real for attackers, since the vast majority of routers are only listened to by a rigidly fixed address space (i.e., 192.168.0.0/16), which makes the control panel inaccessible from the Internet. In addition, the RBrute component does not brute forcefully, but only tries to apply ten passwords from its list.
Conclusion
Simple vectors infecting users with Win32 / Sality malicious code may not be efficient enough to keep the botnet population at an appropriate level. The attackers needed a new way to distribute the malware and in this way became the DNS hijacking for the router. Depending on whether the selected router is susceptible to exploitation, many users connected to it may be victims of redirections. We recommend using secure passwords for accounts of control panels of routers, and also to check whether it is really necessary to allow access to it from the Internet.
We tracked the Win32 / Sality botnet for a long time and observed more than 115,000 available IP addresses that were instructed by “super peers” to maintain the botnet in working condition and coordinate them. We saw similar Sality components that he downloaded onto infected computers. Some of them were similar and differed only in behavior. However, recently, we have discovered a new component with previously unnoticed properties. Unlike the already known Sality components, which are used to steal passwords from FTP accounts and send spam, it has the ability to substitute the address of the router’s primary DNS server (DNS hijacking). According to our telemetry data, this component appeared at the end of October 2013. It was named Win32 / Rbrute .
')
The Win32 / RBrute component adds truly new features to the work of Win32 / Sality. The first module, detected by ESET as Win32 / RBrute.A , searches the webpages of the router's control panels by scanning a specific set of IP addresses to change the record of the main DNS server. The new fraudulent DNS server redirects users to a fake Google Chrome browser installation webpage when they access websites containing the words “google” or “facebook” in the domain name. Instead of a browser, the user is downloaded a malicious Win32 / Sality file itself. Thus, the attackers secure their new installations and the expansion of the botnet of this malware family.
The IP address that is used as the primary DNS server on the compromised router is actually part of the Win32 / Sality network. There is another modification of the malware, Win32 / RBrute.B , it installs Sality on compromised computers and can act as a DNS or HTTP proxy server to deliver a fake Google Chrome browser installer to users who have been redirected through a malicious router.
We can say that the modification technique of the main DNS router is already quite common for various purposes, starting with the purpose of stealing online banking data and ending with blocking client connections to security vendors' websites. This was especially true in connection with the recent discovery of vulnerabilities in the firmware of various models of routers. Win32 / RBrute.A tries to find the administrative web pages of routers by scanning a range of IP addresses received from the C & C server. In the future, a report on this operation will be sent back to the C & C server. At the time of our analysis, Win32 / RBrute.A was used to gain access to the following router models:
- Cisco routers that contain the string "level_15_" in the HTTP protocol realm attribute
- D-Link DSL-2520U
- D-Link DSL-2542B
- D-Link DSL-2600U
- Huawei EchoLife
- TP-LINK
- TP-Link TD-8816
- TP-Link TD-8817
- TP-Link TD-8817 2.0
- TP-Link TD-8840T
- TP-Link TD-8840T 2.0
- TP-Link TD-W8101G
- TP-Link TD-W8151N
- TP-Link TD-W8901G
- TP-Link TD-W8901G 3.0
- TP-Link TD-W8901GB
- TP-Link TD-W8951ND
- TP-Link TD-W8961ND
- TP-Link TD-W8961ND
- ZTE ZXDSL 831CII
- ZTE ZXV10 W300
If a web page is found, the C & C server sends the bot a small list of ten brute force passwords. In the case when the bot picked up the desired password and can log into the account of the router, it will begin to change the settings of the DNS server. It is interesting to note that to gain access to the administrative panel account, only the password search method is used without exploiting any vulnerability. Authentication can be done with the usernames “admin” or “support”, although previous versions also tried to use “root” and “Administrator”. Below is a list of passwords that were transmitted from the C & C server to the bot:
- empty line
- 111111
- 12345
- 123456
- 12345678
- abc123
- admin
- Administrator
- consumer
- dragon
- gizmodo
- iqrquksm
- letmein
- lifehack
- monkey
- password
- qwerty
- root
- soporteETB2006
- support
- tadpassword
- trustno1
- we0Qilhxtx4yLGZPhokY
In case of successful login, the malicious code changes the address of the main DNS server to a fake one, reports a successful infection operation to C & C and continues scanning the range of IP addresses. After such a DNS modification has been made, all requests for address resolvers will go through this server to malicious users, who will relay them to web pages with fake Google Chrome browser installers, in the case of the presence of the “facebook” or “google” domains in the original request.
Fig. The webpage if the domain is successfully redirected, which contains the word "google."
This malware is somewhat similar to the well-known DNSChanger, which redirected users to install malware through advertising fake software. On the advertising sites themselves, the user is redirected through a malicious DNS.
In the case of Sality, as soon as the computer is exposed to infection through a fake Google Chrome browser installer launched by a user, the configuration of the DNS server in Windows is changed to 8.8.8.8 by malicious code by modifying the NameServer registry value to the specified value in HKLM \ SYSTEM \ ControlSet001 \ Services \ Tcpip \ Parameters \ Interfaces \ {network interface UUID}. This IP address is not malicious and belongs to Google's alternative DNS server .
After the installation of the DNS server is completed, the DNS record of the router for this PC becomes useless and the OS will use the server explicitly specified in the registry. On the other hand, other computers that will try to connect to this router will be subjected to malicious redirections, since the router's DNS record is still modified.
The Win32 / Sality malware, which modifies the router's DNS service, consists of two executable files: a router address scanner and a DNS / HTTP server.
The address scanner is detected by ESET as Win32 / RBrute.A . At the beginning of his work, he creates a mutex with the name "19867861872901047sdf", which allows him to keep track of an already running instance of malware. Then every minute he checks the hard-wired IP address in the code to get the command. The command can be of two types: check the range of IP addresses or try to log into the account of the control panel of the router to modify the DNS service. The instruction for checking the range of addresses comes with the IP address of the beginning of the range and the number of addresses. Win32 / RBrute.A will send an HTTP GET request to TCP port 80, hoping to get an error 401 - Unauthorized. The router model will be extracted from the HTTP protocol's realm attribute (more precisely, see its authentication scheme ). If a router is found, the malicious program sends its IP address back to C & C.
Fig. A block diagram of the work of Win32 / RBrute.A.
After the IP address is sent to C & C, the bot receives a command to enter the control panel of the router. It uses the login and password issued by C & C. In case of successful login, the malicious code modifies the address of the main DNS server, which will now point to another computer infected with another modification of RBrute - Win32 / RBrute.B .
Earlier we mentioned a component of a malicious program that acts as a DNS / HTTP server. It is detected as Win32 / RBrute.B. and the execution of its code is divided into three streams: a control flow, a DNS server flow and an HTTP server flow. Although this malicious component can simultaneously run both DNS and HTTP services, in fact, it selects one of them to run using a randomly generated value. A special constant in the formula is used to ensure that in 80% of the cases the bot will act as a DNS server, although in the initial period of tracking the operation using this malicious program, we observed a constant that guaranteed 50% of the cases as DNS.
Fig. Code to select a DNS or HTTP server to start.
RBrute.B has another branch of the code, which is executed when the above code worked incorrectly.
Fig. Another mechanism for launching HTTP / DNS server streams in malicious code.
RBrute operators can manually start the above streams by sending a specially crafted DNS or HTTP request. Like RBrute.A, RBrute.B uses a special mutex named "SKK29MXAD" to prevent its second copy from running on an infected system.
The control thread is used to send data collected by the malware back to the C & C server. Every two minutes RBrute.B sends a data packet to a hard-wired IP address. This package contains information about the system in which the bot is running. The managing server will then provide the bot with an IP address that will be used to deliver the fake Google Chrome installer. If the bot is running in DNS server mode, the IP address of the C & C server will be the same as the address you want to use as a distribution server of a fake browser installer. Otherwise, the management server will send the IP address that is outside the Sality P2P infrastructure and will be used to distribute fake Chrome installers.
The following is information about the system that is sent by the control flow to a remote server.
- The system name is GetComputerName () .
- The recorded time is GetLocalTime () .
- Country - GetLocaleInfo () .
- The path to the Windows directory is GetWindowsDirectoryA () .
- The product name of the OS is from the system registry HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Product Name.
- Processor names - from the registry HKEY_LOCAL_MACHINE \ HARDWARE \ DESCRIPTION \ System \ CentralProcessor \ <CPU #> \ ProcessorNameString.
- Memory size of GlobalMemoryStatus () .
- The presence of a debugger - IsDebuggerPresent () .
- The amount of memory used by the GetProcessMemoryInfo () malware.
- The running time of the malicious program is in minutes.
- The number of threads that are running.
Information package has the following format:
0x00 DWORD Test_Count (CRC32)
0x04 WORD useful_size_load
0x06 BYTE not_used
0x07 BYTE work_mode (HTTP - 0x32 or DNS - 0x64)
Below is a screenshot of the package information sent to C & C.
Fig. Package sent by the bot to the remote server. Blue is the checksum field, red is the payload size field, black is the encrypted server operation mode constant, and green is the encrypted system information.
Information about the system can be (in the package encrypted using RC4):
9BC13555 | 03.24.2014 21: 56: 27 | United States | C: \ WINDOWS | Microsoft Windows XP | proc # 0 QEMU Virtual CPU version 1.0 | 1 | 358 | 511 | 1117 | 1246 | 0 | 2 | 0 | 0 |
The management server will then respond with a packet that contains the IP address to use. The package has the form.
0x00 DWORD Test_Count (CRC32)
0x04 WORD useful_size_load
0x06 BYTE not_used
0x07 BYTE command (0x02 - start or 0x03 - stop the service)
0x08 DWORD IP_address_service (System running Win32 / Rbrute.B or another HTTP server)
The DNS server component stream is waiting for requests that contain the words “google” or “facebook” in the domain name. If it detects a similar request, an IP address of the HTTP server required by the attackers, which they previously sent to this bot (Win32 / Rbrute.B) via C & C, is sent to the unsuspecting client. If the request does not contain these two words, it will be redirected to the Google DNS service ("8.8.8.8" or "8.8.4.4"), and then to the client.
A bot sending a request to the server via the UDP protocol on port 53 of a packet with the constant “0xCAFEBABE” in the payload field will result in the setting of the “udme” flag in the HKEY_CURRENT_USER \ SOFTWARE \ Fihd4 registry section. This flag ensures that the DNS server stream will be started after a reboot. The server must respond with the constant "0xDEADCODE" to confirm that this action is completed.
We mentioned a separate HTTP service stream in Win32 / RBrute.B. Consider it in more detail. This service serves users who have been redirected through a malicious DNS router to download a fake Google Chrome browser distribution. When receiving a request via HTTP, the service flow will first analyze the User-Agent parameter in the header. Further service behavior depends on what is in this parameter.
If the User-Agent parameter contains the string "linux" or "playstation", the service will simply break the connection. If the User-Agent contains information that the browser is used on a mobile device (there are "android", "tablet", "Windows CE", "blackberry" or "opera mini"), then the service may respond with a fake browser installer . Also, a fake Chrome installer will be delivered if the User-Agent contains “opera”, “firefox”, “chrome”, “msie”, or something else.
As in the case of the DNS service, the operator can itself influence the behavior of the HTTP service by sending a specially formed HTTP packet. He can do this by sending a GET or POST request with a special User-Agent "BlackBerry9000 / 5.0.0.93 Profile / MIDP-2.0 Configuration / CLDC-2.1 VendorID / 831", which will cause the bot to set the "htme" flag in the HKEY_CURRENT_USER \ SOFTWARE registry key \ Fihd4. This ensures that the HTTP server starts after a reboot. The server (bot with Win32 / RBrute.B) must respond with the message “kenji oke” to confirm the execution of the command.
All Sality components that need to receive connections from the network incorporate the same code to add a special Windows Firewall rule that allows inbound connections for the malware process. Such an operation is performed by adding the parameter " harmful_file_program_name: *: Enabled: ipsec " to the registry key HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ SharedAccess \ Parameters \ FirewallPolicy \ StandardProfile \ AuthorizedApplications \ List. Below is the function code add_to_firewall_exception Sality , which performs this operation.
In the Win32 / RBrute.B component, this function is called at the beginning of the execution of the malicious program.
Fig. From here, the add_to_firewall_exception function is called .
A similar code is in the spam bot component, which belongs to Sality.
Fig. Spam bot code Sality, in which add_to_firewall_exception is called .
Our telemetry data shows that Win32 / Sality activity is currently declining, or at least remains at the same level as in 2012. We believe that the reduction in the number of detections is due to the low efficiency of current users' infection vectors. This could explain the fact that attackers are looking for new ways to spread Win32 / Sality.
If we look at the statistics of Sality detections over the last year, we will see a slight increase in the number of detections, approximately in December 2013. This date coincides with the time of the first activity of the RBrute component, which replaces the router's DNS service.
We are not sure whether the RBrute component is real for attackers, since the vast majority of routers are only listened to by a rigidly fixed address space (i.e., 192.168.0.0/16), which makes the control panel inaccessible from the Internet. In addition, the RBrute component does not brute forcefully, but only tries to apply ten passwords from its list.
Conclusion
Simple vectors infecting users with Win32 / Sality malicious code may not be efficient enough to keep the botnet population at an appropriate level. The attackers needed a new way to distribute the malware and in this way became the DNS hijacking for the router. Depending on whether the selected router is susceptible to exploitation, many users connected to it may be victims of redirections. We recommend using secure passwords for accounts of control panels of routers, and also to check whether it is really necessary to allow access to it from the Internet.
Source: https://habr.com/ru/post/218655/
All Articles