Attackers Use Stolen Contact Data and Phone-Based Impersonation to Breach Microsoft 365 and Google Accounts

Cybercriminals are increasingly relying on coordinated social engineering attacks powered by stolen contact information, using phone calls, spoofed emails, and legitimate cloud alerts to trick victims into granting access to Microsoft 365 and Google accounts. These multi-channel impersonation campaigns bypass traditional phishing indicators and exploit human trust rather than software vulnerabilities.

Microsoft researchers have been tracking phone-based social engineering attacks since May 2026. Attackers call or text employees on their personal phones while posing as internal IT staff, creating urgency around supposed passkey, MFA, or SSO configuration issues. Because the initial contact happens on unmanaged personal devices, investigators often have little evidence beyond the victim recalling the call.

Attackers gather staff details from public sources, including professional networking sites, and sometimes use already compromised accounts to message coworkers through Microsoft Teams. They also register generic domains that embed the target organization's name as a subdomain, creating URLs that appear familiar at first glance.

Once inside a Microsoft 365 account, attackers focus on persistence. They register their own phone number, authenticator app, or software-based one-time password token under the compromised identity. This durable persistence mechanism allows them to approve future login challenges without the real user involved. With access secured, attackers use Microsoft Graph to enumerate accounts, groups, admin roles, authentication methods, and connected applications. They then quietly pull files and email from SharePoint, OneDrive, and Exchange, often for days or weeks, while keeping activity below usage thresholds to avoid detection.

In parallel, attackers are running multi-channel impersonation scams that mimic Google Support. These operations begin with stolen contact data from breaches, such as the supply-chain incident involving Trezor's shipping partner ShipMonk, which exposed names, phone numbers, email addresses, and physical addresses of more than 80,000 customers. Because attackers know these individuals own hardware crypto wallets, the leaked data becomes a highly targeted roadmap for exploitation.

Armed with accurate personal information, attackers trigger a legitimate Google security event, such as a password reset or an attempt to add a forwarding address. This causes Google to send a real verification code or automated alert to the victim. Moments later, the attacker calls, spoofing caller ID to appear as Google Support. They reference the victim's name and the exact email that just arrived, creating immediate credibility.

Attackers also send spoofed emails pretending to be from the Google Security Team. These messages often include a case number and links to real Google support pages. However, email header analysis reveals SPF failures and non-Google sending servers, proving the messages are forged. The spoofed email is used to anchor the phone call and make the impersonation feel legitimate.

During the call, attackers claim that another email address has already accessed the victim's account and that they verified this using the victim's photo ID. They then ask the victim to read back the six-digit verification code they just received. If the victim provides the code, they bypass Google's security on the attacker's behalf, granting full account access. In some cases, attackers escalate further by requesting photo ID, claiming it is needed to "confirm removal" of unauthorized access. This is a direct attempt at identity theft.

Attackers often use California phone numbers that are not associated with Google, and Google does not make unsolicited security calls, does not ask for verification codes over the phone, and does not request photo ID through live calls. When victims question the legitimacy of the email or mention SPF failures, attackers dismiss concerns and attempt to maintain control of the conversation.

These attacks succeed because they combine legitimate system alerts with high-pressure phone calls, creating cognitive overload that prevents victims from verifying the caller's identity. The strongest defense is a hard boundary: never read verification codes aloud, never provide photo ID, never click links in unexpected security emails, and verify any alerts only by logging directly into the account through a trusted browser or official app.

Security experts warn that organizations should focus on detecting malicious behavior and strengthening identity-based controls rather than relying solely on blocking known phishing URLs. Phishing-resistant MFA, managed-device requirements, and careful monitoring of OAuth flows, redirect chains, and unusual Graph API activity are essential to counter these evolving threats.