Keeping Phishing Adversaries Out of the Middle

Okta’s Identity Defense Operations frequently observes the use of Adversary-in-the-Middle (AiTM) phishing proxies in high-volume, non-targeted attacks against users of corporate email services.

Real-time phishing proxies have been used in red team activity and targeted attacks since at least 2017. Microsoft Threat Intelligence Center (MSTIC) observed campaigns in July 2022 of far higher volume, with 10,000 Microsoft 365 customers targeted in one campaign alone. MSTIC also observed that accounts compromised in these attacks were being abused for Business Email Compromise (payment fraud).  

Since February 2023, Okta has observed AiTM campaigns targeting Microsoft 365 at similar, if not higher scale. Our visibility into these campaigns comes from customers that federate Microsoft 365 sign-ins to Okta.

This higher frequency is largely driven by the availability of AiTM proxy infrastructure on an “as-a-service” basis by groups like EvilProxy and NakedPages. "Phishing as a service" platforms lease access to the infrastructure, configuration, and phishing templates required to operate AiTM campaigns, providing a larger number of threat actors with access to advanced capabilities.

What is AiTM Phishing?

In an adversary-in-the-middle phishing attack, targets are directed to a malicious website that is configured as a reverse proxy server. These “real-time” phishing sites relay requests between a targeted user and an impersonated web application. 

If a user is tricked into signing in to the legitimate web application via one of these malicious sites, the attacker can access the user’s credentials and the session token returned to the browser. 

Users cannot authenticate via attacker-controlled proxies if they use phishing-resistant forms of authentication. 

Okta Identity Engine offers a choice of authenticators that meet the NIST definition for phishing resistance:

• FIDO2 WebAuthn (including support for both platform authenticators built into modern devices and roaming authenticators such as security keys).
• Okta Verify FastPass 
• Smart Cards

Why FastPass is Your Best Bet Against Phishing

Administrators of Okta orgs can enrol users in a broad range of authenticators, each of which offer varied levels of assurance. Given the scale at which AiTM campaigns now operate, Okta Verify FastPass stacks up as the most easily deployed and feature-rich defense, given its unique ability to:

• Detect and prevent AitM phishing campaigns and surface these events in Okta System Log for further investigation and remediation
• Collect device signals on both managed and unmanaged devices for use in policy evaluation and post-event analysis
• Probe for device signals every time a user requests a new application during a session. 
• Offer a consistent user experience on all OS/browser platforms
• Constrain credentials to a single device.

Let’s go through each in detail. 

1. Device Assurance



FastPass is more than just a certificate-based authenticator.

The FastPass agent also enables policies that can allow or deny access to resources based on whether a device is managed, and whether a managed device exhibits a secure posture.  

That capability also extends beyond managed devices. FastPass now collects a range of device signals on any device - managed or otherwise - to provide a baseline view of device posture (OS version, jailbreak status etc). This makes FastPass an ideal authenticator for the “extended enterprise". Admins can easily provide temporary access to specific apps and data to contractors and partners, without requiring them to sign in from devices the organization manages or controls.

2. Continuous Evaluation of Device Context

Traditionally, device context has been most relevant when evaluated at sign-in. Attacks that abuse a valid session token (typically stolen via infostealer malware or AiTM phishing) can bypass these protections. FastPass offers the opportunity to probe for device context more frequently, enabling workflows that identify and revoke stolen sessions.

3. Server-side Detection of AiTM Phishing Attempts

While both FIDO2 WebAuthn and Okta Verify FastPass can prevent AiTM phishing, the latter also offers detection opportunities. 

A failed origin check during an attempt to sign-in using FastPass can be observed server-side. When such an attempt is observed, the Okta service generates a System Log event. This provides security operations teams a high-confidence signal that users are under attack. This live demo shows how powerful that is in detection and response scenarios. 

Why does FastPass offer this detection, but FIDO2 WebAuthn doesn’t? It comes down to the intended design of each authenticator.  The designers of FIDO2 WebAuthn optimized for protecting both the security and the privacy of users. This involves trade-offs: some browsers, for example, allow a user to withhold information about an enrolled authenticator to prevent a user being tracked across multiple websites. 

