รายงานสืบสวนเหตุการณ์จริง : เมื่อ Backdoor ซ่อนตัวเป็น "404 Not Found" | PHP Webshell Investigation

⚠️ หมายเหตุการเผยแพร่: รายงานฉบับนี้ผ่านกระบวนการ Anonymization เพื่อปกป้องข้อมูลขององค์กรเจ้าของระบบ IOC ทั้งหมดได้รับการยืนยันและเหมาะสมสำหรับการนำไปใช้ตรวจสอบและป้องกันในระบบของท่าน

บทสรุปสำหรับผู้บริหาร (Executive Summary)

ทีม TXEC ได้ดำเนินการตรวจพิสูจน์หลักฐานดิจิทัล (Digital Forensics) บน Web Server ขององค์กรแห่งหนึ่งในประเทศไทย ภายหลังพบสัญญาณความผิดปกติในระบบ ผลการตรวจสอบยืนยันว่า มีการฝัง PHP Webshell/Backdoor ไว้บนระบบ โดยผู้โจมตีสามารถเข้าถึงได้จริงและมีพฤติกรรมที่สอดคล้องกับการสำรวจฐานข้อมูลและการสร้างช่องทาง Persistence

จุดที่น่าสนใจเป็นพิเศษในกรณีนี้คือ Webshell ถูกออกแบบให้ ตอบกลับ HTTP Status 404 Not Found แม้ว่าไฟล์จะมีอยู่จริงและสามารถรับคำสั่งได้ เป็นเทคนิคพรางตัวที่ทำให้ระบบ Log Monitoring ทั่วไปมองข้ามได้ง่าย

นอกจากนี้ยังพบหลักฐานการเชื่อมต่อออกไปยัง External IP ที่เป็น Proxy หรือ Tunnel Candidate ซึ่งอาจบ่งชี้ถึงการเตรียมช่องทาง Command and Control

1. บทนำ

การตรวจพบไฟล์ PHP Webshell/Backdoor บน Web Server ถือเป็นหนึ่งในสัญญาณสำคัญที่บ่งชี้ว่าระบบอาจถูกบุกรุก (Compromise) และผู้ไม่หวังดีสามารถสร้างกลไกสำหรับคงสิทธิ์การเข้าถึง (Persistence) ภายในระบบได้สำเร็จ

ในทางปฏิบัติ ผู้โจมตีมักไม่หยุดแค่การฝัง Webshell เพียงอย่างเดียว แต่ดำเนินการต่อเนื่องด้วยกิจกรรมต่าง ๆ เช่น การสร้าง Backdoor เพื่อขโมยข้อมูล (Data Exfiltration), การเคลื่อนย้ายไปยังระบบภายใน (Lateral Movement) และการติดตั้งกลไกสำรองเพื่อกลับเข้ามาในระบบแม้ว่า Webshell ตัวแรกจะถูกลบออกไปแล้ว

รายงานนี้สรุปผลการสืบสวนเหตุการณ์ (Incident Investigation) และการตรวจพิสูจน์หลักฐานดิจิทัล (Digital Forensics) ครอบคลุมตั้งแต่การตรวจสอบไฟล์ต้องสงสัย การวิเคราะห์ลำดับเหตุการณ์ การระบุ IOC ไปจนถึง Detection Rules ที่พร้อมใช้งาน

2. กระบวนการสืบสวน (Investigation Process)

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

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

กำหนดระบบเป้าหมาย ขอบเขตเวลา และคำถามหลัก โดยเน้นตรวจสอบว่าไฟล์ต้องสงสัยที่พบใน /var/www/html/ เป็น Webshell/Backdoor จริงหรือไม่ และมีหลักฐานการใช้งานในสภาพแวดล้อมจริงหรือเปล่า

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

รวบรวมหลักฐานที่เกี่ยวข้อง ได้แก่ Metadata และ Hash ของไฟล์ต้องสงสัย, Source Code, Apache/httpd Access Log, ข้อมูล Directory และไฟล์ใน Web Root, ข้อมูล User Library, ผลตรวจ Cron/Systemd/rc.local และ Network/Service Exposure

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

ตรวจสอบไฟล์และ Log ที่รวบรวมได้โดยคัดกรองจาก File Type, Timestamp, Owner/Group, Permission, Webshell Signature และ Access Pattern เช่น POST Request, User-Agent ที่ผิดปกติ, Obfuscation Function และ HTTP 404 ที่ใช้พรางตัว

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

