Account Takeover Protection 2-27-2023

Account Takeover Protection
Account Takeover Protection 1

Contents
Contents
Account Takeover Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Get Started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Onboard Your Website. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Configure Mitigation Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Explore the Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Allow Access to Trusted IPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Users at Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
View Username Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Account Takeover Protection API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Account Takeover Protection API Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33


Account Takeover (ATO) Protection detects and mitigates account takeover attempts, protecting your web
applications against volumetric and low and slow ATO attacks.
Benefits:
• Real-time login protection with no added latency

• Maximal mitigation, minimal false positives
• Minimal user configuration and interaction
• Clear visibility into attack attempts, users at risk, and compromised user accounts
Imperva Account Takeover Protection is part of the Imperva Cloud Application Security suite.
In this topic:
• What is ATO?
• How does ATO work?
• The challenge
• Imperva ATO Protection
• Visibility
• How do I get started?

What is ATO?
Account takeover can be characterized as the exploitation of legitimate functionality, rather than by the attempt to
exploit unmitigated vulnerabilities. It is one of the most significant cyberthreats today.
In this form of identity theft, a hacker gains illegal access to user login credentials and uses them for malicious
purposes, such as to carry out transactions for monetary gain, transfer of funds, or ecommerce.
How does ATO work?
ATO works on valid business logic, impersonating legitimate users, putting your assets and reputation at great risk.
Automated ATO attacks can often lead to successful penetration of your web application. For example,
• credential stuffing, in which hackers gain access to lists of user credentials and automate the injection of the
breached user name and password combinations to attempt to gain unauthorized access to user accounts, or
• credential cracking, in which hackers discover valid login credentials by repeated randomized attempts.
Anatomy of an Account Takeover Attack
The challenge
The wide availability of resources and the increasingly sophisticated capabilities of attackers present a real challenge
to the detection and mitigation of ATO attacks.
• Stolen lists of credentials are publicly available for free or for low cost online. The common practice of password
reuse on multiple systems or devices greatly increases the risk.
• Distributed "low and slow" ATO attacks, in which the source of the attack spans many IP addresses and
geolocations at a slow rate using hacked computers or routers, enable hackers to stay below the radar and
remain undetected.
• Automation tools are used to mask hackers as legitimate users.
• Once detected, attackers quickly change tactic. Attacks continue to evolve to avoid detection and mitigation.

The detection and mitigation methods of traditional security tools are not sufficient to protect against ATO attacks.
They use methods such as:
• Helping your users choose secure passwords: Even complicated passwords are now being hacked.
• Multi-factor authentication: Unnecessary challenges negatively impact the user experience.
• Mitigation based on login history and IP reputation: IPs can be quickly changed.
A different approach is needed. Successful protection requires accurate detection and advanced mitigation.
Imperva ATO Protection
How can you protect against account takeover?
Accurate detection
Accurate detection is critical for minimizing false positives and maximizing protection.
Imperva Account Takeover Protection employs a layered approach that takes into account a range of factors to
determine the identity and intent of those attempting to gain access to your system.
Identify the source: Is it bot or human? Good or bad bot? Our unique classification technology can identify the
specific type of bot visiting your website. Not all bots pose a threat. In fact, some are crucial to your business. Good
bots are used for productive purposes, such as for gathering data for search engines (googlebot), for commercial
purposes (finding you the best deal), or for chatbots (customer service).
Determine the intent: In addition to looking at who is attempting to log in and the method they are using, our
detection mechanism has to consider the intent of the client as well. Is the login attempt legitimate?
We collect data on devices and IPs, and continue to add them to our reputation engine. Our extensive global network
provides a dynamic view that feeds our system with additional information all the time, leading to fast and accurate
detection.
Attack Probability
Our proprietary system of complex algorithms takes into account factors such as client application, login attempt
rates, and IP reputation, and builds a profile that assesses the likelihood of attack. Then Account Takeover Protection
assigns a risk level to each account takeover attempt: high, medium, or low.
Advanced mitigation
The right balance in mitigation strategy is important. Too lenient, and you are exposed to risk. Too stringent, and you
impact legitimate users and impede the work of good bots that help your business run.
Account Takeover Protection takes a risk-based mitigation approach.
Based on the accumulated information we have on a specific entity at a given time, we assign a risk level. However,
the risk of attack is actively evolving.
For example, an attack may begin from a single source that we don't recognize, but is coming from a standard
browser and appears to be legitimate. At some point, the activity of this client begins to raise suspicion, and continues
for some time. Now the risk has gone up, and our assessed risk level does as well.

Account Takeover Protection enables you to choose a mitigation strategy for each level of risk.
Instead of a static policy, our mitigation evolves as the attack does. You can set a different action for Imperva to take
for each level of risk. For example, you can select a more stringent mitigation for a higher risk level, such as blocking
the login attempt, and a lower level intervention for lower risk, such as a CAPTCHA challenge.
Once you make your selections and test your strategy, your mitigation policy goes into effect. We actively assess the
risk level of each login attempt, and mitigate accordingly, reducing the need for manual mitigation or your additional
input.
Visibility
Account Takeover Protection provides visibility into login activities. You can see if your sites are under attack, which
sites are affected, and which user accounts were hacked.
Of equal or greater significance, you can see which user accounts are at risk, and take the appropriate action.
How do I get started?
New to Account Takeover Protection? Here's how to get started:
Activity More information

Onboarding Get Started
Configure mitigation rules and run a simulation to
Configure Mitigation Rules
assess impact
Explore the data Explore the Data
Drill down into the list of compromised users and
Users at Risk
take appropriate action
See also:
• Get Started
• Configure Mitigation Rules
• Explore the Data
Last updated: 2022-04-14

Get Started
Get started with Imperva Account Takeover Protection.
In this topic:
• Prerequisites
• Connect to Account Takeover Protection
• Onboard a site
Prerequisites
Before getting started with Account Takeover Protection, you need the following:
• An Imperva cloud account. To set up an account, contact an Imperva sales representative.

• An Imperva protected site. Make sure that the website or web application that you want to protect is
configured in the Cloud Security Console.
Connect to Account Takeover Protection
Log in to Account Takeover Protection from the Imperva Cloud Security Console:
Log in to your my.imperva.com account.
1. On the top menu bar, click Application.
2. On the sidebar, expand Advanced Bot Protection and click Account Takeover.
Onboard a site
To get started with Account Takeover Protection, you need to configure a login endpoint. For details, see Onboard
Your Website.
See also:


Onboard Your Website

Account Takeover Protection's capabilities to detect and mitigate account takeover attempts start with behavior
detection on login pages. To get started with ATO Protection, you need to provide details about your site's login
process.
In this topic:
• Overview
• Start the onboarding wizard
• Step 1: Configure the login endpoint
• Step 2: Initial Validation
• Step 3: Failed Login Test
• Step 4: Successful Login Test
• Step 5: Set PII Password (Optional)
• Edit or delete an endpoint configuration
Overview
To onboard a site to Account Takeover Protection, you have to provide the following information about your site's
login process:
• The login endpoint: The path to which the login request is sent.
• The login parameters: The username and password parameters used for login.
• Success criteria: Indicators unique to a successful login, such as return codes, response headers, or page
contents.
Login endpoints are configured per site. You can configure multiple endpoints for your site if needed. For example,
your login endpoints may be an HTML page or an API call.
Supported use-cases
This self-service onboarding process is best suited to a login process that meets the following criteria:
• You have confirmed the full and accurate login path and it does not change. For example, if your login page or
site is being redirected, make sure to configure the destination path.
• You have confirmed the login success criteria, it is unique, and can be distinguished from a failed login attempt
by one and only one of the following:
• HTTP status code
• A response header with a different value for failed and successful logins
• Specific text in the response body that does not appear in a failed login
• The username and password are present in the same request, and the success criteria applies to the response of
that specific request.
• If an endpoint supports login using different, alternative parameters, for example - if it's possible to log in using
either "username" or "email", you can run the onboarding wizard more than once for the same endpoint,
configuring each one with a different login parameter.
Start the onboarding wizard
1. Open Account Takeover Protection. For details, see Get Started.
2. Under Site, select the website that you want to onboard.

