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

ประเด็นสำหรับผู้บริหาร

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

ARTEX คืออะไร ใครพัฒนา และทำงานอย่างไร

AhnLab ระบุว่า ARTEX เผยแพร่โดยผู้ใช้ GitHub ชื่อ Autumn-27 เป็นกรอบงานทดสอบเจาะระบบอัตโนมัติที่เชื่อมกับ LLM ผู้ควบคุมกำหนดเป้าหมายและขอบเขต จากนั้นระบบวางแผน มอบหมายงานให้ agent เรียกใช้เครื่องมือ และนำผลลัพธ์กลับมาปรับงานต่อไป [6] ผู้พัฒนาเครื่องมือกับผู้โจมตีที่นำไปใช้เป็นคนละข้อกล่าวอ้าง ไม่ควรถือว่าเป็นบุคคลเดียวกันโดยไม่มีหลักฐาน

ARTEX จึงต่างจากการถาม chatbot ให้ช่วยเขียนโค้ด เพราะเชื่อมการตัดสินใจกับการทำงานจริงบนระบบ ขีดความสามารถขึ้นกับรุ่น เครื่องมือ สิทธิ์ ข้อมูลเข้าระบบ และเส้นทางเครือข่ายที่มี ไม่ได้หมายความว่าสามารถเจาะได้ทุกระบบหรือค้นพบ zero-day ทุกครั้ง [3][4]

หลักฐานการใช้งานจริง: แยกแต่ละแคมเปญ

แหล่งข้อมูลสิ่งที่รายงานข้อจำกัดในการตีความ
CrowdStrike [1]พบประวัติ session และไฟล์ตั้งค่า ARTEX ในโครงสร้างพื้นฐานที่เกี่ยวกับการโจมตีภาคการเงินเกาหลีใต้ ช่วงปลาย ก.ย.–ต้น ต.ค. 2026 พร้อมหลักฐานนำข้อมูลออกยังไม่ยืนยันจำนวนองค์กรทั้งหมด และไม่ได้ระบุผู้โจมตีเป็นกลุ่มที่มีชื่อแน่ชัด การประเมินแรงจูงใจทางการเงินมีความเชื่อมั่นระดับปานกลาง
Microsoft [2]เชื่อมกิจกรรมอีกแคมเปญกับ Storm-0940 และการใช้ ARTEX เร่งการเข้าถึงผ่านแอปของ ConnectWise ที่ถูกกระทบ รวมถึงกิจกรรม OAuth และ Microsoft Graphการมีแอปหรือพบ sign-in สำเร็จไม่ยืนยันว่าข้อมูลถูกอ่านหรือขโมย ต้องตรวจการทำงานที่ตามมา
Google GTIG / Mandiant [3]พบผู้โจมตีหลายรายใช้ ARTEX ในงานตรวจสอบเหตุบุกรุก ทั้งสอดแนมภายใน ขยายสิทธิ์ และเคลื่อนย้ายในเครือข่ายบางกรณีผู้โจมตีป้อน credentials ที่ยึดมาแล้วให้เครื่องมือ จึงไม่ควรตีความว่า AI เจาะด่านแรกได้เองทุกครั้ง
AhnLab ASEC [4]ทดลองในระบบที่มีจุดอ่อนและพบการรันคำสั่งกับการขยายผล อีกทั้งพบไฟล์ประกอบปฏิบัติการบนโฮสต์บางส่วนผลทดลองเป็นสภาพแวดล้อมเฉพาะ จำนวนเครื่องที่เปิด console ARTEX ไม่เท่ากับจำนวนผู้โจมตีหรือจำนวนเหยื่อ

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

บริบทประเทศไทย: ต้องกังวลแค่ไหน

ข้อเท็จจริงในไทย: ThaiCERT เผยแพร่คำเตือนวันที่ 12 ตุลาคม 2569 โดยอ้างรายงานกรณีภาคการเงิน และแนะนำให้ทบทวนระบบภายนอก การยืนยันตัวตน สิทธิ์ และ log [5] การเผยแพร่คำเตือนของไทยไม่ได้หมายความว่าเหยื่อในรายงานเป็นองค์กรไทย ณ วันที่ตรวจสอบ 2 พฤศจิกายน 2569 แหล่งที่อ้างในบทความนี้ยังไม่ยืนยันเหยื่อไทยโดยตรง การไม่พบรายงานสาธารณะก็ไม่ใช่หลักฐานว่าไม่มีเหตุเกิดขึ้น

บทประเมิน ALPHASEC: องค์กรไทยที่ใช้เว็บ/API สาธารณะ คลาวด์ Microsoft 365 ระบบของคู่ค้า และบัญชีผู้ให้บริการร่วม มีพื้นผิวเสี่ยงในลักษณะเดียวกับเหตุที่รายงาน การประเมินควรอาศัยสภาพระบบจริง ไม่จำกัดเฉพาะธนาคารหรือองค์กรขนาดใหญ่

