Tracking One Year of Malicious Tor Exit Relay Activities (Part II)

Figure 1: Malicious Tor exit fraction (measured in % of the entire available Tor network exit capacity) over time by this particular malicious entity between July 2020 and April 2021. Peak value: The attacker did manage approx. 27.5% of the Tor networks exit capacity on 2021–02–02. Graph by nusenu (raw data source: Tor Project/onionoo)
Figure 2: 2020–08–16: ContactInfo “exitrelays@protonmail.com” tor relays get caught doing MITM attacks. They got removed from the tor network on 2020–08–17. Source: https://twitter.com/leak_ix/status/1295030849663053825
Figure 3: 2020–08–18: ContactInfo “kleinendorstwiebe AT gmail DOT com” tor relays are confirmed as malicious. They got removed on 2020–08–19. Source: https://twitter.com/notdan/status/1295813432843829251

New negative records

  • on 2020–10–30 the malicious entity operated more than 26% of the tor network’s exit relay capacity
  • and on 2021–02–02 they managed more than 27% of tor’s exit relay capacity. This is the largest malicious tor exit fraction I’ve ever observed by a single actor.
Figure 4: Confirmed malicious Tor exit capacity (measured in % of the entire available Tor exit capacity) between 2020–06–21 and 2020–11–01 by ContactInfo (stacked). Only actual malicious relays are included (for example not all relays using ContactInfo CypherpunkLabs were malicious. Graph by nusenu (raw data source: Tor Project/onionoo)

New malicious trends

  • large exit fraction without any relay ContactInfo: This actor is increasingly adding malicious tor relays without any ContactInfo (this is the largest fraction, shown in red in Figure 4). Once a malicious tor exit relay is detected, all other relays using the same ContactInfo are easily found and removed, this is not an issue for them if they do not have a ContactInfo at all. Figure 5 shows the overall tor exit fraction that had no ContactInfo set (blue) and what part of it was malicious (red). We can obviously not rule out that even more of them are malicious and we failed to detect them. The vast majority of exit capacity without ContactInfo was malicious between October 2020 and March 2021.
Figure 5: What fraction of exit relays not having any relay ContactInfo was malicious? (You can ignore the straight red line above “Apr 1, 2021”, that is just a interpolation) Graph by nusenu (raw data source: Tor Project/onionoo)
  • impersonation attacks against other operators: This is not directly visible because the list of contacts was too large to include in Figure 4, but the malicious actor also started to impersonate other operators to hide malicious relays by using their ContactInfos. In one case they used CypherPunkLabs’ ContactInfo. (Side note: To avoid false positives Figure 4 was generated by identifying malicious relays by fingerprint and not by searching for the ContactInfos used by CypherPunkLabs.)

Reaction time matters

Figure 6: Malicious exits using ContactInfo “supportanonymity.club” and “coronamitmdisease2019@hotmail.com” got reported when their exit fraction was at 0.57%. Graph by nusenu (raw data source: Tor Project/onionoo)
Figure 7: Malicious Tor exit relays reported on 2020–08–20 and found on the tor network again in April 2021 (removed on 2021–04–27). Graph by nusenu (raw data source: Tor Project/onionoo)

New adversarial tactics

Unexpected Luck with WHOIS data

Source: twitter
Group #7: other
4E6C7297F16523A236EE1A2EE23AF54ABEF15490
55D490E9E440DD4458F16ABCDD79F48396D55EA9
78F699D58F3353AB6C4CE39E3BD96CE87439753A
B1896E58FDEB5627B6B8334E6ABD42767AB8B0D9
Figure 8: WHOIS records contain the email address “andrejgvozdev55@gmail.com” as abuse contact for the small IP block used by malicious exit relays. Source: RIPE Database (archived version)
Figure 9: Inverse RIPE DB lookup for abuse handle finds an additional IP block also containing malicious exit relays. Source: RIPE database (2021–01–04).
  • andrejgvozdev55@gmail.com tested the bad-relays team by reporting the CypherPunkLabs relays to see if they get removed for improper MyFamily configuration. This information is crucial for them because an attacker can not establish a mutual MyFamily configuration with the victim they impersonate. A few weeks later malicious relays appeared using the CypherPunkLabs ContactInfo (CypherPunkLabs was not the only relay group they reported..).
  • andrejgvozdev55@gmail.com shows up as abuse-contact in WHOIS for two small IP blocks that contain malicious tor exit relays.
  • One of these exit relays in these IP blocks used a confirmed malicious ContactInfo previously identified (“fbirelays@protonmail.com”).
The abuse-contact information for the IP addresses used by malicious tor exit relays. Source: RIPE database (archived version)
Figure 10/11: The abuse-contact address of the IP range hosting malicious tor exit relays (185.32.222.166–185.32.222.173) is allegedly located at this building in Moscow according to RIPE database records. Image Source: yandex.com
Figure 12/13: The alleged abuse-contact address used by the malicious exit relay operator can also be found on booking.com. According to moscowmap.ru the building has 108 apartments and 9 floors. That makes 12 apartments per floor, so apart. 12 (“kv12”) could theoretically be on the ground floor. Image Source: Google Maps / Booking.com (2, 3) (Zvenigorodsko(y)e shosse 13 / Звенигородское шоссе 13)

>1 000 new exit relays in early May 2021

Countermeasures

  • The scale of the detected attacks has never been as large as in 2021.
  • Non-central options should only be considered after trying (and failing) to achieve protections at the tor directory authority level because they will never reach all users.
  • Tor client configuration changes should generally be avoided to avoid splitting the anonymity set and only be used as an option of last resort (or as a method to vote with your feed as a tor user).
  • Non-default tor client configurations make network wide load balancing harder.
  • It requires more effort.

HTTPS-Only Browser Mode

Solving the fake ContactInfo impersonation attacks

Visualizing known and unknown exit fraction

Figure 14: Likely non-malicious exit fraction over time graph allows to draw indirect conclusions about (large scale) malicious activities. Graph by nusenu (raw data source: Tor Project/onionoo)
Figure 15: Contributed exit fraction by (non-spoofable) operator domain. Graph by nusenu

Summary

  • The entity attacking tor users, originally disclosed in August 2020, is actively exploiting tor users since over a year and expanded the scale of their attacks to a new record level (>27% of the tor network’s exit capacity has been under their control on 2021–02–02).
  • The average exit fraction this entity controlled was above 14% throughout the past 12 months (measured between 2020–04–24 and 2021–04–26).
  • The malicious actor actively reported non-malicious but poorly configured relays to the Tor Project’s bad-relays mailing list to find viable victims to use for operator impersonation attacks.
  • Most of the malicious tor exit capacity did not have any relay ContactInfo. Throughout the last 6 months the majority of tor exit capacity without ContactInfo was malicious.
  • The attacker primarily uses servers at the hoster OVH.
  • In early May 2021 the attacker attempted to add over 1 000 exit relays to the tor network.
  • The attacker (or one of them) likely uses the Russian language interface of gmail.com.
  • As of 2021–05–08 I estimate their exit fraction between 4-6% of the tor network’s exit capacity.
  • A new non-spoofable ContactInfo field for tor relays has been specified and has been adopted by over 20% of the network’s exit capacity so far.
  • OrNetStats has been extended to include two new graphs: exit fraction by non-spoofable ContactInfo domain and graphs showing exit fraction without ContactInfo

Additional Background / Disclosure

Want to support this type of research?

Appendix (bonus material)

Fake profiles for fake relays: relaystor.xyz

  • (rudimentary) website
  • twitter profiles (created 2012 and 2014)
  • telegram channel
  • BTC donation address
Source: https://relaystor.xyz/about/ (archived version: https://web.archive.org/web/20210411231629/https://relaystor.xyz/about/ )
Source: https://twitter.com/temporaca86
Source: https://twitter.com/n64alys184
Source: https://unsplash.com/s/photos/man
Source: https://unsplash.com/s/photos/man
Donation bitcoin address shown on the rudimentary relaystor.xyz website. This address has 0 transactions: https://www.blockchain.com/btc/address/bc1qcatkzga54sz3eyzwlr4hzmtfd37rgpenqp62yz (source: https://relaystor.xyz/donate/)

Timeline for events related to andrejgvozdev55@gmail.com (not comprehensive)

  • 2020–09–03 Андрей Гвоздев andrejgvozdev55@gmail.com reports the undeclared relay group of CypherPunkLabs to the bad-relays mailing list. (10 days before that I did send an email to tor-relays about this — which might gave them this idea in the first place)
  • 2020–09–03 I responded by letting them know that the CypherPunkLabs relay group is on our radar and that we were in contact with them.
  • 2020–09–07 first malicious exit at SOFTplus Entwicklungen GmbH gets added (185.32.222.167) — no ContactInfo given. The abuse contact (RIPE database) later points to andrejgvozdev55@gmail.com
  • 2020–09–15 first RIPE DB entries related to andrejgvozdev55@gmail.com are created
  • 2020–09–21 andrejgvozdev55@gmail.com’s first mailing list posting on the tor-relays mailing list
  • 2020–09–26 impersonation: first malicious exit relays using CypherPunkLabs as contact appear (relay fingerprint: 1EC0CCAFA8ABD5470B062AF470EAC97DD069C655)
  • 2020–10–31 a large fraction of malicious exit relays get removed by tor directory authorities
  • 2020–11–06–2020–12–16: more tor exit relays get added in the two identified IP blocks located in AS51395 (Datasource AG) and at other known hosters (OVH, more OVH, 2)
  • 2020–12–31 a new relay using a previously confirmed and known malicious ContactInfo (“fbirelays@protonmail.com” — see Part I) appears on one of the known IP block in AS51395 (91.192.103.35) with abuse contact pointing to “andrejgvozdev55@gmail.com
  • 2021–01–16 ContactInfo (“fbirelays@protonmail.com”) and nickname is removed from that relay (using this known malicious ContactInfo was probably unintentional)
  • 2021–01–18 I reached out to andrejgvozdev55@gmail.com using a random email address, but they didn’t want to disclose which tor relays they run.
  • 2021–02–04 malicious tor exit relays removal event: at OVH (2, 3)
  • 2021–02–18 malicious tor exit relays removal event at multiple hosters (Amarutu Tech., OVH, Frantech, …)
  • 2021–02–22: 52 fake CypherpunkLabs exit relays get added again (tweet by CypherPunkLabs)
  • 2021–03–04 malicious tor exit relays removal event at OVH
  • 2021–03–14 malicious tor exit relays removal event: this is the last seen date for many malicious tor exit relays at AS51395, Datasource AG and a few other ASes (Amarutu Tech, Liteserver Holding, …).
  • 2021–04–08 23 new tor exit relays using contactInfo “andrejgvozdev55(at)gmail(dot)com [tor-relay.co]” join the tor network
  • 2021–04–10 previously identified malicious exit relays (reported to the Tor Project in August 2020) join the Tor network again. (removed on 2021–04–27)
  • 2021–04–12: Last seen date for the relays using contactInfo “andrejgvozdev55(at)gmail(dot)com [tor-relay.co]”;
    https://lists.torproject.org/pipermail/tor-relays/2021-April/019591.html

Appendix II

Timeseries graph showing the new malicious groups getting added immediately after a removal event, which makes them linkable. Graph by nusenu (raw data source: https://metrics.torproject.org/onionoo.html)
  • A: malicious exit group with contact “kleinendorstwiebe AT gmail DOT com” gets kicked→”cockcockcockcock(at)cock(dot)li” relays become exit relays (previously non-exits)
  • B: malicious exit group with contact “cockcockcockcock(at)cock(dot)li” gets kicked → “exit_abuse@posteo.net” relays get added
  • C: exit group with contact “BlackHatsMatter@protonmail.com” gets kicked→”hgonxhe51@gmail.com” relays get added

Appendix III

--

--

--

Tor, Routing Security and DNS Privacy related Topics. https://nusenu.github.io

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
nusenu

nusenu

Tor, Routing Security and DNS Privacy related Topics. https://nusenu.github.io

More from Medium

LiAise — Artificial Intelligence Camera Application for deaf and hard of hearing people…

Scalable Relayer Infrastructure for Blockchain Transactions.

How bots evade the most common AI & ML-driven web protections

NFT marketplace LooksRare competes with Opensea | Tokenview