On October 8, 2024, an IFTAS Connect member observed one of the first spam posts from a network attack conducted by what appeared to be a reuse of the same “nuke” script we saw earlier this year in February, a simple but effective tool to create new accounts in bulk, and use those new accounts to deliver unsolicited messages in an infinite loop.
Various reports highlighted the activities of two parties engaged in an online argument, both sides of which appear to be young scripters based in Japan, with the intent of causing trouble for the other party.
In short, a Discord bot was created that can automate the creation of a new account on an open registration service and then repeatedly spam a new post with ten direct mentions, causing notifications to pop up for hundreds of thousands of Fediverse users, which -thanks to network bridges and unmanaged group functionality – included Bluesky accounts and Friendica groups that automatically boost the posts to potentially thousands more individuals.
The bulk of the October spam originated from predominantly Misskey servers, although other services including Mastodon were also compromised. Misskey is an ActivityPub-enabled microblogging service popular in Japan.
Within an hour of observing the first spam messages, the IFTAS Connect community had created a shared spreadsheet of affected servers. In the previous spam wave, much effort was spent on blocking the increasing number of servers delivering spam, and finding ways to identify and delete spam messages. However, due to the large number of independently operated Fediverse servers, getting this information out in a manner that was helpful to self-hosted and managed-hosted servers, without simply handing the mitigation to the spammers themselves to adapt their attack, proved to be difficult.
We saw fewer than a hundred servers involved in the spam wave. With potentially 30,000 servers, relays, groups and bridges to alert, the community decided to instead try to alert the small number of impacted service providers.
An alert was drafted in English, translated into Japanese and Chinese to help the server operators understand the issue being described, and research began to find contact information for the servers being tracked.
Within the hour, server operators began responding to the alerts and closing down registration, deleting the relevant accounts, and wiping the spam content. After 24 hours almost all servers had responded, leaving only ten still open and spamming the network. At this point, the Social Web ISAC issued an alert to limit content from those ten servers, and began filing abuse reports with the remainder’s web hosts and content delivery networks.
The community tracked outbound emails and messages, and updated the spreadsheet as servers responded and mitigated the issue. If no response was observed after 12 hours, emails were then sent using the relevant web host abuse report functions, which send an email directly to the service operator from their web host or domain registrar.
This mitigated several more servers, bringing the list of servers that were entirely unmonitored “ghost ships” to six. At this point, IFTAS decided to add the remaining servers to the IFTAS Do Not Interact list, which in turn updated users of FediCheck to automatically block those servers.
Overall, the community mitigated almost all of the spam within 48 hours, proving that despite the core issue of decentralised networks not having a network-wide view of the Fediverse, opportunities exist to work together and combat the same issues inherent to all social media platforms.
In response to the February attack, Mastodon added a feature to close new registrations on a service that appears to be unmanaged, which likely helped mitigate this second attack to some degree. Nonetheless, in an ecosystem that allows open federation and open registration by default, we will need better spam blocking tools, and better account creation review options to better guard against this kind of attack in the future. We are aware of several projects underway to provide various defenses against spam, as well as the Fediverse Auxiliary Service Provider Specifications project that should enable third-parties to offer plug-in style help for service providers.
Still, we couldn’t be prouder of the IFTAS Connect community and all the folks who gave their personal time and energy for the good of all. And if you’d like to get alerts from IFTAS consider following https://mastodon.iftas.org/@sw_isac or subscribing to our email alert service.