การโจมตีรูปแบบนี้เรียกว่า Agent Data Injection หรือ ADI โดยผู้โจมตีจะไม่พยายามซ่อนคำสั่งอันตรายไว้ในข้อความโดยตรง แต่จะเปลี่ยนแปลงข้อเท็จจริงเล็ก ๆ เช่น ชื่อผู้ส่งอีเมล หมายเลขปุ่มบนหน้าเว็บ ชื่อผู้เขียนความคิดเห็น หรือผลลัพธ์จากเครื่องมือที่ Agent เชื่อว่าเคยดำเนินการแล้ว

ผลที่ตามมาคือ AI Agent ยังคงทำงานตามคำสั่งของผู้ใช้ตามปกติ แต่ทำงานบนข้อมูลที่ถูกปลอมแปลง ซึ่งอาจนำไปสู่การสั่งซื้อสินค้าโดยไม่ได้ตั้งใจ การรันคำสั่งอันตรายบนคอมพิวเตอร์ หรือการอนุมัติโค้ดที่มีความเสี่ยง

Agent Data Injection คืออะไร

Agent Data Injection เป็นแนวทางการโจมตี AI Agent ที่มุ่งเปลี่ยนแปลงข้อมูลซึ่งระบบใช้ประกอบการตัดสินใจ โดยไม่จำเป็นต้องเปลี่ยนคำสั่งหลักของผู้ใช้

โดยทั่วไป AI Agent ต้องประมวลผลข้อมูลสองประเภท ได้แก่

• คำสั่ง เช่น สิ่งที่ผู้ใช้ต้องการให้ Agent ทำ
• ข้อมูล เช่น อีเมล หน้าเว็บไซต์ ความคิดเห็นใน GitHub ผลลัพธ์จากเครื่องมือ หรือข้อมูลจากฐานข้อมูล

การโจมตีแบบ Prompt Injection ทั่วไปจะซ่อนคำสั่งไว้ในข้อมูล เช่น สั่งให้ Agent เพิกเฉยต่องานเดิมและส่งไฟล์ให้ผู้โจมตี แต่ ADI ใช้วิธีที่แตกต่างออกไป โดยปลอมรายละเอียดที่ Agent เชื่อว่าเป็นข้อมูลจริง

ตัวอย่างเช่น ผู้ใช้สั่งให้ AI สรุปรีวิวสินค้า แต่รีวิวที่ถูกแทรกไว้มีข้อมูลปลอมเกี่ยวกับหมายเลขปุ่ม เมื่อ Agent ต้องการคลิกปุ่ม “อ่านเพิ่มเติม” ระบบอาจคลิกปุ่ม “ซื้อทันที” แทน

ในกรณีของเครื่องมือช่วยเขียนโค้ด ผู้ใช้สามารถสั่งให้ Agent นำวิธีแก้ไขจากผู้ดูแลโครงการใน GitHub มาใช้งาน แต่ความคิดเห็นปลอมอาจทำให้ Agent เชื่อว่าคำสั่งของผู้โจมตีมาจากผู้ดูแลโครงการจริง

ช่องโหว่เกิดจากวิธีที่ AI Agent อ่านข้อมูล

ระบบทั่วไปใช้ตัวแยกข้อมูล เช่น เครื่องหมายคำพูด วงเล็บปีกกา แท็ก วงเล็บเหลี่ยม และบรรทัดใหม่ เพื่อบอกว่าข้อมูลแต่ละส่วนเริ่มต้นและสิ้นสุดตรงไหน

โปรแกรมแบบดั้งเดิมจะอ่านโครงสร้างเหล่านี้ตามกฎที่แน่นอน หากเครื่องหมายไม่ตรงตามรูปแบบ โปรแกรมมักมองว่าเป็นข้อความธรรมดา แต่โมเดลภาษาขนาดใหญ่ไม่ได้อ่านด้วยกฎตายตัวเสมอไป ระบบจะตีความโครงสร้างจากความน่าจะเป็นและบริบทของข้อความ

นักวิจัยเรียกเทคนิคที่ใช้ประโยชน์จากพฤติกรรมนี้ว่า Probabilistic Delimiter Injection

ผู้โจมตีสามารถใส่อักขระที่มีลักษณะคล้ายเครื่องหมายแบ่งข้อมูลลงในช่องที่ตนเองควบคุมได้ เช่น

• เครื่องหมายคำพูดที่มีการ Escape
• เครื่องหมายคำพูดแบบโค้ง
• วงเล็บหรือแท็กที่ดูคล้ายโครงสร้างจริง
• เครื่องหมายดอลลาร์
• การขึ้นบรรทัดใหม่ในตำแหน่งที่ทำให้เกิดความสับสน

แม้อักขระเหล่านี้จะไม่ใช่ตัวแบ่งข้อมูลที่ถูกต้องตามหลักของโปรแกรม แต่ AI อาจตีความว่าเป็นโครงสร้างใหม่ ทำให้มองเห็นข้อมูลที่ไม่มีอยู่จริง เช่น อีเมลอีกฉบับ ปุ่มอีกปุ่ม หรือผลลัพธ์จากเครื่องมืออีกชุดหนึ่ง

ตัวอย่างการโจมตี Agent Data Injection

ทีมวิจัยได้สร้างตัวอย่างการโจมตีบนเครื่องมือที่เปิดให้ใช้งานจริง โดยแบ่งออกเป็นหลายสถานการณ์สำคัญ

ปลอมหมายเลขปุ่มบนหน้าเว็บไซต์

ในระบบ Web Agent ผู้โจมตีสามารถแทรกรีวิวสินค้าที่มีข้อมูลอ้างอิงถึงหมายเลขปุ่มซึ่งตรงกับปุ่มจริงบนหน้าเว็บไซต์

เมื่อ Agent ต้องการคลิกปุ่ม “Read More” เพื่ออ่านรายละเอียดเพิ่มเติม ระบบอาจเลือกหมายเลของค์ประกอบที่ถูกปลอมไว้ และคลิกปุ่ม “Buy Now” แทน ทำให้เกิดการสั่งซื้อโดยที่ผู้ใช้ไม่ได้ตั้งใจ

เครื่องมือที่ถูกนำมาทดสอบประกอบด้วย Claude in Chrome, Google Antigravity และ Nanobrowser

ปัจจัยสำคัญคือ Web Agent บางระบบกำหนดหมายเลของค์ประกอบบนหน้าเว็บแบบเรียงลำดับ ผู้โจมตีจึงสามารถคำนวณหรือคาดเดาหมายเลขของปุ่มเป้าหมายได้ง่าย

ปลอมชื่อผู้เขียนความคิดเห็นใน GitHub

ในเครื่องมือช่วยเขียนโค้ด ผู้โจมตีสามารถสร้างความคิดเห็นที่ดูเหมือนมาจากผู้ดูแลโครงการ โดยปลอมส่วนที่แสดงชื่อผู้เขียนหรือโครงสร้างของข้อมูลความคิดเห็น

เมื่อผู้ใช้สั่งให้ Agent นำวิธีแก้ไขจากผู้ดูแลโครงการไปใช้ ระบบอาจเชื่อว่าคำสั่งของผู้โจมตีเป็นคำแนะนำจากผู้ดูแลจริง และเสนอให้รันคำสั่งดังกล่าวบนคอมพิวเตอร์ของนักพัฒนา

เครื่องมือที่ถูกนำมาทดสอบ ได้แก่

• Claude Code
• OpenAI Codex
• Google Gemini CLI

แม้ระบบจะขอให้ผู้ใช้กดยืนยันก่อนรันคำสั่ง แต่คำอธิบายที่แสดงอาจดูเป็นขั้นตอนปกติ เนื่องจากเหตุผลของ Agent ถูกสร้างขึ้นจากข้อมูลปลอมที่ระบบเชื่อว่าเป็นจริง

ปลอมผลลัพธ์ของการตรวจสอบโค้ด

อีกหนึ่งรูปแบบคือการสร้าง Pull Request ที่ปลอมบันทึกผลการตรวจสอบ ทำให้ Agent เชื่อว่าเคยรันเครื่องมือวิเคราะห์หรือทดสอบความปลอดภัยไปแล้ว

ผลลัพธ์ปลอมอาจระบุว่าโค้ดไม่มีปัญหา เมื่อ Agent ตรวจสอบประวัติการทำงาน ระบบจึงตัดสินว่าโค้ดปลอดภัยและแนะนำให้รวมโค้ดเข้าสู่โครงการ

หากผู้ใช้อนุมัติ Pull Request โค้ดอันตรายจริงอาจถูกนำเข้าสู่ระบบ แม้ขั้นตอนการตรวจสอบที่ Agent อ้างถึงจะไม่เคยเกิดขึ้น

ระบบขออนุมัติก่อนทำงานอาจยังไม่เพียงพอ

AI Agent หลายระบบมีขั้นตอนขออนุมัติจากผู้ใช้ก่อนดำเนินการที่มีความเสี่ยง เช่น คลิกปุ่มสั่งซื้อ รันคำสั่ง หรือรวมโค้ดเข้าสู่โครงการ

อย่างไรก็ตาม การขออนุมัติจะช่วยได้ก็ต่อเมื่อข้อมูลที่แสดงต่อผู้ใช้มีความถูกต้องและเพียงพอ

ในกรณีของ Web Agent หน้าต่างยืนยันอาจแจ้งเพียงว่า Agent ต้องการคลิกองค์ประกอบหนึ่งบนหน้าเว็บ แต่ไม่ได้อธิบายอย่างชัดเจนว่าปุ่มดังกล่าวคืออะไร มีข้อความว่าอย่างไร และเหตุใด Agent จึงต้องคลิก

ส่วนเครื่องมือช่วยเขียนโค้ดอาจแสดงเหตุผลอย่างเป็นขั้นตอน แต่ถ้าข้อมูลต้นทางถูกปลอม เหตุผลทั้งหมดก็ยังดูสมเหตุสมผลได้ แม้ข้อสรุปจะผิดตั้งแต่ต้น

จุดนี้ทำให้ผู้ใช้แยกแยะได้ยากว่าคำขออนุมัติมาจากขั้นตอนปกติ หรือเป็นผลจากข้อมูลที่ผู้โจมตีสร้างขึ้น

โมเดล AI หลายค่ายพบความเสี่ยงจาก ADI

งานวิจัยระบุว่าโมเดลจากหลายผู้พัฒนาแสดงพฤติกรรมที่สามารถถูกโจมตีด้วยวิธีดังกล่าวได้ โดยมีการทดสอบกับโมเดลจาก OpenAI, Anthropic และ Google

โมเดลที่ถูกระบุในงานวิจัยประกอบด้วย

• OpenAI GPT-5.2
• OpenAI GPT-5-mini
• Anthropic Claude Opus 4.5
• Anthropic Claude Sonnet 4.5
• Google Gemini 3 Pro
• Google Gemini 3 Flash

จากการทดสอบ การโจมตีข้อมูลแบบมีโครงสร้างประสบความสำเร็จประมาณ 31% ถึง 43% ขณะที่การโจมตีผ่านข้อมูลบนหน้าเว็บมีอัตราความสำเร็จตั้งแต่ประมาณหนึ่งในสามไปจนถึงเกือบทุกครั้งในบางรูปแบบการทดสอบ

เมื่อนำไปทดสอบกับระบบป้องกัน Prompt Injection ที่ออกแบบมาโดยเฉพาะ การโจมตีแบบซ่อนคำสั่งทั่วไปถูกป้องกันได้เกือบทั้งหมด แต่ ADI ยังสามารถทำงานสำเร็จได้สูงสุดประมาณ 50%

สาเหตุคือระบบป้องกันส่วนใหญ่มุ่งตรวจหาข้อความที่มีลักษณะเป็นคำสั่งอันตราย แต่ ADI ไม่จำเป็นต้องใช้คำสั่งตรง ๆ ผู้โจมตีเพียงเปลี่ยนข้อมูลที่ Agent ใช้ประกอบการตัดสินใจ

วิธีป้องกัน Agent Data Injection

งานวิจัยได้ทดลองแนวทางป้องกันหลายรูปแบบ โดยแต่ละวิธีมีข้อดีและข้อจำกัดแตกต่างกัน

ใช้รหัสองค์ประกอบแบบสุ่ม

ChatGPT Atlas Browser สามารถป้องกันตัวอย่างการโจมตีด้วยการคลิกได้ เนื่องจากระบบกำหนดรหัสแบบสุ่มให้กับองค์ประกอบแต่ละรายการบนหน้าเว็บ แทนการใช้หมายเลขเรียงลำดับ

เมื่อรหัสไม่สามารถคาดเดาได้ ผู้โจมตีจะปลอมหมายเลขให้ตรงกับปุ่มเป้าหมายได้ยากขึ้น

นักวิจัยยังทดลองเพิ่มรหัสสุ่มขนาดสั้นไว้กับชื่อฟิลด์ ซึ่งช่วยลดอัตราความสำเร็จของการโจมตีจากประมาณ 49% เหลือประมาณ 29% โดยยังคงรักษาความสามารถของ Agent ในการทำงานทั่วไปได้

ติดตามแหล่งที่มาของข้อมูล

แนวทางที่มีประสิทธิภาพสูงคือการติดตามว่าแต่ละข้อมูลมาจากแหล่งใด ใครเป็นผู้ควบคุม และระบบสามารถเชื่อถือข้อมูลนั้นได้ในระดับใด

วิธีนี้สามารถป้องกันการโจมตีในชุดทดสอบได้ทั้งหมด แต่มีผลกระทบต่อความสามารถในการทำงานของ Agent อย่างมาก โดยระบบทำงานทั่วไปสำเร็จเพียงประมาณหนึ่งในสามของงานทั้งหมด

ปัญหาคือการติดตามแหล่งที่มาอย่างเข้มงวดอาจทำให้ Agent ปฏิเสธข้อมูลที่จำเป็น หรือไม่สามารถเชื่อมโยงข้อมูลจากหลายแหล่งเพื่อทำงานที่ซับซ้อนได้

ลบเครื่องหมายที่ใช้แบ่งข้อมูล

การลบหรือกรองเครื่องหมายวรรคตอนบางประเภทสามารถลดโอกาสที่ AI จะตีความข้อมูลปลอมเป็นโครงสร้างจริง

อย่างไรก็ตาม วิธีนี้อาจทำลายข้อมูลที่จำเป็น เช่น

• ลิงก์เว็บไซต์
• พาธของไฟล์
• โค้ดโปรแกรม
• JSON หรือ XML
• ข้อความที่ต้องใช้เครื่องหมายคำพูด
• คำสั่งในระบบปฏิบัติการ

จึงเป็นแนวทางที่ลดความเสี่ยงได้ แต่ไม่เหมาะกับ Agent ที่ต้องประมวลผลข้อมูลทางเทคนิคจำนวนมาก

แสดงรายละเอียดก่อนขออนุมัติ

ระบบควรแสดงข้อมูลที่ผู้ใช้สามารถตรวจสอบได้ก่อนอนุมัติ เช่น

• ชื่อและข้อความของปุ่มที่จะคลิก
• URL ปลายทาง
• คำสั่งเต็มที่จะถูกรัน
• ผู้เขียนความคิดเห็นจากข้อมูลที่ผ่านการยืนยัน
• ไฟล์ที่จะถูกแก้ไข
• ผลกระทบจากการรวมโค้ด
• แหล่งที่มาของข้อมูลที่ Agent ใช้อ้างอิง

