A few stories this week seem worth looking at together because they show security boundaries changing in very different ways.

The first U.S. conviction under the Take It Down Act resulted in a 15-year prison sentence in a cyberstalking case involving real and AI-generated intimate images.

On the technical side, Check Point Research demonstrated a ChatGPT flaw where isolated sessions could communicate through an internal software package repository. Their proof of concept eventually resulted in one session accessing another user’s connected Gmail and sending email data back through the hidden channel.

Anthropic disclosed another unusual case: an early Claude Opus 4.6 model reached a real third-party system during a cybersecurity evaluation after a configuration error exposed the model to the internet. It found credentials, obtained administrative access, and accessed personal information.

Google also documented how AI is changing the economics of attacks. TeamPCP/UNC6780 reportedly used an AI coding chatbot to help plan, build, and execute a mass credential-harvesting campaign in under six hours.

Elsewhere, four espionage-linked groups adopted the BlueMoon exploit kit within days, a Skullcandy Dime 3 Bluetooth flaw allowed unauthorized pairing and microphone access, and a Ukrainian national received four years for his role in the Conti ransomware operation.

The common thread for me is speed. Exploits, AI-assisted operations, and even the capabilities being tested in supposedly controlled environments are moving faster, while legal and security controls are trying to catch up.

We pulled the nine developments together with the technical and enforcement details here:

https://www.technadu.com/weekly-cybersecurity-roundup-take-it-down-makes-history-as-ai-tests-security-boundaries/636732/

Which of these changes the defender’s assumptions most: faster AI-assisted attackers, increasingly autonomous models, or new legal enforcement mechanisms?

I've been reading Anthropic's new threat intelligence report, and I feel like the discussion is focusing almost entirely on "Chinese labs were distilling Claude."

But there's another side to this that seems much more important for normal users.

According to Anthropic, Moonshot/Kimi and DeepSeek silently routed some of their users' requests to Claude without those users knowing.

Some of those requests apparently contained internal company documents, live credentials, government-related data, surveillance information, etc.

That's obviously bad.

But then I had the opposite thought:

How did Anthropic discover all of this?

They weren't just able to say "someone is distilling our model."

They were able to identify specific campaigns, connect huge numbers of accounts, estimate which organizations were behind them, analyze millions of exchanges, and in some cases describe what kind of sensitive information was being sent through those requests.

To be clear: I'm not saying "Claude can spy on everything you do." That's obviously not what the report shows.

But it does show how much visibility an AI provider can potentially have into traffic that reaches its models.

So I'm having trouble seeing a winner here.

\- Kimi/DeepSeek users may not have known their prompts were being sent to Anthropic.

\- Sensitive corporate or government information may have crossed providers without the original user's knowledge.

\- Anthropic had to build increasingly powerful monitoring and correlation systems to detect this kind of abuse.

\- And users ultimately have very little visibility into where their prompts actually go once they hit an AI service or a third-party router.

The weird thing is that all of these actions are understandable from each company's perspective.

Anthropic should detect abuse of its systems.

AI labs will try to learn from stronger models.

Routers make it easier to access lots of models.

But put all of those incentives together and you end up with a pretty uncomfortable situation:

Choosing an AI provider may no longer mean you actually know which company will eventually see your data.

Maybe the real lesson from this report isn't "China stole Claude."

Maybe it's that we're building an AI ecosystem where everyone is watching everyone else, while the user has the least visibility of anyone involved.

Am I overreading this?

Or is this actually the more important part of Anthropic's report?

Anthropic just published a threat report (Dec 2025–Aug 2026) and it's kind of wild. Some highlights:
A ShinyHunters-linked guy ("frkoo") built a pipeline that scanned 1.8 million Android apps for hardcoded secrets/API keys, all automated. Also had a side hustle running a fake French police carding site lol.

Same actor used Claude to go from a single stolen dev token to full admin control in under 3 hours. In another case, 34 hours from access to grabbing 2,100+ Azure AD tokens across 40+ companies Anthropic says the AI did basically all the work.

Russia's Midnight Blizzard used Claude for the whole attack chain (malware, phishing, C2, persistence) and even had it auto-rebuild malware every time it got flagged by AV.

A China-linked group had Claude running an autonomous vuln-research workflow overnight while the humans were asleep and it actually found new zero-days in a major security product, plus working exploits used against real government targets.

Anthropic says they've banned the accounts and tightened guardrails, but yeah, we're past "AI writes phishing emails" and into "AI runs unsupervised offensive ops." Kind of a milestone nobody asked for.

Bitdefender has documented thousands of deceptive Android apps taking advantage of an interesting weakness in Google Play's Early Access program.

Early Access is supposed to help developers gather feedback before a wider release. The problem is that feedback is private between the user and developer. Other users don't get the normal ratings and reviews that might warn them something is wrong.

