Security Engines - Compromised Account (Anomaly) Detection
The Anomaly Detection engine detects behaviors or actions that seems abnormal when observed in the context of an organization and a user's historical activity. The engine analyzes the behavior using a machine-learning algorithm that builds a profile based upon historical event information including login locations and times, data-transfer behavior, and email message patterns. Anomalies are often a sign that an account is compromised.
When an anomaly is detected, a security event is generated providing the context and other information necessary for investigation. Depending on the Severity Level, the anomaly is categorized as Critical or Suspected.
- Critical anomalies are events indicating a high probability for compromised accounts. These anomalies require investigation and validation from administrators and should be handled immediately.
Note - You can configure the Anomaly Detection engine to automatically block the detected compromised accounts. For more information, see Configuring Anomaly Detection.
- Suspected anomalies are events that might indicate a compromised account and can be reviewed with a lesser sense of urgency.
By default, for critical anomalies, the Anomaly Detection engine only sends email alerts to administrators. To configure the Anomaly Detection engine to not only send email alerts but also automatically block the detected compromised accounts, see Configuring Anomaly Detection.
Some organizations manage security alerts through dedicated mailboxes shared between different security team members or use them for integration with 3rd party solutions.
With Avanan, you can configure a dedicated mailbox for alerts on detected compromised accounts. To configure the mailbox, see Configuring Anomaly Detection.
To focus on high probability account takeover, do one of these:
- On the Events page, filter the events by Type (Anomaly) and Severity Level (Critical).
- On the Overview page, under Security Events, click on Filter by Type and select Critical Anomalies.
- On the Overview page, click on the Anomalies card main indicators.
New delete-all-emails rule
This anomaly inspects new rules configured to delete all the incoming emails. It detects potential malicious configuration to delete all the incoming emails. This behavior may indicate an account takeover.
This anomaly has the highest impact.
Users Sending Malicious Emails
This anomaly is triggered when an internal user sends a phishing or spam email to internal and/or external recipients.
Note - Using exceptions, administrators can disable this anomaly for a specific user or for all users.
Move all emails to a subfolder
This anomaly inspects new rules configured to move all the incoming emails to a subfolder. It detects possible malicious configurations to move all the incoming emails to a specific subfolder. This behavior could indicate an account takeover.
AI-Based Detection of Anomalous Logins
This anomaly uses an AI engine designed to inspect all the parameters of login events to pinpoint those that malicious actors do. The AI engine inspects a variety of parameters, including IP address, browser type, browser version, device, VPN brand, etc.
Login events detected by this AI engine flag the corresponding users as compromised.
Login from Malicious IP Address
This anomaly detects the compromised accounts based on the IP address from which attackers logged into Microsoft 365.
Users logging into Microsoft 365 from IP addresses detected as sources of phishing emails or from the IP address known to Check Point as malicious will be flagged as compromised.
First Time in New Country
This anomaly is triggered when a user log in from a country they have never logged in from.
Note - If the user's title includes the name of a country, logging in from that country will not be flagged.
Reset Password Anomaly
This anomaly detects successful account takeovers. This anomaly is triggered when a user has received three or more password reset emails (each from a different service) in a short amount of time.
It informs the administrator that a user has attempted to recover their password from three different services.
Example: If someone wants to take over Joe's GitHub account, they may first try to take over his Gmail account. Once they succeed in taking over his Gmail, they can use it to reset his password in the GitHub account - and take it over it as well.
This anomaly detects users that start sending emails at an unusual rate.
It is based on a baseline that is built for every user during Learning Mode and over the span of 30 days after onboarding, measuring the amount of emails sent from the user per minute.
Event text - <user> has sent an unusual number of emails - at a rate of <rate> emails per minute.
Auto-forwarding to external email address
This anomaly is based on reading the Office 365 management events. It processes specific events triggered when a mailbox auto-forwarding rule is created.
The anomaly does these tasks:
- Inspects new auto-forwarding rules created in Office 365
- Checks if the target email is 'external' to the organization. If the email is external, then an anomaly
Note - The anomaly's severity is decided based on the forwarding condition. If there is no condition, the
severity is set to high. By default, the severity is set to medium.
Unusual Country Anomaly
This anomaly detects incoming emails from countries associated with phishing attempts and various types of cyber attacks.
By default, these countries are Nigeria and China. The Allow-List allows you to ignore events from either of these two countries.
Suspicious Geo Location (Impossible Travel)
This anomaly detects possible credential theft and use from another location. It detects the frequent login and email events from different locations, and alerts the administrator about what is likely to be another person operating from an account of a company employee.
It is possible to create Allow-List rule of accounts (for example, employees that use VPN or similar tools on a frequent basis).
Suspicious MFA login failure
This anomaly detects login operations that failed during Multi Factor Authentication (MFA)/Second Factor Authentication (2FA). To reduce the rate of false detection, it correlates the failed MFA with additional events or follow-up successful login.
Event text - A suspicious login failure for <email>, attempting to login from <geo location>, failing at the MFA stage.
Note - The detection is not generated in real time as it correlates and analyzes the past events and successful logins. Alert may be generated a few hours after the failed login.
Client is a vulnerable browser
This anomaly checks the client browser's vulnerability. It checks the browser version used by the end user performing the event (when reported by the SaaS), and compares it to the list of old versions (with known vulnerabilities).
Configuring Anomaly Detection
- Navigate to Configuration > Security Engines.
- Under Anomaly Detection, click Configure.
- Under Compromised accounts workflow, select the required workflow when critical anomalies (which indicates that an account is compromised) are detected.
- To send email alerts to the administrator and automatically block the compromised account, select Alert admins, automatically block user.
- To send only email alerts to the administrator, select Alert admins.
- Under Compromised Microsoft administrators, select the required workflow when compromised
global admin accounts are detected.
- To block compromised global admin accounts, select Automatically block admin.
- To avoid blocking compromised global admin accounts, select Do nothing.
- To send email alerts when suspected anomalies (which indicates that an account may be compromised) are detected, under Suspected compromised accounts workflow, select Alert Admins.
- To configure a dedicated mailbox for alerts on compromised accounts:
- Select the Dedicated mailbox for alerts on compromised accounts checkbox.
- Under Dedicated Alert Mailbox, enter the email address.
- To stop creating massive sender anomaly when an email is sent to an unusually large number of recipients using a distribution list, under Massive Sender Anomaly, select the Do not generate event when sending emails to distribution list check-box. For more information about massive sender anomaly, see Massive sender anomaly.
- To generate Impossible Travel Anomaly event even when the user logs in from multiple locations inside the same country, select the Generate event even if the impossible travel is within the same country check-box. For more information about Impossible Travel Anomaly, see Impossible Travel Anomaly.
- Click Save.
Note - To enable login events for Office 365 GCC environment, contact Avanan Support.
At times, to handle falsely flagged events, administrators may need to create exceptions for anomaly detections.
To create Anomaly exceptions:
- Go to Events screen.
- Select the anomaly event for which you want to create an exception.
- Click on the vertical ellipses icon (in the right side of the selected anomaly event), and select Add Exception.
The Create allow-list for anomaly pop-up screen appears.
- Under Allow-List type, select the required exception from the drop-down.
Note - The drop-down shows different options applicable for the anomaly event you selected.
- Under Apply for all past events, select Yes or No.
- Yes - The exception gets applied to all the events in the past and to the future events.
- No - The exception gets applied only to the event you selected and to all the future events.
- If required, enter a Comment for the anomaly exception.
- Click OK.
To see all the anomaly exceptions, go to Configuration > Anomaly Exceptions.