Supply Chain Attack คืออะไร อ่านจบใน 1 บทความ

เมื่อไม่นานมานี้ ช่วงปลายเดือนมีนาคม 2026 ที่ผ่านมา มีข่าวใหญ่ในวงการ Software Development อีกแล้ว ด้วย Axios ที่เป็น HTTP Library บน Javascript ที่มียอดดาวน์โหลดกว่าหลายล้านครั้ง กลายเป็นพาหะกระจาย Malware เฉยเลย มันเกิดจากกอะไรกันแน่ วันนี้เราจะมาเล่าถึงเบื้องหลังเทคนิคการโจมตีอย่าง Supply Chain Attack กันว่า มันคืออะไร มีเป้าหมายเพื่ออะไร และเขาทำกันอย่างไร รวมไปถึง การจัดการตั้งรับการโจมตีลักษณะนี้ เอาว่า อ่านบทความนี้ แล้วเข้าใจเลย

Supply Chain Attack คืออะไร ?

เพื่อให้เห็นภาพง่ายที่สุด ลองจิตนาการว่า Application หรือระบบของเรา คือ ปราสาท ที่มีการป้องกันแน่นหนา ติดตั้งกำแพงสูงลิบ (Firewall), มีทหารยามตรวจคนเข้าออก (Authentication & WAF) และหน่วยลาดตะเวนที่คอยสอดส่องตลอดเวลา (EDR & Antivirus) หากเราเป็นโจร เห็นแบบนี้ ก็น่าจะรู้แล้วว่า การเอากำลังไปบุกตีประตูหน้าปราสาทตรง ๆ มันยาก เหนื่อย และ เสี่ยงที่จะถูกจับได้ ทำให้ต้องเล่นเกมใหม่ จากการตีเมือง เป็นการวางยาในบ่อน้ำ หรือ แฝงตัวมากับเกวียนเสียงที่ปราสาทต้องเปิดประตูรับเข้ามาใช้งานทุกวันแทน

ในโลกของ Software Development เสบียงที่ว่านี้คือ Third-Party Services, Open-Source Libraries, เครื่องมือที่ใช้ในการพัฒนา หรือกระทั่งระบบ CI/CD Pipeline

ทำให้ Supply Chain Attack จึงหมายถึงการที่ Hacker เจาะเข้าไปฝัง Malicious Code ไว้ในส่วนประกอบต่าง ๆ ไว้ตั้งแต่ต้นทาง เพื่อให้ Code ส่วนนั้นถูกดึง ไปประกอบร่างกับ Software ส่วนหลักขององค์กรอย่างแนบเนียน และส่งต่อไปยังเครื่องของนักพัฒนา, Server และ End User โดยที่ระบบรักษาความปลอดภัยของปราสาทยอมปล่อยเข้ามา เพราะมองว่าเป็น ของที่เชื่อถือได้ (Trusted Component)

ถ้าเรามองในช่วง 10 ปีที่ผ่านมา เราจะเห็นว่า Supply Chain Attack นั้นพบบ่อยขึ้นเรื่อย ๆ ส่วนใหญ่ ๆ คาดว่าน่าจะเกิดจากการที่ ระบบสมัยใหม่มีกลไกการป้องกันตัวเองได้ดีขึ้น ฟิล ๆ เหมือน คนเราล้างมือกันมากขึ้นหลังโควิด ยากที่จะเจาะเข้ามาตรง ๆ เลยต้องเล่นท่านี้กันเยอะ

ถามว่าเป้าหมายที่แท้จริงของการเล่นท่านี้ส่วนใหญ่คืออะไร เราคิดว่ามันมีทั้งหมด 3 อย่างด้วยกัน อย่างแรกคือ การใช้เป็นช่องทางเพื่อขโมยกุญแจบ้าน (Stealing Secrets & Credentials) คือ เราไม่ได้อยากจะทำให้ระบบล่มทันที แต่ใช้เป็นช่องทางในการฝัง Backdoor เพื่อขโมยข้อมูลสำคัญระดับ Infrastructure เช่น Cloud Access Key, Environment Variable และ API Token ซึ่งถ้าได้ของพวกนี้ไป เท่ากับว่า Hacker แทบจะสามารถทำอะไรก็ได้ตามที่ต้องการแล้ว

