VPNFilter Update - VPNFilter exploits endpoints, targets new
devices
By William Largent
Published: 2018-06-06 · Archived: 2026-04-05 22:43:53 UTC
Wednesday, June 6, 2018 09:02
Introduction
Cisco Talos, while working with our various intelligence partners, has discovered additional details regarding
"VPNFilter." In the days since we first published our findings on the campaign, we have seen that VPNFilter is
targeting more makes/models of devices than initially thought, and has additional capabilities, including the ability
to deliver exploits to endpoints. Talos recently published a blog about a broad campaign that delivered VPNFilter
to small home-office network devices, as well as network-attached storage devices. As we stated in that post, our
research into this threat was, and is, ongoing. In the wake of that post, we have had a number of partners step
forward with additional information that has assisted us in our work. This post is an update of our findings over
the past week.
First, we have determined that additional devices are being targeted by this actor, including some from vendors
that are new to the target list. These new vendors are ASUS, D-Link, Huawei, Ubiquiti, UPVEL, and ZTE. New
devices were also discovered from Linksys, MikroTik, Netgear, and TP-Link. Our research currently shows that
no Cisco network devices are affected. We've provided an updated device list below.
We have also discovered a new stage 3 module that injects malicious content into web traffic as it passes through a
network device. At the time of our initial posting, we did not have all of the information regarding the suspected
stage 3 modules. The new module allows the actor to deliver exploits to endpoints via a man-in-the-middle
https://blog.talosintelligence.com/2018/06/vpnfilter-update.html
Page 1 of 16
capability (e.g. they can intercept network traffic and inject malicious code into it without the user's knowledge).
With this new finding, we can confirm that the threat goes beyond what the actor could do on the network device
itself, and extends the threat into the networks that a compromised network device supports. We provide technical
details on this module, named "ssler" below.
Additionally, we've discovered an additional stage 3 module that provides any stage 2 module that lacks the kill
command the capability to disable the device. When executed, this module specifically removes traces of the
VPNFilter malware from the device and then renders the device unusable. Analysis of this module, called "dstr,"
is also provided below.
Finally, we've conducted further research into the stage 3 packet sniffer, including in-depth analysis of how it
looks for Modbus traffic.
Technical details
New third-stage modules
'ssler' (Endpoint exploitation module — JavaScript injection)
The ssler module, which we pronounce as "Esler," provides data exfiltration and JavaScript injection capabilities
by intercepting all traffic passing through the device destined for port 80. This module is expected to be executed
with a parameter list, which determines the module's behavior and which websites should be targeted. The first
positional parameter controls the folder on the device where stolen data should be stored. The purpose of the other
named parameters are as follows:
dst: Used by the iptables rules created to specify a destination IP address or CIDR range that the rule
should apply to.
src: Used by the iptables rules created to specify a source IP address or CIDR range that the rule should
apply to.
dump: Any domain passed in a dump parameter will have all of its HTTP headers recorded in the
reps_*.bin file.
site: When a domain is provided in the "site" parameter, this domain will have its web pages targeted for
JavaScript injection.
hook: This parameter determines the URL of the JavaScript file for injection.
The first action taken by the ssler module is to configure the device's iptables to redirect all traffic destined for
port 80 to its local service listening on port 8888. It starts by using the insmod command to insert three iptables
modules into the kernel (ip_tables.ko, iptable_filter.ko, iptable_nat.ko) and then executes the following shell
commands:
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT
iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8888
Example: ./ssler logs src:192.168.201.0/24 dst:10.0.0.0/16 -A PREROUTING -s 192.168.201.0/24 -d
10.0.0.0/16 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8888
https://blog.talosintelligence.com/2018/06/vpnfilter-update.html
Page 2 of 16
Note: To ensure that these rules do not get removed, ssler deletes them and then adds them back approximately
every four minutes.
Any outgoing web requests on port 80 are now intercepted by ssler and can be inspected and manipulated before
being sent to the legitimate HTTP service. All HTTP requests are sslstripped. That is, the following changes are
made to requests before being sent to the true HTTP server:
Any instances of the string https:// are replaced with http://, converting requests for secure HTTP resources
to requests for insecure ones so sensitive data such as credentials can be extracted from them.
If the request contains the header Connection: keep-alive, it is replaced with Connection: close
If the request contains the header Accept-Encoding with the gzip value, this is converted to Accept-Encoding: plaintext/none so no responses will be compressed with gzip (exceptions are made for certain
file types, such as images).
If the host is in one of the dump: parameters, the details of the request are saved to the disk for exfiltration,
including the URL, port and all of the request headers. If the host is not in a dump: parameter, it will only dump
requests with an Authorization header or URLs that have credentials in them. URLs are determined to have
credentials if they contain either the string assword= or ass= and one of the following strings in them:
sername=
ser=
ame=
ogin=
ail=
hone=
session%5Busername
session%5Bpassword
session[password
Any POST requests to accounts.google.com containing the string signin will also be dumped.
After these modifications are made, a connection to the true HTTP server is made by ssler using the modified
request data over port 80. Ssler receives the response from the HTTP server and makes the following changes to
the response before passing it on to the victim:
A response with an https:// in its Location header value is converted to http://
The following headers are ignored, i.e. not sent to the client:
Alt-Scv
Vary
Content-MD5
content-security-policy
X-FB-Debug
public-key-pins-report-only
Access-Control-Allow-Origin
The entire response is sslstripped — that is, all instances of https:// with \x20http://.
https://blog.talosintelligence.com/2018/06/vpnfilter-update.html
Page 3 of 16
If parameter site: is provided a domain (or part of a domain, e.g. "google"), it will attempt to inject
JavaScript into all Content-Type: text/html or Content-Type: text/javascript responses. The requirement is
that the string be present and long enough to fit the string from the hook: parameter.
The tag will be replaced with