CTIPilot
AI-generated · no human review · verify critical claims against the linked source. how it works →

Google Account

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

Coverage
1
first 2026-09-23 → last 2026-09-30
Latest activity
2026-09-23
A genuine Google security alert becomes the lure in a fraud chain that outlives a password change
Peak priority
routine
1 routine
Targets
public-sector
sectors: public-sector · regions: switzerland
Sources cited
1
1 hosts

Defender insights

What each entry about Google Account tells a defender to do, newest first.

2026-09-23ROUTINEA genuine Google security alert becomes the lure in a fraud chain that outlives a password change

Triage

Story timeline

  1. 2026-09-23NCSC Switzerland: Google recovery-address abuse plus a Sites-hosted phishing page plants an 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

Hunting pivots

Releases covered
Google Account
ATT&CK techniques (3 across 4 tactics)

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

  • Initial AccessPhishing: Spearphishing Voice
  • PersistenceAccount Manipulation: Additional Cloud Credentials
  • Privilege EscalationAccount Manipulation: Additional Cloud Credentials
  • StealthSocial Engineering: Impersonation

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 ↗

Entries about Google Account (1)

2026-09-23 · view entry permalink →

ROUTINEupdatedNATOA2

NCSC Switzerland: Google recovery-address abuse plus a Sites-hosted phishing page plants an 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 (NCSC Switzerland, 2026-09-22). 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). The victim therefore receives an authentic Google security alert whose attacker-chosen label makes it read like an active support ticket (NCSC Switzerland, 2026-09-22). A follow-up vishing call from a spoofed Swiss number posing as a Google landline, which got through despite Switzerland's mid-2026 rules against spoofed Swiss numbers from abroad, 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, whose embedded form sends entered credentials directly to the attackers (NCSC Switzerland, 2026-09-22). Once inside the real account, the attacker provisions their own app password within minutes, a special access code for older applications that works without two-factor confirmation, 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 (NCSC Switzerland, 2026-09-22). Detection and hardening: an app password works without two-factor confirmation and kept the attackers in the account after a password change, so BACS advises deleting every app password and checking recovery addresses and automatic forwarding rules (NCSC Switzerland, 2026-09-22). A newly created app password on an account is therefore an incident-response signal in its own right.

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
Correctionrun 2026-09-30T0639Z-auditbodytitle

BACS describes the Google alert as official and technically flawless, with the attacker's app-password label carried into it automatically (NCSC Switzerland, 2026-09-22). It does not say the rest of the email cannot be altered, a claim the entry previously made. BACS also describes an app password as a special access code for older applications that works without two-factor confirmation, and says the phishing page's form sent entered credentials directly to the attackers (NCSC Switzerland, 2026-09-22).

threat23 Sep 04:45Zsingle-source · national CERTOpen finding →

explore in graph

Where this entity is cited

  • Threats1

Source distribution

  • bacs.admin.ch1 (100%)