สรุปสั้น
บริษัท Datadog โดยทีม Datadog Security Labs ออกมาเตือนถึง “หลายแคมเปญที่ทำงานทับซ้อนกัน” ซึ่งกำลังแจกแจงข้อมูลองค์กร repository และบัญชีผู้ใช้บน GitHub อย่างเป็นระบบผ่าน GitHub API จุดที่น่ากังวลคือผู้โจมตีอาศัยเครื่องมือ scraping อัตโนมัติที่ตั้ง user-agent แบบกำหนดเองหรือให้ดูเหมือนถูกกฎหมาย ร่วมกับบัญชี “ผี” (ghost account) บน GitHub ที่มักมีอายุหลายปี รวมถึง OAuth token และ personal access token (PAT) ที่ถูกขโมยหรือหลุดออกมาจากผู้ใช้ตัวจริง แม้กิจกรรมส่วนใหญ่จะมุ่งเป้าที่ข้อมูลสาธารณะ แต่บางกรณีก็ก้าวข้ามไปไกลกว่านั้นจนสามารถโคลน repository ส่วนตัวได้สำเร็จ
แคมเปญนี้ใช้เครื่องมือสแกนอัตโนมัติผสมกับบัญชีที่ไม่ได้ใช้งานกว่า 50 บัญชี และบัญชีที่ถูกต้องอีกหลายสิบบัญชีที่ถูกเปิดเผย PAT โดยไม่ตั้งใจหรือถูกเจาะด้วยวิธีอื่น สิ่งที่น่าสังเกตเกี่ยวกับบัญชีผีเหล่านี้คือถูกสร้างขึ้นเมื่อ 2 ถึง 5 ปีก่อน แล้วจงใจทิ้งไว้เฉย ๆ เป็นเวลานานก่อนนำมาใช้เป็นอาวุธยิงทราฟฟิก API ข้ามหลายองค์กร เทคนิคนี้เป็นกลยุทธ์ที่มุ่งเลี่ยงการจุดชนวนสัญญาณเตือน และทำให้กิจกรรมดูเหมือนถูกต้องตามกฎหมาย แทนที่จะสร้างบัญชีใหม่แล้วใช้ scraping ทันทีซึ่งจะดูน่าสงสัยกว่า
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 10 กรกฎาคม 2569 ว่า Datadog Security Labs กำลังเตือนถึงหลายแคมเปญที่ทำงานทับซ้อนกันในการแจกแจงข้อมูลองค์กร repository และบัญชีผู้ใช้บน GitHub อย่างเป็นระบบผ่าน GitHub API โดยนางสาว Julie Agnes Sparks วิศวกรความปลอดภัยอาวุโสของ Datadog ระบุว่า ผู้ปฏิบัติการอาศัยเครื่องมือ scraping อัตโนมัติที่ตั้ง user-agent แบบกำหนดเองหรือให้ฟังดูถูกกฎหมาย โดยใช้บัญชีผีบน GitHub ที่มักมีอายุหลายปี หรือ OAuth token และ personal access token (PAT) ที่ถูกขโมยจากผู้ใช้ที่ถูกต้อง แม้กิจกรรมส่วนใหญ่จะโจมตีข้อมูลสาธารณะ แต่บางกรณีก็ก้าวไปไกลกว่าการแจกแจงข้อมูลสาธารณะจนสามารถโคลน repository ส่วนตัวได้สำเร็จ
แคมเปญนี้ใช้เครื่องมือสแกนอัตโนมัติผสมกับบัญชีที่ไม่ได้ใช้งานกว่า 50 บัญชี และบัญชีที่ถูกต้องอีกหลายสิบบัญชีที่ถูกเปิดเผย PAT เพื่ออำนวยความสะดวกในการแจกแจงข้อมูล เนื่องจากพื้นผิว API ส่วนใหญ่ของ GitHub เข้าถึงได้โดยไม่ต้องยืนยันตัวตน คำสั่งแจกแจงจึงคืนข้อมูลที่จำเป็นกลับมาได้ ขณะเดียวกันก็กลมกลืนไปกับการใช้งาน API ปกติ ตัวอย่างคำสั่งที่ใช้ได้แก่ การไล่รายชื่อ repository สาธารณะขององค์กร การเดินดูรายชื่อผู้ติดตามและผู้ที่ผู้ใช้ติดตาม การแจกแจง gist, repo ที่ถูกกด star และการเป็นสมาชิกองค์กร รวมถึงการรัน GraphQL query กับอ็อบเจกต์สาธารณะ ข้อมูลเหล่านี้ถูกนำไปใช้ลาดตระเวนและปูแผนที่กิจกรรมบน GitHub ขององค์กรได้แบบอัตโนมัติ ทั้งว่ามี repository สาธารณะอะไร ใครเป็นสมาชิก สมาชิกเหล่านั้นติดตามใคร และแก้ไขโปรเจกต์ใดบ้าง
วิธีการโจมตี
หัวใจของเทคนิคนี้อยู่ที่การใช้บัญชี “ผี” ที่ถูกสร้างขึ้นเมื่อ 2 ถึง 5 ปีก่อนแล้วปล่อยทิ้งไว้ให้เงียบสนิทเป็นเวลานาน ก่อนจะปลุกขึ้นมายิงทราฟฟิก API ข้ามหลายองค์กรพร้อมกัน การมีประวัติบัญชีที่ดู “แก่” และเคยมีกิจกรรมมาก่อนช่วยให้กิจกรรมการกวาดข้อมูลดูน่าเชื่อถือและไม่จุดชนวนระบบตรวจจับ ต่างจากการสร้างบัญชีใหม่ที่เพิ่งเปิดแล้วเริ่ม scraping ทันที ซึ่งมักถูกจับตาได้ง่ายกว่า เมื่อผสานกับข้อเท็จจริงที่ว่าพื้นผิว API จำนวนมากของ GitHub เปิดให้เข้าถึงได้โดยไม่ต้องยืนยันตัวตน ผู้โจมตีจึงดึงข้อมูลที่ต้องการได้โดยที่คำขอแต่ละครั้งดูไม่มีอะไรผิดปกติ
Datadog อธิบายว่า “เมื่อพิจารณาเป็นรายคำขอ คำขอส่วนใหญ่เหล่านี้ไม่มีอะไรน่าสังเกต มันยิงไปยัง endpoint สาธารณะ ยืนยันตัวตนอย่างถูกต้องหรือไม่ยืนยันเลย และคืนผลลัพธ์สำเร็จ” แต่ความน่ากังวลอยู่ที่ภาพรวม กล่าวคือกลุ่มบัญชีที่เคลื่อนไหวสอดประสานกันข้ามองค์กรต่าง ๆ ด้วยเครื่องมือกำหนดเองที่มีการอัปเดตเวอร์ชันและวนซ้ำต่อเนื่องเป็นสัปดาห์ และในกรณีเลวร้ายที่สุดคือผู้โจมตีที่หยุดแค่การแจกแจงข้อมูลแล้วเริ่มลงมือโคลน repository จริง Datadog ยืนยันว่ามีการเข้าถึงข้อมูลสำเร็จในบางสถานการณ์ โดยผู้โจมตีลงมือโคลน repository ส่วนตัวขององค์กรหนึ่งได้จริง ซึ่งสะท้อนว่ากิจกรรมที่ดูเหมือนไม่มีพิษภัยในระดับรายคำขอ สามารถกลายเป็นการลาดตระเวนก่อนโจมตีห่วงโซ่อุปทาน (Supply Chain) ได้หากมองในภาพรวม
ผลกระทบต่อไทย
องค์กรไทยจำนวนมากทั้งบริษัทซอฟต์แวร์ สตาร์ตอัป ฟินเทค และหน่วยงานที่พัฒนาระบบเอง ต่างใช้ GitHub เป็นศูนย์กลางในการเก็บซอร์สโค้ดและบริหารทีมพัฒนา ข้อมูลที่ผู้โจมตีกวาดได้ เช่น รายชื่อ repository สาธารณะ รายชื่อสมาชิกทีม ความสัมพันธ์ระหว่างนักพัฒนา และโปรเจกต์ที่แต่ละคนแก้ไข ล้วนเป็นวัตถุดิบชั้นดีสำหรับการวางแผนโจมตีแบบเจาะจง ตั้งแต่การฟิชชิงพนักงานที่ระบุตัวได้ ไปจนถึงการโจมตีห่วงโซ่อุปทาน (Supply Chain) ผ่าน dependency หรือ CI/CD ที่ยิ่งอันตรายหากมี PAT หรือ OAuth token หลุดออกมา เพราะผู้โจมตีอาจใช้โทเคนเหล่านั้นโคลน repository ส่วนตัวที่มีความลับทางธุรกิจหรือ credential ฝังอยู่ นักพัฒนาและผู้ดูแลองค์กรในไทยจึงควรถือว่าข้อมูลเมทาดาทาบน GitHub มีค่าเชิงข่าวกรอง และเฝ้าระวังการเข้าถึงที่ผิดปกติแม้จะดูเหมือนการใช้งานปกติก็ตาม
คำแนะนำ
องค์กรควรตรวจสอบและเพิกถอน personal access token (PAT) และ OAuth token ที่ไม่ได้ใช้งานหรือมีสิทธิ์กว้างเกินจำเป็น พร้อมบังคับใช้อายุการหมดอายุของโทเคนและหมุนเวียนอย่างสม่ำเสมอ ควรเปิดใช้การยืนยันตัวตนหลายชั้น (MFA) กับทุกบัญชีในองค์กร จำกัดการมองเห็น repository และรายชื่อสมาชิกให้เป็นสาธารณะเท่าที่จำเป็นจริง และใช้เครื่องมือสแกนความลับ (secret scanning) เพื่อจับ credential ที่เผลอ commit ลงในโค้ด นอกจากนี้ควรเฝ้าระวัง log การเข้าถึง API ในเชิงภาพรวม โดยมองหาแพตเทิร์นของบัญชีหลายตัวที่เคลื่อนไหวสอดประสานกันข้ามองค์กร ทราฟฟิกจากบัญชีที่ไม่มีประวัติกิจกรรมมานาน และการเรียกโคลน repository ที่ผิดปกติ เพราะการมองแต่ละคำขอแยกกันจะไม่เห็นภาพการลาดตระเวนที่กำลังเกิดขึ้น