เจาะลึก Aisuru Botnet: จาก IoT Supply-chain Propagation ถึง Hyper-volumetric DDoS และ Kimwolf Proxyware Ecosystem พร้อม IOC และ Detection Rules

⚠️ หมายเหตุการเผยแพร่: รายงานฉบับนี้เป็นการสรุปและวิเคราะห์เชิงเทคนิคของ Aisuru Botnet โดยทีม TXEC จากการรวบรวม Malware Research, DDoS Mitigation Telemetry, Public IOC และข้อมูลจากหน่วยงานบังคับใช้กฎหมายที่เผยแพร่โดยแหล่ง Threat Intelligence ที่น่าเชื่อถือ (XLab/Qianxin, Protos Labs, Microsoft Azure, Cloudflare, Nokia Deepfield ERT, DOJ/DCIS/FBI, Malpedia, ThreatFox/abuse.ch, Bitsight TRACE) เพื่อสนับสนุนการทำ Threat Hunting และการพัฒนา Detection ภายในองค์กรสมาชิก

บทสรุป (Summary)

Aisuru เป็น IoT DDoS Botnet สายพัฒนาจาก Mirai ที่ถูกติดตามอย่างต่อเนื่องตั้งแต่ปี 2024 โดยเป้าหมายหลักคืออุปกรณ์ Linux แบบ Embedded เช่น Router, DVR, Camera และอุปกรณ์ Edge ที่เชื่อมต่ออินเทอร์เน็ต จุดที่ทำให้ Aisuru แตกต่างจาก Mirai รุ่นทั่วไปคือการพัฒนา Command and Control (C2) หลายรูปแบบ การเข้ารหัสและ Obfuscation ที่เปลี่ยนตามรุ่น การหลบหลีกการวิเคราะห์บน Linux รวมถึงการเพิ่มความสามารถ Proxy เพื่อใช้ประโยชน์จาก IP และ Bandwidth ของอุปกรณ์ที่ถูกยึดครอง นอกเหนือจากการใช้ทำ DDoS เพียงอย่างเดียว

ในปี 2025 ความสามารถด้าน DDoS ของ Aisuru เพิ่มขึ้นอย่างรวดเร็วจนแตะระดับ Hyper-volumetric โดย XLab ตรวจพบเหตุการณ์ประมาณ 11.5 Tbps ในเดือนกันยายน 2025, Cloudflare บันทึกเหตุการณ์ 29.7 Tbps และ 14.1 Bpps ใน Q3 2025 และ Microsoft Azure ยืนยันเหตุการณ์ 15.72 Tbps / 3.64 Bpps เมื่อ 24 ตุลาคม 2025 ที่พุ่งไปยัง Endpoint แห่งหนึ่งในออสเตรเลีย แม้ DOJ จะ Disrupt C2 สำคัญเมื่อ 19 มีนาคม 2026 แต่การเฝ้าระวังควรดำเนินต่อเนื่อง เนื่องจากการ Disruption ไม่ได้ยืนยันว่าทุก Bot และ Infrastructure ถูกกำจัดทั้งหมด และยังพบ IOC ที่ Tag ว่าเกี่ยวข้องกับ Aisuru ต่อเนื่องจนถึงเดือนกรกฎาคม 2026

รายงานฉบับนี้ครอบคลุมตั้งแต่ Infection/Propagation, Malware Architecture, Anti-analysis, C2 Protocol, DDoS Capability, Proxy Function และความเชื่อมโยงกับ Kimwolf Proxyware/ADB Ecosystem ไปจนถึง IOC ที่ยืนยันแล้ว, Detection Rules พร้อมใช้งาน (YARA, Sigma และ Suricata) และข้อเสนอแนะด้าน Containment, Detection และการเตรียมความพร้อมรับมือในระยะยาว

1. บทนำ

Aisuru มีลักษณะเป็น Multi-purpose IoT Botnet ที่มีสายพัฒนาจาก Mirai โดย Malpedia จัดเป็น honeypot-aware variant of Mirai แต่ตัวอย่างช่วงปี 2024-2026 มีการเปลี่ยน C2, Encryption, Anti-analysis และ Command Set หลายรอบ การแพร่กระจายอาศัยทั้ง N-day/0-day, Weak Credential และช่องโหว่บน Router, DVR, Camera และ Embedded Device หลายยี่ห้อ รวมถึงเหตุการณ์เดือนเมษายน 2025 ที่ Infrastructure สำหรับ Firmware Update ของ TOTOLINK ถูกนำไปใช้แจกจ่ายสคริปต์อันตราย

XLab ประเมิน Bot ราว 300,000 Nodes หลังเหตุการณ์ TOTOLINK ขณะที่ Cloudflare ประเมิน Infected Hosts ใน Q3 2025 กว้างกว่าที่ประมาณ 1-4 ล้านเครื่อง ตัวเลขสองชุดมีขอบเขตและวิธีนับต่างกันจึงไม่ควรตีความเป็นจำนวนเครื่องที่แน่นอน

ข้อมูลนี้จัดทำขึ้นโดยทีม TXEC เพื่อสรุปผลการวิเคราะห์เชิงเทคนิคของ Aisuru โดยอ้างอิงจาก Public Threat Intelligence และงานวิจัยเชิงเทคนิคหลายแหล่ง เนื้อหาครอบคลุม Malware Architecture, C2 Protocol, DDoS Capability, Proxy Function, Public IOC และสถานะหลัง Law Enforcement Disruption เพื่อสนับสนุนการทำ Threat Hunting, Network Security และ Incident Response ภายในองค์กร

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

ทีม TXEC ดำเนินการรวบรวมและวิเคราะห์ข้อมูลของ Aisuru โดยเน้น Infection/Propagation, Malware Architecture, C2 Protocol, DDoS Capability, Proxy Function, Public IOC และสถานะหลัง Law Enforcement Disruption จาก Public Threat Intelligence และงานวิจัยเชิงเทคนิคหลายแหล่ง แล้วจัดหมวดหมู่เป็น 5 ขั้นตอนหลัก เพื่อให้สามารถตรวจสอบย้อนกลับและนำผลลัพธ์ไปใช้กับ SOC, Threat Hunting, Network Security และ Incident Response ได้จริง

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

