รู้จัก 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.

มัลแวร์ตัวไหนกำลังเด่นๆ บ้าง?

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 Analyst ถึง Burnout และเราทำอย่างไรกับปัญหานี้ได้บ้าง?”

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

WannaMine “Invoke-Brexit” Campaign Analysis

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.

รู้จัก Coordinated Vulnerability Disclosure (CVD)

Coordinated Vulnerability Disclosure เป็นศัพท์ที่ CERT/CC รณรงค์ให้ใช้แทนคำว่า Responsible Disclosure เนื่องจาก CERT/CC มองว่าคำว่า Responsible ในที่นี้มีความหมายที่คลุมเครือเกินไป

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

ในบทความ rConfig v3.9.2 authenticated and unauthenticated RCE (CVE-2019-16663) and (CVE-2019-16662) ผู้เขียนบทความ Mohammad Askar ระบุว่าได้รายงานช่องโหว่ไปยังผู้พัฒนา rConfig ถึงช่องโหว่ที่ทำให้รันคำสั่งอันตรายจากระยะไกลได้ (RCE) แต่ไม่ได้รับการติดต่อกลับว่าจะมีการแก้ไขช่องโหว่หรือไม่ เขาจึงตัดสินใจเปิดเผยรายละเอียดเกี่ยวกับช่องโหว่เมื่อผ่านไป 35 วันหลังจากที่ไม่มีการตอบรับ
ตัวอย่างองค์กรที่ได้รับประโยชน์จากการรายงานช่องโหว่
ในเหตุการณ์ข้อมูลรั่วไหลของ Capital One ที่เกิดเมื่อเดือนกรกฏาคม 2019 ที่ผ่านมา Capital One ทราบเหตุการณ์นี้จากช่องทางที่เปิดให้นักวิจัยรายงานช่องโหว่ในวันที่ 17 กรกฏาคม 2019 มีผู้ใช้งาน GitHub พบการโพสข้อมูลที่น่าจะเป็นของ Capital One บน GitHub ข้อมูลดังกล่าวประกอบด้วย IP ของเซิร์ฟเวอร์และคำสั่งที่ใช้ดึงข้อมูลออกจากเซิร์ฟเวอร์ของ Amazon ที่ Capital One ใช้บริการ เมื่อสถาบันการเงิน Capital One ได้ทำการตรวจสอบไฟล์ดังกล่าว จึงพบการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาตโดยใช้คำสั่งเหล่านั้นเมื่อวันที่ 22 ถึง 23 มีนาคม 2019 และได้แจ้งไปยัง FBI ซึ่งได้ทำการติดตามจับกุมผู้ต้องสงสัยได้ในเวลาไม่นานต่อมา (สามารถอ่านรายละเอียดของเหตุการณ์ได้จาก https://www.

พัฒนา Threat Hunting Use Case กับ CrowdStrike Events App

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

รีวิวแพลตฟอร์มช่วยแฮก/ทดสอบเจาะระบบอัตโนมัติ Infection Monkey

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

การใช้เครื่องมือหรือวิธีการใดๆ ที่นำเสนอในบทความมีจุดประสงค์เพื่อการทดสอบและประเมินความปลอดภัยระบบ ทีม Intelligent Response และบริษัท ไอ-ซีเคียว จำกัด ขอปฏิเสธความรับผิดชอบหากมีการเนื้อหาของบทความไปใช้เพื่อสร้างความเดือดร้อนหรือกระทำผิดตามบทบัญญัติซึ่งระบุไว้ในพระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550
ทำความรู้จักแนวคิดของ Automated Pentest ของ Infection Monkey
ก่อนที่เราจะไปดูฟีเจอร์ที่หวือหวาที่สุดของ Infection Monkey ซึ่งก็คือการทำงานโดยอัตโนมัติ ทีม Intelligent Response ต้องขอเล่าแนวคิดและเกร็ดเล็กน้อยเกี่ยวกับแนวคิดของ "ความอัตโนมัติ" ที่เกี่ยวข้องกับการหาและโจมตีช่องโหว่ความปลอดภัยกันซักหน่อยครับ

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

ในรุ่นโอเพนซอร์สของ Metasploit หรือที่รู้จักกันในชื่อ Metasploit Framework นั้น ผู้ทดสอบเจาะระบบสามารถเรียกใช้โมดูลระดับตำนานชื่อ db_autopwn ซึ่งจะดำเนินการเรียกใช้โค้ดสำหรับโจมตีช่องโหว่โดยอัตโนมัติ อ้างอิงจากผลลัพธ์การสแกนด้วย NMAP หรือ Nessus หรือโมดูล Browser Autopwn ซึ่งถูกพัฒนาเพื่อเลียนแบบการโจมตีในรูปแบบ Drive-by download ได้
เฟรมเวิร์คระดับตำนานสมัยยุค Backtrack "Armitage" ก็มีฟีเจอร์ Automatic Exploitation ซึ่งใช้แนวคิดเดียวกับ db_autopwn ในการโจมตีโดยอัตโนมัติด้วยเช่นกัน
(ไม่ได้ขายของ) ในยุคต่อมาฟีเจอร์ Auto-Exploitation ได้กลายมาเป็นฟีเจอร์หากินสำคัญของ Metasploit Pro ซึ่งผมเชื่อว่าเราจะได้ยินฟีเจอร์นี้ทุกครั้งจากฝ่ายขายของทาง Rapid 7

ข้อแตกต่างที่เห็นได้อย่างชัดเจนของ Infection Monkey กับกลุ่มซอฟต์แวร์แบบโอเพนซอร์สด้านบนนั้นคือความสามารถในการทำ Automated Post Exploitation เบื้องต้น หรือกระบวนการหลังจากที่ผู้โจมตีสามารถเข้ายึดระบบได้สำเร็จ อาทิ Internal discovery และ Pivoting/Lateral movement ซึ่งในกรณีของกลุ่มซอฟต์แวร์อื่นๆ นั้น อาจจำเป็นต้องมีการใช้ฟีเจอร์เสริมหรือการพัฒนาส่วนเสริมเพื่อให้เกิดการทำงานในลักษณะนี้อีกทีหนึ่ง

ทั้งนี้ด้วยความที่เป็นโครงการโอเพนซอร์ส ความสามารถของ Infection Monkey จึงถูกจำกัดด้วยเทคนิคในการ Gaining access และ Post exploitation ซึ่งเราจะพูดถึงเทคนิคและช่องโหว่ซึ่ง Infection Monkey มีการใช้งานกันต่อในส่วนต่อไปครับ
การทำงานเบื้องต้นของ Infection Monkey
โครงการ Infecion Monkey จะประกอบไปด้วยสองโมดูลหลักๆ คือ Monkey และ Monkey Island

โมดูล Monkey คือไฟล์ประเภทไบนารีซึ่งถูกพัฒนาเพื่อทำหน้าที่เป็นมัลแวร์และสามารถแพร่กระจายได้ ในการใช้งานนั้นผู้ทดสอบจะต้องการเอ็กซีคิวต์เพื่อให้โมดูล Monkey เริ่มการทำงานที่ระบบเป้าหมาย โดยโมดูล Monkey จะเริ่มทำกระบวนการ Internal discovery และ Pivoting/Lateral movement โดยอัตโนมัติตามการตั้งค่า ในรุ่นล่าสุดของ Infection Monkey (1.6.3) ตัวโมดูลจะรองรับการทำงานเฉพาะในระบบปฏิบัติการ Windows (32-bit และ 64-bit) และ Linux (32-bit และ 64-bit)

โมดูล Monkey Island จะเป็นเว็บแอปพลิเคชันซึ่งทำหน้าที่เป็นเซิร์ฟเวอร์ Command & Control ซึ่งจะคอยแสดงสถานะและควบคุมการทำงานของ Monkey โดยผู้ทดสอบสามารถตรวจสอบและหยุดการทำงานของ Monkey ได้ผ่านหน้าแดชบอร์ด เมื่อดำเนินการจนเสร็จสิ้น เราจะทดสอบตรวจสอบ Security Report ได้จากโมดูลนี้ด้วย

สำหรับในรุ่นล่าสุด ผู้ทดสอบสามารถติดตั้ง Monkey Island ได้ทั้งในแพลตฟอร์มของ VMware, AWS, รูปแบบ container, GCP, Azure, Windows Server และแพ็คเกตสำหรับลินุกซ์ซึ่งใช้ Debain-based package managerpenetration testing

สำหรับในการใช้งานนั้น ผู้ทดสอบสามารถเริ่มใช้งานได้ตามขั้นตอนที่ Infection Monkey กำหนดไว้ ได้แก่

ติดตั้งเซิร์ฟเวอร์ Monkey Island
ตั้งค่ารูปแบบการทำงานของโมดูล Monkey
เลือกให้ Monkey เริ่มทำงานที่เซิร์ฟเวอร์ Monkey Island หรือระบบที่ต้องการ
นั่งดูผลลัพธ์การทำงานผ่าน Infection Map
เมื่อการทำงานเสร็จสิ้น ตรวจสอบปัญหาซึ่งพบได้จากหน้า Security Report

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

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

Exploit user/password list หรือรายการของชื่อบัญชีและรหัสผ่านซึ่งจะถูกใช้ในการขั้นตอนของการ Gaining access
Distance from Island คือจำนวน Hop ของระบบซึ่ง Monkey จะสามารถกระโดดและแพร่กระจายไปได้
Network segmentation/exclusion คือรายการของหมายเลขไอพีแอดเดรสหรือ subnet ซึ่งจะถูกยกเว้นจากการพยายามเข้าถึง
Custom post breach command คือรายการของคำสั่งทั้งในระบบ Linux/Windows ซึ่งจะถูกเอ็กซีคิวต์หลังจากที่ Monky สามารถเข้าถึงระบบได้สำเร็จ
TCP scanner คือการตั้งค่าเกี่ยวกับการทำงานในขั้นตอน Discovery ทั้งรูปแบบการสแกนและรายการพอร์ต พอร์ตที่จะตรวจสอบว่าเป็นเซิร์ฟเวอร์ HTTP หรือไม่
Exploits คือรายการของโค้ด/วิธีในการโจมตีช่องโหว่และการตั้งค่าต่างๆ ซึ่งจะใช้ในกระบวนการ Gaining access ได้แก่ Exploiter สำหรับ SMB, WMI, MSSQL, RDP, MS08-067, SSH, ShellShock, SambaCry, ช่องโหว่ ElasticGroovy, ช่องโหว่ Struts2, ช่องโหว่ Oracle Web Logic และช่องโหว่ Hadoop/Yarn

ประเมินการทดสอบด้วย Security Report
เมื่อกระบวนการ Infection เสร็จสิ้น ผู้ทดสอบสามารถตรวจสอบการทำงานรวมไปถึงการค้นพบช่องโหว่ได้จากฟีเจอร์ Securty Report

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

ขอให้สนุกกับการแฮกนะครับ 🙂

รีวิวเฟรมเวิร์คจำลองการโจมตีตามพฤติกรรมของภัยคุกคามเพื่อการทดสอบในรูปแบบ iPentest

บทความนี้จัดทำโดย เนติวัฒน์ วงศ์ยะรา นักศึกษาฝึกงาน และเรียบเรียงโดยทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) บริษัท ไอ-ซีเคียว จำกัด

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