เชื่อมโยงข้อมูลจากหลายแหล่ง ได้แก่ Access Log, Source Code, Metadata, Path Mapping, phpMyAdmin Activity, IP Address ที่น่าสงสัย, User Library และ Timeline 14 วันก่อนและหลังเหตุการณ์

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

สรุปผลการวิเคราะห์ทั้งในมุมผู้บริหารและเชิงเทคนิค พร้อมจัดทำ Findings, Impact, Risk, IOC, ข้อจำกัดของหลักฐาน และข้อเสนอแนะสำหรับ Containment, Eradication, Recovery และ Hardening

3. ข้อค้นพบสำคัญ (Key Findings)

3.1 การยืนยัน Webshell/Backdoor

จากหลักฐานทั้งหมดที่ตรวจสอบ ทีมยืนยันว่า ไฟล์ PHP ที่พบใน /var/www/html/ เป็น Webshell/Backdoor อย่างแน่นอน โดยมีพฤติกรรมดังต่อไปนี้

รับคำสั่งผ่าน HTTP POST

ไฟล์รับ Input ผ่าน $_POST และ $_GET เพื่อให้ผู้โจมตีสามารถส่งคำสั่งเข้ามาจากระยะไกลได้

ถอดรหัสด้วย base64_decode()

Payload ถูกเข้ารหัสก่อนส่งมาเสมอ เพื่อหลีกเลี่ยงการตรวจจับของ Signature-based Detection

Execute ด้วย eval()

รันโค้ดที่ Decode ออกมาในทันที ทำให้ไม่มีไฟล์ Malicious เพิ่มเติมที่ต้องเขียนลง Disk

เปิด Session ออกสู่ภายนอก

มีการสร้าง Connection ออกไปยัง External IP ซึ่งอาจเป็นช่องทางสำหรับ Data Exfiltration

ปิด Error Reporting

ป้องกันข้อมูล Debug รั่วไหลออกไปและช่วยลดร่องรอยที่ตรวจจับได้

ตอบกลับ HTTP 404 (เทคนิคพรางตัวหลัก)

แม้ไฟล์จะมีอยู่จริงและทำงานได้ แต่ถูกตั้งให้ตอบกลับสถานะ 404 Not Found เสมอ ทำให้ระบบ Log Monitoring ที่ Filter เฉพาะ Status 200 หรือ 500 มองข้ามการเข้าถึงไฟล์นี้ได้โดยสมบูรณ์

3.2 ลำดับเหตุการณ์ (Attack Timeline)

จากการวิเคราะห์ Apache/httpd Access Log พบลำดับเหตุการณ์ที่มีความต่อเนื่องและชัดเจน

[ก่อนเหตุการณ์]
IP 10.1.23.69 → เข้าใช้งาน phpMyAdmin-like Application ที่ /tmp/
                → Authenticate สำเร็จในฐานะ user root
                → Browse ฐานข้อมูลสำคัญ (mysql, mysql.user, general_log,
                  slow_log, database ขององค์กร)

[วันที่ 09 มิถุนายน 2026]
IP 10.1.23.69 → เรียกใช้งาน Backdoor File ทั้งแบบ GET และ POST Method
                → HTTP Response แสดงเป็น 404 แต่ไฟล์ทำงานจริง

[ต่อมา พบใน nohup.out]
เครื่องเป้าหมาย → สร้าง Connection ออกไปยัง 103.146.230.91:80
                   → Proxy/Tunnel Candidate (C2 Communication ที่เป็นไปได้)

3.3 phpMyAdmin Exposure: High-Risk Pivot Point

พบว่า phpMyAdmin-like Application เวอร์ชันเก่าถูกวางไว้ที่ /tmp/ ซึ่ง Map กับ /var/www/html/[app]/tmp หรือ /wwhome/[app]/tmp บน Web Root และมีการ Authenticate สำเร็จเป็น user root ก่อนที่จะมีการเรียกใช้งาน Backdoor

แม้ยังไม่พบหลักฐาน POST หรือการแก้ไขข้อมูลผ่าน phpMyAdmin โดยตรง แต่ควรถือว่าเป็น High-Risk Exposure และ Possible Recon/Pivot Point และควรได้รับการจัดการโดยเร็ว

3.4 Hardening Risk ที่ตรวจพบเพิ่มเติม

