April 8, 2014 at 15:58Sality virus modifies the DNS service of routers
The Win32 / Sality family of file infectors has been known for a long time and has been using a P2P botnet since 2003. Sality can act as a virus or as a downloader for other malicious programs that are used to send spam, organize DDoS, generate ad traffic or hack VoIP accounts. Commands and files transmitted over the Sality network are encrypted using RSA (so-called digital signature). The modular architecture of the malware, as well as the durability of the botnet, shows how well the attackers approached the creation of this malicious code.
We tracked the Win32 / Sality botnetover time, and observed more than 115,000 available IP addresses, which were instructed by "super-nodes" (super peers) to support the botnet in working condition and their coordination. We saw similar Sality components that he downloaded to 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 main DNS server (DNS hijacking). According to our telemetry data, this component appeared at the end of October 2013. It is called Win32 / Rbrute .
The Win32 / RBrute component adds truly new features to Win32 / Sality. The first module, detected by ESET as Win32 / RBrute.A , searches the web pages of the control panels of the router by scanning a specific set of IP addresses to change the record of the primary 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 file of Win32 / Sality itself. Thus, attackers secure their new installations and the botnet extension of this malware family.
The IP address that is used as the primary DNS server on the compromised router is, in fact, part of the Win32 / Sality network. There is another modification of the malware - Win32 / RBrute.B , it is installed by Sality on compromised computers and can act as a DNS or HTTP proxy server for delivering a fake Google Chrome browser installer to users who were redirected through a malicious router.
We can say that the technique of modifying the main DNS router is already quite common for various purposes, starting with the theft of online banking data and ending with blocking client connections to security vendor websites. This has become especially relevant in connection with the recent detection of vulnerabilities in the firmware of various router models. Win32 / RBrute.A tries to find the administrative web pages of the routers by scanning the 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 the web page is found, the C&C server sends the bot a short list of ten passwords for brute force. If the bot has selected the right password and can log into the router’s account, it will proceed to change the settings of the DNS server. It is interesting to note that to gain access to the account of the administrative panel, only the method of enumerating passwords is used without exploiting any vulnerability. Authentication can be performed with the usernames “admin” or “support”, although previous versions also tried to use “root” and “Administrator”. The following is a list of passwords that were transferred from the C&C server to the bot:
In case of successful login, the malicious code changes the address of the primary DNS server to a fake one, reports the operation of successful infection on C&C and continues to scan the range of IP addresses. After such a modification of DNS is made, all requests for address resolvers will go through this attacker server, which will relay them to web pages with fake installers of the Google Chrome browser, if the “facebook” or “google” domains are present in the original request.
Fig. Web page in case of a successful redirect of a domain that contains the word "google".
This malware is somewhat reminiscent of the well-known DNSChanger, which redirected users to install malware through advertisements of fake software. The user was redirected to the advertising sites themselves through malicious DNS.
In the case of Sality, as soon as the computer is infected through a fake installer of the Google Chrome browser launched by the user, the DNS server setting in Windows is changed by the malicious code to the value “8.8.8.8” by modifying the NameServer registry parameter to the specified value in the HKLM \ SYSTEM \ ControlSet001 section \ Services \ Tcpip \ Parameters \ Interfaces \ {network interface UUID}. This IP address is not malicious and belongs to the alternative Google 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 registered in the registry. On the other hand, other computers that try to connect to this router will undergo malicious redirections, as the DNS record of the router is still modified.
The Win32 / Sality malicious code that 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 track an already running instance of the malicious program. Then every minute he checks the hard-wired IP address in the code to receive 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 address range check instruction 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 error 401 - Unauthorized. The router model will be extracted from the realm attribute of the HTTP protocol (more precisely, see its authentication scheme ). If a router is found, the malware sends its IP address back to the C&C.
Fig. Flowchart of Win32 / RBrute.A.
After the IP address is sent to C&C, the bot receives a command to enter the router control panel. This uses the username and password issued by C&C. In case of successful login, the malicious code modifies the address of the primary DNS server, which will now point to another computer infected with another RBrute modification - Win32 / RBrute.B .
Earlier, we mentioned a malware component that acts as a DNS / HTTP server. It is detected as Win32 / RBrute.B and its code execution is divided into three streams: control stream, DNS server stream and HTTP server stream. Although this malicious component can simultaneously launch both DNS and HTTP services, in fact, it selects one of them to start using a randomly generated value. A special constant in the formula is used to guarantee that in 80% of cases the bot will work as a DNS server, although in the initial period of tracking the operation using this malware, we observed a constant that guaranteed 50% of cases of working as DNS.
Fig. The code to select the DNS or HTTP server to start.
RBrute.B has another branch of code that executes when the above code worked incorrectly.
Fig. Another mechanism for triggering 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 called “SKK29MXAD” to prevent its second copy from running on the infected system.
A control thread is used to send data collected by a malicious program back to a 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 on which the bot works. The management server will then provide the bot with an IP address that will be used to deliver the fake Google Chrome installer. If the bot operates in DNS server mode, the IP address of the C & C server will match the address that you want to use as the distribution server of the 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 information package has the following format:
Below is a screenshot of the package information sent to C&C.
Fig. The packet sent by the bot to the remote server. The checksum field is blue, the payload size field is red, the server operation mode constant is encrypted in black, and system information is encrypted in green.
Information about the system may look like (in the package it is 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 thread expects queries that contain the words “google” or “facebook” in the domain name. If it detects such a request, the IP address of the HTTP server required by the attackers, which they had 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, then 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 UDP to port 53 of a packet with the constant “0xCAFEBABE” in the payload field will cause the udme flag to be set in the system registry key HKEY_CURRENT_USER \ SOFTWARE \ Fihd4. This flag ensures that the DNS server thread will be started after a reboot. The server should respond with the constant "0xDEADCODE" to confirm the completion of this action.
We mentioned a separate HTTP service thread in Win32 / RBrute.B. Let's consider it in more detail. This service serves users who have been redirected via a malicious DNS router to download a fake distribution of the Google Chrome browser. When a request is received via HTTP, the service flow will first analyze the User-Agent parameter in the header. The further behavior of the service depends on what is in this parameter.
If the User-Agent parameter contains the string “linux” or “playstation”, the service will simply disconnect. 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”), 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 himself 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 lead to the setting of the “htme” flag by the bot in the registry key HKEY_CURRENT_USER \ SOFTWARE \ Fihd4. This ensures that the HTTP server starts after a reboot. The server (bot with Win32 / RBrute.B) should respond with the message “kenji oke” to confirm the execution of the command.
All Sality components that need to receive connections from the network have the same code to add a special Windows Firewall rule that will allow incoming connections for the malware process. This operation is performed by adding the parameter “ malicious_file_name: *: Enabled: ipsec ” to the registry key HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ SharedAccess \ Parameters \ FirewallPolicy \ StandardProfile \ AuthorizedApplications \ List. The following is the code for the add_to_firewall_exception Sality function that 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 that belongs to Sality.
Fig. Sality spam bot code in which add_to_firewall_exception is called .
Our telemetry data show that Win32 / Sality activity is currently decreasing or at least remains at the same level as in 2012. We believe that the reduction in the number of detections is associated with the low efficiency of current infection vectors of users. This could explain the fact that attackers are looking for new ways to distribute 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 performs the DNS service change of the router.
We are not sure of the true effectiveness of the RBrute component for attackers, since the vast majority of routers only listen on a 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 perform strong password guessing, but only tries to apply ten passwords from its list.
Conclusion
Simple vectors to infect users with Win32 / Sality malicious code may not be effective enough to keep the botnet population at the appropriate level. Attackers needed a new way to spread malware, and DNS hijacking for the router became that way. Depending on whether the selected router is susceptible to exploitation, many redirected users can become its victims of redirects. We recommend that you use secure passwords for the accounts of the control panels of the routers, and also check whether it is really necessary to allow access to it from the Internet.
We tracked the Win32 / Sality botnetover time, and observed more than 115,000 available IP addresses, which were instructed by "super-nodes" (super peers) to support the botnet in working condition and their coordination. We saw similar Sality components that he downloaded to 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 main DNS server (DNS hijacking). According to our telemetry data, this component appeared at the end of October 2013. It is called Win32 / Rbrute .
The Win32 / RBrute component adds truly new features to Win32 / Sality. The first module, detected by ESET as Win32 / RBrute.A , searches the web pages of the control panels of the router by scanning a specific set of IP addresses to change the record of the primary 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 file of Win32 / Sality itself. Thus, attackers secure their new installations and the botnet extension of this malware family.
The IP address that is used as the primary DNS server on the compromised router is, in fact, part of the Win32 / Sality network. There is another modification of the malware - Win32 / RBrute.B , it is installed by Sality on compromised computers and can act as a DNS or HTTP proxy server for delivering a fake Google Chrome browser installer to users who were redirected through a malicious router.
We can say that the technique of modifying the main DNS router is already quite common for various purposes, starting with the theft of online banking data and ending with blocking client connections to security vendor websites. This has become especially relevant in connection with the recent detection of vulnerabilities in the firmware of various router models. Win32 / RBrute.A tries to find the administrative web pages of the routers by scanning the 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 realm attribute of the HTTP protocol
- 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 the web page is found, the C&C server sends the bot a short list of ten passwords for brute force. If the bot has selected the right password and can log into the router’s account, it will proceed to change the settings of the DNS server. It is interesting to note that to gain access to the account of the administrative panel, only the method of enumerating passwords is used without exploiting any vulnerability. Authentication can be performed with the usernames “admin” or “support”, although previous versions also tried to use “root” and “Administrator”. The following is a list of passwords that were transferred 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 primary DNS server to a fake one, reports the operation of successful infection on C&C and continues to scan the range of IP addresses. After such a modification of DNS is made, all requests for address resolvers will go through this attacker server, which will relay them to web pages with fake installers of the Google Chrome browser, if the “facebook” or “google” domains are present in the original request.
Fig. Web page in case of a successful redirect of a domain that contains the word "google".
This malware is somewhat reminiscent of the well-known DNSChanger, which redirected users to install malware through advertisements of fake software. The user was redirected to the advertising sites themselves through malicious DNS.
In the case of Sality, as soon as the computer is infected through a fake installer of the Google Chrome browser launched by the user, the DNS server setting in Windows is changed by the malicious code to the value “8.8.8.8” by modifying the NameServer registry parameter to the specified value in the HKLM \ SYSTEM \ ControlSet001 section \ Services \ Tcpip \ Parameters \ Interfaces \ {network interface UUID}. This IP address is not malicious and belongs to the alternative Google 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 registered in the registry. On the other hand, other computers that try to connect to this router will undergo malicious redirections, as the DNS record of the router is still modified.
The Win32 / Sality malicious code that 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 track an already running instance of the malicious program. Then every minute he checks the hard-wired IP address in the code to receive 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 address range check instruction 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 error 401 - Unauthorized. The router model will be extracted from the realm attribute of the HTTP protocol (more precisely, see its authentication scheme ). If a router is found, the malware sends its IP address back to the C&C.
Fig. Flowchart of Win32 / RBrute.A.
After the IP address is sent to C&C, the bot receives a command to enter the router control panel. This uses the username and password issued by C&C. In case of successful login, the malicious code modifies the address of the primary DNS server, which will now point to another computer infected with another RBrute modification - Win32 / RBrute.B .
Earlier, we mentioned a malware component that acts as a DNS / HTTP server. It is detected as Win32 / RBrute.B and its code execution is divided into three streams: control stream, DNS server stream and HTTP server stream. Although this malicious component can simultaneously launch both DNS and HTTP services, in fact, it selects one of them to start using a randomly generated value. A special constant in the formula is used to guarantee that in 80% of cases the bot will work as a DNS server, although in the initial period of tracking the operation using this malware, we observed a constant that guaranteed 50% of cases of working as DNS.
Fig. The code to select the DNS or HTTP server to start.
RBrute.B has another branch of code that executes when the above code worked incorrectly.
Fig. Another mechanism for triggering 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 called “SKK29MXAD” to prevent its second copy from running on the infected system.
A control thread is used to send data collected by a malicious program back to a 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 on which the bot works. The management server will then provide the bot with an IP address that will be used to deliver the fake Google Chrome installer. If the bot operates in DNS server mode, the IP address of the C & C server will match the address that you want to use as the distribution server of the 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 fixed time is GetLocalTime () .
- Country - GetLocaleInfo () .
- The path to the Windows directory is GetWindowsDirectoryA () .
- OS product name - from the system registry HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Product Name.
- Processor names - from the system registry HKEY_LOCAL_MACHINE \ HARDWARE \ DESCRIPTION \ System \ CentralProcessor \
\ ProcessorNameString. - The amount of memory GlobalMemoryStatus () .
- The presence of the debugger is IsDebuggerPresent () .
- The amount of memory used by the GetProcessMemoryInfo () malware .
- The malware’s uptime is in minutes.
- The number of running threads.
The information package has the following format:
0x00 DWORD kontrolnaya_summa (the CRC32)
0x04 WORD razmer_poleznoy_nagruzki
0x06 BYTE ne_ispolzuetsya
0x07 BYTE rezhim_raboty (HTTP - 0x32 or DNS - 0x64)
Below is a screenshot of the package information sent to C&C.
Fig. The packet sent by the bot to the remote server. The checksum field is blue, the payload size field is red, the server operation mode constant is encrypted in black, and system information is encrypted in green.
Information about the system may look like (in the package it is 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 kontrolnaya_summa (the CRC32)
0x04 WORD razmer_poleznoy_nagruzki
0x06 BYTE ne_ispolzuetsya
0x07 BYTE command (0x02 - 0x03 or start - stop service)
0x08 a DWORD IP_adres_servisa (system running Win32 / Rbrute.B or other HTTP-server)
The DNS server component thread expects queries that contain the words “google” or “facebook” in the domain name. If it detects such a request, the IP address of the HTTP server required by the attackers, which they had 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, then 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 UDP to port 53 of a packet with the constant “0xCAFEBABE” in the payload field will cause the udme flag to be set in the system registry key HKEY_CURRENT_USER \ SOFTWARE \ Fihd4. This flag ensures that the DNS server thread will be started after a reboot. The server should respond with the constant "0xDEADCODE" to confirm the completion of this action.
We mentioned a separate HTTP service thread in Win32 / RBrute.B. Let's consider it in more detail. This service serves users who have been redirected via a malicious DNS router to download a fake distribution of the Google Chrome browser. When a request is received via HTTP, the service flow will first analyze the User-Agent parameter in the header. The further behavior of the service depends on what is in this parameter.
If the User-Agent parameter contains the string “linux” or “playstation”, the service will simply disconnect. 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”), 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 himself 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 lead to the setting of the “htme” flag by the bot in the registry key HKEY_CURRENT_USER \ SOFTWARE \ Fihd4. This ensures that the HTTP server starts after a reboot. The server (bot with Win32 / RBrute.B) should respond with the message “kenji oke” to confirm the execution of the command.
All Sality components that need to receive connections from the network have the same code to add a special Windows Firewall rule that will allow incoming connections for the malware process. This operation is performed by adding the parameter “ malicious_file_name: *: Enabled: ipsec ” to the registry key HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ SharedAccess \ Parameters \ FirewallPolicy \ StandardProfile \ AuthorizedApplications \ List. The following is the code for the add_to_firewall_exception Sality function that 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 that belongs to Sality.
Fig. Sality spam bot code in which add_to_firewall_exception is called .
Our telemetry data show that Win32 / Sality activity is currently decreasing or at least remains at the same level as in 2012. We believe that the reduction in the number of detections is associated with the low efficiency of current infection vectors of users. This could explain the fact that attackers are looking for new ways to distribute 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 performs the DNS service change of the router.
We are not sure of the true effectiveness of the RBrute component for attackers, since the vast majority of routers only listen on a 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 perform strong password guessing, but only tries to apply ten passwords from its list.
Conclusion
Simple vectors to infect users with Win32 / Sality malicious code may not be effective enough to keep the botnet population at the appropriate level. Attackers needed a new way to spread malware, and DNS hijacking for the router became that way. Depending on whether the selected router is susceptible to exploitation, many redirected users can become its victims of redirects. We recommend that you use secure passwords for the accounts of the control panels of the routers, and also check whether it is really necessary to allow access to it from the Internet.