S3 Ep102.5: ข้อบกพร่องการแลกเปลี่ยน “ProxyNotShell” – ผู้เชี่ยวชาญพูด [เสียง + ข้อความ]

คลิกแล้วลากบนคลื่นเสียงด้านล่างเพื่อข้ามไปยังจุดใดก็ได้ นอกจากนี้คุณยังสามารถ ฟังโดยตรง บนซาวด์คลาวด์

[โมเด็มดนตรี]

---

เป็ด.  สวัสดีทุกคน.

ยินดีต้อนรับสู่มินิตอนพิเศษอีกตอนของพอดคาสต์ Naked Security

ฉันชื่อ พอล ดัคลิน เชสเตอร์ วิสเนียวสกี้ เพื่อนและเพื่อนร่วมงานของฉันเข้าร่วมอีกครั้ง

สวัสดีคุณเชษฐ์

---

เชษฐ์.  [FAKE AUSSIE ACCENT] จีเดย์ ดั๊ก

---

เป็ด.  เชษฐ์ มั่นใจว่าทุกคนฟัง หากพวกเขากำลังฟังหลังจากพอดแคสต์ออกมาได้ไม่นาน ก็รู้ว่าเรากำลังจะพูดถึงอะไร!

และมันต้องสองลำกล้องนี้ Microsoft Exchange ซีโร่เดย์ ที่ออกมาซักค่อนข้างมากในวันสุดท้ายของเดือนกันยายน 2022:

เพื่อนฝ่ายขายของเรากำลังดำเนินการ "โอ้ สิ้นเดือน สิ้นไตรมาส เป็นเวลาที่วุ่นวาย...แต่พรุ่งนี้ทุกคนจะได้รับการรีเซ็ตเป็น 0 เหรียญ"

สุดสัปดาห์นี้สำหรับ Sysadmins และผู้จัดการ IT จะไม่เป็นเช่นนั้น!

---

เชษฐ์.  ฉันคิดว่าเป็ดในคำพูดอมตะของดักลาสอดัมส์ผู้จากไปอย่างสุดซึ้ง "อย่าตื่นตกใจ" อาจจะเป็นระเบียบ

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

แต่ถ้าคุณใช้ Exchange on-premise...

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

---

เป็ด.  มันคือ CVE-2022-41040 และ CVE-2022-41042… ค่อนข้างปากแข็ง

ฉันเห็นมันถูกอ้างถึงใน Twitter ว่า พร็อกซีNotShellเพราะมันมีความคล้ายคลึงกับ พร็อกซีเชลล์ ช่องโหว่ที่เป็นเรื่องใหญ่เมื่อประมาณปีที่แล้ว

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

---

เชษฐ์.  นั่นคือสิ่งที่ดูเหมือน

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

ดูเหมือนว่าพวกเขาเปิดเผยอย่างมีความรับผิดชอบ ช่องโหว่เหล่านั้น ไปยัง Zero Day Initiative [ZDI] ที่ดำเนินการโดย Trend Micro เพื่อรายงานช่องโหว่ Zero-day อย่างมีความรับผิดชอบ

และแน่นอนว่า ZDI ได้แบ่งปันความฉลาดทั้งหมดนั้นกับ Microsoft เมื่อสามสัปดาห์ก่อน

และที่ออกวันนี้ก็เพราะว่าวงเวียดนาม...

…ดูเหมือนว่าพวกเขาจะหมดความอดทนเล็กน้อยและกังวลว่าสามสัปดาห์แล้วและไม่มีการเตือนหรือคำแนะนำใด ๆ เพื่อช่วยปกป้องผู้คนจากผู้ถูกกล่าวหาว่าเป็นคนรัฐ

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

---

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

ดูเหมือนว่าการเอารัดเอาเปรียบด้วยตัวเองจะไม่เป็นอันตรายอย่างยิ่ง...

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

---

เชษฐ์.  และนั่นเป็นประเด็นสำคัญที่ต้องทำ เป็ด ที่คุณพูดว่า “คนที่สามารถอ่านอีเมลบนเซิร์ฟเวอร์ของคุณได้”

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

---

เป็ด.  ตอนนี้ เราไม่รู้แน่ชัดว่าพวกเขาต้องการข้อมูลประจำตัวประเภทใด เพราะในขณะที่เรากำลังบันทึก [2022-09-30T23:00:00Z] ทุกอย่างยังคงเป็นความลับเป็นส่วนใหญ่