อย่างที่ 2 คือ ใช้มันเป็นทางเข้าสำหรับ Bypass Security Mechanism เพราะต้องยอมรับว่า องค์กรเดี๋ยวนี้มีระบบป้องกันที่โหดมาก ๆ แต่จุดอ่อนมักจะไปตกที่ ความไว้ใจภาย (Implicit Trust) ทำให้หาก Malware แฝงตัวมาในรูปแบบของ Software Update ที่มี Digital Signature หรือ มากับ Dependency ที่นักพัฒนารันติดตั้งด้วยตัวเอง ระบบ Security มักจะมองข้าม และ ปล่อยผ่านแน่นอน

สุดท้ายคือ วิธีการนี้ Hack ครั้งเดียว แต่ได้หลายหมื่น เพราะบางเส้นทาง อย่างการสอดไส้ Backdoor เข้าไปใน Library ที่มีคนโหลดไปใช้งานหลักหลายแสน ถึงล้าน ก็ทำให้ความพยายามมันคุ้มกว่าเยอะมาก ๆ

The Anatomy of Attack

การเขียน Application ในยถคนี้ เราแทบไม่ได้เขียน Code เองโดยเริ่มจาก 0 แล้ว เรามักจะพึ่งพา Library, Framework และระบบอัตโนมัติต่าง ๆ มากมาย ซึ่ง Hacker รู้กันดีว่า Dependencies เหล่านี้แหละ คือ จุดอ่อน ชั้นยอด โดยเป้าหมายคือการแทรกซึมมักจะแบ่งออกเป็น 3 จุดหลัก ๆ ตาม SDLC ได้ดังนี้

Source Code & Dependencies

เป็นจุดที่โดนกันเยอะสุด เป็นเหมือนต้นน้ำเลยก็ว่าได้ โดยพุ่งเป้าไปที่ Package Manager เช่น npm, PyPI และ RubyGems โดยจะพยายามติดตั้ง Library น่ากลัว ๆ เข้าไปด้วยวิธีการต่าง ๆ

Typosquatting หรือการดักพิมพ์ผิด พวกนี้เขาจะสร้าง Library ชื่อคล้าย ๆ กับ Library ดัง ๆ เช่น requests กับ reqeusts ซึ่ง Hacker เขาไปจดชื่อนี้ดักไว้แล้ว พอรันเท่านั้นแหละ ก็แตก ทำให้ โปรดเช็คทุกตัวสะกดทุกตัวอักษรนะ เดี๋ยวหาว่า เจ๊เพ็ญไม่เตือน

Dependency Confusion หลายองค์กรมีการสร้าง Private Package ขึ้นมาใช้กันเองภายใน แต่ถ้า Hacker ดันรู้ชื่อ เขาอาจจะไปสร้าง Package ชื่อเดียวกันเป๊ะ ๆ บน Public Registry แต่ตั้งเลข Version ให้สูง พวก Package Manager ก็จะเห็นว่า อันนี้ตัวใหม่กว่านิ เรียบร้อยเลยดึง Version เลขสูงกว่าจาก Public Registry มาติดตั้งเลย

Build Environment & CI/CD Pipeline

ถัดขึ้นมา อีกเป้าหมายที่หอมหวานมาก ๆ คือ CI/CD Server เพราะระบบนี้ถือกุญแจผีที่เข้าได้ทั้ง Source Code, Database Credential และสิทธิ์ในการ Deploy ขึ้น Production

เมื่อเข้าไปได้ เขาอาจจะหลอกเพิ่มขั้นตอนบางอย่างที่เข้าไปดาวน์โหลด หรือเติม Code อันตรายเข้าไปตอน Compile หรือกระทั่ง การทำ Dependency Injection ระหว่างที่ Build เลยก็ยังได้

ความอันตรายของส่วนนี้คือ Source Code ของเราบน Git จะ Clean มาก ๆ ไม่มี Code แปลกปลอมอยู่ในนั้นเลย Scan ยังไงก็จะไม่เจอแน่นอน แต่มันดันโดนเสียบอยู่ในส่วนที่ Compile ออกมาแล้ว เช่น exe, dll หรือกระทั่ง Docker Image ทำให้การตรวจจับด้วย SAST Tool (Static Application Security Testing) แทบจะเป็นไปไม่ได้เลย

Update Mechanism

