Google Cloud & AI Insights by Digigen

มี MFA แล้ว แต่ผู้โจมตีก็ยังล็อกอินเข้ามาได้อยู่ดี

เขียนโดย Alex Raso - 8 ก.ย. 2026 07:17:52
```html

ความปลอดภัย Microsoft 365, ประเทศไทย

มี MFA แล้ว แต่ผู้โจมตียังล็อกอินเข้ามาได้

โดย Alex ผู้ก่อตั้ง Raso Cyber เผยแพร่ร่วมกับ Digigen

วันอังคาร

อีเมลฉบับนั้นมาจากซัพพลายเออร์ที่บริษัททำงานด้วยกันมานานถึง 6 ปี

มันเป็นใบเสนอราคาที่แชร์ผ่านลิงก์เอกสาร ส่งมาจากชื่อที่อยู่ในสมุดรายชื่อ และเป็นคนเดียวกับที่เคยส่งใบเสนอราคามาแล้วประมาณ 40 ฉบับในปีนั้น Beam ผู้จัดการฝ่าย IT ของบริษัทจัดจำหน่ายชิ้นส่วนอุตสาหกรรมแห่งหนึ่งในกรุงเทพฯ ไม่ใช่คนที่กดลิงก์ แต่เป็นผู้อำนวยการฝ่ายปฏิบัติการของบริษัท ตอนนั้นเขาอยู่บนแท็กซี่แถวพระราม 4 กำลังจะไปสาย และลิงก์ดังกล่าวขอให้เขาลงชื่อเข้าใช้ Microsoft 365 เพื่อเปิดดูไฟล์

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

เอกสารเปิดขึ้นมา และมันก็เป็นใบเสนอราคาจริง ทุกอย่างดูปกติ เพราะในมุมหนึ่งทุกอย่างก็ปกติจริง ๆ เขาได้ยืนยันตัวตนกับ Microsoft อย่างถูกต้องและสำเร็จ และ Microsoft ก็ออก Session Token ให้เพื่อยืนยันว่าเขาได้ผ่านการล็อกอินแล้ว

รายละเอียดเดียวที่เขามองไม่เห็นก็คือ การล็อกอินของเขาถูกส่งผ่านเซิร์ฟเวอร์ของคนอื่นก่อนจะไปถึง Microsoft และมีการเก็บสำเนา Token นั้นเอาไว้

อีกประมาณ 90 วินาทีต่อมา เครื่องหนึ่งใน Microsoft Azure Data Center ทางฝั่งตะวันออกของสหรัฐอเมริกาใช้ Token นั้นเปิดกล่องอีเมลของเขา ไม่มีการถามรหัสผ่าน ไม่มี Authenticator Push ขึ้นมาอีกครั้ง ในมุมของ Microsoft 365 Tenant สิ่งที่เกิดขึ้นดูเหมือนเพียงแค่ผู้อำนวยการฝ่ายปฏิบัติการเปิด Outlook จากอุปกรณ์อีกเครื่องหนึ่ง และข้อกำหนด Multi-Factor Authentication ก็ได้ถูกยืนยันไปแล้ว

ซึ่งในแง่หนึ่ง เขาก็เป็นคนยืนยันมันจริง ๆ

11 วันที่ไม่มีใครสังเกตเห็น

นี่คือส่วนที่หลายคนยอมรับได้ยากที่สุด ไม่มีระบบอะไรพังเลย

ตลอด 11 วัน ผู้โจมตีอ่านอีเมล และส่วนใหญ่พวกเขาก็ทำแค่นั้น พวกเขาอ่านโฟลเดอร์ฝ่ายการเงิน อ่านบทสนทนากับซัพพลายเออร์ อ่านอีเมลเกี่ยวกับการอนุมัติชำระเงิน เรียนรู้ว่าใครเป็นคนอนุมัติอะไร รูปแบบใบแจ้งหนี้หน้าตาอย่างไร ซัพพลายเออร์รายไหนจ่ายช้า และบริษัทต้องจ่ายเงินให้ใครในเดือนนั้น พวกเขายังสร้าง Mailbox Rule เพื่อย้ายอีเมลทุกฉบับที่มีคำว่า "bank", "payment" หรือ "โอนเงิน" ไปไว้ในโฟลเดอร์ Archive ที่ผู้อำนวยการแทบไม่เคยเปิดดู

ในช่วงเวลาประมาณสองสัปดาห์นั้น ผู้โจมตียังพบอีกว่าบัญชีของผู้อำนวยการฝ่ายปฏิบัติการมีสิทธิ์ Global Administrator ใน Microsoft 365 สิทธิ์นี้อยู่กับบัญชีดังกล่าวมานานถึง 4 ปี ตั้งแต่ตอน Migration เพราะครั้งหนึ่งเคยมีคนจำเป็นต้องใช้ และหลังจากนั้นก็ไม่มีใครถอดสิทธิ์ออก

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

จากนั้นพวกเขาก็รอใบแจ้งหนี้ที่มีมูลค่ามากพอ

เช้าวันจันทร์

เรื่องทั้งหมดเริ่มแตกก็จากเหตุการณ์ธรรมดาที่สุดเท่าที่จะจินตนาการได้

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

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

เขาเปิด Audit Log แล้วเริ่มไล่อ่าน จากนั้นก็เริ่มรู้ทันทีว่าเรื่องนี้ใหญ่กว่าที่คิด มีบัญชีที่เขาไม่ได้สร้าง มีการย้าย Licence ไปมา มี User ถูกลบ และเมื่อเขาไล่ดูว่าบัญชีไหนเป็นคนทำกิจกรรมส่วนใหญ่ เขาก็พบ Administrator Account ที่ไม่เคยเห็นมาก่อน ถูกสร้างขึ้นเมื่อ 11 วันก่อน โดยบัญชีของผู้อำนวยการฝ่ายปฏิบัติการตอนตี 4

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

การรีเซ็ตรหัสผ่านของบัญชีหนึ่ง ไม่ได้ทำอะไรกับ Session ที่กำลังทำงานอยู่บนอุปกรณ์อีกเครื่องเลย

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

ก่อนเที่ยง ผู้จัดการฝ่ายการเงินได้รับโทรศัพท์จากซัพพลายเออร์ ถามว่าทำไมเงินจำนวน 1.8 ล้านบาทถึงถูกโอนไปยังบัญชีธนาคารที่พวกเขาไม่รู้จัก

สิ่งที่ต้องทำจริง ๆ ในชั่วโมงแรก

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

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

จากนั้นให้ทำตามลำดับนี้:

  1. ค้นหาทุกบัญชีที่ผู้โจมตีสร้างขึ้นหรือเข้าไปแตะต้อง ไม่ใช่แค่บัญชีเดียวที่คุณเพิ่งเจอ เรียง User ตามวันที่สร้าง แล้วไล่ดูใหม่ทั้งหมดด้วยมุมมองที่ระมัดระวัง ทุกบัญชีที่ไม่มีใครสามารถอธิบายที่มาได้ควรถูกมองว่าน่าสงสัย จนกว่าจะมีคนยืนยันได้ว่ามันถูกต้อง
  2. ตรวจสอบ OAuth Consent Grants นี่คือขั้นตอนที่เกือบทุกคนข้าม และเป็นเหตุผลที่บางองค์กรถูกโจมตีซ้ำอีกครั้งเพียงหนึ่งสัปดาห์หลังจากประกาศว่า Incident จบแล้ว หากผู้โจมตีหลอกให้ User กดยินยอมให้แอปพลิเคชันอันตราย แอปนั้นจะมีสิทธิ์เข้าถึง Mailbox ของตัวเอง ซึ่งยังคงอยู่แม้คุณจะรีเซ็ตรหัสผ่าน เปลี่ยน MFA หรือ Revoke Session ไปแล้ว คุณต้องเข้าไปตรวจสอบและถอนสิทธิ์ที่ไม่ควรอยู่ตรงนั้นออก
  3. ตรวจสอบ Mailbox Rules และการ Forward อีเมล ของทุกบัญชี ไม่ใช่แค่บัญชีที่รู้ว่าถูกเจาะ ผู้โจมตีมักสร้าง Rule เพื่อซ่อน Traffic ของตัวเอง ในกรณีนี้ ระบบได้แอบย้ายอีเมลทุกฉบับที่กล่าวถึงเรื่องธนาคารออกจาก Inbox อย่างเงียบ ๆ นานกว่าหนึ่งสัปดาห์
  4. เก็บ Audit Log เอาไว้ก่อนที่ข้อมูลจะหมดอายุ Microsoft 365 ไม่ได้เก็บ Audit Log ไว้ตลอดไป และ Licence ที่ SME จำนวนมากใช้งานมีระยะเวลาเก็บข้อมูลสั้นกว่าระยะเวลาที่คุณอาจต้องใช้ในการสืบสวน Export ข้อมูลออกมาในวันแรก หากไม่มี Log คุณจะไม่สามารถตอบคำถามสำคัญที่กำลังจะตามมาได้ และบางคำถามจะเป็นเรื่องทางกฎหมาย
  5. จากนั้นค่อยรีเซ็ต Credential และควรทำเมื่อแน่ใจแล้วว่าผู้โจมตีไม่มี Live Session ที่สามารถนั่งดูคุณเปลี่ยนทุกอย่างอยู่

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

เส้นตายที่ไม่มีใครรู้ว่ากำลังนับถอยหลังอยู่

ประมาณ 6 โมงเย็น หลังจากจัดการ Microsoft 365 Tenant จนกลับมาสะอาดอีกครั้ง ผมถามกรรมการผู้จัดการด้วยคำถามหนึ่งที่เขาไม่ได้เตรียมใจไว้

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

ไม่มีใครในห้องนั้นรู้เรื่องนี้ และไม่ได้ถือว่าเป็นเรื่องแปลก PDPC มีการบังคับใช้กฎหมายอย่างจริงจังมากขึ้นเรื่อย ๆ ในช่วงปี 2025 และ 2026 และการไม่แจ้งเหตุละเมิดข้อมูลถูกระบุอยู่ในทุกกรณีการบังคับใช้กฎหมายที่ประกาศในเดือนสิงหาคม 2025 บทลงโทษที่สูงที่สุดจนถึงตอนนี้อยู่ที่ 7 ล้านบาท กับบริษัทที่ไม่ได้แต่งตั้ง DPO ไม่มีมาตรการรักษาความปลอดภัยที่เพียงพอ และไม่แจ้งเหตุภายใน 72 ชั่วโมง

เส้นตายเริ่มนับตั้งแต่เช้าวันนั้น ตอนที่ Beam เปิด Audit Log และทราบว่ามีเหตุเกิดขึ้น ไม่ใช่ตั้งแต่วันที่ผู้โจมตีเข้าระบบครั้งแรกเมื่อ 11 วันก่อน กฎหมายเริ่มนับจากเวลาที่องค์กรรับรู้เหตุ ไม่ใช่จากเวลาที่ระบบถูกเจาะ นั่นหมายความว่าพวกเขามีเวลาถึงวันพฤหัสบดี

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

สิ่งที่พวกเขาซื้อเพิ่ม และสิ่งที่ยังไม่ได้แก้

ในช่วงหนึ่งเดือนหลังจากนั้น บริษัททำในสิ่งที่องค์กรที่จริงจังกับเรื่องความปลอดภัยควรทำหลังผ่านเหตุการณ์ใหญ่ พวกเขาลงทุนเพิ่มอย่างเหมาะสม ทั้ง Advanced Identity Licensing, ระบบ Email Security ที่จริงจังมากขึ้น, Endpoint Detection and Response และระบบ Third-Party Backup พร้อม Email Archiving

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

ในบรรดาสิ่งที่ซื้อมา อะไรบ้างที่จะหยุดการโจมตีครั้งนี้ได้?

คำตอบตรง ๆ คือ ไม่มีสักอย่าง อย่างน้อยก็ถ้าใช้เพียงอย่างเดียว สาเหตุหลักของเหตุการณ์นี้คือ Session Token ถูกขโมย และการนำ Token กลับมาใช้ซ้ำไม่ได้หยุดได้ด้วยการซื้อ Licence เพิ่ม สิ่งที่หยุดมันได้คือการตั้งค่าระบบอย่างถูกต้อง และมาตรการส่วนใหญ่ก็มีอยู่แล้วใน Licence ที่บริษัทถืออยู่ก่อนเกิด Incident:

MFA ที่ป้องกัน Phishing ได้จริง

เช่น Passkey, FIDO2 Security Key หรือ Windows Hello Credential จะถูกผูกทาง Cryptography เข้ากับ Domain Login จริง ทำให้ Proxy ที่อยู่ตรงกลางไม่มีข้อมูลอะไรให้ขโมย นี่คือมาตรการเดียวในรายการนี้ที่หยุดรูปแบบการโจมตีนี้ได้ตั้งแต่ระดับโครงสร้าง ไม่ใช่แค่ลดโอกาสสำเร็จ Push Notification และ Authenticator Code ไม่สามารถทำได้ เพราะในการโจมตีลักษณะนี้ User เป็นคนยืนยัน MFA อย่างถูกต้องด้วยตัวเอง และนั่นคือหัวใจของการโจมตี

Conditional Access ที่บังคับใช้อุปกรณ์ที่ Compliant

Infrastructure ของผู้โจมตีไม่สามารถผ่าน Device Compliance Check ได้ ไม่ว่า Token ที่ถืออยู่จะถูกต้องแค่ไหนก็ตาม

Token Protection

ผูก Token เข้ากับอุปกรณ์ที่ได้รับ Token นั้น หากมีการนำ Token ไป Replay จากอุปกรณ์หรือสถานที่อื่น ระบบจะปฏิเสธทันที

Continuous Access Evaluation

สามารถตัด Session ที่มีความเสี่ยงได้แทบจะทันที แทนที่จะปล่อยให้ Session ทำงานต่อจน Token หมดอายุตามธรรมชาติ

ยกเลิกสิทธิ์ Administrator แบบถาวร

บัญชีของผู้อำนวยการฝ่ายปฏิบัติการไม่ควรถือสิทธิ์ Global Administrator ต่อเนื่องมา 4 ปี หากใช้สิทธิ์แบบ Just-in-Time Privileged Access บัญชีนั้นจะมีมูลค่าต่อผู้โจมตีน้อยลงอย่างมาก

สิ่งเหล่านี้ไม่ได้มีค่าใช้จ่ายสูง มาตรการส่วนใหญ่มีอยู่ใน Microsoft 365 Business Premium อยู่แล้ว สิ่งที่ต้องลงทุนจริง ๆ คือเวลาของใครสักคนไม่กี่สัปดาห์ และความตั้งใจที่จะกลับไปตรวจสอบ Settings ที่อาจไม่มีใครแตะมาตั้งแต่วันที่สร้าง Tenant ขึ้นมา

การซื้อ Licence คือส่วนที่ง่ายที่สุด

นี่ไม่ใช่ปัญหาเฉพาะบริษัทใหญ่

เครื่องมือที่ใช้โจมตีบริษัทนี้มีขายกันในรูปแบบ Subscription ชุดเครื่องมือ Phishing ที่สามารถโจมตีในลักษณะเดียวกันได้เริ่มต้นที่ประมาณ 120 ดอลลาร์สหรัฐต่อเดือน และ Microsoft เคยติดตาม Phishing Kit เพียงชุดเดียวที่ส่งข้อความหลายสิบล้านฉบับไปยังองค์กรมากกว่า 500,000 แห่งในแต่ละเดือน Microsoft รายงานว่าการโจมตีแบบ Adversary-in-the-Middle เพิ่มขึ้นถึง 146% เมื่อเทียบกับปีก่อน และในช่วงเวลาเพียง 3 วันในเดือนเมษายน 2026 แคมเปญเดียวสามารถขโมย Credential และ Session Token จากผู้ใช้มากกว่า 35,000 ราย ในองค์กรกว่า 13,000 แห่ง ครอบคลุม 26 ประเทศ

ผู้ใช้ทุกคนเหล่านั้นมี MFA

84%

ของ Incident Response ที่ MFA ไม่สามารถหยุดการโจมตีได้ (Obsidian Security)

59%

ของบัญชีที่ถูกยึดไปใช้งานมีการเปิด MFA อยู่แล้ว (Proofpoint)

146%

การโจมตีแบบ Adversary-in-the-Middle เพิ่มขึ้นเมื่อเทียบกับปีก่อน (Microsoft)

97%

ของบริษัทในเอเชียตะวันออกเฉียงใต้เป็น SME

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

7 คำถามที่ควรถามผู้ให้บริการ IT ของคุณภายในสัปดาห์นี้

คุณไม่จำเป็นต้องเข้าใจ Token Binding เพื่อคุยเรื่องนี้กับผู้ให้บริการ สิ่งที่ต้องทำคือถามคำถามเหล่านี้:

  1. ถ้าบัญชีของบริษัทถูกเจาะในวันพรุ่งนี้ เราจะ Revoke Session หรือแค่รีเซ็ตรหัสผ่าน?
  2. ตอนนี้ใครบ้างในบริษัทที่ถือสิทธิ์ Global Administrator และแต่ละคนจำเป็นต้องมีสิทธิ์นั้นเพราะอะไร?
  3. เราใช้งาน Phishing-Resistant MFA อยู่ตรงไหนบ้าง หรือทุกคนยังใช้ Authenticator Code และ Push Notification?
  4. ถ้าล็อกอินจากอุปกรณ์ที่บริษัทไม่ได้บริหารจัดการ ตอนนี้สามารถเข้าถึงอีเมลของบริษัทได้หรือไม่?
  5. เราเก็บ Audit Log ไว้นานเท่าไร และหากจำเป็น เราสามารถย้อนดูและสร้างภาพเหตุการณ์ย้อนหลังตลอด 11 วันได้หรือไม่?
  6. เคยมีใครตรวจสอบหรือยังว่า Third-Party Application ใดบ้างที่ได้รับ Consent ให้เข้าถึง Tenant ของเรา?
  7. เรารู้หรือไม่ว่าหน้าที่ในการแจ้งเหตุภายใต้ PDPA ของบริษัทคืออะไร และถ้าเหตุเกิดตอน 6 โมงเย็นวันจันทร์ ใครคือคนที่มีอำนาจตัดสินใจเรื่องนี้?

หากคำตอบที่ได้ยังคลุมเครือ นั่นก็คือ Finding ของคุณแล้ว

และหากคุณกำลังพิจารณาด้วยว่าใครควรเป็นคนดูแล Microsoft 365 Tenant ของบริษัทในแต่ละวัน คู่มือของเราเรื่อง วิธีเลือก Microsoft 365 Partner ในประเทศไทย อธิบายคำถามสำคัญที่ควรถามผู้ให้บริการก่อนตัดสินใจเซ็นสัญญา

ไม่มีค่าใช้จ่าย ไม่มี Sales Deck

ตรวจประเมินความเสี่ยง Microsoft 365 ฟรี

หากบริษัทของคุณใช้งาน Microsoft 365 และยังไม่เคยมีผู้เชี่ยวชาญอิสระเข้ามาตรวจสอบ Tenant อย่างจริงจัง Raso Cyber สามารถช่วยตรวจให้โดยไม่มีค่าใช้จ่าย

เราจะบอกคุณอย่างชัดเจนว่ามาตรการที่สามารถหยุดการโจมตีแบบในบทความนี้ถูกเปิดใช้งานอยู่ใน Environment ของคุณหรือไม่ ไม่ว่าจะเป็น Conditional Access Policies, Authentication Methods, Administrative Role Assignments, OAuth Consent Posture, Audit Log Retention และ Email Authentication คุณจะได้รับรายงานที่อ่านเข้าใจง่ายว่าจุดไหนมีความเสี่ยง จุดไหนควรแก้ และควรเริ่มจากอะไรก่อนตามลำดับ

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

จองผ่าน rasocyber.com ติดต่อผ่าน Digigen

ติดต่อผ่าน Digigen แล้วทีมงานจะช่วยประสานให้คุณได้พูดคุยกับเรา

Digigen สร้างและดูแล Platform ส่วนเราตรวจสอบว่ามันถูกล็อกไว้อย่างปลอดภัยจริงหรือไม่

เกี่ยวกับผู้เขียน: Alex เป็นผู้ก่อตั้ง Raso Cyber บริษัทผู้เชี่ยวชาญด้าน Cyber Security อิสระที่ให้บริการประเมินและยกระดับความปลอดภัยของ Microsoft 365 และ Google Workspace Tenant สำหรับธุรกิจในประเทศไทยและสิงคโปร์ บทความนี้เผยแพร่ร่วมกับ Digigen ซึ่งเป็น Google Cloud Partner และ Microsoft Solutions Partner ที่ได้รับการรับรอง

```