The DDoS extortion criminal group, DD4BC, has been hunted ever since the group’s formation in July 2014 by their victims and law enforcement.
One of their first victims, Bitalo Bitcoin Exchange, issued a 100 bitcoin bounty in November 2014 for information on the full and proven identity of the perpetrators. Additionally, an international cooperation of law enforcement has been tracking the group for over a year and a half. DD4BC’s luck finally ran out. On Jan. 12, Europol announced that one person has been arrested and another detained as part of Operation Pleiades, a cooperative investigation that included law enforcement agencies from Austria, Bosnia and Herzegovina, Germany, the UK and Europol.
One would hope that the arrest would signal an end of DDoS extortion activity, but all signs point to a continuation of this type of behavior. The vast majority of victims do not pay the ransom and choose to wait it out or strengthen their countermeasures, but just enough websites pay the ransom to make it worthwhile for the attackers. Copycats have already sprung up with similar methods and objectives to DD4BC.
DD4BC’s (shorthand for “DDoS 4 Bitcoin”) methods were simple, but very effective: they would choose a victim, such as a financial institution or online gambling company, and launch a DDoS attack on the organization’s website. The DDoS attack, in most cases, would render the website inoperable or slow for visitors. DD4BC would then email a ransom “note” demanding payment. The ransom notes typically had the same attributes:
- A claim that the current DDoS attack the victim is experiencing is caused by the author of the note
- A demand for payment in Bitcoin — usually ranging from $500 to $25,000 when converted to USD
- A threat that if the ransom is not paid, attacks will increase in power and duration
- A promise that if the ransom is paid, DD4BC will leave the company alone forever
There are not any public, confirmed cases of a company paying a ransom to DD4BC; after all, it could be very embarrassing and call the company’s security posture into question, and encourage additional attacks from copycats. However, many ransom notes have been made public and it is possible to track the payment of Bitcoin due to the nature of the cryptocurrency’s public ledger. It’s not entirely conclusive, but there is strong evidence that many website operators paid the ransom, according to a 2015 report on DD4BC released by Arbor Networks.
Arbor Networks found that payments were regularly made to the Bitcoin wallets in the ransom notes; although small in monetary amount, they were steady enough to make the operation profitable. Considering that botnets that launch DDoS attacks can be leased very cheaply, the return on investment is attractive, even though the perpetrators are not likely to get rich.
Copycats have already sprung up; one notable example is the Armada Collective’s attack against ProtonMail in November 2015. Their methods and objectives are a near facsimile of DD4BC’s and this attack is the only confirmed case of the victim paying the ransom. ProtonMail came under sustained DDoS attack and received a ransom note promising to stop if the company paid. The company did pay — but the attacks did not stop. This appears to be because ProtonMail’s woes were made public, which led to even more copycat attackers joining in, hoping to get paid also.
What should a company do if they are attacked and receive a ransom note? Roland Dobbins, principal engineer at Arbor Networks explains,
“Organizations targeted in DDoS extortion attacks should never pay the extortionist — as we’ve seen on many occasions, the extortionist keeps coming back for additional payments, and others in the criminal underground will eventually hear that paying organizations are easy marks, as well, and they’ll end up being constantly bombarded by DDoS attacks.”
It may be tempting to just pay the ransom, to get the attackers to move on or to buy time to strengthen defenses, but this is not a good strategy. It’s best to build these type of attacks into risk models and incident response plans before they occur.
Originally published at www.csoonline.com on January 19, 2016.