SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Threat Intel

Fake ad portals for six AI brands span 189 days; a drawn Google window relays passwords and MFA codes

Island reports a human-operated phishing platform that, behind a Connect button, draws a fake browser window with a trusted address bar and lets an operator choose each MFA prompt. It names six AI brands over 189 days; it states no victim count, loss or operator.

By Parminder Kumar Sharma · · 20 min read

A laptop on a marketing desk showing a blank browser window with a second, smaller blank window laid over it, and a sign-in form drawn as empty rounded pills with one teal button. A fan of plain colour swatches lies in front and a felt board of blank colour squares stands behind. Nothing carries any lettering.

189 days, six brands, one button: what Island dated and what it did not

Island, a browser security company, published a report on 6 October 2026 about what it calls a "human-operated phishing platform" that impersonates advertising products for AI chatbots. Its timeline of the earliest observations it retained runs from 11 March 2026, a Manus and Meta lure, to 16 September 2026, a Muse lure: 189 days (derived), six brands, and one repeated action, a button labelled Connect. Island has the Muse lure on the web by 16 September. That is no more than 8 days after Meta introduced Muse on 8 September, and at least 13 days before Meta's own page of 29 September said Muse can connect "Meta ad accounts in a few clicks" (day counts derived; the lure date is Island's, the other two are Meta's). The Island report is the primary here; The Hacker News and BleepingComputer carried it the same day.

What that does not establish.

  • A victim count. Island writes that it "saw hundreds of victim submissions to the platform". That counts submissions, not people and not accounts taken over, and it gives no period.
  • A loss. The report states no sum for this operation. Its price figures for stolen ad accounts come from Mimecast's research on ad-account theft in general.
  • Who runs it. No person, group or country is named. Island says the operation is human-operated and describes Telegram as a control channel in older code the operators exposed.
  • That any AI vendor's own account was taken. The brand names are costumes. The sign-ins the platform copies are Google, Meta, TikTok and Okta.
  • That UK people were reached. The report gives no country data.
  • That 16 September is the day the Muse site began. Island's dates "are the earliest observations we retained, not the first day each site operated". The Hacker News's "emerged on" is looser than that.

Stated and not stated

Island's report of 6 October 2026, read at about 21:20 BST. Counts marked derived are ours, from Island's indicator list and figures.

  1. Question
    What it is
    Stated by Island
    One platform behind AI ad products, refund claims and fake job sites, on one stack, calling the same endpoints. Operators can hold a victim on a waiting screen, reject a password, choose the next MFA prompt and redirect.
    Not stated
    Who runs it, where, or how many operators.
  2. Question
    Brands and sign-ins
    Stated by Island
    Six AI brands: Gemini, Claude, ChatGPT, Perplexity, Manus, Muse. Four sign-in workflows: Google, Meta, TikTok, Okta.
    Not stated
    Whether other brands were used. The indicator list holds names that suggest at least three more (derived); the text does not discuss them.
  3. Question
    Dates
    Stated by Island
    First retained sightings from 11 March to 16 September 2026. A Muse page capture of 19 September. One backend in 73 archived scans across 25 page domains from 27 May to 20 June. A recruitment page from July 2025.
    Not stated
    The first day any site ran. Whether any site is live now.
  4. Question
    Size
    Stated by Island
    An indicator list of 139 entries: 114 ads, 11 refund, 14 recruitment, 137 distinct because one backend address appears in all three lanes (derived). The ads lane has 89 domain names and 25 hosting addresses (derived).
    Not stated
    How many were live at once, or how many emails were sent.
  5. Question
    Victims
    Stated by Island
    "Hundreds of victim submissions". Targets: agency staff, media buyers and manager-account administrators; for job lures, applicants who may use a work Google or Okta identity.
    Not stated
    People affected, accounts taken over, countries, sectors, any named victim.
  6. Question
    Losses
    Stated by Island
    None for this operation.
    Not stated
    Any sum, any account resold, any spend.
  7. Question
    Delivery
    Stated by Island
    Invitation emails to these pages are documented by IRONSCALES and Intezer, which Island cites.
    Not stated
    How most victims arrived, or in what volume.
  8. Question
    MFA
    Stated by Island
    The operator can ask for another password, an SMS code, an authenticator code, a Google approval prompt, a QR payload, a tap number or an Okta push, reject a code, or finish. Island says the list "includes" these.
    Not stated
    Any command for a passkey or security key, or how the platform treats an account protected by one.
  9. Question
    Advice
    Stated by Island
    Verify AI integrations on the vendor's site. Inspect the outermost origin. Use origin-bound passkeys. Review advertising control changes after exposure.
    Not stated
    Any measured result of these steps.

