Prevent account takeover

Account takeover is an attack where bad actors gain unauthorized access to the victim’s online accounts, such as their email or bank account. Attackers can steal data from the account and execute other kinds of attacks, despite additional identity factors (2FA/MFA).

This describes how you can protect your user accounts against these attacks using Mosaic detection and response services.

How it happens

Common attack vectors for account takeover include:

• credential stuffing using stolen credentials (e.g., from a data breach)
• bots or automation tools used to execute brute-force attacks or credential stuffing
• device takeover using remote access (e.g., RDC or malware)
• social engineering to obtain personal info or trick users into providing remote access
• session/cookie hijacking to perform unauthorized actions within the user's session

Step 1: Report data and actions

The first step to preventing account takeover is to provide Mosaic with the telemetry required to continuously assess risk for the given context, and to identify trusted users. Report sensitive actions as the user requests to perform them during risk moments.

To report data and actions:

1. Add the Detection and Response code snippets, ideally on each page of your website. This will automatically provide telemetry to our machine learning engine—such as device, network, and other context data used to continuously assess risk.
2. Set the (authenticated) user as soon as possible to add the user context for all subsequent events of the session. This will also be used to create and update a behavioral profile of the user, so we can detect anomalies in the future. The user can either be set using the initialize() call, or after authentication using the setAuthenticatedUser() call. In both cases, it should be set only after you've fully authenticated the user (including, for example, any 2FA that was required). Make sure the user identifier you use doesn't contain any personal information.
3. Report all actions that are relevant to your use case using the triggerActionEvent() call. For example, report login , password_reset , and all other relevant actions .
4. When a user logs out or a user session expires, make sure you call clearUser() so they are not associated with future actions.

Step 2: Get recommendations

For every action you report, use our Recommendation API to fetch our recommendation.

When requesting a recommendation, it's best to specify the user identifier (user_id) associated with the account the user wants to access. Even if the user has not yet been authenticated (e.g., in the case of a login action) and hence was not set using the SDK, this enhances our detection capabilities. For example, we can compare the behavior profile of the unauthenticated user against the profile of the specified user in order to detect behavioral anomalies. Specifying the user also helps us determine whether the same device is being used to access multiple accounts.

Based on the recommendation we provide, you can determine the risk level of the action in the given context, choose an appropriate risk mitigation strategy if needed, and build trust for the user, device, and network. You can also send the recommendations to your analytics systems for further persistancy and offline analytics.

Step 3: Mitigate risk

There are different types of recommendations that you can get (see Recommendation types). If you receive a challenge recommendation, you should mitigate the risk by giving the user a challenge to perform. Choose a challenge that's suitable for the action. For example, for a login action, consider a second-factor authentication. We recommend using a strong biometric-based method since it provides the best user experience and is often the most secure.

Each recommendation includes the reasons for the recommendation, which indicate the risk signals that were used to detect suspicious activity. For example, DEVICE_COOKIE_REUSED may indicate session hijacking, PROFILE_DEVICE_NEW means the user is likely using a new device, and DEVICE_SUSPICIOUS_ATTRIBUTE may indicate device spoofing.

Step 4: Reduce friction

Recommendations not only allow you to mitigate risk, they're also used to build trust. If you receive a trust recommendation, you can trust the activity, extend the session, and lower friction.

Next steps

Leverage our authentication and identity management capabilities for account protection scenarios:

• Add authentication
• Centralize user management across all your apps to reduce risk of data breaches
• Add session management to secure your user sessions