Sophos ได้ทำการเผยแพร่แพตช์ความปลอดภัยฉุกเฉินเพื่อแก้ไขช่องโหว่ Zero-day ในผลิตภัณฑ์ XG Firewall ที่ถูกแฮกเกอร์ใช้ประโยช์จากช่องโหว่ขโมยรหัสผ่านบนอุปกรณ์ XG Firewall

Sophos กล่าวว่าพวกเขาได้รับรายงานจากลูกค้ารายหนึ่ง ในวันพุธที่ 22 เมษายนหลังจากลูกค้าพบค่าฟิลด์ที่น่าสงสัยปรากฏในระบบการจัดการ หลังจากทำการตรวจสอบพวกเขาระบุว่าค่าฟิลด์ที่น่าสงสัยนั้นเป็นการโจมตีที่ใช้ช่องโหว่ SQL injection เพื่อขโมยรหัสผ่านบนอุปกรณ์ XG Firewall

Sophos กล่าวว่าแฮกเกอร์ได้ใช้ช่องโหว่ดังกล่าวเพื่อโจมตีอุปกรณ์ XG Firewall ในส่วนการจัดการ Administration หรือ User Portal control panel ที่เปิดให้ทำการจัดการผ่านอินเตอร์เน็ต และยอมรับว่าแฮกเกอร์ใช้ช่องโหว่ SQL injection เพื่อดาวน์โหลดข้อมูลบนอุปกรณ์และคาดว่าข้อมูลที่ถูกขโมยออกไปนั้นอาจมีชื่อบัญชีผู้ใช้และรหัสผ่านที่ถูกเข้าด้วยฟังก์ชั่นแฮชของผู้ดูแลอุปกรณ์ไฟร์วอลล์, บัญชีผู้ใช้ผู้ดูแลระบบพอร์ทัลไฟร์วอลล์และบัญชีผู้ใช้ที่ใช้สำหรับการเข้าถึงอุปกรณ์จากระยะไกล

การอัพเดตความปลอดภัย

Sophos ได้ทำการส่งแพตช์อัพเดตความปลอดภัยฉุกเฉินนี้ไปยังอุปกรณ์ XG Firewalls ของผู้ใช้แล้ว โดยผู้ใช้ที่ตั้งค่า "Allow automatic installation of hotfixes" บนอุปกรณ์จะได้รับการอัพเดตอัตโนมัติ สำหรับผู้ใช้ที่ปิดใช้งานการตั้งค่านี้ผู้ใช้งานสามารถทำตามคำแนะนำดังต่อไปนี้ community.

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

เนื่องจากการระบาดของโรค 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.

อัปเดตล่าสุด: 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.

ในช่วงนี้ข่าวที่เป็นที่จับตามองข่าวหนึ่งคือข่าวของบริษัท สตาร์ ปิโตรเลียม รีไฟน์นิ่ง จำกัด (มหาชน) หรือ 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.

ANY.RUN เว็บไซต์ที่ให้บริการวิเคราะห์พฤติกรรมการทำงานของมัลแวร์ (Sandbox) ได้เผยแพร่ 15 อันดับของมัลแวร์ที่ถูกอัพโหลดเพื่อตรวจสอบเมื่อสัปดาห์ที่แล้ว โดยมี 3 อันดับแรก ดังต่อไปนี้

พบว่าอันดับ 1 ตกเป็นของ Agent Tesla มัลแวร์สาย Assassin ที่จะแฝงตัวเพื่อทำภารกิจสอดส่องพฤติกรรมการทำงานของผู้ใช้งาน และดักจับการพิมพ์ที่อาจเป็นรหัสผ่านบนเครื่องที่ตกเป็นเหยื่อ เมื่อสบโอกาสก็จะนำข้อมูลที่ได้ไปเผด็จศึก พบว่าไฟล์ของมัลแวร์อันดับต้นๆ ที่ถูกส่งมาตรวจสอบจะอยู่ในรูปแบบไฟล์ ZIP และ EXE ที่มีชื่อไฟล์เป็นพวกเอกสารการสั่งซื้อ เช่น Purchase Order (PO) หรือ Shipping Document เป็นต้น

