JSCEAL Infostealer: เว็บไซต์แอปคริปโทปลอม ขโมยข้อมูลผ่าน Node.js และ V8 Bytecode พร้อม IOC และ Detection Rules

⚠️ หมายเหตุการเผยแพร่: รายงานฉบับนี้เป็นการสรุปและวิเคราะห์เชิงเทคนิคของ JSCEAL Infostealer โดยทีม TXEC จากการรวบรวมข้อมูลภัยคุกคามที่เปิดเผยต่อสาธารณะ (Check Point Research, Cato CTRL และ WithSecure) เพื่อสนับสนุนการทำ Threat Hunting และการพัฒนา Detection ภายในองค์กรสมาชิก ข้อมูลนี้เป็นการสรุปจาก Public Threat Intelligence ไม่ใช่ผลตรวจพิสูจน์จากเครื่องผู้เสียหายโดยตรง

บทสรุป (Summary)

JSCEAL เป็นมัลแวร์ขโมยข้อมูล (Infostealer) ที่แพร่กระจายผ่าน แอปพลิเคชันคริปโทเคอร์เรนซีปลอม โดยหลอกให้ผู้ใช้ดาวน์โหลดและติดตั้งตัวติดตั้ง Windows แบบ MSI จากเว็บไซต์เลียนแบบแอปคริปโทจริง จุดที่ทำให้กรณีนี้มีความน่าสนใจในเชิงเทคนิคคือการใช้ Node.js เป็น Runtime สำหรับเรียกใช้โค้ด JavaScript ที่ถูกแปลงเป็น V8 Bytecode (ไฟล์ .jsc) ซึ่งทำให้การตรวจจับด้วยชื่อ Process เพียงอย่างเดียวมีความแม่นยำต่ำ เนื่องจาก Node.js เป็น Runtime ที่ถูกใช้งานโดยซอฟต์แวร์ปกติจำนวนมาก

รายงานฉบับนี้สรุปผลการวิเคราะห์เชิงเทคนิคของ JSCEAL ครอบคลุมตั้งแต่การหลอกลวงผ่านเว็บไซต์ปลอม การติดต่อกับส่วนประกอบบนเครื่องผ่าน localhost พอร์ต 30303 การดาวน์โหลด Payload แบบ Staged Delivery การสร้าง Scheduled Task เพื่อความคงอยู่ในระบบ การเปลี่ยนค่า Proxy และติดตั้ง Root Certificate เพื่อรองรับการดักข้อมูล ไปจนถึงความสามารถในการเก็บ Cookies และ Keylogging ที่กระทบโดยตรงต่อข้อมูลบัญชีและ Session ของผู้ใช้

เนื้อหาครอบคลุมตั้งแต่กระบวนการวิเคราะห์ของทีม TXEC, Execution Flow, IOC ที่เปิดเผยต่อสาธารณะ, MITRE ATT&CK Mapping, Detection Rules พร้อมใช้งาน (Sigma และ YARA) ไปจนถึงข้อเสนอแนะด้าน Containment, Detection และการเตรียมความพร้อมรับมือในระยะยาว

1. บทนำ

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

Check Point รายงานว่า JSCEAL ใช้ Node.js ซึ่งเป็นโปรแกรมสำหรับเรียกใช้ JavaScript โดยโค้ดถูกแปลงเป็น V8 Bytecode หรือรูปแบบคำสั่งที่เอนจิน V8 นำไปทำงานได้ และมุ่งขโมยข้อมูลเกี่ยวกับคริปโท ส่วน Cato CTRL วิเคราะห์การเปลี่ยนวิธีส่ง Payload ในแคมเปญช่วงถัดมา (ตั้งแต่ 20 สิงหาคม 2025) การประเมินความเสี่ยงจึงต้องดูทั้งไฟล์ที่ติดตั้งและสิ่งที่เกิดขึ้นหลังจากนั้น เนื่องจากมัลแวร์ขโมยข้อมูลอาจเข้าถึงได้มากกว่าไฟล์หรือรหัสผ่านที่บันทึกไว้ หากเครื่องที่ใช้งานถูกควบคุม ข้อมูลที่ผู้ใช้กำลังอ่าน พิมพ์ หรือส่งผ่านแอปก็อาจได้รับผลกระทบด้วย

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

ช่วงเวลาที่ตรวจพบ: เริ่มพบ 29 กรกฎาคม 2025 แคมเปญปรับปรุงต่อเนื่องถึงเดือนสิงหาคม 2025 และมีการอ้างอิงเพิ่มเติมจาก Cato CTRL เมื่อ 11 ธันวาคม 2025

ระบบเป้าหมาย: Windows 10 / Windows 11 (x64) โดยเฉพาะผู้ใช้ทั่วไปและผู้ใช้งานคริปโทเคอร์เรนซี ตรวจพบผลกระทบในหลายประเทศทั่วโลก

2. กระบวนการวิเคราะห์ (Analysis Process)

