Hackers Use Legitimate Gmail Feature to Hijack Accounts: How to Protect Yourself

Hello HaWkers, a new attack technique is worrying security experts: hackers are using a legitimate security feature of Gmail itself to hijack user accounts. What makes this attack particularly dangerous is that it doesn't exploit a technical vulnerability - it abuses a functionality designed to protect users.

Do you blindly trust security notifications you receive from Google? After reading this article, you might reconsider that trust.

How the Attack Works

The Feature Being Exploited

Gmail has a security feature that allows users to report when they believe they've lost access to their accounts. This system was created to help people who genuinely lost access to recover their accounts.

The normal feature flow:

1. User reports they lost access to the account
2. Google sends notification to connected devices
3. Notification asks to confirm if it's a legitimate attempt
4. If confirmed, recovery process is initiated

The problem:

• Hackers are abusing this system
• They send multiple recovery requests
• Create a sense of urgency and confusion
• Combine with social engineering by phone or email

Anatomy of the Attack

Phase 1 - Notification bombing:

• Attacker initiates multiple "recovery" attempts
• Victim receives dozens of security alerts
• Notifications look legitimate (come from real Google)
• Confusion increases with each notification

Phase 2 - Social engineering:

• Attacker calls victim posing as Google support
• Uses public information to seem legitimate
• Asks victim to "confirm identity"
• Requests verification code or notification approval

Phase 3 - Compromise:

• Confused victim approves recovery notification
• Or provides authentication code to attacker
• Attacker gains full access to account
• Changes password and recovery methods

Why It's So Effective

Psychological factors:

• Genuine Google notifications generate trust
• High volume of alerts causes fatigue and confusion
• Implied urgency in security messages
• "Support" call seems to resolve the problem

Technical factors:

• No technical vulnerability being exploited
• Anti-fraud systems don't detect malicious activity
• Emails and notifications are from legitimate Google domains
• Difficult to distinguish attack from real problem

Documented Cases

Victim Profile

This type of attack has been primarily targeted at:

Priority targets:

• Executives and entrepreneurs (access to corporate accounts)
• Content creators (accounts with many followers)
• Developers (access to code and infrastructure)
• People with cryptocurrencies linked to email

Recent statistics:

• 300% increase in this type of attack in 2025
• Average compromise time: 15 minutes
• Success rate: ~25% of attempts
• Average loss per victim: $12,000 (considering crypto and fraud)

Real Example

A software developer recently reported their experience:

"I received over 30 security notifications from Google in 10 minutes. My phone wouldn't stop vibrating. Soon after, I received a call from someone identifying as Google support. They said my account was under attack and needed to verify my identity. I almost fell for it - I only stopped because they asked for an SMS code, and I remembered Google never asks for that over the phone."

Warning signs that saved the victim:

• Request for SMS code over phone
• Excessive urgency in the call
• Request to click links sent by "support"
• Pressure to act immediately

How to Protect Yourself

Immediate Preventive Measures

Essential security settings:

1. Enable two-step verification (2FA)

   • Preference: Physical security key (Yubikey, etc.)
   • Alternative: Authenticator app (Google Authenticator, Authy)
   • Avoid: SMS as the only second factor

2. Configure secure recovery methods

   • Recovery email: use a different, well-protected email
   • Phone number: keep updated
   • Security questions: non-obvious answers

3. Review connected devices regularly

   • Access: myaccount.google.com/device-activity
   • Remove unknown devices
   • Do this monthly

4. Enable security alerts

   • Login notifications from new devices
   • Password change alerts
   • Suspicious activity warnings

Recognizing the Attack

Signs you're being attacked:

Digital indicators:

• Multiple security notifications in rapid sequence
• "Account recovery" emails you didn't request
• Login attempt alerts from strange locations
• Requests to approve unknown devices

Social engineering indicators:

• Unsolicited calls about your Google account
• Emails asking to click "security" links
• Urgent messages requesting immediate action
• Any request for verification codes

What to Do If Attacked

Step-by-step response:

1. Don't panic

   • Attackers count on your confusion
   • Breathe and assess the situation calmly

2. Don't approve any notifications

   • Ignore all recovery requests
   • Don't click links in suspicious emails
   • Don't provide codes to anyone

3. Don't answer calls about your account

   • Google rarely calls proactively
   • If you need support, initiate the contact
   • Use official channels (support.google.com)

4. Verify your account directly

   • Access gmail.com by typing yourself
   • Check recent account activity
   • Change your password if necessary

5. Report the incident

   • Use the "It wasn't me" option on suspicious notifications
   • Report phishing to reportphishing@google.com
   • Consider alerting your organization if corporate account

Google's Role

Company Response

Google has spoken about the problem:

Measures already implemented:

• Rate limiting on recovery requests
• Abuse pattern detection
• Improvements to security notifications
• User education about social engineering

Recognized limitations:

• Difficult to distinguish legitimate use from abuse
• System needs to work for real recoveries
• Social engineering is hard to detect technically
• End users are the weakest link

Responsibility Debate

Critics' arguments:

• Google should have more aggressive rate limits
• Notifications should be clearer about risks
• Additional verification for suspicious recoveries
• Better education integrated into products

Google's defense:

• System works for most legitimate cases
• Excessive restrictions would block real users
• Fundamental problem is social engineering, not technical
• Continuous investment in security

Lessons for Developers

This case offers important insights for those developing authentication systems.

Recovery System Design

Principles to consider:

• Intelligent rate limiting (not just numerical)
• Abuse pattern detection
• Notifications that educate about risks
• Cooldown periods for multiple attempts

Important trade-offs:

• Security vs usability
• Protection vs accessibility
• Automation vs human verification
• Convenience vs security friction

2FA Implementation

Best practices:

• Offer multiple second factor methods
• Prioritize phishing-resistant methods (FIDO2/WebAuthn)
• Educate users about risks of each method
• Implement secure fallbacks for device loss

The Future of Authentication

Emerging Trends

Passwordless authentication:

• Passkeys (FIDO2/WebAuthn) gaining adoption
• Biometrics as primary factor
• More accessible physical security keys
• Gradual elimination of traditional passwords

Persistent challenges:

• Social engineering will always be possible
• Account recovery continues to be a weak point
• Balancing security with accessibility
• Large-scale user education

Recommendations for Organizations

For companies:

• Implement SSO with secure providers
• Train employees regularly about phishing
• Use MDM solutions for corporate devices
• Have clear process for security incidents

For individual developers:

• Separate personal from professional accounts
• Use password manager
• Enable 2FA on all critical services
• Maintain backups of recovery codes

Conclusion

The attack that exploits Gmail's recovery feature is an important reminder: security is not just about technology, but also about human behavior. Attackers are constantly looking for ways to bypass technical protections through social engineering.

As developers, we have the responsibility to create systems that are not only technically secure, but also guide users toward safe behaviors and protect them against manipulation.

If you want to deepen your knowledge about web application security, I recommend checking out the article 7-Year Malicious Campaign: Backdoors in Chrome and Edge Extensions which explores another increasingly common attack vector.

Let's go! 🦅