แจ้งเตือนช่องโหว่ระดับวิกฤติใน F5 BIG-IP รันโค้ดอันตรายจากระยะไกล

F5 Networks ซึ่งเป็นหนึ่งในผู้ให้บริการเครือข่ายระดับองค์กรที่ใหญ่ที่สุดในโลกได้เผยแพร่คำแนะนำด้านความปลอดภัยเพื่อเตือนลูกค้าให้ทำการอัพเดตเเพตซ์แก้ไขข้อบกพร่องด้านความปลอดภัยที่เป็นอันตรายซึ่งมีแนวโน้มว่าจะถูกนำไปใช้ประโยชน์ เพื่อโจมตีองค์กรต่างๆ โดยช่องโหว่ดังกล่าวถูกติดตามด้วยรหัส CVE-2020-5902 ช่องโหว่ที่เกิดขึ้นนั้นส่งผลกระทบต่อผลิตภัณฑ์ BIG-IP ซึ่งอยู่ในอุปกรณ์เน็ตเวิร์คเช่น Web Traffic Shaping Systems, Load balance, Firewall, Access Gateway ตลอดจนไปถึง SSL Middleware เป็นต้น

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

รายละเอียดช่องโหว่โดยย่อ

รายละเอียดของช่องโหว่เชิงเทคนิค

การโจมตีช่องโหว่

ระบบที่ได้รับผลกระทบ

การตรวจจับและป้องกันการโจมตี

Root Cause ของช่องโหว่

การบรรเทาผลกระทบ

อ้างอิง

รายละเอียดช่องโหว่โดยย่อ
ช่องโหว่ CVE-2020-5902 เป็นช่องโหว่ Remote Code Execution (RCE) ที่เกิดขึ้นจากข้อผิดพลาดใน BIG-IP Management Interface หรือที่เรียกว่า TMUI (Traffic Management User Interface) โดยช่องโหว่นี้ถูกประเมินด้วยคะแนน CVSSv3 แบบ Base Score อยู่ที่ 10/10 ซึ่งถือว่าเป็นช่องโหว่ที่มีความรุนเเรงและอัตรายอย่างมาก

ผู้ประสงค์ร้ายสามารถใช้ประโยน์จากช่องโหว่นี้ผ่านทางอินเตอร์เน็ตเพื่อเข้าถึง TMUI Component ซึ่งทำงานบน Tomcat เซิร์ฟเวอร์บนระบบปฏิบัติการ Linux ของ BIG-IP ซึ่งช่องโหว่นี้ทำให้ผู้บุกรุกสามารถรันคำสั่งบนระบบได้ โดยการรันคำสั่งสามารถสร้างหรือลบไฟล์, Disable Service และยังสามารถรันคำสั่งโค้ด Java บนอุปกรณ์ที่ใช้ BIG-IP ได้

ช่องโหว่นี้ถูกค้นพบและรายงานโดย Mikhail Klyuchnikov นักวิจัยด้านความปลอดภัยจาก Positive Technologies นักวิจัยได้ทำการค้นหาอุปกรณ์ BIG-IP ที่สามารถเข้าได้ผ่านอินเตอร์เน็ต โดยการใช้ Shodan Search พบว่ายังมีอุปกรณ์ BIG-IP ประมาณ 8,400 ที่สามารถเข้าได้ผ่านอินเตอร์เน็ตซึ่ง 40% อยู่ในประเทศสหรัฐอเมริกา

รูปที่ 1 จำนวนอุปกรณ์ BIG-IP ที่สามารถเข้าได้ผ่านอินเตอร์เน็ต

รายละเอียดของช่องโหว่เชิงเทคนิค
ช่องโหว่ CVE-2020-5902 เป็นช่องโหว่ Directory Traversal ใน /tmui/locallb/workspace/tmshCmd.

บทสรุปจาก FireEye M-Trends 2020: จงทำดียิ่งๆ ขึ้นไป

หากถามความเห็นของทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) ของบริษัท ไอ-ซีเคียว จำกัด ว่าการรับมือและตอบสนองภัยคุกคามในลักษณะไหนที่เราอยากทำให้ได้ หรือทีมในการรับมือและตอบสนองภัยคุกคามทีมใดที่เราอยากเป็นและเอามาเป็นแบบอย่าง ทีมจาก FireEye Mandiant มักเป็นตัวเลือกอันดับต้นๆ ที่เรานึกถึงเสมอ

นอกเหนือจาก Threat Research Blog ที่เราเป็นแฟนตัวยงแล้ว ในทุกๆ ปี FireEye Mandiant จะมีการเผยแพร่รายงาน M-Trends ซึ่งอธิบายภาพรวมของการรับมือและตอบสนองภัยคุกคามที่ด่านหน้า รายงาน M-Trends มีประโยชน์อย่างมากในมุมของการให้ข้อมูลทางสถิติที่มีผลโดยตรงต่องานด้าน Incident response รวมไปถึงการบทวิเคราะห์และการทำนายเพื่อการเตรียมพร้อมรับมือ

ดังนั้นในโพสต์นี้ ทีม Intelligent Response จะมาสรุปประเด็นที่น่าสนใจจากรายงาน M-Trends 2020 ว่าเราผ่านอะไรมาแล้วบ้าง เราจะเจออะไรต่อและเราต้องเตรียมพร้อมเพื่อเจอกกับสิ่งเหล่านั้นอย่างไรครับ

รายงาน M-Trends 2020 ฉบับเต็มสามารถดาวโหลดได้ที่นี่
การลดลงของ Dwell Time และการตรวจจับภัยคุกคามที่รวดเร็วขึ้น
ส่วนสำคัญของ M-Trends ในทุกๆ ปีคือข้อมูลทางด้านสถิติซึ่งสะท้อนให้เห็นประสิทธิภาพในการรับมือและตอบสนองภัยคุกคาม โดยในปีนี้นั้นค่า Dwell time ซึ่งหมายถึงระยะเวลาที่ภัยคุกคามอยู่ในระบบจนกว่าจะถูกตรวจจับได้มีการลดลงในทิศทางที่ดี

ในปี 2018 นั้น เราใช้เวลาถึง 50.5 วันในการตรวจจับการมีอยู่ของภัยคุกคามในสภาพแวดล้อมหรือระบบ ในขณะเดียวกันในปี 2019 เราตรวจจับการมีอยู่ของภัยคุกคามเร็วขึ้นจนเหลือเพียง 30 วันเท่านั้น ในอีกมุมหนึ่งก็อาจสามารถพูดได้ว่าการตรวจจับของเราดีขึ้นจนทำให้เวลาที่ภัยคุกคามจะอยู่ในระบบได้ลดน้อยลง

นอกเหนือจากการลดลงในมุมของการตรวจจับภัยคุกคามภายในแล้ว ยังมีประเด็นที่น่าสนใจในเรื่องของ Dwell time ดังนี้

ค่าเฉลี่ยในการตรวจจับกิจกรรมการของสหรัฐอเมริกาอยู่ที่ 14 วัน โดยกิจกรรมการตรวจพบที่มากที่สุดคือการโจมตีด้วย Ransomware ถูกคิดเป็น 43% ของเวลาเฉลี่ย
ค่าเฉลี่ยในการตรวจจับกิจกรรมการของกลุ่ม APAC อยู่ที่ 54 วันจาก 204 วันจากปีก่อนหน้านี้ โดยกิจกรรมการตรวจพบที่มากที่สุดคือ การโจมตีด้วย Ransomware ถูกคิดเป็น 18% ของเวลาเฉลี่ย

กลุ่ม Entertainment/Media ขึ้นจากอันดับ 5 สู่อันดับ 1 ของกลุ่ม Sector ที่ถูกโจมตีมากที่สุด
10 อันดับของกลุ่มธุรกิจที่มักตกเป็นเป้าหมายในการโจมตีมีตามรายการดังนี้