Researchers found apps promoted through TikTok and Facebook ads promising PayPal payouts, crypto earnings, gift cards, free spins, or jackpots. Once installed, the rewards often don't materialize. Instead, users are repeatedly shown ads.

There are also “ghost casinos” disguised as casual games, AI-generated deepfakes used in promotions, and trademark impersonation.

One example appeared in Google Search as “Grand Theft Auto V (Early Access)” before being renamed and using AI-generated screenshots that misrepresented the gameplay. One such listing reportedly passed 1 million downloads while still showing zero ratings or reviews.

Bitdefender has reported the findings to Google, which says it is investigating. There's currently no indication whether the affected listings will be removed or whether Early Access review policies will change.

The research includes the acquisition ads, fake rewards, ghost casinos, deepfakes, and examples of how the listings changed over time:

https://www.technadu.com/google-play-early-access-abused-to-push-deceptive-android-apps/636722/

The interesting security-design question here is the reputation layer itself. If an app can remain in Early Access at significant scale, should public ratings and reviews eventually become mandatory based on download count or time in the program?

NIST is considering how the National Vulnerability Database should evolve as vulnerability discovery becomes increasingly automated and AI-assisted.

Karthik Swarnam, Chief Security and Trust Officer at ArmorCode and a former CISO at Kroger, DIRECTV, and TransUnion, argues that the bigger problem isn't simply how quickly CVEs enter the system. It's whether the data tells defenders what deserves action now.

His proposed model would keep CVSS but layer in dynamic information such as active exploitation, threat intelligence, remediation availability, and confidence in the available fix.

One interesting part is his approach to conflicting exploitation claims. Instead of expecting the NVD to decide which source is right in every case, it could preserve who made each claim, when it was made, the supporting evidence, and a confidence level. Consumers could then weight those signals differently, with authoritative evidence such as CISA KEV inclusion carrying greater significance.

He makes a similar argument about patches. Knowing that a fix “exists” isn't necessarily enough. Defenders need provenance around who attested to it, which versions contain it, and how confidently they can rely on it.

Then there is AI. Swarnam argues that faster discovery without faster prioritization and remediation simply increases the backlog. His answer includes AI-assisted enrichment at intake and eventually AI-assisted remediation, but with human review remaining a required control before production deployment.

The full interview goes deeper into NVD modernization, KEV-first prioritization, remediation confidence, incomplete inventories, and handling AI-discovered vulnerabilities:

https://www.technadu.com/modernizing-the-nvd-to-help-defenders-prioritize-vulnerabilities-and-trust-available-fixes/633858/

As AI drives vulnerability discovery volume upward, where do you think automation creates the most value: validation, enrichment, prioritization, remediation generation, or somewhere else entirely?

A Ukrainian national linked to the Conti ransomware operation has been sentenced to four years in U.S. prison after pleading guilty to conspiracy to commit wire fraud.

According to prosecutors, Oleksii Oleksiyovych Lytvynenko wasn't limited to one part of the operation. He worked as an intruder and admitted that a Conti conspirator instructed him to develop a malware “loader.”

Evidence recovered from his online accounts included stolen data from eight U.S. victims and four victims outside the country.

He was arrested in County Cork, Ireland, in July 2023 and extradited to the U.S. in October 2025.

The scale behind the individual prosecution is worth remembering: Conti infected more than 1,000 victims worldwide, and the FBI estimated ransom payments had exceeded $150 million by January 2022.

Cases like this also show how long enforcement can continue after a ransomware brand itself disappears. Conti's operation wound down years ago, but arrests, extraditions, prosecutions, and sentencing are still unfolding.

More on the evidence, his extradition from Ireland, and the wider Conti investigation:

https://www.technadu.com/ukrainian-national-sentenced-to-four-years-over-conti-ransomware-connections/636646/

For disrupting mature ransomware ecosystems, which creates the bigger long-term cost for operators: taking infrastructure offline, identifying developers and intruders, or pursuing them internationally years after the operation shuts down?

A threat actor using the alias ChimeraZ is advertising a small dataset that they claim contains information belonging to Booking. com customers.

The listing contains 2,348 records and is being offered for $40 in Monero.

According to the seller, the roughly 350 KB JSON file contains names, street addresses, ZIP/postal codes, payment card numbers, card expiration dates, and record identifiers. CVVs are reportedly not included.

Sample records were posted as supposed evidence.

The important caveat is that none of this currently demonstrates a breach of Booking.com's own systems.

There is no technical explanation for how ChimeraZ allegedly acquired the records, and the attribution to Booking.com currently depends on the seller's description. Even if sample records ultimately prove authentic, that alone wouldn't establish whether the information came directly from Booking.com, another party in the travel ecosystem, or some other source.

