Security

The cutest trap on the internet: weaponizing Google's child-safety system as a kill switch

A fake Minecraft launcher infected my friend α's machine on a Tuesday evening. By morning, an operator had used the stolen access to upload triggering content to α's Google account, log out, and let the platform's own automated child-safety detector erase the witness. The malware is the carrier; the kill switch is the story. The technical reverse-engineering lives in the companion post.

Arthur Dutra··14 min readShare ↗RSS

The email arrived overnight. Sender: no-reply@accounts.google.com. Subject: "Your Google Account has been disabled." Body: child sexual abuse material had been detected in the account; the account was permanently terminated; the case had been forwarded to the National Center for Missing and Exploited Children, as the law requires.

I'm calling the recipient α. α had used that account since they were a child. α did not upload that content. α has never uploaded that content. α was asleep when it happened.

Eleven hours earlier, an operator had taken over α's Google account through a Minecraft-themed malware dropper α had installed that evening. They tried to extort α for permanent control of the account on WhatsApp. When α refused, they (allegedly) used Google's own child-safety enforcement as a weapon. They poisoned the account with material they knew would trigger the automated detector, logged out, and let the system do the rest.

By the time α woke up, the evidence trail pointed at them, not at the operator who had been in the account hours earlier.

This post is about the operational pattern. The technical reverse-engineering of the malware itself, three layers of obfuscation walked end-to-end, lives in the companion post. The malware is professional and worth its own writeup. The malware is not the story. The story is the kill switch the operator built from somebody else's safety system.

The lure

The site that infected α was called KittyCrafts. It sold itself as a community-run Minecraft server with a custom launcher that installed the right modpack, joined the right server, and handled updates automatically. The aesthetic targeted exactly one demographic: children, and the slightly older players who help them set things up. Cozy palette. Cat mascot. "Verified and safe" badge in the header, which is a phrase no security professional has ever written about their own product.

There was no company name. No address. No security contact. No source code. No published file hashes. No signed installer.

A legitimate Minecraft launcher is published by Mojang, signed by Microsoft, and listed on a public page with every prerequisite present. A legitimate modpack from CurseForge or Modrinth is scanned, signed, and broken down mod-by-mod before you install it. KittyCrafts shipped a single unsigned executable from a single link, with no manifest of what it contained.

That is not a launcher. That is a delivery vehicle.

Why this works on the target audience

Minecraft has spent fifteen years training its players to do four things:

  1. Download executables from unfamiliar sites.
  2. Run them as administrator.
  3. Disable their antivirus when it complains.
  4. Trust a recommendation from another player more than a warning from their own operating system.

Every one of those behaviors is exactly what an infostealer operator needs from their victim. The Minecraft mod and client scene is not a side door for credential theft. For a category of malware called infostealers, it is one of the main doors.

The economics are straightforward. A stolen Discord account with a long history sells. A stolen Steam library sells. A stolen Google account tied to YouTube, to Drive, to a parent's payment method, to a Minecraft profile from 2013, sells for more. A stolen browser session cookie that bypasses two-factor authentication on any of those services is worth more again, because it works instantly and leaves no password trail for the victim to follow.

What sits underneath KittyCrafts is, allegedly, a credential-collection operation with a Minecraft launcher painted on the front.

The 90 seconds after the click

α installed the launcher on a Tuesday evening. They had been told about the server by someone they trusted, in a Discord they had been part of for over a year. Windows SmartScreen warned that the file was unrecognized. α clicked "Run anyway," because every Minecraft launcher they had ever used had done the same thing, and every one of them had been fine.

The launcher opened. It looked like a launcher. It downloaded what looked like mods. It logged into Minecraft. It worked.

Underneath, in the same minutes, it handed the operator a key to α's entire digital life. The full technical breakdown is in the companion post. The short version: within ninety seconds of execution, the launcher read the cookie database of every browser on the machine. It read the saved password database of every browser. It opened Discord's local storage to extract the authentication token. It read Minecraft's account file. It called into Windows DPAPI to decrypt the master key that protects all of it.

None of those operations are required to launch Minecraft. All of them are required to take over someone's life.

Then it sent. One multipart upload, packaged and encrypted in transit, addressed to a server that is not Microsoft's, not Mojang's, not any party with a reason to receive your browser cookies. The exchange took about a second and a half. By the time α had clicked "Play," it was over.

The cascade

