สรุปสั้น

ผู้โจมตีเริ่มใช้ห่วงโซ่ช่องโหว่ใน Plex Media Server ที่ถูกตั้งชื่อว่า Plex2Shell โจมตีจริงแล้ว เพียงวันเดียวหลังจากนาย Zach Main นักวิจัยที่ค้นพบ เผยแพร่รายละเอียดทางเทคนิคพร้อมโค้ดพิสูจน์แนวคิด (PoC) เมื่อวันที่ 16 ตุลาคม 2569 ห่วงโซ่นี้นำช่องโหว่ 4 รายการมาต่อกัน เริ่มจาก SSRF ที่ไม่ต้องยืนยันตัวตน ไปจนถึงการขโมยโทเคนผู้ดูแลของเจ้าของเซิร์ฟเวอร์ แล้วจบที่การวางไฟล์ไลบรารีอันตรายให้ตัวแปลงวิดีโอโหลดขึ้นมารัน ผลคือผู้โจมตีรันโค้ดบนเซิร์ฟเวอร์ได้จากระยะไกลโดยไม่ต้องมีบัญชีใด ๆ

นักวิจัยที่ใช้ชื่อ boredhackerblog ตรวจพบการโจมตีบน honeypot ตั้งแต่เช้าวันที่ 17 ตุลาคม ผู้โจมตีดาวน์โหลดไฟล์จากเซิร์ฟเวอร์ภายนอกมาติดตั้งตัวขุดคริปโต XMRig ชื่อ mylovelyminer และ backdoor พร็อกซีบนลินุกซ์ชื่อ myawesomeproxy ซึ่งเปลี่ยนเครื่องเหยื่อให้เป็นทางผ่านทราฟฟิกของคนอื่น โดเมนของพูลขุดคริปโตยังเชื่อมกับโดเมนที่บริษัท Bitsight เคยโยงกับบอตเน็ต DDoS และ proxyware ชื่อ AISURU ช่องโหว่ทั้งหมดถูกแก้แล้วตั้งแต่ Plex Media Server เวอร์ชัน 1.43.3.10861 ที่ออกเมื่อ 3 สิงหาคม 2569 เครื่องที่ยังไม่อัปเดตจึงเป็นเป้าหลัก

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 19 ตุลาคม 2569 ว่ากลุ่มผู้โจมตีเริ่มใช้ห่วงโซ่ช่องโหว่ Plex2Shell โจมตี Plex Media Server เพื่อติดตั้งตัวขุดคริปโตและซอฟต์แวร์ reverse proxy หลังจาก PoC เผยแพร่สู่สาธารณะเพียงวันเดียว นาย Main รายงานช่องโหว่ชุดนี้ให้ Plex ตั้งแต่วันที่ 27 กรกฎาคม 2569 Plex ยืนยันรับเรื่องและจ่ายรางวัล bug bounty ในวันที่ 4 สิงหาคม ได้รับเลข CVE ในวันที่ 23 กันยายน และนาย Main เปิดเผยรายละเอียดต่อสาธารณะในวันที่ 16 ตุลาคม นอกจาก 4 CVE ในห่วงโซ่แล้ว เขายังรายงาน CVE-2026-96651 (CVSS 7.1) อีกรายการหนึ่งในคราวเดียวกัน

ตามไทม์ไลน์ของ boredhackerblog Plex ส่งอีเมลแจ้งผู้ใช้เมื่อวันที่ 1 กันยายน 2569 ว่ามีอัปเดตความปลอดภัยสำหรับ Plex Media Server เวอร์ชัน 1.43.2 และก่อนหน้า แต่ไม่ให้รายละเอียด ต่อมาเมื่อ CVE เผยแพร่ในวันที่ 26 กันยายน ไม่มีรายการใดได้คะแนน CVSS ถึง 9 คะแนนสูงสุดคือ 8.6 ทำให้หลายฝ่ายอาจประเมินความเร่งด่วนต่ำกว่าความเป็นจริง เพราะเมื่อนำมาต่อกันจะได้ RCE แบบไม่ต้องยืนยันตัวตน The Hacker News ระบุว่ายังไม่ชัดว่าช่องโหว่ชุดนี้คือชุดเดียวกับที่ Plex เร่งให้อัปเดตเมื่อต้นเดือนกันยายนหรือไม่ และได้ติดต่อ Plex เพื่อขอความเห็นแล้ว

