AllCrypt WordPress Exploit Theft

Notice: This page is a new case study and some aspects have not been fully researched. Some sections may be incomplete or reflect inaccuracies present in initial sources. Please check the References at the bottom for further information and perform your own additional assessment. Please feel free to contribute by adding any missing information or sources you come across. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

It’s always fascinating to hear about an essentially anonymous exchange operator who secured the exchange only with Wordpress, taunted hackers on Twitter, and then was rude to customers after the fact. Luckily, this exchange didn’t achieve any significant volume, which is not surprising. Had they invested in a simple multi-sig cold storage wallet, all could have been avoided.

The country for this case study is not yet known.

https://web.archive.org/web/20140916141422/https://twitter.com/All_Crypt/

https://web.archive.org/web/20150322174606/https://twitter.com/All_Crypt/

https://web.archive.org/web/20150324203912/https://twitter.com/All_Crypt/

https://web.archive.org/web/20150324204356/https://twitter.com/All_Crypt/

https://web.archive.org/web/20150324204358/https://twitter.com/All_Crypt/

https://web.archive.org/web/20150324210329/https://twitter.com/All_Crypt/

https://web.archive.org/web/20150514221118/https://twitter.com/All_Crypt/

https://web.archive.org/web/20150324205249/https://twitter.com/All_Crypt/status/567551838719705091

https://web.archive.org/web/20150324213113/http://qntra.net/2015/03/amid-decision-to-close-allcrypt-com-reports-hot-wallet-theft/

https://web.archive.org/web/20150324205250/https://twitter.com/All_Crypt/status/567551838719705091

About AllCrypt

“Ironically AllCrypt tweeted “Too small and insignificant to be a target of the hacks this week. Your coins are safe here because no one cares to hack us” on 2/16/2015 (twitter: All_Crypt/status/567551838719705091)”

Homepage Online:

The Reality

There is no evidence to support the notion that hackers will not target smaller platforms. It's simply a matter of how hard the platform is to hack compared with the potential gain from doing so.

What Happened

The AllCrypt platform was hacked through a Wordpress exploit, and 42 bitcoin were taken.

Key Event Timeline - Allcrypt

Date	Event	Description
?	Too Small Tweet	AllCrypt complains to the world that they are too small so no one cares enough to hack them.
March 15th, 2015	WordPress Exploit	A thief manages to get into the AllCrypt Wordpress administration using a marketing director login credential.
March 18th, 2015	Post On Front Of Site	Post is made on the front of the website.

Technical Details

“Around 8PM on Sunday (all times EDT) our marketing director’s blog account requested a password reset. […] The MD saw this email come in, and forwarded it to myself, and another team member (a technical lead/temporary assistant support staff), letting us know what happened and that he did not request the password reset. I did not see the email at the time, as I was out, and it was not a huge red flag that would require a phone call. Once I returned home later, I saw the email, and logged into the server to double-check on things. That’s when I discovered the breach.” “The blog post goes on to describe how the attacker managed to upload PHP files to the WordPress site, install Adminer (a web based database management utility similar to PHPMyAdmin) and then create fake crypto currency balances in the system. From there, using a fake account, the attacker could then trade crypto currency and transfer earnings to a Bitcoin wallet owned and controlled by the attacker.”

Total Amount Lost

The total amount lost has been estimated at $12,000 USD.

Immediate Reactions

Notice On Website:

“On March 18, 2015, AllCrypt, a small crypto currency exchange posted what may very well be one of their last posts on their blog. The Bitcoin exchange had been hacked, resulting in stolen crypto currency.” “42 BTC stolen by the hackers” “The stolen Bitcoins might not seem that much, but for a smaller alternative crypto currency exchange even such an amount is not small.”

“The owner, who appears to be anonymous according to WHOIS information, claims that the site cost him a total of $15,000, and further that they only netted roughly 10 BTC in profits after thirteen months of operation.”

“Between hardware and operating costs, I am personally down over $15,000. Believe me – I feel your pain as well. No one on the site had as much on the servers as I personally did. Not that I expect pity or compassion, but I think it’s important to know that I’m not retiring to a private island because of this. I also think it’s important to be as open as possible to assuage any fears of an inside job.”

In response to a customer after the hack - “I see you running an exchange successfully, I’ll take your advice. Wait, you don’t run an exchange? You’re unemployed? Thanks for the input.”

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

Ongoing Developments

Multiple news articles continue to display inaccurate information on the amount of funds which were lost in the Allcrypt platform.

Individual Prevention Policies

When using any third party custodial platform (such as for trading), it is important to verify that the platform has a full backing of all assets, and that assets have been secured in a proper multi-signature wallet held by several trusted and trained individuals. If this can't be validated, then users should avoid using that platform. Unfortunately, most centralized platforms today still do not provide the level of transparency and third party validation which would be necessary to ensure that assets have been kept secure and properly backed. Therefore, the most effective strategy at present remains to learn proper self custody practices and avoid using any third party custodial platforms whenever possible.

Store the majority of funds offline. By offline, it means that the private key and/or seed phrase is exclusively held by you and not connected to any networked device. Examples of offline storage include paper wallets (seed phrase or key written down and deleted from all electronic media), hardware wallets, steel wallet devices, etc...

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

All wallets, minting functions, and critical infrastructure should be implemented with a multi-signature requirement, with a recommended minimum of 3 signatures required. This means that making important changes or approving spending will require the keys held by at least 3 separate individuals within the organization to approve. The multi-signature should be implemented at the lowest layer possible, all key holders should have security training, and all key holders should be empowered and encouraged to exercise diligence.

Work with other industry platforms to set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

Set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services within the country, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.