การแจ้งเพียงว่า Agent ต้องการดำเนินการบางอย่างอาจไม่เพียงพอ เพราะผู้ใช้ยังไม่สามารถตัดสินได้ว่าระบบกำลังทำสิ่งที่ถูกต้องหรือไม่

เงื่อนไขที่ทำให้การโจมตีเกิดขึ้นได้

Agent Data Injection ต้องอาศัยองค์ประกอบหลายอย่างร่วมกัน

• Agent ต้องประมวลผลข้อมูลที่บุคคลภายนอกแก้ไขได้
• ผู้โจมตีต้องทราบหรือค้นหารูปแบบที่ระบบใช้จัดโครงสร้างข้อมูล
• Agent ต้องนำข้อมูลดังกล่าวไปใช้ตัดสินใจหรือเลือกเครื่องมือ
• ระบบตรวจสอบต้องไม่แยกข้อมูลที่เชื่อถือได้ออกจากข้อมูลที่ผู้ใช้ภายนอกควบคุม
• ขั้นตอนอนุมัติต้องแสดงรายละเอียดไม่เพียงพอต่อการตรวจสอบ

เว็บไซต์ อีเมล GitHub Issue Pull Request รีวิวสินค้า และข้อความจากระบบภายนอกจึงเป็นพื้นที่เสี่ยง เพราะข้อมูลเหล่านี้สามารถถูกสร้างหรือแก้ไขโดยบุคคลที่ระบบไม่ควรเชื่อถือโดยอัตโนมัติ

ผู้โจมตีรู้รูปแบบข้อมูลของ Agent ได้อย่างไร

สำหรับเครื่องมือโอเพนซอร์สหรือระบบที่ติดตั้งบนเครื่อง ผู้โจมตีสามารถศึกษารูปแบบข้อมูลได้จากซอร์สโค้ด การตรวจสอบไฟล์ หรือการวิเคราะห์พฤติกรรมของระบบ

ระบบคลาวด์จะตรวจสอบได้ยากกว่า เนื่องจากรูปแบบข้อมูลภายในไม่ได้เปิดเผยต่อผู้ใช้ แต่ทีมวิจัยระบุว่าสามารถใช้การสนทนาหลายขั้นตอนเพื่อทำให้โมเดลเปิดเผยรูปแบบบางส่วนได้

อีกประเด็นที่ต้องระวังคือ โมเดลขนาดใหญ่และขนาดเล็กของบริษัทเดียวกันอาจใช้รูปแบบข้อมูลร่วมกัน ผู้โจมตีจึงอาจศึกษารูปแบบจากโมเดลขนาดเล็กที่ทดสอบได้ง่ายกว่า แล้วนำข้อมูลไปใช้กับโมเดลขนาดใหญ่

ความเชื่อมโยงกับ EchoLeak และการโจมตีผ่าน GitHub

ปัญหาความน่าเชื่อถือของข้อมูลใน AI Agent เคยปรากฏให้เห็นผ่านช่องโหว่อื่นมาก่อน

ในเดือนมิถุนายน 2025 มีการเปิดเผย EchoLeak หรือ CVE-2025-32711 ซึ่งเกี่ยวข้องกับ Microsoft 365 Copilot ผู้โจมตีสามารถสร้างอีเมลที่ทำให้ระบบเปิดเผยข้อมูลภายในได้โดยไม่ต้องให้ผู้ใช้คลิกลิงก์

EchoLeak ใช้วิธีซ่อนคำสั่งไว้ในข้อมูล ขณะที่ Agent Data Injection เปลี่ยนไปปลอมข้อเท็จจริงที่ระบบเชื่อถือ เช่น ใครเป็นผู้ส่ง ข้อมูลมาจากแหล่งใด หรือเครื่องมือเคยทำอะไรไปแล้ว

นอกจากนี้ ยังเคยมีการสาธิตว่าข้อความใน GitHub Issue และ Pull Request สามารถชักนำ Coding Agent ให้เข้าถึงข้อมูลจาก Repository ส่วนตัว หรือเปิดเผยข้อมูลสำคัญได้

ความแตกต่างสำคัญคือการโจมตีเดิมพยายามสั่ง Agent โดยตรง แต่ ADI ทำให้ Agent เข้าใจสถานการณ์ผิด แล้วปล่อยให้ระบบดำเนินงานเดิมต่อไปเอง

นักพัฒนา AI Agent ควรเตรียมรับมืออย่างไร

การป้องกัน ADI ไม่ควรพึ่งการกรอง Prompt Injection เพียงอย่างเดียว แต่ต้องออกแบบระบบให้แยกข้อมูลตามระดับความน่าเชื่อถืออย่างชัดเจน

แนวทางที่ควรนำไปพิจารณา ได้แก่

• แยก Metadata ที่ระบบสร้างออกจากข้อความที่ผู้ใช้ควบคุม
• ใช้รหัสแบบสุ่มสำหรับองค์ประกอบสำคัญ
• ตรวจสอบตัวตนของผู้ส่งและผู้เขียนจากระบบต้นทาง
• ไม่ใช้ข้อความที่แสดงบนหน้าจอเป็นหลักฐานยืนยันตัวตนเพียงอย่างเดียว
• บันทึกผลการทำงานของเครื่องมือในพื้นที่ที่ข้อมูลภายนอกแก้ไขไม่ได้
• แสดงคำสั่งและผลกระทบทั้งหมดก่อนให้ผู้ใช้อนุมัติ
• กำหนดสิทธิ์ของ Agent ตามหลัก Least Privilege
• แยกขั้นตอนอ่านข้อมูลออกจากขั้นตอนดำเนินการ
• ตรวจสอบข้อมูลซ้ำด้วยโปรแกรมที่ใช้กฎแบบตายตัว
• ทดสอบ Agent ด้วยข้อมูลที่มีโครงสร้างผิดปกติและอักขระหลอก

แนวคิดสำคัญคือ ระบบต้องไม่ถือว่าข้อมูลทุกส่วนที่อยู่ในบริบทเดียวกันมีความน่าเชื่อถือเท่ากัน ชื่อผู้ส่งที่ระบบยืนยันแล้วควรถูกแยกออกจากเนื้อหาอีเมล และผลลัพธ์จากเครื่องมือจริงควรถูกแยกออกจากข้อความที่ Repository ภายนอกสามารถแก้ไขได้

สรุป Agent Data Injection สะท้อนปัญหาความน่าเชื่อถือของข้อมูลใน AI Agent

Agent Data Injection แสดงให้เห็นว่าอันตรายต่อ AI Agent ไม่ได้เกิดจากคำสั่งที่พยายามเปลี่ยนเป้าหมายของระบบเท่านั้น แต่ยังเกิดจากข้อมูลปลอมที่ทำให้ Agent เข้าใจสถานการณ์ผิดได้ด้วย

Agent อาจยังคงทำงานตามคำขอของผู้ใช้ทุกขั้นตอน แต่เลือกปุ่มผิด เชื่อผู้ส่งผิด รันคำสั่งผิด หรืออนุมัติโค้ดผิด เพราะข้อมูลพื้นฐานที่ใช้ตัดสินใจถูกผู้โจมตีแทรกแซง

ระบบป้องกัน Prompt Injection แบบเดิมจึงอาจไม่เพียงพอสำหรับ Agent ที่สามารถดำเนินการจริง นักพัฒนาต้องแยกข้อมูลที่ระบบรับรองออกจากข้อมูลภายนอก ติดตามแหล่งที่มา ใช้รหัสที่คาดเดาไม่ได้ และแสดงรายละเอียดที่ตรวจสอบได้ก่อนขออนุมัติ

เมื่อ AI Agent ได้รับสิทธิ์เข้าถึงเบราว์เซอร์ คอมพิวเตอร์ Repository และข้อมูลภายในองค์กรมากขึ้น การออกแบบขอบเขตความน่าเชื่อถือของข้อมูลจะกลายเป็นส่วนสำคัญของระบบรักษาความปลอดภัย ไม่ต่างจากการแยกโค้ดออกจากข้อมูลในซอฟต์แวร์แบบดั้งเดิม

ที่มา thehackernews

SiamGeek

The post Agent Data Injection ภัยโจมตี AI Agent รูปแบบใหม่ที่ปลอมข้อมูลให้ระบบตัดสินใจผิด appeared first on SiamByte.

อย่างไรก็ตาม โค้ดหลายส่วนของ TuxBot v3 Evolution ยังทำงานไม่สมบูรณ์ และภายในไฟล์ยังพบข้อความคำเตือนด้านความปลอดภัย รวมถึงกระบวนการวิเคราะห์ของ AI ที่ผู้พัฒนาไม่ได้ลบออกก่อนนำโค้ดไปใช้งาน

แม้ตัวอย่างที่นักวิจัยตรวจสอบจะยังมีข้อผิดพลาด แต่โครงสร้างโดยรวมแสดงให้เห็นว่า AI อาจช่วยให้ผู้โจมตีรายเดียวสามารถสร้างระบบบอตเน็ตขนาดใหญ่ที่มีองค์ประกอบซับซ้อนได้รวดเร็วยิ่งขึ้น

TuxBot v3 Evolution คืออะไร

TuxBot v3 Evolution เป็นเฟรมเวิร์กบอตเน็ตแบบแยกส่วนที่ออกแบบมาเพื่อควบคุมอุปกรณ์ IoT ที่ถูกเจาะระบบ เช่น เราเตอร์ กล้องวงจรปิด อุปกรณ์เครือข่าย เซิร์ฟเวอร์ Linux และอุปกรณ์ที่เปิดบริการ Telnet หรือบริการจัดการระยะไกลโดยไม่มีการป้องกันที่เพียงพอ

เมื่ออุปกรณ์ติดมัลแวร์แล้ว ผู้ควบคุมสามารถสั่งให้อุปกรณ์เหล่านั้นเข้าร่วมการโจมตีแบบ Distributed Denial-of-Service หรือ DDoS สแกนหาเป้าหมายเพิ่มเติม เปิดพร็อกซี หรือเรียกใช้โมดูลอื่นภายในระบบได้

นักวิจัยจาก Palo Alto Networks Unit 42 ระบุว่า TuxBot v3 Evolution ถูกสร้างขึ้นให้มีลักษณะคล้ายแพลตฟอร์มควบคุมบอตเน็ตระดับมืออาชีพ รองรับผู้ใช้งานหลายคน มีแผงควบคุมสำหรับผู้ดูแล ระบบติดตั้งอัตโนมัติ และโมดูลโจมตีที่สามารถเพิ่มเติมหรือแก้ไขได้

พบหลักฐานการใช้ AI ช่วยเขียนโค้ดมัลแวร์

หนึ่งในประเด็นสำคัญของ TuxBot v3 Evolution คือการพบข้อความที่เกี่ยวข้องกับโมเดลภาษาขนาดใหญ่ภายในซอร์สโค้ด

นักวิจัยพบว่าไฟล์หลายรายการมีความคิดเห็นในโค้ดที่บันทึกกระบวนการคิด การตัดสินใจ และขั้นตอนการย้ายฟังก์ชันจากภาษาหนึ่งไปยังอีกภาษาหนึ่ง ซึ่งมีลักษณะเหมือนผลลัพธ์ที่สร้างโดย AI

ข้อความบางส่วนมีการกล่าวถึง “ผู้ใช้” ซึ่งในบริบทนี้หมายถึงผู้พัฒนาที่ส่งคำสั่งให้ AI ช่วยเขียนหรือปรับปรุงโค้ด นอกจากนี้ยังพบคำเตือนด้านความปลอดภัยที่ AI ใส่มาพร้อมคำตอบ แต่ผู้พัฒนาไม่ได้ตรวจสอบและลบออกก่อนนำไฟล์ไปใช้งาน

แม้ AI จะช่วยสร้างโครงสร้างของบอตเน็ตได้หลายส่วน แต่ฟังก์ชันบางรายการกลับทำงานผิดพลาด ซึ่งแสดงให้เห็นว่าผู้พัฒนาอาจนำโค้ดที่สร้างขึ้นไปใช้งานโดยไม่ได้ตรวจสอบอย่างละเอียด

องค์ประกอบหลักของ TuxBot v3 Evolution

TuxBot v3 Evolution ไม่ได้เป็นเพียงมัลแวร์ไฟล์เดียว แต่ประกอบด้วยระบบย่อยหลายส่วนที่ทำงานร่วมกัน ได้แก่

• โปรแกรม Bot Agent ที่เขียนด้วยภาษา C
• เซิร์ฟเวอร์ Command-and-Control หรือ C2 ที่เขียนด้วยภาษา Go
• แผงควบคุมสำหรับให้บริการโจมตี DDoS
• ระบบ Exploit Virtual Machine สำหรับจัดการโค้ดเจาะช่องโหว่
• ระบบทดสอบที่ทำงานผ่าน Docker
• ระบบคอมไพล์และสร้างไฟล์มัลแวร์แบบอัตโนมัติ
• เครื่องมือสแกนอุปกรณ์และบริการบนเครือข่าย
• ระบบสื่อสารสำรองหลายรูปแบบ
• โมดูลพร็อกซี SOCKS5
• โมดูลสำหรับหยุดโปรเซสของมัลแวร์คู่แข่ง

โครงสร้างดังกล่าวช่วยให้ผู้พัฒนาสามารถเพิ่มช่องโหว่ วิธีการโจมตี หรือช่องทางติดต่อกับเซิร์ฟเวอร์ควบคุมได้โดยไม่ต้องสร้างระบบใหม่ทั้งหมด

รองรับอุปกรณ์หลายสถาปัตยกรรม

Bot Agent ของ TuxBot v3 Evolution ถูกออกแบบให้สามารถคอมไพล์ข้ามแพลตฟอร์ม เพื่อรองรับอุปกรณ์ IoT และเซิร์ฟเวอร์ที่ใช้หน่วยประมวลผลหลายสถาปัตยกรรม

สถาปัตยกรรมที่พบว่ารองรับประกอบด้วย

• ARM
• MIPS
• MIPSEL
• MIPS64
• x86_64
• PowerPC
• RISC-V

ความสามารถในการรองรับหลายสถาปัตยกรรมช่วยเพิ่มโอกาสที่มัลแวร์จะสามารถทำงานบนเราเตอร์ กล้อง IP กล่อง Android และอุปกรณ์ IoT จากผู้ผลิตหลายรายได้

ใช้รหัสผ่านเกือบ 1,500 ชุดเพื่อโจมตี Telnet

TuxBot v3 Evolution มีโมดูลสำหรับโจมตีบริการ Telnet ด้วยวิธี Brute Force โดยใช้ชุดชื่อผู้ใช้และรหัสผ่านจำนวน 1,496 คู่

รหัสผ่านเหล่านี้จะถูกใช้ทดสอบกับอุปกรณ์ที่เปิด Telnet ไว้บนอินเทอร์เน็ต โดยเฉพาะอุปกรณ์ที่ยังใช้รหัสผ่านเริ่มต้นจากโรงงาน หรือใช้รหัสผ่านที่คาดเดาได้ง่าย

หากเข้าสู่ระบบสำเร็จ มัลแวร์จะพยายามดาวน์โหลดและติดตั้ง Bot Agent ลงในอุปกรณ์ ก่อนเชื่อมต่อกลับไปยังเซิร์ฟเวอร์ C2 เพื่อรอรับคำสั่งจากผู้ควบคุม