กำหนดขอบเขต Aisuru ตั้งแต่การแพร่กระจายบน Router/IoT, C2, Anti-analysis, DDoS, Proxy Monetization, Ecosystem Link และสถานะหลังการ Disruption ปี 2026 เพื่อให้ได้กรอบการวิเคราะห์ที่แยก Malware Core, Ecosystem และ Operational Status ออกจากกันอย่างชัดเจน

ขั้นตอนที่ 2: Evidence Identification & Collection (รวบรวมหลักฐาน)

รวบรวม XLab Reverse Engineering, Protos Threat Report, Microsoft/Cloudflare DDoS Telemetry, Malpedia/ThreatFox, DOJ และ Nokia Deepfield เพื่อให้ได้ชุดข้อมูลที่มี Technical Detail, IOC, Timeline และระดับความเชื่อมั่นครบถ้วน

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

Cross-check ตัวเลข Bot Count, DDoS Peak, C2, Hash, Domain และเหตุการณ์ Takedown แยกข้อมูล Historical ออกจาก Current IOC เพื่อลดการนำ IOC เก่าหรือคำอ้าง Attribution ที่ยังไม่ยืนยันไปใช้ผิดบริบท

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

เชื่อมโยงการติดเชื้อ → Loader/Distribution → DNS/C2 → Bot Login → Speed Profiling → Attack/Proxy → DDoS และเทียบความสัมพันธ์ใน Aisuru Ecosystem เพื่อให้ได้ Attack Flow, TTP Mapping และจุดตรวจจับที่ครอบคลุม Endpoint, DNS และ Network

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

สรุป Technical Finding, Confidence, Public IOC, Recommendation และตัวอย่าง Detection Rule โดยรักษาความแตกต่างระหว่าง Confirmed Evidence กับ Assessment เพื่อให้ได้เอกสารที่ใช้ประกอบ Threat Hunting, DDoS Readiness และการกำหนด Control ภายในองค์กร

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

3.1 Infection & Propagation: จาก N-day/0-day ถึง Supply-chain Propagation

XLab ระบุว่า Aisuru กระจายตัวผ่าน N-day Vulnerability จำนวนมากบนอุปกรณ์เครือข่ายและ IoT และมีหลักฐานว่าผู้ปฏิบัติการสามารถนำ 0-day รวมถึง Weak Credential เข้ามาใช้ได้ด้วย ขอบเขตอุปกรณ์ที่พบประกอบด้วย Router, DVR, Camera และ Gateway Software หลาย Vendor เช่น CVE-2023-28771 บน Zyxel ATP/USG FLEX/VPN/ZyWALL (RCE/Appliance Exploitation), CVE-2023-50381 ใน Realtek RTL819x Jungle SDK (Embedded Device Exploitation), CVE-2024-3721 ใน TBK DVR (DVR Command Execution) และ Device-specific RCE/cnPilot 0-day

พฤติกรรมโดยรวมสะท้อนแนวทาง Scan-and-Exploit ที่เปลี่ยน Exploit ตาม Asset ที่พบ ไม่ได้ผูกกับ CVE เดียว ทำให้การป้องกันแบบ Endpoint EDR เพียงอย่างเดียวไม่ครอบคลุม เพราะอุปกรณ์จำนวนมากไม่มี Agent และใช้ Firmware เก่าที่ไม่ถูกบริหารแบบเดียวกับ Server/Workstation

จุดเปลี่ยนสำคัญเกิดในเดือนเมษายน 2025 เมื่อ XLab ตรวจพบสคริปต์ t.sh บนระบบอัปเดตของ TOTOLINK และตั้งแต่วันที่ 26 เมษายนมีการใช้โดเมน updatetoto[.]tw เป็นจุดดาวน์โหลด การยึด Update Path ทำให้ Router ที่เรียกกระบวนการอัปเดตมีโอกาสรับสคริปต์อันตรายโดยไม่ต้องสแกนช่องโหว่จากภายนอกทุกเครื่อง XLab ประเมินว่าจำนวน Bot เพิ่มเกิน 100,000 เครื่องในเวลาอันสั้น และภาพ Panel ที่รั่วไหลภายหลังแสดง Active Bot มากกว่า 300,000 เครื่อง เหตุการณ์นี้ควรถูกมองเป็น Supply-chain-style Propagation ไม่ใช่การแพร่แบบ Mirai Credential Brute-force ทั่วไป

3.2 Malware Architecture, Anti-analysis และ C2 Protocol

การเรียก "Version" หรือ "Generation" ของ Aisuru แตกต่างกันตามผู้วิจัย จึงควรอ้างอิงช่วงเวลาและคุณลักษณะทางเทคนิคมากกว่าชื่อรุ่นเพียงอย่างเดียว XLab พบตัวอย่างใหม่ตั้งแต่ 14 มีนาคม 2025 โดยช่วงแรกใช้ ECDH-P256 เพื่อแลก Key และใช้ ChaCha20 กับ Network Message ก่อนเปลี่ยนไปเป็นรุ่นที่ตัด ECDH ออก ปรับ xxHash สำหรับ Integrity และใช้ Modified RC4 สำหรับถอด String/Communication Key ส่วน Nokia Deepfield แบ่งวิวัฒนาการกว้างๆ เป็น Gen1 (DNS A + SOCKS5) และ Gen2 (DNS TXT + Modified RC4) และพบ Cryptographic Fingerprint ที่เชื่อมโยง Aisuru กับ JackSkid