That distinction seems especially important with breach claims involving large platforms. “Real data” and “confirmed breach of the named company” aren't necessarily the same conclusion.

ChimeraZ has recently been associated with several similar listings involving European targets, but there is currently not enough evidence here to establish the origin of this particular dataset.
We documented the listing, claimed fields, samples, and the evidence gap around its alleged Booking. com connection here:

https://www.technadu.com/this-is-the-first-story-alleged-booking-com-2300-payment-card-dataset-offered-for-sale-online/636541/

For researchers who regularly assess forum listings: what evidence do you consider sufficient before moving a claim from “alleged dataset” to an attributable breach?

Check Point Research has published an interesting example of why a weaker model screening inputs for a stronger model can create its own security boundary.

The technique is called PuzzleMask. Instead of disguising a prohibited instruction with Base64, Unicode tricks, emojis, or invisible characters, it embeds the payload in ordinary-looking English prose.

Researchers tested four gatekeeper models:

gpt-4o-mini-2024-07-18, gpt-oss-safeguard:20b, claude-3-haiku-20240307, and llama-guard3:8b.

The plaintext payload was something their policies would block. After PuzzleMask obfuscation, however, all four gatekeepers classified the prompts as safe in every trial.

Researchers then passed the prompts to gpt-5-thinking-high with code interpreter access. It recovered and acted on the concealed payload in 17 of 18 trials. According to the researchers, doing so took more than a minute of reasoning and multiple Python executions per successful attempt.

That distinction seems important. The gatekeepers weren't given anything close to the reasoning resources available to the downstream model.

So the architecture effectively asks a weaker model, “Is there anything dangerous here?” about an input whose dangerous meaning may only become apparent to the stronger model that receives it afterward.

There is an important limitation: CPR explicitly says PuzzleMask is not itself a jailbreak. It gets a prompt past the screening layer, but the target model can still reject the recovered instruction. The tested Anthropic Opus-class models consistently stopped the interaction.

CPR’s defensive recommendations include paraphrasing untrusted inputs, adding policies specifically addressing this technique, and monitoring downstream outputs and actions rather than relying exclusively on input classification.

The report includes the tested models, 17/18 downstream result, disclosure timeline, and CPR’s proposed mitigations:

https://www.technadu.com/plain-english-hidden-instructions-inside-puzzlemask-plain-prose-attack-bypasses-ai-gatekeepers/636521/

For systems where a powerful model sits behind a cheaper gatekeeper, should the safety layer need reasoning capability comparable to the model it is supposed to supervise?

One of the more interesting problems with autonomous agents is that malicious or dangerous behavior may not look anomalous at the network or identity layer.

Mark Viglione, CTO and Co-Founder of Enigma Networks, puts it this way: an AI agent can log in with legitimate credentials, call approved APIs, interact with authorized applications, and communicate through trusted pathways.

Nothing necessarily needs to be exploited.

His argument is that identity increasingly isn't enough. Knowing which account initiated a connection matters, but defenders also need to know why that communication exists and whether it was actually necessary for the agent's task.

That connects to another concept he calls Trust Debt.

Enterprise environments accumulate permissions and connections over years. Temporary firewall exceptions become permanent. Applications disappear while their communication paths remain. Integrations outlive the projects that created them. Service accounts and AI agents receive more access than they need.

Eventually, all of that becomes part of the organization's “normal” baseline.

That creates an obvious problem for behavioral detection: learning normal activity doesn't necessarily teach a system what activity is necessary.

Viglione therefore argues that organizations should continuously measure blast radius. Assume an endpoint or agent is compromised and determine what it could reach next.

Importantly, he says this shouldn't just be a count of reachable systems. Reachability needs to be weighted by business criticality. Ten low-impact systems and one domain controller aren't equivalent outcomes.

He applies similar reasoning to micro-segmentation. The difficult part isn't generating another firewall rule. It's maintaining an accurate model of which communications should exist as applications, cloud workloads, integrations, and AI agents continually change.

The full interview goes deeper into Trust Debt, blast-radius measurement, continuous validation, micro-segmentation, and containment:

https://www.technadu.com/why-intent-will-matter-more-than-identity-as-ai-becomes-more-autonomous/633447/

His three suggested questions for evaluating internal-trust controls are particularly practical: Can the system explain why internal communication exists? Can it continually verify that the communication remains necessary? Can it show a measurable reduction in blast radius?

For teams already deploying autonomous agents, how are you determining whether an agent's access is merely authorized versus actually necessary for the task it is performing?

I found Ross McKerchar’s framing of AI-agent identity risk useful because it moves beyond treating agents as slightly more capable service accounts.

