You're not going to believe this, but turns out you can't always take criminals at their word. Actually, I'll walk that back a bit as it may not even be the cybercrime guys who got this wrong, but it all starts here:

🚨Cyber Alert ‼️

🇺🇸US - 𝗖𝗮𝗿𝗵𝗮𝗿𝘁𝘁

ShinyHunters hacking group claims to have compromised Carhartt and allegedly stolen more than 50 GB of compressed data containing millions of customer records, employee information, customer metadata, loyalty-related information, and… pic.twitter.com/BvzsEQS54l

— Hackmanac (@H4ckmanac) August 13, 2026

My usual Have I Been Pwned (HIBP) workflow after a breach emerges is to run our open source Email Address Extractor tool over the corpus of data, get a count of the unique addresses then drop it into the processing pipeline. Having a count helps prioritise: it's roughly the same effort to process a breach with 10M addresses in it as it is 100k addresses, but we obviously reach 100x more people with the larger corpus so that goes first. So, following the release of the Carhartt data above, I ran the tool and got 24,876,077 addresses. That's a biggy, let's dive in.

One of the first things I do when analysing a breach is look for news and industry commentary. Once you get through all the results for class actions (ugh), you usually find various other services and news sites reporting on the incident. One such example (which I won't name, because they're wrong) cited a very similar number to my initial pass, which at face value, reinforced my thinking. But here's where it all takes a turn because, inevitably, this is where the other analysts stopped...

I've been using OpenClaw pretty extensively this year to help with a number of tasks, including breach analysis. Here's how I normally begin (timestamps are AEST and yes, I called it "PwnedClaw"):

[24/08/2026 17:30] Troy Hunt: Let's look at the ShinyHunters Carhartt breach. I'm seeing nearly 25M unique email addresses so it's very large, tell me about what they do.
  
[24/08/2026 17:30] PwnedClaw: Carhartt is an American workwear brand founded in 1889, headquartered in Dearborn, Michigan. They make rugged, durable clothing primarily for tradespeople and outdoor workers: heavy-duty jackets, bibs, coveralls, work pants, boots, and accessories. Think construction workers, farmers, hunters.

They've also crossed over into streetwear/fashion in recent years (particularly through Carhartt WIP, their Work In Progress line), which massively expanded their demographic beyond blue-collar workers into urban fashion, skateboarding, and hip-hop culture. That crossover likely explains a 25M email count — they're not just selling to contractors anymore, they're a mainstream lifestyle brand.

Strong US base but significant global presence, especially in Europe where WIP is huge.

For HIBP context: broad demographic mix (blue-collar workers + fashion/streetwear), real names, physical addresses, and purchase history are likely present given it's a retail breach. Want me to pull the tracker entry for current status?

Ok, cool, nothing too revolutionary there. Let's start analysing the data, and the first thing I do is begin with the report of our open source Email Address Extractor tool, which lists every file an address was found in, and then how many unique ones are in there:

[24/08/2026 17:32] Troy Hunt: Let's start looking at data, and we'll begin with the email extractor report at "\scratch\Carhartt\Carhartt.txt.report.txt"
  
[24/08/2026 17:32] PwnedClaw: Interesting. The data is from Databricks (their analytics/data lakehouse platform) and follows the TPC-DS benchmark schema (tpcds_sf1000) — that's a standard retail analytics benchmark format. The "sf1000" means scale factor 1000, which is massive.

Key observations:

• All emails are in customer_chunk_XXXX.csv files, numbered 0000-0599+, so ~600 chunks
• Each chunk has ~19,300 unique emails, remarkably uniform distribution
• ~600 chunks × ~19,300 = ~11.6M from this directory alone — but you said ~25M total, so there are likely more directories

The TPC-DS schema is telling — it means this was Carhartt's customer analytics warehouse in Databricks, not their production transactional database. TPC-DS models: customer demographics, store sales, web sales, catalog sales, dates, etc. So the data likely includes purchase history and behavioral analytics on top of PII.

Want me to look at an actual chunk file to see what columns are present?

Think of it as using the AI to distil large volumes of information down into something much more workable. In this case, I gave it four of the files in question and let the analysis run:

[24/08/2026 17:33] PwnedClaw: The columns from the TPC-DS customer table:

• c_customer_sk / c_customer_id — internal IDs
• c_current_cdemo_sk — customer demographic key (links to demo table with age/gender/education/marital status/income band)
• c_current_hdemo_sk — household demographic key
• c_current_addr_sk — current address key (links to full address table)
• c_first_shipto_date_sk / c_first_sales_date_sk — date of first purchase/shipment
• c_salutation — Mr/Mrs/Miss/Sir etc.
• c_first_name / c_last_name
• c_preferred_cust_flag — loyalty/preferred customer flag
• c_birth_day / c_birth_month / c_birth_year — full DOB
• c_birth_country
• c_login — empty in the samples
• c_email_address
• c_last_review_date_sk / c_last_review_date