กลุ่ม Entertainment/Media
กลุ่ม Financial
หน่วยงานรัฐฯ
กลุ่มธุรกิจทั่วไปและกลุ่มซึ่งให้บริการจำพวก Professional service
กลุ่มธุรกิจเกี่ยวกับวิศวกรรมและการก่อสร้าง
กลุ่มบริษัททางด้านเทคโนโลยีและกลุ่มองค์กรด้านการติดต่อสื่อสาร
ไม่มีอันดับ
กลุ่ม Healthcare
กลุ่มพลังงาน
กลุ่มองค์กรไม่แสวงหาผลกำไร กลุ่มเกี่ยวกับการคมนาคมและขนส่ง

ช่องทางการโจมตียอดนิยมคือ Remote Desktop และ Phishing
ช่องทางการโจมตีซึ่งเป็นที่นิยมในปี 2019 ยังคงเป็นช่องทางที่ทำให้ผู้โจมตีสามารถควบคุมเป้าหมายได้จากระยะไกลอย่างฟีเจอร์ Remote Desktop เป็นส่วนใหญ่ ในขณะเดียวกันการโจมตีอย่าง Phishing ก็ยังคงได้รับความนิยมและมักถูกใช้โดยกลุ่ม APT อันเนื่องมาจากความยากในการป้องกันและตรวจสอบ
กลุ่ม APT 41 จากจีนคือกลุ่มภัยคุกคามหลักสำหรับประเทศกลุ่ม APAC

กลุ่มผู้โจมตีที่พุ่งเป้ามามาที่ไทยหรือในกลุ่ม APAC คือ APT41 ซึ่งเป็นกลุ่มแฮกเกอร์ที่ได้รับการสนับสนุนจากรัฐบาลจีนโดยทางกลุ่มได้กำหนดเป้าหมายเป็นองค์กรภายใน 14 ประเทศ เช่น ฮ่องกง, ฝรั่งเศส, อินเดีย, อิตาลี, ญี่ปุ่น,พม่า, เนเธอร์แลนด์, สิงคโปร์, เกาหลีใต้, แอฟริกาใต้, , สวิตเซอร์แลนด์, ไทย, ตุรกี, สหราชอาณาจักรและสหรัฐอเมริกากลุ่ม APT41 พุ่งเป้าไปที่การเงินและธนาคาร แต่เป้าหมายหลักคืออุตสาหกรรมวิดีโอเกม

ในการตรวจจับ Advance Persistent Threat (APT) นั้นผู้ดูเเลควรมีระบบตรวจจับ อาทิเช่น Next-Gen Firewall, Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), Web Application Firewall (WAF), Endpoint Protection เพื่อที่จะสามารถแยกแยะพฤติกรรมการใช้งานปกติออกจากพฤติกรรมที่เป็นการโจมตีและแยกแยะไฟล์ที่เป็นอันตรายกับไฟล์ที่ไม่เป็นอันตรายได้ เพื่อที่จะช่วยให้ผู้ดูแลระบบอย่างมีประสิทธิภาพ

รายละเอียดภัยคุกคามและปฏิบัติการของ Maze Ransomware

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

ไมโครซอฟต์มีการบัญญัติคำเพื่อเรียกมัลแวร์เรียกค่าไถ่และปฏิบัติการของมัลแวร์เรียกค่าไถ่ในกลุ่มนี้ว่า Human-operated Ransomware ซึ่งส่วนหนึ่งในปฏิบัติการของมัลแวร์เรียกค่าไถ่ที่สำคัญคือการที่ผู้ไม่ประสงค์ดีคอยควบคุมและจัดการเพื่อให้สามารถสร้างผลกระทบต่อเหยื่อและผลประโยชน์ต่อผู้ไม่ประสงค์ดีให้ได้มากที่สุด

ในเชิงเทคนิคนั้น ความแตกต่างระหว่างมัลแวร์เรียกค่าไถ่และปฏิบัติการแบบทั่วไปซึ่งอาศัยการสร้างเงื่อนไขเพื่อขู่กรรโชกด้วยการเข้ารหัสไฟล์หรือ Classic ransomware campaign กับมัลแวร์เรียกค่าไถ่และกลุ่มปฏิบัติการแบบ Human-operated ransomware มีตามประเด็นดังนี้

เวลาที่ใช้ในปฏิบัติการ (Operation time):

Classic ransomware campaign: จุดอ่อนสำคัญของมัลแวร์เรียกค่าไถ่และปฏิบัติการแบบทั่วไปซึ่งอาศัยการสร้างเงื่อนไขเพื่อขู่กรรโชกด้วยการเข้ารหัสไฟล์อยู่ในจุดที่กระบวนการเข้ารหัสไฟล์ของมัลแวร์เรียกค่าไถ่ถูกตรวจพบหรือถูกขัดขวางก่อนที่จะดำเนินการเสร็จสิ้น ดังนั้นมัลแวร์เรียกค่าไถ่ในกลุ่มนี้จะดำเนินการเสร็จให้เร็วและหลีกเลี่ยงการที่จะถูกตรวจจับให้ได้มากที่สุด ทำให้การตรวจจับนั้นจะสามารถทำได้เฉพาะในช่วงเวลาที่มีการทำงานของมัลแวร์เรียกค่าไถ่เท่านั้น
Human-operated ransomware: มัลแวร์เรียกค่าไถ่และปฏิบัติการในกลุ่มนี้มีการแสดงพฤติกรรมของการเข้าถึงระบบ เคลื่อนย้ายตัวเองไปยังระบบอื่น พยายามยกระดับสิทธิ์และเข้าถึงข้อมูลคล้ายกับพฤติกรรมของกลุ่ม Advanced Persistent Threat (APT) ที่มีเป้าหมายในการจารกรรมข้อมูล ส่งผลให้กรอบและระยะเวลาในการปฏิบัติการนั้นยาวและอาจเพิ่มโอกาสในการตรวจจับความผิดปกติจากพฤติกรรมได้ด้วย

หลักฐานหลังจากการโจมตี (Post-incident artifacts):

Classic ransomware campaign: มัลแวร์เรียกค่าไถ่จะแสดงตัวก็ต่อเมื่อกระบวนการเข้ารหัสไฟล์เสร็จสิ้นแล้วผ่านทาง Ransom note หรือข้อความซึ่งอธิบายเหตุการณ์และขั้นตอนของ ด้วยข้อมูลใน Ransom note ดังกล่าว การระบุหาประเภทของมัลแวร์เรียกค่าไถ่และผลกระทบอื่นๆ ที่อาจเกิดขึ้นจึงสามารถทำได้โดยง่าย
Human-operated ransomware: เนื่องจากระยะเวลาของปฏิบัติการที่ยาวและโอกาสที่ปฏิบัติการของมัลแวร์เรียกค่าไถ่จะถูกตรวจพบระหว่างดำเนินการโดยที่ยังไม่มีหลักฐานอย่างเช่น Ransom note อย่างชัดเจนจึงมีโอกาสที่สูงซึ่งส่งผลให้การระบุประเภทของภัยคุกคามและผลกระทบของเหตุการณ์นั้นทำได้ยาก การรับมือและตอบสนองเหตุการณ์ในลักษณะนี้จำเป็นต้องประเมินถึงความเป็นไปได้ว่าเหตุการณ์ดังกล่าวอาจจบที่มีการใช้ Ransomware ในที่สุดด้วย

พฤติกรรมของ Maze Ransomware
ไมโครซอฟต์ได้มีการเปิดเผยพฤติกรรมของมัลแวร์เรียกค่าไถ่ในกลุ่ม Human-operated Ransomware รวมไปถึงพฤติกรรมของ Maze ในบทความ Ransomware groups continue to target healthcare, critical services; here’s how to reduce risk ซึ่งสามารถสรุปโดยสังเขปได้ดังนี้

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

