แฮกเกอร์ใช้ข้อมูลสาธารณะหาช่องโหว่ของเราได้อย่างไร และเราเหลือเวลาจริงเท่าไร

เวลาเราพูดถึง "โดนแฮก" คนส่วนใหญ่จะนึกถึงภาพคนใส่ฮู้ดนั่งเจาะระบบด้วยช่องโหว่ลับที่ไม่มีใครรู้ ความจริงในปี 2026 กลับตรงข้ามเกือบสิ้นเชิง งานส่วนใหญ่ของผู้โจมตีไม่ได้เริ่มจากการค้นพบอะไรใหม่ แต่เริ่มจากการอ่านสิ่งที่เราประกาศให้โลกรู้อยู่แล้ว ทั้งประกาศช่องโหว่ของผู้ผลิต โค้ดแพตช์บน GitHub รายงานของนักวิจัย และร่องรอยที่ระบบเราทิ้งไว้บนอินเทอร์เน็ต

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

ตัวเลขที่ควรรู้ก่อนอ่านต่อ

รายงาน Verizon DBIR ฉบับปี 2026 ให้ข้อสรุปที่เปลี่ยนวิธีคิดไปพอสมควร คือ การเจาะผ่านช่องโหว่แซงหน้าการใช้รหัสผ่านที่ขโมยมา กลายเป็นช่องทางเข้าอันดับหนึ่ง เป็นครั้งแรกในรอบ 19 ปีของรายงาน และในกลุ่มที่ถูกเจาะผ่านช่องโหว่ อุปกรณ์ขอบเครือข่ายอย่าง VPN และไฟร์วอลล์กระโดดจาก 3% ขึ้นมาเป็น 22%

อีกด้านหนึ่งคือปริมาณ ปี 2025 มี CVE ถูกประกาศ 48,185 รายการ โตจากปีก่อนราว 20% และครึ่งแรกของปี 2026 พุ่งเป็น 35,364 รายการ หรือประมาณหนึ่งช่องโหว่ใหม่ทุก 7 นาที ฟังดูน่าหมดหวัง แต่ตัวเลขที่สำคัญกว่าคือ มีเพียงราว 0.24% ของ CVE ครึ่งปีแรก 2026 ที่มีหลักฐานว่าถูกใช้โจมตีจริงจนเข้าไปอยู่ในแคตตาล็อก KEV ของ CISA

ปัญหาของเราไม่ใช่ "ช่องโหว่เยอะเกินไป" แต่คือ "เราแยกไม่ออกว่าตัวไหนใน 0.24% นั้นคือตัวที่จะมาถึงเราพรุ่งนี้"

และช่องว่างที่อันตรายที่สุดอยู่ตรงนี้ รายงานเดียวกันระบุว่าเวลาเฉลี่ยที่องค์กรใช้ปิดช่องโหว่จนครบคือ 43 วัน เพิ่มขึ้นจาก 32 วันในปีก่อน ขณะที่ช่องโหว่ที่ถูกใช้จริงจำนวนมากถูกโจมตีภายในไม่กี่ชั่วโมงหลังประกาศ

ห่วงโซ่ข้อมูลสาธารณะที่ผู้โจมตีใช้

สิ่งที่หลายคนเข้าใจผิดคือคิดว่าผู้โจมตีต้อง "หา" ช่องโหว่เอง จริง ๆ แล้วมีระบบนิเวศข้อมูลเปิดที่ครบวงจรมาก และเกือบทั้งหมดถูกสร้างขึ้นด้วยเจตนาดีเพื่อให้ฝ่ายป้องกันทำงานได้ ปัญหาคือมันใช้ได้ทั้งสองทาง

1. ประกาศช่องโหว่และแพตช์ของผู้ผลิต

ทุกครั้งที่ผู้ผลิตออก security advisory พร้อมเวอร์ชันแก้ นั่นคือการบอกใบ้ที่ชัดที่สุดว่าโค้ดตรงไหนมีปัญหา เทคนิคที่เรียกว่า patch diffing คือการเทียบโค้ดก่อนและหลังแพตช์เพื่อย้อนหาว่าแก้อะไร ในซอฟต์แวร์โอเพนซอร์สที่มี commit เปิดเผย งานนี้บางครั้งใช้เวลาไม่ถึงชั่วโมง ผลลัพธ์คือช่องโหว่ที่เรียกว่า n-day คือรู้แล้ว แพตช์แล้ว แต่ยังมีคนไม่ได้อัปเดตอีกมหาศาล

2. ฐานข้อมูลจัดลำดับความสำคัญ

NVD, CISA KEV, VulnCheck KEV และคะแนน EPSS ถูกออกแบบมาให้ทีมความปลอดภัยรู้ว่าควรรีบตัวไหน ผู้โจมตีอ่านรายการเดียวกันเพื่อรู้ว่าตัวไหนคุ้มค่าที่จะยิงเป็นวงกว้าง ที่น่าสนใจคือรายงาน State of Exploitation ของ VulnCheck พบว่าปี 2025 มีช่องโหว่ 884 รายการที่ปรากฏหลักฐานการถูกใช้โจมตีครั้งแรก และ 28.96% ของช่องโหว่เหล่านั้นมีหลักฐานว่าถูกใช้ตั้งแต่ก่อนหรือในวันเดียวกับที่ CVE ถูกเผยแพร่ เพิ่มขึ้นจาก 23.6% ในปี 2024