แต่จากสิ่งที่ฉันอ่าน (จากคนที่ฉันเชื่อ) ดูเหมือนว่าคุกกี้เซสชันหรือโทเค็นการพิสูจน์ตัวตนยังไม่เพียงพอ และคุณจะต้องใช้รหัสผ่านของผู้ใช้จริงๆ

หลังจากที่ให้รหัสผ่านแล้ว อย่างไรก็ตาม หากมีการตรวจสอบสิทธิ์แบบสองปัจจัย [2FA] บั๊กแรก (ตัวที่เปิดประตู) จะถูกทริกเกอร์ *ระหว่างจุดที่ให้รหัสผ่านกับจุดที่รหัส 2FA จะเป็น ขอ*.

ดังนั้นคุณต้องมีรหัสผ่าน แต่คุณไม่จำเป็นต้องใช้รหัส 2FA...

---

เชษฐ์.  ดูเหมือนว่ามันจะเป็น “ช่องโหว่ของการตรวจสอบสิทธิ์ระดับกลาง” ถ้าคุณต้องการเรียกมันว่า

นั่นเป็นพรที่หลากหลาย

หมายความว่าสคริปต์ Python แบบอัตโนมัติไม่สามารถสแกนอินเทอร์เน็ตทั้งหมดและอาจใช้ประโยชน์จากเซิร์ฟเวอร์ Exchange ทุกเครื่องในโลกในเวลาไม่กี่นาทีหรือหลายชั่วโมง ดังที่เราเห็นแล้วว่าเกิดขึ้นกับ ProxyLogon และ ProxyShell ในปี 2021

เราเห็นการกลับมาของเวิร์มในช่วง 18 เดือนที่ผ่านมา ซึ่งสร้างความเสียหายให้กับหลายองค์กร

---

เป็ด.  “วอร์เมจ”?

---

เชษฐ์.  เวิร์ม ใช่! [หัวเราะ]

---

เป็ด.  นั่นคือคำ?

ถ้าไม่ใช่ก็คือตอนนี้!

ฉันชอบแบบนั้น… ฉันอาจจะยืมมัน เชสเตอร์ [หัวเราะ]

---

เชษฐ์.  ฉันคิดว่าสิ่งนี้สามารถเวิร์มได้เล็กน้อยใช่ไหม

คุณต้องมีรหัสผ่าน แต่การค้นหาที่อยู่อีเมลและรหัสผ่านชุดเดียวที่ใช้ได้กับเซิร์ฟเวอร์ Exchange ที่ระบุอาจไม่ใช่เรื่องยากเกินไป

เมื่อคุณพูดถึงผู้ใช้หลายร้อยหรือหลายพันคน... ในหลายองค์กร หนึ่งหรือสองคนมีแนวโน้มที่จะมีรหัสผ่านที่ไม่ดี

และคุณอาจไม่ได้ถูกเอารัดเอาเปรียบมาจนถึงทุกวันนี้ เพราะการเข้าสู่ระบบ Outlook Web Access [OWA] ได้สำเร็จนั้นต้องใช้โทเค็น FIDO หรือตัวตรวจสอบสิทธิ์ หรือปัจจัยที่สองที่คุณอาจใช้อยู่

แต่การโจมตีครั้งนี้ไม่ต้องการปัจจัยที่สอง

ดังนั้น การรับชื่อผู้ใช้และรหัสผ่านร่วมกันจึงเป็นอุปสรรคที่ค่อนข้างต่ำ...

---

เป็ด.  ตอนนี้มีความซับซ้อนอื่นที่นี่ใช่ไหม

กล่าวคือถึงแม้ว่า แนวทางของไมโครซอฟต์ กล่าวอย่างเป็นทางการว่าลูกค้า Microsoft Exchange Online สามารถยืนหยัดจาก Blue Alert ได้ เฉพาะเมื่อคุณมี Exchange ภายในองค์กรเท่านั้น...

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

---

เชษฐ์.  แม่นยำ!

เราเห็นสิ่งนี้ย้อนกลับไปที่ ProxyLogin และ ProxyShell

ในหลายกรณี อาชญากรได้เข้าสู่เครือข่ายของพวกเขาผ่านเซิร์ฟเวอร์ Exchange ที่พวกเขาคิดว่าไม่มี

เช่น บางคนไม่ได้ตรวจสอบรายการ VM ที่ทำงานบนเซิร์ฟเวอร์ VMware ของตนเพื่อสังเกตว่าเซิร์ฟเวอร์ Exchange ที่ย้ายข้อมูลซึ่งช่วยเหลือพวกเขาในระหว่างการยกข้อมูลระหว่างเครือข่ายภายในองค์กรและเครือข่ายคลาวด์...