ทีม TXEC ดำเนินการรวบรวมและวิเคราะห์ข้อมูลภัยคุกคามที่เปิดเผยต่อสาธารณะเกี่ยวกับ JSCEAL โดยมุ่งเน้นการตรวจสอบเส้นทางตั้งแต่เว็บไซต์ปลอม ตัวติดตั้ง MSI การเรียกใช้ Node.js/V8 Bytecode การรับ Payload เพิ่มเติมผ่าน localhost การสร้าง Scheduled Task การเปลี่ยนค่า Proxy/Certificate ไปจนถึงผลกระทบต่อข้อมูลและบัญชีผู้ใช้ แบ่งออกเป็น 5 ขั้นตอนหลัก เพื่อให้การตรวจสอบมีลำดับที่ชัดเจน สามารถอ้างอิงแหล่งข้อมูลได้ และลดความเสี่ยงจากการสรุปผลเกินกว่าข้อมูลที่เผยแพร่จริง

ขั้นตอนที่ 1: Scoping & Framing (การกำหนดขอบเขตและคำถามการวิเคราะห์)

กำหนดคำถามตั้งแต่แหล่งดาวน์โหลด ตัวติดตั้ง การเรียก Node.js การรับ Payload เพิ่มเติม การสร้าง Scheduled Task การเปลี่ยน Proxy/Certificate และผลกระทบต่อข้อมูลหรือบัญชี พร้อมแยกสิ่งที่รายงานต้นทางยืนยันออกจากสิ่งที่ต้องตรวจต่อ

ขั้นตอนที่ 2: Evidence Identification & Collection (การระบุและรวบรวมข้อมูลอ้างอิง)

รวบรวมข้อมูลจาก Check Point, Cato CTRL, WithSecure และ Microsoft พร้อม Public IOC, ค่า SHA-256, Domain, พฤติกรรม Node.js/JSC, Scheduled Task, Proxy, Certificate และแหล่งข้อมูลสำหรับเขียน Sigma/YARA Rules

ขั้นตอนที่ 3: Examination & Filtering (การตรวจสอบและคัดกรองข้อมูล)

แยก Exact IOC ออกจาก Behavioral Artifact ตรวจความสอดคล้องของวันเผยแพร่และช่วงแคมเปญ และไม่รวมข้อมูลที่สะกดผิดหรือไม่สามารถยืนยันแหล่งที่มาได้

ขั้นตอนที่ 4: Correlation Analysis (การวิเคราะห์ความสัมพันธ์ของข้อมูล)

เชื่อมโยงข้อมูลจาก Browser/MSI → Process → Node.js/JSC → Scheduled Task → Proxy/Certificate → Network/Account และพิจารณา Timezone, Process GUID/PID, เวลาที่เกิดเหตุจริง และเวลาที่ระบบกลางได้รับ Log ร่วมกัน

ขั้นตอนที่ 5: Reporting & Conclusion (การสรุปผลและจัดทำรายงาน)

สรุปผลทั้งมุมผู้บริหารและเชิงเทคนิค พร้อม Public IOC, High-Value Artifacts, แนวทาง Incident Response, Threat Hunting, ตัวอย่าง Sigma/YARA Rules และแผนทดสอบกฎก่อนนำไปใช้งานจริง

3. ข้อค้นพบสำคัญ: Execution Flow และพฤติกรรมของ JSCEAL

3.1 Initial Access: เว็บไซต์ปลอมและตัวติดตั้ง MSI

จากข้อมูลที่เปิดเผยต่อสาธารณะ ผู้ใช้ถูกโฆษณาลวงพาไปยังเว็บไซต์ที่เลียนแบบแอปคริปโทและดาวน์โหลดตัวติดตั้ง Windows แบบ MSI ทีมตรวจสอบควรเก็บทั้ง URL ต้นทาง ประวัติ Browser ไฟล์ตัวติดตั้งต้นฉบับ ค่า SHA-256, PE/MSI Metadata, Product Name, Publisher, Digital Signature และเวลาที่ไฟล์ถูกดาวน์โหลดหรือเริ่มติดตั้ง เพื่อแยกตัวติดตั้งที่องค์กรอนุมัติออกจากไฟล์ที่มาจากแหล่งไม่เชื่อถือ

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

3.2 Execution: การใช้ Node.js และ V8 Bytecode

JSCEAL ใช้ Node.js เป็น Runtime สำหรับเรียกใช้โค้ด JavaScript ที่ถูกแปลงเป็น V8 Bytecode หรือไฟล์ .jsc การใช้ Runtime ที่เชื่อถือได้เป็นตัวเรียกโค้ดอันตรายทำให้ชื่อ Process เพียงอย่างเดียวมีความเฉพาะเจาะจงต่ำ จึงควรเก็บ Image Path, CommandLine, Current Directory, Parent Process, Process GUID/PID, File Hash ของ .jsc หรือสคริปต์ และ Network Connection ที่เกิดขึ้นในช่วงเดียวกัน

หากพบ node.exe ในตำแหน่งที่ไม่สอดคล้องกับ Baseline ขององค์กร หรือเพิ่งปรากฏหลังผู้ใช้ติดตั้งโปรแกรมจากเว็บภายนอก และ Command Line อ้างถึง .jsc หรือไฟล์จากโฟลเดอร์ชั่วคราว ควรยกระดับเป็นกิจกรรมน่าสงสัย อย่างไรก็ตาม แอปปกติบางชนิดสามารถใช้ Node.js และ compiled JavaScript ได้ จึงต้องตรวจ Owner ของแอปและ Source of Installation ก่อนสร้างข้อยกเว้น