เนื้อหาภายในบทความจะมีตามหัวข้อดังต่อไปนี้ครับ

ทำความรู้จักแนวปฏิบัติการทดสอบเจาะระบบแบบ Intelligence-lead (iPentest)
TTP คืออะไร? นำมาใช้ยังไงได้บ้าง?
จากพฤติกรรมของผู้บุกรุก สู่ Machine-readable Data
แนะนำโอเพนซอร์สเฟรมเวิร์คสำหรับการจำลองพฤติกรรมของภัยคุกคาม
ผลการรีวิวเฟรมเวิร์คสำหรับการจำลองพฤติกรรมของภัยคุกคาม
สรุป

ทำความรู้จักแนวปฏิบัติการทดสอบเจาะระบบแบบ Intelligence-lead (iPentest)
เมื่อวันที่ 4 กันยายนที่ผ่านมา ธนาคารแห่งประเทศไทยออกประกาศภายใต้เรื่องแนวปฏิบัติการทดสอบเจาะระบบแบบ Intelligence-lead (iPentest) ซึ่งรูปแบบของการทดสอบเจาะระบบใหม่โดยเน้นไปที่การทดสอบภายใต้สถานการณ์เสมือนจริงในลักษณะ Red Teaming

ใจความสำคัญของ iPentest นั้นคือการทดสอบเจาะระบบที่มีการใช้ข้อมูล Threat intelligence ในกำหนดสถานการณ์จำลองเพื่อใช้ในการทดสอบเจาะระบบ สถานการณ์จำลองดังกล่าวจะต้องสอดคล้องกับโอกาสและภาพรวมของภัยคุกคามที่สถาบันการเงินจะเผชิญ แนวปฏิบัติยังเปิดช่องทางให้สถานการณ์จำลองถูกดำเนินการได้ในลักษณะของการ Capture the Flag (CTF) ด้วย

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

