Part 4 De-Anonymizing Domains on the Dark Web – Catastrophic OPSEC Failures

Part 4 De Anonymizing Domains on the Dark Web – Catastrophic OPSEC Failures

Catastrophic OPSEC (Operational Security) Failures

Sometimes Ransomware gangs make catastrophic security mistakes that unmasks their anonymity.
 In this last post we will look at how such operational security failures such as establishing correct file permissions allowing for a directory traversal vulnerability which allowed the Talos team to determine the location of the ransomware administrator.


Being one of the newer ransomware groups on the block Nokoyawa resembles the Karma Ransomware operation.

Once a network is breached by this group they encrypt the contents and leave a ransom note for the system administrators which contains the web address for the TOR Site. This site is where the victim can go and chat with ransomware affiliates and try to negotiate for the decryption key.

Looking at the web TOR url there is an assumed unique identifier for each victim they attack.


Victims visiting the chat window are presented with a way to upload their encrypted and the threat actor will decrypt one or two of the files as a proof of concept that their decryption method works.

The ransomware affiliate(s) who setup the web portal made a major security mishaps that blow their cover.

Blast from the past, 1999, Directory Traversal

Looking at the URL of the shared files we see that the link has several HTTP Parameters.


If one tampers with the file= parameter one is able to test for directory traversal.



Using the above command we can have the web server traverse up past the web root directory and actually obtain the /etc/password fine. This file is very sensitive and should be protected by both user permissions and acess control lists. Given that the ransomware gang made a basic data security mistake when configuring the web server, the directory traversal actually works.

What makes this mistake worse,is that certain files which are normally accessible by the root of the system are also available by this directory traversal method.


What this means is that the web server is potentially running as a root user instead of a web server account.

To de-anonymize things it is as simple as pulling the /var/log/auth.log* and searching for successful remote login connections.


Looking at the above picture, we can see that there are 2 main ip addresses that are used by the admin of the ransomware server. The IP’s are the following:

Looking deeper into this IP Addresses we can determine they belong to GHOSTnet GmbH. This company is a Virtual Private Server (VPS) provider.

Normally cyber criminals use such VPS servers as a network proxy, or a bouncing off point, in order to mask their true location.

It is important to note that the 176 IP Address belongs to AS58271, which is listed under Tyatkove Oksana Valerievna. It is possible that the operator forgot to use the VPS server to mask their IP, but instead corrected directly to the server exposing their actual location


Administrative Login Portal

Lastly we are able to see that there is an administrative login panel for the server. It is possible that through credential disclosure an external attacker can take control of this ransomware infrastructure once they login successfully.

Public Facing Administrative Portal For The Nokoyawa Ransomware Group's Infrastructure

Leave a Reply

Your email address will not be published. Required fields are marked *