สภาพที่พบระดับเร่งด่วนเชิงปฏิบัติของ ALPHASECสิ่งที่ต้องทำ
มีหลักฐานรันคำสั่งผิดปกติ บัญชีหรือ secret รั่ว หรือแอปเพิ่มสิทธิ์โดยไม่ได้อนุญาตเริ่มตอบสนองเหตุทันทีรักษาหลักฐาน ควบคุมการเข้าถึง ตรวจขอบเขต และถอน persistence
ระบบภายนอกมีช่องโหว่ที่ถูกใช้จริง บัญชีผู้ดูแลไม่มี MFA หรือแอปคู่ค้ามีสิทธิ์กว้างเร่งแก้ตามความเสี่ยงสูงลด exposure แก้ช่องโหว่ และทบทวนสิทธิ์ โดยไม่รอพิสูจน์ว่าเป็น ARTEX
มี inventory แพตช์ สิทธิ์ต่ำ และการตรวจจับพร้อม แต่ยังไม่ทดสอบ responseตรวจยืนยันและซ้อมทดสอบ alert-to-containment และการกู้คืน พร้อมประเมินจุดอับของ log

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

แผนป้องกัน: ลดโอกาสเข้า ลดการขยายผล ลดเวลาตอบสนอง

วันนี้: รู้จุดเปิดรับและสิทธิ์สำคัญ

  • ทำ inventory เว็บ/API VPN ระบบบริหาร และบริการของคู่ค้าที่เปิดภายนอก รวมระบบเก่าและระบบทดสอบ ให้แต่ละรายการมีเจ้าของชัดเจน
  • เร่งแก้ช่องโหว่ที่มีการใช้โจมตีจริง จำกัดหน้า admin ด้วยช่องทางที่ควบคุมได้ ปิดบริการที่ไม่จำเป็น ใช้ WAF เป็นมาตรการเสริมระหว่างแก้ต้นเหตุ
  • ใช้ MFA ที่ต้าน phishing สำหรับบัญชีสำคัญ ปิดวิธีล็อกอินเก่าที่ไม่จำเป็น และทบทวน session/token เมื่อสงสัยการยึดบัญชี
  • ตรวจ enterprise application, service principal, consent, app role และ secret/certificate โดยเฉพาะแอป backup และ MSP สิทธิ์แอปแบบ app-only ต้องควบคุมแยกจาก MFA ของผู้ใช้

ภายในสัปดาห์: ทำให้ตรวจพบและหยุดได้

  • เชื่อม web/WAF, identity, cloud audit, DNS/proxy, firewall และ EDR ให้ค้นหาเหตุเรียงตามเวลาได้ พร้อมยืนยัน timezone และความครบถ้วนของการเก็บ log
  • แจ้งเตือนลำดับสแกนหลาย endpoint → อัปโหลดไฟล์ → web process เรียก shell → เชื่อมต่อออก หรือ sign-in ผิดปกติ → เพิ่ม credential/role → อ่านข้อมูลจำนวนมาก
  • แยกเครือข่ายเว็บออกจากฐานข้อมูลและระบบบริหาร จำกัด egress ตามงาน และลดสิทธิ์ service account ไม่ให้จุดเข้าเดียวลามถึงทั้งองค์กร
  • กำหนดผู้มีอำนาจ isolate host ปิดบัญชีหรือแอป และ rotate secret ได้จริง พร้อมรักษาหลักฐานและแผนย้อนกลับ

ภายในเดือน: ทดสอบผลและการกู้คืน

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

IOC สำหรับทีม SOC / Threat Hunting

รายการคัดเลือกต่อไปนี้คัดจากรายงานต้นทาง ตรวจสอบวันที่ 2 พฤศจิกายน 2569 แสดง IP แบบ defanged ด้วย [.] เพื่อไม่ให้กดเชื่อมต่อโดยบังเอิญ ต้องแปลงกลับก่อนค้น log รายการเหล่านี้สัมพันธ์กับแคมเปญหรือไฟล์ที่รายงาน ไม่ใช่ลายนิ้วมือสากลของ ARTEX

