Post by @admin@mastodon.bida.im

Kierkethumbs up convincingly

@Kierkegaanks@beige.party 2 hr. ago

@admin that reminds me to make a telegram filter

Pwassonchat the enby catboy

@pwassonchat@eldritch.cafe 23 hr. ago

@Sylvhem Je viens de voir passer ça, j'y connais rien mais tu penses que ça peut être la cause des trucs finlandais bizarres de l'autre jour ?
@admin

ッ p o n d o l o

@pondolo@bologna.one yesterday

@admin

Sono arrivati anche qua
nell' istanza Bologna One...
Ieri pomeriggio per la precisione.

Pensavo fosse un caso isolato o solo diretto alla nostra istanza...

Grazie per l' informazione
🙏

admin - mastodon.bida.im

@admin@mastodon.bida.im yesterday

No server was hacked. The attacker uses email+password combos leaked from OTHER websites (credential stuffing): if a user reused the same password on their fediverse account, the bot logs in with valid credentials on the first try. No bruteforce, no password reset emails, nothing suspicious in the HTTP logs — just clean logins.

HOW WE FOUND THE COMPROMISED ACCOUNTS

Every malicious login on our instance shared the same signature: user agent "Go-http-client/1.1". Mastodon 4.x records all authentication events in the login_activities table, so from the rails console (docker exec -it mastodon-web-1 bin/rails c):

check a single account's login history

u = Account.find_local('username').user
LoginActivity.where(user: u).order(created_at: :desc).limit(10).map { |l| [l.created_at, l.authentication_method, l.success, l.user_agent] }

admin - mastodon.bida.im

@admin@mastodon.bida.im yesterday

No server was hacked. The attacker uses email+password combos leaked from OTHER websites (credential stuffing): if a user reused the same password on their fediverse account, the bot logs in with valid credentials on the first try. No bruteforce, no password reset emails, nothing suspicious in the HTTP logs — just clean logins.

HOW WE FOUND THE COMPROMISED ACCOUNTS

Every malicious login on our instance shared the same signature: user agent "Go-http-client/1.1". Mastodon 4.x records all authentication events in the login_activities table, so from the rails console (docker exec -it mastodon-web-1 bin/rails c):

check a single account's login history

u = Account.find_local('username').user
LoginActivity.where(user: u).order(created_at: :desc).limit(10).map { |l| [l.created_at, l.authentication_method, l.success, l.user_agent] }

admin - mastodon.bida.im

@admin@mastodon.bida.im yesterday

list ALL accounts the bot logged into, including ones that hadn't spammed yet

compromised = LoginActivity.where(user_agent: "Go-http-client/1.1", success: true).includes(user: :account).map { |l| l.user }.uniq
puts compromised.map { |u| u.account.username }.sort.join("\n")

Note: the list contains two populations — real users whose passwords were leaked, and spam accounts registered by the attacker. Creation dates tell them apart:

compromised.sort_by(&:created_at).each { |u| puts "#{u.created_at.to_date} #{u.account.username}" }

HOW WE LOCKED THEM DOWN

We chose to disable accounts (reversible) rather than mass-reset passwords — plus killing active sessions and oauth tokens so the bot gets kicked out immediately:

compromised.each do |user|
user.disable!
user.session_activations.destroy_all

admin - mastodon.bida.im

@admin@mastodon.bida.im yesterday

list ALL accounts the bot logged into, including ones that hadn't spammed yet

compromised = LoginActivity.where(user_agent: "Go-http-client/1.1", success: true).includes(user: :account).map { |l| l.user }.uniq
puts compromised.map { |u| u.account.username }.sort.join("\n")

Note: the list contains two populations — real users whose passwords were leaked, and spam accounts registered by the attacker. Creation dates tell them apart:

compromised.sort_by(&:created_at).each { |u| puts "#{u.created_at.to_date} #{u.account.username}" }

HOW WE LOCKED THEM DOWN

We chose to disable accounts (reversible) rather than mass-reset passwords — plus killing active sessions and oauth tokens so the bot gets kicked out immediately:

compromised.each do |user|
user.disable!
user.session_activations.destroy_all

admin - mastodon.bida.im

@admin@mastodon.bida.im yesterday

Doorkeeper::AccessToken.where(resource_owner_id: user.id).update_all(revoked_at: Time.now.utc)
end

The attacker's own spam accounts were then suspended from the admin panel.

SPAM CLEANUP

Via RemovalWorker, so deletions federate to remote instances (a plain destroy_all would only delete locally):

Status.where("text LIKE ?", "%SPAM_STRING%").find_each do |s|
RemovalWorker.perform_async(s.id, { 'immediate' => true })
end

RESTORING REAL USERS

Each one gets a fresh random password (killing the leaked one) before re-enabling, and a reset email to get back in:

def restore_account(username)
user = Account.find_local(username).user
user.update!(password: SecureRandom.hex(24))
user.enable!
user.send_reset_password_instructions
end

admin - mastodon.bida.im

@admin@mastodon.bida.im yesterday

IF YOUR BIDA ACCOUNT WAS DISABLED: your posts, followers and data are intact. Contact us at info@bida.im and we'll restore your access.

WHAT EVERYONE SHOULD DO, ON EVERY INSTANCE: use a unique password per service (password manager!), and enable 2FA (Settings > Account > Two-factor Authentication) — it's the one thing that makes stolen passwords useless. Check https://haveibeenpwned.com to see if your email is in known leaks.

FELLOW ADMINS: since the campaign is still ongoing, check your login_activities now, even if you haven't seen spam yet — the bot collects access silently before using it. The user agent may differ on your instance: look for unusual patterns (automated UAs like Go/python libraries, rapid logins across many accounts). Reach out if you want to compare notes.

Bida Collective
:antifa: