doublepulsar.com Open in urlscan Pro
52.0.16.118 Public Scan

Back to summary

Submitted URL:
https://doublepulsar.com/proxynotshell-the-story-of-the-claimed-zero-day-in-microsoft-exchange-5c63d963a9e9
Effective URL:
https://doublepulsar.com/proxynotshell-the-story-of-the-claimed-zero-day-in-microsoft-exchange-5c63d963a9e9?gi=33c99365ec3a
Submission: On February 24 via api (February 24th 2023, 4:45:44 am UTC) from US — Scanned from DE

Form analysis
0 forms found in the DOM

Text Content

Open in app

Write

Published in

DoublePulsar

You have 2 free member-only stories left this month.

Kevin Beaumont
Follow

Sep 29, 2022

·
10 min read
·

Member-only

Listen

Save

PROXYNOTSHELL— THE STORY OF THE CLAIMED ZERO DAYS IN MICROSOFT EXCHANGE

Yesterday, cybersecurity vendor GTSC Cyber Security dropped a blog saying they
had detected exploitation of a new Microsoft Exchange zero day:

Warning: New attack campaign utilized a new 0-day RCE vulnerability on Microsoft
Exchange Server | Blog | GTSC — Cung cấp các dịch vụ bảo mật toàn diện
(gteltsc.vn)

If a zero day in Exchange was real, history has shown things go south quickly…
so let us dig into it.

The official logo, because why not.

You can see ZDI confirm they accepted it here as ZDI-CAN-18333 and ZDI-18802

There’s some questions I have from the GTSC write up, e.g.:

That request string looks exactly like ProxyShell, a vulnerability from 2021.

Additionally, the mitigation they give is exactly the same as the ProxyShell
Powershell RCE issue from 2021:

My tweet about that path at the time:

I doubt, from experience, by earlier today it had been through full triage yet
at Microsoft, so some of the information out there will be questionable. (Update
below)

A quick sweep of the internet suggests a lot of organisations haven’t yet
patched for ProxyShell, which is understandable given how Exchange patching
works (if you disagree, you likely haven’t patched Exchange).

Update: Microsoft have been through triage now, and issued CVE-2022–41040 and
CVE-2022–41082. These are two new zero day vulnerabilities in Exchange. It
appears the ProxyShell patches from early 2021 did not fix the issue. There are
currently no patches.

I am calling this ProxyNotShell, as it is the same path and SSRF/RCE pair from
back then… but with authentication.

They do have a significant find in the malware, which attempts to emulate
Microsoft Exchange EWS service:

Additionally, it calls out to 137.184.67[.]33, which is currently running a fake
RD Congo Repats website — which has only 1 user, with 1 minute of login time.
That site has been active since August this year, and looks suspect.

Trend Micro have detection coverage signatures deployed two days ago, and also
call it a zero day.

MITIGATIONS

If you don’t run Microsoft Exchange on premise, and don’t have Outlook Web App
facing the internet, you are not impacted.

You can find out if you have Outlook Web App presented to the internet by
searching Shodan.io for http.component:”outlook web app” — you can add the
filter org:yourorgname or ssl:”*yourorgname*” to find your organisation.

There are a lot of Exchange servers on the internet running Outlook Web App — I
suspect a lot of organisations want to review the level of risk regardless, as
they often don’t need it presenting any more.

source: Shodan

Near a quarter of a million vulnerable Exchange servers face the internet, give
or take.

Please note exploitation needs valid non-admin (or admin) credentials for any
account.

MICROSOFT MITIGATIONS

Microsoft say “Microsoft Exchange Online Customers do not need to take any
action.” This is false — if you run Exchange hybrid servers, a standard part of
Microsoft Exchange Online migration, they are vulnerable. Thousands of orgs
present these to the internet, too.

Microsoft’s Exchange team recommend you update Hybrid servers if you use
Exchange Online:

Microsoft recommend disabling Remote Powershell for Exchange for non-admin users
using this guide. I would be cautious implementing this for a number of reasons
— including if you accidentally restrict access too broadly, you can break
Exchange cluster wide. So, ensure you don’t apply to Exchange service accounts
and Exchange administrators.

End users need to be a member of an Exchange management group to use Remote
Powershell — which isn’t a default configuration.

Microsoft do have some additional mitigations mentioned below in updates, but I
haven’t mentioned them due to effectiveness problems.

