การโจมตีรูปแบบนี้เรียกว่า 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

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

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

ข้อมูลที่เผยแพร่ผ่าน Digital Chat Station บนแพลตฟอร์ม Weibo ระบุว่า Xiaomi 18 Pro จะมาพร้อมการอัปเกรดหลายด้าน ทั้งหน้าจอ กล้อง ระบบเสียง มอเตอร์สั่น แบตเตอรี่ และระบบชาร์จ โดยเฉพาะกล้องหลักและกล้องซูมที่อาจใช้เซนเซอร์ความละเอียดสูงถึง 200 ล้านพิกเซลทั้งสองตัว

Xiaomi 18 Pro จะใช้ชิป Snapdragon 8 Elite Gen 6 Pro

Xiaomi 18 Pro จะใช้ชิป Snapdragon 8 Elite Gen 6 Pro ซึ่งเป็นชิปประมวลผลระดับเรือธงรุ่นใหม่ของ Qualcomm ขณะที่ Xiaomi 18 รุ่นมาตรฐานอาจใช้ Snapdragon 8 Elite Gen 6 รุ่นปกติ

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

หน้าจอแบนขนาดกะทัดรัด ขอบบางเท่ากันทุกด้าน

Xiaomi 18 Pro จะมาพร้อมหน้าจอแบนขนาดไม่ใหญ่มาก โดยเน้นความคมชัดสูงและการออกแบบมุมหน้าจอให้มีความโค้งมนขนาดใหญ่

รายละเอียดหน้าจอที่มีการเปิดเผยประกอบด้วย

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

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

กล้องหลัก 200MP พร้อมเซนเซอร์ขนาดใหญ่

หนึ่งในจุดเด่นสำคัญของ Xiaomi 18 Pro คือระบบกล้องหลัง โดยมีรายงานว่ากล้องหลักจะใช้เซนเซอร์ความละเอียด 200 ล้านพิกเซล พร้อมเซนเซอร์รับภาพขนาดใหญ่

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

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

กล้อง Telephoto Macro ความละเอียด 200MP

นอกจากกล้องหลักแล้ว Xiaomi 18 Pro จะมาพร้อมกล้อง Telephoto Macro ความละเอียด 200 ล้านพิกเซล โดยจะใช้เซนเซอร์ขนาดใหญ่เช่นเดียวกัน

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

จุดเด่นของระบบกล้องที่มีการเปิดเผย ได้แก่

• กล้องหลักความละเอียด 200 ล้านพิกเซล
• กล้อง Telephoto Macro ความละเอียด 200 ล้านพิกเซล
• ใช้เซนเซอร์รับภาพขนาดใหญ่
• รองรับการซูมและการถ่ายภาพระยะใกล้
• เน้นคุณภาพของภาพถ่ายในหลายระยะ

หาก Xiaomi นำกล้องความละเอียด 200 ล้านพิกเซลมาใช้ทั้งกล้องหลักและกล้องซูมจริง Xiaomi 18 Pro จะเป็นสมาร์ตโฟนที่โดดเด่นด้านการถ่ายภาพมากกว่ารุ่นก่อนอย่างชัดเจน

แบตเตอรี่ไม่น้อยกว่า 7,000mAh

Xiaomi 18 Pro จะมาพร้อมแบตเตอรี่ที่มีความจุไม่น้อยกว่า 7,000mAh ซึ่งถือว่าเป็นขนาดที่ค่อนข้างใหญ่สำหรับสมาร์ตโฟนเรือธงที่เน้นตัวเครื่องขนาดกะทัดรัด

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

รองรับชาร์จเร็ว 100W และชาร์จไร้สาย

ด้านระบบชาร์จ Xiaomi 18 Pro จะรองรับการชาร์จแบบมีสายกำลังไฟ 100W พร้อมรองรับระบบชาร์จแบบไร้สาย

ข้อมูลที่มีการเปิดเผยเกี่ยวกับระบบพลังงานประกอบด้วย

• แบตเตอรี่ความจุไม่น้อยกว่า 7,000mAh
• รองรับชาร์จเร็วแบบมีสาย 100W
• รองรับการชาร์จแบบไร้สาย
• ระบบจัดการพลังงานทำงานร่วมกับชิป Snapdragon รุ่นใหม่

ยังไม่มีข้อมูลเกี่ยวกับกำลังไฟสูงสุดของระบบชาร์จไร้สาย รวมถึงระยะเวลาที่ใช้ในการชาร์จแบตเตอรี่จากระดับต่ำจนเต็ม

อัปเกรดลำโพงคู่และมอเตอร์สั่น

Xiaomi จะทำการปรับปรุงระบบลำโพงคู่ของ Xiaomi 18 Pro เพื่อเพิ่มคุณภาพเสียงสำหรับการดูภาพยนตร์ เล่นเกม ฟังเพลง และสนทนาผ่านลำโพง

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

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

