DNS Requirements for the vCenter Server Appliance, lên DNS tạo các record A, PTR
Name vCenter Server 8
vcsa.viettechgroup.lab
IP: 172.16.23.3
Host Esxi or vCenter
IP: 172.16.1.1
If you want to deploy the appliance on an ESXi host, verify that the ESXi host is not in lockdown or maintenance mode and not part of a fully automated DRS cluster
Gồm 8 bước điền các thông tin như các bước chuẩn bị
B1: Introduction -> next
B2: End user license agreement-> Chọn chấp chập và next
Bước 3: Khai báo thông tin host esxi hoặc vcenter cần triển khai
Chọn Yes trust SSL
Bước 4: Khai báo VM tên và user root của VM VCSA
Bước 5: Để default tiny
Bước 6: Chọn Datastores cần Setup
Bước 7: Bước này quan trọng khai báo về port group VM network nào cần sử dụng để VM VCSA có thể liên hệ với ADDS, khi báo như hình tùy theo nhu cầu thực tế mạng của các bạn để gỏ vào.
Bước 8: chỉ là confirm các setting vừa rồi chọn finish
và quản lý vcenter https://ip:443 bằng vsphere client html5
Đây là quản lý máy ảo của VCSA 8 nhé
Tại đây có thể cập nhật các tùy chỉnh theo ý đồ quản trị
Lưu ý ae quản trị viên hay quên, nhớ cập nhật lại lại hệ thống password không là bị change password sau 90 ngày. 😊 Ở đây tùy ae nhé. Tôi thì có mình nên chơi never expires cho chắc ăn.
Mật khẩu vẫn để phức tạp đi
Cái quản trọng nữa là backup config sau khi cấu hình ngon lành để có trường hợp còn khôi phục lại nhé.
Microsoft Outlook Zero-Day Vulnerability- Elevation of Privilege Vulnerability CVE-2023-23397
Tóm tắt:
Microsoft giải thích: CVE-2023-23397 là một lỗ hổng EoP nghiêm trọng trong Microsoft Outlook, được kích hoạt khi kẻ tấn công gửi thư có thuộc tính MAPI mở rộng với đường dẫn UNC đến chia sẻ SMB (TCP 445) trên máy chủ do tác nhân đe dọa kiểm soát. Không cần tương tác người dùng,”
Cơ chế
Kẻ tấn công đã khai thác thành công lỗ hổng này có thể truy cập hàm băm Net-NTLMv2 của người dùng, có thể được sử dụng làm cơ sở cho một cuộc tấn công Chuyển tiếp NTLM chống lại một dịch vụ khác để xác thực là người dùng.
Preview Pane
Hacker tận dụng tính Preview Pane của email Outlook Email được chế tạo đặc biệt sẽ tự động kích hoạt khi nó được ứng dụng khách Outlook truy xuất và xử lý, cung cấp một vectơ tấn công lén lút để tin tặc khai thác. “Kẻ tấn công có thể khai thác lỗ hổng này bằng cách gửi một email được chế tạo đặc biệt, email này sẽ tự động kích hoạt khi nó được ứng dụng khách Outlook truy xuất và xử lý. Điều này có thể dẫn đến việc khai thác TRƯỚC KHI email được xem trong Preview Pane,”
Các phiên bản ảnh hưởng
Tất cả các phiên bản được hỗ trợ của Microsoft Outlook (2010, 2013,2016,2019, 365Apps)cho Windows đều bị ảnh hưởng.
Các phiên bản khác của Microsoft Outlook như Android, iOS, Mac, cũng như Outlook trên web và các dịch vụ M365 khác không bị ảnh hưởng.
Biện pháp làm khắc phục:
Thêm người dùng vào Nhóm bảo mật người dùng được bảo vệ (Protected Users Security Group), ngăn việc sử dụng NTLM làm cơ chế xác thực. Việc thực hiện giảm thiểu này giúp khắc phục sự cố dễ dàng hơn so với các phương pháp vô hiệu hóa NTLM khác.
Chặn TCP 445/SMB gửi đi từ mạng của bạn bằng cách sử dụng tường lửa vành đai(DMZ), tường lửa cục bộ và thông qua cài đặt VPN. Điều này sẽ ngăn việc gửi thông báo xác thực NTLM tới chia sẻ tệp từ xa.
Máy trạm Client
Yêu cầu tất cả máy trạm của Người dùng cuối cần upgrade Microsoft Outlook cho các Phiên bản:
Microsoft Outlook 2013 (64-bit edition):https://www.microsoft.com/en-us/download/details.aspx?id=105070
Microsoft Outlook 2016 (64-bit edition):https://www.microsoft.com/en-us/download/details.aspx?id=105058
Microsoft Office LTSC 2019/2021/365 for 64-bit editions:=> Cick upgrade
Microsoft hôm thứ Ba đã phát hành các bản cập nhật bảo mật để giải quyết 75 lỗ hổng trong danh mục sản phẩm của mình, ba trong số đó đã bị khai thác tích cực trong tự nhiên.
Các bản cập nhật bổ sung cho 22 lỗ hổng mà nhà sản xuất Windows đã vá trong trình duyệt Edge dựa trên Chromium của họ trong tháng qua. Hầu hết các lỗ hổng liên quan đến lỗ hổng khai thác thực thi mã từ xa chiếm đến 47%.
Trong số 75 lỗ hổng, 9 lỗ hổng được xếp hạng Nghiêm trọng và 66 lỗ hổng được xếp hạng Quan trọng về mức độ nghiêm trọng. 37 trong số 75 lỗi được phân loại là lỗi thực thi mã từ xa (RCE). Ba zero-days của lưu ý đã được khai thác như sau:
CVE-2023-21715 (điểm CVSS: 7,3) – Lỗ hổng bỏ qua tính năng bảo mật của Microsoft Office
CVE-2023-21823 (điểm CVSS: 7,8) – Độ cao của lỗ hổng đặc quyền của Cấu phần đồ họa Windows
CVE-2023-23376 (Điểm CVSS: 7,8) – Độ cao trình điều khiển của Hệ thống tệp nhật ký chung Windows (CLFS) của lỗ hổng đặc quyền
“Bản thân cuộc tấn công được thực hiện cục bộ bởi người dùng có xác thực với hệ thống được nhắm mục tiêu”, Microsoft cho biết trong lời khuyên cho CVE-2023-21715.
“Kẻ tấn công được xác thực có thể khai thác lỗ hổng bằng cách thuyết phục nạn nhân, thông qua kỹ thuật xã hội, tải xuống và mở một tệp được chế tạo đặc biệt từ một trang web có thể dẫn đến một cuộc tấn công cục bộ vào máy tính nạn nhân.”
Việc khai thác thành công các lỗ hổng trên có thể cho phép kẻ thù bỏ qua các chính sách macro của Office được sử dụng để chặn các tệp độc hại hoặc không đáng tin cậy hoặc giành được các đặc quyền HỆ THỐNG.
CVE-2023-23376 cũng là lỗ hổng zero-day được khai thác tích cực thứ ba trong thành phần CLFS sau CVE-2022-24521 và CVE-2022-37969 (điểm CVSS: 7,8), đã được Microsoft xử lý vào tháng 4 và tháng 9 năm 2022.
Nikolas Cemerikic của Immersive Labs cho biết: “Trình điều khiển hệ thống tệp nhật ký chung của Windows là một thành phần của hệ điều hành Windows quản lý và duy trì hệ thống tệp nhật ký dựa trên giao dịch, hiệu suất cao”.
“Đây là một thành phần thiết yếu của hệ điều hành Windows và bất kỳ lỗ hổng nào trong trình điều khiển này đều có thể có ý nghĩa quan trọng đối với tính bảo mật và độ tin cậy của hệ thống.”
Cần lưu ý rằng Microsoft OneNote dành cho Android dễ bị tấn công bởi CVE-2023-21823 và với việc dịch vụ ghi chú ngày càng nổi lên như một phương tiện phát tán phần mềm độc hại , điều quan trọng là người dùng phải áp dụng các bản sửa lỗi.
Microsoft cũng giải quyết nhiều lỗi RCE trong Exchange Server, Trình điều khiển ODBC, Trình điều khiển Máy in PostScript và SQL Server cũng như các sự cố từ chối dịch vụ (DoS) ảnh hưởng đến Dịch vụ iSCSI của Windows và Kênh Bảo mật Windows.
Ba trong số các lỗ hổng Exchange Server được công ty phân loại là “Khả năng khai thác cao hơn”, mặc dù việc khai thác thành công yêu cầu kẻ tấn công phải được xác thực.
Các máy chủ Exchange đã được chứng minh là mục tiêu có giá trị cao trong những năm gần đây vì chúng có thể cho phép truy cập trái phép vào thông tin nhạy cảm hoặc tạo điều kiện cho các cuộc tấn công Thỏa hiệp email doanh nghiệp (BEC).
Đọc về lý thuyết sdwan thấy khá trừu tượng và khó hiểu. Khi mình cấu hình sdwan trên fortigate 60F thì nó có các mục sau (như trong hình):
+SDWAN zones: tại đây mình tạo mới 1 interface ảo (hoặc dùng cái mặc định có tên là virtual wan link) và add các member interfaces (là các wan interfaces vật lý có sẵn) vào interface ảo này. Gần giống kiểu mình dùng cisco etherchannel để gộp các ports vật lý vào trong 1 port ảo. Cái virtual wan link này là dùng để ra internet, còn nếu mình muốn vpn đến site khác thì mình tạo 1 vpn zone (ảo) và sau đó tạo và add các đường vpn (vpn1, vpn2 …) vào vpn zone đó (và nó là overlay, vì nó dựa trên cái underlay ở dưới là các đường wan). Việc tạo giao diện wan ảo (gộp các wan vật lý) là để giúp phối hợp và lựa chọn các wan vật lý để đem đến các tính năng như failover, load balancing, path selection, load distribution, lựa chọn đường wan dựa theo chất lượng đường wan và dựa theo app / service / ip / fqdn …
+SDWAN rules: phần này có 1 rule mặc định nằm dưới cùng và trong rule này nó cho mình chọn 1 số thuật toán load balance. Ngoài ra mình có thể tạo thêm rule mới để control vấn đề path selection dựa vào ip / fqdn / app / service / category … ví dụ mình định nghĩa là truy cập Office 365 phải đi qua đường wan1, hoặc tự động chọn đường wan nào có chất lượng tốt nhất dựa vào các SLA đã được định nghĩa và cấu hình, hoặc lựa chọn và phối hợp các đg wan sao cho tối đa bandwidth, hoặc có latency thấp nhất …
+Performance SLA: phần này mình định nghĩa cách thức mình monitor 1 server ngoài internet dựa vào các giao thức như ping, http, dns … để đo lường tính sẵn sàng và chất lượng các đường wan dựa vào nhiều tiêu chí như packet loss, latency, jitter … và dùng các kết quả này vào việc chọn đường wan ở mục sdwan rules. VD mình sẽ cấu hình để nó ping liên tục đến 8.8.8.8 và đo lường các thông số chất lượng của các đg wan thông qua kết quả gói ping.
Tóm lại, sau khi cấu hình 3 mục trên thì ta có 1 giao diện wan ảo mới là virtual wan link (hoặc tên khác do ta đặt) trong đó nó gộp các đường wan vật lý là wan1, wan2 … Ta cũng tạo Perf SLA để monitor và đo chất lượng các đg wan1, wan2 … và tạo sdwan rule để control path selection dựa vào thông tin source, destination và kết quả của perf sla. Nhưng cái virtual wan link này chỉ là để truy cập internet, nếu ta muốn kết nối vpn giữa HQ và branch thì ta phải tạo thêm VPN theo 1 trong 2 cách sau:
+cách 1: tạo và cấu hình IPsec s2s vpn tunnel truyền thống, việc cấu hình khá đơn giản, chú ý cấu hình phase 1 và phase 2 trên fortigate đầu này phải tương thích với phase 1 và phase 2 trên fortigate đầu kia
+cách 2: vào mục sdwan/sdwan zones và tạo 1 vpn zone (ảo) và sau đó tạo và add các vpn thành viên (vd: vpn1 dựa trên wan1, vpn2 dựa trên wan2) vào vpn zone này, việc tạo và add vpn thành viên làm ngay trong giao diện của mục sdwan chứ ko làm trong giao diện của mục VPN như thông thường. Cấu hình vpn theo cách này thì ta phải tạo nhiều đường vpn (vpn1, vpn2) để hệ thống tự động lựa chọn đường vpn phù hợp với từng traffic. Cấu hình khá lằng nhằng nhiều bước, phức tạp hơn so với cách 1, nên mình ko thích cách này lắm, và nó cũng failed trong test lab của mình.
Như vậy với fortigate sdwan thì có 2 dạng virtual link: virtual link dùng để truy cập internet (như cái virtual wan link), và virtual link dùng để kết nối các sites (như vpn zone). SDwan phục vụ truy cập internet thì khá ngon và cấu hình khá đơn giản nên ok,
Store Worker Process stops and returns “System.NullReferenceExceptions” lặp lại nhiều lần.
Không ghi âm và play được Exchange Unified Messaging
Log Exchange Application bị tràn liên quan có mã event ID: 6010
Các lỗi khi update có thể gặp phải:
Dịch vụ Microsoft Exchange AD Topology service có thể không start tự động hoặc lỗi treo làm die hệ thống (Đối với Exchange server 2016 chạy trên Windows Server 2012R2)
Bản xem trước trang web cho các URL được chia sẻ trong Outlook trên web (OWA) không được hiển thị chính xác.
Không thể mở công cụ quản lý Exchange Toolbox MMC snapin
Khuyến cáo Phương nguyễn:
Hiện bản này đang có nhiều lỗi liên quan khuyến cáo mạnh mẽ anh em IT System chưa hãy update nhé để ăn tết vui vẻ chờ MS confirm các bản vá trong tương lai. Vì có rất nhiều người bị lỗi rồi. Khuyến cáo đặc biệt: Tuyệt đối không chạy bản vá này cho Exchange 2013
Để cập nhật admin BIG-IP Configuration qua web thì chúng ta còn nhớ mật khẩu mới vào được. Tuy nhiên vì lý do gì đó quên luôn mật khẩu admin trên web. Chúng ta phải dùng đến công cụ TMOS Shell (tsmh) của F5 nhé.
Thực hiện
Bước 1: logon vào Shell hoặc SSH gỏ lệnh tmsh
tmsh
Bước 2: gỏ lệnh bên dưới
modify auth password root
Nhập password mới và nhập lại cho root account
Bước 3 : để reset luôn tài khoản web admin dùng để cấu hình gỏ lệnh bên dưới
modify auth user admin prompt-for-password
Bước 4 : lưu cấu hình bằng lệnh save sys config
save sys config
Bước 5: Quit
Kiểm tra lại logon nhé
Như vậy là thành công rồi nhé. Chúc các bạn reset thành công trong công việc quản trị F5 network.
Câu chuyện quản trị system của Doanh nghiệp thường quy mô cở trung, vừa to,… Nếu doanh nghiệp chúng ta nhỏ thường ông quản trị mạng làm hết nghĩa là roles và vai trò system admin, network admin là 1 nói chung là all in one 🙂 đó là câu chuyện đương nhiên để tiết giảm chi phí cho Doanh nghiệp. Tuy nhiên đối với Doanh nghiệp lớn SMB to hệ thống vài 1000 user đến vài trăm ngàn user, thì IT helpdesk cần có và phân công nhiệm vụ rõ ràng. Ông System Admin quản trị Domain controller rồi có thể cho các bạn Helpdesk hoặc đơn vị nào đó ví dụ Outsoucing để có quyền tham gia hay join máy tính vào domain. Câu chuyện đặt ra chúng ta không thể một mình làm hết được nên chúng ta phải cho phép ủy quyền 1 số nhóm hoặc người dùng helpdesk làm công chuyện này. Dĩ nhiên loại trừ 1 số người dùng có số lần join domain là 10 lần.
Giải pháp
Hôm nay phương nguyễn chia sẽ đến các bạn một mẹo nhỏ trong quản trị hệ thống mạng Domain controller nhé để làm công đoạn này có 2 cách có thể làm:
Ủy quyền 1 nhóm người hoặc người nào đó có quyền sử dụng Active Directory Users and Computers mà cụ thể là join domain.
Tạo 1 chính sách GPO trên default domain group policy để cấp quyền
Các thực hiện ủy quyền trên ADUC
Để thực hiện delegation vào start-> gỏ lệnh dsa.ms run Active Directory Users & Computers
Tạo 1 nhóm để ủy quyền nhé ví dụ GroupITHelpdesk
Thêm các user cần ủy quyền join vào nhé ví dụ : jsisen, phuong
Muốn ủy quyền OU nào thì chọn OU đấy nhé hoặc có thể chọn cả domain 🙂 phải chuột chọn delegation
Chọn Nex->
Chọn -> Add group vừa tạo trên và chọn ok->next.
Chọn Delegation the following Common tasks-> Join a Computer to the domain
Hoặc chọn Create a custom task to delegate thì chọn Create computer object và Delete nhé.
Chọn Ok finish nhé.
Như vậy Phương Nguyễn chia sẽ cách ủy quyền 1 tài khoản hoặc nhóm có thể có quyền join domain. Chúng ta có thể bàn giao cho các anh em IT helpdesk đi làm mỗi 1 nhiệm vụ join thôi nhé.
Hehehe Nếu thấy hay hãy nhớ like và sharing cho các anh em IT và nếu có copy bài nhớ ghi source từ bài viết.
Khoảng từ đầu tháng 08/2022, trong quá trình thực hiện giám sát an ninh mạng và xử lý sự cố, Trung tâm vận hành bảo mật GTSC SOC phát hiện một đơn vị trọng yếu bị tấn công an ninh mạng vào hệ thống ứng dụng Microsoft Exchange. Quá trình điều tra, đội ngũ chuyên gia BlueTeam xác định kẻ tấn công đã sử dụng một lỗ hổng bảo mật của Microsoft Exchange chưa từng được công bố – hay còn gọi là lỗ hổng 0-day. GTSC SOC Team ngay lập tức đưa ra phương án ngăn chặn tạm thời. Song song, các chuyên gia RedTeam cũng bắt tay ngay vào việc nghiên cứu, debug lại mã nguồn ứng dụng Mail Exchange để tìm ra mã khai thác (exploit). Với lỗ hổng bảo mật Exchange trước đây, đội ngũ RedTeam cũng đã từng phân tích ra exploit trước khi có exploit được public trên thế giới (1-day exploit) nên việc hiểu luồng, cơ chế xử lý của hệ thống Email Exchange đã giúp giảm thời gian cho quá trình research. Ngay sau khi nghiên cứu ra exploit, GTSC đã submit lên ZDI để làm việc với Microsoft nhằm nhanh chóng có bản vá.
Sau khi ZDI verify đã ghi nhận 2 bug liên quan đến exploit:
Tuy nhiên đến thời điểm hiện tại, GTSC ghi nhận thêm các đơn vị khác cũng đang gặp phải sự cố. Sau khi kiểm tra, GTSC xác nhận hệ thống bị tấn công qua lỗ hổng 0-day này. Để hỗ trợ cộng đồng ngăn chặn tạm thời trước khi có bản vá chính thức từ Microsoft, chúng tôi công bố bài viết này để cảnh báo tới các đơn vị có sử dụng hệ thống email Microsoft Exchange.
Thông tin lỗ hổng bảo mật
– Đội ngũ Blueteam trong quá trình giám sát phát hiện được các request exploit dựa trên log IIS có định dạng giống như lỗ hổng ProxyShell: autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com. Đồng thời kiểm tra các logs khác, nhận thấy kẻ tấn công thực hiện được các câu lệnh trên hệ thống. Kiểm tra version number trên máy chủ Exchange bị tấn công nhận thấy máy chủ đã cài đặt bản cập nhật mới nhất tại thời điểm đó nên không thể có trường hợp khai thác bởi lỗ hổng Proxyshell -> xác nhận máy chủ bị khai thác bởi lỗ hổng 0-day RCE mới. Các thông tin này được Blueteam cung cấp lại cho Redteam, từ đó đội ngũ Redteam của GTSC đã tiến hành nghiên cứu để trả lời cho các câu hỏi như tại sao các request lại giống với request của bug ProxyShell?, luồng RCE được thực hiện như thế nào?
– Kết quả nghiên cứu đã giúp GTSC Redteam thành công tìm ra cách sử dụng đường dẫn trên để truy cập tới 1 component ở backend và thực hiện RCE. Thông tin kỹ thuật chi tiết về lỗ hổng tại thời điểm này chúng tôi xin phép chưa công bố.
Các hành vi sau khai thác
Sau quá trình khai thác thành công lỗ hổng, chúng tôi ghi nhận các hành vi tấn công nhằm thu thập thông tin và tạo chỗ đứng trong hệ thống của nạn nhân. Nhóm tấn công cũng sử dụng các kỹ thuật khác nhau nhằm tạo backdoor trên hệ thống bị ảnh hưởng và thực hiện lateral movement sang các máy chủ khác trong hệ thống.
Webshell
Chúng tôi phát hiện các webshell được drop xuống các máy chủ exchange. Các webshell chúng tôi thu thập được hầu hết được obfuscated. Thông qua User-agent chúng tôi phát hiện attacker sử dụng Antsword (một opensource có tính năng hỗ trợ quản lý webshell).
Chúng tôi nghi ngờ các hành vi khai thác này xuất phát từ các nhóm tấn công Trung Quốc, dựa trên codepage trong webshell là 936, một bảng mã ký tự Microsoft cho tiếng Trung giản thể (simplified Chinese).
Một đặc điểm đáng chú ý khác, bên cạnh việc drop các webshell mới hacker cũng thực hiện thay đổi nội dung trong file RedirSuiteServiceProxy.aspx thành nội dung webshell. RedirSuiteServiceProxy.aspx là một tên file hợp pháp sẵn có trong máy chủ Exchange
Bên cạnh các hành vi thu thập thông tin trên hệ thống, attacker thực hiện tải file và kiểm tra kết nối thông qua certutil có sẵn trên môi trường Windows
Ở cuối của mỗi câu lệnh mà kẻ tấn công thực hiện đều có chuỗi echo [S]&cd&echo [E], một trong những dấu hiệu nhận biết của China Chopper.
Ngoài ra, hacker cũng thực hiện inject DLL độc hại vào bộ nhớ, drop các file nghi ngờ lên các máy chủ bị tấn công, và thực thi các file này thông qua WMIC.
Suspicious File
Trên các máy chủ, chúng tôi phát hiện các file nghi ngờ có định dạng exe và dll
Trong số các file nghi ngờ trên, dựa vào các câu lệnh được thực hiện trên máy chủ, chúng tôi nhận định các file all.exe, dump.dll có nhiệm vụ trích xuất thông tin tài khoản trên hệ thống máy chủ. Sau các hành vi trích xuất thông tin tài khoản trên hệ thống, attacker sử dụng rar.exe để nén các file dump và copy ra webroot của máy chủ Exchange. Trong quá trình xử lý sự cố, các file trên đã không còn tồn tại trên hệ thống.
File cm.exe được drop xuống thư mục C:\PerfLogs\ là file cmd.exe
GTSC phân tích một mẫu cụ thể (074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82) để mô tả hành vi của mã độc, các mẫu DLL khác có nhiệm vụ và hành vi giống nhau, chỉ khác nhau về cấu hình listener
DLL gồm 2 hai class: Run và m. Bên trong mỗi class gọi tới các method thực hiện các nhiệm vụ khác nhau. Cụ thể:
Class Run thực hiện tạo listener lắng nghe các kết nối tới port 443, đường dẫn https://*:443/ews/web/webconfig/.
Sau quá trình lắng nghe, mã độc tạo thread mới goi tới r. Method r thực hiện:
– Kiểm tra request nhận được có data trong body hay không. Nếu không có data đi kèm trong request gửi lên máy chủ, kết quả trả về là 404.
– Ngược lại, nếu trong request có đi kèm data, DLL tiếp tục xử lý luồng bên trong nhánh IF:
Kiểm tra request nhận được có tồn tại “RPDbgEsJF9o8S=” hay không. Nếu có, gọi tới method i nằm trong class m để xử lý request nhận được. Kết quả trả về từ Run.m.i sẽ được covert sang chuỗi base64. Kết quả trả về cho client theo format
{
“result”:1,
“message”:”base64(aes(result))”
}
Class m
Method i thực hiện:
– Giải mã request nhận được bằng thuật toán AES với 16 bytes đầu tiên của request là giá trị IV, 16 bytes tiếp theo là giá trị key, các giá trị sau đó là data
– Sau khi giải mã, lấy phần tử đầu tiên trong mảng làm flag để xử lý các case đã được định nghĩa
Case 0: Gọi tới method info. Method này có nhiệm vụ thu thập thông tin hệ thống. Các thông tin bao như kiến trúc hệ điều hành, phiên bản framework, phiên bản hệ điều hành, v.v….GTSC mô phỏng lại case 0 bằng hình ảnh bên dưới. Request gửi lên theo format 16 bytes đầu là giá trị IV, 16 bytes tiếp theo là giá trị key, theo sau là flag để chỉ định option và phần còn lại là data.
base64 (IV | key | aes(flag|data))
Case 1: Gọi tới method sc. Method này có nhiệm vụ cấp phát vùng nhớ để thực thi shellcode
Case 2: Gọi tới 2 method p và r. Method p xử lý các dữ liệu được ngăn cách bởi ký tự “|” lưu vào mảng array3. Mảng array3 sẽ lấy 2 phần tử đầu tiên làm tham số cho method r, method r có nhiệm vụ thực thi command
Case 3: Gọi tới method ld. Method này có nhiệm vụ liệt kê thông tin thư mục và file theo format
D|-|<Ngày tạo> |<Ngày chỉnh sửa> |<tên thư mục hoặc tên file>
o Case 4: Gọi tới method wf. Method này có nhiệm vụ ghi file
o Case 5: Gọi tới method rf. Method này có nhiệm vụ đọc file
Case 6: Tạo thư mục
o Case 7: Xóa file hoặc thư mục
o Case 8: Di chuyển File
o Case 9: Set time cho file
o Case 10: Nạp và thực thi C# bytecode nhận từ request.
Các mẫu DLL khác có nhiệm vụ tương tự, chỉ khác nhau về cấu hình listener như sau:
Chúng tôi cũng phát hiện DLL được inject vào memory của tiến trình svchost.exe. DLL thực hiện kết nối gửi nhận dữ liệu tới địa chỉ 137[.]184[.]67[.]33 được config trong binary. Việc gửi nhận dữ liệu với C2 sử dụng thuật toán RC4, khóa sẽ được tạo trong thời gian chạy (runtime).
Các biện pháp ngăn chặn tạm thời
Quá trình xử lý sự cố trực tiếp của GTSC ghi nhận có trên 1 đơn vị tổ chức bị là nạn nhân của chiến dịch tấn công khai thác lỗ hổng zero day. Ngoài ra chúng tôi cũng lo ngại rằng có thể có nhiều tổ chức khác cũng đã bị khai thác nhưng chưa được phát hiện. Trong thời gian chờ đợi bản vá chính thức từ hãng, GTSC cung cấp biện pháp khắc phục tạm thời nhằm giảm thiểu việc tấn công khai thác lổ hổng bằng cách bổ sung rule chặn các request có dấu hiệu tấn công thông qua module URL Rewrite rule trên máy chủ IIS (Webserver)
– Trong Autodiscover tại FrontEnd chọn tab URL Rewrite chọn Request Blocking
– Add thêm chuỗi “.*autodiscover\.json.*\@.*Powershell.*“ vào Pattern (URL Path):
– Condition input: lựa chọn {REQUEST_URI}
Phát hiện tấn công
Nhằm kiểm tra hệ thống đã bị tấn công bởi lổ hỗng này, các đơn vị/tổ chức có thể thực hiện theo các cách thức sau:
Cách 1: Sử dụng powershell với câu lệnh sau: (Sử dụng powershell để thực hiện search trên toàn bộ folder log IIS mất khá nhiều thời gian)
Cấu hình mặc định IIS log nằm tại đường dẫn “%SystemDrive%\inetpub\logs\LogFiles”
Cách 2: Sử dụng công cụ do GTSC phát triển dựa trên dấu hiệu khai thác lỗ hổng, thời gian thực hiện search nhanh hơn so với việc sử dụng powershell. Đường dẫn tải về công cụ: https://github.com/ncsgroupvn/NCSE0Scanner
Cách 3: Sử dụng công cụ của MS luôn nhé Exchange On-premises Mitigation Tool v2 (EOMTv2) link download tại đây
Trong bản cập nhật Patch Tuesday tháng 9, Microsoft phát hành bản vá cho tổng cộng 63 lỗ hổng trên Windows.
Theo Microsoft, 5 trong số 63 lỗ hổng được xếp loại “nghiêm trọng” do kẻ xấu có thể lợi dụng để thực thi mã từ xa. Đây là một trong những loại lỗ hổng nguy hiểm nhất. Patch Tuesday tháng 9 vá 2 lỗ hổng zero-day đã được công bố, trong đó có 1 lỗ hổng đang được khai thác trong thực tế.
Microsoft phân loại một lỗ hổng là zero-day nếu nó đã được công bố hoặc được khai thác mà chưa có bản vá. Lỗ hổng zero-day được vá hôm nay là “CVE-2022-37969”. Nếu khai thác thành công, thủ phạm có thể chiếm được các đặc quyền hệ thống. Nó được các nhà nghiên cứu tại DBAPPSecurity, Mandiant, CrowdStrike và Zscaler phát hiện. Theo Dhanesh Kizhakkinan – Kỹ sư lỗ hổng cấp cao của Mandiant, dường như lỗ hổng nằm riêng lẻ và không thuộc một chuỗi.
“CVE-2022-37969” ảnh hưởng đến các phiên bản Windows từ 7 đến 11, cũng như Windows Servers 2008 và 2012. Chuyên gia bảo mật Mike Walters của Action1 cho biết, do lỗ hổng có độ phức tạp thấp và không cần tương tác của người dùng, nó có thể sớm bị giới hacker khai thác.
Theo Microsoft, lỗ hổng yêu cầu kẻ tấn công phải xâm nhập được vào thiết bị bị xâm phạm hoặc có khả năng khởi chạy mã trên hệ thống mục tiêu. Dustin Childs, Giám đốc tình báo nguy cơ tại Zero Day Initiative, chia sẻ thêm, các loại lỗ hổng này thường được sử dụng trong các hình thức tấn công social engineering như thuyết phục ai đó mở một tập tin hay bấm vào liên kết. Sau khi nạn nhân làm theo, mã bổ sung sẽ dùng đặc quyền leo thang để chiếm đoạt hệ thống.
Người dùng được khuyến nghị nên cập nhật bảo mật ngay khi có thể. Windows 7 cũng được nhận bản vá bảo mật dù đã bị hết hạn hỗ trợ vào năm 2020.
Người dùng Windows đã cài đặt bản cập nhật bảo mật KB5012170 mới cho Khởi động an toàn đã gặp phải nhiều vấn đề khác nhau, từ lỗi khởi động với lời nhắc Khôi phục BitLocker đến các vấn đề về hiệu suất.
Bộ nạp khởi động UEFI tải ngay sau khi thiết bị được khởi động và chịu trách nhiệm khởi chạy môi trường UEFI với tính năng Khởi động an toàn để chỉ cho phép mã tin cậy được thực thi khi bắt đầu quá trình khởi động Windows.
Trong bản vá thứ ba tháng 8 năm 2022, Microsoft đã phát hành KB5012170 ‘Bản cập nhật bảo mật cho Secure Boot DBX’ độc lập để giải quyết các lỗ hổng được tìm thấy trong các bộ nạp khởi động UEFI khác nhau mà các tác nhân đe dọa có thể sử dụng để bỏ qua tính năng Khởi động Bảo mật của Windows và thực thi mã chưa được ký.