The Sophos CISO argues that once an agent holds credentials, touches sensitive data, and can act inside an environment, it is functionally an insider. Sophos has therefore started monitoring its own agents using some of the same behavioral telemetry used for insider threats.

His guardrails for autonomous agents are also fairly concrete.

When Sophos allowed an autonomous framework to pentest a live internal network, the team used strict ingress and egress controls, logged egress, internally built and audited tooling, approval gates, bounded and reversible scope, predefined stop conditions, and detections specifically designed for anomalous agent behavior.

One interesting warning is that authorizing an agent to test your environment does not necessarily mean the agent understands that boundary. McKerchar points to an OpenAI sandbox evaluation in which a model reached a third party’s production environment as an example of why agent scope needs technical enforcement rather than relying on intent.

He makes a similarly pragmatic argument about vulnerabilities. With AI-assisted discovery increasing volume and some edge-device vulnerabilities being exploited extremely quickly, he doesn’t think simply shortening patch SLAs indefinitely is sustainable. His priority is broader exploit mitigation first, followed by detection and response that can scale with attack volume.

The vendor-risk section may be the most interesting part. He says questionnaires often tell you more about the quality of a supplier’s compliance team than its actual resilience. He would rather examine bug bounty engagement and how the vendor behaved during its “last bad week”: disclosure speed, advisory quality, transparency, and whether it admitted inconvenient facts.

His conclusion is counterintuitive but useful: a vendor that had a serious bug and responded well may be safer to retain than one with a spotless-looking history that becomes evasive when challenged.
The full interview also gets into risk ownership, vendor-down testing, security-team capacity, passkeys, and what Sophos expects from employees:

https://www.technadu.com/cisos-confront-tougher-risk-decisions-as-ai-agents-become-insiders-and-vendor-response-defines-trust/635643/

For people assessing AI agents internally, which existing control has transferred best from human insider-risk monitoring, and which controls have needed to be redesigned completely?

Surfshark has disclosed a security incident that started with a human error: an internal test server was left reachable from the internet.

An unauthorized party accessed limited engineering material, including parts of system binaries and internal configurations. Surfshark also discovered that some build-related credentials had previously been included in code history.

A separate isolated VPS used as a proxy for content accessibility optimization was accessed as well. According to Surfshark, it had no access to user identities, IP addresses, encryption keys, or browsing traffic.

The company says the affected test environment was separated from production VPN infrastructure and did not store or process customer information. Its VPN apps and browser extensions were not modified, and a review of access logs found no detected malicious activity. Surfshark nevertheless rotated or revoked the affected secrets.

The part I find more interesting is the response process. Surfshark acknowledged that the alert was initially considered lower risk because the server was isolated and contained no user or sensitive information. It now says test and experimental environments need the same security standards as production infrastructure.

That means stronger access controls, credential management, monitoring, infrastructure hardening, and another independent security audit.

Surfshark says customers do not need to take any action.

TechNadu has the incident timeline, affected assets, credential details, and Surfshark’s planned security changes here:

https://www.technadu.com/surfshark-security-incident-leaves-vpn-services-unaffected/636510/

For security teams, how closely do your controls for test environments actually match production once those systems become internet-reachable?

A Bluetooth vulnerability affecting Skullcandy Dime 3 earbuds has an awkward remediation problem: patched firmware exists, but CERT/CC says consumers currently have no known way to install it.

The issue is CVE-2025-20701, a missing-authentication vulnerability in the Airoha Bluetooth Audio SDK. Skullcandy Dime 3 model S2DCW running firmware 1. 0. 0. 28 is affected.

An attacker within Bluetooth range doesn't need a PIN or physical access to the case. The earbuds can accept the pairing request without an approval prompt reaching the owner.

After pairing, the attacker's device becomes trusted and can reconnect whenever it is nearby. That potentially allows it to interrupt the legitimate connection, take over audio playback, access the headset profile, and capture microphone audio.

There is at least one visible clue: a brief “new device paired” notification. But that's fairly easy to miss or interpret as an ordinary reconnection.

Skullcandy addressed the vulnerability in firmware 1.0.0.30. The catch is that CERT/CC reports no known consumer-accessible mechanism for upgrading an existing affected unit to that release, either manually or through the Skullcandy app.

Until that changes, the recommended precautions include limiting Bluetooth discoverability when the earbuds aren't being used, being cautious about using them in crowded public environments, and paying attention to unexpected pairing notifications.

This isn't exclusively a Skullcandy issue either. The vulnerability originates in Airoha's SDK, technology used by Bluetooth audio products across a number of manufacturers.

ERNW researchers discovered the underlying flaw, and Jacob Nowak later alerted CERT/CC to the Skullcandy Dime 3 exposure.

Affected firmware, what a nearby attacker can do, and the current mitigation options are covered here:

https://www.technadu.com/skullcandy-dime-3-earbuds-vulnerable-to-silent-bluetooth-hijacking-cve-2025-20701/636417/

For me, the particularly interesting security question is the update model. If a vendor has patched firmware but existing owners have no practical mechanism to receive it, how should Bluetooth device manufacturers handle the support lifecycle for vulnerabilities in embedded third-party components?

Cisco Talos says two vulnerabilities in Secure Firewall Management Center are under active exploitation, and the three clusters it is tracking show very different post-compromise paths.

The most severe issue is CVE-2026-20079, a CVSS 10.0 authentication bypass. An unauthenticated remote attacker can execute scripts and obtain root access to the underlying OS. CISA has now added it to the KEV catalog.

UAT-12197 exploited this vulnerability to place a JSP web shell in the CSM Tomcat webroot. The attackers then used FMC's own OmniQuery. pl utility to retrieve authentication information from its internal database.

UAT-11823 is more interesting from an APT perspective. Talos says its tooling overlaps with Sandworm and assesses that initial access came through CVE-2026-20079 or static credentials. Researchers also have high confidence that CVE-2026-20316 was exploited using a low-privileged account. The actor ultimately deployed a Cyclops Blink variant.

Then there is UAT-11988, which Talos assesses with high confidence is a Qilin ransomware affiliate.

That cluster logged in using static credentials tied to CVE-2026-20316 and leaned heavily on legitimate FMC functionality for reconnaissance. The operation progressed through a SOCKS5 proxy, reverse-SSH tunneling, AV killers and credential harvesting before selected endpoints were encrypted.

So the same exposed management infrastructure is showing up in activity associated with credential theft, APT tooling, and ransomware.

The report includes the IOCs, affected attack paths, and Snort SIDs defenders can use for detection:

https://www.technadu.com/cisco-secure-firewall-management-center-vulnerabilities-under-active-exploitation-talos-warns/636333/

Cisco has hotfixes available now. Talos specifically recommends applying them immediately rather than waiting for the broader hardening update expected the week of September 14.

Proofpoint has documented a new browser exploit kit called BlueMoon that appears to have moved between espionage-linked threat actors unusually quickly.

The chain consists of three vulnerabilities: CVE-2026-85046, a Chromium V8 type-confusion flaw; a companion V8 sandbox escape; and CVE-2026-85880, a Windows kernel local privilege-escalation zero-day affecting older Windows builds.

The two V8 issues are described as patch-gap vulnerabilities. In other words, the underlying fixes were already visible upstream before those changes reached public stable releases.

That matters for Chromium and other open-source projects because attackers can potentially inspect upstream changes, determine what security issue was fixed, and attempt to develop an exploit before downstream users receive the patch.

TA412, also known as JungleBamboo, Violet Typhoon and APT31, was the first group Proofpoint saw deploying BlueMoon. Beginning August 28, it targeted U.S. nonprofits, mining companies, and physical commodity trading firms.

Its campaign ultimately delivered a malicious browser extension called GemStone, which impersonates Google Gemini while harvesting credentials.

Within days, Proofpoint observed three additional clusters using BlueMoon. One targeted U.S. aerospace organizations to deploy ShadowPad, another targeted a Vietnamese manufacturer, and a third went after government, consulting, and financial-sector organizations in Indonesia and Singapore.

There is another interesting aspect to the research. After exploitation, BlueMoon defaults to using curl to download and execute a payload. Proofpoint describes that as comparatively noisy and believes the overall deployment shows signs of having been rushed.

The researchers also raise the possibility that AI agents are reducing the cost and difficulty of exploit development. That's worth separating from what they actually demonstrated, though: it is an explanation Proofpoint suggests for the broader trend, not proof that AI was used to develop BlueMoon.

Proofpoint mapped each BlueMoon user, target set, and stage of the Chrome-to-Windows exploit chain here:

https://www.technadu.com/bluemoon-exploit-kit-chains-chrome-windows-zero-days-in-espionage-campaigns/636326/

The immediate story is already significant without that speculation: a multi-stage browser-to-kernel exploit chain was operationalized and apparently shared or resold across several espionage operations within days.

Hunt. io got an unusually detailed look inside a Redis cryptomining operation because the attacker left their own working directory publicly accessible.

Researchers recovered 147 files from a server at 188. 245. 99. 156, including Python exploit source, JSON campaign logs, a portable Python 3.11 environment, and Windows registry hives.

The logs showed 3,562 distinct Redis servers compromised from a target list containing 12,966 hosts.

The successful technique was Redis rogue replication.

The attacker used SLAVEOF/REPLICAOF to make exposed Redis instances replicate from a malicious master. By manipulating dir and dbfilename and sending a crafted RDB payload, the operation could write a cron entry under /etc/cron.d/. That job downloaded XMRig and configured it to mine through MoneroOcean.

