Brief (incomplete) Analysis and Impact of Tunnel Snake / Moriya Rootkit

Recent articles about a new previously unknown rootkit may at first glance cause concern or uncertainty. However, this report seeks to analyze the threat and assess the risk of this type of malware. First rootkits are surreptitious software that seeks to remain undetected, while affording the attacker covert access and communications to the affected systems.

In short, takeaways from this rootkit for us are two fold.

  1. Every edge accessible Windows system should be instrumented with EDR, or removed. We have no chance to detect or respond to threats to edge Windows Servers if we do not have sensors installed on them.
  2. Rigorous hardening, including driver inventory on edge systems needs to be evaluated. New drivers and installation of new drivers is an observable event with EDR. There is very little reason that such a new driver would be deployed on an edge system. Drivers on virtual systems are much more static than say a workstation or laptop. Any presence or alert of a new driver should be scrutinized and reviewed.


Per Kaspersky’s report, this seems to be used as a part of an opportunistic scanning operation for vulnerable Windows servers on the internet, to deploy a rootkit, to increase this actors anonymity and increase layers of access. My initial opinion, is this particular tooling is designed to lay tracks and plumbing in support of future or more advanced operations. By routing their attacks through unsuspected organizations, they can further hide their true presence.

This driver is a network based Windows Filtering Platform (WFP) driver that accepts and filters packets with a “magic” value in the stream. While it is likely observable by looking at TCP stream anomalies, separate from the host, that is a costly and inefficient approach.

However, it does give us the opportunity to explore our telemetry and logs for unusual HTTP/TCP requests to edge systems. There is certainly precedent for attackers using WebShells, to hide their command and control traffic , to blend in with normal Web Traffic. We could likely observe suspicious outbound communication or scanning originating from a compromised edge device. Ideas include suspicious Paths or URIs. Leveraging the WAF or TLS termination point to look for these non-standard requests and then dropping them at the edge.


In our team’s testing it is very clear that the initial installation and process privilege elevation are easily observable with EDR. The fact that a new , signed driver was delivered and loaded from disk is an observable event. Further, the use of a vulnerable signed driver means an attacker cannot change the driver and still allow it to function. One method is to add a counter-signed block or additional signature to the driver to “pad” or change the specific hash that most teams will be looking for. Drivers are still observable by their objects created and names. These cannot be changed without affecting the integrity of the vulnerable driver.


This is an excellent write up by Kaspersky and our teams should perhaps come away with two takeaways.

  1. Hyper-Vigilance on instrumenting Edge Windows Systems
  2. Thorough review of telemetry available Post exploitation, HTTP Logs, unusual POST/GET/CONNECT type requests etc..

This can be difficult to extract from a compromised device, since the rootkit will work to suppress logs and events associated with its activity. You may need to consider network telemetry to spot behavior, in alternate sources, such as Load Balancers, WAF, TLS Termination points, Error logs, Proxies, of Full Packet Capture systems.

This represents my opinion, not that of my employer, past or present. This is an incomplete, but rough draft analysis, for complete detail and insight, please refer to the excellent blog here:

Not an Expert, I have questions.