… แท้จริงแล้วยังคงเปิดอยู่ เปิดใช้งาน และเปิดเผยต่ออินเทอร์เน็ต

และที่แย่กว่านั้นคือ เมื่อไม่รู้ว่าพวกมันอยู่ที่นั่น พวกเขาก็มีโอกาสน้อยที่จะได้รับการแก้ไข

ฉันหมายถึง องค์กรที่มี Exchange อย่างน้อยอาจพยายามจัดตารางการบำรุงรักษาเป็นประจำ

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

---

เป็ด.  และกฎของเมอร์ฟีบอกว่าถ้าคุณพึ่งพาเซิร์ฟเวอร์นั้นจริงๆ และไม่ได้ดูแลเซิร์ฟเวอร์อย่างถูกต้อง เซิร์ฟเวอร์จะล่มก่อนคุณจำเป็นต้องใช้จริงๆ หนึ่งวัน

แต่ถ้าคุณไม่รู้ว่ามันมีอยู่จริงและมันสามารถใช้ได้ในทางที่แย่ โอกาสที่มันจะใช้งานได้นานหลายปีและหลายปีโดยไม่มีปัญหาใดๆ เลยก็อาจจะค่อนข้างสูง [หัวเราะ]

---

เชษฐ์.  ใช่ น่าเสียดาย นั่นเป็นประสบการณ์ของฉันอย่างแน่นอน!

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

แต่แน่นอน เมื่อคุณได้ยินเกี่ยวกับกระดานข่าวแบบนี้ ถ้าเป็นผลิตภัณฑ์ที่คุณรู้ว่าคุณเคยใช้ในอดีต เช่น Microsoft Exchange ก็เป็นเวลาที่ดีที่จะเรียกใช้งานภายในนั้น การสแกน Nmap...

…และอาจถึงขั้นเข้าสู่ระบบ shodan.io และตรวจสอบบริการภายนอกของคุณ เพื่อให้แน่ใจว่าทุกอย่างปิดอยู่

---

เป็ด.  ตอนนี้เราทราบจากการตอบสนองของ Microsoft แล้วว่าพวกเขากำลังหลบหนีอย่างบ้าคลั่งเพื่อเอาแพตช์ออก

เมื่อแผ่นแปะเหล่านั้นปรากฏขึ้น คุณควรใช้มันอย่างครึกครื้นอย่างรวดเร็ว ใช่ไหม?

เพราะหากมีแพตช์ใด ๆ ที่มุ่งเป้าไปที่วิศวกรรมย้อนกลับเพื่อหาช่องโหว่ มันจะมีลักษณะแบบนี้

---

เชษฐ์.  ใช่เลย เป็ด!

แม้แต่เมื่อคุณแพทช์ มันก็จะมีกรอบเวลาใช่ไหม?

ฉันหมายถึง โดยปกติแล้ว Microsoft สำหรับ Patch Tuesday อยู่แล้ว ให้ปล่อยแพตช์ในเวลา 10.00 น. ตามเวลาแปซิฟิก

ขณะนี้เราอยู่ในเวลาออมแสง ซึ่งเป็นเวลา UTC-7… ดังนั้น ประมาณ 17:00 UTC ปกติจะเป็นช่วงที่ Microsoft ออกแพตช์ เพื่อให้พนักงานส่วนใหญ่มีเวลาทั้งวันเพื่อตอบคำถามที่เข้ามาในซีแอตเทิล [Microsoft HQ อยู่ใน Bellevue, Seattle, WA]

กุญแจสำคัญที่นี่คือ "การแข่งขัน" ของชั่วโมง อาจเป็นนาที ขึ้นอยู่กับความง่ายในการใช้ประโยชน์จากสิ่งนี้ ก่อนที่มันจะเริ่มเกิดขึ้น

และอีกครั้ง เมื่อย้อนกลับไปที่การใช้ประโยชน์จาก Exchange ก่อนหน้านี้ด้วย ProxyShell และ ProxyLogon เรามักจะพบว่าแม้แต่ลูกค้าที่ทำการแพตช์ภายในสาม สี่ หรือห้าวัน...

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

นั่นก็เพียงพอแล้วสำหรับเซิร์ฟเวอร์เหล่านั้นที่จะได้รับ เว็บเชลล์, cryptominers, ทุกชนิด แบ็ค ติดตั้งบนพวกเขา

