New 0-day vulnerability found in Microsoft Exchange

Security researchers from GTSC Network Security firm have found a new zero-day vulnerability in Microsoft Exchange Server 2013/2016/2019, which is exploited in the wild. According to the GTSC report, at the beginning of August 2022, they discovered a critical infrastructure was being attacked, specifically their Microsoft Exchange application. On investigating the incident, they found that the attack utilized an unpublished Exchange security vulnerability, i.e., a 0-day vulnerability on Microsoft Exchange Server. The researcher noted that the vulnerability turns out to be so critical that it allows the attacker to execute code remotely (RCE) on the compromised system.

Note: Microsoft releases the November 2022 Exchange Server Security Updates, which patch these vulnerabilities.

Table of contents

Vulnerability information

While providing SOC service to a customer, GTSC blue team detected exploit requests in IIS logs with the same format as ProxyShell vulnerability:

autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com

Checking other logs, they saw that the attacker can execute commands on the attacked system. The version number of these Exchange servers showed that the latest update had already installed, so an exploitation using Proxyshell vulnerability was impossible.

The GTSC blue team analysts can confirm that it was a new 0-day RCE vulnerability. This information was sent to the GTSC red team members, and conducted research to answer these questions:

  • Why were the exploit requests similar to those of ProxyShell bug?
  • How is the RCE implemented?

GTSC red team successfully figured out how to use the above path to access a component in the Exchange backend and perform RCE. However at this time, they would like NOT to release technical details of the vulnerability yet.

Note: These vulnerabilities affect Microsoft Exchange Server. Exchange Online is not affected.

Upcoming advisories

Checking the Zero Day Initiative upcoming advisories shows two vulnerabilities from GTSC Team.

0-day vulnerability Microsoft Exchange upcoming advisories

Temporary mitigation

GTSC’s direct incident response process recorded more than 1 organization being the victims of an attack campaign exploiting this 0-day vulnerability. In addition, they are also concerned that there may be many other organizations that have been exploited but have not been discovered.

While waiting for the official patch from Microsoft, GTSC provides a temporary remedy to reduce the vulnerability of attacks by adding a rule to block requests with indicators of attack through the URL Rewrite Rule module on IIS server and disabling remote PowerShell for non-admins.

Follow the below steps to mitigate both CVEs:

Important: It is strongly recommended all organizations/enterprises that are using Microsoft Exchange Server to check, review, and apply the below temporary remedy as soon as possible to avoid potential serious damages.

Mitigate CVE-2022-41040

Go through the below steps to block known attack patterns on the Exchange Server and mitigate CVE-2022-41040.

Option 1: Block known attack patterns (manual)

Step 1. Start IIS Manager. Click on Default Web Site and double-click on URL Rewrite.

If URL Rewrite is unavailable, it means that it’s not installed on the Exchange Server 2013/2016/2019, and you need to install IIS URL Rewrite module.

Note: There is no known impact on Exchange functionality if the URL Rewrite module is installed as recommended.

Note: The IIS URL Rewrite Module is required with Exchange Server 2016 CU22 and Exchange Server 2019 CU11 or later. It’s recommended to keep the Exchange Server up to date with the latest Exchange Server Cumulative Update and Exchange Server Security Update.

Suppose you have Exchange Server 2013 running, install the module (IIS will restart, and Outlook clients will lose connection to Exchange Server).

0-day vulnerability Microsoft Exchange IIS 1

Step 2. In the Actions pane on the right-hand side, click Add Rules.

0-day vulnerability Microsoft Exchange IIS 2

Step 3. Select Request Blocking and click OK.

0-day vulnerability Microsoft Exchange IIS 3

Step 4. Ensure URL Path is selected, add the below string, choose Regular Expressions, choose Abort Request, and click OK.

(?=.*autodiscover)(?=.*powershell)
0-day vulnerability Microsoft Exchange IIS 4

Step 5. Expand the rule and select the rule with the pattern you created in the previous step. Click Edit.

0-day vulnerability Microsoft Exchange IIS 5

Step 6. Change the condition input from {URL} to {UrlDecode:{REQUEST_URI}} and click OK.

0-day vulnerability Microsoft Exchange IIS 6