α woke up to the cascade. Discord sign-in alert. Steam sign-in alert. Google sign-in alert. Microsoft sign-in alert. Each from a foreign IP. They were already locked out by then. Their session, on every service, had been cloned to a device they did not own, in a country they have never been to.

The bribery

A few hours later, the operator messaged α directly on WhatsApp, from a number registered in another country. The message was, paraphrased, "I have your accounts. Give me what I want and you get them back."

This is the part of the operation that broke the normal pattern. Most infostealer pipelines are industrial. The operator does not negotiate with the victim. The cookies go into a stealer log, the log gets sold in bulk, and someone three steps down the supply chain monetizes the access. That is the usual shape.

This operator did not do that. They contacted α personally. They asked for cooperation. When α refused, they did something that very few operators do, because most of them do not need to.

They erased the witness.

The kill switch

Google, like every major platform, runs automated systems that scan for child sexual abuse material. They are required to. The systems work in two ways. Hash matching, which compares uploaded files against a database of previously identified material. Machine learning, which flags content that resembles known material closely enough to warrant human review. When a match is confirmed, three things happen, in order: the content is removed, the account is disabled, the case is forwarded to NCMEC, which forwards it to law enforcement in the appropriate jurisdiction.

The system exists for a reason that is not in dispute. It is one of the most consequential safety systems on the consumer internet. It works.

The problem is structural: the system measures the account, not the human at the keyboard. If a stranger has full access to the account, the system cannot tell. And every consequence of what that stranger uploads falls on the account holder.

The operator who took over α's account, allegedly, did exactly this. They uploaded content they knew would trigger the automated detector. They logged out. The system fired. The account was disabled. The case was forwarded. By the time α woke up, the system that was built to protect children had been turned into a kill switch that destroyed the victim's identity and pointed law enforcement at them.

This pattern is not theoretical. There is at least one Reddit thread on r/GMail documenting it from another victim's perspective. There is at least one public sandbox analysis showing a related launcher's behavior. The security community has started talking about it under terms like "weaponized account suspension." It is new enough that there is no settled name for it yet.

What the pattern means in practice is that the goal of the attack stopped being "steal the account and use it." The goal became:

Steal the account, exploit it, and destroy it in a way that puts the victim under suspicion. The destruction is the cover. The platform's own safety system is the murder weapon. The operator never has to touch the victim directly. They just have to know which button on Google's side fires automatically, and aim the account at it.

Every account-recovery system on the consumer internet is built on the assumption that the legitimate user can prove they are the legitimate user. If the system has been turned against them by a sophisticated operator before they have a chance to react, that assumption breaks. The appeal process gets dragged into review queues that take weeks or months. And for as long as it takes to untangle, the victim is, in the eyes of the system, the perpetrator.

What the implant was actually for

The malware is dissected line-by-line in the companion post. Three layers: a 1.1 MB obfuscated batch dropper with payload steganographically split across thousands of comment lines; a 17 KB PowerShell loader that performs classic remote-thread shellcode injection into explorer.exe; a 663 KB Donut-packed shellcode carrying an encrypted .NET RAT.

What matters in this story is what it was built for. The whole pipeline exists to keep an obedient .NET assembly running inside explorer.exe, with that process's full user-context privileges, with command-and-control access, without showing up in any process list under a suspicious name. The implant uses a 7-byte memory marker to prevent double infection across reboots. That is not the behavior of someone running a one-shot smash-and-grab. That is the behavior of someone running a long-term residency.

It is not ransomware. There is no filesystem walk, no key generation, no ransom note, no shadow-copy deletion. It is not a wiper. It is not a coin miner, despite the misleading CPU.exe filename in the rename trick. It is optimized for long-term residency under user-context privileges with full access to that user's data:

  • Browser credential harvesting from Chrome, Edge, Firefox, Brave, Opera.
  • Browser cookie and session-token theft (the part that bypasses two-factor authentication on every signed-in service).
  • Crypto wallet theft from standalone clients and browser extensions.
  • Application token theft from Discord, Telegram, Steam, Slack, gaming launchers.
  • Keylogging via a global hook installed from inside the host process.
  • Clipboard hijacking, watching for wallet addresses and silently replacing them.
  • Periodic screenshots. Reverse shell. Hidden VNC, a second invisible desktop session the operator can drive while the real user is logged in.