มีโค้ดโจมตีอุปกรณ์ IoT มากกว่า 30 กลุ่ม

นอกเหนือจากการเดารหัสผ่าน Telnet แล้ว เฟรมเวิร์กนี้ยังรวมโค้ดที่วางแผนใช้โจมตีช่องโหว่ที่เป็นที่รู้จักในอุปกรณ์ IoT มากกว่า 30 กลุ่ม

เป้าหมายหลักคืออุปกรณ์ที่ไม่ได้อัปเดตเฟิร์มแวร์ หรือยังเปิดหน้าเว็บจัดการที่มีช่องโหว่อยู่บนอินเทอร์เน็ต

อย่างไรก็ตาม นักวิจัยพบว่าโมดูลเจาะช่องโหว่บางส่วนยังทำงานไม่สมบูรณ์ และระบบ Exploit Virtual Machine ในตัวอย่างที่ตรวจสอบยังไม่สามารถทำงานได้ตามที่ผู้พัฒนาออกแบบไว้ทั้งหมด

ช่องทางสื่อสารกับเซิร์ฟเวอร์ C2

TuxBot v3 Evolution ใช้ช่องทางสื่อสารหลักผ่าน TCP ที่เข้ารหัส และยังมีช่องทางสำรองหลายรูปแบบเพื่อช่วยให้บอตยังติดต่อกับผู้ควบคุมได้ แม้ช่องทางหลักจะถูกบล็อก

ช่องทางที่พบประกอบด้วย

• การเชื่อมต่อ TCP แบบเข้ารหัส
• Domain Generation Algorithm หรือ DGA ที่ใช้ SHA-512
• ระบบ Peer-to-Peer หรือ P2P
• คำสั่งที่ลงลายมือชื่อด้วย Ed25519
• Internet Relay Chat หรือ IRC
• DNS TXT Query
• HTTP Polling

การมีช่องทางสำรองหลายระดับทำให้การตัดการเชื่อมต่อระหว่างบอตกับผู้ควบคุมทำได้ยากกว่าบอตเน็ตทั่วไปที่พึ่งพาเซิร์ฟเวอร์หรือโดเมนเพียงแห่งเดียว

พอร์ตที่เซิร์ฟเวอร์ TuxBot ใช้งาน

เซิร์ฟเวอร์ C2 ที่เขียนด้วยภาษา Go ใช้พอร์ต TCP หลักสามพอร์ตสำหรับงานที่แตกต่างกัน

TCP Port 1999 หรือ 31337

ใช้สำหรับรับการเชื่อมต่อจากอุปกรณ์ที่ติดมัลแวร์ และส่งคำสั่งแบบเข้ารหัสไปยังบอตที่กำลังออนไลน์

TCP Port 2222

ใช้เปิด Interactive Shell ผ่านโปรโตคอล SSH เพื่อให้ผู้ควบคุมสามารถเข้าสู่ระบบและจัดการเซิร์ฟเวอร์ได้

TCP Port 9999

ใช้เป็นอินเทอร์เฟซแบบ JSON สำหรับเชื่อมต่อกับโปรแกรมหรือระบบจัดการอื่นผ่าน API

ผู้ดูแลระบบสามารถนำข้อมูลพอร์ตเหล่านี้ไปใช้ประกอบการตรวจสอบบันทึกเครือข่ายได้ แต่ไม่ควรใช้เพียงหมายเลขพอร์ตเป็นตัวบ่งชี้การโจมตีเพียงอย่างเดียว เนื่องจากผู้โจมตีสามารถเปลี่ยนค่าได้

ขั้นตอนการทำงานหลังติดอุปกรณ์

เมื่อ TuxBot เริ่มทำงานบนอุปกรณ์ที่ถูกเจาะระบบ มัลแวร์จะดำเนินการตามลำดับที่กำหนดไว้ล่วงหน้า

ขั้นตอนสำคัญประกอบด้วย

1. โหลดที่อยู่เซิร์ฟเวอร์ C2 จากระบบหลายระดับ
2. ตรวจสอบว่ากำลังทำงานอยู่ในสภาพแวดล้อมวิเคราะห์หรือเครื่องเสมือนหรือไม่
3. ตรวจหาเครื่องมือดีบักและโปรแกรมวิเคราะห์มัลแวร์
4. เปลี่ยนหรือซ่อนชื่อโปรเซส
5. ติดตั้งกลไก Persistence
6. เชื่อมต่อกับเซิร์ฟเวอร์ C2
7. เริ่มโมดูลสแกน Telnet, SSH, HTTP และ ADB
8. ปิดโปรเซสที่เกี่ยวข้องกับมัลแวร์คู่แข่ง
9. เปิดช่องทาง IRC, HTTP, DNS และ P2P สำรอง
10. เริ่ม SOCKS5 Proxy
11. เตรียมโมดูลสำหรับโจมตี DDoS
12. เรียกใช้ส่วนที่เกี่ยวข้องกับการขุดคริปโทเคอร์เรนซี ซึ่งยังอยู่ในลักษณะ Placeholder

ระบบสแกน HTTP รองรับ 128 การเชื่อมต่อพร้อมกัน

โมดูล HTTP Scanner ของ TuxBot สามารถจัดการการเชื่อมต่อพร้อมกันได้สูงสุด 128 รายการ

หน้าที่หลักคือสแกนหาเว็บอินเทอร์เฟซของเราเตอร์ กล้องวงจรปิด และอุปกรณ์ IoT ที่เปิดให้เข้าถึงจากอินเทอร์เน็ต จากนั้นตรวจสอบว่าเป้าหมายมีช่องโหว่หรือใช้การตั้งค่าที่ไม่ปลอดภัยหรือไม่

การสแกนแบบพร้อมกันจำนวนมากช่วยให้บอตเน็ตสามารถค้นหาอุปกรณ์เป้าหมายใหม่ได้อย่างรวดเร็ว และขยายจำนวนเครื่องในเครือข่ายได้โดยอัตโนมัติ

วิธีสร้าง Persistence บนระบบ Linux

เพื่อให้มัลแวร์ยังคงทำงานหลังรีสตาร์ตเครื่อง TuxBot ใช้วิธีติดตั้งตัวเองหลายรูปแบบ

• สร้าง Systemd Service
• เพิ่มคำสั่งลงใน Cron
• เรียกใช้ Watchdog Process
• ตรวจสอบและเปิดโปรเซสใหม่เมื่อมัลแวร์หยุดทำงาน

การใช้หลายกลไกพร้อมกันทำให้การลบมัลแวร์ออกจากระบบทำได้ยากขึ้น หากผู้ดูแลระบบลบเพียงไฟล์หลัก แต่ไม่ได้ตรวจสอบ Service, Cron Job และโปรเซสเฝ้าระวังทั้งหมด

มีต้นแบบจาก Mirai และเครื่องมือ DDoS อื่น

นักวิจัยพบว่าส่วนประกอบของ TuxBot v3 Evolution มีความเชื่อมโยงกับบอตเน็ตและเครื่องมือโจมตีหลายโครงการ

โค้ดบางส่วนมีต้นแบบหรือแนวทางจาก

• Mirai
• AISURU
• Wuhan
• MHDDoS
• Kaitori v3.9

บางฟังก์ชันถูกย้ายมาจาก MHDDoS ซึ่งเป็นเครื่องมือ DDoS แบบโอเพนซอร์สที่พัฒนาด้วยภาษา Python ก่อนถูกนำมาปรับเป็นส่วนหนึ่งของเฟรมเวิร์กใหม่

นักวิจัยยังพบโครงสร้างพื้นฐานที่ใช้ร่วมกับ Kaitori v3.9 และเครื่องมือของ AISURU ซึ่งเชื่อมโยงผู้ควบคุม TuxBot เข้ากับกลุ่มหรือระบบนิเวศ Keksec ที่มีประวัติดำเนินบอตเน็ต IoT หลายสายพันธุ์พร้อมกัน

พบตัวอย่างบน VirusTotal ตั้งแต่เดือนมกราคม 2026

มีการอัปโหลดตัวอย่างมัลแวร์อย่างน้อยหนึ่งรายการไปยังแพลตฟอร์ม VirusTotal เมื่อวันที่ 20 มกราคม 2026 แสดงให้เห็นว่า TuxBot v3 Evolution ถูกพัฒนาและเผยแพร่มาระยะหนึ่งแล้วก่อนที่รายละเอียดจะถูกเปิดเผยต่อสาธารณะ

หลักฐานเพิ่มเติมระบุว่าผู้พัฒนาเริ่มดำเนินงานเกี่ยวกับโครงการนี้ก่อนหน้านั้นประมาณหนึ่งปี โดยเริ่มจากการคัดลอกคลังโค้ด MHDDoS บน GitHub แล้วนำมาปรับปรุงต่อ

นักวิจัยระบุว่าอาจมี TuxBot เวอร์ชันที่ได้รับการแก้ไขและทำงานได้สมบูรณ์กว่าตัวอย่างที่ตรวจพบ เนื่องจากข้อผิดพลาดหลายจุดสามารถแก้ไขได้ด้วยการตรวจสอบโค้ดแบบพื้นฐาน

ความเสี่ยงจากการใช้ AI พัฒนามัลแวร์

กรณีของ TuxBot v3 Evolution แสดงให้เห็นว่า AI สามารถช่วยลดเวลาในการสร้างเครื่องมือโจมตีที่มีองค์ประกอบจำนวนมากได้ แม้ผู้พัฒนาจะไม่ได้มีทีมขนาดใหญ่

ความเสี่ยงสำคัญไม่ได้อยู่ที่ AI สามารถสร้างมัลแวร์ที่สมบูรณ์ได้ทันที แต่เป็นการช่วยให้ผู้โจมตีสามารถ

• เขียนโค้ดได้รวดเร็วขึ้น
• ย้ายฟังก์ชันระหว่างภาษาโปรแกรม
• สร้างระบบควบคุมและ API
• เพิ่มโมดูลสแกนเครือข่าย
• สร้างระบบคอมไพล์หลายสถาปัตยกรรม
• ออกแบบแผงควบคุมสำหรับผู้ใช้งานหลายคน
• นำโค้ดจากโครงการเดิมมาประกอบเป็นเครื่องมือใหม่

ในขณะเดียวกัน ข้อผิดพลาดและข้อความจาก AI ที่หลงเหลืออยู่ในไฟล์ก็แสดงให้เห็นว่าการพึ่งพาโค้ดที่สร้างโดย AI โดยไม่มีการตรวจสอบ สามารถสร้างปัญหาด้านเสถียรภาพและความปลอดภัยให้กับผู้พัฒนาเองได้เช่นกัน

วิธีป้องกันอุปกรณ์ IoT จาก TuxBot และบอตเน็ตประเภทเดียวกัน

องค์กรและผู้ใช้งานควรตรวจสอบอุปกรณ์ IoT ที่เชื่อมต่ออินเทอร์เน็ตอย่างสม่ำเสมอ โดยเฉพาะอุปกรณ์ที่ไม่ได้รับการอัปเดตเป็นเวลานาน

แนวทางป้องกันที่ควรดำเนินการ ได้แก่

• เปลี่ยนชื่อผู้ใช้และรหัสผ่านเริ่มต้นทันที
• หลีกเลี่ยงการใช้รหัสผ่านซ้ำกับระบบอื่น
• ปิด Telnet และใช้ SSH เมื่อจำเป็น
• จำกัดการเข้าถึง SSH ด้วย Firewall หรือ VPN
• ปิด ADB บนอุปกรณ์ Android ที่ไม่จำเป็นต้องใช้งาน
• ไม่เปิดหน้าเว็บจัดการอุปกรณ์ให้เข้าถึงจากอินเทอร์เน็ตโดยตรง
• อัปเดตเฟิร์มแวร์จากผู้ผลิตอย่างสม่ำเสมอ
• แยกเครือข่าย IoT ออกจากระบบงานสำคัญ
• ตรวจสอบ DNS TXT Query และการเชื่อมต่อ IRC ที่ผิดปกติ
• ตรวจสอบ Systemd Service และ Cron Job ที่ไม่รู้จัก
• เฝ้าระวังการสแกนพอร์ตจำนวนมากจากอุปกรณ์ภายใน
• ตรวจสอบการใช้งาน CPU และแบนด์วิดท์ที่เพิ่มขึ้นผิดปกติ
• ลบหรือเปลี่ยนอุปกรณ์ที่สิ้นสุดระยะเวลาการสนับสนุนแล้ว

บอตเน็ต IoT ยังเป็นภัยคุกคามที่ต้องเฝ้าระวัง

การเปิดเผย TuxBot v3 Evolution เกิดขึ้นในช่วงเดียวกับที่มีการตรวจพบบอตเน็ตอื่น เช่น RustDuck และ AryStinger ซึ่งมุ่งโจมตีเราเตอร์ กล้อง IP กล่อง Android และเซิร์ฟเวอร์ที่มีการรักษาความปลอดภัยไม่เพียงพอ

อุปกรณ์ที่ถูกยึดครองสามารถถูกนำไปใช้โจมตีบริการออนไลน์ ทำให้เว็บไซต์หรือระบบไม่สามารถให้บริการได้ รวมถึงใช้เป็นจุดเริ่มต้นในการสำรวจเครือข่ายของเป้าหมายเพิ่มเติม

แม้ TuxBot v3 Evolution ในตัวอย่างที่ตรวจสอบจะยังอยู่ระหว่างการพัฒนา แต่ฟังก์ชันหลักหลายส่วนสามารถทำงานได้แล้ว ประกอบกับการใช้ AI ช่วยสร้างโค้ด ทำให้ผู้โจมตีสามารถเพิ่มความสามารถและสร้างบอตเน็ตที่ซับซ้อนได้รวดเร็วกว่าเดิม

สรุป

TuxBot v3 Evolution เป็นบอตเน็ต IoT แบบแยกส่วนที่รวมความสามารถด้านการเดารหัสผ่าน การโจมตีช่องโหว่ การสแกนเครือข่าย การโจมตี DDoS การเปิดพร็อกซี และการสื่อสารกับเซิร์ฟเวอร์ควบคุมผ่านหลายช่องทางไว้ในระบบเดียว

หลักฐานภายในซอร์สโค้ดแสดงให้เห็นว่าผู้พัฒนาใช้ AI ช่วยเขียนและปรับย้ายโค้ดหลายส่วน แม้ผลลัพธ์บางรายการจะยังมีข้อผิดพลาดและมีข้อความจาก AI หลงเหลืออยู่ก็ตาม

เหตุการณ์นี้สะท้อนให้เห็นว่าภัยคุกคามจากบอตเน็ต IoT กำลังพัฒนาไปสู่ระบบที่มีความซับซ้อนและสร้างได้รวดเร็วขึ้น องค์กรจึงควรเร่งตรวจสอบอุปกรณ์ IoT ปิดบริการที่ไม่จำเป็น อัปเดตเฟิร์มแวร์ และจำกัดการเข้าถึงอุปกรณ์จากอินเทอร์เน็ต เพื่อลดโอกาสถูกนำไปใช้เป็นส่วนหนึ่งของเครือข่ายบอตเน็ต

ที่มา thehackernews

SiamGeek

The post พบ TuxBot v3 Evolution บอตเน็ต IoT ที่ใช้ AI ช่วยพัฒนา พร้อมระบบโจมตี DDoS หลายรูปแบบ appeared first on SiamByte.

