This is a guest diary written by Remco Verhoef . Remco is the founder of Dutchsec

The past weeks we’ve seen several large DDoS attacks taking advantage of public accessible memcached instances. By sending UDP packets to lots of memcached instances, with the source address being set to the victim, the return packet will be amplified (50.000 times) compared to the original packet, causing a DDoS of the victim. The largest attack seen so far has been 1.7Tb.

Several reports are referencing that the attacks contain a new method to deliver a ransom note and asking for Bitcoin or Monero. The ransom note (Pay_50_XMR_To) is included within UDP packets sent to the victim. (http://fortune.com/2018/03/02/crypto-hackers-monero-ddos-attack-ransom/)

We have seen attacks before where Elasticsearch, Redis and Mongodb instances had data replaced by ransom notes, claiming bitcoins. The vulnerable memcached instances have been around for a long time, which makes it possible that the data was replaced by an attacker not interested in the DDoS attempt, while another attacker used the same instance (with the content as is, in this case, the ransom note) for an amplification attack.

To effectively use a memcached server in a DoS attack, the attacker will first add data to the server. This will increase the size of the reply. So far, attackers have usually used one letter keys like “a b c d e f g h j k l m n” and then later requested the connect for these keys using the spoofed victim attacks. Within our honeytrap data we see first occurrences using the amplification signature “gets a b c d e f g h j k l m n” and UDP since 24th of February. An interesting fact is that for some reason key i isn’t being queried. In the period before we see a lot of “stats” commands (using TCP) probing our honeytraps. This could have been a first probe to see if there was a vulnerable memcached instance. Important to know is that to add a 1M large value into the database, TCP should be used.UDP is limited by the IPv4 datagram size to 64kBytes, effectively limiting the maximum value size to a little less than 64kBytes.

On 24th and 26th of February we’ve seen several gets being fired from (or spoofed to) host 103.60.13.34. In total we’ve seen gets from (or spoofed to) this host on 24th Feb, 26th Feb, 9th March and 11th March.

At the 26th of February, we’ve also seen host 185.165.31.26. The 27th we’ve seen host 162.212.155.220.

The 1.35 terabits attack on Github took place on the 28th of February. So apparently we’ve had some precursors of this upcoming attack 4 days before in our honeytraps.  On and after the 1st of March, at the time of the first publications about the attacks, we’ve seen an increase in the number of attacks.

The gets command being used will retrieve one or multiple exact keys, the DDoS attacker should have known (or prepared) the key.

We’ve added simple support for Memcached stats to Honeytraps. To be sure we don’t inadvertently participate in DDoS attacks UDP answers will be rate limited.

If you take into account the following, then we cannot exclude the possibility that instances had been ransomed before by different attackers than the attackers behind the large DDoS attacks.

• vulnerable and abandoned memcache servers have been accessible for a long time

• there have been ransoming of databases, indexes and caching servers before

• it is not logical to ask for ransom while firing the largest attacks ever

• no signs of replacing the data right before the DDoS attack

• instead of the XMR ransom note, we now see BTC ransom notes

• the cmd being sent to the server contained key names a till n, where many of the instances only contain key a. The initial packet could have been smaller, or the other b .. n keys have been flushed/removed already.

• the value should have been set by TCP, because the size of the values we see is close to the default 1M size limit.

The following question arises, did the DDoS attackers took advantage of ransomed instances to execute the DDoS or did they prepare the memcached instances themselves for a longer period of time?