เมื่อสายโทรศัพท์จาก "Helpdesk" กลายเป็นจุดเริ่มต้นของการข่มขู่เรียกค่าไถ่

เมื่อพนักงานได้รับสายที่อ้างว่าเป็นฝ่าย IT และแจ้งให้ปรับปรุงระบบยืนยันตัวตน คำขอนั้นอาจดูสอดคล้องกับงานประจำ การตัดสินใจเพียงไม่กี่ครั้งจึงอาจเปิดทางให้บุคคลอื่นเข้าถึงบัญชีที่เชื่อมกับอีเมลและเอกสารขององค์กรได้ทั้งหมด — โดยไม่มีการเข้ารหัสไฟล์แม้แต่ไฟล์เดียว

บทความ Exclusive นี้วิเคราะห์กลุ่ม UNC6671 (รู้จักในชื่อ BlackFile) ซึ่ง Google Threat Intelligence Group (GTIG) ติดตามมาตั้งแต่ต้นปี 2026 โดยรวบรวมข้อมูลจากรายงานของ GTIG, Arctic Wolf และ Microsoft เพื่อให้ทีม SOC และ Identity Security นำไปใช้เป็นแนวทางสืบสวน กำหนด Log ที่ต้องเก็บ และวางกฎตรวจจับสำหรับภัยคุกคามประเภทนี้

รายละเอียดทางเทคนิค

ภาพรวมกลุ่มและขอบเขตการระบุผู้โจมตี

GTIG รายงาน UNC6671 ในชื่อปฏิบัติการ BlackFile (รายงานเดือนสิงหาคม 2026) โดยเชื่อมกิจกรรมนี้กับชื่อแบรนด์ Redact, Pink, Helix และ Falcon ซึ่งแสดงให้เห็นโครงสร้างบริการที่ผู้โจมตีอาจใช้ร่วมกัน อย่างไรก็ตาม GTIG ระบุว่ายังมีความเป็นไปได้เรื่องสมาชิกที่แยกตัวหรือการใช้บริการ Vishing ร่วมกัน จึงไม่ควรอ่านความสัมพันธ์นี้เป็นโครงสร้างองค์กรที่ยืนยันครบถ้วน

Arctic Wolf ใช้ชื่อ PREY-0058 สำหรับกิจกรรมที่มีวิธีการทับซ้อนกับ UNC6671 และรายงานการขโมยข้อมูลจาก Microsoft 365 และ SaaS เพื่อข่มขู่ ส่วน Microsoft ระบุ Storm-3121 และ Storm-3032 ในกิจกรรมหลอกเรื่อง Passkey — รายงานนี้ใช้ข้อมูลของ Microsoft ประกอบมุมตรวจจับ ไม่ถือว่า Storm-3121/3032 เป็นชื่ออื่นของ UNC6671

เป้าหมายที่รายงานอยู่ในอเมริกาเหนือ ออสเตรเลีย และสหราชอาณาจักร โดยเน้นกลุ่ม Financial Services และองค์กรที่ใช้ Cloud SSO เป็นหลัก รายงานนี้ไม่ได้ระบุว่ามีผู้เสียหายในไทยจาก UNC6671 แล้ว

ลำดับการโจมตีแบบเต็ม (Full Attack Chain)

ขั้นที่ 1 — Vishing: โทรหลอกปลอม Helpdesk

ผู้โจมตีติดต่อพนักงานผ่านโทรศัพท์ส่วนตัว โดยอ้างเป็นฝ่าย IT Helpdesk และแจ้งว่าต้องย้ายไปใช้ Passkey หรือปรับปรุง MFA ตามนโยบายใหม่ คำขอนั้นฟังดูสมเหตุสมผลสำหรับพนักงานทั่วไป เพราะการย้ายไปใช้ Passkey เป็นเรื่องที่หลายองค์กรกำลังดำเนินการอยู่จริง

สิ่งสำคัญที่ต้องเข้าใจ: การใช้คำว่า Passkey เป็นข้ออ้างในการโทรไม่ได้พิสูจน์ว่าเทคโนโลยี Passkey ถูกเจาะ ผู้โจมตีใช้คำนี้เพื่อสร้างความน่าเชื่อถือเท่านั้น

ขั้นที่ 2 — AiTM Phishing: ดักข้อมูลยืนยันตัวตน

