Okta ผู้ให้บริการด้าน Identity and Access Management (IAM) ได้ออกอีเมลที่ระบุว่า "เป็นความลับ" แจ้งเตือนเหตุการณ์ Security Incident ถึงกรณีที่ Private GitHub ของตนถูกแฮ็กในเดือนธันวาคมที่ผ่านมา โดยทาง BleepingComputer ได้รับการยืนยันว่าเกิดเหตุการณ์นี้เกิดขึ้นจริง

รายละเอียดเหตุการณ์

เมื่อต้นเดือนธันวาถาม GitHub ได้แจ้งเตือน Okta เกี่ยวกับการตรวจพบพฤติกรรมน่าสงสัยเกี่ยวกับการเข้าถึงที่เก็บ Source Code ของ Okta
จากการตรวจสอบ พบว่าเป้าหมายในการโจมตีครั้งนี้คือการคัดลอกโฟลเดอร์ Repository ที่เป็นที่เก็บข้อมูลของ Okta
อย่างไรก็ตาม Okta ยืนยันว่า แม้ผู้โจมตีจะขโมย Source Code ของ Okta ได้สำเร็จ แต่ก็ไม่สามารถเข้าถึงบริการ หรือข้อมูลลูกค้าของ Okta ได้ ดังนั้นลูกค้าที่อยู่ภายใต้มาตรฐาน HIPAA, FedRAMP หรือ DoD ของ Okta จะไม่ได้รับผลกระทบ เนื่องจากบริษัทไม่มีการใส่ข้อมูลของลูกค้าที่เป็นความลับบน Source Code ด้วยเหตุนี้ลูกค้าจึงไม่จำเป็นต้องดำเนินการใด ๆ
ทันทีที่ Okta ทราบเกี่ยวกับพฤติกรรมที่น่าสงสัย จึงได้ทำการจำกัดการเข้าถึงไฟล์ Repository ชั่วคราว นอกจากนี้ยังยกเลิกการ Integration จาก third-party applications ทั้งหมดบน GitHub
จากนั้นได้ตรวจสอบการเข้าถึงทั้งหมดที่ไปยัง Repository บน GitHub รวมถึงทดสอบการเข้าถึงไฟล์ด้วย Environment อื่น ๆ เพื่อให้แน่ใจว่าไม่มีใครสามารถเข้าถึงไฟล์ได้ พร้อมกับชี้แจงว่าเหตุการณ์ครั้งนี้กระทบกับ Okta Workforce Identity Cloud (WIC) code repositories เท่านั้น แต่ไม่กระทบกับ Auth0 Customer Identity Cloud product

สรุปเหตุการณ์ Cybersecurity Incident ของ Okta ในปี 2565

ช่วงปลายเดือนมกราคม 2565 Okta ก็ได้มายอมรับว่ามีข้อมูลรั่วไหล และอาจส่งผลกระทบต่อลูกค้า 2.5% หรือประมาณ 375 องค์กรในเวลานั้น โดยพิจารณาจากฐานลูกค้าของ Okta มากกว่า 15,000 รายในเดือนนี้
เดือนมีนาคม พบว่ากลุ่ม Lapsus$ อ้างว่าได้สิทธิ์เข้าถึง Admin Console และข้อมูลลูกค้าของ Okta โดยการโพสต์ภาพหน้าจอที่มีข้อมูลที่ถูกขโมยบน Telegram
ในเดือนเมษายน พบว่า Okta มีข้อมูลรั่วไหลเป็นระยะเวลา 25 นาที ก่อนที่เหตุการณ์นั้นจะหยุดลง
เดือนกันยายน Auth0 ของ Okta ได้เคยเกิดเหตุการณ์ในลักษณะเดียวกันคือมีการเข้าถึงแหล่งเก็บ Source Code จาก Third Party ภายนอก

ที่มา : bleepingcomputer

GitHub จะกำหนดให้ผู้ใช้งานทุกคนที่เผยแพร่ code บนแพลตฟอร์ม เปิดการใช้งาน Two-factor authentication (2FA) เป็นมาตรการป้องกันเพิ่มเติมบนบัญชีภายในสิ้นปี 2566

ซึ่ง Two-factor authentication จะช่วยเพิ่มความปลอดภัยให้กับบัญชีผู้ใช้ด้วยการเพิ่มขั้นตอนในกระบวนการเข้าสู่ระบบ

