Re: The Dark Web as You Know It Is a Myth


Link to article:

[This is the first entry in many to come as I roll up my sleeves and drag up some dirt and gold on the world of hidden services.]

Following Joseph’s article, whom I have talked to on some occasions in recent weeks, I decided to look further into the sites that often meet people entering the “dark web”. There is an impression that the “dark web” is full of a few things; child porn, drug sites, hacking groups, weapon traffickers and more. So I’m going to give some of these sites a quick digging and see what comes up.

Legal Disclosure: On the advice of my solicitor, even for the purposes of this publication, it could be considered a crime in my country to knowingly visit or attempt to visit sites that may contain indecent images of children. Even if my intent is to bring them down or report them. Thus, I shall be excluding child porn sites from those I investigate. Furthermore, I am legally advised to say I do not encourage using these sites and links are included only so that you may do your own further research.

The first stop is the “Hidden Wiki”. There are many clones out there, so I picked a few at random and started on my list. One site that stood out to me, in particular, was amazingitriw6yro.onion, which allegedly belongs to Shiny-Flakes. SF was a dark net market vendor who was busted this year in one of the largest drug seizures in Germany. I have made no attempt to verify if this is a scam site or was genuinely some kind of bazaar. Anyway, it is the technical information that grabbed my interest.

Interestingly (and by that, I mean moronically), the Apache server that operates the site has all the default modules loaded in. This provides the first point of entry into exploring a wider ecosystem of sites. By passing the URI of server-status, Apache serves up a list of statistics and other vhosts on the webserver, which is usually used for the system administrator to monitor the server.


From this – there are 3 obvious possibilities from this. The first is that this “Shiny Flakes” person operates a lot of hidden services – possible if he wasn’t behind bars right now. Since he is and we can see the last server restart was this week, I feel it safe to exclude this possibility. The second possible explanation is that it is a scam site, but having a brief glance over I have no idea.

The third possibility is that there is a shared web hosting service behind the site. This seems plausible as independent sites or operations are likely to be willing to share servers. So from the other vhosts available on the apache server status page, I pulled three other URLs from a list of many:

A supposed professional hacker group, offering everything from doxxing, to DDOS, to tracking partners and of course fraud of various kinds. In fact, they offer pretty much everything under the sun with huge promises.

The front page prompts me to log in to an “Assassins Community”. Didn’t bother going further in on this one.

Presents itself as the “Deepweb Gun Store”. Again, a login page which I did not proceed any further with at this point.


Without needing to investigate this further, I feel I can draw a few probable truths of what are behind this (admittedly, small) sample of sites.

1. If the sites above are legitimate, they are on a shared hosting service of some description. This means that whoever controls the server will also have full access to the data of the site, and so should one site be compromised – so shall they all.

2. If the sites are scams – which I rank as a reasonable belief, then it certainly shows that most other listings probably are too. They are in constant competition to push themselves to the top of the various wikis, with no clear leader based on reputation or peer review like the dark net markets.

3. The people behind these sites are no techies. They use an Apache web server with the server-status module loaded in, suggesting no thought has been given to the operational security of the web server. This is more common with scam sites since they have lower expenditure to rent a cheap server, with no other expenses that real traders would have in whatever wares they were advertising.

Take note, none of the above outcomes is what are advertised or touted by the mass media about the “dark web”. There are lots of listings for all sorts of services, but many of them are scams. Just as we don’t believe the guy on eBay selling a nuke, we should also take many of these offerings with a pinch of salt. Above all is the integrity of how journalists report these things in perspective with a healthy dose of skepticism.

A small, now benign release


As the following is now benign since it shut down earlier than expected, I feel no problem in releasing this. As far as I know they were a scam market and were being rounded up to tick up the numbers of onions that could be seized as part of the next bust. Ah well, one down, many more to go.

In relation to the following Tweet:

cthulhu@cthulhu:~$ echo -n “The Kiss Marketplace at hidden service address kissmpg5zave56f4.onion and IP address will be seized by the British or Latvian police in the very near future. They have used no magic or special technical ability and Tor is not broken. SALT VyKMK7mojPBlm1JpIGDtA5Zfc0x5ZOTLELqLxgupBpVq5mBnZzP4qcn” | sha1sum | awk ‘{print $1}’

Update on Current Projects


