A Tale of the Most Sophisticated Spear Phishing Attack I’ve Ever Seen – Google Ads Hack

Last Thursday, I opened a support ticket labeled with the all-too-familiar subject line:
“HELP!! User’s account has been hacked!!! URGENT!”

My first thought was, “This is probably just another case of a browser pop-up saying something like, ‘You’ve been hacked!’ or ‘Your computer has 52 viruses! Call Microsoft Support at 555-5555.’”

If you work in IT, you know the drill. Nine out of ten times, you dismiss these incidents with a simple, “Close the window and move on.” I was ready to do just that. (Foreshadowing, anyone?)

I contacted the user via Teams and asked them to share their screen. What I saw wasn’t a typical scareware pop-up—it was the Google Ads dashboard.

For those unfamiliar, Google Ads is a platform where users can create and manage ad campaigns that appear at the top of search results when specific keywords are searched (e.g., “Show my bike shop’s ad whenever someone searches for ‘bikes.’”). Our company relies heavily on Google Ads to manage hundreds of thousands of dollars in ad spend for our clients.

The user showed me that one of the campaigns had its daily spending limit set to $10,000, with $380 already charged to the account. Alarm bells went off. We immediately paused the campaign to prevent further charges and began investigating.

This was no fake virus pop-up. Someone had compromised the account.

The Investigation Begins

We quickly discovered that a specific user’s account had made the changes, increasing spending limits and creating new campaigns. We suspended the account, revoked all active sessions, and began auditing their activity logs.

Here’s where things got puzzling: all user accounts in our environment are protected with multi-factor authentication (MFA), and the affected user had MFA enabled for nearly five years.

How did someone bypass MFA?

Tracing the Logs

The user’s typical login location was Ontario, but the logs showed suspicious activity originating from Brazil during our company’s holiday break. When I asked the user if they had traveled to Brazil over Christmas, they laughed and said, “No.”

Digging deeper, I found that the unauthorized logins successfully used both the correct password and SMS-based MFA.

“How is this even possible?” I asked again.

Google Workspace support confirmed that the logs showed an SMS MFA challenge had been sent—and approved. When I asked the user about it, they looked at their SMS app and saw that there was in fact a SMS that came in at this time but insisted they hadn’t shared it with anyone. They’d undergone security training and knew never to disclose MFA codes, even to IT.

Still, somehow, the attacker had obtained and used the code.

A Deeper Look

Then, I noticed something troubling in the account settings: the attacker had added a passkey to the account and linked it to an iCloud Keychain. This meant they had a permanent, device-independent backdoor to the account—so long as they had access to that iCloud account.

Then the realization hit hard: the attackers had been in the account for over eight days!

Finding the Fraudulent Campaigns

In the admin logs, I identified three new ad campaigns created by the attackers. While we quickly found one, the remaining two were harder to track because the logs didn’t specify which Google Ads accounts were involved.

To complicate matters, someone on the user’s team had overzealously removed their access to all their managed ad accounts—making it impossible to trace their previous activity.

Using a break-glass account, I reset it’s password and got ready to log into a few accounts to look at logs.

The Phishing Trap Revealed

During this process, I encountered a key turning point. I had no idea what the URL was for Google Ads was so I Googled “Google Adwords,” clicked the first sponsored link, and landed on what appeared to be the official Google Ads login page. I Clicked Sign In in the top right and just as I was about to type in the break-glass account credentials, the user shouted, “Wait, stop! Look at the URL.”

Sure enough, I was NOT on Google Ads.

How did I get here? I backed up a step to look at the Google Ads page. I looked at the address in the URL bar and it was green and secure but The URL started with sites.google.com/...—a Google Proptery, but not the actual Google Ads platform. It was an impeccable replica, complete with SSL encryption and perfect design, hosted on Google’s own infrastructure.

It hit me like a ton of bricks:

The attackers had created a fake Google Ads login page using Google Sites.
They ran a malicious ad campaign targeting users searching for “Google Ads.”
The vanity URL in the ad displayed ads.google.com, but the link redirected to their fake site.

How the Attack Worked

Here’s the chilling breakdown of their spear-phishing attack:

Malicious Ad Setup
- The attackers gained access to a legitimate Google Ads account, used it to create fraudulent ads, and targeted users searching for “Google Ads.”
- Google Ads allows you to create a Vanity URL for the Ad. This is the URL that show to the user on the search page. When you click on this ad it actually uses a different URL provided by the user that has all the tracking information in it so they can track click throughs. It’s a really ugly URL and no one wants that showing on the search page so that why you use a vanity URL. Google Ads does have rules in place for these vanity URLS , the vanity URL MUST be in the same domain as the redirect link is pointing to. Users cannot create a vanity URL saying the ad is from ads.google.com but when they click it goes to badsite.org. The malicious add was able to use ads.google.com because the site they were redirecting to was sites.google.com. They are in the same domain so this was trusted and allowed. This is how they were able to use this vanity URL and trick people into thinking this was a real Google Ad
Fake Login Page
- Their Google Site mimicked the Google Ads login page perfectly, even mirroring dark mode settings if you had it enabled.
Man-in-the-Middle (MitM) Login
- When a victim entered their username and password, the attackers relayed it to the real Google login server.
- The real server responded with a 2FA challenge, which the attackers would process and forwarded to the victim.
- When testing the login process took a lot longer then normal to process each step of the login for obvious reasons now.
- When the victim entered the 2FA code, the attackers sent it to Google, gaining a legit session token.
Establishing Persistence
- Once they had a valid session, they used a replay attack on the Google account to add a passkey to the account, stored in an iCloud Keychain, giving them continuous access.
Exploiting the Compromise
- They increased ad spend limits, created fraudulent campaigns, and launched more malicious ads targeting new victims for Google Ads
- They Launched new campaigns targeting other sites like paying for parking tickets to steal credit card information when people search for “Pay for parking Ticket”

Aftermath and Lessons Learned

Over eight days, the attackers racked up over $13,000 in charges across three campaigns. Google Ads support has been an absolute nightmare, with repetitive requests for information and a lack of urgency. Seven days later, we’re still fighting for a resolution.

This attack was the most sophisticated phishing scheme I’ve ever encountered. The attackers weaponized Google’s own tools—Google Ads and Google Sites—to create an air of legitimacy that would fool even seasoned IT professionals.

Key Takeaways:

SMS-based 2FA is vulnerable. Consider transitioning to phishing-resistant MFA options like FIDO2 keys.
Monitor ad spend closely. A daily audit could help catch fraudulent activity sooner.
Educate users. Highlight the risks of phishing, even from URLs that appear legitimate.

This experience was frustrating, infuriating, and, in a strange way, impressive. It was a stark reminder of how clever and determined attackers can be—and why we must remain vigilant.