ก่อนเริ่มทำงาน Bot จะตรวจ Command Line ว่ามีชื่อเครื่องมือ Capture เช่น tcpdump, wireshark, tshark หรือ dumpcap หรือไม่ และตรวจ Hardware Identifier ของ Kernel เพื่อหา VMware, VirtualBox, KVM, Microsoft และ QEMU หากพบจะ Exit เพื่อลดการถูกวิเคราะห์แบบ Dynamic จากนั้นเขียนค่า -1000 ลง /proc/self/oom_score_adj เพื่อลดโอกาสถูก OOM Killer ยุติ Process รุ่นที่ XLab วิเคราะห์ยังคงไฟล์บน Disk โดยพบ Runtime/Filename libcow.so และใช้ชื่อ Process ที่ดูปกติบนอุปกรณ์ Linux เช่น telnetd, udhcpc, inetd, ntpclient, watchdog, klogd, upnpd หรือ dhclient ชื่อ Process เหล่านี้ไม่ควรถูก Block ตรงๆ แต่ต้อง Correlate กับ Path, Parent, Hash, Package Ownership และ Network Behavior

ในส่วน C2 Aisuru ใช้ Domain และ DNS TXT เป็น Dead-drop สำหรับซ่อน Backend Address ตัวอย่างสำคัญคือ approach[.]ilovegaysex[.]su และ coerece[.]ilovegaysex[.]su โดย XLab เคยถอด TXT Record ของ approach แล้วพบช่วง C2/GRE 151.242.2.22-151.242.2.25 การใช้ TXT Dead-drop ช่วยให้ผู้ควบคุมเปลี่ยน Backend ได้โดยไม่ต้อง Rebuild Binary ทุกครั้ง ในสายพัฒนาปี 2025 พบการเปลี่ยน Decode จาก Base64+ChaCha20 ไปเป็น Base64+XOR และใช้ Modified RC4 กับ String/Communication Key บางส่วน ข้อมูล Login ของ Bot มี STUN IP, Bot ID, Version, Node Name, Current Working Directory, Kernel Version และสถานะการรองรับ UDP โดย Header ของ Message มีขนาด 8 Byte ประกอบด้วย msgType, randSize, bodySize และ bodyHash

C2 Command Set (msgType) ที่สำคัญต่อการตรวจจับ:

• ▸ 0 — Get shared network key: เริ่มต้นการแลก Network Key
• ▸ 1 — Key information: ส่งข้อมูล Key ระหว่าง Bot/C2
• ▸ 2 — Confirm key: ยืนยัน Key ก่อน Session ทำงาน
• ▸ 3 — Login information: ส่ง Bot ID, Version, Node/Kernel และ Network Capability
• ▸ 4 — Heartbeat: รักษา Session และใช้ติดตาม Bot ที่ยัง Active
• ▸ 5 — Exit: สั่งยุติ Process/Session
• ▸ 6 — Attack: สั่ง DDoS ตาม Attack Handler ที่กำหนด
• ▸ 7 — Execute command: สั่งรันคำสั่งบนอุปกรณ์ที่ถูกยึด
• ▸ 8 — New C2: เปลี่ยน/ย้าย C2 เพื่อรักษาความต่อเนื่อง
• ▸ 9 — Reverse shell: เปิด Interactive Shell กลับไปยังผู้ควบคุม
• ▸ 10 — Proxy: ใช้ Node เป็น Proxy/Relay
• ▸ 101 / 201 / 202 — Reporting: รายงาน Telnet Scan, Killer State และ Network Speed ของ Node

3.3 DDoS Capability: จากหลัก Tbps สู่ Hyper-volumetric

Aisuru ถูกใช้กับ Direct Volumetric DDoS ที่ยิง Traffic จาก Infected Host ไปยังเป้าหมายโดยตรง ความสามารถครอบคลุม UDP Volumetric Flood, TCP SYN/ACK/STOMP, GRE, RakNet และรูปแบบ UDP ที่ปรับ Payload/Port ได้ จุดเด่นไม่ใช่เพียงจำนวน Bot แต่เป็น Bandwidth ของ Residential/Edge Device ที่เพิ่มขึ้นตาม Fiber-to-the-Home รวมถึงการกระจาย Source จำนวนมากในหลายเครือข่าย

สรุปเหตุการณ์ DDoS สำคัญที่ยืนยันแล้ว:

• ▸ กันยายน 2025 — 11.5 Tbps (XLab): Attack ต่อ 185.211.78[.]117 จาก C2 Tracking
• ▸ Q3 2025 — 29.7 Tbps (Cloudflare): UDP Carpet Bombing กระจาย Destination Port เฉลี่ยประมาณ 15,000 พอร์ตต่อวินาที พร้อมสุ่ม Packet Attribute เพื่อเพิ่มความยากในการ Filter
• ▸ Q3 2025 — 14.1 Bpps (Cloudflare): Packet-rate Record ในกิจกรรม Aisuru
• ▸ 24 ตุลาคม 2025 — 15.72 Tbps / 3.64 Bpps (Microsoft Azure): Multi-vector DDoS ต่อ Endpoint แห่งหนึ่งในออสเตรเลีย มากกว่า 500,000 Source IP
• ▸ Q4 2025 — 31.4 Tbps (Cloudflare): อยู่ในบริบท Aisuru-Kimwolf Ecosystem จึงไม่ควรใช้แทนสถิติ Pure Aisuru โดยไม่ระบุ Qualifier

3.4 Proxy, ADB และ Kimwolf Proxyware Ecosystem

XLab พบ Network Speed Test ที่เรียก Public Speedtest Service และส่งผลกลับ C2 ซึ่งสอดคล้องกับการคัดเลือก Node ที่มี Bandwidth/Latency เหมาะสมสำหรับ Proxy Service โดย Command Set มี msgType 10 สำหรับ Proxy และมี Telemetry สำหรับ Network-speed Report จึงทำให้อุปกรณ์ที่ถูกยึดมีมูลค่าเชิง Operational มากกว่าการเป็น DDoS Node เพียงอย่างเดียว

