Customer portal
Investigation, Ransomware

A Special Investigation exposing a ransomware group’s clear-web IP and their duplicate identities


Before we dive into this investigation it’s worth to just spend a brief moment to describe the Apache Server-Status page.

The Apache Server Status page is a diagnostics and metrics page provided by the mod_status module. When mod_status is enabled a metrics page is served via localhost on the /server-status path. 

This page is typically served via localhost only. It offers diagnostic information about the Apache service and client requests. It shows the full request URI and client IP information.

Serving this page in production, outside of localhost would be considered an information disclosure vulnerability and could offer an attacker information about client requests, essentially anything disclosed in a POST request URI or GET request. 

In the scope of Tor onion services where a Tor service is published it will inherently expose all localhost services to the entirety of Tor – therefore any services designed to be protected by the typically non externally routeable local loopback interface become externally accessible.

Locating Onions with Server-Status Pages

We must first export a list of all onions we are aware of that have server-status pages. One of the tasks we perform when crawling an onion service is to identify interesting paths and services. We perform a check for common directories such as server-status along with many others.

This process is identical to a directory enumeration, except for being far more optimised to ensure crawler performance is prioritised.

Therefore using our path API we are able to query for all onions we’ve found and that are operational with server status pages:

server path search for server-status pages API

We find that there are 1,370 results with server-status pages:

Search results JSON export

The next task is to compile a list of all known (relatively current) ransomware blogs. We do this by merging our own lists, those we’ve found via OSINT and other published ransomware group site lists.

Of those we find a total of 71 onion unique addresses, these include v2 and v3 onions.

Now we have a relatively straightforward task of cross-checking our server-status results against this list to see what ransomware group sites have server-status pages, if any.

We do this with a very simple bash script that uses the grep tool:

Checking out output we see that there are in total only 3 ransomware blogs/group sites:

Arvin Club, Haron & Midas

Checking the first, Arvin Club:

We see that the server status page presents a vhost of localhost, not much to go by!

We also note that the server is running Ubuntu and is located in the UTC time zone.

Haron Server-Status Page

Checking the Haron server-status page we see that again the vhost is localhost, the server is running Debian and the time zone is Moscow Standard Time (MSK)

Lastly, checking the Midas server status page:

Midas Server-Status Page

We see a VHOST that is not localhost, this time it shows as “”

A server running Debian and a time zone of Moscow standard time.

The hostname exposed in the servers-status page for the Midas shows that the web server running the Midas blog is being hosted by Selectel a Russian cloud hosting company:

For at least a short period of time the clear web portion of the Midas blog was exposed to the internet allowing Google to crawl and index the server-status page. 

The Google Cache is of a AWS IP, Germany “” . According to the Google Cache entry the server was exposed at least up to 27th of September 2021 likely some time before that date, possibly after the 2nd of October 2021. 

How are we sure that this cache entry is the Midas blog web-server? 

It could very likely have been another server if Selectel reprovision hostnames. The evidence contained in the server-status client requests for the Becquerel host cache page are unique to the files found on the current Midas blog. 

Identical files requested in the Google Cache as what exists on the Midas blog web server

We can say with strong certainty that the cache entry, the clear-web IP and hostname all belong to the Midas web server and that the host is current and operational. 

Linking Midas to Haron and Avaddon

Reviewing the client request on refresh revealed some interesting paths. These paths point to image and file locations. Further investigation of these paths uncovered content that is shared or identical to both the Haron and Midas blogs. 

For example…

Haron test.jpg image

Midas test.jpg image


Midas Victim file [redacted]

Identical victim file on the Haron web server

Midas Mess directory

Mess directory

Identical but older Mess directory on the Haron web server

Haron mess directory

There is significant cross referencing between folder structures and files to show that the Midas web blog is a copy of the Haron web blog, if we go by the last modified date stamps on all of the files we have been able to observe across both blog sites. 

Not only do the sharing of files and file structure suggest that this is the same group/operator but both web sites have each other’s logos.

Further, we can see logo “development” taking place with logo names such as “newlogo2.png” and “finalLogo.png”. We propose it would be very unusual for one seemingly competing group to have another group’s logo on their web server and indeed for them to have each others!

The curious case of Avaddon

On the topic of logos. Investigation showed that both Haron and Midas contained the logo file for Avaddon Ransomware group:

There were rumours that not only Haron / Midas were the same group but that there were links with Haron to Avaddon.

Forum post on the Dublikat (Duplicate) dark web forum:

“Haron is built on code copied from other ransomware. So, the researchers noticed the following “parallels”: to create binaries, Haron uses the old ransomware builder Thanos; The ransomware site, where victims are asked to negotiate and pay the ransom, is almost identical to Avaddon’s site (as is the site for leaking stolen data); the ransom letter contains large snippets of text copied from a similar Avaddon note; Haron’s server contains icons and images previously found on the official Avaddon website. What all these similarities are connected with is still unclear. The researchers believe that the Haron operators may have hired one of the former Avaddon members, but they clearly did not have access to the source code of the Avaddon ransomware.”


We are now able to shed a bit more light on this forum post. It would seem that not only did Haron share resources, images text and icons but so does Midas now too, since it is just a copy of the Haron blog.

Although Avaddon is now defunct and their onion address is no longer valid we’ve been able to extract a html cache of their page from our index. 

Making minor changes to the HTML code, to refacing the Midas and Haron onion address we’ve effectively been able to “resurrect” the old Avaddon website.

Minor html updates to the Avaddon historic html source:

These minor updates allowed us to load the html source and have the page render in an almost exact way it would have done in the past.

Avaddon website resurrected loaded locally from a file:

And this is because the file and folder structure of the Haron / Midas websites still contain the original logo CSS and other content that were made for the Avaddon ransomware group website.

We are therefore able to put forward the claim supported by the evidence in this article that all previous suggestions that these groups were interlinked do appear to be correct.

We’ve confirmed the following Clear Web IPs for both Haron and Midas, both hosted by Selectel Russia: – Midas – Haron

This proves our assumption that the blogs are hosted on separate VMs both hosted at Selectel.

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Consent to display content from - Youtube
Consent to display content from - Vimeo
Google Maps
Consent to display content from - Google
Consent to display content from - Spotify
Sound Cloud
Consent to display content from - Sound