เตือนภัย! แคมเปญ GhostAction โจมตีบัญชี GitHub กว่า 1,900 บัญชี มุ่งขโมย Credentials และ Secrets จากกว่า 30,000 Repositories - Thailand Computer Emergency Response Team (ThaiCERT)警告!GhostAction 发起的攻击活动已入侵超过 1900 个 GitHub 账户,企图窃取超过 3 万个代码仓库的凭据和密钥。——泰国计算机应急响应小组 (ThaiCERT)
ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่ง

ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (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
泰国国家计算机安全事件响应中心 (ThaiCERT) 一直在监测网络威胁形势,并发现了一份名为 GhostAction 的攻击活动报告,该活动的目标是 GitHub 上的软件开发基础设施。攻击者控制开发者账户,并将恶意 GitHub Actions 工作流嵌入软件仓库,以窃取 CI/CD 密钥、云凭证、软件包注册表令牌和 API 密钥等敏感信息。GitGuardian 报告称,超过 30,000 个仓库成为攻击目标,涉及约 3,000 个用户和组织,约 1,900 个 GitHub 账户被盗用。[1]
1. 威胁详情 [2] GhostAction 是一种针对 GitHub 软件开发系统的软件供应链攻击活动。该攻击最早于 2015 年 9 月被发现,至今仍在持续。攻击者使用窃取的凭证,例如 GitHub 个人访问令牌 (PAT) 或从信息窃取器日志和泄露数据库中获取的凭证,来获取对代码库具有写入权限的开发者帐户。在控制帐户后,攻击者会向代码库添加恶意的 GitHub Actions 工作流,并将其命名为类似于安全审计流程的文件,例如 security-audit.yml、github_actions_security.yml 和 security-check.yml。该工作流旨在搜索并收集 GitHub Actions、源代码和 Git 历史记录中的机密信息,然后将这些信息发送到攻击者的基础架构。目标数据包括 AWS 凭证、GitHub/GitLab 令牌、云 API 密钥、SSH 密钥、数据库凭证、npm/PyPI/DockerHub 令牌以及 AI 提供商的 API 密钥。
2. 可能受影响的系统和帐户:2.1 开发者或维护者的 GitHub 帐户,其个人访问令牌、密码或凭证可能已被盗用或泄露。2.2 此类帐户拥有写入或管理访问权限的 GitHub 代码库。2.3 包含 GitHub Actions 工作流并存储 CI/CD 流水线密钥或凭证的代码库。2.4 之前在源代码或 Git 历史记录中存储过凭证、令牌或 API 密钥的代码库,即使这些信息已从当前文件中删除。2.5 在 CI/CD 流水线中使用外部服务(例如 AWS、Azure、Google Cloud、DockerHub、GitHub Container Registry、npm、PyPI 以及各种 AI 和 SaaS 服务)凭证的组织。
3. 攻击方法 [3] 攻击者首先使用窃取的 GitHub 账户凭证或个人访问令牌访问代码仓库,然后使用受害者的账户添加恶意工作流,使提交看起来像是来自合法开发者或维护者。工作流运行时,它会在 GitHub Actions 和代码仓库的文件中搜索密钥,并检查 Git 历史记录中是否存在之前提交的凭证。新的有效载荷可以搜索 AWS 访问密钥、GitHub/GitLab 令牌、云凭证和 AI API 密钥,并提取凭证的上下文信息,以帮助识别相关的密钥,然后再将这些信息发送到攻击者的服务器。GitGuardian 报告称,在 2016 年 10 月 8 日至 9 日的一次攻击中,攻击者先将有效载荷发送给了大约 160 个初始受害者,然后在短短 20 分钟内将攻击扩展到大约 28,000 个新的代码仓库,并试图从公共代码仓库的持续集成 (CI) 中访问 3,174 个密钥。
4. 潜在影响:如果攻击者成功窃取凭证或密钥,可能导致对云系统、CI/CD 基础设施、源代码库、数据库或软件包注册表的未经授权访问。此外,被盗凭证还可能被用于对其他系统发起进一步攻击。攻击者可能修改源代码,在软件包中插入恶意代码或后门,从而引发影响众多软件用户或最终用户的软件供应链攻击。
5. 监控和预防指南 5.1 检查所有 GitHub 仓库是否存在未经授权的工作流,尤其要检查以下目录下的文件: 5.1 检查名为 .github/workflows/ 的文件,例如 security-audit.yml、github_actions_security.yml 或 security-check.yml。 5.2 检查 Git 提交历史记录和 GitHub 审计日志,查找并非由管理员执行的提交或工作流修改,即使提交显示的维护者帐户名称正确。 5.3 检查 GitHub Actions 运行历史记录,查找异常工作流,尤其是读取密钥、检查 Git 历史记录或向外部系统发送数据的那些工作流。 5.4 检查存储在 GitHub Actions 中的凭据和密钥,包括出现在源代码或 Git 历史记录中的凭据,如果怀疑凭据已泄露,则立即撤销并轮换凭据。 5.5 检查并撤销不必要的个人访问令牌、SSH 密钥和访问令牌,并为可能受影响的帐户颁发新的令牌。 5.6 为 GitHub 帐户启用多因素身份验证 (MFA),尤其是具有仓库编辑权限的开发者和维护者帐户。5.7 遵循以下原则……最小权限原则限制个人访问令牌和 GitHub Actions 令牌仅用于访问必要的仓库和资源。5.8 避免在源代码中存储密码、API 密钥、令牌或私钥,并执行密钥扫描以检测仓库和 Git 历史记录中是否存在任何残留凭据。
6. 其他风险缓解措施:6.1 建立分支保护规则,并在允许对关键分支进行代码或工作流修改之前强制执行拉取请求审查。6.2 限制对 .github/workflows/ 目录下文件的编辑权限,仅限授权管理员。6.3 检查 CI/CD Runner 的网络连接,查找未知或未经授权的端点。6.4 将访问令牌的有效期设置为最短,并定期轮换密钥。6.5 如果检测到可疑工作流,立即停止该工作流,删除恶意文件,验证可能被访问的凭据范围,并在恢复系统之前替换所有相关凭据。
参考文献 [1] https://dg.th/bi6mh7dyvs [2] https://dg.th/9awb8zkpdi [3] https://dg.th/p9gixo35ab