Credential Stuffing and Brute Force Against Magento Admin and Customer Accounts

What it is

Credential stuffing and brute force are the two automated password attacks that never stop hitting Magento's two authentication surfaces: the Admin sign-in and the storefront customer login at /customer/account/loginPost. They look alike in an access log but are mechanically distinct. Brute force is vertical — many password guesses against one known account. Credential stuffing is horizontal — one or two guesses each against tens of thousands of accounts, replaying username/password pairs harvested from unrelated third-party breaches (combolists) on the bet that customers reuse passwords. The distinction matters because Magento's native defence, per-account lockout, is built for the first pattern and structurally blind to the second.

Root cause

On the storefront the root cause is external: the credential has already leaked somewhere else, so nothing about the Magento account has to be weak for the pair to work. On the Admin the root cause is exposure plus lax controls — a predictable /admin path, a low-entropy or shared admin password, and lockout thresholds left at defaults.

Magento does ship account lockout for both surfaces. Admin lockout defaults to six failures (admin/security/lockout_failures) before the account is locked for a configurable number of minutes (admin/security/lockout_threshold); the storefront has the equivalent under Customer Configuration. But the counter is per account. An attacker who sends a single attempt to each of 50,000 accounts trips nothing — every account records one failure and resets. Rotate the source across a residential proxy pool and per-IP counters fall the same way. Per-account and per-IP lockout together do not constrain low-and-slow horizontal stuffing.

How attackers abuse it

The tooling is commodity: OpenBullet/SentryMBA-style configs, combolists sold by the million, and rotating residential proxies that give each request a fresh consumer IP. Bots enumerate installs by hitting default admin paths and the standard storefront login endpoint, then run in two modes.

• Storefront stuffing. A POST loop replays a combolist against loginPost, one pair per account. A hit yields saved addresses, full order history, stored gift-card and loyalty balances, and — because the password was reused — frequently the victim's email account too, which is where recovery and refund fraud begin.
• Admin brute/spray. A dictionary or password-spray run against the admin path. A single success is total store compromise: skimmer injection into checkout, customer-data export, malicious admin user creation.

reCAPTCHA on the form and per-account lockout are both evaded by single-attempt pacing and IP rotation; token-solving services defeat CAPTCHA outright on high-value targets.

Who got hit / real examples

There is rarely a named "Magento breach" headline for this class because the compromise happens one account at a time and surfaces later as refund fraud, loyalty-point theft, or a card skimmer. The scale is documented at the industry level: credential stuffing and account takeover are consistently ranked among the most common automated attacks against retail, with attackers running huge volumes of loyalty-account attempts at near-zero marginal cost (HUMAN Security). Adobe's own response is the strongest signal of the Admin-side risk — two-factor authentication was made mandatory and non-optional on the Admin from Magento 2.4, precisely because admin account takeover via guessed and reused passwords was a recurring root cause.

How to check

Both attacks are loud in aggregate even when quiet per account. On the storefront, look for a high volume of POSTs to loginPost spread across many distinct usernames from few IPs (concentrated stuffing) or few attempts per account from many IPs (distributed stuffing). A skewed success ratio — many 302 redirects back to the login form (failures) interspersed with occasional post-login 302s to the account dashboard — is the tell.

grep 'POST /customer/account/loginPost' /var/log/nginx/access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -30

Cross-reference with request rate per minute and User-Agent diversity: a single UA string across hundreds of source IPs is automation. On the Admin, review failed-login and lockout events, and confirm the admin frontName is not the default.

How to fix it

No single control stops stuffing; layer per-account lockout, a friction control on the form, and rate limiting at the edge where per-account counters cannot see the campaign shape.

1. Tighten Admin controls. Keep 2FA mandatory, use a non-default admin path, and lower the lockout tolerance.

bin/magento config:set admin/security/lockout_failures 3
bin/magento config:set admin/security/lockout_threshold 30
bin/magento config:set admin/security/use_case_sensitive_login 1
bin/magento setup:config:set --backend-frontname="admin_$(openssl rand -hex 4)"
bin/magento cache:flush

2. Enable Google reCAPTCHA on every auth form — Admin sign-in and storefront login, create-account, and forgot-password (Stores > Configuration > Security > Google reCAPTCHA). Prefer the invisible/score-based mode so legitimate users are not challenged.
3. Rate limit at the edge, not just per account. This is the only layer that sees the campaign. Cap loginPost and the admin login by IP and by ASN, and hard-challenge datacenter and known-proxy ASNs, since real shoppers do not log in from cloud ranges.

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /customer/account/loginPost {
    limit_req zone=login burst=3 nodelay;
    # proxy_pass to the Magento upstream as usual
}

4. Break the reuse chain. Screen new and changed customer passwords against a breached-password corpus (for example the Pwned Passwords range API) so a credential known to be in a combolist cannot be set. Raise the minimum length and required character classes above defaults.
5. Offer customer 2FA / passwordless for high-value accounts. Stored-value accounts are worth the friction.