Identity Security Insights Remediations Summary

Overview

Identity Security Insights provides a series of research-backed detections and recommendations based on areas of risk found in your connected applications and services. The following table is a list of potential concerns, along with their methods of remediation.

For more information, please see the following pages:

• Identity Security Insights Recommendations Dashboard.
• Identity Security Insights Detections Dashboard.

Detections

Summary	Concern	Detail	Remediation
Azure AD Connector account behaving strangely	Attackers may have compromised an Azure AD Connector account.	Azure 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.	Investigate whether account is compromised.
Azur eAD Identity Protection fired an alert for a login from a new country	Someone may have compromised this user's Azure AD account.	A user successfully logged in from a country they have never authenticated from before.	Investigate the suspicious activity.
Azure AD login from MCAS risky IP address	This threat intel may indicate a user compromise, or the use of an unauthorized VPN, which can also put user accounts at risk.	Azure AD Microsoft Cloud App Security detected a user login from a known risky IP.	Investigate login.
Azure AD Identity Protection detected a privileged user login from an anonymized IP	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.	Privileged 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.	Investigate signin for malicious activity.
Azure AD Identity Protection detected a 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.	Azure AD Identity Protection detected a possible password spray attack.	Investigate whether the password spray was successful.
Azure AD Identity Protection detected unlikely travel combined with unfamiliar features for an account	The combination of unlikely travel and unfamiliar features increases the likelihood that a user account may have successfully been compromised.	Azure AD Identity Protection triggered an unlikely travel alert for a user, as well as an unfamiliar features alert on the same IP.	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 AD	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 activity	The login attempt used valid credentials but was blocked by Azure because the attempt was originated from a known malicious IP address.	Immediately 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 tools	User's credentials may have been compromised and an attacker may have successfully logged in.	A user logged in using a user agent string that is preset in multiple offensive Azure Active Directory tools.	Ensure that user rotates their password and investigate peripheral activity for signs of compromise.
Activity found on partially disabled identity	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.	You 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.	Investigate log activity to determine if this activity was malicious.
Account associated with personal email address	This may make it difficult to revoke access and represents a risk in the event the email account is compromised.	An account in your environment has what appears to be a personal email address associated with it.	Investigate whether these email addresses should be associated with these accounts.
Account forwarding all or most of its email to an external address	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.	A user's mailbox has been configured to forward all or most of their mail to another address at an external domain.	Investigate forward and consider asking employee to disable it.
Unusual number of MFA failures in quick succession	Attackers sometimes spam MFA login attempts in hopes that the user will accidentally approve one.	An account tried and failed to authenticate second factor many times in quick succession.	Investigate failed logins.
Successful MFA fatigue attempt identified	User's password may have been compromised and used to successfully authenticate by an attacker.	User shows multiple denied MFA pushes followed by a successful MFA authentication in a short time period.	Investigate whether this activity was expected.
Okta user self-reported suspicious activity	Someone may be attempting to compromise this user's Okta account.	A user reported to Okta that they saw suspicious activity related to their account.	Investigate the suspicious activity.
Identified an Okta Password Spray including a successful auth.	An attacker may have successfully guessed a user password using a password list, or used a known leaked password and were testing its legitimacy.	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.	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 hijacking	An attacker may have stolen cookies from a legitimate Okta session and used them to access applications in your environment.	An 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.	Investigate whether session hijacking occurred.
Okta admin login from account without MFA	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.	Privileged 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.	Investigate whether account is compromised .Consider securing account with MFA.
Attacker may have brute forced the password for an Okta user	Attackers may have breached an Okta account.	Multiple failed login attempts due to invalid credentials followed by a successful authentication(s) within 10 minutes.	Investigate whether the authentications ended with a successful authentication.
Dangerously outdated browser used	User's identity may be compromised through this browser.	A user logged in using a browser likely to contain critical, actively-exploited security flaws.	Ensure that users use fully patched web browsers to access company resources.
User may have been successfully phished via Device Code authentication	User may have fallen victim to a device code phish which would grant attackers legitimate authentication token with a long expiry.	An 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 phishing	Investigate whether this activity is expected/successful.
Recent activity in dormant account	Unused, abandoned accounts are frequent targets for attackers. A previously-unused account becoming active can sometimes be a sign of a breach.	A account that had previously been unused for at least 60 days recently became active again.	Verify that the activity in this account is benign.
A privileged account was recently re-enabled	Attackers may enabled deactivated privileged accounts to establish persistence.	You have a privileged account that someone recently re-enabled.	Investigate whether account was re-enabled legitimately.
Suspicious changes to a service principal	Attackers may have breached your Azure account and altered a service principal to use as a backdoor.	Attackers 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.	Investigate whether service principal changes were malicious.
Login via Tor	Threat actors often use tor to cover their tracks. Login may not be legitimate.	A user accessed a company resource with their network traffic routed through the tor network.	Investigate login.
A user has successfully authenticated from a country they have never signed in from before	User account may be compromised, and an attacker may have successfully logged in.	A account has logged in from a country this user has never logged in from previously.	Verify that the activity in this account is expected.
Successful Powershell authentication from an unmanaged device	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.	An 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.	Investigate log activity to determine if this activity was malicious.

