Human rights alliance ‘Karapatan’ under long lasting DDoS attack


– An analysis of the cyberattacks

Stockholm, 18th August 2021

During the past three weeks, the website of the prominent Philippine human rights coalition Karapatan has been under denial of service attack. The attacks started on 29th of July 2021, and are still ongoing. The attacks are taking place amid the online solidarity campaign #StopTheKillingsPH, which marks one year since human rights organizations and advocates across the world asserted the call to stop the killings in the Philippines and to prosecute President Rodrigo Duterte for his crimes against the Filipino people. The event also marks one year since the killing of human rights worker Zara Alvarez, active member of Karapatan.

In the spirit of changing the landscape of commercial denial-of-service mitigation services where forensics knowledge is kept highly confidential, Qurium discloses how the attacks were fingerprinted and mitigated with the hope that other organizations can learn from our experience, and in solidarity with human rights organizations and independent media that do not have the resources to mitigate and attribute targeted attacks.

This forensics report compiles our technical findings about the infrastructure and techniques used to launch the attacks against Karapatan.

The physical infrastructure

At the time of writing, the website is still receiving application layer web floods against the specific URL: https://www.karapatan.org/resources where the organization disseminates its human rights reports.

This is a breakdown of the attack infrastructure used to launch billion of malicious web requests.

The attack traffic is generated by:

  • servers running a modified version of CC-attack: Challenge Collapsar python code (%cc-attack)
  • headless chromium browsers (%headless)

