TXEC

TXEC Thailand Threat eXchange and Enhanced Cybersecurity
ศูนย์กลางการแลกเปลี่ยน Threat Intelligence ระดับองค์กร ที่ออกแบบมาเพื่อ “บริบทของประเทศไทยโดยเฉพาะ”

🚨 พบการจดโดเมนเลียนแบบแบรนด์เพิ่มขึ้น องค์กรควรตรวจสอบอะไร ?โดเมนปลอมที่มีชื่อคล้ายเว็บไซต์จริงกำลังถูกนำมาใช้เป็นโครงสร...
07/08/2026

🚨 พบการจดโดเมนเลียนแบบแบรนด์เพิ่มขึ้น
องค์กรควรตรวจสอบอะไร ?
โดเมนปลอมที่มีชื่อคล้ายเว็บไซต์จริง
กำลังถูกนำมาใช้เป็นโครงสร้างพื้นฐานสำคัญ
ของการโจมตีแบบ Phishing
การขโมยบัญชีผู้ใช้งาน การหลอกชำระเงิน
และการแพร่กระจายมัลแวร์
📊 รายงาน Phishing Landscape 2025 ซึ่ง
วิเคราะห์รายงาน Phishing เกือบ 4 ล้านรายการ
ระหว่างเดือนพฤษภาคม 2024 ถึงเมษายน 2025
พบว่า มีโดเมนมากกว่า 1.5 ล้านชื่อ ถูกนำไปใช้
ในการโจมตีแบบ Phishing เพิ่มขึ้นประมาณ 38%
จากปีก่อนหน้า และประมาณ 77% ของโดเมน
เหล่านี้ถูกจดขึ้นโดยผู้ไม่ประสงค์ดีโดยตรง
ไม่ใช่เว็บไซต์ปกติที่ถูกแฮ็กภายหลัง
ขณะเดียวกัน Infoblox รายงานว่า จากโดเมน
ที่เพิ่งถูกตรวจพบกว่า 100.8 ล้านชื่อ
ในช่วงเวลา12 เดือน มีประมาณ 25.1% ถูกจัดว่า
เป็นโดเมนอันตรายหรือน่าสงสัย สะท้อนให้เห็น
ว่าผู้โจมตีกำลังสร้างและหมุนเวียนโดเมน
จำนวนมากเพื่อหลบเลี่ยงระบบตรวจจับ
🔎 รูปแบบโดเมนเลียนแบบที่องค์กรควรเฝ้าระวัง
ผู้โจมตีอาจสร้างชื่อโดเมนให้ใกล้เคียงกับแบรนด์จริง
เช่น
▪️สลับหรือตัดตัวอักษร
เช่น sosecure เป็น sosecuure
▪️ใช้อักขระที่มองคล้ายกัน เช่น ตัวอักษร o กับเลข 0
▪️เพิ่มคำที่สร้างความน่าเชื่อถือ เช่น login, secure,
support, invoice หรือ verify
▪️เปลี่ยนนามสกุลโดเมน เช่น จาก .com เป็น .net,
.co หรือ TLD อื่น
▪️ใช้ Internationalized Domain Name หรือ
อักขระต่างภาษาให้ดูเหมือนชื่อแบรนด์จริง
▪️นำโดเมนเก่าที่หมดอายุและเคยได้รับความ
น่าเชื่อถือกลับมาใช้โจมตี
CISA ระบุว่าโดเมนที่มีลักษณะคล้ายของจริง
สามารถถูกใช้สำหรับ Phishing, Drive-by
Compromise, การส่งมัลแวร์ และ
เป็นช่องทาง Command and Control ได้
🛡️องค์กรควรตรวจสอบอะไรทันที
1. ตรวจหาโดเมนที่มีชื่อคล้ายแบรนด์
ค้นหาชื่อบริษัท ชื่อผลิตภัณฑ์ ชื่อผู้บริหาร และ
คำที่เกี่ยวข้องกับบริการขององค์กร ร่วมกับการ
สะกดผิด การสลับตัวอักษร และนามสกุลโดเมนอื่น
2. ตรวจสอบวันที่จดทะเบียนและอายุโดเมน
โดเมนที่เพิ่งจดใหม่ก่อนเริ่มแคมเปญ Phishing
ไม่นานถือเป็นสัญญาณที่ควรตรวจสอบเพิ่มเติม
แต่ไม่ควรตัดสินจากอายุโดเมนเพียงอย่างเดียว
3. ตรวจสอบ DNS และโครงสร้างพื้นฐาน
พิจารณา A, AAAA, CNAME, Name Server
และ IP Address ที่โดเมนชี้ไป รวมถึงตรวจว่า
หลายโดเมนต้องสงสัยใช้ Hosting, Registrar
หรือโครงสร้างพื้นฐานเดียวกันหรือไม่
4. ตรวจสอบ MX Record
แม้เว็บไซต์ยังไม่มีเนื้อหา แต่หากมีการตั้งค่า
MX Record โดเมนนั้นอาจถูกเตรียมไว้สำหรับ
ส่งอีเมลปลอม อย่างไรก็ตาม การมี MX Record
เพียงอย่างเดียวยังไม่สามารถยืนยันเจตนาร้ายได้
เพราะผู้ให้บริการบางรายอาจสร้างค่าเหล่านี้
เป็นค่าเริ่มต้น
5. ตรวจสอบใบรับรอง TLS
การมี HTTPS หรือรูปแม่กุญแจไม่ได้หมายความว่า
เว็บไซต์ปลอดภัย ควรติดตาม Certificate
Transparency Log เพื่อค้นหาใบรับรองใหม่
ที่ออกให้กับโดเมนซึ่งมีชื่อแบรนด์ขององค์กร
6. ตรวจสอบหน้าเว็บไซต์อย่างปลอดภัย
ตรวจหาโลโก้ แบบฟอร์ม Login ช่องกรอกข้อมูล
บัตรเครดิต ข้อมูลติดต่อ QR Code และข้อความ
ที่เลียนแบบเว็บไซต์จริง โดยไม่เปิดผ่านเครื่อง
ใช้งานทั่วไปหรือกรอกข้อมูลใด ๆ ลงไป
7. ตรวจสอบ Log ภายในองค์กร
ค้นหาใน DNS Log, Proxy, Firewall,
Secure Web Gateway, Email Gateway
และ Endpoint ว่ามีพนักงานหรือระบบใด
เคยติดต่อกับโดเมนต้องสงสัยหรือไม่
8. ตรวจสอบการปลอมแปลงอีเมล
ตรวจสอบว่าองค์กรตั้งค่า SPF, DKIM และ
DMARC สำหรับโดเมนจริงอย่างเหมาะสม
โดยเฉพาะ DMARC Policy และการติดตาม
รายงาน เพื่อช่วยลดการปลอมแปลงอีเมล
จากโดเมนขององค์กร
⚠️ เมื่อพบโดเมนต้องสงสัย ควรดำเนินการอย่างไร
▪️บันทึกหลักฐาน เช่น URL, Screenshot,
DNS Record, Certificate และเวลาที่ตรวจพบ
▪️บล็อก Domain และ URL ผ่าน DNS Filtering,
Email Gateway, Proxy และ Endpoint
▪️ตรวจสอบย้อนหลังว่ามีผู้ใช้งานเข้าถึง
หรือ กรอกข้อมูลหรือไม่
▪️หากพบการกรอก Credentials ให้เปลี่ยนรหัสผ่าน
ยกเลิก Session และตรวจสอบ MFA ทันที
▪️แจ้ง Registrar, Hosting Provider, Certificate
Authority หรือ แพลตฟอร์มที่เกี่ยวข้อง
เพื่อขอระงับบริการ
▪️ประสานฝ่ายกฎหมายและเจ้าของ
เครื่องหมายการค้าสำหรับกระบวนการ Takedown
▪️แจ้งเตือนพนักงาน ลูกค้า และ Partner
ผ่านช่องทางทางการขององค์กร
▪️ส่งต่อข้อมูล Indicators of Compromise
เพื่อช่วยให้องค์กรอื่นตรวจจับและป้องกันได้เร็วขึ้น
CISA แนะนำให้ใช้ URL หรือ DNS Filtering
เพื่อจำกัดการเข้าถึงเว็บไซต์อันตราย แต่ระบุว่า
การเพิ่มBlocklist ด้วยตนเองเพียงอย่างเดียวไม่เพียงพอ
เพราะผู้โจมตีสามารถสร้าง URL และโดเมนใหม่ได้อย่างต่อเนื่อง
📌 ข้อควรระวังจาก TXEC
โดเมนที่ยังไม่มีหน้าเว็บไซต์ หรือยังไม่ถูกขึ้นบัญชีดำ
ไม่ได้หมายความว่าไม่มีความเสี่ยง ผู้โจมตีอาจ
จดโดเมนทิ้งไว้ก่อนเปิดใช้งานจริง หรือ เปิดให้
เฉพาะเหยื่อ ประเทศ อุปกรณ์ และช่วงเวลาที่กำหนด
องค์กรจึงควรเปลี่ยนจากการรอให้ลูกค้ารายงาน
เว็บไซต์ปลอม มาเป็นการติดตาม Digital Footprint
และ Lookalike Domain อย่างต่อเนื่อง
เพราะยิ่งตรวจพบโดเมนเลียนแบบได้เร็วเท่าใด
ก็ยิ่งลดโอกาสที่โดเมนนั้นจะถูกใช้หลอกพนักงาน
ลูกค้า และคู่ค้าขององค์กรได้มากขึ้น
🔐 TXEC — รู้ก่อน รับมือก่อน
ศูนย์กลางการแลกเปลี่ยนข้อมูลภัยคุกคาม
ทางไซเบอร์สำหรับทุกองค์กร
📚🙌 อยากอ่านบทความ Exclusive แบบนี้
เพียงสมัครสมาชิก TXEC เพื่อเข้าถึง Incident Summary,
Threat Intelligence และบทวิเคราะห์เชิงเทคนิค
สำหรับองค์กรในบริบทประเทศไทย
👉 ลงทะเบียนเข้าร่วมเป็นสมาชิก
https://txec.sosecure.co.th/register