ดังนั้น เมื่อแพตช์อย่างเป็นทางการออกมา คุณไม่เพียงแค่ต้องดำเนินการอย่างรวดเร็ว...

…*หลังจาก* คุณลงมือ เป็นการดีที่จะกลับไปตรวจสอบระบบเหล่านั้นอย่างละเอียดเพื่อหาหลักฐานที่อาจเป็นไปได้ว่าพวกเขาถูกโจมตีในช่องว่างระหว่างเวลาที่แพทช์พร้อมใช้งานและเมื่อคุณสามารถใช้มันได้

ฉันแน่ใจว่าจะมีการสนทนามากมายเกี่ยวกับ Naked Security และใน Twitter และที่อื่นๆ พูดถึงประเภทของการโจมตีที่เราเห็น เพื่อให้คุณรู้ว่าควรมองหาอะไร

---

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

…จริงๆ แล้ว สิ่งที่สำคัญที่สุดคือมัลแวร์ทุกประเภทมีความเป็นไปได้

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

คุณต้องออกไปในเชิงรุกและคอยดู เผื่อว่าพวกมิจฉาชีพจะอยู่ในเครือข่ายของคุณแล้ว และพวกเขาได้ทิ้งบางสิ่งไว้เบื้องหลัง (ซึ่งอาจมีมานานแล้ว!) ที่คุณยังไม่ได้สังเกต

---

เชษฐ์.  ดังนั้นฉันคิดว่านั่นนำเราไปสู่ “เราจะทำยังไงกันดี ระหว่างที่รอแพตช์”

บล็อก Microsoft Security Research Center (MSRC) เผยแพร่แล้ว คำแนะนำในการบรรเทาทุกข์ และรายละเอียด… เท่าที่ Microsoft ยินดีที่จะเปิดเผยในเวลานี้

ฉันจะบอกว่าถ้าคุณเป็นคนบริสุทธิ์ Microsoft Exchange ออนไลน์ ลูกค้าคุณค่อนข้างชัดเจนและคุณควรใส่ใจในกรณีที่สิ่งต่าง ๆ เปลี่ยนไป

แต่ถ้าคุณอยู่ในสถานการณ์แบบไฮบริด หรือคุณยังคงใช้งาน Microsoft Exchange ภายในองค์กร ฉันคิดว่าอาจมีงานบางอย่างที่คุ้มค่าที่จะทำในบ่ายวันนี้หรือเช้าพรุ่งนี้ หากไม่มีอย่างอื่น

แน่นอน ตอนที่อัดเสียง นี่คือบ่ายวันศุกร์… ดังนั้น จริงๆ แล้ว เมื่อคุณกำลังฟังสิ่งนี้อยู่ “ทันทีที่คุณได้ยิน ถ้าคุณยังไม่ได้ฟัง”

อะไรคือแนวทางปฏิบัติที่ดีที่สุดที่นี่ Duck?

แน่นอน สิ่งหนึ่งที่คุณสามารถทำได้คือปิดการเข้าถึงเว็บภายนอกจนกว่าจะมีโปรแกรมแก้ไข

คุณสามารถปิดเซิร์ฟเวอร์ IIS ของคุณแล้วเสร็จ!

---

เป็ด.  ฉันสงสัยว่าหลาย บริษัท จะไม่อยู่ในตำแหน่งนั้น

และไมโครซอฟต์แสดงรายการสองสิ่งที่พวกเขาพูด… พวกเขาไม่ได้พูดว่า “วิธีนี้ได้ผลแน่นอน”

พวกเขาแนะนำว่ามันจะจำกัดความเสี่ยงของคุณอย่างมาก

หนึ่งคือมีกฎการเขียน URL ใหม่ที่คุณสามารถใช้กับเซิร์ฟเวอร์ IIS ของคุณได้ (ความเข้าใจของฉันคือ IIS เองที่ยอมรับการเชื่อมต่อขาเข้าที่เปลี่ยนเป็นการเข้าถึง Exchange Web Services [EWS])

ดังนั้นจึงมีการตั้งค่า IIS ที่คุณสามารถทำได้ซึ่งจะมองหาการใช้ประโยชน์จากช่องโหว่แรก ซึ่งจะป้องกันไม่ให้ PowerShell เริ่มทำงาน

และมีพอร์ต TCP บางพอร์ตที่คุณสามารถบล็อกบน Exchange Server ของคุณได้