3. โค้ดสาธิตและเทมเพลตสแกน

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

4. ข้อมูลสแกนทั้งอินเทอร์เน็ต

บริการอย่าง Shodan, Censys และ FOFA เก็บ banner, TLS certificate, favicon hash และ HTTP header ของทุกอย่างที่เปิดพอร์ตอยู่บนอินเทอร์เน็ต แปลว่าเมื่อมีช่องโหว่ใหม่ของอุปกรณ์ยี่ห้อหนึ่ง คำถามว่าใครใช้ของยี่ห้อนี้อยู่บ้าง ตอบได้ในไม่กี่วินาที โดยไม่ต้องแตะเป้าหมายเลยสักครั้ง สิ่งที่เราคิดว่าไม่มีใครรู้หรอกว่าเรามีเซิร์ฟเวอร์ตัวนี้ แทบไม่จริงอีกต่อไป

5. ความลับที่หลุดจากโค้ดและ CI

รายงาน State of Secrets Sprawl ปี 2026 ของ GitGuardian พบ secret ที่ถูก hardcode ราว 29 ล้านรายการ ในปี 2025 เพิ่มขึ้น 34% จากปีก่อน และตัวเลขที่เจ็บที่สุดคือ 32.2% ของ repository ภายในองค์กรมี secret ฝังอยู่ เทียบกับ 5.6% ใน repo สาธารณะ แปลว่าเมื่อผู้โจมตีเข้าถึง repo ภายในได้ครั้งเดียว มักได้กุญแจต่อไปฟรี ๆ อีกหลายดอก นอกจากนี้ 64% ของ secret ที่ยืนยันว่าใช้งานได้ในปี 2022 ยังใช้ได้อยู่จนถึงสี่ปีให้หลัง เพราะไม่มีใครหมุนคีย์

6. ห่วงโซ่อุปทานของแพ็กเกจ

เหตุการณ์เวิร์ม Shai-Hulud บน npm ช่วงปลายปี 2025 คือกรณีตัวอย่างที่ชัดที่สุด มัลแวร์ฝังตัวในแพ็กเกจ ค้นหา token ของ npm และ GitHub ในเครื่องที่ติดตั้ง แล้วเผยแพร่เวอร์ชันติดเชื้อของแพ็กเกจอื่นที่เหยื่อมีสิทธิ์ต่อโดยอัตโนมัติ กลายเป็นเวิร์มที่แพร่ตัวเองได้จริงในระบบนิเวศ JavaScript พร้อมทั้งดัน workflow ของ GitHub Actions เข้าไปในทุก repo ที่เข้าถึงได้เพื่อดูดความลับออกมา ระลอกที่สองตามมาในเดือนพฤศจิกายน 2025

ไทม์ไลน์จริงของช่องโหว่หนึ่งตัว

• ก่อนประกาศหลายสัปดาห์ งานวิจัยของ GreyNoise พบว่าจากการสังเกตการสแกนที่พุ่งผิดปกติ 216 ครั้ง มี 80% ที่ตามมาด้วย CVE ใหม่ภายในหกสัปดาห์ และ 50% ภายในสามสัปดาห์ พูดง่าย ๆ คือความเคลื่อนไหวของผู้โจมตีบางครั้งมาถึงก่อนประกาศทางการ

• วันประกาศ (T0) advisory ออก แพตช์ออก และเกือบสามในสิบของช่องโหว่ที่ถูกใช้จริงมีร่องรอยการโจมตีตั้งแต่วันนี้หรือก่อนหน้า

• ชั่วโมงถึงวันแรก PoC และเทมเพลตสแกนโผล่ การสแกนเป็นวงกว้างเริ่มขึ้น สำหรับช่องโหว่อุปกรณ์ขอบเครือข่ายหลายตัวในปี 2025 การสแกนเริ่มภายในไม่กี่ชั่วโมงหลัง advisory

• สัปดาห์ที่ 1 ถึง 6 ผู้โจมตีที่ยิงเป็นวงกว้างเก็บเกี่ยวเหยื่อ วางแบ็กดอร์ ขาย access ต่อ

• วันที่ 43 ซึ่งเป็นค่ากลางของเรา องค์กรทั่วไปเพิ่งแพตช์เสร็จ

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

AI กำลังบีบหน้าต่างนี้ให้แคบลงอีก