That is what was running on α's machine for the eleven hours between install and cascade. The launcher worked because the launcher had to work. Underneath it, the implant was already onboarding α's accounts into the operator's inventory.

The takedown that did not take

The investigation produced a formal report filed with cybercrime authorities. The report contains the dropper binary, its hashes, the network captures, the decompiled exfiltration logic, the destination endpoints, the WhatsApp evidence of the extortion attempt, and timestamps for every step. The phone number connected to the WhatsApp contact is in that report. It is not in this post, because the place for attribution is the police report, not the public web.

The hosting provider behind the origin received the same evidence package. Cloudflare received an abuse report. Mojang and Microsoft were notified. Discord's Trust and Safety team received the exfiltration details. α filed an appeal on the Google account, with a copy of the police report attached.

The hosting provider takedown took about 72 hours. By the time it processed, the KittyCrafts site was offline.

Four days later, the same operation came back online under a different name.

The new site is kittycraft.help. Different domain. Different registrar. Different hosting provider. Same artwork. Same launcher pattern. The installer it serves drops a batch file that, when run, matches the structural fingerprints of the original dropper. Different padding. Different macro variable names. Different output paths. Same three-layer architecture. Same Donut signature. Same target list.

That is the part of this story I want to leave you with, because it is the part that no single report or takedown can fix. Domain takedowns do not break an operation. Domain takedowns relocate an operation. As long as it costs the operator three dollars in registration and an afternoon of reskinning to reappear, the operation is going to reappear. The cost of being taken down is rounding error. The cost of being a victim is your accounts, your wallet, in α's case your entire digital identity, and a permanent flag on your record from a system that cannot tell that the person who poisoned the account was not you.

The asymmetry is the story. The asymmetry is also the reason the next victim has already downloaded the installer by the time you finish reading this.

Defense, for the audience this targets

If you install Minecraft mods, or someone in your house does, here is what actually defends against this category of attack:

  1. The official Minecraft launcher from minecraft.net never asks you to disable your antivirus. If a launcher does, that is the warning. Not a recommendation. The warning.
  2. Modpacks belong on CurseForge or Modrinth. Both scan uploads, sign manifests, and let you see what is inside before you install. A modpack that requires a custom executable to install is asking you to do something the legitimate platforms do not require.
  3. SmartScreen blocking an installer is not a false positive that you click past. SmartScreen blocks unknown publishers because they are unknown. The right response is verify, or close.
  4. Two-factor authentication on every account that supports it, using a hardware key or an authenticator app, not SMS. Two-factor does not stop session cookie theft, but it slows the attacker's recovery hijacks and gives platforms more signals to act on.
  5. If you suspect a compromise, do not log out and back in from the infected device. That just gives the attacker more cookies. Go to a clean device. Change passwords. Invalidate all active sessions on every account. Only then come back to the original machine and wipe it.
  6. If you are setting up a child's gaming PC, the account does not get administrator privileges. Most of this dropper's pipeline requires either elevation or access to a user profile that has stored a lot of credentials. Removing the elevation path removes most of the attack surface.
  7. Compromise propagates through trust. The Discord friend who told α about KittyCrafts had been in their server for over a year. That is not a stranger by any normal definition. The defense propagates through trust too. Talk to the people in your life about what installers should and should not look like, and do it before they need to know.

Where this leaves us

α's appeal is still in review. kittycraft.help is still online. The operator, at the time of this writing, has not been arrested.

I am publishing this anyway, because every week the pattern stays undocumented is a week another α gets the same email. The system that disabled α's account is not going away. It cannot. The vulnerability is not in the system. The vulnerability is in the assumption underneath it: that whoever is using an account is the person who is supposed to be using it. For most of the lifetime of the consumer internet, that assumption was good enough. It is not good enough anymore.

If you recognized any part of α's story in your own, the recovery checklist above is in the right order. If you operate a platform, the appeal queue for compromised accounts is where the cost of this attack is being absorbed right now. Resourcing it is not optional anymore.

The technical reverse-engineering of the dropper, three layers walked end-to-end with deobfuscator code and indicators of compromise, is in the companion post. Hashes only; the live sample is not distributed.

If you suspect you or someone you know has been targeted, contact your national cybercrime reporting unit. In Brazil: SaferNet and the Polícia Federal cybercrime unit. In the United States: ic3.gov. In the United Kingdom: actionfraud.police.uk. Do not contact the operator. Do not pay. Preserve evidence and report.