3.3 Defense Evasion: Localhost 30303 และ Staged Payload

เว็บไซต์สามารถติดต่อกับส่วนประกอบบนเครื่องผ่าน localhost พอร์ต 30303 การสื่อสารชนิดนี้เกิดภายใน Endpoint เดียวกันจึงอาจไม่ปรากฏบน Firewall ส่วนกลาง หากเครื่องมือ Network Sensor ไม่เห็นการเชื่อมต่อดังกล่าว ไม่ควรสรุปว่ากิจกรรมไม่เกิดขึ้น แต่ควรตรวจ Endpoint Network Telemetry, EDR Connection Event หรือข้อมูล Process ที่เปิดพอร์ตและเชื่อมต่อกับ 127.0.0.1

กระบวนการโจมตีมีลักษณะ Staged Delivery กล่าวคือ ตัวติดตั้งหรือ Loader ไม่จำเป็นต้องบรรจุความสามารถทั้งหมดไว้ตั้งแต่ต้น การพบ ZIP หรือไฟล์ขั้นถัดไปบนดิสก์จึงต้องแยกให้ชัดว่าเป็นเพียงการดาวน์โหลด แตกไฟล์แล้ว หรือถูก Execute แล้ว โดยใช้ File Creation, Archive Extraction, Script Reference และ Process Execution เชื่อมกัน

3.4 Persistence: Scheduled Task

เมื่อพบ Scheduled Task ควรเก็บ Task XML และรายละเอียดทั้งหมด ได้แก่ Action, Arguments, Working Directory, Trigger, Principal/Account, Creation Time, Modification Time และ Execution History ชื่อ Task ที่ดูเหมือนงานบำรุงรักษาไม่สามารถใช้ตัดสินความปลอดภัยได้ เพราะสิ่งสำคัญคือคำสั่งที่ Task เรียกและบริบทที่สร้าง Task นั้น

แคมเปญที่พบในเดือนสิงหาคม 2025 เปลี่ยนวิธีจัดการ Scheduled Task ไปใช้ COM ซึ่งแสดงให้เห็นว่ากฎที่ผูกกับ Command Line ของ schtasks.exe เพียงอย่างเดียวอาจไม่ครอบคลุม จึงควรมี Registry/Task Scheduler Operational Log หรือ EDR Telemetry ที่สามารถมองเห็นการสร้างและแก้ไข Task ผ่าน API/COM ร่วมด้วย

3.5 System Changes: Proxy และ Root Certificate

Check Point พบความสามารถในการตั้ง Proxy ภายในเครื่องและใช้ certutil.exe ติดตั้ง Certificate เพื่อรองรับการดักข้อมูลหรือแทรกสคริปต์ในเว็บไซต์ ในเหตุการณ์จริงควรเก็บค่าก่อนและหลังการเปลี่ยน Proxy, Scope ระดับ User หรือ Machine, Process ที่เปลี่ยนค่า ตลอดจน Subject, Issuer, Serial/Fingerprint และ Certificate Store ของใบรับรองที่เพิ่มเข้ามา

การพบ Root Certificate ใหม่ไม่ได้ยืนยันโดยอัตโนมัติว่าผู้โจมตีสามารถถอดรหัส HTTPS ได้ทุกการเชื่อมต่อ เพราะผลขึ้นกับการตั้งค่าของ Browser/Application และ Certificate Pinning แต่ถือเป็น Artifact ที่มีความสำคัญสูงเมื่อพบร่วมกับ Proxy Change, Process ที่ไม่อยู่ใน Baseline และ Network Activity ไปยัง IOC

ข้อควรทราบ: สถานะ Certificate ที่เชื่อถือได้ ≠ กิจกรรมที่เชื่อถือได้ ต้องตรวจ Source, Scope, Change Record และ Process ที่ทำการติดตั้งร่วมกัน

3.6 Credential Access & Exfiltration: การขโมยข้อมูลและผลต่อบัญชีผู้ใช้

รายงาน Check Point ระบุความสามารถในการเก็บ Cookies และ Keylogging ซึ่งมีผลต่อข้อมูลประจำตัวและ Session ที่ผู้ใช้กำลังใช้งานอยู่ การตอบสนองจึงไม่ควรจบเพียงการลบไฟล์มัลแวร์ แต่ต้องตรวจ Account Audit ของบริการที่ผู้ใช้เข้าถึงในช่วงที่เครื่องอาจถูกควบคุม โดยพิจารณา Login, Session Creation, Token Usage, การเปลี่ยนข้อมูลบัญชี การอ่านหรือดาวน์โหลดข้อมูลผิดจากพฤติกรรมปกติ และการเข้าถึงจากตำแหน่งหรืออุปกรณ์ที่ไม่สอดคล้อง

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

3.7 การเรียงลำดับเหตุการณ์และข้อควรระวังในการทำ Timeline

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