Option 2: Block known attack patterns (script)

What if you want to speed up the process because you have multiple Exchange Servers running?

Download EOMTv2.ps1 PowerShell script and place it in the C:\scripts\ folder.

Start Windows PowerShell as administrator and run the script.

C:\scripts\EOMTv2.ps1

Note: Run the script on every Exchange Server.

The output shows that the migration completes on the Exchange Server.

VERBOSE: Checking if EOMTv2 is up to date with https://aka.ms/EOMTv2-VersionsUri
VERBOSE: Starting EOMTv2.ps1 version 22.10.07.2029 on EX01-2019
VERBOSE: EOMTv2 precheck complete on EX01-2019
VERBOSE: Applying mitigation on EX01-2019
VERBOSE: Starting mitigation process on EX01-2019
VERBOSE: IIS URL Rewrite Module is already installed on EX01-2019
VERBOSE: Applying URL Rewrite configuration to EX01-2019 :: Default Web Site
VERBOSE: Mitigation complete on EX01-2019 :: Default Web Site
VERBOSE: EOMTv2.ps1 complete on EX01-2019, please review EOMTv2 logs at
C:\Users\ADMINI~1.EXO\AppData\Local\Temp\2\EOMTv2\EOMTv2.log and the summary file at C:\EOMTv2Summary.txt

This is how it looks in IIS after the EOMTv2.ps1 PowerShell script completes.

0-day vulnerability Microsoft Exchange IIS EOMTv2

Option 3: Block known attack patterns (EEMS)

For customers who have the Exchange Emergency Mitigation Service (EEMS) enabled, Microsoft released the URL Rewrite mitigation for Exchange Server 2016 and Exchange Server 2019. The mitigation will be enabled automatically.

0-day vulnerability Microsoft Exchange IIS EMS

Mitigate CVE-2022-41082

Go through the below steps to disable remote PowerShell for non-admins/service accounts and mitigate CVE-2022-41082.

Option 1: Disable remote PowerShell for non-admins

Step 1. Run Exchange Management Shell as administrator.

Step 2. Disable Remote PowerShell for all users.

Get-User -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true' | Set-User -RemotePowerShellEnabled $false

Step 3. Verify that Remote PowerShell is disabled for all users.

Get-User -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true' | ft Name,UserPrincipalName

Step 4. Enable Remote PowerShell for the user(s) that needs it. This is most likely the administrator accounts and service accounts.

Set-User -Identity "userprincipalname" -RemotePowerShellEnabled $true

What if you get locked out and can’t connect with Exchange Management Shell?

Suppose you forget to enable Remote PowerShell for the admin account and Exchange Management Shell does not connect to the Exchange Server anymore, follow the below steps:

Step 1. Close Exchange Management Shell

Step 2. Run PowerShell as administrator (note that this is PowerShell and not Exchange Management Shell):

Step 3. Add the Exchange Management PowerShell Snap-In:

Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.Snapin

Step 4. Enable Remote PowerShell for the admin account:

Set-User -Identity "userprincipalname" -RemotePowerShellEnabled $true

Step 5. Start Exchange Management Shell, and everything works as you expect.

Option 2: Disable remote PowerShell for non-admins (script)

This is the recommended approach because new users you create will have Remote PowerShell enabled. Running the below PowerShell script as a scheduled task every night or every couple of hours will ensure that explicitly the user accounts in the defined security group has Remote PowerShell access, and all other user accounts are disabled for Remote PowerShell.

Step 1. Start Active Directory Users and Computers.

Step 2. Create a security group with the name AllowRemotePS.

0-day vulnerability Microsoft Exchange Remote PowerShell 1

Step 3. Open the AllowRemotePS group, click on the General tab and fill in the description CVE-2022-41082.

0-day vulnerability Microsoft Exchange Remote PowerShell 2

Step 4. Click on the Members tab and add the administrators/service accounts that need remote PowerShell access. Click OK.

0-day vulnerability Microsoft Exchange Remote PowerShell 3

Step 5. Download and place DisableRemotePS.ps1 PowerShell script in C:\scripts\ folder.

Ensure the file is unblocked to prevent errors when running the script. Read more in the article Not digitally signed error when running PowerShell script.

