วิธีที่ภัยคุกคามผ่านเบราว์เซอร์หลบเลี่ยงระบบความปลอดภัยเครือข่ายแบบดั้งเดิม

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

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

โครงสร้างของการโจมตีผ่านเบราว์เซอร์ที่ระบบของคุณไม่ตรวจพบ

ลองนึกภาพนี้: นักวิเคราะห์การจัดซื้อของบริษัทผลิตกำลังค้นหาผู้จัดหาสินค้าอุตสาหกรรมเฉพาะทาง ผลค้นหาที่ได้รับการสนับสนุน — ซึ่งถูกส่งผ่านเครือข่ายโฆษณาหลักที่ถูกต้องตามกฎหมาย — ปรากฏอยู่ด้านบนสุดของผลการค้นหา โดเมนของโฆษณานั้นผ่านการกรอง URL ได้ และชื่อเสียงของแพลตฟอร์มโฆษณาเองก็ไม่มีปัญหา นักวิเคราะห์จึงคลิกเข้าไป หน้าปลายทางจะตรวจจับเวอร์ชันของเบราว์เซอร์ ยืนยันว่าไม่ใช่แซนด์บ็อกซ์ โหลดโค้ด JavaScript ที่ถูกซ่อนไว้หลังการเปลี่ยนเส้นทางสามชั้น และปล่อยโปรแกรมขโมยข้อมูลที่เก็บรวบรวมข้อมูลรับรองทั้งหมดที่เก็บไว้ในตัวจัดการรหัสผ่านของเบราว์เซอร์ โปรแกรมป้องกันไวรัสที่ติดตั้งบนอุปกรณ์ปลายทาง (Endpoint AV) เห็นกระบวนการ Chromium ที่ลงนามแล้วกำลังทำงานตามปกติของเบราว์เซอร์—คือรัน JavaScript—และไม่ดำเนินการใดๆ

MITRE ATT&CK บันทึกแบบการโจมตีนี้ไว้เป็น T1189 (Drive by Compromise): ผู้โจมตีเข้าถึงระบบได้ผ่านผู้ใช้ที่เข้าชมเว็บไซต์ในระหว่างการท่องเว็บตามปกติ วิธีการส่งมอบรวมถึงเว็บไซต์ที่ถูกต้องที่ถูกแทรกโค้ดอันตราย ไฟล์สคริปต์ที่ส่งจากพื้นที่จัดเก็บข้อมูลบนคลาวด์ที่ถูกบุกรุก และโฆษณาอันตรายที่ส่งผ่านผู้ให้บริการโฆษณาที่ถูกต้อง (malvertising)

แม้แต่ Google เองก็ยอมรับถึงขนาดของปัญหานี้: ในปี 2024 เพียงปีเดียว Google ได้บล็อกโฆษณาที่ไม่เหมาะสมจำนวน 5.1 พันล้านชิ้น และระงับบัญชีผู้โฆษณา 39.2 ล้านบัญชี (Google Ads Safety Report, 2025) ตัวเลขเหล่านี้ทำให้ตกใจ—และยังเป็นตัวแทนเพียงส่วนที่ถูกตรวจพบเท่านั้น โฆษณาที่ผ่านระบบไปได้นั้นก่อให้เกิดพื้นที่โจมตีที่ SOC ของคุณมองไม่เห็นมากที่สุด เพราะทุกขั้นตอนการควบคุมในห่วงโซ่—DNS, ประเภท URL, ใบรับรอง TLS, ลายเซ็นจุดปลายทาง—ล้วนประเมินโครงสร้างพื้นฐานของโฆษณาว่าเป็นที่น่าเชื่อถือ

หากเซสชันของนักวิเคราะห์นี้ถูกส่งผ่าน remote browser isolation, JavaScript จะถูกดำเนินการในคอนเทนเนอร์คลาวด์แบบชั่วคราว โปรแกรมขโมยข้อมูลจะไม่มีกระบวนการท้องถิ่นใดที่จะแทรกแซง ไม่มีที่เก็บข้อมูลรับรองเพื่ออ่าน และไม่มีเส้นทางคงอยู่ไปยังจุดปลายทาง