(อย่างไรก็ตาม จากการตรวจสอบล่าสุด พบว่าโดน Emotet เตะลงมาแล้ว)

อันดับที่ 2 ตกเป็นของ Emotet มัลแวร์สาย Alchemist ที่พบว่ามีการเล่นแร่แปรธาตุมักจะสอดแทรกความสามารถใหม่ตลอดเวลา จากการที่พบว่ามัลแวร์ตระกูลนี้จะหลายเวอร์ชั่นมาก ตั้งแต่ที่มีการพบครั้งแรกเมื่อปี 2014 โดยหลักๆ ตัวมันเองจะเป็นมัลแวร์ตั้งต้น (dropper) เพื่อไปดาวน์โหลดพรรคพวกตัวอื่นๆ เข้ามาต่อไป พบว่าตัวอย่างไฟล์ที่ถูกส่งมาให้ตรวจสอบก็ยังคงเป็นไฟล์เอกสาร Microsoft Office ที่มีการฝัง Macro ไว้ และเอกสารปลอมที่มีนามสกุลเป็น EXE ด้วย

(จุดที่น่าสังเกตคือ ถ้าดูตามสถิติโดยรวมทั้งหมดและล่าสุดแล้ว พบว่า Emotet ถูกจัดว่าเป็นอันดับ 1 ที่ถูกพบมากที่สุด)

อันดับที่ 3 พบว่าเป็น LokiBot มัลแวร์สาย Thief ที่มีจุดหมายเพื่อแฝงตัวเข้ามาขโมยข้อมูลออกไปเป็นหลัก ไม่ว่าจะ Web Browsers, FTP, E-mail และแอพพลิเคชั่นอื่นๆ ที่มีการใช้งานอยู่บนเครื่อง ก็อีกเช่นเดียวกันตัวอย่างไฟล์ที่พบว่าถูกส่งขึ้นมาตรวจสอบ หนีไม่พ้นไฟล์เอกสาร Microsoft Office ที่มีชื่อไฟล์เป็นเอกสารที่เกี่ยวกับกระบวนการสั่งซื้อ เช่น Payment, Invoice และ Quotation เป็นต้น

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

คุณกำลังตกเป็นเป้าหมายของผู้ไม่หวังดีอยู่นะ !!! ระวังตัวมากๆ นะครับ

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

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

ในบทความนี้ทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) จาก บริษัท ไอ-ซีเคียว จำกัดจะขอพักการใช้ทักษะทางด้านเทคนิคของเรามาโฟกัสที่คำถามที่สำคัญสำหรับเหล่า Security Analyst, SOC Operator และ SOC Manager นั่นคือคำถามว่าปัจจัยใดที่มีผลต่อประสิทธิภาพในการทำงานของเรา และในขณะเดียวกันอะไรที่ทำให้เราไม่มีประสิทธิภาพ แล้วเราสามารถทำอะไรกับมันได้สำหรับปัญหาเหล่านี้

บทความนี้อ้างอิงเนื้อหาโดยส่วนใหญ่มาจากงานวิจัยชื่อ A Human Capital Model for Mitigating Security Analyst Burnout โดย Sathya Chandran และคณะ ซึ่งสามารถดาวโหลดงานวิจัยฉบับเต็มได้ตามลิงค์ที่แนบมาครับ
รายละเอียดการทำวิจัย
ในส่วนแรกของบทความนี้ เราขออธิบายรายละเอียดและที่มาของประเด็นและข้อเสนอที่จะถูกนำเสนอในหัวข้อต่างๆ โดยการพูดถึงกระบวนการทำวิจัย ตัวแปรและทฤษฎีที่สำคัญและข้อจำกัดของงานวิจัยนี้ครับ

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

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