I have to apologise first for the lack of follow-up to my previous posts (they are on the way – I promise!). I have been focussing on a new project that I have had in the works for some time now and have been planning that out quite extensively. With lots of potential for hidden services and a  complete lack of transparency in the ecosystem, starting a new project that is designed to scale massively is a rather unique challenge.

As a quick overview of them all, I wanted to update those who follow my projects on some of them.

First is the shared hosting project. Most of us remember Freedom Hosting and the stir that caused over a year ago. It was one of the few places in the hidden service ecosystem that people with very little to no technical ability could maintain their site without having any knowledge of command lines, web servers and hardening. With that now gone, it puts the entry barrier to hidden services ever higher. Despite my previous post designed to make is quite painless, the fact of the matter is that using a command line is still intimidating to many people who have never even ventured away from Windows.

Making a shared host is a much harder job than one would imagine, particularly with the prevalence of them on the “clearnet”. Most shared hosts on the DNS system rely on a small set of tools to achieve this, usually cPanel WHM, Plesk and WHMCS. While there is nothing particularly wrong with these tools, they are simply not designed for hidden services and licensing issues could pose a real problem to widespread deployment. This is what made me decide that I need to create a custom solution from scratch.

Scaling on the hidden service is also a very difficult problem, especially with high traffic. In addition, I don’t want to be redesigning this system every few months as it drastically increases workload over time, and so getting this right the first time will make things way easier for me. Here are some of the problems I am thinking about when building this system:

1. Tor can only use one core of a CPU to process traffic and perform crypto operations. That means I must load balance between several tor processes. What are the best means by which to monitor this and automate the process of load balancing hidden service keys across the processes – in particular if the virtual machine isolation is used between them.
Solution: Using a single core virtual machine on another server, and then pointing the HS at another dedicated server means the CPU is dedicated to that process for maximum throughput. Then, using a machine on the control server, it can use SSH keys to distribute the private keys and hostnames based on their load readings and shuffled as required.

 2. If a DDOS is performed, it will likely max out the CPU core before saturating the traffic or guard. How can I mitigate this?
Solution: Creating a separate virtual machine from the rest that has more stringent resources allocated to it. This means the DDOS will only exhaust a small pool of resources and leave the others to perform normally, serving the existing hidden services. This does not prevent or stop a DDOS, but it does limit the damage that is caused by a single client being the target of an attack.

3. How can I prevent the system being overloaded by the tor process, the web server, the database and the file storage all on a single server?
Solution: Split them. One server shall handle the tor processes, split into smaller virtual machines for isolation and pseudo load-balancing. The Tor server will also have an Nginx reverse proxy installed on it locally with a large SSD cache, perhaps 240Gb that will store frequently accessed disk material. This reduces the intra-server network load and reduces requests and connections between the frontend and the web server. Plus using an SSD over a hard drive reduces the latency between the request being made and replied to, so larger files like images or constantly accessed text files are read at lightning speed. Using hardware to their specific tasks is also useful; so for the Tor process machine a high CPU clock rate and small SSD storage is best. For the webserver, multiple cores are better with large storage pools in a RAID array for redundancy. The database server must have a good CPU, but large amounts of RAM and a SSD storage pool, that performs better under a large amount of small read/write requests than disk-based drives, will make increase performance substantially.

4. How can I scale the storage pools? Ideally I would like to point the webserver to a single backend storage mechanism so it can grow seamlessly, but I cannot use a cloud solution due to the inherent privacy risks.
Problem: I haven’t fully thought this part through yet, but redundancy and the ability to scale it to many TB’s is very important. Please feel free to write in if you have any suggestions!

My aim in this project is to bring hidden services to the masses. This is critical to me as with every new revelation from the Snowden leaks; I am losing faith constantly in traditional security models. Tor hidden services provide end to end encryption by default and offer privacy for both the user and host. But to make a technology come to a larger audience, we have to lower the barrier to entry so that anybody can easily throw up their own blog. We can work together to break the dogma that privacy is only for “bad” people.

Another, probably more controversial project, is a file/image hosting service.  Now there is the stereotype that all image hosts are simply for the purpose of child porn on the “dark net”, but I differ. The only reasons tor hidden services have a reputation for child porn is because nobody bothers to challenge the stereotype. We need more challengers, who want to shift the landscape. We can’t wipe out child porn, but what we can do is bring the layman to hidden services and spring up legitimate services to drown out the notion that such technology is only for criminals. We can only change the world when enough good people stand up and challenge whatever negativities or reserves people may have.

