Dan Kondor

∙

Zero-Day Threats & Why Port 443 Matters

Zero-Day Threats & Why Port 443 Matters

Dan Kondor

∙

Zero-Day Threats & Why Port 443 Matters

Zero-Day Threats & Why Port 443 Matters

Dan Kondor

∙

Zero-Day Threats & Why Port 443 Matters

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.

© 2026 World Wide Pass — WWPass

Get WWPass

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

© 2026 World Wide Pass — WWPass

Get WWPass

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

© 2026 World Wide Pass — WWPass