แหล่งที่มาอ้างอิง :
Interisle Phishing Landscape 2025,
Infoblox 2025 DNS Threat Landscape Report
และ CISA MITRE ATT&CK T1583.001

🔎 มาวิเคราะห์เหตุการณ์ข้อมูลนักลงทุนกว่า 200,000 ราย รั่วไหลเหตุการณ์ครั้งนี้มีต้นเหตุจากช่องโหว่ IDOR หรือการตรวจสอบสิท...
04/08/2026

🔎 มาวิเคราะห์เหตุการณ์ข้อมูลนักลงทุนกว่า 200,000 ราย รั่วไหล

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

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

บทความนี้ TXEC จะพาไปวิเคราะห์:

• ช่องโหว่ IDOR คืออะไร? และเกิดขึ้นได้อย่างไร?
• ข้อมูลประเภทใดได้รับผลกระทบ
• เหตุใด Automated Scanner อาจตรวจไม่พบ
• นักลงทุนและองค์กรควรรับมืออย่างไร

⏳ เปิดให้อ่านฟรีในช่วงเวลาจำกัด
ก่อนสงวนเนื้อหาฉบับเต็มสำหรับสมาชิก TXEC เท่านั้น

อ่านบทวิเคราะห์ฉบับเต็มได้ที่
https://txec.sosecure.co.th/th/articles/TSD-Investor-Portal-Leaking-Data

อยากอ่านบทความ Exclusive แบบนี้ 🙌
สมัครสมาชิก TXEC เพื่อเข้าถึง Incident Summary, Threat Intelligence และบทวิเคราะห์เชิงเทคนิคสำหรับองค์กรในบริบทประเทศไทย

👉 ลงทะเบียนเข้าร่วมเป็นสมาชิก
https://txec.sosecure.co.th/register

#การลงทุน #ข้อมูลรั่วไหล #รู้ก่อนรับมือก่อน

03/08/2026