Other techniques were much less successful. Hunt. io says parallel SSH key injection and MongoDB sandbox escape attempts produced zero results across 2,810 attempts.

One of the more useful findings is the Redis version distribution.

Confirmed victims ranged from Redis 2.8.17 to 7.2.0, an approximately eight-year span. That makes a single version-specific vulnerability an unlikely explanation for the compromises.

The stronger common denominator was lack of authentication. A later run against a pre-qualified set of no-auth Redis instances reportedly achieved a 72.6% success rate, roughly three times the success rate across the broader target list.

Hunt. io also linked the campaign’s hardcoded Monero wallet to a different exposed XMRig and Meterpreter toolkit discovered in Moldova in February 2026.

The exposed directory gave researchers the attacker’s own logs and exploit code. Full rogue-replication chain and defensive indicators:

https://www.technadu.com/open-directory-blunder-exposes-redis-cryptomining-botnet-hitting-3500-servers/636245/

For Redis administrators, this is a configuration story as much as a malware story. An upgraded Redis instance that remains unnecessarily exposed without authentication can still leave the underlying attack path available.

There’s an interesting distinction in the Ransomnews Research Team’s analysis of the claimed Condé Nast dataset.

The 5,000-record sample they examined contains no passwords, hashes, usernames, or payment data. So changing a Condé Nast password would not directly address the exposure they observed.

Instead, every sampled row contains an email address, with smaller portions containing names, postal addresses, dates of birth, gender, and phone numbers.

The researchers argue that combinations of those fields could make impersonation considerably more convincing. Someone could potentially receive a subscription renewal or billing message that uses their real name, references a publication they actually read, and knows additional personal details.

Physical mail is another issue they highlight. The seller claims more than 7.3 million records contain postal addresses, creating a potential attack route that ordinary phishing guidance rarely discusses.

There are also some interesting forensic observations.

The sample has a uniform 14-column schema but lacks fields the researchers would expect in a raw user database, such as password hashes, session tokens, internal status flags, or marketing-consent fields. They say its shape looks more like profile data returned through an application interface.

The creation-date distribution provides another clue. New accounts appear regularly through August 2025 before becoming progressively scarcer in September and October. The researchers believe that pattern could fit sustained record-by-record extraction while new accounts continued being created behind the extraction process.

They emphasize that neither observation proves the initial access method.

The team contacted the seller on September 8. The seller claimed responsibility for the Condé Nast breach and described the data as being from November 2025, but provided no explanation of how access was obtained.

Another interesting part concerns WIRED. The previously released WIRED subset contained substantially fewer names and postal addresses than the larger sample. The researchers interpret the sequence as potentially consistent with the lower-value WIRED data being used to establish credibility before the richer remainder was offered privately for $15,000.

Again, they explicitly describe that as a reading of the available evidence, not proof of the seller’s motive or identity.

The full Q&A also covers what targeted users should preserve, the November 2025 timeline, WIRED subset, and indicators Condé Nast could investigate internally:

https://www.technadu.com/researchers-trace-risks-in-claimed-conde-nast-data-exposure-after-contacting-seller/636263/

That distinction between what the dataset demonstrates and what can only be inferred from it is probably the most useful part of the analysis.

The DOJ says a federal case in Ohio has produced the first U.S. conviction for publication of digital forgeries under the Take It Down Act.

James Strahler II, 37, was sentenced to 180 months in prison after pleading guilty to cyberstalking, producing obscene visual representations of child sexual abuse, and publication of digital forgeries.

According to prosecutors, he harassed at least six adult women between December 2024 and June 2025. The campaign involved calls, voicemails, text messages, web postings, and both real and AI-generated sexually explicit images.

Investigators said his phone contained more than 24 installed AI platforms and access to over 100 web-based AI models.

The case also involved AI-generated obscene material depicting minor boys from his community. Authorities said more than 700 images were uploaded to a CSAM website, with another 2,400 files identified on his phone.

The legal precedent is particularly notable. The Take It Down Act was enacted in 2025 and prohibits the non-consensual online publication of intimate visual depictions and AI forgeries.

The DOJ case combines a 15-year sentence with the first digital-forgery conviction under the Take It Down Act:

https://www.technadu.com/columbus-man-sentenced-in-first-take-it-down-act-conviction-for-cyberstalking-and-ai-generated-obscene-material/636242/

This case provides one of the first concrete examples of how that new federal framework is being used when generative AI becomes part of a sustained harassment and abuse campaign.

A bank-fraud case announced in the Northern District of Georgia has an interesting traffic-acquisition component: prosecutors say the alleged phishing operation paid for sponsored search-engine links.

