An RSA key opened a Tor exit server at 04:38 UTC on 28 August 2026. It wasn’t in the authorized_keys file. Surprise?

Dan Goodin at Ars Technica ended his reporting of 333 hijacked exits on this silent key, calling it a last perplexing finding. The relay operators called it an open question on the tor-relays list.

But I looked at their own post and see an answer.

Ebury loads keys from memory. ESET documented the method in October 2017: on a backdoor connection the implant sets sshd’s AuthorizedKeysFile to /proc/self/environ and hooks open(), so the attackers’ RSA public key is read from the process environment and authorized.

The authorized_keys file is bypassed. The operators pulled the implant configuration from process memory on their own servers and printed it: AuthorizedKeysFile /proc/self/environ, UsePAM no, LogLevel QUIET, HISTFILE=/dev/null. A key that logs in with that configuration in place leaves exactly the trace we see here, an accepted login and an empty file.

So, it stands to reason, the key worked silently because Ebury was already inside sshd on Switzerland2 when the key arrived. The flow of events in UTC:

03:19	Attacker logs in to the management server with the operator password, correct first try
03:25	Ebury 1.8.3 installed on the management server
04:33	Two SSH connections to Switzerland2, dropped before authentication
04:38	Switzerland2 accepts RSA key SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk
04:38 +1s	sudo decodes base64 into perl and installs the same Ebury build on Switzerland2

The install they can see came one second after the login. The login needed trust that was already in place, so whatever granted it was there first. On the backdoor reading, the sudo at 04:38:01 was a reinstall onto a host the attacker already owned, run with the operator’s sudo password because they had it.

The operators themselves seem to arrive here as well. They give two possibilities, a line in the main sshd_config or an earlier backdoor, and then report that the main sshd_config came from the hosting provider’s VPS image and that the attacker replaced it on 30 September. Both of their possibilities say trust was established on Switzerland2 before 28 August, by someone other than the operators.

The hosting layer is where Ebury has lived for a decade. ESET’s May 2024 paper documents hosting providers whose infrastructure was compromised so that Ebury landed on the servers they rented out. ESET rented one and had Ebury within seven days. One provider lost 70,000 servers in 2023. Tor exit nodes are on ESET’s victim list. Kaba, who found the 333 exits by scanning every exit with exitmap, names the hosting company as the open theory.

Marc-Etienne Léveillé, who investigated Ebury at ESET for more than a decade, told the list that with 400,000 servers compromised since 2009 there are most likely other compromised relays still running.

Every check the operators ran on the host passed. dpkg -V passed because the packaged library stays intact and only a symlink moves. ldd on sshd passed because the implant loads through libkrb5 into sshd-session. A shell reported a clean /proc/self/maps because the implant hides from the processes it lives in. One of their review passes declared the server clean on those results. The true findings came from outside the host: the public CollecTor archive showed the exit policy had changed, process memory showed the implant, and the Tor network health team saw the policy change in the directory data before the operators saw anything on their own machines.

The password reuse is the stated root cause. It explains 03:19 and it explains 04:38:01. It has nothing to do with 04:38:00. That second belongs to a backdoor that predates the password, and the burning question now is who put it there.