ทำไมระบบความปลอดภัยเครือข่ายแบบดั้งเดิมจึงล้มเหลวอย่างเป็นระบบเมื่อถึงเบราว์เซอร์

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

ช่องว่างในการตรวจสอบการส่งข้อมูลที่ถูกเข้ารหัส

รายงานการโจมตีแบบเข้ารหัสปี 2024 ของ ThreatLabz พบว่า 87% ของภัยคุกคามถูกซ่อนอยู่ในข้อมูลการสื่อสาร TLS/SSL เกตเวย์เว็บที่ปลอดภัยแบบเก่าส่วนใหญ่ไม่สามารถถอดรหัส TLS 1.3 ในระดับใหญ่ได้ หรือต้องยกเว้นประเภทการรับส่งข้อมูลขนาดใหญ่ — เช่น ระบบธนาคาร พอร์ทัลด้านสุขภาพ และแอปพลิเคชัน SaaS ที่ใช้การตรึงใบรับรอง — จากการตรวจสอบ ผู้โจมตีที่จัดตั้งหน้าเว็บเพื่อเก็บข้อมูลรับรอง (credential harvesting) ไว้เบื้องหลังใบรับรอง Let's Encrypt ที่ถูกต้องบนโดเมนที่เพิ่งจดทะเบียนใหม่ สามารถผ่านช่องโหว่นี้ได้อย่างแนบเนียน นักวิเคราะห์ SOC ที่ตรวจสอบบันทึกพร็อกซีจะเห็นการเชื่อมต่อ HTTPS ออกไปยัง CDN และไม่มีสิ่งใดดูผิดปกติจนกระทั่งสายเกินไป

การกรอง URL และความล่าช้าของข้อมูลความน่าเชื่อถือ

ฐานข้อมูลชื่อเสียง URL เป็นระบบที่ตอบสนองแบบเชิงรับ แคมเปญโฆษณาที่เป็นอันตรายที่ใช้โดเมนใหม่ ซ่อนหน้าปลายทางเพื่อแสดงเนื้อหาที่ดูปลอดภัยต่อโปรแกรมค้นหา และส่งโค้ดอันตรายจริงเฉพาะให้กับเหยื่อที่มีลายนิ้วมือเบราว์เซอร์ตรงกับที่กำหนด จะไม่ปรากฏในฟีดภัยคุกคามใดๆ จนกว่าจะเกิดการโจมตีระลอกแรก ลองพิจารณาแคมเปญซอฟต์แวร์ที่ติดโทรจันแบบทั่วไป ซึ่งกระจายผ่านโฆษณาบนเครื่องมือค้นหา: เว็บไซต์เหล่านั้นโปรโมตแอปพลิเคชันที่ดูน่าเชื่อถือ โดเมนดาวน์โหลดผ่านการตรวจสอบชื่อเสียง และมัลแวร์จะอยู่ในสถานะไม่ทำงานเป็นเวลาหลายสัปดาห์ก่อนที่จะถูกเปิดใช้งาน — นานพอที่จะรอดพ้นจากการบล็อก URL แบบย้อนหลังส่วนใหญ่

จุดอ่อนของซอฟต์แวร์ป้องกันไวรัสและ EDR สำหรับอุปกรณ์ปลายทางในเบราว์เซอร์

การโจมตีในเบราว์เซอร์นั้นยากต่อการตรวจจับโดยเครื่องมือรักษาความปลอดภัยของจุดปลายเนื่องจากหลักฐานการโจมตีมีอายุสั้น ถูกซ่อนอยู่ในหน่วยความจำของเบราว์เซอร์ และถูกส่งต่อเกือบจะทันทีเพื่อรักษาประสบการณ์การใช้งานของผู้ใช้ (GitLab Security Tech Notes, 2025) เมื่อโค้ด JavaScript ที่มีเจตนาร้ายถูกดำเนินการภายในเครื่องยนต์ V8 ของเบราว์เซอร์ มันจะไม่สร้างไฟล์ลงบนดิสก์ แต่จะจัดการ DOM อ่านข้อมูลในช่องฟอร์ม และส่งข้อมูลออกผ่านการเชื่อมต่อ WebSocket ที่ดูเหมือนกับการจราจรของเบราว์เซอร์ที่ถูกต้องตามกฎหมาย ตัวแทน EDR ที่ติดตามโครงสร้างกระบวนการ การเขียนไฟล์ และการเปลี่ยนแปลงรีจิสทรี จะไม่พบสิ่งใดที่สามารถดำเนินการได้