Another option is to copy and paste the below code into Notepad. Give it the name DisableRemotePS.ps1 and place it in the C:\scripts\ folder.

# Load Exchange Management Shell PowerShell Snap-In
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

# Allow Remote PowerShell Group
$AllowRPSGroup = "AllowRemotePS"

# Get all users with enabled Remote PowerShell
$AllUsers = Get-User -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true' | select SamAccountName, RemotePowerShellEnabled

# Get all users from AllowRPSGroup
$AllowUsers = Get-ADGroupMember $AllowRPSGroup -Recursive | ForEach-Object { Get-User -Identity $_.SamAccountName | select SamAccountName, RemotePowerShellEnabled }

# Enable Remote PowerShell for allowed users
foreach ($AllowUser in $AllowUsers) {
    if ($AllowUser.RemotePowerShellEnabled -eq $false) {
        Set-User $AllowUser.SamAccountName -RemotePowerShellEnabled $true
    }
}

# Disable Remote PowerShell for all users
foreach ($User in $AllUsers) {
    if ($AllowUsers.SamAccountName -notcontains $User.SamAccountName) {
        Set-User $User.SamAccountName -RemotePowerShellEnabled $false
    }
}

Step 6. Run Exchange Management Shell as administrator and run the script.

C:\scripts\DisableRemotePS.ps1

Step 7. Verify that Remote PowerShell is enabled for the AllowRemotePS security group users.

Get-User -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true' | ft Name,UserPrincipalName

Step 8. Create a scheduled task so the script will run every night or every couple of hours.

Note: You should keep this script running as a scheduled task in the future because this makes the attack surfer smaller.

Verify mitigation

It’s always good to verify that you applied the mitigation successfully.

Open a web browser and insert the adjusted autodiscover URL.

https://mail.domain.com/Autodiscover/autodiscover.json@PowerShell

This is how it looks before the mitigation (which is BAD):

0-day vulnerability Microsoft Exchange bad

This is how it looks after mitigation (which is GOOD):

0-day vulnerability Microsoft Exchange good

Verify with PowerShell and run the below command:

Invoke-WebRequest https://mail.domain.com/Autodiscover/autodiscover.json@PowerShell

It should reply with The underlying connection was closed: An unexpected error occurred on a receive.

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a receive.
At line:1 char:1
+ Invoke-WebRequest https://mail.domain.com/Autodiscover/autodiscover.js ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Detection

To help organizations check if their Exchange Servers have been exploited by this bug yet, GTSC released guidelines and a tool to scan IIS log files.

Method 1: Use PowerShell command:

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

In our example, the IIS logs are in the path C:\inetpub\logs\LogFiles\ and the PowerShell command will look like this:

Get-ChildItem -Recurse -Path "C:\inetpub\logs\LogFiles\" -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'

Method 2: Use the tool developed by GTSC.

Based on the exploit signature, GTSC developed a tool to automate the task rather than search with a much shorter time needed than using Powershell.

0-day vulnerability Microsoft Exchange tool

Conclusion

Mitigate the Exchange Servers NOW. You must apply both mitigations, blocking known attack patterns (CVE-2022-41040) and disabling remote PowerShell for non-admins (CVE-2022-41082).

CVE-2022-41040: Only keep one mitigation rule active in IIS, and don’t use multiple rules. After that, verify that the mitigation is successfully applied. As last, detect if your Exchange Servers are exploited.

CVE-2022-41082: Disable remote PowerShell for all users first. After that, enable remote PowerShell for the administrators/service accounts that need it.

Wait for Microsoft to release a patch (they are working on it).

Suppose you have all the mailboxes in Microsoft 365/Office 365, then you should change the autodiscover URL to Exchange Online. After that, remove the Exchange Server firewall ports, so the Exchange Server is not published to the internet. Read more in the article keep last Exchange Server in organization.

Further information

Latest updates

Update 1: Nothing yet from Microsoft. I will keep the article up to date with the latest changes.

Update 2: Microsoft is investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019. Microsoft has confirmed that the URL Rewrite instructions and blocking the ports used for Remote PowerShell (shown in this article) successfully break current attack chains.

Update 3: Updated the IIS mitigation steps with an easier walk-through.