So: full name, email, DOB, salutation, birth country, preferred customer status, first purchase date. Address is a foreign key here (in a separate address table that's presumably also in the dump).

Notable: c_login appears empty — so no passwords in this table. DOB is split across three columns which is a bit unusual but all three are there. Birth year goes back to 1949 in the sample, so this spans a wide age range.

Want me to check how many rows have DOB fully populated, and whether there are other tables in the dump (address, demographics) in what you have locally?

I'll save you from all the to-and-fro of my questions and PwnedClaw's responses, here's where it gets interesting and where AI plays a genuinely valuable role:

[24/08/2026 17:41] PwnedClaw: TLD anomaly worth flagging:

• 4M .edu and 3.9M .org is extremely high for a retail brand. That's likely noise from the TPC-DS synthetic data generation mixed with real records, or it could indicate Carhartt ran promotions targeting institutions. Worth sanity checking a sample of those.

Want me to pull 20 random .edu and .org samples to see if they look real or synthetic?

Huh, yeah, that feels odd. Let's drill down further, and just a quick caveat: I'm highly confident that all the data I'm about to show is fabricated and that I'm not inadvertently putting someone else's PII on display here.

[24/08/2026 17:47] Troy Hunt: Give me some examples of what you consider synthetic addresses
  
[24/08/2026 17:48] PwnedClaw: From the earlier sample:

Clearly synthetic (TPC-DS generated):

• roy.griffin@mbfhz82d0vkpes4x.edu — random hex-like domain
• violet.day@ob7.edu — 3-char alphanumeric
• michael.ware@c.edu — single character domain
• manuel.baugh@p.edu — single character domain
• april.garza@r3zc1yf6i2lxfg.edu — random alphanumeric
• craig.hodge@nrvnrtanujylkigl.edu — random consonant string
• ted.walker@9q3ulo9h987zp.edu — starts with digit, mixed
• michelle.larue@lkvb06fkzsjv.org — random alphanumeric
• joel.maldonado@y8rlxnc.org — short random alphanumeric

The pattern is consistent: real-looking Firstname.Lastname local part (from TPC-DS customer name generation) grafted onto a completely random/gibberish domain. The local parts look plausible but the domains have no vowel patterns, random digit insertion, or are implausibly short (single characters).

The tell: TPC-DS generates customer emails by concatenating real name fields with random domain strings. So you get sally.smith@uea8muo3gx9udizg.edu — Sally Smith is plausible, but no .edu institution has that domain.

Want me to build a filter that identifies synthetic domains specifically (gibberish detection) and get a precise real vs synthetic split?

Oh yeah, that's definitely junk. It was enough for me to start trawling through the data myself, old-school, like I used to, well, before earlier this year! And that's where I found data like this:

c_customer_sk,c_customer_id,c_current_cdemo_sk,c_current_hdemo_sk,c_current_addr_sk,c_first_shipto_date_sk,c_first_sales_date_sk,c_salutation,c_first_name,c_last_name,c_preferred_cust_flag,c_birth_day,c_birth_month,c_birth_year,c_birth_country,c_login,c_email_address,c_last_review_date_sk,c_last_review_date
11270429,AAAAAAAANBJPLKAA,1423814,7001,19788,2451033,2451003,Miss,Marina,Tucker,Y,13,3,1968,BENIN,,Marina.Tucker@xgpgHqAu.com,2452499,2452499

It's the same sort of .edu pattern but not on a .edu TLD. First name, last name, random domain name. And "Benin"?! I'll save you Googling it like I had to, it's a small country in West Africa and if I'm guessing, not a major Carhartt market.

[24/08/2026 17:51] Troy Hunt: Yeah, something smells here, there are screwy domains in addresses like this too: Marina.Tucker@xgpgHqAu.com
  
[24/08/2026 17:52] PwnedClaw: That's a much bigger problem than I initially thought. The frequency analysis confirms it:

• 54.8% of addresses (13.6M) are at domains appearing 100+ times — these are real
• 45.2% (11.25M) are at domains appearing fewer than 100 times — and 8.4M of those contain digits

So the synthetic pattern isn't confined to .edu/.org at all — it's throughout .com and everything else too. Marina.Tucker@xgpgHqAu.com is the same TPC-DS generation, just with .com slapped on.

The 32% figure I gave you earlier was a significant undercount. The real split looks closer to:

• ~13.6M real addresses (domains with 100+ occurrences)
• ~11.25M synthetic (single-use gibberish domains across all TLDs)

That's roughly 45% junk across the whole corpus, not 32%.

For HIBP the headline number would be around 13-14M rather than 24.8M. Want me to produce a clean filtered list of just the real addresses for an accurate count?

And the more I probed, the more it all unravelled:

[24/08/2026 17:53] Troy Hunt: I want you to get a distinct list of all domains with a count next to each one showing how many addresses are on it. This is starting to smell bad.
  
[24/08/2026 17:54] PwnedClaw: Done. 10.35M unique domains written to:

scratch/Carhartt/domain-counts.txt

Format is countdomain, sorted by count descending. So the top of the file is gmail.com (http://gmail.com/) at 7M+, and the long tail is all the single-occurrence gibberish. Your HIBP domain dataset should make it very obvious where the cliff edge is between known-real and never-seen-before.
  
[24/08/2026 17:58] Troy Hunt: There's an extraordinary long tail of domains with only 1 address. Also look at the country of birth next to the add addresses; places like Myanmar, Latvia and PNG are just really odd in terms of likelihood.
  
[24/08/2026 17:58] PwnedClaw: That country distribution is damning. Here's what's wrong with it:

97.6% of domains appear exactly once — that's not a long tail, that's a signature. Real breach data from a retail company would have thousands of addresses on corporate domains, hundreds on ISP domains, a natural power law. Instead you have 10.1M singleton domains. That's pure TPC-DS generation.

The birth country data is the other nail in the coffin. Look at what's in those 4 chunk files:

• Venezuela, Nicaragua, Qatar, Montenegro, Lesotho, Gambia, Norfolks Island, Réunion, Comoros, Western Sahara, Palau...
• United States appears only 407 times — tied with Canada, both dwarfed by places like Antigua and Barbuda and Lesotho
• The distribution across 211 countries is essentially uniform — ~380-420 per country

That's textbook TPC-DS. It generates customer records with birth countries sampled uniformly from the full ISO country list. No real Carhartt customer database would have more customers born in Montenegro than the United States.

Bottom line: What you have here looks like real Carhartt customer records (the carharttdonotship.com, carhartt.com domains, the 70% HIBP hit rate on freemail addresses) that were stored in Databricks alongside TPC-DS benchmark data that was run against the same schema. ShinyHunters grabbed the whole Databricks dump without distinguishing real customer data from the benchmark test data sitting in the same tables.

The real customer data is in there, but it's heavily contaminated with synthetic TPC-DS records. Your domain frequency analysis from HIBP will be the cleanest way to separate them.

Annoying AI sentence structure aside ("that's not [one thing], that's [this other thing]"), this is just gold. And PwnedClaw gives ShinyHunters a bit of a free pass too: these guys just grabbed and published everything without realising there was a bunch of synthetic data in there. But there's one more smoking gun:

[24/08/2026 18:02] Troy Hunt: Also look at the distribution of birth year - there are way too many people with early 1900's entries, got any stats on that?
  
[24/08/2026 18:03] PwnedClaw: Birth year stats are conclusive. The distribution runs 1924-1992 and is perfectly flat — roughly 1,050-1,194 per year, every single year without exception. That's not population data, that's a random number generator with a fixed range.

A real Carhartt customer base would be heavily weighted 1965-1995, almost nothing pre-1950, and the pre-1924/post-1992 cutoffs wouldn't exist at all. Instead you get mathematically uniform coverage of 69 years. TPC-DS again.

Here's the full picture of what we now have as synthetic indicators — every single one points the same direction:

| Signal                        | Finding                                                          |
| ----------------------------- | ---------------------------------------------------------------- |
| Domain singletons             | 97.6% of domains appear exactly once                             |
| Synthetic TLDs                | 32% of addresses on .edu/.org with gibberish domains             |
| Gibberish .com domains        | e.g. Marina.Tucker@xgpgHqAu.com                                  |
| Firstname.Lastname pattern    | 50.4% — should be ~10-15% in real retail data                    |
| Birth country distribution    | Perfectly uniform across all 211 ISO countries, US = 407 records |
| Birth year distribution       | Perfectly flat 1924-1992, ~1,100/year                            |
| carharttdonotship.com         | Proves real Carhartt data IS present                             |
| 70% HIBP hit rate on freemail | Proves real records are mixed in                                 |

The conclusion is pretty solid: this is a real Carhartt Databricks breach, but the TPC-DS benchmark data was co-located in the same schema and ShinyHunters (and every aggregator after them) grabbed it all without knowing what they were looking at.

It would have been so easy just to dump this all into HIBP, put out social posts with a big headline number and be done with it, but it'd also be completely wrong. And here's what's really worrying about watching other people do exactly this: headline numbers get misrepresented, victim organisations are unfairly reported on (news headlines with the HIBP number often follow quickly), I run the risk of attracting the ire of the company for inaccurate reporting, and the whole thing just becomes a mess.

So, was Carhartt actually breached, and did ShinyHunters fabricate the data?

Almost certainly "yes" and then, almost certainly "no", and both positions are supported by previous ShinyHunters form. These guys are approaching 100 breaches sitting on their Tor site (all of which I've reviewed), and I'm yet to see a single one with data they've fabricated. These guys have a track record of successfully gaining access to large orgs and dumping data that genuinely came from the claimed origin. Not to trivialise their criminal extortion campaigns, but misrepresenting the scope of their activities would be bad for business in the same way that not following through on threats and dumping data when they don't get payment would be. This presents an alternate theory PwnedClaw has already touched on: Carhartt simply had a bunch of test data sitting in their Databricks instance.

Going back to the output of our tool, here are the largest files which we now know have junk data in them:

Unique addresses per file:
\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\tables\samples\tpcds_sf1000\customer_chunk_0309.csv: 19,402
\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\tables\samples\tpcds_sf1000\customer_chunk_0589.csv: 19,372
\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\tables\samples\tpcds_sf1000\customer_chunk_0568.csv: 19,362
\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\tables\samples\tpcds_sf1000\customer_chunk_0460.csv: 19,360
\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\tables\samples\tpcds_sf1000\customer_chunk_0263.csv: 19,358
\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\tables\samples\tpcds_sf1000\customer_chunk_0584.csv: 19,358
\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\tables\samples\tpcds_sf1000\customer_chunk_0350.csv: 19,357
\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\tables\samples\tpcds_sf1000\customer_chunk_0264.csv: 19,356
\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\tables\samples\tpcds_sf1000\customer_chunk_0278.csv: 19,356

There were 600 of these files, then another 1,200 files with similar data in this common path:

C:\ShinyHunters\shouldve_paid_the_ransom_carhartt_shinyhunters\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\20260801_033207\samples\tpcds_sf1000\customer\chunk_0116.csv: 9,689
C:\ShinyHunters\shouldve_paid_the_ransom_carhartt_shinyhunters\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\20260801_033207\samples\tpcds_sf1000\customer\chunk_0921.csv: 9,689
C:\ShinyHunters\shouldve_paid_the_ransom_carhartt_shinyhunters\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\20260801_033207\samples\tpcds_sf1000\customer\chunk_1172.csv: 9,689
C:\ShinyHunters\shouldve_paid_the_ransom_carhartt_shinyhunters\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\20260801_033207\samples\tpcds_sf1000\customer\chunk_0529.csv: 9,688
C:\ShinyHunters\shouldve_paid_the_ransom_carhartt_shinyhunters\shouldve_paid_the_ransom_carhartt_shinyhunters\databricks\databricks_dump\20260801_033207\samples\tpcds_sf1000\customer\chunk_0054.csv

Once excluded, the unique address count plummeted to just 13,306,258 results. That's a 47% drop from the 24M+ number we started at... and it's still too high.

I always eyeball the distinct list of email addresses after they're exported by our tooling. Call me old-fashioned, but I still reckon there are things I'll see with my experienced human eyes that the AI will miss (at least, for now). And it missed these:

[25/08/2026 08:47] Troy Hunt: Back on Carhartt, we have a lot of instances like these where the same alias appears across 3 different versions of the domain. I'm writing this up in a blog post, help me explain to the readers what's going on here and why it's inflating the numbers:

[unique alias]@carhartt.com
[unique alias]@carhartt.mail.onmicrosoft.com
[unique alias]@carhartt.onmicrosoft.com

  [25/08/2026 08:47] PwnedClaw: When someone creates an email account at a company like Carhartt, Microsoft 365 (which Carhartt uses for email) automatically creates the mailbox under multiple domain identities simultaneously:

• carhartt.com (http://carhartt.com/) — the primary, human-facing domain (the one you'd put on a business card)
• carhartt.onmicrosoft.com (http://carhartt.onmicrosoft.com/) — Microsoft's default domain, automatically assigned to every Microsoft 365 tenant, exists whether you want it or not
• carhartt.mail.onmicrosoft.com (http://carhartt.mail.onmicrosoft.com/) — a routing domain Microsoft uses internally for mail flow

All three resolve to the exact same person, the same inbox, the same [unique alias]. It's not three people — it's one person with three email addresses that all deliver to the same place.

The inflation problem: when a breach dataset is exported or scraped, all three variants can appear as distinct rows because technically they are distinct email addresses, even though they represent a single individual. A naive deduplication (or none at all) counts [unique alias] three times instead of once.

The fix HIBP applies is normalising to the primary domain and deduplicating on that — but it requires knowing which domains are Microsoft routing aliases, which isn't always obvious, and the breach data doesn't label them as such.

I've previously removed these manually by regex'ing them out myself, but let's not repeat laborious tasks that can be automated away:

[25/08/2026 15:39] Troy Hunt: Cool, delete all those from the file at "\scratch\Carhartt\Carhartt.txt" and we'll keep refining that until it's better sanitised. Tell me how many rows you remove as well.
  
[25/08/2026 15:39] PwnedClaw: Done. Removed 5,736 rows, down from 13,306,258 to 13,300,522.

Continuing the eyeballing work, another pattern emerges:

[25/08/2026 15:41] Troy Hunt: I'm seeing a lot of addresses that begin with "deactivate-". How many are there and what can you tell me about this pattern?
  
[25/08/2026 15:41] PwnedClaw: 288,982 of them. The pattern is clear: these are accounts that were deactivated in Carhartt's system (likely an e-commerce platform or loyalty/membership system), where instead of deleting the record, they prefixed the email address with deactivate- to mark it as inactive while preserving the row. It's a common soft-delete pattern — keeps the data for audit/history purposes but flags the account as no longer active.

The implications for HIBP:

• These are real email addresses that no longer exist in that form — deactivate-[unique alias]@carhartt.com is not a deliverable address
• The real person's address is just [unique alias]@carhartt.com, which may already appear separately in the breach data
• Notifying deactivate-* addresses would bounce or go nowhere

Worth removing them, but worth checking first how many have a corresponding non-deactivated version in the file — if most do, they're pure duplicates and safe to drop. Want me to check that?
  
[25/08/2026 15:42] Troy Hunt: How many already appear without that prefix?
  
[25/08/2026 15:42] PwnedClaw: 285,808 of the 288,982 already have a non-prefixed version in the file — that's 99% pure duplicates. Only ~3,174 appear exclusively as deactivate- with no corresponding active address.
[25/08/2026 15:43] Troy Hunt: Delete all the "deactivate-" prefixed addresses with corresponding active addresses, remove the prefix from the other ones and give me a new total count.
[25/08/2026 15:43] PwnedClaw: Done. Removed 285,808 rows, renamed 3,174 rows, new total: 13,014,714.

That's enough of human eyes, what else have we got?

[25/08/2026 15:50] Troy Hunt: Review the remaining addresses - are there any remaining unusual patterns that frequently occurs? Small issues here and there don't matter, anything in the thousands or more?

[25/08/2026 15:50] PwnedClaw: Two stand out:

wctest.com — 48,787 rows
Looks like a test domain used during development or QA. Not real customers.

carharttdonotship.com — 32,514 rows
The domain name says it all — this appears to be Carhartt's internal domain for flagging accounts they won't ship to (fraud, chargebacks, banned customers). Real people possibly, but deliberately excluded from Carhartt's operations and almost certainly not expecting breach notifications from their banned account email.

Everything else looks like normal consumer email providers. Want to remove either or both of those?

[25/08/2026 15:53] Troy Hunt: They also all seem to have "perftest" in the alias. Delete all these addresses.

[25/08/2026 15:53] PwnedClaw: Done. Removed 48,787 rows, new total: 12,965,927.

[25/08/2026 15:54] Troy Hunt: And the carharttdonotship.com  addresses also have "perftest" in the aliases so let's drop all those too and give me a total remaining count.

[25/08/2026 15:54] PwnedClaw: Done. Removed 32,514 rows, new total: 12,933,413.

Not quite the 24M+ headline any more, that's almost half the addresses in the original corpus discarded because they don't represent actual people. Whilst nothing empirically bad would have happened if I'd loaded them all, the incident would have looked twice as bad as what it actually is (based on the raw numbers, at least), and when I later put out a tweet like this, the percentage of pre-existing addresses would have read way too low:

New breach: Carhartt was the target of a ShinyHunters extortion campaign earlier this month. Data allegedly obtained from the company was later published, including 12.9M unique email addresses. 83% were already in @haveibeenpwned. Read more: https://t.co/Nfs0LT2Qto

— Have I Been Pwned (@haveibeenpwned) August 25, 2026

But let's do one more AI-assisted sanity check, and I'm tending to ask this on each and every breach I process now:

[25/08/2026 16:01] Troy Hunt: Based on the remaining email addresses alone, what can you see that gives you confidence this came from Carhartt? Explain with examples and equally, explain if there's any data that *disproves* Carhartt as the origin.
  
[25/08/2026 16:01] PwnedClaw: Here's what the email addresses alone tell us:

Evidence FOR Carhartt as the origin:

• 15,057 @carhartt.com employee addresses — internal staff addresses don't end up in a dataset unless it came from Carhartt's own systems. You don't scrape these from the outside.
• Hash-prefixed internal aliases like 004cab9722d948ae956d10ce31e7ed74[unique alias]@carhartt.com — that 32-character hex prefix before the surname is clearly a system-generated internal identifier, the kind of thing a CRM or e-commerce platform creates internally. Completely invisible externally.
• carharttdonotship.com (now removed) — a domain that only makes sense if you're inside Carhartt's order management system. No external actor would know this domain exists, let alone have thousands of records under it.
• wctest.com perftest data (now removed) — performance test data from what appears to be Carhartt's own WooCommerce implementation. Again, only accessible internally.
• Demographically consistent — overwhelmingly US consumer email providers (Gmail, Yahoo, Hotmail, AOL, Comcast, sbcglobal, att.net (http://att.net/), verizon.net (http://verizon.net/)). Carhartt is a US workwear brand with a predominantly American customer base. The mix matches perfectly.

Evidence AGAINST Carhartt as the sole/direct origin:

• [unique alias]@state.mn.us — a government employee address. Plausible as a real Carhartt customer, but worth noting government addresses appearing in retail breach data is slightly unusual.
• The sheer volume (12.9M) is large for a workwear retailer — possible the data aggregates multiple systems or years of records, or includes data from third-party partners like Ticketmaster-style fulfilment services.

Overall the internal markers (employee addresses, hash aliases, internal test domains) are the smoking guns — those simply cannot come from anywhere other than Carhartt's own systems.
  
[25/08/2026 16:14] Troy Hunt: Acknowledging the cases "for" and agreeing, I want to challenge both cases "against":

Gov email addresses are *always* in data breaches. Even Ashley Madison (and similar).

My wife tells me that Carhartt is not solely considered a "workwear retailer" and produces products that are worn well beyond just the building site. Review their website and see if your analysis needs revision: https://www.carhartt.com/
  
[25/08/2026 16:14] PwnedClaw: Withdrawn. 12.9M records is entirely plausible for Carhartt — they're a 130-year-old brand with massive mainstream appeal well beyond workwear. Streetwear culture adopted Carhartt heavily in the 90s and it's remained a genuine lifestyle brand since. The volume is consistent with a large, broad consumer base accumulated over many years of e-commerce. That objection doesn't hold up.

Of course, anything AI says needs to be validated and in the cases above, that had already been done. I've included that transcript here anyway just to illustrate the due diligence involved in properly validating data, not just picking it up and chucking it in with a massive headline figure. But it does massively accelerate activities that were previously very manual:

[26/08/2026 05:40] Troy Hunt: Looking at the final list of email addresses, what do the sub-addresses tell us about the origin?
  
[26/08/2026 05:40] PwnedClaw: The sub-addresses are a goldmine for provenance. The dominant signal is clear:

1,072 +carhartt — people who tagged their address specifically when signing up at Carhartt. This is the single biggest tag and is an unambiguous origin marker. Combined with the typo variants (+carhart ×35, +carharrt ×14, +carhatt ×6, +carthartt ×4, +carh ×12) you've got ~1,150+ people who fingerprinted their Carhartt signup specifically.

+paypal ×112, +pp ×10, +applepay ×8` — people who used PayPal/Apple Pay to check out at Carhartt, and tagged the email to that payment method. Strongly confirms this is a shopping/ecommerce dataset.

+shopping ×28, +shop ×15, +orders ×9, +receipts ×4, +retail ×3` — generic purchase-tracking tags, consistent with an online store.

+www.carhartt.com ×8, +carhartt.com ×8` — people who tagged the full domain. Explicit.

+apple ×13` — likely Sign in with Apple or Apple Pay checkout.

The picture is unambiguous: this is a legitimate Carhartt customer/order database, not a compiled list or credential stuffing corpus. People sub-addressed their emails at the point of purchase. That's about as strong a provenance signal as you can get.

And so on and so forth. I don't need to labour the point with more examples, but let me come back around to the premise of this post: take headline numbers with a grain of salt unless you're confident in the processes of those making the claims. I'm fond of saying that whenever there are misleading statements made about breaches, "the truth is in the data", but you have to be willing to go and seek that truth out, even if it requires a significant investment in time.

I genuinely think I've nailed the IoT door lock situation! Well, Ubiquiti has, but I think I've worked out how to put it all into a residential house and have it make sense. There are a few basic tenets:

1. Main power (never have to rely on batteries)
2. Fail-secure (needs to remain locked on power outage)
3. Local control (no cloud latency to contend with)
4. Manual override ("the house is on fire, let me out")

Which is exactly what we have here in this week's vid (and sorry about the section of rubbish audio; the camera mic started capturing it for a short period there). There are some edge cases I want to validate the impact of, namely the inability to keep the door both closed and unlocked, and some of the assumptions I've made around access methods. The laundry will be our low-impact test case; then, if that's all good, I'll start rolling this approach out much more seriously across the house. Stay tuned, I think this will actually be pretty awesome.

Today, we welcome the 48th government onboarded to Have I Been Pwned’s free gov service: Sri Lanka. Sri Lanka CERT now has access to monitor Sri Lankan government domains against the data in HIBP, helping identify exposed government accounts and respond when they appear in new data breaches.

As with the other governments already using the service, this is about using breach data for good: giving national cyber teams practical visibility into their public sector exposure and supporting their work to protect government services.

The current ransomware situation is a bit of a kludge (deep breath): a lot of ransomware (which often doesn't even involve "ware", it's just extortion) is carried out by kids who successfully make a truckload of money but can't spend it without getting caught and the companies they breach rapidly get piled onto by class action lawyers that keeps them busy fighting and being cautious not to say anyting to customers lest that then gets used against them in litigation. That's mostly it; more in this week's video:

A little wind noise, a little connectivity flakiness, and a little lip-sync issues from YouTube, but look at that view! 🤩 Back to business, it's the Brinks Home FAQ I found most interesting this week. I mean, how do you write your own FAQ then fail to actually answer most of the questions?! Being conscious that they're the target of criminal extortion and are genuinely the victims here, I still struggle to grasp how simple incident response questions can be so lawyer-speaked as to remove all sensible meaning from the responses. But this is how these things tend to play out these days (speaking generically, yet to be seen fully for Brinks): hacker gets data by just calling up and asking for it (vishing -> OAuth), hacker demands money, hacker gets no money so dumps the data, company gets a gazillion class actions overnight and lawyers up to the hilt, customers get notified "where legally required" (which it usually isn't) 🤷‍♂️

Today, we welcome the 47th government onboarded to Have I Been Pwned’s free gov service: Nepal. Their National Cyber Security Centre now has access to monitor Nepalese government domains against the data in HIBP. This gives the NCSC the ability to identify exposure across government email addresses and respond quickly when those accounts appear in a new data breach.

This is precisely what the HIBP government service was built for: helping national cyber teams strengthen threat monitoring and incident response capabilities by providing visibility into compromised credentials and breached accounts across their government domain space.

Nepal joins a growing list of governments and national cybersecurity teams using HIBP to better understand their exposure, protect government departments and public resources, and reduce the risk posed by compromised credentials before attackers can take advantage.

Apparently, Aussies are so obsessed with coffee that it's referred to as the coffee capital of the world down here (some bits, at least). "But what about Italy?" people ask. Having spent a lot of time in a lot of Italy, no, it's just not the same. It's not the same ubiquity of high-quality coffee shops and passion for what many view as the art of making espresso-based drinks. There's comparably little tolerance for the likes of Starbucks (who have not fared well in Australia), and other mass-produced forms of the drink (I don't think I've ever seen diner-style filter coffee here). All that said, we may have gone just a little overboard with the new machine, but anything worth doing is worth doing to excess 😊

The Origin Energy breach down here in Aus is all over the news this week, and as with many breaches, it's multi-faceted. You've got them leading with "don't worry, your credit card is fine", the hacker leading with "they didn't respond when I tried to report it", and now news that the two parties have "come to an agreement". Maybe money was paid, or maybe Origin made some promises to restrain the hounds if commitments about data deletion were made. But both outcomes, of course, provide no guarantee that data has been nuked, so now they get to spend perpetuity waiting for the data that maybe - just maybe - it leaks. And we all should be working on precisely that assumption, just like we did with Optus and Medibank and Latitude and Ticketek and Qantas...

References

1. Sponsored by: CoreView: Misconfigurations in Microsoft 365 leave doors open. Scan your tenant for free.

I reckon this week's video on how Claude is tying together info from UniFi, Home Assistant and the Pi-Hole is an absolute ripper. Or at least the concept is - if ever there was an actual value proposition for AI it's taking lots of noise and converting it into a useful signal. Or, sometimes, it's just helping you see the woods through the trees, and that's exactly what Claude helped me do last night when every Sonos unit in the house refused to connect to any music service. It only took Claude a moment to work out: "you know your Pi-Hole is dead, right?" Uh... I do now! Give it a go, it's pretty awesome (and the Pi-Hole came good with a power cycle on the PoE port).

"Build a smart home", they said. "It'll make life so much better", they said. Well, life wasn't very bloody good at 23:00 the other night after travelling 33 hours from Paris only to find the IoT doorlock batteries dead and the 9V "jump start" procedure completely failing! Eventually, the locksmith arrived and opened an old-school physical lock on another door in an alarmingly short time. So, lessons:

1. Battery-powered locks suck and will eventually lock you out of your house
2. Don't trust a fallback mechanism as rudimentary as "hold a 9V battery on some terminals"
3. Always have an old school manual backup approach, AKA "a key"

As I say in the video, we do have other doors that have keys, and if it weren't for the complacency we developed, we would have had one of these accessible. But alas, we didn't. The path forward is to take a deep dive into Ubiquiti's Access ecosystem, which I've flagged in the past, and by pure coincidence, I already had a meeting lined up with them to discuss just this. So, the hardware is on the way, and I'll have something entirely new to play with in the coming weeks. Stay tuned!

How's this for a location?! I mean, last week was nice with Scott in Mallorca, but Marrakech is, well, wow 😮 Anyway, about those data breaches... This week I'm talking about the futility of attempting to remove piss from a pool, yet here we are, with various companies wanting to place that message alongside the very data breaches they can do nothing about! As I say in the post, I don't question the good intentions behind setting up a service to try to scrub data from legally operating data brokers, but the marketing machines behind those organisations that regularly reach out to me for product placement don't really seem to grasp that reality. At least now they have a nice explainer courtesy of that post 😊

I can't recall if someone else originally came up with this saying or if I said it in some off-the-cuff comment and it just propagated, but since it's often attributed back to me, I'll relay it here regardless:

Trying to delete yourself from the internet is like trying to take piss out of a swimming pool

Depending on the publication, I'll tailor the saying to be either more broadly palatable or more, uh, "Australian", but the sentiment doesn't change: once data spreads on the internet, you can never put a lid on it. This is important in the context of data breaches because it speaks to the immutability of our exposed personal information. It also speaks to the limited practicality of services that promise to erase your data from the internet, and it's the constant outreach from these organisations looking for marketing opportunities on Have I Been Pwned (HIBP) that's prompted me to write this.

Let's begin with those services, and because there are so many and I don't want to throw any of them under the bus, I won't name names. I also won't name them because whilst they're rather assertive in their marketing outreach, I do believe they're well-intentioned and I don't want to imply otherwise. And they have a role to play; it's just much more limited than is represented. The positioning is often around "data broker removal services", or "protect my data", or "remove my information from the internet". You'll find various companies providing these services by searching for those terms, or you can search for specific organisations... and find others hijacking the search term as they pay to market their brand in front of others. Usual internet marketing shadiness, of course, but IMHO it speaks volumes about the commercialisation of the data removal business.

These services all follow roughly the same marketing handbook:

1. Data brokers have your personal information, which they may obtain via both legitimate and dodgy means
2. It may be used for nefarious purposes such as identity theft, stalking, spam and other privacy violations
3. Pay us, and we'll ask the brokers to remove your data

So let's go through these points one by one, starting with the data broker claim, which is absolutely correct. Your data has value - "data is the new oil" - and there's business in obtaining and selling it. I've dealt with many of them personally over the years, primarily because they've had data breaches. Master Deeds in South Africa was massive. National Public data a couple of years ago was many times larger. Exactis, Adapt, and many others have also been added to HIBP over the years. To the best of my knowledge, they're legally operating services, even if they may exist on the fringe of what most of us would consider "a bit dodgy" as far as respecting our personal information goes.

Which brings us to the second point about nefarious uses. There is a very broad spectrum of legitimacy across data brokers. Let's pick two extremes as far as the legality of the service goes. On the "very legally operating" end of things, we have Experian, and even if you don't like what they do, there's no arguing the fact that they're on the cleaner end of legitimacy and do provide valid services. At the other end, you have the likes of LeakedSource (and pretty much every other service with the word "Leak" in its name) that... well... just Google them. And there are many, many more at each end and everywhere in between. And a lot of it's very grey: different legal jurisdictions, different means of obtaining data, and different tolerances for adhering to opt-out requests.

But it's the data removal piece that's the real problem. If you pay one of the services in question to scrub you from the internet, I have no doubt they'll have some degree of success with the legally operating services. Those services will comply with legal requests and are adequately equipped to receive and process them. But the LeakedSources of the world? Not so much. And that's where the rub begins:

Requests to remove personal information are only effective for services that are willing to honour them.

That should sound profoundly obvious to anyone reading this now, but it doesn't really feature when you read the marketing material on data removal services. But I'm only just warming up...

Imagine trying to remove your data from here:

🚨🇺🇸 ShinyHunters has leaked the data of multiple companies...

🇺🇸 American Tower Corporation

🇺🇸 JCPenney & subsidiaries under Catalyst Brands & Authentic Brands Group

🇺🇸 Madison Square Garden Sports Corp.

🇺🇸 Ralph Lauren

🇺🇸 https://t.co/08IaUnp1sx pic.twitter.com/TvqanSTO1Y

— Dark Web Informer (@DarkWebInformer) June 16, 2026

That's a small snippet of the ShinyHunters website from a couple of weeks ago. At the time of writing, a bunch more data has been dumped, including only about 15 minutes before putting these words down in the draft blog post. These breaches have impacted tens of millions of people, including my wife courtesy of her having previously shopped at Canada Goose. Now, let's see how you go about scrubbing her data from that incident. For all the data broker removal services I'll direct to this post later, how do you do that? Clearly, you can't. The pee is now in the pool, and you're not taking it back out. And it's not just "on the dark web" either, their Tor site links through to a clear web site hosting all the data:

And that's just the beginning. Because we're talking about digitised data posted publicly, it replicates like crazy. There will be tens of thousands of copies of my wife's personal info floating around between personal stashes, Telegram channels and public hacking forums. That genie is never going back in the bottle, not unless we're talking about the narrow scope of a legally operating data broker, which raises another issue:

What legally operating broker is enriching their corpus from data breaches?! That's just not where the legitimate ones source info from. The data comes from surveys, exchanges with other services where you ticked the box to agree to the terms and conditions for exchanging data with "partners", public business directories, and even arrest records. Legal services, legal sources, legal processes. In one of the emails from a company looking for product placement, they described their plan as follows (bold is mine):

a plan which allows you to remove your personal information from any URL (where it's legal) you find your personal information on

So what we're left with is data removal services being effective for legally operating brokers who honour legitimate requests, whilst being completely useless against the worst kinds of sites that replicate and abuse your data. In other words, you may be able to opt out of some marketing material or content that's way too specifically targeted to you, but you can't stop the bad guys trying to steal your identity or extort you because "we caught you watching porn on your PC via the malware we installed". It's a little like the court injunctions being the thoughts and prayers of data breach response I wrote about in October: I can't touch the Qantas data breach because I'm a law-abiding Australian who knows about the injunction, but there's absolutely nothing stopping the genuinely bad actors from abusing that data.

And therein lies the core of why I don't want to entertain partnerships with these organisations: not because I disagree with the service or because it will cause any harm, rather because when someone uses HIBP to search for their email address and finds it in the Canada Gooses of the world, these services can't do anything about it. They're merely skimming the leaves off the top of the pool, and no amount of skimming is going to remove what we all know still lies beneath.

How's the view?! Back to business, it's now 8 years ago that Scott and I thought it would be a cool idea to build Why no HTTPS? We used the site to shame companies for not implementing their transport later security property, and to make it a bit of fun, we shamed by country as well. This helped people jump on the bandwagon of giving their respective countries a little "encouragement", and we hope they'll do the same now with Why no Passkeys? Following my infamous phishing incident last year, I registered the domain with the intent of building the successor for the TLS version. However, due to a combination of me having no time and Scott getting very good with Claude Code, he's now stood up this project solo and done a wonderful job of it. Go and check it out, and give those big names from your country a little push.

I know enough about home cinema audiovisual to know there's a lot I don't know. It's conscious incompetence, if you like, which is different to the unconscious incompetence most people have on the topic. That's not to sound derogatory (it's spelled out that way in the competence model), rather it recognises that this is a super specialised area and as soon as you start scratching the surface, things get very complex and very expensive really fast. But it's also exciting, and what we've got in the pipeline for our house expansion will blow you away. More to come soon 😎

Light switches. How on earth is it so hard to find decent light switches?! It sounds ridiculous until you actually spend enough time looking for ones that meet two simple criteria:

1. Aren't stateful (switch is up or down, has to be push-button)
2. Looks good

Now, I'm conscious that this is also very likely an Australian problem, more so than a European or North American one. We're pretty limited by what we get down here, and because it involves electricity, the switches here have to pass all sorts of local Aussie tests and standards. I can't just jump onto eBay or Amazon and ship a box of good ones over from the US. So we're stuck with these rubbish ones... unless you can find me something decent? Please?! 🙏