Recommendations

Summary	Concern	Detail	Remediation
Overprivileged Azure AD Connector account	The Azure AD Connector account does not need the Global Administrator role anymore. It unnecessarily increases the impact of this account being compromised, which is especially important because attackers like to use tools like AAD Internals to steal the Azure AD Connector password from memory on on-prem servers.	Azure 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. In some older configurations, this account was granted Global Administrator, but this is no longer necessary for Azure AD Connect to work correctly.	Remove Global Administrator from Azure AD Connector account.
Azure AD Connector account not protected by Conditional Access Policies	An attacker steals the Azure AD Connector account's credentials and is able to use them to authenticate from their own infrastructure because no Conditional Access Policies are in place.	Azure 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. Because it typically has a very predictable access pattern (a single on-prem server authenticating over and over again), it's wise to add conditional access policies to make it harder for attackers to use the account if they manage to steal its credentials.	Use Conditional Access Policies to restrict authentication to Azure AD Connector account.
Identity with dormant accounts	These unused accounts may be unnecessary attack surface or grant the identity unnecessary privilege.	An identity has account(s) that have not been used recently.	Verify that dormant accounts are necessary. If they are not, disable them.
Already-privileged user can escalate or regain privilege via ownership of a group	Already-privileged user may be able to escalate their privilege further, or regain privilege after it is revoked.	Privileged user owns a group that grants significant privilege, and as a result can add themselves or any other user to this group, even if their existing privilege is revoked.	Consider whether the privileged user should be owner of this group.
MFA Not Enabled	All interactive accounts should be protected by MFA to reduce the chance of compromise if credentials are stolen.	MFA not required to login to these accounts	Enable MFA for all interactive accounts.
Privileged account with stale password	NIST and others no longer recommend password rotation for regular users because it causes them to choose less secure, easier to remember passwords. This is not true of privileged accounts and service accounts, which should have automatically-generated passwords. For these accounts, annual password rotations help reduce the impact of credential theft of accidental credential exposure.	A privileged account has not had its password reset within the last year.	Rotate the passwords for these accounts.
Privileged Azure AD account not managed by Password Safe	Privileged accounts not managed by Password Safe are more likely to be compromised.	An Azure AD account with significant privileges is not managed by Password Safe.	Managed these accounts with Password Safe.
krbtgt password has not been rotated recently	The krbtgt password has not been rotated in greater than 180 days in your environment, making it more likely that an attacker might have at some point compromised the hash, giving them the ability to act as any user in the domain using 'Golden Tickets' (i.e. forged TGTs).	krbtgt is a special domain account. The hash of its password encrypts ticket granting tickets (TGTs) issued by the domain controller when Kerberos authentication is used. As a result, if its password hash is compromised, an attacker can forge TGTs for any account in the domain. Since krbtgt is not used interactively, and because of impact of it being compromised, we recommend changing the password at least every 180 days.	Change the krbtgt password.
Partially-revoked identity	An identity has their primary account (in Okta or Azure Active Directory) disabled, but other secondary accounts still enabled. 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.	Identity with one major account disabled but other accounts enabled, which may indicate incomplete offboarding.	Verify that identity does not have improperly-enabled accounts.
Unprivileged user can escalate their privilege via ownership of a group	If this account is compromised, attackers could escalate their privilege using this vulnerability.	Unprivileged user owners a group that grants significant privilege, and as a result can add themselves or any other user to this group.	Change owner of this group.