Maze มักปรากฎการเข้าถึงระบบที่มีความเสี่ยงด้วยการโจมตีผ่านเซอร์วิส Remote Desktop ซึ่งตั้งค่าไว้อย่างไม่ปลอดภัย ในขณะที่มัลแวร์กลุ่มอื่นมีการโจมตีช่องโหว่ซึ่งเป็นที่มีการเปิดเผยมาก่อนแล้ว อาทิ ช่องโหว่ใน Citrix Application Delivery Controller (CVE-2019-19781) หรือช่องโหว่ใน Pulse Secure VPN (CVE-2019-11510) ไมโครซอฟต์ยังมีการระบุว่าเป้าหมายหลักของ Maze คือการโจมตีกลุ่มผู้ให้บริการ (Managed Service Provider) เพื่อใช้เป็นช่องทางในการเข้าถึงผู้ใช้บริการในกลุ่มธุรกิจนี้ด้วย
Maze ใช้โปรแกรม Mimikatz ในการระบุหาข้อมูลสำหรับยืนยันตัวตนในระบบ ข้อมูลสำหรับยืนยันตัวตนนี้จะถูกใช้เพื่อเข้าถึงระบบอื่นๆ
กระบวนการเคลื่อนย้ายตัวเองในระบบภายในขององค์กรมักเกิดขึ้นผ่านการใช้โปรแกรม Cobalt Strike ทั้งนี้เทคนิคและวิธีการที่ Cobalt Strike รองรับนั้นโดยส่วนใหญ่เป็นเทคนิคซึ่งเป็นที่รู้จักกันอยู่แล้ว อาทิ การโจมตีแบบ Pass-the-Hash, WinRM หรือการใช้เซอร์วิส PsExec ในการเข้าถึงด้วยข้อมูลสำหรับยืนยันตัวตนที่ได้มา
กระบวนการฝังตัวของ Maze มีการปรากฎการใช้ฟีเจอร์ Scheduled Tasks ร่วมกับการใช้คำสั่ง PowerShell ซึ่งทำให้ผู้โจมตีสามารถเข้าถึงระบบที่ถูกโจมตีไปแล้วได้ Maze ยังมีการใช้ฟีเจอร์ WinRM ในการควบคุมระบบเมื่อได้บัญชีซึ่งมีสิทธิ์ของ Domain admin ด้วย
Maze มีการแก้ไขการตั้งค่าใน Group Policy หลายรายการเพื่อช่วยอำนวยความสะดวกในการโจมตี

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

ในกรณีที่ตรวจพบพฤติกรรมต้องสงสัย พิจารณาการทำ Endpoint segmentation โดยการกำหนด Policy ของ Windows Firewall หรือด้วยอุปกรณ์อื่นๆ เพื่อจำกัดการติดต่อระหว่างโฮสต์หากมีการพยายามติดต่อรับส่งข้อมูลผ่านทางโปรโตคอล
ในกรณีที่ตรวจพบพฤติกรรมต้องสงสัย พิจารณาการทำ Endpoint segmentation โดยการจำกัดหรือปิดการใช้งานฟีเจอร์ Administrative shares ได้แก่ ADMIN$ (ใช้โดย PsExec), C$, D$ และ IPC$ ทั้งนี้องค์กรควรมีการประเมินความเสี่ยงก่อนดำเนินการเนื่องจากการจำกัดหรือปิดการใช้งานฟีเจอร์ดังกล่าวอาจส่งผลต่อการทำงานของระบบภายในองค์กร
จำกัดการใช้งานบัญชีผู้ใช้งานในระบบในกรณีที่มีการใช้งานเพื่อแพร่กระจายมัลแวร์
ตั้งค่าหากมีการใช้ Remote Desktop Protocol (RDP) โดยให้พิจารณาประเด็นดังต่อไปนี้

จำกัดการเข้าถึงจากอินเตอร์เน็ต หรือในกรณีที่จำเป็นต้องมีการเข้าถึง ให้ทำการกำหนดหมายเลขไอพีแอดเดรสที่สามารถเข้าถึงได้ผ่าน Windows Firewall
พิจารณาใช้งาน Multi-factor authentication ทั้งในรูปแบบของการใช้งาน Remote Desktop Gateway หรือเทคโนโลยีอื่นๆ ที่เกี่ยวข้อง
จำกัดสิทธิ์และการจำกัดบัญชีผู้ใช้งานที่สามารถเข้าถึงระบบจากระยะไกลผ่านโปรโตคอล
ในกรณีที่จำเป็นต้องมีการเข้าถึงและใช้งาน Remote Desktop Protocol (RDP) จากอินเตอร์เน็ต ให้พิจารณาใช้งาน Network Leveal Authentication (NLA) เพื่อป้องกันการโจมตีในรูปแบบของการเดาสุ่มรหัสผ่าน ทั้งนี้หากมีการใช้งาน NLA ควรตรวจสอบให้แน่ใจว่าระบบที่มีการเชื่อมต่อนั้นรองรับการใช้งาน และไม่ควรใช้ฟีเจอร์ CredSSP เพื่อป้องกันการบันทึกข้อมูลสำหรับยืนยันตัวตนไว้ในหน่วยความจำของระบบ

ทำการตั้งค่า Group Policy เพื่อควบคุมสิทธิ์ในการใช้ตามความเหมาะสม อาทิ ทำการตั้งค่าเพื่อป้องกันการเข้าถึงข้อมูลสำหรับยืนยันตัวตนที่ไม่ได้ถูกปกป้องในหน่วยความจำผ่านทาง Group Policy หรือการตั้งค่ารีจิสทรี รวมไปถึงดำเนินการตั้งค่าที่เกี่ยวข้องกับความแข็งแกร่งของรหัสผ่านของบัญชีผู้ใช้งานใน Group Policy
ติดตั้งซอฟต์แวร์ป้องกันมัลแวร์บนเครื่องในองค์กรทุกเครื่อง และอัปเดตข้อมูลและเวอร์ชั่นของซอฟต์แวร์ให้เป็นปัจจุบันอยู่เสมอ
พิจารณาการใช้งานข้อมูลตัวบ่งชี้ภัยคุกคาม (Indicator of Compromise — IOC) ในการช่วยเฝ้าระวังและตรวจจับการมีอยู่ของภัยคุกคาม แหล่งข้อมูลซึ่งสามารถค้นหาข้อมูลตัวบ่งชี้ภัยคุกคามของ Maze มีตามรายการดังต่อไปนี้

ค้นหาข่าวและ IOC ทั้งหมดของ Maze ด้วย APT & Malware CSE
(แนะนำ) รายงานการวิเคราะห์พฤติกรรมของ Maze จาก FireEye
(แนะนำ) รายงานการวิเคราะห์การทำงานของไฟล์มัลแวร์ในปฏิบัติการ Maze โดย McAfee

คำแนะนำในการรักษาความปลอดภัยให้ Microsoft 365 จาก US-CERT

US-CERT ออกคำแนะนำในการรักษาความปลอดภัยให้กับการใช้งาน Microsoft 365 โดยแนะนำให้ปฏิบัติดังต่อไปนี้

เปิดการใช้งานการยืนยันตัวตนหลายปัจจัยให้กับบัญชีผู้ดูแลระบบ [1]
ใช้หลัก Least Privilege เพื่อป้องกันไม่ให้ Global Administrator ถูกโจมตีด้วยการสร้างบัญชีอื่นๆ แยกออกมาโดยให้สิทธิ์ที่จำเป็นเท่านั้น [2],[3]
เปิดการใช้งาน Audit Log โดย Audit Log จะเก็บเหตุการณ์ที่เกิดจากผลิตภัณฑ์ต่างๆ ในเครือ Microsoft 365 เช่น Exchange Online, SharePoint Online, OneDrive เป็นต้น [4]
ปิดการใช้งานอีเมลโปรโตคอลที่ล้าสมัยอย่าง POP3, IMAP หรือ SMTP [5]
เปิดการใช้งานการยืนยันตัวตนหลายปัจจัยให้กับบัญชีการใช้งานทั้งหมด
เปิดการใช้งานการแจ้งเตือนเหตุการณ์ผิดปกติ [6]
ส่ง log ของ Microsoft 365 ไปยัง SIEM ของค์กรเพื่อช่วยในการตรวจจับ [7]

