Skip to content
NewCybercrime Report 2026 · Eight Chapters · A Post Is Not An Incident → Explore The ChaptersCybercrime Report 2026 → Explore

Account Buyer Rate Sheets: What They Ask Suppliers For

Account buyer rate sheets require 2FA secrets, cookies and friend counts. Rate pairs differ; the secret column suggests supplier enrolment.

By
Brandefense Research Team
Published
9 November 2026
Reading time
8 min read
Chapter 04 of 08Web editionEdition 1.0Open the chapter report

On 15 April 2026 a Bengali-language post listed three Facebook account and cookie products. The first paid a members rate of 12.00 tk, 12.50 tk from 100 IDs and 13.00 tk from 300.

The third product, accounts registered with a phone number, zero friends and 2FA, carried a members rate of 5.5 tk. An admin rate was available by message (SC-O011). The poster was buying, and account buyer rate sheets like this read as purchase orders.

Buy-side submissions are 17.0% of the Botnet Log class in our hand-read sample (95% interval 11.1 to 23.0, 160 posts), and the main investigation covers the wider mix. This article asks a narrower question: what do the sheets ask suppliers to hand over, and which of those attributes actually move the rate?

What 69 Hand-Coded Sheets Require of Suppliers

We coded a hand-read sample of 69 distinct buy-side texts, drawn from 371 candidates. Of these, 31 are multi-product rate sheets and 28 are single-product rate posts, so 59 state rates. The other ten are submission notices or requests without rates. The shares below are of those 59, with 95% intervals:

  • A 2FA secret as a required column in at least one product: 47.5% (35.3 to 60.0). A cookie column: 57.6% (44.9 to 69.4).
  • A friend or follower count specified: 66.1% (53.4 to 76.9). A sign-up route, by number or any mail: 45.8% (33.7 to 58.3).
  • A report time or acceptance percentage: 57.6% (44.9 to 69.4). Separate admin and member rates: 37.3% (26.1 to 50.0).
  • Volume tiers by batch size: 20.3% (12.0 to 32.3).

A sheet therefore specifies the secret, the session, the profile’s friend count, its sign-up route and how fast it must be reported. These count distinct texts, not suppliers.

The cleanest test is a same-sheet pair: one sheet prices two variants of the same base product that differ only in the 2FA field, the cookie field or both. Nine of the 31 multi-product sheets contain such a pair, 11 pairs in all. In seven pairs variant A has cookies and B has 2FA, a swap; in the other four B adds a field to A. Rates are as written, in taka.

Base product Variant A Variant B B minus A
Facebook, number sign-up cookies 4.20 2FA 4.80 +0.60
Facebook, number sign-up cookies 5.30 2FA 6.00 +0.70
Facebook cookies 4.0 2FA and cookies 4.5 +0.5
Number sign-up, zero friends cookies 4.50 2FA 5.50 +1.00
Number sign-up, zero friends cookies 4 2FA 5 +1
Number or any mail, zero friends cookies 5.20 2FA 5.20 0
Instagram cookies 4.00 2FA 3.80 -0.20
Hotmail, zero friends cookie 8.20 2FA 8.80 +0.60
Hotmail, zero friends cookie 6.80 2FA and cookie 7.30 +0.50
Hotmail, 30 friends 2FA 11.00 2FA and cookie 11.50 +0.50
Hotmail, 30-plus friends 2FA 15 2FA and cookie 19 +4

In nine of the 11 pairs the 2FA variant, or the variant with both fields, pays more. In one the two are equal and in one the Instagram 2FA line pays less.

Eight of the nine increases are 0.5 to 1.0 tk, and the median increase is about 13% of the lower variant (our calculation). That is a modest premium in this small set, close to the volume tier on SC-O011, where 300 or more IDs lifts 12.0 to 13.0 tk (8%).

Across the whole parsed set, taka unified, the stated rate per submitted ID is a median 3.5 for Instagram with 2FA (69 sheets) and 4.0 for Instagram cookies (15). For Facebook number or any-mail accounts it is 5.0 for cookies (104), 5.5 for 2FA (45) and 6.2 for both (7).

Friend count is associated with larger gaps across sheets. Hotmail or Outlook with zero friends sits at 8.0 to 8.5 (24 to 37 sheets per variant), against 11.5 to 13.5 for 30-plus friends (10 to 32).

A 5 October sheet fits this, listing rates of 16 tk, 10 tk and 3 TK. The selected rates do not isolate a country, name or reporting-time premium.

