Parental Control Flaw Allows Google Account Hacks

An ongoing  malicious campaign is abusing a flaw in the Google Family Link parental control feature to hijack accounts, ReversingLabs (RL) researchers warn. It starts with links sent in Discord asking for game reviews. Often, these links are sent from compromised Discord accounts, to whoever the victim recently messaged. These links take victims to a fake game website that then leads to a Dropbox page containing the download for a malicious executable.

Once downloaded, this executable takes over a victim's machine. From there, hackers compromise Google accounts linked to the infected device by re-casting the account holder as a minor (younger than 13) and abusing Google’s Family Link feature to put the account under the control of a malicious “parent” account, locking out users and blocking account recovery efforts.

The attackers then demand ransom payments to prevent them from selling account data and access. This blog will walk through the mechanics of these campaigns, while also exploring how these actors abuse the Google Family Link feature.

Google Account Compromises: ‘Hey’ Says It All

It is Monday night, and my friend Christina starts sending the same strange message to our friends over Discord. A simple “hey.” Those three letters are all it takes to throw our friend group into chaos. 

Those familiar with Christina noted she was not sounding like herself. She was exchanging pleasantries, but quickly became insistent that people download this game she had been working on. While friends knew Christina was involved in various projects, those were usually event planning and music production related. She had never engaged with video game development. Friends began to talk to each other about the issue. Some reached out to her outside of Discord and confirmed their worst fears; Christina had been hacked.

The beginning of cleanup started quickly after the first messages were sent out. Christina’s boyfriend started sending warning messages in the Discord servers they both were members in, telling people that Christina’s account was compromised. However, he found that he was quickly banned from these servers. The attacker was not just messaging people to propagate the malware, they were abusing Christina’s admin powers to prevent warnings from going out. At this point, I stepped in and privately contacted admins on these Discord servers and warned of the compromise. This led to the compromised accounts being quickly kicked. 

Discussions with Christina revealed that she noticed multiple of her accounts had been compromised. That included her Steam account, where the attackers attempted to make purchases of game items, potentially for resale. Unfortunately, one server had its only other moderator, Cerise, banned by the hackers as they sought to leverage Christina’s account permissions to control the narrative. Since Cerise lost access to the server, she privately messaged whoever she could that Christina’s account was compromised. In servers where the account did not have administrator permissions, the hacker would insist they were the legitimate Christina, but was quickly banned when it became evident they were not. 

It took around 20 minutes from start to finish, but eventually the attack was halted. Christina’s compromised account had been banned from most of the servers it was active in, and people had spread the warning. Christina wiped her machine and made a new Discord account. This account is how she would negotiate with her attackers, and also inform others about what happened.

Google’s Family Link Fuels Account Takeovers

In conversations with Christina and her boyfriend after the fact, Christina revealed what had happened to her. Just before the compromise, she received a message from a distant friend she did not talk to much, with a simple request for a quick review of a game they claimed to have been working on. Christina took this at face value and downloaded the executable. 

The actor behind this campaign created a website to bolster their fake game’s legitimacy. When a user clicks the “Download” button (Figure 1.1), they are redirected to download a file hosted at a Dropbox link. 

