Detections

What is the Detections page?

The Detections page summarizes areas of potential risk or compromised entities, including suspicious login failures, missing multi-factor authentication, and stale or dormant accounts.

By default, new and in-progress detections display in order of severity and discovery date. You can click any individual detection to display additional information about the identified risk and its importance or severity.

ℹ️

Note

You can export the Detections page as a .csv using the Download button.

How is it useful?

Detections include the source system and entity type by default, allowing at-a-glance views into potentially compromised services, applications, or accounts.

Detection capabilities

Identity Security Insights leverages multiple methods to detect malicious and anomalous activity.

  • Tactics, Techniques, and Procedures (TTP), Indicators of Compromise (IOC), and Indicators of Attack (IOA) represent activity that is strongly associated with attackers. Identity Security Insights updates regularly with the latest in known attack strategies to ensure you are provided a comprehensive picture of identity-related risk. TTP, IOC, and IOA detections include areas of risk, like logins without MFA, dormant account activity, and new Identity Provider enrollment. The detection shows the reason for the concern and an example of how to address the threat.

  • Anomaly-based detections use AI-backed methods to report on unusual and specific account activity. This activity may not represent an attack signature, but instead detect novel and suspicious activity outside of recognized methods of compromise. Anomaly-based detections report on risks such as:

    • Infrastructure changes following suspicious MFA events could indicate a compromised account.
    • Changes to Azure service principals which seem unusual compared to other environments, can indicate a breach.
    • Excessive Secret Safe read events, which may represent suspicious access within PasswordSafe.

The details for these detections describe how to determine if they are malicious.

Additional detections exist around integrated BeyondTrust products, allowing you to receive detections on anomalous activity and malicious IP access within your organization.

Search and filter your grouped detections

Grouped detections include all accounts that share a specific detection.

  1. On the Detections page, click the Grouped tab.

  2. To search for a:

    • detection: Enter a Detection Name and, optionally, select a filter.Filters include is equal to, is not equal to, Contains, Starts with, Ends with, and Does not contain.
    • severity: Select a Severity from the drop-down list.
    • provider: Enter or select a provider name in the Providers list.
    • account: Enter a digit in the Accounts field and, optionally, select a filter.Filters include is equal to, is not equal to, Is greater than, Is greater than or equal to, Is less than, and Is less than or equal to.

Search and filter your ungrouped detections

Ungrouped detections include all detections. On the Detections page, search results display automatically as you add search terms and select options.

Use a Saved filter

Select a Saved filter from the drop-down list.

Create your own filter

  1. Click Add Filter.
    The Filter Detections dialog box displays.
  2. Select And or Or to determine how you want the saved filter to refine the first data set you're entering.
  3. Optionally, click Add Filter to add a new set of filtering criteria, and select your criteria from the drop-down menus.
  4. Optionally, click Add Group to add a group of additional filters to further refine your filtered criteria.
  5. Click Apply Filter.

Use the columns

Not all columns display by default. Use the columns to search for a(n):

  • detection: Enter a Detection Name and, optionally, select a filter.Filters include is equal to, is not equal to, Contains, Starts with, Ends with, and Does not contain.
  • severity: Select a Severity from the drop-down list.
  • provider: Enter or select a provider name in the Providers list.
  • location: Enter the Location name.
  • account: Enter a digit in the Accounts field and, optionally, select a filter.Filters include is equal to, is not equal to, Is greater than, Is greater than or equal to, Is less than, and Is less than or equal to.
  • label: Enter or select a label name in the Labels list.
  • direct privilege: Enter or select a Direct Privilege. Direct privileges are the inherent rights of an account. This column is hidden by default. Use the Column icon to select the column to display.
  • True Privilege: Enter or select a True Privilege. True Privilege is the full scope of access an account could potentially gain. A True Privilege score shows what detections and recommendations put highly privileged accounts at risk.
  • detection date: Use the calendar to select a date and, optionally, select a filter. Filters include is equal to, is after or equal to, Is after, Is before or equal to, and Is before.

Customize your detection display

Select which columns to view in your results list via the Columns icon and reorder your results by column:

  1. Click the column header to activate it.
  2. Click the arrow icon that displays to sort alphabetically or numerically.

Change or add a comment to a status

Authorized users can change the status of a detection, and they can include an optional comment to describe the nature of the update or change. The status change and comment history are viewable on the Detection Details page.

  1. Locate the status you want to update.
  2. Click Update Status.
  3. Optionally, select a new status from the drop-down menu. Options include New, In Progress, Resolved, False Positive, or Ignored.
  4. Optionally, add a comment.
  5. Click Update Status.
    Your status change and comment saves.