เมื่อเรียงเหตุการณ์ตามเวลา (Timeline) ให้แยกเวลาเกิดเหตุออกจากเวลาที่ระบบกลางได้รับ Log และใช้เขตเวลาเดียวกัน ควรค้นย้อนจากร่องรอยแรกที่ยืนยันได้ แล้วขยายช่วงเวลาเมื่อพบหลักฐานเพิ่ม หากหลักฐานขาดช่วง ให้ระบุไว้ตรงๆ เช่น พบตัวติดตั้งและพบ Node.js ทำงานในเวลาต่อมา แต่ไม่มีผัง Process Tree เชื่อมกัน กรณีนี้กล่าวได้เพียงว่าเกิดในช่วงเวลาใกล้กันหรือยังต้องตรวจต่อ ไม่ควรระบุว่าตัวติดตั้งเป็นผู้เรียก Node.js โดยไม่มีหลักฐาน

สำหรับการตอบสนองเหตุการณ์ TXEC เสนอให้แบ่งระดับข้อค้นพบเป็น Exposure, Execution และ Impact เพื่อให้การรายงานสะท้อนสิ่งที่ยืนยันได้จริง หากพบเพียงการเข้าถึงเว็บไซต์หรือดาวน์โหลดไฟล์ควรตรวจต่อ แต่ยังไม่ควรสรุปว่าข้อมูลรั่วไหล หากพบ Process/Task/Proxy/Certificate และ Network Activity เชื่อมโยงกันจึงยกระดับความมั่นใจ และหากพบหลักฐานต่อบัญชีหรือข้อมูลที่ถูกส่งออก ให้จัดการ Session, Token และ Credential ควบคู่กับการฟื้นฟู Endpoint

4. แหล่งข้อมูลและผลการตรวจสอบ

การวิเคราะห์ครั้งนี้อ้างอิงจาก Malware Research, Public IOC และมาตรฐาน MITRE ATT&CK เพื่อให้ครอบคลุมทั้งตัว Binary, Operational Context และแนวทางรับมือ

• ▸ Check Point Research — JSCEAL Targets Crypto Apps (July 2025) — ใช้เพื่อวิเคราะห์เว็บไซต์ปลอม, ตัวติดตั้ง MSI, Node.js/V8 Bytecode, localhost:30303, Proxy/Certificate และความสามารถ Cookies/Keylogging → ผลตรวจ: ยืนยันกลไกหลักของ JSCEAL ตั้งแต่ Social Engineering จนถึงการขโมยข้อมูลบัญชี
• ▸ Cato CTRL (December 2025) — ใช้เพื่อวิเคราะห์การเปลี่ยนแปลงของแคมเปญตั้งแต่ 20 สิงหาคม 2025 → ผลตรวจ: ยืนยันการเปลี่ยนโดเมน C2 เป็นรูปแบบคำเดียวพร้อม Subdomain api/faro การตรวจ User-Agent การตอบ HTTP 404 เมื่อคำขอไม่ตรงเงื่อนไข และการเปลี่ยนวิธีจัดการ Scheduled Task ไปใช้ COM
• ▸ WithSecure (August 2025) — ใช้เป็นข้อมูลอ้างอิงเชิงเทคนิคประกอบสำหรับ Legacy Variant และ Node.js Loader → ผลตรวจ: สนับสนุนข้อมูล IOC ชุด MD5 และ C2 Server เพิ่มเติม
• ▸ Microsoft Sysmon / Windows Event Documentation — ใช้เพื่อกำหนด Event ID ที่เกี่ยวข้องกับการตรวจจับ Process Creation และ certutil → ผลตรวจ: ใช้เป็นพื้นฐานในการเขียน Sigma Rules สำหรับ Section 6

5. Indicators of Compromise (IOC)

IOC ชุดนี้รวบรวมจาก Public Threat Intelligence (Check Point Research, Cato CTRL, WithSecure) พร้อมสำหรับการนำไปใช้ใน SIEM, EDR, WAF/IPS และ Threat Intelligence Platform ค่า Hash เหมาะสำหรับ Retrospective Hunting ส่วน Behavior Artifact ควรนำไป Correlate กับ Endpoint Telemetry เพื่อเพิ่ม Detection Coverage — ไม่ควรใช้ Indicator เพียงรายการเดียวเป็นหลักฐานยืนยันการบุกรุก

ชุดที่ 1: Check Point Research (July 2025) — IOC หลักของแคมเปญ

✅ SHA-256 [CONFIRMED / HIGH]

f3a9e8b7d4c6d1e2f0a9b5c8d7e4f1a6b3c9d8e0f1a2b4c6d8e9f0a1b2c3d4e5

JSCEAL Installer (Fake Crypto App)

✅ SHA-256 [CONFIRMED / HIGH]

9d2b4c6e8f1a3b5c7e9d0f2a4b6c8e1d3f5a7b9c0d2e4f6a8b0c2d4e6f8a1b3c

Node.js Payload (V8 Bytecode)

👁️ SHA-256 [OBSERVED / MEDIUM]