ไม่ได้เข้าร่วม แต่อยากมีส่วนร่วมด้วย 🙌
SOSECURE มอบโอกาสสุดพิเศษ พร้อมสนับสนุนคนไทย
จัดแคมเปญ Thai Cyber Boost 60/40 🇹🇭
พบกับโปรโมชั่นครั้งใหญ่ ลดเยอะที่สุดเท่าที่เคยมีมา !!
ใน Cyberdemy ( powered by SOSECURE )
ไม่จำกัดหลักสูตรการเรียนรู้ ลด 60% ทุกคอร์สเรียน !!
ผู้เรียนสามารถเลือกพัฒนาทักษะได้ตามเป้าหมายของตนเอง
[ Click Here >> https://cyberdemy.co/courses ]
SOSECURE สนับสนุนส่วนลดสูงสุด 60%
ผู้เรียนชำระเพียง 40%
อัปสกิลก่อน ได้เปรียบก่อน
🔥 รีบคว้าโอกาสก่อนจะหมดสิทธ์
ระยะเวลาแคมเปญสิ้นสุด 30 ก.ย. 2026 เท่านั้น !!
Tel : 02-511-2422
LINE :
Website : [www.sosecure.co.th](http://www.sosecure.co.th/)
#ไทยช่วยไทย

#คอร์สออนไลน์
#เรียนCybersecurity
#ย้ายสายงาน #เรียนCybersecurity
#คนทั่วไป #เปลี่ยนสายงาน #อัปสกิล

🔴 พบช่องโหว่ CVE-2026-43503 บน Linux Kernelเปิดทางยกระดับสิทธิ์เป็น Root ผ่าน Cloned Packetsมีการเปิดเผยช่องโหว่ความรุนแ...
31/07/2026

🔴 พบช่องโหว่ CVE-2026-43503
บน Linux Kernelเปิดทางยกระดับสิทธิ์
เป็น Root ผ่าน Cloned Packets
มีการเปิดเผยช่องโหว่ความรุนแรงสูง
CVE-2026-43503 ใน Linux Kernel
ซึ่งเกี่ยวข้องกับการจัดการหน่วยความจำ
ของแพ็กเก็ตแบบแบ่งปันและโคลน
หรือ Cloned Socket Buffers (skb)
ช่องโหว่นี้อาจเปิดโอกาสให้ผู้ใช้งานที่
มีสิทธิ์ระดับต่ำดัดแปลงข้อมูลในหน่วย
ความจำที่เชื่อมโยงกับไฟล์สำคัญ
จนนำไปสู่การ ยกระดับสิทธิ์เป็น Root
และอาจใช้หลบหนีจาก Container ได้
ในบางเงื่อนไข
นักวิจัยจาก JFrog Security Research
เรียกช่องโหว่รูปแบบนี้ว่า DirtyClone
และจัดให้อยู่ในกลุ่มเทคนิค DirtyFrag
🔍 ช่องโหว่เกิดขึ้นได้อย่างไร
Linux Kernel ใช้โครงสร้าง `sk_buff` หรือ `skb`
เพื่อจัดเก็บและประมวลผลแพ็กเก็ตเครือข่าย
โดยบางกรณี Kernel จะโคลนแพ็กเก็ตหรือ
ย้าย Fragment ระหว่าง Socket Buffer
ข้อบกพร่องเกิดขึ้นเมื่อสถานะของ
Shared Fragment ไม่ถูกส่งต่ออย่างถูกต้อง
ทำให้ Kernel เข้าใจผิดว่าหน่วยความจำ
ที่ใช้ร่วมกันสามารถแก้ไขได้อย่างปลอดภัย
ผู้โจมตีจึงอาจสร้างเงื่อนไขให้ข้อมูลจาก
แพ็กเก็ตถูกเขียนทับลงบน Page Cache
ที่เชื่อมโยงกับไฟล์ในระบบ
⚠️ จากสิทธิ์ระดับต่ำสู่ Root
หากผู้โจมตีควบคุมตำแหน่งและข้อมูล
ที่ถูกเขียนได้สำเร็จ อาจนำไปใช้แก้ไขไฟล์
ที่เกี่ยวข้องกับการยืนยันตัวตน การกำหนดสิทธิ์
หรือ Process ที่ทำงานด้วยสิทธิ์สูง
JFrog ระบุว่าช่องโหว่นี้สามารถนำไปใช้โจมตี
แบบ Local Privilege Escalation ได้จริง
และประเมินความรุนแรงที่ CVSS 8.8
📌 ไม่ใช่ Remote Root โดยตรง
ผู้โจมตีต้องมีความสามารถในการ
รันโค้ดภายในระบบก่อน เช่น
▪️ มีบัญชีผู้ใช้ระดับต่ำ
▪️ เข้าควบคุม Application หรือ Service ได้แล้ว
▪️ รันโค้ดภายใน Container
▪️ ใช้ช่องโหว่อื่นเป็นจุดเริ่มต้นของ Attack Chain
ดังนั้น CVE-2026-43503 มีแนวโน้ม
ถูกใช้เป็นขั้นตอนยกระดับสิทธิ์ต่อจาก
การโจมตีอื่น มากกว่าจะเป็นช่องโหว่
ที่โจมตีจากอินเทอร์เน็ตแล้วได้สิทธิ์ Root ทันที
🖥️ ระบบที่ควรเร่งตรวจสอบ
▪️ Linux Server ที่มีผู้ใช้งานหลายราย
▪️ Container Host และ Kubernetes
▪️ CI/CD Runner และระบบ Build
▪️ Cloud Workload ที่เปิดใช้ User Namespace
▪️ Hosting และ Development Server
▪️ ระบบที่ยังไม่ได้อัปเดต Kernel Security Patch
สถานะผลกระทบขึ้นอยู่กับ Kernel และแพตช์
ที่แต่ละ Distribution นำไปใช้ จึงไม่ควร
ตรวจสอบจากหมายเลข Kernel เพียงอย่างเดียว
🛡️ แนวทางรับมือ
✅ อัปเดต Kernel Security Patch จากผู้จัดจำหน่าย
✅ Reboot ระบบหลังติดตั้งแพตช์
✅ ตรวจสอบ Kernel Runtime ที่กำลังใช้งานจริง
✅ หลีกเลี่ยง Privileged Container
✅ จำกัด Linux Capabilities โดยเฉพาะ `CAP_NET_ADMIN`
✅ ทบทวนการใช้งาน Unprivileged User Namespace
✅ ใช้ Seccomp, AppArmor หรือ SELinux
✅ เฝ้าระวัง Process ที่เปลี่ยนเป็น UID 0 หรือมีการแก้ไขไฟล์ระบบผิดปกติ
🔎 มุมมองจาก TXEC
CVE-2026-43503 แสดงให้เห็นว่า
Attack Surface ของ Linux ไม่ได้
อยู่เฉพาะ Service ที่เปิดรับการเชื่อมต่อ
จากภายนอก แต่ยังรวมถึงกลไกภายใน
Kernel ด้าน Network และ
Memory Management
แม้เป็น Local Attack ผู้โจมตีก็อาจใช้สิทธิ์
ระดับต่ำจากบัญชีรั่วไหล ช่องโหว่อื่น
หรือ Workload ภายใน Container
เพื่อยกระดับสิทธิ์และเข้าควบคุมระบบได้
องค์กรที่ใช้งาน Cloud, Container,
Shared Hosting และ CI/CD จึงควร
ตรวจสอบ Kernel Advisory อัปเดตและ
Reboot ระบบ พร้อมจำกัดสิทธิ์ของ Container
และ User Namespace โดยเร็ว
📩 ติดต่อเพื่อรับข้อมูลเพิ่มเติม
👉 ลงทะเบียนเข้าร่วมเป็นสมาชิก
https://txec.sosecure.co.th/register
☎️ 02-511-2422
📧 [[email protected]](mailto:[email protected])
🌐 txec.sosecure.co.th
แหล่งอ้างอิง :
JFrog Security Research
NIST National Vulnerability Database
Ubuntu Security
Red Hat Security
Linux Kernel CVE Database





🔴 พบ Bluekit PhaaS ใช้ Browser-in-the-Middle ขโมยบัญชี Microsoft แม้เปิด MFAนักวิจัยด้านความมั่นคงปลอดภัยไซเบอร์เปิดเผยก...
24/07/2026

🔴 พบ Bluekit PhaaS ใช้ Browser-in-the-Middle
ขโมยบัญชี Microsoft แม้เปิด MFA
นักวิจัยด้านความมั่นคงปลอดภัยไซเบอร์เปิดเผย
การแพร่กระจายของ Bluekit แพลตฟอร์มประเภท
Phishing-as-a-Service (PhaaS) ที่ช่วยให้ผู้โจมตี
สร้างและบริหารแคมเปญฟิชชิง ดักข้อมูลเข้าสู่ระบบ
และยึดเซสชันของผู้ใช้งาน Microsoft ได้ แม้บัญชี
จะเปิดใช้ Multi-Factor Authentication (MFA) แล้วก็ตาม
โดยนักวิจัยตรวจพบโฮสต์ที่เกี่ยวข้องกับ Bluekit
ประมาณ 70 รายการ ภายในระยะเวลาหนึ่งสัปดาห์
สะท้อนถึงความสามารถในการขยายโครงสร้างพื้นฐาน
เพื่อโจมตีเป้าหมายจำนวนมาก
🔎 Bluekit คืออะไร?
Bluekit เป็นบริการฟิชชิงสำเร็จรูปที่รวมองค์ประกอบ
สำคัญไว้ในแพลตฟอร์มเดียว เช่น
- หน้าเว็บไซต์ปลอม
- ระบบบริหารจัดการแคมเปญ
- ระบบเก็บข้อมูลรับรอง
- การแจ้งเตือนเมื่อมีเหยื่อเข้าสู่ระบบ
- เครื่องมือหลบเลี่ยงการตรวจจับ
แพลตฟอร์มมีลักษณะคล้ายบริการซอฟต์แวร์เชิงพาณิชย์
โดยมีแพ็กเกจสมาชิก แดชบอร์ดส่วนกลาง ระบบติดตั้ง
เว็บไซต์อัตโนมัติ และเทมเพลตเลียนแบบบริการต่าง ๆ
เช่น Microsoft, Google, Amazon, Apple, GitHub
สถาบันการเงิน และกระเป๋าเงินคริปโทเคอร์เรนซี
รูปแบบ PhaaS ทำให้ผู้โจมตีที่ไม่มีทักษะทางเทคนิค
ขั้นสูงสามารถดำเนินแคมเปญฟิชชิงได้ง่าย รวดเร็ว
และเป็นระบบมากขึ้น
⚙️ เทคนิค Browser-in-the-Middle ทำงานอย่างไร?
Bluekit ใช้เทคนิค Browser-in-the-Middle (BitM)
โดยเปิดหน้าเข้าสู่ระบบจริงของบริการเป้าหมายบน
เบราว์เซอร์ที่ผู้โจมตีควบคุม จากนั้นจึงถ่ายทอด
หน้าจอและการโต้ตอบมายังเครื่องของเหยื่อแบบเรียลไทม์
แพลตฟอร์มใช้ไลบรารีโอเพนซอร์ส rrweb เพื่อบันทึก
และส่งต่อการเปลี่ยนแปลงของหน้าเว็บ ทำให้เหยื่อ
เห็นหน้าเข้าสู่ระบบที่มีลักษณะใกล้เคียงของจริงอย่างมาก
แต่ในทางเทคนิค กระบวนการเข้าสู่ระบบกำลังเกิดขึ้น
บนเครื่องของผู้โจมตี
ลำดับการโจมตีโดยทั่วไปมีดังนี้
📩 เหยื่อได้รับอีเมล ข้อความ หรือลิงก์ฟิชชิงที่เลียนแบบบริการ Microsoft
🔍 เว็บไซต์ตรวจสอบว่าเป็นผู้ใช้งานจริงหรือระบบสแกนอัตโนมัติ
🖥️ เหยื่อเห็นหน้าเข้าสู่ระบบ Microsoft ผ่านระบบ BitM
🔐 เหยื่อกรอกอีเมล รหัสผ่าน และยืนยัน MFA ตามปกติ
🌐 การยืนยันตัวตนเกิดขึ้นบนเบราว์เซอร์ที่ผู้โจมตีควบคุม
⚠️ ผู้โจมตีได้รับเซสชันที่ผ่านการยืนยันแล้วและนำไปควบคุมบัญชี
🛡️ Bluekit เจาะ MFA ได้จริงหรือไม่?
Bluekit ไม่ได้ถอดรหัส OTP เจาะระบบ Microsoft
หรือทำลายกลไก MFA โดยตรง
สิ่งที่เกิดขึ้นคือ เหยื่อเป็นผู้กรอกรหัสผ่านและ
อนุมัติ MFA ให้กับเซสชันของผู้โจมตีด้วยตนเอง
ผ่านหน้าฟิชชิง เมื่อการยืนยันสำเร็จ ผู้โจมตีจึง
ได้รับเซสชันที่ได้รับอนุญาตแล้ว และอาจไม่จำเป็น
ต้องขอรหัส MFA ซ้ำในทันที
ดังนั้น MFA ยังคงเป็นมาตรการรักษาความปลอดภัย
ที่สำคัญ อย่างไรก็ตาม MFA ที่ใช้ OTP หรือการกด
ยืนยันผ่านแอปเพียงอย่างเดียว อาจไม่สามารถป้องกัน
การโจมตีแบบยึดเซสชันได้ทั้งหมด
🕵️ Bluekit หลบเลี่ยงการตรวจจับอย่างไร?
Bluekit ใช้เทคนิคหลายรูปแบบเพื่อหลบเลี่ยง
ทั้งระบบตรวจจับอัตโนมัติและนักวิเคราะห์ เช่น
- ซ่อนและทำให้โค้ด JavaScript อ่านได้ยาก
- เปลี่ยนโครงสร้าง HTML และรายละเอียด
ของหน้าเว็บทุกครั้งที่โหลด
- ใช้ CAPTCHA ที่เลียนแบบระบบป้องกันบอต
- ตรวจจับ Headless Browser และเครื่องมือ
วิเคราะห์อัตโนมัติ
- ใช้ WebRTC เพื่อตรวจสอบความผิดปกติของข้อมูล IP
- ปรับสี ความสว่าง และองค์ประกอบภาพแบบสุ่ม
เทคนิคเหล่านี้อาจทำให้เว็บไซต์แสดงหน้าเปล่า
หรือเนื้อหาปกติเมื่อถูกตรวจสอบด้วยระบบอัตโนมัติ
แต่แสดงหน้าฟิชชิงจริงเมื่อพบผู้ใช้งานที่ตรงตาม
เงื่อนไขของผู้โจมตี
🏢 ผลกระทบที่อาจเกิดขึ้นกับองค์กร
หากบัญชี Microsoft 365 ถูกยึด ผู้โจมตีอาจเข้าถึง
บริการและข้อมูลที่เชื่อมโยงกับบัญชีนั้น เช่น Outlook,
Teams, SharePoint และ OneDrive รวมถึง
เอกสารภายใน รายชื่อติดต่อ และประวัติการสื่อสาร
บัญชีที่ถูกควบคุมยังอาจถูกนำไปใช้เพื่อ
📧 ส่งอีเมลฟิชชิงจากบัญชีที่มีอยู่จริง
👤 แอบอ้างเป็นผู้บริหาร พนักงาน หรือคู่ค้าขององค์กร
🔁 สร้างกฎส่งต่ออีเมลเพื่อซ่อนหรือขโมยข้อความ
📄 ค้นหาข้อมูลทางการเงิน สัญญา หรือเอกสารสำคัญ
💼 ดำเนินการโจมตีแบบ Business Email Compromise
🔗 ขยายการโจมตีไปยังบัญชีและระบบอื่นภายในองค์กร
ความเสี่ยงจะเพิ่มสูงขึ้นอย่างมาก หากบัญชีที่ถูกโจมตี
เป็นบัญชีผู้ดูแลระบบหรือมีสิทธิ์เข้าถึงข้อมูลสำคัญ
✅ แนวทางรับมือสำหรับองค์กร
1. ใช้ Phishing-resistant MFA 🔑
พิจารณาใช้ Passkey, FIDO2 Security Key,
Windows Hello for Business หรือ
Certificate-based Authentication แทนการพึ่งพา
OTP และ Push Notification เพียงอย่างเดียว
2. บังคับใช้ Conditional Access 🛡️
กำหนดนโยบายตรวจสอบอุปกรณ์ ตำแหน่งที่ตั้ง
ระดับความเสี่ยง และสถานะ Compliance
ก่อนอนุญาตให้เข้าถึงข้อมูลสำคัญ
3. ตรวจสอบ Sign-in Logs อย่างต่อเนื่อง 📊
เฝ้าระวังการเข้าสู่ระบบจากประเทศหรือ IP
ที่ไม่เคยใช้งาน อุปกรณ์ใหม่ User Agent ผิดปกติ
หรือการเปลี่ยนตำแหน่งอย่างรวดเร็ว
4. จำกัดอายุของเซสชัน ⏱️
กำหนด Session Lifetime และ Sign-in Frequency
ให้เหมาะสม เพื่อลดระยะเวลาที่ Session Cookie
หรือ Token ที่ถูกขโมยสามารถนำกลับมาใช้งานได้
5. เฝ้าระวังกิจกรรมหลังเข้าสู่ระบบ 👁️
ตรวจสอบการสร้าง Inbox Rule
การเพิ่มวิธียืนยันตัวตนใหม่ การลงทะเบียนอุปกรณ์
การเพิ่ม OAuth Application
และการเปลี่ยนแปลงสิทธิ์ที่ผิดปกติ
6. ยกระดับ Security Awareness 🎓
อบรมให้ผู้ใช้งานตรวจสอบชื่อโดเมน
หลีกเลี่ยงการเข้าสู่ระบบผ่านลิงก์ในอีเมล
และเปิดบริการ Microsoft ผ่าน Bookmark
หรือพิมพ์ที่อยู่เว็บไซต์ด้วยตนเอง
📌 สรุป
Bluekit สะท้อนให้เห็นว่า ภัยฟิชชิงกำลังเปลี่ยนจาก
การสร้างเพียง “หน้าเว็บไซต์ปลอม” ไปสู่การควบคุม
“กระบวนการเข้าสู่ระบบจริง” แบบเรียลไทม์
องค์กรจึงไม่ควรพึ่งพา MFA เพียงอย่างเดียว แต่ควร
ยกระดับไปสู่ Phishing-resistant Authentication
ควบคู่กับการควบคุมอุปกรณ์ การจำกัดอายุเซสชัน
และการตรวจจับพฤติกรรมผิดปกติหลังการเข้าสู่ระบบ
⚠️ ประเด็นสำคัญคือ ผู้โจมตีอาจไม่จำเป็นต้องเจาะ
ระบบยืนยันตัวตน หากสามารถหลอกให้ผู้ใช้งานเป็น
ผู้อนุมัติเซสชันให้แทนได้
ติดต่อเพื่อรับข้อมูลเพิ่มเติม ได้แล้ววันนี้ !!
👉 ลงทะเบียนเข้าร่วมเป็นสมาชิก
https://txec.sosecure.co.th/register
Contact Us
☎️ Tel. 02-511-2422
📬 [email protected]
🌐 txec.sosecure.co.th
แหล่งที่มา :
- Netcraft: Bluekit Phishing-as-a-Service: Browser-in-the-Middle, Evolved
- CloudSEK: Bluekit Phishing as a Service (PhaaS)
- Microsoft: แนวทางการใช้ Phishing-resistant MFA


23/07/2026

Thai Cyber Boost 🇹🇭🔥พลังไทยช่วยไทย 60/40
โอกาสดีสำหรับคนไทยที่อยากอัปสกิล
ด้าน Cybersecurity ให้พร้อมรับมือโลกดิจิทัลอย่างมั่นใจ
SOSECURE ขอร่วมสนับสนุนการเรียนรู้ของคนไทย
เพื่อเพิ่มโอกาสในการลงทุนกับทักษะแห่งอนาคต
ในราคาที่เข้าถึงง่ายขึ้น
มอบส่วนลดสูงสุด 60% ทุกคอร์สใน Cyberdemy
ครอบคลุมตั้งแต่พื้นฐาน Cybersecurity ไปจนถึง
ทักษะเฉพาะทางที่นำไปต่อยอดในการทำงานได้จริง
💻 เรียนออนไลน์ได้ทุกที่
📚 เนื้อหาออกแบบโดยผู้เชี่ยวชาญ
🚀 เพิ่มทักษะ พร้อมสร้างโอกาสใหม่ในสายงาน Cybersecurity
📅 โปรโมชันตั้งแต่วันที่ 13 กรกฎาคม – 30 กันยายน 2569
" เริ่มต้นเรียนรู้วันนี้ เพื่อเพิ่มทักษะ เพิ่มโอกาส
และเตรียมพร้อมสำหรับอนาคตในโลกไซเบอร์ "
Click Here >> https://cyberdemy.co/courses
💬สนใจสมัครเรียนหรือสอบถามรายละเอียดเพิ่มเติม
Tel : 02-511-2422
LINE :
Website : [www.sosecure.co.th](http://www.sosecure.co.th/)
#ไทยช่วยไทย

#คอร์สออนไลน์
#เรียนCybersecurity

🔍 ทีม TXEC ลงสนามสอบสวนเหตุการณ์จริงในไทย: Backdoor ที่ซ่อนตัวเป็น "404 Not Found"เคยรู้ไหมว่า ไฟล์ที่ตอบกลับ "404 Not F...
21/07/2026

🔍 ทีม TXEC ลงสนามสอบสวนเหตุการณ์จริงในไทย: Backdoor ที่ซ่อนตัวเป็น "404 Not Found"

เคยรู้ไหมว่า ไฟล์ที่ตอบกลับ "404 Not Found" อาจไม่ได้หายไปจริงๆ แต่กำลังแอบรับคำสั่งจากแฮกเกอร์อยู่เงียบๆ?

นั่นคือสิ่งที่เกิดขึ้นจริงกับองค์กรแห่งหนึ่งในไทย และทีม TXEC เป็นคนลงสอบสวน

🕵️ สิ่งที่เราพบ:

ไฟล์ PHP Webshell ถูกฝังไว้บน Web Server โดยถูกออกแบบให้ตอบกลับ HTTP 404 เสมอ ไม่ว่าจะมีการเรียกใช้งานจริงหรือไม่ก็ตาม ทำให้ระบบ Log Monitoring ทั่วไปมองข้ามมันไปโดยสมบูรณ์

แต่ความจริงคือมันกำลังทำงานอยู่ตลอดเวลา รับคำสั่งผ่าน HTTP POST, ถอดรหัส Payload ด้วย base64, และรันโค้ดผ่าน eval() โดยไม่ทิ้งร่องรอยบน Disk

ยังไม่หมด — เราพบหลักฐานการเชื่อมต่อออกไปยัง External IP ที่เป็น Proxy/Tunnel Candidate ด้วย

📋 รายงานฉบับเต็มมีอะไรบ้าง:

✅ Attack Timeline วันต่อวันของเหตุการณ์จริง
✅ IOC ที่ยืนยันแล้ว: SHA-256 Hash, IP Address, User-Agent
✅ YARA Rule 3 ชุด พร้อมใช้งานใน SIEM/EDR
✅ Sigma Rule 2 ชุด สำหรับ Detection ทันที
✅ วิธีล่า Webshell แบบ Fake 404 ในระบบของคุณ
✅ Checklist Hardening สำหรับ Linux Web Server

🔒 บทความนี้เป็น Exclusive Content สำหรับสมาชิก TXEC

แต่เราเปิดให้อ่านฟรีแบบจำกัดเวลาก่อนนะ
→ อ่านก่อนหมดเวลา 👇
🔗 https://txec.sosecure.co.th/th/articles/Incident-Report-15July26

💡 อยากได้บทความแบบนี้ทุกเดือน?

สมัครสมาชิก TXEC ฟรี แล้วได้รับสิทธิ์เข้าถึง Exclusive Content ที่เขียนจากเหตุการณ์จริงในบริบทไทย โดยทีม Threat Intelligence ของ SOSECURE

🎁 สมาชิกฟรีได้รับ:
→ บทความ Exclusive Content บริบทไทย ที่ไม่มีที่ไหน
→ IOC และ Detection Rule จากเหตุการณ์จริง พร้อมใช้งานทันที
→ Monthly Threat Report สรุปภัยคุกคามรายเดือน
→ สิทธิ์เข้าร่วม Webinar และ Threat Talk

📝 สมัครฟรีได้เลย: https://txec.sosecure.co.th/th/register

รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า 🛡️

#รู้ก่อนรับมือก่อน

🚨ภัยคุกคามไซเบอร์ยุคใหม่ไม่ได้พยายาม “ทำลายระบบทันที” เสมอไปแต่เลือกใช้วิธีที่อันตรายกว่า คือ แฝงตัวให้เหมือนเป็นส่วนหนึ...
17/07/2026

🚨ภัยคุกคามไซเบอร์ยุคใหม่ไม่ได้พยายาม
“ทำลายระบบทันที” เสมอไป
แต่เลือกใช้วิธีที่อันตรายกว่า คือ
แฝงตัวให้เหมือนเป็นส่วนหนึ่งของระบบปกติ
ล่าสุดมีรายงานการพบ Mistic Backdoor
หรือ MLTBackdoor มัลแวร์ประเภท Backdoor ที่ถูกออกแบบมาเพื่อหลบการตรวจจับและคง
อยู่ในระบบองค์กร โดยใช้เทคนิคที่เกี่ยวข้อง
กับ DLL Sideloading ผ่านไฟล์ที่ดูเหมือนหรือ
เกี่ยวข้องกับเครื่องมือฝั่ง Microsoft Defender /
Endpoint Security ทำให้กิจกรรมบางส่วนดูคล้าย
กระบวนการที่ถูกต้องตามปกติ
📋 สิ่งที่น่ากังวลคือ Mistic ถูกเชื่อมโยงกับกลุ่ม
Initial Access Broker (IAB) ซึ่งมีบทบาท
ในการเจาะระบบองค์กร เพื่อสร้าง “จุดยืน”
ภายในเครือข่ายก่อนขายสิทธิ์เข้าถึงต่อให้กับ
กลุ่มอาชญากรรมไซเบอร์หรือกลุ่ม Ransomware
ในมุมขององค์กร นี่ไม่ใช่แค่ปัญหา Malware ทั่วไป
แต่เป็นสัญญาณว่า Endpoint Security เพียงอย่างเดียว
อาจไม่เพียงพอ หากไม่มีการตรวจจับพฤติกรรมผิดปกติ
การเฝ้าระวัง Threat Intelligence และการวิเคราะห์
เชิงลึกจากหลายแหล่งข้อมูลร่วมกัน
กรณี Mistic Backdoor แสดงให้เห็นแนวโน้มสำคัญของการโจมตีสมัยใหม่
คือการใช้เทคนิค Living-off-the-Land และ Trust Abuse โดยอาศัยไฟล์หรือกระบวนการที่ดูน่าเชื่อถือ เพื่อหลีกเลี่ยงการตรวจจับจาก Security Stack แบบเดิม
ประเด็นสำคัญไม่ใช่แค่การพบมัลแวร์ตัวใหม่ แต่คือผู้โจมตีมุ่งเน้นการแฝงตัวให้อยู่ในระบบได้นานที่สุด เพื่อหลบเลี่ยงการตรวจจับ ก่อนขยายสิทธิ์ เคลื่อนที่ภายในเครือข่าย และในบางกรณี สิทธิ์การเข้าถึงอาจถูกส่งต่อผ่าน Initial Access Broker ไปยังกลุ่ม Ransomware
สำหรับองค์กรไทย นี่คือเหตุผลว่าทำไมการมีเพียง
Antivirus หรือ EDR ยังไม่พอ แต่ต้องมีการเชื่อมโยง
ข้อมูลจาก Endpoint, Network, Identity, Cloud และ
Threat Intelligence เข้าด้วยกัน เพื่อมองเห็นพฤติกรรม
ผิดปกติก่อนที่เหตุการณ์จะลุกลามเป็น Incident ขนาดใหญ่.
🎯 สิ่งที่องค์กรควรให้ความสำคัญ
- ตรวจสอบพฤติกรรมผิดปกติของไฟล์ที่เกี่ยวข้องกับ Microsoft Defender หรือ Endpoint Security
- เฝ้าระวังการใช้เทคนิค DLL Sideloading และการรัน Payload แบบ In-memory
- ตรวจจับพฤติกรรม ClickFix หรือการหลอกให้ผู้ใช้คัดลอก/รันคำสั่งเอง
- ตรวจสอบการเชื่อมต่อ C2 ที่เข้ารหัสหรือใช้โดเมนที่ถูกสร้างแบบอัตโนมัติ
ใช้ Threat Intelligence เพื่ออัปเดต IOC, TTP และพฤติกรรมของภัยคุกคามอย่างต่อเนื่อง
สำหรับ TXEC เหตุการณ์นี้สะท้อนให้เห็นว่า
ภัยคุกคามไม่ได้หยุดอยู่ที่การป้องกันหน้าด่าน
แต่องค์กรจำเป็นต้องมีระบบแลกเปลี่ยนข่าวกรองภัยคุกคาม เพื่อรู้เท่าทันเทคนิคใหม่ ๆ และลดระยะเวลาในการตรวจจับและตอบสนอง
รู้ก่อน เห็นก่อน รับมือก่อน
คือหัวใจสำคัญของ Cyber Resilience ในยุคที่ผู้โจมตีเริ่มซ่อนตัวอยู่หลังเครื่องมือที่เราคุ้นเคย
ติดต่อเพื่อรับข้อมูลเพิ่มเติม ได้แล้ววันนี้ !!
👉 ลงทะเบียนเข้าร่วมเป็นสมาชิก
https://txec.sosecure.co.th/register
Contact Us
☎️ Tel. 02-511-2422
📬 [email protected]
🌐 txec.sosecure.co.th




🔴 นักวิจัยเผยช่องโหว่ OpenClaw เปิดทางโจมตีจาก WhatsApp สู่การรันโค้ดบนเครื่อง Hostนักวิจัยด้านความมั่นคงปลอดภัยเปิดเผยช...
13/07/2026

🔴 นักวิจัยเผยช่องโหว่ OpenClaw เปิดทางโจมตี
จาก WhatsApp สู่การรันโค้ดบนเครื่อง Host
นักวิจัยด้านความมั่นคงปลอดภัยเปิดเผยชุดช่องโหว่
ความรุนแรงสูง 3 รายการ ในแพลตฟอร์ม OpenClaw
ซึ่งเป็น AI Agent แบบ Open Source ที่สามารถ
เชื่อมต่อกับ WhatsApp และแอปแชตอื่น ๆ เพื่อรับ
คำสั่งและควบคุมเครื่องคอมพิวเตอร์ของผู้ใช้งาน
⚠️จุดที่น่ากังวลคือ ผู้โจมตีสามารถส่ง ข้อความผ่าน
WhatsApp เพียงข้อความเดียว ที่มีเนื้อหาซึ่ง
ออกแบบมาเป็นพิเศษ (Prompt Injection)
เพื่อหลอกให้ AI Agent ดำเนินการตามคำสั่ง
จนนำไปสู่การ ขโมยข้อมูลรับรอง (Credentials),
ยกระดับสิทธิ์ (Privilege Escalation) และท้ายที่สุด
รันโค้ดบนเครื่อง Host ที่ติดตั้ง OpenClaw ได้
หากระบบยังไม่ได้อัปเดตแพตช์และมีการตั้งค่า
ที่เอื้อต่อการโจมตี
🔍สิ่งที่นักวิจัยค้นพบ
การโจมตีอาศัยการเชื่อมโยงของช่องโหว่หลาย
รายการเข้าด้วยกัน ทำให้ AI Agent กลายเป็น
"ตัวกลาง" ที่ผู้โจมตีใช้ควบคุมเครื่องของเหยื่อ
โดยลำดับการโจมตีประกอบด้วย
- ส่งข้อความอันตรายผ่าน WhatsApp
- AI Agent ประมวลผลข้อความและเชื่อว่า
เป็นคำสั่งที่ถูกต้อง
- เข้าถึงหรือขโมย Credentials ที่จัดเก็บไว้
- ยกระดับสิทธิ์ของกระบวนการทำงาน
- สั่งรันคำสั่งบนระบบปฏิบัติการของเครื่อง
Host (Remote Code Ex*****on)
⚠️ทำไมเหตุการณ์นี้จึงน่ากังวล
เหตุการณ์นี้สะท้อนว่า Attack Surface
ของ AI Agent ไม่ได้จำกัดอยู่ที่ตัวโมเดล AI
แต่ขยายไปถึง
- แอปพลิเคชันรับส่งข้อความ
(WhatsApp, Telegram ฯลฯ)
- Memory และบริบทการสนทนา
- เครื่องมือ (Tools) ที่ Agent สามารถเรียกใช้
- ระบบปฏิบัติการ
- API Keys และ Credentials
- Docker หรือ Sandbox ที่ใช้รัน Agent
กล่าวคือ หาก AI Agent มีสิทธิ์เข้าถึงเครื่อง
หรือบริการต่าง ๆ มากเกินไป การโจมตีผ่าน
ข้อความเพียงข้อความเดียวอาจนำไปสู่การ
ยึดเครื่องได้ทั้งระบบ
🎯ผู้ได้รับผลกระทบ
ความเสี่ยงมีผลต่อผู้ที่ใช้งาน OpenClaw
โดยเฉพาะกรณีที่
- ใช้งานเวอร์ชันที่ยังไม่ได้ติดตั้งแพตช์ล่าสุด
- เชื่อมต่อ OpenClaw กับ WhatsApp หรือแพลตฟอร์มแชตอื่น
- อนุญาตให้ Agent เรียกใช้ Shell Commands หรือเครื่องมือที่มีสิทธิ์สูง
- เก็บ API Keys, Tokens หรือ Secrets ไว้ในสภาพแวดล้อมเดียวกับ Agent
🛡️คำแนะนำสำหรับองค์กร
องค์กรที่ใช้งาน AI Agent ควรดำเนินการดังนี้
1. อัปเดต OpenClaw เป็นเวอร์ชันล่าสุดที่มีการแก้ไขช่องโหว่
2. จำกัดสิทธิ์ของ AI Agent ตามหลัก Least Privilege
3. แยกสภาพแวดล้อม (Isolation/Sandbox) สำหรับการรัน Agent
4. ไม่อนุญาตให้ข้อความจากภายนอกสามารถสั่งงานเครื่องมือสำคัญได้โดยตรง
5. เพิ่มการตรวจสอบ Prompt Injection และตรวจสอบ Log ของการเรียกใช้ Tools อย่างต่อเนื่อง
6. แยกการจัดเก็บ Credentials และ Secrets ออกจาก Runtime ของ AI Agent
มุมมองจาก TXEC
กรณีนี้เป็นอีกตัวอย่างที่ชัดเจนว่า ความเสี่ยงของ
AI Agent ไม่ได้เกิดจากโมเดล LLM เพียงอย่างเดียว
แต่เกิดจาก "สิทธิ์" และ "การเชื่อมต่อ" ที่ Agent
มีต่อระบบจริง เมื่อ Agent สามารถเข้าถึงไฟล์
ระบบปฏิบัติการ และเครื่องมืออัตโนมัติได้มากขึ้น
ช่องทางโจมตีก็ขยายตามไปด้วย
ดังนั้น การออกแบบสถาปัตยกรรมที่แยกขอบเขต
ความเชื่อถือ (Trust Boundary) และควบคุมสิทธิ์
อย่างเหมาะสม จึงเป็นหัวใจสำคัญในการลดความ
เสี่ยงของระบบ Agentic AI
ติดต่อเพื่อรับข้อมูลเพิ่มเติม ได้แล้ววันนี้ !!
👉 ลงทะเบียนเข้าร่วมเป็นสมาชิก
https://txec.sosecure.co.th/register
Contact Us
☎️ Tel. 02-511-2422
📬 [email protected]
🌐 txec.sosecure.co.th
ที่มาแหล่งอ้างอิง:
The Hacker News , SecurityWeek








*****on

🔴 พบแคมเปญมัลแวร์ Edgecution ใช้ Microsoft Edge Extension เป็นช่องทางควบคุมระบบของเหยื่อจากรายงานแคมเปญมัลแวร์ที่ถูกตั้ง...
10/07/2026

🔴 พบแคมเปญมัลแวร์ Edgecution
ใช้ Microsoft Edge Extension
เป็นช่องทางควบคุมระบบของเหยื่อ
จากรายงานแคมเปญมัลแวร์ที่ถูกตั้ง
ชื่อว่า “Edgecution” ซึ่งมุ่งโจมตี
ผู้ใช้งานในองค์กรผ่านการปลอมตัว
เป็นฝ่าย IT และส่งข้อความผ่าน Microsoft Teams
เพื่อหลอกให้ดาวน์โหลดเครื่องมืออัปเดต หรือ
Spam Filter สำหรับ Outlook
เมื่อเหยื่อทำตามขั้นตอน ผู้โจมตีจะติดตั้ง
ส่วนขยายอันตรายบน Microsoft Edge พร้อม
Python Backdoor และสร้าง Scheduled Task
เพื่อเปิด Edge ในโหมด Headless
ทำให้ส่วนขยายสามารถทำงานได้โดยที่
ผู้ใช้งานไม่เห็นหน้าต่างเบราว์เซอร์ หรือ
การแจ้งเตือนตามปกติ
จุดสำคัญของการโจมตีคือการใช้ฟังก์ชัน
Native Messaging เพื่อเชื่อมต่อระหว่าง
Edge Extension กับโปรแกรมภายนอก
เบราว์เซอร์ ส่งผลให้ผู้โจมตีสามารถสั่ง
รันคำสั่งบน Windows ได้ เช่น
• รัน PowerShell และ Shell Command
• ดาวน์โหลดหรือสร้างไฟล์เพิ่มเติม
• ตรวจสอบ Process และข้อมูลระบบ
• รัน Python Code จากระยะไกล
• เปลี่ยนเซิร์ฟเวอร์ Command and Control
ลักษณะดังกล่าวทำให้ Edgecution
สามารถถูกใช้เป็นช่องทางตั้งหลักในระบบ
ดาวน์โหลดมัลแวร์เพิ่มเติม หรือ
เตรียมความพร้อมสำหรับการโจมตี
ในขั้นต่อไป รวมถึง Ransomware
สิ่งที่องค์กรควรตรวจสอบ
1. ข้อความ Microsoft Teams
ที่อ้างว่าเป็นฝ่าย IT และขอให้ติดตั้ง
Outlook Update หรือ Spam Filter
2. การเปิด msedge.exe พร้อมคำสั่ง
--headless หรือ --load-extension
3. Scheduled Task ที่เรียกใช้งาน
Microsoft Edge จากตำแหน่งผิดปกติ
4. Edge Extension หรือ
Native Messaging Host ที่ไม่ได้รับอนุญาต
5. Python Runtime, PowerShell Script
หรือ AutoHotKey Script ที่เพิ่งถูกสร้างขึ้น
6. การเชื่อมต่อ WebSocket ไปยัง
CloudFront Domain ที่ไม่เกี่ยวข้องกับระบบงาน
คำแนะนำเบื้องต้น
องค์กรควรจำกัดการติดตั้ง Browser Extension
ผ่าน Enterprise Policy อนุญาตเฉพาะ Extension
ที่ผ่านการตรวจสอบ และเฝ้าระวังการใช้งาน
PowerShell, AutoHotKey รวมถึง
Native Messaging Host ภายในระบบ
หากพบพฤติกรรมต้องสงสัย ควรแยกเครื่อง
ออกจากเครือข่าย ตรวจสอบ Scheduled Task,
Registry และ Credential ที่อาจถูกกรอก
ในเว็บไซต์ปลอม พร้อมเพิกถอน Session หรือ
Token ที่เกี่ยวข้องโดยเร็ว
กรณี Edgecution สะท้อนให้เห็นว่า
Browser Extension อาจถูกนำมาใช้เป็น
ส่วนหนึ่งของการโจมตีระดับระบบปฏิบัติการได้
หากผู้โจมตีสามารถหลอกให้เหยื่อติดตั้ง
องค์ประกอบเพิ่มเติมบนเครื่องสำเร็จ
ติดต่อเพื่อรับข้อมูลเพิ่มเติม ได้แล้ววันนี้ !!
👉 ลงทะเบียนเข้าร่วมเป็นสมาชิก
https://txec.sosecure.co.th/register
Contact Us
☎️ Tel. 02-511-2422
📬 [email protected]
🌐 txec.sosecure.co.th
ที่มาแหล่งอ้างอิง:
Zscaler ThreatLabz, BleepingComputer, Hive Pro








ที่อยู่

410, 34 ถนนรัชดาภิเษก แขวง สามเสนนอก เขต ห้วยขวาง
Bangkok
10310

เวลาทำการ

จันทร์ 09:00 - 18:00
อังคาร 09:00 - 18:00
พุธ 09:00 - 18:00
พฤหัสบดี 09:00 - 18:00
ศุกร์ 09:00 - 18:00

เว็บไซต์

แจ้งเตือน

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

ทางลัด

แชร์

ประเภท