Caixa insurance unit breach exposes names and tax IDs of 7.6 and 5 more

What people are saying

The FBI says North Korean hackers stole more than $400 million in cryptocurrency through fake video calls, according to a BBC report that was widely reposted. One post on X described the scheme as using fake video calls and deepfakes. On Hacker News, one commenter said attackers had approached them through their open-source work and tried to get them to download a booby-trapped repository.

What holds up

The core claim is confirmed. The FBI says more than 900 victims fell for the scheme, which it calls FaceStealer, over the last 18 months. The Justice Department said it had seized cloud infrastructure used in the scam.

The method is well described. Officials say invitations arrive from genuine accounts that attackers have taken over on Telegram, LinkedIn, Slack and Discord. In some cases the attackers waited months, or more than a year, before taking funds.

The deepfake framing is only partly right. The FBI says the attackers are just starting to use AI-generated deepfakes of well-known crypto figures. The core trick is replayed recordings of real past victims. The FBI ties FaceStealer to a cluster known as Sapphire Sleet or UNC1069, which it says is separate from the group blamed for the Binance theft.

The developer angle is real. The FBI said attackers broke into the computer of a maintainer of widely used software and added malicious code, and that this was caught before it spread widely. The repository lure on Hacker News is one person's account and is not part of the FBI case.

Inside the threads

The developer who described the repository lure said the attackers had built a convincing fake network of sites and companies. Several commenters asked for a recording of a fake call to judge how real it looked. Another replied that the article describes replayed footage rather than AI video, which pushes back on the deepfake framing. One practitioner suggested frequent refresher training, since people cannot stay alert all the time. A large share of the thread became an argument about whether crypto should exist, and one commenter questioned North Korean attribution in general, though nothing in the FaceStealer reporting disputes it. Another commenter summed up the risk: "2% hit your blind spot or vulnerability."

Our take

We think the crypto framing leads many readers to dismiss this as someone else's problem. The vector is general: a hijacked account belonging to a trusted contact, a fake meeting page, and a fake fix the user runs. Robertson put it plainly: "This is not something we can patch." In our reading, the underrated risk is the developer workstation, because one compromised maintainer can push code into your supply chain. Binance also said attackers used a fake job interview to compromise an engineer's computer before reaching transfer approval systems. We would treat meeting invitations and recruiter contact as untrusted input, whoever appears to send them. The deepfake angle is overblown for now. Replayed real footage is cheaper, and it already works.

What to do

• Tell staff that no real meeting platform requires them to run a script or paste a terminal command to fix audio. Make that a reportable event.
• Allow only managed, approved meeting clients, and block lookalike meeting domains at the web proxy.
• Restrict developers' ability to run unvetted code on machines that hold signing keys or publish access.
• Require out-of-band confirmation before acting on links from contacts on messaging platforms, especially links sent by executives and finance approvers.

What people are saying

A commenter in the Hacker News discussion objected to headlines reading "TSMC Hacked," calling them misleading. The Record reported that the hacker demanded 3 BTC for the information. One post on X repeated that TSMC found no evidence its own systems were compromised and cited more than 46,000 employee records.

What holds up

In a Form 6-K filed with the SEC, TSMC said some current and former employee data was made available on an external website without authorization. The company said it has found no evidence that its systems have been compromised.

TSMC said the data matched information stored in the system services of a cloud service provider and was unrelated to its operations or customer data. The Record reported that the cloud service provider was not named. TSMC said it is working with the cloud vendor, investigating authorities and a third-party cybersecurity firm.

Wccftech reported that the sellers posted a sample file covering 499 employees, including addresses, bank account numbers and emergency contact details.

Our verdict is partly confirmed. In our reading, the exposure of employee data is established by TSMC itself, while the claim that TSMC's own systems were hacked runs against the filing. The 6.9 GB size and the record count rest on the seller's word.

Inside the threads

One Hacker News commenter guessed that TSMC used third-party HR software and that the software was breached. A third dismissed the statement as a perfunctory filing. One commenter speculated about the size of the crew from the ransom amount.

Our take

We think the argument over the word "hacked" matters less than where the data sat. In our reading, the filing points to a provider holding employee records, which makes this a third-party risk story. We think employees, more than chip designs, are the exposed asset here: home addresses, bank details and emergency contacts are raw material for targeted phishing and impersonation. Our take is that the trade-secret angle is overblown on current evidence. What we think is underrated is how many HR, payroll and benefits vendors hold this kind of data at most companies, often with less scrutiny than core systems get.