สิ่งที่เปลี่ยนแปลง: เบราว์เซอร์ได้กลายเป็นพื้นที่ทำงานขององค์กรแล้ว

การเปลี่ยนแปลงสามประการที่เกิดขึ้นพร้อมกัน ได้ทำให้เบราว์เซอร์เปลี่ยนจากจุดที่ได้รับความสนใจน้อยลง กลายเป็นจุดโจมตีหลัก:

ก่อนอื่น SaaS ได้แทนที่เครือข่ายในฐานะขอบเขตความปลอดภัย เมื่อพนักงานเข้าถึง Salesforce, Workday, ServiceNow และ Microsoft 365 ผ่านเบราว์เซอร์ เซสชันเบราว์เซอร์นั้นคือชั้นการเข้าถึง การที่เซสชันเบราว์เซอร์ถูกบุกรุกจะให้สิทธิ์การเข้าถึงเท่ากับการที่ VPN ถูกบุกรุก — และมักให้สิทธิ์การเข้าถึงมากกว่าด้วย เนื่องจากเซสชัน SaaS มักคงอยู่ข้ามอุปกรณ์ต่าง ๆ และไม่มีการบันทึกข้อมูลที่ชั้นเครือข่ายเหมือนที่การเชื่อมต่อ VPN ให้ไว้

ประการที่สอง การถูกโจมตีผ่านเว็บในฐานะช่องทางติดเชื้อขั้นต้นกำลังเพิ่มขึ้นอย่างรวดเร็ว รายงาน Mandiant M Trends 2025 พบว่า การโจมตีผ่านเว็บเพิ่มขึ้นจาก 5% เป็น 9% ของช่องทางติดเชื้อเริ่มต้นระหว่างปี 2023 และ 2024 — เพิ่มขึ้นเกือบสองเท่า การโจมตีผ่านเว็บนี้รวมถึงการโจมตีแบบ drive-by, โฆษณาที่เป็นอันตราย, การปนเปื้อน SEO และเว็บไซต์ที่ถูกโจมตี การเพิ่มขึ้นนี้ไม่ใช่เพียงความผันผวนแบบสุ่ม แต่สะท้อนให้เห็นว่าผู้โจมตีกำลังเปลี่ยนมาใช้การส่งมอบผ่านเบราว์เซอร์อย่างตั้งใจ เนื่องจากวิธีนี้สามารถหลีกเลี่ยงระบบควบคุมที่องค์กรได้ลงทุนไป

ประการที่สาม การขโมยข้อมูลรับรองและการชิงสิทธิ์เซสชันได้กลายเป็นอุตสาหกรรมแล้ว ตามรายงาน Mandiant M Trends 2025 ข้อมูลรับรองที่ถูกขโมยเป็นช่องทางเข้าถึงเริ่มต้นที่พบมากที่สุดเป็นอันดับสอง คิดเป็น 16% ของเหตุการณ์ที่ได้รับการสอบสวน ส่วนรายงาน Verizon 2025 DBIR ระบุว่า ข้อมูลรับรองที่ถูกขโมยถูกใช้ใน 22% ของเหตุการณ์การละเมิดข้อมูล ข้อมูลรับรองจำนวนมากเหล่านี้มีต้นกำเนิดจากเบราว์เซอร์: รหัสผ่านที่กรอกอัตโนมัติ คุกกี้ในที่เก็บข้อมูลท้องถิ่น และโทเค็นเซสชันที่ถูกจับโดยมัลแวร์ขโมยข้อมูล (infostealer) ที่ทำงานในบริบทการเรนเดอร์ การรวมตัวกันของมัลแวร์ขโมยข้อมูล ตลาดซื้อขายข้อมูลรับรอง และเบราว์เซอร์ในฐานะพื้นที่ทำงาน หมายความว่า เซสชันเบราว์เซอร์ที่ถูกบุกรุกเพียงครั้งเดียวก็สามารถเปิดทางให้ผู้โจมตีเข้าถึงห่วงโซ่การโจมตี (kill chain) ทั้งหมดได้