ที่มา: https://www.

รวมแหล่งข้อมูลภัยคุกคาม (Threat Intelligence) ในสถานการณ์ COVID-19

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

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

ดังนั้นในบทความนี้ทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) จาก บริษัท ไอ-ซีเคียว จำกัด จะมาพูดถึงแหล่งข้อมูลภัยคุกคามที่เกี่ยวข้องกับการใช้ประโยชน์ของ COVID-19 ซึ่งสามารถนำไปปรับใช้ให้เกิดการตรวจจับและป้องกันภัยคุกคามได้อย่างมีประสิทธิภาพครับ

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

โครงการ littl3field/DodgyDomainsBot เป็นโครงการซึ่งนำผลลัพธ์จากสคริปต์ในการระบุหาโดเมนที่อาจมีส่วนเกี่ยวข้องกับภัยคุกคามที่ใช้สถานการณ์ COVID-19 มาเผยแพร่ โดยได้แยกส่วนของรายการที่ตรวจสอบแล้วและยังไม่ได้ตรวจสอบไว้อยู่ให้เลือกใช้งานได้
โครงการ Blacklist จาก COVID-19 Cyber Threat Coalition เป็นรายการโดเมนต้องสงสัยและเป็นอันตรายที่รวบรวมมาจากกลุ่ม Cyber Threat Coalition ซึ่งถูกตั้งขึ้นมาเฉพาะกิจเพื่อรับมือกับภัยคุกคามในช่วง COVID-19 โดยข้อมูลสามารถเข้าถึงได้ทั้งในรูปแบบของไฟล์เอกสาร หรือผ่าน API จาก AlienVault OTX
โครงการ COVID-19 Threat Bulletin จาก Anomali ซึ่งติดตามภัยคุกคามและการโจมตีต่างๆ ที่เกี่ยวข้องกับ COVID-19 พร้อมด้วยรายการ IOC กว่า 6,000 รายการที่สามารถนำไปใช้ได้ทันที
โครงการ COVID-19 Threat List จาก DomainTools เป็นลักษณะของรายการโดเมนที่เกี่ยวข้องกับภัยคุกคามในช่วง COVID-19 ในรูปแบบ CSV อัปเดตรายวัน
เหนือกว่า IOC ต้อง TTP โครงการ Hunting Notebook สำหรับ Azure Sentinel เพื่อระบุหาพฤติกรรมภัยคุกคามที่เกี่ยวข้องกับ COVID-19
โครงการ Corona Domain Data จาก Swimlane เป็นข้อมูลอัปเดตรายวันในรูปแบบ JSON และ TXT ซึ่งสามารถนำไปวิเคราะห์หรือใช้ต่อในการตรวจจับได้ทันที
โครงการ Coronavirus-Phishing-Yara-Rules จาก Cofense เป็นโครงการซึ่งรวบรวม Yara rule สำหรับการคัดแยกและตรวจจับลักษณะของข้อมูลใดๆ ที่อาจเกี่ยวข้องกับภัยคุกคามที่ใช้สถานการณ์ COVID-19
รายการโดเมนเนมจดทะเบียนใหม่ที่อาจเกี่ยวข้องกับ COVID-19 themed threat โดย Malware Patrol มีทั้งแบบ TXT, JSON, BIND RPZ Zone, Squid และ Snort
โครงการ Coronavirus Host Reputation Feed จาก @j0hn_f ซึ่งนำข้อมูลจาก F-Secure มาวิเคราะห์เพิ่มเติม มีการเพิ่มคะแนนความน่าเชื่อถือและแจกจ่ายในรูปแบบ JSON
Telemetry จาก apklab.

สรุปปัญหาความปลอดภัยและความเสี่ยงใน Zoom

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

อย่างไรก็ตาม Security ที่ดีไม่ควรเป็น Security ที่เกิดจากความหวาดระแวงอย่างไม่สมเหตุสมผล ดังนั้นในบทความนี้ ทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) จากบริษัท ไอ-ซีเคียว จำกัด จะมาสรุปข่าวที่เกิดขึ้น และความคิดเห็นของเราต่อความเสี่ยงเพื่อให้การจัดการความเสี่ยงนั้นเกิดขึ้นอย่างเหมาะสมครับ

หมายเหตุ: เราจะดำเนินการอัปเดตบทความนี้ให้มีความทันสมัยที่สุดเท่าที่จะทำได้เมื่อให้ผู้อ่านได้รับข้อมูลที่เป็นปัจจุบันมากที่สุด

 
สารบัญ (อัปเดตล่าสุด 9 เมษายน 2020)

ปัญหาความเสี่ยงที่อนุญาตให้ผู้ไม่หวังดีค้นหาและสามารถเข้าร่วมการประชุมเพื่อก่อกวนการประชุมในรูปแบบที่ชื่อ “Zoombombing”
ช่องโหว่อนุญาตให้แฮกเกอร์ลักลอบเข้ามาเปิดเว็บแคมของผู้ใช้และไมโครโฟนของ Mac โดยไม่ได้รับอนุญาตด้วยการหลอกให้ผู้ใช้เข้าไปเยี่ยมชมเว็บไซต์ที่เป็นอันตราย
Zoom ถูกฟ้องร้องว่าแอบเก็บข้อมูลผู้ใช้และส่งให้ข้อมูลกลับไปหา Facebook
Zoom ไม่มีการเข้ารหัสแบบ End-to-End Encrypted (E2EE)
ความเสี่ยงผู้ใช้ Zoom อาจพบบุคคลอื่นที่ไม่รู้จักและสามารถดูข้อมูลที่อยู่, อีเมลและรูปถ่ายจากรายชื่อผู้ติดต่อภายใต้โดเมนอีเมลที่ใช้
ช่องโหว่บน Zoom สามารถขโมย Windows Credentials ได้
Zoom เเสดงข้อมูลและรูปโปรไฟล์ที่ถูกปกปิดใน LinkedIn
นักวิจัยเผย Zoom ส่งทราฟฟิกวิดีโอคอลผ่านจีน ฝั่ง Zoom แจงเป็นศูนย์ข้อมูลสำรอง

ปัญหาความเสี่ยงที่อนุญาตให้ผู้ไม่หวังดีค้นหาและสามารถเข้าร่วมการประชุมเพื่อก่อกวนการประชุมในรูปแบบที่ชื่อ “Zoombombing”
ระดับความเสี่ยง
สามารถทำให้ผู้ไม่หวังดีใช้ Meeting ID การประชุมเข้าร่วมการประชุมโดยไม่ได้รับอนุญาติ และก่อกวนการประชุมด้วยวิธีการต่างๆ
สถานะการแก้ไข
ดำเนินการแก้ไขเรียบร้อยวันที่ 7 เมษายน 2020 โดย Zoom เวอร์ชั่น 4.6.10 (20033.0407)
รายละเอียด
ความเสี่ยงนี้เกิดจากผู้ไม่หวังดีได้รับ Meeting ID การประชุม หรือค้นหาจากเเหล่งสาธารณะหรือรูปการประชุมที่มองเห็น Meeting ID ผู้ไม่หวังดีสามารถทดลองเข้าร่วมการประชุมได้โดยใช้ Meeting ID โดยไม่ต้องรับเชิญ ถ้าผู้สร้างห้องประชุมไม่ทำการใส่รหัสห้องประชุม และก่อกวนด้วยวิธีการต่างๆ เช่นส่งเสียงรบกวนหรือเปิดกล้องเพื่อแสดงร่างกายเปลือย, ส่งภาพอนาจาร, ภาพที่น่าเกลียดหรือคำพูดที่ไม่สุภาพเพื่อทำลายการประชุม
Reference:

https://support.