สำหรับผู้ใช้งาน GitHub การถูกเข้าถึงบัญชีผู้ใช้งาน สามารถนำไปสู่การเผยแพร่โค้ดที่เป็นอันตรายสำหรับใช้ในการโจมตีในรูปแบบ supply chain attacks ซึ่งขึ้นอยู่กับความนิยมของแต่ละ project โดยบางกรณีอาจมีผลกระทบในวงกว้างได้

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

เมื่อต้นปีทีผ่านมา GitHub เคยประกาศถึงการตัดสินใจให้ผู้พัฒนา Project ที่มีผลกระทบสูง และมีการดาวน์โหลดมากกว่าหนึ่งล้านครั้งต่อสัปดาห์ต้องมีการเปิดใช้งาน 2FA

ซึ่งการกำหนดให้มีการเปิด 2FA สำหรับผู้ใช้งานทั้งหมดจะครอบคลุมผู้ใช้ประมาณ 83 ล้านคน

การออกข้อกำหนด 2FA

GitHub จะกำหนดให้มีการเปิด 2FA บนบัญชี GitHub ทุกบัญชีตั้งแต่เดือนมีนาคม 2566 โดยในตอนแรกจะผลักดันให้บัญชีผู้ใช้งานที่อยู่ในกลุ่มผู้เผยแพร่ข้อมูลเริ่มดำเนินการก่อน

หลังจากนั้นจะทำการประเมินผลก่อนที่จะขยายไปสู่กลุ่มผู้ใช้งานที่ใหญ่ขึ้น

GitHub กล่าวว่ากลุ่มของผู้ใช้งานที่จะเริ่มดำเนินการจะถูกแบ่งโดยใช้เกณฑ์ดังต่อไปนี้ :

ผู้ใช้ที่เผยแพร่แอป หรือแพ็กเกจ GitHub หรือ OAuth
ผู้ใช้ที่มีการสร้าง code เวอร์ชันใหม่ ๆ
ผู้ใช้ที่เป็นผู้ดูแลองค์กร และองค์กร
ผู้ใช้ที่ contributed code ไปยัง repositories สำคัญ ๆ เช่น npm, OpenSSF, PyPI, หรือ RubyGems
ผู้ใช้ที่ contributed code ไปยัง repositories สาธารณะ และส่วนตัวประมาณสี่ล้านอันดับแรก

โดยผู้ที่ได้รับแจ้งล่วงหน้าเพื่อเปิดการใช้งาน 2FA ผ่านทางอีเมล จะมีระยะเวลา 45 วันในการดำเนินการ เมื่อครบกำหนดเวลา ผู้ใช้งานจะเริ่มเห็นคำแนะนำในการเปิดใช้งาน 2FA บน GitHub อีก 1 สัปดาห์ และหากยังไม่ดำเนินการ ก็จะถูกบล็อกไม่ให้เข้าถึงฟีเจอร์ของ GitHub ได้

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

ที่มา : bleepingcomputer

Dropbox ออกมายอมรับเหตุการณ์ข้อมูลรั่วไหล ซึ่งเกิดจากการที่ผู้โจมตีสามารถขโมย code repositories ของบริษัทออกไปกว่า 130 รายการ ภายหลังจากการเข้าถึงบัญชี GitHub โดยใช้ข้อมูลส่วนตัวของพนักงานที่ถูกขโมยจากการโจมตีแบบฟิชชิ่ง

บริษัทพบว่าถูกแฮ็กเมื่อวันที่ 14 ตุลาคม 2565 ที่ผ่านมา เมื่อ GitHub แจ้งว่ามีพฤติกรรมที่น่าสงสัย ซึ่งเกิดขึ้นหนึ่งวันก่อนที่จะมีการส่งการแจ้งเตือน จนถึงปัจจุบัน (1 พฤศจิกายน 2565) จากการตรวจสอบพบว่าข้อมูลที่ผู้โจมตีรายนี้เข้าถึงส่วนใหญ่เป็นคีย์ API ที่ใช้โดยนักพัฒนาของ Dropbox ซึ่งรวมไปถึง source code, ข้อมูลชื่อ และที่อยู่อีเมลกว่า 2000-3000 รายการ ทั้งของพนักงาน Dropbox ของลูกค้าปัจจุบัน และลูกค้าในอดีต ซึ่งปัจจุบัน Dropbox มีผู้ใช้งานที่ลงทะเบียนมากกว่า 700 ล้านคน