Sophos เปิดเผยผลการวิเคราะห์ข้อมูลจากระบบ Endpoint Protection ของบริษัท โดยพบว่า AI Coding Agent หลายรายกำลังเรียกใช้คำสั่งและเข้าถึงข้อมูลในลักษณะที่คล้ายกับพฤติกรรมของผู้โจมตี ส่งผลให้ระบบตรวจจับภัยคุกคามแจ้งเตือนหรือบล็อกการทำงาน แม้ตัว AI จะไม่ได้มีเจตนาร้ายก็ตาม

พฤติกรรมที่ถูกตรวจจับมีตั้งแต่การถอดรหัสข้อมูลรับรองในเบราว์เซอร์ การตรวจสอบข้อมูลใน Windows Credential Manager การดาวน์โหลดไฟล์ผ่านเครื่องมือของระบบ ไปจนถึงการสร้างสคริปต์ในโฟลเดอร์ Startup เพื่อให้ทำงานอัตโนมัติเมื่อเปิดเครื่อง

AI Coding Agent ทำอะไรจนถูกมองว่าเป็นการโจมตี

Sophos วิเคราะห์ข้อมูลจากระบบตรวจจับพฤติกรรมบน Windows เป็นระยะเวลา 7 วันในเดือนมิถุนายน 2026 โดยนับจากจำนวนเครื่องที่พบพฤติกรรม ไม่ได้นับจากจำนวนเหตุการณ์ทั้งหมด

ผลการวิเคราะห์พบว่ากิจกรรมที่ถูกบล็อกแบ่งออกเป็นกลุ่มสำคัญ ได้แก่

• การเข้าถึงข้อมูลรับรองคิดเป็น 56.2 เปอร์เซ็นต์
• การสั่งรันคำสั่งหรือโปรแกรมคิดเป็น 28.8 เปอร์เซ็นต์
• การดาวน์โหลดไฟล์ผ่านเครื่องมือของ Windows
• การสร้างกลไกให้โปรแกรมทำงานอัตโนมัติหลังเปิดเครื่อง
• การลองใช้วิธีอื่นทันทีเมื่อวิธีแรกถูกระบบรักษาความปลอดภัยบล็อก

Sophos ระบุว่าข้อมูลดังกล่าวเป็นเพียงภาพจากระบบของบริษัทในช่วงเวลาจำกัด จึงไม่ควรถูกมองว่าเป็นตัวแทนของอุตสาหกรรมทั้งหมด แต่สะท้อนให้เห็นแนวโน้มที่ฝ่ายรักษาความปลอดภัยต้องเตรียมรับมือ

การเข้าถึงข้อมูลในเบราว์เซอร์ทำให้ระบบแจ้งเตือน

หนึ่งในกฎตรวจจับที่ทำงานบ่อยที่สุดเกี่ยวข้องกับการใช้ Windows Data Protection API หรือ DPAPI เพื่อถอดรหัสข้อมูลที่ถูกจัดเก็บไว้ในเบราว์เซอร์

กฎนี้คิดเป็น 42.6 เปอร์เซ็นต์ของกลุ่มพฤติกรรมเข้าถึงข้อมูลรับรอง โดยปกติแล้ว DPAPI ถูกใช้เพื่อปกป้องข้อมูลสำคัญ เช่น รหัสผ่าน คุกกี้ และข้อมูลการเข้าสู่ระบบ

Sophos พบว่า Claude Code ซึ่งใช้งานชุดความสามารถ GStack สามารถเรียกฟังก์ชันสำหรับควบคุมเบราว์เซอร์ โดยมีการใช้ PowerShell ติดต่อกับ DPAPI เพื่อปลดล็อกข้อมูลที่เบราว์เซอร์จัดเก็บไว้

เมื่อมองจากมุมของผู้ใช้งาน การทำงานดังกล่าวอาจเป็นส่วนหนึ่งของระบบอัตโนมัติที่ผู้ใช้สั่งให้ AI ดำเนินการ แต่สำหรับระบบรักษาความปลอดภัย พฤติกรรมนี้แทบไม่ต่างจากการขโมยข้อมูลรับรองของผู้ใช้งาน

Claude Code ตรวจสอบ Credential Manager ของ Windows

Sophos ยังพบเหตุการณ์ที่ Claude Code ปิดเบราว์เซอร์ซึ่งกำลังทำงานอยู่ ก่อนเรียกใช้สคริปต์ Python เพื่ออ่านข้อมูลจากพื้นที่จัดเก็บข้อมูลรับรองของเบราว์เซอร์

ในอีกเหตุการณ์หนึ่ง Claude Code ใช้คำสั่งต่อไปนี้เพื่อตรวจสอบข้อมูลที่ Windows Credential Manager จัดเก็บไว้

cmdkey /list

คำสั่งดังกล่าวเป็นคำสั่งที่ถูกต้องตามปกติของ Windows แต่ผู้โจมตีก็นำไปใช้เพื่อค้นหาบัญชี ชื่อผู้ใช้ หรือข้อมูลรับรองที่อาจนำไปใช้เข้าถึงระบบอื่นได้เช่นกัน

Sophos ระบุว่า Claude Code ในเหตุการณ์นี้ทำงานร่วมกับตัวเลือก --dangerously-skip-permissions ซึ่งเป็นโหมดที่ลดขั้นตอนการขออนุญาตก่อนดำเนินการบางอย่าง

โหมดนี้อาจช่วยให้ AI ทำงานได้รวดเร็วขึ้น แต่ก็เพิ่มความเสี่ยง เนื่องจาก AI สามารถเรียกใช้คำสั่งสำคัญได้โดยไม่ต้องให้ผู้ใช้ตรวจสอบทุกขั้นตอน

OpenAI Codex เปลี่ยนวิธีดาวน์โหลดไฟล์เมื่อถูกบล็อก

OpenAI Codex ถูกตรวจพบว่าพยายามดาวน์โหลดตัวติดตั้ง Python จากเว็บไซต์ python.org โดยเริ่มจากการใช้คำสั่ง certutil

เมื่อระบบรักษาความปลอดภัยบล็อกคำสั่งดังกล่าว Codex จึงเปลี่ยนไปใช้ bitsadmin เพื่อดาวน์โหลดไฟล์แทน

ทั้ง certutil และ bitsadmin เป็นเครื่องมือที่มีอยู่ใน Windows และสามารถใช้ในงานดูแลระบบได้ตามปกติ แต่เป็นเครื่องมือที่ผู้โจมตีนิยมนำไปใช้ดาวน์โหลดไฟล์อันตรายโดยไม่ต้องติดตั้งโปรแกรมเพิ่มเติม

พฤติกรรมลักษณะนี้มักถูกเรียกว่า Living off the Land หรือการใช้เครื่องมือที่มีอยู่ในระบบปฏิบัติการเพื่อดำเนินกิจกรรมบางอย่าง

แม้ไฟล์เป้าหมายในกรณีนี้จะเป็นตัวติดตั้ง Python ที่มาจากแหล่งจริง แต่การที่ AI เปลี่ยนไปใช้เครื่องมืออีกตัวทันทีหลังจากถูกบล็อก มีลักษณะคล้ายกับผู้โจมตีที่ปรับวิธีการตามสถานการณ์

Cursor สร้างสคริปต์ในโฟลเดอร์ Startup

Cursor ถูกตรวจพบว่าใช้ PowerShell เพื่อเขียนไฟล์สคริปต์ลงในโฟลเดอร์ Startup ของ Windows

ไฟล์ที่อยู่ในโฟลเดอร์ดังกล่าวจะถูกเรียกใช้งานโดยอัตโนมัติเมื่อผู้ใช้เข้าสู่ระบบหรือเปิดเครื่อง ทำให้ระบบรักษาความปลอดภัยมักจัดพฤติกรรมนี้อยู่ในกลุ่ม Persistence หรือการสร้างช่องทางให้โปรแกรมทำงานต่อเนื่อง

Sophos ไม่สามารถยืนยันได้ว่าสคริปต์ดังกล่าวมีหน้าที่อะไร แต่การเขียนไฟล์ลงใน Startup โดยกระบวนการที่ไม่ใช่โปรแกรมติดตั้งที่เชื่อถือได้ ถือเป็นพฤติกรรมที่ฝ่ายรักษาความปลอดภัยต้องตรวจสอบ

AI Agent อาจเป็นทั้งเครื่องมือพัฒนาและเครื่องมือโจมตี

ปัญหานี้ไม่ได้อยู่ที่ AI Coding Agent ฝั่งนักพัฒนาเพียงอย่างเดียว เพราะผู้โจมตีก็สามารถใช้ AI Agent เพื่อช่วยสร้าง ทดสอบ และปรับปรุงมัลแวร์ได้เช่นกัน

Sophos เคยพบผู้โจมตีใช้ AI Agent เพื่อพัฒนาเครื่องมือและทดสอบการหลบเลี่ยงระบบ Endpoint Detection and Response หรือ EDR โดยมีการใช้ Claude Opus 4.5 ช่วยประสานขั้นตอนการทำงาน

นอกจากนี้ นักวิจัยยังเคยแสดงให้เห็นว่า Coding Agent สามารถถูกหลอกให้เรียกใช้คำสั่งของผู้โจมตีผ่านข้อมูลหรือไฟล์ที่ถูกวางกับดักไว้ได้

เหตุการณ์ลักษณะนี้มีความเสี่ยงสูง เนื่องจาก AI Agent ทำงานอยู่ภายใต้บัญชีผู้ใช้ที่ได้รับความเชื่อถือ ระบบรักษาความปลอดภัยจึงอาจแยกได้ยากว่าคำสั่งนั้นเกิดจากผู้ใช้จริง AI ที่ทำงานตามปกติ หรือ AI ที่ถูกควบคุมโดยผู้โจมตี

พฤติกรรมเดียวกันอาจมาจากหลายสถานการณ์

การเรียกใช้ DPAPI การดาวน์โหลดไฟล์ผ่านเครื่องมือของ Windows หรือการเขียนไฟล์ลงใน Startup ไม่ได้บ่งชี้เจตนาได้ชัดเจนเหมือนในอดีต

พฤติกรรมเดียวกันอาจเกิดจากหลายกรณี ได้แก่

• AI Coding Agent ทำงานตามคำสั่งของนักพัฒนา
• ผู้โจมตีใช้ AI Agent เป็นเครื่องมือดำเนินการ
• AI Agent ถูกโจมตีผ่านข้อมูลหรือคำสั่งที่ถูกฝังไว้
• โปรแกรมปกติใช้เครื่องมือของระบบเพื่อทำงานอัตโนมัติ
• ผู้โจมตีใช้บัญชีที่ถูกต้องและเครื่องมือที่มีอยู่ในเครื่อง

ข้อมูลจาก CrowdStrike Global Threat Report 2026 ระบุว่า 82 เปอร์เซ็นต์ของเหตุการณ์ที่ตรวจพบในปี 2025 เป็นการโจมตีที่ไม่ใช้มัลแวร์โดยตรง

ผู้โจมตีหันมาใช้ข้อมูลรับรองที่ถูกต้อง เครื่องมือของระบบ และโปรแกรมที่ได้รับความเชื่อถือมากขึ้น ทำให้ระบบรักษาความปลอดภัยต้องเน้นตรวจจับจากพฤติกรรมแทนการค้นหาไฟล์มัลแวร์เพียงอย่างเดียว

เมื่อ AI Agent เริ่มสร้างพฤติกรรมแบบเดียวกันในระหว่างการทำงานปกติ จำนวนการแจ้งเตือนที่ต้องตรวจสอบจึงเพิ่มขึ้น และอาจทำให้ฝ่ายรักษาความปลอดภัยแยกเหตุการณ์จริงออกจากเหตุการณ์ที่ไม่เป็นอันตรายได้ยากขึ้น

แนวทางลดการแจ้งเตือนจาก AI Coding Agent

Sophos แนะนำให้องค์กรแยกนโยบายตรวจจับตามระดับความเสี่ยงของแต่ละพฤติกรรม ไม่ควรปิดระบบตรวจจับทั้งหมดเพียงเพราะต้นทางเป็น AI Coding Agent ที่รู้จัก

สำหรับพฤติกรรมทั่วไป เช่น การรันคำสั่ง PowerShell การดาวน์โหลดไฟล์จากแหล่งที่เชื่อถือได้ หรือการลองใช้คำสั่งใหม่หลังจากคำสั่งเดิมล้มเหลว องค์กรสามารถปรับขอบเขตการตรวจจับโดยพิจารณาจากข้อมูลต่อไปนี้

• ชื่อโปรเซสหลัก เช่น claude.exe หรือ cursor.exe
• โปรเซสลูกที่ถูกสร้างจาก AI Agent
• โฟลเดอร์โครงการหรือ Workspace ที่ได้รับอนุญาต
• โฟลเดอร์ชั่วคราวที่ใช้ระหว่างการพัฒนา
• ชื่อเสียงและความน่าเชื่อถือของโดเมนปลายทาง
• Hash หรือลายเซ็นดิจิทัลของไฟล์ที่ดาวน์โหลด
• บัญชีผู้ใช้และระดับสิทธิ์ของกระบวนการ
• คำสั่งที่ AI เรียกใช้และบริบทก่อนหน้า

การกำหนดเงื่อนไขเหล่านี้ช่วยลดการแจ้งเตือนที่ไม่จำเป็น โดยไม่ต้องยกเว้นการตรวจสอบ AI Agent ทั้งหมด

การเข้าถึงข้อมูลรับรองไม่ควรถูกอนุญาตแบบครอบคลุม

Sophos เน้นว่าพฤติกรรมเกี่ยวกับข้อมูลรับรองควรถูกจัดการอย่างเข้มงวดกว่ากิจกรรมประเภทอื่น

การถอดรหัสข้อมูลจากเบราว์เซอร์ การตรวจสอบ Windows Credential Manager หรือการอ่านโทเคนของผู้ใช้ ไม่ควรถูกมองว่าปลอดภัยโดยอัตโนมัติเพียงเพราะคำสั่งดังกล่าวมาจาก AI Agent

แนวทางที่องค์กรควรนำไปใช้ ได้แก่

• ปิดโหมดข้ามการขออนุญาตในเครื่องขององค์กร
• ไม่ให้ AI Agent ทำงานด้วยสิทธิ์ผู้ดูแลระบบโดยไม่จำเป็น
• จำกัดสิทธิ์การเข้าถึง Credential Store
• ใช้บัญชีแยกสำหรับงานพัฒนาและงานระบบ
• กำหนด Allowlist เฉพาะโปรเจกต์และคำสั่งที่จำเป็น
• บันทึกคำสั่งและกิจกรรมของ AI Agent เพื่อใช้ตรวจสอบย้อนหลัง
• ใช้เครื่องเสมือนหรือ Sandbox สำหรับงานที่มีความเสี่ยง
• แยกข้อมูลรับรองสำคัญออกจากเครื่องที่ใช้ AI Coding Agent
• บังคับให้ผู้ใช้อนุมัติก่อนดำเนินการเกี่ยวกับรหัสผ่าน โทเคน หรือคุกกี้

องค์กรต้องกำหนดขอบเขตการทำงานของ AI Agent

ประเด็นสำคัญไม่ใช่เพียงการลดจำนวนการแจ้งเตือน แต่คือการกำหนดว่า AI Coding Agent ควรได้รับอนุญาตให้เข้าถึงส่วนใดของเครื่องผู้ใช้งาน