What to do

• Inventory which vendors hold employee personal and banking data, and confirm their breach-notification terms and timelines in contract.
• Brief staff, especially those in sensitive roles, on phishing and impersonation that uses personal details such as addresses or family contacts.
• Add a payroll and bank-detail change verification step that does not rely on email alone.
• Review your third-party risk program for how it covers cloud-hosted HR data.

What people are saying

A Citizen Lab post says a Bloomberg investigation into Penlink's ad-based surveillance system Webloc builds off Citizen Lab research and identifies additional customers of the tracking technology. On Bluesky, one post said the Bloomberg investigation finds evidence that confirms Citizen Lab's reports of potential Webloc customers. Citizen Lab said on X that its senior researcher spoke to Bloomberg about the mass surveillance tool being used by security agencies worldwide.

What holds up

Citizen Lab's April report describes Webloc as a global geolocation surveillance system that monitors hundreds of millions of people based on data purchased from consumer apps and digital advertising. It says Webloc was developed by Cobwebs Technologies and is now sold by its successor Penlink. Webloc is sold as an add-on to the social media and web intelligence system Tangles.

Working with the investigative platform VSquare, Citizen Lab found that Hungarian domestic intelligence has used Webloc since at least 2022. The report also names the national police in El Salvador as a customer. Listed U.S. customers include the U.S. military, the Texas Department of Public Safety and several police departments in Los Angeles, Dallas, Baltimore, Tucson and Durham.

Citizen Lab says it used open source research, freedom of information requests and server infrastructure mapping to identify customers in the US, El Salvador and Hungary. Its November post adds that the Austrian Ministry of the Interior has since been confirmed as a customer. Citizen Lab says Bloomberg identified customers in additional countries including the Netherlands, Germany, Mexico, Singapore, Saudi Arabia and Israel.

In our reading, the core claim is partly confirmed: Citizen Lab's own research establishes Webloc customers in several countries, while the longer list of countries rests on Bloomberg's reporting as Citizen Lab summarizes it.

Inside the threads

On Hacker News, one commenter pointed readers to the underlying pieces, noting the Bloomberg report is more recent while Citizen Lab's own reporting dates from April. Several commenters argued for ad blockers, with one saying every browser should include one by default as part of its malware and tracking protection. Another asked how browser limits on powerful ad blockers had affected this. One complained that reading Bloomberg's article requires accepting advertising cookies. Another predicted that agentic browsing would soon undermine the system. In our reading, the thread mostly skipped the point that much of this data comes from consumer apps, where a browser ad blocker offers little cover.

Our take

We think the useful lesson for a security leader is about data your employees leak through ordinary apps, not about surveillance policy debates you cannot control. In our view, the ad blocker argument is overblown as a fix, because location data sold through app software development kits never touches the browser. We think the underrated risk is travel: staff and executives visiting countries named as customers carry phones that may broadcast location to the advertising market. Our take is that this belongs in insider-risk and executive protection planning as much as in privacy policy. We also think the lawfulness questions in Europe will take years to settle, so controls on your own fleet matter more in the near term.

What to do

• We would review mobile device management settings to restrict advertising identifiers and location permissions on corporate phones.
• We would audit which apps on managed devices embed advertising or data-broker code, and remove those that are not needed for work.
• We would brief traveling executives on keeping a minimal set of apps installed and location services off when not needed.

What people are saying

Reuters reported that Uber said an unauthorized party used compromised credentials at a service provider to access its data. On X, one account said filings in three US states already count 7,870 drivers. Another post described data breaches as the new normal in the AI era.

What holds up

The notice is dated November 10. It said the provider told Uber on October 9 that the credentials had been compromised.

TechCrunch reported that Uber is notifying thousands of drivers that their personal and driver's license information was stolen at one of its tech providers. It identified that provider as Fireworks AI, which gives developers access to open artificial intelligence (AI) models. An Uber spokesperson told TechCrunch the incident affected Fireworks.ai, "which had access to some Uber data."