honeypot ของ boredhackerblog เห็นการสแกนและการลองโจมตีแบบทั่วไปในช่วงแรก การโจมตีเดินหน้าต่อได้ก็ต่อเมื่อเขาเปิดให้ honeypot ส่งทราฟฟิกออกนอกเครือข่าย เพราะห่วงโซ่ต้องให้เซิร์ฟเวอร์ติดต่อกลับไปหาผู้โจมตี ไฟล์ที่ถูกดาวน์โหลดมาจาก 217.60.194[.]116 ประกอบด้วยไฟล์ Docker ที่บรรจุตัวขุดคริปโต และไบนารีชื่อ x ที่บีบอัดด้วย UPX การอัปเดตในวันเดียวกันพบไฟล์ myawesomeproxy ซึ่ง VirusTotal จัดเป็น backdoor และ reverse proxy แบบซ่อนตัวบนลินุกซ์ เมื่อรันจะแสดงข้อความว่า “การรันซอฟต์แวร์นี้บนอุปกรณ์ของคุณถือว่าคุณยินยอมให้ทราฟฟิกอินเทอร์เน็ตของคุณถูกใช้งานจากภายนอก” ส่วนตัวขุด XMRig ที่ชื่อ mylovelyminer ชี้ไปที่พูลขุด ota.proxystream[.]st ขณะที่ global.relay.proxystream[.]st ซึ่งเป็นโดเมนย่อยของโดเมนเดียวกัน ถูก Bitsight ระบุเมื่อเดือนสิงหาคม 2569 ว่าเกี่ยวข้องกับบอตเน็ต AISURU

ข้อจำกัดของหลักฐานที่ควรเก็บไว้คือ boredhackerblog ระบุเองว่าข้อมูลจาก honeypot อาจไม่ครบ เพราะมีการเปลี่ยนการตั้งค่าทราฟฟิกขาออกและ tcpdump ระหว่างทดสอบ และยังไม่ได้ตรวจ packet capture ทั้งหมด ผู้โจมตีอาจดัดแปลงโค้ดหรือเทคนิคไปจาก PoC ต้นฉบับ นอกจากนี้ผู้ใช้หลายรายบน Reddit รายงานว่าเซิร์ฟเวอร์ Plex ของตนถูกฝัง mylovelyminer ตัวเดียวกัน แต่ยังยืนยันไม่ได้ว่าเกิดจาก Plex2Shell

อัปเดต 21 ต.ค. 2569: เว็บไซต์ The Hacker News รายงานว่าหน่วยงาน CISA ของสหรัฐฯ เพิ่มช่องโหว่ทั้ง 4 รายการของ Plex2Shell ได้แก่ CVE-2026-96652 (CVSS 5.3), CVE-2026-96654 (CVSS 6.9), CVE-2026-96655 (CVSS 5.3) และ CVE-2026-96656 (CVSS 8.6) เข้าแคตตาล็อก Known Exploited Vulnerabilities (KEV) เมื่อวันที่ 20 ตุลาคม 2569 ตามรายงานการโจมตีจริงของ boredhackerblog และสั่งหน่วยงานพลเรือนของรัฐบาลกลางให้แก้ CVE-2026-96656 กับ CVE-2026-96654 ภายในวันที่ 23 ตุลาคม และอีก 2 รายการภายในวันที่ 3 พฤศจิกายน 2569

วิธีการโจมตี