Xiaomi 18 Pro อาจมาพร้อม Android 17

Xiaomi 18 Pro มีโอกาสเปิดตัวพร้อมระบบปฏิบัติการ Android 17 และครอบทับด้วยระบบของ Xiaomi รุ่นใหม่ แต่ในขณะนี้ยังไม่มีข้อมูลยืนยันเกี่ยวกับเวอร์ชันซอฟต์แวร์อย่างเป็นทางการ

รายละเอียดด้านซอฟต์แวร์ที่ยังต้องติดตามประกอบด้วย ระยะเวลาการอัปเดต Android จำนวนปีของแพตช์ความปลอดภัย ฟีเจอร์ AI และความสามารถใหม่ภายในระบบของ Xiaomi

กำหนดเปิดตัว Xiaomi 18 Pro

Xiaomi วางแผนเปิดตัวสมาร์ตโฟนตระกูล Xiaomi 18 ในเดือนกันยายน โดยจะประกอบด้วยอย่างน้อย 3 รุ่น ได้แก่

• Xiaomi 18
• Xiaomi 18 Pro
• Xiaomi 18 Pro Max

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

สรุปสเปกสำคัญ Xiaomi 18 Pro

Xiaomi 18 Pro จะเป็นสมาร์ตโฟนเรือธงที่เน้นทั้งประสิทธิภาพ กล้องถ่ายภาพ และแบตเตอรี่ โดยรายละเอียดสำคัญที่มีการเปิดเผยในขณะนี้ ได้แก่

• ชิป Snapdragon 8 Elite Gen 6 Pro
• หน้าจอแบนขนาดกะทัดรัด
• ขอบหน้าจอบางและสมมาตรทั้งสี่ด้าน
• กล้องหลักความละเอียด 200 ล้านพิกเซล
• กล้อง Telephoto Macro ความละเอียด 200 ล้านพิกเซล
• แบตเตอรี่ไม่น้อยกว่า 7,000mAh
• ชาร์จเร็วแบบมีสาย 100W
• รองรับการชาร์จแบบไร้สาย
• ลำโพงคู่ได้รับการปรับปรุง
• มอเตอร์สั่นขนาดใหญ่ขึ้น
• วางแผนเปิดตัวในเดือนกันยายน

สรุป

Xiaomi 18 Pro จะเป็นอีกหนึ่งสมาร์ตโฟนเรือธงที่น่าจับตามอง โดยเฉพาะการใช้กล้องหลักและกล้อง Telephoto Macro ความละเอียด 200 ล้านพิกเซล พร้อมแบตเตอรี่ขนาดไม่น้อยกว่า 7,000mAh และชาร์จเร็ว 100W

นอกจากนี้ ชิป Snapdragon 8 Elite Gen 6 Pro หน้าจอขอบบาง และการปรับปรุงระบบเสียงกับมอเตอร์สั่น จะช่วยยกระดับประสบการณ์ใช้งานโดยรวม อย่างไรก็ตาม รายละเอียดทั้งหมดในขณะนี้ยังไม่ได้รับการประกาศจาก Xiaomi โดยตรง จึงต้องติดตามข้อมูลเพิ่มเติมเมื่อใกล้ถึงกำหนดเปิดตัวในเดือนกันยายน

The post Xiaomi 18 Pro วางแผนเปิดตัวเดือนกันยายน พร้อมกล้องคู่ 200MP และแบตเตอรี่ 7,000mAh appeared first on SiamByte.

ชิป Samsung Gaia จะเน้นการประมวลผล AI ภายในอุปกรณ์ หรือ Edge AI เพื่อช่วยลดการพึ่งพาระบบคลาวด์ พร้อมเพิ่มความรวดเร็ว ความเป็นส่วนตัว และประสิทธิภาพด้านการใช้พลังงาน

Samsung Gaia คือชิป AI สำหรับพีซีรุ่นใหม่

Gaia เป็นชิป AI Accelerator ที่ Samsung จะทำขึ้นสำหรับรองรับงานประมวลผลปัญญาประดิษฐ์บนคอมพิวเตอร์ส่วนบุคคล โดยภายในจะใช้สถาปัตยกรรมหน่วยประมวลผล NPU ที่ได้รับการปรับแต่งให้เหมาะกับงาน AI มากขึ้น

NPU หรือ Neural Processing Unit เป็นหน่วยประมวลผลที่ออกแบบมาเพื่อจัดการงานด้าน Machine Learning และ AI โดยเฉพาะ เช่น การสร้างข้อความ การประมวลผลภาพ การแปลภาษา การตัดเสียงรบกวน และการใช้งานผู้ช่วย AI บนพีซี

จุดเด่นเบื้องต้นของชิป Samsung Gaia ประกอบด้วย

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

Samsung ส่งชิปต้นแบบให้ลูกค้ารายใหญ่ทดสอบแล้ว

