A banking trojan's own API documentation calls stolen PINs quiz answers, and the victim a person staring at it
Group-IB found a complete AI assistant reply left verbatim inside a phishing overlay being served to banking customers. The platform's documentation describes credential theft as quiz completion and remote control as parental monitoring.
By Parminder Kumar Sharma · · 9 min read
The artefact left in the live page
On 23 September 2026, Group-IB published an analysis of a previously undocumented Android banking trojan whose operator calls it RemControl. Most of the report is the usual inventory: overlay injection, screen streaming, keylogging, input injection, self preservation. One finding is not usual.
At the end of one of the phishing overlays being served to banking customers, Group-IB found a complete AI assistant reply left in the file. Not a comment, not a fragment: implementation notes, a summary of what had been changed, and a closing offer to make further adjustments. Group-IB's own description is dry and exact: "Anyone who has accidentally copy-pasted a part of the chat along with the code written by AI will recognize this."
The operator's backend documentation, which was publicly accessible during the analysis, fits the same pattern. The endpoint that serves fake banking screens and the endpoint that receives the credentials typed into them are documented as handling quiz answers. The remote control features are documented as parental-monitoring. In the operator panel's own documentation, a banking victim is described as "a person staring at the quiz".
What that does not establish. It does not establish which model or which product was used: Group-IB names none, and neither will this piece. It does not establish how much of the platform is machine written; the evidence is artefacts in the overlays and the API documentation, not a measured proportion of the code. It does not establish that the operator could not have built the same thing without help. And it does not establish that a refusal would have stopped anything, which is the part worth sitting with.
Nothing here was jailbroken
The instinctive reading of this story is that somebody defeated a safety system. The evidence points somewhere less comfortable.
The artefacts describe a parental monitoring application. Consider what a real one does. It reads what is on the screen. It can view and control the device remotely. It runs persistently, resists casual removal by a child, and reports activity to a remote server. It is built, on Android, on exactly the accessibility APIs that this trojan abuses, because there is no other way to do it.
Now consider a quiz application. It renders an HTML form. It posts the answers to a backend. It stores them against an identifier. That is the credential submission path in this platform, unchanged in shape and mostly unchanged in code.
Nobody needed to ask for a banking trojan. The cover story and the product specification are the same document.
The same component described two ways. Left column is how the platform's own documentation describes it, from Group-IB's analysis. Right column is what it does in deployment.
| Component | Described in the documentation as | What it does in the campaign |
|---|---|---|
| Overlay fetch endpoint | Serving a quiz | Serves a full screen fake bank login over the real app |
| Submission endpoint | Receiving quiz answers | Receives PINs, mobile banking codes and card expiry dates |
| Remote control features | Parental monitoring | Operator taps, swipes and types on the victim's phone |
| The person at the other end | A person staring at the quiz | A retail banking customer being defrauded |
Where the abuse actually becomes visible
If the request that produced the code was indistinguishable from a legitimate one, the interesting question is where the campaign stops being ambiguous. Group-IB's report answers it, and the answer is not in the source code.
The dropper requests VPN permission and routes traffic from the Google Play Store package through a null tunnel, so that Play Protect cannot scan the installation. No parental monitoring product does that. The dropper generates a fresh signing certificate for every installation, so that two infections never share a hash. No legitimate product does that either. The payload watches for navigation to app management, accessibility settings and factory reset screens, and fires a back action to dismiss them before the user can act, in over 30 languages. That is not persistence, it is preventing removal by the device's owner.
That is the honest line between the two products, and every item on it is a runtime behaviour. None of it is visible in a request for a quiz form or a monitoring backend. It is visible on the device, in the install flow, and in what the application does to the settings screens its user would need to reach.
The practical consequence for anyone building or buying AI safety tooling is uncomfortable but clean: intent classification at the point of code generation cannot carry this weight. The same overlay HTML is a tutorial, an accessibility helper and a credential harvester, and which one it is gets decided later by somebody else.
The rest of it, because the fraud is the actual harm
The AI artefact is the striking part of the report. It is not the dangerous part. Group-IB confirmed active overlays for more than 30 financial institutions across Italy, France, Spain, Poland, Portugal, Canada and GCC member states, with Italy and France as the primary targets on the evidence of the campaign tags.
Three capabilities are worth naming for anyone writing detection content.
The pattern lock capture searches the accessibility tree for the lock screen grid across ten Android OEM implementations, including AOSP, Xiaomi MIUI, Huawei, OPPO ColorOS, Samsung One UI and OnePlus, extracts the screen coordinates of each cell and sends them to the server, which is enough to reconstruct the unlock pattern. The screen streaming sends both WEBP frames and the full accessibility node tree as structured JSON, so the operator gets a machine readable map of the interface rather than pictures to squint at. And the overlay target list is fetched from the server after registration, so the operator can retarget an already infected phone at any time without touching it again.
The infrastructure timing is worth recording because it is checkable. The command and control domain was registered on 12 May 2026. The first samples reached VirusTotal on 19 July 2026, which is 68 days later. The two distribution domains were registered on 10 July, nine days before the first sample. Artwork embedded in the phishing pages carries Photoshop metadata dated to April 2026. This was prepared, not improvised.
On attribution, Group-IB is careful and it is worth repeating the care. The operator tag hardcoded in every sample is UNKK. Droppers with the same file naming convention carried Medusa payloads until July 2026 and RemControl afterwards, the Medusa affiliate tag UNKN differs by one letter, both use Telegram dead drops to resolve the server address and both target Italy and France. Group-IB's conclusion: these are "suggestive of a common operator" but "a definitive link cannot be established from available evidence". That is what a responsible attribution sentence looks like.
What to do about it
Take this with you
In the order worth doing
- If you run a consumer facing bank or fintech, check whether your mobile application detects that an accessibility service is driving it, and whether your fraud rules treat a session in which input arrives with no matching touch events as higher risk. This family's entire value depends on that gap.
- Treat lock screen pattern entry as compromised on any device where this family is suspected, and advise a reset of the pattern from a different device, because the coordinates alone reconstruct it.
- For corporate Android fleets, block installation from unknown sources by policy rather than by advice, and alert on any application holding accessibility permission that was not installed from a managed source.
- Tell users the one thing that actually distinguishes the attack: a login screen that appears unexpectedly, over an app they already had open, is the attack. Nothing about the page itself will look wrong, because it was built to look right.
- If you are writing or reviewing AI usage policy, stop investing in the assumption that a refusal boundary drawn around described intent will catch this class. Put the controls where the behaviour is: distribution, installation, runtime permission grants and what the deployed thing touches.
- Where your own developers use assistants, treat pasted output as untrusted source that requires review before it reaches production. The operator in this report shipped a chat transcript into a live page, which is the same failure mode with a smaller blast radius.
That last one is not a joke at the criminal's expense. The same accident, made by a bank's own contractor, puts implementation notes about an internal system into a page served to customers.
The question this leaves
There is a comfortable version of this story in which a safety system failed and a better one would have held. The report does not support it. The operator asked for a parental monitoring backend and quiz pages, which is a description that thousands of legitimate products would also give of themselves, and received working software that did exactly what the description said. The fraud came from where it was pointed.
So the question for anybody drawing a policy boundary around AI assisted development, in a vendor or in your own organisation: if the request is indistinguishable from a legitimate one and the artefact is indistinguishable from a legitimate one, what exactly is your control looking at, and at what moment does it look?
This analysis was researched with Claude, made by Anthropic.
Sources
- PrimaryThe RemControl analysis of 23 September 2026 by Bruno Bijelic, read in full, used for every technical claim, the AI artefacts, the infrastructure dates and the attributionGroup-IBaccessed 2026-09-25
- PrimaryAndroid's own accessibility service documentation, used for what the permission grants and why it is the pivot in every family of this kindGoogleaccessed 2026-09-25
- Reported byCoverage of the same research, used only to confirm the reporting date and the summary of geographiesBleepingComputeraccessed 2026-09-25
