The Meta 2FA Trap: From Verified Badge to Account Takeover

What Happened

Scammers are sending fake emails pretending to be from Meta (the company behind Facebook and Instagram), claiming a user's page has been approved for a 'verified blue badge.' The email links to a convincing fake website that tricks users into entering their username, password, and even the one-time security code (two-factor authentication code) sent to their phone — handing attackers everything needed to break into their account within seconds. This affects Facebook and Instagram page owners and business account holders, and is especially dangerous because even users who have extra security enabled (two-factor authentication) can still have their accounts stolen. Users should not click verification links received via email and should instead log in directly to their Meta account to check for any legitimate notices; organizations should report suspicious emails and train staff to recognize fake brand impersonation messages.

Key Takeaways

• Attackers impersonate Meta's verification system using a Gmail sender with display name 'Meta Verified' to lure Facebook/Instagram page administrators.
• The attack chain abuses legitimate platforms (Google Forms, Vercel) as intermediate redirect and hosting stages to evade email security filters.
• The phishing kit captures 2FA tokens in real time (adversary-in-the-middle style), allowing near-immediate account takeover before tokens expire.
• The phishing landing page at verifybadge-trustix.vercel.app mimics Meta's privacy center with convincing branding including Meta logo, blue badge imagery, and Facebook/Instagram UI elements.
• PII collected includes full name, email address, business email, Facebook page name, phone number, and date of birth in addition to credentials and 2FA codes.

Affected Systems

• Meta (Facebook) page administrators and business account holders
• Instagram account holders
• Any platform user targeted via email (Windows/macOS/mobile — platform-agnostic)
• Organizations using Meta Business Suite for marketing or communications

Attack Chain

The attack begins with a phishing email sent from a Gmail account displaying the name 'Meta Verified', with subject line 'Verification Approved Result', targeting Meta page administrators and directing them to click an embedded Google Forms URL. The Google Form (Stage 1) is styled with Meta Verified branding and includes a secondary link redirecting the victim to a Vercel-hosted phishing page at verifybadge-trustix.vercel.app/privacy-center, which mimics Meta's privacy center. The Vercel page (Stage 2) first collects PII (full name, email, business email, Facebook page name, phone, date of birth), then presents a fake Facebook password prompt, and finally displays a convincing fake two-factor authentication dialog requesting the victim's TOTP or SMS code. The captured credentials and 2FA token are exfiltrated to the threat actor in real time, who immediately uses them to authenticate to the victim's legitimate Meta account and take control before the time-limited token expires.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

The article provides no detection rules of any type. Detection guidance is limited to IOC tables (URLs and IPs) and behavioral indicators described in prose. Organizations should use the provided IOCs to build custom detections in their email security gateway, proxy, and SIEM platforms.

Detection Engineering Assessment

EDR Visibility: Low — This is a purely browser-based, social engineering phishing attack with no malware, scripts, or executables deployed on the endpoint. EDR tools have minimal direct visibility into credential submission via web forms. Network Visibility: Medium — Network proxies and DNS resolvers can detect and block connections to the known phishing URLs and IPs. However, the use of HTTPS and legitimate cloud platforms (Google Forms, Vercel) complicates traffic inspection without SSL inspection capabilities. Detection Difficulty: Hard — The campaign abuses fully legitimate services (Gmail, Google Forms, Vercel) for each stage of the attack chain, making domain/IP reputation-based detections unreliable. The HTTPS encryption of phishing pages and use of cloud infrastructure with valid TLS certificates further evades standard network security controls. Detection relies primarily on behavioral analysis of email content and URL patterns.

Required Log Sources

• Email gateway logs (sender address, display name, embedded URL analysis)
• DNS query logs (lookups for verifybadge-trustix.vercel.app)
• Web proxy / secure web gateway logs (HTTP/HTTPS connections to known IOC URLs and IPs)
• Browser history or DLP telemetry (form submissions to Google Forms or Vercel-hosted pages)
• Identity provider / SSO logs (anomalous Meta/Facebook authentication events from unexpected IPs or geolocations)

Hunting Hypotheses

