เมื่อมีรายงานว่า SharePoint Server RCE ถูกนำไปใช้โจมตีจริงหลังมีการเผยแพร่ Proof-of-Concept หรือ PoC ประเด็นที่องค์กรควรถามอาจไม่ใช่เพียง “patch แล้วหรือยัง” แต่ควรถามต่อว่า “ก่อน patch มีใครเข้ามาแล้วหรือไม่” และ “ข้อมูลหรือ credential ใดอาจถูกแตะต้องไปแล้วบ้าง”

SharePoint ในหลายองค์กรไม่ใช่แค่ระบบเก็บไฟล์ แต่เป็นพื้นที่ทำงานร่วมกันของฝ่ายกฎหมาย การเงิน HR IT โครงการภายใน เอกสารลูกค้า และข้อมูลที่ใช้ตัดสินใจทางธุรกิจ หากระบบนี้ถูกโจมตี ผลกระทบจึงไม่ได้หยุดอยู่ที่ server downtime แต่อาจขยายไปถึงข้อมูลภายใน ความลับทางธุรกิจ ความน่าเชื่อถือ และ compliance ขององค์กร

จากรายงานของ The Hacker News เมื่อ 21 กรกฎาคม 2026 ระบุว่า CVE-2026-50522 ซึ่งเป็นช่องโหว่ Remote Code Execution ใน Microsoft SharePoint Server ถูกพบว่ามีการโจมตีหลังมี public PoC โดยมีประเด็นสำคัญคือผู้โจมตีอาจพยายามดึง machine keys เพื่อคงสิทธิ์หรือ persistence ต่อไปหลังจากนั้น ขณะเดียวกัน CISA เคยแจ้งเตือนการโจมตีช่องโหว่ SharePoint หลายรายการในเดือนกรกฎาคม 2026 และเน้นให้เร่ง hardening ระบบ SharePoint on-premises

เมื่อ SharePoint ไม่ใช่แค่ระบบเอกสาร แต่เป็นศูนย์กลางข้อมูลภายใน

หลายองค์กรใช้ SharePoint เป็น document repository, collaboration portal, intranet, project workspace หรือ workflow กลางของหลายแผนก นั่นหมายความว่า SharePoint อาจมีข้อมูลหลายประเภทอยู่รวมกัน ตั้งแต่เอกสารภายในทั่วไป ไปจนถึงข้อมูลที่มีความอ่อนไหว เช่น ข้อมูลลูกค้า ข้อมูลพนักงาน เอกสารสัญญา audit evidence policy หรือแผนกลยุทธ์

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

สำหรับผู้บริหาร IT และ Security Manager สิ่งที่น่ากังวลคือ SharePoint มักอยู่ในจุดที่เชื่อมทั้ง identity, file access, permission structure และ business process หาก governance ของสิทธิ์ไม่ชัด การโจมตีหนึ่งครั้งอาจเปิดทางให้ข้อมูลหลายส่วนถูกเข้าถึงเกินกว่าที่คาดไว้

ทำไม PoC ทำให้ความเสี่ยงเปลี่ยนเร็ว

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

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

โดยเฉพาะ SharePoint on-premises ที่เปิดรับจากอินเทอร์เน็ต หรือเชื่อมกับระบบภายในหลายส่วน ความเสี่ยงหลัง PoC จะสูงขึ้นหากองค์กรยังไม่มี asset inventory ที่ชัด ไม่มี vulnerability prioritization และไม่มี log monitoring ที่เพียงพอ

Patch สำคัญ แต่ไม่ควรเป็นจุดจบของการรับมือ

การ patch เป็นขั้นตอนจำเป็น แต่ในกรณีที่มี active exploitation หรือมี public PoC แล้ว patch เพียงอย่างเดียวอาจไม่ตอบคำถามสำคัญสามข้อ

ข้อแรก ระบบเคยถูกโจมตีก่อน patch หรือไม่
ข้อสอง มี credential, key, token หรือ configuration ใดถูกเข้าถึงไปแล้วหรือไม่
ข้อสาม ผู้โจมตียังมี persistence หรือช่องทางกลับเข้ามาในระบบอยู่หรือไม่

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

ตรวจสอบร่องรอยการโจมตี

ทีม IT และ Security ควรตรวจ log ที่เกี่ยวข้องกับ SharePoint, IIS, authentication, abnormal request pattern, unexpected process execution และการเข้าถึงไฟล์ผิดปกติ โดยเฉพาะช่วงก่อนและหลังมีข่าว PoC

หากองค์กรไม่มี log retention หรือ centralized monitoring ที่ดี เหตุการณ์ลักษณะนี้จะกลายเป็นบทเรียนสำคัญว่า incident readiness ไม่ได้เริ่มในวันที่เกิดเหตุ แต่เริ่มตั้งแต่การออกแบบระบบให้มีหลักฐานเพียงพอสำหรับการตรวจสอบย้อนหลัง

หมุนเวียน Key และ Credential ที่เกี่ยวข้อง

