กังวลเกี่ยวกับ Exchange Zero-Day หรือไม่? นี่คือสิ่งที่ต้องทำ PlatoBlockchain Data Intelligence ค้นหาแนวตั้ง AI.

กังวลเกี่ยวกับการแลกเปลี่ยน Zero-Day หรือไม่? นี่คือสิ่งที่ต้องทำ

Microsoft ยืนยันแล้ว ช่องโหว่ Zero-day ใหม่สองช่องโหว่ใน Microsoft Exchange Server (CVE-2022-41040 และ CVE-2022-41082) กำลังถูกโจมตีใน "การโจมตีแบบจำกัดเป้าหมาย" ในกรณีที่ไม่มีโปรแกรมแก้ไขอย่างเป็นทางการ องค์กรควรตรวจสอบสภาพแวดล้อมของพวกเขาเพื่อหาสัญญาณของการเอารัดเอาเปรียบ และจากนั้นใช้ขั้นตอนการบรรเทาเหตุฉุกเฉิน

  • CVE-2022-41040 — การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ ทำให้ผู้โจมตีที่ตรวจสอบสิทธิ์แล้วส่งคำขอโดยอ้างว่าเป็นเครื่องที่ได้รับผลกระทบ
  • CVE-2022-41082 — การเรียกใช้โค้ดจากระยะไกล ซึ่งช่วยให้ผู้โจมตีที่ตรวจสอบสิทธิ์สามารถเรียกใช้ PowerShell ได้ตามอำเภอใจ

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

ขั้นตอนการตรวจจับการเอารัดเอาเปรียบ

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

ตาม GTSC องค์กรสามารถตรวจสอบว่า Exchange Server ของตนถูกโจมตีแล้วหรือไม่โดยเรียกใช้คำสั่ง PowerShell ต่อไปนี้:

รับ-ChildItem -Recurse -Path -Filter "*.log" | Select-String -Pattern 'powershell.*Autodiscover.json.*@.*200 .'

GTSC ยังได้พัฒนาเครื่องมือในการค้นหาสัญญาณของการเอารัดเอาเปรียบและ เผยแพร่บน GitHub. รายการนี้จะได้รับการอัปเดตเมื่อบริษัทอื่นเปิดตัวเครื่องมือของตน

เครื่องมือเฉพาะของ Microsoft

  • ตามที่ Microsoftมีการสืบค้นข้อมูลใน Microsoft Sentinel ที่สามารถใช้ค้นหาภัยคุกคามเฉพาะนี้ได้ หนึ่งในคำถามดังกล่าวคือ แลกเปลี่ยน SSRF Autodiscover ProxyShell การตรวจหา ซึ่งสร้างขึ้นเพื่อตอบสนองต่อ ProxyShell ใหม่ ดาวน์โหลดไฟล์ที่น่าสงสัยของ Exchange Server แบบสอบถามจะค้นหาการดาวน์โหลดที่น่าสงสัยในบันทึก IIS โดยเฉพาะ
  • การแจ้งเตือนจาก Microsoft Defender for Endpoint เกี่ยวกับการติดตั้งเว็บเชลล์ที่เป็นไปได้, เว็บเชลล์ IIS ที่เป็นไปได้, การดำเนินการกระบวนการแลกเปลี่ยนที่น่าสงสัย, การใช้ประโยชน์จากช่องโหว่ของ Exchange Server ที่เป็นไปได้, กระบวนการที่น่าสงสัยที่บ่งบอกถึงเว็บเชลล์ และการประนีประนอม IIS ที่เป็นไปได้อาจเป็นสัญญาณว่า Exchange Server ได้รับ ถูกบุกรุกผ่านช่องโหว่ทั้งสอง
  • Microsoft Defender จะตรวจจับความพยายามหลังการแสวงประโยชน์เป็น แบ็คดอร์:ASP/Webshell.Y และ แบ็คดอร์:Win32/RewriteHttp.A.

ผู้จำหน่ายระบบรักษาความปลอดภัยหลายรายได้ประกาศอัปเดตผลิตภัณฑ์ของตนเพื่อตรวจหาการแสวงประโยชน์เช่นกัน

Huntress กล่าวว่าได้เฝ้าติดตามเซิร์ฟเวอร์ Exchange ประมาณ 4,500 เซิร์ฟเวอร์ และขณะนี้กำลังตรวจสอบเซิร์ฟเวอร์เหล่านั้นเพื่อหาสัญญาณที่อาจมีการเอารัดเอาเปรียบในเซิร์ฟเวอร์เหล่านี้ “ในขณะนี้ Huntress ไม่เห็นสัญญาณของการเอารัดเอาเปรียบหรือสัญญาณบ่งชี้การประนีประนอมบนอุปกรณ์ของพันธมิตรของเรา” Hammond เขียน

ขั้นตอนการบรรเทาสาธารณภัยที่ต้องทำ

Microsoft สัญญาว่าจะดำเนินการแก้ไขอย่างรวดเร็ว ระหว่างนี้ องค์กรต่างๆ ควรใช้การบรรเทาปัญหาต่อไปนี้กับ Exchange Server เพื่อปกป้องเครือข่ายของตน

ตาม Microsoft ลูกค้า Microsoft Exchange ในสถานที่ควรใช้กฎใหม่ผ่านโมดูล URL Rewrite Rule บนเซิร์ฟเวอร์ IIS

  • ใน IIS Manager -> Default Web Site -> Autodiscover -> URL Rewrite -> Actions เลือก Request Blocking และเพิ่มสตริงต่อไปนี้ในเส้นทาง URL:
.*autodiscover.json.*@.*Powershell.*

อินพุตเงื่อนไขควรตั้งค่าเป็น {REQUEST_URI}

  • บล็อกพอร์ต 5985 (HTTP) และ 5986 (HTTPS) เนื่องจากใช้สำหรับ Remote PowerShell

หากคุณกำลังใช้ Exchange Online:

Microsoft กล่าวว่าลูกค้า Exchange Online จะไม่ได้รับผลกระทบและไม่ต้องดำเนินการใดๆ อย่างไรก็ตาม องค์กรที่ใช้ Exchange Online มีแนวโน้มที่จะมีสภาพแวดล้อม Exchange แบบไฮบริด โดยมีการผสมผสานระหว่างระบบภายในองค์กรและระบบคลาวด์ พวกเขาควรปฏิบัติตามคำแนะนำข้างต้นเพื่อปกป้องเซิร์ฟเวอร์ภายในองค์กร

ประทับเวลา:

เพิ่มเติมจาก การอ่านที่มืด