PATCHES

There are none yet.

HUNTING

To hunt for SSRF to the Exchange management interface, run something like this
(MS Sentinel format) — it requires you be collecting IIS logs.

ThreatHunting/Exchange-CVE-2021–34473-SSRF at master · GossiTheDog/ThreatHunting
· GitHub

To hunt for RCE, run something like this:

ThreatHunting/Exchange-Powershell-via-SSRF at master · GossiTheDog/ThreatHunting
· GitHub

Both queries are from 2021, but still work.

I also published two Advanced Hunting Queries for Microsoft Defender for
Endpoint. These look for any Exchange servers with unknown processes under IIS,
and any Exchange servers with PowerShell Remoting processes.

ThreatHunting/MSExchange-UnknownSubprocesses at master ·
GossiTheDog/ThreatHunting · GitHub

SO WHAT IN CONCLUSION

* I can say for sure attacks have been happening on Exchange servers which
match these patterns
* I can’t say for sure it’s a zero day, with the information provided — it
looks more ProxyShell to me. UPDATE: Scrap that, Microsoft say they are two
new zero days.
* The information provided may not be complete or there may be a patch
regression somewhere, it is unclear
* Microsoft, ZDI and GTSC need to talk
* Some of the malware (I’m talking the backdoor portion) planted appears brand
new
* I will keep updating this post with more information
* As always, stay calm and keep on keeping on.

UPDATES

30TH SEPTEMBER 2022–9AM BST

Microsoft have issued a blog post.

30TH SEPTEMBER 2022–3PM BST

Added Defender hunting query.

1ST OCTOBER 2022–11AM BST

Microsoft have stealth removed this mitigation from their blog:

Archive link. If you got network teams to make this mitigation for RCE, do not
consider it a valid mitigation.

If you are on an Exchange Cumulative Update made available after September 2021,
Microsoft have deployed an Exchange Emergency Mitigation Service (EEMS) update
to attempt to block attacks, if your system is eligible.

To check this is applied, go to Administrative Tools -> IIS Manager -> Sites ->
Default Website and click URL Rewrite. If you see the below, this is deployed.

Microsoft have made available Exchange On-premises Mitigation Tool v2 (EOMTv2),
a PowerShell script you can use to mitigate any impacted Exchange version. The
tool is below:

EOMTv2 — Microsoft — CSS-Exchange

This tool has to be run manually. Please note this tool requires the following
installation to work:

Update for Universal C Runtime in Windows (microsoft.com)

3RD OCTOBER 2022–1PM BST

Microsoft’s mitigation of using URL rewrite — delivered via EOMTv2 and via EEMS,
and in the manual mitigations — is easily bypassable. Video by GTSC, the
original finders:

As found by Jang. Microsoft should probably look at the source code to Exchange.

A better mitigation:

Also, add a rule from {HTTP_COOKIE} containing Email=autodiscover, to terminate
the connection.

Microsoft have removed the suggestion of abandoning Legacy Auth in Exchange
on-prem and using Modern Authentication MFA from their security blog, given
Exchange on-prem doesn’t support Modern Authentication yet, in the space year
2022:

4TH OCTOBER 2022 — 11AM BST

Microsoft have failed to acknowledge their mitigation bypass. I have published a
video detailing the risks involved:

GreyNoise see 24 IP addresses scanning for ProxyNotShell vulnerable systems,
with 22 of those IPs tagged as malicious:

GREYNOISE TRENDS

AT GREYNOISE, WE COLLECT AND ANALYZE UNTARGETED, WIDESPREAD, AND OPPORTUNISTIC
SCAN AND ATTACK ACTIVITY THAT REACHES…

viz.greynoise.io

4TH OCTOBER 2022–9PM BST

Microsoft have corrected the mitigation guidance for the bypass:

They have not mentioned the mitigation was easily bypassable.

If you manually applied this mitigation you need to manually *change* the
mitigation string above. If you ran EOMTv2, you need to redownload the script
and run it again. The EOMTv2 website doesn’t say the script has changed — so
make sure your admins have the right script.

The bypass was this:

The source of the problem was this — Microsoft Exchange’s source code replaces
.. with @, and Microsoft didn’t know.

Exchange source code, via Will Dormann

The ‘So What’ with all of this is your Exchange Servers were not protected, and
still aren’t if you haven’t got EEMS installed or manually applied the new
mitigations… so we begin the cycle again.