IOC / ประเภทบริบทและแหล่งที่มาวิธีใช้
38.244.50[.]120 — IPโครงสร้างพื้นฐานผู้โจมตีในรายงานเกาหลีใต้ CrowdStrike [1]ค้น web, firewall, proxy และ authentication log แล้วตรวจพฤติกรรมร่วม
101.53.80[.]20
205.214.59[.]31
124.155.252[.]63
154.201.79[.]246
23.248.249[.]90
23.158.220[.]98
103.248.148[.]84
203.160.133[.]172
209.209.85[.]38 — IP		Proxy ที่พบในการดำเนินกิจกรรมตาม CrowdStrike [1]ใช้ร่วมกับช่วงเวลาและปลายทาง IP อาจใช้ร่วมกับบุคคลอื่นหรือเปลี่ยนผู้ใช้งาน
144.172.64[.]128
144.172.64[.]99
144.172.64[.]60 — IP		Sign-in / Graph activity ในแคมเปญ Storm-0940 ตาม Microsoft [2]ตรวจ service-principal sign-in, Graph และการเปลี่ยน credential/สิทธิ์ของแอป
134.122.137[.]132
204.194.51[.]54 — IP		เกี่ยวข้องกับ operational directory ที่ AhnLab ตรวจ [4]ตรวจความเชื่อมโยงกับไฟล์และพฤติกรรมเพิ่มเติม ไม่เหมารวมโฮสต์ ARTEX ทุกเครื่องว่าอันตราย
085f53a1ce8c634ac7b0d63e42b56b15
0c501aca4fc29efe47f122ddc9c1af85
0eb259067e565221109a3ee988e1faa3
220a1465b2c5ee3ec86861ee17a91e2f
2d13374c14bcaaa99ab00f16cc18b300 — MD5		ตัวอย่าง 5 hash จากชุดไฟล์ที่ AhnLab เผยแพร่ [4]ค้น EDR / file inventory เป็น exact match ของไฟล์ตัวอย่าง ไม่ใช่ hash โปรแกรม ARTEX ทั้งหมด รุ่นไฟล์เปลี่ยนอาจไม่ตรง

ข้อควรระวัง: ไม่พบ IOC ไม่ได้แปลว่าปลอดภัย และพบ IP ตรงไม่ได้ยืนยันการบุกรุก ต้องดูทิศทางการเชื่อมต่อ เวลา process บัญชี และกิจกรรมตามมา ทบทวนอายุ IOC และบริการที่ใช้ร่วมก่อนบล็อก เพื่อไม่กระทบงานปกติ

User-Agent และชื่อไฟล์: ใช้เป็นเบาะแสที่มีข้อจำกัด

AhnLab พบ norma/0.4 และ curl/<VERSION> ในการทดลอง ส่วน artex-selfupdate เป็นการเช็กอัปเดตจากเครื่องที่รัน ARTEX ไป GitHub จึงไม่ควรคาดว่าจะพบใน access log ของเว็บเหยื่อ ค่าเหล่านี้เปลี่ยนได้ และ curl ใช้งานปกติอย่างแพร่หลาย การพบเพียงค่าเดียวไม่ยืนยัน ARTEX [4]

ทีม SOC ควรให้น้ำหนักกับพฤติกรรมต่อเนื่อง เช่น web server เรียก shell, การดึง credential และการเคลื่อนย้ายภายใน มากกว่าการตั้งกฎจับชื่อเครื่องมืออย่างเดียว [3]

ถ้าพบร่องรอยต้องสงสัย ควรทำอย่างไร

  1. ตรวจว่าเป็นงานผู้ดูแลหรือการทดสอบที่ได้รับอนุญาตหรือไม่ พร้อมรักษา log และ timeline
  2. ควบคุมบัญชี แอป หรือโฮสต์ที่สงสัยตาม playbook หลีกเลี่ยงลบ enterprise application เป็นขั้นแรกจนสูญเสียหลักฐานหรือกระทบบริการโดยไม่จำเป็น [2]
  3. ตรวจ credentials ที่เพิ่มใหม่ สิทธิ์ที่เปลี่ยน web shell ช่องทางคงอยู่ และขอบเขตข้อมูลที่เข้าถึงจริง การแพตช์อย่างเดียวไม่ถอนการเข้าถึงที่ผู้โจมตีสร้างไว้
  4. ให้ทีม incident response และเจ้าของข้อมูลประเมินผลกระทบ รวมถึงหน้าที่แจ้งเหตุตามข้อเท็จจริงและกฎที่ใช้กับองค์กร ไม่ตัดสินจากชื่อ ARTEX หรือจำนวน IOC ที่ตรงเพียงอย่างเดียว

เตรียมความพร้อมรับการโจมตีด้วย Agentic AI

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

ติดต่อ ALPHASEC · 091 003 4852 · contact@alphasec.co.th

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

  1. CrowdStrike — แคมเปญภาคการเงินเกาหลีใต้ (7 ต.ค. 2026)
  2. Microsoft — Storm-0940 และการใช้สิทธิ์แอปของคู่ค้า (21 ต.ค. 2026)
  3. Google GTIG / Mandiant — ARTEX and Friends (30 ต.ค. 2026)
  4. AhnLab ASEC — การทดลองและ IOC ของ ARTEX
  5. ThaiCERT — คำเตือน ARTEX และ Claude Code (12 ต.ค. 2026)
  6. AhnLab — ผู้เผยแพร่ต้นทางและการติดตาม infrastructure

ค้นคว้าและวิเคราะห์โดย ALPHASEC ตรวจสอบข้อมูล 2 พฤศจิกายน 2569 ข้อประเมินบริบทไทยและแผนดำเนินการเป็นบทวิเคราะห์ของ ALPHASEC แยกจากข้อเท็จจริงที่อ้างรายงานต้นทาง