งานของ Bitsight ในปี 2026 พบ PROXY Tasking ที่ถูกนำไปใช้เชื่อมต่อ Backconnect Endpoint และเข้าถึง ADB/TCP 5555 ภายในเครือข่ายที่ Bot มองเห็น Chain ที่รายงานประกอบด้วยการดาวน์โหลด /sdcard/f.apk, ติดตั้ง Android Package a.b.c และ Drop ELF ชื่อ libandroid_runtime.so สำหรับ Proxy Behavior พฤติกรรมนี้มี Tooling/Infrastructure บางส่วนทับซ้อนกับ Kimwolf จึงควรใช้เป็น Hunting Context สำหรับ Android/ADB และไม่เหมารวมว่าเป็น Behavior ของ Core Linux Aisuru ทุก Sample

Proxyware Branch ที่ Bitsight วิเคราะห์ยังใช้ ENS/Ethereum JSON-RPC เป็นกลไกหา C2 โดย Query xxggibyrdc[.]eth และมี DNS Fallback เช่น global.relay.proxystream[.]st และ 5gf7jtfk0y[.]st ก่อนเชื่อม TCP/8001 ขณะที่ TCP/8002 ปรากฏใน Payload-delivery Context ของ ADB Chain IOC เหล่านี้ควรใช้แบบ Time-bounded และ Enrich ด้วย Passive DNS/Current Resolution ก่อน Block

4. แหล่งข้อมูลและผลการตรวจสอบพยานหลักฐานดิจิทัล

การวิเคราะห์ครั้งนี้ใช้ข้อมูลจาก Malware Research, DDoS Mitigation Telemetry, Public IOC, Threat Intelligence Database และข้อมูลจากหน่วยงานบังคับใช้กฎหมาย โดยให้ความสำคัญกับแหล่งที่มี Direct Telemetry หรือ Reverse Engineering ก่อนข้อมูลที่เป็น Attribution/Anonymous Source

• ▸ XLab / Qianxin — ใช้เพื่อตรวจสอบ Reverse Engineering, Propagation, C2 และ Attack Command → ผลตรวจ: ยืนยัน TOTOLINK Propagation, DNS TXT C2, Anti-analysis, Protocol, Proxy และ 11.5 Tbps Telemetry
• ▸ Protos Labs — ใช้เพื่อตรวจสอบ Consolidated Threat Report / IOC → ผลตรวจ: ยืนยัน Critical Risk, 29.7 Tbps Context, High-confidence Domain IOC และ Mitigation Priorities
• ▸ Microsoft Azure — ใช้เพื่อตรวจสอบ Cloud DDoS Mitigation Telemetry → ผลตรวจ: ยืนยัน 15.72 Tbps, 3.64 Bpps, มากกว่า 500,000 Source IP และ High-rate UDP Flood
• ▸ Cloudflare DDoS Threat Reports — ใช้เพื่อตรวจสอบ Direct DDoS Mitigation Telemetry → ผลตรวจ: ยืนยัน 29.7 Tbps, 14.1 Bpps, UDP Carpet-bombing, ประมาณ 1-4 ล้านเครื่อง Host Estimate และ 31.4 Tbps ในบริบท Aisuru-Kimwolf
• ▸ Nokia Deepfield ERT — ใช้เพื่อตรวจสอบ Code Lineage / Ecosystem / C2 Crypto → ผลตรวจ: เชื่อม Aisuru-JackSkid ระดับ High และ Aisuru-Kimwolf ระดับ Medium แยก Propagation Pipeline จาก Bot Binary
• ▸ DOJ / DCIS / FBI — ใช้เพื่อตรวจสอบ Law-enforcement Status → ผลตรวจ: ยืนยันปฏิบัติการวันที่ 19 มีนาคม 2026 กระทบกว่า 3 ล้านอุปกรณ์รวม 4 Botnets และ Aisuru มี DDoS Command กว่า 200,000 รายการ
• ▸ Malpedia — ใช้เพื่อตรวจสอบ Family Taxonomy → ผลตรวจ: จัด Aisuru เป็น elf.aisuru และอธิบายว่าเป็น Honeypot-aware Mirai Variant
• ▸ ThreatFox / abuse.ch — ใช้เพื่อตรวจสอบ IOC Lifecycle หลัง Disruption → ผลตรวจ: มี Aisuru-tagged IOC ถึงเดือนกรกฎาคม 2026 ใช้เป็น Pivot สำหรับ Hunting ไม่ควร Block IP โดยไม่ Validate อายุ/Ownership
• ▸ Bitsight TRACE — ใช้เพื่อตรวจสอบ C2/Command Telemetry ปี 2026, PROXY, ADB, Proxyware → ผลตรวจ: ยืนยัน Post-disruption Behavior, Backconnect/ADB Chain และ Android/Proxyware Hunting Context โดยต้องแยกจาก Core Linux Aisuru

5. Indicators of Compromise (IOC)

IOC ชุดนี้รวบรวมจาก Public Threat Intelligence พร้อมสำหรับการนำไปใช้ใน SIEM, EDR, WAF/IPS และ Threat Intelligence Platform ค่า Hash เหมาะสำหรับ Retrospective Hunting ส่วน Behavior Artifact ควรนำไป Correlate กับ DNS/NetFlow/Firewall Telemetry มากกว่าการ Block แบบถาวรโดยไม่ตรวจอายุข้อมูล เนื่องจาก IOC ของ Aisuru มีการเปลี่ยนแปลงตามการย้าย C2 และการ Disruption หลายรอบ

5.1 Domain / IP — High Confidence

✅ Domain [CONFIRMED / HIGH]

ilovegaysex[.]su

Parent Domain ที่ใช้กับ C2/DNS TXT ในงาน XLab/Protos

✅ Domain [CONFIRMED / HIGH]

coerece[.]ilovegaysex[.]su

C2-related Subdomain / DNS Dead-drop Family

✅ Domain [CONFIRMED / HIGH]