An image/file host has many of the same challenges, minus the databases, so that project is somewhat straightforward and shall be a great primer to optimising the full web hosting service.

If you have any thoughts on what sort of hidden services you’d like me to launch, please do let me know! My 2015 goal is getting hidden services to the masses and so I’d always love to hear your suggestions, or perhaps feedback on my plans above.

Setting up a hidden service with Nginx


Setting up a hidden service is not difficult, despite all the headlines lately of major busts and it often being referred to as the “dark net”. In this quite short guide, we have the very simple aim of setting up a hidden service to serve up static HTML pages using Nginx. I could write a whole thesis on why using Nginx is superior to Apache for this use case, but for now I shall keep it simply to “it’s simpler and more secure”.

This guide is in no way meant to be exhaustive here. This is not a hardening guide. This is here to get you started with your first hidden service. You can rent a VPS to do this, or you can even host it on a virtual machine on your computer (it makes no difference – really).

Now I intend for this to be as accessible as possible but there is a very small set of requirements. I don’t believe this will rule out anyone who is intending on setting up a basic hidden service.


– Know how to SSH into a VPS/server
– Running Debian 7 (Wheezy) 64 bit

What I would recommend for your Debian installation is at least 256 MB RAM, 1 core or more and 8Gb or more hard drive space. If you are installing Debian on your local machine, you do not need to install anything but the very base files. Everything you  need in this guide will be installed as we go along. However for the purpose of this guide, I will act like you are using a basic VPS. Commands will be highlighted in purple & configuration entries in blue.


Contents at a glance:

1. Connect to the server
2. Retrieve some packages
3. Setup user
4. Add user to sudoers & basic SSH configuration
5. Download & install Tor
6. torrc file configuration & hidden service key generation
7. Nginx installation & configuration


1. Connect to the server

To SSH into your VPS, it is very simple. If you have a Linux computer, go to the command line and type:

ssh root@<ip-address-here>

This will prompt you to enter the root password and once you have entered it, you should be logged in as root!


2. Retrieve some packages

As root, type the following command:
apt-get update && apt-get upgrade && apt-get install sudo nano
You will then be told how much additional space is required to install the above packages after the package list has been updated, and the updates downloaded. Type “Y” and hit enter to accept and install them.


3. Setup user

It is recommended you never run any software as root when you can avoid it. So as root type:

adduser user

This will add a new user called “user” (feel free to replace this with whatever you want). You may be asked for various other bits of information like full name, office number etc, you can just hit enter to skip them. At the end you will be asked “Is the information correct?”, again type Y and hit enter to confirm.


4. Add user to sudoers & basic SSH configuration

For those not familiar with Linux systems, sudo is the package which enables users to obtain superuser capabilities just like root for certain tasks. This allows a user to login to the system and manage it without needing to switch to root. To add your new user to the sudo list, type the following as root:
sudo adduser user sudo

Now “user” has been added to the sudoers list. Now we should make some very quick and basic changes to your sshd process to block off anyone trying to SSH into your VPS as root and a simple technique to stop brute force SSH attempts.

To open up your sshd configuration, type:
nano /etc/ssh/sshd_config

The first option to find is “Port 22” which should be near the top of the file. Change the port “22” to something non-standard, for example 22555, so the new entry should look like this:
Port 22555

Now you need to disable root SSH login attempts. Find the option “PermitRootLogin yes” and change it to “no” so the new entry is as follows:
PermitRootLogin no

Now as root, reload the SSH service using:
service ssh reload

This reloads sshd, and your changes should now take effect. Note that in future when you SSH into your server, you must remember the new port and login as a user. So for example, if your new user is called “user” and the port you changed the above setting to is 22555, your new ssh command is:

ssh -p 22555 user@<ip-address-here>


5. Download & install Tor

The first and most important thing that must be done is to update the sources list to the official Tor Project repository. To make this easy for you, I have reduced this to a single command:

echo ‘deb wheezy main’ >> /etc/apt/sources.list && echo ‘deb-src wheezy main’ >> /etc/apt/sources.list && gpg –keyserver –recv 886DDD89 && gpg –export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add – && apt-get

This means the official Tor repository is now added to your sources list, and you have downloaded the official Tor Project keys to your server to cryptographically ensure the binaries you receive are genuine. Now to install Tor itself, we want to switch to our newly created user which in this instance I have called “user”. This can be done by running the command:

su user

Now to install the Tor binary and the Tor Project keyring, run:

sudo apt-get update && sudo apt-get install tor

Tor is now installed and automatically starts!


6.  torrc file configuration & hidden service key generation

The torrc file is the configuration file Tor reads your options from. The file is full of information that we don’t currently need, and so I recommend deleting the existing torrc file and creating a new one. This can be done using a single quick command:

sudo rm /etc/tor/torrc && sudo nano /etc/tor/torrc

This should now remove the existing torrc and open a new one up in the nano file editor. The minimum you will require for running a hidden service is the following configuration, which can be pasted and saved in the new file:

DataDirectory /var/lib/tor
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80

Pressing Ctrl + X will save the file. Now to generate the hidden service key and make the Tor process take note of our changes, we should reload the process:

sudo service tor reload

To find out what your hidden service key is (also known as the hostname), use the cat command. Write this hostname down somewhere or copy it to your clipboard – you will need it in a moment:

sudo cat /var/lib/tor/hidden_service/hostname

The private key can be found at (you don’t need to view this right now, this is for your information only):

You can share the hostname key with anyone you want to visit your site. It should look something like qhzwfy24i22jchdw.onion (this is the one I generated when testing this tutorial).


7. Nginx installation & configuration

As user, type the following command to install Nginx:

sudo apt-get install nginx

Now we need to make a new directory in /var/www/ for our hidden service site. Use the mkdir command to do this:

sudo mkdir -p /var/www/hidden_service/

Finally, we need to set the permissions for the new folders:

sudo chown -R www-data:www-data /var/www/hidden_service/ && sudo chmod 755 /var/www

So we can test the setup in a moment, let us generate a quick test index page, very similar to how we made the new torrc file earlier:

sudo nano /var/www/hidden_service/index.html

In this file, paste the following snippet of HTML code and save the file:

<html> <head> <title>Hidden Service Success</title> </head> <body> <h1>Success: You Have Set Up Your Hidden Service With NGINX</h1> </body> </html>

Now comes the part where we need to configure Nginx to listen in the correct place. In Apache, this would be called a Virtual Host but on Nginx they are known as Server Blocks. To make the new Server Block, we are going to to use the nano command again:

sudo nano /etc/nginx/sites-available/hidden_service

In this newly created file, paste the following snippet of information. Using the hostname you copied earlier to replace qhzwfy24i22jchdw.onion with your own address:

server {

root /var/www/hidden_service/;
index index.html index.htm;
server_name qhzwfy24i22jchdw.onion;

Save and exit this new file. The last step now is to create a symbolic link between the sites-available directory and sites-enabled directory. In Apache, we use a2ensite but Nginx does not have such a function, but instead we can use the following command to form one:

sudo ln -s /etc/nginx/sites-available/hidden_service /etc/nginx/sites-enabled/hidden_service

Finally, restart Nginx for all the new configuration options to take effect:

sudo service nginx restart


That’s it! You now have your own hidden service online! Using the Tor Browser, if you visit your hostname (the 16 characters followed by the .onion) you should now see a page reading “Success: You Have Set Up Your Hidden Service With NGINX”. You can now upload your files in the /var/www/hidden_service/ directory or follow other setup guides on the net to install other applications!

I hope this guide has been of some use to you, particularly if you are new to hidden services. For the non-techies out there, it is a considerable stepping stone to understanding how the web works once you have gone through the steps of setting up your own, particularly using a hidden service! If you have any further questions on this, have errors or want me to write further guides on installing specific applications, please do let me know by getting in touch via the Contact page or catch me on Twitter @CthulhuSec!

Proof of Knowledge & Disclosures


Copies also kept at the following paste locations:
Hash: SHA1

Please keep a copy of the following checksums for future use. I am not
at privilege at this moment to divulge anything further about what these
checksums may or may not verify other than to state they are a proof of
foreknowledge about events which are about to unfold. I hopefully will
never need to release these, but if I must it is crucial the
authenticity can be verified by as many people as possible. The context
of these and who it concerns at Tor hidden services.

On Twitter:

On Twitter:

At this moment (3rd Feb 2015) I am under no compulsion to write this
message and I have not been served any gag orders in relation to the
exact text above. Should for any reason I become unable to disclose the
above information myself, another person will step forward to do so.
Thus gagging orders aimed at myself, my legal team, my known associates
or any other form of restraint against me will not prevent the release
of this information. Should my enemies test my resolve on this matter –
you will fail.
Version: GnuPG v2