มีรายงานว่า Samsung ได้ส่งชิป Gaia รุ่นต้นแบบให้กับลูกค้ารายใหญ่บางรายเพื่อนำไปทดสอบแล้ว แต่ยังไม่มีการเปิดเผยรายชื่อบริษัทหรือผู้ผลิตอุปกรณ์ที่ได้รับชิปต้นแบบดังกล่าว

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

Samsung วางแผนเริ่มผลิตชิป Gaia ในปริมาณมากภายในปีหน้า หากการทดสอบและกระบวนการพัฒนาเป็นไปตามแผนที่กำหนด

ชิป Gaia จะรองรับงาน Edge AI บนพีซี

หนึ่งในเป้าหมายหลักของ Samsung Gaia คือการรองรับ PC Edge AI ซึ่งหมายถึงการประมวลผลข้อมูล AI ภายในเครื่องโดยตรง แทนการส่งข้อมูลทั้งหมดไปยังเซิร์ฟเวอร์ภายนอก

การประมวลผล AI ภายในพีซีมีข้อดีหลายด้าน ได้แก่

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

ชิป Gaia จึงอาจถูกนำมาใช้งานร่วมกับฟีเจอร์ AI บนระบบปฏิบัติการ โปรแกรมสำนักงาน เครื่องมือสร้างคอนเทนต์ และซอฟต์แวร์ประชุมออนไลน์

Samsung Gaia จะเน้นประสิทธิภาพต่อพลังงาน

รายงานระบุว่า Samsung จะออกแบบชิป Gaia ให้มีประสิทธิภาพต่อการใช้พลังงานในระดับสูง ซึ่งเป็นปัจจัยสำคัญสำหรับพีซีและโน้ตบุ๊กรุ่นใหม่ที่ต้องทำงานด้าน AI อย่างต่อเนื่อง

การใช้ NPU แยกสำหรับประมวลผลงาน AI จะช่วยลดภาระของ CPU และ GPU ทำให้ระบบสามารถเลือกใช้หน่วยประมวลผลที่เหมาะสมกับลักษณะงานได้มากขึ้น

ตัวอย่างงานที่สามารถส่งไปประมวลผลด้วย NPU ได้แก่

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

Gaia จะรองรับตลาด Physical AI และหุ่นยนต์

นอกจากการใช้งานบนพีซีแล้ว Samsung ยังวางแผนให้ Gaia รองรับตลาด Physical AI ซึ่งเป็นการนำ AI ไปใช้งานร่วมกับอุปกรณ์ที่สามารถรับรู้และตอบสนองต่อสภาพแวดล้อมจริงได้

อุปกรณ์ในกลุ่ม Physical AI อาจครอบคลุมถึง

• หุ่นยนต์ภายในบ้าน
• หุ่นยนต์อุตสาหกรรม
• อุปกรณ์อัตโนมัติในโรงงาน
• กล้องและระบบตรวจจับอัจฉริยะ
• อุปกรณ์ Edge Computing
• ระบบควบคุมเครื่องจักรด้วย AI

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

Samsung เตรียมแข่งขันในตลาดชิป AI สำหรับพีซี

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

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

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

สรุป Samsung Gaia ชิป AI สำหรับพีซี

Samsung วางแผนพัฒนาชิป AI Accelerator สำหรับพีซีภายใต้ชื่อรหัส Gaia โดยจะใช้กระบวนการผลิตขนาด 4 นาโนเมตร พร้อมสถาปัตยกรรม NPU ที่ออกแบบมาเพื่อรองรับการประมวลผล Edge AI อย่างมีประสิทธิภาพ

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

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

ที่มา gsmarena

The post Samsung วางแผนพัฒนาชิป AI สำหรับพีซี Gaia บนกระบวนการผลิต 4 นาโนเมตร appeared first on SiamByte.

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

GigaWiper และ BLUERABBIT อาจเป็นมัลแวร์ตัวเดียวกัน

Microsoft ระบุค่าแฮชของไฟล์ GigaWiper จำนวน 4 รายการ ซึ่งตรงกับค่าแฮชที่บริษัท Binary Defense เปิดเผยในรายงานเกี่ยวกับมัลแวร์ชื่อ BLUERABBIT นอกจากนี้ ทั้งสองรายงานยังพบว่าเซิร์ฟเวอร์ควบคุมและสั่งการของมัลแวร์มีความตรงกัน

Binary Defense อ้างอิงข้อมูลจาก Google Threat Intelligence Group และเชื่อมโยงมัลแวร์ดังกล่าวกับกลุ่มผู้โจมตีที่มีความเกี่ยวข้องกับอิหร่าน โดยมีเป้าหมายหลักเป็นองค์กรในอิสราเอล ขณะที่ Microsoft ไม่ได้ระบุชื่อประเทศหรือกลุ่มผู้โจมตีอย่างชัดเจน