ผู้โจมตีพาเหยื่อไปยังหน้าล็อกอินเลียนแบบองค์กร ซึ่งทำหน้าที่เป็น Adversary-in-the-Middle (AiTM) — ตัวกลางแทรกระหว่างผู้ใช้กับระบบยืนยันตัวตนจริง เมื่อผู้ใช้กรอกข้อมูลและอนุมัติ MFA ผู้โจมตีได้รับทั้ง Credential และ Session Token ในเวลาเดียวกัน

• ▸ จุดที่ต้องแยกให้ชัดในการสืบสวน: ผู้ใช้เพียงเปิดหน้าเว็บ / กรอกรหัสผ่าน / อนุมัติ MFA / หรือทำขั้นตอนลงทะเบียนวิธีใหม่แล้ว แต่ละกรณีสร้างสมมติฐานและขอบเขตการตรวจสอบต่างกัน
• ▸ ข้อจำกัด: การที่หน้าจอแจ้งว่าการยืนยันสำเร็จ ตอบได้เพียงว่าระบบยอมรับขั้นตอนนั้น ยังไม่ตอบว่าบุคคลที่กำลังใช้ผลการยืนยันเป็นเจ้าของบัญชีหรือไม่

ขั้นที่ 3 — Session Hijack & เพิ่ม Authentication Method

หลังได้ Session Token ผู้โจมตีเข้าถึง SSO Account และดำเนินการสองส่วนควบคู่กัน:

• ▸ เพิ่ม Authentication Method ที่ผู้โจมตีควบคุม เพื่อให้สามารถกลับเข้ามาได้แม้รหัสผ่านจะถูกเปลี่ยน
• ▸ ลบอีเมลแจ้งเตือนจาก Microsoft/บริการต่างๆ ที่ถูกส่งมายังกล่องจดหมายเหยื่อ เพื่อปกปิดร่องรอย

ขั้นที่ 4 — Cloud Data Collection ผ่าน SSO

ผู้โจมตีใช้สิทธิ์ของบัญชีที่ยึดมาเพื่อเข้าถึง SharePoint, OneDrive และบริการ M365 ที่เชื่อมต่อผ่าน SSO โดยใช้สคริปต์ดึงข้อมูล

• ▸ ประเด็นสำคัญสำหรับ DFIR: GTIG รายงานว่าบางวิธีที่ผู้โจมตีใช้ดึงเนื้อหาไฟล์ ปรากฏเป็น FileAccessed แทน FileDownloaded ทำให้กฎตรวจจับที่เฝ้าดูเฉพาะ FileDownloaded อาจมองไม่เห็นกิจกรรมนี้
• ▸ การมี SSO ไม่ได้แปลว่าทุกระบบถูกเข้าถึงแล้ว ต้องตรวจสิทธิ์และ Log ของแต่ละแอปแยกกัน

ขั้นที่ 5 — ขยายขอบเขตผ่านอีเมลที่ยึดมา

• ▸ รีเซ็ตรหัสผ่านของ แอปองค์กรที่ไม่ได้อยู่ใต้ SSO โดยใช้กล่องจดหมายที่ถูกยึดเป็นช่องทางกู้คืนบัญชี
• ▸ ดำเนินการลบอีเมลแจ้งเตือนต่อเนื่องเพื่อซ่อนร่องรอย

ขั้นที่ 6 — Extortion: ข่มขู่โดยไม่เข้ารหัสไฟล์

ผู้โจมตีส่งข้อความเรียกค่าไถ่พร้อมตัวอย่างข้อมูลที่ขโมยมาเป็นหลักฐาน แต่ ไม่ได้เข้ารหัสไฟล์ในระบบ ทำให้การประเมินผลกระทบต้องอาศัย Log และบริบทของบัญชี ไม่ใช่การตรวจสอบความเสียหายของระบบ

ผลกระทบที่อาจเกิดขึ้น

