Overview
Castle exposes a number of signals in the API response body: A list of potentially risky properties and behaviors that were detected on the event.
Example API response
{
"action": "deny",
"scores": {
"account_abuse": {
"score": 0.67
},
"account_takeover": {
"score": 0.77
},
"bot": {
"score": 0.34
}
},
"signals": {
"bot_behavior": {},
"proxy_ip": {},
"disposable_email": {},
"multiple_accounts_per_device": {}
},
// ...
}
That is, this event originated from a proxy IP address (proxy_ip
) where the device information indicates that the event was scripted (bot_behavior
) and there are many different accounts in use on the device the event was sent from (multiple_accounts_per_device
). Also, the user's email address is from a domain commonly used to create one-off addresses (disposable_email
).
Note: This feature is enabled for environments created after April 19, 2021. Please contact Castle support if you would like to enable this feature for environments created before this date.
List of signals
Automated activity
Name | Description |
---|---|
| Castle detects bot like behavior by analyzing several factors, including keystroke and mouse movements, how the user interacts with the application, repetitive event sequences and IP-reputation. Bot behavior can be an indication of all sorts of unwanted behavior, including fake account creation, testing of stolen credit card numbers and credential testing, but also more benign behavior like integration testing using browser automation software. |
| Castle continuously monitors all traffic to detect patterns and isolate requests that are sent as part of a credential stuffing attack. Due to the nature of credential stuffing attacks, analysis of the failed logins is an essential part of the detection. Credential stuffing is an automated type of attack in which stolen account credentials, in particular e-mail addresses, are used to gain unauthorized access to user accounts. Credential stuffing attacks, unlike credential cracking, do not attempt to guess any passwords with brute force, but rather leverage a list of leaked credentials. |
| This signal is a strong indicator of automated attempts, in which the attacker is either repeating the same email pattern or submitting completely random emails, typically during registration. The email provider may still be legitimate and non-disposable. |
| This signal learns what is typical behavior for a user account and then detects anomalous bursts of requests. This is often correlated with automated attacks or abuse. |
| This signal learns what is typical behavior for a device and then detects anomalous bursts of requests. This is often correlated with automated attacks or abuse. |
| This signal learns what is the typical rate of traffic coming from IP addresses and then detects anomalous bursts of requests. This is often correlated with automated attacks or abuse. |
Anomalous behavior
Name | Description |
---|---|
impossible_travel | This is triggered by comparing the user's current location with their last known location and then detecting trips that are highly unlikely, or even impossible, given the time between the two events. This signal correlates with man-in-the-middle attacks, account takeovers, and offshore attacks. |
multiple_accounts_per_device | The device, from which this event originated, has been used to log into multiple user accounts. This could indicate account abuse or promotion abuse. |
Device data error
Name | Description |
---|---|
missing_device_data | The data forwarded from the device to the server is empty. This is possibly due to an attacker attempting to bypass the client-side analysis, however, it could also be due to a misconfigured integration. |
invalid_device_data | The data forwarded from the device to the server could not be interpreted, most likely due to a replay attack or request tampering. |
replayed_device_data | This signal triggers whenever the device data collected by Castle has been re-used, which can be an indication of a script or bot. Developer note: $attempted and $succeeded (or $failed ) status events are usually sent to Castle within the same request. The same request token will be valid for both of these. |
Device intelligence
Name | Description |
---|---|
spoofed_device | There is evidence that the request is not coming from a genuine device but that the device parameters have been changed or are fabricated. This includes using a device emulator that mimics the entire client context of the device or simply changing the user agent string in the browser. |
headless_browser | A headless browser is a browser that can be used without a graphical interface. It can be controlled programmatically to automate attacks like web scraping, fake account registrations, and credit card testing. |
http_client_library | HTTP client libraries are used to send requests to an application with relatively little effort using a command line or a script. They are frequently used in less sophisticated but high-volume automated attacks and abuse. |
web_crawler | A web crawler is an application that searches and indexes documents on the Internet. It should be considered abnormal if an authenticated user is claiming to be a web crawler. |
carrier_ip_country_mismatch | This signal will trigger if there is a mismatch between the IP country and the mobile carrier country, and they are not neighboring countries. |
missing_headers | The HTTP headers typically sent by web browsers are missing, which can be an indication that the request was initiated by a script. However, in case you see this signal on the majority of requests, it could be due to a misconfigured integration. See API Reference for the details. |
timezone_area_mismatch | The configured timezone area (continent) on the device is different from the one indicated by the IP location. This could be an indication of using a proxy. |
Email intelligence
Name | Description |
---|---|
| Castle checks the email domain against lists of known disposable email providers. A disposable email domain indicates that the email address was issued by a service that issues temporary inboxes that expire after a short period of time. Examples of these providers are Mailinator, TempMail, and Guerrilla Mail. |
| An unreachable email indicates that the email domain does not exist or does not accept incoming emails. It is a strong indicator that the email cannot be verified. You can use this signal to:
|
| An email address that does not conform to internet email standards, or which does not exist on the recipient's server. Examples include addresses without the @ sign, addresses that include certain special characters and/or spaces, or failed SMTP authentication attempts. |
| This signal triggers whenever signs of randomness or profanities are found in the email. This typically means that the user signed up without a serious intent to use the service. |
| Triggers when there are variations of the same email address, e.g. [email protected] and [email protected] |
IP intelligence
Name | Description |
---|---|
abuse_ip | An IP address that was recently found in one of many publicly accessible abuse and spam databases. |
datacenter_ip | An IP address belonging to a hosting provider, data center, or content delivery network can serve to provide anonymity, as well as be used to launch large-scale automated fraud campaigns. |
proxy_ip | Proxy servers are used to mask the true location of a device. This signal identifies requests coming from proxy servers both by running the IP address against lists of known proxy IPs and by identifying timezone and timing anomalies that indicate that the traffic was routed through a proxy server. |
tor_ip | Tor anonymizes internet traffic and is frequently used by fraudsters to conceal their true location. A Tor IP is an IP address that matches an entry in Tor's official list of exit nodes. |
Novel user attributes
Name | Description |
---|---|
new_country | This signal triggers when a user account was accessed from a new country. It only triggers once per user and country combination. It does not trigger for the user's first country. |
new_device | This signal triggers when a user account was accessed from a new device. It only triggers once per device and does not trigger for the user's first device. |
new_device_type | This signal triggers when a user account was accessed from a new device type. It only triggers once per user and device type combination. It does not trigger for the user's first device type. |
new_isp | This signal triggers when a user account was accessed from a new Internet Service Provider. It only triggers once per user and ISP combination. It does not trigger for the user's first ISP. |
new_language | This signal triggers when a user account was accessed from a device using a new language setting. It only triggers once per user and language combination. It does not trigger for the user's first language. |
new_os | This signal triggers when a user account was accessed from a new Operating System. It only triggers once per user and OS combination. It does not trigger for the user's first OS. |
Updated about 2 months ago