A hacked creator account is not only a login problem. It is an audience safety incident: an attacker can use years of earned trust to post scam links, impersonate the creator in private messages, remove collaborators, or change recovery details. Resetting the password matters, but it does not prove fans are safe or that every connected account is clean.
This runbook separates containment, identity recovery, fan communication, access cleanup, and verification. It is for creators and small teams running a channel, membership, or community across several services. Follow the steps in order instead of improvising from a compromised account.
Treat the compromise as two linked incidents. Identity recovery means regaining control of the email, channel, and community accounts. Audience protection means stopping fraudulent posts, giving fans one trustworthy update route, and correcting harmful instructions already sent.
A team that works only on identity recovery can leave fans following an attacker for hours. A team that posts warnings without securing the root account can have those warnings deleted or contradicted. If two trusted people are available, give each track an owner. A creator working alone alternates between the tracks using the sequence below.
Before changing anything, write down the first known bad event, the affected accounts, and what fans may have seen. Save screenshots of public posts, account notifications, changed settings, and suspicious messages. Do not forward live malicious links to moderators or fans; record the visible text and the destination domain without encouraging anyone to open it.
Choose an update route that does not depend on the compromised identity: the creator’s website, a mailing list controlled through a separate account, or another verified social profile whose session and recovery email are known to be safe. The first notice covers five things:
Do not claim the incident is resolved because one password changed. Say what is known and what is still under review, and keep every later update on the same page or thread so fans never have to weigh competing announcements.
For a multi-host show, name the person authorized to publish recovery updates. Other hosts can link to that statement, but they should not create separate timelines or speculate about the attacker. One source reduces the chance that an outdated instruction keeps circulating.
Start with the email or identity provider that controls password resets. Google’s compromised-account checklist directs users to review security events, signed-in devices, recovery information, and unfamiliar account changes. The order matters: recovering a channel while its email is still exposed gives the attacker another way back in.
Use a device you trust. If the usual computer shows unexpected extensions, remote-control software, or repeated sign-in prompts, move recovery to another device and have the original inspected before using it for admin access again. Then, for each root account:
A password reset is one control, not the finish line. Recovery settings, active sessions, delegated access, and mail rules can all preserve an attacker’s path after the password changes.
Once the root identity is under control, use each platform’s own recovery surface. YouTube publishes a dedicated hacked-channel recovery guide; follow it instead of relying on people who contact the creator privately claiming they can restore the channel. Then inventory every surface connected to the creator’s public identity:
Check public content before deleting it. Preserve enough evidence to know what fans received, then remove or label fraudulent posts through the recovered platform. If a malicious livestream or giveaway is still running, containment comes before perfect documentation.
Discord keeps a canonical support article for compromised accounts. Automated access to that page can be blocked, so open the official support URL directly in a normal browser during a Discord incident, and never substitute a recovery form sent by an unknown user.
Creators share work with editors, producers, co-hosts, agencies, and volunteer moderators. During recovery, do not stop at asking whether each person seems trustworthy; check what every account can actually do.
YouTube’s channel permissions documentation describes role-based access that works without sharing the primary account. Review the current owner and manager list against a written roster, and remove unknown accounts, expired contractors, duplicate access, and roles broader than the person’s current job. Apply the same method across community tools:
Do not restore every integration at once. Bring back publishing, moderation, and member support first, and hold convenience automations until the team can verify their owner, permissions, and expected behavior.
Shared passwords make the audit harder, because the team cannot tell which person or device used the credential. Replace shared logins with named roles wherever the service supports them. If a service needs one login, limit it to the smallest possible group and document who holds the recovery method.
The first notice tells fans to pause. The recovery update tells them exactly what happened to their interactions, by answering six questions:
Do not copy malicious URLs into the announcement. Describe the fraudulent offer or message in plain language and tell fans how to recognize the legitimate domain. If the attacker asked for money, say so clearly. If the team does not yet know whether member information was exposed, say that too, and give a time for the next update.
Moderators need a prepared answer for repeat questions: a short approved statement and one escalation route. They remove active scam links, preserve reports, and point members to the canonical update. They should not diagnose individual devices, promise refunds, or announce facts the incident owner has not verified.
Work through the whole checklist before changing the public status to recovered.
Whoever performed the recovery can miss a setting, because they remember what they meant to change. Have another trusted operator inspect the final state against the roster and the checklist.
Use a clean test account to see what an ordinary fan sees: the channel description, recent posts, pinned announcements, invitation links, membership roles, direct-message guidance, and support route. Confirm that old scam links are gone or clearly marked and that the canonical notice is easy to find.
Then test privileged access. Ask each remaining collaborator to sign in with their own account and perform only the actions their role requires, and confirm that removed accounts cannot publish, moderate, change billing, or reconnect an app.
Recovery is complete when five things are true: the identity is controlled, fan-facing harm is contained, privileged access matches the current roster, essential workflows pass a test, and the team has published a final verified update. Until then, keep the incident open.
Create an off-platform incident page now, before any account is compromised. Put its owner, URL, backup access method, and first-warning template in the team’s operating notes, so fans have one place to trust when the normal channel cannot be trusted.