Storm-3068 เจาะ Azure DevOps ขโมย Kubernetes Credential จากบัญชีเดียว

Microsoft Threat Intelligence และทีม DART เปิดเผยแคมเปญของกลุ่ม Storm-3068 ที่เริ่มต้นจากการยึดบัญชีผู้ใช้เพียงบัญชีเดียวผ่าน Self-Service Password Reset ก่อนขยายการเข้าถึงเข้าสู่ Azure DevOps, Pipeline และ Kubernetes Cluster ทั่วทั้งองค์กร โดยไม่ใช้ช่องโหว่ซอฟต์แวร์หรือ Custom Malware แต่อย่างใด สิ่งที่น่ากังวลคือการโจมตีทั้งหมดอาศัยเพียงสิทธิ์ที่บัญชีมีอยู่เดิมและเครื่องมือที่ถูกกฎหมาย ทำให้แยกแยะจากกิจกรรม Developer ปกติได้ยากมาก

รายละเอียดการโจมตี

การยึดบัญชีเริ่มต้นผ่าน Self-Service Password Reset

Storm-3068 เริ่มต้นด้วยการใช้ประโยชน์จาก Self-Service Password Reset (SSPR) ซึ่งเป็นฟีเจอร์ที่องค์กรส่วนใหญ่เปิดไว้เพื่อลดภาระ IT Helpdesk หลังจากรีเซ็ต Password สำเร็จ ผู้โจมตีลงทะเบียน Authentication Method ของตนเองเข้ากับบัญชีเหยื่อเพื่อรักษาการเข้าถึงระยะยาว การกระทำนี้ทำให้เจ้าของบัญชีจริงสูญเสียการควบคุมบัญชีโดยไม่รู้ตัว ขณะที่ผู้โจมตีได้รับ Persistent Access ที่ผ่านการยืนยัน MFA อย่างถูกต้อง

การสำรวจ Azure DevOps และ Pipeline

ด้วยสิทธิ์ที่ได้รับจากบัญชีที่ยึดมา Storm-3068 ใช้ Legitimate Administrative Tools และ Automated Scripts สำรวจ Azure DevOps Projects, Repositories, Pipelines และ Deployment Environments อย่างเป็นระบบ Microsoft ระบุว่า "Repositories, Service Connections และ Deployment Settings สามารถเป็น Roadmap สู่สภาพแวดล้อมที่กว้างขวางขึ้นขององค์กร" ข้อมูลที่ได้จากการสำรวจนี้ทำให้ผู้โจมตีมองเห็นภาพรวมของโครงสร้างพื้นฐานทั้งหมดของเหยื่อ รวมถึงเส้นทางที่เชื่อมต่อไปยัง Production Environment

การสร้าง Malicious Pipeline เพื่อขโมย Kubernetes Credential

ขั้นตอนที่ซับซ้อนที่สุดคือการสร้าง Malicious Pipeline ใน Azure DevOps เพื่อดึง Kubernetes Credential ในวงกว้าง โดย Pipeline ถูกออกแบบให้รัน Job หลายรายการเพื่อค้นหาและดึง Cluster Configuration File ที่มี Authentication Data พบว่ามีการเข้าถึง Resource มากกว่า 50 รายการ และสามารถ Compromise Kubernetes Cluster ได้สำเร็จถึง 7 Cluster พร้อมเพิ่ม Kubeconfig File ที่ขโมยมา 7 ชุดเข้าไปใน Repository

การติดตั้ง Remote Access และ Tunneling

หลังได้รับ Credential ของ Kubernetes Cluster แล้ว Storm-3068 ดำเนินการติดตั้ง Persistence Mechanism โดยปรับแก้ Pipeline Script เพื่อติดตั้ง Atera Remote Management Agent บนระบบเป้าหมาย และใช้ Chisel Tunneling Utility สร้าง Reverse Tunnel ไปยัง External IP เพื่อเปิดเส้นทางเชื่อมต่อกับ Kubernetes API Server โดยตรง ซึ่งทำให้ผู้โจมตีสามารถ Operate ภายในเครือข่ายได้โดยไม่จำเป็นต้องผ่าน Perimeter Security อีกต่อไป

