เตือนภัย! แคมเปญ GhostAction โจมตีบัญชี GitHub กว่า 1,900 บัญชี มุ่งขโมย Credentials และ Secrets จากกว่า 30,000 Repositories

ยอดเข้าชม: 70 views

ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (ThaiCERT) ได้ติดตามสถานการณ์ภัยคุกคามทางไซเบอร์ พบรายงานแคมเปญโจมตีที่มีชื่อว่า GhostAction ซึ่งมุ่งโจมตีโครงสร้างพื้นฐานด้านการพัฒนาซอฟต์แวร์บน GitHub โดยผู้โจมตีเข้าควบคุมบัญชีนักพัฒนาและฝัง GitHub Actions Workflow ที่เป็นอันตรายลงใน Software Repository เพื่อขโมยข้อมูลสำคัญ เช่น CI/CD Secrets, Cloud Credentials, Package Registry Tokens และ API Keys ทั้งนี้ GitGuardian รายงานว่ามี Repository ถูกกำหนดเป้าหมายมากกว่า 30,000 รายการ ครอบคลุมผู้ใช้งานและองค์กรประมาณ 3,000 ราย และเกี่ยวข้องกับบัญชี GitHub ที่ถูกบุกรุกประมาณ 1,900 บัญชี [1]

1. รายละเอียดภัยคุกคาม [2]
GhostAction เป็นแคมเปญโจมตีแบบ Software Supply Chain Attack ที่มุ่งโจมตีระบบพัฒนาซอฟต์แวร์บน GitHub โดยพบครั้งแรกตั้งแต่เดือนกันยายน 2568 และยังคงมีการโจมตีอย่างต่อเนื่องจนถึงปัจจุบัน ผู้โจมตีใช้ข้อมูลรับรองที่ถูกขโมย เช่น GitHub Personal Access Token (PAT) หรือ Credentials ที่ได้จาก Infostealer Logs และฐานข้อมูลรั่วไหล เพื่อเข้าถึงบัญชีนักพัฒนาที่มีสิทธิ์เขียน (Write Access) บน Repository หลังจากเข้าควบคุมบัญชีได้ ผู้โจมตีจะเพิ่ม GitHub Actions Workflow ที่เป็นอันตรายลงใน Repository โดยตั้งชื่อให้ดูเหมือนเป็นกระบวนการตรวจสอบความปลอดภัย เช่น
– security-audit.yml
– github_actions_security.yml
– security-check.yml
Workflow ดังกล่าวถูกออกแบบให้ค้นหาและรวบรวมข้อมูลลับจาก GitHub Actions, Source Code และประวัติ Git (Git History) ก่อนส่งข้อมูลออกไปยังโครงสร้างพื้นฐานของผู้โจมตี โดยข้อมูลเป้าหมายประกอบด้วย AWS Credentials, GitHub/GitLab Tokens, Cloud API Keys, SSH Keys, Database Credentials, npm/PyPI/DockerHub Tokens รวมถึง API Keys ของผู้ให้บริการ AI

2. ระบบและบัญชีที่อาจได้รับผลกระทบ
2.1 บัญชี GitHub ของนักพัฒนาหรือ Maintainer ที่ Personal Access Token, Password หรือ Credentials อาจถูกขโมยหรือรั่วไหล
2.2 GitHub Repository ที่บัญชีดังกล่าวมีสิทธิ์ Write หรือ Administrative Access
2.3 Repository ที่มี GitHub Actions Workflow และมีการจัดเก็บ Secrets หรือ Credentials สำหรับ CI/CD Pipeline
2.4 Repository ที่เคยจัดเก็บ Credentials, Tokens หรือ API Keys ไว้ใน Source Code หรือ Git History แม้ว่าข้อมูลดังกล่าวจะถูกลบออกจากไฟล์ปัจจุบันแล้ว
2.5 หน่วยงานที่ใช้งาน Credentials สำหรับบริการภายนอก เช่น AWS, Azure, Google Cloud, DockerHub, GitHub Container Registry, npm, PyPI รวมถึงบริการ AI และ SaaS ต่าง ๆ ภายใน CI/CD Pipeline

3. รูปแบบการโจมตี [3]
ผู้โจมตีเริ่มจากการนำ Credentials หรือ Personal Access Token ของบัญชี GitHub ที่ถูกขโมยมาใช้เข้าถึง Repository จากนั้นเพิ่ม Workflow อันตรายโดยใช้บัญชีของเหยื่อเอง ทำให้ Commit ที่เกิดขึ้นอาจดูเหมือนมาจากนักพัฒนาหรือ Maintainer ที่ถูกต้องตามปกติ เมื่อ Workflow ทำงาน จะทำการค้นหา Secrets ทั้งจาก GitHub Actions และไฟล์ภายใน Repository รวมถึงตรวจสอบ Git History เพื่อค้นหา Credentials ที่เคยถูก Commit ไว้ในอดีต โดย Payload รุ่นใหม่สามารถค้นหา AWS Access Key, GitHub/GitLab Token, Cloud Credentials และ AI API Keys รวมถึงดึงข้อมูลบริบทรอบ Credentials เพื่อช่วยระบุ Secret Key ที่เกี่ยวข้อง ก่อนส่งข้อมูลไปยังเซิร์ฟเวอร์ของผู้โจมตี
ทั้งนี้ GitGuardian ระบุว่า ในการโจมตีช่วงวันที่ 8–9 ตุลาคม 2569 ผู้โจมตีส่ง Payload ไปยังเหยื่อเดิมประมาณ 160 ราย ก่อนขยายการโจมตีไปยัง Repository ใหม่ประมาณ 28,000 รายการภายในเวลาเพียงประมาณ 20 นาที และมีความพยายามเข้าถึง Secrets จำนวน 3,174 รายการ จาก CI ของ Public Repository