เทรนด์ด้านการทดสอบและประเมินความมั่นคงปลอดภัยในลักษณะของ iPentest นั้นเป็นหนึ่งในเทรนด์ด้านความปลอดภัยที่ได้รับความนิยมสูงขึ้นในแวดวงความปลอดภัยไซเบอร์ทั่วโลก กระบวนการดังกล่าวถูกเรียกด้วยชื่อที่แตกต่างกันในหลายรูปแบบ อาทิ Red teaming, Adversary simulation, Adversary emulation, Threat emulation และอื่นๆ ในขณะเดียวกันสายงาน อาทิ Red team, Threat hunter หรือ Purple team ก็เกิดขึ้นและได้รับความนิยมสูงไม่แพ้กัน
TTP คืออะไร? นำมาใช้ยังไงได้บ้าง?
เมื่อพูดถึงการใช้งาน Threat intelligence เพื่อการจำลองพฤติกรรมของผู้โจมตีจริง เราจำเป็นต้องเข้าใจประเภทของ Threat intelligence ที่สามารถนำไปใช้งานได้ก่อน หนึ่งในวิธีการจำแนกประเภทของ Threat intelligence ที่ง่ายและได้รับความนิยมรูปแบบหนึ่งคือ The Pyramid of Pain ซึ่งเป็นผลงานของ David J. Bianco

