CSS-Exchange VS New-KrbtgtKeys.ps1

The MaxServicePointIdleTime property I changed because of what I saw suggested here: https://github.com/microsoft/CSS-Exchange/issues/1581.

This is actively exploited, patch immediately. Microsoft also provided a script that checks Exchange items for malicious messaging items: https://github.com/microsoft/CSS-Exchange/blob/a4c096e8b6e6eddeba2f42910f165681ed64adf7/docs/Security/CVE-2023-23397.md

Microsoft has released a PowerShell script that can be run on Exchange infrastructure to scan email files for malicious UNC paths, however, patching is the preferred mitigation strategy.

I would expect that installing the URL Rewrite 2 module shouldn't cause any problems -- E2013 as such doesn't care about it. In fact, Microsoft's own EOMT script for the Hafnium mitigations suggests installing it. It'll likely require a reboot, though, or at the very least an IIS restart.

Yep, the August security update and OS updates were installed on all four nodes. But the order in which they were installed may have been different... I don't recall. Someone just posted above that this is a known problem with Windows 2012/R2: https://github.com/microsoft/CSS-Exchange/pull/1166

Which is the latest I can find on Github. This server is running Exchange 2019 CU 11. It has the March updates (KB5012698), but not the May one (KB5014261). You can also verify from the build number it's not up to date. There are no vulnerabilities reported and the only thing in "red" is that TCP keepalive warning.

https://github.com/microsoft/CSS-Exchange/issues/535 Even the maintainer David Paulson of the ExchangeHealtcheck script opened an issue on this matter, only waiting on feedback of the Exchange Team.

You should start rotating your krbtgt password (example script), if you haven't done so. You'll break everything if it's never been rotated. At least twice with a minimum of a day in-between. Never rotate twice under 10 hours or you'll break a lot.

This is critical. Most AD domains never change this password, so if the domain's been around since Windows 2000, that's a lot of opportunity for someone to pick up and use it to grant themselves any access. Often the reason for not doing so is the havoc it can cause if you have a huge worldwide domain with hundreds of DCs and some don't get the replicated password change before you do it a second time. Microsoft has a tool that minimizes this risk.

You would likely need a PowerShell plugin, via TPC, that uses this Microsoft script: https://www.microsoft.com/en-us/security/blog/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/ . Though the script appears to be gone from MSFT, and can be found here: https://github.com/microsoft/New-KrbtgtKeys.ps1/blob/master/New-KrbtgtKeys.ps1 . Though Msft might have gotten their script originally from this author: Jorge de Almeida Pinto - more updated script here: https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1

The first is about last change of the Kerberos password. Can I safely change such password with this script? Honestly I never did this before.

I've used the reccomended microsoft script here https://github.com/microsoft/New-KrbtgtKeys.ps1

krbtgt script

Reset the krbtgt keys twice: https://github.com/microsoft/New-KrbtgtKeys.ps1/blob/master/New-KrbtgtKeys.ps1