Fascist Hosting Company 1776hosting.com

AS397702 1776 Solutions, LLC

IP Addresses: 256


Hosted Domains
There are 9 domain names hosted across 13 IP addresses on this ASN. RouterOS v6.45.3 1776hosting.com https://mail.jaw.sh Kiwi FOSS kfcdn.xyz https://riot.kiwifarms.net, matrix.kiwifarms.net https://www.lolcow.tv nginx [ssl:autodelete.kiwifarms.net] 9chan (Cloudflare), 9chan.hk 9chan (Cloudflare) matrix.kiwifarm.net git git.kiwifarm.net [503 Service Unavailable] democratieparticipative.website [NS_ERROR_NET_ON_TRANSACTION_CLOSE] sonichu.com https://mirror.bullshit.agency [400 Bad Request] CentOS [ssl:wiki.onaforums.net] https://onaforums.net [Apache] Apache2 Debian [action-zealandia.com] nginx [ssl:brooklynfink.com] Freech Enterprises LTD https://lsxsnow6jabasmfaioc6hmxlzqld45tbppc474rm2kswpslbybttylqd.onion resetera.kiwifarms.net 9chan (Cloudflare) [possibly principal live site] 9chan (Cloudflare) [possibly also ninechn[xxxxxxxxxxxx].onion]

A Quick Look into 8 Chan – IP Map

8 Chan is hosted in Reno, USA at N.T Technology In. They employ a range of servers to host 8chan including a mail server, a mirroring server, and various mirror servers. 8 Chan are a service that masquerades as a free-speech platform but in reality is purpose built to recruit, train and mobilise ethno-nationalist and alt-right extremism.

8 Chan employs the services of CloudFlare who protect their terrorism spawning platform from DDoS Attacks.

For a look into their other websites, see: EXCLUSIVE: How money flows from Amazon to 8chan

What is more interesting than staring at CloudFlare servers are the actual 8 Chan web-servers themselves. Below is a little map of their current setup which will likely change in the coming days.

Warning: This may bore you to death

  • https://whois.arin.net/rest/org/NTTECH-1.html
    Jim Watkins and his son run this little private server farm.
  • https://whois.arin.net/rest/poc/TW488-ARIN.html
  • Netblock NET-206-223-144-0-1 (Hosts 8ch.net) Info
  • https://whois.arin.net/rest/net/NET-206-223-144-0-1.html
  • IP Block: –

Production Servers

Server IP:

  • Server: nginx/1.11.3
  • Mail server
  • X-Powered-By: PHP/5.4.16
  • mail.8ch.net
  • SSH-2.0-OpenSSH_6.6.1
  • Ports: 22, 25, 80, 110, 143, 993, 995, 5353 is open – Multicast DNS

Observation: This is obviously a mail server application and very out of date.

Server IP:

  • Not properly bound to 8chan
  • Server: nginx/1.8.0
  • SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420

Observation: It is likely this is the principle server

Server IP:

  • Bound to 8chan.net
  • Server: nginx/1.14.0
  • SSH-2.0-OpenSSH_7.2 FreeBSD-20160310

Server IP:

  • redirects to 8chan.net
  • Server: nginx/1.8.1
  • OpenSSH NULL

Server IP:

  • redirects to 8chan.net
  • Server: nginx/1.10.1
  • SSH-2.0-OpenSSH_7.2 FreeBSD-20160310

Live Static Archives:

  • They appear to be static live html outputs of the site
  • PHP script is disabled

  • Server: nginx/1.8.1
  • SSH-2.0-OpenSSH_7.2 FreeBSD-20160310

  • Server: nginx/1.14.0
  • SSH-2.0-OpenSSH_7.5 FreeBSD-20170903

  • CVE-2018-15919
  • CVE-2018-15473
  • CVE-2017-15906
  • Server: nginx/1.14.0
  • SSH-2.0-OpenSSH_7.5 FreeBSD-20170903

  • Server: nginx/1.11.2
  • SSH-2.0-OpenSSH_7.5 FreeBSD-20170903