1. ระบบยังทำงานได้ตามปกติ แต่ข้อมูลรั่วไหลแล้ว — การขาดไฟล์ถูกเข้ารหัสหรือระบบหยุดทำงานไม่ใช่เกณฑ์ว่าความเสียหายยังไม่เกิดขึ้น เป้าหมายของ UNC6671 คือความลับของข้อมูล พนักงานอาจยังทำงานได้ปกติขณะที่บุคคลอื่นกำลังค้นเอกสารหรืออีเมลขององค์กรอยู่
2. บัญชีเดียวเปิดทางสู่หลายบริการ — เมื่อผู้โจมตีผ่านขั้นตอนยืนยันตัวตนได้ การกระทำถัดไปปรากฏเป็นกิจกรรมของบัญชีที่มีสิทธิ์อยู่แล้ว ทำให้การตรวจเฉพาะไฟล์อันตรายหรือการเชื่อมต่อจากภายนอกไม่เพียงพอ
3. Long-lived Session Token ยังมีผลแม้เปลี่ยนรหัสผ่านแล้ว — Microsoft ระบุว่า IdP ไม่สามารถยกเลิก Session Token ที่แอปออกเองได้โดยตรงในทุกกรณี การเปลี่ยนรหัสผ่านเพียงอย่างเดียวไม่ใช่เกณฑ์ปิดเหตุ ต้องตรวจพฤติกรรมของแอปปลายทางด้วย
4. Log Gap ทำให้ขอบเขตความเสียหายประเมินได้ยาก — หาก Microsoft Graph Activity Logs ไม่ได้เปิดเก็บมาก่อน หรือ OfficeActivity ไม่มีข้อมูลครบ การสืบสวนอาจระบุได้เพียงว่าบัญชีถูกใช้งาน แต่ยืนยันขอบเขตข้อมูลที่ถูกเข้าถึงไม่ได้ทั้งหมด

สิ่งที่องค์กรควรทำ

การตอบสนองเร่งด่วนเมื่อรับแจ้งเหตุ

1. เริ่มเก็บข้อมูลทันทีที่รับแจ้ง — แม้ยังไม่ยืนยันว่าบัญชีถูกยึด ให้บันทึกเวลารับแจ้ง URL และสิ่งที่ผู้ใช้ทำ แต่ละสถานะใช้หลักฐานและการตอบสนองต่างกัน: การได้รับสาย / กรอกข้อมูลแล้ว / มีการเพิ่ม Auth Method / พบการเข้าถึงข้อมูล
2. ตรวจ Sign-in และการเปลี่ยน Authentication Method — หากผู้ใช้ยืนยันว่าได้รับคำขอ MFA ระหว่างคุยโทรศัพท์ ให้เทียบเวลารับสายกับ Sign-in ที่สำเร็จและเหตุการณ์ลงทะเบียนข้อมูลความปลอดภัยในช่วงเดียวกัน
3. จำกัดการเข้าถึงและ Revoke Session — กำหนดบัญชีและบริการเป้าหมายให้ชัด บันทึกผลจากระบบหลังดำเนินการ ไม่ใช้เพียงข้อความว่าได้ส่งคำสั่งแล้วเป็นหลักฐานว่าการเข้าถึงสิ้นสุด และประสานเจ้าของแอปเพื่อตรวจเซสชันที่บริการปลายทางจัดการเอง
4. เงื่อนไขคืนบัญชี — ยืนยันเจ้าของบัญชีผ่านช่องทางอิสระ ตรวจวิธียืนยันตัวตนที่เหลือทั้งหมด ทบทวนสิทธิ์และการเปลี่ยนแปลงที่เกิดระหว่างเหตุ และวางแผนเฝ้าระวังหลังคืนบัญชีสำหรับแอปที่เกี่ยวข้องจริง

คำถามที่ควรถามผู้แจ้งเหตุ

• ▸ ใครติดต่อมา โทรเข้าช่องทางใด มีการส่งลิงก์หรือรหัสหรือไม่
• ▸ เปิดด้วยอุปกรณ์ใด กรอกอะไร และมีข้อความยืนยันแบบใด
• ▸ บันทึกเวลาที่ผู้ใช้จำได้พร้อมระดับความแน่นอน แยกจากเวลาที่ได้จาก Log
• ▸ อย่าขอให้ผู้ใช้ส่ง OTP หรือ Token ที่ยังใช้งานได้ลงใน Ticket ให้เก็บข้อความ ภาพหน้าจอ และ URL แทน

กฎตรวจจับ (Detection Rules — KQL)

กฎต่อไปนี้จัดทำโดย TXEC เพื่อเป็น ต้นแบบสำหรับค้นหา ไม่ใช่ลายเซ็นระบุ UNC6671 และไม่ควรใช้บล็อกอัตโนมัติก่อนทดสอบกับ Tenant จริงขององค์กร ต้องยืนยันฟิลด์และชื่อตารางก่อนเปิดใช้งาน

KQL 1 — การลงทะเบียนข้อมูลความปลอดภัย (MFA Registration)