Update 4: Microsoft is working on a fix/patch.

Update 5: Added information that you need to install the IIS URL rewrite module (this should be installed if you have an up-to-date Exchange Server 2016/2019). But, if you have Exchange Server 2013, you need to install it if it’s not yet available on the system before you can apply the mitigation.

Update 6: Added a walk-through about how to block PowerShell Remoting on the Exchange Server.

Update 7: Use “Regular Expressions” instead of “Wildcards” when creating the rule in IIS.

Update 8: Changed the request blocking rule (how to block) from Send an HTTP 403 (Forbidden) Response to Abort Request.

Update 9: Adjusted manual mitigation to apply on Default Web Site instead of Default Web Site/Autodiscover directory only, automated mitigation with official Microsoft script, and added EEMS mitigation.

Update 10: The URL pattern to detect/prevent the Exchange 0-day provided by MSRC (Microsoft Security Response Center) and GTSC Team can easily be bypassed.

GTSC team provided an update on 03-10-2022: After receiving information from Jang (@testanull), we noticed that the regex used in the Rewrite Rule could be bypassed. The GTSC team updated the new regex in the rule.

Updated the article to the below updated pattern:

.*autodiscover\.json.*Powershell.*

Note: Microsoft didn’t yet update their script with the new pattern. So you have to add it manually (see article) for now. I will update the post once Microsoft adjusts its script as they are working on it.

Update 11: Microsoft updated the EEMS rule, which is automatically applied. The EOMTv2 script has been updated to include the URL Rewrite improvement. Ensure that you have version 22.10.03.1829 or later.

Update 12: While the first URL pattern to detect/prevent the Exchange 0-day was bypassed and fixed, there is now a second one.

Updated the article to the below updated condition input to successfully mitigate the bypass:

{UrlDecode:{REQUEST_URI}}

Update 13: The GTSC team has confirmed that the latest mitigation can be bypassed and said that they updated the value in the condition input field from {REQUEST_URI} to {UrlDecode:{REQUEST_URI}}.

Update 14: Removed the Block PowerShell remoting section from the article. If you did add an inbound rule in the firewall to block ports HTTP: 5985 and HTTPS: 5986, you should remove it as they don’t have anything to do with it.

Update 15: Added a section about how to disable remote PowerShell for non-admins. Perform these steps to mitigate CVE-2022-41082.

Update 16: Microsoft updated the EEMS rule, which is automatically applied. The EOMTv2 script has been updated to include the condition input field improvement. Ensure that you have version 22.10.05.2304 or later.

Update 17: Working on a PS script to make it easier to mitigate CVE-2022-41082.

Update 18: Added a step-by-step instruction on enabling Remote PowerShell for the admin account if you mistakenly disabled it and can’t connect with Exchange Management Shell to Exchange Server.

Update 19: DisableRemotePS.ps1 PowerShell script for CVE-2022-41082 added, including steps. This is the recommended method.

Update 20: Microsoft improved the URL rewrite rules on October 7, 2022.

Updated the article to the below updated pattern:

(?=.*autodiscover)(?=.*powershell)

The EEMS service is receiving new rule automatically. EOMTv2 script has been updated (script auto-updates on Internet connected machines and the updated version is 22.10.07.2029).

Update 21: Microsoft releases the November 2022 Exchange Server Security Updates, which patch these vulnerabilities.

Subscribe to the newsletter and stay up to date with the latest IT tips and tricks.

Did this article help you? Share this article with your network and help them too.

ALI TAJRAN

ALI TAJRAN

ALI TAJRAN is a passionate IT Architect, IT Consultant, and Microsoft Certified Trainer. He started Information Technology at a very young age, and his goal is to teach and inspire others. Read more »

X TwitterLinkedIn

What Others Are Reading