เมื่อ Software ถูก Deliver ถึง End User แล้ว Hacker ยังสามารถโจมตีผ่านระบบ Update ได้ ท่านี้เท่าที่เจอมา มักจะเป็นท่าที่กลุ่มองค์กรใหญ่ ๆ หรือ State-Sponsored Attack ชอบเล่นกัน เพราะบอกเลยว่า มันไม่ได้ง่ายขนาดนั้น

ระบบใหญ่ ๆ ตอนนี้ การจะอัพเดทได้ เขาจะมีการทำ Digital Seal ผ่านการใช้ Digital Signature ด้วย หากเราแอบแก้ไข Update File โดยการ Inject Code น่ากลัวเข้าไป ตัว Seal จะขาดทันที ประกอบกับระบบตอนนี้บางตัว เขาจะมีการ Update เงียบ ๆ ติดตั้งเอง ต่อเมื่อ Updater อันนั้นถูก Sign ด้วย Digital Certificate ที่ถูกต้องของบริษัทผู้พัฒนา การจะได้มานั้น Hacker ก็ต้องเจาะเข้าไปขโมย Private Key ของบริษัท เพื่อเอามา Sign Malware ตัวเอง

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

พอ Malware ครอบด้วย Digital Signature ของแทร่แล้ว ระบบมันมักจะปล่อยผ่าน เพราะถือว่า มันเป็นไฟล์จากผู้พัฒนาที่เชื่อถือได้ สุดท้าย Software มันก็จะ Download Patch ผีนี้ ไปติดตั้งในเครื่องแบบอัตโนมัติเฉยเลย

Case Study #1: The XZ Utils (CVE-2024-3094)

เคสแรกนี้ เป็นเคสที่ต้องจารึกไว้ในวงการ Open-Source เลยละ เพราะมันเกือบเป็นหายนะโลกแล้ว จุดเริ่มต้นมันเกิดจาก การที่ Engineer ของ Microsoft สังเกตเห็นว่า ทำไม SSH Login มันช้าผิดปกติไป 500ms

Hacker ชื่อว่า Jia Tan ไม่ได้ใช้การเจาะระบบโง่ ๆ เพื่อเข้ามาได้ เขาใช้ เวลา โดยการแฝงตัวเข้ามาช่วยเขียน Code และแก้บั๊คให้กับ Project xz (Library สำหรับทำ File Compression ที่อยู่บน Linux แทบทุก Distro บนโลก) เป็นเวลากว่า 2 ปีเต็ม จนได้รับความวางใจจากผู้พัฒนาให้เป็น Maintainer ที่มีสิทธิ์ในการจัดการ Project

หลังจากได้สิทธิ์มาแล้ว เขาก็ได้แอบฝัง Backdoor ซ่อนไว้ใน Test Data ความพีคคือ มันไม่ได้ฝังธรรมดานะ มันทำ Obfuscation และแยกส่วนกระจายกันออกไปใน Test Data จากนั้นเขียน Shell Script ที่ซ่อนตัวประกอบร่างไว้ในกระบวนการ Configure ของระบบ Build สิ่งที่มันทำคือ มันเข้าไป Hook กับ RSA_public_decrypt Function ของระบบ sshd

สิ่งที่เกิดขึ้นคือ มันเปิด Backdoor ให้ Hacker ที่มีกุญแจเฉพาะสามารถส่งคำสั่งเข้ามารันบน Server หรือที่เราเรียกว่า Remote Code Execution (RCE) โดยไม่ต้องใส่รหัสผ่าน และไม่ทิ้ง Log อะไรไว้เลย โชคดีว่า มันถูกค้นพบก่อนที่จะถูก Update กระจายลง Production ของ Linux หลากหลาย Distro ทั่วโลกแบบเฉียดฉิว ขอบคุณสังคม Open-Source จริง ๆ ที่ช่วยกันตรวจ ไม่งั้นชิบหายแน่นอน

Case Study #2: SolarWinds

ในทั้ง 3 Case Study เราบอกเลยว่า ไอ้นี่คือ Masterpiece ของ Attack Design จริง ๆ และที่ทำได้ขนาดนั้นเพราะมันเป็น State-Sponsored แหล่งข่าวหลาย ๆ เจ้าบอกว่า คาดว่าน่าจะได้รับการสนับสนุนจากรัฐบาลของรัสเชีย เหยื่อในรอบนี้คือบริษัท Software Network Monitoring อย่าง SolarWinds