ข้อมูลประจำวันที่ได้จากการบันทึกจะถูกนำมาประเมินผลด้วยทฤษฎี Grounded theory ซึ่งเป็นหลักทฤษฎีของการศึกษาปรากฎการณ์ทางสังคมเพื่อสร้างทฤษฎีหรือโมเดลมาอธิบายปัจจัยที่เกี่ยวข้องผ่านทางการให้เหตุผลแบบอุปนัย (Inductive reasoning) จากข้อมูลที่ทำการรวบรวมมา นิยามและคุณลักษณะจะถูกกำหนดให้กับข้อมูลก่อนจะถูกนำมาจับกลุ่มตามความสัมพันธ์ที่มีต่อกันระหว่างนิยาม

ตัวอย่างของข้อมูลที่ถูกเก็บรวบรวมมาจากนักวิจัยซึ่งทำงานกับร่วมกับทีม SOC เช่น
ในระหว่างที่ทำการวิเคราะห์เหตุการณ์ภัยคุกคาม ฉันได้ให้คำแนะนำแก่ Security analyst คนอื่นว่าเราควรลองเข้าถึงระบบ Domain controller เพื่อหาและเก็บข้อมูลที่สำคัญเพิ่มเติม อย่างไรก็ตาม Security analyst อีกคนหนึ่งกล่าวว่าการเข้าถึง Domain controller เป็นการกระทำที่มีความเสี่ยงเกินไปสำหรับ Security analyst
ตัวอย่างข้อมูลนี้จะถูกนิยามและให้คุณลักษณะไว้ว่าเป็นประเด็นที่เกี่ยวข้องกับความรับผิดชอบ (liability) และการถูกไม่ได้รับหรือถูกจำกัดสิทธิ์ที่ควรได้รับเพื่อดำเนินการอย่างใดอย่างหนึ่ง (restricted of empowerment) หลังจากนั้นด้วยข้อมูลและการให้นิยามอื่นๆ ที่แตกต่างกัน นิยามและคุณลักษณะจะถูกจับกลุ่มและรวบรวมให้กลายเป็นประเด็นใหญ่สุดท้ายเพื่อสร้างเป็นโมเดลในการอธิบายพฤติกรรมที่เกี่ยวข้องกัน

ส่วนของการเก็บข้อมูล ศึกษาข้อมูลและพัฒนาโมเดลเพื่ออธิบายพฤติกรรมของ Security analyst ถูกดำเนินการใน SOC ของบริษัททางด้านไอทีที่มีลักษณะของผู้ให้บริการในสหรัฐอเมริกา โดยผลลัพธ์โมเดลที่ได้จากการทำวิจัยนั้นถูกนำมาตรวจสอบกับ SOC ของมหาวิทยาลัยแห่งหนึ่งในสหรัฐฯ ซึ่งได้ผลลัพธ์ที่สอดคล้องกัน  ทังนี้รายละเอียดของบุคลากร SOC รวมไปถึงการแบ่งหน้าที่ เพศ และประสบการณ์ในการทำงานสามารถอ่านได้เพิ่มเติมจากในหัวข้อที่ 4 Fieldwork Setup และหัวข้อที่ 5 SOC Demography
ปัจจัยที่เกี่ยวข้องกับประสิทธิภาพการทำงานของ Security Analyst
ภายใต้งานวิจัยนี้นิยามปัจจัยที่เกี่ยวข้องกับประสิทธิภาพการทำงานของ Security analyst ตามแนวคิดเรื่องทุนมนุษย์ (Human capital) ซึ่งหมายถึงทรัพยากรที่คนหรือกลุ่มคนมี เช่น ความรู้และความเชี่ยวชาญ, ทักษะและประสบการณ์, ความคิดสร้างสรรค์และคุณสมบัติอื่นๆ ที่คนหรือกลุ่มคนพึงมี การที่ Security analyst สามารถสร้างและพัฒนาทุนมนุษย์ได้อย่างเหมาะสมสามารถการันตีความมีประสิทธิภาพของ SOC ในด้านกำลังคนได้

ทุนมนุษย์ของ Security analyst ถูกสร้าง รักษาและพัฒนาจาก 4 ปัจจัยหลัก โดยแต่ละปัจจัยจะมีความเกี่ยวข้องซึ่งกันและกันในมุมที่ว่าปัจจัยก่อนหน้ามีความจำเป็นต่อการมีอยู่และคุณภาพของปัจจัยต่อไป