การโจมตีเริ่มมาจากอีเมลฟิชชิ่งที่ถูกส่งไปยังพนักงานของ Dropbox หลายคน โดยการใช้อีเมลปลอมที่แอบอ้างเป็นแพลตฟอร์ม CircleCI ซึ่งเมื่อคลิกลิงค์ จะถูก redirect ไปยังหน้า Landing Page ของฟิชชิ่งให้กรอกชื่อผู้ใช้ และรหัสผ่านของ GitHub รวมไปถึงการขอให้กรอก "One Time Password (OTP)” ด้วย

อีเมลฟิชชิ่งที่แอบอ้างเป็น CircleCI

หลังจากสามารถขโมยข้อมูลส่วนตัวของพนักงานของ Dropbox ได้ ผู้โจมตีจึงสามารถเข้าถึง GitHub ของ Dropbox และขโมย code repositories ออกไปกว่า 130 รายการ ซึ่งประกอบไปด้วยข้อมูลสำเนาของไลบรารีของ third-party ที่มีการปรับเปลี่ยนสำหรับการใช้งานของ Dropbox, ผลิตภัณฑ์ต้นแบบที่ใช้ภายใน, เครื่องมือ และ configuration files ที่ใช้โดย Security Team แต่ Dropbox ยืนยันว่า แฮ็กเกอร์ไม่สามารถเข้าถึง core apps หรือ infrastructure หลักได้ รวมไปถึงบัญชี รหัสผ่าน หรือข้อมูลการชําระเงินของลูกค้า เนื่องจากระบบเหล่านั้นมีการรักษาความปลอดภัยที่เข้มงวดมากกว่า

เพื่อตอบสนองต่อเหตุการณ์ที่เกิดขึ้น Dropbox กําลังดําเนินการด้านความปลอดภัยเพิ่มเติม โดยการใช้ WebAuthn และ hardware tokens หรือ biometric factors

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

โดย GitHub ระบุว่ามักจะพบการขโมยข้อมูลออกไปทันทีหลังจากที่บัญชีของผู้ใช้งานถูกเข้าถึงได้ โดยจากการตรวจสอบพบว่าผู้โจมตีส่วนใหญ่จะใช้ VPN หรือบริการ Proxy เพื่อทำให้ติดตามได้ยากขึ้น

ที่มา : bleepingcomputer.

บัญชี GitHub ถูกแฮ็กโดยผู้ไม่หวังดีที่แอบอ้างเป็นแพลตฟอร์ม CircleCI DevOps ผ่านทางแคมเปญฟิชชิ่งที่กำหนดเป้าหมายไปยังผู้ใช้งาน GitHub เพื่อขโมย credentials และ two-factor authentication (2FA)

ลักษณะการโจมตีของผู้โจมตี

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

โดยเป้าหมายของผู้โจมตีเพื่อขโมยข้อมูล credentials ของบัญชี GitHub และ two-factor authentication (2FA)
หลังจากผู้โจมตีสามารถขโมย credentials ได้สำเร็จ จะทำการสร้าง personal access tokens (PATs) เพื่ออนุญาตโปรแกรม OAuth และเพิ่มคีย์ SSH ให้สามารถได้รับการเข้าถึงบัญชีโดยไม่ได้รับอนุญาต