SSH Root Login เปิดอยู่

ควรปิดการ Login ด้วย Root โดยตรงและเปลี่ยนมาใช้ Key-based Authentication แทน

Password Authentication บน SSH ยังเปิดใช้งาน

ควรปิดและบังคับใช้ SSH Key เพื่อลดความเสี่ยงจาก Brute Force

FTP Service เปิดให้บริการอยู่

FTP ส่งข้อมูลในรูป Plaintext รวมถึง Credential ควรพิจารณาปิดหรือแทนด้วย SFTP

MySQL Listen บน Interface ที่กว้างเกินไป

ตรวจสอบว่า MySQL Bind อยู่บน Localhost (127.0.0.1) เท่านั้น ไม่ใช่ 0.0.0.0

phpMyAdmin เวอร์ชันเก่าอยู่บน Web Root

ควรปิดหรือย้ายออกจาก Public Path ทันที เนื่องจากเป็นเป้าหมายหลักในขั้นตอน Reconnaissance ของผู้โจมตี

4. แหล่งหลักฐานและผลการตรวจสอบ

Webshell File Metadata (ใช้ตรวจสอบ: Owner, Permission, mtime/ctime, Hash, File Type)

ยืนยันเป็น PHP Script พร้อมค่า SHA256 สำหรับนำไปใช้เป็น IOC

Source Code (ใช้ตรวจสอบ: Behavior และ Execution Primitive)

พบ Fake 404 Response, Session Handling, base64_decode, eval และ Custom Response Wrapper

Apache/httpd Access Log (ใช้ตรวจสอบ: การเรียกใช้งานก่อน Cutoff)

พบ GET และ POST Request จาก IP เป้าหมายไปยัง Backdoor File

Filesystem Checks (ใช้ตรวจสอบ: Backdoor เพิ่มเติมใน Web Root ชั้นแรก)

ยังไม่พบไฟล์ PHP หรือ Backdoor เพิ่มเติมในพื้นที่ที่ตรวจสอบแล้ว

Account Artifacts (ใช้ตรวจสอบ: User Library และ Login Session)

Library เป็น Shell User มี Session เก่าจากสิงหาคม 2025 แต่ไม่พบ Command History ก่อน Cutoff

Service/Process/Network (ใช้ตรวจสอบ: Exposure และ Persistence เบื้องต้น)

พบ Hardening Risk หลายรายการ ได้แก่ SSH Root Login, Password Auth, FTP และ MySQL Listen

nohup.out (ใช้ตรวจสอบ: Proxy/Tunnel Indicator)

พบ Suspicious Connection ไปยัง 103.146.230.91:80 ซึ่งเป็น Proxy/Tunnel Candidate

5. Indicators of Compromise (IOC)

IOC ชุดนี้ผ่านการยืนยันจากหลักฐานในเหตุการณ์จริง พร้อมสำหรับการนำไปใช้ใน SIEM, EDR, WAF/IPS และ Threat Intelligence Platform

✅ SHA-256 [CONFIRMED / HIGH]

bfbd293650b817f9f654e7f0695def0b690aed862301a9a6ea2417e2ee01df97

Hash ของ PHP Backdoor File ที่ตรวจพบ ใช้สำหรับ File-based Detection

✅ Path File [CONFIRMED / HIGH]

/var/www/html/backdoorfile.php

ที่อยู่ของ Backdoor บนระบบ ควรตรวจสอบ Filesystem และ Backup

✅ IP Address [CONFIRMED / HIGH]

10.1.23.69

Internal IP ที่เชื่อมต่อกับ phpMyAdmin และเรียกใช้งาน Backdoor File

👁️ User-Agent [OBSERVED / MEDIUM]

python-requests/2.34.2

พบการใช้งานในการส่ง HTTP POST Request ไปยัง Backdoor

👁️ User-Agent [OBSERVED / MEDIUM]

PostmanRuntime/7.54.0

พบการใช้งานในการส่ง POST พร้อม Token Parameter

👁️ Network IOC [OBSERVED / MEDIUM]

103.146.230.91:80

External IP ที่พบใน nohup.out เป็น Proxy/Tunnel/C2 Candidate

✅ Attack Technique [CONFIRMED / HIGH]

HTTP POST ไปยังไฟล์ .php ที่ตอบกลับ Status 404