ความสามารถ (Skills)
อำนาจและสิทธิ์ในการดำเนินการ (Empowerment)
ความสร้างสรรค์ (Creativity)
การพัฒนาและเติบโตของศักยภาพ (Growth)

เราสามารถใช้ 4 ปัจจัยนี้ในการอธิบายทุนมนุษย์ของ Security analyst ได้ดังนี้

Security analyst จะต้องมีความสามารถ (Skills) ที่ตรงกับสิ่งที่ทำรวมไปถึงมีศักยภาพที่เหมาะสม เนื่องจากงานของ SOC นั้นเกี่ยวข้องกับระบบของผู้อื่นรวมไปถึงการตัดสินใจ หากปราศจากซึ่งความสามารถที่เหมาะสมก็ย่อมแยกที่ Security analyst จะสามารถมีคุณลักษณะในขั้นต่อไปได้
เมื่อมีความสามารถที่เหมาะสมแล้ว Security analyst ควรจะได้รับอำนาจและสิทธิ์ในการดำเนินการ (Empowerment) ซึ่งรวมไปถึงการรับผิดชอบในหน้าที่ การมีอำนาจและสิทธิ์นี้สร้างช่องทางให้ Security analyst สามารถทำสิ่งใหม่หรือเสนอวิธีการใหม่ในการทำงานที่จะสร้างผลลัพธ์และเป็นโมเมนตัมในการทำงานและพัฒนาตนเองต่อไปได้ และยังนำไปสู่ประเด็นในเรื่องของความไว้เนื้อเชื่อใจด้วย
ด้วยการมีอำนาจและสิทธิ์ในการดำเนินงานตามความเหมาะสมเป็นใบเบิกทาง Security analyst จะได้รับสิทธิ์ในการที่จะสามารถรับมือและมีส่วนร่วมกับการแก้ปัญหากับสถานการณ์ใหม่ที่อยู่นอกเหนือจาก Procedure ที่ SOC มี การขาดซึ่งความสร้างสรรค์ (Creativity) ในการทำงานจะส่งผลให้เกิดความเบื่อหน่ายเมื่อต้องทำงานเดิมซ้ำๆ และทำให้โอกาสเกิดข้อผิดพลาดมีมากขึ้นด้วย
การได้รับโอกาสเพื่อทำสิ่งใหม่จะส่งผลให้เกิดการพัฒนาและเติบโตของศักยภาพ (Growth) และส่งผลให้ Security analyst รู้สึกประสบความสำเร็จและมีจุดมุ่งหมาย การพัฒนาและเติบโตของศักยภาพสามารถเกิดขึ้นได้จากการเรียนรู้จากผู้ที่มีประสบการณ์มากกว่าหรือผ่านทางการโยกย้ายหน้าที่ไปยังหน้าที่ที่เหมาะสมตามความสามารถ

อ้างอิงจากงานวิจัย โมเดลซึ่งเป็นผลลัพธ์จากการวิจัยได้อธิบายว่าความรู้สึก Burnout ของ Security analyst จะเกิดขึ้นเมื่อพวกเขาติดอยู่ ณ จุดใดจุดหนึ่งของปัจจัยเหล่านี้ไปเรื่อยๆ และไม่สามารถพัฒนาขึ้นไปได้

นอกเหนือจากปัจจัยเฉพาะบุคคลในเรื่องของทุนมนุษย์ งานวิจัยยังเสนอปัจจัยภายนอกอีก 3 ปัจจัยที่สามารถกระทบต่อปัจจัยในเรื่องของทุนมนุษย์ได้ ได้แก่