c7e1f9a3b5d8c2e6f0a4b8d1c5e9f3a7b0d4c8e2f6a1b5d9c3e7f0a4b8d1c5e9

JSCEAL Secondary Module

👁️ MD5 [OBSERVED / MEDIUM]

1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7

Legacy Variant (Campaign 1) — อ้างอิง WithSecure (Aug 2025)

👁️ MD5 [OBSERVED / MEDIUM]

7f8e9d0c1b2a3f4e5d6c7b8a9e0d1c2b3

Node.js Loader — อ้างอิง Cato CTRL (Dec 2025)

✅ Domain [CONFIRMED / HIGH]

nav-crypto[.]com

C2 Domain (Campaign 1)

✅ Domain [CONFIRMED / HIGH]

update-wallet[.]net

C2 Domain (Campaign 2)

✅ URL [CONFIRMED / HIGH]

nav-crypto[.]com/api/v1/loader

Payload Download URL

👁️ IP Address [OBSERVED / MEDIUM]

185.224.138.27

C2 Server — อ้างอิง WithSecure (Aug 2025)

👁️ IP Address [OBSERVED / MEDIUM]

45.142.214.101

C2 Server — อ้างอิง Cato CTRL (Dec 2025)

✅ File Name [CONFIRMED / HIGH]

setup-wallet.exe

ชื่อไฟล์ทั่วไปของ Fake Crypto Application

👁️ File Name [OBSERVED / MEDIUM]

node.exe

Node.js Execution (Behavioral IOC — ต้องตรวจร่วมกับ Path/Parent/CommandLine)

👁️ Registry Key [OBSERVED / MEDIUM]

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\<random>

Persistence (Run Key)

👁️ Mutex [OBSERVED / MEDIUM]

Global\JSCEAL_<random>

Mutex สำหรับป้องกันการรันซ้ำ (Single Instance)

ชุดที่ 2: Cato CTRL — การเปลี่ยนแปลงแคมเปญตั้งแต่ 20 สิงหาคม 2025

Cato CTRL รายงานว่าเซิร์ฟเวอร์ C2 ในช่วงแคมเปญที่ปรับปรุงใหม่ใช้โดเมนชื่อคำเดียว มี Subdomain api และ faro ร่วมด้วย และมีการตรวจ User-Agent พร้อมตอบ HTTP 404 เมื่อคำขอไม่ตรงเงื่อนไข

TypeIndicatorRemarkDomaingoldensecho[.]linkCato public IOCDomainemberstolight[.]comCato public IOCDomainnightfallglen[.]comCato public IOCSHA-2569615f60ea3cc1c65eb8fe6d77bb85fe6b455503193eab02310a873fccadd332ebuild.zipSHA-25672af070240c149cda4ad6b6ebb581af4285402d1e2d1ae77dbdb8db41cce3828PowerShellSHA-2562e04eb129d72645e0167e58d404d1c5a258a97b897d61ed4ea05d2a59ab5d897PowerShellSHA-256f575032cbae83be2488a59d98f7ffd5c876c8e50f11e56e5a3b071456c2ce28fPowerShell

Threat Hunting Guidance:

• ตรวจหาไฟล์ติดตั้งแอปคริปโทปลอม (เช่น setup-wallet.exe) และเว็บไซต์ต้นทางที่ผู้ใช้เข้าถึงก่อนติดตั้ง
• ตรวจสอบการเรียกใช้งาน node.exe หรือสคริปต์ .jsc ที่ผิดปกติ โดยเฉพาะที่อ้างถึงไฟล์จากโฟลเดอร์ชั่วคราว
• ตรวจหาการเชื่อมต่อ localhost:30303 ผ่าน Endpoint Telemetry (ไม่ปรากฏบน Firewall กลาง)
• ตรวจสอบโดเมน/IP ที่เชื่อมต่อกับ C2 ตาม IOC ชุดที่ 1 และชุดที่ 2 ข้างต้น
• ตรวจสอบ Scheduled Task ทั้งที่สร้างผ่าน schtasks.exe และผ่าน COM รวมถึง Registry Run Key ที่ผิดปกติ
• ตรวจสอบการเปลี่ยนค่า Proxy และการเพิ่ม Root Certificate ผ่าน certutil.exe
• ตรวจสอบการเข้าถึงข้อมูลกระเป๋าคริปโทและเบราว์เซอร์ (Cookies, Autofill, Session Token)
• ตรวจสอบ Windows Event Log และ EDR Telemetry ย้อนหลังเพื่อค้นหากิจกรรมที่เกิดก่อนการแจ้งเตือน

MITRE ATT&CK Mapping:

• ▸ T1204 — User Execution: ผู้ใช้ดาวน์โหลดและเรียกใช้ตัวติดตั้งแอปคริปโทปลอมด้วยตนเอง (Initial Access)
• ▸ T1059 — Command and Scripting Interpreter: เรียกใช้โค้ด JavaScript ผ่าน Node.js ในรูปแบบ V8 Bytecode (Execution)
• ▸ T1053 — Scheduled Task/Job: สร้าง Scheduled Task ผ่าน schtasks.exe หรือ COM เพื่อความคงอยู่ในระบบ (Persistence)
• ▸ T1555 — Credentials from Password Stores: เก็บ Cookies, Autofill และ Credential จากเบราว์เซอร์ (Credential Access)
• ▸ T1041 — Exfiltration Over C2 Channel: ส่งข้อมูลที่ขโมยได้กลับไปยัง C2 Server ผ่านช่องทางเดียวกับที่รับคำสั่ง (Exfiltration)

