An analytics engineer who builds debugging tools for Google's own tag ecosystem said he fell for a reverse-proxy phishing page that he reached through a Google search ad for the query "cloud console". David Vallejo, founder of Analytics Debugger, described the attack in a LinkedIn post published on October 7, 2026, according to the post's timestamp. The fake page was hosted on sites.google.com and sent logins to a lookalike domain, accounts.gtoosl.com.

In Short

Someone searched Google for the Google Cloud Console, clicked an ad near the top of the results, and landed on a copy of Google's login page that was secretly run by attackers. Because the ad and the page both sat on Google's own properties, the trap looked trustworthy enough to catch an experienced data professional. What changes is that an ad at the top of your search results pointing at a Google address can no longer be taken as proof that the login page behind it belongs to Google.

What the post describes

The account is short and specific. "So, I guess it had to happen at some point: I've been phished," Vallejo wrote. "More specifically, I fell victim to a reverse-proxy phishing attack through the Google Cloud Console, via Google Ads listings."

According to Vallejo, a Google search for "cloud console" returned, among the first results in the ad section, a listing that "may leads to a page hosted on sites.google.com that perfectly replicates the Google Cloud Console homepage." He attached a screen recording to the post. The capture visible in the LinkedIn post shows a Google-branded sign-in panel inside a browser window, though the recording itself was not part of the material reviewed for this article.

Clicking Login on that page, according to Vallejo, redirected him to accounts.gtoosl.com. He said the domain sits behind Cloudflare at the IP address 188.114.96.5 and "appears to have been registered in August through a Hong Kong-based registrar." The post does not give a day in August, the registrar's name, or the advertiser name attached to the ad.

Vallejo said he noticed "almost immediately" and changed his password. He did not say in the post whether any account data, OAuth grants, or billing settings were changed by the attackers, and he did not report a loss.

He also tried to rule out his own machine as the cause. The attack was "tested on a brand new installed Firefox instance," Vallejo wrote, which in his words "kind of eliminated the change of this being just an issue with the my setup, any compromises extension, etc." That test addresses one obvious objection: that a malicious browser extension, rather than a paid listing, sent him to the fake page.

How a reverse-proxy phishing page works

Traditional phishing pages are static copies. They capture whatever a victim types and then usually fail, because they cannot talk to the real service. A reverse-proxy kit removes that weakness by sitting between the victim and the genuine site, a version of the man-in-the-middle position that security researchers have described for decades.

Vallejo summarised the flow in a single line: "You → attacker → Google." The attacker, he wrote, "then proxies Googles responses back to you, making the site behave almost exactly like the real Google pages." Because the real Google login server is answering, the pages that appear, including prompts for a second factor, are the genuine ones, merely relayed.

That is the mechanism that makes such attacks dangerous for anyone holding admin rights over advertising or cloud accounts. A relay can see the password as it passes through. It can also see a one-time code typed into a relayed prompt, and the session cookie that Google issues once login succeeds. Vallejo was careful not to overstate what he could prove: the setup allows "the page can look and behave normally while potentially allowing the attackers to intercept information passing through it."

He also found subdomains mapped to different Google surfaces. "They also use domains such as play.gtoosl.com and accounts.gtoosl.com to proxy different parts of the Google experience," according to the post. Separate hostnames for separate Google properties suggest a kit configured to relay more than one Google service, rather than a single cloned page.

The weak point in the attacker's design

There is one control that a relay of this type cannot easily pass. A passkey is bound cryptographically to the domain it was created for, so a browser will not offer a passkey registered to google.com on a page served from gtoosl.com. Vallejo's own list of checks includes making sure 2-Step Verification is enabled, "preferably with a passkey or security key." SMS codes and authenticator-app codes, by contrast, are just numbers that a proxy can forward.

Google Ads has already moved part of the way. Starting July 15, 2026, Google Ads required a passkey for certain sensitive account actions, covering account linking updates and user access changes. Ordinary logins were not covered by that requirement, and Google Cloud Console is a separate product with its own access controls. A stolen session for a Google account could therefore still open doors that the July 15 rule does not guard.

The domain trail

Vallejo pointed to three signals that, in hindsight, might have stopped him. "There's an obvious clue in the domain name 'gtoosl.com' is a typo designed to look like google like stuff," he wrote. "Unfortunately, I wasnt paying attention to the URL after clicking Login."