Other servers of interest in this IP range (but not necessarily 8CH):

  • ESMTP Postfix (Ubuntu)
  • Server: nginx/1.4.6 (Ubuntu)

  • Server: nginx
  • Port 123 is open: NTP Multicast DNS…Mac?
  • Port 443
  • Port 5353 is open: Mac workstation?
  • Port 8080 is open: = > See below
  • Port 9306 is open: database port, probably bound locally

Observation: This looks like a remote workstation

  • Server: nginx
  • This server likely does the archiving / static page generation
  • https://gitgud.io/Sapphire/FutaBilly

  • SSH-2.0-OpenSSH_7.2 FreeBSD-20160310

  • Port 22 open
  • CVE-2016-8858
  • SSH-2.0-OpenSSH_7.2 FreeBSD-20160310

Observation: SSH servers?

  • CVE-2016-8858
  • SSH-2.0-OpenSSH_7.2 FreeBSD-20160310

Observation: SSH servers?

  • Meow
  • Server: Apache/2.4.7 (Ubuntu)
  • SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8

Why you should ditch Cloudflare

Cloudflare is a network provider offering a reverse proxy, pass-through service. Apart from some terrible security practices, (for example even if you use SSL certificates [https://], Cloudflare can see your passwords), Cloudflare also does the following:

  • Shields criminal webmasters by hiding their IP address from the public.

The example most on our minds at the moment is the massacre of worshippers at several mosques in Christchurch, Aotearoa New Zealand by a white supremacist terrorist, who had used 8chan as a launch pad for his terror. Cloudflare, while fully aware of the activities that occur on 8chan, and even after this took place on their clients web platform, continue to offer them IP shielding, protecting the very existance of 8chan, allowing users free reign to plan, strategise and refine the tactics of their next mass shooting.

What can you do?

Check if your company or webserver uses Cloudflare and ditch them. They are not an essential service for 99% of their customers use their service more because of scareware tactics by the company.

How can I find out if my website is using Cloudflare?

Check to see if your domain name is in the following list of 10,078 websites that use Cloudflare:

If they are then if you are familiar with domain name DNS you can either log into your web service control panel and follow their instructions about how to disconnect the service, essentially resetting your domain name servers back to their original settings, or contact the help and support centre of your web service to request either instructions or their assistance to remove your support for this service.

Defeating fingerprinting scanning of onion websites running WordPress:

This is not a discussion about detecting if a TorHS website has WordPress installed, but rather about tricking attackers that scan your website into moving along, nothing interesting here.

For starters, if you are running multiple onion websites on a single webserver (and my recommendation is that you do not do this, use one website per webserver), you will need to make sure that your server is not vulnerable to an attack where it is possible for an attacker to enumerate all the onion sites running on your server.

So don’t be lazy, set your Virtualhost containers ServerName correctly!

That said (and is the point of this little blog piece), even if you have correctly configure this, WordPress has recently added a function that adds an extra ‘dns-prefetch’ into the page code which is in of itself, not interesting other than it could cause your onion site to be short-listed for further attention by attackers scanning for virtualhost mis-configurations because this new addition to WordPress can trigger a false positive.

For example if an attacker were to trace:

$ curl -H "Host: abcdefghijklm.onion" --socks5-hostname -s --user-agent "Mozilla/5.0" abcdefghijklm.onion | sha1sum

(note: even though sha1sum is vulnerable to collision attacks, we use it here merely for illustration purposes – i.e its a short hash)

This returns:
5f18492f012c9e1d0df76c47d4a7b75c703ae6c3 -

Same trace instead using localhost as the hostname:
$ curl -H "Host: localhost" --socks5-hostname -s --user-agent "Mozilla/5.0" abcdefghijklm.onion | sha1sum

4d0389cf2c7e362fa5b3d920c8c6c394f5d0d021 -

This is because WordPress adds an extra:

< link rel='dns-prefetch' href='//abcdefghijklm.onion /' >

…when the trace hostname is localhost.

To prevent this, go to:

remove_action('wp_head', 'wp_resource_hints', 2);

Now trace:

$ curl -H "Host: localhost" --socks5-hostname -s --user-agent "Mozilla/5.0" abcdefghijklm.onion | sha1sum
5f18492f012c9e1d0df76c47d4a7b75c703ae6c3 -


$ curl -H "Host: abcdefghijklm.onion" --socks5-hostname -s --user-agent "Mozilla/5.0" abcdefghijklm.onion | sha1sum
5f18492f012c9e1d0df76c47d4a7b75c703ae6c3 -

Hashes match! Your site is not interesting, attacker moves along…


Hokioi Security OPSEC practices

Hash: SHA256

Hardware Security:

  • Hard drives are encrypted with unique pass phrases
  • Servers protected by pfSense hardware firewalls

Operating Systems:

  • Client OS: TAILS
  • TAILS USBs are destroyed regularly with a grinder and ‘soaked’

Communications Security:

Information Security:

  • Pass phrases are spread out over multiple e2e encrypted remotely stored password DB’s
  • No sensitive information is stored on any inhouse devices
  • Personal data is stored on an airgapped offline computer
  • Hokioi Security Canary Statement

Version: GnuPG v2


Mitigating Jackhammer 1.2 website traumatising tool styled attacks

Hash: SHA256

What is Jackhammer 1.2?

Jackhammer 1.2 ( sometimes called Jackhammer 2.0 ) was developed in 2003 by Mike Parniak ( Archon ) from TheBlackHand / Cafe Counterintelligence in response to CCISecurity script he released that blocked attacks from Jackhammer 1.0

Jackhammer is a MS Windows only, layer 7 attack application that also allows attackers to use multiple anonymous proxies to distribute the perceived point of origin of an attack across as many proxies as an attacker desires or is able to use, therefore masking the originating IP address of the attacker.

Attackers are able to choose from a number of attack strategies allowing them to tweak the exact type of attack that Jackhammer performs as well as optimising the overall data transfer, i.e 10,000 proxies x 0.1 ms = 1 request per 1000 seconds per proxy.

While Jackhammer is an old application, it’s attack method is still very relevant today as it was in 2003. With the advent of flood protection services such as Cloudflare, Jackhammer attacks are easily thwarted, but without employing such services, webservers are still quite vulnerable to the attacks that can be delivered via Jackhammer.

Jackhammer 1.2 Connection Strategies:

* Disconnect after Response Code: On this setting, Jackhammer only reads the first 12 bytes of the webserver’s response, in order to get it’s HTTP response code. This is mostly used in conjunction with the “Disable proxies on Bad Response Code” option. It lets Jackhammer detect if a proxy has been banned (403 code) or similar, and thus disable now-useless proxies during a flood.
* Disconnect on any data received: As soon as data is received from the proxy server, indicating a response to Jackhammer’s request, Jackhammer destroys the socket to avoid further data (minimizing received data, but ensuring that the proxy is responding).
* Hold connection until disconnected: This setting has Jackhammer sit on the socket and not disconnect it. Only if Jackhammer needs to create a new socket and is maxed out, or if the remote host disconnects it, will Jackhammer destroy a socket. This setting is often best used in conjunction with a slow speed to run a webserver out of connections.
* Disconnect after data sent: A low-bandwidth lifesaver. This option causes Jackhammer to disconnect immediately after successfully sending all the header data to the proxy. Tests have shown that the proxy will still deliver the request to the target server before disconnecting. This means it is a good option to use against scripts, but a poor option against large files.
* Incremental List Segments: If an attacker has a large list of proxies, and are worried that the website they are flooding may ban the proxies they use as they’re flooding… attackers can have it only use pieces of the proxy list at a time.
* Get and use initial cookies: One of the other powerful options on Jackhammer is the ability to get and store the cookies that websites return, and pass them along on future connections. If an attacker enables this option then the first time each proxy performs a request, Jackhammer waits for the full response header and records all the cookies. From this point on, it adds a cookie: line with those cookies to all requests from that proxy.
* Get, use, and keep cookies updated: This option only works if the attacker also has the above option enabled. Instead of just waiting for the first set of cookies, Jackhammer will always read the full header and update the cookies accordingly.

An attacker can use these combinations of attacks to simulate expected traffic but at such a scale as to cause a denial of service condition, and in some cases, with little bandwidth consumption.

Example Low Bandwidth GET Request Attack:
For example where a CMS creates and database stores guest cookie sessions in this manner:

$guesthash = sha1( $_SERVER[ 'HTTP_USER_AGENT' ] . $ip );

Attack Method: Disconnect after data sent

GET http://attackvictim.com/?%%ALPHANUM[4,10]%%=%%ALPHANUM[4,10]%% HTTP/1.1
Accept: */*
Host: %%HOST%%
User-Agent: Mozilla/4.0 %%ALPHANUM[4,10]%%
X-Forwarded-For: %%IP%%

Then the above attack request method would quickly fill a database with junk guest sessions and in many cases overwhelming the database with very little data sent due to the ability to customise the user-agent with every request.

Add to that the ridiculously shitty way for example in which vBulletin determines the real IP address of a visitor in its fetch_alt_ip() function ( includes/class_core.php ), it is even possible to spoof the IP address with every request as well.

Resource Intensive Request Attacks:

Because Jackhammer allows for custom HTTP header requests, an attacker will often look for the most CPU/memory intensive, and/or bandwidth intensive request as their choice of attack.

POST Requests: these are cpu intensive and the favourite of attackers. Unprotected forms are the usual target and a flood attack of even a few requests per second can overwhelm a webserver.

Especially forms that result in an email, or emails being sent, can also result in both a servers resources being overwhelmed as well as a bandwidth attack as mass amounts of emails are generated from each POST request.

However there are other POST requests that can overwhelm a server even without a waiting form.

For example versions of PHP earlier than 5.4 were very susceptible to blind post request attacks where the post data generates a large multidimensional array:



GET Requests: often targeted at site features like search functions where a search request results in a database intensive request which repeated in quick succession can quickly overwhelm a database server resources.

Example GET request of a search function using wild cards:

GET http://attackvictim.com/?search=a*&%%ALPHANUM[4,10]%%=%%ALPHANUM[4,10]%% HTTP/1.1
Accept: */*
Host: %%HOST%%
User-Agent: Mozilla/5.0
Client-IP: %%IP%%

GET request attacks targeting large files can also result in a bandwidth attack sufficient enough to cause a denial of service request condition.


How to mitigate Jackhammer type attacks ( in this example using PHP and optionally javascript ) without ceding to the likes of Cloudflare, or other captcha services/methods:

One approach to mitigate an attack from tools like Jackhammer is to enumerate the ways in which these tools fail to emulate a standard browser as a means of detecting them as the source of an HTTP request.

Most layer 7 HTTP request attack tools cannot interpret javascript so therefore it is possible then for a server to ask a complex javascript initiated question that a standard browser with javascript enabled would be able to answer.

For example you could write a piece of javascript to set a session which a standard web browser would have no trouble completing but an attack tool like Jackhammer could not.

Javascript though for some web admins is not preferable.

The usual method is to set a session based IP management to count requests per a period of time and restrict IP addresses that break these rules.

A Jackhammer attack is often mistaken as a botnet attack because Jackhammer allows an attacker to deploy multiple proxies.

An attacker with a very large proxy list can deliver a sizeable attack even against rate-limiting algorithms because of the time it would take for Jackhammer to toggle through a very large list.

The time between the first and second request from a specific proxy IP address of an attacker employing say 10,000 anonymous proxies could be 5 minutes.

Combined with javascript as noted above, will very likely prevent an attack from proceeding.

Lastly it is important to prevent direct access to large files on a server, and it is preferred to pipe a file via session based access which are subject to the same browser emulation requirements stated above.

Download Jackhammer 1.2 for testing purposes only: https://mega.nz/#!fII2BKpZ
Decryption key: !CEFrXPHEbzFD2XdxIbpRRdhJjCHd1AifiCc256LwB3I
Version: GnuPG v2


Further security considerations when hosting a SecureDrop or Globaleaks server

Hash: SHA256

If you are a journalist organisation with a central office situated in a country that respects the role of journalists, then you may quite comfortably run a SecureDrop or Globaleaks server within the offices of your organisation and depend on journalistic privilege preventing governments from entering your offices and walking out with your secure dead drop servers, or forcing you to hand over ( in the case of SecureDrop where encrypting with a journalists GPG key is left up to the source ) the applications GPG key, or placing gag orders on you.

Be careful though, many states will selectively respect the rights of journalists depending on the size and power of the news network. For example even in Aotearoa New Zealand, the police have little qualms raiding the houses of independent journalists such was the case with investigative journalist Nicky Hager in 2014.

If your threat model means that keeping the location of your dead drop secret is also critical, then you should consider taking additional steps to protect your tor hidden service IP and therefore location from being discovered.

Hosting a secure dead drop:
Never run your SecureDrop or Globaleaks server on a VPS or any other form of remote hosting. There have been too many instances of virtual server vulnerabilities as well as malicious VPS providers. The most secure option is dedicated hardware in a secure premises.

Also avoid single point of failure services like load balancing methods which attempt to cloud host SecureDrop or Globaleaks servers. That also goes for applications that remote host the private keys. Avoid these.

Prevent guard node attacks:
There are a few types of attacks that target the relays which your SecureDrop or Globaleaks servers connects to. Their purpose is to deanonymise your server, and can also be used to attempt to identify who is connecting to your service.

To mitigate this attack you will have to consider running your own anonymous relays as dedicated entry nodes for your SecureDrop or Globaleaks server.

When these are safely configured, your SecureDrop or Globaleaks servers can then be set to now select its entry guard node only from those stipulated in the torrc file, and if these relays come under attack, your dead drop will just become unavailable rather than shift to relays that could potentially be under the control of an attacker.

Do not draw attention to your Tor Hidden Service:
Make sure the IP address of a Tor Hidden Service does not act in a way dissimilar to a standard user of Tor, the attacker will not be able to easily determine that there is a Tor Hidden Service running ( i.e do not run any other service on the IP of your Tor Hidden Service as these may draw attention to your specific IP address ).

It is also good practice however to run your SecureDrop or Globaleaks server on a separate internet connection than your organisations own corporate network connection.
Version: GnuPG v2


Choosing the right secure submission system for your organisation

Hash: SHA256

To begin, first read @yawnbox’s excellent piece on this.

Choosing which secure source submission platform is right for you. I want to add some additional thoughts on the differences ( while hopefully not regurgitating too much of what has already been covered by @yawnbox )


SecureDrop in my opinion is designed and best suited with medium to large sized news media organisations in mind. If you are an established news media organisation and are seeking the most secure anonymous platform to manage newsroom sources, then you should look at deploying a SecureDrop platform.

SecureDrop requires the greater investment in equipment to meet its minimum requirements, and experienced Linux administrators to maintain and operate.

With SecureDrop, the administrator must be in-house.

SecureDrop does not require the source to have a javascript enabled TorBrowser in order to interact with the server and upload documents.

SecureDrop does offer the source the option to manually pre-encrypt files with the journalists PGP keys before uploading, without this though, a file is still encrypted with the applications own dedicated PGP key. This means person/persons with the pass phrase of the application’s PGP key can decrypt uploaded files.

SecureDrop’s technical strength is it’s NSA level hardened threat model reducing the threat surface to the bare minimum. The security practices stipulated in the SecureDrop Wiki documentation should be used by all journalists when handling secure information.

However at a certain level it also depends on a country’s ruling government to respect the right of journalists. For example a government who does not respect these rights could force the administrators to hand over the application’s PGP keys thus being able to decrypt any files still resident on the SecureDrop or future submissions if the organisation is forced to continue running the SecureDrop under duress.


Globaleaks was designed to scale from a single journalist/receiver through to as many journalists/receivers as your server can handle, using the least amount of equipment -> a single webserver ( and an optional additional hardware firewall – my professional recommendation ).

Globaleaks requires the source to have a javascript enabled TorBrowser.

A Globaleaks administrator does not have to be in-house in order to configure administrative settings.

A Globaleaks source files are first temporarily pre-encrypted with a symmetric AES key before being encrypted with the journalists own PGP key ( recommended deployment method ). Therefore at no time are the files stored on the server in unencrypted form. This also means only *that* specified journalist can decrypt files sent to them.

An encrypted email notification can be configured to be sent to the corresponding journalist/receiver when a submission is made.

Globaleaks server can be more securely deployed in a country/region that has no respect for journalist privilege, or used for non-journalist related deployments using standard compartmentalisation methods. If the server location is compromised, a state actor cannot get access to encrypted files. Getting access to source content files is only possible if they de-anonymise the journalists/receivers, AND get access to their PGP private key pass phrase, in which case only the files of the individual journalists/receivers that are still resident on the server will be compromised, rather than all files.

Common to Both

Both platforms deploy on the Tor network to provide a layer of anonymity and end to end encryption as well as some protection of the location of the secure dead drop systems.

Both allow for multiple receivers/journalists.

Like any webserver system, they need an administrator to keep the physical equipment’s OS and applications up to date.

Both Globaleaks and SecureDrop can be deployed into an already compromised network, as is the case with many established news organisations, this is due to the use of the SecureDrop recommended pFSense hardware firewall being used with either choice.


Many journalists still struggle with basic encryption issues. Using TAILS correctly and with persistence configured correctly, takes time to learn, and get used to if you do not use it regularly. PGP crypto is difficult to get right and clunky to use.


So as is the case with some deployments of SecureDrop, often the administrators or an onsite security specialist is employed to take on the role of “file decrypter” rather than the journalists doing this function. Once decrypted, files are analysed then encrypted by this person with the PGP keys of the nominated journalist before forwarding to them.


Globaleaks documented security requirements for journalists/receivers is low. Therefore I encourage journalists/receivers to use the same standards required by SecureDrop journalists/receivers. In security best practices they would only ever access the Globaleaks journalists/receivers login area via a dedicated TAILS laptop and decrypt files via a dedicated airgapped ( never used on the internet or networked ) TAILS laptop.

Globaleaks also demands sources enable javascript in their TorBrowser’s. This can be off-putting for the more security minded sources. Also some browsers like Orfox do not have the ability to enable javascript so are therefore blocked from interacting with a Globaleaks server.
Version: GnuPG v2


My Analysis of the Rawshark Hack of Cameron Slater’s Communications

Hash: SHA256

What I want to discuss here is the attack on the WhaleOil communications network which resulted in a large cache of emails and attachments becoming the centrepiece of Nicky Hager’s book Dirty Politics.

I hope that you the readers, bloggers and users of online services will learn from the mistakes Cameron Slater made, and harden your web applications to minimise the chances of this happening to you.

I will also try to keep this as non-techie and non-geeky as possible …

[ full story on Putatara.net ]
Version: GnuPG v2


How to securely leak information to a SecureDrop or GlobaLeaks whistleblower platform

Hash: SHA256

Your number one priority in sharing truth is to preserve your anonymity. Highly secure platforms for secure disclosure of information like SecureDrop and GlobaLeaks go as far as technically possible to protect your identity and to protect the transfer and dissemination of your information to the world.

However you need to take the right countermeasures to protect yourself long before you arrive at the point of sending information.

These mandatory considerations can be grouped in three categories: Social Risks, Social Responsibilities, Technological Risks

Social Risks

After a piece information has been liberated, and when the news about the facts related to the info you submitted reaches public media attention, yo uneed to understand the process that will take place around you. You need to have a clear understanding of how submitted information can be a risk to you even if your identity is protected.

  • Who else knows you has access to, or knows you have access to this information
  • Are ready to cope with all the “stress” of an internal or external investigation?

Social Responsibilities

After a piece information has been liberated, pressure will come on all who could have potentially disclosed the confidential information.

  • Will your anonymous disclosing bring undue persecution on others who will fall under heavy scrutiny along with yourself?
  • Will your anonymous disclosing cause further persecution on victims that would rather remain anonymous?

You should consider submitting to a SecureDrop or GlobaLeaks platform only after a full understanding these points.

Technological Risks

You must be aware of the fact that while using a computer and the internet to exchange information, most of the actions you do leave traces (computer logs) that could lead an investigator to identify where you are and who you are.

You may leave computer traces while:

  • Researching the information to be submitted
  • Acquiring the information to be submitted
  • Reading even this web page
  • Submitting the information to us
  • Exchanging data with receivers of your submission

All these actions may leave traces that compromise your security, but with a few technological protection steps, you can minimise the risks.

Social Protection

  • Don’t ever tell your intention to anyone before you make a submission
  • Don’t ever tell your intention to anyone after you make a submission
  • Don’t ever tell your intention to anyone after the news about the submission gets out to public media
  • Be sure that there’s no surveillance systems ( cameras or other ) in the place where you acquire and submit the information
  • Don’t look around on search engines or news media website for the information you submitted ( this would reveal that you knew about it earlier )

Technological Protection

To achieve a 100% guarantee of security from technical perspective, you need to be computer-proficient enough to fully understand all the risks.

However, by strictly following the procedures and tips reported below, you should be safe enough:

  • Submit information using Anonymous Web Browsing software Tor Browser Bundle
  • Don’t submit information from the personal computer provided to you by your employer
  • Keep the Submission’s Receipt ( GlobaLeaks ) or Diceware Phrase ( SecureDrop ) safe, and destroy this information after you don’t need it anymore
  • Don’t keep a copy of the information you submitted!
  • While acquiring the information to be submitted, be sure that there’s no traces being left leading back to your identity ( eg: store files using Veracrypt within your USB key, and when the submission process is completed, grind the USB key down to powder using a file or hand grinder )
  • Be aware of the fact that “meta data information” may be present in some of the data you are submitting.
  • Consider cleaning up the Metadata by using tools such as ExifTool, Exiv2, Exif Jpeg header manipulation tool, and/or MAT bundled with the TAILS linux live CD.
  • Consider converting all the data that you are sending us into standard PDF format.

By applying the above described procedures, you will be safe enough.

Safe enough doesn’t means 100% safe.

To overall improve your digital security you should undergo reading of the Security-in-a-Box project, which explains most of the risks and related countermeasures.

Security of the Hokioi Security Secure Submission Platform

Hokioi Security Secure Submission Platform is implemented using the GlobaLeaks Software, and anonymity for the confidential source is provided thanks to Tor software.

Tor is the state-of-the-art when it comes to digitally protect anonymity and has received a lot of attention from both the academic research community and experts in the IT security field.

GlobaLeaks is the first opensource, secure and anonymous confidential source platform designed by the Hermes Center for Transparency and Digital Human Rights.

Tor is already integrated in GlobaLeaks; that way, the Site Owner does not obtain any kind of traces or information about the Confidential Source’s identity or location.

Complete security can never be guaranteed; however, we have designed this technology taking into account scenarios where a confidential source’s life and liberty may be at stake.

Having read all that, the Tor accessible website address of the Hokioi Security Secure Submission Platform is:


Other Secure Submission Platforms of note:

Version: GnuPG v2