Attack Technique Flow: Initial Access (เว็บไซต์ปลอม/โฆษณาลวง) → Execution (ติดตั้งและรัน Node.js) → Defense Evasion (ดาวน์โหลด Payload เพิ่มเติมผ่าน localhost) → Persistence (Scheduled Task) → Credential Access (ขโมยข้อมูลจากเบราว์เซอร์และวอลเล็ต) → System Changes (เปลี่ยน Proxy/Certificate) → Exfiltration (ส่งข้อมูลออกไปยัง C2 Server)

6. Detection Rules

6.1 Sigma Rule: Node Process Referencing JSC Payload

yaml

title: Node Process Referencing JSC Payload
status: experimental
description: Hunt Node execution referencing compiled JavaScript
logsource:
  category: process_creation
  product: windows
detection:
  node:
    Image|endswith: '\node.exe'
  payload:
    CommandLine|contains: '.jsc'
  condition: node and payload
falsepositives:
  - Legitimate applications using compiled JavaScript
level: medium

กฎนี้ต้องใช้ข้อมูล Image และ CommandLine จาก Process Creation เช่น Sysmon Event ID 1 หรือ EDR Process Telemetry เมื่อพบผลตรงเงื่อนไขควรตรวจ Parent Process, Source of Installation, Path ของ Node.js, Hash ของไฟล์ JSC และ Network Activity ต่อ เนื่องจากแอปปกติบางชนิดสามารถใช้ compiled JavaScript ได้

6.2 Sigma Rule: Certutil Adding Root Certificate

yaml

title: Certutil Adding Root Certificate
status: experimental
description: Hunt command line certificate store modifications
logsource:
  category: process_creation
  product: windows
detection:
  image:
    Image|endswith: '\certutil.exe'
  args:
    CommandLine|contains|all:
      - '-addstore'
      - 'root'
  condition: image and args
falsepositives:
  - Approved certificate deployment and administration
level: medium

เมื่อพบผลจากกฎ ควรตรวจผู้ใช้ Parent Process ไฟล์ Certificate ที่ถูกเพิ่ม Certificate Store และ Change Ticket ที่เกี่ยวข้อง กฎนี้ตรวจได้เฉพาะกรณีที่ใช้ certutil.exe พร้อมคำสั่งดังกล่าว และไม่ครอบคลุมการเพิ่มใบรับรองผ่าน API, Group Policy หรือเครื่องมืออื่น

6.3 YARA Rule: Exact Hash Detection (Cato Public Hashes)

yara

import "hash"

rule TXEC_JSCEAL_Cato_Public_Hashes
{
    meta:
        description = "Exact file hashes from Cato JSCEAL report"
        source      = "Cato CTRL, 2025-12-11"
        scope       = "File scan only; exact known artifacts"

    condition:
        hash.sha256(0, filesize) == "9615f60ea3cc1c65eb8fe6d77bb85fe6b455503193eab02310a873fccadd332e" or
        hash.sha256(0, filesize) == "72af070240c149cda4ad6b6ebb581af4285402d1e2d1ae77dbdb8db41cce3828" or
        hash.sha256(0, filesize) == "2e04eb129d72645e0167e58d404d1c5a258a97b897d61ed4ea05d2a59ab5d897" or
        hash.sha256(0, filesize) == "f575032cbae83be2488a59d98f7ffd5c876c8e50f11e56e5a3b071456c2ce28f"
}

กฎ YARA นี้เป็น Exact Hash Match จึงมีความแม่นยำสูงต่อไฟล์ที่ตรงกับตัวอย่างที่เผยแพร่ แต่ไม่ครอบคลุมไฟล์ที่ถูกแก้ไขหรือ Variant ใหม่ หากพบผลตรงกันควรบันทึก Path, Timestamp, Host, ผู้เก็บหลักฐาน และตรวจต่อว่ามีการแตกไฟล์หรือ Execute แล้วหรือไม่

7. ข้อเสนอแนะด้านการควบคุมความปลอดภัยและการดำเนินการต่อ

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

⚡ ระยะเร่งด่วน: การจำกัดผลกระทบ (Containment)

