Written by Francis Geronimo (Senior IT Engineer) and Zeeshan Khadim (Head of Security)
In this blog, we will cover how Panther deployed phishless FIDO2 (WebAuthn) security keys, including details on the hardware, software, and steps taken. The aim of this blog is to help other organizations understand, prioritize and deploy this effective security control.
Phishing is one of the most prevalent social engineering attacks. According to Verizon’s 2022 DBIR, 82% of breaches involved a human element and 20% of breaches involved phishing, with another 40% involving stolen credentials.
Recent targeted phishing attacks against Twilio, Cloudflare and other companies reinforce the need for companies to adapt phishless forms of Multi-factor Authentication (MFA). In these targeted attacks, the phishing kit would immediately relay any captured username and passwords to the attacker, in addition to any provided Time-based One-Time Password (TOTP) MFA codes. The attacker would then quickly leverage the stolen credentials and TOTP codes before they expired. In Cloudflare’s case, they used FIDO2 (WebAuthn) security keys, instead of TOTP codes, thwarting the attackers.
FIDO2 (WebAuthn) security keys cannot be phished due to origin binding, whereas TOTP codes from an SMS text, authenticator app, or YubiKey can be captured and replayed, and push-based MFA can be bypassed through social engineering techniques like a “fatigue attack”.
At Panther, we utilize Okta as our IdP and we use FIDO2 (WebAuthn) security keys from YubiKey in conjunction with Okta’s Adaptive MFA product. Our Okta policy is configured to only allow WebAuthn MFA, disallowing SMS, TOTP or push-based MFA mechanisms to defend against similar social engineering attacks. This policy is applied to all of our full time employees and contractors across the globe.
Each colleague receives two security keys, a Yubikey 5ci and a Yubikey 5c Nano. The Yubikey 5ci can be used by both laptops and mobile devices, but is largely intended for enrolling and supporting the mobile device. The Yubikey 5c Nano is for laptops and is intended to stay plugged in, given its small, flush-like form-factor.
To limit frustration and friction, employees also register a biometric factor, using TouchID/FaceID for macOS and iOS, and Fingerprint Auth for Android. This limits the frequency the 5ci is needed for mobile, supports employees who prefer TouchID over a always-used USB port, and it helps employees get “unstuck”, in the event a security key is lost, damaged or forgotten at home.
Prior to the deployment of security keys, Panther used a mix of TOTP and push-based MFA. To determine the viability of migration, we did an audit of employee’s devices to determine what percentage of devices supported USB-C, Lightning and/or Biometric authentication.
We leveraged Google Workspace and Okta logs to perform this audit. With these datasets already flowing into our internal Panther deployment, we ran a query similar to the following to identify the types of mobile devices being used:
SELECT
client:userAgent:os,
client:userAgent:rawUserAgent,
COUNT(DISTINCT (actor:alternateId)) as userCount
FROM
panther_logs.public.okta_systemlog
WHERE
p_occurs_since('7 days')
GROUP BY
client:userAgent:os, client:userAgent:rawUserAgent
ORDER BY
userCount DESCCode language: SQL (Structured Query Language) (sql)We determined nearly all of our colleague’s devices were compatible. In the cases where they weren’t, we simply paid the employee to get a newer phone. While this cost could be seen as excessive (especially with larger organizations), it’s worth considering the cost of the mitigating control you would otherwise have to deploy and maintain, in addition to the risk absorbed by the business.
Our next step was to find a provider that would streamline and automate YubiKey deployment. We ended up using Yubico’s YubiEnterprise Delivery platform to handle the logistics of delivering YubiKeys to our colleagues across the globe.
Next, we developed documentation to help the company with initial enrollment and setup of their YubiKeys with detailed instructions and screenshots to make the transition as seamless as possible.
Lastly, we gradually rolled out the new policy that only allowed WebAuthn MFA, and disallowed SMS, TOTP and push-based MFA via Okta Verify and otherwise. Utilizing Okta Groups and their native authentication policies, we were able to stage the rollout of this policy in phases, identifying any pain points early on.
SSO Tax: The value of a security key deployment is partly dependent on how many applications are protected and behind your IdP. This is largely due to the fact that very few applications support FIDO2 (WebAuthn) security keys natively. To have the greatest protection possible, Panther has a policy of paying the “SSO tax”, to ensure all of our business applications are protected by phishless MFA, in addition to achieving consistent logging, role-based access, and automated provisioning and deprovisioning. While we disagree with the “SSO tax” in principle, the alternative of building and relying on manual IT processes, the deployment of additional compensating or alternative controls, and the risk of a successful phishing attack, is seen as more expensive, both operationally and from a business perspective.
CTAP: Some popular applications don’t support FIDO2 (WebAuthn) security keys. For example, the “desktop” version of Office365 for macOS. For these users, you will need to create an MFA exception in your IdP. Using Okta Identity Engine, we are able to limit the scope of the exception to specific applications such as Office365. Additionally, Okta Workflows can be used to time bound the exceptions by automatically removing users from Okta groups bound to the authentication policy exception.
Mobile Apps Biometrics: iOS apps leveraging an embedded browser for their WebAuthn flow (WKWebView) will not recognize TouchID/FaceID. As a result, your users will need to leverage their FIDO2 (WebAuthn) security key. An example is the Asana iOS application.
Logistical Delays: As a remote-first company, we found that logistical delays and supply chain shortages were hampering new employees from being effective on day 1. Our process at the time was to order Yubikeys as needed. We solved this by working with an IT storage and logistics provider, allowing us to have security keys on hand to deploy at a moment’s notice in case of emergencies or for employee onboarding.
In addition to deploying and enforcing the use of FIDO2 (WebAuthn) security keys for your IdP, it’s important to validate that the broader control is working as expected on an ongoing basis.
Panther’s detection team has released detection rules that can be used to assess the state of MFA across different applications. For example, this standard detection rule can detect and alert on MFA getting disabled across a number of different systems such as Okta or this detection rule can detect the same for OneLogin.
Continuing with Okta as the example, Panther can also be used to investigate password and MFA reset events using this query:
SELECT
p_event_time,
actor:alternateId as actor_user,
target[0]:alternateId as target_user,
eventType,
client:ipAddress as ip_address
FROM
panther_logs.public.okta_systemlog
WHERE
eventType IN
( 'user.mfa.factor.reset_all',
'user.mfa.factor.deactivate',
'user.mfa.factor.suspend',
'user.account.reset_password',
'user.account.update_password',
'User.mfa.factor.update'
)
AND
p_occurs_since('7 days')
-- If you wish to investigate a single user, uncomment and add their email here
-- and actor:alternateId = '<EMAIL_GOES_HERE>'
ORDER BY
p_event_time DESCCode language: SQL (Structured Query Language) (sql)Panther’s Detection team has also just released a new detection that attempts to look for the domain name patterns the attackers used in recent phishing attacks as covered in this report by Group-IB.
In addition to MFA, Panther can analyze log data from hundreds of systems including AWS, GCP, Microsoft 365, G Workspaces, Crowdstrike, OSquery, and more. Check out a list of all our supported integrations. Contact us for a demo to get started.
