การโจมตีทั้งหมดมีเงื่อนไขสำคัญคือ ต้องมีมัลแวร์ทำงานอยู่บนคอมพิวเตอร์ของเหยื่อแล้ว และมัลแวร์นั้นใช้สิทธิ์ระดับผู้ใช้ทั่วไปได้ ไม่จำเป็นต้องมีสิทธิ์แอดมิน อย่างไรก็ตาม เทคนิคเหล่านี้ไม่ได้ทำลายการเข้ารหัสของ WebAuthn หรือ FIDO2 แต่โจมตีช่องว่างในกระบวนการที่ Chrome และ Google ใช้สร้างความน่าเชื่อถือให้กับอุปกรณ์และจัดการ Passkey
มัลแวร์จะดึงกุญแจระบุตัวตนอุปกรณ์ของ Chrome ซึ่งถูกห่อหุ้มด้วย TPM จากไฟล์ passkey_enclave_state ที่เก็บอยู่ในเครื่อง จากนั้นนำกุญแจดังกล่าวไปใช้ผ่าน Windows CNG API ซึ่งเป็น API การเข้ารหัสตามปกติของ Windows เพื่อเซ็นคำขอที่ผู้โจมตีควบคุม
ผลลัพธ์คือ ผู้โจมตีสามารถสร้าง WebAuthn assertion ที่ถูกต้องได้ โดยไม่มีหน้าต่างแจ้งเตือน ไม่มีการถาม PIN และไม่มีการยืนยันด้วยลายนิ้วมือหรือชีวมิติบนหน้าจอของเหยื่อ
เทคนิคนี้ใช้ได้กับเว็บไซต์ที่ไม่ตรวจสอบบิต User Verified (UV) ในข้อมูลจากตัวตรวจสอบสิทธิ์ แม้เว็บไซต์จะตั้งค่าขอให้มีการยืนยันตัวตนจากผู้ใช้ก็ตาม
จุดอ่อนที่ถูกใช้ประโยชน์: ระบบยืนยันตัวตนบนคลาวด์เชื่อถือกุญแจระบุตัวตนที่เก็บอยู่ในเครื่อง และเว็บไซต์บางแห่งไม่ได้บังคับตรวจสอบว่า Passkey ผ่านการยืนยันตัวตนของผู้ใช้จริงหรือไม่
เทคนิคนี้เริ่มจากการลบหรือทำให้ไฟล์ passkey_enclave_state ใช้งานไม่ได้ เพื่อบังคับให้ Chrome เข้าสู่กระบวนการเพิ่มอุปกรณ์หรือ re-onboarding ใหม่
ระหว่างกระบวนการดังกล่าว Chrome จะสร้างกุญแจสำหรับ User Verification ในขั้นตอนที่เลื่อนการทำงานออกไปชั่วคราว ผู้โจมตีจึงสามารถแทรกกุญแจ UV ของตนเองเข้าไปในช่วงเวลานั้นได้ ระบบยืนยันตัวตนบนคลาวด์ของ Google ไม่ได้ตรวจสอบ attestation ของกุญแจใหม่อย่างเพียงพอ ทำให้ assertion ที่เซ็นด้วยกุญแจของผู้โจมตีมีค่า UV เป็น 1
ด้วยเหตุนี้ Silver Pass-ta-key จึงสามารถผ่านการตรวจสอบได้ แม้เว็บไซต์จะบังคับใช้ User Verification ก็ตาม และผู้โจมตีอาจใช้งานจากเครื่องของตนเองต่อได้ โดยไม่จำเป็นต้องให้คอมพิวเตอร์ของเหยื่อออนไลน์อยู่ตลอดเวลา
จุดอ่อนที่ถูกใช้ประโยชน์: ไม่มีการตรวจสอบ attestation ระหว่างเพิ่มอุปกรณ์ใหม่อย่างเพียงพอ และไฟล์สถานะ enclave สามารถถูกลบได้โดยไม่มีระบบป้องกันที่เหมาะสม
Golden Pass-ta-key ใช้กระบวนการเพิ่มอุปกรณ์ใหม่ในลักษณะเดียวกัน ก่อนดึงข้อมูลจากหน่วยความจำของโปรเซส Chrome เพื่อค้นหา Security Domain Secret (SDS)
SDS เป็นกุญแจสมมาตรขนาด 32 ไบต์ที่ใช้เข้ารหัส Private Key ของ Passkey ซึ่งซิงก์อยู่ในบัญชี Google หากผู้โจมตีได้ SDS ไป ก็อาจถอดรหัส Private Key ของ Passkey ที่มีอยู่ทั้งหมด รวมถึง Passkey ใหม่ที่จะซิงก์เข้ามาในอนาคตได้
ก่อนหน้านี้ Google ยังเคยบันทึก SDS เป็นข้อความแบบไม่เข้ารหัสไว้ในเอาต์พุต chrome://device-log/FIDO ซึ่งถูกนำออกหลัง Unit 42 รายงานปัญหาแล้ว แต่ประเด็นที่ SDS ปรากฏอยู่ในหน่วยความจำของ Chrome ระหว่างขั้นตอนเพิ่มอุปกรณ์ยังคงเป็นความเสี่ยง
จุดอ่อนที่ถูกใช้ประโยชน์: SDS ปรากฏในรูปแบบข้อความธรรมดาในหน่วยความจำของโปรเซส Chrome ระหว่างกระบวนการเพิ่มอุปกรณ์
Pass-ta-key รูปแบบพื้นฐานสามารถใช้โจมตีเว็บไซต์ใดก็ตามที่ไม่ตรวจสอบค่า UV จากข้อมูล authenticator อย่างถูกต้อง Unit 42 ระบุว่า eBay เคยเป็นหนึ่งในเว็บไซต์ที่ไม่ได้บังคับตรวจสอบดังกล่าว แต่ eBay ได้แก้ไขปัญหาแล้ว
นักวิจัยยังระบุว่า มีเว็บไซต์จำนวนมากอย่างน่าประหลาดใจที่ตั้งค่า userVerification: "required" ตอนลงทะเบียน Passkey แต่กลับไม่ตรวจสอบบิต UV ที่ส่งกลับมาในขั้นตอนเข้าสู่ระบบ
SDS ทำหน้าที่เสมือนกุญแจหลักของ Passkey ทั้งหมดที่ซิงก์อยู่ในบัญชี Google ดังนั้นการรั่วไหลของ SDS อาจนำไปสู่ความเสี่ยงสำคัญดังนี้
จากผลการวิจัยของ Unit 42 แนวทางสำคัญสำหรับผู้ใช้และผู้ให้บริการมีดังนี้
userVerification: "required" แทน "preferred" สำหรับการทำรายการสำคัญ ณ วันที่เผยแพร่ข้อมูลเมื่อ 3 สิงหาคม 2026 ยังไม่มีการกำหนดหมายเลข CVE ให้กับปัญหานี้ และ Google ยังไม่ได้ยืนยันต่อสาธารณะว่าจะปรับแก้เส้นทางการโจมตีแบบ Silver หรือ Golden โดยตรงหรือไม่
ประเด็นสำคัญสำหรับผู้ใช้คือ Passkey ยังไม่ได้ถูกทำลายด้วยการถอดรหัสโดยตรง แต่ความปลอดภัยของมันขึ้นอยู่กับความปลอดภัยของอุปกรณ์ปลายทางด้วย หาก Windows เครื่องนั้นติดมัลแวร์ ระบบยืนยันตัวตนที่ออกแบบมาให้สะดวกอาจถูกนำไปใช้ในทางที่ผู้ใช้ไม่ทันสังเกต