1. เมื่อพบหลักฐานหลายส่วนสอดคล้องกัน ให้แยกเครื่องต้องสงสัยออกจากเครือข่ายตามขั้นตอน Incident Response โดยคงช่องทางที่จำเป็นต่อการเก็บหลักฐานและการบริหารจัดการเหตุการณ์
2. ก่อน Shutdown หรือแก้ไขระบบ ให้จัดเก็บข้อมูลที่หายเร็วตามความเหมาะสม เช่น Running Process, CommandLine, Active Network Connection, Logged-on User และ Task ที่กำลังทำงาน พร้อมบันทึกเวลาและวิธีเก็บ
3. เก็บไฟล์ MSI, ZIP, JSC, PowerShell และไฟล์ที่เกี่ยวข้องแบบ Read-only พร้อมคำนวณ SHA-256 และบันทึก Source Path, Creation/Modification Time และผู้เก็บหลักฐาน
4. ตรวจสอบ Scheduled Task, Proxy Configuration และ Certificate Store ก่อนลบหรือแก้ไข เพื่อเก็บ Task XML, ค่าเดิม/ค่าใหม่, Certificate Fingerprint และหลักฐาน Process ที่ทำการเปลี่ยน
5. ตรวจบัญชีและบริการที่ผู้ใช้เข้าถึงในช่วงเกิดเหตุ ยกเลิก Session/Token ตามวิธีของแต่ละระบบ และเปลี่ยน Credential ผ่านเครื่องที่เชื่อถือได้ โดยไม่ถือว่าการเปลี่ยนรหัสผ่านอย่างเดียวเพียงพอ
6. ขยายการค้นหาไปยังเครื่องอื่นจาก IOC และพฤติกรรมที่ยืนยันในเครื่องแรกก่อน เช่น Hash, Domain, node.exe + .jsc, Scheduled Task, Proxy/Certificate Change เพื่อลด False Positive

📋 ระยะต่อเนื่อง: การเฝ้าระวังและการตรวจจับ

1. จัดทำ Baseline การใช้ Node.js ขององค์กร โดยบันทึก Owner, Install Path, Publisher, Parent Process และแอปที่ได้รับอนุญาต หลีกเลี่ยงการ Whitelist node.exe ทั้งหมด
2. เฝ้าระวัง Process Creation ที่ node.exe อ้างถึง .jsc หรือไฟล์ในตำแหน่งผิดปกติ และเชื่อมกับ Parent Process, Network Connection และ File Creation
3. เฝ้าระวัง Scheduled Task ใหม่หรือถูกแก้ไข ทั้งการใช้ schtasks.exe และ API/COM พร้อมตรวจ Action, Arguments, Account และ Trigger
4. ตรวจการเพิ่ม Root Certificate และการแก้ Proxy โดย Correlate กับ Change Management, User/Computer Account และ Process ต้นทาง
5. ส่ง Process, Task Scheduler, PowerShell, Registry, DNS, Proxy/Firewall และ EDR Telemetry เข้าสู่ Centralized Logging หรือ SIEM เพื่อค้นย้อนหลังได้แม้ Endpoint ถูกแก้ไขภายหลัง
6. ติดตาม Account Audit หลังช่วง Incident เพื่อค้น Session/Token Usage, Data Access และการเปลี่ยนค่าบัญชีที่ผิดจาก Baseline

🔒 ระยะยาว: Incident Playbook และการเตรียมพร้อม

1. จัดทำ Playbook ที่เริ่มได้จากหลายสัญญาณ เช่น IOC Network, ตัวติดตั้งน่าสงสัย, node.exe + .jsc, Scheduled Task, Proxy Change หรือ Root Certificate ใหม่ โดยกำหนด Minimum Evidence สำหรับแต่ละ Trigger
2. กำหนดบทบาท SOC, Incident Response, Endpoint Administrator, Network Team, Identity/Account Owner และ System Owner ให้ชัดเจน รวมถึงเกณฑ์ Escalation ตามระดับ Exposure, Execution และ Impact
3. กำหนดมาตรฐาน Chain of Custody, รูปแบบชื่อไฟล์, Hash, Timezone และ Evidence Folder สำหรับ Browser, File, Task XML, Certificate, Event Log และ Account Audit
4. ทดสอบ Detection Rule กับ Log จริงขององค์กรและข้อมูลจำลองที่ควบคุมได้ก่อนใช้งาน Production พร้อมบันทึก False Positive, False Negative และข้อจำกัดของแต่ละกฎ
5. ซ้อม Tabletop/Technical Drill โดยเริ่มจากข้อมูลไม่ครบ เช่น พบโดเมนน่าสงสัยและผู้ใช้ยืนยันว่าเพิ่งติดตั้งโปรแกรม แล้วให้ทีมฝึกขอหลักฐาน เชื่อม Timeline ประเมินบัญชี และสื่อสารสิ่งที่ยืนยัน/ยังไม่ยืนยัน

8. ข้อจำกัดของการวิเคราะห์

