# VPNFilter Update - VPNFilter exploits endpoints, targets new devices
**[blog.talosintelligence.com/2018/06/vpnfilter-update.html](https://blog.talosintelligence.com/2018/06/vpnfilter-update.html?m=1)**
## 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](https://blog.talosintelligence.com/2018/05/VPNFilter.html)
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](https://blog.talosintelligence.com/2018/05/VPNFilter.html)
-----
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 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
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://.
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