ส่วนขยายเบราว์เซอร์: การโจมตีในห่วงโซ่อุปทานที่คุณยังไม่ได้ติดตาม

ผู้ประสานงานด้านการตลาดติดตั้งส่วนขยาย Chrome สำหรับตรวจสอบไวยากรณ์ที่ได้รับความนิยม ซึ่งมีผู้ใช้ 500,000 คน และคะแนน 4.8 ดาว หกเดือนต่อมา ผู้พัฒนาส่วนขยายนี้ขายมันให้กับผู้ซื้อที่ไม่เป็นที่รู้จัก เจ้าของใหม่ส่งการอัปเดตแบบเงียบที่เพิ่มโค้ดเพื่อดึงข้อมูลคุกกี้และโทเค็นเซสชันจากทุกเว็บไซต์ที่ผู้ใช้เข้าชม รวมถึงพอร์ทัล SSO ของบริษัท ไม่มีการแจ้งเตือนใดเกิดขึ้น เนื่องจากส่วนขยายนี้ได้รับการเชื่อถืออยู่แล้ว การอัปเดตถูกส่งผ่านร้านค้าอย่างเป็นทางการ และกระบวนการดึงข้อมูลใช้การเรียก HTTPS มาตรฐาน

ในเดือนธันวาคม 2024 ผู้ก่อภัยคุกคามได้ดำเนินการโจมตีห่วงโซ่อุปทานซอฟต์แวร์ โดยใช้บัญชีผู้พัฒนาที่ถูกแฮ็กเพื่อแจกจ่ายการอัปเดตส่วนขยายเบราว์เซอร์ที่เป็นอันตรายจาก Chrome Web Store (GitLab Security Tech Notes, 2025) ผู้ก่อภัยคุกคามได้อัปเดตส่วนขยายด้วยโค้ดที่ดึงข้อมูลจาก HTTP headers และเนื้อหา DOM ตามการกำหนดค่าแบบไดนามิก — ซึ่งเป็นการโจมตีที่ซับซ้อนและส่งผลกระทบต่อผู้ใช้อย่างน้อย 3.2 ล้านคน

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

จากมุมมองของ SOC การโจมตีประเภทนี้แทบจะมองไม่เห็นเลย ส่วนขยายนี้ทำงานภายในกระบวนการของเบราว์เซอร์ สื่อสารผ่าน HTTPS ไปยังโดเมนที่อาจเพิ่งถูกจดทะเบียนหรือโฮสต์บนแพลตฟอร์มคลาวด์ และเข้าถึงเนื้อหาหน้าเว็บที่ผู้ใช้เห็นอย่างถูกต้องตามปกติ ตัวแทนที่ติดตั้งบนอุปกรณ์ปลายทาง (endpoint agents) ไม่ตรวจพบการโจมตีนี้ ระบบการเฝ้าระวังเครือข่ายจะตรวจพบการส่งข้อมูลที่เข้ารหัสไปยัง CDN มาตรการป้องกันที่มีประสิทธิภาพเพียงอย่างเดียวคือการบริหารจัดการส่วนขยายอย่างละเอียด — การกำหนดรายชื่ออนุญาต (allowlisting), การตรวจสอบสิทธิ์ (permission auditing), การตรึงเวอร์ชัน (version pinning) — และการแยกเซสชันเบราว์เซอร์ผ่านกลไกการแยกเบราว์เซอร์ (browser isolation) เพื่อให้แม้ส่วนขยายที่ถูกบุกรุกก็ไม่สามารถเข้าถึงจุดปลายทางจริงได้