State filings seen by TechCrunch list 2,567 people in Massachusetts, 3,430 in South Carolina and 1,873 in Rhode Island. TechCrunch expects the number to rise as more notifications come in. Uber said it had not identified any misuse of the data to date.

Fireworks attributed its breach to a financially motivated group that sells stolen tokens for access to large language models. No known group has taken credit. The Hill described the stolen data as license plate numbers. That does not match TechCrunch's account.

We rate the claim partly confirmed. Two outlets establish the breach, the vendor and the exposure of license data. The total number of affected drivers and the attacker are not known.

Inside the threads

The r/privacy thread was small. One commenter said the case was a reason to refuse ID scans on websites. Another replied that the affected data belonged to drivers, not riders. A third took aim at timing: "Would have been nice if they let people know 10 days ago."

On X, the 7,870 figure matches the sum of the three state counts TechCrunch reported. In our reading it is a floor, not a total. The "AI era" framing is speculation in our view. Reuters describes access through compromised credentials, not a flaw in an AI model.

Our take

We think the real story is supply chain, not AI. Uber has been here before. In a multistate settlement, Texas and other states settled with Uber for $148 million over its one-year delay in reporting a breach of driver data. That settlement required Uber to protect user data it stores on third-party platforms.

On timing, about a month passed between the vendor's alert and the dated notice. That is far from a year-long delay. The underrated point is that a model-hosting provider held government ID data at all. If the attackers wanted model access tokens, the license data may have been collateral. In our reading, that makes it a data minimization failure more than a targeted theft.

Most security teams cannot say which AI vendors hold regulated personal data. We think that gap is where boards should press.

What to do

• Inventory every AI and model-hosting vendor that receives personal data, and confirm which identity documents or license numbers flow to them.
• Require short-lived, scoped credentials and prompt breach notice clauses in AI vendor contracts. Test that you can cut data connections fast.
• Map state notification triggers for driver's license numbers in advance so counsel can file within deadlines when a vendor reports an incident.

What people are saying

A post on X relayed a report from Upstox that the advisory names publicly available AI tools, including ARTEX and a multi-agent tool called PentAGI.

What holds up

The FBI FLASH says threat actors have weaponized ARTEX, an open-source, large language model (LLM)-driven agentic platform. It says they use it to automate intrusions from reconnaissance through data exfiltration, and that a variety of malicious actors have done so since at least August 2026. The FBI reports some intrusions went from initial targeting to privileged access in under three hours.

The campaigns it names include attacks on South Korean financial institutions that exposed personal information of about 67,000 individuals. They also include a supply chain compromise of ConnectWise Cloud Backup customers that enabled access to more than 2,250 downstream tenants.

The FBI says the framework still spreads through community forks, archived copies and a commercial version, ARTEX PRO. As of early November, researchers had identified over 1,600 publicly exposed ARTEX console instances. ARTEX ships no model of its own and plugs into external LLM providers.

CERT-EU, the cybersecurity service for EU institutions, separately reported several threat actors using ARTEX. It said AI-driven activity against its own constituency highly likely involved the tool. Verdict: confirmed.

Inside the threads

The X post framed the advisory as covering "the ARTEX family of LLM-based tools" rather than a single product. In our reading, the easy misread is that AI tooling means novel exploits. The FBI's initial-access list is mostly familiar weaknesses, including abused cross-account cloud trust from a partner tenant and compromised third-party vendor credentials.

Our take

We think the important number is three hours, not 67,000. When a tool can chain small misconfigurations at machine speed, a patch-and-triage cycle measured in weeks loses to it. CERT-EU makes the point directly: ARTEX can work through low-complexity misconfigurations a human tester would notice but lack time to check. Our take is that the "AI hacking" framing is overblown. The more useful framing is that your backlog of low-severity findings is now an attack path. The underrated part is third-party exposure: partner tenant trust and vendor federation appear in the FBI's access list, and the ConnectWise case shows how one provider fans out to thousands of customers. Taking down the original repository changed little, in our reading, because forks and a paid version remain.

What to do

• Have your security operations team run the FLASH IOCs against network and cloud logs, and hunt for automated scanning patterns against internet-facing assets.

• Keep low-severity findings in the remediation cycle instead of accepting them as risk, since chained minor issues are the stated concern.

• Review cross-tenant cloud trust and vendor federation, and make sure monitoring covers your own AI tools and AI-connected assets.