งานวิจัยของ Anthropic ที่วัดผลกระทบของโมเดลภาษาต่อการสร้าง exploit จากแพตช์ (n-day) ให้ตัวเลขที่ควรอ่านอย่างจริงจัง จากแพตช์ความปลอดภัยของ Firefox 18 รายการ โมเดลที่เก่งที่สุดในการทดสอบสร้าง PoC ที่ทำงานได้ 14 รายการ โดย PoC แรกใช้เวลาราว 12 นาที และสร้าง exploit ที่รันโค้ดได้จริง 8 รายการภายในราว 12 ชั่วโมง ส่วนฝั่ง Windows kernel 21 รายการ ทำ PoC ได้ 18 รายการ โดยตัวแรกใช้เวลา 31 นาที

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

ทำไมเว็บธุรกิจทั่วไปถึงอยู่ในเป้า

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

สิ่งที่ทีมพัฒนาทำได้จริง เรียงตามผลตอบแทน

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

2. จัดลำดับด้วย KEV และ EPSS ไม่ใช่ CVSS อย่างเดียว CVSS บอกว่าร้ายแรงแค่ไหนถ้าถูกใช้ ส่วน KEV บอกว่าถูกใช้จริงแล้ว และ EPSS บอกความน่าจะเป็นที่จะถูกใช้ ในทางปฏิบัติ CVE ที่อยู่ใน KEV ควรมี SLA เป็นชั่วโมง ไม่ใช่สัปดาห์

3. ยกอุปกรณ์ขอบเครือข่ายเป็นชั้นบนสุด VPN, ไฟร์วอลล์, reverse proxy และ appliance ทุกตัวที่รับทราฟฟิกจากอินเทอร์เน็ตโดยตรง ควรมีรอบอัปเดตแยกและเร็วกว่าระบบภายใน ตัวเลข 3% ขึ้นเป็น 22% ไม่ใช่เรื่องบังเอิญ

4. ลดพื้นที่ผิวก่อนคิดเรื่องแพตช์ แผงแอดมินไม่ควรเข้าถึงได้จากทุก IP ในโลก ปิดหลัง VPN หรือ SSO ทำ IP allowlist ปิดพอร์ตจัดการ ปิด endpoint ที่ไม่ได้ใช้ ช่องโหว่ที่เข้าไม่ถึงคือช่องโหว่ที่ยิงไม่โดน

5. ทำ dependency ให้อัปเดตอัตโนมัติและมี SBOM ตั้ง Dependabot หรือ Renovate ให้เปิด PR เอง รัน osv-scanner หรือ npm audit ใน CI และล็อกเวอร์ชันด้วย lockfile ใช้ npm ci แทน npm install ใน pipeline และพิจารณาปิด install script ของแพ็กเกจที่ไม่จำเป็น

6. จัดการ secret อย่างจริงจัง ติด pre-commit hook อย่าง gitleaks เปิด push protection ของ GitHub ย้ายคีย์ไป secret manager และที่สำคัญที่สุดคือหมุนคีย์เป็นรอบ เพราะสถิติบอกว่าคีย์ที่หลุดมักยังใช้ได้อีกหลายปี

7. เก็บ log ให้พอจะสืบย้อนได้ access log, log ของ WAF, log การ deploy และการเข้าถึงแอดมิน เก็บอย่างน้อย 90 วัน ถ้าวันหนึ่งพบว่าถูกเจาะตั้งแต่สองเดือนก่อน log 7 วันช่วยอะไรไม่ได้เลย

8. ใช้ WAF เป็นตัวซื้อเวลา ไม่ใช่ตัวแก้ virtual patching ช่วยกันคลื่นสแกนช่วงแรกได้จริง แต่มันคือผ้าพันแผลระหว่างรอหน้าต่างปิดระบบ ไม่ใช่ทางออกถาวร

9. ตั้งสมมติฐานว่าอาจถูกเจาะไปแล้ว หลังแพตช์ช่องโหว่ที่อยู่ใน KEV ให้ตรวจไฟล์แปลกปลอม บัญชีที่ถูกสร้างใหม่ cron job ที่ไม่คุ้น และหมุน credential ทั้งหมดที่ระบบนั้นถืออยู่

10. ซ้อมกู้คืน ไม่ใช่แค่มีแบ็กอัป แบ็กอัปที่ไม่เคยลอง restore คือแบ็กอัปที่ยังพิสูจน์ไม่ได้ และควรมีสำเนาที่ผู้ที่ยึดระบบได้ลบไม่ได้

เช็คลิสต์เจ็ดวันแรก

ถ้าอ่านจบแล้วอยากเริ่มทันทีโดยไม่ต้องรื้อทั้งระบบ ลองสามอย่างนี้ก่อน

• วันที่ 1 ถึง 2 ทำรายการทุกอย่างที่เปิดสู่อินเทอร์เน็ต พร้อมเวอร์ชันจริงของแต่ละตัว

• วันที่ 3 ถึง 4 เทียบรายการนั้นกับ CISA KEV และแพตช์เฉพาะตัวที่ตรงกัน ไม่ต้องสนใจที่เหลือก่อน

• วันที่ 5 ถึง 7 ปิดแผงแอดมินจากสาธารณะ เปิด dependency bot และสแกนหา secret ที่หลุดใน repo ย้อนหลัง

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

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