เทคนิคพรางตัวหลักของ Backdoor ในเหตุการณ์นี้

Threat Hunting Guidance:

• ตรวจสอบ HTTP POST ไปยังไฟล์ PHP ที่ตอบกลับ 404 ใน Web Server Log
• ตรวจสอบการใช้งาน User-Agent python-requests และ PostmanRuntime บน Production Server
• ตรวจสอบการเชื่อมต่อออกไปยัง 103.146.230.91:80 หรือปลายทาง External ที่ไม่รู้จัก
• ตรวจสอบ Web Server Log, Application Log, Process/Command History และ nohup.out

6. Detection Rules

6.1 YARA Rule: Exact Hash Detection

ใช้ตรวจจับไฟล์ Backdoor ตัวนี้โดยตรงผ่าน SHA-256 Hash ความแม่นยำสูงสุด ไม่มี False Positive

yara

import "hash"

rule TXEC_PHP_Webshell_Confirmed_SHA256
{
    meta:
        author      = "TXEC Team"
        description = "Detects confirmed PHP webshell by SHA-256 hash"
        category    = "Webshell"
        severity    = "critical"
        confidence  = "high"
        date        = "2026-07-15"
        reference   = "TXEC Incident Investigation"

    condition:
        filesize > 0 and
        hash.sha256(0, filesize) ==
        "bfbd293650b817f9f654e7f0695def0b690aed862301a9a6ea2417e2ee01df97"
}

6.2 YARA Rule: PHP Webshell Behavior Detection

ใช้ตรวจจับ PHP Webshell โดยทั่วไปจากพฤติกรรม (Behavioral) เหมาะสำหรับ Hunt หา Webshell ที่ดัดแปลงแล้ว

yara

rule TXEC_Suspicious_PHP_Webshell_Behavior
{
    meta:
        author      = "TXEC Team"
        description = "Detects PHP files containing common webshell behavior"
        category    = "Webshell"
        severity    = "high"
        confidence  = "medium"
        date        = "2026-07-15"

    strings:
        $php    = "<?php" ascii nocase

        /* User-controlled input */
        $input1 = "$_POST"    ascii
        $input2 = "$_GET"     ascii
        $input3 = "$_REQUEST" ascii
        $input4 = "php://input" ascii nocase

        /* Command execution */
        $cmd1 = "shell_exec(" ascii nocase
        $cmd2 = "system("     ascii nocase
        $cmd3 = "passthru("   ascii nocase
        $cmd4 = "exec("       ascii nocase
        $cmd5 = "proc_open("  ascii nocase
        $cmd6 = "popen("      ascii nocase

        /* Obfuscation or decoding */
        $obf1 = "base64_decode(" ascii nocase
        $obf2 = "gzinflate("     ascii nocase
        $obf3 = "str_rot13("     ascii nocase
        $obf4 = "gzuncompress("  ascii nocase
        $obf5 = "eval("          ascii nocase

    condition:
        filesize < 2MB and
        $php and
        1 of ($input*) and
        1 of ($cmd*) and
        1 of ($obf*)
}

6.3 YARA Rule: IOC Artifact Detection

ใช้ตรวจจับ Artifact ที่เกี่ยวข้องกับเหตุการณ์นี้โดยตรง ทั้ง External IP, User-Agent และ Token Pattern

yara

rule TXEC_Incident_IOC_Artifacts
{
    meta:
        author      = "TXEC Team"
        description = "Detects incident-related network and client artifacts"
        category    = "Incident IOC"
        severity    = "medium"
        confidence  = "medium"
        date        = "2026-07-15"

    strings:
        $external_ip  = "103.146.230.91"      ascii wide
        $ua_python    = "python-requests/2.34.2" ascii wide nocase
        $ua_postman   = "PostmanRuntime/7.54.0"  ascii wide nocase
        $token        = "token=token"            ascii wide nocase

    condition:
        2 of them
}

6.4 Sigma Rule: Suspicious HTTP POST to PHP Using Automation Tools

ใช้ตรวจจับ HTTP POST ไปยังไฟล์ PHP ผ่าน User-Agent ที่เกี่ยวข้องกับ Automation เหมาะสำหรับ SIEM และ WAF

yaml

title: TXEC Suspicious HTTP POST to PHP Using Automation Tools
id: 07f51310-4c78-4d28-9fc8-202607150001
status: experimental
description: Detects HTTP POST requests to PHP files using observed automated User-Agents
author: TXEC Team
date: 2026-07-15