โดเมนจริงของ CircleCI คือ [circleci.

พบช่องโหว่ Zero-day ในแอปพลิเคชัน 7-zip โดยช่องโหว่ที่พบนี้สามารถยกระดับสิทธิ์ผู้โจมตีให้เป็นผู้ดูแลระบบได้ ช่องโหว่นี้ถูกค้นพบโดยผู้ใช้ GitHub ที่ชื่อว่า Kagancapar โดยมีหมายเลข CVE-2022-29072

7-zip เป็นแอปพลิเคชันที่สามารถใช้งานได้หลายแพลตฟอร์ม แต่ช่องโหว่นี้ส่งผลกระทบกับ Windows โดยตรง เนื่องการโจมตีต้องอาศัย Windows help application ที่ชื่อว่า hh.

Spring ได้ออกแพตซ์อัปเดตเร่งด่วนเพื่อแก้ไขช่องโหว่ Zero-day remote code execution ของ 'Spring4Shell' ซึ่งก่อนหน้านี้มีข้อมูลรายละเอียดของช่องโหว่ และโค้ดที่ใช้การโจมตีถูกปล่อยออกมา ก่อนที่จะมีแพตช์อัปเดตเพื่อแก้ไขช่องโหว่ดังกล่าว

เมื่อวานนี้ (30 มีนาคม 2022) มีการพบ exploit code ที่ใช้สำหรับโจมตีช่องโหว่ remote code execution ใน Spring Framework ที่มีชื่อว่า 'Spring4Shell' มีการเผยแพร่อยู่บน GitHub และได้ถูกลบออกไปแล้ว อย่างไรก็ตามข้อมูลได้ถูกแชร์ออกไปอย่างรวดเร็ว และได้มีการทดสอบโดยนักวิจัยด้านความปลอดภัย ซึ่งยืนยันว่าสามารถใช้ในการโจมตีได้จริง

Spring ได้ออกคำแนะนำด้านความปลอดภัยโดยแจ้งว่าช่องโหว่นี้ (CVE-2022-22965) จะส่งผลกระทบต่อแอปพลิเคชัน Spring MVC และ Spring WebFlux ใน JDK 9

การโจมตีช่องโหว่ดังกล่าวต้องใช้ Apache Tomcat, แอปพลิเคชันแพ็คเกจ WAR และ "spring-webmvc หรือ spring-webflux" dependencies

ช่องโหว่ดังกล่าวส่งผลกระทบกับแอปพลิเคชัน Spring MVC และ Spring WebFlux ที่ทำงานบน JDK 9+ ซึ่งการโจมตีจะสำเร็จได้ก็ต่อเมื่อ แอปพลิเคชันที่ทำงานบน Tomcat ที่ถูกติดตั้งในรูปแบบ WAR

หากแอปพลิเคชันถูกติดตั้งเป็น Jar เป็นค่าเริ่มต้น จะไม่มีความเสี่ยงต่อการถูกโจมตี อย่างไรก็ตามช่องโหว่ดังกล่าวมีรายละเอียดที่ค่อนข้างกว้าง และอาจมีวิธีอื่นในการใช้ประโยชน์จากช่องโหว่ดังกล่าว (more…)

Omer Gil และทีม พบช่องโหว่ซึ่งเป็นส่วนหนึ่งของ DevOps ตาม Blog และได้แจ้งกับทาง Information Security Media Group ว่าต้องมีการตรวจสอบกลไกในการตรวจสอบบน GitHub และเนื่องจาก GitHub Actions เป็นส่วนที่มีการติดตั้งเป็นค่า default เบื้องต้นทำให้มีผลต่อองค์กรที่มีการใช้งานทุกที่

GitHub เป็นแพลตฟอร์มในการพัฒนาซอฟต์แวร์ที่ใช้ควบคุมการดำเนินการแก้ไข การตรวจสอบการดำเนินการต่างๆใน Codeโปรแกรมต่างๆที่ทางผู้พัฒนาโปรแกรมได้ทำการสร้างขึ้น โดย GitHub Action คือการส่งต่อข้อมูลที่ทางผู้พัฒนาได้มีการแก้ไข สร้าง workflows เพื่อทำการส่งต่อไปยัง production

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

โดย GITHUB_TOKEN จะทำงานควบคู่กับ PR (การตรวจสอบทบทวนสิ่งที่มีการขอ merge request) User สามารถทบทวนสิ่งที่ผู้ใช้งานบางคนทำการเปลี่ยนแปลงแก้ไข ก่อนที่จะส่งไปยังระบบงาน production เมื่อ PR ถูกสร้างขึ้นมาจะไม่สามารถ merge ข้อมูลรวมกันได้เนื่องจากจะต้องมีการอนุมัติเสียก่อน แต่ในการโจมตีนี้ workflows จะทำงานทันทีเมื่อมีการอนุญาตจาก PR โดย github-actions bot

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

ที่มา: bankinfosecurity.

เมื่อเดือนที่แล้ว Cloudflare บริษัทผู้ให้บริการระบบเครือข่าย network และรักษาความปลอดภัยเว็บไซต์ ได้แก้ไขช่องโหว่ที่สำคัญในไลบรารี CDNJS ซึ่งมีการใช้งานอยู่ที่ 12.7% ของเว็บไซต์ทั้งหมดบนอินเทอร์เน็ต

CDNJS เป็นเครือข่ายการส่งเนื้อหา (Content Delivery Network) แบบโอเพ่นซอร์สที่ให้บริการฟรี ซึ่งให้บริการไลบรารี JavaScript และ CSS ประมาณ 4,041 รายการ ทำให้เป็น CDN ไลบรารี JavaScript ที่ได้รับความนิยมสูงสุดเป็นอันดับสองรองจาก Google Hosted Libraries

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

ช่องโหว่ดังกล่าวถูกค้นพบและรายงานโดยนักวิจัยด้านความปลอดภัย RyotaK เมื่อวันที่ 6 เมษายน พ.ศ. 2564 ซึ่งยังไม่พบหลักฐานว่ามีการใช้ช่องโหว่นี้ในการโจมตีจริง

ช่องโหว่นี้ทำงานโดยการส่งแพ็คเกจไปยัง CDNJS ของ Cloudflare โดยใช้ GitHub และ npm ใช้เพื่อทริกเกอร์ช่องโหว่ path traversal และท้ายที่สุดคือทำให้เซิร์ฟเวอร์สามารถเรียกใช้โค้ดจากระยะไกลได้ น่าสังเกตว่าโครงสร้างพื้นฐานของ CDNJS มีการอัปเดตไลบรารีเป็นอัตโนมัติโดยเรียกใช้สคริปต์บนเซิร์ฟเวอร์เป็นระยะ เพื่อดาวน์โหลดไฟล์ที่เกี่ยวข้องจากที่เก็บ Git ซึ่งมีการจัดการโดยผู้ใช้หรือรีจิสตรีแพ็กเกจ npm

RyotaK พบว่า "สามารถเรียกใช้โค้ดได้ หลังจากดำเนินการ path traversal จากไฟล์ .tgz ไปยัง npm และเขียนทับสคริปต์ที่ทำงานเป็นประจำบนเซิร์ฟเวอร์" และ “ช่องโหว่นี้สามารถโจมตีได้โดยไม่ต้องใช้ทักษะพิเศษใดๆ แต่ก็สามารถส่งผลกระทบต่อเว็บไซต์จำนวนมากได้ ทำให้เป็นไปได้ว่าจะเกิดการโจมตีช่องโหว่นี้ในลักษณะ Supply-chain ได้"

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

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

ที่มา : thehackernews

จากที่ Microsoft ออกแพตช์ฉุกเฉินเพื่อเเก้ไขช่องโหว่ Zero-day สำหรับ Microsoft Exchange ที่ผ่านมาเมื่อวันที่ 2 มีนาคม 2021 ปัจจุบันกลุ่มช่องโหว่ดังกล่าวที่ถูกตั้งชื่อว่า ProxyLogon (https://proxylogon.

กลุ่มนักวิจัยจาก Malwarebytes ออกรายงานแจ้งเตือนกลุ่ม APT ใหม่ภายใต้ชื่อ LazyScripter ซึ่งมีความเคลื่อนไหวมาตั้งแต่ปี 2018 โดยมีจุดน่าสนใจสำคัญคือการมีเป้าหมายการโจมตีอยู่ในอุตสาหกรรมและสายการบิน

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

เนื่องลักษณะของการใช้มัลแวร์แบบโอเพนซอร์ส รวมไปถึงใช้เครื่องมือในการทดสอบเจาะระบบอย่าง Empire framework ในปฏิบัติการ การเชื่อมโยงกลุ่มผู้โจมตีกลุ่มใหม่นี้ให้เข้ากับฐานข้อมูลภัยคุกคามที่เป็นที่รู้จักนั้นย่อมทำได้ยาก ทั้งนี้ Malwarebytes มีการตั้งสมมติฐานเกี่ยวกับความเกี่ยวข้องของ LazyScripter ออกเป็น 2 แนวทาง โดยแนวทางแรกนั้นเกี่ยวข้องกับกลุ่ม MuddyWater ของประเทศอิหร่าน และอีกแนวทางหนึ่งนั้นเกี่ยวข้องกับกลุ่ม APT28 จากรัสเซีย ซึ่งในขณะนี้น้ำหนักค่อนข้างเทไปที่ฝั่งของ MuddyWater มากกว่าทั้งในเรื่องเครื่องมือที่ใช้ พฤติกรรมและเป้าหมาย

ผู้ที่สนใจสามารถอ่านรายงานต้นฉบับของ MalwareBytes ได้ที่ malwarebytes

ที่มา: bleepingcomputer