5TH OCTOBER 2022–4PM BST

There is now a bypass of the mitigation for the bypass of the mitigation.

Microsoft forgot to enable URL decoding in IIS URL Rewrite, so you can just
encode the P in Powershell as %50 as an example:

Credit: Will Dormann

I observed this in the wild on an Exchange server today, where they used both ..
in place of @ (the earlier mitigation bypass) and encoded part of the Powershell
string, to bypass Exchange Emergency Mitigation Service.

Fix = change the URL Rewrite rule to this:

5TH OCTOBER 2022–10PM BST

Volexity, who found ProxyLogon, attributes this activity to a China based threat
actor in the thread below:

This threat actor also had a zero day in Zimbra email solution.

Separately, two of the known victims are the Turkish Ministry of Trade and the
Turkish Ministry of Industry and Technology — both run Exchange Server presented
to the internet.

Turkish Ministry of Industry and Technology

6TH OCTOBER 2022–11AM

There are currently 31 IPs scanning the internet for ProxyNotShell vulnerable
systems, with 27 of those being tagged as malicious, according to GreyNoise:

Microsoft have again updated their mitigations, to deal with the bypass for the
mitigation of the mitigation of the mitigation mention above:
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

Exchange Server users who manually applied the mitigation or ran EOMTv2 script
should reapply the mitigation using the guide above.

7TH OCTOBER 2022–10AM BST

People have found there is another bypass to the mitigation to bypass to the
mitigation to the bypass to the mitigation. Details later but Microsoft might
want to check around this code:

> public static bool IsAutodiscoverV2PreviewRequest(string path) {
> ArgumentValidator.ThrowIfNull(“path”, path); return
> path.EndsWith(“/autodiscover.json”, StringComparison.OrdinalIgnoreCase); }

Additionally, many of Microsoft’s signatures for detection of this threat rely
on monitoring w3wp.exe, aka IIS. This is where subprocesses are spawned,
webshells are written (and read) etc.

However, there’s a big issue — if you use Windows Server 2016 or above,
Microsoft automatically exclude w3wp.exe when IIS is installed — which Exchange
Server does:

The other highlight above is the IIS temp folders are excluded, which is where
.net objects (common as Exchange exploit artefacts) live.

This applies for the free version of Microsoft Defender, and Defender for
Endpoint (and the cloud/server variants).

The result is Microsoft’s telemetry is incomplete, and webshells and such aren’t
being detected properly — this likely explains why easily detectable, on
VirusTotal, webshells have been used in the wild like this. IIS isn’t monitored.

These exclusions aren’t visible on the box, or in Microsoft Defender for
Endpoint’s portal.

The only way to correct this is to turn off automatic exclusions:

However Microsoft specifically recommend not doing this.

8TH OCTOBER 2022 — MIDNIGHT BST

Microsoft have published another manual mitigation, EOMTv2 script and EEMS
update, to cover a bypass in my previous entry.

The technical issue was the code will accept anything if autodiscover.json is at
the end of the request. So you can stick /powershell earlier in the request.

This is from the MS Exchange source:

So you can request, say:

/autodiscover/admin..localhost/powershell/autodiscover.json?blah=foo

Exchange strips it down and still processes, and it doesn’t meet the prior regex
as Powershell isn’t at the end.

October 9th 2022–10am BST

The mitigation has been updated again by MS.

Regex changed from:

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

to:

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

Additionally, a new webshell file name:

8TH NOVEMBER 2022–7PM GMT

Microsoft have finally released a patch for this. Head over to Security Updates
on this to grab the patches (you need to be on a supported Cumulative Update to
have a patch).

CVE-2022–41082 — Security Update Guide — Microsoft — Microsoft Exchange Server
Remote Code Execution Vulnerability

Cybersecurity
Zero Day
Microsoft Exchange

284

BY DOUBLEPULSAR

Cyber Threat Content and Response, from porgs, direct to your email box. Take a
look.

By signing up, you will create a Medium account if you don’t already have one.
Review our Privacy Policy for more information about our privacy practices.

Get this newsletter

doublepulsar.com Open in urlscan Pro 52.0.16.118 Public Scan

Form analysis 0 forms found in the DOM

Text Content

doublepulsar.com Open in urlscan Pro
52.0.16.118 Public Scan

Form analysis
0 forms found in the DOM