RL was unable to obtain a sample of the executable, as the Dropbox link no longer contained the executable once researchers accessed it. However, the research team did conduct an analysis of the website (https://hyperionbeta[.]netlify[.]app/) used to distribute the malware, to provide further context. Here are the techniques used by the attacker, which are unique and applicable to any malware capable of gaining initial account access.

Figure 1.1 shows an instance of a malicious game website, taken with Spectra Analyze Interactive Analysis sandbox.

Figure 1.2 shows more details of the fake game website taken through the Spectra Analyze Interactive Sandbox.

Figure 1.3 shows the Spectra Analyze page with information on the Hyperionbeta Netflify app.

This executable Christina downloaded was not actually a game, it was malware. Without a sample to analyze, the exact malware family cannot be determined. Behaviorally speaking, it has the capacity to hijack browser sessions and steal login credentials. Christina says her memories blur after she started the executable. She remembers getting notified of a login attempt for her Google account from Turkey, but she was not able to interact with it before it disappeared.

In no time at all, the attackers behind the campaign took over her Discord account, ran transactions on Steam, and kicked her off of her Google account. Christina had all the recommended protections in place, like multi-factor authentication - tapping to approve sign ons -as well as secure account recovery methods. But hackers found a way around these and she was still compromised.

How? As it turns out, a quirk in Google’s Family Link system was responsible for her losing control of her Google account. During the hack, she was logged out of her browser session. Upon attempting to log back in, she noticed her password had changed. She attempted to use her recovery methods, but was blocked from recovery and notified that she needed the approval of a “parent.” This was odd, given that Christina is in her thirties and well into adulthood.

The Family Link feature is designed to allow parents and guardians to supervise and curate their children's online experience. It does this by connecting two or more accounts in a family group, with one account acting as a parent and the rest acting as children. This parent account can directly influence the child account, and has features such as location tracking, setting screen time limits, blocking apps, updating personal information, and more. Most crucially, it allows parents to update the passwords on child accounts, which will automatically log all current sessions out. These controls can help families legitimately oversee their children’s online experience: tailoring interactions based on specific needs.

The compromise of Christina’s account — and others — show that the Family Link feature is not sufficiently secured and can be exploited for malicious purposes. The assignment process of the Family Link feature allows hackers to bypass an account’s multi-factor authentication and make changes to the account. Specifically: using their access to her Google account, the attackers altered Christina’s account's age to turn her from an adult into a minor in the system (younger than 13 years old), thereby invoking a Google policy regarding under-age users.

This policy forced the account to be assigned to a “parent account” that was under the hackers’ control (Figure 2.2). Once assigned, the parent account has total control over the child’s account and can update the child account’s password, and kick the legitimate user out (Figure 2.1) and more.

Figure 2.1 shows a Google Support article confirming that resetting a child account password from family link automatically signs the account out.

Figure 2.2 shows a victim of attempted recovery being blocked by parental approval.

As the hack of Christina’s account shows, the peculiarities of the Family Link feature impose many obstacles to victims who wish to regain control of their account. For example, the “child” victim does not have a way to view the new password created by their “parent.” Any attempts at account recovery using authenticator codes, text recovery, email recovery, or any other methods are halted by the need for parental approval before advancing the recovery process. This puts “child” victims at the mercy of their “parent” attackers, who obviously will not assist in account recovery. 

Based on reports by victims of Family Link compromises posted to sites like Reddit, Google’s Gmail customer support is unable to help with account recovery following Family Link-fueled compromises.

When Parents Demand a Ransom

After Christina’s accounts were hijacked, the purpose of the attack became clear. The hackers used her compromised Discord account to demand a ransom: $250 to stop the spread of harvested information on the dark web;  $250 for the accounts to be returned; or $450 for both. The messages, written in English, used erratic syntax and mocked Christina’s efforts to get answers about how they intended to use the stolen data (Figures 3.1, 3.2).

Figure 3.1 shows the hacker requests $250 to keep information off the dark web, and an additional $250 for return of the accounts.

Figure 3.2 shows that the hacker confirms ransom is for return of the accounts.

Figure 3.3 and 3.4 show another victim being informed of the ransom with the $250/$450 price quotes.

Christina spent some time attempting to contact Gmail and Discord support to recover her accounts, but had no luck. Some other accounts were recoverable, like her Steam account. An interesting detail is that Steam’s support emails were initially sent in Turkish, which aligns with the Turkey-based Google login attempt seen in the early stages of the compromise.

Figures 3.5 and 3.6 show communications from Steam in Turkish. The first image is shows a login attempt; the second a notification of password reset.

She migrated to a new Gmail account, and after some time, the hackers deleted her compromised account. However, her compromised Discord account remained active, and recently tried to start up the whole scheme again, messaging people about another game. This spurred the creation of this article.

Two Years of Attacks

In reading further, slews of complaints of similarly compromised Gmail accounts were found populating Reddit (1,2,3,4) and the Google Help (1,2,3) forums dating back close to two years.

Google Support posts from as early as April 2024 describe user accounts being compromised through malicious use of the Family Link feature. In these statements, it is said that the attackers simply monitor the account, and could theoretically intervene at any time. 

More recent reports begin to describe the tactic shift into account lockout and ransom. However, blackmail is still on the table based on the previously pictured ransoms. These reports have been happening in 2026, with the most recent report being around March 2 (See additional source). With Google support unable to do anything to assist child accounts without cooperation from the parent,  the only potential route of recovery seems to be going through YouTube support, but evan that is a long shot. Many commenters advise to just move on.

Considering how much control a parent has over child accounts, it is concerning that hackers are using this as a way to lock people out at such a scale. With the context of the myriad of reported victims, it seems there may be a lack of sufficient controls over this assignment process, leading to frequent abuse. It is a tantalizing option for attackers to use this feature to compromise accounts, as it makes recovery near impossible for the user. It makes one wonder, how easy is it to assume control of an account using Family Link?

Recreating the Compromise 

In order to fully understand the nature of this system, researchers attempted the child account assignment process. Here is a step-by-step outline of the process of assigning a child account by age change using two new dummy accounts. Child (childtest312@gmail.com) will act as the child account, and Parent (parenttest312@gmail.com) will act as the parent. Both were set to adults with a birthday of May 15th 2000.

In addition, the accounts were given MFA through an authenticator app. Although these accounts did not get directly bound to recovery phone numbers, they were activated in association with different devices. Google tracks how many accounts are registered to each mobile device through linking them internally to that device’s phone number.

Figure 4.1 shows a Child account with two-step verification enabled.

Figure 4.2 shows a Child account with an authenticator app connected.

Figure 4.3 shows a Parent account with two-step verification enabled.

Figure 4.4 shows a Parent account with an authenticator app connected.

For extra security, skip password when possible was disabled on both accounts:

Figure 4.5 shows skip password when possible set to disabled.

Another attempt of assigning parent accounts to an existing child account was done using a researcher's personal accounts, but no screengrabs were taken. This attempt was successful, allowing the parent account to be assigned with no MFA checks, subsequently enabling complete control of the child account to be given to the parents.

Even with account access, researchers could not find a way to remove supervision or prove the account was not a child. This first attempt prompted the second attempt with the dummy accounts to gather screen grabs of the process. These separate attempts are relevant later, since the usage of dummy accounts did not lead to successfully assigning the child account.

The dummy child account was logged into a browser, but not the parent account. This was done to best mimic a potential victim's environment. To start the child account process, navigate to manage the Google account, and look into personal information.

Figure 5.1 shows the On Manage Google Account interface, selecting birthday.

Scroll and click the birthday button.

Figure 5.2 showsclicking on the birthday to open the birthday change menu.

Clicking the currently assigned birthday opens the screen to update it.

Figure 5.3 shows the original birthday on the account.

From there, the birthday for the account can be changed.

Figure 5.4 shows updating of the birthday year to 2018.

Figure 5.5 shows confirmation that the account belongs to a 7-year-old.

Birthday changes will prompt a Cancel or Confirm dialog, but crucially, this does not require any form of reauthentication. If the account age is set to recent enough to be considered a child, it prompts a countdown and gives a 14 day period to resolve the issue. Children are not supposed to use Google services unsupervised, so the resolutions are either to provide a form of ID to prove the user is an adult or assign a parent account. It is of note that once a parent account is assigned, the option to prove age with ID is no longer valid.

Figure 5.6 shows a screen informing that the account with be deleted in 14 days unless age is verified or parent is assigned.

The attackers will go through this route to assign a parent account, which involves going through some information screens.

Figure 5.7 shows information on setting up supervision.

Figure 5.8 shows how to set up a supervision screen.

Figure 5.9 shows a warning about data deletion for child’s account.

The process does require the potential child accounts password to authenticate, but will not trigger any other forms of authentication.

Figure 5.10 shows the request for a child account password.

Passwords are a very weak form of authorization. They can easily be found within the browser, like if the user has their passwords stored in a password manager. Since the malware for this attack requires some level of credential or browser access, this check could easily be bypassed by attackers who find a stored password. 

There is also the chance that attackers are able to change the victim's password within settings without being prompted to reauthorize. The Skip password when possible option makes it more likely that this will happen. It is the default option on Google accounts. When enabled it allows users to change their passwords within settings without first entering an existing password. So attackers could change an user's password to their own, which would allow them to enter it on the figure 5.10 screen and continue the child account assignment process.

It is of note that during this test, an attempt was made to change the password within the Google account, mimicking the scenario where the attacker could not access a password otherwise. Changing the passwords on these accounts required the existing password to be entered, due to Skip password when possible being disabled. After selecting “try another way”, it prompted the user to enter a previous password or authenticator code.

Figure 5.11.1 shows the first attempt when “Try another way” was selected for password but authenticator app token was entered.

Figure 5.11.2 shows the second attempt of resetting password when “Try another way” was selected for both password and authenticator code.

This makes disabling the “Skip password when possible” option a potential countermeasure to this type of takeover, assuming credentials are otherwise not compromised.

Circling back to the Family Link process, after the child accounts put in their password, the parent account will enter their password to complete the process, however, a discrepancy was encountered during this part of the process.

On the first attempt at recreating this attack, an established set of Google accounts had been used. Through using this account, parental control was immediately established after passwords were entered. It should also be noted that the parent and child account during that test shared a recovery phone number, which may have loosened the controls for connecting the accounts.

Once Family Link was established, the researcher confirmed changing the password did kick off the child account, and the child account required parental approval to go through the password recovery process, as previously discussed. That means that if successful, the establishing of a Family Link effectively locks anyone with a malicious parent out of their account. 

However, for the controlled experiment, the process prompted a screen to verify identity, requiring a credit card to continue.

Figure 5.12 shows the parent consent screen, asking to authorize using a credit card.

Figure 5.13 shows the credit card information entry screen.

At this time, it is unclear what triggers a need for credit card authentication. It might be something as simple as account age and activity. The Parent312@gmail.com account had not been used previously, and did not have any credit cards bound to it. The account used in the other test had an established history and had used credit cards to buy things on the account. This history may have bypassed the need for the credit card consent check. It could be that Google accounts being associated with the same number causes less strict regulation, and if the account is associated with a different number, it attempts one of these checks.

Another possibility is that the attempt to change password mid-process triggered the system to see the takeover as potentially fraudulent, triggering this additional check. However, based on the fact that there are still reports of this compromise, it seems that this control is not sufficient. 

There are a myriad of potential bypasses to the limited controls set in place. Reports state that other credentials were stolen alongside the Google account. Those include the Discord credentials used to perpetuate the malware, so it is likely that the malware responsible has credential harvesting capabilities. Google passwords could be stolen, allowing for entry of that password when prompted.

Another possibility is that hackers could use credit card information saved in the browser to bypass that check, although without malware samples, that possibility cannot be completely verified. Based on the content of the ransom communications shared above, it seems the hackers may have the information needed to make false identities using what was stolen from victims. This renders the limited checks during the Family Link assignment process useless. 

This is where testing of the Family Link feature ends. With the ongoing publication of complaints online of abuse of this feature and researcher exploration of the assignment process, it seems like the Family Link feature is still exploitable. According to reporting in Forbes in early December of 2025, a spokesperson claims Google is aware of this attack route. It is an uncommon issue, but still an acknowledged one. Users must be careful with how they move forward with this information, leading to the following recommendations.

Recommendations

Malicious file attachments, links, and websites are the most common tools that hackers use to compromise user machines and accounts. Any downloads and links, especially unexpected ones, need to be regarded with caution. Even trusted users can not be trusted innately. Files can be scanned for malware in advance. It is recommended to execute files in a protected environment, like a sandbox or virtual machine, to mitigate damage in the case the file turns out to be malicious.

Taking these measures can keep malicious files from accessing sensitive systems, accounts, and data. When clicking links, double check the URL is in alignment with the domain. Public scanners can also be used as a secondary check for URL safety.

For Google account owners, some safeguards can be put in place to make account takeovers less likely. They include: 

• Enabling multifactor authentication, ideally with non-SMS options such as authenticator apps (Google, Microsoft, Authy); hardware keys such as YubiKey; or biometrics IDs such as FaceID, fingerprints, etc. It is important to remember that account recovery methods are not the same as having multifactor authentication enabled.
• Removing Google password from the password manager and system so it can not be  harvested by attackers who have gained access to your password manager or local system. 

Disabling Google’s Skip password when possible feature, which can help prevent attackers from changing an account’s password using hijacked access. Disabling this requires authentication to be entered before changing the password from within the account, complicating attackers efforts to reconfigure the compromised account as a child account under the control of a malicious parent.

Figure 6.1, Skip password turned off in Security & sign in settings

• Using Google Takeout to periodically maintain backups of Google accounts can also help users have recovery options aside from paying ransom in the account that their account is compromised. While this is a last resort option, having backups of data is better than having none, and it may also save users’ in other situations of account loss.

For Google, the numerous reports of attacks that exploit the Family Link feature are evidence that an overhaul of the company’s current account verification system is needed. Among other things, better attack heuristics are needed in connection to its Family Link feature. Account age changes should not be a frequent occurrence, so extra security measures would not impact the typical user experience.

For example: A sudden age change rendering the account owner a minor should require the use of an account recovery method, regardless of whether the user had enabled multifactor authentication. In addition, the assignment process by which the child account enters a password should also require a multifactor authentication check or account recovery method. The lack of these controls does not make legitimate use easier, it only makes it trivial for attackers to exploit. These suggested solutions are only a sample of the kinds of tighter controls needed to prevent Family Link abuse.

Closing Thoughts

From a dime-a-dozen tale of a Discord hack to a deep dive on the Google Family Link exploit, a lot of ground was covered in this article. To review, a fake game Trojan perpetuated by attackers on Discord delivers malware. This malware steals various credentials and hijacks existing Google sessions, allowing for attackers to make changes to accounts without trigger authentication requests. With this access, they use a vulnerability in Google’s Family Link system, in which a lack of authentication measures allow for complete account control and lockout.

By assigning a victim's accounts to a hacker’s family group, hackers can change the victim’s password and simultaneously prevent recovery, since Family Link requires parental approval for children to change their passwords. This allows hackers to ransom out access to the account to victims, with Google support unable to assist. Readers are encouraged to remain alert for potential phishing attempts, even if they come from seemingly trustworthy accounts.

Today, Google users can help protect their accounts by enabling 2-step verification, disabling Skip password when possible, and maintaining backups. Hopefully, Google will soon implement sufficient controls to prevent misuse of this feature, and allow it to only perform its intended function.  

Indicators of Compromise (IOCs)

Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.

The following IOCs were collected as part of RL investigation of this campaign.

URLs:

• https://vampirk-beta[.]netlify[.]app (Sep 2025)
• https://dungeonwarriordemo[.]netlify[.]app (Nov 2025)
• https://www.dropbox[.]com/scl/fi/wduyccgsm5njhhpvqhhog/DungeonWarriorDemo.exe
• https://hyperionbeta[.]netlify[.]app (Feb 2026)
• https://www.dropbox[.]com/scl/fi/hrbi8psg6j123os5lg56t/HyperionV2.exe