Stop a wave of abusive sign-ups

When a script signs up hundreds of accounts on your storefront, they share something: an email domain, the network they came from, or the name they give their servers. We look for that and raise it to your team as a pattern. From a pattern your team blocks what the accounts share, so new ones stop, and acts on every account that matches it in one bulk run.

An org admin passes the step-up check within the 10 minutes before a run that ends orders or accounts (Sign in to the staff console).

Every 5 minutes we count the accounts that signed up, and the free servers ordered, in the last hour. A value opens a pattern when enough different accounts share it:

We leave out the large mail providers, such as gmail.com and outlook.com, and a domain you allowed with a rule. A pattern with nothing new for 24 hours reads resolved, and so does a blocked one once its block has ended.

When a pattern opens on an email domain that none of your accounts older than 30 days uses, counting its subdomains, we block the domain for 24 hours at once and the pattern reads blocked. New sign-ups on it are refused while you decide (Blocked email domains). If a new wave arrives on the domain after that block has ended, we block it again for 24 hours. Each block we make is in your audit log as abuse.pattern.block, made by the system.

1. Open /staff/abuse, which is Abuse under People in the sidebar. The staff home page also lists open patterns and the domains we blocked automatically under Patterns to review, with when each automatic block lifts.
2. The Patterns tab lists open patterns. Each row shows the shared value and its kind, how many accounts shared it in the last hour and in all, and when it was first and last seen. Choose another status (blocked, dismissed, resolved or all) or one kind to narrow the list.
3. From a pattern's menu, choose View accounts to open the customer list filtered to its accounts, or View servers for their servers in every status.

From a pattern's menu, an admin chooses Block for 24 hours, Block with no end, or Dismiss for 7 days, and confirms. A block takes a reason if you want one, kept on the rule for the next person. Once a block has ended, the pattern says so and offers the block again.

• Blocking a pattern writes the rule its kind needs: the email domain, the network, or the server name. The API takes any number of hours, or no end.
• Dismissing a pattern closes it for 7 days, however many accounts share the value; the API takes 1 to 90 days. A rule it already has stays.

A blocked email domain refuses sign-ups and free orders. A blocked network refuses free orders from it, and a blocked server name refuses free orders that use it. Accounts that already exist keep working until you act on them.

A rule blocks or allows one email domain, network or server name on your storefront. The Rules tab lists your brand's rules and Coritan's, which apply to every storefront; you can read Coritan's but not remove them.

To add one, an admin chooses Add rule on the Rules tab and fills in:

• The kind: an email domain such as whateverbro.com, a network such as 203.0.113.0/24, or a server name.
• The action. Block refuses the value. Allow keeps a domain out of patterns and out of automatic blocks, and makes a network count as a home connection. Count as VPN or hosting, for a network only, means a free order from it needs a qualifying Discord link (How free servers work).
• How long it lasts: 24 hours, 7 days, 30 days or no end.
• A reason, if you want one.

A network rule names at most a /8 (IPv4) or a /16 (IPv6). Remove, in a rule's menu, takes one of your brand's rules away.

A bulk run applies one action to every account or server a filter matches, up to 20,000 at a time, and works through them in the background, 100 at a time. It takes the same filters as the customer list and the server list, and a pattern as a filter. For an email-domain pattern that is the accounts on the domain and its subdomains that signed up no more than 30 days before the pattern was first seen, so long-standing customers on the same domain are left out. For the other kinds it is the accounts that made the pattern.

1. Open the accounts: View accounts on a pattern, or filter /staff/customers yourself, for example by email domain and sign-up date. The same steps work on /staff/servers.
2. Tick the whole page, then choose Select all matching customers in the bar at the bottom. The bar then counts every match. When every match fits on one page, the bar offers no such choice: the action then applies to the ticked accounts at once, without a run.
3. Choose the action in the bar. On customers that is Suspend servers, Unsuspend servers, Terminate servers, Pause accounts or Ban accounts. Pausing suspends the account and every order on it and ends its sessions; unsuspending the account on its page brings it back. Banning ends its sessions and ends every order it has.
4. In the dialog, check the action and enter a reason. Opening a ticket for each customer, and for a termination the cancellation email, are off unless you turn them on. An admin can add a deletion date to a suspension.
5. Confirm. To terminate, pause or ban, type the phrase the dialog shows, which names the action and the count, such as pause 9876 customers.

The progress dialog shows how many the run has worked through, applied and skipped. Cancel run stops it before its next 100; what it already did stays done. Every run and its progress stays on the Abuse page's Bulk runs tab.

Through the API:

1. Ask how many the filter matches with POST /staff/abuse/bulk-runs/preview.
2. Start the run with the same filter, that count as expected_total, the action and a reason. The actions are suspend and unsuspend (the orders), terminate (end the orders), pause (suspend the account and its orders, which ends its sessions; unsuspending brings it back) and ban (ban the account, which ends its sessions, and end its orders).
3. Follow its progress with GET /staff/abuse/bulk-runs/{uuid}, and stop it with POST /staff/abuse/bulk-runs/{uuid}/cancel. What it already did stays done.

A run opens support tickets and emails customers only when you ask it to. Each member may start 6 runs an hour.

curl -X POST "https://api.coritan.com/api/v1/orgs/acme/staff/abuse/bulk-runs/preview" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"target": "customers", "filter": {"email_domain": "whateverbro.com"}}'

The answer holds total. Start the run with it:

curl -X POST "https://api.coritan.com/api/v1/orgs/acme/staff/abuse/bulk-runs" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"target": "customers", "filter": {"email_domain": "whateverbro.com"}, "expected_total": 9876, "action": "pause", "reason": "Bot sign-ups"}'

GET /staff/abuse/patterns lists patterns, with status set to open, blocked, dismissed, resolved or all. POST /staff/abuse/patterns/{id}/block takes hours (or null for no end), and POST /staff/abuse/patterns/{id}/dismiss takes days. GET, POST and DELETE /staff/abuse/rules list, add and remove rules.

409 with selection_changed

The filter matches a different number of accounts than you sent, usually because more signed up. total in the answer is the new count; check it and start the run again.

422 with selection_too_large

More than 20,000 match. Narrow the filter, for example by sign-up date.

422 with invalid_filter

A run needs at least one filter that narrows the list, so it never acts on your whole storefront by accident. all as a status or an audience, and a search of only *, narrow nothing.

403 Ending orders or accounts, or pausing them, needs an org admin

Ask an org admin to start the run.

• Look after customers
• Manage customer servers
• How free servers work