The latest FBI and CISA update on Russian intelligence-linked phishing campaigns is a reminder that secure messaging apps can still be undermined when attackers persuade users to hand over account recovery material. The new warning says operators targeting Signal accounts are no longer only asking for SMS codes, PINs, or linked-device approvals. They are also trying to obtain the Signal Backup Recovery Key, a credential that can unlock a victim’s backed-up message history and support account takeover.
For organizations with journalists, government personnel, defense-related teams, executives, political staff, or Ukraine-focused operations, this is not a theoretical risk. The reported targeting centers on people of high intelligence value, and the technique is practical because it abuses a legitimate backup feature rather than breaking Signal encryption.
What changed in the phishing campaign
The updated advisory, covered by The Hacker News, attributes the activity to Russian Intelligence Services groups and references public tracking names UNC5792 and UNC4221. Earlier waves of activity focused on well-known account takeover paths: convincing users to provide SMS verification codes, account PINs, or to click deceptive group-invite links that linked an attacker-controlled device to the victim’s account.
The newer tactic is more damaging for message confidentiality. Attackers posing as Signal support reportedly guide the target through enabling Signal backups, viewing the Backup Recovery Key, and pasting that key back into the conversation. Once the attacker has it, they can restore the victim’s backup and access private and group message history contained in that backup. The warning also notes an important persistence problem: the old key may remain useful against the same phone number until the user generates a new key.
That makes this campaign different from ordinary one-time code theft. A stolen login code may provide a brief takeover window. A stolen backup recovery key can expose historical communications and may continue to create risk until rotated.
Why this does not mean Signal encryption is broken
The most important technical distinction is that the reported campaign is social engineering, not a cryptographic break. End-to-end encryption can protect messages in transit and on service infrastructure, but it cannot stop a user from being tricked into giving an attacker a recovery secret or authorizing a malicious device.
This pattern is common in modern targeting of secure communications. Attackers increasingly avoid hardened encryption and instead attack the surrounding account lifecycle: registration codes, recovery flows, device-linking features, cloud backups, help-desk workflows, and user trust. In this case, the attacker’s goal is to make the victim treat a sensitive recovery key like a routine support code.
The defensive lesson is straightforward: recovery keys, backup keys, one-time passwords, account PINs, and device-linking confirmations are secrets. Support teams, colleagues, administrators, and messaging platforms should not ask users to paste them into chats.
Immediate actions for Signal users
Anyone who may have shared a Signal Backup Recovery Key should treat the account and message backup as compromised. The practical response is to generate a new recovery key in Signal settings, which invalidates the previous key for future backup downloads. That step cannot undo message history already restored by an attacker, but it can reduce continued exposure.
Users should also review linked devices and remove anything unfamiliar. Because previous campaigns abused linked-device workflows, this check is important even if the user does not remember sharing a recovery key. If there is any doubt, assume the account may have been accessed and move sensitive conversations to a newly verified channel.
For high-risk users, verify safety numbers with key contacts again, preferably through an out-of-band method such as an in-person check, a known phone call, or an existing trusted channel. Be especially cautious with urgent messages that claim a backup problem, mandatory security rollout, data recovery issue, or account protection deadline.
What security teams should do
Organizations that support high-risk users should turn this into a concrete advisory, not just a news alert. A short internal notice should explain that Signal Backup Recovery Keys must never be shared, screenshots of recovery screens should not be sent to anyone, and “support” messages inside Signal should be treated as suspicious unless verified independently.
Security teams should also update phishing training examples. Many users understand that SMS codes are sensitive, but fewer recognize a backup recovery key as equally sensitive. Training should show the difference between a legitimate local settings action and a request to transmit a secret to another person.
For incident response, add questions about secure messaging account recovery to intake procedures. If a targeted employee reports suspicious Signal messages, responders should ask whether they shared a recovery key, enabled backups at someone else’s instruction, entered a PIN, clicked a group invite, or approved a linked device. Those details determine whether the response is simple user education, account hardening, or a broader compromise investigation.
Red flags to watch for
The strongest warning sign is any message that asks a user to reveal, paste, photograph, or forward a recovery key. Other suspicious indicators include messages claiming to be from Signal support, urgent warnings about message loss, mandatory two-factor enrollment prompts delivered through chat, unexpected group invitations, and instructions that walk the user through account settings.
Legitimate security workflows should minimize secret exposure. If a process requires a user to disclose a recovery key to another person, it should be considered hostile until proven otherwise.
Bottom line
This campaign works because it targets the human side of secure communications. Signal’s encryption may remain intact, but attackers can still gain access if they obtain the secrets that control backups and account recovery. The right response is to treat recovery keys with the same sensitivity as passwords, rotate any key that may have been exposed, review linked devices, and train high-risk users to verify support claims through trusted channels before taking action.
Source: The Hacker News