ค้นเหตุการณ์ที่ Arctic Wolf กล่าวถึง แยกผู้ดำเนินการออกจากบัญชีที่ถูกเปลี่ยนค่า กฎนี้แสดงทั้งขั้นเริ่มและขั้นสำเร็จ เพื่อช่วยวิเคราะห์ลำดับ ไม่ควรตีความว่าทุกแถวหมายถึงมี MFA Device ใหม่เพิ่มแล้ว

kql

AuditLogs
| where TimeGenerated >= ago(24h)
| where ActivityDisplayName in~ (
    "User started security info registration",
    "User registered security info")
| where Result =~ "success"
| extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName),
         ActorIP  = tostring(InitiatedBy.user.ipAddress),
         ActorApp = tostring(InitiatedBy.app.displayName)
| mv-expand Target = TargetResources
| where tostring(Target.type) =~ "User"
| extend TargetId  = tostring(Target.id),
         TargetUPN = tostring(Target.userPrincipalName)
| project TimeGenerated, Id, ActivityDisplayName,
          ActorUPN, ActorApp, ActorIP, TargetId, TargetUPN,
          Target, AdditionalDetails
| order by TimeGenerated desc

• ▸ สิ่งที่ควรตรวจต่อ: ผู้ใช้เพิ่งเปลี่ยนโทรศัพท์หรือมี Helpdesk Ticket อนุมัติหรือไม่ มีการเข้าสู่ระบบก่อนหน้าแบบใด และรายละเอียด Audit ยืนยันการเปลี่ยนวิธีใดจริง
• ▸ ข้อจำกัด: กฎเลือกชื่อกิจกรรมเพียงสองชื่อ อาจไม่ครอบคลุมการเพิ่มวิธียืนยันตัวตนผ่านผู้ดูแลหรือช่องทางอื่น ผลว่างไม่ยืนยันว่าไม่เกิดการเปลี่ยนค่า

KQL 2 — การเข้าถึงหรือดาวน์โหลดไฟล์จำนวนมาก

รวม FileAccessed และ FileDownloaded เพื่อไม่พลาดการเข้าถึงที่ไม่ปรากฏเป็นคำสั่งดาวน์โหลด ค่า 50 ไฟล์ต่อ 15 นาทีเป็นค่าเริ่มต้นสำหรับปรับ

kql

OfficeActivity
| where TimeGenerated >= ago(24h)
| where OfficeWorkload in~ ("SharePoint", "OneDrive")
| where Operation in~ ("FileAccessed", "FileDownloaded")
| where isnotempty(UserId)
| summarize Events = count(),
    UniqueFiles       = dcountif(OfficeObjectId, isnotempty(OfficeObjectId)),
    MissingObjectId   = countif(isempty(OfficeObjectId)),
    IPs               = make_set(ClientIP, 20),
    Agents            = make_set(UserAgent, 10),
    Operations        = make_set(Operation, 5),
    SampleFiles       = make_set(OfficeObjectId, 10)
  by OrganizationId, UserId, bin(TimeGenerated, 15m)
| where UniqueFiles >= 50
| order by UniqueFiles desc

• ▸ ก่อนยกระดับเหตุ: ตรวจว่าเป็นงาน Sync ย้ายข้อมูล หรือแอปที่ได้รับอนุญาตหรือไม่ เทียบกับความรับผิดชอบของบัญชีและความสำคัญของไฟล์
• ▸ ข้อจำกัด: กฎนี้ไม่จำกัด IP ในการจัดกลุ่ม ผลอาจรวมหลายเซสชันของผู้ใช้เดียวกัน และการนับ dcount เป็นค่าประมาณ

KQL 3 — การสำรวจหลายหมวดข้อมูลผ่าน Microsoft Graph

ค้นคำขอ GET ที่สำเร็จและเกี่ยวข้องกับหลายประเภททรัพยากร เหมาะสำหรับหากิจกรรมสำรวจเบื้องต้น

kql

MicrosoftGraphActivityLogs
| where TimeGenerated >= ago(24h)
| where RequestMethod =~ "GET"
| where ResponseStatusCode between (200 .. 299)
| where isnotempty(UserId)
| extend Path = tolower(tostring(parse_url(RequestUri).Path))
| extend Category = case(
    Path matches regex @"/users(/|$)",  "Users",
    Path matches regex @"/groups(/|$)", "Groups",
    Path matches regex @"/sites(/|$)",  "Sites",
    Path matches regex @"/drives(/|$)", "Drives",
    "Other")
