Security operations · 4 MIN READ · JOSHUA KIM, EVAN REICHARD AND ASHWIN RAMESH · JUL 13, 2021 · TAGS: Cloud security / MDR
Credentials phishing attacks are on the rise and bad actors are finding new and creative ways to bypass multi-factor authentication (MFA).
This trend isn’t surprising – a large percentage of people abruptly switched to remote work last year. And attackers didn’t waste time in taking advantage of the upheaval.
We’ve noticed that one multi-factor authentication solution in particular caught the eye of attackers – Okta.
Why Okta?
Orgs that use Okta rely on its authentication and access management feature to grant users access to their apps. This is the holy grail for a threat actor, giving them a one-stop shop to access multiple apps that can be used to stage an attack or exfiltrate data.
We sounded the alarm about this trend in an infographic. But what do these types of attacks look like?
That’s what we’re going to cover here.
In this two-part blog series, we’re going to share an example of an Okta phishing attack that we responded to in our security operations center (SOC). The attacker used a man-in-the-middle (MITM) tactic to send users to a fake Okta login page.
This post will go over how we detected that a user’s credentials were compromised, how you can spot a phony Okta page and we’ll share some tips on how your org can stay resilient against these types of attacks.
We’ll follow up with a deep dive into our investigative process in the second part of this series – so stay tuned!
Phishing for credentials
So, what happened?
Attackers emailed a link to a fake Okta login page from the email service provider, SendGrid.
If a user submitted their credentials using the fake Okta page, they were redirected to a page masquerading as the Duo Security MFA page that was hosted by the attacker.
While the org had configured two-factor authentication (2FA), the attacker’s phishing campaign and social engineering successfully circumvented existing security controls by hijacking the user’s authenticated network sessions.
Spotting a fake Okta page
The fake Okta login page mirrored settings of the users’ workplace, like the org’s logo, and was convincing enough to leave them unaware that they weren’t logging into their normal login page.
But there were some telltale signs that this was a phishing attempt.
Let’s look at the fake login and two-factor authentication pages that were created. Do you notice anything strange?
The fake Okta login and two-factor pages.
Once we started our investigation, here are some things we noticed right off the bat:
- The attacker-owned phishing site was using the non-secure HTTP over HTTPS.
- The attacker-owned site didn’t render the security image or the default avatar picture when entering a username.
- The “Remember Me” option was missing the checkbox.
- The attacker used similar but not exactly the same language on their page.
- The attacker-owned site said “Need sign-in assistance?” while a real Okta page reads “Need help signing in?”
- The bottom left hyperlink should state, “Powered by Okta” not “OktaPowered by.”
- Other things seemed off, and we noted minor details like different font style and sizes between the respective texts.
Detecting Duo malicious logins
During initial triage, we started to dig into how the user’s credentials were compromised.
We noticed that there were two devices (and their IP addresses) in the Duo Authentication Logs associated with a Duo Push Authentication event:
- Access Device – The device from which the user is requesting the Duo Push.
- Authentication Device – The device approving or rejecting the Duo Push.
For a legitimate authentication event, we can assume that the access device and the authentication device are in close proximity to each other, and since we have the IP addresses of both devices, we can build a detection off this assumption.
An example SIEM query-based rule is provided below.
SIEM query-based rule
The first step was to get a geographical location from the IP addresses. We did this by enriching the IP addresses using SumoLogic’s geo://location operator. This gave us the latitude, longitude and the country codes of both IP addresses.
We then used an additional SumoLogic feature called haversine, which allows us to determine the birds-eye distance between two geographical coordinates.
Finally, using the newly derived distance and country of origin for both the access and authentication device, we can generate an alert if the countries differ or if the distance between the two devices exceeds a determined length.
This doesn’t mean that there aren’t false positives.
Some organizations use various VPNs/proxies that could cause a legitimate login to appear illegitimate. For example, if the user happens to be using a VPN on their phone or authentication device, it could fire an alert if the devices aren’t recognized.
At Expel, we’re able to mitigate some of the false positives by hooking this detection into a context database. This allows us to suppress the alert if one of the IP addresses is originating from a known and authorized VPN or network egress point.
4 tips on how you can prevent credentials phishing
While the tried and true methods of phishing attacks, like business email compromise (BEC), persist – phishing tactics are getting more sophisticated.
And we’ll likely see more instances of phishing or credentials phishing similar to this attack in the future.
Beyond implementing best security practices for Okta (enabling MFA, network blocklisting, enforcing complex passwords, enabling email notifications for end users and device trust), updating your security awareness training when a new type of attack is identified can help reduce your phishing triage-related headaches.
There are four things that you can share with your employees to ensure they don’t fall victim to this type of attack:
- Enforce MFA prompts when users connect to sensitive apps via app-level MFA. Don’t make your Okta a one-stop shop for an attacker. Protect your sensitive apps with additional MFA to help add another layer of defense.
- Remind your users to make note of and remember the security image tied to their Okta account on the sign in page. If your users don’t see or recognize their chosen security image, they might be on a fraudulent page.
- Tell your users to always review the source of the 2FA request (if via push notification) to verify if the login is from the expected region/area. If they get an unexpected login request, encourage them to report the event. They can do that either by email or using the reporting features within the 2FA mobile app.
- Customize your Okta sign-in page appearances. Believe it or not, we’re pretty good at pattern recognition. When implemented, if a user lands on a default Okta sign-in page with no customization, it may help trigger their spidey-sense and let them know that something isn’t right.
This incident serves as a reminder that we always need to stay sharp and think twice before clicking a link or hitting that sign-in button.
Find out what Expel looks for when a phishing email is submitted
