Oort Knowledge Base
Search…
⌃K

Oort Insights

Oort provides more than 40 checks. This page provides a brief summary of each check. For further detail, please view the relevant sub-pages.
A Bypass Code Was Used To Successfully Sign In
A user has used a bypass code to sign in instead of MFA. Bypass codes are issued when a user lost their phone or asks for temp access.
Recommended Actions
Users should not be assigned bypass codes or run in bypass mode. If they do, please make sure to link a ticket opened in security.
Accounts With Unusually High Activity
Accounts with unusually high activity in a given day.
Recommended Actions
Tag known service accounts and machine identities as “MACHINE” in Oort. Investigate the spike to determine what application is generating the activity.
Active Account under Heavy Attack
Adversaries might successfully log in with an IP that was used to probe other accounts in the organization.
Recommended Actions
Contact the end-user to verify the origin of the actions.
Admin Impersonation in Okta
Okta allows impersonation, mainly for support.
If an attacker takes over an admin account they can impersonate other legitimate users.
Recommended Actions
Please contact your Okta administrator to ensure the actor is authorized to impersonate a user session.
We recommend Okta admins share a teams/slack channel and attest, preferably with a ticket that the work was sanctioned.
If the user impersonation session is not legitimate, make sure the target user is returned to a good state and create an incident.
Admin Role Assigned to User in Okta
A user was assigned an admin role.
Recommended Actions
Please make sure this assignment was done through the right process and confirm in a Slack/Teams message.
If the target should not be an admin or should not be assigned that role please start an investigation and add the ticket number here.
Allow/Block Browsers
Common browsers like Chrome, IE/Edge, Safari, and Firefox comprise over 80% of browser activity. Rare browser activity can be a security issue due to the latency of applying patches to those browsers. It also may indicate that this is not the user who usually uses the account. This check has a customizable allow or block list.
Recommended Actions
Please review the activity of users tracked with a rare browser. Evaluate the user alongside other security anomalies like new locations or login failures. You can exclude this user from the check or add the browser to your allowed list.
Allow/Block Email Logins
You can toggle between using a blocklist or an allowlist. You can allow only users with email domains in your allowed list (recommended), or you can allow from a list of popular personal email providers. We do not recommend the latter in a work setting.
Recommended Actions
Depending on your security posture, consider deleting users using emails with those domains, and exploring why you have them in the system. You may also update your allow or block list.
Application Login Bypasses SSO
User logged into application directly. Preventing logins with a username and password, ensures that users can’t bypass your SSO system.
Recommended Actions
Users should not be logging into application directly, unless this is an admin initiative to respond to an SSO outage or other problem. If they do, please make sure to link a ticket opened in security.
Applications with Expired Secrets
Obtains applications with expired secrets in Azure AD.
Recommended Actions
Remove expired secrets from the corresponding Azure AD applications.
Azure Admin Activity Anomaly
Adversaries may create/modify an account to maintain access to victim systems or modify the configuration settings to evade defenses and/or escalate privileges.
To identify such actions, Oort alerts on new (over the last 90 days) administrative actions performed by the account or on actions performed on multiple targets simultaneously (more than 10 targets in 10 minutes - configurable).
Recommended Actions
Verify with the account the reason for the changes.
Note - most of the alerts will represent accounts/application lifecycle (join/leave/move) so it's important to check the context of the action.
HRIS Discrepancies
Oort detects users with the manager not in sync between your HRIS and IDP.
Recommended Actions
We recommend correcting any inconsistencies.
Inactive Account Probing
Users with a sudden spike in failed login attempts after a long period of inactivity.
Recommended Actions
Investigate the source of failed login attempts and update geo-blocking rules. Check if the username was in any known data breaches. Follow recommended remediation for Inactive Users. Trigger an access review with the user’s manager to verify that the dormant account still needs access. If the account is unneeded, suspend it. Otherwise, continue monitoring it for activity and suspend it after a grace period of configurable number of days.
Inactive Guest Users
An Azure Active Directory (Azure AD) business-to-business (B2B) collaboration user's UserType = Guest. Most systems allow you to easily invite these users into the Directory. This check tracks if these guests have logged in during the last configurable number of days. Most compliance frameworks require you to assess and purge these users promptly.
Recommended Actions
First, assess the users' security posture. We can also determine if users have conditional access and MFA enabled. We recommend deleting these users on a schedule, as they are easy to re-invite.
Inactive Users
Inactive users are users who have not shown any activity in the past configurable number of days yet also have accounts with enabled status in one or more systems.
Why is it a problem?
Dormant accounts carry unnecessary financial and information security risks for your organization. These users might consume application licenses without using them. By leaving standing entitlements in place that are not needed or not used on a regular basis, attackers may be able to use a dormant account to gain access to sensitive systems and data. By reducing the number of accounts and adopting a least privilege model, organizations can ultimately reduce the attack surface of the entire organization.
How is it measured?
Users who are enabled (Active status) and who have not successfully authenticated during more than configurable number of days.
Recommended Actions
Trigger an access review with the user’s manager to verify that the dormant account still needs access. If not needed, suspend the account immediately. Otherwise, continue monitoring the account for activity and suspend it after a grace period of configurable number of days.
IP Threat Detected
IP address reputation is like a credit score. Each address has a score based on associations with bad behaviors. It likely poses a risk if it ever hosted malware, phishing sites, or spam. The riskier the address, the worse its reputation. Like a credit score, its reputation takes a while to clear.
Oort uses an up-to-date risk service to notify customers when a user logs in from a marked address.
Recommended Actions
We recommend contacting the end user to purge the machine originating the traffic. In order to reduce false positives, only successful logins are tagged.
Login to Admin Console in Okta
These are the users that have logged into the admin console in the last week.
As is, it is mainly a report to see if you can notice someone you don't know or who should have not done this. It is a method to track who is logging in and tracking changes.
Recommended Actions
Please track if you see someone you do not know or who might be odd.
Consider reviewing the list on a weekly basis or connecting to the digest email.
MFA Flood
After the attackers gained access to account credentials they may abuse the automatic generation of push notifications to MFA services (such as Duo Push, Microsoft Authenticator, and Okta) to have the user grant access to their account.
To detect such an attack, Oort calculates the number of failed authentications on an account over 1 min timeframe and alerts if the number is higher than 5 (configurable).
Recommended Actions
Check with the account if the failed login attempts were initiated by the account.
Check for suspicious access to applications right after the MFA flood attack.
Check if the username was in any known data breaches and update the account password if needed.
New Country for Tenant
Attackers may obtain and abuse account credentials to gain initial access, persistence, privilege escalation, or defense evasion.
Monitoring accesses from locations with no operation can identify such credentials misuse. To identify compromised accounts, Oort alerts on successful logins from a new (over the last 90 days) country for the tenant.
To reduce false positive alerts, accounts that were created less than 3 days prior to the check run are excluded. In addition, access from a managed device will be excluded for customers with Azure AD with InTune.
The check will be triggered on anomalous activities in the last 24 hours (configurable).
Recommended Actions
We recommend contacting the end user to verify the origin of the actions.
Never Logged In
Accounts that were created but never successfully logged in.
Recommended Actions
Trigger an access review with the user’s manager to verify that the unused account is still necessary. If not needed, suspend the account immediately. Otherwise, reset the account and direct the manager to onboard the user correctly.
No MFA Configured
Multi-Factor Authentication (MFA) requires users to provide something they know, like a password or PIN, or something they have, like an out-of-band device or a one-time password provider. All users should be using MFA to gain access to the system.
Recommended Actions
Some system accounts may not have MFA. We recommend categorizing those for easy detection. Consider using solutions like expired passwords to block access to these accounts.
For newly created user accounts, Oort provides a default of 14 days before alerting that this account has no MFA configured. This value can be modified in the Check Settings.
Okta Admin Activity Anomaly
Adversaries may create/modify an account to maintain access to victim systems or modify the configuration settings to evade defenses and/or escalate privileges.
To identify such actions, Oort alerts on new (over the last 90 days) administrative actions performed by the account or on actions performed on multiple targets simultaneously (more than 10 targets in 10 minutes - configurable).
Recommended Actions
Verify with the account the reason for the changes.
Note - most of the alerts will represent accounts/application lifecycle (join/leave/move) so it's important to check the context of the action.
Okta Long Running Sessions
Extremely long sessions without re-authentication pose a security threat and can increase the chance of session hijacking.
Recommended Actions
Clear the end user sessions to require re-authentication.
We recommend setting "Maximum Okta session lifetime" to 16 hours (one working day) and "Expire session after the user has been idle on Okta for" to 2 hours.
Okta Session Length Policy Compliance
Okta authentication policies should have a maximum session length configured to prevent extremely long sessions without re-authentication. Similarly, the session idle time should be set to an appropriate value for your organizational policies.
Enforcing session timeouts for idle and maximum session lifetime is an important security control for mitigating attacks such as session hijacking. By default, Okta recommends that the session idle timeout is set to 2 hours (120 min) and the Maximum Okta session lifetime is enabled and set to no more than 30 days.
This insight will fail if any of your active Okta authentication policies do not have a maximum session lifetime value OR if the session idle expiration value is higher than the Oort value (configurable, 120 min by default).
Recommended Actions
Validate your Okta authentication policy settings.
We recommend setting "Maximum Okta session lifetime" to 16 hours (one working day) and "Expire session after the user has been idle on Okta for" to 2 hours.
Configure this insight session idle value to match your Okta session policies.
Oort Client Secret Expiring Soon
The Client Secret key for the Oort Application in Azure AD will expire in 90 days or less. If the key expires, Oort will not be able to collect data.
Recommended Actions
Please issue a new Client Secret and update the Integration in Oort with the new key.
Rate Limit Alert
Okta has several rate-limiting functions for API. In this check, we alert system.org.rate_limit.violation and core.concurrency.org.limit.violation and we share which users contributed to the rate violation.
Recommended Actions
Okta has several rate-limiting functions for API. In this check, we alert system.org.rate_limit.violation and core.concurrency.org.limit.violation, and we share which users contributed to the rate violation. In most cases, these are service accounts from services that require tuning, such as Oort, Datadog, or Workday. Please check your organizational rate limits based on Okta API rate limit categories.
Consider the following actions: (1) Contact support of Okta to increase the rate limit if the operation is required, (2) Contact support of the product to see if events can be tuned (3) Consider moving to EventBridge to collect events.
Risky Parallel Sessions
Running parallel sessions is not high risk on its own, but is not common outside of IT.
This check flags users that have different session IDs in a one-minute timeframe, from at least two unique user agents and two unique IPs where and not all IPs are common for the integration
Recommended Actions
Please verify the users with sessions running in parallel are from IT/InfoSec teams.
Role Assigned to Azure Cloud Only Account
A role was assigned to a Cloud Only account.
Recommended Actions
We recommend verifying why the role has been assigned to the account.
Service Account Successful Sign In
These are the service accounts that have successfully signed in during the last week.
Service Accounts are usually used for backend-to-backend communication and are not supposed to have sign-ins.
Recommended Actions
Please track if this sign-in is legitimate.
Consider reviewing the list on a weekly basis or connecting to the digest email.
Slack User Inconsistencies
This check detects if your Slack account has users defined that are not defined in the IDP.
Recommended Actions
Consider migrating users to guests with an expiry or to a slack connection.
Successful Access from a Previously Only Failing IP
Start taking notes…
Super Admin Login to Google
A Super Admin has logged in to Google.
Recommended Actions
Please make sure that this access is legitimate, consider having a notification channel and confirming by users who made the access.
Successful Access from a Previously Only Failing IP
Adversaries might successfully login with an IP address that was used to probe other accounts in the organization.
Recommended Actions
Contact the end-user to verify the origin of the actions.
Suspicious Activity Reported by End User
This check detects users that reported suspicious or unrecognized activity to the org admin from an email notification.
This check requires the "Suspicious Activity Reporting" feature to be configured in Okta.
Recommended Actions
Oort recommends you notify the user and admin channel, Oort allows the user to say the user made a mistake to reduce false positives. Please review the highlighted activity in the log to see the highlighted session.
Telecom MFA Limit Reached
Users who hit a limit on verification phone calls or text codes during sign-in.
Recommended Actions
If the problem repeats periodically, encourage users to move to an app or an external authenticator. If that is not possible due to local or business regulations, consider using an external provider like Duo.
Unmanaged Devices Access
This check detects if a user is accessing from an unmanaged device in the last 7 days (configurable). Oort will give an indication of the event and IP if the device was managed or not to allow you to inspect it closer.
Recommended Actions
We recommend alerting the users to use their managed devices directly or managers if the behavior persists.
Unused application for a user
This is the list of applications not used by a specific user. More likely than not, all users will have unused applications.
Recommended Actions
Alert users about their unused applications or their managers before taking away access.
Upcoming App Key Expiration
Oort detected applications that are in use, but their keys are about to expire within 90 days.
Recommended Actions
We recommend either renewing the keys or exploring migrating off these applications and notifying the users.
User Has Directly Assigned Application
This user has applications directly assigned to them and not through a group.
Recommended Actions
Please make sure the user is assigned the app through a group.
User in IDP but not in HRIS
Oort detects users defined in your IDP that your HR Information System (HRIS) cannot find.
Recommended Actions
We recommend removing these users. If the account is currently showing activity, we recommend contacting the manager.
User Password Expiration Failure
Among others, long-lasting active SSO sessions can cause accounts not to reset their passwords. These accounts didn't reset their passwords for a configurable period of time. We suggest enforcing a password reset.
Recommended Actions
We recommend enforcing password changes for users that fail the check.
User Stuck in Non-functional State
Users who have been in a non-functional state for more than configurable number of days. Functional statuses: Active, Deprovisioned, Suspended.
Recommended Actions
We recommend removing these users.
User Type Missing
Your IDP allows you to categorize users by type. We highly recommend using this feature. Guests and API users are most likely to be missing a user type.
Recommended Actions
Log into your IDP's admin console and update the users with missing types. Ensure that your user-creation process includes type assignments.
Users With New Email Forward Rules
Email forwarding is mostly harmless and comes from the need to deal with life changes and organizational shifts.
It is also a known bad pattern for people knowing they are about to change jobs and is a cause of data loss.
Recommended Actions
Please check if the forward rule is legitimate, for example, contractors and managers or a potential data loss issue.
Weak MFA Configured
Multi-Factor Authentication (MFA) requires users to provide something they know, like a password or PIN, or something they have, like an out-of-band device or a one-time password provider.
The National Institute of Standards and Technology (NIST) recommends using one-time password solutions or cryptographical solutions such as Google Authenticator, Okta Verify, or Microsoft Authenticator as the second factor of authentication.
Recommended Actions
Encourage users to use stronger authentication on a more regular basis. If that is not possible, we recommend tagging users with administrative privileges in critical services like Okta and Workday, and providing them with physical authentication solutions like Yubikey.
Weak MFA Was Used To Successfully Sign In
Multi-Factor Authentication (MFA) requires users to provide something they know, like a password or PIN, or something they have, like an out-of-band device or a one-time password provider
The National Institute of Standards and Technology (NIST) recommends using one-time password solutions or cryptographical solutions such as Google Authenticator, Okta Verify, or Microsoft Authenticator as the second factor of authentication, as SMS and voice calls are susceptible to attacks.
Recommended Actions
Encourage users to use stronger authentication on a more regular basis. If that is not possible, we recommend tagging users with administrative privileges in critical services like Okta and Workday and providing them with physical authentication solutions like Yubikey.