3. On the dashboard, click the Settings icon.
4. Under Login Endpoints, click Add login endpoint config and fill in the fields.
Step 1: Configure the login endpoint
Provide the following details to configure the login endpoint for your site.
You can either provide the login endpoint path, or start with one of the available onboarding templates available in
the Type field.
Field Description
The request that is sent when a user enters their

login credentials to gain access to your site or
application.
This is the HTTP POST request sent by login

requests, and not the login page itself.
Login endpoint path
Format:
• Must start with /

• Does not include the host/domain name
For example: /shop/auth/login
Select an onboarding template to automatically fill

in the fields with standard, recommended values.
You can then edit the fields as needed.
Templates are available for:
• Wordpress
• Joomla
Type • Jenkins
• Confluence
• Outlook Web App
• Jira
• Basic Auth: This template automatically
inserts the username and password
parameters, which you cannot change. The
values are then extracted by the Imperva
proxy during login.
Success criteria
Define the indicator of a successful login to your site.

Field Description
Options include:
• Response "status code" is: Enter the HTTP

status code that indicates a successful login.
For example, 202.
• Response "header" contains the key name
and value pair: Enter the key and value pair
contained in an HTTP response header that
indicates a successful login. For example,
Location, /user/
• Response "body" contains the exact string:
Enter the string contained in the
HTTP response body that indicates a
successful login.
Enter the name of the username and password

parameters used for login to your site.
Login parameter names
These parameters must either be sent in the
POST request as URL-encoded path parameters or
appear as JSON values in the request body.
Where can I find the required information?
Your application team should provide the details. The following questions can help the application team give you the
information you need for onboarding:
• Does the site use HTTP POST for logins?