Online Meeting Security Checklist – รวมขั้นตอนการตั้งค่าความปลอดภัยให้กับการประชุมออนไลน์

เนื่องจากการระบาดของโรค Coronavirus หรือ COVID-19 แอปพลิเคชั่นการประชุมทางวิดีโอ Zoom ได้กลายเป็นแอปพลิเคชั่น ที่ได้รับความนิยมในการติดต่อสื่อสารกับเพื่อนและครอบครัว หรือแม้แต่การทำงานร่วมกับเพื่อนร่วมงานในองค์กรต่างๆ ทั่วโลก

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

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

1. อย่าเปิดเผย Personal Meeting ID หรือ Meeting ID ให้ใครรู้
ผู้ใช้ Zoom ทุกคนจะได้รับ "Personal Meeting ID" (PMI) ที่เชื่อมโยงกับบัญชี ถ้าหากให้ PMI กับบุคคลอื่นๆ หรือ PMI หลุดไปสู่สาธารณะ ผู้ไม่หวังดีจะสามารถทำการตรวจสอบว่ามีการประชุมอยู่หรือไม่ และอาจเข้ามาร่วมประชุมหรือก่อกวนได้หากไม่ได้กำหนดรหัสผ่าน
2. ใส่รหัสผ่านในการประชุมทุกครั้ง
เมื่อทำสร้างการห้องประชุมใหม่ Zoom จะเปิดใช้งานการตั้งค่า "Require meeting password" โดยอัตโนมัติและกำหนดรหัสผ่านแบบสุ่ม 6 หลัก และไม่ควรยกเลิกการตั้งค่านี้เนื่องจากจะทำให้ทุกคนหรือผุ้ก่อกวนสามารถเข้าถึงการประชุมได้โดยไม่ได้รับอนุญาต
3. สร้างห้อง Waiting Room
Zoom สามารถเปิดใช้งานฟีเจอร์ Waiting Room เพื่อป้องกันผู้ใช้เข้าสู่การประชุมโดยไม่ได้รับการยอมรับจากโฮสต์ (ผู้ที่สร้างการประชุม) ก่อนได้รับอนุญาต
4. ไม่ควรอนุญาตให้มีการ Join Before Host
ผู้ที่สร้างการประชุมควรควบคุมและหมั่นตรวจสอบผู้ที่เข้าร่วมการประชุมอยู่เสมอว่าเป็นผู้ที่ได้รับอนุญาตจริงหรือไม่โดยเฉพาะอย่างยิ่งในการประชุมในเรื่องประเด็นที่ออนไหว การตั้งค่า Enable waiting room เป็นค่าเปิดจะส่งผลให้ผู้ที่เข้าถึงคนแรกกลายเป็นโฮสต์และมีสิทธิ์ในการควบคุมเรียกดูข้อมูลของผู้เข้าร่วมการประชุมโดยอัตโนมัติโดยอัตโนมัติ ดังนั้นตัวเลือกของ Enable waiting room จึงไม่เคยถูกเปิดใช้งานโดยไม่จำเป็น
5. ปิดการแชร์หน้าจอของผู้เข้าร่วม

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

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

ตัวอย่างเช่น นายกรัฐมนตรีสหราชอาณาจักร บอริส จอห์นสัน ทวีตรูปภาพการประชุมของ "คณะรัฐมนตรี” และในภาพที่พบมีเลข Meeting ID ของการประชุมปรากฏอยู่ สิ่งนี้อาจจะถูกใช้โดยผู้โจมตีเพื่อพยายามเข้าถึงการประชุมโดยไม่ได้รับอนุญาต และสามารถเข้าร่วมได้ผ่าน Meeting ID ที่แสดงได้
8. อย่าโพสต์ลิงค์การประชุมในที่สาธารณะ
เมื่อสร้างห้องประชุมผ่าน Zoom ไม่ควรโพสต์ลิงก์ที่จะไปยังการประชุมสู่สาธารณะ การกระทำเช่นนั้นจะทำให้เครื่องมือค้นหาเช่น Google จัดทำบันทึกและเปิดให้ค้นหาลิงค์ดังกล่าว และทำให้ทุกคนที่สามารถค้นหาลิงก์การประชุมสามารถเข้าถึงการประชุมได้ เนื่องจากการตั้งค่าเริ่มต้นใน Zoom คือการฝังรหัสผ่านในลิงค์คำเชิญ
9. ระวังมัลแวร์ที่แฝงมาในไฟล์ติดตั้ง Zoom
เนื่องจากการระบาดของโรค Coronavirus ที่เพิ่มขึ้นอย่างรวดเร็วได้มีการเเอบแฝงมัลแวร์ โดยกระจายผ่านเว็บไซต์ฟิชชิ่ง, อีเมล์ฟิชชิ่งและการโจมตีอื่น ๆ ที่เกี่ยวข้องกับข่าวการระบาด โดยมัลแวร์ที่ถูกสร้างขึ้นและแฝงไปกับไฟล์การติดตั้งแอพพลิเคชั่น Zoom เพื่อความปลอดภัยโปรดตรวจสอบการดาวน์โหลดไคลเอนต์ แอพพลิเคชั่น Zoom ทุกครั้งที่ทำการดาวน์โหลด และดาวน์โหลดโดยตรงจากเว็บไซต์ https://zoom.

Microsoft เตือนภัยผู้ใช้ Windows ระวังตกเป็นเป้าหมายการโจมตีด้วยช่องโหว่ Zero-day

Microsoft ได้ออกประกาศเตือนความปลอดภัยในระบบปฏิบัติการ Windows หลังพบผู้บุกรุกใช้ 2 ช่องโหว่ zero-day ใหม่สามารถเรียกใช้การโจมตีระยะไกล (RCE) ในไลบรารี Adobe Manager