Hypothesis	Telemetry	ATT&CK Stage	FP Risk
Hunt for outbound DNS queries or HTTP/HTTPS connections to Vercel subdomains (vercel.app) that contain keywords commonly used in brand impersonation phishing, such as 'verify', 'badge', 'meta', 'privacy-center', or 'trusted' in the subdomain or path, particularly from users who recently received emails containing Google Forms short-links (T1566.002).	DNS query logs, web proxy logs, email gateway URL extraction logs	Initial Access	Medium — legitimate applications are deployed on Vercel; keyword matching should be combined with email correlation to reduce false positives
Hunt for users who submitted data to Google Forms URLs (forms.gle short-links or docs.google.com/forms) shortly after receiving an email from a Gmail sender with a display name containing 'Meta', 'Facebook', 'Instagram', or 'Verified' (T1566.002, T1598.003).	Email gateway logs correlated with web proxy logs or browser telemetry	Initial Access / Credential Access	Low — the combination of Gmail sender impersonating Meta and form submission is a strong signal
Hunt for Meta/Facebook account login events originating from IP addresses or geolocations inconsistent with a user's normal baseline, occurring within a short time window (e.g., under 5 minutes) after the user's known location submitted credentials — indicative of real-time AiTM credential replay (T1557, T1078).	Identity provider logs, Meta Business Suite audit logs, CASB telemetry	Credential Access / Account Takeover	Low — impossible travel or near-simultaneous logins from different IPs is a strong AiTM indicator
Hunt for emails where the sender display name contains brand names ('Meta', 'Facebook', 'Instagram', 'Verified') but the actual sending domain is a free webmail provider such as gmail.com, yahoo.com, or outlook.com — a classic display name spoofing technique (T1566.002).	Email gateway logs, DMARC/DKIM/SPF validation results	Initial Access	Low — legitimate Meta communications will originate from meta.com or facebookmail.com, not Gmail
Hunt for browser-based form submissions containing password or authentication code field data directed to non-Meta domains (i.e., any domain other than meta.com, facebook.com, or instagram.com) when the page content claims Meta or Facebook branding — indicative of credential harvesting pages using legitimate hosting providers (T1583.006).	DLP solutions with web content inspection, browser isolation platforms, secure web gateway with SSL inspection	Credential Access	Medium — requires SSL inspection and content-aware DLP; may generate false positives on legitimate OAuth flows if not properly scoped

Control Gaps

• Standard email spam filters that rely on sender domain reputation will not flag Gmail-origin phishing emails with deceptive display names
• URL reputation engines that allowlist Google Forms (forms.gle) by default will not block Stage 1 redirect links
• Web proxies or firewalls that allowlist Vercel (vercel.app) as a legitimate cloud platform will not block the Stage 2 phishing payload
• Traditional 2FA/TOTP implementations do not protect against real-time AiTM token capture and replay — FIDO2/passkey-based authentication is required to resist this attack class
• User security awareness training that only teaches users to 'check for HTTPS' or 'look for the padlock' will not detect this attack, as all stages use valid TLS certificates on legitimate platforms

Key Behavioral Indicators

• Email sender display name claims 'Meta', 'Facebook', or 'Meta Verified' but envelope From/Reply-To domain is a free webmail provider (e.g., gmail.com)
• Email body contains a Google Forms short-link (forms.gle) as the primary call-to-action URL rather than a meta.com or facebookmail.com domain
• Outbound web request to a vercel.app subdomain containing terms like 'verifybadge', 'trustix', 'privacy-center', or similar Meta-impersonation keywords
• User browser navigating to a non-Meta domain that renders Facebook logo, Meta Verified blue badge imagery, or Facebook password prompt UI elements
• Meta account login event from an IP address geographically inconsistent with the authenticated user's normal location, occurring within minutes of a phishing email receipt
• DMARC/DKIM/SPF failure or alignment mismatch on email claiming Meta Verified origin

False Positive Assessment

• Low — the combination of a Gmail sender impersonating Meta, a Google Forms redirect, and a Vercel-hosted credential harvesting page with specific subdomain keywords is highly specific to this attack pattern. Legitimate Meta communications originate from meta.com or facebookmail.com domains, not Gmail, and do not route through third-party form or hosting platforms for credential collection.

Recommendations

Immediate Mitigation

• Block the known phishing IOCs at email gateway and web proxy: URLs https://forms.gle/cV8Fbu9eNgHpdY1dA and https://verifybadge-trustix.vercel.app/privacy-center, and IPs 64.29.17.3 and 216.198.79.3
• Search email logs for messages with subject 'Verification Approved Result' or sender display name 'Meta Verified' originating from gmail.com and quarantine any identified instances
• Alert users who may have received and interacted with this email to immediately change their Meta/Facebook account passwords and review account activity for unauthorized access
• If account compromise is confirmed, revoke all active Meta sessions and connected third-party app tokens, and report the compromise to Meta's support team