การทำงานแบบอัตโนมัติ (Automation) หากเกิดขึ้นก็สามารถช่วยงานซ้ำซ้อนใน SOC ได้และทำให้เกิดการทำงานร่วมกันระหว่างหลายฝ่ายซึ่งทำให้เกิดลักษณะงานที่ท้าทายและแปลกใหม่ ทั้งนี้มันจะเกิดขึ้นได้ก็ต่อเมื่อเกิดการตรวจสอบกระบวนการทำงานอย่างจริงจังว่าเกิดข้อจำกัดขึ้นในส่วนใด การขาดซึ่งการทำงานแบบอัตโนมัติส่งผลให้ Security analyst ถูกบังคับให้ทำงานซ้ำซ้อนซึ่งทำให้สูญเสียโอกาสในการพัฒนา Skills และ Creativity ไป
ประสิทธิภาพในเชิงปฏิบัติการ (Operational Efficiency) ปัจจัยนี้ถูกอธิบายในมุมของหาก SOC สามารถปฏิบัติการได้อย่างมีประสิทธิภาพ Security analyst จะได้รับอิทธิพลจากสิ่งนี้และส่งผลกระทบต่อทุนมนุษย์ภายในตัวของเขาเอง ความมีประสิทธิภาพในเชิงปฏิบัติการนั้นร่วมไปถึงการทำงานแบบอัตโนมัติที่ช่วยลดงานซ้ำหรือการเกิดขึ้นของเทคโนโลยีใหม่ที่ช่วยให้การทำงานนั้นเป็นไปได้ง่ายขึ้น
ตัวชี้วัด (Metrics) เนื่องจาก SOC เป็นกระบวนการที่มีการลงทุนสูง การเกิดขึ้นของตัวชี้วัดในงานวิจัยนี้จึงเป็นถูกนำมาเป็นปัจจัยหนึ่งที่กลุ่มของผู้บริหารกำหนดและประเมินรวมไปถึงความคาดหวังต่อกิจกรรมและผลลัพธ์ที่ได้ของ SOC หากตัวชี้วัดถูกกำหนดขึ้นอย่างไม่เหมาะสม นั่นหมายถึงการประเมินที่ผิดพลาดในประสิทธิภาพในเชิงปฏิบัติการและอาจหมายถึงการสูญเสียโอกาสในการพัฒนาทุนมนุษย์และปัจจัยอื่นๆ ไป งานวิจัยนี้ยังคงไม่อาจสรุปได้ถึงตัวชี้วัดที่เหมาะสมในการประเมินประสิทธิภาพในเชิงปฏิบัติการ โดยเสนอเพียงแค่ผลกระทบที่มีเท่านั้น

งานวิจัยนี้ยังคงมีข้อจำกัดในหลายประเด็น อาทิ กระบวนการพัฒนาโมเดลเพื่ออธิบายปรากฎการณ์ทางสังคมรวมไปถึงกระบวนการทดสอบเกิดขึ้นกับ SOC เพียงไม่กี่ราย ซึ่งอาจทำให้โมเดลไม่ได้สะท้อนถึงความจริงได้อย่างแม่นจำ และด้วยข้อจำกัดที่ผู้ทำวิจัยจะต้องเข้าร่วมในกระบวนการทำงานของ SOC เป็นระยะเวลาที่นานซึ่งทำให้ความหลากหลายของสภาพแวดล้อมในการทำวิจัยเกิดขึ้นได้ยาก รวมไปถึงข้อผิดพลาดที่อาจเกิดขึ้นในการเก็บข้อมูล ผลลัพธ์จากงานวิจัยนี้จึงสมควรที่จะถูกตั้งคำถามและพิสูจน์เพื่อการพัฒนาต่อไป
สรุป
งานวิจัย A Human Capital Model for Mitigating Security Analyst Burnout นี้ผูกประเด็นปัญหาของการ Burnout ใน Security analyst ไว้กับประเด็นเรื่องของทุนมนุษย์อันได้แก่ ความสามารถ, สิทธิ์และอำนาจนการดำเนินการ, ความสร้างสรรค์และการพัฒนาและเติบโตของศักยภาพ พร้อมกับปัจจัยภายนอกอื่นๆ เป็นหลัก โดยได้เสนอในมุมว่าประสิทธิภาพและความพึงพอใจในการทำงานขึ้นอยู่กับการสร้าง พัฒนาและรักษาตัวแปรเหล่านี้เอาไว้ ในขณะเดียวกันปัญหาของการ Burnout เกิดจากการไม่สามารถสร้าง พัฒนาและรักษาตัวแปรเหล่านี้เอาไว้ได้

