N0n, a data-extortion group whose leak site ZeroFox first observed on September 21, 2026, listed Fanatics Inc. on September 20. Fanatics is headquartered at 8100 Nations Way in Jacksonville, though it also runs offices in New York, San Mateo, and Tampa. The listing claims 108 GB across 46,902 order files, plus accounts-payable, customer-balance, bank-transaction, tax-exemption, and fraud-prevention records — figures the group itself supplied and a breach tracker repeated, not an independently verified count. Fanatics has not confirmed the claim, and as of this writing no filing or outside reporting corroborates it. A leak-site post is published on the attacker's schedule, before anyone outside the group has checked it — that's true whether or not this one holds up.
The claim nobody can check from outside
What distinguishes N0n from the half-dozen extortion crews that launched this autumn, per ZeroFox's September 29 flash report, is "its threat to encrypt or delete data backups." The same report immediately qualifies it: "it is unclear whether n0n is able to access victim data backups." In its first 24 hours online the group claimed more than a dozen victims, and technology and professional services together account for 46 percent of its targeting since.
That gap between the stated threat and the demonstrated capability can't be closed from outside the group's own infrastructure. Nobody reading a leak-site post gets to know whether the deletion claim is real. What every reader can know this week is whether the same deletion would succeed if it came from inside their own network — because that test doesn't depend on N0n's tooling at all. It depends on which identities in your environment can reach the backup repository, and what happens when one of them tries.
Test the deletion path, not the vendor's claim
Run the first check from a standard user account, not an admin session: attempt to authenticate to the backup console or API with ordinary domain-user credentials. Most backup platforms tie delete rights to a role rather than to password strength, and the role is frequently nested inside a domain group that was built for an unrelated purpose. If a phished user's existing group membership reaches that role without anyone granting it explicitly, that's the finding — not a hypothetical.
Second, have whoever administers backups show you, live, what happens when a deletion is requested against a copy that's supposed to be locked. "Retention lock" means one thing when it's enforced by the storage layer — object lock on immutable storage, a true WORM target — and a weaker thing when it's a policy setting inside the backup software that an administrator credential can simply uncheck. If the answer to "what happens" is a policy document instead of an access-denied error on screen, the backup is discouraged, not protected.
Third, check what the "offsite copy" actually is. A replication job that mirrors deletes along with writes will carry a delete command to the second copy on its next sync, which erases the reason to have a second copy at all. Confirm the replication is one-way and lagged, or that the downstream target sits on retention-locked storage that won't accept a delete command from the replication service account in the first place.
None of this is free to run. Testing deletion against production backup infrastructure risks actually deleting something, so it has to run against a disposable job or a staging repository, and pulling a backup administrator into a live walkthrough costs their time and probably a change ticket. That cost is real. It's still smaller than learning the lock was a setting after an incident, when the people who could answer these questions are rarely the ones who get asked first.
What to check this week
- Which identity holds delete rights on your backup repository, and is it reachable through any group membership a standard user could already have?
- Is retention lock enforced by the storage layer, or by a software policy a privileged credential can change?
- Does your offsite or secondary copy accept delete and overwrite commands from the same service account that writes to primary storage?
- Have you watched a deletion attempt actually fail against a locked copy, or only read that it would?
- If you monitor leak-site aggregators for your company's name, add a second watch for your sector plus state. On October 11, N0n posted three listings reading "architecture & design · Florida, USA" with a publication deadline of October 14 at 12:00 UTC — almost certainly one firm counted three times, and with no company name anywhere in any of them. Name-based monitoring would never surface it.
North InfoSec runs AI-assisted penetration testing and security assessments, including identity and access reviews of backup and recovery infrastructure. northinfosec.com