GigaWiper มีคำสั่งทำลายข้อมูล 3 รูปแบบ

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

1. ล้างข้อมูลทั้งฮาร์ดดิสก์

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

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

2. แรนซัมแวร์ปลอมที่ไม่สามารถถอดรหัสได้

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

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

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

3. เขียนทับไดรฟ์ Windows หลายรอบ

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

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

GigaWiper ไม่ได้มีหน้าที่ทำลายข้อมูลเพียงอย่างเดียว

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

ความสามารถที่ Microsoft ตรวจพบประกอบด้วย

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

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

ปลอมตัวเป็นกระบวนการอัปเดต OneDrive

เพื่อให้ทำงานอยู่ในระบบได้นาน GigaWiper จะพยายามปลอมตัวเป็นส่วนประกอบของ Microsoft OneDrive

มัลแวร์จะสร้าง Scheduled Task ชื่อ OneDrive Update และตั้งค่าให้ทำงานทุกหนึ่งนาที พร้อมบันทึกข้อมูลการทำงานไว้ใน Registry ภายใต้ตำแหน่งดังนี้

HKCU\SOFTWARE\OneDrive\Environment

เมื่อเปิดช่องทางควบคุมเครื่องจากระยะไกล มัลแวร์ยังสร้างกฎใน Windows Firewall โดยใช้ชื่อ Microsoft.Windows.CloudExperienceHost ซึ่งคล้ายกับชื่อส่วนประกอบจริงของ Windows เพื่อหลีกเลี่ยงการตรวจสอบจากผู้ดูแลระบบ

ใช้บริการธุรกิจจริงเพื่อซ่อนการสื่อสาร

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

บริการที่ตรวจพบประกอบด้วย

• RabbitMQ สำหรับส่งคำสั่งไปยังเครื่องที่ติดเชื้อ
• Redis สำหรับส่งผลลัพธ์กลับไปยังผู้ควบคุม
• MinIO สำหรับส่งข้อมูลที่ขโมยออกจากระบบ

การใช้บริการเหล่านี้ช่วยให้การรับส่งข้อมูลของมัลแวร์ดูคล้ายทราฟฟิกของระบบธุรกิจทั่วไป โดยเฉพาะในองค์กรที่มีการใช้งาน RabbitMQ, Redis หรือ MinIO อยู่แล้ว

จุดเชื่อมโยงกับ Crucio และ FlockWiper

Microsoft ตรวจสอบโค้ดภายใน GigaWiper และพบว่าส่วนแรนซัมแวร์ปลอมมีพื้นฐานมาจาก Crucio ขณะที่ส่วนล้างข้อมูลหลายรอบเชื่อมโยงกับ FlockWiper

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

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

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

Microsoft ยังพบข้อความ GRAT ปรากฏซ้ำในเส้นทาง Debug ของ FlockWiper และชื่อฟังก์ชันภายใน GigaWiper ซึ่งช่วยสนับสนุนความเชื่อมโยงระหว่างเครื่องมือทั้งสอง

GigaWiper เป็นส่วนหนึ่งของการโจมตีด้วยมัลแวร์ล้างข้อมูล

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

Palo Alto Networks Unit 42 เคยติดตามกิจกรรมลักษณะใกล้เคียงกันจากกลุ่ม Handala Hack ขณะที่สำนักงานไซเบอร์แห่งชาติของอิสราเอลเคยออกคำเตือนเกี่ยวกับการโจมตีด้วยมัลแวร์ล้างข้อมูลในเดือนมีนาคม 2026

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

สัญญาณที่อาจใช้ตรวจจับ GigaWiper

ผู้ดูแลระบบและทีมรักษาความปลอดภัยสามารถตรวจสอบความผิดปกติที่เกี่ยวข้องกับ GigaWiper ได้จากหลายสัญญาณ

• มี Scheduled Task ชื่อ OneDrive Update และทำงานทุกหนึ่งนาที
• พบทราฟฟิก RabbitMQ หรือ Redis จากคอมพิวเตอร์ผู้ใช้งานทั่วไป
• มีการเรียกใช้คำสั่ง takeown หรือ icacls กับไฟล์ระบบ Windows
• มีความพยายามแก้ไขไฟล์สำคัญ เช่น bootmgr หรือ ntoskrnl.exe
• พบการสร้างกฎ Firewall ชื่อ Microsoft.Windows.CloudExperienceHost
• มีการลบ Windows Event Logs โดยไม่มีเหตุผลด้านการบำรุงรักษา
• พบการเชื่อมต่อไปยังเซิร์ฟเวอร์ควบคุมที่ Microsoft เปิดเผย

แนวทางป้องกัน GigaWiper

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

แนวทางสำคัญประกอบด้วย