This Post Has 80 Comments

  1. Hi Ali.

    Thanks for all the great info. I look to your site for guidance regularly.

    Quick question on EEMS.

    Do you know of any way to alert admins when an EEMS mitigation has been implemented? I know of the Event IDs, and the logging at \v1\logging, but we’re looking for a way to be immediately informed when a mitigation has been applied. We chased out tails once, when a mitigation had been applied but we not very informed on EEMS. Any info or ideas are greatly appreciated.

    On a related note, is it critical that the mitigation be removed after the subsequent SU has been installed? We have not removed the one mitigation that was applied back in ’22 and we have installed several SUs since.

    Thanks again, Ali!

    Reply

  2. Thanks for these amazing posts. Thanks to CVE-2022-41040 and CVE-2022-41082 I discovered your resourceful blog!

    I discussed the question I’m about to ask you with other people and also Googled but could find anything about this.

    Our Exchange Servers are version 2010, which are not supported anymore since October 13, 2020 and they’re on Windows Server 2008 R2. Yeah, I know…

    But nowhere is Exchange 2010 mentioned as being affected, only 2013, 2016 and 2019.

    But knowing that 2010 isn’t supported anymore might not be a surprise it’s not mentioned, although I’ve seen times where apparently EOL versions of other Microsoft products have been listed as affected for other vulnerabilities in the past, if I’m not mistaken.

    But I haven’t found any allusion to Exchange 2010 anywhere. Which doesn’t necessarily mean they aren’t affected.

    So as a preventive measure, I recommended to apply the mitigations.

    I just did right now. I know I’m late be we had many other urgent issues to cover that were officially affecting us.

    My question is, what are your thoughts about applying the mitigations on Exchange 2010 servers. Do you think there’s a chance they’re affected or am I off track for reasons I’m not aware of?

    Other question, I executed the script you recommend to give remove access to non-admins for remote acces to PowerShell and I’m not sure it’s giving an expected output.

    It started by outputing that it didn’t have Microsoft.Exchange.Management.PowerShell.SnapIn installed and then warned that several objects have been damaged and are in an incoherent state.

    I saw these warnings before with another command I made to just get a list of mailboxes so I’m not too concerned as after validation, nothing was damaged as such.

    I’m just wondering if anyone has encountered something like this.
    I might not do it on the other servers as I can’t confirm if it’s ok.

    Could it just be because it doesn’t have Microsoft.Exchange.Management.PowerShell.SnapIn installed?

    Anyways, I just wnated to have your thoughts or anyone else’s if someone has ideas on this.

    Thank you!

    Reply

    1. You may mitigate these vulnerabilities on Exchange Server 2010, but there are many more that you didn’t.

      Microsoft releases many Cumulative Updates (CUs) and Security Updates (SUs) for supported Exchange Servers.

      Exchange Server 2010 reached its end of support on October 13, 2020, and is open to security flaws. At this moment, you are asking to be attacked.

      I recommend upgrading to a newer Exchange Server or Exchange Online (Microsoft 365) as soon as possible.

      To disable remote PowerShell for non-admins, you need to run Exchange Management Shell and run the commands.

      Reply

  3. It is safe to apply recommended security patches to mitigate vulnerabilities. Any side affects or negative impact?

    Reply

  4. Hello !

    Just for information, the last Security Update for Exchange fixes these Zero-Days 🙂

    It is time to patch ! 😉

    Reply

      1. Hello,

        one question about the patch from mircosoft, what is with URL rewrite rule i set before microsoft patch?

        regards michael

        Reply

        1. After successfully installing the November 2022 Exchange Server Security Updates, you can safely remove the IIS URL rewrite rule.

          1. Applied manually – you could remove the mitigation manually by modifying IIS settings.

          2. Applied using the EOMTv2 script – you could remove the mitigation using .\EOMTv2.ps1 -RollbackMitigation.

          3. Applied by EEMS – if mitigation is manually removed, it will be re-applied again until Microsoft updates the mitigation XML file in their service.

          Reply

  5. Apologies if this was covered already. We’re running Exchange 2013. Which Exchange roles need the rewrite rule added? Just mailbox, or Edge and CAS also? Thanks in advance.

    Reply

  6. Hi All, won’t this actually cover the “remote powershell” part? So we can use New-ClientAccessRule and later run Set-ClientAccessRule with appropriate “-ExceptUsernameMatchesAnyOfPatterns” switch?

    Reply

  7. Hello Ali

    After I performed the detection with the tool developed by GTSC on various servers, I saw in the log that was created that various threats were present.

    What do I do with these threats, should I do a deeper analysis of the timeslot of this threat and possibly block these public IPs that have performed the access or what is the procedure according to Microsoft?

    Detailed as always. Thank you for the work that you put in.

    Reply

  9. We have hybrid exchange 2016 and auto discover is pointing to office 365 and we do not have any mailbox present in on Prem.

    Do we also need to follow this to mitigate?

    Reply

  10. Hi Ali, thx 4 your work. so i would implement the script but i see in the powershell logs entries of healthmailboxes. what should i do with them?

    Reply

  13. Should it be pretty obvious on the NCSSE0Scanner results to see if you’ve been compromised? My scan ran all night and I don’t see anything obvious in the log. But it doesn’t necessarily say CLEAN.

    Lots of this stuff-
    Start scan folder D:\Logs\inetpub\logs\LogFiles at 2022-10-05 19:25:28 (at tick 6677121125)
    Found file: D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210601.log with size 568217151 bytes
    Found file: D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210602.log with size 553360206 bytes
    Thread 0: Start scan file D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210601.log at 2022-10-05 19:25:28 (at tick 6677121140)
    Found file: D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210603.log with size 587096405 bytes
    Thread 1: Start scan file D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210602.log at 2022-10-05 19:25:28 (at tick 6677121140)
    Found file: D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210604.log with size 474857106 bytes
    Found file: D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210605.log with size 123297155 bytes
    Found file: D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210606.log with size 117002821 bytes

    Then lots of this –
    Found file: D:\Logs\inetpub\logs\LogFiles\W3SVC2\u_ex221005.log with size 345288061 bytes
    Thread 1: Done scan file D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210602.log at 2022-10-05 19:25:32 (at tick 6677125484), total in 4344 ms
    Thread 1: Start scan file D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210604.log at 2022-10-05 19:25:32 (at tick 6677125484)
    Thread 1: Done scan file D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210604.log at 2022-10-05 19:25:36 (at tick 6677128843), total in 3359 ms
    Thread 1: Start scan file D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210606.log at 2022-10-05 19:25:36 (at tick 6677128843)
    Thread 1: Done scan file D:\Logs\inetpub\logs\LogFiles\W3SVC1\u_ex210606.log at 2022-10-05 19:25:37 (at tick 6677129656), total in 813 ms

    Then finally –
    Done scan folder D:\Logs\inetpub\logs\LogFiles at 2022-10-06 07:28:11 (at tick 6720484046), total in 43362921 ms

    Reply

    1. What do we do with these threats, should we do a deeper analysis of the timeslot of this threat in the IIS log and possibly block these public IPs that have performed the access or what is the procedure according to Microsoft?

      Reply

  14. The exclusion of the members of “AllowRemotePS” group relies on the Get-ADGroupMember command that is in the ActiveDirectory module for PS. This either has to be done on a Domain Controller or the ActiveDirectory module has to be installed on the Exchange Server and imported before you run the script on the Exchange Server.

    Reply

  16. Hi,
    First, you have a really nice Blog Ali Tajran. Thanks to keep this page uptodate.

    About RemotePowershell, the official documentation says:

    By default, all user accounts have access to remote PowerShell. However, to actually use remote PowerShell to connect to an Exchange server, the user needs to be a member of a management role group, or be directly assigned a management role that enables the user to run Exchange cmdlets. For more information about role groups and management roles, see Exchange Server permissions.

    So, assuming no user has “special” or belongs to any of these groups, is that okay to keep RemotePowershell enabled? That makes sense?

    https://learn.microsoft.com/en-us/powershell/exchange/control-remote-powershell-access-to-exchange-servers?view=exchange-ps

    Reply

  17. I did the Get-User -ResultSize Unlimited -Filter ‘RemotePowerShellEnabled -eq $true’ | Set-User -RemotePowerShellEnabled $false

    but I didn’t enable it for myself. so when I tried to get the exchange shell again, I get “failed to connect to exchangserver in the current site”. what do I do now? can you help get my account back to this?

    Reply

  19. How do you run the GTSC developed tool to search for the exploit signature in IIS Log Files? The link just goes to a page that looks like it has the core files. I downloaded the ZIP, extracted, but could not find anything to run / execute. Am I missing a step or something?

    Reply

  20. Hello, and thanks for all your updates 🙂

    By the way, last patern {UrlDecode:{REQUEST_URI}} shot down in flames my IIS on exch2019 cu12
    I have a look again,
    Ber

    Reply

  21. A second bypass and Microsoft didn’t yet update their script.

    I added the pattern manually and keep checking your blog for more updates! Thanks!!!

    Reply

  22. on our Exchange 2013 the URL Rewrite rule created on “Default Web Site” is also created on “Exchange Back End” site, which makes the Exchange Management Shell not working on server! Deleting the rule in “Exchange Back End” site also remove the rule in “Default Web Site” It seems they are connected.
    No found this issue on an Exchange 2016 IIS

    Reply

  23. Are you sure that blocking ports in Windows Firewall is enough? Because MS strongly recommends to disable remote PW for non admin users and Nino Bilic from MS states that Exchange remote PS uses port 443 via IIS. Just curious

    Reply

  26. Hi Sir,

    Appreciate for ur explanation, anyway after we run get-child command to detect our Exchange Servers, it showed no result, how do we know if there’s any logs related ?

    Reply

  27. I ran the script from MS right after it came out. Can I modify the already created rule by simply removing the “*\@” part? Thanks

    Reply

  28. Hi Ali.
    Thanks for the article.
    Please update the script on Github with the new pattern from Update 10, otherwise people won’t get the correct rule.

    Reply

    1. I can’t because that’s Microsoft’s GitHub repository. For now, use the manual approach and wait for Microsoft (they are testing the pattern/working on a new pattern).

      Reply

  29. Hello,

    Thank you for the details steps. I had a question regarding an article i found that states that the mitigation microsoft pushed out can be bypassed. In the article it states that the mitigation sent out is too specific and by removing the “*\@” portion of it will have widen the attackers it can help prevent. I noticed that in step 4 you don’t have that in the url pattern but in step 6 you do. Would you recommend removing the “*\@” portion of the pattern or leave it in.

    Reply

    1. See Update 10: The URL pattern to detect/prevent the Exchange 0-day provided by MSRC (Microsoft Security Response Center) and GTSC Team can easily be bypassed.

      I recommend removing the “*\@” portion of the pattern, as shown in the article.

      Thanks for letting me know, I updated step 6, so it shows correctly now.

      Reply

      1. Another issue arise with the clients, this time with Mac Outlook. They are being prompted about Autodiscovery Redirect over and over. I tried disabling but no luck.

        I’d appreciate it if you could take a look.

        Best regards

        Reply

        1. Managed to solve this by deleting the Rewrite rules on IIS and recreating them again using the latest EOMS.ps1

          Thanks

          Reply

          1. We are having the same issue. after aplying the patch auto discover is not working any longer on exchange 2013. i keep getting 500 error.

  34. Be sure to launch Powershell ISE as a 64 bit process or the script will error out. That’s 20 minute’s I won’t ever get back 🙂

    Reply

  36. We are running Exchange 2013 on Server 2012 R2 IIS 6.2. Microsoft’s URL Rewrite download does not show as being available for IIS 6. Earliest version shown is IIS7. Can this URL Rewrite version be used with 6.2 or is there an earlier version I can source?

    Thanks for the great article. It is really well done!

    Reply

    1. It’s safe and recommended to install the Microsoft URL Rewrite module on Windows Server 2012 R2 (IIS 8.5 by default).

      There are two Internet Information Services (IIS) Managers on Exchange Server:

      – Internet Information Services (IIS) Manager
      – Internet Information Services (IIS) 6.0 Manager

      You need to open the first one and go to Help > About. That will tell your IIS version.

      Reply

      1. please disregard my previous question.
        IIS 8.5 is there with an IIS 6 Management Console installed as an additional Role service, which is what I initially picked up. Not sure was why that was added.

        Your article is so helpful thanks.

        Reply

  37. Your site was the first place I looked after the Exchange team blog. I truly appreciate how quickly you update your articles. Thank you!

    Reply

  41. In the Exchange environment, we do not have autodiscover from the external network. The link is blocked and it is not possible to get an autodiscover connection with outlook.
    Do we need IIS mitigation urgently?

    Thanks,

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *