Datadog Security Research ตรวจพบแคมเปญ Password Spraying ที่มุ่งโจมตี AWS Root Account ขององค์กรมากกว่า 150 แห่ง ระหว่างวันที่ 24 กรกฎาคม ถึง 23 สิงหาคม 2569 โดยผู้ไม่ประสงค์ดีพยายามเข้าสู่ AWS Management Console ด้วยรหัสผ่านที่พบบ่อยหรืออาจรั่วไหลมาก่อน แม้ยังไม่พบหลักฐานการเข้าสู่ระบบสำเร็จในแคมเปญนี้ แต่ลักษณะการกระจายความพยายามไปยังหลายบัญชีและหลายประเทศสะท้อนถึงปฏิบัติการที่มีการวางแผนมาอย่างดี
รายละเอียดแคมเปญ
AWS Root Account คือเป้าหมายที่มีความอ่อนไหวสูงที่สุด
AWS Root User คือ Identity ดั้งเดิมที่ถูกสร้างขึ้นเมื่อลงทะเบียนบัญชี AWS มีสิทธิ์การเข้าถึงแบบไม่จำกัดเหนือทรัพยากร Cloud, การตั้งค่าบัญชี, ข้อมูล Billing และฟังก์ชันการดูแลระบบที่มีความอ่อนไหวสูง หากบัญชีนี้ถูกบุกรุกสำเร็จ ผู้โจมตีอาจได้รับการควบคุมสภาพแวดล้อม AWS ขององค์กรในวงกว้างมากกว่าการบุกรุกบัญชี IAM ทั่วไป
ลักษณะการโจมตีแบบ Password Spraying
Datadog พบว่าองค์กรส่วนใหญ่ที่ตกเป็นเป้าหมายได้รับความพยายาม Login ที่ล้มเหลวเพียงไม่กี่ครั้ง โดยค่ามัธยฐานอยู่ที่ 2 ครั้งต่อองค์กร ขณะที่บางรายพบมากถึง 8 ครั้งตลอดระยะเวลาหนึ่งเดือน ลักษณะนี้เป็นรูปแบบเฉพาะของ Password Spraying ซึ่งเป็นเทคนิคที่ผู้โจมตีทดลองรหัสผ่านที่พบบ่อยหรือเคยรั่วไหลจำนวนจำกัดกับบัญชีจำนวนมาก แทนที่จะพยายามหลายครั้งกับบัญชีเดียว เพื่อหลีกเลี่ยงการถูก Lockout จาก Brute Force แบบดั้งเดิมที่มุ่งเป้าไปที่บัญชีเดียวซ้ำๆ
Indicator ที่พบในกิจกรรม
นักวิจัยพบ User-Agent String 2 รูปแบบ ที่ปรากฏซ้ำในกิจกรรมนี้อย่างสม่ำเสมอ
- รูปแบบหนึ่งเลียนแบบ Microsoft Edge รุ่นเก่าที่ใช้ Chrome Version 85 เป็นฐาน
- อีกรูปแบบเลียนแบบ Firefox เวอร์ชัน 120
แม้ค่า User-Agent จะสามารถปลอมแปลงได้ง่ายโดยผู้โจมตี แต่ยังสามารถใช้เป็นจุดเริ่มต้นในการค้นหา Log การยืนยันตัวตนที่เกี่ยวข้องได้ในการทำ Retrospective Hunting
โครงสร้างพื้นฐานที่ใช้ปกปิดต้นทาง
แคมเปญนี้อาศัย Proxy Infrastructure โดยกระจาย Source IP Address ไปยังหลายประเทศและหลาย Autonomous System ทำให้มาตรการป้องกันแบบ Geo-blocking หรือ IP-based Blocking มีประสิทธิภาพลดลงอย่างมีนัยสำคัญ Threat Intelligence Service ระบุว่าโครงสร้างพื้นฐานที่ใช้เป็น Hosting Service, Residential Proxy หรือระบบลักษณะเดียวกันที่มักถูกใช้เพื่อซ่อนต้นทางที่แท้จริงของกิจกรรมที่เป็นอันตราย
รูปแบบการเลือกเป้าหมาย
องค์กรที่ตกเป็นเป้าหมายไม่มีรูปแบบชัดเจนทั้งในแง่อุตสาหกรรมและประเทศ บ่งชี้ว่าผู้โจมตีอาจใช้รายชื่ออีเมลบัญชี AWS จำนวนมากมากกว่าการมุ่งเป้าไปที่ภาคส่วนใดภาคส่วนหนึ่งโดยเฉพาะ ประเด็นที่น่าสนใจคือการ Login ผ่าน Root User จำเป็นต้องใช้ Email Address ของบัญชี ซึ่งบ่งชี้ว่าผู้โจมตีอาจได้รับ Email เหล่านี้มาจาก Data Leak, ข้อมูลสาธารณะ, Phishing หรือการทำ Reconnaissance รูปแบบอื่น หรืออาจทดสอบ Email องค์กรจำนวนมากจนพบ Root Identity ที่ใช้งานได้จริง
ผลกระทบที่อาจเกิดขึ้น
- AWS Root Account เป็นบัญชีที่มีสิทธิ์ไม่จำกัดเหนือทรัพยากร Cloud ทั้งหมด หากถูกบุกรุกสำเร็จ ผู้โจมตีอาจควบคุมสภาพแวดล้อม AWS ขององค์กรได้อย่างกว้างขวาง รวมถึงการเข้าถึงข้อมูล Billing และการตั้งค่าบัญชีระดับสูงสุด
- แม้ยังไม่พบการเข้าสู่ระบบสำเร็จในแคมเปญนี้ แต่การที่ผู้โจมตีทราบ Email ของ Root Account จำนวนมากสะท้อนถึงความเสี่ยงด้าน Reconnaissance ที่องค์กรอาจไม่รู้ตัว และอาจถูกนำไปใช้ในการโจมตีรูปแบบอื่นในอนาคต เช่น Phishing ที่มุ่งเป้าเฉพาะเจาะจง
- การใช้ Proxy กระจายในหลายประเทศทำให้มาตรการป้องกันแบบ Geo-blocking หรือ IP-based Blocking มีประสิทธิภาพจำกัดต่อแคมเปญลักษณะนี้ องค์กรจึงจำเป็นต้องพึ่งพามาตรการป้องกันที่ไม่ยึดติดกับ Location ของ Source IP เพียงอย่างเดียว
- รูปแบบ Password Spraying ที่กระจายความพยายามไปยังหลายบัญชีทำให้ยากต่อการตรวจจับด้วย Threshold-based Alert แบบดั้งเดิม ที่มักตั้งค่าจากจำนวนความพยายาม Login ที่ล้มเหลวติดต่อกันในบัญชีเดียว
สิ่งที่องค์กรควรทำ
- ตรวจสอบให้แน่ใจว่า Root Account ทุกบัญชีเปิดใช้งาน Multi-factor Authentication ตามที่ AWS บังคับใช้ตั้งแต่เดือนมิถุนายน 2568 พร้อมพิจารณาใช้ Hardware MFA แบบ Phishing-resistant สำหรับ Management Account ที่มีความสำคัญสูง
- ตรวจสอบ AWS CloudTrail Log สำหรับ ConsoleLogin Event ระดับ Root โดยเฉพาะความพยายาม Login ที่ล้มเหลวซึ่งใช้ User-Agent ที่ตรงกับรูปแบบที่ระบุ (Edge บน Chrome 85 หรือ Firefox 120)
- ตั้ง Alert สำหรับการ Login สำเร็จระดับ Root, กิจกรรม Root API และการเปลี่ยนแปลง Credential ของ Root เพื่อให้ทีม Security ทราบทันทีหากมีกิจกรรมที่เกี่ยวข้องกับ Root Account เกิดขึ้น
- ลดการใช้งาน Root Credential ตามปกติให้เหลือน้อยที่สุด เปิดใช้ Centralized Root Access ผ่าน AWS Organizations หากทำได้ และบังคับใช้ Service Control Policy (SCP) เพื่อจำกัดกิจกรรม Root โดยตรงใน Member Account
แนวทางลดความเสี่ยงระยะยาว
1. จัดทำ Inventory ของ Root Account Email ทุกบัญชี AWS ในองค์กร และพิจารณาใช้ Email Alias เฉพาะที่ไม่เปิดเผยต่อสาธารณะ
เพื่อลดโอกาสที่ Email ของ Root Account จะรั่วไหลผ่าน Data Leak หรือถูกคาดเดาได้ง่ายจากรูปแบบ Email องค์กรทั่วไป
2. บังคับใช้ Hardware Security Key หรือ Phishing-resistant MFA สำหรับ Root และบัญชีที่มีสิทธิ์สูงทั้งหมด
เนื่องจาก Password Spraying เป็นเพียงขั้นตอนแรกของการโจมตี การมี MFA ที่แข็งแกร่งช่วยป้องกันการเข้าถึงได้แม้รหัสผ่านจะถูกเดาถูกต้อง
3. ผสาน Threat Intelligence เกี่ยวกับ Proxy/Residential Proxy Infrastructure เข้ากับระบบ Detection
เพื่อชดเชยข้อจำกัดของมาตรการ Geo-blocking แบบดั้งเดิมที่ไม่สามารถรับมือกับการโจมตีที่กระจาย Source IP ไปยังหลายประเทศได้อย่างมีประสิทธิภาพ
4. ทบทวนและซ้อม Incident Response Playbook เฉพาะสำหรับกรณี Root Account Compromise
เนื่องจากผลกระทบจากการบุกรุก Root Account มีความรุนแรงและซับซ้อนกว่าการบุกรุกบัญชี IAM ทั่วไปมาก ควรมีขั้นตอนที่ชัดเจนสำหรับการตอบสนองอย่างรวดเร็ว
วิเคราะห์ในมุมมองจาก TXEC
แคมเปญนี้เป็นตัวอย่างที่ชัดเจนของการโจมตีที่ TXEC เฝ้าติดตามอย่างต่อเนื่อง นั่นคือการมุ่งเป้าไปที่ Identity ที่มีสิทธิ์สูงสุดในสภาพแวดล้อม Cloud โดยตรง แทนที่จะพยายามเจาะระบบผ่านช่องทางทางเทคนิคที่ซับซ้อน สิ่งที่น่าสนใจเป็นพิเศษคือแม้แคมเปญนี้จะยังไม่ประสบความสำเร็จตามที่ Datadog รายงาน แต่ขนาดของปฏิบัติการที่ครอบคลุมกว่า 150 องค์กร พร้อมโครงสร้างพื้นฐาน Proxy ที่กระจายในหลายประเทศ แสดงให้เห็นถึงระดับการลงทุนที่ผู้โจมตีทุ่มเทให้กับการโจมตี Cloud Identity โดยเฉพาะ
TXEC มองว่าเหตุการณ์นี้ตอกย้ำความสำคัญของการบังคับใช้ MFA บน Root Account อย่างเคร่งครัด ซึ่งเป็นมาตรการที่ AWS เริ่มบังคับใช้มาตั้งแต่กลางปี 2568 แต่องค์กรจำนวนไม่น้อยอาจยังไม่ได้ทบทวนหรือยืนยันสถานะการเปิดใช้งานอย่างครบถ้วน โดยเฉพาะในบัญชี AWS ที่สร้างขึ้นมานานและอาจถูกมองข้ามจากทีม Security ในปัจจุบัน การตรวจสอบ Root Account ทุกบัญชีอย่างสม่ำเสมอจึงควรเป็นส่วนหนึ่งของ Cloud Security Hygiene พื้นฐานที่ทุกองค์กรควรมี
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News, Datadog Security Labs ]