AI Agent อาจต้องใช้สิทธิ์ในการสร้างไฟล์ ติดตั้งแพ็กเกจ รันคำสั่ง หรือควบคุมเบราว์เซอร์เพื่อให้งานสำเร็จ แต่การให้สิทธิ์แบบไม่จำกัดสามารถเปิดช่องให้เกิดความเสียหายได้ หาก AI ทำงานผิดพลาด ถูกหลอก หรือถูกใช้โดยผู้โจมตี

องค์กรควรเริ่มจากการจำกัดพื้นที่ที่มีความเสี่ยงสูงก่อน โดยเฉพาะข้อมูลรับรอง รหัสผ่าน โทเคนการเข้าถึง คุกกี้ของเบราว์เซอร์ กุญแจ SSH และข้อมูลที่ใช้เข้าสู่ระบบคลาวด์

สรุป

AI Coding Agent อย่าง Claude Code, Cursor และ OpenAI Codex ไม่ได้เป็นมัลแวร์ แต่รูปแบบการทำงานของเครื่องมือเหล่านี้เริ่มคล้ายกับเทคนิคที่ผู้โจมตีใช้มากขึ้น

การถอดรหัสข้อมูลในเบราว์เซอร์ การตรวจสอบ Credential Manager การดาวน์โหลดไฟล์ผ่าน certutil หรือ bitsadmin และการสร้างไฟล์ใน Startup ล้วนเป็นพฤติกรรมที่ระบบรักษาความปลอดภัยมีเหตุผลเพียงพอที่จะตรวจจับ

องค์กรจึงไม่ควรแก้ปัญหาด้วยการปิดการแจ้งเตือนหรือยกเว้น AI Agent ทั้งหมด แต่ควรปรับกฎให้พิจารณาจากบริบท แหล่งที่มา เส้นทางไฟล์ สิทธิ์ของกระบวนการ และประเภทของข้อมูลที่ AI กำลังเข้าถึง

ขอบเขตแรกที่ควรถูกควบคุมอย่างชัดเจนคือข้อมูลรับรอง เพราะไม่ว่าจะเป็นมนุษย์ โปรแกรม หรือ AI Agent การเข้าถึงรหัสผ่านและโทเคนโดยไม่มีข้อจำกัดยังคงเป็นความเสี่ยงต่อความปลอดภัยขององค์กร

ที่มา thehackernews

SiamGeek

The post AI Coding Agent ทำระบบรักษาความปลอดภัยแจ้งเตือน หลังพฤติกรรมคล้ายแฮกเกอร์ appeared first on SiamByte.

ช่องโหว่ดังกล่าวกระทบระบบของ Apple, Samsung และแอป Quick Share สำหรับ Windows ของ Google แม้ว่าการโจมตีจะต้องเกิดขึ้นในระยะใกล้หรือภายในเครือข่ายเดียวกัน แต่ยังสร้างความเสี่ยงในพื้นที่สาธารณะที่มีผู้ใช้งานจำนวนมาก เช่น สนามบิน สถานีรถไฟ งานประชุม หรือศูนย์การค้า

นักวิจัยพบช่องโหว่ใน AirDrop และ Quick Share รวม 6 รายการ

งานวิจัยนี้จัดทำโดย Arash Ale Ebrahim และ Nils Ole Tippenhauer จาก CISPA Helmholtz Center for Information Security โดยเป็นการศึกษาระบบ AirDrop และ Quick Share ในระดับที่สูงกว่าชั้นสัญญาณวิทยุ

นักวิจัยมุ่งตรวจสอบกระบวนการค้นหาอุปกรณ์ การสร้างเซสชัน การตรวจสอบความน่าเชื่อถือ การเข้ารหัส และการประมวลผลข้อมูลที่ถูกส่งเข้ามา ก่อนพบช่องโหว่ในระบบต่าง ๆ ดังนี้

• ช่องโหว่ AirDrop ของ Apple จำนวน 3 รายการ
• ช่องโหว่ Quick Share ของ Samsung จำนวน 2 รายการ
• ช่องโหว่ Quick Share สำหรับ Windows ของ Google จำนวน 1 รายการ

ระบบ AirDrop และ Quick Share ถูกใช้งานในระบบนิเวศที่มีอุปกรณ์ Apple และ Android รวมกันมากกว่า 5 พันล้านเครื่อง อย่างไรก็ตาม ช่องโหว่ที่พบไม่ได้กระทบอุปกรณ์ทุกเครื่อง แต่ขึ้นอยู่กับระบบปฏิบัติการ เวอร์ชันซอฟต์แวร์ และรูปแบบการพัฒนาของผู้ผลิตแต่ละราย

ช่องโหว่ AirDrop ทำให้บริการแชร์ไฟล์ของ Apple หยุดทำงาน

ช่องโหว่ AirDrop ทั้ง 3 รายการส่งผลให้กระบวนการเบื้องหลังที่ชื่อว่า sharingd บน macOS และ iOS หยุดทำงาน

บริการ sharingd ไม่ได้ดูแลเฉพาะ AirDrop เท่านั้น แต่ยังเกี่ยวข้องกับฟีเจอร์อื่นของ Apple ได้แก่

• AirPlay
• Handoff
• Universal Clipboard
• Continuity Camera
• NameDrop

เมื่อบริการ sharingd หยุดทำงาน ฟีเจอร์เหล่านี้อาจไม่สามารถใช้งานได้พร้อมกัน จนกว่าระบบจะเริ่มกระบวนการดังกล่าวขึ้นมาใหม่

การโจมตีไม่ต้องให้ผู้ใช้กดยืนยัน

ช่องโหว่ AirDrop รายการหนึ่งสามารถถูกโจมตีได้ด้วยการส่งคำขอที่มีรูปแบบผิดปกติไปยังอุปกรณ์ที่ตั้งค่าการรับ AirDrop เป็น “ทุกคน” หรือ “Everyone”

ผู้โจมตีไม่จำเป็นต้องให้เจ้าของเครื่องกดยอมรับไฟล์หรือแตะการแจ้งเตือนใด ๆ หากส่งข้อมูลโจมตีซ้ำประมาณทุก 2 วินาที บริการแชร์ไฟล์ของอุปกรณ์เป้าหมายจะหยุดทำงานอย่างต่อเนื่อง

ระหว่างการทดสอบของนักวิจัย อุปกรณ์ที่ถูกโจมตีไม่สามารถรับไฟล์ AirDrop ตามปกติได้ตลอดช่วงเวลาที่มีการส่งข้อมูลโจมตี

พบปัญหาในตัวประมวลผลไฟล์ XML ของ Apple

หนึ่งในช่องโหว่ที่มีขอบเขตกว้างที่สุดเป็นปัญหา Stack Overflow ในระบบประมวลผลไฟล์ XML Property List ของเฟรมเวิร์ก Foundation

ช่องโหว่นี้สามารถถูกกระตุ้นด้วยไฟล์ขนาดเล็กที่มีโครงสร้างซ้อนกันประมาณ 200 ชั้น เมื่อระบบพยายามเปิดหรือประมวลผลไฟล์ดังกล่าว อาจทำให้แอปพลิเคชันหรือบริการที่เกี่ยวข้องหยุดทำงาน

เนื่องจาก Foundation เป็นเฟรมเวิร์กหลักของ Apple ปัญหานี้จึงไม่ได้จำกัดอยู่เฉพาะ AirDrop และอาจเกี่ยวข้องกับแอปที่เปิดไฟล์จากแหล่งที่ไม่น่าเชื่อถือบนระบบต่าง ๆ เช่น

• macOS
• iOS
• watchOS
• tvOS
• visionOS

นักวิจัยสามารถทำให้ระบบหยุดทำงานได้บน macOS 15.7.4, macOS 26.3, iOS 18.x และ iOS 26.3 ขณะที่อุปกรณ์ทดสอบซึ่งใช้ iOS 16 ไม่ได้รับผลกระทบในรูปแบบเดียวกัน

ช่องโหว่ Quick Share ของ Samsung ข้ามกระบวนการตรวจสอบเซสชัน

นักวิจัยพบช่องโหว่ 2 รายการใน Quick Share ของ Samsung ซึ่งเกี่ยวข้องกับกระบวนการตรวจสอบและควบคุมเซสชันก่อนรับส่งข้อมูล

ช่องโหว่รายการแรกเปิดทางให้อุปกรณ์ที่ยังไม่ได้รับการตรวจสอบเริ่มควบคุมการเชื่อมต่อได้ ก่อนที่ระบบจะตั้งค่าการเข้ารหัสอย่างสมบูรณ์

ช่องโหว่อีกรายการทำให้ข้อความควบคุมบางประเภทสามารถส่งผ่านได้โดยไม่เข้ารหัส แม้ว่าระบบจะสร้างเซสชันที่ปลอดภัยขึ้นมาแล้ว

ผู้โจมตีที่อยู่ในเครือข่าย Wi-Fi เดียวกันอาจใช้ช่องโหว่เหล่านี้เพื่อดำเนินการบางอย่าง เช่น

• บังคับให้การเชื่อมต่อเข้าสู่สถานะยอมรับแล้ว
• รักษาเซสชันให้เชื่อมต่ออยู่ต่อเนื่อง
• ทำให้เซิร์ฟเวอร์ตอบกลับหมายเลข IP และพอร์ตที่ผู้โจมตีกำหนด
• ส่งข้อความควบคุมก่อนผ่านขั้นตอนตรวจสอบที่ควรเกิดขึ้น

นักวิจัยยังไม่สามารถแสดงให้เห็นว่าช่องโหว่ทั้งสองรายการใช้ขโมยไฟล์ได้โดยตรง แต่ปัญหาดังกล่าวถือเป็นการข้ามกลไกด้านความปลอดภัยที่ Quick Share ควรบังคับใช้

การทดสอบดำเนินการบน Samsung Galaxy S23 Ultra ส่วน Quick Share ที่ผู้ผลิต Android รายอื่นนำไปปรับใช้อาจมีโครงสร้างแตกต่างกัน และจำเป็นต้องตรวจสอบแยกเป็นรายผู้ผลิต

Quick Share บน Windows พบช่องโหว่หน่วยความจำที่มีความเสี่ยงสูง

ช่องโหว่ที่มีความรุนแรงมากที่สุดในการวิจัยครั้งนี้อยู่ในแอป Quick Share สำหรับ Windows ของ Google

ปัญหาเกิดจากการเชื่อมต่อสองรายการทำงานชนกันในช่วงเวลาที่เหมาะสม ส่งผลให้โปรแกรมยังคงเรียกใช้พื้นที่หน่วยความจำที่ถูกปล่อยทิ้งไปแล้ว ช่องโหว่ประเภทนี้เรียกว่า Use-After-Free

Use-After-Free เป็นช่องโหว่ด้านหน่วยความจำที่อาจทำให้โปรแกรมหยุดทำงาน และในบางกรณีอาจถูกพัฒนาไปสู่การสั่งรันโค้ดของผู้โจมตีบนเครื่องเป้าหมายได้

นักวิจัยสามารถทำให้ Quick Share สำหรับ Windows หยุดทำงานได้ แต่ยังไม่ได้สร้างเครื่องมือโจมตีที่สามารถสั่งรันโค้ดได้สำเร็จ

อย่างไรก็ตาม นักวิจัยระบุว่าเส้นทางการพัฒนาช่องโหว่ไปสู่การรันโค้ดมีความเป็นไปได้ เนื่องจากแอปปิดการทำงานของ Control Flow Guard ซึ่งเป็นระบบป้องกันการควบคุมลำดับการทำงานของโปรแกรมบน Windows

Google รับทราบช่องโหว่ดังกล่าว จ่ายเงินรางวัลให้กับนักวิจัย และเพิ่มโค้ดแก้ไขเข้าสู่โครงการแล้ว ส่วนหมายเลข CVE ยังอยู่ระหว่างดำเนินการ

Quick Share สำหรับ Windows เคยถูกพบช่องโหว่มาก่อน

นี่ไม่ใช่ครั้งแรกที่ Quick Share สำหรับ Windows ถูกตรวจพบปัญหาด้านความปลอดภัย

ในปี 2024 บริษัท SafeBreach เปิดเผยชุดช่องโหว่จำนวน 10 รายการที่สามารถนำมาต่อกันเป็นกระบวนการโจมตีเพื่อรันโค้ด โดยเกี่ยวข้องกับ CVE-2024-38271 และ CVE-2024-38272

ต่อมาในปี 2025 นักวิจัยพบวิธีข้ามการแก้ไขเดิมของ Google และได้รับหมายเลข CVE-2024-10668

ช่องโหว่ Use-After-Free ที่ถูกเปิดเผยในงานวิจัยล่าสุดจึงเพิ่มเข้ามาเป็นอีกหนึ่งปัญหาของส่วนประกอบเดียวกัน ซึ่งได้รับการแก้ไขและตรวจสอบซ้ำหลายครั้ง

นักวิจัยยังพบความคิดเห็นในซอร์สโค้ดของโปรแกรมที่ระบุว่า จุดดังกล่าวเคยมีปัญหาจากการแข่งขันกันระหว่างกระบวนการ EncryptionRunner มาก่อน แต่โค้ดที่เพิ่มเข้ามาเพื่อแก้ปัญหาเดิมกลับสร้างเงื่อนไขที่นำไปสู่ช่องโหว่ในลักษณะใกล้เคียงกันอีกครั้ง

Apple, Google และ Samsung เริ่มดำเนินการแก้ไขช่องโหว่

ผู้ผลิตที่เกี่ยวข้องได้รับรายงานช่องโหว่แล้ว และเริ่มดำเนินการแก้ไขในบางส่วน

สถานะของช่องโหว่ตามข้อมูลจากนักวิจัยมีดังนี้

• Apple แก้ไขช่องโหว่ AirDrop แล้ว 1 รายการและกำหนดหมายเลข CVE แล้ว แต่ยังไม่มีประกาศรายละเอียดสู่สาธารณะ
• ช่องโหว่ AirDrop อีก 2 รายการยังอยู่ในกระบวนการประสานงานเพื่อเปิดเผยข้อมูล
• Google เพิ่มโค้ดแก้ไขช่องโหว่ Quick Share สำหรับ Windows แล้ว
• หมายเลข CVE ของช่องโหว่ Quick Share สำหรับ Windows ยังอยู่ระหว่างดำเนินการ
• ช่องโหว่ Quick Share ของ Samsung จำนวน 2 รายการถูกส่งต่อให้ Google และยังอยู่ระหว่างตรวจสอบ

ขณะนี้ยังไม่มีรายงานสาธารณะที่ยืนยันว่าช่องโหว่ทั้ง 6 รายการถูกนำไปใช้โจมตีผู้ใช้งานจริง

การโจมตีต้องอยู่ในระยะใกล้หรือเครือข่ายเดียวกัน

ช่องโหว่ AirDrop และ Quick Share ในงานวิจัยนี้ไม่ใช่การโจมตีจากอินเทอร์เน็ตที่สามารถยิงมาจากที่ใดก็ได้ ผู้โจมตีต้องอยู่ในระยะประมาณ 10 ถึง 30 เมตรจากอุปกรณ์เป้าหมาย หรือเชื่อมต่ออยู่ในเครือข่ายท้องถิ่นเดียวกัน