การเก็บรวบรวมข้อมูลรับรองและการขโมยเซสชัน: การเจาะระบบ MFA ผ่านเบราว์เซอร์

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

MITRE ATT&CK T1185 (การขโมยเซสชันเบราว์เซอร์) อธิบายว่าผู้โจมตีใช้ประโยชน์จากช่องโหว่ด้านความปลอดภัยและฟังก์ชันการทำงานที่มีอยู่ในซอฟต์แวร์เบราว์เซอร์เพื่อเปลี่ยนแปลงเนื้อหา ปรับเปลี่ยนพฤติกรรมของผู้ใช้ และดักจับข้อมูล ตัวอย่างเฉพาะคือเมื่อผู้โจมตีแทรกซอฟต์แวร์เข้าไปในเบราว์เซอร์ ซึ่งทำให้พวกเขาสามารถรับช่วงต่อคุกกี้ เซสชัน HTTP และใบรับรอง SSL ของลูกค้าได้ ด้วยสิทธิ์เหล่านี้ ผู้โจมตีอาจสามารถเข้าถึงทรัพยากรใดก็ตามในอินทราเน็ต เช่น SharePoint หรือเว็บเมล การใช้เบราว์เซอร์เพื่อเปลี่ยนเป้าหมาย (Browser pivoting) ยังสามารถหลีกเลี่ยงระบบความปลอดภัยที่จัดให้โดยการยืนยันตัวตนแบบสองขั้นตอน (2-factor authentication) ได้อีกด้วย

นี่ไม่ใช่ปัญหาทางทฤษฎีเท่านั้น ชุดเครื่องมือฟิชชิ่งแบบ "Adversary in the Middle" ได้กลายเป็นสินค้าทั่วไปแล้ว ชุดเครื่องมือ Phishing as a Service (PaaS) ปัจจุบันใช้เทคนิค "Browser in the Browser" (BitB) ที่แสดงหน้าต่างเบราว์เซอร์ปลอมภายในเบราว์เซอร์จริงของผู้ใช้ เพื่อเลียนแบบขั้นตอนการเข้าสู่ระบบที่ถูกต้อง ชุดเครื่องมือเหล่านี้แสดงหน้าเข้าสู่ระบบที่ดูน่าเชื่อถือ พร้อมด้วยแถบที่อยู่ปลอม และสามารถจับข้อมูลรับรองการเข้าสู่ระบบและโทเค็นเซสชันที่กำลังใช้งานอยู่ได้ นอกจากนี้ ยังใช้การตรวจสอบป้องกันบอท การโหลดตามเงื่อนไข การหมุนเวียนโดเมนอย่างรวดเร็ว และการบดบังโค้ด เพื่อหลีกเลี่ยงการตรวจจับ

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

การรั่วไหลข้อมูลผ่าน JavaScript: การสูญเสียข้อมูลผ่านเครื่องยนต์เรนเดอร์

นักวิเคราะห์ของบริษัทในภาคสุขภาพเปิดพอร์ทัลวิจัยที่ถูกบุกรุกผ่านสคริปต์วิเคราะห์ของฝ่ายที่สาม JavaScript ที่ถูกแทรกเข้าไปจะอ่าน DOM ของแอปพลิเคชัน SaaS แบบแท็บที่นักวิเคราะห์เปิดไว้ — โดยเฉพาะแดชบอร์ดบันทึกข้อมูลผู้ป่วย — โดยอ่านข้อมูลที่แสดงอยู่แปลงเป็น JSON blob แล้วส่งข้อมูลดังกล่าวไปยังจุดปลายทางที่ผู้โจมตีควบคุมผ่านการเชื่อมต่อ WebSocket ที่ดูเหมือนการส่งข้อมูลเทเลเมทรี ไม่มีการดาวน์โหลดไฟล์ใดๆ ไม่มีการวางไฟล์ที่รันได้ลงระบบ กฎDLPที่เฝ้าระวังไฟล์แนบ การเขียนข้อมูลลง USB หรือการอัปโหลดขึ้นคลาวด์ ไม่ถูกทริกเกอร์เลย

