Exchange 2016 Successful ProxyShell exploitation

[pronto 6]

Servus Community,

a Thor scan has detected anomalies on one of our Exchange servers tonight (see screenshot). Apparently it is a vulnerability in the Autodicover protocol of the Exchange server. Heise (a major IT magazine in Germany) notes several attack vectors regarding Autodiscover (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) [1/de], which Microsoft should have fixed with the patches KB5001779 [1] and KB5003435 [2] According to Microsoft, both patches should already be included in CU20. This is installed on our servers. Why Thor recognizes this attack as successful, I can not yet estimate.

ESET actually continuously logs the blocking of an attempt to exploit a vulnerability on the server, but does not go into further detail about which vulnerability it is. Is there any way to find out which vulnerabilities these are specifically, and can we find out if ESET has a matching pattern for the above vulnerabilities, and especially since when? Is anything known in this context in your offices?

[1] https://www.heise.de/news/Exchange-Server-jetzt-patchen-Angreifer-suchen-aktiv-nach-neuer-Luecke-6158190.html

[2] https://support.microsoft.com/en-us/topic/description-of-...-kb5001779

[3] https://support.microsoft.com/en-us/topic/description-of-...-kb5003435

Thx & Bye Tom

[itman 1,659]

Refer to this article: https://www.bleepingcomputer.com/news/microsoft/microsoft-exchange-servers-scanned-for-proxyshell-vulnerability-patch-now/

Quote

Attackers scan for vulnerable Exchange servers

This week, security researcher Kevin Beaumont tweeted that a threat actor was probing his Microsoft Exchange honeypot against the server's Autodiscover service.

Interesting thing I noticed in MailPot with Exchange servers - somebody has started targeting them using autodiscover.json, a detection avoidance and relatively undocumented feature it appears. pic.twitter.com/MOuTaoOQL2

— Kevin Beaumont (@GossiTheDog) August 2, 2021

While these initial attempts were unsuccessful, last night, after more details about the vulnerability were released, attackers modified their scans to use the new Autodiscover URL disclosed in Tsai's slide above.

https://Exchange-server/autodiscover/autodiscover.json?@foo.com/mapi/nspi/?&Email=autodiscover/autodiscover.json%3F@foo.com

Using the new URL, it appears that the threat actors were successfully able to detect a vulnerable system as it triggers the compilation of the ASP.NET web application.

At this point, it appears to me Eset is blocking the attempted scanning of the Exchange server. Hard to determine since your Event log screen shot is in German language.

Edited August 10, 2021 by itman

[pronto 6]

7 minutes ago, itman said:

Refer to this article: https://www.bleepingcomputer.com/news/microsoft/microsoft-exchange-servers-scanned-for-proxyshell-vulnerability-patch-now/

At this point, it appears to me Eset is blocking the attempted scanning of the Exchange server. Hard to determine since your Event log screen shot is in German language.

It doesn't really say anything useful. The really important information, e.g. which security vulnerability is being tried to be exploited, is unfortunately missing. Translated it says:

Quote

Attempt to exploit a security vulnerability: Blocked

Thx & Bye Tom

[itman 1,659]

4 minutes ago, pronto said:

It doesn't really say anything useful. The really important information, e.g. which security vulnerability is being tried to be exploited, is unfortunately missing.

In may be that Eset is handling this activity as a "generic" detection as shown here: https://forum.eset.com/topic/21959-firewall-in-eset-mail-security/

[pronto 6]

1 minute ago, itman said:

In may be that Eset is handling this activity as a "generic" detection as shown here: https://forum.eset.com/topic/21959-firewall-in-eset-mail-security/

This happens all the time, day in and day out. What should I do with this information? But if it should be brute force attempts, then it probably does not concern the security vulnerability mentioned here. The question is also whether ESET detects this at all or only becomes active when dangerous files are installed on the system.

The backdoor of the Hafnium exploit was found by ESET but only a few hours later. Whether ESET would have detected the exploit at a later time, even before the backdoor was installed, I don't know.

Unfortunately, I know too less about the impact of this vulnerability.

Thx & Bye Tom

 

[itman 1,659]

50 minutes ago, pronto said:

This happens all the time, day in and day out. What should I do with this information?

What Thor and Eset subsequently are detecting is this scanning activity:

Quote

While these initial attempts were unsuccessful, last night, after more details about the vulnerability were released, attackers modified their scans to use the new Autodiscover URL disclosed in Tsai's slide above.

https://Exchange-server/autodiscover/autodiscover.json?@foo.com/mapi/nspi/?&Email=autodiscover/autodiscover.json%3F@foo.com

 

Since your Exchange Server 2016 OS is fully patched, the scans and subsequent detection's are of no concern; at least presently. As I see it, the only way to prevent this scanning activity is to block it at the network perimeter. How this could be done w/o busting legit inbound traffic I have no clue. Or, wait till Microsoft issues a patch to eliminate this Autodiscover URL capability.

This does show the advantage of using a third party e-mail forwarder service. You allow inbound e-mail traffic from that concerns IP address at the network perimeter and block everything else. 

Edited August 10, 2021 by itman

[itman 1,659]

Another nasty current attack is the following, if applicable to your environment:

Quote

Researchers said organizations that handle sensitive data on their servers should watch for this malware. In particular, organizations using Outlook on the web (OWA) service on their Exchange email servers.

“OWA is implemented via IIS and makes an interesting target for espionage. In any case, the best way to keep IISpy out of your servers is to keep them up to date, and carefully consider which services are exposed to the internet, to reduce the risk of server exploitation,” they added.

https://www.itpro.co.uk/security/cyber-security/360521/new-malware-plants-backdoor-on-microsoft-web-server-software

Edited August 10, 2021 by itman

[pronto 6]

3 hours ago, itman said:

Since your Exchange Server 2016 OS is fully patched, the scans and subsequent detection's are of no concern; at least presently. As I see it, the only way to prevent this scanning activity is to block it at the network perimeter. How this could be done w/o busting legit inbound traffic I have no clue. Or, wait till Microsoft issues a patch to eliminate this Autodiscover URL capability.

I think it's time to seriously consider a reverse proxy server. We used to have one when Microsoft had a TMG server in their portfolio, but after that was discontinued, our Exchange servers are connected directly to the Internet. Not having one was already not an advantage with the hafnium exploit issue a few month ago. We had to reinstall all the Exchange servers at this time.

Btw: Our Exchangers are not fully patched. We have installed the CU20, but there were three security updates that are still missing. At least Microsoft states that CU20 is sufficient, there was no mention of security patches. A technician from our service provider also said that CU20 should be sufficient and Thor may have only registered the HTTP request.

Tomorrow I will install the last security patch and in two weeks the current CU21. In the meantime I'll get busy looking for signs of a successful exploit but to do that I need to know what to be looking for first. Until then, I hope ESET keeps its eyes open and I still don't get any negative feedback.

If anyone has any concrete leads on what to be looking for already, that information would be helpful.

Thx & Bye Tom

Edited August 10, 2021 by pronto

[itman 1,659]

1 hour ago, pronto said:

I think it's time to seriously consider a reverse proxy server.

Microsoft "best practices" indeed recommends this: https://social.technet.microsoft.com/wiki/contents/articles/13974.microsoft-security-best-practices-to-protect-internet-facing-web-servers.aspx