รายละเอียดช่องโหว่โดยย่อ
2 ช่องโหว่ zero-day ใหม่นี้อยู่ใน Adobe Type Manager Library (atmfd.

ทุกสิ่งที่คุณต้องรู้เกี่ยวกับช่องโหว่ CoronaBlue/SMBGhost (CVE-2020-0796)

อัปเดตล่าสุด: 16 March 2020, Afternoon
การเปลี่ยนแปลง: เพิ่มรายละเอียดกับการวิเคราะห์แบบ Post-mortem analysis

สืบเนื่องจากการเปิดเผยรายละเอียดของช่องโหว่โดย Cisco Talos เมื่อวันอังคารที่ผ่านมา ในวันที่ 10 มีนาคม 2020 Microsoft ได้เผยแพร่ ADV200005 คำแนะนำสำหรับช่องโหว่ RCE (Remote Code Execution) ใน Microsoft Server Message Block 3.1.1 (SMBv3) ซึ่งให้รายละเอียดและข้อมูลที่มากขึ้นเกี่ยวกับช่องโหว่ (CVE-2020-0796) ที่มีลักษณะ “Wormable” ในโปรโตคอล SMB โดยผู้โจมตีสามารถใช้ช่องโหว่เพื่อโจมตีจากระยะไกลและสามารถเเพร่กระจายเช่นเดียวกับกรณีของ CVE-2017-0143/0144 ที่ WannaCry Ransomware ใช้

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

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

รายละเอียดช่องโหว่โดยย่อ
CVE-2020-0796 หรือที่ถูกเรียกในอีกชื่อหนึ่งว่า Corona Blue และ SMB Ghost ช่องโหว่เป็นการโจมตีจากระยะไกลใช้ประโยชน์จากข้อผิดพลาดโดยการส่งแพ็คเก็ตที่ออกแบบมาเป็นพิเศษไปยังเซิร์ฟเวอร์ SMBv3 ที่เป็นเป้าหมายซึ่งเหยื่อจะต้องเชื่อมต่อด้วย โดยจากข้อมูลเบื้องต้นนั้น ช่องโหว่นี้เกิดจากปัญหา Buffer overflow ในส่วนที่มีการบีบอัดข้อมูล นอกจากนี้ช่องโหว่จะทำให้การโจมตีแบบ “Wormable” หรือมัลแวร์ชนิดต่างๆ สามารถแผ่กระจายไปบนคอมพิวเตอร์ไคลเอนต์ของเหยื่อได้ง่ายและยากต่อการป้องกัน

อ้างอิงจาก CERT/CC ช่องโหว่นี้ถูกประเมินด้วยคะแนน CVSSv2 แบบ Base score 10 คะแนนเต็ม โดยมีคะแนน Temporal score ซึ่งเกี่ยวข้องกับความเป็นไปได้ในการโจมตีและการลดผลกระทบ 8.1 คะแนน เช่นเดียวกับ Environmental score

ในวันที่ 13 มีนาคม 2020 หลังจากที่ไมโครซอฟต์ได้มีการปล่อยแพตช์ของช่องโหว่นี้ออกมา นักวิจัยด้านความปลอดภัยจาก Synacktiv ก็ได้เปิดเผยบล็อกการวิเคราะห์ช่องโหว่ตามไปทันที ทีมตอบสนองการโจมตีและภัยคุกคามได้ทำการวิเคราะห์แพตช์ที่เกิดขึ้นในไฟล์ srv2.sys และยืนยันตามประเด็นที่ Synacktiv เสนอได้แก่

ฟังก์ชันที่มีค่า Similarity ต่ำหรือทุก Change ไปเยอะมากในไฟล์ srv2.sys คือฟังก์ชัน SmbDecompressData
ในฟังก์ชันดังกล่าว จุดที่เปลี่ยนไปมากที่สุดคือการเพิ่มกระบวนการตรวจสอบก่อนการเรียกใช้ฟังก์ชัน SrvNetAllocateBuffer ซึ่งจะถูกเรียกขึ้นมาไว้ในการจองพื้นที่หน่วยความจำเพื่อรองรับการ decompress ข้อมูล
ในรูปทางด้านซ้ายซึ่งเป็นซอร์สโค้ดของไฟล์ srv2.sys ที่ยังไม่ถูกแพตช์ ฟังก์ชัน SrvNetAllocateBuffer จะทำการนำค่า OriginalCompressedSegmentSize และ OffsetOrLength มาใช้เพื่อประเมินหน่วยของความจำที่จะจอง
เนื่องจากสองค่านี้เป็นค่าที่ผู้ใช้งานสามารถควบคุมได้ ผู้ใช้งานสามารถควบคุมทั้งสองค่าให้เกิด Integer overflow เมื่อมีการหาส่วนต่าง และทำให้ SrvNetAllocateBuffer ต้องจอง buffer ขนาดใหญ่เกินจริงจนกลายเป็น BSOD "PAGE_FAULT_IN_NON_PAGED_AREA" ได้
ช่องโหว่ Integer overflow สามารถนำไปใช้ในการพัฒนาต่อเป็น Remote code execution ได้ ทั้งนี้ผู้โจมตีจะต้องทำการพัฒนาโค้ดเพื่อ bypass ฟีเจอร์ Exploit mitigation อีกมากมายในทำให้ได้มาซึ่ง RCE ด้วย

บริษัทรักษาความปลอดภัยทางไซเบอร์ Kryptos Logic ได้กล่าวว่ามีโฮสต์ประมาณ 48,000 รายทั่วอินเทอร์เน็ตที่มี Port เปิดการเชื่อมต่อผ่านอินเทอร์เน็ตผ่านโปรโตคอล SMB และมีความเสี่ยงต่อการถูกโจมตีโดยใช้จุดบกพร่องนี้ และได้ทำการเเชร์คลิปการการทดสอบโจมตีนี้ด้วย
การโจมตีช่องโหว่
ในขณะนี้ยังไม่พบการใช้ช่องโหว่นี้การโจมตี หรือการปรากฎของโค้ดสำหรับโจมตีและโค้ด POC ใดๆ ทั้งนี้เราตรวจพบสคริปต์สำหรับการใช้ระบุหาช่องโหว่แล้ว โดยในเบื้องต้นนั้นสคริปต์เหล่านี้ดำเนินการตรวจสอบเพียงแค่รุ่นของเซิร์ฟเวอร์ตามรายละเอียดในเบื้องต้นของช่องโหว่เท่านั้น
ระบบที่ได้รับผลกระทบ
รุ่นของระบบที่ได้รับผลกระทบจากช่องโหว่มีตามรายการดังต่อไปนี้

Windows 10 Version 1903 for 32-bit Systems
Windows 10 Version 1903 for ARM64-based Systems
Windows 10 Version 1903 for x64-based Systems
Windows 10 Version 1909 for 32-bit Systems
Windows 10 Version 1909 for ARM64-based Systems
Windows 10 Version 1909 for x64-based Systems
Windows Server, version 1903 (Server Core installation)
Windows Server, version 1909 (Server Core installation)

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

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

อัปเดตวันที่ 13 มีนาคม 2563: ไมโครซอฟต์ได้ดำเนินการปล่อยแพตช์รหัส KB 4551762 เพื่อปิดช่องโหว่นี้แล้ว โดยแพตช์จะเพิ่มกระบวนการตรวจสอบค่าในส่วนของโปรแกรมที่มีช่องโหว่ นี่คือวิธีที่ดีที่สุดในการป้องกันการถูกโจมตีโดยช่องโหว่นี้และเราแนะนำเป็นอย่างยิ่งให้ดำเนินการแพตช์โดยทันที (ดาวโหลดแพตช์ได้จากที่นี่)
ในมุมของการ Hardening มีการปล่อยไฟล์ ADMX ซึ่งจะเพิ่มตัวเลือกใน Group Policy ให้สามารถปิดฟีเจอร์ SMB Compression ได้ (ดูเพิ่มเติม)
คำแนะนำของ Microsoft คือให้ทำการติดตั้งการปรับปรุงช่องโหว่นี้ทันทีที่ออก Patch ป้องกัน เบื้องต้นเราสามารถปิดใช้งานกระบวนการบีบอัดซึ่งคาดว่าจะเกี่ยวข้องกับช่องโหว่เพื่อ Block ผู้โจมตีที่ไม่ได้รับอนุญาตจากการโจมตีช่องโหว่จากเซิร์ฟเวอร์ SMBv3 ด้วยคำสั่ง PowerShell ด้านล่าง

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force

เนื่องจาก SMB เป็นโปรโตคอลที่ส่วนใหญ่จะใช้กันในองค์กร ทาง Microsoft จึงแนะนำให้ Block Traffic ขาเข้าและขาออกสำหรับเครือข่ายภายนอกบน Port TCP 445 บน Firewall ในองค์กรเพื่อป้องกันเครือข่ายและจะช่วยปกป้องระบบที่อยู่หลัง Firewall จากความพยายามโจมตีช่องโหว่นี้ เป็นวิธีการป้องกันที่ดีที่สุดเพื่อช่วยหลีกเลี่ยงการโจมตีทางอินเทอร์เน็ต อย่างไรก็ตามระบบยังอาจเสี่ยงต่อการถูกโจมตีจากภายในองค์กรอยู่ (ดูเพิ่มเติมวิธีการ Block Port TCP 445 ออกจากเครื่องเซิร์ฟเวอร์องค์กร)

การวิเคราะห์ระบบที่คาดว่าถูกโจมตีโดยช่องโหว่
หลังจากที่ไมโครซอฟต์ได้มีการปล่อยแพตช์สำหรับช่องโหว่นี้ออกมา พร้อมกับรายงานการวิเคราะห์ช่องโหว่จากผู้เชี่ยวชาญด้านความปลอดภัย ในวันที่ 14 มีนาคม 2020 นักวิจัยด้านความปลอดภัย eerykitty ได้มีการเปิดเผยโค้ดสำหรับโจมตีช่องโหว่ดังกล่าวซึ่งส่งผลให้ระบบเกิดการ Crash และเหตุการณ์ Blue Screen of Death (BSOD) ในมุมมองของทีมตอบสนองการโจมตีและภัยคุกคาม แม้ว่าผลกระทบจากช่องโหว่ในเวลานี้จะทำให้ระบบสูญเสียได้เพียงความพร้อมในการใช้งาน (Availability) แต่การสูญเสียเพียงความพร้อมในการใช้งานหรือให้บริการก็ส่งผลให้คุณลักษณะที่ทำให้เกิดความมั่นคงปลอดภัยของระบบนั้นไม่สมบูรณ์ได้

ในประเด็นนี้ทีมตอบสนองการโจมตีและภัยคุกคามจะมาสรุปสิ่งที่เราค้นพบในรูปแบบของ Post-mortem analysis ซึ่งสามารถใช้ในการประเมินความปลอดภัยระบบในลักษณะของ Compromised assessment และการช่วยระบุหาต้นตอความผิดปกติหากสงสัยว่าระบบอาจถูกโจมตีด้วยช่องโหว่ CVE-2020-0796 ได้

เราทำการจำลองระบบที่ใช้ในการทดสอบโดยทำการติดตั้งระบบ Windows 10 Enterprise รุ่น 1903 ที่ยังไม่ถูกแพตช์ โดยระบบไม่มีการตั้งค่าหรือติดตั้งโปรแกรมใดๆ เพิ่มเติม การระบุหาตัวบ่งชี้ภัยคุกคาม (Indicator of compromise) จะดำเนินการบนข้อมูลที่ระบบสร้างหรือบันทึกเป็นค่าเริ่มต้นเท่านั้น เพื่อให้ข้อมูลที่สามารถใช้ยืนยันการโจมตีได้ครอบคลุมกับระบบที่มีอยู่ทั่วไปในโลกมากที่สุด

โครงการ eerykitty/CVE-2020-0796-PoC มีการนำแก้ไขการทำงานของไลบรารี smbprotocol เพื่อให้รองรับการทำงานกับฟีเจอร์ compression ใน SMB รุ่น 3.1.1 โดยเพื่อทำการ overflow พื้นที่ในหน่วยความจำ ผู้พัฒนาได้มีการกำหนดค่า OffsetOrLength ในเฮดเดอร์ให้มีค่าเป็น 0xffffffff ไว้ในโค้ดของ smbprotocol อยู่แล้ว

เมื่อระบบที่มีช่องโหว่รับแพ็คเกตจากสคริปต์ที่ใช้โจมตี ระบบจะเกิดการ Crash และจะแสดงอาการ Blue screen of death ด้วย Stop code คือ PAGE_FAULT_IN_NON_PAGED_AREA โดย Stop code มักเกิดจากปัญหาการอ้างอิงข้อมูลในหน่วยความจำที่ไม่ถูกต้องจนทำให้ระบบไม่สามารถทำงานได้

การยืนยันว่ามีการใช้สคริปต์ดังกล่าวหรือสคริปต์ที่มีลักษณะใกล้เคียงกันในการทำ DoS กับระบบที่มีช่องโหว่สามารถตรวจสอบได้ตามประเด็นดังต่อไปนี้

ตรวจสอบ Event log ของระบบโดยให้ระบุหา EID41 Kernel-Power ใน System log ซึ่งระบุการรีสตาร์ทของระบบแบบผิดปกติและ EID1001 BugCheck ใน System log ที่ช่วงเวลาใกล้เคียงซึ่งจะระบุว่าระบบเกิดปัญหาจาก "บั๊ก" ของโปรแกรมบางอย่างจนต้องมีการรีสตาร์ท ในกรณีทั่วไประบบจะมีการบันทึกข้อมูลในหน่วยความจำไว้ในลักษณะ Memory dump ซึ่งสามารถใช้ในการระบุหาที่มาของข้อผิดพลาดได้อีกด้วย
ทำการตรวจสอบไฟล์ MEMORY.DMP ด้วย Dumpchk หรือ Windbg โดยในกรณีที่ระบบถูกโจมตีด้วย CVE-2020-0796 นั้น ลักษณะของ Call stack จะปรากฎตามรูปด้านบนซึ่งมีสาเหตุมาจากการพยายามใช้พื้นที่ของหน่วยความจำที่ถูกจองขึ้นมาผิดพลาด

เนื่องจากข้อจำกัดที่จำเป็นต้องใช้ private symbol ในการวิเคราะห์ ข้อมูลที่เกี่ยวข้องกับฟังก์ชัน srvnet!SmbCompressionDecompress เช่น พารามิเตอร์หรือตัวแปรของฟังก์ชันจึงไม่สามารถระบุได้ยอย่างชัดเจน

ระบุหาข้อมูลเครือข่ายที่เกี่ยวข้องกับพอร์ต 445 และมีเป้าหมายมายังระบบที่เกิดความผิดปกติในช่วงเวลาใกล้เคียงกัน เราพบว่าหลังจากที่มีการสั่งโจมตี ระบบจะใช้เวลา 1-2 วินาทีก่อนจะมีการ Crash เกิดขึ้น
ยืนยันว่าระบบที่เกิดความผิดปกตินั้นขาดซึ่งการติดตั้งแพตช์และมีการเปิดใช้งานฟีเจอร์ที่เกี่ยวข้องกับการเกิดขึ้นของช่องโหว่จริง

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

https://securityaffairs.

รู้จัก Business Email Compromise (BEC) การโจมตีผ่านอีเมลเพื่อหลอกเอาเงินจากองค์กร

ในช่วงนี้ข่าวที่เป็นที่จับตามองข่าวหนึ่งคือข่าวของบริษัท สตาร์ ปิโตรเลียม รีไฟน์นิ่ง จำกัด (มหาชน) หรือ SPRC ระบุในงบการเงินประจำไตรมาส 4 ปี 2562 ว่าค่าใช้จ่ายในการบริหารในช่วงดังกล่าวเพิ่มขึ้นเป็น 31 ล้านดอลลาร์สหรัฐฯ จาก 8 ล้านดอลลาร์สหรัฐฯ (ส่วนต่างคือ 23 ล้านดอลลาร์สหรัฐฯ ประมาณ 690 ล้านบาท) โดยเพิ่มมาจากการถูกโจมตีธุรกรรมทางอีเมลในช่วงปลายปีที่ผ่านมา ทำให้มีการชำระเงินไปยังบัญชีที่ไม่ถูกต้อง หลังเกิดเหตุการณ์บริษัทได้ดำเนินการร่วมกับผู้เชี่ยวชาญด้านไอทีทั้งภายในและภายนอกทันทีในการตรวจสอบหาสาเหตุและได้เพิ่มระบบป้องกันภายในให้แข็งแกร่งมากขึ้น โดย SPRC ยังคงทำงานร่วมกับหน่วยงานที่เชี่ยวชาญในการเรียกคืนค่าเสียหายดังกล่าว แต่ได้มีการรับรู้ค่าเสียหายในงบการเงินในไตรมาส 4/2562 ไว้ก่อน

 

 

ในปัจจุบันนี้ยังไม่มีรายละเอียดเชิงลึกโดยตรงว่า SPRC ถูกโจมตีแบบใด แต่ถ้าวิเคราะห์บริบทในรายงานดังกล่าวว่าเกิดจากการ “ถูกโจมตีธุรกรรมทางอีเมลจนสูญเสียรายได้” ลักษณะดังกล่าวจะไปตรงกับการโจมตีที่มีชื่อเรียกว่า Business Email Compromise (BEC) หรือในบางครั้งอาจถูกเรียกว่า Email Account Compromise (EAC)

 

 

ในบทความนี้ทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) จาก บริษัท ไอ-ซีเคียว จำกัดจะมานำเสนอรายละเอียดเกี่ยวกับการโจมตีแบบ Business Email Compromise (BEC) เพื่อให้องค์กรเตรียมรับมือค่ะ

 
Business Email Compromise (BEC) คืออะไร
Business Email Compromise (BEC) หมายถึงการโจมตีผ่านอีเมลเพื่อหลอกให้สูญเสียรายได้ผ่านทางอีเมล เป็นลักษณะของการทำ Social Engineering โดยนอกเหนือจากการหลอกลวงทางอีเมลแล้วอาจมีการใช้วิธีเพิ่มเติมเพื่อเร่งรัดให้เหยื่อตกใจและรีบดำเนินการเพิ่มเติมด้วยการโทรศัพท์ ซึ่งสถิติจาก FBI ระบุว่ามีการโจมตีในรูปแบบดังกล่าวเริ่มตั้งแต่ปี 2013 โดยทาง FBI ได้ยกตัวอย่างสถานการณ์การโจมตีแบบ BEC ไว้ 5 สถานการณ์ดังต่อไปนี้

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

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

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

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

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

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

 
ข้อมูลที่น่าสนใจเกี่ยวกับ BEC
รายงานเกี่ยวกับสถานการณ์ภัยคุกคามทางอีเมลใน Q2 2019 ของ FireEye ระบุว่าภัยคุกคามทางอีเมลมีมัลแวร์มาด้วยแค่ 14% ส่วนอีก 86% ไม่มีมัลแวร์ แต่เป็นภัยคุกคามประเภทอื่นๆ อย่างอีเมลปลอมเป็น CEO (CEO fraud) , อีเมลปลอมตัวเป็นคนอื่น และ spear phishing โดยมีอีเมลในรูปแบบ Business Email Compromise (BEC) เพิ่มขึ้น 25%

 

 

FBI's 2019 Internet Crime Report รายงานล่าสุดของ FBI ที่เพิ่งออกเมื่อช่วงต้นเดือนกุมภาพันธ์ 2020 ระบุว่าจากการแจ้งความเกี่ยวกับการโจมตีทางไซเบอร์ทั้งหมด 467,361 รายการ คิดเป็นการสูญเสียเงินกว่า 3.5 พันล้านดอลลาร์สหรัฐ โดยกว่าครึ่งหนึ่งของการสูญเสียเงิน (1.77 พันล้านดอลลาร์สหรัฐ) เกิดจากการโจมตีในรูปแบบของ BEC

 

 

องค์การตำรวจอาชญากรรมระหว่างประเทศ (INTERPOL) ออกรายงานสรุปภัยคุกคามทางไซเบอร์ในภูมิภาคอาเซียนเมื่อวันที่ 17 กุมภาพันธ์ 2020 ระบุว่าในภูมิภาคอาเซียนนี้ถูกโจมตีในลักษณะของ BEC คิดเป็น 5% ของทั้งโลก

 

 

INTERPOL ระบุว่าการถูกโจมตีแบบ BEC มักไม่ถูกรายงานเพราะองค์กรกลัวเสียชื่อเสียง ทำให้ไม่สามารถวิเคราะห์ข้อมูลความสูญเสียที่แท้จริงและแนวโน้มได้ รวมถึงการตามเงินคืนจาก BEC มักเจอทางตันเมื่อเจอกระบวนการฟอกเงิน เฉลี่ยแล้วการโจมตี BEC ที่สำเร็จจะได้เงินราวๆ 130,500 ดอลลาร์สหรัฐ (ประมาณ 4 ล้านบาท)