สถานการณ์นี้แสดงให้เห็นว่าทำไมdata loss prevention ขยายไปถึงเซสชันของเบราว์เซอร์เอง JavaScript ที่ทำงานในเบราว์เซอร์มีสิทธิ์เข้าถึงข้อมูลทั้งหมดที่ผู้ใช้สามารถเห็นได้ ข้อจำกัดข้ามต้นทาง (Cross-Origin Restrictions) ช่วยได้บ้าง แต่สคริปต์ของฝ่ายแรกที่ถูกบุกรุก ไลบรารีในห่วงโซ่อุปทานที่ถูกปนเปื้อน และส่วนขยายที่เป็นอันตราย ล้วนทำงานอยู่ในต้นทางเดียวกันกับแอปพลิเคชันที่ถูกต้อง

Mandiant ไม่สามารถระบุช่องทางติดเชื้อเริ่มต้นได้สำหรับ 34% ของการบุกรุกในปี 2024 (M Trends 2025) — สัดส่วนนี้ชี้ให้เห็นถึงจุดอ่อนที่อาจมีในระบบบันทึกข้อมูลและระบบตรวจจับขององค์กร การนำข้อมูลออกผ่านเบราว์เซอร์เป็นปัจจัยที่อาจมีส่วนทำให้เกิดช่องว่างดังกล่าว: เมื่อข้อมูลถูกส่งออกไปผ่านเครื่องยนต์เรนเดอร์แทนที่จะผ่านระบบไฟล์ ร่องรอยทางนิติวิทยาศาสตร์จะเหลือน้อยมาก

สิ่งที่ทีมความปลอดภัยควรทำในขณะนี้

ความไม่สอดคล้องกันทางโครงสร้างระหว่างภัยคุกคามที่ส่งผ่านเบราว์เซอร์กับระบบควบคุมชั้นเครือข่ายจะไม่หายไปเอง นี่คือแผนการดำเนินการที่จัดลำดับความสำคัญแล้ว:

1. ติดตั้งremote browser isolation ข้อมูลการรับส่งที่มีความเสี่ยงสูง

RBI ดำเนินการประมวลผลเนื้อหาเว็บภายในคอนเทนเนอร์คลาวด์แบบใช้แล้วทิ้ง และส่งเฉพาะผลลัพธ์ภาพที่ปลอดภัยไปยังจุดปลายทางเท่านั้น โหลดมัลแวร์จากโฆษณาที่เป็นอันตราย (malvertising), การโจมตีแบบ drive-by exploits และการส่งข้อมูลออกนอกระบบ (exfiltration) ที่ใช้ JavaScript ทั้งหมดจะถูกยุติภายในคอนเทนเนอร์ เริ่มต้นด้วย URL ที่ยังไม่ได้จัดประเภทและหมวดหมู่ที่มีความเสี่ยงสูง จากนั้นขยายไปยังการรับส่งข้อมูลเว็บทั้งหมดสำหรับผู้ใช้ที่มีสิทธิ์พิเศษและบทบาทที่มีความสำคัญ แพลตฟอร์ม SSESkyhigh Security ที่ผสานรวม RBI ช่วยหลีกเลี่ยงความซับซ้อนในการติดตั้งผลิตภัณฑ์แยกส่วนแบบสแตนด์อโลน

2. บังคับใช้การตรวจสอบ TLS โดยไม่มีการยกเว้นใดๆ