logsource:
    category: webserver

detection:
    method:
        http_method: POST

    php_target:
        url_path|endswith: ".php"

    suspicious_user_agent:
        user_agent|contains:
            - "python-requests/2.34.2"
            - "PostmanRuntime/7.54.0"

    condition: method and php_target and suspicious_user_agent

fields:
    - source_ip
    - destination_ip
    - hostname
    - url_path
    - http_method
    - user_agent
    - http_status
    - bytes_out

falsepositives:
    - Authorized API integration
    - Application testing using Postman
    - Internal automation scripts

level: high

tags:
    - attack.persistence
    - attack.t1505.003
    - attack.execution
    - attack.t1059.004

6.5 Sigma Rule: Connection to Observed External Proxy/Tunnel Candidate

ใช้ตรวจจับการเชื่อมต่อออกไปยัง External IP ที่พบในเหตุการณ์ ซึ่งอาจเป็น C2 Communication

yaml

title: TXEC Connection to Observed External Proxy or Tunnel Candidate
id: 6da4f0ee-df93-4b52-8af9-202607150002
status: experimental
description: Detects outbound connections to an external IP observed during the incident
author: TXEC Team
date: 2026-07-15

logsource:
    category: network_connection

detection:
    destination:
        destination_ip: "103.146.230.91"
        destination_port: 80

    condition: destination

fields:
    - source_ip
    - source_hostname
    - user
    - process_name
    - process_command_line
    - destination_ip
    - destination_port
    - bytes_sent
    - bytes_received

falsepositives:
    - Authorized connection confirmed by the organization

level: high

tags:
    - attack.command_and_control
    - attack.t1071.001
    - attack.proxy
    - attack.t1090

7. ข้อเสนอแนะการตอบสนองและป้องกัน

⚡ ระยะเร่งด่วน: Containment (ทำทันทีหลังเก็บหลักฐานครบ)

1. แยกเครื่องเป้าหมายออกจากเครือข่ายหลัก (Network Isolation) และทำ Quarantine หรือย้ายไฟล์ Backdoor ออกจาก Web Root ผ่าน Change Control ที่องค์กรกำหนด
2. เปลี่ยน Permission หรือ Block การเข้าถึง ผ่าน Web Server หากต้องการเก็บไฟล์ไว้วิเคราะห์ต่อ
3. ปิดหรือจำกัดการเข้าถึง phpMyAdmin เฉพาะ IP Admin ผ่าน VPN หรือ Jump Host เท่านั้น
4. เปลี่ยนรหัสผ่านทุกบัญชี ที่เกี่ยวข้อง ได้แก่ MySQL root, Database User, Linux User ที่เชื่อมกับ Web Root, SSH Account และ Web Application Admin
5. ตรวจสอบ Process ที่ยังทำงานอยู่ และ Active Network Connection เพื่อมั่นใจว่าไม่มี Webshell Session, Reverse Tunnel หรือ Process แปลกปลอมค้างอยู่

📋 ระยะสั้น: Monitoring & Detection Enhancement

1. สร้าง Detection Rule สำหรับ HTTP POST ไปยังไฟล์ PHP ที่ตอบกลับ 404 ดูรายละเอียดใน Sigma Rule 6.4 ข้างต้น
2. Monitor User-Agent ที่ผิดปกติ: python-requests, PostmanRuntime, curl, wget, Go-http-client และ Request ที่ไม่มี Referer
3. Monitor การเข้าถึง Admin Path: /tmp/, /phpMyAdmin/, /pma/, /admin/, /dbadmin/, /setup/, /scripts/
4. Monitor Outbound Connection ไปยัง 103.146.230.91:80 และ External IP ที่ไม่รู้จัก ดูรายละเอียดใน Sigma Rule 6.5
5. ส่ง Log สำคัญเข้า SIEM: Apache/httpd Access Log, Error Log, SSH Log, sudo/su Log, Cron Log, MySQL Log, Systemd Journal และ Audit Log
6. กำหนด Log Retention อย่างน้อย 90 ถึง 180 วัน
7. จัดทำ Baseline ของไฟล์ใน Web Root (Hash, Owner, Permission, Timestamp) เพื่อใช้เปรียบเทียบเมื่อมีการเปลี่ยนแปลง