The indicator list is why this briefing describes Island's infrastructure but does not print it: it holds 139 entries, they are in Island's report for defenders to block, and reprinting them here adds nothing a reader needs. Two details of Island's are worth keeping. The operators exposed source code for earlier versions through misconfigured public repositories, which is how Island traced the reuse. And one backend was seen in "73 archived scans across 25 page domains", serving AI ad lures, refund pages and a fake careers site: "A page selling an AI ads product and a page offering a fake job talked to the same server."

What the Connect button does, at the level a defender needs

The browser-in-the-browser technique is not new. The researcher who published it on 15 March 2022 framed it as a question: whether it is possible to make the "Check the URL" advice less reliable. His answer, on his own page, was a window drawn with ordinary web markup around an embedded page, "basically indistinguishable" from the real pop-up. That is the whole principle: the page paints a browser, and the address in the painted bar is whatever the page author chooses. Island's 2026 account is that principle sold as a product, with an operator attached.

A tall diagram in six boxes. The lure is an AI ads page with a Connect button. The real browser stays on the lure's domain while the page draws a second window with a trusted address. What is typed goes to the platform, which keeps up to three password attempts and fingerprints the device. An operator chooses the next screen, such as an SMS code, an authenticator code, a Google prompt or an Okta push, then tries the real account. A last box says a passkey is scoped to the real site's origin.
Drawn from Island's report of 6 October 2026 (text and its Figure 4) and the W3C WebAuthn specification, at mechanism level. Nothing here is a build step.

Island's wording for the key moment is plain: "Clicking Connect does not open Google. The page draws a fake Google window inside itself." A capture it shows has the real browser still on the phishing domain, with a second window inside it "complete with a lock icon and an address bar reading accounts.google.com". The fake adapts to Windows, macOS, iOS and Android, and "newer builds copy the small details as well": Safari's address pill, Chrome's custom tabs, a dark mode. A comment Island found in the bundle explains why one toolbar effect matters: without it, "the chrome looks painted-on and gives away the fake". That is a developer working against detection by eye (inference from the comment).

What is typed into the drawn form does not go to Google. Island says the client creates a record, fingerprints the device "from IP and location down to screen size and WebGL", and keeps up to three password attempts so an operator can reject one and ask again. Commands then arrive over a live channel while the victim waits, and the backend "chooses the next screen". Island's contrast is with a reverse-proxy kit: this platform "locally rebuilds the provider interface and collects credentials and MFA state through its own APIs", so the traffic looks like an AI product talking to an unrelated backend. The Hacker News adds that, armed with the credentials, the attacker "attempts to sign in to the account in real-time"; Island's Figure 4 says the same.

Operator commands described in Island's report, by function, against the NCSC's ranking of MFA types (corporate MFA guidance, 26 September 2024) and its passkeys blog (23 April 2026). Read 21:30 BST, 6 October 2026.

  1. Operator can ask for (Island)
    A passkey or security key prompt: no such command is listed
    NCSC rank of that type
    1 of 5: FIDO2 credentials
    What the NCSC says
    Gives "phishing resistance", with guessing and theft resistance.
  2. Operator can ask for (Island)
    A Google approval prompt, a tap number, an Okta push
    NCSC rank of that type
    2 of 5: challenge-based apps
    What the NCSC says
    "Only partial phishing resistance". The blog calls push approvals "inherently phishable".
  3. Operator can ask for (Island)
    An authenticator code, Google or Okta
    NCSC rank of that type
    3 of 5: app-based code generators
    What the NCSC says
    "Known to be vulnerable to the OTP interception phishing attack".
  4. Operator can ask for (Island)
    An SMS code
    NCSC rank of that type
    5 of 5: message-based methods
    What the NCSC says
    Only for when "no other strengthening method is possible"; also "inherently phishable" in the blog.
  5. Operator can ask for (Island)
    A QR payload to scan
    NCSC rank of that type
    Not ranked
    What the NCSC says
    Not addressed on the pages read.