ในกรณีที่มีความเป็นไปได้ว่าผู้โจมตีอาจเข้าถึง machine keys, service account, application pool identity, token หรือ credential ที่เกี่ยวข้อง การ patch อย่างเดียวอาจไม่เพียงพอ องค์กรควรพิจารณา key rotation, credential reset และ review สิทธิ์ของ account ที่เชื่อมกับ SharePoint อย่างเป็นระบบ

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

ประเมินสิทธิ์และข้อมูลที่อาจถูกเข้าถึง

SharePoint มักมี permission inheritance ที่ซับซ้อน บาง library หรือ site อาจเปิดสิทธิ์กว้างกว่าที่เจ้าของข้อมูลเข้าใจ การตรวจสอบหลังเหตุจึงควรรวมถึง data exposure assessment ว่ามีข้อมูลประเภทใดอยู่ในระบบ ใครมีสิทธิ์เข้าถึง และข้อมูลใดจัดเป็นข้อมูลส่วนบุคคลหรือข้อมูลสำคัญทางธุรกิจ

จุดนี้เชื่อมกับ PDPA, Data Governance และ ISO/IEC 27001 โดยตรง เพราะองค์กรต้องรู้ว่าข้อมูลอยู่ที่ไหน ใครเข้าถึงได้ มี control ใดคุ้มครอง และหากเกิดเหตุจะพิสูจน์การควบคุมได้อย่างไร

มุมมองสำหรับผู้บริหาร: ความเสี่ยงอยู่ที่ข้อมูล ไม่ใช่แค่เซิร์ฟเวอร์

SharePoint RCE เป็นตัวอย่างที่ดีของความเสี่ยงที่ผู้บริหารไม่ควรมองเป็นงาน patch management เพียงอย่างเดียว เพราะความเสียหายที่แท้จริงอาจอยู่ที่ข้อมูลภายใน ความต่อเนื่องของธุรกิจ ความเชื่อมั่นของลูกค้า และความพร้อมด้าน compliance

คำถามที่องค์กรควรถามคือ

• SharePoint Server ของเรามี exposure จากภายนอกหรือไม่
• ระบบได้รับ patch ครบถ้วนตาม version ที่ใช้งานหรือยัง
• มี log เพียงพอสำหรับตรวจสอบย้อนหลังหรือไม่
• มีข้อมูลส่วนบุคคลหรือข้อมูลสำคัญใดอยู่ใน SharePoint
• มีการ review permission และ service account ล่าสุดเมื่อไร
• หากพบ data exposure องค์กรมี incident response และ PDPA breach process พร้อมหรือไม่

องค์กรที่ตอบคำถามเหล่านี้ได้เร็ว จะลดความเสียหายได้ดีกว่าองค์กรที่รู้เพียงว่า “ติดตั้ง patch แล้ว”

ACIS เราช่วยคุณได้อย่างไร

ACIS ช่วยองค์กรรับมือความเสี่ยงลักษณะ SharePoint RCE ได้มากกว่าการแนะนำให้ patch ระบบ โดยช่วยมองครบตั้งแต่ People, Process และ Technology

ในเชิง Technology ACIS ช่วยประเมินช่องโหว่ ตรวจสอบ exposure และทดสอบความเสี่ยงของระบบสำคัญผ่าน Vulnerability Assessment, Security Assessment และ Penetration Testing เพื่อให้องค์กรรู้ว่าจุดอ่อนที่แท้จริงอยู่ตรงไหน

ในเชิง Process ACIS ช่วยวางแนวทาง Incident Readiness, Patch Management, Access Control, Logging และ ISMS ตามแนวทาง ISO/IEC 27001 เพื่อให้องค์กรไม่ได้แก้ปัญหาเป็นครั้ง ๆ แต่มีระบบบริหารความเสี่ยงที่ตรวจสอบได้

ในเชิง Data Protection และ Compliance ACIS ช่วยประเมินว่าหากระบบ SharePoint มีข้อมูลส่วนบุคคลหรือข้อมูลสำคัญ องค์กรควรเตรียม data inventory, breach response, evidence และกระบวนการ PDPA อย่างไร โดยสามารถเชื่อมกับ TrustWork และบริการ PDPA Consulting ได้อย่างเป็นระบบ

Vulnerability Assessment / Security Assessment: ประเมินระบบ SharePoint และระบบที่เชื่อมต่อ เพื่อระบุช่องโหว่ configuration risk และ exposure ที่ควรแก้ไข

Penetration Testing: ทดสอบความเสี่ยงเชิงรุกจากมุมมองผู้โจมตี โดยเฉพาะระบบ on-premises ที่เปิดให้เข้าถึงจากภายนอก

ISO/IEC 27001 Consulting / ISMS Readiness: วางระบบบริหารความมั่นคงปลอดภัยสารสนเทศ ตั้งแต่ asset, access control, logging, incident management และ continual improvement

Incident Readiness: เตรียม playbook กระบวนการตรวจสอบ log, containment, credential rotation และ post-incident review

PDPA Consulting / TrustWork: ประเมินผลกระทบด้านข้อมูลส่วนบุคคล และจัดทำกระบวนการรองรับ data breach notification

Data Governance Consulting: ช่วยให้องค์กรรู้ว่าข้อมูลสำคัญอยู่ที่ไหน ใครเป็นเจ้าของ ใครเข้าถึงได้ และควบคุมอย่างไร

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