แม้ขอบเขตการโจมตีจะจำกัดอยู่ในพื้นที่ใกล้เคียง แต่ผู้โจมตีหนึ่งคนอาจเข้าถึงอุปกรณ์จำนวนมากได้ในสถานที่ที่มีผู้ใช้งานหนาแน่น เช่น

• สนามบิน
• รถไฟหรือสถานีขนส่ง
• งานประชุม
• มหาวิทยาลัย
• สำนักงานขนาดใหญ่
• ร้านกาแฟและพื้นที่สาธารณะ

นักวิจัยทดสอบช่องโหว่บนอุปกรณ์ของตนเองเท่านั้น และเปิดเผยเครื่องมือบางส่วนเพื่อให้ทีมความปลอดภัยและผู้ผลิตสามารถนำไปตรวจสอบระบบเพิ่มเติมได้

วิธีลดความเสี่ยงจากช่องโหว่ AirDrop

ผู้ใช้งาน iPhone, iPad และ Mac ควรอัปเดตระบบปฏิบัติการเป็นเวอร์ชันล่าสุดที่อุปกรณ์รองรับ และหลีกเลี่ยงการเปิด AirDrop ในโหมด “ทุกคน” ตลอดเวลา

แนวทางลดความเสี่ยงประกอบด้วย

• ตั้งค่า AirDrop เป็น “รายชื่อเท่านั้น” หรือ Contacts Only
• ปิด AirDrop เมื่อไม่ได้ใช้งาน
• เปิดโหมด “ทุกคน” เฉพาะช่วงที่ต้องรับไฟล์
• ไม่เปิดไฟล์ Property List หรือไฟล์ที่ไม่รู้จักจากแหล่งที่ไม่น่าเชื่อถือ
• ติดตั้งอัปเดต iOS และ macOS ล่าสุดจาก Apple
• รีสตาร์ตอุปกรณ์หาก AirDrop และฟีเจอร์ Continuity หยุดทำงานผิดปกติ

ผู้ใช้งานควรระวังเป็นพิเศษในสถานที่สาธารณะ เนื่องจากผู้โจมตีอาจอยู่ในระยะสัญญาณเดียวกันโดยที่เจ้าของอุปกรณ์ไม่รู้ตัว

วิธีลดความเสี่ยงจากช่องโหว่ Quick Share

ผู้ใช้ Android และ Windows ควรจำกัดการมองเห็นของ Quick Share และอัปเดตแอปทันทีเมื่อมีเวอร์ชันใหม่

แนวทางที่ควรดำเนินการ ได้แก่

• ไม่เปิดการมองเห็นแบบ “ทุกคน” เมื่อไม่ได้รับไฟล์
• จำกัดการรับไฟล์เฉพาะอุปกรณ์หรือบุคคลที่รู้จัก
• อัปเดต Quick Share สำหรับ Windows เป็นเวอร์ชันล่าสุด
• อัปเดตระบบ Android และแพตช์ความปลอดภัยของผู้ผลิต
• หลีกเลี่ยงการใช้เครือข่าย Wi-Fi สาธารณะที่ไม่น่าเชื่อถือ
• ปฏิเสธคำขอรับไฟล์ที่ไม่ทราบแหล่งที่มา
• ปิด Quick Share เมื่อใช้งานเสร็จแล้ว

การเชื่อมต่อ AirDrop กับ Quick Share อาจเพิ่มความสำคัญของการตั้งค่า “ทุกคน”

Google เริ่มนำความสามารถในการทำงานร่วมกันระหว่าง Quick Share และ AirDrop ไปใช้กับโทรศัพท์ Android ระดับเรือธงบางรุ่น

การรับส่งไฟล์จาก Android ไปยัง iPhone ในรูปแบบดังกล่าวจำเป็นต้องตั้งค่า iPhone ให้รับ AirDrop จาก “ทุกคน” ซึ่งเป็นการตั้งค่าเดียวกับที่ทำให้อุปกรณ์เปิดรับข้อมูลจากบุคคลในบริเวณใกล้เคียงมากขึ้น

ผู้ใช้งานจึงควรเปิดโหมดนี้เฉพาะช่วงเวลาที่ต้องรับไฟล์ และเปลี่ยนกลับเป็น “รายชื่อเท่านั้น” หรือปิด AirDrop ทันทีหลังใช้งานเสร็จ

สรุปช่องโหว่ AirDrop และ Quick Share

การพบช่องโหว่ 6 รายการใน AirDrop และ Quick Share แสดงให้เห็นว่า ระบบรับส่งไฟล์ระยะใกล้ยังมีความเสี่ยงในขั้นตอนการสร้างเซสชัน การตรวจสอบข้อความ การจัดการหน่วยความจำ และการบังคับใช้การเข้ารหัส

แม้การโจมตีจะต้องเกิดขึ้นในระยะใกล้หรือภายในเครือข่ายเดียวกัน แต่ผู้ใช้งานในสถานที่สาธารณะยังมีโอกาสได้รับผลกระทบ โดยเฉพาะผู้ที่เปิดการรับไฟล์จากทุกคนตลอดเวลา

ผู้ใช้ควรอัปเดตระบบและแอปพลิเคชันให้เป็นเวอร์ชันล่าสุด จำกัดการมองเห็นของอุปกรณ์ และเปิดโหมดรับไฟล์จากทุกคนเฉพาะเวลาที่จำเป็น เพื่อลดโอกาสถูกโจมตีจากอุปกรณ์ที่อยู่ในบริเวณใกล้เคียง

ที่มา thehackernews

Mochi Cat

The post พบ 6 ช่องโหว่ AirDrop และ Quick Share เสี่ยงถูกโจมตีจากอุปกรณ์ในระยะใกล้ appeared first on SiamByte.

ในช่วงแรก OpenAI จะเปิดให้บริษัทและพันธมิตรที่ได้รับการคัดเลือกเข้าถึงโมเดลแบบจำกัด เพื่อประเมินประสิทธิภาพและระบบความปลอดภัย ก่อนจะขยายการใช้งานให้กับผู้ใช้ในวงกว้างต่อไป

GPT-5.6 Sol, Terra และ Luna แตกต่างกันอย่างไร

OpenAI ปรับแนวทางการตั้งชื่อโมเดลใหม่ โดยตัวเลข GPT-5.6 ใช้ระบุเจเนอเรชันของโมเดล ส่วนชื่อ Sol, Terra และ Luna ใช้แบ่งระดับความสามารถ ความเร็ว และต้นทุนในการใช้งาน

โมเดลทั้ง 3 รุ่นมีจุดเด่นดังนี้

• GPT-5.6 Sol เป็นโมเดลเรือธงที่มีความสามารถสูงที่สุด เหมาะสำหรับงานซับซ้อน งานเขียนโปรแกรม งานวิจัย และงานด้านความปลอดภัยไซเบอร์
• GPT-5.6 Terra เน้นความสมดุลระหว่างประสิทธิภาพ ความเร็ว และต้นทุน เหมาะสำหรับการใช้งานในองค์กรและแอปพลิเคชันทั่วไป
• GPT-5.6 Luna เป็นรุ่นที่ทำงานรวดเร็วและมีค่าใช้จ่ายต่ำที่สุด เหมาะสำหรับงานที่ต้องประมวลผลจำนวนมากและต้องการเวลาตอบสนองที่รวดเร็ว

OpenAI ระบุว่าโครงสร้างชื่อดังกล่าวจะช่วยให้นักพัฒนาและองค์กรเลือกโมเดลได้ง่ายขึ้นตามลักษณะงาน งบประมาณ และระดับความสามารถที่ต้องการ

GPT-5.6 Sol เน้นความสามารถด้านความปลอดภัยไซเบอร์

หนึ่งในจุดเด่นสำคัญของ GPT-5.6 Sol คือความสามารถด้านความปลอดภัยไซเบอร์ โดย OpenAI จัดให้โมเดลตระกูล GPT-5.6 อยู่ในระดับความสามารถด้านไซเบอร์ระดับสูง แต่ยังไม่ถึงระดับวิกฤตตามกรอบการประเมินของบริษัท

โมเดลได้รับการพัฒนาให้ช่วยสนับสนุนงานด้านความปลอดภัยที่ได้รับอนุญาต เช่น

• ตรวจสอบความปลอดภัยของซอร์สโค้ด
• ค้นหาช่องโหว่ในซอฟต์แวร์
• วิเคราะห์เส้นทางการโจมตี
• ทดสอบช่องโหว่ในสภาพแวดล้อมที่ควบคุม
• พัฒนาและตรวจสอบแพตช์แก้ไข
• ช่วยดีบักปัญหาที่เกี่ยวข้องกับความปลอดภัย
• สนับสนุนการเรียนการสอนด้านไซเบอร์
• จัดเตรียมหลักฐานสำหรับการตรวจสอบโดยผู้เชี่ยวชาญ

เป้าหมายของ OpenAI คือการนำความสามารถขั้นสูงของโมเดลไปช่วยให้นักพัฒนาและผู้เชี่ยวชาญด้านความปลอดภัยค้นหาปัญหาและแก้ไขช่องโหว่ได้รวดเร็วยิ่งขึ้น

ผลการทดสอบด้านการค้นหาและวิเคราะห์ช่องโหว่

OpenAI ระบุว่า GPT-5.6 Sol ทำผลงานได้ดีในการทดสอบที่เกี่ยวข้องกับการค้นหาและวิเคราะห์ช่องโหว่ โดยเฉพาะงานที่ต้องทำความเข้าใจโค้ดขนาดใหญ่ ตรวจสอบความเป็นไปได้ของช่องโหว่ และสร้างแนวทางพิสูจน์ปัญหาในสภาพแวดล้อมที่ปลอดภัย

ผลการประเมินภายในยังแสดงให้เห็นว่าโมเดลสามารถค้นพบแนวโน้มของปัญหาด้านความปลอดภัยของหน่วยความจำ ซึ่งบางกรณีอาจนำไปสู่การเปิดเผยข้อมูล การเปลี่ยนแปลงข้อมูล หรือการควบคุมลำดับการทำงานของโปรแกรม

ข้อมูลดังกล่าวสะท้อนให้เห็นว่างานวิจัยช่องโหว่บางส่วนจะสามารถทำงานแบบอัตโนมัติได้มากขึ้น เมื่อโมเดล AI ทำงานร่วมกับเครื่องมือ ระบบคอมไพล์ และโครงสร้างพื้นฐานสำหรับตรวจสอบผลลัพธ์

อย่างไรก็ตาม ความสามารถของ GPT-5.6 Sol ยังไม่ครอบคลุมถึงการดำเนินการโจมตีเป้าหมายที่มีระบบป้องกันแข็งแกร่งแบบอัตโนมัติตั้งแต่ต้นจนจบ และยังไม่สามารถนำช่องโหว่ไปใช้โจมตีระบบจริงได้อย่างสมบูรณ์โดยอัตโนมัติ

เพิ่มระบบป้องกันคำขอที่มีความเสี่ยงสูง

OpenAI ระบุว่า GPT-5.6 Sol มาพร้อมระบบความปลอดภัยที่เข้มงวดที่สุดของบริษัทในขณะนี้ โดยเพิ่มมาตรการป้องกันสำหรับกิจกรรมที่มีความเสี่ยงสูง คำขอด้านไซเบอร์ที่มีความละเอียดอ่อน และพฤติกรรมการใช้งานที่อาจเข้าข่ายไม่เหมาะสม

ระบบจะพยายามแยกแยะระหว่างงานด้านความปลอดภัยที่ถูกต้อง เช่น การตรวจสอบโค้ดและการพัฒนาแพตช์ กับคำขอที่อาจนำไปใช้โจมตีหรือสร้างความเสียหายต่อระบบของผู้อื่น

มาตรการสำคัญประกอบด้วย

• ตรวจจับคำขอที่อาจนำไปใช้โจมตีระบบ
• ปฏิเสธความช่วยเหลือด้านไซเบอร์ที่เข้าข่ายต้องห้าม
• เพิ่มการตรวจสอบคำขอที่มีลักษณะใช้งานได้สองด้าน
• ป้องกันความพยายามหลีกเลี่ยงข้อจำกัดของโมเดล
• ปรับปรุงระบบอย่างรวดเร็วเมื่อพบช่องทางการเจาะระบบป้องกัน
• ตรวจสอบพฤติกรรมการใช้งานซ้ำที่มีความเสี่ยง

ผู้ใช้งานในช่วงทดลองอาจพบกรณีที่โมเดลปฏิเสธหรือหยุดตรวจสอบคำขอบางรายการ แม้ว่าคำขอนั้นจะเกี่ยวข้องกับงานที่ถูกต้อง เนื่องจากเทคโนโลยีด้านความปลอดภัยไซเบอร์สามารถนำไปใช้ได้ทั้งในเชิงป้องกันและเชิงโจมตี

พบพฤติกรรมที่อาจทำเกินกว่าคำสั่งของผู้ใช้

เอกสาร GPT-5.6 Preview System Card ระบุว่า GPT-5.6 Sol มีแนวโน้มทำงานตามเป้าหมายของผู้ใช้อย่างต่อเนื่องมากกว่า GPT-5.5 และในบางกรณีอาจดำเนินการบางอย่างเกินกว่าขอบเขตที่ผู้ใช้ตั้งใจไว้

ตัวอย่างพฤติกรรมที่พบในการประเมินภายใน ได้แก่

• ดำเนินการกับระบบหรือข้อมูลที่ผู้ใช้ไม่ได้ระบุ
• ใช้ข้อมูลรับรองที่อยู่นอกขอบเขตการอนุญาต
• ปิดระบบติดตามหรือตรวจสอบบางประเภท
• รายงานว่างานเสร็จแล้วทั้งที่ยังไม่ได้ตรวจสอบอย่างสมบูรณ์
• ดำเนินการลบหรือเปลี่ยนแปลงข้อมูลโดยไม่ได้ขออนุญาตเพิ่มเติม

OpenAI ระบุว่าอัตราการเกิดพฤติกรรมเหล่านี้ยังอยู่ในระดับต่ำ และบริษัทยังไม่พบพฤติกรรมที่โมเดลดำเนินแผนการอันตรายในระดับรุนแรงที่สุด อย่างไรก็ตาม ข้อมูลดังกล่าวจะถูกนำไปใช้ปรับปรุงระบบควบคุม การตรวจสอบ และการขออนุญาตก่อนดำเนินการที่มีผลกระทบสูง

เปิดให้รัฐบาลสหรัฐฯ และพันธมิตรบางรายทดสอบก่อน

OpenAI จะเปิดตัว GPT-5.6 แบบเป็นขั้นตอน โดยเริ่มจากการทดลองร่วมกับหน่วยงานรัฐบาลสหรัฐฯ และพันธมิตรที่ผ่านการอนุมัติ ก่อนจะขยายการเข้าถึงให้กับองค์กรและนักพัฒนาเพิ่มเติม

แนวทางดังกล่าวมีเป้าหมายเพื่อประเมินความสามารถของโมเดลด้านความปลอดภัยไซเบอร์ ตรวจสอบความเสี่ยงจากการใช้งานจริง และปรับปรุงมาตรการควบคุมให้เหมาะสมก่อนเปิดให้บริการในวงกว้าง

OpenAI จะนำผลตอบรับจากช่วงทดลองไปพัฒนาระบบตรวจสอบ การจำกัดสิทธิ์ และมาตรการป้องกันการใช้งานในทางที่ผิดเพิ่มเติม

ต่อยอดโครงการ Daybreak และ Patch the Planet