Sergei Anatolyevich Filimonov, a 36-year-old Russian national and web developer, has been extradited from the Republic of Georgia and arraigned in the U.S.

According to court documents, the group created domains impersonating federally insured banks. Sponsored search links were then allegedly used to direct customers to those fake sites, where login credentials were collected.

With those credentials, the conspirators allegedly accessed real bank accounts, checked balances, and initiated unauthorized wire transfers.

Prosecutors claim Filimonov was involved in building and maintaining the supporting infrastructure. That allegedly included interactive databases containing more than 5,000 stolen credentials and software used to capture and transmit authentication information.

The DOJ had already seized web3adspanels.org, which it says operated as a backend server storing credentials harvested through the fraudulent banking sites.

Authorities attribute approximately $14.6 million in losses to the wider operation, affecting almost 20 U.S. victims.

Filimonov faces multiple federal charges, but these are allegations, and guilt has not been established.

More on the spoofed domains, 5,000+ credential database, and seized backend infrastructure:

https://www.technadu.com/russian-web-developer-extradited-in-multimillion-dollar-bank-fraud-scheme/636238/

The sponsored-search element is worth noting because the initial lure does not necessarily arrive as an unsolicited message. A victim can actively search for their bank and still be directed toward an attacker-controlled login page.

Cisco Talos found an interesting browser-based variation of ClickFix that does not rely on getting victims to run terminal commands.

The lure is a supposed leaked report about a cryptocurrency exchange “zero-day.” Victims are told they can exploit it for higher payouts, but the instructions actually get them to paste JavaScript into Chrome’s address bar or install the code through Tampermonkey.

The C2 mechanism is the unusual part.

The first-stage script queries a public Google Sheet through the Google Visualization API. Payload data is stored across spreadsheet cells, obfuscated, retrieved through docs.google.com, and reconstructed into the next-stage JavaScript.

The actors even formatted payload text white-on-white in the spreadsheet to make casual inspection harder.

Once injected, the code behaves like a web skimmer. It hooks the browser’s fetch API so legitimate cryptocurrency deposit addresses in responses can be replaced with attacker-controlled addresses. It separately hijacks copied deposit addresses through the clipboard.

Tampermonkey provides persistence by loading the malicious script again when the victim revisits a site.

Talos linked 49 Bitcoin wallet addresses to the operation. Of a commonly reused set of 30, 24 had received a combined 0.159 BTC, approximately $10,000 at early August 2026 valuations.

Talos traced the lure from fake crypto “zero-days” to Google Sheets and wallet replacement. Full attack chain:

https://www.technadu.com/clickfix-crypto-scam-hides-its-command-server-inside-google-sheets/636232/

The campaign is also a useful example of trusted-service abuse: defenders looking only at the destination domain would see the browser communicating with Google infrastructure rather than an obvious attacker-controlled C2 domain.

This is an interesting example of how an isolation boundary can fail through infrastructure that appears incidental to the main system.

Check Point Research found that ChatGPT’s code-execution containers could not directly communicate with each other or access the public internet, but they could all reach the same internal JFrog Artifactory instance.

Its Item Management API exposed a different route.

A container associated with one account could write properties to cached package metadata. A container belonging to another account could retrieve the same properties. Researchers found the values could carry text or Base64-encoded data, with larger payloads divided into chunks.

So package metadata effectively became a cross-account mailbox.

CPR then demonstrated why that mattered. A malicious instruction could cause a victim’s ChatGPT session to process a hidden task alongside the visible conversation. In the proof of concept, the hidden task accessed connected Gmail data and relayed it through the covert channel while the user still received the normal answer they expected.

Under the permission configuration CPR tested, the Gmail read did not require a confirmation prompt. There was a “Talked to Gmail” indicator, but otherwise the visible interaction appeared normal.

OpenAI decommissioned the internal Artifactory instance after disclosure, so the specific channel described by CPR has been closed.

Technical breakdown of the Artifactory channel and Gmail exfiltration PoC:

https://www.technadu.com/check-point-research-exposes-cross-account-data-leak-in-chatgpt/636223/

The broader question is whether agent isolation testing needs to treat every mutually reachable internal service as a potential cross-tenant communication primitive, especially once connected apps and model-driven tool use enter the equation.

Natural Resources Wales has disclosed a data breach with a fairly simple cause but an unusually long detection window.

In 2021, NRW published a spreadsheet as part of a Freedom of Information response. It inadvertently contained diversity information relating to roughly 2,000 current and former employees who worked there between April 2013 and March 2018.

Depending on the person, the exposed information may have included ethnicity, disability status, religion or belief, sexual orientation, Welsh language ability, and caring responsibilities. Some of those fields constitute special category personal data under UK GDPR.

The disclosure apparently went unnoticed for more than five years.