Read down the middle column. Every prompt Island lists that the NCSC ranks sits below the NCSC's first choice, and the NCSC's own phrase for the attack is "convinced to enter their OTP code into a disguised phishing website". The table is our arrangement of two sources, not a finding by either. Island's list says "includes", so its absence of a passkey command is not proof there is none.

Three friendly names, and what each one does not control

The address bar. It is the one trust cue every user has been taught, and a drawn copy costs the attacker nothing. Island's advice is to inspect the outermost origin, and it is correct: "A page can draw an address bar, lock icon, browser tab, QR prompt, or security dialog. It cannot change the real browser origin." But the check only works for someone who can tell, while the page is busy imitating a browser, which edge of the screen is the real one. With newer builds copying the small details, an eyesight control is a race the attacker can keep running (inference). BleepingComputer adds that a drawn window cannot be dragged outside the browser or resized, unlike a real pop-up. Island's report, as read, does not say that, so it is reported here as BleepingComputer's claim and not offered as a control. The NCSC makes the general point about email phishing: widen defences "to include technical measures, with user education being just one aspect" (NCSC phishing guidance, reviewed 13 February 2024).

"MFA". It reads as a second barrier, and against a stolen password it is one. The NCSC's older consumer page says that with 2-step verification "even if a criminal knows your password, they won't be able to access your accounts"; it was last reviewed in January 2022 (NCSC 2SV guidance). Google's advertiser page says 2-Step Verification "can help keep bad actors out, even if your password has been compromised" (Google Ads Help). Both are true of a stolen password. Neither describes a code typed into a window the attacker controls, which is the case Island reports: the code is relayed while it is still valid. The NCSC's 2026 position is blunter. Its blog of 23 April says traditional MFA "remains fundamentally vulnerable to phishing because secrets or approvals can be observed and relayed during a live session" (NCSC blog). Fairness runs the other way too: the NCSC's corporate guidance still says "any implementation of MFA is still superior to reliance on passwords alone" (NCSC MFA guidance). Having MFA is not the failure. Treating it as the end of the question is.

The AI brand. The lure borrows names people already trust, and borrows the news cycle with them. Island's own advice is "Treat fictional AI integrations as account-access requests." Whether the name is a plausible advertiser product is the next section's question, and the answer differs by vendor.

The lure works because the real thing is new

Ads in AI chatbots, and AI tools that ask to connect to an ad account, are new enough that a reader cannot rule one out from the brand name alone. This site's brief 232 covers OpenAI's ads in detail. The table sets Island's earliest retained sighting for each brand against what that vendor's own pages say, all read between 21:21 and 21:36 BST on 6 October 2026.