🔒 ระยะต่อเนื่อง: Hardening & Preparedness

1. จัดทำ Incident Playbook สำหรับกรณีตรวจพบ Webshell ครอบคลุมตั้งแต่การเก็บหลักฐาน การ Hash ไฟล์ การตรวจ Log จนถึงการตัดสินใจ Isolate ระบบ
2. กำหนด Escalation Workflow ว่าเมื่อพบ Webshell ต้องแจ้งใคร: SOC, System Owner, Web Developer, DBA, Management, Legal, Data Protection Officer
3. จัดทำ Linux Web Server Security Checklist: Cron, Systemd, rc.local, SSH Key, Web Root, Upload Directory, PHP File, Suspicious Process, Network Connection, Log และบัญชีที่มี Shell
4. ซ้อม Tabletop Exercise หรือ Technical Drill เป็นระยะเพื่อให้ทีมเข้าใจบทบาทของตนเองเมื่อเกิดเหตุจริง
5. ปิด SSH Root Login และบังคับใช้ Key-based Authentication พร้อม MFA
6. ปิด FTP และแทนด้วย SFTP หรือ SCP
7. Bind MySQL บน Localhost (127.0.0.1) เท่านั้น ไม่ควร Listen บน 0.0.0.0

8. ข้อจำกัดของการสืบสวน

• การตรวจสอบในรายงานนี้อ้างอิงจากหลักฐานที่ได้รับ ณ ช่วงเวลาที่กำหนด ไม่สามารถยืนยันได้ว่าครอบคลุม Backdoor ทุกตัวที่อาจมีอยู่ในระบบ
• ไม่พบ Command History ก่อน Cutoff Date ทำให้ไม่สามารถระบุ Initial Access Vector ได้อย่างแน่ชัด
• phpMyAdmin Activity ที่ตรวจพบยังไม่มีหลักฐาน POST โดยตรง จึงควรตีความเป็น High-Risk Exposure มากกว่าการยืนยันว่าข้อมูลถูกแก้ไขผ่านช่องทางนั้น
• External IP 103.146.230.91 จัดว่าเป็น Proxy/Tunnel Candidate ยังไม่มีการยืนยันว่าเป็น C2 Server ที่ Active

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

กรณีนี้เป็นตัวอย่างที่ดีของ Webshell ที่ผ่านการออกแบบมาเพื่อหลีกเลี่ยงการตรวจจับ เทคนิค Fake 404 ที่ใช้ในที่นี้เป็นเทคนิคที่ไม่ซับซ้อนแต่มีประสิทธิภาพสูงมากในการต่อต้าน Log Monitoring ทั่วไป เพราะ Security Team ส่วนใหญ่มักตั้ง Alert บน HTTP 200 หรือ 500 มากกว่า 404

ประเด็นที่ TXEC อยากเน้นจากกรณีนี้

1. การ Monitor แบบ Status-based อย่างเดียวไม่เพียงพอ

องค์กรควรวิเคราะห์ Pattern ของ Request ร่วมด้วย เช่น POST ไปยังไฟล์ที่ตอบ 404, User-Agent ที่ไม่ใช่ Browser และ Byte Size ที่ผิดปกติ

2. phpMyAdmin บน Production คือความเสี่ยงที่ประเมินต่ำเกินไปเสมอ

Database Admin Tool เวอร์ชันเก่าที่ Accessible จาก Web เป็นเป้าหมายที่ผู้โจมตีค้นหาเป็นอันดับต้น ๆ ในขั้นตอน Reconnaissance

3. nohup.out เป็นแหล่งหลักฐานที่มักถูกมองข้าม

ไฟล์ nohup.out ที่พบหลักฐาน Proxy/Tunnel ในกรณีนี้เป็นตัวอย่างที่ดีว่า Forensic Evidence บางอย่างอยู่ในที่ที่ไม่ได้คาดคิด ทีมสืบสวนควรมี Checklist ที่ครอบคลุมพื้นที่เหล่านี้

4. Detection Rules ที่แชร์ในรายงานนี้ได้มาจากเหตุการณ์จริงในไทย

ซึ่งหมายความว่ามีความเกี่ยวข้องสูงกับสภาพแวดล้อมขององค์กรในประเทศไทย TXEC ขอแนะนำให้นำไปทดสอบใช้ในระบบ SIEM หรือ EDR ของท่านได้ทันที

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

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

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

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