The second signal was the registrar. A domain registered in August 2026 through a Hong Kong-based registrar is young, and young domains are a common feature of phishing infrastructure. The third was the hosting arrangement. According to Vallejo, "having the domain registered on a non-usual registrar, and using Cloudflare are not good points either." Cloudflare operates one of the largest CDN and reverse-proxy networks on the internet, and placing a domain behind it hides the address of the origin server from anyone looking up the domain. The IP address Vallejo listed, 188.114.96.5, belongs to Cloudflare's network rather than to the attacker's own machine, which means it identifies the shield, not the operator.

The same pattern turned up in a separate case covered by PPC Land earlier this year. In April, a fake client inquiry sent to a Google Ads agency used a look-alike domain registered on April 7, 2026, three days before the email arrived, and the domain redirected to the real company's website to survive a casual check. Fresh registrations, near-miss spellings, and redirects to legitimate properties recur across both incidents.

Why Google Sites matters

The first hop in Vallejo's account was not gtoosl.com. It was sites.google.com, Google's free website builder. That detail shifts the question from whether Google's ad systems can spot a suspicious domain to whether they can spot a malicious page hosted on Google's own domain.

An ad whose display URL and landing page both point to a google.com address carries borrowed credibility at every step. A searcher looking for a Google product sees a Google address, lands on a Google-hosted page, and only leaves Google's domain at the moment of login, the step where attention is lowest. Vallejo's account shows that sequence working on someone whose day job is inspecting how Google's tags and pages behave.

One commenter said he had seen the same structure elsewhere. "I've seen other phising sites following the same google sites pattern," wrote Rick Dronkers, who describes his work as data engineering for performance advertisers. "I think the google sites logic is being used to rank higher in SEO somehow and get the google credibility." Dronkers framed the ranking explanation as a guess, and nothing in the post shows how the ad was approved or how long it ran.

What the post also does not include is the ad itself. There is no ad text, no advertiser name, and no screenshot of the search results page. Without those, it is not possible to establish from this source whether the advertiser account was newly created, compromised, or verified, or whether the ad ran in one country or many. Vallejo's account is the testimony of one user, and Google had not responded in the comments visible in the captured post.

How the analytics community responded

The post had 40 reactions and 8 comments at the time it was captured on October 9, 2026. The visible replies split between alarm and a familiar argument about ad blocking.

Stéphane Hamel, a marketing, data and privacy strategist, took the second route. "Maybe one more reason to use Brave and an ad blocker! I don't see Google ads, so no chance of falling for something like this," he wrote. Yehoshua Coren, who signs as Analytics Ninja, replied with a single word: "Wow." Balazs Vajna, head of analytics at MarketingLens, followed: "indeed. Wow. Thanks David for flagging this!"

Coren later tagged Ginny Marvin, Google's Ads Product Liaison, directly. "while clearly Google Ads is too large of an attack surface to seal hermetically, imho it's worth it if you could pass this back to the security team who might be able to add additional checks to their systems to catch bad actors like this," he wrote. No reply from Marvin appears in the captured thread.

Marvin has addressed similar questions before. When agencies reported fake client leads in April, she described phishing as a common route to unauthorised account access and pointed to marking suspicious emails as spam.

What Vallejo said he checked

Vallejo closed with a list of checks for anyone who "recently logged into Google Cloud Console through a search result." According to the post, they were: review recent security activity and signed-in devices; check and revoke any suspicious third-party or OAuth access; make sure 2-Step Verification is enabled, preferably with a passkey or security key; change the password anywhere else it was reused; and check Gmail for unexpected forwarding rules, filters, delegates, or recovery changes.

The Gmail item is the least obvious and arguably the most telling. Forwarding rules and delegates persist after a password change. An attacker who sets one up during a short window of access keeps receiving mail, including password reset messages, long after the victim believes the incident is closed. OAuth grants behave the same way: a token issued to a malicious application does not depend on the password and survives its reset.

The wider record on Google ad safety

Google publishes enforcement totals once a year. Its 2025 Ads Safety Report, released in April 2026, said the company blocked or removed more than 8.3 billion ads and suspended 24.9 million advertiser accounts during 2025. Of those, 602 million ads and 4 million accounts were tied to the violations most closely associated with scams. Account suspensions fell about 36% from 39.2 million in 2024.

Those totals measure what was caught, not what got through. In September, an analysis distributed by the Video Advertising Bureau set Google's 3.3 million US advertiser account suspensions against 86,800 brand advertisers on television and noted that Google does not disclose how long violating ads ran or how many people saw them. On Google's own statement that more than 99% of violating ads were stopped before serving, as many as about 83 million could still have reached users. A single Cloud Console phishing listing is one data point inside that unmeasured remainder.