แม้ว่างานวิจัยจะสามารถนำเสนอโมเดลเพื่อให้เราได้นำมาทดสอบและพิสูจน์ถึงความแม่นยำกันต่อไป โมเดลและทฤษฎีซึ่งนำเสนอตัวแปรของพฤติกรรมในสังคมก็ยังคงทำหน้าที่ได้เพียงชี้ให้เห็นถึงความเป็นไปได้ของกลุ่มปัจจัยหนึ่งจากปัจจัยมากมายที่จะส่งผลกระทบต่อการทำงานของ Security analyst การควบคุมปัจจัยที่เกี่ยวข้องกับประสิทธิภาพก็ยังคงไม่ชัดเจนและเหลือทิ้งไว้เป็นคำถามต่อไปว่า Manager และ Executive ควรจะบริหารและจัดการ รวมไปถึงบาลานซ์ปัจจัยต่างๆ ให้เหมาะสมได้อย่างไรเพื่อให้ทุนมนุษย์และปัจจัยที่เกี่ยวข้องสามารถเกิดขึ้นได้อย่างมีประสิทธิภาพและปราศจากผลกระทบที่ไม่พึงประสงค์ได้มากที่สุด

With threat response and remediation capability provided on Emergency Incident Response service by our Intelligent Response team, in this post we will cover the latest WannaMine campaign that happened during December 2019, what we have discovered and accomplished during the incident, and technical threat analysis.

นอกเหนือจากความพร้อมของข้อมูลที่จะถูกใช้เพื่อระบุหาการมีอยู่ของภัยคุกคาม ปัจจัยที่มีความสำคัญอีกปัจจัยหนึ่งซึ่งจะการันตีความสำเร็จของการระบุหาภัยคุกคามในรูปแบบของ Threat hunting นั้น คือการคิดค้นและพัฒนาสมมติฐานหรือไอเดียที่จะใช้ในการระบุการมีอยู่ของภัยคุกคามดังกล่าวในเชิงรุก (proactive) รวมไปถึงการประเมินและปรับปรุงให้สมมติฐานหรือ Hunting use case นั้นสามารถใช้งานได้จริงและเกิดประสิทธิภาพ

ในบทความนี้ทีมตอบสนองภัยคุกคาม (Intelligent Response) จาก บริษัท ไอ-ซีเคียว จำกัด จะมาสาธิตการพัฒนา Hunting use case บนเทคโนโลยีซึ่งเรามีความถนัด 2 เทคโนโลยี ได้แก่ CrowdStrike Falcon ซึ่งจะทำหน้าที่เป็นส่วน Endpoint detection and response (EDR) ในการเก็บข้อมูลจากระบบต่างๆ มาระบุหาการมีอยู่ของภัยคุกคามโดยใช้ Splunk Search Processing Language (SPL) กับฟีเจอร์ CrowdStrike Events App ซึ่งใช้ Splunk เป็นเทคโนโลยีหลังบ้านหลักครับ

สำหรับสถานการณ์จำลองที่ทีมตอบสนองภัยคุกคามจะสาธิตการทำ Threat hunting นั้น เราจะทำการพัฒนา SPL โดยนำแนวคิดมาจาก Hunting use case ซึ่งถูกเผยแพร่โดย Red Canary ในงาน BlackHat USA 2019 ภายใต้หัวข้อ Fantastic Red Team Attacks and How to Find Them
Fantastic Red Team Attacks and How to Find Them - A Summary
ก่อนที่เราจะไปดูกันที่ใจความสำคัญของบล็อกนี้ เราจำเป็นที่จะต้องเข้าใจเนื้อหาและเป้าหมายของหัวข้อการบรรยายจากทาง Red Canary ก่อน สำหรับการบรรยายในหัวข้อ Fantastic Red Team Attacks and How to Find Them นั้น Casey Smith ซึ่งปัจจุบันดำรงตำแหน่ง Director of applied research ของ Red Canary ได้มีการเปิดเผยเทคนิคการโจมตีใหม่ซึ่งใช้ไบนารี dbgsrv.