INTERPOL วิเคราะห์ว่าการโจมตีแบบ BEC จะไม่หายไปในเร็วๆ นี้อย่างแน่นอน เพราะลงทุนน้อยแต่ได้เงินมาก ผู้โจมตีที่หลอกลวงแบบอื่นๆ ต่างหันมาโจมตีแบบ BEC และไม่โจมตีแบบหว่านแห เน้นไปทาง targeted attack เพื่อหวังผล

 

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

ผู้โจมตีเริ่มโจมตีด้วยการทำ Phishing เพื่อหลอกเอาบัญชีผู้ใช้และรหัสผ่านอีเมลของบุคคลในองค์กรไป
ผู้โจมตีเข้าถึงอีเมล ฝังตัว และติดตามอ่านอีเมลของเหยื่อเพื่อหาช่องทางในการโจมตี โดยอาจมีการค้นหาด้วยคำค้นที่บ่งบอกถึงการทำธุรกรรมทางการเงินอย่าง invoice, PO, Purchase Order, statement เป็นต้น รวมถึงอาจมีการ forward อีเมลที่มีคำค้นดังกล่าวไปยังอีเมลของผู้โจมตี
ในกรณีที่ผู้โจมตีพบว่าไม่สามารถใช้ประโยชน์จากบัญชีอีเมลของเหยื่อได้ ผู้โจมตีจะหาวิธีส่ง phishing ภายในรายชื่อผู้ติดต่อทางอีเมลทั้งหมดเพื่อหาเหยื่อรายอื่นๆ ซึ่งองค์กรอาจรู้ตัวในขั้นนี้
ในกรณีที่ผู้โจมตีสามารถหาช่องทางใช้ประโยชน์จากอีเมลของเหยื่อรายนี้ได้ เช่น ทราบว่าเหยื่อเป็นผู้ที่มีอำนาจในการจัดซือ ผู้โจมตีจะเข้ามาอ่านอีเมลของเหยื่อเป็นระยะเพื่อหาโอกาส
เมื่อสบโอกาสพบว่าเหยื่อกำลังซื้อสินค้าและได้รับอีเมลขาเข้าที่พูดถึงให้การโอนเงินไปเพื่อทำธุรกรรมกับคู่ค้าผู้โจมตีจะทำการลบอีเมลที่ส่งเลขบัญชีจริงมา แล้วส่งอีเมลปลอมเข้ามายังอินบ็อกเพื่อเปลี่ยนเลขบัญชีเป็นเลขบัญชีของผู้โจมตี
เหยื่อโอนเงินไปยังบัญชีปลอม ทำให้ผู้โจมตีได้เงินทั้งหมดไป
เหยื่อรู้ตัวว่าโอนเงินไปยังบัญชีปลอมเมื่อคู่ค้าทวงถามถึงเงินค่าสินค้า

แนวทางการป้องกันและรับมือการโจมตี BEC ในลักษณะดังกล่าว
จากตัวอย่างเหตุการณ์ที่ยกขึ้นมานี้ สามารถแบ่งออกเป็นสามส่วน ดังนี้

ผู้โจมตีเข้าถึงอีเมลได้
เตรียมตัวโอนเงิน
เมื่อโอนเงินไปแล้วพบว่าตกเป็นเหยื่อ

เราสามารถป้องกันการเข้าถึงอีเมลของผู้โจมตีได้โดย

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

เราสามารถเพิ่มความระมัดระวังในการเตรียมตัวโอนเงินเพื่อป้องกันการโอนเงินไปยังบัญชีที่ผิดได้โดย

ตรวจสอบและยืนยันข้อมูลบัญชีปลายทาง
ตรวจสอบชื่อผู้ส่งอีเมลเมื่อจะทำการโอนเงิน
เพิ่มกระบวนการตรวจสอบอีเมลขาเข้า ตั้งค่าอีเมลให้ถูกต้อง (SPF,DKIM,DMARC) เพื่อป้องกันการได้รับอีเมลปลอม
เพิ่มกระบวนการตรวงสอบการเปลี่ยนแปลงบัญชี เช่น ขอหนังสือรับรองการเปลี่ยนบัญชีอย่างเป็นทางการ

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

กระบวนการโอนเงินเกิดขั้นในลักษณะใด สามารถ recall กลับมาได้หรือไม่?
ตรวจสอบทางเลือกในการระบุหายอดที่โอนและขอ freeze account
องค์กรมีความคุ้มครองในกรณีที่เกิดขึ้นหรือไม่ เช่น มีสินไหมทดแทนที่ช่วยลดความเสียหายได้

แหล่งความรู้เพิ่มเติม

Seven ways to spot a business email compromise in Office 365 https://expel.