Impersonation has been a stated enforcement target for some time. In February 2024, Google said it would suspend accounts impersonating public figures, brands or organisations immediately and permanently, without prior warning, with enforcement from March 2024. An ad that steers searchers for a Google product to a clone of a Google login page would appear to fall squarely within that policy. So why did it appear at all, and for how long? The source does not say whether it was caught, or when.

Regulators are watching the same gap. In July, Ofcom opened a consultation on nearly 40 draft measures for a fraudulent advertising code of practice, estimating that UK victims lose more than 200 million pounds a year to fraud-related ads. The code covers paid-for advertising on the largest services, with maximum penalties of 18 million pounds or 10% of global revenue. Ofcom's feedback deadline was October 2, 2026, five days before Vallejo's post. Litigation is moving in parallel: in April, the Consumer Federation of America filed a class action against Meta over scam ads, citing internal projections that about 10% of Meta's 2024 revenue came from scam and banned-goods ads.

Malicious advertising in the open web has also grown more technical. In August, PPC Land covered SourTrade, a campaign that assembled malware inside victims' browsers and ran programmatic ads in 12 countries, impersonating TradingView, Solana and Luno. Back in September 2024, the Morphixx scam routed requests through Google's ad server while fingerprinting users before deciding what to show them.

Account security as an advertising problem

For the people who run media budgets, the target here is not the consumer. A practitioner searching for "cloud console" is, by definition, someone who administers Google infrastructure. Analytics engineers, tag managers and paid media specialists often hold access to Google Cloud projects, BigQuery exports, Google Analytics properties, and linked Google Ads accounts under the same Google identity. One captured session can reach all of them.

Google has spent 2026 tightening the controls around advertiser accounts specifically. In February, Google Ads users questioned a support form clause that authorised specialists to make account changes directly, without a separate confirmation step. In July, Google Ads began requiring a second administrator to approve the removal of a user's access, a day before the passkey rule for sensitive actions took effect. Both changes assume the attacker is already inside the account. Vallejo's case concerns the step before that: how a credible-looking route to the login page is bought.

There is a further irony that the post leaves unstated. Vallejo is not an inexperienced user. PPC Land covered his open-source library for capturing ad click identifiers such as gclid, fbclid and msclkid in March 2025. Someone who inspects how Google's tracking parameters move between pages still followed a paid listing to a counterfeit login, because every visible signal before the Login button pointed to Google.

What remains unverified

Several elements of the account rest only on Vallejo's description. The registration month, the registrar's location, and the Cloudflare address come from his own lookups; the post does not include WHOIS output. The claim that the kit is a reverse proxy is presented with hedging ("it appears to use a reverse proxy"). The listing is described as appearing among the first results in the ad section, but the text also says it "may" lead to the Google Sites page, which leaves open whether the redirect was consistent for every click. The post contains one stray character ("Hong Kong-based registrar. Y") that appears to be a typing slip.

None of that undercuts the core of the account, which is first-hand and was posted publicly under Vallejo's own name. But the advertiser identity, the duration of the campaign, the number of people who clicked, and whether Google has removed the ad are not known from the source.

Timeline

Summary

Who: David Vallejo, founder of Analytics Debugger and an analytics engineer, along with commenters Stéphane Hamel, Yehoshua Coren, Balazs Vajna and Rick Dronkers. Google, as operator of Google Ads and Google Sites, and Ginny Marvin, Google's Ads Product Liaison, who was tagged in the thread.

What: Vallejo said a Google search ad for "cloud console" led him to a cloned Google Cloud Console homepage hosted on sites.google.com, which sent him at login to accounts.gtoosl.com, a Cloudflare-fronted domain he believes runs a reverse-proxy phishing kit. He said he noticed almost immediately and changed his password.

When: The LinkedIn post was published on October 7, 2026. The domain was registered in August 2026, according to Vallejo, and the post was captured with 40 reactions and 8 comments on October 9, 2026.

Where: In Google Search ad results, on Google Sites, and on the domain gtoosl.com and its subdomains, including play.gtoosl.com. The registrar is described as Hong Kong-based.

Why it matters: The people most likely to search for "cloud console" are the ones who administer Google Cloud, Analytics and Ads accounts. A paid listing that keeps victims on Google's own domain until the moment of login undercuts the URL checks that practitioners rely on, and Google's published enforcement figures do not show how long such ads run before removal.