Threat actors continue to evolve methods to access valid credentials using new techniques such as multi-factor authentication or MFA spamming that we must detect.
On Sept. 15, the security world was worked into a frenzy across social media as details of Uber’s “cybersecurity incident” were revealed. While Uber worked with the Department of Justice, this social engineering attack was swiftly attributed to Lapsus$, likely due to similar tactics and techniques used against their other victims. These attacks prove that no matter how spectacular and innovative your company’s cybersecurity training may be, anyone and everyone can potentially fall victim to a social engineering attack.
In this article, we are going to detail the expansion and improvement of Falco’s Okta plugin to identify Multi-Factor Authentication (MFA) push request spamming, mitigating situations such as this.
Who is Lapsus$?
They are a cyber-crime group or hacker group. Regardless of what you call them, this crew is good at what they do.
Lapsus$ has presumably only been active since late 2021, when they targeted the Brazilian Ministry of Health. In early 2022, a slew of attacks on large technology companies were attributed to them: Okta, Nvidia, Samsung, Ubisoft, T-Mobile, and Microsoft.
Their preferred attack vectors for initial access and credential access are stolen credentials and social engineering. Once credentials and access are obtained, they shoot for sensitive data. Unlike ransomware gangs who typically post stolen data on dark web websites, Lapsus$ has been seen using a Telegram channel to share information about their attacks and victim information.
Catch MFA spamming attacks with Falco
Falco has a strong reputation as the de facto tool for runtime security in linux, container, and Kubernetes environments. What you may not know is that Falco extended its detection capabilities with a Falco plugin framework.
This allows them to create plugins for different data sources and use the standard Falco engine over all of those additional logs.
After Lapsus$ breached Okta in January, Falco developed resources for detecting malicious activity in Okta logs using Falco rules and an okta-analyzer plugin.
Following this recent event, the Falco team expanded their Okta plugin to detect the credential access technique T1621: Multi-Factor Authentication Request Generation that Lapsus$ leveraged in the Uber attack. This technique, also known as MFA spamming or MFA fatigue, involves an attacker repeatedly logging into a victim account, resulting in several application or text push notifications sent to the victim in the hopes that the victim will eventually confirm the requests.
For an in-depth explanation of Falco’s Okta plugin, the team released a blog which explains how to install and use it.
There are two ways in which MFA spamming can manifest itself in the Okta logs, using Okta Verify. They are MFA failures and MFA denies. The former being more generic and covering events like timeouts, and the latter triggering when a user chooses “no” when asked if it was them. Using this information, the Falco Okta plugin keeps track of how often these events are seen per user and if the number of events crosses a specified threshold, an alert is triggered.
Example alert for too many MFA denies:
13:46:59.678000000: Warning A user has denied too many MFA pushes in last 5min (user='John Doe' reason='User rejected Okta push verify' countLast300=3)
Example alert for too many general failures, including MFA timeouts:
13:59:28.012000000: Warning A user has failed MFA too many times in last 5min (user='John Doe' last_reason='User rejected Okta push verify' countLast300=3)
These are the Falco rules which the plugin uses to generate the above alerts:
rule: Too many failed MFA in last 5min
desc: An user failed MFA too many times in the last 5min
condition: okta.mfa.failure.countlast[300]>=3
output: "A user has failed MFA too many times in last 5min (user='%okta.actor.name' last_reason='%okta.reason' countLast300=%okta.mfa.failure.countlast[300])"
priority: WARNING
source: okta
tags: [okta]
- rule: Too many denied MFA Pushes in last 5min
desc: A user denied too many MFA Pushes in the last 5min
condition: okta.mfa.deny.countlast[300]>=3
output: "A user has denied too many MFA pushes in last 5min (user='%okta.actor.name' reason='%okta.reason' countLast300=%okta.mfa.deny.countlast[300])"
priority: WARNING
source: okta
tags: [okta]
Code language: JavaScript (javascript)Using these rules, your monitoring or response team can gain visibility into these types of attacks occurring and take preventive actions, if necessary. Automated actions could also be taken by using a tool such as Falco Sidekick or another security orchestration, automation, and response (SOAR) tool.
All day and every day mitigations
Merely adding to your mandated social engineering training is not going to keep your company safe. Social engineering is a unique attack vector that no tool can truly prevent. We have a few practical pointers for you to mull over and share with your employees:
- Unexpected MFA challenges should never be accepted. Only confirm the challenges you initiate, it’s common sense.
- Anomalous network and user behavior detections can help. Access to privileged access management (PAM) through VPN or viewing mass numbers of privileged accounts should be flagged as anomalous. Ensure a member of your security team is reviewing these alerts.
- Treat service integrations as business critical. Access credentials should never appear in plain text, even when embedded in one-off scripts for internal use. Protect them.
- Secrets management in software delivery is essential. Avoid the use of static, embedded secrets such as certificates, API keys, or credentials as a part of your secure continuous delivery. Consistently use secrets management mechanisms for data sources and system integrations to protect your “keys to the kingdom.”
Conclusion
This event has proven, yet again, that no one is completely shielded from being the target of a social engineering attack.
Uber’s security program is mature; it clearly includes the use of MFA to protect remote access, PAM to protect privileged credentials, and service integration to support security automation. Therefore, we must continue to take and improve security measures against social engineering attacks for initial access. Once an actor is in, they move quickly. Review your security logs for this kind of activity and protect yourself moving forward.