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 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.
New third-stage modules
- 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.
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:
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:
- The entire response is sslstripped — that is, all instances of https:// with \x20http://.
Each domain that is sslstripped in the responses (e.g. domains found in links) is then added to a list of stripped domains. Subsequent requests that are intercepted by the ssler module to domains in this list will occur via HTTPS over port 443, instead of HTTP over port 80. By default, four domains are on this list, so ssler will always connect to these domains via HTTPS over port 443: www.google.com, twitter.com, www.facebook.com, or www.youtube.com.
'dstr' (device destruction module)
The dstr modules are used to render an infected device inoperable by deleting files necessary for normal operation. It deletes all files and folders related to its own operation first before deleting the rest of the files on the system, possibly in an attempt to hide its presence during a forensic analysis.
The x86 version of the dstr module was analyzed in-depth. This module first deleted itself from the disk and then stops the execution of the parent Stage 2 process. It will then search all running process for ones named vpnfilter, security, and tor and terminate them. Next, it explicitly deletes the following files and directories:
The dstr module clears flash memory by overwriting the bytes of all available /dev/mtdX devices with a 0xFF byte. Finally, the shell command rm -rf /* is executed to delete the remainder of the file system and the device is rebooted. At this point, the device will not have any of the files it needs to operate and fail to boot.
Additional research on the third stage packet sniffer
'ps' (stage 3 packet sniffer)
One of stage 3 packet sniffer module samples we have is the R600VPN MIPS-like (Lexra architecture) sample. This sample is a packet sniffer that is looking for basic authentication as well as monitoring ICS traffic, and is specific to the TP-LINK R600-VPN. The malware uses a raw socket to look for connections to a pre-specified IP address, only looking at TCP packets that are 150 bytes or larger (note: This is the full packet size, with headers. Depending on the size of the TCP header, the PDU could be approximately 56 to 96 bytes and still meet the criteria to get logged). It has the ability to view, but not modify, the network traffic. Very significant changes would be required to implement functionality that could modify traffic.
Packets that are not on port 502, are scanned for BasicAuth, and that information is logged.
- Else: (non-Modbus traffic): sniffing HTTP basic auth credentials
- Destination IP Address == command line argument IP address
- Source port > 1024
- Source port != 8080
- Source port != 8088
- Packet Data length > 20 bytes
- Packet does not contain
- </ and >
- Basic Og==
- Password Required
- this. and .get
- 200 OK
- Packet contains 'Authorization: Basic' OR one user/pass combination
- Logging: Logs on IPs and ports, but not the packet contents on port 502. It does not validate the traffic as Modbus.
- Modbus: Logs SourceIP, SourcePort, DestinationIP, DestinationPort and labels it *modbus*
- All Other: write full packet to log file if and only if it passes basic auth check
These new discoveries have shown us that the threat from VPNFilter continues to grow. In addition to the broader threat surface found with additional targeted devices and vendors, the discovery of the malware's capability to support the exploitation of endpoint devices expands the scope of this threat beyond the devices themselves, and into the networks those devices support. If successful, the actor would be able to deploy any desired additional capability into the environment to support their goals, including rootkits, exfiltration capability and destructive malware.
Talos would like to thank all of the individual researchers, companies and intelligence partners from around the world who have stepped forward to share information and address this threat. Your actions have helped us gain a greater understanding of this campaign, and in some cases, have directly improved the situation. We recognize this is a team sport, and truly appreciate your assistance.
We will continue to monitor VPNFilter and work with our partners to understand the threat as it continues to evolve in order to ensure that our customers remain protected and the public is informed.
Updated List of IOCs
As stated previously, we highly suspect that there are additional IOCs and versions of this malware that we are not currently aware of. The following list of IOCs comprises what we know as of this date. News IOCs are in BOLD below.
Known C2 Domains and IPs
Associated with the 1st Stage
Associated with the 2nd Stage
Known File Hashes
1st Stage Malware
2nd Stage Malware
3rd Stage Plugins
Self-Signed Certificate Fingerprints
Known Affected Devices
The following devices are known to be affected by this threat. Based on the scale of this research, much of our observations are remote and not on the device, so it is difficult to determine specific version numbers and models in many cases.
Given our observations with this threat, we assess that this list may still be incomplete and other devices may be affected.
Asus Devices: RT-AC66U (new)
RT-N10 (new) RT-N10E (new)
D-Link Devices: DES-1210-08P (new)
Huawei Devices: HG8245 (new)
Linksys Devices: E1200
RB Groove (new)
RB Omnitik (new)
Other QNAP NAS devices running QTS software
PBE M5 (new)
Unknown Models* (new)
ZXHN H108N (new)
* Malware targeting Upvel as a vendor has been discovered, but we are unable to determine which specific device it is targeting.