{
	"id": "db37e07c-fc2f-42d3-9b0c-6d65b4734af8",
	"created_at": "2026-04-06T03:37:32.149946Z",
	"updated_at": "2026-04-10T03:21:00.635705Z",
	"deleted_at": null,
	"sha1_hash": "52e0c5bd4d3a10f10df36f5e9b32303bb7ce34d3",
	"title": "Win32/Sality newest component: a router’s primary DNS changer named Win32/RBrute",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 381726,
	"plain_text": "Win32/Sality newest component: a router’s primary DNS changer named\r\nWin32/RBrute\r\nBy Benjamin Vanheuverzwijn\r\nArchived: 2026-04-06 03:26:28 UTC\r\nWin32/Sality is a family of malware that has been using a peer-to-peer botnet since at least 2003. It is a file infector and a\r\ntrojan downloader, the latter of which is mainly used to send spam, although it has been used for different purposes such as\r\nfaking advertising network traffic, distributed denial of service or VoIP account cracking. All commands and files exchanged\r\nthrough Sality's P2P network are digitally signed, making it resilient to protocol manipulation. Its modular architecture as\r\nwell as the longevity of the botnet shows good programming practice and an efficient software design.\r\nWe’ve been tracking Win32/Sality network for quite some time now and  seen more than 115 000 IP addresses reachable\r\nfrom the Internet using so-called “super peers,” which keep the botnet alive and propagate commands to regular peers.\r\nWe have seen the same components downloaded over the years with little change to their underlying behavior. Lately, a new\r\ncomponent has now appeared with some novel characteristics:  the ability to change a residential broadband gateway router's\r\nprimary DNS address, which is different from the usual FTP password stealer or spambot deployed by Win32/Sality.\r\nAccording to our telemetry data, this component was dropped for the first time at the end of October 2013. It was first\r\npublicly discussed by Dr. Web, who has published a technical analysis of one component, the IP address scanner. They\r\nnamed it Win32/RBrute.\r\nThis blog will contain\r\nAn overview of the infrastructure supporting the primary DNS changer component\r\nA technical analysis of the two binaries that support the operation\r\nA brief analysis of the spread of the operation\r\nA review of the similarities between the DNS changer component and the other components dropped by\r\nWin32/Sality\r\nA new purpose: changing a router's primary DNS\r\nThis feature adds a new dimension to the Win32/Sality operation. The first component, detected by ESET as\r\nWin32/RBrute.A, scans the Internet for router administration pages in order to change the entry for their primary DNS\r\nserver. The rogue DNS server redirects users to a fake Google Chrome installation page whenever they are trying to resolve\r\ndomains containing the words “google” or “facebook”. The binary distributed through this installation page is in fact\r\nWin32/Sality itself, providing a way for the Sality botnet's operators to increase its size further by infecting other users\r\nbehind this router.\r\nThe IP address used as the primary DNS on a compromised router is part of the Win32/Sality network. In fact, another\r\nmalware, detected by ESET as Win32/RBrute.B, is installed by Win32/Sality on compromised computers and can act either\r\nas a DNS or a HTTP proxy server to deliver the fake Google Chrome installer.\r\nThe Operation\r\nFar from being a new technique these days , changing the primary DNS  on a router is quite in vogue  right now for\r\neverything from the theft of bank credentials to blocking communications with security vendors, especially with recent\r\nreports of vulnerabilities in different router’s firmware.\r\nWin32/RBrute.A tries to find the administration web pages for routers by downloading a list of IP addresses from its C\u0026C\r\nserver to scan and then reporting back its findings. At the time of our investigation, Win32/RBrute.A targeted the following\r\nrouters:\r\nCisco routers matching “level_15_” in the HTTP realm attribute\r\nD-Link DSL-2520U\r\nD-Link DSL-2542B\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 1 of 10\n\nD-Link DSL-2600U\r\nHuawei EchoLife\r\nTP-LINK\r\nTP-Link TD-8816\r\nTP-Link TD-8817\r\nTP-Link TD-8817 2.0\r\nTP-Link TD-8840T\r\nTP-Link TD-8840T 2.0\r\nTP-Link TD-W8101G\r\nTP-Link TD-W8151N\r\nTP-Link TD-W8901G\r\nTP-Link TD-W8901G 3.0\r\nTP-Link TD-W8901GB\r\nTP-Link TD-W8951ND\r\nTP-Link TD-W8961ND\r\nTP-Link TD-W8961ND\r\nZTE ZXDSL 831CII\r\nZTE ZXV10 W300\r\nIf a web page is found, the C\u0026C sends a short list of about ten passwords to the bot and instructs it to perform a brute force\r\npassword guess attack against the router. If the bot is able to log in to the router, it will then proceed to change the router’s\r\nprimary DNS server settings. It is interesting to note that only brute force attack is used to gain access to the router’s\r\nadministration portal; no exploit code is used. The authentication is done with usernames of “admin” and “support”,\r\nalthough previous versions also tried “root” and “Administrator”. Below is a list of passwords we have observed being\r\ntransmitted from the C\u0026C:\r\n\u003cempty string\u003e\r\n111111\r\n12345\r\n123456\r\n12345678\r\nabc123\r\nadmin\r\nAdministrator\r\nconsumer\r\ndragon\r\ngizmodo\r\niqrquksm\r\nletmein\r\nlifehack\r\nmonkey\r\npassword\r\nqwerty\r\nroot\r\nsoporteETB2006\r\nsupport\r\ntadpassword\r\ntrustno1\r\nwe0Qilhxtx4yLGZPhokY\r\nIn the event of a successful login, the malware changes the primary DNS server to a rogue one, reports a successful infection\r\nto the C\u0026C, and continues with scanning the Internet.\r\nOnce a router's primary DNS address is compromised, all DNS queries made by users will go through the rogue DNS server,\r\nmodifying them to point to the fake Chrome installer page whenever \"facebook\" or \"google\" domains are resolved.\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 2 of 10\n\nThis example shows a successful redirection for a domain that is not registered but contains the word “google”.\r\nThis operation is somewhat similar to DNSChanger, which drove users to install fake software to further spread malware\r\nusing a rogue DNS service.\r\nOnce a computer is infected by running the fake Google Chrome installer, its primary DNS server will be changed to\r\n“8.8.8.8” by updating the following registry key:\r\nHKLM/SYSTEM/ControlSet001/Services/Tcpip/Parameters/Interfaces/{network interface UUID}/NameServer = “8.8.8.8”\r\nIt should be noted that the IP address \"8.8.8.8\" belongs to Google Public DNS, a legitimate domain name service operated\r\nby Google, and it is not involved with Win32/RBrute.\r\nSince infected PCs will no longer be using the router’s DNS server, they will no longer be affected by its bogus redirections.\r\nOn the other hand, the router is still compromised and will nag each computer trying to resolve \"facebook\" or \"google\"\r\ndomains through its DNS service until they are infected with Win32/Sality. This tactic is far from stealthy and in fact tries to\r\nannoy the user into infecting its system or simply breaking “google” and “facebook” domains for operating systems that are\r\nnot targeted (e.g. Linux).\r\nCurrently, the goal of this operation appears to be solely to increase Sality’s botnet size.\r\nTechnical Analysis\r\nWin32/Sality’s DNS changer component is composed of two binaries: a router scanner and a DNS / HTTP server. Both\r\nmalware are dropped by Win32/Sality.\r\nRouter Scanner Binary - Win32/RBrute.A\r\nAt the beginning of the execution, the malware creates a mutex with the name “19867861872901047sdf” to avoid running\r\nmultiple instances.\r\nIt then checks a hard-coded IP address every minute to fetch a command; that command is either a scan instruction or a\r\nrequest to try to log onto an IP address to change the primary DNS.\r\nA scan instruction comes with an IP address to start and the number of addresses to try. Win32/RBrute.A will try to do a\r\nHTTP GET on TCP/80, hoping to receive a HTTP Error 401 - Unauthorized. The router model is extracted from the realm\r\nattribute of the HTTP authentication schemes. If a targeted router is found, the malware sends back its IP address to the\r\nC\u0026C.\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 3 of 10\n\nWin32/RBrute.A flowchart\r\nThe C\u0026C will then issue a request to login to the router using a password provided by the C\u0026C. If the login is successful,\r\nthe primary DNS server is changed in the router to a host running the Win32/RBrute.B malware.\r\nDNS and HTTP Server Binary - Win32/RBrute.B\r\nThis component is divided in three parts: the control thread, the DNS server thread, and the HTTP server thread.\r\nAlthough both the DNS and the HTTP server thread can be used at the same time, the malware will choose, based on a\r\nrandom value, to be either a DNS or a HTTP server. A constant in the formula ensures that 80% of the infections will act as\r\nDNS servers, although we’ve seen this constant set to 50% at the beginning of the operation.\r\nChoosing the DNS or HTTP server thread randomly.\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 4 of 10\n\nIf the chosen server thread would not start, the malware will fall back to the other mode:\r\nFallback to the other mode if the choosen thread could not start.\r\nThe operator can also force a thread to start by sending a specially crafted DNS or HTTP request. A mutex with the name\r\n\"SKK29MXAD\" ensures that only one instance can run on the host.\r\nControl Thread\r\nThe control thread is used to report back to the C\u0026C and to reconfigure the server instance.\r\nEvery two minutes, the malware will send a packet to a hard-coded IP address containing information about the machine on\r\nwhich it is running. The C\u0026C will then answer with an IP address that will be used to deliver the infected Chrome\r\ninstallation. If the malware is in DNS mode, the IP address served by the C\u0026C will be that of a rogue HTTP server installed\r\non a Sality-compromised machine. In the other case, the C\u0026C will send the IP address of a server outside of Sality’s P2P\r\nnetwork, which will be serving the fake Chrome installation page.\r\nListed below is the host information sent by the control thread to the C\u0026C:\r\nComputer name - GetComputerName()\r\nLocal time - GetLocalTime()\r\nCountry - GetLocaleInfoA()\r\nWindows directory - GetWindowsDirectoryA()\r\nWindows product name - from the registry key \"HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows\r\nNT/CurrentVersion/Product Name\"\r\nCPU names - from the registry keys\r\n\"HKEY_LOCAL_MACHINE/HARDWARE/DESCRIPTION/System/CentralProcessor/\u003cCPU\r\n#\u003e/ProcessorNameString\"\r\nMemory stats - GetMemoryStatusEx()\r\nResult of IsDebuggerPresent()\r\nMemory usage of the malware - GetProcessMemoryInfo()\r\nUptime of the malware - in minutes\r\nNumber of threads n use\r\nThe information packet has the format:\r\nThe screenshot below shows an information packet sent to the C\u0026C.\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 5 of 10\n\nHost information packet sent to the C\u0026C.\r\nIn blue: payload checksum, in red: payload length, in black: encrypted server mode, in green: encrypted host information\r\nThe host information, green in the previous example, is the following string encrypted with RC4:\r\n9BC13555|24.03.2014 21:56:27|United States|C:\\WINDOWS|Microsoft Windows XP|proc#0 QEMU Virtual CPU\r\nversion 1.0|1|358|511|1117|1246|0|2|0|0|\r\nThe C\u0026C will then answer with a packet with the service IP address to use:\r\nDNS Server Thread\r\nThe DNS server looks for requests that contain “google” or “facebook” in the domain name. If it finds one, the DNS\r\nresponse it will send back will contain the IP address of a Win32/RBrute.B HTTP server on the Sality network. If the query\r\ndoesn't contain “facebook” or “google”, it will relay the query to Google’s DNS servers (“8.8.8.8” or “8.8.4.4”) and will\r\nforward the response to the client.\r\nSending a packet to the server on UDP/53 with “0xCAFEBABE” as the payload will set the “udme” flag in the Windows\r\nregistry key \"HKEY_CURRENT_USER/SOFTWARE/Fihd4\". This flag ensure that the DNS server thread will start at the\r\nnext reboot, overriding the random process. The server will reply “0xDEADCODE” to confirm the command.\r\nHTTP Server Thread\r\nWhen receiving a browser request by a user that has been redirected, the HTTP server thread will first look at the browser\r\nUser-Agent and will have a different behavior consequently.\r\nIf the User-Agent contains “linux” or “playstation”, the server will silently drop the connection (how rude!). If the User-Agent makes reference to a mobile (matching one of the following words: “android”, “tablet”, “Windows CE”, “blackberry”\r\nor “opera mini”), the server will serve Win32/Sality (!) malware 5% of the time even though these are mobile devices User-Agent; otherwise, the request is dropped.  Finally, if the User-Agent contains “opera”, “firefox”, “chrome”, “msie” or\r\nanything else, the user will be served the Win32/Sality.\r\nThe User-Agent will affect the port on which the query is made on the rogue HTTP server distributing the malware.\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 6 of 10\n\nAny HTTP GET request sent to these ports will serve the fake Chrome installation page… even if you’re browsing with\r\nChrome!\r\nAkin to the DNS server thread, the botmaster can affect the HTTP server behavior by sending a specially- crafted HTTP\r\npacket. Specifically, sending a GET or POST request with the User-Agent “BlackBerry9000/5.0.0.93 Profile/MIDP-2.0\r\nConfiguration/CLDC-2.1 VendorID/831” will set the “htme” flag in the  registry key\r\n\"HKEY_CURRENT_USER/SOFTWARE/Fihd4\", effectively ensuring that malware will start the HTTP server thread upon\r\nreboot, overriding the random process. The server will send “\u003chtml\u003ekenji oke\u003c/html\u003e” to confirm a successful execution.\r\nThe HTTP server also keeps a list of allowed files to be served. If a browser makes a HTTP query on a domain matching\r\n“google” or “facebook” to a file not in the list, the server will reply with a HTTP 200 OK, with the following payload:\r\n\u003chtml\u003e\u003cmeta http-equiv=\"refresh\" content=\"0; url=/\"\u003e\u003c/html\u003e\r\nredirecting the browser to the front page -- hence serving the fake Chrome installation page. For example, if the user\r\nbrowses to “http://google.com/does-not-exist” and “does-not-exist” is not in the allowed files list, the user will be redirected\r\nto “http://google.com” instead of having the usual HTTP 404 error.\r\nWe should also note that every HTTP GET query made on the HTTP server that contains the string “.exe” will be\r\nforwarded to the rogue HTTP server, regardless of the allowed files list. The rogue server will always answer with an\r\ninfected binary.\r\nSimilarities with other Sality components\r\nBased on the following observations, we believe that the main file infector as well as all the components previously\r\ndescribed are all developed by the same group of people. By looking at each of the components binaries, they all share the\r\nsame technical details and coding style.\r\nNo persistence needed\r\nNone of the dropped Sality components, including those discussed before, needs a way to be persistent across system reboot,\r\nalthough some modules might store configuration in the registry. They are always downloaded and launched by the\r\npersistent layer: the file infector.\r\nBuffer Initialization\r\nThe operators have the standard practice of initializing their buffers with the ‘0’ value. The compiler “visual-c++” doesn’t\r\noptimize the following C code when the operators compile a software:\r\nchar buf[4096] = {0};\r\nThis is compiled into the code displayed in the following screenshots.\r\nUn-optimized initialization of a buffer of size 4096 bytes.\r\nThis assembly stub is seen in every component dropped by Win32/Sality.\r\nBypassing the Firewall\r\nAll components that need to receive connections from the Internet share the same code to add a specific rule in the Windows\r\nFirewall authorizing incoming requests to go through. It will add the value \"[malware file name]:*:Enabled:ipsec\" to the\r\nfollowing registry key\r\n“HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/SharedAccess/Parameters/FirewallPolicy/StandardProfile/AuthorizedAppl\r\nto achieve this goal. The following screenshot shows a subset of the “add_to_firewall_exception()” function.\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 7 of 10\n\nA subset of \"add_to_firewall_exception()\" function, shared by almost all components of Win32/Sality.\r\nIn Win32/RBrute.B, this function is called at the beginning of the malware execution:\r\nCalling add_to_firewall_exception() before creating the mutex in the WinMain() function of Win32/RBrute.B.\r\nSame thing found in the Win32/Sality’s spambot component:\r\nWin32/Sality's spambot component calling the add_to_firewall_exception() function.\r\nInfection Statistics\r\nOur data show that the detection for Win32/Sality is currently decreasing or at least staying stable since 2012. We believe\r\nthat the reduced number of detections is due to the reduced efficiency of the current infection vectors. This might explain\r\nwhy the operators are looking for new ways to spread Win32/Sality.\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 8 of 10\n\nWin32/Sality detection worldwide\r\nIf we take a look at the detections for the last year, we can see a small increase, around December 2013, in Win32/Sality\r\ndetections that coincides with the date where the DNS changer component was released in the wild, although those numbers\r\nshould be taken with a grain of salt since other factors could contribute to variation in its spreading, like being dropped by\r\nanother botnet.\r\nWin32/Sality detections last year\r\nWe’re not sure about the effectiveness of the Win32/Sality router DNS changer operation, since a lot of router configuration\r\nportals listen only on the private address space (e.g., 192.168.0.0/16) -- making them non-accessible from the Internet. Also,\r\nthe router password brute force is not very aggressive, only trying a list of about ten passwords.\r\nConclusion\r\nThe usual infection vectors of Win32/Sality might not be sufficient enough to keep the botnet alive; hence the botnet\r\ncontrollers are deploying new component to grow the botnet. DNS hijacking on routers can be quite effective if done\r\ncorrectly. It can reach a lot of users behind a single router, especially on public access points. As routers are not commonly\r\nprotected by security solutions, it provides an unrestricted environment to attackers allowing them to try several techniques\r\nto steal users’ information. An existing technology that could fix the problem is DNSSEC, since the result of a DNS request\r\nis cryptographically signed and hence not prone to tampering.  A good security practice that would reduce the scope of the\r\nproblem is to change the default password on router’s web interface.\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 9 of 10\n\nFile Analyzed\r\nThe following are the SHA-1 hashes of files observed during our monitoring of Win32/RBrute malware.\r\nWin32/RBrute.A\r\n8f4e43675948e806d99125e916191e04f8840b46\r\nf8031d843626ac198a6f3c056f57098012e178e2\r\n21649df3044f2203403a855108c1db1d95a2ab46\r\nWin32/RBrute.B\r\n5d1263c1c707ce163c9b36452dcb7340a7fd8909\r\n73e2fe07a3f875521b5bfe8c3dd8fd6b6819c8f8\r\nSource: https://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nhttps://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://www.welivesecurity.com/2014/04/02/win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute/"
	],
	"report_names": [
		"win32sality-newest-component-a-routers-primary-dns-changer-named-win32rbrute"
	],
	"threat_actors": [],
	"ts_created_at": 1775446652,
	"ts_updated_at": 1775791260,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/52e0c5bd4d3a10f10df36f5e9b32303bb7ce34d3.pdf",
		"text": "https://archive.orkl.eu/52e0c5bd4d3a10f10df36f5e9b32303bb7ce34d3.txt",
		"img": "https://archive.orkl.eu/52e0c5bd4d3a10f10df36f5e9b32303bb7ce34d3.jpg"
	}
}