The Pyramid of Pain จำแนกประเภทของ Threat intelligece ด้วยขั้นของความพยายามที่ผู้โจมตีต้องใช้เพื่อแก้ไข/เปลี่ยนแปลงตัวบ่งชี้ภัยคุกคาม (indicator) ในแต่รูปแบบเพื่อให้สามารถหลบหลีกการตรวจจับและการป้องกันได้

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

หากเราไล่ไปถึงยอดของพีระมิด เราจะพบว่าสิ่งที่ผู้โจมตีเปลี่ยนแปลงได้ยากที่สุดนั้นคือสิ่งที่เรียกว่า Tactics,Techniques and Procedures หรือ TTP ซึ่งมีความหมายดั้งเดิมที่เกี่ยวข้องกับการรักษาความมั่นคงจากภัยก่อการร้ายก่อนจะถูกนำมาใช้ในการรักษาความปลอดภัยไซเบอร์ TTP อธิบายถึงรูปแบบหรือลักษณะพฤติกรรมที่ผู้บุกรุกจะทำเมื่อจะสร้างความเสียหายหรือโจมตี พฤติกรรมอาจมีความเหมือนกันในหลายกลุ่มผู้บุกรุก แต่หากเราสามารถรวบรวมรูปแบบหรือลักษณะของพฤติกรรมดังกล่าว ไปจนถึงตัวบ่งชี้ภัยคุกคามในระดับที่ต่ำลงมาได้ การระบุกลุ่มผู้บุกรุกจากพฤติกรรมก็สามารถทำได้อย่างมีประสิทธิภาพเช่นเดียวกัน
จากพฤติกรรมของผู้บุกรุก สู่ Machine-readable Data
ในช่วงหลายปีที่ผ่านมา ความพยายามในการอธิบายรูปแบบหรือลักษณะพฤติกรรมของผู้บุกรุกให้อยู่ในรูปแบบของข้อมูลที่สามารถถูกประมวลผลและใช้งานได้โดยคอมพิวเตอร์เกิดขึ้นในหลายรูปแบบ เราจะมาดูกันครับว่าในทุกวันนี้เรามีวิธีในการอธิบายพฤติกรรมของผู้บุกรุกเพื่อนำข้อมูลไปใช้กันอย่างไรบ้าง
เฟรมเวิร์คตระกูล STIX/MAEC/CYBOX
STIX/MAEC/CyBox คือความพยายามจาก OASIS Cyber Threat Intelligence (CTI) TC ในการพัฒนากรอบและมาตรฐานเพื่ออธิบายพฤติกรรมของผู้โจมตี ตัวบ่งชี้ภัยคุกคามรวมไปถึงสิ่งที่ตรวจพบอื่นๆ (Observable) โดย STIX เน้นไปที่การอธิบายข้อมูลภัยคุกคามทั้งช่องโหว่, ผู้กระทำ, เป้าหมาย, จุดมุ่งหมาย, ตัวบ่งชี้ภัยคุกคามและอื่นๆ ด้วยความสัมพันธ์ระหว่างกัน