The designers of Okta FastPass, on the other hand, optimized for user security, user experience and ease of administration. 

4. Usability

Usability is an overlooked aspect of security. Unfortunately, the authentication experience most users are most familiar with today (passwords, SMS etc) doesn't always offer the highest assurance.

Once enrolled, Okta FastPass and FIDO2 WebAuthn authenticators offer dramatically improved user experiences over passwords and OTPs. The process of signing in can be up to 50%-75% faster, depending on how many factors are required in policy. Okta FastPass can satisfy both a possession (device) and an inherence (biometric) factor in one gesture.

Again, there are subtle differences between the usability of each phishing-resistant authenticator. The experience of WebAuthn varies by browser and by whether the credential was enrolled in single-device or multi-device mode, and much of this nuance isn't obvious to users.

Okta FastPass, by contrast, is optimized for a consistent user experience in any browser and on any device (Android, iOS, MacOS and Windows).

5. Device-Bound Credentials

In a personal or consumer context, PassKeys (discoverable WebAuthn credentials) promise to dramatically accelerate the journey to passwordless authentication.

Today, multi-device credentials present some interesting challenges in an enterprise context. Where previously a platform-based WebAuthn credential was device-bound, they can now be transferred from a managed device to an unmanaged device using iCloud, AirDrop or alternative services hosted by Google or Microsoft.

This additional attack surface can materially degrade the assurance a credential provides. Consider a scenario in which admins enforce phishing resistant authenticators for access to sensitive applications and data: there is no guarantee that a user will apply the same requirement for access to their personal Apple, Google or Microsoft account. The path of least resistance for an attacker may be to phish a user for access to their personal accounts, to then obtain a credential that could potentially be used to unlock access to enterprise apps. So organizations using PassKeys have to accept the residual risk posed by a compromised personal cloud account.

FastPass, by contrast, binds credentials to a device. Administrators can also write policies for differentiated levels of access based on whether the credential was hardware-protected (stored in a Trusted Platform Module) versus stored in software.


Conclusion

FastPass and WebAuthn offer dramatically higher assurance than alternative forms of authentication. Given the lower bar for adversaries to conduct session-stealing phishing campaigns, we recommend enrolment policies that require Okta Verify and WebAuthn, and authentication policies that enforce phishing resistance at every opportunity.  

Beyond the immediate risks posed by AiTM phishing, we also recommend taking a holistic approach to managing the risk posed by hijacked sessions:

• Apply endpoint protection software to protect devices from malware that extracts session cookies from the user’s browser
• Evaluate Okta’s integrations with endpoint detection providers to deny authentication requests from devices exhibiting poor security hygiene
• Set maximum and idle application session duration according to NIST guidelines
• Set reauthentication frequency to “every time” for access to sensitive applications
• Deny requests from anonymizing proxies, from ASNs with a poor reputation or from locations where you don’t expect users to authenticate from. These requests can be blocked pre-authentication using Network Zones.
• Train users to identify indicators of suspicious emails, phishing sites and common social engineering techniques used by attackers. Make it easy for users to report potential issues by configuring End User Notifications and Suspicious Activity Reporting
• Protect administrative sessions: Take a "Zero Standing Privileges" approach to administrative access. Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. Apply ASN and IP Session Binding (from Settings > Features) to all administrative apps to prevent the replay of stolen administrative sessions. Enable Protected Actions (under Settings > Features) to force re-authentication whenever an administrative user attempts to perform sensitive actions.
• Talk to your SaaS partners about support for Demonstrating Proof-of-Possession, Continuous Access Evaluation Profile (CAEP) and Universal Logout.

Change Log

1.1 - March 8, 2024

• Updated recommendations to include new features released as part of Okta Secure Identity Commitment: Protected Actions, ASN/IP Session Binding.

1.0 - May 12, 2023

• Original Article Published