Infrastructure Hardening

• Configure email gateway to flag or quarantine emails where the sender display name contains 'Meta', 'Facebook', or 'Instagram' but the actual sending domain is not meta.com, facebookmail.com, or instagram.com
• Enable DMARC enforcement (p=reject) on your organization's email domain to prevent display name spoofing attacks impersonating your own brand
• Consider deploying a Secure Web Gateway with SSL inspection to allow content-aware inspection of submissions to Google Forms or Vercel-hosted pages
• Implement CASB (Cloud Access Security Broker) to monitor and alert on anomalous Meta/social media authentication events from corporate users
• Migrate Meta Business Suite accounts to FIDO2 hardware security keys or passkeys, which are phishing-resistant and immune to real-time AiTM token capture

User Protection

• Enforce phishing-resistant MFA (FIDO2/passkey) for all Meta Business accounts rather than TOTP or SMS-based 2FA, which can be bypassed by real-time AiTM attacks
• Train users to always navigate to Meta account pages directly (facebook.com, meta.com) rather than clicking links in emails, even if the email appears official
• Advise users to verify Meta communications by logging into the Meta Business Suite directly and checking the notification center for any legitimate verification requests
• Instruct users to inspect the browser address bar URL before entering any credentials — legitimate Meta pages will always be on meta.com, facebook.com, or instagram.com domains

Security Awareness

• Brief page administrators and social media managers specifically on Meta Verified impersonation phishing, as they are the primary target demographic for this campaign
• Train users to recognize that legitimate companies (including Meta) will never ask for a 2FA code via a web form or email link — real 2FA prompts only appear on official login pages
• Educate users that a webpage appearing professional or displaying familiar logos does not confirm its legitimacy; always check the domain in the address bar
• Include this campaign as a case study in phishing simulation programs to test whether users can identify multi-stage, brand-impersonation attacks using legitimate infrastructure
• Establish a clear internal reporting process for suspected phishing emails so security teams can rapidly triage and block new phishing campaigns before widespread user interaction

MITRE ATT&CK Mapping

• T1566.002 - Phishing: Spearphishing Link
• T1078 - Valid Accounts
• T1556.006 - Modify Authentication Process: Multi-Factor Authentication
• T1585.001 - Establish Accounts: Social Media Accounts
• T1550.004 - Use Alternate Authentication Material: Web Session Cookie
• T1583.006 - Acquire Infrastructure: Web Services
• T1598.003 - Phishing for Information: Spearphishing Link
• T1557 - Adversary-in-the-Middle

Additional IOCs

• Ips:
  • 199[.]36[.]158[.]100 - IP resolving Stage 1 Google Forms phishing URL
  • 64[.]29[.]17[.]3 - IP resolving Stage 2 Vercel phishing payload domain
  • 216[.]198[.]79[.]3 - Secondary IP resolving Stage 2 Vercel phishing payload domain
• Domains:
  • verifybadge-trustix[.]vercel[.]app - Attacker-controlled Vercel subdomain; hosts credential and 2FA harvesting pages
  • forms[.]gle - Legitimate Google Forms short-link domain abused as Stage 1 redirect to collect victim interaction before routing to Stage 2 payload
• Urls:
  • hxxps://forms[.]gle/cV8Fbu9eNgHpdY1dA - Stage 1 phishing URL; Google Form branded as Meta Verified used as initial lure
  • hxxps://verifybadge-trustix[.]vercel[.]app/privacy-center - Stage 2 phishing payload URL; Meta-branded page collecting PII, password, and 2FA token
  • hxxps://docs[.]google[.]com/forms/d/e/1FAIpQLSd3gBNAO5UIISandiJ9z1kp2rvcFHtg09DaUpYNK_eY03O_PQ/viewform - Full Google Forms URL visible in Figure 2 browser address bar; the Google Form impersonating Meta Verified invitation
• Other:
  • Sender display name: Meta Verified <[redacted]@gmail.com> - Phishing email sender uses Gmail account with display name 'Meta Verified' to impersonate Meta; not a legitimate meta.com address
  • Email subject: Verification Approved Result - Subject line used in the phishing email to create urgency and legitimacy around a fake Meta verification approval
  • Ref ID: WXL5EK9R - Fake reference ID included in phishing email footer to simulate official ticket tracking and increase perceived legitimacy
  • Ticket ID: #8U23-IL7F-3Y9N - Fake ticket identifier displayed on the Vercel phishing landing page to further simulate an official Meta support interaction