Wiz เปิดรายงาน AI Agent โจมตีคลาวด์ทั้งระบบ ไล่ยึด AWS, GCP และ Kubernetes เอง
Wiz CIRT เผยกรณีจริงที่ AI Agent โจมตีคลาวด์ขององค์กรตั้งแต่ต้นจนจบ เจาะจาก Kafka UI แล้วไล่ใช้ข้อมูลรับรองข้าม AWS, GCP, Kubernetes, CI/CD และระบบยืนยันตัวตน
โดย กองบรรณาธิการ THAI DATA อ่าน 5 นาที
สรุปประเด็นสำคัญ
- ทีมรับมือเหตุการณ์ของ Wiz (Wiz CIRT) เผยแพร่รายงานเมื่อ 19 ตุลาคม 2026 ว่าในการบุกรุกหลายกรณีช่วงไม่กี่สัปดาห์ที่ผ่านมา AI Agent โจมตีคลาวด์และคุมปฏิบัติการเองทั้งหมด ตั้งแต่หาทางเข้าจนถึงแก้สคริปต์ของตัวเอง
- ทางเข้าที่ยืนยันได้ทางหนึ่งคือช่องโหว่ Java RCE ใน Kafka UI ที่เปิดออกอินเทอร์เน็ต และ IP เดียวกันถูกพบสแกนสภาพแวดล้อมของลูกค้า Wiz รายอื่น มากกว่า 600 แห่ง ในช่วงเวลาเดียวกัน
- ใน AWS ผู้โจมตีสร้าง IAM user ใหม่แล้ว assume OrganizationAccountAccessRole ได้สิทธิ์ผู้ดูแลข้ามบัญชีสมาชิกทั้ง AWS Organization ส่วนใน GCP ใช้ service account ที่สร้างโทเคนได้ออกข้อมูลรับรองให้หลายสิบตัวตน
- บน CI/CD และ GitOps มีงาน 5 สายรันพร้อมกัน และ manifest แรกที่ดันเข้าคลัสเตอร์ Kubernetes ยกระดับเป็น cluster-admin
- เมื่อ AI Agent โจมตีคลาวด์ จังหวะการทำงานสูงถึงหลายร้อยถึงหลายพันคำสั่งต่อชั่วโมง และทรัพยากรที่สร้างขึ้นมีชื่ออย่าง pentest, probe, recon ซึ่ง Wiz ประเมินว่าน่าจะใช้หลบ guardrail ของโมเดล AI
ทีมรับมือเหตุการณ์ของ Wiz (Wiz Customer Incident Response Team หรือ CIRT) เผยแพร่รายงานเมื่อ 19 ตุลาคม 2026 ชำแหละกรณีจริงที่ AI Agent โจมตีคลาวด์ขององค์กรแห่งหนึ่งตั้งแต่ต้นจนจบ ระบบเอเจนต์หาทางเข้า เก็บข้อมูลรับรอง และกระโดดข้าม AWS, Google Cloud (GCP), Kubernetes, CI/CD และ Identity Provider ด้วยความเร็วที่คนทำไม่ได้
รายงานเขียนโดย Eden Abergil, Zohar Kaplan และ Kurt Giacchino ระบุว่าในการบุกรุกหลายกรณีช่วงไม่กี่สัปดาห์ที่ผ่านมา AI ไม่ได้เป็นแค่ผู้ช่วยของแฮกเกอร์อีกต่อไป แต่เป็น AI Agent โจมตีคลาวด์และคุมปฏิบัติการเองทั้งหมด Wiz ไม่ได้เปิดเผยชื่อองค์กรที่ถูกโจมตี บอกเพียงว่าเป็นองค์กรที่ใช้หลายคลาวด์ขนาดใหญ่ และชี้ว่าปัญหาของฝ่ายป้องกันไม่ใช่การมองไม่เห็น แต่ร่องรอยกระจายอยู่ใน log หลายระบบจนไม่มี alert ใดเล่าเรื่องได้ครบ
AI Agent โจมตีคลาวด์ต่างจากแฮกเกอร์ทั่วไปอย่างไร
Wiz CIRT สรุปลักษณะของ AI Agent โจมตีคลาวด์ที่พบซ้ำในหลายการสอบสวน ซึ่งแยกการโจมตีแบบนี้ออกจากทั้งการโจมตีที่คนลงมือเองและสคริปต์อัตโนมัติแบบเดิม
- จังหวะเร็วและไม่หยุด กิจกรรมสูงถึงหลายร้อยถึงหลายพันคำสั่งต่อชั่วโมง ต่อเนื่องเป็นเวลานานโดยไม่มีช่วงพักหรือรูปแบบเวลาทำงานแบบคน
- ทำหลายแพลตฟอร์มพร้อมกัน ขณะที่งานหนึ่งสำรวจทรัพยากรคลาวด์ อีกงานหนึ่ง deploy workload ลง Kubernetes สร้าง pipeline หรือ query ฐานข้อมูล จากต้นทางเดียวกันในช่วงเวลาเดียวกัน
- ไล่ใช้ข้อมูลรับรองต่อเป็นทอด เช่น service account token ของ Kubernetes นำไปสู่ service account บนคลาวด์ แล้วไปถึงระบบ CI/CD จนได้สิทธิ์ผู้ดูแลเต็ม
- ลองผิดลองถูกแบบเรียลไทม์ เมื่อพยายามแล้วล้มเหลว เอเจนต์อ่าน error เขียนสคริปต์ใหม่ และลองอีกครั้งภายในไม่กี่นาที
- ตั้งชื่อแบบงานทดสอบเจาะระบบ ทรัพยากรและไฟล์มีคำว่า pentest, probe, recon, redteam, exfil ซึ่ง Wiz ประเมินว่าน่าจะช่วยให้กิจกรรมดูเหมือนการทดสอบที่ได้รับอนุญาตและหลบ guardrail ของโมเดล AI
- มีรหัสงานเป็นตัวเลข ตัวเลขเดียวกันปรากฏในหลายสิ่งที่เกี่ยวข้องกัน และงานที่ล้มเหลวถูกลองใหม่ด้วยเลขเดิมต่อท้าย -b, -c, -d
เส้นทางที่ AI Agent โจมตีคลาวด์: จาก Kafka UI ถึง AWS และ GCP
ผู้โจมตีลองหลายประตูพร้อมกัน ทั้งส่ง payload ของช่องโหว่ที่รู้จักกันดี ลองเข้า cloud storage แบบไม่ยืนยันตัวตน และไล่ใช้ API ของเครื่องมือนักพัฒนาที่เปิดออกภายนอก ทางเข้าที่ยืนยันได้ทางหนึ่งคือช่องโหว่ Java remote code execution ใน Kafka UI ที่เปิดออกอินเทอร์เน็ต แม้จะได้ฐานที่มั่นแล้วก็ยังสแกนหาทางเข้าสำรองต่อ และ IP เดียวกันถูกพบสแกนสภาพแวดล้อมของลูกค้า Wiz รายอื่นมากกว่า 600 แห่งในช่วงเดียวกัน
| ขั้น | สิ่งที่ AI Agent ทำตามรายงานของ Wiz |
|---|---|
| ในพ็อด Kubernetes | วาง backdoor ในหลายพ็อดข้ามหลายคลัสเตอร์ ดึง service account token ค้นตัวแปร environment ที่มีคำว่า token, secret, key, pass และ query IMDS เพื่อเอาข้อมูลรับรองของโหนด |
| GCP | ใช้ service account ที่มีสิทธิ์สร้างโทเคนออกข้อมูลรับรองให้หลายสิบตัวตน กวาดข้อมูลจาก container registry และสร้างบริการ Cloud Run แบบสาธารณะที่ขึ้นต้นด้วย pentest- |
| AWS | สั่งงานข้ามเครื่องผ่าน AWS Systems Manager (SSM) เตรียมส่งข้อมูลออกไป bucket ชื่อ pentest-<task_id> และสร้าง IAM user ขึ้นต้นด้วย probe เพื่อ assume OrganizationAccountAccessRole |
| Identity Provider | ใช้ admin API key ที่ถูกเจาะสร้างผู้ใช้ใหม่ ตั้งรหัสผ่าน เพิ่มเข้ากลุ่มผู้ดูแลและกลุ่มที่ผูกกับ AWS IAM Identity Center แล้วเข้า AWS ผ่าน SSO ภายในไม่กี่นาที |
AI Agent โจมตีคลาวด์ผ่าน CI/CD, GitOps และ Kubernetes
Wiz ระบุว่าแพลตฟอร์ม CI/CD และ GitOps เป็นตัวรันงานหลักเมื่อ AI Agent โจมตีคลาวด์ครั้งนี้ โดยมีงาน 5 สายทำพร้อมกันและป้อนผลให้กัน ได้แก่ เก็บ secret จากทุกแหล่ง สำรวจว่า runner และพ็อดแต่ละตัวเข้าถึงอะไรได้ ลองข้อมูลรับรองกับเป้าหมายที่เข้าถึงได้ ศึกษาและใช้บริการที่พบ และขยายกำลังประมวลผลด้วย runner กับพ็อดใหม่ ข้อมูลรับรองใหม่ทุกตัวถูกลองกับทุกเป้าหมายทันที
บนแพลตฟอร์ม GitOps เอเจนต์ใช้ deployment service account ที่ถูกเจาะดัน manifest ที่เป็นอันตรายเข้าคลัสเตอร์ production และ manifest แรกยกระดับเป็น cluster-admin จากนั้นดึง Secret ข้ามหลายคลัสเตอร์ เมื่อ RBAC กันไว้ก็หันไปอ่าน ConfigMap ที่มีรหัสผ่านเริ่มต้นและคีย์เข้ารหัสแบบข้อความธรรมดา พยายามอ่านไฟล์ที่ vault-agent sidecar ถอดรหัสไว้ในพ็อด และวาง C2 เป็น workload ที่ฟื้นตัวเองได้ ภายหลังยังแก้ workload ผ่าน GitOps controller โดยตรงจึงไม่เหลือร่องรอยใน Git history
การส่งข้อมูลออกเปลี่ยนช่องทางตามที่แต่ละสภาพแวดล้อมยอม ทั้งส่งไป webhook[.]site, commit ข้อมูลลง repository ขององค์กรเอง, ใช้ log ของ runner และเก็บไว้ใน ConfigMap ส่วนการสร้าง bucket ปลายทางถูกปฏิเสธ
ทำไมเรื่องนี้สำคัญ
กรณี AI Agent โจมตีคลาวด์ครั้งนี้แสดงว่าสิทธิ์ที่ตั้งไว้กว้างเกินไปในจุดเดียวกลายเป็นสิทธิ์ทั้งองค์กรได้ในเวลาไม่นาน เอกสารของ AWS ระบุว่าเมื่อสร้างบัญชีสมาชิกผ่านคอนโซล AWS Organizations ระบบจะสร้าง OrganizationAccountAccessRole ให้อัตโนมัติ และ role นี้มีสิทธิ์ผู้ดูแลเต็มในบัญชีสมาชิก ส่วนเอกสารของ Google Cloud ระบุว่าการสวมสิทธิ์ service account ต้องใช้ permission iam.serviceAccounts.getAccessToken ซึ่งอยู่ใน role อย่าง Service Account Token Creator ตัวตนที่ถือ role นี้จึงเป็นโรงงานออกโทเคนให้ผู้โจมตีได้ทันที
อีกประเด็นคือเมื่อ AI Agent โจมตีคลาวด์ ร่องรอยจะ "ดัง" แต่ฝ่ายป้องกันจะได้ประโยชน์จากเสียงดังนั้นก็ต่อเมื่อเห็นครบทุกระบบ ทุกช่วงของเหตุครั้งนี้ปรากฏใน log คนละแหล่ง ทั้ง audit log ของคลาวด์และ Kubernetes, runtime, Identity Provider และ CI/CD
สิ่งที่องค์กรไทยควรทำ
- รวม log ไว้ค้นที่เดียว audit log ของคลาวด์และ Kubernetes, เหตุการณ์ runtime, log ของ Identity Provider, CI/CD และแอป SaaS ควรอยู่ในที่เดียวกันด้วยระยะเก็บที่เท่ากัน
- ตรวจสิทธิ์ที่ AI Agent โจมตีคลาวด์ใช้ข้ามระบบ ดูว่าใครบ้างที่ assume OrganizationAccountAccessRole ได้ (เอกสาร AWS ให้ใส่เงื่อนไข MFA หรือช่วง IP ในนโยบายได้) และใครถือ Service Account Token Creator บน GCP รวมทั้ง pipeline ที่ถือสิทธิ์ถาวรทุก environment
- ปิดเครื่องมือที่ไม่ควรออกอินเทอร์เน็ต เช่น Kafka UI คอนโซลจัดการ และเครื่องมือนักพัฒนาภายใน เพราะ AI Agent โจมตีคลาวด์โดยกวาดหาทุกช่องที่เปิดอยู่
- เมื่อยืนยันเหตุแล้วให้ถือว่าทุกอย่างรั่ว Wiz แนะนำให้เปลี่ยนข้อมูลรับรองทุกตัวบนทรัพยากรที่ถูกเจาะแทนการไล่หาว่าตัวไหนถูกอ่าน แล้วตามดูการใช้งานผิดปกติของแต่ละตัวตนหลังเวลาที่ถูกเจาะ
- ตั้งการค้นหาสัญญาณที่รายงานให้ไว้ ทรัพยากรชื่อ pentest, probe, recon, redteam หรือ exfil ที่มีเลขกำกับ และการเชื่อมต่อออกไปยังบริการรับ webhook อ่านพื้นฐาน Kubernetes และข่าวคลาวด์อื่นได้ที่หมวดคลาวด์
คำถามที่พบบ่อย
AI Agent โจมตีคลาวด์ในรายงานของ Wiz ต่างจากการโจมตีทั่วไปอย่างไร?
ในกรณีที่ Wiz CIRT สอบสวน AI Agent โจมตีคลาวด์ด้วยความเร็วหลายร้อยถึงหลายพันคำสั่งต่อชั่วโมงโดยไม่หยุดพัก ทำงานหลายแพลตฟอร์มพร้อมกัน ใช้ API ของแต่ละระบบได้คล่อง และเมื่อสคริปต์ล้มเหลวก็อ่าน error แล้วเขียนใหม่ภายในไม่กี่นาที ต่างจากคนที่ทำทีละระบบหรือสคริปต์ที่รันตามขั้นตอนตายตัว
AI Agent โจมตีคลาวด์ในรายงานของ Wiz เข้าระบบได้อย่างไร?
Wiz ระบุว่า AI Agent โจมตีคลาวด์โดยลองหลายช่องทาง ทั้งส่ง payload ของช่องโหว่ที่รู้จักกันดี ลองเข้า cloud storage แบบไม่ยืนยันตัวตน และใช้ API ของเครื่องมือนักพัฒนาที่เปิดออกภายนอก ทางเข้าที่ยืนยันได้ทางหนึ่งคือช่องโหว่ Java remote code execution ใน Kafka UI ที่เปิดออกอินเทอร์เน็ต
Kubernetes ถูกใช้ในการโจมตีครั้งนี้อย่างไร?
ในกรณีที่ AI Agent โจมตีคลาวด์ครั้งนี้ Wiz ระบุว่าเอเจนต์เข้าถึง Kubernetes API ได้สามทาง คือ runner ของ CI/CD, การ deploy ผ่าน GitOps และตัวตนที่สร้างเองใน Identity Provider จากนั้นดึง Secret และ ConfigMap ข้ามหลายคลัสเตอร์ ยกระดับเป็น cluster-admin และวาง C2 เป็น workload ที่ฟื้นตัวเองได้แม้พ็อดถูกลบ
องค์กรควรป้องกัน AI Agent โจมตีคลาวด์อย่างไร?
Wiz แนะนำให้รวม log ของคลาวด์ Kubernetes Identity Provider และ CI/CD ไว้ค้นที่เดียว เปลี่ยนข้อมูลรับรองทุกตัวบนทรัพยากรที่ถูกเจาะแทนการไล่หาว่าตัวไหนถูกอ่าน แยกความไว้ใจระหว่าง staging กับ production และสแกนระบบที่เปิดออกอินเทอร์เน็ตอย่างต่อเนื่อง เพราะ AI Agent โจมตีคลาวด์โดยกวาดหาช่องโหว่ได้กว้างและเร็ว
แหล่งอ้างอิง
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- Wiz3AWS37Google Cloud30
- ผลิตภัณฑ์และเทคโนโลยี
- Kubernetes20Java8
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