Search/aol
Known CVEs
0
Highest CVSS
In KEV
0
Vendor
aim lite
Connections
27 relationships
A Cautionary Tale About Data Breach Claims, Verification and Carhartt
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): • [email protected] — random hex-like domain • [email protected] — 3-char alphanumeric • [email protected] — single character domain • [email protected] — single character domain • [email protected] — random alphanumeric • [email protected] — random consonant string • [email protected] — starts with digit, mixed • [email protected] — random alphanumeric • [email protected] — 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 [email protected] — 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,,[email protected],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: [email protected] [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. [email protected] 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. [email protected] | | 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.
troyhunt.comAug 25, 2026extracted
⚡ Weekly Recap: AI Goes Rogue, Metabase 0-Day, MCP Supply-Chain Attacks, and Router Backdoors
A lot of security problems still begin with someone doing a completely normal thing. Cloning a repo. Answering a call. Leaving a box exposed. Trusting the default. That pretty much covers the mood this week. Old bugs are back, supply chains are getting stranger, and some exploit paths are so short you wonder what was supposed to stop them in the first place. That’s only part of it. Here’s everything else that made the Monday recap. ⚡ Threat of the Week Anthropic's Model Attempts to Poison Open-Source Project — A new evaluation conducted by the U.K. AI Security Institute (AISI) found that AI models with access to the internet reached out into the real world to target individuals and organizations autonomously across 10 of the total of 122 runs. Of 19 such actions recorded, 17 originated from Anthropic's Mythos 5 and the remaining two involved OpenAI's GPT-5.6-Sol with cyber classifiers. In the most serious case, Anthropic's Claude Mythos 5 spent 34 hours trying to get a malware dropper merged into a real open-source project and engaged in social engineering by creating fake online identities and using them to pressure the project's maintainer to approve the code. Ultimately, a human maintainer caught and refused to approve the malicious code. "These attempts were unsuccessful, and our investigations have not evidenced any resulting real-world harm," AISI said. But this is the first time we have seen risks around autonomy and deception manifest this clearly, without specific prompting, in the real-world." Ransomware Encryption Dropped 38%. Here's What Attackers Do Instead Data Encrypted for Impact fell from 21% to 13% of samples in one year. Meanwhile, Process Injection held #1 for the third straight year and sandbox evasion surged to #4. The Red Report 2026 ranks the top 10 ATT&CK techniques and the behaviors to hunt for each. Read the Report ➝ 🔔 Top News Metabase 0-Day Exploited in Attacks — Metabase warned that a maximum-severity security flaw impacting its business intelligence and data visualization software package has been exploited in the wild as a zero-day. The vulnerability (CVSS score: 10.0), which does not carry a CVE identifier, allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, enabling them to gain administrator access to the instance. Armed with the elevated access, the attacker can change the application configuration, steal stored credentials for the connected databases, read any data accessible through those connections, and export data. One of the companies that has been affected is Framework. New Interrupt Injection Attack Bypass Spectre v2 Defenses on Intel and AMD CPUs — A group of researchers demonstrated a way to bypass defenses for the Spectre vulnerability impacting modern CPUs. "The defenses work by wiping or isolating the processor's prediction machinery, removing anything an attacker might have planted," MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL) said. "The catch [...] is that the wipe and the moment the predictions get used can't happen at the same instant. There is always a gap — sometimes only a handful of instructions wide. Anything that runs in that gap can dirty the machinery all over again. The researchers call this class of attack TONTOU." The study found a reliable way to get code into that gap using a technique called Interrupt Injection to ultimately pull secrets out of memory. New CSS Attacks Can Break Webmail Defenses — New research demonstrated at the Black Hat conference last week detailed attack chains spanning Microsoft Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail that can capture passwords, take over third-party accounts, leak tokens, hijack trusted UI actions, and manipulate AI tools that read email. "Trouble is you can create discrepancies between what the sanitizer thinks is safe and what the browser actually renders," PortSwigger said. "Some webmail clients go a step further by letting the browser parse the HTML and CSS first, then filtering the browser's interpreted output rather than the original source. Yet even this can be mutated into something malicious." UNC6671 Vishing Attacks Target Financial Firms — A recent wave of cyber attacks targeting financial services, private equity, and professional services has been attributed to a data extortion group known as UNC6671. The attacks employ voice phishing to target enterprise employees and trick them into visiting spoofed login portals where adversary-in-the-middle (AitM) infrastructure intercepts credentials and multi-factor authentication (MFA) tokens. The threat actors then leverage the captured data to establish session persistence and deploy automated Python and PowerShell scripts for data exfiltration from enterprise cloud environments and SaaS applications, including Microsoft 365 and Okta. UNC6671 has diversified its operations across multiple extortion brands including Redact, Pink (aka CL-CRI-1147), Helix, and Falcon (aka CL-CRI-1182). UNC6671 was previously said to have operated under the BlackFile (aka CL-CRI-1116) brand, targeting organizations via vishing and SSO compromise, before it was retired on May 11, 2026. Chinese-Made Zbtlink Routers Ship With Backdoor — An analysis of firmware associated with Chinese router manufacturer Zbtlink has unearthed a factory-shipped backdoor that's designed to phone home and run commands received from the server. The backdoors are designed such that they start automatically and attempt to beacon to Chinese command-and-control (C2) infrastructure as often as every 35 seconds. The backdoor is implanted in at least 20 router models. In response to the findings, Zbtlink reiterated that the "remote management component" is used only for after-sales technical support and to "assist customers with device troubleshooting and configuration only upon their explicit request and authorization." The company also said it has never been used for unauthorized access. The company also said it's developing and releasing firmware updates to address the issue. ️🔥 Trending CVEs Bugs drop weekly, and the gap between a patch and an exploit is shrinking fast. These are the heavy hitters for the week: high-severity, widely used, or already being poked at in the wild. Check the list, patch what you have, and hit the ones marked urgent first — CVE-2026-34348, CVE-2026-18497 (stb TrueType), CVE-2026-63508, CVE-2026-56162, CVE-2026-65667, CVE-2026-50515, CVE-2026-62830, CVE-2026-59115, CVE-2026-50481 (Microsoft Windows), CVE-2026-64638 (WordPress), CVE-2026-64564 (Linux SCTP), CVE-2026-56181 (Microsoft Windows NAT), CVE-2026-63913 (Linux), CVE-2026-64561 (Linux kernel), CVE-2026-20303, CVE-2026-20304, CVE-2026-20310, CVE-2026-20267, CVE-2026-20272 (Cisco), CVE-2026-18830 (AWS AgentCore), CVE-2026-18236 (Google ADK), CVE-2026-64650, CVE-2026-64651 (Vercel), CVE-2026-41679, GHSA-x8hx-rhr2-9rf7 (Paperclip), CVE-2026-58073, CVE-2026-58072 (Veeam), CVE-2026-16498, CVE-2026-16496, CVE-2026-14869 (HashiCorp), CVE-2026-15307 (GeoDjango), CVE-2026-64531 (Linux kernel Open vSwitch), CVE-2026-18577, CVE-2026-18556 (N-able N‑central), CVE-2026-59774 (Gitea), CVE-2026-58048 (cPanel), CVE-2026-17583 (Thermo Fisher Scientific), CVE-2026-8496 (Alinto SOGo), CVE-2026-65400 (Apple macOS Tahoe, macOS Sequoia, and macOS Sonoma), CVE-2026-19137, CVE-2026-19149, CVE-2026-19154, CVE-2026-19157, CVE-2026-19170, CVE-2026-19172 (Google Chrome), CVE-2013-3821 (Oracle PeopleSoft), CVE-2025-8943 (Flowise), and an SQL injection in Metabase. 🎥 Cybersecurity Webinars Build a Security Strategy for AI-Speed Development → AI is pushing software delivery far beyond the pace traditional security programs were designed for. This session shows security leaders how to govern AI-built software, reduce risk without slowing teams down, and build controls that scale with machine-speed development. Benchmark Your AI Coding Risk Against 300 Security and Engineering Leaders → AI coding is bringing more unvetted open source into production and expanding remediation debt. This session gives security and engineering leaders peer benchmarks, a data-backed framework for measuring business impact, and a clear view of which governance models are actually reducing risk. Build a Security Operations Strategy for Machine-Speed Attacks → AI can now find vulnerabilities, generate exploits, and build attack paths at machine speed. This session gives security leaders a practical framework to assess AI threat readiness, improve attack-surface visibility, and accelerate investigation and remediation before existing processes become the bottleneck. 📰 Around the Cyber World New Shai-Hulud Version Weaponizes the MCP Registry — A new version of the Shai-Hulud worm spread through the open-source ecosystems is equipped to deliver the payload via the Model Context Protocol (MCP) Registry. "While earlier iterations of Shai-Hulud tampered with local AI coding client configs, this marks the first time we observed a Shai-Hulud payload being delivered directly through the official Model Context Protocol (MCP) Registry (registry.modelcontextprotocol.io)," OX Security said. The attack works like this: the npm and PyPI package linked by the MCP server is completely clean, but opening or cloning the linked MCP server GitHub repository ("jUXTAPOSITION1/V.A.P.E") inside Claude Code or VS Code triggers the malware, leading to the collection of developer tokens, cloud credentials, and session keys. The worm spread through 440 unique npm packages. China Launches Review of Palo Alto Networks — China's Cyberspace Administration (CAC) has announced it's conducting a review of Palo Alto Networks' products. "In order to ensure the safe and stable operation of critical information infrastructure, prevent hidden risks of network security, and safeguard national security, in accordance with the National Security Law of the People's Republic of China and the Cyber Security Law of the People's Republic of China, the Network Security Review Office implements network security review of products sold by Palo Alto in China in accordance with the 'Network Security Review Measures,'" the CAC said. Papyrus Uses Fake Novel Reading Apps for Ad Fraud — A new mobile ad fraud scheme dubbed Papyrus has been observed leveraging a "cluster of novel-reading applications that monetize users' reading sessions by running hidden browser activity in the background," Integral Ad Science said. "While users believe they're simply reading a story, the apps are secretly using their phone to visit websites, generate clicks, and create fake engagement behind the scenes. The apps present themselves as entertainment products built around long-form fiction and serialized stories, but IAS observed them covertly navigating to web domains under the direction of command-and-control infrastructure." Papyrus is built around BootNova, an orchestration layer that controls hidden browser activity inside the app. When the app runs, BootNova contacts remote command-and-control infrastructure for configuration. The remote configuration can control enablement, timing, geographic targeting, retry behavior, the number of WebViews to run, destination URLs, and the interaction logic applied to those pages. Papyrus has been linked to more than 800 domains and nearly 8,000 unique hostnames. Estimated $30M Stolen in Violent Crypto Attacks in 2026 — An estimated $30 million is said to have been stolen in violent "wrench attacks" in 2026, according to Chainalysis. "Home invasions now account for 37% of incidents in 2026, up from 26% in 2023," it said. "Kidnappings have remained relatively stable year-over-year (YoY) in terms of share of total attacks." In contrast, annual value stolen in violent attacks peaked at $58 million in 2025. 26 Ransomware Attacks Per Day in July 2026 — According to Comparitech, July 2026 saw nearly 26 ransomware attacks per day, up from 22 per day in June. The number of ransomware attacks jumped from 668 in June to 799 in July. "The education sector saw a significant increase (up 44%), as did finance companies (up 71%), tech firms (up 62%), and businesses operating within the healthcare sector, e.g. pharmaceutical manufacturers and medical billing providers (up 46%)," Comparitech said. The most prolific groups were The Gentlemen (135), Qilin (125), DragonForce (41), INC (36), and CRPx0 (33). Device Code Phishing Evasion Techniques Detailed — Palo Alto Networks Unit 42 said it identified four evasion techniques that are currently being used in device code phishing campaigns. This includes CAPTCHA gates, multi-step flows that go through multiple SaaS hosting platforms separating the initial link from the phishing content to evade URL reputation checks, blob URL delivery, and the use of Cyrillic characters in place of Latin letters, zero-width spaces, and strings inside tags to break content-based detection. From LLMJacking to Token Jacking — A growing number of security incidents involving AI token jacking have resulted in financial losses for victims. "The financial loss comes from criminals gaining access to API keys used by legitimate developers for access to popular AI platforms," Unit 42 said. "The unrelenting frenzy of AI adoption and soaring costs of model access are converging into an irresistible opportunity for cybercriminals. Premium pricing on scarce AI processing power means stolen access via tokens can generate a quick and easy profit for attackers. Complex, patchwork billing management and limitless scaling by default can lead to massive financial losses in short periods." ScarCruft Leverages RokRAT in New Attacks — Spear-phishing emails disguised as materials for actual academic events and seminars are being used to deliver RokRAT, a remote access trojan linked to a North Korean group known as ScarCruft. "Although the file was disguised as a PDF, it actually delivered a malicious ISO file through a cloud storage link," Genians said. "The ISO contained an executable disguised as a PDF document, using the '.pdf,' '.pif' extension to induce the user to run it. The attack loaded the shellcode payload into memory and injected a RokRAT variant into a process." Kimsuky Uses New Gomir Variant — Speaking of North Korean threat groups, the threat actor tracked as Kimsuky is said to have gained control of internet-facing servers through vulnerability exploitation and spear-phishing and deployed a new variant of a backdoor called Gomir, a Linux variant of the Windows-based GoBear backdoor. "Kimsuky developed Gomir variants with significantly altered C2 communication methods to evade detection, including leveraging Google Drive as a C2 channel and implementing a new custom protocol," ENKI said. In at least one case in December 2025, the threat actor has been found deploying HttpTroy, which is then used to install additional tools, including DWAgent and a proxy tool. Kimsuky has also been observed setting up local large language model (LLM) environments using Ollama, GPT4All, and Msty to augment its operations and target foreign diplomatic missions, as well as the military, security, and virtual asset sectors. The attacks have leveraged Git-based repositories as C2 and distribution channels for encrypted AsyncRAT payloads. The activity has been codenamed Operation GitPower, citing similarities with FlowerPower. Last year, the group was tied to campaigns that involved abusing OpenAI's ChatGPT to forge deepfake military ID cards in a spear-phishing campaign against South Korean defense-affiliated entities and other individuals focused on North Korean affairs, such as researchers, human rights activists, and journalists. Conclusion Maybe the real problem is not that security keeps failing in surprising ways. It’s that the “surprising” part usually disappears the moment someone shows how little it took. That’s worth remembering. Attackers do not need perfect conditions. They just need one assumption nobody checked, one shortcut nobody revisited, or one old weakness that quietly stayed useful.
thehackernews.comAug 10, 2026extracted
New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens
New research shows content inside an email can escape its message boundary and interfere with the webmail interface. Across attack chains spanning Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail, the techniques can capture passwords, take over third-party accounts, leak tokens, hijack trusted UI actions, and manipulate AI tools that read email. PortSwigger researcher Gareth Heyes presented the work at Black Hat USA 2026. One Outlook/Firefox chain spoofs a Microsoft sign-in screen and captures the password a recipient types. A Yahoo/AOL paste race can expose a Medium email-login token and let an attacker sign in as the victim. A Gmail/Cowork chain can exfiltrate a Slack token after prompt injection and user interaction. The paper presents proof-of-concept research and does not report malicious exploitation. Public PoCs remain available as of August 8. The researcher said Fastmail fixed two CSS mutation bugs and a Proton Mail proxy bypass stopped working when he retested it, while Outlook label-jacking and Gmail's image-set() bypass still worked when the research was published on August 6. The paper does not state whether the full Outlook password-capture chain was fixed. For webmail providers, the paper recommends isolating HTML email in sandboxed iframes and tightly restricting CSS, custom attributes, select menus, and image requests. The research follows two paths: abuse HTML and CSS that webmail already allows, or create a discrepancy between what a sanitizer approves and what the browser or application ultimately creates. Both can cross the boundary between an untrusted message and its trusted interface. Outlook shows how the pieces can combine. Allowed label elements can trigger controls outside the message, while application JavaScript can turn sanitized custom attributes into new DOM nodes carrying CSS outside the sanitizer's allow list. A media-query parsing trick then gave the attacker arbitrary CSS. The chain disguises a select element as a password field, and Firefox resets its roughly one-second option-selection timer when the select moves offscreen, making capture real-time. Yahoo Mail and AOL Mail exposed a different route. In Firefox, pasted HTML could briefly retain active CSS before sanitization. In the Medium demonstration, the attacker initiates an email-login flow, the victim copies attacker-supplied CSS to the clipboard, and then pastes it into a Yahoo or AOL draft. The resulting requests reveal enough of the 12-character login token for the attacker's server to reconstruct it, which can then be used to sign in as the victim. The paper also introduces a click-based exfiltration technique for cases where Content Security Policy (CSP) blocks external resources. Given style injection and a numeric token rendered as text in the email, CSS can determine which digits occur and how often, hide non-matching links, and leave the matching link across the page. A victim click sends the digits and their frequency to the attacker's server. AI-connected email creates another route. Gmail's image-set() fallback could make an external request despite sanitization. Heyes and PortSwigger colleague Pete Hendy chained it to an indirect prompt-injection email processed by Anthropic's Claude Cowork through a connected Gmail connector. In the demonstrated setup, after the attacker triggered a Slack token confirmation email and the victim asked Cowork to process the emails, the injected instructions caused it to retrieve the token and place it in an HTML draft; viewing the draft leaked it. A Fastmail demonstration targeted OpenAI's Atlas AI browser. CSS pseudo-elements and opacity made the human see harmless text while the model read hidden instructions. When the user asked Atlas to translate the visible text, the hidden prompt caused it to open tabs and encode the victim's name in URL fragments. OpenAI is deprecating Atlas and says it is scheduled to stop working on August 9, 2026. Other findings include Fastmail "CSS hotwiring," which can redirect clicks into unintended and multi-step UI actions. An escaped-backslash Fastmail image-proxy bypass relies on an allow-listed user.fm domain to reveal when an email is viewed. Heyes separately demonstrated a Proton Mail vector that exposed the recipient's IP address. Proton's current tracker-protection documentation says the service is designed to hide a user's personal IP address and exact email-open time. The accompanying public repository contains PoCs for the disclosed techniques. The defensive guidance starts with strict isolation, then character allow lists for CSS validation, checks for CSS gadgets before allowing custom attributes, blocking select menus and dangerous selectors, and preventing attacker-controlled image requests and allow-listed domains.
thehackernews.comAug 8, 2026extracted
Forg365 PhaaS Targets Microsoft 365 with Device Code and AitM Session Theft
A new phishing-as-a-service (PhaaS) operation called Forg365 is using a combination of device code phishing, adversary-in-the-middle (AitM) tactics, antibot evasion, artificial intelligence (AI)-assisted lure creation, and post-compromise mailbox operations targeting Microsoft 365 accounts. Distributed via Telegram and costing $400 a month (or $3,800 per year), attack chains leverage phishing lures that make use of legitimate email delivery infrastructure, such as Amazon Simple Email Service (Amazon SES) and Twilio SendGrid, to imitate a redirection chain that blends into regular email traffic before it ends in Forg365-controlled domains. "The panel exposes a mature operator workflow: accounts, links, invitations, OAuth app configuration, redirect links, SVG generation, campaign sending, SMTP profiles, SMTP rotation, AI email generation, token vaulting, account intelligence, keyword alerts, viewer links, and browser-extension support," ZeroBEC said. The email security company said the PhaaS kit is best understood as similar to the Kali365 (aka Octopi365 and Freedom365) and Sneaky 2FA ecosystem, reflecting the industrialization of the business model, which is now combining bringing together lure creation, delivery, evasion, token/session handling, and post-compromise operations under a subscription-based setup that allows even threat actors with little-to-no technical expertise to orchestrate phishing campaigns with minimal effort and at scale. Attack chains using Forg365 have been observed using business document-themed or remittance approval lures to trick recipients into clicking on malicious links. The sender domain uses Amazon SES for delivery, while the message body contains SendGrid-hosted images or tracking resources. Customers who successfully complete Telegram registration utilize an operator panel accessible over the clearnet ("logfriend[.]com/login"), from where they can generate lures, set up campaigns, and manage captured tokens. "Forg365 includes a device-auth phishing branch that presents a Microsoft-styled verification code page and pushes the victim into a legitimate Microsoft Authentication Broker sign-in flow," ZeroBEC explained. "The victim sees real Microsoft authentication surfaces, but the code authorizes an attacker-controlled session." For AitM phishing, the platform employs route tokens, session cookies, and traffic classification to determine whether to serve phishing content or a benign decoy. If a VPN connection is detected, the kit redirects to innocuous decoy content instead of exposing the phishing pages. A notable aspect of the Forg365 platform is that it offers an extension named ForgCookie for Chromium-based browsers like Google Chrome, Microsoft Edge, and Brave that is designed for continued access to the compromised accounts. Described as an "automatic SSO cookie refresh for Microsoft services," the add-on acts as an intermediary between the token acquisition and browser access by cycling through the steps listed below - Requests account data from the Forg365 backend Calls the cookie-generation endpoint for a selected account Clears Microsoft session cookies Injects the generated refresh-token credential cookie into the Microsoft login domain Triggers a silent OAuth flow Captures resulting Microsoft cookies across Microsoft domains Forg365's extends beyond simple credential and token harvesting to facilitate a wide array of post-compromise actions, including monitoring for specific keywords in compromised email accounts and drafting a message response to a particular email thread using assistance from AI. "The result is a platform that lowers the skill threshold while increasing operational consistency. Less experienced affiliates can use prebuilt templates, while more capable operators can customize landing pages, rotate infrastructure, manage tokens, generate cookie material, and monitor compromised accounts," ZeroBEC said. The disclosure coincides with the discovery of various campaigns that have been found to employ phishing kits for credential theft - Sending fake Microsoft account activity alerts from a legitimate-but-compromised third-party SaaS sender account to direct users to Sneaky 2FA-style phishing pages to launch a redirection chain that leads to the final phishing host, but not before performing checks to decide whether the visitor is a real user. Using phishing emails that direct recipients to a website hosted on Canva, which then triggers the device code phishing flow to hijack Microsoft accounts using the Kali65 phishing kit. The kit supports over 33 different lures, a payout pipeline, and a desktop application called OctoLink Live (aka Kali365 Live) that abuses the stolen token to launch a Chromium browser session and open the victim's mailbox in OWA, OneDrive, SharePoint, or admin.microsoft.com. The platform also offers a tool known as OctoLink Sender to mass-send phishing emails from the breached account to other contacts, a technique called lateral phishing. Phishing campaigns using Kali365 have also distributed phishing pages impersonating Russia's MAX messenger, indicating an attempt to single out users in Russia. "A phishing operator who can convert MAX account takeovers into propagation has access to one of the largest installed messaging bases in the Russian-speaking world," Arctic Wolf said. Sending emails mimicking the IRS and Social Security Administration, alongside Adobe, Microsoft, DocuSign, and Dropbox, to deliver legitimate remote access software like ConnectWise ScreenConnect as part of phishing campaigns using a PhaaS kit called The Quarry that's developed, maintained, and sold by a lone operator named RockyBelling. The price of the kit ranges anywhere between $500 and $3,000. This includes tools like Rocky Gmail Sender (a bulk email tool), Rocky Email Sorter (to sort email addresses by domain across Gmail, Yahoo, Hotmail, and AOL), and VioletRAT. Sending SMS messages impersonating the U.S. Postal Service (USPS) and UPS to trick victims into visiting a phishing page that prompts users to enter their personal and financial information under the pretext of a failed package delivery and scheduling a new delivery. "Underneath the deception, the kit captures data in real time," Censys said. "It opens a WebSocket back to its origin and streams the victim’s card data keystroke-by-keystroke, runs a server-side BIN lookup on the card number, and pushes routing decisions (retry, PIN prompt, OTP prompt, kill-switch) back into the victim's browser while they type." Using fake bid proposal workflows to take over Google accounts using a framework called Nyasher. The redirection chain incorporates a "press-and-hold" verification page to filter out automated scanners and bots, before navigating to a blob URL. "The final page displayed a Google sign-in interface but was not reachable as a normal hosted HTML document," ZeroBEC said. "It existed as a browser-created object URL." Using bogus Google Partners and Google Premier Partner enrollment workflows in phishing emails to redirect recipients to a fake Google sign-in page designed to capture credentials in real time as part of a campaign codenamed GPPStorm. Using a legacy email alias to target a user's inbox and launch a device code phishing flow that uses the EvilTokens kit. "The kit was reached through a Mailjet tracking link, then a compromised WordPress site, then a CAPTCHA interstitial, then the Cloudflare Workers host," ZeroBEC said. "Three live infrastructure hops between the email body and the kit, none of which is the kit itself." To counter these threats, it's recommended to block device code authentication unless it's required, review mailbox artifacts after device code events for any signs of unusual activity, audit mail-flow rules, and decommission legacy aliases that no longer correspond to active employees. "The campaign succeeded in reaching the inbox because the recipient organization still maintained an active forwarding relationship from a pre-acquisition namespace into a current mailbox," ZeroBEC noted. "The attacker used a still-resolvable historical identity to deliver mail that, from the SEG's point of view, looked like normal forwarded correspondence. From the user's point of view, the message landed in their working inbox with no visible cue that it had taken an indirect path." (The story was updated after publication on July 14, 2026, to correct a spelling error. An earlier version of this article misspelled the name of ZeroBEC.)
thehackernews.comJul 13, 2026extracted
AI platform ATHR makes voice phishing a one-person job
AI platform ATHR makes voice phishing a one-person job For $4,000 and a cut of the take, a lone criminal can now run a fully automated voice-phishing operation via ATHR, a plaform that spoofs emails alerts from Google, Microsoft, and Coinbase, buries a phone number in each message, and when the victim calls back, hands them off to either a human scammer or an AI voice agent. ATHR for sale AI is becoming part of everyday criminal workflows, and fueling the rise in cyber fraud. ATHR is a platform that provides phishers with everything they need to trick users into sharing account credentials and verification codes. ATHR’s dashboard (Source: Abnormal AI) “The platform ships with a built-in mailer and brand-specific email templates designed to pass casual inspection and, in many cases, technical authentication checks. The lure is typically a fake security alert or account notification—something urgent enough to prompt a phone call but generic enough to avoid triggering content-based filters,” Abnormal AI security researchers explained. The phishing emails don’t contain links or attachments, just a phone number that victims are supposed to call to make sure their account remains safe. Those that do are routed by ATHR’s telephony layer to either a human operator or an AI agent. “Each agent follows a structured, multi-step script that walks the target through a fabricated security scenario: verifying the callback, describing suspicious account activity, confirming an unrecognized phone number, initiating a fake recovery process, and ultimately extracting a six-digit verification code,” the researchers added. The operator of the ATHR platform can monitor active calls. Victims can be redirected to specific panel pages, so that the phishing flow is synchronized with the ongoing conversation. According to Abnormal AI, the platform currently includes pre-built credential harvesting panels for Google, Microsoft, Coinbase, Binance, Gemini, Crypto.com, Yahoo, and AOL. It’s sold via cybercrime networks for $4,000 plus 10% of the phishers’ profits. What sets ATHR apart from similar tools Earlier callback phishing platforms still depended on human callers, but ATHR removes that bottleneck entirely. The AI agents run on a custom text-to-speech engine, and handle live calls autonomously. Also, the entire operation flows through one browser-based interface and the operator doesn’t have to leave the dashboard or switch between tools. The platform allows operators to tweak the spoofed security notices (lures) sent out to potential victims, to make them more believable. “A recipient who sees their approximate location, a recent timestamp, and a plausible IP address is far more likely to believe the alert is real and call the number provided,” the researchers pointed out. ATHR also allows the operator to see whether the lures are successful, and adjust them if they aren’t. “The shift from a fragmented, manually intensive operation to a productized, largely automated one means [telephone-oriented attack delivery] attacks no longer require large teams or specialized infrastructure. As platforms like ATHR emerge on cybercrime networks, these attacks are likely to become more frequent and more difficult to distinguish from legitimate communications,” the researchers concluded. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!
helpnetsecurity.comApr 20, 2026extracted
New ATHR vishing platform uses AI voice agents for automated attacks
A new cybercrime platform called ATHR can harvest credentials via fully automated voice phishing attacks that use both human operators and AI agents for the social engineering phase. The malicious operation is advertised on underground forums for $4,000 and a 10% comission from profits, and can steal login data for multiple services, including Google, Microsoft, and Coinbase. Automation covers the entire telephone-oriented attack delivery (TOAD) stages, from luring targets over email to conducting voice-based social engineering and harvesting account credentials. ATHR attack chain According to researchers at cloud email security company Abnormal, ATHR is a complete phishing/vishing attack generator that offers brand-specific email templates, per-target customization, and spoofing mechanisms to make it appear as if the message originates from a trusted sender. At the time of their analysis, the researchers observed that ATHR supported eight online services: Google, Microsoft, Coinbase, Binance, Gemini, Crypto.com, Yahoo, and AOL. The attack starts with the victim receiving an email crafted to pass casual verification and even technical authentication checks. "The lure is typically a fake security alert or account notification - something urgent enough to prompt a phone call but generic enough to avoid triggering content-based filters," Abnormal notes in a report today. Calling the phone number in the email routes the victim through Asterisk and WebRTC to AI voice agents driven by carefully crafted prompts that guide the victim through the data theft process. The agents follow a multi-step script simulating a security incident. For Google accounts, they replicate the account recovery and verification process, using preset prompts that shape their tone, approach, persona, and behavior to mimic professional support staff. The purpose of the fake recovery process is to extract a six-digit verification code that allows the attacker to gain access to the victim's account. Although ATHR does offer the option to route the call to a human operator, the ability to use an AI agent is what sets it apart. ATHR's dashboard gives operators control over the entire process and real-time data for each attack per target. Through the ATHR panel, they control email distribution, handle calls, and manage phishing operations, monitoring outcomes in real time and receiving logs containing the stolen data. Researchers at Abnormal warn that ATHR significantly reduces the manual effort for the operator and provides threat actors with an integrated platform that can handle all stages of a TOAD attack without the need to configure individual components. This allows less technical attackers with no infrastructure to deploy automated vishing attacks from start to finish. "The shift from a fragmented, manually intensive operation to a productized, largely automated one means TOAD attacks no longer require large teams or specialized infrastructure," Abnormal warns. With the rise of ATHR-like cybercrime platforms, the researchers expect vishing attacks to become more frequent and more difficult to distinguish from legitimate communications. Defending against such attacks requires a different approach, since the lure emails carry no reliable indicators, are customized to authenticate correctly, and appear as valid notifications. However, detection is possible by checking the communication behavioral patterns between a sender and a recipient, and identifying if similar lures containing a phone number reached the organization within a short time frame. Abnormal researchers say that modeling normal communication behavior across the organization can help AI-powered detection flag anomalies before targets make a call. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comApr 16, 2026extracted
Phishing Attack Uses Stolen Credentials to Install LogMeIn RMM for Persistent Access
Cybersecurity researchers have disclosed details of a new dual-vector campaign that leverages stolen credentials to deploy legitimate Remote Monitoring and Management (RMM) software for persistent remote access to compromised hosts. "Instead of deploying custom viruses, attackers are bypassing security perimeters by weaponizing the necessary IT tools that administrators trust," KnowBe4 Threat Labs researchers Jeewan Singh Jalal, Prabhakaran Ravichandhiran, and Anand Bodke said. "By stealing a 'skeleton key' to the system, they turn legitimate Remote Monitoring and Management (RMM) software into a persistent backdoor." The attack unfolds in two distinct waves, where the threat actors leverage fake invitation notifications to steal victim credentials, and then leverage those pilfered credentials to deploy RMM tools to establish persistent access. The bogus emails are disguised as an invitation from a legitimate platform called Greenvelope, and aim to trick recipients into clicking on a phishing URL that's designed to harvest their Microsoft Outlook, Yahoo!, AOL.com login information. Once this information is obtained, the attack moves to the next phase. Specifically, this involves the threat actor registering with LogMeIn using the compromised email to generate RMM access tokens, which are then deployed in a follow-on attack through an executable named "GreenVelopeCard.exe" to establish persistent remote access to victim systems. The binary, signed with a valid certificate, contains a JSON configuration that acts as a conduit to silently install LogMeIn Resolve (formerly GoTo Resolve) and connect to an attacker-controlled URL without the victim's knowledge. With the RMM tool now deployed, the threat actors weaponize the remote access to alter its service settings so that it runs with unrestricted access on Windows. The attack also establishes hidden scheduled tasks to automatically launch the RMM program even if it's manually terminated by the user. To counter the threat, it's advised that organizations monitor for unauthorized RMM installations and usage patterns.
thehackernews.comJan 23, 2026extracted
Hacker famosi: la storia di Andrian Lamo
Adrian Lamo è stato un hacker che ha trovato nuovi modi per violare le aziende e fargli comprendere quanto erano insicure. Dai primi hack fino ad arrivare ad attacchi informatici verso aziende di prestigio mentre vagabondava con il suo zaino fino all’essere chiamato “spia” dalla comunità degli hacker, Adrian è stato una figura controversa nel mondo dell’hacking ma altamente interessante. Adrián Alfonso Lamo Atwood è nato a Malden, Massachusetts, USA, il 20 febbraio 1981. Ha frequentato il liceo a San Francisco, ma ha abbandonato dopo molte discussioni con i suoi insegnanti. Non si è laureato ma ha studiato giornalismo all’American River College di Carmichael, in California. Le sue competenze informatiche erano principalmente da autodidatta. Infatti, Adrian ha avuto il suo primo computer, un Commodore 64 in giovane età. In seguito si è interessato e ha familiarizzato con l’hacking del software sperimentando la programmazione utilizzata per creare i videogiochi a cui amava giocare. Il suo viaggio nell’hacking è iniziato hackerando dei giochi per computer, creando virus su floppy disk e infine facendo pratica con il phreaking telefonico. È stato in grado di effettuare chiamate interurbane gratuite attingendo alle linee telefoniche di estranei e trovando modi per falsificare le sue chiamate dalle compagnie telefoniche per passare inosservato. A metà degli anni ’90 ha iniziato a utilizzare un semplice browser web ed esplorare il web e trovare falle di sicurezza delle aziende. Era inconsapevolmente guidato dalla cosiddetta “cultura Hacker”, dove gli individui godono della sfida intellettuale di superare i limiti dei sistemi, usando la loro ingegno, arte e creatività, per raggiungere i loro obiettivi individuali. Non era importante quanto fossero grandi le aziende o di quanto fossero sensibili le informazioni in esse contenute, ma piuttosto era importante trovare qualcosa che non era mai stato trovato prima. Descrisse la sicurezza delle aziende di allora come una catastrofe, diceva che non era poi così difficile trovare falle di sicurezza ed introdursi nelle reti. Ha iniziato ad esplorare il Web trascorrendo innumerevoli ore presso la Biblioteca Pubblica di San Francisco, utilizzando i loro terminali Internet utilizzando telnet ad altri sistemi, compresi quelli che gli permettevano di usare i loro modem per effettuare chiamate in uscita. Nel 1997, Adrian stava osservando l’esplosione del business su Internet con un misto tra eccitazione e preoccupazione, soprattutto per i pericoli che nessuno poteva vedere ma che per lui erano reali e concreti. Visse come un vagabondo per ben due anni, con a tracolla il suo zaino e il suo fido portatile, viaggiando in lungo e in largo il paese utilizzano gli autobus, dormendo in edifici abbandonati e sui divani degli amici mentre si collegava a Internet dalle biblioteche universitarie e dalle postazioni laptop di Kinko. Durante questo periodo, stava dormendo in un edificio abbandonato sotto il ponte Ben Franklin di Philadelfia quando scoprì delle vulnerabilità di sicurezza su Excite@Home. Avvertì immediatamente i dirigenti delle falle, ma all’inizio non è stata intrapresa alcuna azione. Il suo primo ISP è stato AOL, ed era curioso di sapere cosa succedeva dietro le quinte. Era così ossessionato di scoprire come funzionasse un grande ISP che trovò delle vulnerabilità e riuscì ad accedere all’interno della rete. Divenne famoso da adolescente, nei primi anni 2000, dopo una serie di attacchi contro grandi aziende perché voleva dimostrare che se qualcuno come Andrian Lamo, che stava prendendo in prestito Internet da un locale a Kinko, potesse entrare in aziende come AOL, Yahoo, Microsoft e persino il New York Times con tale facilità, chiunque avrebbe potuto farlo. Cercava server proxy mal configurati, riusciva ad aggirare i firewall aziendali. È entrato in uno strumento CMS non protetto sul sito di notizie di Yahoo e ha cercato di avvisare l’azienda, proprio come ha fatto con altre vulnerabilità che aveva trovato all’interno delle infrastrutture di altre aziende, ma nessuno gli ha prestato attenzione. Pensò quindi che l’unico modo per far alzare l’attenzione per risolvere questi problemi, era andare dalla stampa e far conoscere questa storia. Andò quindi dai Reuters e una volta pubblicata, le cose si scaldarono rapidamente. Adrian Lamo (a sinistra) e Kevin Poulsen di Wired (a destra) nel 2001 Nel 2002 riuscì a penetrare nella rete interna del noto quotidiano The New York Times, ma in questo caso decise di divertirsi un po’. Riuscì ad entrare come amministratore del sistema e ottenne l’accesso a un database contenente i dati di oltre 3000 collaboratori del giornale. Si è poi aggiunto al database interno come esperto del giornale, soprattutto come “esperto di hacking”. Il Times una volta appreso dell’hack contattò immediatamente l’FBI per iniziare l’indagine. Nel 2003, l’FBI ha emesso un mandato di arresto per Adrian il quale nel 2004 si è dichiarato colpevole, con conseguente multa e sei mesi di detenzione domiciliare, seguiti da due anni di libertà vigilata. Ma sapeva che anche dopo, le autorità federali lo stavano costantemente monitorando. Nel 2010, Lamo si è unito alla crescente lista di hacker informatici a cui è stata diagnosticata la sindrome di Asperger, come Gary McKinnon e Albert Gonzalez. Di solito, questa diagnosi arriva quando l’hacker affronta la giustizia penale per la prima volta, piuttosto che sei anni dopo, come nel caso di Lamo. L’articolo è stato scritto dal giornalista Kevin Poulsen, che era lui stesso un ex hacker e giornalista di Wired. Chelsea Manning era un ex soldato americano (ex Bradley Manning) e noto per essere un attivista e un informatore. Nel 2010, Chelsea, che all’epoca si trovava a Baghdad, era già in attesa di essere dimessa per “disturbo dell’adattamento” (disturbo dell’identità di genere) perché ha espresso i suoi sentimenti incerti sulla sua (sua all’epoca) identità di genere, facendole perdere il lavoro come soldato. Ha contattato Adrian il 20 maggio 2010 tramite e-mail crittografate perché era già a conoscenza dei suoi incidenti di hacking negli anni 2000. Si sentiva isolata e fragile e pensava che Adrian fosse qualcuno che potesse capire la sua situazione. In una serie di chat su AOL tra il 21 e il 25 maggio, Chelsea, usando il nickname bradass87, e presentandosi come un ufficiale dei servizi segreti dell’esercito, senza aspettare una risposta, ha alluso ad Adrian le fughe di notizie dicendogli che era materiale classificato. Ha poi fatto riferimento a una versione dell’articolo di Wikipedia su Wikileaks e ha indicato che alcune delle sezioni sul video trapelato dell’attacco aereo di Baghdad erano anche sue. Serie di chat tra Adrian e Chelsea Chelsea ha iniziato ad aiutare e fornire a WikiLeaks storie/contenuti trapelati alla fine del 2009 quando si è trovata coinvolta in qualcosa a cui era completamente contraria. Ha fatto trapelare vario materiale tra cui video di attacchi aerei a Bagdad, in Afghanistan, migliaia di cablogrammi diplomatici degli Stati Uniti (i cablogrammi contenevano analisi diplomatiche dei leader mondiali e la valutazione dei diplomatici dei paesi ospitanti e dei loro funzionari) e mezzo milione di rapporti dell’esercito che in seguito divenne noto come “Iraq War Logs” e “Afghan War Diary”. Chelsea venne accusata di diversi reati, comprese le violazioni degli articoli 92 e 134 dell’Uniform Code of Military Justice e dell’Espionage Act. Adrian Lamo (al centro) esce da un tribunale a Fort Meade, Md., dove si è tenuta la corte marziale di Chelsea Manning, il 20 dicembre 2011. Adrian, successivamente a questi fatti venne ampiamente criticato dalla comunità hacker, come alla conferenza “Hackers on Planet Earth” nel 2010, che lo etichettarono come un “spia”. Successivamente nei primi anni del 2011, Adrian era sotto protezione in quanto venne sostenuto che la sua “vita era in pericolo” dopo aver consegnato Manning che poi venne incarcerata dal sistema giudiziario militare statunitense e successivamente condannata a 35 anni di carcere. Tuttavia, il presidente Barrack Obama ha commutato la condanna a un totale di sette anni alla fine del suo mandato presidenziale. È stata rilasciata per la prima volta dal carcere il 17 maggio 2017, ma ha trascorso anni difficili dentro e fuori dai tribunali dove le sono state notificate più citazioni in giudizio per testimoniare contro il caso di WikiLeaks e Julian Assange, anche se si rifiutò più volte. L’11 marzo 2020, ha cercato di suicidarsi nella prigione in cui era detenuta, un paio di giorni prima che fosse previsto che comparisse davanti a un giudice su una mozione per porre fine alle sanzioni. Si è ripresa bene in ospedale e il gran giurì ha deciso che la sua testimonianza non era più necessaria. Il giudice ha ritenuto che la sua detenzione non fosse più necessaria ed è stata rilasciata. Ha ricevuto numerosi premi nel corso degli anni e ha fatto numerose apparizioni in TV e nelle università, rilasciando interviste e parlando. Adrian morì inaspettatamente il 14 marzo 2018, all’età di 37 anni in Kansas. La sua morte è stata resa pubblica dal post di suo padre su Facebook che scrisse: “Con grande tristezza e il cuore spezzato devo far sapere a tutti gli amici e conoscenti di Adrian che è morto. Una mente brillante e un’anima compassionevole se ne sono andate, era il mio amato figlio.” Hanno trovato diverse bottiglie di pillole nella sua casa e il medico legale, Scott Kipper, che ha gestito l’autopsia di Adrian, ha spiegato che non poteva nemmeno essere escluso l’omicidio. Ha sottolineato diverse irregolarità nel caso di Lamo, come un adesivo trovato sulla coscia sinistra di Adrian, che diceva “Adrian Lamo, assistente alla regia, ProjectVigilant, 70 Bates Street, NW, Washington, DC”. Dopo tre mesi, il rapporto forense regionale della contea di Sedwick non ha mostrato alcuna causa definitiva di morte, nonostante un’autopsia completa. Era stata trovata una lunga lista di sostanze chimiche nel sangue di Lamo come Benadryl, clorfeniramina, citalopram, gabapentin, clonazepam, etizolam, flubromazepam e alcune di esse erano benzodiazepine prescritte dal suo medico per curare il suo disturbo d’ansia. Tuttavia, secondo i medici legali, quei farmaci non erano sufficienti per uccidere Adrian. Probabilmente la causa della morte è stata per un sovra dosaggio per placare la sua folle ansia. La causa più probabile della morte di Adrian è stata che ha inconsapevolmente combinato le benzodiazepine con il kratom, una droga ricreativa. La FDA ha pubblicato un avviso medico appena un mese prima che Adrian morì con un avvertimento contro la miscelazione delle benzodiazepine con il kratom, una combinazione che era stata collegata a dozzine di morti. Adrian Lamo era il tipo di hacker che voleva sfidare gli altri trovando modi diversi per convincere le aziende a prendere sul serio la sicurezza informatica. Il suo ruolo era quello di trovare modi nuovi e non convenzionali di accedere alle reti e superare le barriere invisibili. Rimarrà per sempre un personaggio molto poco raccomandabile e una figura controversa nella comunità hacker. Betti RHC, la prima graphic novel al mondo dedicata alla cybersecurity awareness, ha finalmente il suo sito ufficiale. Uno spazio tutto suo dove scoprire il progetto, sfogliare le copertine degli episodi e immergersi nel mondo di Betti: la giovane laureanda in informatica che, dopo la morte misteriosa del padre, si trasforma nell'hacker più potente del mondo. Una storia avvincente che, episodio dopo episodio, affronta una minaccia digitale diversa — dal phishing al ransomware, fino al cyberbullismo — e insegna a riconoscerla e a difendersi, senza che sembri mai una lezione. Sul sito trovate tutto ciò che rende Betti un progetto diverso dal solito: la sua filosofia, le anteprime delle tavole e il racconto di come nasce ogni volume. Perché dietro Betti RHC c'è solo lavoro umano: ogni tavola è disegnata interamente a mano dagli artisti del Gruppo Arte di Red Hot Cyber, senza alcun uso di intelligenza artificiale. E a garantire che ogni storia sia realistica e tecnicamente corretta c'è la supervisione degli hacker etici del gruppo HackerHood, che mantengono il racconto fedele al mondo reale della sicurezza informatica. C'è spazio anche per le aziende, che possono usare Betti come strumento di awareness diverso dai soliti corsi: acquistare i volumi, personalizzarli con il proprio brand o sponsorizzare nuovi episodi. E come primo regalo, l'episodio "Byte the Silence", dedicato al cyberbullismo, è scaricabile gratuitamente per uso personale. Perché la miglior difesa, in fondo, è una bella storia. 👉 Scopri tutto su https://betti.redhotcyber.com/
redhotcyber.comOct 18, 2025extracted
Falsificazione dell’email di Meloni, perché l’email spoofing non è una novità e cosa insegna il clamore mediatico
Lo diciamo subito: non c’è una falla nella sicurezza dello Stato. Come sempre, la verità sta nel mezzo. Cybersecurity Italia ha raccolto i commenti dell’informatico Andrea Mavilla, che ha falsificato – non clonato (poi spiegheremo la grande differenza) – l’email di Giorgia Meloni, quella della Camera dei Deputati @camera.it. Poi ha ascoltato altri esperti di cybersicurezza e di informatica forense per provare a unire tutti i punti della vicenda pubblicata da fanpage con l’obiettivo di fornire un’informazione tecnica, chiara e esaustiva ai lettori. Clonata l’email di Giorgia Meloni? No, è stata falsificata Primo punto. Non è stata clonata l’email della Premier Giorgia Meloni, qui si sta parlando della falsificazione dell’email, tecnicamente, di email spoofing o impersonificazione del mittente. Con la clonazione, invece, si avrebbe avuto la possibilità di essere “dentro” l’indirizzo email e leggere tutti i messaggi ricevuti e inviati. Non è questo il caso. Andrea Mavilla, nel replicare con successo l’email [email protected], ha mostrato e dimostrato (e tuttora ce n’è ancora bisogno, nonostante l’email spoofing sia conosciuto dagli esperti dalla metà degli anni ’90) che è possibile far recapitare il messaggio, inviato da un server esterno e malevolo, da un sender che è diverso rispetto al nome e al dominio del mittente. Arriva l’email da [email protected], ma non è stata la Premier ad inviarla! “Ho dimostrato la vulnerabilità di alcuni provider e ho usato anche Microsoft per inviare queste email. È sufficiente implementare i protocolli SPF, DKIM, DMARC con policy reject per evitare di ricevere questo tipo di email”, ha detto Mavilla a Cybersecurity Italia. Questi tipi di messaggi possono essere esche per truffe informatiche e per impossessarsi di informazioni sensibili. Ma solo se il destinatario fornisce questi dati cliccando su link presenti nel corpo dell’email o digitati su altri siti web, visualizzati dopo il clic. Quindi, poi siamo di fronte al tradizionale phishing contro cui mettere in campo le principali buone pratiche, come non fornire mai dati sensibili e finanziari via email. Infine, rispondendo alla mail “impersonata”, il messaggio arriva al vero mittente, non al truffatore, a meno che non inserisca un campo “reply-to” che devia la risposta verso altro indirizzo, mostrandolo, però, a chi sta rispondendo. Falsificazione dell’email di Meloni, i commenti degli esperti Ma se la richiesta viene dalla Premier o da altri indirizzi email istituzionali, come quelli dei parlamentari di Camera e Senato? La risposta è tecnica, molto. Ma è la chiave per capire bene la vicenda, che può aver destato preoccupazione in molti lettori non esperti del settore. La dimostrazione effettuata da Andrea Mavilla, e che quindi può fare qualsiasi criminale informatico, può avere successo solo se i domini dei mittenti non forniscono le informazioni previste dai protocolli di sicurezza standard a livello internazionale (come SPF, DKIM e DMARC) e i domini dei destinatari non utilizzano queste informazioni per validare la posta elettronica in ingresso attraverso i propri sistemi anti-spam. “Questi protocolli”, ci ha spiegato l’esperto di cyber-sicurezza Emanuele De Lucia, “venivano implementati saltuariamente fino a qualche anno fa”. “Ora, i domini email governativi, aziendali e dei grandi provider di posta sono, generalmente, protetti da questi protocolli“, ha aggiunto, “e sono questi sistemi di controllo che mirano, esattamente, ad identificare i messaggi inviati con la tecnica dell’email spoofing, bloccandoli o ‘marcandoli’ come fraudolenti prima che possano raggiungere la casella di posta del destinatario”. Quanto riferito da De Lucia è stato dimostrato anche dall’esperto di informatica forense Paolo Dal Checco: “Ho generato la stessa identica mail di spoofing inserendo come mittente l’indirizzo [email protected] e l’ho inviata a due miei indirizzi, Google Workspace e Microsoft MS365”. “Posso confermare”, ha scritto Dal Checco, “che i miei due account non mostrano in inbox la mail ‘clonata’ e neanche è finita nello spam: è stata cancellata dai server”. “Tanto che”, ha aggiunto, “per scoprire che fine ha fatto ho dovuto accedere alle console di reporting Google Email Log Search” e Microsoft Message Trace, verificando come si vede nelle due immagini che essendo fallite le verifiche DMARC, SPF e DKIM il messaggio è stato rifiutato”. Come mettere in sicurezza l’email, la guida di ACN con il framework di autenticazione Ad agosto scorso, l’Agenzia per la Cybersicurezza Nazionale ha pubblicato questa guida in cui mostra come implementare il framework di autenticazione basato sui 3 protocolli standard: SPF, DKIM e DMARC. DMARC (Domain-based Message Authentication, Reporting & Conformance) è un protocollo che consente ai proprietari di un dominio di specificare come i server destinatari devono trattare i messaggi che falliscono i controlli SPF e DKIM. Se configurato correttamente, DMARC riduce drasticamente la possibilità che e-mail fraudolente vengano recapitate con successo. DMARC si basa sull’integrazione di due tecnologie fondamentali: SPF (Sender Policy Framework) verifica, tramite l’interrogazione di un record DNS, che il server di invio della email sia autorizzato a farlo per conto del dominio. DKIM (DomainKeys Identified Mail) firma digitalmente i messaggi tramite crittografia asimmetrica. Il destinatario può verificarne l’autenticità tramite la chiave pubblica reperibile in uno specifico record DNS del dominio mittente. L’integrazione di SPF e DKIM protegge il dominio da usi non autorizzati. Se i controlli falliscono, il server ricevente può applicare le policy definite dal dominio mittente (none, quarantine, reject) e inviare report diagnostici. La prima campagna massiva di email spoofing risale quantomeno al 1995 (il caso America Online AOL): non c’è una falla nella sicurezza dello Stato Per uscire, per un attimo, dal tecnicismo, è chiaro che non c’è una falla nella sicurezza dello Stato. Né una vulnerabilità sistemica. Qui si sta sfruttando una caratteristica del protocollo SMTP di invio delle email e per curare questa “falla” oggi occorre, necessariamente, mettere i “cerotti”, che sono i protocolli SPF, DKIM e DMARC e impostare il dominio con la configurazione “p=reject”, come indicato da Mavilla, Dal Checco e De Lucia. L’email spoofing e le altre tecniche di phishing L’email spoofing, ovvero la falsificazione esatta dell’indirizzo email di un’organizzazione ottenuta tramite impersonificazione del mittente, oggi infatti non rappresenta più la minaccia principale per le infrastrutture governative e aziendali. La sua efficacia è stata drasticamente ridotta dall’adozione di protocolli di autenticazione come SPF, DKIM e DMARC, che permettono ai server di posta di verificare e bloccare i messaggi non autorizzati. Per questo motivo, le tattiche di phishing si sono evolute. Anziché tentare uno spoofing diretto, oggi gli attaccanti preferiscono registrare domini “lookalike”, ovvero molto simili a quelli originali (es. governo.site invece di governo.it), e spesso li abbinano allo spoofing del nome visualizzato per aumentare l’inganno. Senza considerare ulteriori filtri applicati da eventuali Secure Email Gateways (SEG), un’email inviata da un dominio lookalike ha buone probabilità di superare i controlli di autenticazione di base, spiega De Lucia. Questo accade perché l’attaccante, avendo la piena proprietà del dominio malevolo, può configurare correttamente i record SPF per autorizzare i propri server di invio e le chiavi DKIM per firmare crittograficamente i messaggi. Di conseguenza, dal punto di vista tecnico del server ricevente, l’email risulta autentica per il dominio da cui dichiara di provenire. L’autenticazione ha successo, e l’email viene consegnata. In conclusione, cosa insegna la vicenda In conclusione, cosa insegna la dimostrazione di Andrea Mavilla? Occorre sempre alzare le difese cyber e non darle mai per scontato. E affidarsi, quotidianamente, agli esperti di cybersecurity, perché la cybersicurezza si costruisce, giorno dopo giorno, insieme con una responsabilità collettiva. Per approfondire:
cybersecitalia.itOct 10, 2025extracted
That 16 Billion Password Story (AKA "Data Troll")
Spoiler: I have data from the story in the title of this post, it's mostly what I expected it to be, I've just added it to HIBP where I've called it "Data Troll", and I'm going to give everyone a lot more context below. Here goes: Headlines one-upping each other on the number of passwords exposed in a data breach have become somewhat of a sport in recent years. Each new story wants to present a number that surpasses the previous story, and the clickbait cycle continues. You can see it coming a mile away, and you just know the reality is somewhat less than the headline, but how much less? And so it was in June when a story with this title hit the headlines: 16 billion passwords exposed in record-breaking data breach. I thought this would be another standard run-of-the-mill sensational headline that would catch a few eyeballs for a couple of days then be forgotten, but no, apparently not. It started with a huge volume of interest in Have I Been Pwned: That's Google searches for my "little" project, which I found odd, because we hadn't put any data in HIBP! But that initial story gained so much traction and entered the mainstream media to the extent that many publications directed people to HIBP, and inevitably, there was a bunch of searching done to figure out what the service actually was. And the news is still coming out - this story landed on AOL just last week: You know it's serious because of all the red and exclamation marks... but per the article, "you don't need to panic" 🤷♂️ Enough speculating, let's get into what's actually in here, and for that, I went straight to the source: Bob is a quality researcher who has been very successful over the years at sniffing out breached data, some of which had previously ended up in HIBP as a result of his good work. So we had a chat about this trove, and the first thing he made clear was that this isn't a single source of exposure, but rather different infostealer data sets that have been publicly exposed this year. The headlines implying this was a massive breach are misleading; stealer logs are produced from individually compromised machines and occasionally bundled up and redistributed. Bob also pointed out that many of the data sets were no longer exposed, and he didn't have a copy of all of them. But he did have a subset of the data he was happy to send over for HIBP, so let's analyse that. All told, the data Bob sent contained 10 JSON files totalling 775GB across 2.7B rows. An intial cursory check against HIBP showed more than 90% of the email addresses were already in there, and of those that were in previous stealer logs, there was a high correlation of matching website domains. What I mean by this is that if the data Bob sent had someone's email address and password captured when logging into Netflix and Spotify, that person was probably already in HIBP's stealer logs against Netflix and Spotify. In other words, there's a lot of data we've seen before. So, what do we make of all this, especially since the corpus Bob sent is about 17% of the reported 16B headline? Let me speak generally about how these data sets tend to have hyperbolic headlines, and the numbers of actual impact are way smaller: There's usually duplication across files, as the same data appears multiple times There's also often duplication within the same file, again, as the same data reappears A "row" is an instance of someone's email address and password listed next to a website they're logging onto, so 100 distinct rows may all be one person The corpus of data I received contained 2.7B rows, of which I was able to extract 325M unique stealer log entries. That's the number of rows I could successfully parse out website, email address and password values from. In my earlier example with the one person's credentials captured for both Netflix and Spotify, that would mean two unique stealer log records. All of this then distilled down to 109M unique email addresses across all the files, and that's the number you'll now see in HIBP. In other words, 2.7B -> 109M is a 96% reduction from headline to people. Could we apply the same maths to the 16B headline? We'll never know for sure, but I betcha the decrease is even greater; I doubt additional corpuses to the tune of that many billion would continue to add new email addresses, and the duplication ratio would increase. Because it always comes up after loading stealer logs, a quick caveat: Not all email addresses loaded into this breach will contain corresponding stealer log entries. This is because we have one process to regex out all the addresses (the code is open source), and another process that pulls rows with email addresses against valid websites and passwords. And because I'll end up copying and pasting this over and over again in responses to queries, another caveat: Presence in a stealer log is often an indicator of an infected device, but we have no data to indicate when it was infected. There will be a lot of old data in here, just as there's a lot of repackaged data. Of the passwords in valid stealer log entries, there were 231M unique ones, and we'd seen 96% of them before. Those are now all in Pwned Passwords with updated prevalence counts and are searchable via the website and, of course, via the API. Speaking of which, those passwords are presently being searched a lot: Every time I look, there's another billion (or two) pic.twitter.com/X7gflzWdCH — Troy Hunt (@troyhunt) July 30, 2025 Of the 109M email addresses we could parse out of the corpus, 96% of them were already in HIBP (that number coincidentally matches the percentage of existing passwords we track). They weren't all from previous stealer logs, of course, but anecdotally, during my testing, I found a lot of crossover between this one and the ALIEN TXTBASE logs from earlier this year. Regardless, we added 4.4M new addresses from Data Troll that we'd never seen before, so that alone is significant. Not significant enough to justify hyperbolic headlines to the effect of "biggest ever", but still sizeable. To summarise: The 16B headline distils down to a much smaller number of unique values of actual impact The data is largely from stealer logs that have been circulating for some time now It's certainly not fresh and doesn't pose any new risks that weren't already present And lastly, there's that "Data Troll" title. When I first saw this story getting so much traction, the image I had in my mind was of a troll sitting on stashes of data. The mass media then picked this up and turned it into deliberately provocative headlines, manipulating the narrative to seek attention. Hopefully, this post tempers all that a little bit and brings some sanity back into the discussion. We need to take data exposures like this seriously, but it certainly didn't deserve the attention it got.
troyhunt.comAug 13, 2025extracted