These are stated rates per submitted ID on the sheets, with the unit implied by the sheet wording. They show what posters say they pay, not market prices, and each median stays within its own product type.

Admin and Members Rates Point to a Layered Chain

Separate admin and member rates appear on 37.3% of rate posts. SC-O011 offers a members rate on the sheet and an admin rate by message. A 21 October post wants 100 zero-friend cookie files at 4.5 tk. It says samples go to a buyer for checking and claims a daily intake of ten thousand IDs if they pass.

The simplest reading is an intermediary between many small suppliers and an end buyer, with the lower member rate as the supplier-facing price. The acceptance wording supports it: 57.6% of rate posts state a report time or acceptance percentage, which puts the risk of a bad batch on the supplier. The alternative is that “admin” is simply the group owner’s own tier. Either way the text shows a layered chain and not who sits at its end.

Demand for lists reads differently. A combolist request (SC-O045) sets a “private only” condition, so this one request judges a list on exclusivity where account sheets judge on attributes. A Russian-language buy-up advert (SC-O014) shows no rates. A single selected advert does not establish repetition or how many buyers exist.

Who Enrolled the Second Factor?

Three readings fit the sheets: bulk-registered accounts, accounts taken from their holders and then re-secured, and resold aged accounts. Of the 69 texts, 75.4% (64.0 to 84.0) say nothing about origin. Six give naming or registration rules, three use creation wording and four ask the supplier to live-check an account before submitting. Four more give a method pointer or a buyer-check line.

The 2FA column helps to choose between them. A time-based authenticator seed is created when the account holder enrols, and a thief who takes over an account generally cannot read the victim’s seed.

A sheet that makes the secret a required column therefore fits supplier-enrolled accounts better than accounts handed over as found. The supplier may have enrolled the factor at registration or after taking the account. That is the stronger reading, not a fact. It would weaken if a sheet asked for an original seed or paired a theft claim with the column.

SC-O018 shows only demand for the cookie step: the poster supplies a login and wants the cookie string within an hour.

What Should Platform and Identity Teams Look For?

If the valuable object is a profile with its own second factor and a session, the useful signals sit in enrolment and session behaviour. The first follows directly from the required columns; the second combines coded cues with the bulk-registration reading; the third uses mailbox-recovery background.

  • A second-factor enrolment and a long-lived session followed shortly by use from a different network and device. This follows from the 2FA and cookie columns, and it holds under every reading. NIST’s SP 800-63B-4 describes timeouts and reauthentication for this surface.
  • Bursts of new accounts with zero friends registered by one route. This follows from the friend-count (66.1%) and sign-up route (45.8%) cues, and it fits only the bulk-registration reading.
  • Mailbox accounts with 2FA, which hold the higher rates when the friend count is higher. A mailbox often sits in recovery chains for other services, which is background knowledge and not from our data.

None of these proves theft, and the sheets do not address enterprise mailboxes. They do suggest that, on accounts like these, the second factor is part of what the supplier hands over. If that reading holds, its presence tells a platform little about who now controls the account.

Our account takeover lifecycle guide shows where a transferred account sits in the attack, and the write-up of session hijacking and cookie theft covers the defender side. Dark Web Monitoring is where posts like these are tracked. For the other side of the trade, see how credential list subscriptions are priced.

Method and Scope

Why AI agents. Brandefense Blackhole, our cybercrime database, collects around 17 to 23 million dark web and Telegram posts a month. Reading that volume by hand, and linking a recruitment ad on one forum to a leak-site claim on another and a price list in a Telegram channel weeks later, is beyond what a human team can do alone.

Claude Opus 5.5 prepared the research: it searched the data, sorted and translated posts and drafted the text. Codex Astra then checked every number against the dataset files and tested each claim, and anything that did not hold was removed.

Brandefense analysts reviewed and approved the findings.

Scope: Telegram-dominated posts, 1 January to 27 October 2026, counted as distinct texts, not buyers or suppliers. Classifier recall for wanted posts is about 0.6, so classifier counts may miss buy-side posts. We use the hand-coded sample to describe their share; recall alone does not establish a lower bound.

Parsed medians can include wrong splits, and catalogue records are selected examples. See the full methodology and the Stolen accounts research hub.

Share this articleLinkedInXEmail
Brandefense logo

Stay Ahead of Digital Threats.

Take control of your digital security with an exclusive demo of our AI-driven threat intelligence platform.

Open The Full Demo Form →