The Outsider Phishing Kit persists despite the Operation Ghost Hook takedown. Discover how the ChenLun Outsider PhaaS kit bypasses MFA via AiTM attacks.
The Phantom Deal campaign uses fake acquisition documents to target executives. Gen exposed the Phantom Deal fraud after tracking bogus payment demands.
French authorities detained an 18-year-old suspected member of the ZeroBytes hacking group over cyberattacks against the country's tax authority and other organizations.
A municipal utility in Bavaria is recovering from a cyberattack that encrypted its internal IT systems but did not affect water and electricity services.
Most security teams already have a breach clock memorized. GDPR gives you 72 hours. SEC rules give public companies four business days after determining an incident is material. Those numbers get built into incident response runbooks, tabletop exercises and escalation paths, because the clock starts the moment the team confirms something happened.
Article 73 of the EU AI Act adds a third clock, and in my work advising enterprise clients on AI governance, I have yet to see one with a runbook for it.
The obligation took effect on August 2, and it did so alone. The EU’s Digital Omnibus on AI, in force since late July, pushed the rest of the Act’s high-risk enforcement wave — classification, conformity assessment, technical documentation — back to December 2027. Article 73 was not part of that reprieve, though the extra time elsewhere is worth using to get ready. It requires providers of high-risk AI systems to report serious incidents to national market surveillance authorities within 15 days by default, 10 days if a death is involved and just 2 days for incidents the Act classifies as widespread or as a serious disruption to critical infrastructure. Coverage of Article 73 so far has treated it as a legal filing requirement, handled through the same channel as a data protection filing. That framing misses what the obligation is. It is an incident response deadline, and it runs on a different trigger than the breach clocks most security teams already know.
A client once asked me, almost as an aside, whether their customer-facing AI tool would trigger a reporting duty if it simply gave someone bad information rather than getting hacked. At the time, the honest answer was probably not, under any framework they were tracking. Article 73 changes that, and most organizations building or buying AI for the EU market have not caught up yet.
What counts as a trigger here is broader than most teams expect
GDPR’s 72-hour clock starts when you become aware of a personal data breach. That is a bounded question. Did data leave the environment? Was it accessed without authorization? Article 73 asks something harder. The European Commission’s draft guidance takes the position that an indirect causal link between an AI system and a downstream harm is enough to trigger the reporting duty. Their example is a loan denial that traces back to a flawed AI credit assessment. The AI system does not cause harm the moment it produces the assessment, only once a human acts on it and denies the loan. The fundamental rights category requires the infringement to interfere with Charter-protected rights at scale, which is why the Commission illustrates that threshold with patterns, a recruitment tool that discriminates systematically or a credit system that categorically rejects an entire neighborhood. Under the Commission’s reading, once a pattern like that exists, the clock starts when the provider becomes aware of it, not when the system generated the output.
Here’s a plainer version of that pattern. A public benefits agency uses an AI system to match applicants against its records. A flaw in the matching logic occasionally conflates applicants, and over several weeks it happens to a run of different people, each flagged as already receiving the same benefit elsewhere and suspended. Nobody catches the pattern at the time, because each flag looks unremarkable on its own. Applicants don’t find out until their payments stop arriving, weeks after the first mismatch. The system never malfunctioned in any way security tooling would catch. It just produced bad matches until people started missing payments.
That is a different kind of determination than “Did we get breached?” It requires tracing a causal chain from a model output through a downstream decision to an actual harm, then judging how confident you are in that link before you are required to report it. Most incident response teams have a well-practiced instinct for confirming unauthorized access, but few have one for confirming that an AI system caused a harm that surfaced elsewhere in the business, days or weeks later. I have watched security leaders confidently answer, “Were we breached?” in minutes, then go quiet when asked, “Did our AI system cause this?” because nobody owns that second question yet.
Why this does not fit into an existing IR playbook
Most incident response programs are built around a single moment: detection. Something trips an alert, a SOC analyst confirms it and the clock starts. Article 73 incidents will not look like that at all. The AI system that produced the flawed output may show no signs of compromise. Nothing gets flagged by a SIEM. The first sign might come from a customer complaint, an internal audit finding or a pattern a compliance analyst notices months after the AI system made the decision.
That means the “becoming aware” clause in Article 73 is doing real work, and most organizations have not decided who is responsible for noticing. Is it the team monitoring the AI system’s technical performance, the business unit acting on its outputs, or whoever eventually hears the complaint? Under Article 73, the clock starts when any of them establishes, or suspects, the causal link, and 15 days is not a long runway if the first internal conversation about “is this our incident” does not happen until day six or seven. I have seen governance structures where a business unit head, a model risk team and security each assumed someone else owned this judgment call. In practice nobody did, and that gap is where a 15-day clock burns down to five.
Some security teams are already mapping agent governance to a maturity model, arguing that oversight must scale with autonomy, moving from agent identities that are barely inventoried toward ones that are bounded, monitored and revocable in real time. Article 73 raises the stakes on that model considerably. The less a human reviews an AI system’s output before it reaches a customer, the more likely a downstream harm surfaces without anyone watching for it in real time, which is exactly the blind spot Article 73 is designed to close.
What needs to change
A few additions belong in an existing incident response program before this becomes a live problem instead of a paper requirement.
First, a defined owner for the causal link determination. Data breach response usually has a clear owner: security confirms the technical facts, legal makes the materiality call. Article 73 needs an equivalent split: Someone technical enough to trace an AI system’s output to a downstream decision and someone with authority to make the reporting call once that link looks plausible rather than certain. In practice, I recommend naming this owner in the incident response plan, not leaving it to be sorted out during the first real incident, when the clock is already running.
Second, a lower bar for opening an investigation. If GDPR taught teams to investigate the moment unauthorized access is suspected, Article 73 requires investigating the moment a downstream harm is suspected to trace back to an AI system, when the system looks normal to security monitoring. That means feeding business unit complaints and customer escalations into the same triage process that currently only starts from technical alerts.
Third, a documented decision log for the indirect link judgment call. Given how broadly the Commission has defined what counts as reportable, organizations will make defensible calls not to report many ambiguous situations. Those decisions need to be documented with the reasoning behind them, the way a security team documents a false positive call, because a regulator revisiting that judgment months later will expect to see how it was made rather than take the outcome on faith.
Fourth, controls built into the AI system, not bolted on after the fact. A defined owner and a lower investigation bar help catch a problem once it surfaces, but neither reduces how often a flawed output reaches a customer first. Scoped credentials, tool allowlists and pre-action approval hooks cut down on how many incidents exist to report.
The AI Act’s high-risk obligations have absorbed most of the attention this year, because conformity assessments and technical documentation are heavy lifts with long lead times. Article 73 looks lighter by comparison, a reporting duty rather than a certification process. It is not lighter. It asks security and compliance teams to build a new kind of judgment into their incident response programs, on a clock as tight as anything GDPR or the SEC have required. Treat the deferral on the rest of the high-risk package as what it actually is, extra runway to build that judgment and name its owner, because the conformity paperwork still gives you months and Article 73 still gives you days.
Crooks are taking a holiday. They’re counting on you to fund it.
For decades, cybercriminals have stolen roughly the same types of data. Biographical and personal details—like Social Security numbers, birthdates, addresses, and phone numbers—can be stolen to commit identity fraud. Credit card numbers, expiration dates, and CVC codes can be stolen to make fraudulent purchases. Usernames and passwords can, in the wrong hands, let a cybercriminal impersonate someone, steal sensitive photographs to later use for extortion, or abuse a reputation.
All of these attack models seek to turn sensitive or important data into currency. But an emerging form of digital fraud is targeting data that, when used strategically, practically is currency: Loyalty points.
Loyalty points programs are run by nearly every type of consumer-facing business today, from hotels to airlines to grocery stores to donut shops. As repeat customers accrue these points, they can exchange them for discounted prices on future purchases, cutting the costs of hotel stays, flights, rental cars, and even entire vacations.
But the value stored within these loyalty points makes them a high target for cybercrime, said Kim Sutherland, Global Head of Fraud and Identity at LexisNexis® Risk Solutions.
“Most loyalty currency is worth about one cent per point, and then there are premium programs that can be worth more than that,” Sutherland said, explaining that 100,000 airlines points, for example, can be worth $1,000 in the US. “Why criminals care so much about this is because most of us are not paying attention to our loyalty programs the same way we would our bank account.”
But diligence is much needed here, Sutherland said, noting that one Chicago teacher only learned that 240,000 of his airlines points had been stolen because he received a basic confirmation email about their use. In another example, a man’s airline miles were stolen and fraudulently used to book rental cars in New York and Memphis.
Today, on the Lock and Code podcast with host David Ruiz, we speak with Sutherland about loyalty points theft— how it happens, what companies are doing to protect customers, and what people can do to stay safe.
“Some of us don’t even know how to access those points, right? Or we don’t even know we’re accumulating them, but the fraudsters do.”
Welcome in! You’ve entered, Only Malware in the Building. Join us each month to sip tea and solve mysteries about today’s most interesting threats. Your host is Selena Larson, Proofpoint intelligence analyst and host of their podcast DISCARDED. Inspired by the residents of a building in New York’s exclusive upper west side, Selena is joined by her co-hosts N2K Networks Dave Bittner and Keith Mularski, former FBI cybercrime investigator and now Chief Global Ambassador at Qintel.
Being a security researcher is a bit like being a detective: you gather clues, analyze the evidence, and consult the experts to solve the cyber puzzle. This week, Dave, Selena, and Keith explore the pros and cons of allowing select U.S. companies to conduct offensive cyber operations under strict government guardrails. They discuss what the proposed framework could mean for private-sector security researchers, how researchers have already been operating in this space for years, and where the line between defense and offense gets blurry. They also look at how adversaries such as China and Russia use proxy companies and other private-sector entities to conduct cyber operations—and consider whether giving trusted U.S. companies similar capabilities could strengthen cyber defenses or create new risks.
Berlin refused a 30 Bitcoin ransom, leading hackers to leak 6TB of sensitive state administration and national defense data on the dark web.
When a ransomware gang dumps nearly six terabytes of state administration files onto the dark web, ignoring them does not make the problem go away. The Rhysida ransomware group recently carried out this exact threat against Berlin after local authorities refused to pay a thirty Bitcoin ransom.
At the end of August, Berlin’s state government confirmed it was dealing with an extortion attempt following an August cyberattack on the city-state’s administrative network, and officials have already refused the requested ransom. The ransomware group Rhysida claimed responsibility on its leak site August 28, posting an entry titled simply “Berlin, Germany” and claiming 5.79 terabytes of data across roughly 1.44 million files, with personal information on 12,076 individuals allegedly included.
Rhysida claimed it stole 5.79 TB of data, covering around 1.44 million files. The alleged dataset includes:
Personal data: 12,076 individuals, 16,389 email addresses, 11,963 phone numbers and 148 IBANs.
Sensitive records: more than 5,000 personnel files, more than 5,000 administrative-offence files, payroll data and leadership information.
Credentials: plaintext passwords and credentials for systems including GebäudAtlas, the ePayment PAYONE database and Z_ADMIN accounts.
Government and legal material: disciplinary proceedings, court cases, supervisory documents, NDA records and Bundesrat committee protocols.
Classified information: data related to classified-material handling and documents allegedly containing state secrets.
Critical infrastructure: vulnerability analyses concerning Berlin’s water supply.
Identity documents: passports and ID cards from personnel records.
Other material: contracts, financial documents, HR records, infrastructure files, health data, password stores and SQL/PST archives.
The group also claimed that the material could involve violations of GDPR, German classified-information rules, criminal law and KRITIS/BSIG requirements. These are Rhysida’s claims and have not been independently verified.
The scale of the breach is staggering. Investigators are now looking at roughly 1.4 million files containing personal details of civil servants, internal infrastructure records, and critical government data.
The fallout goes far beyond routine data theft. Investigative journalist Lars Winkelsdorf pointed out the gravity of the situation on social media.
Die absolute Vollkatastrophe ist eingetreten
Dieses Datenleck ist schlimmer als alle bisherigen Terroranschläge zusammen 1/xhttps://t.co/epU4mCYgew
“In addition to LKA documents related to investigations, the files also include plans concerning national defense—ranging from the federal government’s secret communication channels in the event of an apocalypse to defense-related companies and emergency plans developed by government agencies,” Winkelsdorf wrote.
Exposing crisis response plans and secret communication channels turns a financial shakedown into a national security headache.
Worse still, the leaked material includes files concerning chemical, biological, radiological, and nuclear threats.
“Among the published files is a folder titled “AG CBRN-Rahmenplanung.” CBRN stands for chemical, biological, radiological and nuclear threats,” notes the Euronews report
Having that kind of operational data floating around public forums gives hostile actors a blueprint for disaster.
Refusing to pay ransoms is the right policy, but it rarely stops the bleeding once the network is compromised. Governments keep treating cybersecurity like an IT expense rather than an existential line of defense.
Until boards start treating network segmentation with the same seriousness as physical security, we will keep watching expensive countdown timers tick down to zero.
Berlin’s state government announced the launch of a crisis response after the threat actors published the stolen data.
“A central crisis unit will oversee the review, verification and assessment of the leaked data and support efforts to inform affected citizens and businesses, said the city.” Reuters reports.
MikroTik RouterOS SSH zero-day (MikroTrick chain) under active exploitation since Sept 2. Patch to 7.24.2, 7.23.5, or 6.49.21 immediately and check logs.
“If you have a MikroTik router on the internet with SSH open, it may already be compromised” Raiu wrote on Medium.
The attack chain being exploited is called MikroTrick and combines two of six vulnerabilities CERT Polska discovered and disclosed: CVE-2026-67276 (CVSS score of 9.2), an SSH authentication bypass, and CVE-2026-86060, an SSH session privilege escalation.
“The CERT Polska team has identified and coordinated the disclosure of six vulnerabilities in MikroTik RouterOS. Combining two of them allows an attacker to take full control of the device without authentication if the device supports remote access using the SSH protocol. To make this chain easier to identify, we have given it a common name, MikroTrick.” states CERT Polska. “In recent days we have been observing attacks against RouterOS devices accessible from the internet. “
CVE-2026-67276 flaw stems from how RouterOS verifies RSA public keys. If an attacker knows a valid username and the public part of the user’s RSA key, they can create a fake key and log in without the private key.
When combined with the privilege-escalation flaw, the attack can give an attacker full administrator access to any internet-exposed RouterOS device with SSH enabled.
“MikroTik has released fixes in versions 7.25beta3, 7.24.2, 7.23.4, and 6.49.21 on September 3, however, it would appear that exploitation began as early as September 2, making it a 0day.” Raiu added. “This seems to suggest someone got hold of the news the patches were dropping and began exploiting it at scale.”
A Polish security forum contained logs showing September 2 exploitation attempts, and CERT Polska confirmed successful attacks including the creation of an “ops” account dating to at least September 2.
Most of the attacks observed so far originated from 82.192.72[.]4, a Leaseweb IP that was hosting a busybox binary (a MIPS build from 2010, identical to the official BusyBox 1.16.1 precompiled binary), alongside three other files: ftpsrv.py, launch.sh, and serve.py. A second IP, 103.102.31[.]18, has also been associated with the campaign. Three of the four hosted files have no VirusTotal detections as of writing.
MikroTik routers are popular because they can run for years with little attention. But that also makes SSH vulnerabilities more dangerous. Devices that haven’t received updates in years may not get patched before attackers start exploiting a new flaw.
Defenders can detect attacks by looking for specific log entries. Failed login attempts show the username -2, which isn’t a valid account and shouldn’t appear in normal logs. A successful attack appears in /system history as ssh:-2@<IP>, followed by an action such as creating a user, adding an SSH key, changing firewall rules, or enabling a proxy or tunnel.
“When one is attached to a configuration action—especially the creation or modification of users, SSH keys, scripts, schedulers, services, firewall rules, proxies, tunnels, or packet-sniffing settings—treat it as confirmed compromise unless it came from an authorized security test.” concluded Raiu. “Do not assume the device is safe merely because no -2 login failure appears: logs may have rolled over or cleaned.”
The creation of an account named “ops” is an additional confirmed indicator of compromise in the observed attacks.
Raiu tested the reproducibility of the exploit using four different AI tools. Astra refused on safety grounds and suggested he apply for cyber verification. The other three (Sol, Daybreak Blue, and GLM-5.3) were willing to help but none could complete a working implementation. That gap gives defenders an estimated one to two days before a working proof of concept appears publicly on GitHub, which is better than nothing but not by much given that exploitation is already happening at scale from a single IP.
CERT Polska noted something unusual: MikroTik sent push notifications through its official mobile app to alert users about the vulnerabilities, a first for the company. Patched versions are 7.25beta3, 7.24.2, 7.23.4, 7.23.5 (released September 4), and 6.49.21. Devices using MikroTik’s default firewall configuration and not directly exposing SSH to the public internet are likely protected, but any device with SSH reachable from untrusted networks should be patched immediately and inspected for the indicators above.
The full list of IOCs from Raiu’s analysis: IPs 82.192.72[.]4 and 103.102.31[.]18; file hashes 6e95f70fdbabb57881b3f5b2c8465d4b17ba901100704efb1278bb3386e6729d (ftpsrv.py), 972b474b896f9fac3cd6b5b8476b410b8f39fbedee8a3b0c745d6e3b328d7dcd (launch.sh), and 6dca83338d60467b65b7789d4d59754e40a7aaa36f40ea2da57538367ac9b89e (serve.py).
Another trove of data from Berlin's government has appeared online, authorities said. Germany's information security agency separately warned about the Rhysida cybercrime group.
A new round of the weekly Security Affairs newsletter has arrived! Every week, the best security articles from Security Affairs are free in your email box.
Enjoy a new round of the weekly SecurityAffairs newsletter, including international press.
Attackers are exploiting two new PaperCut flaws to steal credentials and gain privileged access in education-sector attacks across the U.S. and Europe.
Attackers are exploiting two recelty disclosed PaperCut flaws, CVE-2026-81578 and CVE-2026-82078, in attacks targeting schools and other education organizations in the U.S. and Europe, as reported by TheHackerNews.
Arctic Wolf researchers observed threat actors chaining an authentication bypass with remote code execution to run commands, perform reconnaissance and create privileged accounts. The activity shows how quickly attackers can turn newly disclosed vulnerabilities into real-world attacks, putting sensitive credentials and systems at risk.
“Arctic Wolf observed exploitation of PaperCut servers affected by CVE-2026-81578 and CVE-2026-82078 leading to command execution, reconnaissance, and attempts to create privileged accounts.” reads the advisory. “Observed post-exploitation activity included delivery of Windows registry hive collection tools, Metasploit/Meterpreter-related Java payloads, and commands used to identify hosts, users, processes, and sensitive configuration data.”
PaperCut, an enterprise print-management platform, has a history of exploitation, including attacks that delivered LockBit ransomware. PaperCut disclosed active exploitation of the latest flaws on August 27, 2026. CISA added both to its Known Exploited Vulnerabilities catalog on August 31.
Attackers used PaperCut flaws to run basic system checks, create a privileged account named Administrator17, and collect system and user data.
They downloaded credential-harvesting tools with certutil and used Meterpreter Java payloads to establish remote sessions. The attackers also searched PaperCut configuration files for passwords, secrets, LDAP settings and tokens.
Researchers observed lsa_collect.exe extracting registry keys to recover the Windows BootKey, which could give attackers access to the SAM database and stored credentials.
Defenders should review PaperCut server.log files for known exploitation indicators and look for unusual five-character .class, .cmd, or .out files. Monitor pc-app.exe for command shells such as cmd.exe and powershell.exe, and investigate commands like whoami, tasklist, ver, and uname.
Also check for credential-harvesting tools, unexpected privileged accounts such as Administrator17, suspicious requests to /custom/pcp_*.txt, and large downloads using python-requests.
Finally, keep PaperCut management interfaces off the public internet and install the vendor’s security fixes.
Manchester Airports Group (MAG) data allegedly leaked by FulcrumSec exposes emails and phone numbers of 8.8 million people.
Manchester Airports Group, which operates Manchester, London Stansted and East Midlands airports, has confirmed a data breach involving customer information held in a third-party database. The company says airport operations, passenger safety and aviation security were not affected, but the incident has exposed data that can make fraud far more convincing.
The data related to parking, lounge and Fast Track bookings, as well as airport Wi-Fi sign-ups. MAG said attackers took email addresses, phone numbers, vehicle registration details and postcodes, while payment-card data was not accessed.
The group disclosed the incident on 27 August and said it had contained the risk, engaged specialist advisers and notified relevant authorities.
The extortion group FulcrumSec claimed responsibility for the intrusion and leaked the data after MAG had refused its ransom demand.
“Today we are releasing the Manchester Airports Group dataset: every customer, event, configuration that serves Manchester Airport, London Stansted and East Midlands Airport. Half a terabyte, and every byte of it is pure PII. However, we have decided to withhold the most dangerous part of the breach : the nearly 200,000 passengers whose entire upcoming travel schedules were exposed by MAG’s negligence, which, when linked with their full PII and vehicle information, creates an ideal opportunity for burglars, stalkers, and worse.” FulcrumSec wrote on its data leak site. “Unfortunately for them, MAG made zero effort to protect all their data they’d been collecting. The way we gained access was so simple it is tragi-comical: Iterable admin keys in the frontend JavaScript of each of its three airports’ websites: manchesterairport.co.uk, stanstedairport.com, and eastmidlandsairport.com. Each site had its own key hardcoded into it that provided access to millions of passengers who had passed through that airport. That means for this breach to have occurred at the scale it did, MAG had to make a catastrophic security mistake not once, not twice, but THREE times.”
FulcrumSec claims it accessed MAG’s systems using administrator keys exposed in the JavaScript of its three airport websites. MAG hasn’t confirmed this, and SecurityWeek hasn’t independently verified it, so the claim remains unproven. Still, the case highlights a basic security rule: keep secrets off client-side code, rotate them regularly, limit access and scan code, repositories, logs and configurations for accidental exposure.
The group then published roughly 550 GB of uncompressed data it says came from the airport operator’s systems.
“These exposed keys gave us access to the following:
8,672,291 customer profiles with email, name, mobile, home town, postal region, and the residential IP address the account last connected from
1,169,302,811 events, of which 1,160,120,195 are email-channel events: 611,629,550 sends, 463,286,223 opens, 36,878,965 clicks, plus every subscribe, unsubscribe, bounce and complaint
2,482,763 purchases — every booking every customer of its parking, lounge, and fast-track products has ever made. An analysed subset of 1,154,675 transactions, from 877,754 identified purchasers, totals £83,413,317.89
461,433 SMS messages rendered with a passenger’s booking date, car park and vehicle registration spelled out in plain text
108,077 unique UK vehicle registration plates tied to the owner’s email, mobile, airport, car park and dated booking
The complete platform configuration: every campaign, every journey, every list, every segment and every template, all as live JSON” FulcrumSec added.
The announcement claims that a leaked MAG database exposes 190,849 future bookings, including 142,755 linked to vehicle registrations, potentially revealing when homes will be empty.
It also claims the data includes thousands of government, judicial, military, police, NHS and defence-industry employees, creating significant security risks. The attackers say they removed the most sensitive travel details before publishing, while accusing MAG of downplaying the breach.
Databreach notification service Have I Been Pwned processed the available dataset and added the incident to its breach database. The service reports that approximately 8.8 million email addresses and phone numbers were compromised, alongside names, IP addresses, browser user-agent details, geographic information, purchases and vehicle registration plates.
That is not just a list of email addresses. It is a working fraud kit: a criminal can link a person to an airport, a booking type, a car, a location and a contact number. They don’t need to guess much after that.
What affected people should do
Anyone who has used MAG’s parking, lounge, Fast Track or airport Wi-Fi services should assume that phishing attempts may become more tailored. They should be cautious with messages claiming to concern a booking, refund, parking penalty, account problem or payment request.
Users should change passwords if they reused one associated with these services elsewhere, especially on email accounts. They should also enable multi-factor authentication, review account-recovery methods and avoid clicking links in unexpected messages.
A legitimate organisation will not ask for a password, a banking PIN or a one-time authentication code by email, SMS or phone. If a message refers to a booking, open the relevant airport or provider site manually rather than following the link it contains.
The U.S. Department of Justice and the U.K.'s National Crime Agency and Crown Prosecutor signed a memorandum to cooperate on cases involving Southeast Asian scam operations.
In its first annual assessment, published Friday, the City of London Police said victims reported losing £6.3 million ($8.5 million) to account hacks in the year ending March 31, up from £1.2 million ($1.6 million) a year earlier.
Amir Yaryab is the leader of the IRGC's cyber unit and oversees hacker groups such as the CyberAv3ngers, the State Department said in posting a reward for information about him.
FBI probes suspected breach at IDScan.net after dark web service Nexus offered 153M+ US and Canadian driver’s license scans.
A dark web identity theft service called Nexus appeared on September 1, 2026, offering searchable access to more than 153 million scanned driver’s licenses belonging to people in the United States and Canada.
The FBI’s New Orleans field office opened a formal investigation the same day. Brian Krebs at KrebsOnSecurity, who broke the story, traced the source to idscan.net, a New Orleans-based identity verification company whose clients include Hertz, Target, FedEx, Motorola Solutions, Caesars Entertainment, and the financial services firm Jack Henry.
“On Monday, Aug. 31, a source alerted KrebsOnSecurity to a service advertised by a new user on the Russian cybercrime forum Exploit, offering access to digital scans of identity documents on more than 170 million people in North America. The source brought it to my attention because the proprietor of this identity theft service offered my Virginia drivers license as a free sample in their initial sales thread on Exploit.” wrote Krebs. “The service, dubbed Nexus, claims to have more than 153 million drivers licenses for people in the United States and Canada, as well as more than 10 million identification cards; more than three million travel documents and/or international IDs; and at least 579,000 medical cards.”
The record total was also increasing by roughly 400,000 per day at the time of publication, which the operators attributed to ongoing active exfiltration from a live breach they claim has been running for over a year.
Krebs found his own driver’s license in the database after a source alerted him to the service. The operators had posted his Virginia license as a free sample on the Russian cybercrime forum Exploit. Each record contains six images of the license, showing the front and back in visible, infrared, and ultraviolet light, with a timestamp. Krebs’ timestamp matched a June 2025 flight and car rental.
He then checked nine friends and relatives, and everyone who found their license confirmed traveling or renting a car around the same date. His license and his mother’s, who rented a Hertz car with him that day, had timestamps just seconds apart.
Security researcher Zach Edwards, whose license also appeared in Nexus, narrowed the source further. His timestamp matched a trip to Las Vegas for DEF CON in August. He hadn’t rented a car, but he had shown his license at a marijuana dispensary: Planet13, a multi-state chain. In 2022, idscan.net published a press release announcing an exclusive identity verification partnership with Planet13’s dispensaries nationally. The company now serves more than 1,000 marijuana dispensaries in 19 states, and its own documentation confirms that its technology scans IDs with both infrared and ultraviolet light, precisely the format of the images appearing in Nexus.
Idscan.net performs more than 21 million verifications per month at more than 20,000 locations globally. Its client list spans car rentals, retailers, hotels, financial services, and dispensaries, which explains both the volume and the geographic spread of the records. The dataset also includes marijuana dispensary cards and records marked with the notation “CAC,” which may refer to Common Access Cards, the government-issued credentials used to enter federal buildings and secure facilities. If confirmed, that would significantly expand the security implications beyond consumer identity theft.
The database reportedly contained the driver’s licenses of U.S. Defense Secretary Pete Hegseth and the FBI’s assistant director, but not FBI Director Kash Patel’s.
Idscan.net said Krebs’ findings would help its internal investigation but gave no further details. The company later said it was working with law enforcement and forensic experts. Soon after the story became public, the Nexus service went offline.
Identity verification systems that require driver’s licenses are spreading sensitive data across an expanding network of third-party vendors, and oversight mechanisms haven’t kept pace. Every bar, hotel, car rental counter, dispensary, and age-verification system that scans an ID is creating a copy of that image in a system whose security posture the cardholder has no way to assess.
The idscan.net incident, if confirmed at the reported scale, would be among the largest exposures of government-issued identity document images ever recorded.
Krebs reports that Nexus shut down after his article, while the FBI opened an investigation after learning that stolen IDs may include licenses belonging to FBI agents.
412,000 The Town 2025 festival buyer records are being sold for $10,000, with Brazil’s data openly marketed for bank fraud, loans and SIM registration.
A seller on a Russian-language data-trading forum listed what they’re calling a Ticketmaster database on September 2, claiming over 412,000 Latin American purchase records with a heavy concentration of Brazilian data. Ransomnews’s analysis confirms the sample is genuine ticket-buyer data from The Town 2025, the São Paulo music festival, though who actually lost the data and how remains unconfirmed.
“The listing is headed “SELLING NEW TICKETMASTER DATABASE” and describes a global ticketing platform, Latin America region, with an internal ticketing database as the source and a breach date of 28 August 2026. It advertises 412,192 rows across 34 columns.” reported Ransomnews. “The country breakdown is dominated by Brazil at 251,557 records, or 61%, with Argentina at 219, Chile 155, Colombia 144, Peru 123 and Paraguay 72, plus nine more countries not itemised.”
The seller is asking $10,000 for the full database, or $80 for every 1,000 records, with escrow available. The 251,557 Brazilian records make up about 61% of the database, meaning the seller is effectively asking around four cents per person.
The data includes names, email addresses, CPF numbers, phone numbers, neighborhoods, ticket types, and payment details. Together, these details provide a detailed profile that could be used for identity theft and fraud.
“The seller’s own notes are the part that should concern Brazilian readers most. Alongside the sales copy, the listing states that the CPF numbers work “for Brazilian bank fraud, loan apps and SIM registration”.” continues the report.”That is not our characterisation of the risk. It is the seller describing the intended use of the file.”
Ransomnews ran the kind of checks that usually expose fake listings within minutes, and this one kept passing. Purchase IDs across the sample rise in strict chronological order, exactly what an auto-incrementing database key produces and something close to statistically impossible to fake by chance. Every CPF number in the sample passes Brazil’s official check-digit validation, phone area codes correctly match the state listed on each row rather than defaulting to a single city, and neighborhood names map precisely onto their stated cities, the kind of granular accuracy a random data generator simply doesn’t produce.
The ticket prices provide another strong sign that the database is genuine. Full-price tickets cost exactly 975 reais, while discounted tickets cost 487.50 reais, matching Brazil’s legal student discount. The database also lists Pix and Elo as payment methods, both widely used in Brazil.
Even the incomplete records look realistic. Complimentary tickets issued by the festival’s back office contain no name or CPF, only the ticket type and date. These kinds of inconsistencies are common in real databases but would be unusual in fabricated data.
However, there is an important detail that challenges the claim of a direct Ticketmaster breach. Every record in the sample has exactly the same processing timestamp: October 1, 2025 at 23:05:41, about two weeks after the festival ended.
A live database dump would normally contain different timestamps. The identical timestamp instead suggests that the data may have been exported in a single batch after the event and then shared with a promoter, sponsor, payment provider, or another partner. Ransomnews therefore warns that blaming Ticketmaster directly would go beyond what the available evidence currently shows.
That distinction matters more than it might seem, because it points at an industry-wide blind spot rather than one company’s failure. Brazilian ticketing requires CPF collection to enforce discount eligibility rules, which means live-events companies routinely end up holding a national identity number, a verified phone, and a home neighborhood for hundreds of thousands of people, data with the sensitivity of a bank record sitting inside an industry with nothing like a bank’s security requirements. The moment that data gets exported into a spreadsheet to reconcile ticket sales with a partner, which happens constantly and rarely makes headlines, it becomes dramatically easier to lose.
“If you bought tickets to The Town 2025, treat your CPF as exposed.” concludes the report. “A CPF cannot be reissued the way a password can, and the seller is explicitly marketing these numbers for credit and telecoms fraud.”
If you bought tickets to The Town 2025, the practical response here isn’t panic, it’s specific vigilance. A CPF can’t be reissued the way a password gets reset, so treat it as permanently exposed and check your credit record through Brazil’s Central Bank registry or services like Serasa for accounts you didn’t open. Watch closely for SIM swap attempts given the seller’s explicit mention of telecom fraud, and be skeptical of any inbound call or message referencing your actual festival purchase, since whoever holds this file knows exactly which days you attended and how you paid, more than enough detail to make a scam call sound completely legitimate.
Entrar