MAEC เน้นไปที่การอธิบายข้อมูลจำเพาะที่เกี่ยวกับมัลแวร์ทั้งคุณลักษณะของไฟล์, ความเกี่ยวข้องกับกลุ่มผู้โจมตีรวมไปถึงสายพันธุ์ของมัลแวร์

ท้ายที่สุด CyBox เน้นไปที่การอธิบายและให้ความหมายของทุกข้อมูลที่ตรวจพบ (Observable) โดยไม่จำกัดว่าสิ่งนั้นจะเป็นตัวบ่งชีภัยคุกคามหรือไม่ ไม่ว่าจะเป็นค่ารีจิสทรี, พฤติกรรมการลบไฟล์หรือข้อมูลในโปรโจตอล HTTP GET

ในปัจจุบันองค์กรหลายแห่งมีการเผยแพร่ตัวบ่งชี้ภัยคุกคามในรูปแบบของไฟล์ STIX รวมไปถึงเปิดให้องค์กรสามารถเข้าถึงและใช้งานข้อมูลในฟอร์แมตของ STIX ได้ผ่านเซิร์ฟเวอร์ TAXII ตัวอย่างเช่น ประกาศล่าสุดจาก US-CERT ว่าด้วยเรื่องของมัลแวร์ ELECTRICFISH จากกลุ่มแฮกเกอร์ Lazarus
เฟรมเวิร์คตระกูล MITRE ATT&CK
MITRE ATT&CK สามารถถูกเรียกได้ว่าทั้งเฟรมเวิร์คและแหล่งข้อมูล TTP ที่ดีที่สุดแหล่งหนึ่งของโลก มันได้ทำการรวบรวมและอธิบาย TTP ไว้ในรูปแบบเดียวกับที่ Cyber Kill Chain ของ Lockheed Martin เคยทำแต่ด้วยรายละเอียดที่เยอะกว่า รวมไปถึงการเชื่อมโยงระหว่าง TTP, กลุ่มผู้โจมตี, เครื่องมือที่ใช้และคำแนะนำในการตรวจจับและบรรเทาผลกระทบที่เกิดขึ้นจากเทคนิคที่ผู้บุกรุกกระทำ

ความนิยมของ MITRE ATT&CK ทำให้มันถูกนำไปปรับใช้กับผลิตภัณฑ์ด้านความปลอดภัยหลายรายการ รวมไปถึงการนำไปใช้ในการอธิบายพฤติกรรมของผู้บุกรุกใหม่ๆ ยกตัวอย่างเช่น ผลิตภัณฑ์ในกลุ่ม Endpoint Detection & Response "CrowdStrike" ซึ่งนำข้อมูลจาก MITRE ATT&CK มาใช้เพื่อช่วยในการตรวจจับ

ทีม Intelligent Response ยังได้เคยนำแนวคิดของ MITRE ATT&CK มาใช้ในการอธิบายความเชื่อมโยงระหว่างพฤติกรรมของผู้โจมตีและกลุ่มผู้โจมตีในงาน MissConf(SP)#5 ภายใต้หัวข้อ APT-Based Security Assessment and Detection (ดูสไลด์)
แนะนำโอเพนซอร์สเฟรมเวิร์คสำหรับการจำลองพฤติกรรมของภัยคุกคาม
ด้วยข้อมูลที่ได้มาจากฐานข้อมูล TTP ในรูปแบบต่างๆ ทีม Intelligent Response จึงได้มีการรวบรวมและทดสอบโอเพนซอร์สเฟรมเวิร์คที่สามารถนำข้อมูลดังกล่าวมาจำลองเป็นพฤติกรรมจริงๆ ในสภาพแวดล้อมที่ต้องการได้ ความสามารถในการจำลองพฤติกรรมของภัยคุกคามนอกจากจะช่วยในการประเมินความเสี่ยงด้านความปลอดภัยแล้ว มันยังมีส่วนสำคัญในการพัฒนาศักยภาพในการรับมือและตอบสนองภัยคุกคาม และการใช้เพื่อทดสอบความสามารถของผลิตภัณฑ์ด้านความปลอดภัยด้วย