เชื่อแล้วว่าพอร์ต 5985 และ 5986 จะหยุดสิ่งที่เรียกว่า PowerShell Remoting... จะหยุดคำสั่งการดำเนินการระยะไกล PowerShell อันธพาลที่ถูกกระตุ้นไปยังเซิร์ฟเวอร์ Exchange

อย่างไรก็ตาม โปรดทราบว่า Microsoft บอกว่าสิ่งนี้จะ “จำกัด” การเปิดเผยของคุณ แทนที่จะสัญญาว่าพวกเขารู้ว่าจะแก้ไขทุกอย่าง

และนั่นอาจเป็นเพราะพวกเขาสงสัยว่ามีวิธีอื่นที่สามารถกระตุ้นสิ่งนี้ได้ แต่พวกเขาก็ยังไม่ค่อยรู้ว่ามันคืออะไร [หัวเราะ]

การตั้งค่าทั้งสองไม่ใช่สิ่งที่คุณทำใน Exchange เอง

หนึ่งในนั้นอยู่ใน IIS และอีกประเภทหนึ่งคือกฎการกรองเครือข่ายบางประเภท

---

เชษฐ์.  จะช่วยให้เราผ่านพ้นไปได้ในอีกไม่กี่วันข้างหน้านี้ ในขณะที่ Microsoft ให้การแก้ไขอย่างถาวรแก่เรา

ข่าวดีก็คือ ฉันคิดว่าซอฟต์แวร์รักษาความปลอดภัยจำนวนมาก ไม่ว่าจะเป็น IPS ที่อาจรวมอยู่ในไฟร์วอลล์ของคุณ หรือผลิตภัณฑ์รักษาความปลอดภัยปลายทางที่คุณปกป้องโครงสร้างพื้นฐาน Microsoft Windows Server ของคุณ...

... การโจมตีสำหรับสิ่งนี้ ในหลายกรณี (อย่างน้อยก็รายงานเบื้องต้น) จะดูคล้ายกับ ProxyLogon มาก ดังนั้นจึงไม่ชัดเจนว่ากฎที่มีอยู่จะป้องกันการโจมตีเหล่านี้หรือไม่

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

---

เป็ด.  ถูกต้อง เชสเตอร์

และข่าวดีสำหรับลูกค้า Sophos ก็คือ คุณสามารถติดตามการตรวจจับเฉพาะของ Sophos ได้หากต้องการดูบันทึกของคุณ

ไม่ใช่แค่สำหรับ IPS ไม่ว่าจะเป็น IPS บนไฟร์วอลล์หรือปลายทาง แต่เรายังมีกฎด้านพฤติกรรมอีกมากมาย

คุณสามารถติดตามชื่อการตรวจจับเหล่านั้นได้หากต้องการไปหาพวกเขา... ทำตามนั้นบน @SophosXops ฟีด Twitter

เนื่องจากเราได้รับชื่อการตรวจจับใหม่ที่คุณสามารถใช้ในการไล่ล่าภัยคุกคาม เรากำลังเผยแพร่ชื่อดังกล่าวที่นั่น เพื่อให้คุณสามารถค้นหาได้อย่างง่ายดาย:

Sophos X-Ops ได้เพิ่มการตรวจจับต่อไปนี้:

Troj/WebShel-EC และ Troj/WebShel-ED ตรวจจับเว็บเชลล์ที่กล่าวถึงในการโจมตี

IPS Signature sid:2307757 ตามข้อมูลที่เผยแพร่โดย Microsoft สำหรับทั้ง Sophos XG Firewall และ Sophos Endpoint IPS

— Sophos X-Ops (@SophosXOps) September 30, 2022

---

เชษฐ์.  ฉันแน่ใจว่าเราจะมีอะไรให้พูดมากกว่านี้ในพอดคาสต์ของสัปดาห์หน้า ไม่ว่าจะเป็น Doug ที่จะเข้าร่วมกับคุณ หรือว่าฉันอยู่ในที่นั่งรับเชิญอีกครั้งหรือไม่

แต่ฉันค่อนข้างมั่นใจว่าเราจะไม่สามารถวางสิ่งนี้ลงบนเตียงได้ในขณะนี้….

---

เป็ด.  ฉันคิดว่าเหมือน ProxyShell เช่น Log4Shell จะมีเสียงก้องกังวานอยู่พักหนึ่ง

ดังนั้นบางทีเราน่าจะพูดได้ดีกว่าเหมือนเช่นเคย เชสเตอร์:

จนกว่าจะถึงครั้งต่อไป…

---

ทั้งสอง  รักษาความปลอดภัย

[โมเด็มดนตรี]