หากภัยคุกคามส่วนใหญ่ซ่อนตัวอยู่ในข้อมูลที่เข้ารหัส การยกเว้น HTTPS ในปริมาณมากจากการตรวจสอบจะก่อให้เกิดจุดบอดที่แน่นอน สถาปัตยกรรม SWG ที่ส่งผ่านคลาวด์สมัยใหม่สามารถตรวจสอบ TLS 1.3 ในระดับใหญ่ได้โดยไม่เกิดปัญหาความล่าช้าและปัญหาการจัดการใบรับรองเหมือนอุปกรณ์รุ่นเก่า ตามที่ NIST SP 800 207 เน้นย้ำ หลักการ Zero Trust ถือว่าไม่มีการให้ความเชื่อถือโดยปริยายต่อสินทรัพย์หรือบัญชีผู้ใช้เพียงเพราะตำแหน่งทางกายภาพหรือตำแหน่งในเครือข่ายเท่านั้น หลักการนี้ขยายไปถึงเซสชันที่เข้ารหัสด้วย: ให้เชื่อถือในตัวตนและข้อมูล ไม่ใช่ในชั้นหุ้มของโปรโตคอล

3. จำกัดการใช้งานส่วนขยายของเบราว์เซอร์

Implement an allowlist of approved extensions. Audit permissions aggressively—any extension requesting <all urls host permissions or access to cookies and web requests should require security review. Pin extension versions to prevent silent malicious updates. For organizations that cannot fully restrict extensions, RBI provides a safety net by isolating extension activity from the corporate session.

4. ย้าย DLP เข้าสู่บริบทของเบราว์เซอร์

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

5. ใช้ระบบการยืนยันตัวตนที่ต้านการฟิชชิ่ง

กุญแจความปลอดภัยแบบฮาร์ดแวร์ที่สอดคล้องกับมาตรฐาน FIDO2 จะผูกการยืนยันตัวตนกับโดเมนที่ถูกต้อง ทำให้การโจมตีแบบฟิชชิ่งแบบคนกลาง (man-in-the-middle) เป็นไปไม่ได้โดยโครงสร้าง แม้ผู้ใช้จะคลิกลิงก์ที่เป็นอันตรายก็ตาม การผูกโทเค็นเซสชันและการประเมินสถานะความปลอดภัยอย่างต่อเนื่องยังช่วยลดช่วงเวลาที่ระบบอาจถูกโจมตีได้อีกด้วย

ความเร่งด่วน: ช่องว่างในการตรวจพบกำลังขยายตัว ไม่ใช่ลดลง

เวลาอยู่เฉลี่ยทั่วโลกในปี 2024 อยู่ที่ 11 วัน (Mandiant M Trends 2025) และการบุกรุกหลายกรณีถูกค้นพบภายในสัปดาห์แรก ซึ่งฟังดูน่าหวัง — จนกระทั่งคุณพิจารณาว่าการโจมตีผ่านเบราว์เซอร์สามารถดำเนินการห่วงโซ่การโจมตี (kill chain) ทั้งหมดให้เสร็จสิ้นภายในไม่กี่นาที: การเก็บรวบรวมข้อมูลรับรองการเข้าสู่ระบบ การยึดครองเซสชัน การนำข้อมูลออก และการล้างร่องรอย — ทั้งหมดนี้เกิดขึ้นภายในเซสชันเบราว์เซอร์เดียว ซึ่งอาจไม่ปรากฏในบันทึกของอุปกรณ์ปลายทางหรือเครือข่ายเลย

57% ขององค์กรทราบถึงการละเมิดข้อมูลในปี 2024 เป็นครั้งแรกจากแหล่งข้อมูลภายนอก (Mandiant M Trends 2025) หาก SOC ของคุณเองไม่ใช่ฝ่ายที่ค้นพบการละเมิดข้อมูลนั้น คำถามคือว่าเครื่องมือของคุณมีความสามารถในการตรวจสอบเบราว์เซอร์ได้หรือไม่ สำหรับองค์กรส่วนใหญ่ คำตอบที่ตรงไปตรงมาคือ “ไม่” รายงาน DBIR ปี 2025 ของ Verizon ได้เน้นย้ำความเป็นจริงนี้ โดยพบว่า การมีส่วนร่วมของมนุษย์มีบทบาทใน 60% ของเหตุการณ์การละเมิดระบบ — และในโลกที่เน้นการใช้งานเบราว์เซอร์เป็นหลัก เบราว์เซอร์คือจุดที่การปฏิสัมพันธ์ของมนุษย์เกิดขึ้น

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