approach[.]ilovegaysex[.]su

TXT Record เคย Decode ไปยังช่วง C2 151.242.2.22-25

✅ Domain [CONFIRMED / HIGH]

ministry[.]ilovegaysex[.]su / lane[.]ilovegaysex[.]su

Historical Aisuru Infrastructure

✅ Domain [CONFIRMED / HIGH]

updatetoto[.]tw

Historical Downloader Domain ใน TOTOLINK Propagation Campaign

✅ IP Range [CONFIRMED / HIGH]

151.242.2[.]22-25

Historical C2/GRE Set เดือนเมษายน 2025

5.2 Recent C2/Proxy Observation — ต้อง Validate ก่อนใช้งาน

👁️ IP:Port [OBSERVED / HIGH — Validate Last Seen/Ownership]

206.189.94[.]70:37215

👁️ IP:Port [OBSERVED / HIGH — Validate Last Seen/Ownership]

160.119.71[.]125:8080

👁️ IP:Port [OBSERVED / HIGH — Recent Proxy/C2]

132.243.199[.]3:8001

👁️ IP:Port [OBSERVED / HIGH — Recent Proxy/C2]

165.232.100[.]127:8001

5.3 Sample Hash (SHA-1) — Protos Labs

ใช้สำหรับ Retrospective Hunting และ Sample Pivot ไม่ควรใช้แทน Behavior Detection เนื่องจาก Botnet สามารถ Rebuild Binary ได้ง่าย

• ▸ 09894c3414b42addbf12527b0842ee7011e70cfd
• ▸ 51d9a914b8d35bb26d37ff406a712f41d2075bc6
• ▸ 616a3bef8b0be85a3c2bc01bbb5fb4a5f98bf707
• ▸ ccf40dfe7ae44d5e6922a22beed710f9a1812725
• ▸ 26e9e38ec51d5a31a892e57908cb9727ab60cf88
• ▸ 08e9620a1b36678fe8406d1a231a436a752f5a5e
• ▸ 053a0abe0600d16a91b822eb538987bca3f3ab55

5.4 ADB / Proxyware Ecosystem Artifact (Kimwolf-related — แยกจาก Aisuru Linux Core)

• ▸ Port 5555/TCP: ADB Exposure / Local Access Target ใน Related ADB Chain
• ▸ Port 8001/TCP: Proxy C2 / Backconnect Port ใน Proxyware Branch
• ▸ Port 8002/TCP: Payload-delivery Endpoint ใน ADB Chain
• ▸ Android Artifact: /sdcard/f.apk — APK Delivery Artifact
• ▸ Android Package: a.b.c — Package Name ใน Captured ADB Chain
• ▸ ELF: libandroid_runtime.so — Proxybot Artifact ใน ADB/Proxyware Chain
• ▸ ENS: xxggibyrdc[.]eth — Proxyware C2 Locator
• ▸ Domain: global.relay.proxystream[.]st, 5gf7jtfk0y[.]st — Proxyware C2 Fallback

5.5 Behavior / Hunt Artifact ที่มีค่ามากกว่า IOC แบบคงที่

• ▸ DNS TXT Query ไปยัง Domain ที่ผิดปกติ โดยเฉพาะ Domain ที่เคยสัมพันธ์กับ Aisuru และมี Record ถูก Decode เป็น IP List
• ▸ Process Name เช่น telnetd, udhcpc, ntpclient, watchdog หรือ dhclient แต่ Executable อยู่ใน /tmp, /var/tmp, /dev/shm หรือ Writable Path
• ▸ การเขียนค่า -1000 ไปยัง /proc/self/oom_score_adj จาก Process ที่ไม่ใช่ Service ที่องค์กรอนุญาต
• ▸ ELF ที่มี Key/String PJbiNbbeasddDfsc, Runtime/Filename libcow.so หรือ Anti-analysis String ร่วมกับพฤติกรรม DNS/C2 ที่สอดคล้อง
• ▸ Outbound UDP/GRE Spike จาก IoT VLAN, Destination/Port จำนวนมาก, Source Port Randomization และ Attack Burst ที่เกิดภายในไม่กี่วินาที
• ▸ Android/IoT Device ที่เปิด ADB/5555 โดยไม่จำเป็น ร่วมกับ /sdcard/f.apk, Package a.b.c, libandroid_runtime.so หรือ Outbound TCP/8001-8002 ที่ผิด Baseline

Threat Hunting Guidance:

• ตรวจหา DNS TXT Query ไปยังโดเมนที่เกี่ยวข้องกับ Aisuru
• ตรวจ Abnormal IoT Egress Burst และ Destination-port Dispersion
• ตรวจ Process ชื่อ telnetd, udhcpc, watchdog จาก Writable Path
• ตรวจการเชื่อมต่อ TCP/5555, 8001 และ 8002 จาก IoT/Android Device
• ตรวจ Artifact เช่น libcow.so, t.sh, /sdcard/f.apk และ libandroid_runtime.so
• ใช้ Passive DNS และ Current Ownership ก่อน Block Historical IOC

MITRE ATT&CK Mapping: Initial Access (Exploit Public-Facing Application) → Discovery (Network Service Scanning) → Command & Control (DNS TXT Dead-drop / Custom C2) → Defense Evasion (Masquerading / Anti-analysis) → Impact (Direct Network Flood)

6. Detection Rules

6.1 YARA Rule: Aisuru Gen2 Hunting

yara

rule TXEC_Aisuru_Gen2_Hunting {
    meta:
        description = "Hunting rule for Aisuru Gen2 Linux ELF artifacts"
        author      = "TXEC Team"
        reference   = "XLab / Nokia Deepfield / Protos"
        confidence  = "medium-high"

    strings:
        $key = "PJbiNbbeasddDfsc" ascii
        $oom = "/proc/self/oom_score_adj" ascii
        $a1  = "tcpdump" ascii
        $a2  = "wireshark" ascii
        $a3  = "tshark" ascii
        $a4  = "dumpcap" ascii

    condition:
        uint32(0) == 0x464c457f and
        $key and $oom and 2 of ($a*)
}