Detections list

NameDescriptionConcernAction
Azure AD Connector account behaving strangelyAzure AD Connect synchronizes information from on-prem Active Directory to Azure Active Directory. It uses a special AAD service account to write information on the Azure side. This service account is a common target for attackers, who extract its password from memory using tools like AAD Internals. This account is behaving in an unusual way in your environment, which suggest that it may have been compromised.Attackers may have compromised an Azure AD Connector account.Investigate whether account is compromised.
Azure AD Identity Protection fired an alert for a login from a new countryA user successfully logged in from a country they have never authenticated from before.Someone may have compromised this user's Azure AD account.Investigate the suspicious activity.
Azure AD login from MCAS risky IP addressAzure AD Microsoft Cloud App Security detected a user login from a known risky IP.This threat intel may indicate a user compromise, or the use of an unauthorized VPN, which can also put user accounts at risk.Investigate login.
Azure AD Identity Protection detected a privileged user login from an anonymized IPPrivileged accounts especially should rarely be used via third party VPNs or proxy service. A sign in from one of these service could indicate that the account is compromised, or that legitimate traffic may be being intercepted by an unscrupulous VPN or proxy provider.Attackers often use anonymized IP's to avoid detection/tracking. Many budget consumer VPNs and proxies are not well-secured, and could allow a malicious insider or attacker to intercept this user's traffic.Investigate signin for malicious activity.
Azure AD Identity Protection detected a password spray attackAzure AD Identity Protection detected a possible password spray attack.Password sprays can lead to credential compromise in the worst case. Even if attackers don't compromise credentials, they often end up locking multiple user accounts guessing incorrect passwords.Investigate whether the password spray was successful.
Azure AD Identity Protection detected unlikely travel combined with unfamiliar features for an accountAzure AD Identity Protection triggered an unlikely travel alert for a user, as well as an unfamiliar features alert on the same IP.The combination of unlikely travel and unfamiliar features increases the likelihood that a user account may have successfully been compromised.Investigate whether account is compromised. Survey peripheral activity for activity after the suspicious login.
Attacker obtained a user's password and attempted to login via Azure ADThe login attempt used valid credentials but was blocked by Azure because the attempt was originated from a known malicious IP address.The user's password has likely been compromised and an attacker may have successfully signed in from a different IP. The attacker may also try this same password for other accounts. It could also indicate a legitimate user is sharing an IP address with devices conducting malicious activityImmediately rotate this user's credentials and investigate other suspicious sign in activity for this user around the time of this alert. The attackers may have used a different IP with a more neutral reputation, or attempted to use these credentials against other applications that don't have access to this threat intel.
Sign in with user agent commonly used by AAD attack toolsA user logged in using a user agent string that is preset in multiple offensive Azure Active Directory tools.User's credentials may have been compromised and an attacker may have successfully logged in.Ensure that user rotates their password and investigate peripheral activity for signs of compromise.
Activity found on partially disabled identityYou have an identity in your environment with its primary account disabled, but other accounts enabled, suggesting that it may have been only partially offboarded. Additionally, at least one of these still-enabled accounts shows activity in the last 7 days.An identity has their primary account (in Okta or Azure Active Directory) disabled, but other secondary accounts still enabled, which are active. This may be an indicator of incomplete offboarding. A disgruntled ex-employee may still have access to these accounts, and could use them to attack the organization.Investigate log activity to determine if this activity was malicious.
Account associated with personal email addressAn account in your environment has what appears to be a personal email address associated with it.This may make it difficult to revoke access and represents a risk in the event the email account is compromised.Investigate whether these email addresses should be associated with these accounts.
Account forwarding all or most of its email to an external addressA user's mailbox has been configured to forward all or most of their mail to another address at an external domain.It's possible that attackers are using the forward to steal email, including things like password reset messages. Even if the forward is legitimate, it could lead to a breach if employee's personal account is compromised or they leave the company. It could also lead to corporate intellectual property being stored insecurely and/or retained by employee after moving to a new position.Investigate forward and consider asking employee to disable it.
Unusual number of MFA failures in quick successionAn account tried and failed to authenticate second factor many times in quick succession.Attackers sometimes spam MFA login attempts in hopes that the user will accidentally approve one.Investigate failed logins.
Successful MFA fatigue attempt identifiedUser shows multiple denied MFA pushes followed by a successful MFA authentication in a short time period.User's password may have been compromised and used to successfully authenticate by an attacker.Investigate whether this activity was expected.
Okta user self-reported suspicious activityA user reported to Okta that they saw suspicious activity related to their account.Someone may be attempting to compromise this user's Okta account.Investigate the suspicious activity.
Identified an Okta Password Spray including a successful auth.An attacker appears to have ran a password spray against your Okta domain, targeting 5+ users in a 15 minute window which included a successful login.An attacker may have successfully guessed a user password using a password list, or used a known leaked password and were testing its legitimacy.Investigate whether the successful login was legitimate/expected activity. If this confirmed suspicious we recommend rotating the user's password and terminating all existing Okta sessions.
Okta session hijackingAn attacker may have stolen cookies from a legitimate Okta session and used them to access applications in your environment. A user had an Okta session with activity in one location. New activity appeared within that same session but coming from a significantly different location, using a different web browser and without any associated explicit login events. This pattern is typical of certain types of session hijacking.An attacker may have stolen cookies from a legitimate Okta session and used them to access applications in your environment.Investigate whether session hijacking occurred.
Okta admin login from account without MFAPrivileged accounts should almost always be protected with MFA. An Okta admin recently logged into the admin dashboard from an account that doesn't have MFA configured.Privileged accounts without MFA often exist because of oversights, and often their overall hygiene is poor. As a result, they're good targets for attackers. It's possible this access is the result of a breach.Investigate whether account is compromised .Consider securing account with MFA.
Attacker may have brute forced the password for an Okta userMultiple failed login attempts due to invalid credentials followed by a successful authentication(s) within 10 minutes.Attackers may have breached an Okta account.Investigate whether the authentications ended with a successful authentication.
Dangerously outdated browser usedA user logged in using a browser likely to contain critical, actively-exploited security flaws.User's identity may be compromised through this browser.Ensure that users use fully patched web browsers to access company resources.
User may have been successfully phished via Device Code authenticationAn account in your environment successfully logged in via Device Code authentication from an IP they have never successfully authenticated from before. This suggests the user's account may have been compromised via device code phishingUser may have fallen victim to a device code phish which would grant attackers legitimate authentication token with a long expiry.Investigate whether this activity is expected/successful.
Recent activity in dormant accountA account that had previously been unused for at least 60 days recently became active again.Unused, abandoned accounts are frequent targets for attackers. A previously-unused account becoming active can sometimes be a sign of a breach.Verify that the activity in this account is benign.
A privileged account was recently re-enabledYou have a privileged account that someone recently re-enabled.Attackers may enabled deactivated privileged accounts to establish persistence.Investigate whether account was re-enabled legitimately.
Suspicious changes to a service principalAttackers sometimes alter service principals in victim Azure environments so that they can use them as backdoors. We've detected changes to a service principal which seem unusual compared to similar principals in other environments.Attackers may have breached your Azure account and altered a service principal to use as a backdoor.Investigate whether service principal changes were malicious.
Login via TorA user accessed a company resource with their network traffic routed through the tor network.Threat actors often use tor to cover their tracks. Login may not be legitimate.Investigate login.
A user has successfully authenticated from a country they have never signed in from beforeA account has logged in from a country this user has never logged in from previously.User account may be compromised, and an attacker may have successfully logged in.Verify that the activity in this account is expected.
Successful Powershell authentication from an unmanaged deviceAn account successfully authenticated via Powershell from a device that is not managed in Azure AD. Powershell authentications are typically associated with administrator activity and are not common for standard users, especially on unmanaged devices. Even if the activity is legitimate, many companies prohibit performing administrative tasks from unsecured, personal devices, because of the possibility of credential theft.Successful logins from devices not registered in Azure AD could indicate compromise or malpractice by legitimate users. Unregistered devices will not meet the corporation security standard and are not monitored.Investigate log activity to determine if this activity was malicious.
Okta admin privileges were assigned to an entire groupAbusing Okta privileges is a common attack method used for privilege escalation. Adding admin privileges to an entire group is extremely rare and should always be investigated.Assigning admin privileges to a group, instead of directly assigning a user admin privileges, is a common behavior to avoid detection.Verify the activity was sanctioned and that the group is not being overprivileged if not necessary.
Okta admin privileges were granted to a userA user's privileges were heightened, either by being added to an Admin Okta Group, or by having admin privileges directly assigned to their account. This activity should always be verified.This activity is fairly rare and should always be investigated. Although not necessarily malicious, this activity could be generated by a valid assignment from a system administrator, an accidental overprivileged assignment, or a user who made the assignment without proper authorization. However, this is a common method of privilege escalation used by attackers.Verify the activity was sanctioned, that the user is expected to have this level of permissions, and is not being overprivileged if not necessary.

©2003-2025 BeyondTrust Corporation. All Rights Reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.