Hacker ทำการเจาะระบบเข้ามาใน Network ของ SolarWinds และแฝงตัวอยู่ในนั้นหลายเดือน เป้าหมายของมันคือ Build Server ที่ใช้ทำ CI/CD สำหรับ Orion การโจมตีทำโดยการเขียน Script เพื่อดักจับจังหวะที่ Software กำลังถูก Compile อยู่แล้วทำการแทรก Code C# อันตรายเข้าไปในไฟล์ ก่อนที่ไฟล์ที่โดนสอดไส้นี้จะเข้าสู่กระบวนการทำ Digital Signature เนียนไปกับ Code ดั่งเดิมเลยละ และมีการสั่งให้ Sleep หน่วงการทำงานไป 12-14 วันหลังติดตั้ง เพื่อเลี่ยงการตรวจจับของ Sandbox

ผลคือ ลูกค้าของ SolarWinds รวมถึงหน่วยงานความมั่นคงของสหรัฐ และบริษัทระดับ Fortune 500 กว่า 18,000 แห่ง ดาวน์โหลด Update ที่โดนสอดไส้เข้าไปติดตั้ง ส่งผลให้เครือข่ายระดับชาติถูก Hacker เข้าไปวิ่งเล่นได้อย่างอิสระเลยทีเดียว

Case Study #3: Axios

ย้อนกลับไปที่เคสของ Axios ที่เราพูดถึงไปตอนต้น นี่คือ รูปแบบ Classic มาก ๆ เกิดขึ้นกันแบบรายวันบน Package Registry โดย Hacker พยายามหาวิธีในการ Takeover Account ของ Developer ตัวจริง เช่นส่ง Phishing หรือดึง Token จากระบบเก่า ๆ จากนั้น Update Version ใหม่ที่มีการยัดไส้เข้าไป

กลไกหลักที่ใช้มักจะไปกองอยู่ที่ preinstall หรือ postinstall Hook ภายใน package.json ทำให้ทันทีที่รัน npm install พวก Script ที่ซ้อนอยู่ก็จะเริ่มทำงานรัน curl หรือ wget เพื่อเอา Malware เข้ามารัน มันจะพุ่งเป้าเข้าไปหาไฟล์พวก Credential หรือ SSH Key หรือ Environment Variable แล้วแอบยิงข้อมูลพวกนี้กลับไปที่ Server ของ Hacker

นั่นทำให้ Endpoint ที่ Developer ใช้งานและ CI/CD Server จะกลายเป็นจุดอ่อนในเกมนี้ทันที ข้อมูลความลับสุดยอด โดนขโมยออกไปตั้งแต่ยังไม่ทันได้ Deploy ด้วยซ้ำ

เราจะป้องกันมันได้อย่างไร (Defence Strategies)

อ่านมาถึงตรงนี้ อาจจะรู้สึกว่า ถ้าการดึง Open-Source มาใช้งานแล้วน่ากลัวขนาดนี้ เรากลับไปเขียนเองทุกบรรทัดเลยดีมั้ย คำตอบคือ เป็นไปไม่ได้แล้ว เพราะในโลกที่แข่งขันด้วยความเร็วสูงมาก การเขียนเองน่าจะไม่ทันกินแน่ ๆ สิ่งที่เราต้องเปลี่ยนจึงไม่ใช่การ เลิกใช้ แต่เป็นการ ใช้แบบไม่ไว้ใจ และมีการตรวจสอบทุกขั้นตอนการทำงานมากกว่า

อย่างแรกคือ การทำ SBOM (Software Bill of Materials) ลองคิดภาพนะว่า เราซื้อข้าวกล่องมากิน เราย่อมอยากรู้ว่าในอาหารนี้มันประกอบด้วยอะไรบ้าง เผื่อเราแพ้อาหารอันไหน SBOM มันก็คือสิ่งนั้นใน Software มันคือ บัญชีรายชื่อ ที่บอกว่า Application ของเราประกอบด้วย Library, Framework และ Dependencies ตัวไหนบาง รวมถึง ระบบ Version อย่างชัดเจน สมมุติว่า มีข่าวออกมาว่า Library นึงมี Zero-day แทนที่เราจะต้องเข้าไปนั่งไล่ Dependencies เยอะ ๆ ด้วยมือ เราสามารถใช้เครื่องมือ เช่น Syft เข้าไปสแกน SBOM รู้ผลใน 1 วินาทีเลยว่า Project ไหนแตกบ้าง และเข้าไป Patch ได้ทันที