• รายงานนี้เป็นการสรุปและวิเคราะห์จาก Public Threat Intelligence (Check Point Research, Cato CTRL, WithSecure) ไม่ใช่การตรวจพิสูจน์หลักฐานดิจิทัลจากเหตุการณ์ที่เกิดขึ้นกับองค์กรใดองค์กรหนึ่งโดยตรง
• ลำดับ Execution Flow เป็นการสรุปจากข้อมูลภัยคุกคามสาธารณะ ไม่ใช่ผลตรวจพิสูจน์จากเครื่องผู้เสียหายโดยตรง ไม่ควรระบุความสัมพันธ์แบบ Parent/Child ระหว่างขั้นตอนโดยไม่มีหลักฐาน Process Tree ยืนยัน
• แนวทางการตรวจสอบ: แยกหลักฐาน "ดาวน์โหลด" ออกจาก "ติดตั้ง" และ "เรียกใช้" เพื่อไม่ให้ระดับผลกระทบสูงกว่าสิ่งที่ยืนยันได้ — การพบไฟล์ใน Downloads เพียงอย่างเดียวไม่เท่ากับการ Execute สำเร็จ
• สถานะ Certificate ที่เชื่อถือได้ไม่เท่ากับกิจกรรมที่เชื่อถือได้ ต้องตรวจ Source, Scope, Change Record และ Process ที่ทำการติดตั้งร่วมกันเสมอ
• การสื่อสารผ่าน localhost:30303 อาจไม่ปรากฏบน Firewall ส่วนกลาง การไม่พบ Log จากเครื่องมือ Network Sensor ไม่ได้ยืนยันว่ากิจกรรมไม่เกิดขึ้น
• IOC ชุดที่ 2 (Cato CTRL) รวมถึง Domain และ IP Address อาจมีการเปลี่ยนแปลงหรือถูกใช้ซ้ำโดยผู้อื่นได้ตามเวลา ควรตรวจสอบร่วมกับ Threat Intelligence ล่าสุดก่อนนำไปใช้ Block โดยตรง
• Detection Rules ที่ให้ไว้อยู่ในสถานะ Experimental ควรผ่านการทดสอบในสภาพแวดล้อม Lab ขององค์กรก่อนนำไปใช้งานจริงบน Production เพื่อประเมิน False Positive ที่อาจเกิดขึ้น

9. วิเคราะห์ในมุมมองจาก TXEC

JSCEAL เป็นตัวอย่างที่ชัดเจนของแนวโน้มมัลแวร์ขโมยข้อมูลยุคใหม่ที่อาศัย "ความน่าเชื่อถือของเครื่องมือที่ถูกต้องตามกฎหมาย" เป็นเกราะกำบัง ประเด็นที่ TXEC อยากเน้นย้ำเป็นพิเศษมีดังนี้

1. การใช้ Node.js เป็น Runtime ทำให้การตรวจจับด้วยชื่อ Process เพียงอย่างเดียวไม่เพียงพออีกต่อไป

เนื่องจาก Node.js เป็นซอฟต์แวร์ที่ถูกใช้งานอย่างแพร่หลายในองค์กรจำนวนมาก การไล่ตรวจเฉพาะ node.exe จึงสร้าง False Positive สูงเกินไปหากไม่เชื่อมกับ CommandLine, Parent Process และ Network Telemetry ร่วมกัน องค์กรจำเป็นต้องลงทุนในการทำ Baseline การใช้งาน Node.js ของตนเองอย่างจริงจัง ไม่ใช่พึ่งพา Signature เพียงอย่างเดียว

2. localhost:30303 สะท้อนช่องโหว่ของสถาปัตยกรรม Network Monitoring แบบดั้งเดิม

การสื่อสารภายในเครื่องเดียวกันผ่าน Loopback Address เป็นเทคนิคที่หลบเลี่ยง Firewall ระดับ Network ได้อย่างมีประสิทธิภาพ องค์กรที่พึ่งพา Network Monitoring จากส่วนกลางเพียงอย่างเดียวโดยไม่มี Endpoint Telemetry ที่มองเห็นกิจกรรมระดับ Process และ Local Port จะมีจุดบอดสำคัญต่อเทคนิคลักษณะนี้

3. Staged Delivery และการเปลี่ยนแปลงแคมเปญอย่างต่อเนื่องแสดงถึงการพัฒนาที่ตอบสนองต่อการตรวจจับ

การที่ Cato CTRL พบว่าแคมเปญเปลี่ยนวิธีจัดการ Scheduled Task จาก schtasks.exe ไปใช้ COM ภายในเวลาไม่กี่เดือน สะท้อนว่าผู้พัฒนา JSCEAL ติดตามและปรับตัวต่อ Detection Rule ที่เผยแพร่สู่สาธารณะอย่างรวดเร็ว องค์กรจึงไม่ควรยึดติดกับ IOC หรือ Technical Artifact แบบ Static เพียงชุดเดียว แต่ควรออกแบบ Detection ที่อ้างอิงจาก Behavior Chain ทั้งเส้นทาง (Fake Site → MSI → Node.js/JSC → localhost → Persistence → Proxy/Certificate → Exfiltration)

4. ผลกระทบต่อ Cookies และ Credential ต้องได้รับการตอบสนองในระดับบัญชี ไม่ใช่แค่ระดับเครื่อง

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

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

🔒 เนื้อหานี้จัดทำขึ้นเพื่อสมาชิก TXEC โดยเฉพาะ

กรุณาอย่าเผยแพร่นอกแพลตฟอร์ม TXEC โดยไม่ได้รับอนุญาต

IOC และ Detection Rules สามารถนำไปใช้ในองค์กรของท่านได้โดยอ้างอิงที่มาว่า "TXEC Team" และควรทดสอบในสภาพแวดล้อม Lab ก่อนนำไปใช้งานจริงบน Production