- Executive Offense
- Posts
- Labs2Learn: Instaglam
Hey everyone!
Welcome back to Labs 2 Learn. In our previous ticketing-system issue, we looked at framing: claims the agent accepted without checking. This week, a support assistant confirms a new email address and lets the wrong person change an existing account.
The target is Instaglam, one of the labs we've built at Arcanum and hand out with our Attacking AI class. It's a photo-sharing app with an AI support assistant on the login page.
We built this exercise around the failure described in the June 1, 2026 404 Media report on Instagram's AI support account takeovers. Instaglam recreates that failure pattern.
Watch what the email check allows next. That's where the recovery flow goes wrong.
Let's get into it.
/The TL;DR
Recovery needs proof of account ownership. The assistant accepts a code sent to a newly supplied address. That doesn't establish the user's right to change the existing account.
Plain requests can reveal broken permissions. Ordinary recovery requests move this flow forward without demonstrating an instruction override.
The tools must enforce the permission check. The recovery service has to establish permission for the specific account and action before making a change.
/ Background: A Help Desk With Account Privileges
Instaglam looks like a familiar photo app. The login page features @glow, the fictional GLOW Cosmetics account, with a verified badge and 4.2 million followers. The support link sits below the login form.
That link opens the Mega AI Support Assistant in a Help Center window. Mega is the fictional company behind the app. The assistant's greeting offers help with account issues.
This assistant has tools behind it. The capture reports email-enrollment and password-reset operations. Those tools can change who controls an account.
Think about a human help desk. A username helps the rep find an account. It doesn't establish the right to change it. The chatbot needs the same check.
(Sponsor)
Get Visibility into Threat Actor Chatter with Flare
Flare's Threat Intelligence brings together the sources and capabilities your team needs in a single threat intelligence solution that delivers better context and faster signals to action for your security operations.
With our CTI Module, you can:
Research threat actors, campaigns, indicators of compromise (IOCs), tactics, techniques, and procedures (TTPs) in one place.
Report findings in executive-ready format, scoped to your organization.
Operationalize indicators by delivering high-volume IOC coverage with full STIX object relationships into existing security stacks.
Analyze suspicious files and URLs is an isolated, evasion-resistant environment before you act on them.
Cut through the Chatter. See the Intelligence for yourself.
/ Step 1: The Account
The conversation starts before sign-in. The recovery request names @glow and supplies a new mailbox. The assistant responds that it sent a verification code to that address and asks for it.
There are two pieces of information here: the named account and the mailbox receiving the code. Neither, by itself, establishes who is entitled to recover @glow.
Think about a human help desk. A username helps the rep find the account. The next question is whether the user has the right to change it. In this exchange, the next step is to verify the new address.
/ Step 2: What the Mailbox Check Proves
The email arrives in the newly supplied mailbox. Its subject is an Instaglam verification code, but the body is the detail to pay attention to: it describes a request to add the receiving address to @glow.
The message names the account the change would affect. It doesn't establish that the person reading the email owns that account.
That distinction is easy to lose in a recovery flow. An email arrives, a code comes back, and the interface can label an address verified. The question is what that label permits.
Checking this mailbox could establish access to it. It cannot, on its own, establish the right to change recovery details on @glow.
/ Step 3: The Changed Account
The assistant accepts the code and reports that the new email has been verified and added to @glow. It then invites the user to supply a new password. The next reply reports a successful reset.
Read the transition in that screenshot. Once the assistant accepts the code, it treats the user as someone allowed to continue changing the account. The conversation hasn't established that permission.
Those are still the assistant's claims. We need the application outcome too.
The recorded walkthrough returns to the ordinary login form and reaches the account view.
There's @glow, the test email on file, and the challenge flag.
The documented login and account view confirm the takeover is complete.
/ Tactical Takeaways
Map tools by what they can change. Document the accounts each tool can affect and the permission check that should protect each action.
Keep ordinary requests in the test plan. When reviewing an application you control, include basic requests that should be denied. They give you a baseline for whether its account permissions hold.
Ask what "verified" means. Identify what each check establishes and what action it permits. A new mailbox and an existing account need different evidence.
Check the resulting account. Keep the conversation and reported tool events, then confirm what changed in the application. That separates a bot's claim from a completed action.
/ Mapping to the Arcanum PI Taxonomy
Our Arcanum PI Taxonomy separates intent, technique, input, and evasion. Here's how this run fits:
Intent: PIT-I-20, Unauthorized Action Execution. Account changes the user wasn't authorized to request. The confirmed result is a completed takeover.
Technique: PIT-T-60, Direct Request (Plain Prompting). Ordinary recovery language, with no demonstrated instruction override.
Technique: PIT-T-47, Confused Deputy (Agent Authority Confusion). The assistant uses privileged recovery tools for a user whose right to change the account hasn't been established.
Input: PIT-N-02, Chat Interface. Requests submitted directly through the support chat.
Evasion: None demonstrated. The recorded messages show no encoding, hidden text, or other filter-evasion technique.
/ Defender's Corner
Establish the right to recover the account first. Use recovery evidence already associated with the account. If that evidence is unavailable, require a fallback that independently establishes the user's right to recover it before changing recovery details.
Enforce authorization in every recovery tool. Each tool must check trusted recovery state for the specific account and requested change. The model's decision to call a tool cannot grant permission.
/ Outro
If you're building an AI support assistant, ask your engineers one question: what establishes the user's right to change this account before the recovery tools act?
For more practice, our public AI Security Resource Hub brings together community labs, CTFs, tools, and reading for AI security testing.
Thanks for reading, and as always, feel free to reply or hit us up on Twitter if something in here sparked a thought.
Happy hacking 😎