{
	"id": "d09231a9-5ef6-481e-a306-b6229557f334",
	"created_at": "2026-04-06T00:21:33.907686Z",
	"updated_at": "2026-04-10T13:12:41.736706Z",
	"deleted_at": null,
	"sha1_hash": "8d893e8947e9a9a9e370c723ba5d099f34b1ee42",
	"title": "Is “KAX17” performing de-anonymization Attacks against Tor Users?",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 335772,
	"plain_text": "Is “KAX17” performing de-anonymization Attacks against Tor\r\nUsers?\r\nBy nusenu\r\nPublished: 2021-12-01 · Archived: 2026-04-05 13:30:36 UTC\r\nHashtag: #KAX17\r\nTwo years ago in December 2019, I first wrote about a particular and unusual malicious actor on the tor network.\r\nThis blog post is about how that actor expanded their visibility into the tor network during the last two years after\r\ntheir removal by the tor directory authorities in October 2019 and why this particular actor is more concerning\r\nthan the usual malicious tor relay group.\r\nThe threat landscape on the tor network motivates the second part, in which we will outline a design and proof of\r\nconcept implementation to help tor users defend themselves and significantly reduce their risk of using malicious\r\ntor relays without requiring the identification of malicious relays — a problem that has become impractical to\r\ntackle.\r\nMajor Tor Network Threat Actors\r\nTo give you a clearer picture which actor we will be focusing on in this blog post, here is a short overview of the\r\ntwo main actors we have reported about in the past. Let’s also give them code names so it easier to refer to them.\r\nActor “BTCMITM20” Profile\r\nactive since at least 2020\r\nsophistication: amateur level but persistent and large scale\r\noperated relay types: exit relays\r\n(known) concurrently running relays peak: \u003e350 relays\r\n(known) advertised bandwidth capacity peak: 40 Gbit/s\r\n(known) exit probability peak: 27%\r\nprimary motivation: financial profit (by replacing bitcoin addresses in tor exit traffic)\r\ndefenses: easy; HSTS preloading for website operators; on tor clients: ensure HTTPS is used properly.\r\npast blog posts about this actor:\r\nHow Malicious Tor Relays are Exploiting Users in 2020 (Part I)\r\nTracking One Year of Malicious Tor Exit Relay Activities (Part II)\r\nActor “KAX17” Profile\r\nhttps://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8\r\nPage 1 of 6\n\nactive since at least 2017\r\nsophistication: non-amateur level and persistent\r\nuses large amounts of servers across many (\u003e50) autonomous systems (including non-cheap cloud hosters\r\nlike Microsoft)\r\noperated relay types: mainly non-exits relays (entry guards and middle relays) and to a lesser extend tor\r\nexit relays\r\n(known) concurrently running relays peak: \u003e900 relays\r\n(known) advertised bandwidth capacity peak: 155 Gbit/s\r\n(known) probability to use KAX17 as first hop (guard) peak: 16%\r\n(known) probability to use KAX17 as second hop (middle) peak: 35%\r\nmotivation: unknown; plausible: Sybil attack; collection of tor client and/or onion service IP addresses;\r\ndeanonymization of tor users and/or onion services\r\npast blog post about KAX17:\r\nThe Growing Problem of Malicious Relays on the Tor Network\r\nWe consider it less likely that KAX17 and BTCMITM20 are the same actor, but due to some minor overlap we\r\ndid not rule out the possibility that there is some limited form of collaboration between these actors yet. The\r\nremainder of this blog post is about KAX17 only.\r\nWhat visibility into the tor network did KAX17 have during the past 3 years?\r\nThe following graph shows (known) KAX17' network fraction in % of the entire tor network for each position\r\n(first, second and last hop of a tor circuit) over the past 3 years.\r\nAfter I reported the exit relays (at the time I did not know they are part of KAX17) they got removed in October\r\n2020, but I do not believe that halted their exit operations completely. Coincidentally a new large no-name exit\r\nrelay group was born the day after their removal. That new group is not included in figure 1 because it can not be\r\nattributed to KAX17 using the same strong indicator.\r\nTo provide a worst-case snapshot, on 2020–09–08 KAX17's overall tor network visibility would allow them to de-anonymize tor users with the following probabilities:\r\nfirst hop probability (guard) : 10.34%\r\nsecond hop probability (middle): 24.33%\r\nlast hop probability (exit): 4.6%\r\nAs middle and exit relays are frequently changed the likelihood to use KAX17's relays increases with tor usage\r\nover time. We have no evidence, that they are actually performing de-anonymization attacks, but they are in a\r\nposition to do so and the fact that someone runs such a large network fraction of relays “doing things” that\r\nordinary relays can not do (intentionally vague), is enough to ring all kinds of alarm bells.\r\nGet nusenu’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nhttps://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8\r\nPage 2 of 6\n\nRemember me for faster sign in\r\nIn the course of 2020 large amounts of suspicious non-exit relays joined the network and were reported to the Tor\r\nProject, but since they no longer got removed, I sent them to the public tor-talk mailing list as their capacity\r\ncontinued to increase (2020–08–20, 2020–09–22).\r\nThe unexpected hint towards a better understanding of the mystery\r\nAt the time (2020) I had no strong linkability indicators for these large sets of non-exit relays to the KAX17 actor\r\n- that changed a few weeks ago (fall 2021), when a reader of this blog, reached out to share their notes about a\r\nsuspicious group of relays. We independently verified and reproduced their observations on a technical level.\r\nWhen put into the broader context, their hint helped to understand the bigger picture by providing strong\r\nindicators that all those relays:\r\nare in fact operated by a single entity and\r\nall of them are actually part of KAX17.\r\nWhat is special about KAX17?\r\nKAX17 is more worrisome than the usual malicious tor exit relay group, because they appear to be rather keen on\r\nhaving a large visibility into non-exit positions of the network (entry guard and middle relay). These positions are\r\nuseless for the usual malicious actor manipulating and sniffing tor exit traffic, because in these positions no\r\nplaintext traffic is available. Actors performing attacks in these non-exit positions are considered more advanced\r\nadversaries because these attacks require a higher sophistication level and are less trivial to pull off.\r\nSome parts of this story reminded me of the so called “relay early” traffic confirmation attack from back in 2014\r\nthat combined running malicious relays with active tor protocol level exploitation to de-anonymize onion services\r\n(at the time called “hidden services”) and their users, because that was one of these rare cases where you also got\r\nto see attacks involving non-exit relays. Other than that there is nothing pointing in that direction.\r\nKAX17's involvement in tor-relays policy discussions\r\nWhen looking over KAX17 relays’ metadata I repeatedly came across a particular email address. Some of\r\nKAX17's relays initially had used that email address in their ContactInfo but soon after these relays were setup the\r\nemail address got removed from their configuration. I also came across this email address on the tor-relays\r\nmailing list. Interestingly it became almost exclusively involved on the mailing list when policy proposals with\r\nregards to malicious relays were discussed or when large malicious relay groups got removed. They apparently\r\ndisliked the proposals to make their activities less effective :)\r\nSince everyone can use your email address in their relay’s ContactInfo, that information is not necessarily\r\nauthentic, but since the email address has been used on KAX17 relays long before it first appeared on the tor-relays mailing list I guess that was just poor OPSEC on their part.\r\nSelf-defense: Helping tor users help themselves\r\nIt is apparent that tor users have powerful adversaries with a lot of resources at their hands. It is a particularly\r\nuncomfortable situation to be in, knowing some actor has been running large fractions of the tor network for years\r\nhttps://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8\r\nPage 3 of 6\n\nand will continue to do so. It is also clear that we can not detect— let alone get removed — even such large scale\r\nrelay groups in a timely manner. KAX17’s operations likely got severely degraded when the tor directory\r\nauthorities took actions against them in November 2021, but they already started to restore their foothold, like\r\nthey did after their first removal in October 2019, so we will need some more sustainable solutions when dealing\r\nwith malicious relays.\r\nIn the past I have always been reluctant to make tor client configuration changes that affect path selection because\r\nit makes a tor client theoretically stand out, but in the light of the tor network’s threat landscape I consider it a\r\nreasonable (for some threat model even a necessary) act of self-defense to stop using untrusted relays for certain\r\npath positions to reduce the risk of de-anonymization and other types of attacks — even if that is a non-default\r\nconfiguration.\r\nTo achieve that goal tor clients would need to:\r\n(1) configure trusted operators or learn about them via so called trust anchors\r\n(2) automatically enumerate all relays of trusted operators\r\n(3) automatically configure the tor client to use only trusted relays for certain positions like entry guard and/or exit\r\nrelay\r\nThe design allows tor users to assigns trust at the operator level and inherits that trust to all the relays an operator\r\nmanages. This should ensure scalability and be less fragile to changes like when new relays get added or replaced.\r\nNon-spoofable operator identifiers\r\nHow do we tackle (2)? The tor network has no identifiers for relay operators. There is a relay’s ContactInfo string,\r\nbut using that without any verification scheme is not safe and has been exploited by malicious operators in the\r\npast. So we need some operator identifiers that can not be spoofed arbitrarily by an adversary. Luckily we are not\r\nunprepared for that. In 2020 I wrote a specification (CIISS) that allows tor relay operators to link their relays to\r\ntheir domain/hostname in a verifiable way. That is accomplished using a simple 2-way link from the relay to a\r\ndomain and from the domain back to a relay. In practice an operator has to perform two simple steps to link her\r\nrelay to her domain in a non-spoofable way according to the specification:\r\n1. add\r\nurl:example.com proof:uri-rsa ciissversion:2\r\nto her relay’s ContactInfo\r\n2. publish the relay’s fingerprint at the IANA registered well-known URI:\r\nhttps://example.com/.well-known/tor-relay/rsa-fingerprint.txt\r\n(or create a DNS TXT record).\r\nIn the past few months the proven domain has already been widely implemented by most large exit operators of\r\nthe tor relay community and currently over 50% of the tor network’s exit capacity is covered (more is better):\r\nPress enter or click to view image in full size\r\nhttps://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8\r\nPage 4 of 6\n\nFigure 2: \u003e50% of the tor network’s exit capacity has proven their domain according to the CIISS\r\nspecification. Source: nusenu (an interactive version of the graph can be found at OrNetStats)\r\nThis provides tor users with non-spoofable automatically verifiable operator identifiers they can assign trust to. It\r\nis important to stress the point that proven domains are not implicitly trusted, malicious groups can also proof\r\ntheir domain. It is only the first step, an identifier that users can choose to trust. The adoption of the proven\r\noperator domain for guard relays is significantly lower (~10% guard probability), until that fraction increases\r\nusers could configure a trusted relay as a bridge to reduce their chance of using malicious guards.\r\nTrusting operator domains\r\nTrust in this context means that a relay operators is believed to operate relays without malicious intent. The details\r\nof publishing and consuming trust information are laid out in this specification draft: A Simple Web of Trust for\r\nTor Relay Operator IDs. It allows the (optional) dynamic discovery of trusted operators starting from a trust\r\nanchor, but it also supports stricter manual only trust assignments (without recursive discovery)— it is up to the\r\nuser to decide.\r\nProof of concept implementation\r\nWe’ve implemented a quick and dirty proof of concept of the steps outlined above and are publishing it with this\r\nblog post. It is not meant for general use by end-users.\r\nhttps://github.com/nusenu/trustor-poc\r\nIt is implemented as a python script that talks to the local tor client via its control port/socket, reads the local file\r\nwith a list of trusted operator domains, verifies relay/domain proofs (via tor) and configures the tor client to use\r\nhttps://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8\r\nPage 5 of 6\n\nexit relays run by trusted operators only. The list of trusted operators is defined by the user.\r\nWe would like to implement an actual serious implementation and we might have an update on that within the\r\nnext months.\r\nSummary\r\nA mysterious actor which we gave the code-name KAX17 has been running large fractions of the tor\r\nnetwork since 2017, despite multiple attempts to remove them from the network during the past years.\r\nKAX17 has been running relays in all positions of a tor circuit (guard, middle and exit) across many\r\nautonomous systems putting them in a position to de-anonymize some tor users.\r\nTheir actions and motives are not well understood.\r\nWe found strong indicators that a KAX17 linked email address got involved in tor-relays mailing list\r\ndiscussions related to fighting malicious relays.\r\nDetecting and removing malicious tor relays from the network has become an impractical problem to\r\nsolve.\r\nWe presented a design and proof of concept implementation towards better self-defense options for tor\r\nclients to reduce their risk from malicious relays without requiring their detection.\r\nMost of the tor network’s exit capacity (\u003e50%) supports that design already. More guard relays adopting\r\nthe proven domain are needed (currently at around 10%).\r\nAcknowledgements\r\nI’d like to thank the person who provided crucial input towards a better understanding KAX17's relays. The\r\nperson asked to remain anonymous.\r\nAppendix\r\nThe following graph shows KAX17's network capacity (at least the one we know about). The detection method\r\nhas certainly false-negatives (there are relays we did not attribute to them).\r\nSource: https://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8\r\nhttps://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8"
	],
	"report_names": [
		"is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8"
	],
	"threat_actors": [
		{
			"id": "0ca8aa42-5713-4277-b265-456f1601eef4",
			"created_at": "2023-11-17T02:00:07.585347Z",
			"updated_at": "2026-04-10T02:00:03.452848Z",
			"deleted_at": null,
			"main_name": "KAX17",
			"aliases": [],
			"source_name": "MISPGALAXY:KAX17",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434893,
	"ts_updated_at": 1775826761,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8d893e8947e9a9a9e370c723ba5d099f34b1ee42.pdf",
		"text": "https://archive.orkl.eu/8d893e8947e9a9a9e370c723ba5d099f34b1ee42.txt",
		"img": "https://archive.orkl.eu/8d893e8947e9a9a9e370c723ba5d099f34b1ee42.jpg"
	}
}