OKTA Brute Force Attack Detection with Microsoft Sentinel
The following post focuses on Okta brute force detection with Microsoft Sentinel and many tips for the investigation and day-2-day.
A hacker attempts to guess your usernames and passwords during a brute force attack. Hackers use tools to speed up the guessing game. But even with sophisticated tools, it can take some hackers hours, days, weeks, or even months to hit the right combination.
A hacker can explore your system with the correct username/password, just like a verified user. If the intruder is lucky and guesses the combination for someone with plenty of security clearance, the results can be devastating.
There are a few terms for credential attacks, such as password attacks, identity attacks, dictionary attacks, etc. Identity attacks come in different styles with different nuances. The most prevalent attacks are the Password Spray and Brute-force attacks.
What are the differences between a brute-force attack password spraying and credential stuffing? This post will explain some of the highlights and differences between various authentication attack types and manage those attacks with Microsoft Sentinel.
Type of Attacks
A hacker with skill, time, and a bit of luck can bombard your server with thousands of attempted logins. One of those combinations could be successful, and if it is, the hacker gets inside.
No username/password combination is completely hackproof. Given enough time, attackers can crack any combination. Some hackers do their work manually. They may start with the items they know, such as:
- Username structure.
- Password rules.
- Existing passwords.
Other hackers lean on tools that run login attempts automatically. Experts say there are at least nine of these tools, and while they should be deemed illegal and impossible to find, most can be downloaded online and put to use right away.
A hacker with automated toolsets up a scan walks away and hopes the program strikes gold eventually.
Brute-Force is defined as “relying on or achieved through the application of force, effort, or power in usually large amounts instead of more efficient, carefully planned, or precisely directed methods.”
In this sense, brute-force authentication attacks can be considered an aggression that employs overwhelming force to determine valid credentials.
Typically, #bruteforce attacks will target a single account identifier (username, email address, etc.) with extensive lists of possible passwords, attempting each in succession until the correct password is determined, the account is locked out, the attack is mitigated, or the threat actor abandons her efforts.
First, you need to create a wordlist through manual or automated means. This base wordlist is managed with Hashcat.
The process of managed by creating variations of the words on the wordlist that include commonly used “complexity,” such as capitalizing the first letter, adding “!” to the end, or the current year “2020”.
There are lots of tools to perform identity attacks, including:
In short, a Brute-force attack is using multiple passwords to attack one user’s account. Security systems quickly detect this attack, and the account is locked out in many scenarios. For example, mitigation can with Azure AD Smart Lockout to protect the user against this type of attack.
TIP: in many scenarios, brute-force attacks can come from different IP addresses, and countries are used to hide detection.
Whether a hacker leans on tools or attempts a manual attack, that person must pick an approach to guide the work.
Common types of brute force #attacks include:
Password Spray is a variation of an authentication attack. This authentication attack employs usernames and then matches these with common and few passwords.
Password spray attack is generally less focused than brute-force attacks. The focus of a brute-force attack is usually an account or a handful of known accounts, which are subjected to large lists of possible passwords.
Password spraying flips this around a bit common. Default and passwords are used against an extensive list of possible accounts. So, where the many-to-one ratio in brute-force attacks is many passwords to one username, it’s many usernames to one password in password spraying.
Real-world password spraying attacks will incorporate lists of common, default, or known passwords. That is a conceptually different way of performing authentication attacks as the “known variable” is the password, not the account name. Where in a brute-force attack, the known variable is the username.
In short, a #password #spray attack is using one password to attack multiple users. Security systems do not easily detect this attack method. For example, Microsoft Cloud App Security and Azure AD Identity Protection can identify this attack.
Credential stuffing use hijacked account credentials and typically consists of lists of usernames or email addresses. Corresponding passwords are used to gain unauthorized access to user accounts through large-scale automated login requests directed against a web or application.
Password reuse is still common and can compromise account credentials continually bought and sold online by threat actors.
Usually, these compromised accounts will leverage to authenticate to additional services, applications, or systems.
Compromised credentials, known as “dumps,” are publicly available, and threat actors frequently use these dumps to attempt to compromise additional accounts belonging to the affected user.
Comparison table with differences between password spray, brute-force, and credential stuffing.
Now that you are familiar with the identity attacks, you can move on to the next steps and know the information that Azure AD, Azure Identity Protection, Microsoft Cloud App Security, and Azure Sentinel can detect and respond to identity attacks.
Microsoft Sentinel Detection Rule
There are many ways to develop detection rules for Okta brute force and other Okta identity attacks. The common mechanism for all types of attacks and detection rules is to take the values from user and system logs. Below are the main and common #okta values for creating the correct detection rules:
- authenticationContext –
Under each value, some sub-values can be part of the detection rules.
The following query is suitable for brute force potential attack detection
// OKTA – Potential Identity Attacks
// Attempts to Brute Force or Password an Okta User Account
let Threat = dynamic([“Password Spray”,”Brute Force”,”OKTA Brute Force”]);
let Severity = dynamic([“WARN”,”ERROR”]);
| where TimeGenerated >= ago(1d)
| where debugContext_debugData_threatDetections_s has_any (Threat)
and severity_s has_any (Severity)
and debugContext_debugData_threatSuspected_s == “true”
| project TimeGenerated,actor_id_s, actor_type_s, client_ipAddress_s, eventType_s, severity_s, outcome_reason_s, outcome_result_s,debugContext_debugData_threatSuspected_s, debugContext_debugData_threatDetections_s, displayMessage_s, transaction_type_s, client_geographicalContext_state_s
| summarize IPs = dcount(client_ipAddress_s), Location = make_set(client_geographicalContext_state_s) by actor_id_s
- debugContext take the threat detection value
- debugContext take the threat suspected value
- severity_s take the information level for this attack
- summarize put the difference between spray and brute force.
Spray or Brute-force
In a cloud environment, there are many conflicts of which type of attack is. Because Identity Providers work differently, we need to identify when each attack, spray, or Brute-Force.
When using the client_ipAddress_swith location and set by actor_id_s. In this situation, we can know how brute force occurs.
summarize IPs = dcount(client_ipAddress_s), Location = make_set(client_geographicalContext_state_s) by actor_id_s
TIP: in this scenario, we receive many IP’s, actors, and locations – The reason is the way password spray behaves and how it provides the results in Okta and then in #MicrosoftSentinel.
When it comes to spray, we need to change the aggregation order. This time we need to count by severity_s, and client_ipAddress_s, and the client_geographicalContext_state_s
summarize SeverityCount = count() by severity_s, client_ipAddress_s, client_geographicalContext_state_s
TIP: TIP: With the value where USERs != “” any value with more than 1 user is visible. To filter, you can also confiscate this value on, for example, where USERs != “” to only get results visible with 5+ users.
Scenario – Brute Force Attempts to an Okta User
Identifies when an Okta user account is locked out 3 times within a 3-hour window. An adversary may attempt a brute force or password spraying attack to obtain unauthorized access to user accounts. The default Okta authentication policy ensures that a user account is locked out after 10 failed authentication attempts.
Okta event log
Threat Mapping by Framework: MITRE ATT&CK
For all Okta detection rules > https://github.com/eshlomo1/Microsoft-Sentinel-4-SecOps/tree/master/OKTA/Detection