| where Category != "Other"
| summarize Requests      = count(),
    Categories    = dcount(Category),
    SeenCategories = make_set(Category, 4),
    SamplePaths   = make_set(Path, 10),
    IPs           = make_set(IPAddress, 10)
  by AadTenantId, UserId, AppId, bin(TimeGenerated, 15m)
| where Requests >= 50 and Categories >= 2
| order by Requests desc

• ▸ ข้อควรระวัง: ไม่ถือว่าการเรียก API ปกติเป็นภัยโดยลำพัง แอปจัดการเอกสารและระบบรายงานอาจตรงกฎโดยชอบ ต้องตรวจ AppId เจ้าของแอป และช่วงเวลางานร่วมด้วย
• ▸ ข้อจำกัด: ไม่ครอบคลุม POST แบบ batch คำขอที่ไม่มี UserId หรือเส้นทางนอกสี่หมวด — ต้องเปิด Microsoft Graph Activity Logs ไว้ก่อนเหตุจึงจะมีข้อมูล

KQL 4 — ตรวจบริบทการเข้าสู่ระบบของบัญชีที่สงสัย

ใช้หลังพบผลจากกฎข้างต้น แทนค่า [email protected] ด้วย UPN ที่ได้รับอนุญาตให้สืบสวน

kql

let TargetUPN = "[email protected]";
SigninLogs
| where TimeGenerated >= ago(7d)
| where UserPrincipalName =~ TargetUPN
| where ResultType == "0"
| project TimeGenerated, UserId, UserPrincipalName,
          IPAddress, AppDisplayName, AppId,
          AuthenticationRequirement, AuthenticationDetails,
          ConditionalAccessStatus, DeviceDetail,
          CorrelationId, UniqueTokenIdentifier
| order by TimeGenerated asc

• ▸ ResultType == "0" บอกเพียงความสำเร็จในการเข้าสู่ระบบ ไม่รับรองว่าผู้ใช้เป็นผู้ดำเนินการจริง ต้องตรวจว่าการยืนยันผ่านวิธีใด มีข้อมูลอุปกรณ์หรือไม่ และเทียบกับสิ่งที่ผู้ใช้ยืนยัน

Public IOC

โดเมนจากแคมเปญ PREY-0058 ที่ Arctic Wolf เผยแพร่ใช้ประกอบการเฝ้าระวัง รายการเต็มพร้อมบริบทวันเผยแพร่อยู่ในเอกสาร Incident Report ฉบับเต็มของ TXEC

• ▸ วิธีนำ IOC ไปใช้: แยกชื่อ Host ออกจาก URL ก่อนเปรียบเทียบ ทำตัวพิมพ์เล็กให้สม่ำเสมอ และใช้เงื่อนไข Host ตรงกับโดเมนหลักหรือจบด้วยจุดตามด้วยโดเมนหลัก — ป้องกันไม่ให้ passkeyhelpdesk.com.example.org ถูกนับว่าตรงกับ passkeyhelpdesk.com
• ▸ ข้อควรระวัง: การพบ DNS Query อย่างเดียวไม่ได้ยืนยันว่ามีการกรอกข้อมูล หรือว่าผู้โจมตีได้ Session ไปแล้ว ต้องเชื่อมกับ Sign-in และกิจกรรมบัญชีก่อนสรุป และแยกคำขอจากระบบสแกนลิงก์อัตโนมัติออกก่อนนับผู้ได้รับผลกระทบ

แนวทางลดความเสี่ยงระยะยาว