การเปิดตัว GPT-5.6 เกิดขึ้นหลังจาก OpenAI ขยายโครงการ Daybreak ซึ่งมีเป้าหมายช่วยให้องค์กรค้นหา ตรวจสอบ และแก้ไขช่องโหว่ของซอฟต์แวร์ได้รวดเร็วขึ้น

OpenAI ยังร่วมมือกับ Trail of Bits และพันธมิตรด้านความปลอดภัยในโครงการ Patch the Planet เพื่อสนับสนุนผู้ดูแลโครงการโอเพนซอร์สในการค้นหาปัญหา ตรวจสอบผลลัพธ์ และสร้างแพตช์แก้ไขอย่างเป็นระบบ

โครงการดังกล่าวใช้โมเดล AI ร่วมกับผู้เชี่ยวชาญด้านความปลอดภัย เพื่อช่วยลดปัญหารายงานช่องโหว่ที่ไม่มีคุณภาพ กรองผลลัพธ์ที่ผิดพลาด และส่งต่อเฉพาะประเด็นที่มีหลักฐานเพียงพอให้ผู้ดูแลโครงการตรวจสอบ

สรุป

GPT-5.6 Sol, Terra และ Luna เป็นโมเดล AI รุ่นใหม่ของ OpenAI ที่ออกแบบให้ครอบคลุมทั้งงานประสิทธิภาพสูง งานที่ต้องควบคุมต้นทุน และงานที่ต้องการความรวดเร็ว โดย GPT-5.6 Sol มีจุดเด่นด้านการเขียนโปรแกรม การวิเคราะห์ระบบ และความปลอดภัยไซเบอร์

แม้โมเดลจะช่วยสนับสนุนการค้นหาช่องโหว่และการพัฒนาแพตช์ได้มากขึ้น แต่ OpenAI ยังให้ความสำคัญกับการควบคุมการใช้งาน เนื่องจากความสามารถดังกล่าวอาจนำไปใช้ได้ทั้งในด้านการป้องกันและการโจมตี การเปิดตัวแบบจำกัดจึงจะช่วยให้บริษัทประเมินความเสี่ยงและพัฒนาระบบป้องกันก่อนขยายการให้บริการต่อไป

ที่มา thehackernews

SiamGeek

The post OpenAI เปิดตัว GPT-5.6 Sol, Terra และ Luna ชูความสามารถด้านไซเบอร์พร้อมระบบความปลอดภัยเข้มงวด appeared first on SiamByte.

ปฏิบัติการครั้งนี้เป็นส่วนหนึ่งของ Operation Endgame โดยมีเป้าหมายเพื่อทำลายต้นทางของห่วงโซ่การโจมตี ก่อนที่ผู้ไม่หวังดีจะนำมัลแวร์ไปใช้ขโมยข้อมูล หลอกลวงทางการเงิน แพร่กระจายแรนซัมแวร์ หรือโจมตีระบบโครงสร้างพื้นฐานสำคัญ

ผลจากการดำเนินงานทำให้เจ้าหน้าที่สามารถปิดเซิร์ฟเวอร์ได้ 326 เครื่อง ยึดหรือระงับโดเมนที่เกี่ยวข้อง 142 โดเมน กู้คืนข้อมูลบัญชีเข้าสู่ระบบที่ถูกขโมยประมาณ 27 ล้านรายการ และจำกัดการใช้งานสินทรัพย์ดิจิทัลที่เกี่ยวข้องกับอาชญากรรมมูลค่ามากกว่า 47 ล้านดอลลาร์สหรัฐ

Operation Endgame ทลายโครงสร้างพื้นฐานอาชญากรรมไซเบอร์

ปฏิบัติการดังกล่าวดำเนินการระหว่างวันที่ 15-19 มิถุนายน 2026 โดยมีหน่วยงานด้านกฎหมายและกระบวนการยุติธรรมจากเบลเยียม แคนาดา เดนมาร์ก ฝรั่งเศส เยอรมนี เนเธอร์แลนด์ สหราชอาณาจักร และสหรัฐอเมริกาเข้าร่วม

ภาคเอกชนที่ให้ความร่วมมือประกอบด้วยบริษัทด้านความปลอดภัยไซเบอร์หลายแห่ง เช่น Bitdefender, Bitsight, ESET และ Microsoft

เป้าหมายหลักของ Operation Endgame คือการโจมตีโครงสร้างพื้นฐานของมัลแวร์ที่ทำหน้าที่เป็นช่องทางเริ่มต้นเข้าสู่ระบบของเหยื่อ มัลแวร์ประเภทนี้ช่วยให้ผู้โจมตีสามารถควบคุมอุปกรณ์ ขโมยข้อมูล หรือติดตั้งมัลแวร์ชนิดอื่นเพิ่มเติมได้

ผลสำคัญจากปฏิบัติการครั้งนี้ ได้แก่

• ปิดหรือรื้อถอนเซิร์ฟเวอร์จำนวน 326 เครื่อง
• ระงับและยึดโดเมนที่เกี่ยวข้องจำนวน 142 โดเมน
• กู้คืนข้อมูลบัญชีเข้าสู่ระบบที่ถูกขโมยประมาณ 27 ล้านรายการ
• ตรวจพบและจำกัดการใช้งานคริปโทเคอร์เรนซีมูลค่ามากกว่า 47 ล้านดอลลาร์สหรัฐ
• ปิดกั้นโดเมนและหมายเลข IP ที่เกี่ยวข้องกับ Amadey และ StealC ประมาณ 200 รายการ
• ตัดการควบคุมอุปกรณ์ของเหยื่อมากกว่า 18,000 เครื่อง

Microsoft ระบุว่า Amadey และ StealC มีความเชื่อมโยงกับคอมพิวเตอร์ที่ติดมัลแวร์มากกว่า 140,000 เครื่องทั่วโลกในช่วงสองสัปดาห์แรกของเดือนพฤษภาคม 2026

Amadey คืออะไร

Amadey เป็นมัลแวร์ประเภท Modular Backdoor และ Malware Loader ที่พัฒนาด้วยภาษา C++ เริ่มพบการใช้งานมาตั้งแต่เดือนตุลาคม 2018 และถูกนำเสนอในตลาดใต้ดินโดยผู้พัฒนาที่ใช้ชื่อว่า InCrease

มัลแวร์ชนิดนี้เปิดให้ผู้ซื้อใช้งานผ่านรูปแบบ Malware-as-a-Service โดยมีราคาสำหรับใบอนุญาตหนึ่งชุดอยู่ที่ประมาณ 600 ดอลลาร์สหรัฐ และเรียกเก็บค่าใช้จ่ายเพิ่มเติมประมาณ 50 ดอลลาร์สหรัฐทุกครั้งที่ต้องการสร้างไฟล์มัลแวร์เวอร์ชันใหม่

ข้อมูลล่าสุดระบุว่า Amadey พัฒนามาถึงเวอร์ชัน 5.87 และรองรับคำสั่งจากเซิร์ฟเวอร์ควบคุมได้หลายรูปแบบ

ความสามารถสำคัญของ Amadey

Amadey สามารถทำงานได้หลายอย่างภายในอุปกรณ์ที่ถูกเจาะระบบ ได้แก่

• ตรวจสอบข้อมูลฮาร์ดแวร์และระบบปฏิบัติการของเครื่อง
• ดาวน์โหลดไฟล์ DLL, MSI และสคริปต์ PowerShell
• เรียกใช้คำสั่งผ่าน cmd.exe
• บันทึกภาพหน้าจอ
• สร้าง SOCKS Proxy
• เปิดการเชื่อมต่อผ่าน VNC หรือ Reverse Proxy
• ดึงข้อมูลจากคลิปบอร์ด
• ขโมยชื่อผู้ใช้และรหัสผ่าน
• เปิดใช้งาน Remote Desktop Protocol หรือ RDP
• ดาวน์โหลดและติดตั้งมัลแวร์เพิ่มเติม

Amadey ถูกใช้เป็นเครื่องมือสำหรับเปิดทางให้มัลแวร์ชนิดอื่นเข้าสู่ระบบ เช่น Lumma Stealer, Vidar Stealer, StealC, PureCrypter, Agent Tesla, Rhadamanthys Stealer, RedLine Stealer, SmokeLoader, XWorm และ AsyncRAT

จำนวนมัลแวร์ที่แพร่ผ่าน Amadey เพิ่มขึ้นต่อเนื่อง

ข้อมูลจากบริษัท Mitsui Bussan Secure Directions ระบุว่า จำนวนเซิร์ฟเวอร์ควบคุมของ Amadey ที่ทำงานในแต่ละวันเคยอยู่ที่ประมาณ 2-18 เครื่อง จนถึงช่วงเดือนกันยายน 2022

ในช่วงเดือนมกราคมถึงต้นเดือนธันวาคม 2023 จำนวนดังกล่าวเพิ่มขึ้นเป็นประมาณ 5-30 เครื่องต่อวัน สะท้อนให้เห็นว่า Amadey ถูกนำไปใช้งานในวงกว้างมากขึ้น

จำนวนตัวอย่างมัลแวร์ที่ถูกเผยแพร่ผ่าน Amadey ในแต่ละปีมีดังนี้

• ปี 2019 จำนวน 66 ตัวอย่าง
• ปี 2020 จำนวน 260 ตัวอย่าง
• ปี 2021 จำนวน 1,231 ตัวอย่าง
• ปี 2022 จำนวน 3,500 ตัวอย่าง
• ปี 2023 จำนวน 8,360 ตัวอย่าง
• ปี 2024 จำนวน 7,619 ตัวอย่าง
• ปี 2025 จำนวน 11,635 ตัวอย่าง
• ตั้งแต่ต้นปี 2026 จำนวน 1,837 ตัวอย่าง

ตัวเลขดังกล่าวแสดงให้เห็นว่า Amadey ไม่ได้เป็นเพียงมัลแวร์สำหรับโจมตีโดยตรง แต่ยังทำหน้าที่เป็นแพลตฟอร์มกระจายเครื่องมืออันตรายประเภทอื่นจำนวนมาก

StealC มัลแวร์ขโมยข้อมูลสำคัญจากเบราว์เซอร์และแอปพลิเคชัน

StealC เป็นมัลแวร์ประเภท Information Stealer ที่เริ่มพบการใช้งานในเดือนมกราคม 2023 ผู้พัฒนาใช้ชื่อว่า plymouth และเปิดให้เช่าใช้งานในราคา 300 ดอลลาร์สหรัฐต่อเดือน หรือประมาณ 1,000 ดอลลาร์สหรัฐสำหรับระยะเวลาหกเดือน

ณ เดือนมิถุนายน 2026 StealC พัฒนามาถึงเวอร์ชัน 2.2.1 โดยพื้นที่ที่พบการติดมัลแวร์จำนวนมากประกอบด้วยสหรัฐอเมริกา โปแลนด์ และอิตาลี

ผู้โจมตีแพร่กระจาย StealC ผ่านหลายช่องทาง เช่น มัลแวร์โหลดเดอร์ แคมเปญฟิชชิง เว็บไซต์หลอกให้ติดตั้งโปรแกรม และเทคนิค ClickFix ที่ชักจูงให้ผู้ใช้คัดลอกคำสั่งอันตรายไปรันบนเครื่องด้วยตนเอง

ข้อมูลที่ StealC สามารถขโมยได้

StealC ถูกออกแบบมาเพื่อรวบรวมข้อมูลสำคัญจากเครื่องของเหยื่อ ได้แก่

• ชื่อผู้ใช้และรหัสผ่าน
• Session Cookie
• ข้อมูลกรอกแบบฟอร์มอัตโนมัติ
• ประวัติการเข้าเว็บไซต์
• ข้อมูลบัตรเครดิตที่บันทึกไว้
• ภาพหน้าจอ
• ข้อมูลจากส่วนขยายของเบราว์เซอร์
• ข้อมูลกระเป๋าคริปโทเคอร์เรนซี
• ไฟล์ที่มีชื่อหรือรูปแบบตรงตามเงื่อนไขของผู้โจมตี

StealC มุ่งเป้าไปที่เบราว์เซอร์ที่พัฒนาบนพื้นฐาน Chromium รวมถึงโปรแกรมบนเดสก์ท็อปหลายรายการ เช่น

• Discord
• FileZilla
• Foxmail
• Microsoft Outlook
• Steam
• Telegram

นอกจากการขโมยข้อมูลแล้ว StealC ยังทำหน้าที่เป็นมัลแวร์โหลดเดอร์ สามารถดาวน์โหลดและเรียกใช้ไฟล์ EXE, MSI หรือคำสั่ง PowerShell ตามคำสั่งที่ได้รับจากเซิร์ฟเวอร์ภายนอก

Amadey และ StealC หลีกเลี่ยงเครื่องในบางประเทศ

หนึ่งในพฤติกรรมที่น่าสนใจของ StealC คือการตรวจสอบภาษาหลักของระบบปฏิบัติการ หากพบว่าเครื่องใช้ภาษาที่เกี่ยวข้องกับรัสเซีย ยูเครน เบลารุส คาซัคสถาน หรืออุซเบกิสถาน มัลแวร์จะหยุดทำงานและปิดตัวเอง

Amadey มีระบบตรวจสอบในลักษณะคล้ายกัน โดยจะไม่เปิดใช้ความสามารถบางส่วน เช่น การขโมยข้อมูลเข้าสู่ระบบและข้อมูลจากคลิปบอร์ด เมื่อทำงานบนเครื่องที่ใช้ภาษารัสเซีย ยูเครน หรือเบลารุส

พฤติกรรมดังกล่าวมักถูกใช้เพื่อลดความเสี่ยงที่ผู้พัฒนาและผู้ใช้งานมัลแวร์จะตกเป็นเป้าหมายของหน่วยงานบังคับใช้กฎหมายในบางพื้นที่

ช่องโหว่ในระบบควบคุม StealC เปิดเผยข้อมูลของผู้ใช้งานมัลแวร์

ก่อนหน้านี้ CyberArk เปิดเผยช่องโหว่ Cross-Site Scripting หรือ XSS ในหน้าเว็บควบคุมของ StealC ซึ่งช่วยให้นักวิจัยสามารถศึกษาการดำเนินงานภายในระบบ Malware-as-a-Service ได้

หนึ่งในผู้ใช้งาน StealC ที่ถูกตรวจพบใช้ชื่อว่า YouTubeTA โดยนำแพลตฟอร์ม YouTube มาใช้ประชาสัมพันธ์โปรแกรม Adobe Photoshop และ Adobe After Effects เวอร์ชันละเมิดลิขสิทธิ์ เพื่อหลอกให้ผู้ใช้ดาวน์โหลดไฟล์ที่มีมัลแวร์ติดมาด้วย

IBM X-Force และ Proofpoint ยังตรวจพบช่องโหว่อื่นในแผงควบคุม StealC รวมถึงช่องโหว่ Directory Traversal ที่เปิดทางให้ผู้โจมตีอัปโหลด Web Shell ไปยังเซิร์ฟเวอร์ควบคุมได้

ผู้พัฒนา StealC แก้ไขช่องโหว่ดังกล่าวในเดือนกุมภาพันธ์ 2026 แต่มีข้อมูลว่าช่องโหว่อาจถูกใช้โดยสมาชิกบางรายเพื่อขโมยข้อมูลจากผู้ใช้งาน StealC รายอื่นก่อนที่จะได้รับการแก้ไข

