CTIPilot

Google Account

product · product:google-account single-source-national-cert

Coverage timeline
1
first 2026-09-23 → last 2026-09-23
Peak priority
routine
1 routine
Sources cited
1
1 hosts
Sections touched
1
active-threats
Co-occurring entities
0
no co-occurrence
ATT&CK techniques
3
pinned v19.2 · see below

Hunting pivots

Releases covered
Google Account

ATT&CK techniques

3 techniques observed across 1 entry, derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.2 · compare on the matrix · Navigator layer (JSON)

Initial Access TA0001

T1566.004Phishing: Spearphishing Voice×1

Adversaries may use voice communications to ultimately gain access to victim systems. Spearphishing voice is a specific variant of spearphishing. It is different from other forms of spearphishing in that it employs the use of manipulating a user into providing access to systems through a phone call or other forms of voice communications. Spearphishing frequently involves social engineering techniques, such as posing as a trusted source (ex: Impersonation) and/or creating a sense of urgency or alarm for the recipient.

Evidence: 2026-09-23/ncsc-ch-google-recovery-oauth-app-password-persistence · ATT&CK page ↗

Persistence TA0003

T1098.001Account Manipulation: Additional Cloud Credentials×1

Adversaries may add adversary-controlled credentials to a cloud account to maintain persistent access to victim accounts and instances within the environment.

Evidence: 2026-09-23/ncsc-ch-google-recovery-oauth-app-password-persistence · ATT&CK page ↗

Privilege Escalation TA0004

T1098.001Account Manipulation: Additional Cloud Credentials×1

Adversaries may add adversary-controlled credentials to a cloud account to maintain persistent access to victim accounts and instances within the environment.

Evidence: 2026-09-23/ncsc-ch-google-recovery-oauth-app-password-persistence · ATT&CK page ↗

Stealth TA0005

T1684.001Social Engineering: Impersonation×1

Adversaries may impersonate a trusted person or organization in order to persuade and trick a target into performing some action on their behalf. For example, adversaries may communicate with victims (via Phishing for Information, Phishing, or Internal Spearphishing) while impersonating a known sender such as an executive, colleague, or third-party vendor. Established trust can then be leveraged to accomplish an adversary’s ultimate goals, possibly against multiple victims.

Evidence: 2026-09-23/ncsc-ch-google-recovery-oauth-app-password-persistence · ATT&CK page ↗

Story timeline

  1. 2026-09-23NCSC Switzerland: Google recovery-address abuse plus a Sites-hosted phishing page plants an OAuth app-password backdoor that survives a password reset
    active-threatsA genuine Google security alert becomes the lure in a fraud chain that outlives a password change

Where this entity is cited

  • active-threats1

Source distribution

  • bacs.admin.ch1 (100%)

explore in graph

Entries about Google Account (1)

2026-09-23 · view entry permalink →

ROUTINENATOA2

NCSC Switzerland: Google recovery-address abuse plus a Sites-hosted phishing page plants an OAuth app-password backdoor that survives a password reset

NCSC Switzerland (BACS) reports a fraud chain that combines abuse of a legitimate Google account-security feature with vishing and app-password persistence. Attackers create their own Google account, register the victim's email address as its "recovery address," then generate an app password inside their own account and label it with social-engineering text impersonating a support case: "they then generated an app password in their own account and labelled it in the free-text field with: 'Kevin W. Case-ID: 834333 To view your case…'" (translated from German; NCSC Switzerland, 2026-09-22). "Google's automated system then sent an official, technically flawless security warning to the victim. Because the naming text was automatically carried into the email, it looked to the recipient as if Google were running an urgent support case with a case handler and case number" (translated from German; NCSC Switzerland, 2026-09-22). Google's recovery-notification email is itself genuine and unmodifiable by the attacker except for that free-text label, so the victim receives an authentic Google security alert that reads like an active support ticket. A follow-up vishing call from a spoofed Swiss-looking number (surviving Switzerland's mid-2026 anti-spoofing rules for foreign-originated calls) then pressures the victim to resolve the "compromise" via a phishing page hosted on the legitimate sites.google.com domain rather than accounts.google.com, which relays entered credentials to the attacker in real time. Once inside the real account, the attacker immediately provisions their own app password (a legacy credential type that bypasses two-factor authentication) giving persistent access that survives a subsequent password change: "as a result, the perpetrators retained access to the account even after a password change. In the reported case, emails and contacts continued to sync unnoticed to a device abroad for an extended period after the attack" (translated from German; NCSC Switzerland, 2026-09-22).

Triage: legitimate Google administrators and helpdesks never call account holders unprompted about a security case; the tell is the free-text "case ID" riding inside an otherwise-genuine Google recovery-address notification, and any login page served from sites.google.com rather than accounts.google.com. Detection and hardening: audit and restrict app-password issuance on any Google account, and treat an app-password creation event with the same sensitivity as a new OAuth grant for incident-response purposes, since it is a durable, MFA-bypassing credential that a full password rotation does not revoke.

They then generated an app password in their own account and labelled it in the free-text field with: "Kevin W. Case-ID: 834333 To view your case…".

Google's automated system then sent an official, technically flawless security warning to the victim. Because the naming text was automatically carried into the email, it looked to the recipient as if Google were running an urgent support case with a case handler and case number.

As a result, the perpetrators retained access to the account even after a password change. In the reported case, emails and contacts continued to sync unnoticed to a device abroad for an extended period after the attack.

Bundesamt für Cybersicherheit (BACS) / NCSC Switzerland 2026-09-22
threat23 Sep 04:45Zsingle-source · national CERTOpen finding ↗