Prevent or mitigate telephony-based fraud

International revenue sharing fraud (IRSF)—often referred to as toll fraud—is the use of a telecommunications product or service without the intent to pay for that product or service. This type of fraud most often involves attackers who use a phone system to generate a high volume of international calls on expensive routes. Because toll fraud can be costly and interfere with business operations, the topics in this section provide recommendations and best practices for toll fraud mitigation.

People involved in a toll fraud attack make calls to premium-rate numbers and take a cut of the revenue generated from these calls. Because the costs associated with the fraudulent calling activity are charged back to the customer by the telecommunications provider, it is important to take steps to prevent or minimize the chances of an attack succeeding.

Toll fraud attacks can take many forms, but most typically involves involve telephony services in countries that have expensive calling rates, such as Latvia, Somalia, and Gambia. If your organization does business with customers or suppliers in countries with expensive calling rates, you should be aware of the risk and cost of toll fraud attacks and how attacks might affect traffic from legitimate users.

Before you begin

You should review these recommendations and best practices if any of the following apply to your organization:

• You are using Voice OTP or SMS OTP for multifactor authentication.

• You have enabled self-service registration on one or more of your Okta orgs.

• You use an Okta-hosted or a custom Sign-In Widget for any of your Okta orgs.

• You are using the Okta Authentication API or the Factors API for telephony use cases.

• You have enabled a custom user provisioning or self-service registration solution.

How vulnerable is my Okta organization to toll fraud?

Your Okta organization might be vulnerable to toll fraud attacks if the organization allows certain activities. For example, the organization might be vulnerable to toll fraud attacks if you have set up authentication to allow the following conditions:

• You allow users to self-register without requiring strong proof of their identity. This might be the case if you have custom user provisioning or self-service registration solutions enabled on your org.

• You allow Voice or SMS as authentication factors for registration or sign-in activity.

If your organization supports any of these features, people seeking to commit fraud can abuse account creation or sign-in activity, then initiate Voice MFA calls to expensive countries by providing fake phone numbers.

You should note that Okta always enforces back-end Voice MFA security measures. However, to give your organization flexibility, Okta does not impose any specific business logic for account creation. Therefore, Okta does not enforce identity proofing or the deactivation of potentially malicious users by default.

While Okta continuously improves the tools available to help mitigate toll fraud attacks, you should follow the recommendations in this article to protect your organization.

Why you should protect your organization from toll fraud attacks

There are many practical reasons you should try to protect your organization from toll fraud attacks. For example, toll fraud attacks create fake accounts on your service. A proliferation of fake accounts might result in:

• Higher operational costs required to identify and remove fake accounts.

• Devaluation of your user base and the reliability of your user information, including non-quality leads, users that will never visit your site again, lowered engagement with your service, higher cost to acquire new users.

• Fraudulent selling activity (if applicable).

• Blocking of legitimate traffic by providers if sender numbers are identified as generating low engagement communications.

The results of a toll fraud attack can lead to negative consequences, such as:

• High volumes of toll traffic might result in delaying or preventing the delivery of Voice and SMS messages for legitimate users.

• Providers blocking numbers from certain countries might result in blocking SMS and Voice delivery to legitimate accounts.

• Increased costs for usage above the purchased contract aMAU count and for using telephony APIs.

How Okta mitigates toll fraud on your behalf

Okta has implemented the following measures to mitigate the impact of toll fraud:

• Service cap for SMS and Voice traffic

  If your Okta organization hits the service cap limit, all Voice and SMS MFA traffic is blocked for the org for 24 hours. If this occurs, the recipients making the requests receive an HTTP 429 error message.

• Per-user Voice and SMS rate limits

  Per-user voice and SMS enrollment rate limits are enforced to prevent a single user from flooding your org with malicious calls.

• Alerts during an active attack

  The Okta support team will notify you if there is an active toll fraud attack on one or more of your Okta organizations.

Steps you can take to mitigate toll fraud

There are several steps you can take to mitigate toll fraud attacks. Okta recommends that you review and implement these steps to protect your organization from toll fraud activity and mitigate the effects caused by toll fraud attack.

Use network zones to block malicious traffic pre-authentication

If you are aware of known malicious IP addresses attempting to access your Okta org(s), you can use network zones to block traffic pre-authentication. Blocking traffic before authentication prevents attackers from accessing your Okta sign-in and registration pages if the attempt is initiated from an IP or network identified in your network zone policy.

To learn more about blocking access pre-authentication, see:

• Create zones for IP addresses

• Create a dynamic zone

Disable Voice MFA or control Voice MFA per group

If you do not need Voice MFA enabled for any user in your Okta org, you can deactivate it using the Admin Console. The specific steps for removing Voice as a factor for authentication depend on whether you are using Okta Classic or Okta Identity Engine.

For more information about removing Voice from your multifactor authentication policies as an Okta administrator, see Configure the phone authenticator.

If you do need Voice MFA, do not allow enrollment for new accounts until some form of identity proofing has been completed to ensure that the account is not fraudulent.

If you will never require Voice MFA for your Okta organization, you can contact Okta support to disable this feature entirely.

Check your user provisioning methods

If applicable, Okta recommends that you reevaluate how you create and provision user accounts to determine if additional security measures might prevent fake accounts from being created. For example, consider adding the following security methods to your exisiting account creation and provisioning methods:

• Block account creation from known or potentially malicious geographic locations

• Validate user registration using email-based verification

• Integrate with identity proofing tools to determine if the email address may be coming from a fake domain

• Implement rate limiting on custom registration pages to stop fraudsters from generating fake accounts in large volumes

• Deactivate fake users on your org to prevent fraudsters from rotating through the fake accounts to generate calls

Monitor malicious activity and deactivate bad actors

The following query illustrates how you can monitor suspicious voice activity in the Okta System Log.

1
2
3
4
5
6
7
event_type="system.voice.send_phone_verification_call"
    stats count values(client_geographical_context_country) 
    as Country dc(target1_alternate_id) 
    as unique_count_phone_numbers 
    by actor_alternate_id, client_ip_address, client_user_agent_raw_user_agent
    where count > 20
    table actor_alternate_id, client_ip_address, client_user_agent_raw_user_agent, Country, unique_count_phone_numbers

Note these fields are also available when using the Okta Identity Cloud Add-on for Splunk.

This query checks the field system.voice.send_phone_verification_call and analyzes if the count of the combination of User, IP Address & User Agent is greater than a certain threshold (in this example, where the count greater than 20). You can set the threshold depending on the time frame of the search. If the search is run every hour, you can set the threshold to a value that is higher than the benign activity during the hour.

This sample query uses the following fields:

Based on the output returned by the query, you can identify and delete any bad actors or fake users in your org.

Contact Okta Support to receive a list of allowed countries

If you are confident in the specific list of countries servicing your customers and would like to block voice MFA calls to all other countries, contact Okta Support. Okta Support can block all countries to which there should be no voice MFA traffic.

You can also contact Okta Support to modify the rate limits on your organization. If you are experiencing increased toll fraud attacks or an increase in the creation of fake user accounts, Okta Support can work with you to create strict rate limits on voice and SMS enrollment endpoints, decreasing the frequency of new accounts that can be created on your org.

Integrate with identity proofing solutions for new account creation

You can enable user self-verification through document-based or knowledge-based proofs to improve identity confidence and approve access for authorized individuals. See Identity Proofing to learn more.

If you have any additional questions on toll fraud, contact Okta Support.

Related topics

Telephony

Configure and use telephony

Connect to an external telephony service provider

Regulatory compliance