6.2 YARA Rule: ADB / Proxyware Artifact (Kimwolf Ecosystem)

yara

rule TXEC_Aisuru_ADB_Proxyware_Artifact {
    meta:
        description = "Aisuru/Kimwolf-related ADB proxyware artifacts"
        author      = "TXEC Team"
        status      = "experimental"

    strings:
        $ens        = "xxggibyrdc.eth" ascii
        $fallback1  = "global.relay.proxystream.st" ascii
        $fallback2  = "5gf7jtfk0y.st" ascii
        $elfname    = "libandroid_runtime.so" ascii

    condition:
        2 of them
}

6.3 Sigma Rule: Linux Process Masquerading From Writable Path

yaml

title: Aisuru-Like Linux Process Masquerading From Writable Path
status: experimental
logsource:
    product: linux
    category: process_creation
detection:
    daemon_name:
        Image|endswith:
            - '/telnetd'
            - '/udhcpc'
            - '/ntpclient'
            - '/watchdog'
            - '/upnpd'
            - '/dhclient'
    writable_path:
        Image|startswith:
            - '/tmp/'
            - '/var/tmp/'
            - '/dev/shm/'
    condition: daemon_name and writable_path
falsepositives:
    - Embedded devices legitimately launching copied utilities from writable paths
level: high

6.4 Suricata/Snort Rule: Known C2 Domain Query

alert dns $HOME_NET any -> any 53 (
  msg:"TXEC AISURU known C2 parent domain query";
  dns.query; content:"ilovegaysex.su"; nocase;
  classtype:trojan-activity; sid:4206101; rev:1;
)

alert dns $HOME_NET any -> any 53 (
  msg:"TXEC AISURU historical downloader domain query";
  dns.query; content:"updatetoto.tw"; nocase;
  classtype:trojan-activity; sid:4206102; rev:1;
)

Recommended Correlation:

• Known/Recent Aisuru IOC Match + Outbound UDP/GRE Spike ภายใน 30 นาที → Severity Critical
• Rare DNS TXT + Linux Process Masquerading + /proc/self/oom_score_adj Modification → Severity High
• IOC Match เพียงอย่างเดียวแต่ไม่มี Supporting Telemetry → Alert เพื่อ Validate ก่อน Block ระยะยาว

6.5 Network / SIEM Rule: Hyper-volumetric Bot Behavior (Vendor-neutral)

Detection Logic (vendor-neutral)

FROM netflow_or_firewall
WHERE source_zone IN (IoT, Guest, Unmanaged)
AND direction = "outbound"
GROUP BY src_ip, 30s
HAVING
    udp_packets > baseline(src_ip) * 20
    OR unique_dst_ip > 500
    OR unique_dst_port > 200
    OR gre_packets > 0
THEN correlate WITH
    recent_aisuru_ioc_match
    OR rare_dns_txt_query
    OR process_masquerading_alert
SEVERITY = HIGH / CRITICAL

6.6 ADB / Kimwolf Ecosystem Detection

• ▸ Alert เมื่ออุปกรณ์ Android/TV Box หรือ Residential Proxy Endpoint เปิด TCP/5555 โดยไม่อยู่ใน Allowlist
• ▸ Block East-West Access ไป TCP/5555 ระหว่าง User/IoT VLAN หากไม่มี Business Need และตรวจ ADB Connection จาก Proxy/Unmanaged Segment
• ▸ Tag Finding เป็น "Aisuru/Kimwolf Ecosystem" ไม่ใช่ Aisuru Linux IOC จนกว่าจะมี Malware/Telemetry ยืนยัน Family เพื่อหลีกเลี่ยง Attribution Error

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

เพื่อจำกัดความเสี่ยงจาก Aisuru และ Botnet ที่มีลักษณะใกล้เคียง องค์กรควรออกแบบ Control ให้ครอบคลุมทั้งการป้องกันไม่ให้อุปกรณ์ IoT/Network Edge ถูกยึด การตรวจจับ C2/Proxy/DDoS จากภายใน การใช้ Upstream DDoS Protection แบบ Always-on และการเตรียม Incident Playbook ที่ตัดสินใจได้ภายในไม่กี่นาที เนื่องจากเหตุการณ์ระดับ Hyper-volumetric มักสิ้นสุดก่อนกระบวนการ Manual Escalation จะทำงานครบ

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