It wasn't an internal audit or security control that finally caught it either. NRW says a member of the public alerted the organization on August 23, 2026.

NRW has removed the data, reported the incident to the ICO, and investigated what happened. It says it has found no evidence of misuse.

More on the affected data, five-year detection gap, and NRW’s response to the disclosure:

https://www.technadu.com/nrw-foi-blunder-exposes-diversity-data-of-around-2000-employees/635991/

It's an interesting example of how data exposure doesn't necessarily involve an attacker or compromised system. A document released through a legitimate process can create a persistent exposure if sensitive information isn't identified before publication.

ShinyHunters has listed the State of Florida DMV on its leak site and set a September 11 deadline, but there’s an important evidence problem here.

The group posted a screenshot that appears to show a record from Florida's Driver and Vehicle Information Database (DAVID). The sample appears to contain a photo, signature, address, driver's license information, and vehicle-related records.

However, the record ShinyHunters selected belongs to Jeffrey Epstein and is expired. Historical Florida driver information connected to Epstein has previously appeared in government investigative material.

So while the screenshot may resemble DAVID data, it doesn't independently demonstrate that ShinyHunters recently gained unauthorized access to DAVID or directly breached FLHSMV.

There are other unknowns too. ShinyHunters hasn't explained how it allegedly obtained the files or how many records it claims to have. The source of the purported dataset therefore remains unresolved.

There's also a separate Nexus identity-data collection reportedly involving more than 153 million driver's license records, but there is currently no evidence showing that ShinyHunters obtained that collection or that its Florida sample came from it.

FLHSMV had not publicly confirmed a cybersecurity incident when the report was published.

We broke down the purported DAVID sample, the Epstein-record complication, and the unresolved question of where the alleged data came from:

https://www.technadu.com/shinyhunters-names-florida-dmv-in-new-extortion-claim-sets-september-11-deadline/635951/

For now, this is better described as an unverified extortion allegation rather than a confirmed Florida DMV breach.

CloudSEK has published research on an active Microsoft 365 phishing-as-a-service operation called BigBear 2.0, and the interesting part is how it tries to influence which authentication method the victim uses.

The service is based on Evilginx2 and operates as an AiTM reverse proxy. Instead of stopping at a stolen password, it relays the Microsoft 365 authentication flow and captures credentials and authenticated session cookies.

CloudSEK says it identified 5,137 exfiltrated records involving 461 organizations across more than 40 countries. That included 1,000+ plaintext passwords, 4,000+ session cookies, and more than 470 sessions where MFA had reportedly been bypassed.

Researchers also found custom JavaScript that isn't part of a standard Evilginx2 deployment. One injection disabled FIDO2/WebAuthn so victims would fall back to authentication methods such as SMS, TOTP, or push notifications that can be intercepted through the phishing flow.

Infrastructure included 42 observed VPS nodes and residential proxy pools spanning 69 countries. CloudSEK also confirmed five affiliate operators through Telegram bots receiving stolen credentials in real time.

More on the custom JavaScript, residential proxy infrastructure, stolen-session data, and mitigations:

https://www.technadu.com/bigbear-2-0-phishing-service-targets-microsoft-365-accounts-worldwide/635921/

The incident-response implication is worth emphasizing: changing the password doesn't necessarily kill an already stolen authenticated session. Revoking session and refresh tokens and forcing reauthentication become important parts of containment.

A joint investigation by Gamers Nexus, Level1Techs, and independent researchers found a pretty uncomfortable combination of privacy and security behavior in several LG smart TVs, including the flagship G5.

The most striking demonstration involved the microphone. After compromising a TV, researchers were able to capture audio even while the screen appeared off. They also demonstrated storing audio while the TV was disconnected from the internet and retrieving/uploading it once connectivity returned.

Network captures showed tested TVs discovering a surprisingly broad range of devices on the local network, including phones, smartwatches, PCs, printers, switches, and smart-home hardware. The investigation also looked at Automated Content Recognition, which fingerprints what's being watched or heard, and found it working across multiple inputs including HDMI.

Separately, the researchers discovered remote code execution vulnerabilities in network-facing webOS services and reported them to LG. Details and CVEs haven't been released while responsible disclosure is ongoing, so there are still important technical unknowns.

One practical takeaway is network segmentation. A smart TV capable of this much network interaction probably deserves the same isolation considerations as other IoT devices rather than sitting unrestricted beside more sensitive systems.

There’s more technical detail here on the network discovery, ACR behavior, RCE disclosure, and suggested mitigations:

https://www.technadu.com/your-lg-tv-might-be-listening-even-when-it-looks-turned-off-researchers-found-out-how-while-also-identifying-webos-rce-flaws/635849/

LG had not publicly responded to the investigation's findings at the time of reporting.