Island's Figure 6 (earliest retained lure sightings, 2026) against vendor pages. Day gaps are derived. Treated alike: only what each page says, as read.

  1. Brand and lure date
    Manus x Meta, 11 March
    What the vendor's own page says
    Manus's help page: pick the Meta Ads Manager connector, click "Connect", authorise read-only access. Its blog post is dated Wednesday 18 March, no year shown.
    Gap
    Lure retained 7 days before the post
  2. Brand and lure date
    ChatGPT, 31 March
    What the vendor's own page says
    OpenAI's help page: ad testing "started in the United States on February 9, 2026", Free and Go plans. Its Ads Manager page lists the United Kingdom as available for self-service.
    Gap
    Lure 50 days after the test began
  3. Brand and lure date
    Claude, 29 April
    What the vendor's own page says
    Anthropic, 4 February 2026: "Claude will remain ad-free." The page says nothing of an advertiser portal.
    Gap
    Lure 84 days after the pledge
  4. Brand and lure date
    Gemini, 12 May
    What the vendor's own page says
    Google, 20 May 2026: new ad formats built with Gemini in AI Mode, labelled "Sponsored". Gemini Apps Help: a Google Ads account can be connected to Gemini Apps (page undated).
    Gap
    Lure 8 days before the 20 May post
  5. Brand and lure date
    Perplexity, 30 June
    What the vendor's own page says
    Perplexity's blog of 12 November 2024 announced ad experiments. No current page on its advertising position was found.
    Gap
    Not established
  6. Brand and lure date
    Muse, 16 September
    What the vendor's own page says
    Meta, 8 September: Muse is a personal AI agent, with no advertiser product in that post. 29 September: Muse can connect "Meta ad accounts in a few clicks"; "nothing publishes, sends, or spends without your approval".
    Gap
    Lure 8 days after launch, 13 before the 29 September page
A vertical timeline to scale from 4 February to 6 October 2026. Left: Island's first retained lure sightings for Manus and Meta on 11 March, ChatGPT 31 March, Claude 29 April, Gemini 12 May, Perplexity 30 June and Muse 16 September, 189 days in all. Right: vendor pages on 4 February (Anthropic), 9 February (OpenAI), 18 March (Manus), 20 May (Google), 8 September (Meta) and 29 September (Meta). Island reports on 6 October.
Dates from Island's Figure 6 and from the vendor pages in the table above. The Manus page shows no year; 18 March is a Wednesday in 2026 (derived).

Read plainly (our reading of the table): for four of the six brands, Manus, ChatGPT, Gemini and Muse, the vendor's own pages describe a real way to advertise, or to connect an ad account to an AI product. For one, Claude, the vendor has said it will not carry ads. For one, Perplexity, the current position was not established. Nobody can tell which is which from the brand name, and that gap is the lure's raw material. Anthropic's pledge concerns what users see inside Claude and does not discuss advertiser products, so a portal that sells placement in Claude would sit against it (inference). The same test, page by page, applies to every brand in the table. Two of the real flows use the word Connect too: Manus's help page and Meta's page both say "connect" for linking an ad account to an AI tool. A sign-in that begins with that word is ordinary.

Why an advertising account is the prize

Island says the lures are written for agency staff, media buyers and manager-account administrators, because an advertising account carries a stored payment method and an approved budget, and a manager account can reach several client accounts, each with its own billing profile and linked users. It adds: "For the victim, the card is the easy part: they can remove it within hours. Getting the account back is not." Its description of the aftermath is that attackers "typically add their own administrators and downgrade the legitimate owner", and recovery "can take weeks or months while the account keeps serving ads". Those are Island's statements about the category. The report does not say any victim of this operation lost an account, or how long a recovery took.

Mimecast's research of 28 July 2026 puts numbers on the market: 6.4 million detections over four years of the theft of Meta Business Manager and Google Ads accounts (detections, not victims), aged accounts with a clean spend history worth a premium of 2 to 4 times, and a conclusion that the "primary impact is the loss of account control rather than direct financial theft". Its controls overlap with the checklist below: least privilege, leavers revoked the same day, billing alerts to a monitored inbox.

IRONSCALES described on 9 September a message to a paid-media manager at a global advertising agency, offering early access to an AI advertising workspace under the sender alias "Gemini Ads". It passed SPF, DKIM and DMARC because the attacker had registered, and aligned, its own sending domain: "Nothing for a Header Check to Contradict", in IRONSCALES's heading. The page behind it was a clone of an AI chat interface whose send button read Connect; IRONSCALES did not see what happened after the click. Island cites IRONSCALES, but IRONSCALES's page, as read, does not say it is the same operation. Either way, a passing mail check shows the sender controls the domain it claims, not that the product exists.

