Platform
Solutions
Resources
Company
Platform
Solutions
Resources
Company

Dan Kondor
∙
Zero-Day Threats & Why Port 443 Matters


Dan Kondor
∙
Zero-Day Threats & Why Port 443 Matters


Dan Kondor
∙
Zero-Day Threats & Why Port 443 Matters

The initial attack in Microsoft Exchange's March 2021 zero-day vulnerabilities, including CVE-2021-26855 (known as ProxyLogon), required an untrusted connection to the server's port 443. Our Exchange servers were out of reach because every request to /owa/ and /ecp/ went to a WWPass authentication page first, so a scanner never got a response from Exchange itself.
The Alert and the First Scan
When I got an alert about Microsoft Exchange's zero-day vulnerabilities CVE-2021-26855, 26857, 26858, and 27065, I immediately checked the logs of attempted access to our standard exchange servers' ports. I usually find thousands of unsuccessful attempts to connect by various bots, port scanners, and similar players. I scanned these ports with well-known script http-vuln-exchange:
To explore these vulnerabilities, a malicious JS code must gain access to port 443 (which is possible if you use the default OWA authentication page):
But in our network, all access to web resources is controlled by WWPass authentication, where any requests to url /owa/ or /ecp/ are redirected to WWPass' authentication page with a QR code.
Our Exchange does not get a chance to respond until an authorized user scans a QR code with the WWPass Key app, our mobile multi-factor authenticator app.
As you can see from the script above, the attackers just got Error nil for /owa
It means that despite our Exchange servers having these vulnerabilities, due to properly established access control, they could not be exploited. So our Exchange servers were protected even before Microsoft announced these vulnerabilities and released the patches.
Testing the Hypothesis on an Exposed Exchange Server
To test my hypothesis, I used the same script to see how it would work with the Exchange server with the username/password login that was exposed to the internet and not protected by WWPass login.
You can immediately see the potential vulnerability, which can easily be exploited by hackers:
Exchange behind WWPass authentication | Exchange exposed behind a username/password login | |
|---|---|---|
Requests to /owa/ and /ecp/ | Redirected to a WWPass authentication page with a QR code | Reach the exposed login |
Scan result on port 443 | Error nil for /owa | (15.0.1497) Exchange 2013 potentially vulnerable |
Does Exchange respond to the scanner? | No, not until an authorized user scans the QR code | Yes, the script identifies the version |
What Can We Learn From This?
What can we learn from this accident? More importantly, why are our servers not a part of the ever-growing list of compromised ones?
IT security and aviation safety have a lot in common, so IT professionals can learn from the history of aviation accidents (and catastrophes). It's well known that in most cases, mishaps are attributed not to a single breakdown or human error (an IT security accident in our industry), but to a combination of factors. That's why to stay safe flying in the air (and in your datacenter), one must have multiple measures preventing potential issues.
Why Proactive Security Matters
Volexity, a Washington DC-based security firm, said the Hafnium attacks started as early as January 3, 2021, but the vulnerability was officially announced in early March. It is not unusual that there is a gap between when hackers start their activity and when affected organizations learn about it. That means that companies should be proactive in their security measures.
Why Username and Password Logins Fall Short
Zero-day vulnerabilities like the Microsoft Exchange one can usually be exploited through gaining access to systems through channels reserved for humans to legitimately get there. Unfortunately, most companies still use rudimentary username/password logins, which provide little protection against serious attacks. Some augment them with OTP "second factors" (SMS texts, Google Authenticator type generators, and such), which somehow improve security, although hardly dramatically.
How WWPass Login Improves Resilience
WWPass usernameless and passwordless login improves resilience against attacks, including those that exploit zero-day vulnerabilities. An additional layer of protection like this would definitely help not only keep user accounts safe, but also in most cases, mitigate other risks, like the one caused by the Exchange vulnerability.
FAQ
What were the March 2021 Microsoft Exchange zero-day vulnerabilities?
Four flaws (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065) that Microsoft disclosed and patched on March 2, 2021, after they were used against on-premises Exchange servers. Microsoft attributed the attacks to a group it calls HAFNIUM.
Why does port 443 matter for these vulnerabilities?
Microsoft said the initial attack required the ability to make an untrusted connection to the Exchange server's port 443. CISA's alert recommended restricting untrusted connections to port 443 (or using a VPN) and restricting external access to /owa/ and /ecp/, while noting that this doesn't help if the attacker is already inside the network.
How did authentication in front of Exchange keep these servers out of reach?
Requests to /owa/ and /ecp/ were redirected to a WWPass authentication page with a QR code, so Exchange didn't respond until an authorized user scanned the code with the WWPass Key app. A scan of the servers returned only "Error nil for /owa."
Does putting authentication in front of Exchange replace patching?
No. Staying safe takes multiple measures. Authentication in front of Exchange keeps unauthenticated requests from reaching it, but it doesn't help against an attacker already inside the network, and Microsoft's own tooling and patches remain part of the answer. Volexity observed exploitation starting in early January 2021, well before patches existed.
Get Started
To learn more about WWPass multi-factor authentication for Exchange and other services, contact us today.
The initial attack in Microsoft Exchange's March 2021 zero-day vulnerabilities, including CVE-2021-26855 (known as ProxyLogon), required an untrusted connection to the server's port 443. Our Exchange servers were out of reach because every request to /owa/ and /ecp/ went to a WWPass authentication page first, so a scanner never got a response from Exchange itself.
The Alert and the First Scan
When I got an alert about Microsoft Exchange's zero-day vulnerabilities CVE-2021-26855, 26857, 26858, and 27065, I immediately checked the logs of attempted access to our standard exchange servers' ports. I usually find thousands of unsuccessful attempts to connect by various bots, port scanners, and similar players. I scanned these ports with well-known script http-vuln-exchange:
To explore these vulnerabilities, a malicious JS code must gain access to port 443 (which is possible if you use the default OWA authentication page):
But in our network, all access to web resources is controlled by WWPass authentication, where any requests to url /owa/ or /ecp/ are redirected to WWPass' authentication page with a QR code.
Our Exchange does not get a chance to respond until an authorized user scans a QR code with the WWPass Key app, our mobile multi-factor authenticator app.
As you can see from the script above, the attackers just got Error nil for /owa
It means that despite our Exchange servers having these vulnerabilities, due to properly established access control, they could not be exploited. So our Exchange servers were protected even before Microsoft announced these vulnerabilities and released the patches.
Testing the Hypothesis on an Exposed Exchange Server
To test my hypothesis, I used the same script to see how it would work with the Exchange server with the username/password login that was exposed to the internet and not protected by WWPass login.
You can immediately see the potential vulnerability, which can easily be exploited by hackers:
Exchange behind WWPass authentication | Exchange exposed behind a username/password login | |
|---|---|---|
Requests to /owa/ and /ecp/ | Redirected to a WWPass authentication page with a QR code | Reach the exposed login |
Scan result on port 443 | Error nil for /owa | (15.0.1497) Exchange 2013 potentially vulnerable |
Does Exchange respond to the scanner? | No, not until an authorized user scans the QR code | Yes, the script identifies the version |
What Can We Learn From This?
What can we learn from this accident? More importantly, why are our servers not a part of the ever-growing list of compromised ones?
IT security and aviation safety have a lot in common, so IT professionals can learn from the history of aviation accidents (and catastrophes). It's well known that in most cases, mishaps are attributed not to a single breakdown or human error (an IT security accident in our industry), but to a combination of factors. That's why to stay safe flying in the air (and in your datacenter), one must have multiple measures preventing potential issues.
Why Proactive Security Matters
Volexity, a Washington DC-based security firm, said the Hafnium attacks started as early as January 3, 2021, but the vulnerability was officially announced in early March. It is not unusual that there is a gap between when hackers start their activity and when affected organizations learn about it. That means that companies should be proactive in their security measures.
Why Username and Password Logins Fall Short
Zero-day vulnerabilities like the Microsoft Exchange one can usually be exploited through gaining access to systems through channels reserved for humans to legitimately get there. Unfortunately, most companies still use rudimentary username/password logins, which provide little protection against serious attacks. Some augment them with OTP "second factors" (SMS texts, Google Authenticator type generators, and such), which somehow improve security, although hardly dramatically.
How WWPass Login Improves Resilience
WWPass usernameless and passwordless login improves resilience against attacks, including those that exploit zero-day vulnerabilities. An additional layer of protection like this would definitely help not only keep user accounts safe, but also in most cases, mitigate other risks, like the one caused by the Exchange vulnerability.
FAQ
What were the March 2021 Microsoft Exchange zero-day vulnerabilities?
Four flaws (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065) that Microsoft disclosed and patched on March 2, 2021, after they were used against on-premises Exchange servers. Microsoft attributed the attacks to a group it calls HAFNIUM.
Why does port 443 matter for these vulnerabilities?
Microsoft said the initial attack required the ability to make an untrusted connection to the Exchange server's port 443. CISA's alert recommended restricting untrusted connections to port 443 (or using a VPN) and restricting external access to /owa/ and /ecp/, while noting that this doesn't help if the attacker is already inside the network.
How did authentication in front of Exchange keep these servers out of reach?
Requests to /owa/ and /ecp/ were redirected to a WWPass authentication page with a QR code, so Exchange didn't respond until an authorized user scanned the code with the WWPass Key app. A scan of the servers returned only "Error nil for /owa."
Does putting authentication in front of Exchange replace patching?
No. Staying safe takes multiple measures. Authentication in front of Exchange keeps unauthenticated requests from reaching it, but it doesn't help against an attacker already inside the network, and Microsoft's own tooling and patches remain part of the answer. Volexity observed exploitation starting in early January 2021, well before patches existed.
Get Started
To learn more about WWPass multi-factor authentication for Exchange and other services, contact us today.
The initial attack in Microsoft Exchange's March 2021 zero-day vulnerabilities, including CVE-2021-26855 (known as ProxyLogon), required an untrusted connection to the server's port 443. Our Exchange servers were out of reach because every request to /owa/ and /ecp/ went to a WWPass authentication page first, so a scanner never got a response from Exchange itself.
The Alert and the First Scan
When I got an alert about Microsoft Exchange's zero-day vulnerabilities CVE-2021-26855, 26857, 26858, and 27065, I immediately checked the logs of attempted access to our standard exchange servers' ports. I usually find thousands of unsuccessful attempts to connect by various bots, port scanners, and similar players. I scanned these ports with well-known script http-vuln-exchange:
To explore these vulnerabilities, a malicious JS code must gain access to port 443 (which is possible if you use the default OWA authentication page):
But in our network, all access to web resources is controlled by WWPass authentication, where any requests to url /owa/ or /ecp/ are redirected to WWPass' authentication page with a QR code.
Our Exchange does not get a chance to respond until an authorized user scans a QR code with the WWPass Key app, our mobile multi-factor authenticator app.
As you can see from the script above, the attackers just got Error nil for /owa
It means that despite our Exchange servers having these vulnerabilities, due to properly established access control, they could not be exploited. So our Exchange servers were protected even before Microsoft announced these vulnerabilities and released the patches.
Testing the Hypothesis on an Exposed Exchange Server
To test my hypothesis, I used the same script to see how it would work with the Exchange server with the username/password login that was exposed to the internet and not protected by WWPass login.
You can immediately see the potential vulnerability, which can easily be exploited by hackers:
Exchange behind WWPass authentication | Exchange exposed behind a username/password login | |
|---|---|---|
Requests to /owa/ and /ecp/ | Redirected to a WWPass authentication page with a QR code | Reach the exposed login |
Scan result on port 443 | Error nil for /owa | (15.0.1497) Exchange 2013 potentially vulnerable |
Does Exchange respond to the scanner? | No, not until an authorized user scans the QR code | Yes, the script identifies the version |
What Can We Learn From This?
What can we learn from this accident? More importantly, why are our servers not a part of the ever-growing list of compromised ones?
IT security and aviation safety have a lot in common, so IT professionals can learn from the history of aviation accidents (and catastrophes). It's well known that in most cases, mishaps are attributed not to a single breakdown or human error (an IT security accident in our industry), but to a combination of factors. That's why to stay safe flying in the air (and in your datacenter), one must have multiple measures preventing potential issues.
Why Proactive Security Matters
Volexity, a Washington DC-based security firm, said the Hafnium attacks started as early as January 3, 2021, but the vulnerability was officially announced in early March. It is not unusual that there is a gap between when hackers start their activity and when affected organizations learn about it. That means that companies should be proactive in their security measures.
Why Username and Password Logins Fall Short
Zero-day vulnerabilities like the Microsoft Exchange one can usually be exploited through gaining access to systems through channels reserved for humans to legitimately get there. Unfortunately, most companies still use rudimentary username/password logins, which provide little protection against serious attacks. Some augment them with OTP "second factors" (SMS texts, Google Authenticator type generators, and such), which somehow improve security, although hardly dramatically.
How WWPass Login Improves Resilience
WWPass usernameless and passwordless login improves resilience against attacks, including those that exploit zero-day vulnerabilities. An additional layer of protection like this would definitely help not only keep user accounts safe, but also in most cases, mitigate other risks, like the one caused by the Exchange vulnerability.
FAQ
What were the March 2021 Microsoft Exchange zero-day vulnerabilities?
Four flaws (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065) that Microsoft disclosed and patched on March 2, 2021, after they were used against on-premises Exchange servers. Microsoft attributed the attacks to a group it calls HAFNIUM.
Why does port 443 matter for these vulnerabilities?
Microsoft said the initial attack required the ability to make an untrusted connection to the Exchange server's port 443. CISA's alert recommended restricting untrusted connections to port 443 (or using a VPN) and restricting external access to /owa/ and /ecp/, while noting that this doesn't help if the attacker is already inside the network.
How did authentication in front of Exchange keep these servers out of reach?
Requests to /owa/ and /ecp/ were redirected to a WWPass authentication page with a QR code, so Exchange didn't respond until an authorized user scanned the code with the WWPass Key app. A scan of the servers returned only "Error nil for /owa."
Does putting authentication in front of Exchange replace patching?
No. Staying safe takes multiple measures. Authentication in front of Exchange keeps unauthenticated requests from reaching it, but it doesn't help against an attacker already inside the network, and Microsoft's own tooling and patches remain part of the answer. Volexity observed exploitation starting in early January 2021, well before patches existed.
Get Started
To learn more about WWPass multi-factor authentication for Exchange and other services, contact us today.

Get WWPass
Download the WWPass Key app and test authentication without a username or password.

Get WWPass
Download the WWPass Key app and test authentication without a username or password.