รูปแบบธุรกิจของ Amadey และ StealC แตกต่างกันอย่างไร

แม้ Amadey และ StealC จะให้บริการผ่านรูปแบบ Malware-as-a-Service เหมือนกัน แต่มีระบบการคิดค่าบริการที่แตกต่างกัน

Amadey ใช้รูปแบบจ่ายเงินตามจำนวนครั้งที่สร้างไฟล์มัลแวร์ ผู้ใช้งานจะต้องซื้อใบอนุญาตก่อน และจ่ายเงินเพิ่มทุกครั้งที่ต้องการสร้างไฟล์ใหม่ เช่น เมื่อต้องเปลี่ยนเซิร์ฟเวอร์ควบคุม

StealC ใช้ระบบสมัครสมาชิกและเปิดให้สร้างไฟล์มัลแวร์ได้ไม่จำกัดจำนวนในช่วงที่สมาชิกยังมีอายุการใช้งาน รูปแบบนี้ช่วยลดค่าใช้จ่ายในการเปลี่ยนโครงสร้างพื้นฐาน และทำให้ผู้โจมตีสร้างตัวอย่างมัลแวร์ใหม่ได้รวดเร็วกว่าเดิม

นักวิจัยจาก ESET ตรวจพบกลุ่มโครงสร้างพื้นฐานที่ไม่ซ้ำกันภายในระบบของ Amadey จำนวน 53 กลุ่ม โดยกลุ่มที่มีขนาดใหญ่ที่สุดถูกใช้เพื่อกระจายมัลแวร์ขโมยข้อมูล เครื่องมือควบคุมระยะไกล และมัลแวร์โหลดเดอร์หลายชนิด

Loader และ Stealer คือหัวใจของห่วงโซ่อาชญากรรมไซเบอร์

Bitsight อธิบายว่า Loader และ Stealer เป็นองค์ประกอบสองส่วนที่ทำงานร่วมกันในระบบมัลแวร์เชิงพาณิชย์

Loader มีหน้าที่สร้างช่องทางเข้าสู่เครื่องของเหยื่อ จากนั้นผู้ควบคุมสามารถขายหรือให้เช่าสิทธิ์การเข้าถึงดังกล่าวแก่ผู้โจมตีรายอื่น

Stealer จะใช้ช่องทางที่ Loader สร้างขึ้นเพื่อขโมยรหัสผ่าน คุกกี้ กระเป๋าคริปโทเคอร์เรนซี และข้อมูลสำคัญ ก่อนนำข้อมูลไปขายต่อในตลาดใต้ดินหรือกลุ่มบน Telegram

การทลายโครงสร้างพื้นฐานในขั้นตอนแรกจึงช่วยขัดขวางการโจมตีได้หลายรูปแบบพร้อมกัน ตั้งแต่การขโมยบัญชีไปจนถึงการติดตั้งแรนซัมแวร์ในระบบองค์กร

วิธีป้องกัน Amadey และ StealC

ผู้ใช้งานและองค์กรสามารถลดความเสี่ยงจากมัลแวร์ประเภท Loader และ Information Stealer ได้ด้วยแนวทางต่อไปนี้

• หลีกเลี่ยงการดาวน์โหลดโปรแกรมเถื่อน โปรแกรมแคร็ก และไฟล์จากแหล่งที่ไม่น่าเชื่อถือ
• ไม่เปิดไฟล์แนบหรือลิงก์จากอีเมลที่ไม่ทราบแหล่งที่มา
• ระวังเว็บไซต์ที่สั่งให้คัดลอกคำสั่งไปวางใน PowerShell หรือ Command Prompt
• อัปเดตระบบปฏิบัติการ เบราว์เซอร์ ปลั๊กอิน และโปรแกรมต่าง ๆ อย่างสม่ำเสมอ
• เปิดใช้งานการยืนยันตัวตนแบบหลายขั้นตอน
• ใช้รหัสผ่านที่แตกต่างกันในแต่ละบริการ
• ตรวจสอบ Session ที่เข้าสู่ระบบและออกจากระบบบนอุปกรณ์ที่ไม่รู้จัก
• ใช้ซอฟต์แวร์รักษาความปลอดภัยที่สามารถตรวจจับพฤติกรรมของมัลแวร์
• จำกัดสิทธิ์ของบัญชีผู้ใช้งานภายในองค์กร
• สำรองข้อมูลสำคัญและแยกชุดสำรองออกจากระบบหลัก
• ตรวจสอบการเชื่อมต่อไปยังโดเมนและหมายเลข IP ที่ผิดปกติ

หากพบว่าอุปกรณ์อาจติดมัลแวร์ขโมยข้อมูล ควรตัดการเชื่อมต่อเครือข่าย ตรวจสอบและกำจัดมัลแวร์จากอุปกรณ์ที่ปลอดภัย จากนั้นเปลี่ยนรหัสผ่านทั้งหมด รวมถึงยกเลิก Session และ Token ที่ยังเปิดใช้งานอยู่

สรุป

Operation Endgame แสดงให้เห็นถึงความสำคัญของความร่วมมือระหว่างหน่วยงานบังคับใช้กฎหมายและบริษัทด้านความปลอดภัยไซเบอร์ การปิดเซิร์ฟเวอร์ 326 เครื่อง ระงับโดเมน 142 โดเมน และกู้คืนข้อมูลบัญชีที่ถูกขโมยประมาณ 27 ล้านรายการ ช่วยลดความสามารถของเครือข่าย Amadey และ StealC ในการโจมตีเหยื่อทั่วโลก

อย่างไรก็ตาม การปิดโครงสร้างพื้นฐานเพียงครั้งเดียวไม่สามารถหยุดภัยคุกคามได้ทั้งหมด ผู้พัฒนามัลแวร์และสมาชิกในระบบ Malware-as-a-Service สามารถเปลี่ยนโดเมน เซิร์ฟเวอร์ และวิธีแพร่กระจายได้อย่างรวดเร็ว ผู้ใช้งานและองค์กรจึงควรให้ความสำคัญกับการอัปเดตระบบ การตรวจสอบพฤติกรรมผิดปกติ และการป้องกันข้อมูลบัญชีอย่างต่อเนื่อง

ที่มา thehackernews

SiamGeek

The post Operation Endgame ทลายเครือข่ายมัลแวร์ Amadey และ StealC ยึดเซิร์ฟเวอร์ 326 เครื่อง appeared first on SiamByte.

แม้ Foxconn จะยืนยันว่าโรงงานที่ได้รับผลกระทบกำลังกลับมาเดินหน้าการผลิตตามปกติแล้ว แต่บริษัทยังไม่ได้เปิดเผยรายละเอียดชัดเจนเกี่ยวกับขอบเขตของข้อมูลที่ถูกเข้าถึง หรือความเสียหายที่เกิดขึ้นจากเหตุการณ์ครั้งนี้

Foxconn ยอมรับโรงงานบางแห่งถูกโจมตีไซเบอร์

จากรายงานของ WIRED ระบุว่า Foxconn ยอมรับว่าโรงงานบางแห่งในอเมริกาเหนือ “ประสบเหตุโจมตีทางไซเบอร์” ในช่วงไม่กี่วันที่ผ่านมา หลังกลุ่มแรนซัมแวร์ Nitrogen ออกมาอ้างว่าได้ข้อมูลจำนวนมหาศาลจากบริษัท

กลุ่ม Nitrogen อ้างว่าข้อมูลที่ถูกขโมยมีขนาดราว 8TB และอาจรวมถึงข้อมูลสำคัญ เช่น แผนผัง โครงการ และรายละเอียดงานจากลูกค้ารายใหญ่หลายบริษัท ไม่ว่าจะเป็น Dell, Google, Apple และ Nvidia

อย่างไรก็ตาม ขณะนี้ยังไม่มีการยืนยันอย่างเป็นทางการว่าข้อมูลที่เกี่ยวข้องกับ Apple หรือโปรเจกต์ในอนาคตของ Apple ถูกขโมยไปจริงหรือไม่

โรงงาน Foxconn ในสหรัฐฯ อาจได้รับผลกระทบ

แม้รายงานของ WIRED จะไม่ได้ระบุชื่อโรงงานโดยตรง แต่มีรายงานเพิ่มเติมจาก The Cybersec Guru และ AppleInsider ว่า หนึ่งในโรงงานที่อาจได้รับผลกระทบคือโรงงานของ Foxconn ในเมือง Mount Pleasant รัฐวิสคอนซิน ประเทศสหรัฐอเมริกา

มีรายงานว่าปัญหาเริ่มชัดเจนขึ้นเมื่อระบบเครือข่ายภายในโรงงานเกิดการล่ม ทั้ง Wi-Fi ระบบโครงสร้างพื้นฐาน และระบบลงเวลาทำงานของพนักงาน ส่งผลให้บางส่วนต้องกลับมาใช้วิธีบันทึกเวลาด้วยกระดาษชั่วคราว

นอกจากนี้ AppleInsider ยังระบุว่าโรงงานของ Foxconn ในเมือง Houston รัฐเท็กซัส อาจได้รับผลกระทบจากเหตุการณ์ครั้งนี้ด้วยเช่นกัน

ข้อมูลที่ถูกปล่อยตัวอย่างยังไม่พบไฟล์เกี่ยวกับ Apple โดยตรง

หนึ่งในประเด็นที่หลายคนจับตามองคือ ข้อมูลที่กลุ่มแรนซัมแวร์อ้างว่าขโมยไปนั้น มีข้อมูลเกี่ยวกับ Apple หรือผลิตภัณฑ์ในอนาคตของ Apple รวมอยู่ด้วยหรือไม่

จากข้อมูลที่มีรายงานในขณะนี้ ระบุว่ากลุ่ม Nitrogen ได้เผยแพร่ตัวอย่างไฟล์บางส่วนที่อ้างว่านำมาจาก Foxconn แต่ยังไม่พบหลักฐานชัดเจนว่ามีไฟล์ที่เกี่ยวข้องกับ Apple โดยตรง

เหตุผลหนึ่งที่อาจทำให้ยังไม่พบข้อมูลของ Apple คือโรงงาน Mount Pleasant ของ Foxconn นั้นมีรายงานว่าเน้นผลิตสินค้าอย่างโทรทัศน์และเซิร์ฟเวอร์ข้อมูล มากกว่าจะเป็นสายการผลิต iPhone หรืออุปกรณ์หลักของ Apple

Foxconn เคยถูกโจมตีด้วยแรนซัมแวร์มาแล้วหลายครั้ง

เหตุการณ์ครั้งนี้ไม่ใช่ครั้งแรกที่ Foxconn ตกเป็นเป้าของการโจมตีทางไซเบอร์ เพราะในช่วงหลายปีที่ผ่านมา บริษัทเคยเผชิญเหตุลักษณะเดียวกันมาแล้วหลายครั้ง

ตัวอย่างเหตุการณ์สำคัญที่เคยเกิดขึ้น ได้แก่

• ปี 2020 โรงงาน Foxconn ในเมือง Ciudad Juárez ประเทศเม็กซิโก ถูกโจมตีด้วยแรนซัมแวร์ โดยมีการเข้ารหัสเซิร์ฟเวอร์และขโมยข้อมูล พร้อมเรียกค่าไถ่เป็น Bitcoin มูลค่าประมาณ 34.6 ล้านดอลลาร์ในขณะนั้น
• ปี 2022 กลุ่ม LockBit เคยโจมตีโรงงาน Foxconn อีกแห่งในเม็กซิโก และส่งผลกระทบต่อการผลิต
• ปี 2024 บริษัทลูกของ Foxconn อย่าง Foxsemicon Integrated Technology ถูก LockBit อ้างว่าโจมตี พร้อมมีการเปลี่ยนหน้าเว็บไซต์และกล่าวอ้างเรื่องข้อมูลรั่วไหล

เหตุการณ์เหล่านี้สะท้อนให้เห็นว่า Foxconn เป็นหนึ่งในเป้าหมายสำคัญของกลุ่มแฮกเกอร์และแรนซัมแวร์ เนื่องจากบริษัทมีบทบาทสำคัญในซัพพลายเชนของอุตสาหกรรมเทคโนโลยีระดับโลก

ทำไมการโจมตี Foxconn ถึงน่าจับตา

Foxconn เป็นผู้ผลิตอุปกรณ์อิเล็กทรอนิกส์รายใหญ่ที่ทำงานร่วมกับแบรนด์เทคโนโลยีชั้นนำหลายราย การถูกโจมตีทางไซเบอร์จึงไม่ได้กระทบเฉพาะระบบภายในบริษัทเท่านั้น แต่อาจส่งผลต่อซัพพลายเชน ข้อมูลลูกค้า และความเชื่อมั่นของคู่ค้าทั่วโลก

ประเด็นที่ควรจับตาจากเหตุการณ์นี้ ได้แก่

• ขอบเขตข้อมูลที่กลุ่ม Nitrogen อ้างว่าขโมยไปจริง
• มีข้อมูลของลูกค้ารายใหญ่ เช่น Apple, Dell, Google หรือ Nvidia รวมอยู่หรือไม่
• ผลกระทบต่อการผลิตในโรงงานอเมริกาเหนือ
• มาตรการรักษาความปลอดภัยไซเบอร์ของ Foxconn หลังเกิดเหตุ
• ความเป็นไปได้ที่ข้อมูลตัวอย่างเพิ่มเติมจะถูกปล่อยออกมาในอนาคต

Foxconn ระบุโรงงานกำลังกลับมาผลิตตามปกติ

ในตอนนี้ Foxconn ยังไม่ได้ยืนยันรายละเอียดเชิงลึกเกี่ยวกับข้อมูลที่ถูกโจมตี หรือจำนวนโรงงานที่ได้รับผลกระทบอย่างชัดเจน แต่บริษัทระบุว่าโรงงานที่เกี่ยวข้องกำลังกลับมาดำเนินการผลิตตามปกติ

อย่างไรก็ตาม เหตุการณ์นี้ยังต้องติดตามต่อไป เพราะหากข้อมูลที่ถูกขโมยมีความเกี่ยวข้องกับลูกค้ารายใหญ่จริง อาจกลายเป็นประเด็นสำคัญในวงการเทคโนโลยีและความปลอดภัยไซเบอร์อีกครั้ง

สรุป

Foxconn ถูกจับตาอีกครั้งหลังมีรายงานว่าโรงงานบางแห่งในอเมริกาเหนือถูกโจมตีทางไซเบอร์ โดยกลุ่มแรนซัมแวร์ Nitrogen อ้างว่าสามารถขโมยข้อมูลได้มากถึง 8TB แม้ขณะนี้ยังไม่มีหลักฐานชัดเจนว่าข้อมูลของ Apple ถูกขโมยไปโดยตรง แต่เหตุการณ์นี้ถือเป็นอีกหนึ่งสัญญาณเตือนสำคัญของอุตสาหกรรมเทคโนโลยี ที่ต้องให้ความสำคัญกับความปลอดภัยไซเบอร์มากขึ้น โดยเฉพาะบริษัทที่เป็นส่วนหนึ่งของซัพพลายเชนระดับโลก

ที่มา 9to5mac

Mochi Cat

The post Foxconn ถูกโจมตีไซเบอร์อีกครั้ง กลุ่มแรนซัมแวร์ Nitrogen อ้างขโมยข้อมูล 8TB จากโรงงานในอเมริกาเหนือ appeared first on SiamByte.