การสืบสวนและ Containment โดย Microsoft DART

Microsoft DART (Detection and Response Team) ร่วมกับ Microsoft Threat Intelligence ทำการสืบสวนและดำเนินการ Contain ผ่าน Daily Briefing และ Prioritized Guidance ตลอดกระบวนการ หลักฐานที่พบในการสืบสวน ได้แก่ Git Version History ที่แสดงการเปลี่ยนแปลง Code ที่ไม่ได้รับอนุมัติ, Audit Log ของการ Reset Password ที่ผิดปกติ และ Pipeline Artifact ที่มีพฤติกรรมผิดปกติ

ผลกระทบที่อาจเกิดขึ้น

1. บัญชีเดียวกลายเป็นประตูสู่ Infrastructure ทั้งหมด — ความสำเร็จของ Storm-3068 สะท้อนว่าหากบัญชีที่มีสิทธิ์เข้าถึง Azure DevOps ถูกยึด ผู้โจมตีสามารถมองเห็นและเข้าถึง Development Pipeline, Service Connection และ Kubernetes Cluster ทั้งหมดที่บัญชีนั้นมีสิทธิ์ได้
2. Source Code และ Secret ใน Pipeline ตกอยู่ในอันตราย — Azure DevOps Pipeline มักมี Secret, API Key, Service Account Password และ Deployment Token ที่ฝังอยู่ในรูปแบบ Variable หรือ Service Connection ซึ่งผู้โจมตีสามารถดึงออกมาได้ทั้งหมดหากได้รับสิทธิ์เข้าถึง Repository
3. การตรวจจับทำได้ยากเนื่องจากใช้ Legitimate Tool — การที่ Storm-3068 ใช้เฉพาะ Tool ที่ถูกกฎหมายและสิทธิ์ที่มีอยู่เดิม ทำให้กิจกรรมผสมกับ Developer Activity ปกติ Detection ที่พึ่งพา Signature หรือ Malware Pattern จะไม่ตรวจพบพฤติกรรมเหล่านี้
4. Kubernetes Cluster ที่ถูก Compromise เปิดทางสู่ Production — เมื่อ Attacker ได้ Kubeconfig File ของ Cluster แล้ว สามารถเข้าถึงทุก Container และ Workload ที่รันอยู่ รวมถึง Secret ที่ Inject เข้าไปใน Pod ซึ่งอาจรวมถึง Database Credential และ Third-Party API Key

สิ่งที่องค์กรควรทำ

1. จำกัดการใช้ SSPR สำหรับบัญชีที่มีสิทธิ์สูง — ห้ามหรือเพิ่มขั้นตอน Approval สำหรับ Privileged Account ที่ทำ Self-Service Password Reset โดยเฉพาะบัญชีที่มีสิทธิ์เข้าถึง Azure DevOps, Production Pipeline หรือ Kubernetes Environment และตรวจสอบ Authentication Method Registration ที่ไม่คาดคิด
2. ใช้ Phishing-Resistant MFA และ Branch Protection — Enforce Multi-Factor Authentication ที่ต้านทาน Phishing ได้สำหรับทุก Account ที่เข้าถึง Azure DevOps และกำหนด Branch Protection Policy ที่กำหนดให้การ Merge ต้องผ่าน Code Review จากบุคคลที่สอง เพื่อป้องกันการแก้ไข Pipeline Script โดยไม่ได้รับอนุมัติ
3. จำกัดสิทธิ์การสร้างและแก้ไข Pipeline — ใช้หลัก Least-Privilege กับ Azure DevOps Permission โดยจำกัดว่าบัญชีใดสามารถสร้าง Pipeline ใหม่หรือแก้ไข Pipeline ที่มีอยู่ได้ รวมถึงตรวจสอบและจำกัด Service Connection ที่ Pipeline มีสิทธิ์เข้าถึง
4. ตรวจสอบ Audit Log สำหรับ Kubernetes Access ที่ผิดปกติ — ตรวจสอบ Kubernetes Audit Log สำหรับ Job ที่ดึง Configuration File หรือ Secret ในปริมาณสูงผิดปกติ, การติดตั้ง Agent ใหม่บน Node และ Connection ออกไปยัง External IP ที่ไม่คุ้นเคยจาก Cluster Environment