ตามบทความของนาย Main ห่วงโซ่ Plex2Shell มี 5 ขั้นตอน ขั้นแรกเป็น SSRF ผ่าน endpoint /player/timeline ซึ่งตรวจเพียงว่ามี header X-Plex-Token อยู่ ไม่ตรวจว่าโทเคนถูกต้องหรือไม่ ผู้โจมตีจึงใส่ค่าขยะได้ และพารามิเตอร์ protocol ถูกนำไปประกอบเป็น URL โดยไม่ตรวจสอบ ทำให้บังคับเซิร์ฟเวอร์ส่งคำขอ POST กลับเข้าหาตัวเองผ่าน loopback ได้ (CVE-2026-96652, CVSS 5.3) ขั้นที่สอง API /system/agents/* เชื่อคำขอที่มาจาก loopback และข้ามการตรวจโทเคน ผู้โจมตีจึงเรียกฟังก์ชันของปลั๊กอินตัวอื่นพร้อมพารามิเตอร์ที่กำหนดเองได้ผ่าน endpoint searchOne (CVE-2026-96654, CVSS 6.9)

ขั้นที่สามคือการขโมยโทเคนผู้ดูแลของเจ้าของเซิร์ฟเวอร์ เฟรมเวิร์กปลั๊กอินจะแนบโทเคนนี้ไปกับคำขอขาออกที่ URL ขึ้นต้นด้วย http://127.0.0.1 แต่การตรวจแบบเทียบคำขึ้นต้นมีช่องโหว่ เมื่อผู้โจมตีใช้ชื่อโดเมนที่ขึ้นต้นเหมือนกันแต่ resolve ไปยัง IP ของตัวเอง โทเคนจึงถูกส่งไปหาผู้โจมตี ใน honeypot พบว่าผู้โจมตีใช้ชื่อโฮสต์ของบริการ sslip.io ที่สร้างจาก IP ของตัวเอง ที่พอร์ต 8952 ขั้นที่สี่ เมื่อได้โทเคนเจ้าของแล้ว ผู้โจมตีใช้ SSRF อีกตัวผ่านพาธ /video/:/transcode/universal ดึงไฟล์วิดีโอที่แฝง payload ELF จากเซิร์ฟเวอร์ภายนอก (CVE-2026-96655, CVSS 5.3) แล้วตั้งค่าตัวแปลงวิดีโอ x264 ให้เขียนเฟรมที่ถอดรหัสแล้วลงพาธที่เลือกเองในโฟลเดอร์ Codecs (CVE-2026-96656, CVSS 8.6) ขั้นสุดท้าย ตัวแปลงวิดีโอจะโหลดไฟล์ .so ในโฟลเดอร์นั้นตอนเริ่มทำงาน shared object ที่ผู้โจมตีสร้างจึงถูกรันด้วยสิทธิ์ของผู้ใช้ plex

คำขอโจมตีที่ honeypot จับได้ส่งไปที่ /player/timeline/subscribe ชี้ไปยังปลั๊กอิน com.plexapp.agents.thetvdb ฟังก์ชัน GetResultFromNetwork บน 127.0.0.1:32400 ใช้ commandID=1 ค่า X-Plex-Target-Client-Identifier ขึ้นต้นด้วย poc_ และ User-Agent Python-urllib/3.10 ซึ่งเป็นร่องรอยที่ใช้ตั้งกฎตรวจจับได้ นาย Main ยังเผยแพร่กฎตรวจจับไว้ใน repository ของ PoC และ boredhackerblog แชร์ไฟล์ pcap จากแล็บไว้บน GitHub

ผลกระทบ

Plex Media Server มักถูกเปิดพอร์ต 32400/TCP สู่อินเทอร์เน็ตโดยตรงเพื่อให้ดูสื่อจากนอกบ้านได้ และ Censys เคยพบอุปกรณ์ที่เปิดหน้าเว็บของ Plex Media Server สู่อินเทอร์เน็ตกว่า 360,000 เครื่อง แม้ไม่ใช่ทุกเครื่องจะมีช่องโหว่ แต่ห่วงโซ่นี้ไม่ต้องใช้บัญชีใด ๆ และมีโค้ดสาธารณะแล้ว เครื่องที่ยังไม่อัปเดตจึงถูกเจาะได้ง่าย ผลกระทบที่เห็นชัดคือการถูกใช้ขุดคริปโตซึ่งกินทรัพยากรเครื่อง แต่ที่น่ากังวลกว่าคือ backdoor พร็อกซี เพราะเปลี่ยนเครื่องเหยื่อที่อยู่บน IP บ้านให้กลายเป็นทางผ่านของทราฟฟิกผู้อื่น ซึ่งเป็นทรัพยากรที่ผู้โจมตีนิยมใช้หลบระบบป้องกันที่บล็อก IP ของศูนย์ข้อมูล

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

คำแนะนำ

  • อัปเดต Plex Media Server เป็นเวอร์ชัน 1.43.3.10861 หรือใหม่กว่าทันที โดยเฉพาะเครื่องบน NAS ที่ต้องดาวน์โหลดแพ็กเกจมาติดตั้งเอง
  • ไม่เปิดพอร์ต 32400/TCP สู่อินเทอร์เน็ตโดยตรง ให้เข้าผ่าน VPN หรือฟีเจอร์ Remote Access ของ Plex แทน
  • ตรวจโฟลเดอร์ Codecs ของ Plex หาไฟล์ .so ที่ไม่รู้จัก และตรวจโปรเซสชื่อ mylovelyminer, myawesomeproxy หรือ xmrig ที่รันด้วยผู้ใช้ plex
  • ค้น log หาคำขอไปยัง /player/timeline/subscribe ที่มีพารามิเตอร์ protocol ผิดปกติ ค่า X-Plex-Target-Client-Identifier ขึ้นต้นด้วย poc_ หรือ User-Agent Python-urllib/3.10 และนำกฎตรวจจับจาก repository ของนาย Main มาใช้
  • บล็อกและค้นหาการเชื่อมต่อไปยัง IP และโดเมนในส่วน IoCs รวมถึงการ resolve ชื่อโฮสต์ sslip.io จากเซิร์ฟเวอร์ Plex
  • หากพบร่องรอย ให้ถือว่าเครื่องถูกยึด แยกเครื่องออกจากเครือข่าย เปลี่ยนโทเคนและรหัสผ่านของบัญชี Plex และพิจารณาติดตั้งระบบใหม่
  • องค์กรควรกำหนดให้พนักงานที่ทำงานจากบ้านแยกอุปกรณ์งานออกจากเซิร์ฟเวอร์สื่อและ NAS ในเครือข่ายบ้าน

Indicators of Compromise (IoCs)

IP ที่ใช้โจมตี

  • 45.194.92[.]222
  • 91.92.40[.]202
  • 176.65.139[.]228

IP ที่ใช้แจกจ่ายไฟล์อันตราย

  • 217.60.194[.]116

โดเมน

  • ota.proxystream[.]st (พูลขุดคริปโต)
  • global.relay.proxystream[.]st (เชื่อมโยง AISURU ตาม Bitsight)

SHA-256

  • 5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441 — ไฟล์ Docker
  • 68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7 — x (UPX packed)
  • b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49 — x (UPX unpacked)
  • e546b10aee5edc754da4f9b0baace00392257121911f630145078eafad1e6bd9 — myawesomeproxy
  • 2d3c618b21a7e2f8bcd735da188e44a7609ff3f204832dd0781cd09e4388c9db — xmrig

แหล่งอ้างอิง