Detect and Prevent Cross Device Authentication
So, you recently implemented phishing-resistant authentication policies.
Firstly, congrats! You’ve significantly raised the bar for potential threat actors and have a far better chance of detecting a compromise going forward. This will force threat actors to shift their focus to compromising your end-user devices. So what does this actually look like and what else can you do?
Even with phishing resistant authentication in place, there are several techniques a threat actor could employ that leverage a compromised endpoint to successfully authenticate to Okta-protected resources. The threat model for FIDO authentication, for example, notes that there are limits to how much protection an authenticator offers if the hardware it operates on is compromised.
One such example of this is what we call a ‘Cross Device Authentication (CDA) attack’ - this is when an attacker connects to a protected resource from their machine and forwards the required authentication flow through a machine they have previously compromised to gain unauthorized access.
I won't go into all the details here, as this technique has previously been proposed and documented by other researchers (XPNSec, GitLab).
Combatting CDA Attacks
Prevention
Steve Lind recently published a great blog, ‘Stay secure with FastPass and Trusted App Filters’, which details what Trusted App Filters are and how they can be used to protect against Cross Device Authentication (CDA) attacks, so be sure to check it out.
Detection
In this blog post, I would like to provide some potential detection ideas off the back of Trusted App Filters. When you authenticate with FastPass using the LOOPBACK or APPLE_SSO_EXTENSION binding methods (i.e. the phishing-resistant methods), you will find in the associated user.authentication.auth_via_mfa event, under the ‘AuthenticatorContext’ object, a variety of information about the process that initiated the authentication is logged.

These values are particularly useful from a detection perspective, as they give you visibility into what process the authentication request was initiated from, and can be used to detect unexpected or anomalous processes initiating authentication in your environment. Our Identity Defence Operations team have put together an example query that you can use to identify authentication requests that are not initiated by a browser using System Log.
Leveraging Adam Chester’s lightweight proxy on our attacker machine and an SSH reverse proxy on the compromised machine, when we authenticate to an Okta protected resource from the attackers machine, the authentication request is forwarded over the reverse proxy to FastPass on the compromised machine. Looking in the ‘AuthenticatorContext’ object we can see that the initiating process is SSH.

Another potential avenue for detecting Cross Device Authentication (CDA) attacks is via anomalies in the session establishment. During the authentication flow a user.session.start event and a user.authentication.auth_via_mfa event are generated. Leveraging the root_session_id, we can tie these events together. Next we can extract the client IPs from each event, looking for when they don't match. In an attack scenario, the IP in the user.session.start event will be the attacker and the IP in the user.authentication.auth_via_mfa event will be the compromised device. We can then layer techniques like impossible travel, conflicting ASNs or changes in User Agents to identify suspicious events. At times, (depending on your environment) these methods can be prone to false positives, so combining this with an anomalous calling process can help filter out the noise and turn this into a robust detection opportunity.

Closing comments
To find out more, I highly recommend checking out Steve Lind’s recent blog, which covers Trusted Application Filters more in-depth. If you can’t get enough after that, check out our Oktane on Demand 2024 session, where Steve and I include a demo on how Trusted App Filters can thwart Cross Device Authentication (CDA) attacks.