• Does the login request have a dedicated endpoint (e.g. "POST /auth/login", as opposed to "POST /index.php?
action=login" or "POST /" with an "action" request header)? Does every POST to this endpoint represent a login
request?
• What is the path to the login endpoint when it is sent from Imperva Cloud WAF to the service's host?
• Does the site have more than one endpoint through which users can log in? If so, what are they? Do they all use
HTTP POST?
• If I look at the HTTP request in plain text, how would I identify the username? Is there more than one way to
send a username in a login request?
• If I look at the HTTP request in plain text, how would I identify the password? Is there more than one way to
send a password in a login request?
• Is the password sent as is? If not, how is it transformed?
• Are the username and password sent in the same request (the login request)?
• Is the username and password combination the only thing in the request which would determine the login's
success or failure? Or are there other factors in the same request, such as CAPTCHA, verification code, or
security questions?
• Does the site use 2FA or MFA of any sort? If so, is it mandatory in every request?
• Can the client/UI determine from the response to the login request whether or not login was successful?

• Given the response to the login request, how does the client/UI differentiate a successful login from a failed
one?
For many sites, the following steps are sufficient to obtain the login details. In any case, it is advisable to confirm the
details with the application team. You can also use these steps to confirm the information you received.
1. In a browser, open the site you are onboarding.

2. Open developer tools > Network tab.
3. Log in to your site with credentials that will result in a failure to log in. Click the login request in the developer
tools to retrieve the information you need. The name of the login request is typically something like login,
signin, auth, or validate. Copy the status code, response headers, and response body details as described in the
table below.
4. Log in to your site again, this time using credentials that can successfully log in. Copy the details again.
5. Compare the details to identify and confirm the distinctions between a successful and failed login.
Details to retrieve from developer tools:
Header For use in this ATO Protection onboarding field:

Request URL Login endpoint path
Examples of success/failure criteria:
Status code
Success criteria
Headers
Set-Cookie: Auth=true
Response body contains the string:
"Successfully logged in"
Login parameter names: Username/email and

Request Payload or Form Data
password
Step 2: Initial Validation
Imperva attempts to detect actual login attempts to your site in order to validate the endpoint configuration you
defined in Step 1.
If you do not expect any login attempts during this time, you can click Next to skip this step.
If validation fails, make sure that the information you entered in Step 1 is accurate and complete.

Step 3: Failed Login Test

Imperva attempts to validate your endpoint configuration to confirm that a failed login attempt can be accurately
detected.
1. Use the randomly generated username and password on this page to log in to your site.
If your site requires a username in a different format, such as an email address or specific password
requirements, you can edit the Generated Username or Generated Password fields to prevent the test from
failing unnecessarily. Make sure that the username is not a valid username on your site.
Note: If you edit the Generated Username or Generated Password fields, you must click Apply before
attempting to log in to your site with these credentials.
2. Return to the ATO onboarding page and confirm that your failed login configuration was successfully validated.
Step 4: Successful Login Test
Imperva attempts to validate your endpoint configuration to confirm that a successful login attempt can be accurately
detected.
1. Enter a username for an active account on your site and click Apply.
2. Log in to your site using the username you entered, and the valid password for the user.
3. Make sure that login to your site is successful.
4. Return to the ATO onboarding page and confirm that your successful login configuration was successfully
validated.
Note: If the self-service onboarding process does not complete successfully, make sure to recheck the details you
configured. If you encounter other issues that prevent the self-service onboarding from completing successfully,
please contact Support.
Step 5: Set PII Password (Optional)
Set a PII password in order to see usernames in cleartext.
To protect the privacy of your users, username fields containing personally identifiable information (PII) are encrypted
by default and displayed as an encoded string in the Account Takeover Protection console.
To access the username details for the users who attempt to log in to your protected sites, you can set this option to
display username data in cleartext.
Note:
• This step is optional and can also be completed later on the Settings page. The benefit of setting the PII
password as early as possible ensures no data is lost, as data collected before the PII password is set cannot be
decrypted and will not be available.
• This step of the onboarding process is displayed only if a PII password has not yet been configured for any
endpoint in the website.
To learn more about this feature, see View Username Data.

Edit or delete an endpoint configuration

On the Settings page, under Login Endpoints, click the Login URL.
Next step:
Define an encryption password for your site to enable you to view cleartext usernames in Account Takeover
Protection: View Username Data

Configure Mitigation Rules

Mitigation rules assign actions, such as Block or Captcha challenge, to account takeover attempts for varying levels
of risk.
By default, the Account Takeover Protection mitigation strategy provides the appropriate level of protection for most
customer scenarios.
If you find that the default strategy is not sufficiently addressing your needs, you can configure custom settings,
manually assigning a mitigation action to each attack probability.
Then you can run a simulation to assess the impact of your protection strategy and view the results.
In this topic:
• Open the configuration page

• Evaluate the default protection strategy
• Configure a custom protection strategy
Open the configuration page
To view or configure the mitigation strategy for your site:
On the Account Takeover Protection dashboard, click Configure mitigation.
Evaluate the default protection strategy

The default Account Takeover Protection mitigation strategy blocks all malicious account takeover attempts with a
high risk probability.
Hover over the HIGH link on the screen to view statistics on high-risk traffic to your site.
Configure a custom protection strategy

1. Click the Custom Protection Strategy toggle button to display the custom settings.

2. Configure your mitigation strategy and simulate the impact:
1. Assign a mitigation action to each attack probability. For more details on attack probability, see Account
Takeover Protection.
Action Description
Blocks the login request and does not allow

the user to log in.
When Account Takeover Protection blocks a

request, the HTTP 403 Forbidden response
Block status code is returned to the client. The
content of the response also includes Imperva
error code 15 which indicates that the request
was blocked by security rules. For more details
on Imperva error codes, see Cloud WAF Error
Pages and Codes.
Captcha The user is presented with a captcha challenge

before being allowed to log in.

Action Description
By default, Google reCAPTCHA is used. You can
opt to use GeeTest CAPTCHA instead for a
specific site. For details, see Website Security
Settings.
The response is never sent and the connection

is kept open, leaving the bots waiting
endlessly. It is effectively a block without
Tarpit immediate notification to the client that the
request was blocked. It adds confusion
regarding the request state and causes the
attackers to waste more of their resources.
None No action is taken.
2. Click Simulate to see how your configuration applies to recent account takeover attempts. For example,
you may see that based on your current strategy, an excessively high percentage of your customers will
get a CAPTCHA challenge, leading you to reconsider your settings.
3. Apply the configuration:
When you are satisfied with your strategy, click Apply Configuration to activate the rules for your site.
See also:


Explore the Data

Explore the data for your site on the Account Takeover Protection Dashboard.
In this topic:
• Filter the displayed data

• Configure mitigation
• Login activity over time
• Users under risk
• Top visitors
• Account takeover attempts by country
Filter the displayed data
The banner at the top of the dashboard describes the data displayed on the page.
Select a site in your account and a time frame for the data.
View data for an individual endpoint
If you have defined multiple login endpoints for your website, you can select one from the Endpoint Selection drop-
down. (By default, the dashboard displays data for all endpoints.)
The dashboard is then refreshed and displays data for the selected endpoint only.
If you drill down further by clicking View details on one of the dashboard sections, data is displayed according to the
time and endpoint selected on the dashboard.
Note: The User Anomaly section on the dashboard is not currently refreshed by the endpoint selection and continues
to display data for all endpoints.
Configure mitigation
Assign mitigation actions, such as Block or Captcha, to account takeover attempts for each risk level. Run a
simulation to assess the impact of your security strategy and view the results.
For details, see Configure Mitigation Rules.

Login activity over time
View trends and statistics on logins and login attempts to your site.
• See the percentage of ATO attempts as compared to total login attempts.

• View the impact of your mitigation strategy on malicious attempts.
• Examine ATO trends over time.

When you drill down into any of the login data (by clicking View details on suspicious/mitigated/aggregator logins),
the Visualize option enables you to view a graphical representation of login attempts over time according to the
client's source IP address.
On the graph:
• Hover for more details on specific data points.

• Click View legend to select the data points to display in the graph.
• Filter using the legend radio buttons below the graph.
• Click and drag to zoom in.
Widget Description
All login attempts to your site - successful, mitigated,
Total logins
malicious, legitimate.
Any potential takeover, as determined by our

Account takeover logins
internal detection mechanism.
Successful login requests that have a risk level

assigned to them by Account Takeover Protection.
Suspicious successful logins
Click View details to see the list of compromised
user accounts. For more details, see Users at Risk.
The number of attempted logins to your site that

were mitigated according to your configured
mitigation rules.
If you have not yet configured mitigation rules, this

statistic is disabled in the graph.
Mitigated suspicious logins
After you configure mitigation rules, this category is
automatically enabled and you begin to see the
impact in the graph.
To configure mitigation, see Configure Mitigation

Rules.
Aggregator logins The number of login requests that were classified as

coming from known aggregators.

Widget Description
An aggregator is a service, used mainly in the
financial sector, that retrieves information from
multiple accounts and services on behalf of its
customers and displays it in one location. Using the
credentials provided by their customers, the
aggregator logs in to the accounts to retrieve the
information.
Aggregators can generate many logins from the

same IP address, which can be perceived as an
attack. Account Takeover Protection identifies
aggregators, distinguishing them from attackers,
and thereby reduces false positives.
Click View details for more information. Account

Takeover Protection provides a list of logins that we
have determined with a medium or high level of
confidence to be aggregators.
The Aggregator IPs page displays the list of

aggregator IP addresses, along with the related
information such as the confidence level assigned to
the IP, the source country, and failed/successful
logins during the last 24 hours.
In addition, a sampling of logins for each IP is

provided, including the username and client
application that was used for logging in.
Users under risk

View details of user accounts that have been hacked or are at risk of being compromised.
See recent trends in account takeover attempts for the site.
For more details on this area, see Users at Risk.
Widget Description
Unique credentials seen in successful login requests

Suspicious successful logins (unique users) that have a risk assigned to them by Account
Takeover Protection.
Users whose login credentials have been found in

Leaked credentials
publicly available online databases of leaked
credentials.

Widget Description
Click to see the list of user accounts with leaked
credentials.
Users whose login credentials have been used by

attackers and are likely to be publicly leaked.
Likely leaked credentials
Click the section to view details.
Top visitors
Top Attackers
View the distribution of account takeover attempts for each attack probability level, listed by client type, IP, IP
reputation, and successful user logins:
Tab Description
The client application used for the account takeover

attempt.
Client application
For the full list of Imperva classified clients, see
Client Classification.
The IP address of the client used for the account

IP
takeover attempt.
The categorization of the source IP, based on our

internal classification and assessment mechanisms.
The reputation gives an indication of the type of

IP Reputation
activity originating from that IP.
For example, comment-spammers, anonymous

proxies, or Google Cloud Platform
User Anomaly
Behaviors that deviate from what is considered standard and reasonable login activity can be an indication of fraud.
Account Takeover Protection tracks login patterns to detect anomalies, such as logging in from too many IPs, from a
new ASN, or from several different countries in too short a time span.

Tab Description
Users that logged in from an unusual amount of

Username
different IP addresses.
ASN Users that logged in from different ASNs.

Country Users that logged in from multiple countries.
Users that logged in from locations that are too far
Velocity Violation
apart in too short a time.
Successful Users Users that successfully logged in.
Login timeline
In each section, you can click on a username to view the login timeline. All of the user's logins are listed, including the
time, source location, IP address, and VPN (if used) of the login. You can also see if the login was successful or not.
The Visualize option enables you to view a graphical representation of login attempts over time for each username.
Account takeover attempts by country

View the distribution of account takeover attempts by country for the selected site and time frame.
You can download the data as an image in .png format.
See also:

• Users at Risk

Allow Access to Trusted IPs

You can add an IP address to the Account Takeover Protection allowlist to indicate that all login attempts from this IP
should be allowed access.
Note: The Account Takeover Protection allowlist is independent from other allowlists and has no impact on Cloud
WAF or Advanced Bot Protection behavior.
To configure the allowlist:
On the Account Takeover Protection dashboard, click Settings.
Under Allow List, click Configure allowlist.
You can add a single IP, multiple IPs, or an IP range.
To add multiple IP addresses, separate the values with commas.
To add an IP range, enter IP/Mask.

Users at Risk
View the list of user accounts that have been hacked or are at risk of being compromised. Review the details of the
user accounts at risk and take appropriate action, such as advising your customers to change their passwords.
On the Account Takeover Protection dashboard, under Users under risk, click the arrows to view additional details.
In this topic:
• Suspicious successful logins (unique users)

• Reasons
• Leaked credentials
• Likely leaked credentials
Suspicious successful logins (unique users)
Successful login requests that have a risk level assigned to them by Account Takeover Protection.
We examine each login, add it to our database, and compare it to publicly available lists of leaked credentials. If a
match is found, it is displayed here, enabling you to take appropriate action, such as requesting that your customer
changes their password.
Suspicious successful logins
Displays information on suspicious logins by Source IP. Click a row to display the list of users in the Account
takeovers table.
Field Description
Source IP The IP address of the suspicious login.
Country The country of origin of the source IP.
The number of users hacked by the selected IP
address. The list is displayed in the
# of account takeovers
Account takeovers table on the right. See more
details below in Account takeovers.
The categorization of the source IP, based on our

internal classification and assessment mechanisms.
The reputation gives an indication of the type of

IP reputation
activity originating from that IP.
For example, comment-spammers, anonymous

proxies, or Google Cloud Platform
Last seen Time stamp of the last login attempt.

Field Description
The severity of the risk. For more details, see Attack
Risk level
Probability in Account Takeover Protection.
Account takeovers
The users hacked by the selected IP address. User names are encrypted.
Select a Source IP in the left pane to display the list.
Field Description
The encrypted user name of the compromised

account.
To access the username details for the users who

Username
attempt to log in to your protected sites, you can
configure Account Takeover Protection settings to
display username data in cleartext. For details, see
View Username Data.
The client application used for the account takeover.

Client application For the full Imperva client classification list, see
Client Classification.
The client application used for the account takeover,
according to the declaration in the UserAgent HTTP
Declared client app
header of the login request. For the full Imperva
client classification list, see Client Classification.
The trigger for identifying that the user account was
Reason
hacked. For more details, see Reasons.
Event time Time stamp of the account takeover.
Reasons
The activity that caused these accounts to be marked as compromised.
Reason Description
Excessive failed login rate with multiple usernames,

originating from the same device in a short period in
time.
Brute force
Determined by factors such as the login result ratio
per device, number of usernames, and the device
risk based on Imperva reputation and classification
indicators.

Reason Description
Excessive failed login rate with excessive number of

different passwords, originating from the same
device in a short period in time.
Password brute force
per device, number of failed logins, and the device
indicators.
Excessive failed login and number of common

passwords (passwords most frequently used in
dictionary attacks, e.g. 123456), originating from the
same device in a short period in time.
Common password
Determined by factors such as the number of failed
logins per device, password reputation, and the
device risk based on Imperva reputation and
classification indicators.
Excessive failed login and number of common users

(e.g., admin, administrator), originating from the
same device in a short period in time.
Common user
Determined by factors such as the number of failed
logins per device, user reputation, and the device
indicators.
Excessive number of successful logins, using known

leaked credentials, originating from the same device
in a short period in time.
Credential stuffing
per device, credential reputation, and the device risk
based on Imperva reputation and classification
indicators.
Excessive failed logins from devices that share

Dynamic bot signatures
unique signature-related characteristics over a short
period of time.

Reason Description
This is calculated on the entire site and all of its
devices, and the determination of risk is based on
common group behavior.

per site and its risk, based on Imperva reputation
and classification indicators.
"E" indicates that the specified signature was

determined to be especially malicious and was
assigned an "extreme" level of risk by Account
Takeover Protection. These signatures are blocked
from the first request.
Excessive number of users successfully logged from

the same device in a short period of time.
Suspicious number of users
per device and its risk based on Imperva reputation
and classification indicators.
Leaked credentials
Users whose login credentials have been found in publicly available online databases of leaked credentials.
View the list of user names, the IP address used to log in, and the time of login.
Likely leaked credentials
Users whose login credentials have been used by attackers and are likely to be publicly leaked.
Imperva Research Labs analyze Account Takeover Protection data on credential stuffing attacks across our customer
base to determine which other credentials may be connected to an identified attacker, and therefore likely to also be
at risk.
Section Description
Graph of logins over time.
Compare the total number of login attempts to the

Likely leaked credentials number of login attempts that used risky
credentials.
Click and drag a section of the graph to zoom in to a

smaller time range.

Section Description
Toggle the options in the legend for different views
of the graph.
The number of login attempts that used risky

Total logins with likely leaked credentials
credentials.
The number of unique credentials used by attackers

Unique likely leaked credentials
that logged in to the website.
The list of user credentials identified as risk and

likely to be publicly leaked, including username and
the source IP address of the login.
Usernames used by attackers
Usernames are encrypted by default. For more
details, see View Username Data.
For example, there may be 1 unique set of credentials used by attackers attempting to login to your site, and a total of
5 login attempts using those credentials.
This section also displays trend data, comparing the statistics to the previous time period, according to the time range
selection on the Account Takeover Protection dashboard.

See also:


View Username Data

To protect the privacy of your users, username fields containing personally identifiable information (PII) are encrypted
by default and displayed as an encoded string in the Account Takeover Protection console.
To access the username details for the users who attempt to log in to your protected sites, you can configure Account
Takeover Protection settings to display username data in cleartext.
In this topic:
• Overview
• Enable cleartext usernames
• How it works
• Reset your password
Overview
To display cleartext usernames, you create a password for each site in the account that you want to view username
data for.
Password sharing
The password defined for the site is shared by all account users. Each user is required to enter the password in order
to view username data in cleartext.
PII-enabled sessions
When you define the password, or enter the password that another account user has defined, the feature is enabled
for your browser session. Once enabled, cleartext usernames are displayed for 14 days or until you clear your cache.
After this time, you are required to re-enter your password to display cleartext usernames.
Note: Cleartext usernames are displayed only for login requests that occur after the PII password is set, or if the
usernames were found in publicly available leaked credential lists.
If a password has been defined for the site but is not enabled in your browser, encrypted usernames are displayed.
This occurs when:
• the password was defined by another user and you have not yet entered it in your browser
• you log in to ATO protection from another browser or device
• your PII-enabled session has expired.
Enable cleartext usernames
Open the Account Takeover Protection Settings:
1. On the dashboard, click the Settings icon.

2. Under Personally Identifiable Information (PII) Management, define or enter the password for securing your
username encryption key.

Password requirements
A strong password is required. The password must contain:
• At least 8 characters
• At least 1 uppercase letter
• At least 1 lowercase letter
• At least 1 number
• At least 1 special character
Note: The password you define in ATO Protection is not connected to the password you use to access the Cloud
Security Console.
How it works
When you define a password to enable this feature, Imperva generates a public and private RSA key pair for the
selected site in your account. The password is then used to secure your username encryption key.
• The public key is used to encrypt incoming usernames, and is stored in our database.
• The password you define is used to encrypt the private key. The password is not maintained in our database. It
is retained by the browser until the session expires or until you clear the cache.
• The password-encrypted private key is required to decrypt the usernames, and is stored in our database for this
purpose. Because we do not have the password, we cannot access the encrypted data, and your customer PII
remains protected.
Reset your password
On the Account Takeover Protection dashboard, open the Settings and click Change password.
After you reset your password, you can no longer access the cleartext data for usernames that were previously
encrypted using the old password. Once you set a new password, encryption begins on new login data using the new
password.

Account Takeover Protection API

Access your Imperva Account Takeover Protection data using an API.
Authentication
In order to use the API, you must be authenticated. To authenticate, send your API ID and API key using the x-API-Id
and x-API-Key request headers. For example:
x-API-Id: 12345
x-API-Key: 123**************789
You create and manage API keys in the Cloud Security Console. For details, see API Key Management.
ATO API Definition
For instructions on using the Account Takeover Protection API, see the Account Takeover Protection API Definition.
The definition file presents a full, formatted, and interactive version of the ATO APIs that you can use to learn about
the APIs, or test them using your API ID and key.

Account Takeover Protection API Definition

This is the API documentation for Imperva Account Takeover Protection. ATO detects and mitigates account takeover
attempts, protecting your web applications against volumetric and low and slow ATO attacks. For the full feature
documentation, see https://docs.imperva.com/bundle/account-takeover.
More information: https://helloreverb.com
Contact Info: hello@helloreverb.com
Version: 2.0.0
BasePath:/ato
All rights reserved
Access
http://apache.org/licenses/LICENSE-2.0.html
1. APIKey KeyParamName:x-API-Id KeyInQuery:false KeyInHeader:true

2. APIKey KeyParamName:x-API-Key KeyInQuery:false KeyInHeader:true
Methods
Models
Table of Contents
Configuration
• post /v2/sites/{siteId}/onboard/copy-to/{target-site-id}
• delete /v2/sites/{siteId}/endpoint/{endpointId}
• get /v2/sites/{siteId}/endpoints
• get /v2/sites
Evidence
• post /v2/sites/{siteId}/report/evidence/aggregators
• post /v2/sites/{siteId}/report/evidence
• post /v2/sites/{siteId}/report/evidence/suspicious-successful
• post /v2/sites/{siteId}/report/evidence/leaked
• post /v2/sites/{siteId}/report/evidence/likely-leaked
• post /v2/sites/{siteId}/report/evidence/mitigated
General
• post /v2/sites/{siteId}/allowlist
• get /v2/sites/{siteId}/allowlist
• delete /v2/sites/{siteId}/allowlist
• put /v2/sites/{siteId}/allowlist
Mitigation
• get /v2/sites/{siteId}/mitigation

• post /v2/sites/{siteId}/mitigation
PiiPassword
• delete /v2/sites/{siteId}/pii-password
• post /v2/sites/{siteId}/pii-password
Statistics
• post /v2/sites/{siteId}/stats
Timeline
• post /v2/sites/{siteId}/timeline
TopSources
• post /v2/sites/{siteId}/stats/top
• post /v2/sites/{siteId}/stats/top/client
• post /v2/sites/{siteId}/stats/top/country
• post /v2/sites/{siteId}/stats/top/ip
• post /v2/sites/{siteId}/stats/top/ip-fingerprint
• post /v2/sites/{siteId}/stats/top/reputation
Users
• post /v2/sites/{siteId}/stats/users/aggregators
• post /v2/sites/{siteId}/stats/users
• post /v2/sites/{siteId}/stats/users/leaked
• post /v2/sites/{siteId}/stats/users/likely-leaked
• post /v2/sites/{siteId}/stats/users/suspicious-successful
Up
post /v2/sites/{siteId}/onboard/copy-to/{target-site-id}
Copy a single login endpoint, or all of them, from the "source" website to the "target" website
under the same account ID (copyEndpointConfigurationFromSiteToAnotherSite)
Both sites must be under the same account ID (no sub-accounts support yet). In addition, mitigation settings are not
copied.
Path parameters
siteId (required)
Path Parameter — The Imperva ID of the "source" website (the website we copy from) format: int64
target-site-id (required)
Path Parameter — The Imperva ID of the "target" website (the website we want to copy the endpoint
config to) format: int64
Query parameters
caid (optional)

Query Parameter — The Imperva account ID. By default, the API operates on account (A) associated with the API
credentials used for authentication. To operate on a different account (an account under the account (A)), specify the
account ID. format: int64
endpointId (optional)
Query Parameter — Optional: pass an endpoint ID to copy, if none passed all endpoints will be copied
Responses
200
OK
400
Bad Request
401
Not Authorized
500
Internal Server Error
Up
delete /v2/sites/{siteId}/endpoint/{endpointId}
Delete an endpoint for this website (deleteEndpoint)
Delete the specified endpoint from the specified website.If the API key used is for a parent account, and the website
belongs to a sub account, the caid of the sub account must be specified.
Path parameters
endpointId (required)
Path Parameter — The endpoint ID to delete
siteId (required)
Path Parameter — The Imperva ID of the website format: int64
Query parameters
caid (optional)
Responses
200
OK

400
Bad Request
401
Not Authorized
500
Up
get /v2/sites/{siteId}/endpoints
Retrieve all the onboarded login endpoints for this website (getEndpoints)
Retrieve a list of all onboarded login endpoints for your website. Each endpoint will include its id, url, username and
password parameters. If the API key used is for a parent account, and the website belongs to a sub account, the caid of
the sub account must be specified.
Path parameters
siteId (required)
Query parameters
caid (optional)
Return type
array[Endpoints]
Example data
Content-Type: application/json
[ {
"password" : "password",
"endpointId" : "endpointId",
"url" : "url",
"username" : "username"
}, {
"password" : "password",
"url" : "url",
"username" : "username"
} ]

Produces
This API call produces the following media types according to the Accept request header; the media type will be
conveyed by the Content-Type response header.
• application/json
Responses
200
List of onboarded endpoints, each includes url, id, username and password parameters
400
Bad Request
401
Not Authorized
500
Up
get /v2/sites
Retrieve all onboarded sites with their mitigation status. (getOnboardedSitesWithMitigationStatus)
Retrieve a list of all onboarded sites for the account ID. Each site will include the Imperva website ID, site name, and
mitigation status. If the API key used is for a parent account, and the website belongs to a sub account, the caid of the
sub account must be specified.
Return type
array[SiteStatus]
Example data
[ {
"websiteName" : "mysite.com",
"isMitigationOn" : true,
"siteId" : 0
}, {
"websiteName" : "mysite.com",
"isMitigationOn" : true,
"siteId" : 0
} ]

Produces
Responses
200
List of onboarded sites with their mitigation status.
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/report/evidence/aggregators
Retrieve aggregated login report (getAggregatorsEvidence)
Retrieve the list of login events that were classified as coming from known aggregators. If the API key used is for a
parent account, and the website belongs to a sub account, the caid of the sub account must be specified.
Path parameters
siteId (required)
Consumes
This API call consumes the following media types via the Content-Type request header:
• */*
Request body
body EvidenceRequest (required)
Body Parameter — Specify the time selection and/or endpoint ID
Query parameters
caid (optional)

Return type
Evidence
Example data
{
"evaluation" : {
"risk factors" : [ "risk factors", "risk factors" ],
"reputation" : [ "reputation", "reputation" ],
"type" : "type"
},
"request" : {
"referrer" : "referrer",
"request session id" : 6,
"request path" : "request path",
"request client" : "request client",
"declared request client" : "declared request client",
"request country" : "request country",
"request time" : 1,
"request id" : 0,
"request IP" : "request IP"
},
"deviceStats" : {
"fingerprint" : "fingerprint",
"leaked credentials" : 5,
"risk" : "LOW",
"successful logins" : 2,
"failed logins" : 5
}
}
Produces
Responses
200
List of aggregator login events Evidence

400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/report/evidence
Retrieve report of all user logins (getAllEvidence)
Retrieve the list of successful login events that used publicly available leaked credentials. If the API key used is for a
Path parameters
siteId (required)
Consumes
• */*
Request body
Query parameters
caid (optional)
Return type
SuspiciousSuccessfulEvidence
Example data
{
"aggregators" : "aggregators",
"suspiciousSuccessful" : "suspiciousSuccessful",

"likelyLeaked" : "likelyLeaked",
"leaked" : "leaked",
"mitigated" : "mitigated"
}
Produces
Responses
200
List of login events SuspiciousSuccessfulEvidence
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/report/evidence/suspicious-successful
Retrieve the compromised users login report (getCompromisedEvidence)
Retrieve the list of successful login events that had a non-zero probability of being an attack. If the API key used is for a
Path parameters
siteId (required)
Consumes
• */*
Request body

Query parameters
caid (optional)
Return type
Evidence
Example data
{
"evaluation" : {
"type" : "type"
},
"request" : {
"request time" : 1,
"request id" : 0,
},
"deviceStats" : {
"risk" : "LOW",
"failed logins" : 5
}
}
Produces

Responses
200
List of login events, returned type is always COMPROMISED Evidence
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/report/evidence/leaked
Retrieve the leaked users login report (getLeakedEvidence)
Retrieve the list of successful login events that used publicly available leaked credentials. If the API key used is for a
Path parameters
siteId (required)
Consumes
• */*
Request body
Query parameters
caid (optional)
Return type
Evidence

Example data
{
"evaluation" : {
"type" : "type"
},
"request" : {
"request time" : 1,
"request id" : 0,
},
"deviceStats" : {
"risk" : "LOW",
"failed logins" : 5
}
}
Produces
Responses
200
List of login events, returned type is always LEAKED Evidence
400
Bad Request
401
Not Authorized

500
Up
post /v2/sites/{siteId}/report/evidence/likely-leaked
Retrieve the likely leaked users login report (getLikelyLeakedEvidence)
Retrieve the list of likely leaked login events that potentially used publicly available leaked credentials. If the API key
used is for a parent account, and the website belongs to a sub account, the caid of the sub account must be specified.
Path parameters
siteId (required)
Consumes
• */*
Request body
Query parameters
caid (optional)
Return type
LikelyLeakedEvidence
Example data
{
"ip" : "ip",
"request time" : 0,
"user" : "user"
}
Produces

Responses
200
List of likely leaked login events LikelyLeakedEvidence
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/report/evidence/mitigated
Retrieve the mitigated (CAPTCHA, BLOCK, TARPIT) users login report (getMitigatedEvidence)
Retrieve the list of mitigated (CAPTCHA, BLOCK, TARPIT) login events. If the API key used is for a parent account, and
the website belongs to a sub account, the caid of the sub account must be specified.
Path parameters
siteId (required)
Consumes
• */*
Request body
Query parameters
caid (optional)

Return type
Evidence
Example data
{
"evaluation" : {
"type" : "type"
},
"request" : {
"request time" : 1,
"request id" : 0,
},
"deviceStats" : {
"risk" : "LOW",
"failed logins" : 5
}
}
Produces
Responses
200
List of login events, returned type is always MITIGATED Evidence
400
Bad Request

401
Not Authorized
500
Up
post /v2/sites/{siteId}/allowlist
Update the allowlist for a specific site (addToAllowList)
Update the list of IPs and subnets excluded from traffic mitigation by ATO Protection. All traffic from these IPs will not
be mitigated. The input should be a comma separated JSON list containing the IPs to add to the site allowlist. Each
allowed IP object can have a mask property to be applied to that IP and allow that whole subnet. For example:
[{"ip":"192.20.1.1","desc":"My own IP"},
{"ip":"15.5.0.0","mask":"16","desc":"Office
subnet"},
{"ip":"20.1.1.0","mask":"24","desc":"Home
subnet"}]
Path parameters
siteId (required)
Consumes
• */*
Request body
body AllowlistIp (required)
Body Parameter — List of IPs/subnets
Responses
200
OK
400
Bad Request
401
Not Authorized

500
Up
get /v2/sites/{siteId}/allowlist
Retrieve the allowlist for a specific site (getAllowList)
Retrieve the list of IPs and subnets excluded from traffic mitigation by ATO Protection. All traffic from these IPs will not
be mitigated.
Path parameters
siteId (required)
Return type
AllowlistIp
Example data
{
"ip" : "192.10.20.0",
"updated" : 1632530998076,
"mask" : "24",
"desc" : "My own IP to always allow"
}
Produces
• */*
Responses
200
List of the IPs and subnets to exclude from mitigation AllowlistIp
400
Bad Request
401
Not Authorized

500
Up
delete /v2/sites/{siteId}/allowlist
Remove IPs from the allowlist for a specific site (removeFromAllowList)
Remove the list of IPs and subnets from the current allowlist configuration of the site. Matching the IPs and subnets
will be done by comparing the 'ip' and 'mask' fields of the entries. For example:
[{"ip":"192.20.1.1"},
{"ip":"15.5.0.0","mask":"16"}]
Path parameters
siteId (required)
Consumes
• */*
Request body
Body Parameter — List of IPs/subnets to remove
Responses
200
OK
400
Bad Request
401
Not Authorized
500
Up
put /v2/sites/{siteId}/allowlist
Overwrite the allowlist for a specific site (setAllowList)

Overwrite the list of IPs and subnets excluded from traffic mitigation by ATO Protection. THIS CALL WILL REPLACE THE
EXISTING LIST. All traffic from these IPs will not be mitigated. The input should be a comma separated JSON list
containing all the IPs in the allowlist for the site. Each allowed IP object can have a mask property to be applied to
that IP and allow that whole subnet.
Path parameters
siteId (required)
Consumes
• */*
Request body
Body Parameter — Complete list of IPs/subnets
Responses
200
OK
400
Bad Request
401
Not Authorized
500
Up
get /v2/sites/{siteId}/mitigation
Get the mitigation configuration for a specific site. (getMitigationConfig)
Pass a comma-separated string of endpoint ids in order to get the mitigation configuration just for those ones. If not
passed, this API will retrieve the mitigation configuration for all endpoints
Path parameters
siteId (required)

Query parameters
caid (optional)
endpointIds (optional)
Query Parameter — Comma-separated list of endpoint ids
Return type
array[MitigationRequest]
Example data
[ {
"lowAction" : "NONE",
"highAction" : "NONE",
"mediumAction" : "NONE"
}, {
"lowAction" : "NONE",
"highAction" : "NONE",
"mediumAction" : "NONE"
} ]
Produces
Responses
200
Retrieve a list of endpoint IDs with their mitigation configuration, e.g. [ { "endpointId":
"764337755", "lowAction": "NONE", "mediumAction":
"NONE", "highAction": "BLOCK" }, { "endpointId":
"1429179364", "lowAction": "NONE", "mediumAction":
"CAPTCHA", "highAction": "CAPTCHA" } ]
400
Bad Request

401
Not Authorized
500
Up
post /v2/sites/{siteId}/mitigation
Change the mitigation configuration for a specific site and endpoint. The actions (low, medium, high) should all be in
UPPER CASE. (setMitigationConfigForEndpoints)
Possible values for actions are: NONE, CAPTCHA, BLOCK, TARPIT.
Path parameters
siteId (required)
Consumes
Request body
body MitigationRequest (required)
Body Parameter — Specify endpoint ID and mitigation actions list
Query parameters
caid (optional)
Responses
200
OK
400
Bad Request
401
Not Authorized

500
Up
delete /v2/sites/{siteId}/pii-password
Reset the PII password (deletePiiPassword)
Reset the PII password for the current account. This will delete the currently configured PII password and you will
have to configure a new one before being able to see plaintext usernames. If the API key used is for a parent account,
and the website belongs to a sub account, the caid of the sub account must be specified.
Path parameters
siteId (required)
Query parameters
caid (optional)
Responses
204
No Content
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/pii-password
Update the PII password (setPiiPassword)
Update the PII password for the current account. If the API key used is for a parent account, and the website belongs
to a sub account, the caid of the sub account must be specified.
Path parameters
siteId (required)

Consumes
Request body
body PiiConfigPassword (required)
Body Parameter — Pii Password to update
Query parameters
caid (optional)
Responses
200
OK
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats
Get all stats - top stats and unique users stats. (getAllStats)
If the API key used is for a parent account, and the website belongs to a sub account, the caid of the sub account must
be specified.
Path parameters
siteId (required)
Consumes

Request body
body StatsRequest (required)
Body Parameter — Specify the time selection
Query parameters
caid (optional)
Query Parameter —
Return type
AllStats
Example data
{
"top" : {
"client" : {
"high" : {
"key" : 2
},
"low" : {
"key" : 5
},
"none" : {
"key" : 1
},
"medium" : {
"key" : 5
}
}
},
"users" : {
"leaked" : {
"current total" : 0,
"previous total" : 6
}
}
}

Produces
Responses
200
Retrieve all stats - top stats and unique users stats. AllStats
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/timeline
Get the login timeline for a site. (getLoginsTimeline)
Pass an endpoint id in order to get the timeline just for that one. If you don't pass an endpoint id, all configured ids
will be sent as one "TOTAL" (summed together). A login timeline represents ongoing login requests made
to your site over a time period. Each data point represents the number of logins attempted for that time bucket (each
5 minutes).
Path parameters
siteId (required)
Consumes
Request body

Query parameters
caid (optional)
Query Parameter —
Return type
LoginsTimeline
Example data
{
"intervalMs" : 300000,
"endpointId" : "1616877031",
"timeline" : {
"key" : {
"total" : 7944,
"data" : "[5, 1, 0, 0, 0, 75, 2, 1, 0, 0]",
"prevTotal" : 4532
}
},
"startTime" : 1673624384997
}
Produces
Responses
200
Retrieve the login requests timeline LoginsTimeline
400
Bad Request
401
Not Authorized

500
Up
post /v2/sites/{siteId}/stats/top
Get all the top stats (country, client, reputation, successful user, ip, ip+fingerprint). (getAllTopSourcesStats)
be specified.
Path parameters
siteId (required)
Consumes
Request body
Query parameters
caid (optional)
Query Parameter —
Return type
TopStats
Example data
{
"client" : {
"high" : {
"key" : 2
},
"low" : {
"key" : 5
},

"none" : {
"key" : 1
},
"medium" : {
"key" : 5
}
}
}
Produces
Responses
200
Retrieve all the top stats (country, client, reputation, successful user, ip, ip+fingerprint). TopStats
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/top/client
Get top number of requests by client of unique users for the current time period compared to previous time period
(getTopClients)
be specified.
Path parameters
siteId (required)
Consumes

Request body
Query parameters
caid (optional)
Query Parameter —
Return type
TopSource
Example data
{
"high" : {
"key" : 2
},
"low" : {
"key" : 5
},
"none" : {
"key" : 1
},
"medium" : {
"key" : 5
}
}
Produces
Responses
200
Retrieve the top clients performing logins to this site and endpoint ID, by risk level TopSource

400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/top/country
Get top number of requests by country of unique users for the current time period compared to previous time period
(getTopCountries)
be specified.
Path parameters
siteId (required)
Consumes
Request body
Query parameters
caid (optional)
Query Parameter —
Return type
TopSource
Example data

{
"high" : {
"key" : 2
},
"low" : {
"key" : 5
},
"none" : {
"key" : 1
},
"medium" : {
"key" : 5
}
}
Produces
Responses
200
Retrieve the top countries performing logins to this site and endpoint ID, by risk level TopSource
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/top/ip
Get top number of requests by IP of unique users for the current time period compared to previous time period
(getTopIps)
be specified.
Path parameters
siteId (required)

Consumes
Request body
Query parameters
caid (optional)
Query Parameter —
Return type
TopSource
Example data
{
"high" : {
"key" : 2
},
"low" : {
"key" : 5
},
"none" : {
"key" : 1
},
"medium" : {
"key" : 5
}
}
Produces

Responses
200
Retrieve the top IPs performing logins to this site and endpoint ID, by risk level TopSource
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/top/ip-fingerprint
Get top number of requests by IP + Fingerprint of unique users for the current time period compared to previous time
period (getTopIpsFps)
be specified.
Path parameters
siteId (required)
Consumes
Request body
Query parameters
caid (optional)
Query Parameter —

Return type
TopSource
Example data
{
"high" : {
"key" : 2
},
"low" : {
"key" : 5
},
"none" : {
"key" : 1
},
"medium" : {
"key" : 5
}
}
Produces
Responses
200
Retrieve the top IPs + Fingerprints performing logins to this site and endpoint ID, by risk level TopSource
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/top/reputation

Get top number of requests by reputation of unique users for the current time period compared to previous time
period (getTopReputation)
be specified.
Path parameters
siteId (required)
Consumes
Request body
Query parameters
caid (optional)
Query Parameter —
Return type
TopSource
Example data
{
"high" : {
"key" : 2
},
"low" : {
"key" : 5
},
"none" : {
"key" : 1
},
"medium" : {
"key" : 5

}
}
Produces
Responses
200
Retrieve the top reputations performing logins to this site and endpoint ID, by risk level TopSource
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/users/aggregators
Get aggregators successful requests of unique users for the current time period compared to previous time period
(getAggregatorsStats)
be specified.
Path parameters
siteId (required)
Consumes
Request body

Query parameters
caid (optional)
Query Parameter — format: int64
Return type
UsersStats
Example data
{
}
Produces
Responses
200
Retrieve the aggregators unique users for the requested time span, including the same for the previous time span
UsersStats
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/users
Get all the unique users stats (leaked, aggregator, likely-leaked, suspicious-successful). (getAllUniqueUsersStats)

be specified.
Path parameters
siteId (required)
Consumes
Request body
Query parameters
caid (optional)
Query Parameter —
Return type
AllUserStats
Example data
{
"leaked" : {
}
}
Produces

Responses
200
Get all the unique users stats (leaked, aggregator, likely-leaked, suspicious-successful). AllUserStats
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/users/leaked
Get leaked successful requests of unique users for the current time period compared to previous time period
(getLeakedStats)
be specified.
Path parameters
siteId (required)
Consumes
Request body
Query parameters
caid (optional)

Return type
UsersStats
Example data
{
}
Produces
Responses
200
Retrieve the leaked unique users for the requested time span, including the same for the previous time span
UsersStats
400
Bad Request
401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/users/likely-leaked
Get likely leaked successful requests of unique users for the current time period compared to previous time period
(getLikelyLeakedCredentialsStats)
be specified.
Path parameters
siteId (required)

Consumes
Request body
Query parameters
caid (optional)
Query Parameter —
Return type
UsersStats
Example data
{
}
Produces
Responses
200
Retrieve the likely leaked unique users for the requested time span, including the same for the previous time span
UsersStats
400
Bad Request

401
Not Authorized
500
Up
post /v2/sites/{siteId}/stats/users/suspicious-successful
Get suspicious successful requests of unique users for the current time period compared to previous time period
(getSuspiciousSuccessfulStats)
be specified.
Path parameters
siteId (required)
Consumes
Request body
Query parameters
caid (optional)
Return type
UsersStats
Example data
{
}

Produces
Responses
200
Retrieve the suspicious successful unique users for the requested time span, including the same for the previous time
span UsersStats
400
Bad Request
401
Not Authorized
500

Models
Methods
Table of Contents
1. AllStats
2. AllUserStats
3. AllowlistIp
4. DeviceStats
5. Endpoints
6. Evaluation
7. Evidence
8. EvidenceRequest
9. LikelyLeakedEvidence
10. LoginsTimeline
11. MitigationRequest
12. PiiConfigPassword
13. Request
14. RequestTimeline
15. SiteStatus
16. StatsRequest
17. StreamingOutput
18. SuspiciousSuccessfulEvidence

19. TopSource
20. TopStats
21. UsersStats
AllStats Up
users (optional)
AllUserStats
top (optional)
TopStats
AllUserStats Up
leaked (optional)
UsersStats
aggregator (optional)
UsersStats
suspiciousSuccessful (optional)
UsersStats
likelyLeaked (optional)
UsersStats
AllowlistIp Up
ip
String IP address to exclude. This will be either an IPv4 (e.g. 50.3.183.2) or normalized IPv6 representation (e.g.
2001:db8:0:0:1:0:0:1).
example: 192.10.20.0
mask (optional)
String [Optional] IP subnet mask to use for excluding a range of IPs. This is the number of bits to use from the IP
address as a subnet mask to apply on the source IP of incoming traffic.
example: 24
desc (optional)
String Description of the IP/subnet.
example: My own IP to always allow
updated (optional)
Long Timestamp, in UNIX Epoch milliseconds, of the latest update of this entry. format: int64
example: 1632530998076
DeviceStats Up
failed logins (optional)
Long Failed logins in last 24 hours. format: int64
fingerprint (optional)
String Client fingerprint.
leaked credentials (optional)
Long Number of leaked credentials used to login in last 24 hours. format: int64
risk (optional)
String Probability that this event was part of an attack, as computed post-factum.
Enum:

LOW
MEDIUM
HIGH
successful logins (optional)
Long Successful logins in last 24 hours. format: int64
Endpoints Up
String The endpoint ID
url (optional)
String URL configured for this endpoint
username (optional)
String Username parameter configured for this endpoint
password (optional)
String Password parameter configured for this endpoint
Evaluation Up
risk factors (optional)
array[String] Additional risk factors contributing to the total risk score.
type (optional)
String Type of login evidence.
reputation (optional)
array[String] IP reputation as classified by the proxy.
Evidence Up
request (optional)
Request
deviceStats (optional)
DeviceStats
evaluation (optional)
Evaluation
EvidenceRequest Up
piiPassword (optional)
String Specify the PII password used to encrypt login information. If not specified, the user names will be hashed or
encrypted.
Long Optional: Specify the endpoint ID you would like to fetch information for. If not specified, all endpoints would be
used. If no endpoint ID is supplied, the default will be all endpoints. format: int64
start time (optional)
Long Specify the timestamp, in UNIX Epoch milliseconds, from which events are retrieved. format: int64
end time (optional)
Long Specify the timestamp, in UNIX Epoch milliseconds, to which events are retrieved. format: int64
range in hours (optional)
Long Specify the range, in hours, for which events are retrieved. If specified, range will be used. If not specified,
startTime and endTime will be used instead. format: int64

example: 24
LikelyLeakedEvidence Up
user (optional)
String The username, if the PII password was specified, or a hashed/encrypted form of the username if the PII
password was not specified or does not match.
ip (optional)
String IP address from which the login attempt was made. This will be either an IPv4 (e.g. 50.3.183.2) or normalized
IPv6 representation (e.g. 2001:db8:0:0:1:0:0:1).
request time (optional)
Long Timestamp, in UNIX Epoch milliseconds, of the login event. format: int64
LoginsTimeline Up
startTime (optional)
Long Starting timestamp in UNIX Epoch milliseconds from which this timeline data begins. format: int64
example: 1673624384997
intervalMs (optional)
Long Time interval between data points in milliseconds. format: int64
example: 300000
String The endpoint ID related to this login timeline.
example: 1616877031
timeline
map[String, RequestTimeline]
MitigationRequest Up
String Endpoint ID associated with this request.
lowAction (optional)
String Mitigation action configured for low risk requests - in UPPER CASE.
Enum:
NONE
CAPTCHA
BLOCK
TARPIT
mediumAction (optional)
String Mitigation action configured for medium risk requests - in UPPER CASE.
Enum:
NONE
CAPTCHA
BLOCK
TARPIT
highAction (optional)
String Mitigation action configured for high risk requests - in UPPER CASE.
Enum:
NONE
CAPTCHA

BLOCK
TARPIT
PiiConfigPassword Up
current (optional)
String Current password.
proposed (optional)
String Proposed password.
Request Up
request client (optional)
String Request client.
declared request client (optional)
String Declared request client.
request id (optional)
Long Request ID. format: int64
request session id (optional)
Long Request session ID. format: int64
request IP (optional)
String IP address from which the login attempt was made. This will be either an IPv4 (e.g. 50.3.183.2) or normalized
IPv6 representation (e.g. 2001:db8:0:0:1:0:0:1).
request time (optional)
Long Timestamp, in UNIX Epoch milliseconds, of the login event. format: int64
request path (optional)
String The login request endpoint path.
request country (optional)
String Country code where the login attempt was made.
referrer (optional)
String The URL of the referring page.
RequestTimeline Up
total (optional)
Long Total requests for the current time span selection. format: int64
example: 7944
prevTotal (optional)
Long Total requests for the previous time span selection. format: int64
example: 4532
data (optional)
array[Long] List where every value is the count of login requests for that time interval. format: int64
example: [5, 1, 0, 0, 0, 75, 2, 1, 0, 0]
SiteStatus Up
siteId (optional)
Long The Imperva website ID format: int64
websiteName (optional)
String The site name (URL)

example: mysite.com
isMitigationOn (optional)
Boolean The site mitigation status (true/false)
example: true
StatsRequest Up
start time (optional)
Long Specify the timestamp, in UNIX Epoch milliseconds, from which events are retrieved. format: int64
end time (optional)
Long Specify the timestamp, in UNIX Epoch milliseconds, to which events are retrieved. format: int64
range in hours (optional)
Long Specify the range, in hours, for which events are retrieved. If specified, range will be used. If not specified,
startTime and endTime will be used instead. format: int64
example: 24
StreamingOutput Up
SuspiciousSuccessfulEvidence Up
likelyLeaked (optional)
String
aggregators (optional)
String
suspiciousSuccessful (optional)
String
mitigated (optional)
String
leaked (optional)
String
TopSource Up
none (optional)
map[String, Long] Top source by type mapped to a count of requests with risk level "none". format: int64
low (optional)
map[String, Long] Top source by type mapped to a count of requests with risk level "low". format: int64
medium (optional)
map[String, Long] Top source by type mapped to a count of requests with risk level "medium". format:
int64
high (optional)
map[String, Long] Top source by type mapped to a count of requests with risk level "high". format: int64
TopStats Up
client (optional)
TopSource
country (optional)
TopSource
ip (optional)

TopSource
ipFingerprint (optional)
TopSource
reputation (optional)
TopSource
UsersStats Up
current total (optional)
Integer Total number of unique users for the the requested time span, as passed in the API model
"StatsRequest" format: int32
previous total (optional)
Integer Total number of unique users for the previous time span, as passed in the API model
"StatsRequest" (e.g. if time specified in API is 24 hours, then this will return for the previous 24 hours.
format: int32

Account Takeover Protection 2-27-2023

Uploaded by

Copyright:

Available Formats

You might also like

Account Takeover Protection 2-27-2023

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Account Takeover Protection 2-27-2023

Uploaded by

Copyright:

Available Formats

Account Takeover Protection