and then proxied via 30.000 bots composed by:

  • Tor Exit Nodes (#tor)
  • Compromised Mikrotik Routers (#mikrotik)
  • Compromised VPS/Servers (#ssh)
  • Open Proxies (SOCKS4/5 and HTTP) (#openproxy)
  • Private Proxies (#proxyrotator)
  • Compromised IoT devices (#scada)
  • Large pools of IPs with closed ports in specific providers (#gho$t)

The geographical distribution of the bots that flood the website is global but four countries account for almost half of the bots: Russia, Ukraine, Indonesia and China.

Overview – Top countries distribution (CN, RU, UA, ID, HK, ID, VN)

The following providers/ASNs account for 25% of the bad traffic:

  • AS17974 PT Telekomunikasi Indonesia
  • AS42437 T2-ROSTOV-AS
  • AS29497 KUBANGSM
  • AS31213 MEGAFON
  • AS15895 KSNET-AS
  • AS45102 Alibaba (China)
  • AS8359, MTS

The Ukrainian, Chinese and Russian ASN have dozens of networks running bots and some prefixes show more than 50% of malicious traffic.

The network infrastructure

After looking into the geographical distribution of the botnet, the next thing we analyzed was the billions of individual requests that form the web flood.

A large part of the bad traffic are requests of the form:

/resources/?i257707892589o13400596508G96443965907L97881972700T

When analyzing each of these individual requests, with what looks as random strings to bypass any Cache system and anti-DDOS protection, we can see that one unique web request comes simultaneously from 100-400 bots and often with strong geo-location binding.

The same random unique request is multiplexed and hence amplified within a specific geographical region. The analysis of the different clusters of bad traffic shows a composition of multiple traffic generators proxying the random requests to specific pools of proxies. This behavior is very consistent across large pools of bots from Russia and China.

Unique random request forwarded to proxies in Russia *only*

This “random pattern” of the botnet when it comes to the traffic generation and the presence of many IP addresses that we identified as open proxies made us believe that the botnet mostly is a composition of proxy networks of different nature that are refreshed periodically.

We compiled close to 50 million flooding requests and extracted their “random” strings and applied some basic character frequency analysis.

/resources/?random_strings

The random generator creates unique requests of the form

CHAR: [A-Z][a-z]$ INTEGER [0-271400281257]

CHAR + INT + CHAR + INT + CHAR + CHAR + INT + CHAR + INT + CHAR

The character analysis shows:

1. We have a double character always in the middle of the sequence and integers around it 🙂

2. We have integers always < 271400281257

The answer is 271400281257

A google search for the number 271400281257 returned some results 🙂

User Agents with AdsBot-Google

While the botnet uses many different User Agents, many of them make references to Google Ads, for example

- Mozilla/5.0 (Linux; Android 5.0; SM-G920A) AppleWebKit (KHTML, like Gecko) Chrome Mobile Safari (compatible; AdsBot-Google-Mobile; +http://www.google.com/mobile/adsbot.html)
- AdsBot-Google (+http://www.google.com/adsbot.html)

This specific detail gave us one more clue to fingerprint the botnet

Refreshed lists of proxies

The botnet refreshes the list of proxies every hour, changing the bots for new ones.

Finding the code

After analyzing the attack traffic for several weeks and classifying the 30,000+ IP addresses used in infrastructure we have concluded the following:

  • The attacker is using several traffic generators that generate the random requests.
  • The requests are NOT generated in the edges of the botnet but in one or several coordination control servers.
  • Different attack methods are supported including GET, POST and HEAD floods
  • Requests are distributed across different pools of proxy servers that can be renewed periodically.
  • Pools of proxy servers are linked geographically. The attacker can obtain or purchase proxies for specific countries.
  • The proxy network does not support Javascript.
  • The proxies are reachable via HTTP, SOCKS4 and SOCKS5 protocols
  • The proxies used are composed of routers (Mikrotik), compromised servers (via SSH password brute force) and the TOR infrastructure.
  • The botnet is pulling lists of proxies from websites offering proxy services by means of APIs or scraping the sites or Telegram channels.
  • The attacker can scrape websites offering free proxy servers
  • The attacker is making using a private lists of proxy servers

These type of attacks are known as “Challenge Collapsar (CC)”.

After reviewing several public implementations that matched the capabilities of the botnet, we found the public code hxxps://github.com/Leeon123/CC-attack and hxxps://github.com/MHProDev/MHDDoS reproduced the attack traffic we recorded.

https://camo.githubusercontent.com/ac4239ea56ac60b06a2fc8cde65078282191a230825aa624e375b6bcc9dce90e/68747470733a2f2f692e696d6775722e636f6d2f756544686474652e706e67
MHDDOS a CC-attack fork

A modified CC-Attack

Although the code available in GitHub is able to reproduce most of the patterns of attack traffic we receive, there are some interesting differences that make us believe that the attack is run with a modified “premium version” of this code.

  • The attack launches similar random GET requests also using the Tor infrastructure but the public code does not contain this logic.
The TOR specific code is not available in the public version
  • Some headers have been removed from the original code to make it less traceable.

Headless browsers and proxy rotation

The floods are mostly originated from the extended CC-Attack python code and not real browsers but weeks after the attack started a small portion of the traffic looked different as it was able to respond to Javascript challenges. Their User-Agents also had a very distinct pattern.

User-Agents used in the Headless Browser Traffic Generator

We looked into this specific traffic and these specific headless browser versions and also noticed that the traffic was coming from several IP addresses with the following Web Page.

The IP addresses are modified Mikrotik Routers with the Copyright notice (C) ProxyRotoation

This misspelling of “ProxyRotoation” allowed us to do a clever search in Censys and to identify several more devices of this type:

One of the IP with the same banner “Proxy Rotoator” 209{.}141.60.124 is associated to online “service” Proxyrotator.com

This finding suggests that the attacker is familiar with “Web Scraping” infrastructure and has repurposed the “Proxy Networks” to conduct denial of service attacks.

Dedicated Proxies and exploited IoTs

Hundreds of IP addresses from Ukrainian provider Kyivstar PJSC (ASN 15895) have been used in the attacks. None of the IP addresses have a Proxy exposed tand that make us believe this part of the infrastructure is a “private proxy botnet” for hire.

From the hundreds of IPs from Kyivstar, we found one “Internet of Things (IoT)” device that was compromised. This device run a special computer device used for industrial control systems “PLC BMX P34”, this device was exploited to run as a private proxy.

P34 IoT known internally as “Korva”. The “S” in IoT stands for security

Timeline

The 29th of July 2021 at 5:36 AM after conducting a 1 minute attack against the home page of Karapatan, the attacker sets up a monitoring using the online service “check-host” for the specific URL https://www.karapatan.org/resources and then launches a second and long lasting attack.

After starting the second attack and not trusting the results of “check-host”, the Vietnamese IP address 123.31.174.135 and later on using a Mobilefone IP 103.199.63.236 checked if the URL was still online.

During the next two hours the attacker modified the scripts to remove any possible attack signatures and loaded the first large pool of proxies while also flooding the site via the Tor network.

During the first weeks of attacks, the Chinese and Ukrainian providers provided most of the bot addresses. The 10th of August a new large pool of addresses coming from Russia were added to the attack and the 16th of August traffic coming from Vietnam was added.

During the 16th of August 2021, the attacks intensified with the inclusion of “headless browsers” supporting Javascript and capable to bypass common anti-DDOS techniques as “captchas”. The attackers used the very same proxy network with the “headless browsers” to flood the website.

High level overview of traffic to Karapatan during the attack