• เปิดใช้งาน Tamper Protection เพื่อป้องกันการปิดระบบแอนติไวรัส
• ใช้ Endpoint Detection and Response ในโหมดบล็อก
• เปิด Cloud-delivered Protection
• เปิดระบบตรวจสอบและแก้ไขภัยคุกคามอัตโนมัติ
• จำกัดสิทธิ์ของบัญชีผู้ใช้งานและบัญชีผู้ดูแลระบบ
• ตรวจสอบ Scheduled Task ที่ถูกสร้างขึ้นใหม่
• ควบคุมการใช้งาน RabbitMQ, Redis และ MinIO จากเครื่องปลายทาง
• แยกเครือข่ายระหว่างเครื่องผู้ใช้งานและระบบเซิร์ฟเวอร์
• จัดเก็บข้อมูลสำรองแบบออฟไลน์หรือแบบแก้ไขย้อนหลังไม่ได้
• ทดสอบกระบวนการกู้คืนข้อมูลเป็นประจำ

Microsoft ยังแนะนำให้บล็อกหมายเลขไอพีของเซิร์ฟเวอร์ควบคุมที่ตรวจพบ ได้แก่

• 185.182.193[.]21
• 212.8.248[.]104

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

การสำรองข้อมูลแบบออฟไลน์ยังเป็นแนวป้องกันที่สำคัญ

เนื่องจาก GigaWiper สามารถทำลายข้อมูลในระดับดิสก์และเข้ารหัสไฟล์โดยไม่เก็บกุญแจถอดรหัส การกู้คืนข้อมูลจากเครื่องที่ถูกโจมตีจึงทำได้ยากมาก

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

ข้อมูลสำรองที่เหมาะสมควรมีคุณสมบัติดังนี้

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

สรุป

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

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

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

ที่มา thehackernews

The post Microsoft เปิดรายละเอียด GigaWiper มัลแวร์ทำลายข้อมูล Windows พร้อมความสามารถสอดแนมและควบคุมเครื่อง 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

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

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

ล่าสุดมีรายงานจาก Digital Chat Station แหล่งข่าวด้านเทคโนโลยีจากประเทศจีน ระบุว่า Honor วางแผนเปิดตัว Robot Phone อย่างเป็นทางการในเดือนสิงหาคม ซึ่งทำให้ช่วงเวลาการเปิดตัวมีความชัดเจนมากขึ้น แม้ Honor ยังไม่ได้ประกาศวันจัดงานหรือกำหนดการวางจำหน่ายอย่างเป็นทางการ

Honor Robot Phone วางแผนเปิดตัวเดือนสิงหาคม

ก่อนหน้านี้ Honor ยืนยันว่า Robot Phone จะเปิดตัวภายในไตรมาส 3 ของปี แต่ยังไม่ได้เปิดเผยว่าอุปกรณ์รุ่นนี้จะเปิดตัวในเดือนใด

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

อย่างไรก็ตาม รายละเอียดเกี่ยวกับราคา ประเทศที่วางจำหน่าย และรุ่นย่อยของตัวเครื่องยังไม่ได้รับการเปิดเผยจาก Honor

จากสมาร์ตโฟนต้นแบบสู่ผลิตภัณฑ์ที่วางจำหน่ายจริง

Honor Robot Phone เคยถูกนำมาแสดงต่อสาธารณชนในงาน CES ช่วงเดือนมกราคม ก่อนจะถูกนำไปจัดแสดงอีกครั้งในงาน MWC ที่เมืองบาร์เซโลนาในช่วงต้นเดือนมีนาคม

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

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

จุดเด่นของ Honor Robot Phone

Honor Robot Phone แตกต่างจากสมาร์ตโฟนทั่วไปด้วยระบบกล้องที่สามารถยื่นออกมาจากตัวเครื่องและเคลื่อนไหวได้อย่างอิสระ โดยมีแนวคิดการทำงานคล้ายกับกล้องขนาดเล็กอย่าง DJI Osmo Pocket และ Insta360 Luna

จุดเด่นที่มีรายงานออกมา ได้แก่

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

กล้องกิมบอลพับเก็บได้ทำงานอย่างไร

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

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

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

Honor Robot Phone จะเหมาะกับใคร

ด้วยรูปแบบกล้องที่แตกต่างจากโทรศัพท์ทั่วไป Honor Robot Phone จะเหมาะกับผู้ใช้งานหลายกลุ่ม เช่น

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

ข้อมูลที่ Honor ยังไม่ได้เปิดเผย

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

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

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

สรุป Honor Robot Phone

Honor Robot Phone เป็นสมาร์ตโฟนแนวคิดใหม่ที่วางแผนมาพร้อมกล้องกิมบอลแบบพับเก็บในตัว รองรับระบบกันสั่นและการติดตามวัตถุอัตโนมัติ โดยมีแนวทางการใช้งานคล้ายกับกล้อง DJI Osmo Pocket และ Insta360 Luna