จากรายการของเฟรมเวิร์คที่ได้มีการรวบรวมไว้ ทีม Intelligent Response ได้มีการเลือกเฟรมเวิร์คซึ่งจะนำมาทดสอบตามรายการดังต่อไปนี้

Red Team Automation (RTA) จาก Endgame โดยเป็นเฟรมเวิร์คซึ่งนำพฤติกรรมของผู้โจมตีตามที่ระบุไว้ใน MITRE ATT&CK มารวบรวมไว้ให้อยู่ในรูปแบบของสคริปต์ ซึ่งสามารถตั้งค่าและเรียกใช้เพื่อจำลองพฤติกรรมของผู้โจมตีจริงๆ ขึ้นมาได้
APT Simulator จาก Nextron Systems เป็นเฟรมเวิร์คในการจำลองพฤติกรรมของภัยคุกคามในกลุ่ม APT ให้อยู่ในรูปแบบของสคริปต์ Batch สำหรับระบบปฏิบัติการ Windows พฤติกรรมซึ่งมีการจำลองนั้นเป็นพฤติกรรมที่ไม่ได้อิงจาก MITRE ATT&CK แต่มีบางส่วนคล้ายคลึงกัน
Atomic Red Team จาก Red Canary เป็นเฟรมเวิร์คซึ่งทำการรวบรวม TTP ของผู้บุกรุกอ้างอิงจาก MITRE ATT&CK ไว้ในรูปแบบของ atomic test case ซึ่งทำให้ผู้ทดสอบสามารถนำแต่ละเทคนิคมาทำการปรับแต่งและควบคุมพฤติกรรมที่จะทำการจำลองได้
CALDERA จาก MITRE เป็นโครงการจากผู้ดูแล MITRE ATT&CK ซึ่งถูกพัฒนาขึ้นเพื่อจำลองพฤติกรรมของผู้โจมตีแบบครบวงจร พร้อมทั้งมีรูปแบบของมัลแวร์เสมือนภายในตัวเฟรมเวิร์คเอง

โดยในการรีวิวนั้น ทีม Intelligent Response มีการตั้งคุณสมบัติที่ต้องการไว้ตามรายการดังต่อไปนี้

เฟรมเวิร์คที่เหมาะสมจะต้องมีความครบถ้วนตามฐานข้อมูลภัยคุกคาม MITRE ATT&CK เพื่อให้เกิดความครอบคลุมในการทดสอบภายใต้จุดประสงค์ที่แตกต่างกันให้มากที่สุด
เฟรมเวิร์คจะต้องมีความยืดหยุ่นมากพอให้ทีม Intelligent Response สามารถแก้ไขการตั้งค่าได้ตามต้องการ เช่น การแก้ไข Payload ที่จะถูกเอ็กซีคิวต์ในแต่ละเทคนิคการโจมตี รวมไปถึงเปลี่ยนแปลงรูปแบบและลักษณะของการจำลอง
เฟรมเวิร์คจะต้องสามารถถูกปรับแต่งให้สามารถทำงานโดยอัตโนมัติได้อย่างมีประสิทธิภาพและง่ายดาย ยกตัวอย่างเช่น ผู้ทดสอบสามารถบันทึกรายการของพฤติกรรมที่ต้องการไว้ในรูปแบบของ Playbook และสั่งให้เฟรมเวิร์คจำลองพฤติกรรมตามที่ระบุในช่วงหรือระยะเวลาที่กำหนดได้
เฟรมเวิร์คจะต้องรองรับระบบปฏิบัติการที่หลากหลาย