What only a bound credential changes

The W3C WebAuthn specification, a Recommendation dated 25 August 2026, says each credential is "scoped to a given WebAuthn Relying Party" and "can only be accessed by origins belonging to that Relying Party", with the scoping "enforced jointly by conforming User Agents and authenticators". Applied here: a drawn window on another origin has no credential to ask for, and nothing a person could read out. The NCSC's blog says passkeys "remove this class of attack entirely by cryptographically binding authentication to the legitimate service". The FIDO Alliance, Google and Microsoft make similar claims on their own pages, as does Island: origin-bound passkeys "remove the reusable password and one-time-code material this platform is built to collect". On 23 April 2026 the NCSC said it will recommend passkeys wherever a service supports them (NCSC).

Three limits keep that from being a slogan. First, offering is not requiring. Google's own 2-Step Verification page for advertisers lists a security key beside a call, a text message, a Google prompt and an authenticator app. Turning 2-Step Verification on does not turn the weaker steps off. A manager account can mandate "2-Step Verification or Advanced Protection" for sub-accounts (Google), and Advanced Protection requires a passkey or security key but also "limits third-party app access to your data" (Google). Whether that suits an agency with many freelancers and tools is a judgement we cannot make for you. Second, recovery. A fallback that accepts a code is a door the operator can still ask for; this site's brief 248 covers Report Fraud's passkey campaign and brief 88 the GOV.UK One Login case, which keeps a phishable route open beside passkeys. Third, Island's report does not test it: how the platform behaves against an account a passkey protects is not stated, so that step rests on the design claims above (inference).

For UK teams that hold ad-account admin rights: the order worth doing

This applies to marketing teams, agencies, freelancers and charities running Google Ads, including accounts under Google Ad Grants, who hold administrator rights on an advertising account or a manager account. The order below is our judgement; none of the sources ranks these steps. The facts inside it are from the pages named.

Take this with you