1. ตรวจ Inventory ของ Router, DVR, Camera, Gateway และอุปกรณ์ Embedded ที่ Internet-facing พร้อมเทียบ Firmware/CVE กับ Vendor Advisory โดยให้ความสำคัญกับอุปกรณ์ที่หมด Support หรือไม่มี Secure Update Mechanism
2. ปิด Remote Management จาก Internet หากไม่จำเป็น จำกัด Management Plane ด้วย ACL/VPN/Jump Host และยกเลิก Default Credential หรือ Shared Credential บนอุปกรณ์ทั้งหมด
3. Block/Sinkhole High-confidence Domain ที่ยืนยันแล้วใน DNS Security และตรวจย้อนหลัง DNS TXT Query ไปยัง Domain เหล่านี้อย่างน้อย 90-180 วัน
4. Isolate อุปกรณ์ที่พบพฤติกรรมผิดปกติ หากพบ IoT/Router/DVR/Android Device สร้าง Outbound UDP/TCP/GRE ผิด Baseline หรือเชื่อม C2 ให้ Isolate จาก Internet/East-West Network พร้อมเก็บ DNS, NetFlow, Firewall Session, รุ่น/Firmware, Process และ Suspicious Binary ก่อน Reflash/Reimage หากพิสูจน์ Integrity ไม่ได้ให้ Reflash ด้วย Trusted Vendor Image หรือ Replace Device
5. ประสาน ISP/CDN/DDoS Provider ให้เปิด Always-on Scrubbing หรือกำหนด Automatic Diversion/Rate-control สำหรับ Service สำคัญ ไม่รอให้เกิดเหตุแล้วจึงเปลี่ยน Route
6. ตรวจ Egress Policy ของ IoT VLAN ให้ใช้งานเฉพาะ Destination/Protocol ที่จำเป็น จำกัด UDP และ GRE (IP Protocol 47) ตาม Business Need และ Block Direct Internet Access ของอุปกรณ์ที่ไม่ต้องออกอินเทอร์เน็ต
7. กำหนด DNS Resolver ภายในแบบบังคับ ห้าม IoT ใช้ External DNS โดยตรง เพื่อให้สามารถตรวจ TXT Query, NXDOMAIN Spike และ C2 Domain ได้จากจุดกลาง
8. อย่า Assume ว่า IP/Domain ชุดเดิมคือ Infrastructure ปัจจุบัน หลังเหตุการณ์ Law-enforcement Takedown ให้ตรวจ Last Seen และ Ownership ทุกครั้งก่อน Block/Allow เพื่อหลีกเลี่ยง False Positive จาก IP Reassignment
9. ตรวจ Proxy/Residential Proxy SDK บนอุปกรณ์ Android/TV Box และอุปกรณ์ Unmanaged ที่เชื่อม Corporate Network หากพบ ADB/TCP 5555 เปิดโดยไม่จำเป็นให้ปิดทันที สำหรับอุปกรณ์ที่ต้องใช้ ADB ให้จำกัด Source IP และแยก Management Network จาก User/IoT VLAN ทั้งนี้จัดเป็น Kimwolf/Aisuru Ecosystem Control ไม่ใช่ Aisuru Linux Core Indicator
10. เก็บ NetFlow/sFlow, Firewall, DNS, DDoS Provider Event และ Router Log แบบ Centralized ให้เพียงพอสำหรับย้อน Timeline อย่างน้อย 180 วันในระบบสำคัญ

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

หลัง Patch/Containment ควรเพิ่ม Detection Coverage ใน 3 จุดหลัก คือ DNS, Network Flow และ Edge/IoT Telemetry โดยเน้น Chain ของพฤติกรรม ไม่พึ่ง Hash อย่างเดียว

1. Monitor DNS TXT Query ไปยัง Rare Domain/TLD และแจ้งเตือนเมื่อ TXT Response มี Encoded/Obfuscated Payload หรือมี Pattern ที่ Decode เป็น IPv4 List
2. Monitor Process Masquerading บน Linux/Embedded Device: Process Name ดูเป็น System Daemon แต่ Executable Path, Parent, Working Directory หรือ Network Destination ผิดจาก Baseline
3. Monitor การแก้ /proc/self/oom_score_adj เป็นค่าติดลบมาก โดยเฉพาะ -1000 จาก Binary ที่มาจาก Writable Path หรือเพิ่งถูกดาวน์โหลด
4. Monitor Outbound UDP Flood, GRE, TCP SYN/ACK Burst, Destination Fan-out, Port Fan-out และ PPS/Bandwidth ที่สูงผิดปกติจาก IoT/Guest/Unmanaged Segment
5. ทำ Baseline ปริมาณ DNS, UDP, TCP และ Internet Destination ต่อ Device Class เพื่อให้ตรวจพบ Bot ที่ไม่สร้าง Traffic สูงตลอดเวลาแต่ถูก Trigger เป็นช่วงสั้น
6. รับ Alert/Telemetry จาก DDoS Provider ผ่าน API/SIEM เพื่อ Correlate Attack Start Time, Vector, Top Source ASN/Country และ Target VIP โดยอัตโนมัติ
7. ทำ Threat Hunting กับ Recent C2 IOC แบบ Time-bounded และเก็บผล Seen/Not Seen เพื่อปรับ Blocklist Lifecycle รวมถึงตรวจ ADB-enabled State, Package a.b.c, /sdcard/f.apk, libandroid_runtime.so และ Outbound TCP/8001-8002 บนอุปกรณ์ Android/IoT ที่อยู่ภายใต้การจัดการ

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

องค์กรควรมี DDoS/Botnet Incident Playbook ที่กำหนด Decision Point, Owner, Escalation Path และขั้นตอนการสื่อสารกับ ISP/CDN/DDoS Provider ล่วงหน้า โดยแยกเหตุการณ์ "ถูกโจมตีจากภายนอก" ออกจาก "พบ Bot ภายในองค์กรกำลังยิงออก" เพราะหลักฐานและ Containment ต่างกัน

1. กำหนด Trigger สำหรับ Automatic Mitigation เช่น Bandwidth/PPS/Concurrent Flow/UDP Fan-out และให้ SOC มีสิทธิ์ Activate Scrubbing ตามเกณฑ์โดยไม่ต้องรออนุมัติหลายชั้น
2. เตรียม Contact Matrix ของ ISP, CDN, Cloud, Registrar และ Vendor ของอุปกรณ์ Edge พร้อม SLA/หมายเลขฉุกเฉินที่ทดสอบแล้ว
3. ซ้อม Tabletop และ Technical Drill อย่างน้อยปีละ 1-2 ครั้ง โดยจำลอง Burst ที่สั้นกว่า 10 นาที เพื่อทดสอบว่า Alert, Escalation และ Routing Change ทำงานทัน
4. กำหนด Evidence Package มาตรฐาน ได้แก่ NetFlow/sFlow, PCAP Sample, DDoS Provider Report, DNS Log, Router Config, Firmware Version, NAT/Firewall Session และ Timeline
5. ตรวจ Supply-chain Control ของ Network Device: Firmware Signing, Update Server Validation, Vendor Support Lifecycle และช่องทาง Patch ที่องค์กรตรวจสอบได้
6. ติดตาม IOC แบบ Feed Lifecycle มี First Seen/Last Seen/Confidence/Source/Expiry และทบทวน Allow/Block Rule เป็นรอบ เพื่อลดปัญหา IP Reassignment

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