1. ยกระดับ MFA เป็น Phishing-Resistant — ประเมินการบังคับใช้ MFA ที่ต้านทานฟิชชิง (เช่น Hardware Security Key หรือ Passkey จริงที่ผูกกับ Device) พร้อมกำหนดเงื่อนไขอุปกรณ์ที่องค์กรควบคุมได้ใน Conditional Access
2. จำกัดขั้นตอน MFA Registration / Account Recovery — เพิ่มการตรวจสอบขั้นตอนลงทะเบียนวิธีใหม่ให้เหมาะกับความเสี่ยง โดยเฉพาะการเพิ่ม Auth Method ควรต้องการการอนุมัติจากผู้ดูแลหรือยืนยันตัวตนเพิ่มเติม ไม่ให้ผู้ใช้ทำเองได้ทันทีหลังล็อกอิน
3. Helpdesk: ช่องทางยืนยันตัวตนที่ผู้โทรกำหนดเองไม่ได้ — ให้พนักงานสามารถโทรกลับตาม เบอร์จากระบบภายใน ไม่ใช้เบอร์ที่ผู้โทรแจ้ง หาก Helpdesk ต้องการให้ผู้ใช้ทำขั้นตอนใดผ่านลิงก์ ให้ส่งผ่านช่องทางที่องค์กรควบคุม ไม่ใช่ URL ที่ระบุในสายโทรศัพท์
4. เปิด Log ก่อนเกิดเหตุ — โดยเฉพาะ Microsoft Graph Activity Logs — Log ที่ไม่ได้เปิดเก็บมาก่อนไม่สามารถกู้คืนย้อนหลังได้ องค์กรที่ใช้ Microsoft 365 ควรตรวจสถานะการเก็บ AuditLogs, OfficeActivity, MicrosoftGraphActivityLogs และ SigninLogs ว่าเปิดอยู่และนำเข้า SIEM หรือ Sentinel แล้ว
5. ฝึกซ้อม Incident Playbook จาก "สายต้องสงสัย" — เริ่มการซ้อมจากสถานการณ์ที่พนักงานแจ้งว่ารับสายต้องสงสัย แล้วให้ทีมลองตามหา Sign-in การเปลี่ยนค่าบัญชี และการเข้าถึงข้อมูลจากหลักฐานฝึก วัดว่าแต่ละทีมติดต่อกันได้เร็วเพียงใดและติดขัดที่สิทธิ์หรือ Log จุดไหน

วิเคราะห์ในมุมมองจาก TXEC

UNC6671 / BlackFile สะท้อนให้เห็นภัยคุกคามที่ทีมรักษาความปลอดภัยหลายแห่งยังไม่ได้เตรียมรับมือ — เพราะไม่มีมัลแวร์ ไม่มีระบบหยุดทำงาน และกิจกรรมทั้งหมดปรากฏเป็น "บัญชีที่มีสิทธิ์กำลังใช้งานระบบ"

จุดที่น่ากังวลที่สุดคือขั้นตอนการโจมตีที่ทำซ้ำได้ง่าย: โทรศัพท์ + หน้า Phishing + ข้อมูลยืนยันตัวตนที่ได้มา = เข้าถึงข้อมูลได้ทันที การป้องกันจึงต้องทำที่ ขั้นตอน Authentication ให้ยากกว่านี้ตั้งแต่แรก ไม่ใช่รอตรวจหลังเหตุเกิด

สำหรับองค์กรไทยที่ใช้ Microsoft 365 เป็นระบบหลัก ข้อเสนอเร่งด่วนของ TXEC มีสามข้อ: (1) ตรวจสถานะ Log ที่จำเป็นว่าเปิดและนำเข้าสู่ระบบ SIEM แล้ว (2) ทบทวนกระบวนการยืนยันตัวตนของ Helpdesk ว่าผู้โทรไม่สามารถกำหนดขั้นตอนได้เอง และ (3) เตรียม Playbook ที่ระบุผู้รับผิดชอบจริงสำหรับสถานการณ์ "มีพนักงานรับสายต้องสงสัย"

ชื่อกลุ่มอาจเปลี่ยน แต่วิธีโจมตีพื้นฐานจะคงอยู่ตราบใดที่ขั้นตอน Account Recovery ยังทำผ่านโทรศัพท์ได้

[ แหล่งอ้างอิง:

[1] GTIG, "Welcome to BlackFile: Inside a Vishing Extortion Operation", 16 พ.ค. 2026 — https://cloud.google.com/blog/topics/threat-intelligence/blackfile-vishing-extortion-operation/

[2] GTIG & Mandiant, "UNC6671 Rebrands: Multi-Brand Vishing Extortion Targets Financial Services and Enterprise Cloud Environments", 6 ส.ค. 2026 — https://cloud.google.com/blog/topics/threat-intelligence/unc6671-targets-financial-services-and-enterprise-cloud-environments

[3] Arctic Wolf, "Active Cloud Data Theft and Extortion Campaign Targeting Microsoft 365 and SaaS Platforms", 3 ก.ย. 2026 — https://arcticwolf.com/resources/blog/security-bulletin-active-cloud-data-theft-and-extortion-campaign-targeting-microsoft-365-and-saas-platforms/

[4] Microsoft Security Research, "Passkey-themed social engineering leads to identity and cloud compromise", 9 ก.ย. 2026 — https://www.microsoft.com/en-us/security/blog/2026/09/09/passkey-themed-social-engineering-leads-identity-cloud-compromise/ ]