Ad-account administrators: in this order

  • Inventory every advertising account and everyone with admin on it: Google Ads and its manager accounts, Meta business portfolios, TikTok, and the Google, Microsoft or Okta identities that unlock them. Include agencies, freelancers and any Ad Grants account.
  • Put a passkey or hardware security key on every admin identity first, then everyone else. The NCSC ranks FIDO2 credentials first and gives, as an example, administrators issued a hardware key that must be used for administrative interfaces. Where a platform lets you require it, require it, and check the weaker steps are off.
  • Plan recovery before enforcing. The NCSC says services should give clear ways to set up recovery options. Test what happens when a key is lost, and keep that route out of a text message.
  • Separate admin from daily work. Give each person their own sign-in and the least access the job needs, and remove leavers the same day. Google's Security Agent suggests downgrading an Admin who never uses admin actions, and the NCSC says people with administrator accounts should not use them to check email or browse the web.
  • Never sign in from a link in an ad, an invitation or a message. Type the vendor's address or use a bookmark. Treat any request to connect an ad account to an AI tool as an access request, approved by the account owner through the vendor's own site, as Island advises.
  • Use a password manager that recognises real sites. The NCSC notes some will not autofill on fake websites. Treat a manager that offers nothing as a warning (our reading, not the NCSC's wording).
  • Restrict who can be invited and linked. In Google Ads, set allowed email domains, check the Related managers tab for managers outside your hierarchy, and require 2-Step Verification or Advanced Protection across sub-accounts.
  • Set spend and role alerts you will read. Send billing and unusual-login alerts to a monitored shared inbox, review change history weekly (our interval), and watch for new admins, new manager links, raised budgets and new automated rules.
  • Write the incident steps now. Report the compromise to the platform at once. Google asks for timestamps of unauthorised user additions, unauthorised manager account IDs and evidence of budget increases or automated rules. Remove unknown users, end other sessions and reset sign-in details through the platform's recovery flow, review every client account the identity could reach, and tell clients if a manager account was touched.
  • Report it. Phishing emails go to the NCSC's Suspicious Email Reporting Service, scam websites to the NCSC's website form, scam ads to the ASA. If money is lost or an account is hacked, use Report Fraud.

What the platforms say about these steps. Google's compromised-account page says that on a confirmed compromise it pauses only campaigns the unauthorised user created or changed, removes the compromised users, unlinks unauthorised manager accounts, and sends a change log that only users who were Admins before the compromise date can approve. Its best-practice page says unremoved inactive users "can still sign in to your account and make changes", and its Security Agent page says "Most security issues happen because of stolen passwords from phishing". Meta's Security Centre page says two-factor authentication is required for business portfolios 90 days or older, and recommends more than one person with full control. These are the vendors' claims about their own tools, as read at 21:30 BST.

Method, commercial interest, and what we could not verify

Method. The Island report, The Hacker News, the NCSC pages, Meta's newsroom and the 2022 technique page were read in full with command-line requests and a browser User-Agent. BleepingComputer, the vendor pages and Report Fraud were read in a browser tab of our own, with the returned address checked. The W3C answered a command-line request with a challenge, which was not bypassed; the page loaded in an ordinary browser without one. Island's figures 4, 6 and 8 were read as images. The Hacker News and BleepingComputer are pointers: both follow Island. The technique is described only at the level of the public principle.

Commercial interest. Island sells an enterprise browser, and its report closes by saying so. Mimecast and IRONSCALES sell email security. Google, Microsoft and the FIDO Alliance's members promote passkeys, and Meta and others appear in the lures. Nothing here says any vendor has acted wrongly. Vendor pages are the vendors' claims.

What we could not verify.

  • Island's observations (archived scans, exposed code, the control channel). We did not visit any site or test any indicator.
  • "Hundreds" has no number. BleepingComputer ties it to a Telegram channel and cautions that it may not equal compromised accounts; Island's text, as read, says neither.
  • BleepingComputer's statement that a drawn window cannot be moved or resized.
  • The dates in Island's Figure 6 were read from the figure; the text itself gives only "By September 16" for Muse.
  • Perplexity's current advertising position, the year on Manus's blog post, and the launch date of Gemini's Google Ads connected app (the page is undated).
  • Intezer's page, which Island cites for invitation emails, was not read.
  • Session revocation is not named in the Google and Island pages read; it is our addition in the incident step.
  • Whether any lure reached UK recipients.

The question this leaves

Which of your advertising accounts could an operator still open if an administrator were handed nothing more than a typed code?

Key facts

Sources

  1. PrimaryThe report, read in full by command-line request at about 21:20 BST on 6 October 2026: six brands, Figure 6 dates, operator model, command vocabulary, indicator list counts, victim wording, recommendationsIslandaccessed 2026-10-06
  2. PrimaryIntroducing Muse, published 8 September 2026: a personal AI agent, no advertiser product in the postMetaaccessed 2026-10-06
  3. PrimaryMuse for Small Business, published 29 September 2026: connecting Meta ad accounts, nothing spends without approvalMetaaccessed 2026-10-06
  4. PrimaryAbout Security Centre: two-factor authentication required for business portfolios 90 days or olderMetaaccessed 2026-10-06
  5. PrimaryThe 15 March 2022 write-up of the browser-in-the-browser technique, used only for the principle and its datemr.d0xaccessed 2026-10-06
  6. PrimaryMulti-factor authentication for corporate online services: ranking of five MFA types and the wording on phishing resistanceNCSCaccessed 2026-10-06
  7. PrimaryWhy MFA matters: OTP interception, and any MFA superior to passwords aloneNCSCaccessed 2026-10-06
  8. PrimaryPasskeys are more secure than traditional ways to log in, 23 April 2026: traditional MFA inherently phishable, relay in a live sessionNCSCaccessed 2026-10-06
  9. PrimaryNews of 23 April 2026: passkeys recommended wherever supportedNCSCaccessed 2026-10-06
  10. PrimaryPhishing attacks: defending your organisation, reviewed 13 February 2024: technical measures, administrator accounts, password managersNCSCaccessed 2026-10-06
  11. PrimarySetting up 2-Step Verification, reviewed 10 January 2022: the stolen-password framingNCSCaccessed 2026-10-06
  12. PrimaryReport a scam email: the Suspicious Email Reporting Service and Report FraudNCSCaccessed 2026-10-06
  13. PrimaryReport a scam websiteNCSCaccessed 2026-10-06
  14. PrimaryReport a scam advert: ASA routeNCSCaccessed 2026-10-06
  15. PrimaryGoogle Ads Help, 2-Step Verification: the five second-step methods including security keyGoogleaccessed 2026-10-06
  16. PrimaryGoogle Ads Help, manager account security mandates: require 2-Step Verification or Advanced Protection; allowed domainsGoogleaccessed 2026-10-06
  17. PrimaryGoogle Ads Help, best practices: remove inactive users, minimum access, Related managersGoogleaccessed 2026-10-06
  18. PrimaryGoogle Ads Help, Security Agent: phishing as the main cause, passkeys, downgrading unused AdminGoogleaccessed 2026-10-06
  19. PrimaryGoogle Ads Help, what to do if your account is compromised: report, evidence, what Google doesGoogleaccessed 2026-10-06
  20. PrimaryGoogle Ads Help, suspicious emails or calls: Google never asks for passwords by email or linkGoogleaccessed 2026-10-06
  21. PrimaryAdvanced Protection FAQ: passkey or security key requiredGoogleaccessed 2026-10-06
  22. PrimaryNew ad formats built with Gemini in AI Mode, 20 May 2026Googleaccessed 2026-10-06
  23. PrimaryGemini Apps Help: connecting a Google Ads account to Gemini Apps (undated)Googleaccessed 2026-10-06
  24. PrimaryGoogle Ad Grants help page: the programme and its Google Ads accountsGoogleaccessed 2026-10-06
  25. PrimarySafety Centre, passkeys: strongest protection against phishingGoogleaccessed 2026-10-06
  26. PrimaryAds in ChatGPT help page, read 21:21 BST on 6 October 2026: ad testing since 9 February 2026, plansOpenAIaccessed 2026-10-06
  27. PrimaryAds Manager availability: self-service, United Kingdom listedOpenAIaccessed 2026-10-06
  28. PrimaryClaude is a space to think, 4 February 2026: Claude will remain ad-freeAnthropicaccessed 2026-10-06
  29. PrimaryHelp centre: connecting Meta Ads Manager with the Connect button, read-onlyManusaccessed 2026-10-06
  30. PrimaryBlog post on the Meta Ads Manager connector, dated Wednesday 18 March, no year shownManusaccessed 2026-10-06
  31. PrimaryWhy we are experimenting with advertising, 12 November 2024Perplexityaccessed 2026-10-06
  32. PrimaryPasswordless authentication page: phishing-resistant authentication with a passkeyMicrosoftaccessed 2026-10-06
  33. PrimaryPasskeys: phishing resistant and secure by designFIDO Allianceaccessed 2026-10-06
  34. PrimaryWeb Authentication Level 3 Recommendation, 25 August 2026: credentials scoped to the Relying Party's originsW3Caccessed 2026-10-06
  35. PrimaryHome page: organisations under cyber attack call 0300 123 2040; Scotland reports via 101Report Fraudaccessed 2026-10-06
  36. Reported bySame-day coverage, used as a pointer to Island's report and for the real-time sign-in wordingThe Hacker Newsaccessed 2026-10-06
  37. Reported bySame-day coverage read in a browser tab with the returned address checked; used as a pointer and for the drag and resize claim, attributed to itBleepingComputeraccessed 2026-10-06
  38. Reported byAd account theft, 28 July 2026: 6.4 million detections, 2 to 4 times premium, loss of controlMimecastaccessed 2026-10-06
  39. Reported byA beta-invite phish, 9 September 2026: an AI advertising workspace invitation that passed email authenticationIRONSCALESaccessed 2026-10-06

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.