รายงานล่าสุดระบุว่า Honor จะทำการเปิดตัวอุปกรณ์รุ่นนี้ในเดือนสิงหาคม หลังจากเคยนำต้นแบบไปแสดงในงาน CES และ MWC รวมถึงทดลองใช้ถ่ายวิดีโอในงาน Shanghai International Film Festival

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

The post Honor Robot Phone วางแผนเปิดตัวเดือนสิงหาคม พร้อมกล้องกิมบอลพับเก็บในตัว appeared first on SiamByte.

นักวิจัยด้านความปลอดภัยจาก Zimperium zLabs ระบุว่า RedWing มีลักษณะคล้ายกับ Oblivion ซึ่งเป็นบริการมัลแวร์ให้เช่าที่เคยถูกเปิดเผยก่อนหน้านี้ โดย Oblivion มีค่าใช้งานประมาณ 300 ดอลลาร์ต่อเดือน

RedWing คืออะไร

RedWing เป็นมัลแวร์ Android ที่ถูกพัฒนาในรูปแบบ Malware-as-a-Service หรือบริการมัลแวร์ให้เช่า ผู้ให้บริการจะจัดเตรียมระบบสำหรับสร้างแอปอันตราย แผงควบคุม คู่มือการใช้งาน วิดีโอสอน และระบบส่วนลดสำหรับสมาชิกที่แนะนำผู้ใช้งานรายใหม่

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

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

RedWing แพร่กระจายเข้าสู่โทรศัพท์ Android อย่างไร

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

ระบบสร้างมัลแวร์สามารถเลียนแบบร้านค้าแอปหลายแห่ง ได้แก่

• Google Play Store
• Samsung Galaxy Store
• Huawei AppGallery
• RuStore
• หน้าเว็บไซต์ดาวน์โหลดแอปที่ออกแบบขึ้นใหม่ทั้งหมด

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

มัลแวร์หลอกขอสิทธิ์ควบคุมเครื่องทีละขั้นตอน

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

สิทธิ์สำคัญที่มัลแวร์จะพยายามขอ ได้แก่

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

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

ความสามารถของมัลแวร์ RedWing

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

สร้างหน้าล็อกอินธนาคารปลอม

RedWing สามารถแสดงหน้าล็อกอินปลอมซ้อนทับบนแอปธนาคารหรือแอปกระเป๋าคริปโตจริง เทคนิคนี้เรียกว่า Overlay Attack

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

ขโมยรหัส OTP และข้อมูลบนหน้าจอ

มัลแวร์สามารถอ่านข้อความ SMS ที่เข้ามาใหม่เพื่อดักจับรหัส OTP รวมถึงใช้ Accessibility Service อ่านข้อมูลที่ปรากฏบนหน้าจอ เช่น

• รหัสยืนยันการทำธุรกรรม
• หมายเลขบัตรธนาคาร
• รหัส PIN
• รหัสผ่าน
• ข้อมูลบัญชี
• ข้อความแจ้งเตือนจากธนาคาร

เปิดระบบโอนสายไปยังผู้โจมตี

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

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

ถ่ายทอดสดหน้าจอและบันทึกการพิมพ์

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

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

ควบคุมกล้องและไมโครโฟน

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

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

ใช้เครื่องที่ติดมัลแวร์โจมตีเว็บไซต์

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

ผู้ซื้อสามารถเลือกแอปเป้าหมายได้เอง

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

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

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

พบเป้าหมายอย่างน้อย 82 สถาบัน

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

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

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

RedWing ใช้เทคนิค On-Device Fraud

RedWing สะท้อนแนวโน้มการโจมตี Android แบบ On-Device Fraud ซึ่งผู้โจมตีจะควบคุมโทรศัพท์ของเหยื่อและทำธุรกรรมจากอุปกรณ์เครื่องเดิมโดยตรง

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

มัลแวร์ Android กลุ่มอื่นที่ใช้แนวทางใกล้เคียงกัน ได้แก่

• Fantasy Hub บริการมัลแวร์ให้เช่าที่มุ่งเป้าไปยังผู้ใช้งานในรัสเซีย
• Albiriox มัลแวร์ที่รองรับการโจมตีแอปการเงินมากกว่า 400 แอป
• Klopatra มัลแวร์ที่ใช้ระบบควบคุมระยะไกลและหน้าล็อกอินปลอมเพื่อขโมยเงินจากบัญชี

RedWing ไม่จำเป็นต้องใช้ช่องโหว่ Android

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

ดังนั้นขั้นตอนการดาวน์โหลดและติดตั้งแอปจึงเป็นจุดสำคัญที่สุดในการป้องกันมัลแวร์ประเภทนี้

วิธีป้องกันมัลแวร์ RedWing บน Android

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