แนวทางลดความเสี่ยงระยะยาว

1. DevSecOps Pipeline Security — ทบทวน Security ของ CI/CD Pipeline อย่างสม่ำเสมอ รวมถึงการตรวจสอบว่า Secret ที่ใช้ใน Pipeline ถูกจัดการผ่าน Vault หรือ Secret Manager แทนการ Hardcode หรือใส่เป็น Plain Text Variable และกำหนด Approval Gate สำหรับ Pipeline ที่เข้าถึง Production Environment
2. Workload Identity แทน Static Credential — แทนที่การใช้ Credential แบบ Static ใน Kubernetes และ Cloud Environment ด้วย Workload Identity หรือ OIDC-Based Authentication ซึ่งออก Token ชั่วคราวที่หมดอายุโดยอัตโนมัติ ทำให้แม้ผู้โจมตีจะขโมย Configuration File ได้ก็ไม่สามารถใช้งาน Credential ระยะยาวได้
3. Zero Trust สำหรับ Development Environment — ออกแบบ Network Architecture ที่ Kubernetes API Server และ Development Environment ไม่สามารถเข้าถึงได้จาก Internet โดยตรง ใช้ Bastion Host หรือ Private Link และบังคับให้ทุก Connection ผ่าน Identity-Aware Proxy ที่ตรวจสอบ Context ของผู้ขอเชื่อมต่อทุกครั้ง
4. Behavioral Detection สำหรับ Developer Activity — ใช้ UEBA หรือ Anomaly Detection ที่เรียนรู้รูปแบบกิจกรรมปกติของ Developer แต่ละคน และแจ้งเตือนเมื่อพบ Pattern ผิดปกติ เช่น การเข้าถึง Repository หลายร้อยรายการในเวลาสั้น, การสร้าง Pipeline ในเวลานอกเวลาทำการ หรือการ Push Code จาก IP ที่ไม่เคยใช้มาก่อน

วิเคราะห์ในมุมมองจาก TXEC

Storm-3068 เป็นตัวอย่างที่ชัดเจนของแนวคิด "Living Off the Land in the Cloud" ซึ่งผู้โจมตีไม่จำเป็นต้องนำเครื่องมือโจมตีที่แปลกปลอมเข้ามาในระบบเลย เพราะทุกสิ่งที่ต้องการมีอยู่แล้วในรูป Legitimate Tool และ Native Cloud Feature กรณีนี้ยังเน้นย้ำว่าการมี MFA เพียงอย่างเดียวไม่เพียงพอ หาก Self-Service Password Reset เปิดช่องให้ผู้โจมตีลงทะเบียน Authentication Method ของตัวเองได้ MFA ก็กลายเป็นสิ่งที่ควบคุมโดยผู้โจมตีแทน

สำหรับองค์กรไทยที่ใช้ Azure DevOps ในกระบวนการพัฒนาซอฟต์แวร์ โดยเฉพาะองค์กรที่มี Kubernetes Cluster บน Azure หรือ Cloud อื่น ขอแนะนำให้ตรวจสอบทันทีว่า SSPR Policy และ Authentication Method Registration ถูก Scope จำกัดเหมาะสมหรือไม่ และ Pipeline ทั้งหมดมี Approval Process ก่อนที่ Code Change จะถูก Execute หรือยัง เพราะ Azure DevOps ที่ไม่ได้ตั้งค่า Security ไว้อย่างรัดกุมอาจกลายเป็นแผนที่นำผู้โจมตีไปยัง Infrastructure ทั้งหมดขององค์กรได้ รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า

[ แหล่งอ้างอิง: CyberSecurity News , Microsoft Threat Intelligence / DART ]