Admin Accounts as Privileged Identities: Threat Modelling WhatsApp Group Takeover

The identity problem behind a chat group

Treat a WhatsApp group the way you would treat any shared resource in your infrastructure. It has an access control list (members), a set of privileged principals (admins), a configuration surface (who can edit info, add people, share the invite link, approve joins) and no central identity provider. Each admin is a phone number, and authentication to that number is bound to a one-time registration code delivered over SMS or voice.

That design means the security of a group with hundreds of members is reduced to the weakest admin endpoint. If one admin hands over a six-digit code to a caller pretending to be a bank or a shop, the attacker does not exploit a vulnerability. They complete a legitimate registration flow on hardware they control, and the platform behaves exactly as specified.

The report by Ivan Schroll maps this chain using institutional sources from Brazil (FEBRABAN, the civil police of São Paulo and Mato Grosso, MPDFT) and the WhatsApp Help Center. Below is the part most useful to engineers.

Attack chain, step by step

Target selection. The attacker obtains a name and phone number. Group membership itself leaks numbers to every participant.
Code trigger. A registration for the victim's number is started on an attacker device, so the real owner receives a code.
Pretext. The attacker calls or messages, posing as customer service, and asks for "a code" framed as a protocol or confirmation number.
Re-registration. The account moves to the attacker's device. Past messages are not readable, because they are end-to-end encrypted and stored locally, but group membership is inherited immediately.

A variant worth modelling: the attacker enables two-step verification with a PIN the victim does not know. The Help Center states that a user without the PIN must wait 7 days before trying again. That is a week of attacker persistence on a privileged account.

Secondary surfaces

Linked devices. A primary phone can link up to four companion devices, and companion phones are logged out after more than 14 days without use of the primary. Linked sessions are a second place to audit after any suspected compromise.
SIM swap. Lee, Kaiser, Mayer and Narayanan (2020) showed that five US prepaid carriers used authentication challenges attackers could subvert. SMS delivery of codes inherits carrier support weaknesses.

Blast radius mapped to controls

Damage path after takeover	Documented control	Residual limit
Phishing or payment links posted by the hijacked admin	Allow-list link filtering that deletes other URLs	Payment requests without links still pass
Flooding the group	Anti-spam and anti-flood thresholds, strikes	A careful attacker stays under the threshold
Accomplice accounts joining	Member approval with filters, daily limits and history	Native admin rights can still add members
No forensic trail	Moderation history and action records	Only covers actions taken through the tool
Sensitive actions requested via an AI assistant	MCP access with verified identity, scoped access, confirmation and audit history	Only covers the MCP interface

The paper is explicit that these consequences follow from documented features, not from measured incidents. There are no official figures on how often admin accounts are hijacked.

Engineering conclusion: least privilege for group admins

The mitigation pattern is the same one you apply to cloud consoles.

Harden every privileged identity. Never share the code, enable two-step verification, add a recovery email or passkey where available, and review linked devices on a schedule.
Avoid a single point of failure. Keep more than one admin, but not everyone. One admin means no one can remove a cloned number; ten admins means ten phishing targets.
Lock the configuration plane. Restrict editing of group settings to admins, require approval for new members and reset the invite link after any incident, since a reset permanently invalidates the previous URL.
Separate human access from admin rights. Per-user dashboard access lets a team moderate without each person holding native admin rights. The 9bot documentation describes how access per user, history and approval rules are configured.
Plan the role lifecycle. Granting, reviewing and revoking admin status should be a routine task, as covered in this guide on how to add, change or remove a WhatsApp group admin.

Any bot or automation connected to the group runs with the permissions of its account, so that number needs the same protection as a human admin. Tools act after the takeover, not before it. The weak link remains the person persuaded to read a code aloud.

Source: Ivan Schroll (2026), Account Takeover of WhatsApp Group Administrators: Verification-Code Hijacking, Linked Devices and Layered Mitigations. DOI 10.17605/OSF.IO/HZUN5

Author: Ivan Schroll (ORCID 0009-0007-0680-5570)