4. ผลกระทบที่อาจเกิดขึ้น
หากผู้โจมตีสามารถขโมย Credentials หรือ Secrets ได้สำเร็จ อาจนำไปสู่การเข้าถึงระบบ Cloud, CI/CD Infrastructure, Source Code Repository, Database หรือ Package Registry โดยไม่ได้รับอนุญาต รวมถึงอาจใช้ Credentials ที่ขโมยได้เพื่อโจมตีต่อเนื่องไปยังระบบอื่น ผู้โจมตีอาจแก้ไข Source Code แทรก Malicious Code หรือ Backdoor ลงใน Software Package และนำไปสู่การโจมตีแบบ Software Supply Chain Attac ที่ส่งผลกระทบต่อผู้ใช้งานซอฟต์แวร์หรือระบบปลายทางจำนวนมากได้

5. แนวทางการตรวจสอบและป้องกัน
5.1 ตรวจสอบ GitHub Repository ทั้งหมดเพื่อค้นหา Workflow ที่ไม่ได้รับอนุญาต โดยเฉพาะไฟล์ภายใต้ .github/workflows/ ที่มีชื่อ เช่น security-audit.yml, github_actions_security.yml หรือ security-check.yml
5.2 ตรวจสอบ Git Commit History และ GitHub Audit Logs เพื่อค้นหา Commit หรือการแก้ไข Workflow ที่ผู้ดูแลระบบไม่ได้ดำเนินการเอง แม้ Commit ดังกล่าวจะแสดงชื่อบัญชีของ Maintainer ที่ถูกต้องก็ตาม
5.3 ตรวจสอบ GitHub Actions Run History เพื่อค้นหา Workflow ที่ผิดปกติ โดยเฉพาะ Workflow ที่มีการอ่าน Secrets, ตรวจสอบ Git History หรือส่งข้อมูลออกไปยังระบบภายนอก
5.4 ตรวจสอบ Credentials และ Secrets ที่จัดเก็บใน GitHub Actions รวมถึง Credentials ที่เคยปรากฏอยู่ใน Source Code หรือ Git History และดำเนินการ Revoke และ Rotate Credentials ทันที หากสงสัยว่าอาจถูกเปิดเผย
5.5 ตรวจสอบและยกเลิก Personal Access Token, SSH Key และ Access Token ที่ไม่จำเป็น รวมถึงออก Token ใหม่สำหรับบัญชีที่อาจได้รับผลกระทบ
5.6 เปิดใช้งาน Multi-Factor Authentication (MFA) สำหรับบัญชี GitHub โดยเฉพาะบัญชีนักพัฒนาและ Maintainer ที่มีสิทธิ์แก้ไข Repository
5.7 ใช้หลัก Least Privilege จำกัดสิทธิ์ของ Personal Access Token และ GitHub Actions Token ให้สามารถเข้าถึงเฉพาะ Repository และ Resource ที่จำเป็น
5.8 หลีกเลี่ยงการจัดเก็บ Password, API Key, Token หรือ Private Key ลงใน Source Code และดำเนินการ Secret Scanning เพื่อตรวจหา Credentials ที่อาจหลงเหลืออยู่ใน Repository และ Git History

6. แนวทางลดความเสี่ยงเพิ่มเติม
6.1 กำหนด Branch Protection Rules และบังคับใช้ Pull Request Review ก่อนอนุญาตให้มีการแก้ไข Code หรือ Workflow ใน Branch สำคัญ
6.2 จำกัดสิทธิ์ในการแก้ไขไฟล์ภายใต้ .github/workflows/ ให้เฉพาะผู้ดูแลที่ได้รับอนุญาต
6.3 ตรวจสอบ Network Connections จาก CI/CD Runner เพื่อค้นหาการเชื่อมต่อไปยังปลายทางที่ไม่รู้จักหรือไม่ได้รับอนุญาต
6.4 กำหนดอายุของ Access Token ให้สั้นที่สุดเท่าที่จำเป็น และดำเนินการ Rotate Secrets เป็นระยะ
6.5 หากตรวจพบ Workflow ต้องสงสัย ให้หยุดการทำงานของ Workflow ทันที ลบไฟล์ที่เป็นอันตราย ตรวจสอบขอบเขตของ Credentials ที่อาจถูกเข้าถึง และเปลี่ยน Credentials ทั้งหมดที่เกี่ยวข้องก่อนนำระบบกลับมาใช้งาน

แหล่งอ้างอิง
[1] https://dg.th/bi6mh7dyvs
[2] https://dg.th/9awb8zkpdi
[3] https://dg.th/p9gixo35ab