อย่างที่ 2 คือ การทำ Dependencies Management ที่เป็นระบบ หนึ่งในพฤติกรรมที่โคตรอันตรายมาก ๆ คือ การตั้งค่าให้ระบบดึง Package Latest Version หรือการใส่เจ้าเครื่องหมาย Caret ไว้หน้าเลขเวอร์ชั่นใน package.json เพราะนั่นแปลว่า เรายอมให้ระบบ Update Code ใหม่ ๆ เข้ามาเอง แน่นอนว่า ถ้าโดนแบบ Axios ก็คือแตกยับได้ วิธีการแก้คือ เราควรทำ Version Pinning หรือการระบุเลข Version ที่เราต้องการใช้แบบเจาะจง และบังคับใช้ Lockfile เพื่อรับประกันว่าทุกคนที่ได้สัมผัส Code จะได้ใช้ Dependencies Version เดียวกัน ตัวเดียวกันเป๊ะ ๆ รวมถึงการใช้ Integrity Checking ด้วยการตรวจสอบ Hashing เพื่อยืนยันว่า Dependencies ที่ดาวน์โหลดลงมาไม่ได้ถูกสอดไส้ระหว่างทาง หากค่า Hash ไม่ตรงกับต้นฉบับ ระบบก็จะปฏิเสธการติดตั้งทันที

อย่างที่ 3 คือ การทำ Hardening บน CI/CD Server และ Zero Trust เพราะอย่างที่ได้เล่าไปว่า CI/CD Server เป็นเป้าหมายหลักที่ Hacker อยากได้มาก ๆ เพราะมันเป็นเหมือนโรงงานผลิตที่เข้าถึง Code และ Credential สำคัญทั้งหมด ทำให้พยายามอย่ายัด Cloud Credential แบบถาวรเอาไว้เด็ดขาด เปลี่ยนไปใช้ OIDC (OpenID Connect) เพื่อขอ Temporary Token ที่มีอายุสั้น ๆ แทน รวมถึงการแยก Build Environment ออกจากกัน และเคลียร์ทิ้งทันทีเมื่อใช้งานเสร็จ เพื่อป้องกันไม่ให้ Malware วิ่งข้าม Project กันมาได้

สุดท้ายคือ Shift-Left Security และ Code Signing คือ อย่ารอให้ Application ถูก Build แล้วค่อยสแกนหา Malware แต่เป็นการย้าย Security มาอยู่ด้านซ้ายสุดของกระบวนการทำงาน ผ่านเครื่องมือพวก Software Composition Analysis (SCA) เช่น Dependabot มันจะคอยดักจับ และแจ้งเตือนทันทีที่เราพยายาม Pull Package ที่มีประวัติถูก Hack

สรุป

โลกของการพัฒนา Software เปลี่ยนไปไกลมาก ๆ แล้ว มันไม่ได้เป็นเรื่องของการแค่ตั้ง Firewall หนา ๆ หรือการบังคับให้พนักงานใช้รหัสผ่านยาว ๆ แล้ว แต่มันครอบคลุมไปถึง Code ทุกบรรทัดและ Library ทุกตัว ทีเรานำมาประกอบกันเป็นระบบ

Trust ความเชื่อมั่น แต่ทำไมวงการ Cyber Security ถึงมูฟออนไป Zero-Trust กัน

คำว่า Zero-Trust น่าจะเป็นคำที่น่าจะเคยผ่านหูผ่านตามาไม่มากก็น้อย หลายคนบอกว่า มันเป็นทางออกสำหรับการบริหาร และจัดการ IT Resource สำหรับการทำงานในปัจจุบันเลยก็ว่าได้ วันนี้เราจะมาเล่าให้อ่านกันว่า มันคืออะไร และ ทำไมหลาย ๆ คนคิดว่า มันเป็นเส้นทางที่ดีที่เราจะมูฟออนกันไปทางนั้น

ArnondoraArnon Puitrakul

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