• รายงานนี้เป็นการสรุปและวิเคราะห์จาก Public Threat Intelligence ไม่ใช่การตรวจพิสูจน์หลักฐานดิจิทัลจากเหตุการณ์ที่เกิดขึ้นกับองค์กรใดองค์กรหนึ่งโดยตรง
• ตัวเลข Bot Count และ DDoS Peak มาจาก Telemetry ของแต่ละแหล่งซึ่งมีขอบเขตและวิธีนับต่างกัน (เช่น XLab ประมาณ 300,000 Nodes เทียบกับ Cloudflare ประมาณ 1-4 ล้านเครื่อง) จึงไม่ควรนำมารวมหรือเทียบกันโดยตรงว่าเป็นจำนวนที่แน่นอนชุดเดียว
• ค่า 31.4 Tbps ใน Q4 2025 อยู่ในบริบท Aisuru-Kimwolf Ecosystem ไม่ควรใช้แทนสถิติ Pure Aisuru โดยไม่ระบุ Qualifier
• IOC ชุดนี้มีการเปลี่ยนแปลงตามการย้าย C2 และการ Disruption หลายรอบ ควร Correlate กับ DNS/NetFlow/Firewall Telemetry และตรวจอายุ/Ownership ก่อน Block แบบถาวร
• พฤติกรรม ADB/Proxyware มี Tooling/Infrastructure บางส่วนทับซ้อนกับ Kimwolf จึงต้องแยกจาก Core Linux Aisuru ด้วย Sample, Protocol, Infrastructure และ Timestamp ไม่ใช้ Family Name เพียงอย่างเดียวเป็นตัวตัดสิน
• แม้ DOJ จะ Disrupt C2 สำคัญเมื่อ 19 มีนาคม 2026 แต่การ Disruption ไม่ได้ยืนยันว่าทุก Bot และ Infrastructure ถูกกำจัดทั้งหมด ยังพบ IOC ที่ Tag ว่าเกี่ยวข้องกับ Aisuru ต่อเนื่องจนถึงเดือนกรกฎาคม 2026
• Detection Rules ที่ให้ไว้ควรผ่านการทดสอบในสภาพแวดล้อม Lab ขององค์กรก่อนนำไปใช้งานจริงบน Production เพื่อประเมิน False Positive ที่อาจเกิดขึ้น

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

Aisuru สะท้อนให้เห็นวิวัฒนาการของ IoT Botnet ที่ TXEC เฝ้าติดตามมาต่อเนื่อง จาก Mirai รุ่นดั้งเดิมที่มุ่งเน้นเพียงการโจมตี DDoS ไปสู่ Multi-purpose Platform ที่มีทั้งความสามารถ Proxy Monetization, Reverse Shell และการเชื่อมโยงกับ Ecosystem อื่นอย่าง Kimwolf ประเด็นที่ TXEC อยากเน้นย้ำเป็นพิเศษมีดังนี้

1. Supply-chain Propagation ผ่าน Firmware Update คือความเสี่ยงที่มองข้ามไม่ได้

เหตุการณ์ TOTOLINK แสดงให้เห็นว่าการยึด Update Path ของอุปกรณ์เครือข่ายสามารถเพิ่ม Bot ได้กว่า 100,000 เครื่องในเวลาอันสั้น โดยไม่ต้องอาศัยการสแกนช่องโหว่จากภายนอกทีละเครื่อง องค์กรและ Vendor ควรให้ความสำคัญกับ Firmware Signing และ Update Server Validation มากขึ้น เพราะ Attack Vector ลักษณะนี้ขยายผลกระทบได้เร็วกว่า Scan-and-Exploit แบบดั้งเดิมมาก

2. ตัวเลข Hyper-volumetric DDoS สะท้อนว่า Threshold การป้องกันแบบเดิมอาจไม่เพียงพอ

เหตุการณ์ระดับ 15-31 Tbps ที่ยืนยันแล้วจากหลายแหล่งชี้ว่าการพึ่งพา On-premise DDoS Mitigation เพียงอย่างเดียวไม่เพียงพออีกต่อไป องค์กรที่มี Internet-facing Service สำคัญจำเป็นต้องมี Always-on Upstream Scrubbing และ Automatic Diversion ที่ทำงานได้ภายในไม่กี่นาที เนื่องจากเหตุการณ์ระดับนี้มักสิ้นสุดก่อนกระบวนการ Manual Escalation จะทำงานทัน

3. Kimwolf/Proxyware Ecosystem คือสัญญาณของการต่อยอดมูลค่าจากอุปกรณ์ที่ถูกยึด

การที่ Aisuru ไม่ได้หยุดอยู่แค่ DDoS แต่ขยายไปสู่ Residential Proxy ผ่าน ADB Chain บน Android สะท้อนว่าผู้ปฏิบัติการมองอุปกรณ์ที่ยึดได้เป็นทรัพยากรที่สร้างรายได้ได้หลายทาง องค์กรจึงควรตรวจสอบอุปกรณ์ Android/TV Box ที่เชื่อมต่อกับเครือข่ายองค์กรว่าเปิด ADB โดยไม่จำเป็นหรือไม่ ควบคู่ไปกับการเฝ้าระวัง Aisuru Core บน Linux/IoT

4. อย่า Assume Infrastructure เดิมหลัง Law Enforcement Disruption

แม้ DOJ จะ Disrupt C2 สำคัญไปแล้ว แต่ IOC ที่ยังคงถูก Tag ต่อเนื่องจนถึงกลางปี 2026 แสดงว่า Bot และ Infrastructure บางส่วนยังไม่ถูกกำจัดทั้งหมด องค์กรควรตรวจสอบ Last Seen และ Ownership ของ IOC ทุกครั้งก่อน Block/Allow แทนการเชื่อว่าการ Disruption หมายถึงภัยคุกคามสิ้นสุดลงแล้ว

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

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

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

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