ผลการรีวิวเฟรมเวิร์คสำหรับการจำลองพฤติกรรมของภัยคุกคาม
Red team automation (RTA)
Red Team Automation หรือ RTA มีการรวบรวมเทคนิคจาก MITRE ATT&CK ไว้ทั้งหมดประมาณ 42 รายการ โดยเน้นไปที่การกลุ่ม Defense evasion, Execution และ Persistence การใช้งานสามารถทำได้ทั้งในรูปแบบของการเรียกใช้โมดูลแยกสำหรับแต่ละเทคนิค, รันทุกเทคนิคโดยอัตโนมัติผ่านทางสคริปต์ run_all.

แจ้งเตือนกลุ่มแฮกเกอร์ Silence มุ่งโจมตีสถาบันทางการเงินทั่วโลก

บทนำ
เมื่อเดือนกันยายน 2018 นักวิจัยจาก Group-IB ออกรายงานชื่อ Silence: Moving into the darkside เปิดเผยกลุ่มแฮกเกอร์กลุ่มใหม่ชื่อ Silence เชื่อมโยงกับการขโมยเงินจากธนาคารในรัสเซีย, ธนาคารในยุโรปตะวันออก และสถาบันทางการเงิน ซึ่ง Group-IB ให้ความสนใจกลุ่ม Silence เพราะเป็นกลุ่มที่แตกต่างจาก APT ที่มุ่งโจมตีสถาบันการเงินทั่วไป เนื่องจากมีขนาดเล็กแต่มีความสามารถในการพัฒนาเทคนิคและเครื่องมือ ไม่ว่าจะเป็นการพัฒนาเครื่องมือเองใหม่, แก้ไขจากความผิดพลาด หรือลอกเลียนแบบจากกลุ่มอื่นๆ

Group-IB ค้นพบการเคลื่อนไหวของกลุ่ม Silence ตั้งแต่เดือนกรกฏาคมปี 2016 โดยกลุ่ม Silence พยายามทำการถอนเงินผ่านระบบกลางที่เชื่อมระหว่างแต่ละธนาคารในรัสเซีย (AWS CBR: Automated Work Station Client of the Russian Central Bank) แต่ไม่ประสบความสำเร็จ จากนั้นกลุ่ม Silence มีการพัฒนาเทคนิคการโจมตีและทดลองอีกหลายครั้งจนกระทั่งทำการโจมตีสำเร็จในเดือนตุลาคมปี 2017 และทำการโจมตีต่อมาอีกหลายครั้งในปี 2018 รวมเป็นเงินกว่า 800,000 ดอลลาร์สหรัฐฯ

ต่อมาในเดือนสิงหาคม 2019 Group-IB ได้ออกรายงาน Silence 2.0: Going Global อัปเดตการทำงานของกลุ่ม Silence ว่าได้ขยายการโจมตีเป็นทั่วโลก โดยจากกันยายน 2018 ที่ออกรายงานฉบับแรกมาจนถึงการออกรายงานฉบับที่ 2 นี้ Group-IB คาดว่ากลุ่ม Silence ได้สร้างความเสียหายกว่า 4.2 ล้านดอลลาร์สหรัฐฯ แล้ว

ทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) จากบริษัท ไอ-ซีเคียว จำกัดจะสรุป Tactics, Techniques, and Procedures (TTP) ของกลุ่ม Silence ตาม MITRE ATT&CK Framework ดังต่อไปนี้

Tactics, Techniques, and Procedures (TTP) ของกลุ่ม Silence
ขั้นที่ 0 Contact database check การส่งอีเมลปลอมไปยังเป้าหมายเพื่อเช็คว่าอีเมลนั้นๆ รับอีเมลได้หรือไม่

ขั้นที่ 1 Mail-out to valid address ส่งอีเมลโจมตีไปเฉพาะอีเมลที่ถูกต้อง โดยภายในมีไฟล์แนบที่เป็นอันตราย

ขั้นที่ 2 Infection of the victim's computer เมื่อเหยื่อหลงเปิดไฟล์แนบและติดเชื้อ Silence.

Capital One Data Breach: Analysis & Recommendation

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

Executive Summary
Incident Timeline
Possible Vulnerabilities and Flaws
Recommendation
References
AWS Case Study by Security Researcher

Executive Summary
Capital One Financial Corporation announced today that on July 19, 2019, it determined there was unauthorized access by an outside individual who obtained certain types of personal information relating to people who had applied for its credit card products and to Capital One credit card customers.