• ดาวน์โหลดแอปจาก Store อย่างเป็นทางการเท่านั้น
• หลีกเลี่ยงการติดตั้งไฟล์ APK ที่ได้รับผ่านข้อความ แชต หรืออีเมล
• ระวังลิงก์ที่อ้างว่าเป็นการอัปเดตแอปธนาคารหรือแอประบบ
• ไม่เปิดสิทธิ์ติดตั้งแอปจากแหล่งที่ไม่รู้จักโดยไม่มีเหตุผล
• ไม่เปิด Accessibility Service ให้กับแอปที่ไม่จำเป็นต้องใช้
• ไม่ตั้งแอปทั่วไปเป็นโปรแกรมรับส่ง SMS เริ่มต้น
• ตรวจสอบเหตุผลก่อนอนุญาตให้แอปทำงานแบบไม่จำกัดแบตเตอรี่
• ตรวจสอบแอปที่ซ่อนไอคอนหลังติดตั้ง
• เปิดใช้งาน Google Play Protect
• อัปเดตระบบ Android และแอปให้เป็นเวอร์ชันล่าสุด
• ติดต่อธนาคารทันทีเมื่อพบธุรกรรมหรือการโอนสายผิดปกติ

แนวทางป้องกันสำหรับองค์กร

องค์กรที่ดูแลโทรศัพท์ Android ของพนักงานสามารถบังคับใช้นโยบายความปลอดภัยจากส่วนกลางได้ เช่น

• ปิดการติดตั้งแอปจากภายนอก Store
• บล็อกไฟล์ APK ที่ไม่ได้รับอนุญาต
• แจ้งเตือนเมื่อแอปร้องขอสิทธิ์ Accessibility
• ตรวจจับแอปที่พยายามเป็นโปรแกรม SMS เริ่มต้น
• จำกัดสิทธิ์กล้อง ไมโครโฟน และตำแหน่ง
• ตรวจสอบพฤติกรรมการซ่อนไอคอนแอป
• เฝ้าระวังการเปิดระบบโอนสายโดยไม่ได้รับอนุญาต
• ใช้ระบบ Mobile Device Management หรือ Mobile Threat Defense

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

ชื่อแอปไม่ใช่ตัวบ่งชี้ที่เพียงพอ

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

การตรวจสอบเฉพาะชื่อแอปจึงอาจไม่เพียงพอ สิ่งที่ควรเฝ้าระวังคือพฤติกรรมของแอป เช่น การขอ Accessibility การขอเป็นแอป SMS เริ่มต้น การซ่อนไอคอน การปิดข้อจำกัดแบตเตอรี่ และการติดตั้งจากแหล่งภายนอก

สรุป

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

ความสามารถของ RedWing ครอบคลุมตั้งแต่การขโมยรหัสผ่านและ OTP การสร้างหน้าล็อกอินปลอม การบันทึกหน้าจอและการพิมพ์ ไปจนถึงการโอนสาย ควบคุมกล้อง ไมโครโฟน และทำธุรกรรมจากโทรศัพท์ของเหยื่อโดยตรง

การป้องกันที่สำคัญที่สุดคือไม่ติดตั้งแอปจากลิงก์หรือแหล่งที่ไม่รู้จัก และไม่อนุญาตสิทธิ์ Accessibility, SMS, กล้อง หรือไมโครโฟนให้กับแอปที่ไม่มีเหตุผลชัดเจนในการใช้งาน

ที่มา thehackernews

The post RedWing มัลแวร์ Android ให้เช่าผ่าน Telegram ขโมยข้อมูลธนาคารและรหัส OTP appeared first on SiamByte.

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

แบตเตอรี่ iPhone 18 Pro Max จะมีความจุสูงสุด 5,567mAh

ข้อมูลจากฐานข้อมูล 3C ซึ่งถูกเผยแพร่โดย Digital Chat Station ระบุรายละเอียดความจุแบตเตอรี่ของ iPhone 18 Pro Max จำนวนสองรุ่น ดังนี้

• iPhone 18 Pro Max รุ่น eSIM จะใช้แบตเตอรี่ความจุ 5,567mAh
• iPhone 18 Pro Max รุ่นมีช่องใส่ซิมการ์ดจะใช้แบตเตอรี่ความจุ 5,391mAh

ตัวเลขดังกล่าวแตกต่างจากข้อมูลก่อนหน้านี้ที่ระบุว่า รุ่น eSIM จะมีแบตเตอรี่ 5,425mAh ส่วนรุ่นที่รองรับซิมการ์ดแบบปกติจะมีแบตเตอรี่ 5,235mAh

ข้อมูลชุดใหม่จึงแสดงให้เห็นว่า Apple วางแผนเพิ่มความจุแบตเตอรี่ของ iPhone 18 Pro Max มากกว่าที่มีการเปิดเผยในช่วงแรก

เปรียบเทียบแบตเตอรี่ iPhone 18 Pro Max กับ iPhone 17 Pro Max

หากข้อมูลจากฐานข้อมูล 3C ถูกต้อง iPhone 18 Pro Max จะได้รับการเพิ่มความจุแบตเตอรี่จาก iPhone 17 Pro Max อย่างชัดเจน โดยแต่ละรุ่นจะมีรายละเอียดดังนี้

• รุ่น eSIM จะเพิ่มความจุแบตเตอรี่ประมาณ 479mAh
• รุ่นมีช่องใส่ซิมการ์ดจะเพิ่มความจุแบตเตอรี่ประมาณ 568mAh

การเพิ่มความจุในระดับนี้จะช่วยให้ iPhone 18 Pro Max สามารถใช้งานได้นานขึ้น โดยเฉพาะการถ่ายวิดีโอ เล่นเกม ใช้งานระบบปัญญาประดิษฐ์ และเชื่อมต่อเครือข่ายมือถือเป็นเวลานาน

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

ทำไม iPhone 18 Pro Max รุ่น eSIM จึงมีแบตเตอรี่ใหญ่กว่า

Apple วางแผนจำหน่าย iPhone รุ่นที่รองรับ eSIM เพียงอย่างเดียวในบางประเทศ โดยเฉพาะสหรัฐอเมริกา ขณะที่ประเทศอื่น รวมถึงประเทศจีน จะยังได้รับรุ่นที่มีช่องใส่ซิมการ์ดแบบปกติ

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

ความแตกต่างระหว่างแบตเตอรี่ทั้งสองรุ่นมีดังนี้

• รุ่น eSIM มีแบตเตอรี่ 5,567mAh
• รุ่นซิมการ์ดมีแบตเตอรี่ 5,391mAh
• รุ่น eSIM มีความจุมากกว่าประมาณ 176mAh

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

iPhone 18 Pro และ iPhone 18 Pro Max จะเน้นการใช้งานที่ยาวนานขึ้น

เอกสารจากฐานข้อมูล 3C ถูกเชื่อมโยงกับ iPhone 18 Pro และ iPhone 18 Pro Max แม้จะยังไม่มีการเปิดเผยชื่อรุ่นอย่างเป็นทางการจาก Apple แต่ข้อมูลความจุแบตเตอรี่แสดงให้เห็นว่าบริษัทวางแผนพัฒนาอายุการใช้งานแบตเตอรี่ให้เป็นหนึ่งในจุดเด่นของสมาร์ตโฟนรุ่นใหม่

iPhone 18 Pro Series จะได้รับการพัฒนาในหลายด้าน ได้แก่

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

หาก Apple สามารถเพิ่มแบตเตอรี่พร้อมลดการใช้พลังงานของชิปและหน้าจอได้สำเร็จ iPhone 18 Pro Max จะเป็นหนึ่งใน iPhone ที่มีระยะเวลาการใช้งานต่อการชาร์จโดดเด่นที่สุด

ข้อมูลแบตเตอรี่ยังไม่ได้รับการยืนยันจาก Apple

แม้รายละเอียดดังกล่าวจะมาจากฐานข้อมูลรับรองมาตรฐาน 3C ของประเทศจีน แต่ Apple ยังไม่ได้ประกาศข้อมูลเกี่ยวกับ iPhone 18 Pro และ iPhone 18 Pro Max อย่างเป็นทางการ

ตัวเลขความจุแบตเตอรี่อาจมีการเปลี่ยนแปลงก่อนเปิดตัวจริง รวมถึงอาจแตกต่างกันตามประเทศ รุ่นย่อย และระบบซิมที่รองรับ ผู้ที่สนใจจึงควรรอติดตามข้อมูลจาก Apple อีกครั้งในวันเปิดตัว

สรุปแบตเตอรี่ iPhone 18 Pro Max

ข้อมูลล่าสุดระบุว่า Apple วางแผนให้ iPhone 18 Pro Max รุ่น eSIM ใช้แบตเตอรี่ความจุ 5,567mAh ส่วนรุ่นที่มีช่องใส่ซิมการ์ดจะใช้แบตเตอรี่ 5,391mAh ซึ่งเพิ่มขึ้นจาก iPhone 17 Pro Max อย่างชัดเจน

การเพิ่มความจุแบตเตอรี่จะช่วยให้ iPhone 18 Pro Max รองรับการใช้งานหนักได้ยาวนานขึ้น โดยรุ่น eSIM จะมีแบตเตอรี่ใหญ่กว่าเล็กน้อย เนื่องจากไม่มีช่องใส่ซิมการ์ดอยู่ภายในตัวเครื่อง อย่างไรก็ตาม รายละเอียดทั้งหมดจะต้องรอการยืนยันจาก Apple เมื่อมีการเปิดตัวอย่างเป็นทางการ

The post แบตเตอรี่ iPhone 18 Pro Max อาจเพิ่มเป็น 5,567mAh แยกรุ่น eSIM และซิมการ์ด appeared first on SiamByte.