blog.pypi.org
Mike Fiedler
PyPI Admin, Safety & Security Engineer (PSF)
Shai-Hulud is a great worm, not yet a snake. Attack on npm ecosystem may have implications for PyPI.
PyPI and Shai-Hulud: Staying Secure Amid Emerging Threats
An attack on the npm ecosystem continues to evolve, exploiting compromised accounts to publish malicious packages. This campaign, dubbed Shai-Hulud, has targeted large volumes of packages in the JavaScript ecosystem, exfiltrating credentials to further propagate itself.
PyPI has not been exploited, however some PyPI credentials were found exposed in compromised repositories. We've revoked these tokens as a precaution, there's no evidence they have been used maliciously. This post raises awareness about the attack and encourages proactive steps to secure your accounts, especially if you're using build platforms to publish packages to PyPI.
How does this relate to PyPI?
This week, a security researcher disclosed long-lived PyPI credentials exposed as part of the Shai-Hulud campaign. The credentials were found in GitHub repositories (stored as repository secrets), and were still valid. We saw an attack with insecure workflow settings for Ultralytics in 2024.
While the campaign primarily targets npm, some projects use monorepo setups, publishing both JavaScript packages to npmjs.com and Python packages to PyPI from the same repository. When attackers compromise these repositories, they can extract credentials for multiple platforms.
We investigated the reported credentials and found they were associated with accounts that hadn't published recently. We've revoked these credentials and reached out to affected users to advise them to rotate any remaining tokens.
What can I do to protect my PyPI account?
Here are security practices to protect your PyPI account:
Use Trusted Publishing: If you are using a build platform to publish packages to PyPI, consider using a Trusted Publisher. This eliminates the need to manage long-lived authentication tokens, reducing the risk of credential exposure. Trusted Publishing uses short-lived, scoped tokens for each build, minimizing the impact of any potential compromise. This approach has risen in popularity, with other registries like Crates.io, RubyGems, and npmjs.com adopting similar models.
When using GitHub Actions, consider layering in additional security measures, like requiring human approval via GitHub Environments before publishing. This blog post from pyOpenSci has detailed guidance on adding manual review steps to GitHub Actions workflows.
Audit your workflows for misconfiguration: Review your GitHub Actions workflows for any potential security issues. Tools like zizmor and CodeQL can help identify vulnerabilities in your CI/CD pipelines. Adopt scanning as automated actions for the repository to catch future issues.
Review your account activity: Regularly check your PyPI account activity for any unauthorized actions. If you notice any suspicious activity, report it to the PyPI security team immediately.
Taking any of these steps helps mitigate the risk of compromise and keeps packages secure.
themoscowtimes.com
Dec. 2, 2025
Hundreds of Porsche vehicles across Russia have been rendered undriveable after a failure in their factory-installed satellite security system, according to reports from owners and dealerships.
Drivers in Moscow, Krasnodar and other cities began reporting sudden engine shutdowns and fuel-delivery blockages last week, effectively immobilizing their vehicles.
Rolf, Russia’s largest dealership group, said service requests spiked on Friday as cars lost connection to their onboard alarm modules, which are linked via satellite.
The outage affects all Porsche models and engine types, and any vehicle could potentially lock itself automatically, a Rolf representative told the RBC news website.
“It’s possible this was done deliberately,” the representative was quoted as saying, though no evidence has emerged to support that claim.
Owners’ groups say the problem appears tied to the Vehicle Tracking System, or VTS, which is an onboard security module.
The Russian Porsche Macan Club said some drivers had restored function by disabling or rebooting the VTS, while others reported success after disconnecting their car batteries for up to 10 hours, according to the Telegram channel Mash.
Rolf said specialists were still investigating the root cause of the problem. Porsche’s office in Russia and its global headquarters in Germany have not yet commented on the system failure.
Porsche halted deliveries and suspended its commercial operations in Russia after the full-scale invasion of Ukraine in February 2022. However, the company still retains ownership of three subsidiaries in the country, which it has so far been unable to sell.
The Guardian
Dan Milmo Global technology editor.
Wed 3 Dec 2025 07.00 CET
Researchers uncovered 354 AI-focused accounts that had accumulated 4.5bn views in a month
Hundreds of accounts on TikTok are garnering billions of views by pumping out AI-generated content, including anti-immigrant and sexualised material, according to a report.
Researchers said they had uncovered 354 AI-focused accounts pushing 43,000 posts made with generative AI tools and accumulating 4.5bn views over a month-long period.
According to AI Forensics, a Paris-based non-profit, some of these accounts attempt to game TikTok’s algorithm – which decides what content users see – by posting large amounts of content in the hope that it goes viral.
One posted up to 70 times a day or at the same time of day, an indication of an automated account, and most of the accounts were launched at the beginning of the year.
Last month TikTok revealed there were at least 1.3bn AI-generated posts on the platform. More than 100m pieces of content are uploaded to the platform every day, indicating that labelled AI material is a small part of TikTok’s catalogue. TikTok is also giving users the option of reducing the amount of AI content they see.
Of the accounts that posted content most frequently, half focused on content related to the female body. “These AI women are always stereotypically attractive, with sexualised attire or cleavage,” the report said.
AI Forensics found the accounts did not label half of the content they posted and less than 2% carried the TikTok label for AI content – which the nonprofit warned could increase the material’s deceptive potential. Researchers added that the accounts sometimes escape TikTok’s moderation for months, despite posting content barred by its terms of service.
Dozens of the accounts revealed in the study have subsequently been deleted, researchers said, indicating that some had been taken down by moderators.
Some of the content took the form of fake broadcast news segments with anti-immigrant narratives and material sexualising female bodies, including girls that appeared to be underage. The female body category accounted for half of the top 10 most active accounts, said AI Forensics, while some of the fake news pieces featured known broadcasting brands such as Sky News and ABC.
Some of the posts have been taken down by TikTok after they were referred to the platform by the Guardian.
TikTok said the report’s claims were “unsubstantiated” and the researchers had singled it out for an issue that was affecting multiple platforms. In August the Guardian revealed that nearly one in 10 of the fastest growing YouTube channels globally were showing only AI-generated content.
“On TikTok, we remove harmful AIGC [artificial intelligence-generated content], block hundreds of millions of bot accounts from being created, invest in industry-leading AI-labelling technologies and empower people with tools and education to control how they experience this content on our platform,” a TikTok spokesperson said.
The most popular accounts highlighted by AI Forensics in terms of views had posted “slop”, the term for AI-made content that is nonsensical, bizarre and designed to clutter up people’s social media feeds – such as animals competing in an Olympic diving contest or talking babies. The researchers acknowledged that some of the slop content was “entertaining” and “cute”.
| TechCrunch
Zack Whittaker
10:55 AM PST · December 3, 2025
Marquis said ransomware hackers stole reams of banking customer data, containing personal information and financial records, as well as Social Security numbers, belonging to hundreds of thousands of people. The number of affected people is expected to rise.
Fintech company Marquis is notifying dozens of U.S. banks and credit unions that they had customer data stolen in a cyberattack earlier this year.
Details of the cyberattack emerged this week after Marquis filed data breach notices with several U.S. states confirming its August 14 incident as a ransomware attack.
Texas-based Marquis is a marketing and compliance provider that allows banks and other financial institutions to collect and visualize all of their customer data in one place. The company counts more than 700 banking and credit union customers on its website. As such, Marquis has access to and stores large amounts of data belonging to consumer banking customers across the United States.
At least 400,000 people are so far confirmed affected by the data breach, according to legally required disclosures filed in the states of Iowa, Maine, Texas, Massachusetts, and New Hampshire that TechCrunch has reviewed.
Texas has the largest number of state residents so far who had data stolen in the breach, affecting at least 354,000 people.
Marquis said in its notice with Maine’s attorney general that banking customers with the Maine State Credit Union accounted for the majority of its data breach notifications, or around one-in-nine people who are known to be affected throughout the state.
The number of individuals affected by the breach is expected to rise as more data breach notifications roll in from other states.
Marquis said the hackers stole customer names, dates of birth, postal addresses, and financial information, such as bank account, debit, and credit card numbers. Marquis said the hackers also stole customers’ Social Security numbers.
According to its most recent notices, Marquis blamed the ransomware attack on hackers who exploited a vulnerability in its SonicWall firewall. The vulnerability was considered a zero-day, meaning the flaw was not known to SonicWall or its customers before it was maliciously exploited by hackers.
Marquis did not attribute the ransomware attack to a particular group, but the Akira ransomware gang was reportedly behind the mass-hacks targeting SonicWall customers at the time.
TechCrunch asked Marquis if it is aware of the total number of people affected by the breach, and if Marquis received any communication from the hackers or if the company paid a ransom, but we did not hear back by the time of publication.
sicuranext.com
Claudio Bono
01 Dec 2025
Earlier this year, our CTI team set out to build something we'd been thinking about for a while: a phishing intelligence pipeline that could actually keep up with the threat. We combined feeds from hundreds of independent sources with our own real-time hunt for suspicious SSL/TLS certificates. The goal was simple: get better visibility into what attackers are actually doing, not what they were doing six months ago.
Last quarter's numbers hit harder than we expected: 42,000+ validated URLs and domains, all actively serving phishing kits, command-and-control infrastructure, or payload delivery.
This isn't your grandfather's phishing problem. We're not talking about misspelled PayPal domains and broken English. What we're seeing is organized, efficient, and frankly, impressive in all the wrong ways. This research breaks down the infrastructure, TTPs, and operational patterns behind modern phishing—and what it means for anyone trying to defend against it.
Finding #1: All Roads Lead to Cloudflare
Here's the headline: 68% of all phishing infrastructure we tracked lives on Cloudflare.
Provider Domains % of Total
Cloudflare 17,202 68.0%
GCP 3,414 13.5%
AWS 2,185 8.6%
Azure 1,355 5.4%
This isn't random. Cloudflare's free tier is a gift to threat actors—zero upfront cost, world-class DDoS protection (yes, really), and proxy services that completely mask origin servers. Good luck tracking down the actual host when everything's bouncing through Cloudflare's edge network.
We're seeing thousands malicious domains clustered on AS13335 alone. That's Cloudflare's primary ASN, and it's become the de facto home base for phishing operations worldwide.
The CDN Divide: Two Strategies, One Ecosystem
When we looked at the 12,635 unique IPs hosting these IOCs, a clear pattern emerged. The threat landscape has forked:
51.54% direct hosting – Think disposable infrastructure. Spin it up fast, burn it down faster. Perfect for smishing blasts and hit-and-run campaigns.
48.46% CDN/proxy-protected: The long game. These setups are built to survive, leveraging CDNs (92% Cloudflare, naturally) for origin obfuscation and anti-takedown resilience.
Here's the problem: your IP-based blocking protection? It works on roughly half the threat landscape. The other half just laughs at you from behind Cloudflare's proxy. You need URL filtering, domain heuristics, and TLS fingerprinting now. IP blocks alone are a coin flip.
And before anyone says "these domains must be unstable", we saw a 96.16% mean DNS resolution rate. These operators run infrastructure like a Fortune 500 company. High availability, minimal downtime, proper DevOps hygiene. It's professional-grade crime.
Finding #2: Abusing Trust at Scale
Forget .xyz and .tk domains. Attackers have moved upmarket.
TLD Count Why They Use It
.com 11,324 Universal legitimacy
.dev 7,389 Targets developers
.app 2,992 Mobile/SaaS impersonation
.io 2,425 Tech sector credibility
.cc 1,745 Cheap, minimal oversight
The surge in .dev and .app domains tells you everything. Attackers aren't just going after your CFO anymore: they're targeting developers. Fake GitHub OAuth flows, spoofed Vercel deployment pages, bogus npm package sites. They're hunting credentials from the people who actually understand security, betting (correctly) that a something.dev domain gets less scrutiny than something-phishing.tk.
Free Hosting: The Perfect Cover
Now pair this with free hosting platforms, and you get a disaster: 72% of domains in our dataset used obfuscation via legitimate services.
Vercel: 1,942 domains
GitHub Pages: 1,540 domains
GoDaddy Sites: 734 domains
Webflow: 669 domains
Try explaining to your CISO why you need to block github.io or vercel.app. You can't. Your developers need those. Your business uses those. Attackers know this, and they're weaponizing it. Domain reputation systems collapse when every phishing page sits under a trusted parent domain.
Finding #3: PhaaS and the Industrialization of Crime
We need to stop calling these "phishing kits." That undersells what we're dealing with.
What we're seeing is Phishing-as-a-Service (PhaaS): full-stack criminal SaaS platforms. Services like Caffeine - now offline - and W3LL offer subscription-based access to complete attack infrastructure: hosting, templates, exfiltration pipelines, even customer support. They've turned phishing into a commodity anyone can buy.
The real nightmare feature? MFA bypass. Kits like EvilProxy and Tycoon 2FA don't bother stealing passwords anymore. They operate as adversary-in-the-middle (AitM) proxies, sitting between the victim and the legitimate service. User authenticates, kit intercepts, passes creds through to the real site, then steals the resulting session cookie. No password needed. No MFA challenge. Just instant account access.
These platforms also ship with serious evasion tech:
Geofencing to block security researchers by IP range
User-Agent Based Cloaking that targets devices by browser user agent: often the final landing page is only visible on mobile devices browsers
DevTools detection (open F12, page immediately stop working)
Cloudflare CAPTCHA to filter out automated scanners
Over the past four months, we clustered 20 distinct phishing clusters based on shared infrastructure fingerprints: same rotated IPs, same registrars, identical evasion patterns and obfuscation methods. This isn't a bunch of script kiddies copying code. It's coordinated, engineered operations with centralized data management and exfiltration workflows.
Almost 60% of the observed IOCs are deemed to be linked with PhaaS, this means a global tendency to separate those who produce and manage actual infrastructure from those (often non-technical users) who use it (for a fee), hoping to make a significant profit by reselling stolen data.
Finding #4: Meta in the Crosshairs
If there's one target dominating the landscape, it's Meta. 10,267 mentions: 42% of all brand impersonation we tracked.
Brand Mentions Attack Type
Meta 10,267 Facebook/Instagram/WhatsApp creds
Amazon 2,617 Payment data, account takeover
Netflix 2,450 Subscription scams
PayPal 1,993 Financial fraud, redirects
Stripe 1,571 Merchant account compromise
Why Meta? Three billion users. Multiple attack surfaces. Credential reuse across platforms. It's target-rich and full of high-value accounts. The focus on Stripe and PayPal shows attackers aren't just after creds anymore: they're after money. Direct financial fraud, merchant compromise, payment interception.
What This Means for Defense
The era of "just block the domain" is over. We're up against industrialized, adaptive, professionally-run adversaries. Deterministic detection is dead. You can't regex your way out of this anymore, defenses need to evolve:
CDN-aware detection – IP blocking is 50% effective at best
Behavioral analysis – Focus on session anomalies, not just domains
TLS fingerprinting – Track certificate patterns and issuance velocity
Hunt for PhaaS indicators – Cluster campaigns by shared infrastructure
User education that doesn't suck – Stop educating people talking about domain typosquotting or http vs https concepts: teach people what real-scenario looks like in practice.
This isn't FUD. This is what 42,000 live phishing sites look like when you actually go hunting for them. The threat is real, it's organized, and it's not slowing down.
What Comes Next: Diving Deep into the Criminal Engine
In our next in-depth analysis, we will reveal the real infrastructure that powers this industrialization. We will guide you step by step through a modern and complex PhaaS platform, demonstrating exactly how the TTPs described in this article function in a real operational environment.
| The Record from Recorded Future News
therecord.media
Jonathan Greig
December 1st, 2025
A recent cyberattack on South Korea’s largest cryptocurrency exchange was allegedly conducted by a North Korean government-backed hacking group.
Yonhap News Agency reported on Friday that South Korean government officials are involved in the investigation surrounding $30 million worth of cryptocurrency that was stolen from Upbit on Wednesday evening.
On Friday, South Korean officials told the news outlet that North Korea’s Lazarus hacking group was likely involved in the theft based on the tactics used to break into the cryptocurrency platform and the methods deployed to launder the stolen funds.
Investigators believe the hackers impersonated administrators at Upbit before transferring about $30 million.
In a statement, the company called the theft an “abnormal withdrawal” and said it is in the process of investigating the attack.
Oh Kyung-seok, CEO of parent company Dunamu, added that the platform has suspended deposits and withdrawals.
All losses will be covered by Upbit. The attack came one day after South Korean internet giant Naver purchased Dunamu for $10 billion.
“After detecting the abnormal withdrawal, Upbit immediately conducted an emergency security review of the relevant network and wallet systems,” the CEO said. “To prevent further abnormal transfers, all assets have been transferred to a secure cold wallet.”
Upbit tracked some of the stolen funds to another wallet on Thursday and is trying to freeze some of the assets so they cannot be moved further.
Investigators noted that the attack bears the hallmarks of a previous incident in 2019 when about $40 million was stolen from Upbit. That attack was also attributed to Lazarus — one of the most prolific state-backed hacking groups.
Lazarus is allegedly organized within the North Korean Reconnaissance General Bureau and has stolen billions worth of cryptocurrency over the last nine years, with blockchain monitoring firm Chainalysis saying hacking groups connected to North Korea’s government stole $1.3 billion worth of cryptocurrency across 47 incidents in 2024.
The group is accused of stealing $1.5 billion from Dubai-based crypto platform Bybit in February. The United Nations said last year that it is tracking dozens of incidents over a five-year period that have netted North Korea $3 billion.
bleepingcomputer.com
By Bill Toulas
December 1, 2025
The popular open-source SmartTube YouTube client for Android TV was compromised after an attacker gained access to the developer's signing keys, leading to a malicious update being pushed to users.
The compromise became known when multiple users reported that Play Protect, Android's built-in antivirus module, blocked SmartTube on their devices and warned them of a risk.
The developer of SmartTube, Yuriy Yuliskov, admitted that his digital keys were compromised late last week, leading to the injection of malware into the app.
Yuliskov revoked the old signature and said he would soon publish a new version with a separate app ID, urging users to move to that one instead.
SmartTube is one of the most widely downloaded third-party YouTube clients for Android TVs, Fire TV sticks, Android TV boxes, and similar devices.
Its popularity stems from the fact that it is free, can block ads, and performs well on underpowered devices.
A user who reverse-engineered the compromised SmartTube version number 30.51 found that it includes a hidden native library named libalphasdk.so [VirusTotal]. This library does not exist in the public source code, so it is being injected into release builds.
"Possibly a malware. This file is not part of my project or any SDK I use. Its presence in the APK is unexpected and suspicious. I recommend caution until its origin is verified," cautioned Yuliskov on a GitHub thread.
The library runs silently in the background without user interaction, fingerprints the host device, registers it with a remote backend, and periodically sends metrics and retrieves configuration via an encrypted communications channel.
All this happens without any visible indication to the user. While there's no evidence of malicious activity such as account theft or participation in DDoS botnets, the risk of enabling such activities at any time is high.
Although the developer announced on Telegram the release of safe beta and stable test builds, they have not reached the project's official GitHub repository yet.
Also, the developer has not provided full details of what exactly happened, which has created trust issues in the community.
Yuliskov promised to address all concerns once the final release of the new app is pushed to the F-Droid store.
Until the developer transparently discloses all points publicly in a detailed post-mortem, users are recommended to stay on older, known-to-be-safe builds, avoid logging in with premium accounts, and turn off auto-updates.
Impacted users are also recommended to reset their Google Account passwords, check their account console for unauthorized access, and remove services they don't recognize.
At this time, it is unclear exactly when the compromise occurred or which versions of SmartTube are safe to use. One user reported that Play Protect doesn't flag version 30.19, so it appears safe.
BleepingComputer has contacted Yuliskov to determine which versions of the SmartTube app were compromised, and he responded with the following:
"Some of the older builds that appeared on GitHub were unintentionally compromised due to malware present on my development machine at the time they were created. As soon as I noticed the issue in late November, I immediately wiped the system and cleaned the environment, including the GitHub repository."
"I became aware of the malware issue around version 30.47, but as users reported lately it started around version 30.43. So, for my understanding the compromised versions are: 30.43-30.47."
"After cleaning the environment, a couple of builds were released using the previous key (prepared on the clean system), but from version 30.55 onward I switched to a new key for full security. The differing hashes for 30.47 Stable v7a are likely the result of attempts to restore that build after cleaning the infected system."
Update 12/2 - Added developer comment and information.
nextron-systems.com - Nextron Systems
by Marius BenthinNov 28, 2025
Over the last weeks we’ve been running a new internal artifact-scanning service across several large ecosystems. It’s still growing feature-wise, LLM scoring and a few other bits are being added, but the core pipeline is already pulling huge amounts of stuff every week – Docker Hub images, PyPI packages, NPM modules, Chrome extensions, VS Code extensions. Everything gets thrown through our signature set that’s built to flag obfuscated JavaScript, encoded payloads, suspicious command stubs, reverse shells, and the usual “why is this here” indicators.
The only reason this works at the scale we need is THOR Thunderstorm running in Docker. That backend handles the heavy lifting for millions of files, so the pipeline just feeds artifacts into it at a steady rate. Same component is available to customers; if someone wants to plug this kind of scanning into their own CI or ingestion workflow, Thunderstorm can be used exactly the way we use it internally.
We review millions of files; most of the noise is the classic JS-obfuscation stuff that maintainers use to “protect” code; ok… but buried in the noise you find the things that shouldn’t be there at all. And one of those popped up this week.
Our artifact scanning approach
We published an article this year about blind spots in security tooling and why malicious artifacts keep slipping through the standard AV checks. That’s the gap this whole setup is meant to cover. AV engines choke on obfuscated scripts, and LLMs fall over as soon as you throw them industrial-scale volume. Thunderstorm sits in the middle – signature coverage that hits encoded payloads, weird script constructs, stagers, reverse shells, etc., plus the ability to scale horizontally in containers.
The workflow is simple:
pull artifacts from Docker Hub, PyPI, NPM, the VS Code Marketplace, Chrome Web Store;
unpack them into individual files;
feed them into Thunderstorm;
store all hits;
manually review anything above a certain score.
We run these scans continuously. The goal is to surface the obviously malicious uploads quickly and not get buried in the endless “maybe suspicious” noise.
The finding: malicious VS Code extension with Rust implants
While reviewing flagged VS Code extensions, Marius stumbled over an extension named “Icon Theme: Material”, published under the account “IconKiefApp”. It mimics the legitimate and extremely popular Material Icon Theme extension by Philipp Kief. Same name pattern, same visuals, but not the same author.
The fake extension had more than 16,000 installs already.
Inside the package we found two Rust implants: one Mach-O, one Windows PE. The paths looked like this:
icon-theme-materiall.5.29.1/extension/dist/extension/desktop/
The Mach-O binary contains a user-path string identical in style to the GlassWorm samples reported recently by Koi (VT sample link below). The PE implant shows the same structure. Both binaries are definitely not part of any real icon-theme extension.
The malicious extension:
https://marketplace.visualstudio.com/items?itemName=Iconkieftwo.icon-theme-materiall
The legitimate one:
https://marketplace.visualstudio.com/items?itemName=PKief.material-icon-theme
Related GlassWorm sample:
https://www.virustotal.com/gui/file/eafeccc6925130db1ebc5150b8922bf3371ab94dbbc2d600d9cf7cd6849b056e
IOCs
VS Code Extension
0878f3c59755ffaf0b639c1b2f6e8fed552724a50eb2878c3ba21cf8eb4e2ab6
icon-theme-materiall.5.29.1.zip
Rust Implants
6ebeb188f3cc3b647c4460c0b8e41b75d057747c662f4cd7912d77deaccfd2f2
(os.node) PE
fb07743d139f72fca4616b01308f1f705f02fda72988027bc68e9316655eadda
(darwin.node) MACHO
Signatures
YARA rules that triggered on the samples:
SUSP_Implant_Indicators_Jul24_1
SUSP_HKTL_Gen_Pattern_Feb25_2
Status
We already reported the malicious extension to Microsoft. The previous version, 5.29.0, didn’t contain any implants. The publisher then pushed a new update, version 5.29.1, on 28 November 2025 at 11:34, and that one does include the two Rust implants.
As of now (28 November, 14:00 CET), the malicious 5.29.1 release is still online. We expect Microsoft to remove the extension from the Marketplace. We’ll share more details once we’ve fully unpacked both binaries and mapped the overlaps with the GlassWorm activity.
Closing
This is exactly the kind of thing the artifact-scanner was built for. Package ecosystems attract opportunistic uploads; VS Code extensions are no different. We’ll keep scanning the big ecosystems and publish findings when they’re clearly malicious. If you maintain an extension or a package registry and want to compare detections with us, feel free to reach out; we’re adding more sources week by week.
Update 29.11.2025
Since we published the initial post, a full technical analysis of the Rust implants contained in the malicious extension has been completed. The detailed breakdown is now available in our follow-up article: “Analysis of the Rust implants found in the malicious VS Code extension”.
That post describes how the implants operate on Windows and macOS, their command-and-control mechanism via a Solana-based wallet, the encrypted-payload delivery, and fallback techniques including a hidden Google Calendar-based channel.
Readers who want full technical context, IOCs and deeper insight are encouraged to review the new analysis.
Post-mortem of Shai-Hulud attack on November 24th, 2025
Oliver Browne
Nov 26, 2025
PostHog news - posthog.com
At 4:11 AM UTC on November 24th, a number of our SDKs and other packages were compromised, with a malicious self-replicating worm - Shai-Hulud 2.0. New versions were published to npm, which contained a preinstall script that:
Scanned the environment the install script was running in for credentials of any kind using Trufflehog, an open-source security tool that searches codebases, Git histories, and other data sources for secrets.
Exfiltrated those credentials by creating a new public repository on GitHub and pushing the credentials to it.
Used any npm credentials found to publish malicious packages to npm, propagating the breach.By 9:30 AM UTC, we had identified the malicious packages, deleted them, and revoked the tokens used to publish them. We also began the process of rolling all potentially compromised credentials pre-emptively, although we had not at the time established how our own npm credentials had been compromised (we have now, details below).
The attack only affected our Javascript SDKs published in npm. The most relevant compromised packages and versions were:
posthog-node 4.18.1, 5.13.3 and 5.11.3
posthog-js 1.297.3
posthog-react-native 4.11.1
posthog-docusaurus 2.0.6
posthog-react-native-session-replay@1.2.2
@posthog/agent@1.24.1
@posthog/ai@7.1.2
@posthog/cli@0.5.15What should you do?
If you are using the script version of PostHog you were not affected since the worm spread via the preinstall step when installing your dependencies on your development/CI/production machines.
If you are using one of our Javascript SDKs, our recommendations are to:
Look for the malicious files locally, in your home folder, or your document roots:Terminal
find . -name "setup_bun.js" \
-o -name "bun_environment.js" \
-o -name "cloud.json" \
-o -name "contents.json" \
-o -name "environment.json" \
-o -name "truffleSecrets.json"
Check npm logs for suspicious entries:Terminal
grep -R "shai" ~/.npm/_logs
grep -R "preinstall" ~/.npm/_logs
Delete any cached dependencies:Terminal
rm -rf node_modules
npm cache clean --force
pnpm cache delete
Pin any dependencies to a known-good version (in our case, all the latest published versions, which have been published after we identified the attack, are known-good), and then reinstall your dependencies.
We also suggest you make use of the minimumReleaseAge setting present both in yarn and pnpm. By setting this to a high enough value (like 3 days), you can make sure you won't be hit by these vulnerabilities before researchers, package managers, and library maintainers have the chance to wipe the malicious packages.
How did it happen?
PostHog's own package publishing credentials were not compromised by the worm described above. We were targeted directly, as were a number of other major vendors, to act as a "patient zero" for this attack.
The first step the attacker took was to steal the Github Personal Access Token of one of our bots, and then use that to steal the rest of the Github secrets available in our CI runners, which included this npm token. These steps were done days before the attack on the 24th of November.
At 5:40PM on November 18th, now-deleted user brwjbowkevj opened a pull request against our posthog repository, including this commit. This PR changed the code of a script executed by a workflow we were running against external contributions, modifying it to send the secrets available during that script's execution to a webhook controlled by the attacker. These secrets included the Github Personal Access Token of one of our bots, which had broad repo write permissions across our organization. The PR itself was deleted along with the fork it came from when the user was deleted, but the commit was not.
The PR was opened, the workflow run, and the PR closed within the space of 1 minute (screenshots include timestamps in UTC+2, the author's timezone):
initial PR logs
At 3:28 PM UTC on November 23rd, the attacker used these credentials to delete a workflow run. We believe this was a test, to see if the stolen credentials were still valid (it was successful).
At 3:43 PM, the attacker used these credentials again, to create another commit masquerading, by chance, as the report's author (we believe this was a randomly chosen branch on which the author happened to be the last legitimate contributor given that the author does not possess any special privileges on his GitHub account).
This commit was pushed directly as a detached commit, not as part of a pull request or similar. In it, the attacker modified an arbitrary Lint PR workflow directly to exfiltrate all of our Github secrets. Unlike the previous PR attack, which could only modify the script called from the workflow, and as such could only exfiltrate our bot PAT, this commit had full write access to our repository given the ultra-permissive PAT which meant they could run arbitrary code on the scope of our Github Actions runners.
With that done, the attacker was able to run their modified workflow, and did so at 3:45 PM UTC:
Follow up commit workflow runs
The principal associated with these workflow actions is posthog-bot, our Github bot user, whose PAT was stolen in the initial PR. We were only able to identify this specific commit as the pivot after the fact using Github audit logs, due to the attackers deletion of the workflow run following its completion.
At this point, the attacker had our npm publishing token, and 12 hours later, at 4:11 AM UTC the following morning, published the malicious packages to npm, starting the worm.
As noted, PostHog was not the only vendor used as an initial vector for this broader attack. We expect other vendors will be able to identify similar attack patterns in their own audit logs.
Why did it happen?
PostHog is proudly open-source, and that means a lot of our repositories frequently receive external contributions (thank you).
For external contributions, we want to automatically assign reviewers depending on which parts of our codebase the contribution changed. GitHub's CODEOWNERS file is typically used for this, but we want the review to be a "soft" requirement, rather than blocking the PR for internal contributors who might be working on code they don't own.
We had a workflow, auto-assign-reviewers.yaml, which was supposed to do this, but it never really worked for external contributions since it required manual approval defeating the purpose of automatically tagging the right people without manual interference.
One of our engineers figured out this was because it triggered on: pull_request which means external contributions (which come from forks, rather than branches in the repo like internal contributions) would not have the workflow automatically run. The fix for this was changing the trigger to be on: pull_request_target, which runs the workflow as it's defined in the PR target repo/branch, and is therefore considered safe to auto-run.
Our engineer opened a PR to make this change, and also make some fixes to the script, including checking out the current branch, rather than the PR base branch, so that the diffing would work properly. This change seemed safe, as our understanding of on: pull_request_target was, roughly, "ok, this runs the code as it is in master/the target repo".
This was a dangerous misconception, for a few reasons:
on: pull_request_target only ensures the workflow is being run as defined in the PR target, not the code being run - that's controlled by the checkout step.
This particular workflow executed code from within the repo - a script called assign-reviewers.js, which was initially developed for internal (and crucially, trusted) auto-assignment, but was now being used for external assignment too.
The workflow was modified to manually checkout the git commit of the PR head, rather than the PR base, so that the diffing would work correctly for external contributions, but this meant that the code being run was controlled by the PR author.These pieces together meant it was possible for a pull request which modified assign-reviewers.js to run arbitrary code, within the context of a trusted CI run, and therefore steal our bot token.
Why did this workflow change get merged? Honestly, security is unintuitive.
The engineer making the change thought pull_request_target ensured that the version of assign-reviewers.js being executed, a script stored in .github/scripts in the repository, would be the one on master, rather than the one in the PR.
The engineer reviewing the PR thought the same.
None of us noticed the security hole in the month and a half between the PR being merged and the attack (the PR making this change was merged on the 11th of September). This workflow change was even flagged by one of our static analysis tools before merge, but we explicitly dismissed the alert because we mistakenly thought our usage was safe.Workflow rules, triggers and execution contexts are hard to reason about - so hard to reason about that Github is actively making changes to make them simpler and closer to our understanding above. Although, in our case, these changes would not have protected us against the initial attack.
Notably, we identified copycat attacks on the following day attempting to leverage the same vulnerability, and while we prevented those, we had to take frustratingly manual and uncertain measures to do so. The changes Github is making to the behaviour of pull_request_target would have prevented those copycats automatically for us.
How are we preventing it from happening again?
This is the largest and most impactful security incident we've ever had. We feel terrible about it, and we're doing everything we can to prevent something like this from happening again.
I won't enumerate all the process and posture changes we're implementing here, beyond saying:
We've significantly tightened our package release workflows (moving to the trusted publisher model).
Increased the scrutiny any PR modifying a workflow file gets (requiring a specific review from someone on our security team).
Switched to pnpm 10 (to disable preinstall/postinstall scripts and use minimumReleaseAge).
Re-worked our Github secrets management to make our response to incidents like this faster and more robust.PostHog is, in many of our engineers minds, first and foremost a data company. We've grown a lot in the last few years, and for that time, our focus has always been on data security - ensuring the data you send us is safe, that our cloud environments are secure, and that we never expose personal information. This kind of attack, being leveraged as an initial vector for an ecosystem-wide worm, simply wasn't something we'd prepared for.
At a higher level, we've started to take broad security a lot more seriously, even prior to this incident. In July, we hired Tom P, who's been fully dedicated to improving our overall security posture. Both our incident response and the analysis in this post-mortem simply wouldn't have been possible without the tools and practices he's put in place, and while there's a huge amount still to do, we feel good about the progress we're making. We have to do better here, and we feel confident we will.
Given the prominence of this attack and our desire to take this work seriously, we wanted to use this as a chance to say that if you'd like to work in our security team, and write post-mortems like these (or, better still, write analysis like this about attacks you stopped), we're always looking for new talent. Email tom.p at posthog dot com, or apply directly on our careers page.
| Europol
europol.europa.eu
From 24 to 28 November 2025, Europol supported an action week conducted by law enforcement authorities from Switzerland and Germany in Zurich, Switzerland. The operation focused on taking down the illegal cryptocurrency mixing service ‘Cryptomixer’, which is suspected of facilitating cybercrime and money laundering.
Open in modalOP Olympia - this domain has been seized
Three servers were seized in Switzerland, along with the cryptomixer.io domain. The operation resulted in the confiscation of over 12 terabytes of data and more than EUR 25 million worth of the cryptocurrency Bitcoin. After the illegal service was taken over and shut down, law enforcement placed a seizure banner on the website.
A service to obfuscate the origin of criminal funds
Cryptomixer was a hybrid mixing service accessible via both the clear web and the dark web. It facilitated the obfuscation of criminal funds for ransomware groups, underground economy forums and dark web markets. Its software blocked the traceability of funds on the blockchain, making it the platform of choice for cybercriminals seeking to launder illegal proceeds from a variety of criminal activities, such as drug trafficking, weapons trafficking, ransomware attacks, and payment card fraud. Since its creation in the year 2016, over EUR 1.3 billion in Bitcoin were mixed through the service.
Deposited funds from various users were pooled for a long and randomised period before being redistributed to destination addresses, again at random times. As many digital currencies provide a public ledger of all transactions, mixing services make it difficult to trace specific coins, thus concealing the origin of cryptocurrency.
Mixing services such as Cryptomixer offer their clients anonymity and are often used before criminals redirect their laundered assets to cryptocurrency exchanges. This allows ‘cleaned’ cryptocurrency to be exchanged for other cryptocurrencies or for FIAT currency through cash machines or bank accounts.
Europol’s support
Europol facilitated the exchange of information in the framework of the Joint Cybercrime Action Taskforce (J-CAT), which is hosted at Europol’s headquarters in The Hague, the Netherlands. One of Europol’s priorities is to act as a broker of law enforcement knowledge, providing a hub through which Member States can connect and benefit from one another’s and Europol’s expertise.
Throughout the operation, the agency provided crucial support, including coordinating the involved partners and hosting operational meetings. On the action day, Europol’s cybercrime experts provided on-the-spot support and forensic assistance.
In March 2023, Europol already supported the takedown of the largest mixing service at that time, ‘Chipmixer’.
Participating countries:
Germany: Federal Criminal Police Office (Bundeskriminalamt); Prosecutor General’s Office Frankfurt am Main, Cyber Crime Centre (Generalstaatsanwaltschaft Frankfurt am Main, Zentralstelle zur Bekämpfung der Internet- und Computerkriminalität)
Switzerland: Zurich City Police (Stadtpolizei Zürich); Zurich Cantonal Police (Kantonspolizei Zürich); Public Prosecutor‘s Office Zurich (Staatsanwaltschaft Zürich)
cybersecuritynews.com
By Guru Baran - November 29, 2025
CISA has officially updated its Known Exploited Vulnerabilities (KEV) catalog to include a critical flaw affecting OpenPLC ScadaBR, confirming that threat actors are actively weaponizing the vulnerability in the wild.
The security defect, identified as CVE-2021-26829, is a Cross-Site Scripting (XSS) vulnerability rooted in the system_settings.shtm component of ScadaBR. While the vulnerability was first disclosed several years ago, its addition to the KEV catalog on November 28, 2025, signals a concerning resurgence in exploitation activity targeting industrial control environments.
The vulnerability allows a remote attacker to inject arbitrary web script or HTML via the system settings interface. When an administrator or an authenticated user navigates to the compromised page, the malicious script executes within their browser session.
Categorized under CWE-79 (Improper Neutralization of Input During Web Page Generation), this flaw poses significant risks to Operational Technology (OT) networks.
Successful exploitation could allow attackers to hijack user sessions, steal credentials, or modify critical configuration settings within the SCADA system. Given that OpenPLC is widely used for industrial automation research and implementation, the attack surface is notable.
CISA indicated that this vulnerability could impact open-source components, third-party libraries, or proprietary implementations used by various products, making it challenging to fully define the scope of the threat.
Under Binding Operational Directive (BOD) 22-01, CISA has established a strict remediation timeline for Federal Civilian Executive Branch (FCEB) agencies. These agencies are required to secure their networks against CVE-2021-26829 by December 19, 2025.
While CISA has not currently linked this specific exploit to known ransomware campaigns, the agency warns that unpatched SCADA systems remain high-value targets for sophisticated threat actors.
Mitigations
Security teams and network administrators are urged to prioritize the following actions:
Apply Mitigations: Implement vendor-supplied patches or configuration changes immediately.
Review Third-Party Usage: Determine if the vulnerable ScadaBR component is embedded in other tools within the network.
Discontinue Use: If mitigations are unavailable or cannot be applied, CISA advises discontinuing the use of the product to prevent compromise.
Organizations are encouraged to review the GitHub pull request for the fix (Scada-LTS/Scada-LTS) for code-level details.
securityweek.com
ByIonut Arghire| November 24, 2025 (7:14 AM ET)
Spanish flag carrier Iberia is notifying customers that their personal information was compromised after one of its suppliers was hacked.
In Spanish-written emails sent on Sunday, a copy of which threat intelligence provider Hackmanac shared on social media, the company said that names, email addresses, and frequent flyer numbers were stolen in the attack.
According to Iberia, no passwords or full credit card data was compromised in the attack, and the incident was addressed immediately after discovery.
The airline said it also improved customer account protections by requiring a verification code to be provided when attempting to change the email address associated with the account.
Iberia said it has notified law enforcement of the incident and that it has been investigating it together with its suppliers.
The company did not say when the data breach occurred and did not name the third-party supplier that was compromised. It is unclear if the incident is linked to recently disclosed hacking campaigns involving Salesforce and Oracle EBS customers.
It should also be noted that Iberia sent out notifications roughly one week after a threat actor boasted on a hacking forum about having stolen roughly 77 gigabytes of data from the airline’s systems.
The hacker claimed to have stolen ISO 27001 and ITAR-classified information, technical aircraft documentation, engine data, and various other internal documents.
Asking $150,000 for the data, the threat actor was marketing it as suitable for corporate espionage, extortion, or resale to governments.
Founded in 1927, Iberia merged with British Airways in 2011, forming International Airlines Group (IAG), which also owns Aer Lingus, BMI, and Vueling. Iberia currently has an all-Airbus fleet, operating on routes to 130 destinations worldwide.
interestingengineering.com
By Bojan Stojkovski
Nov 23, 2025 02:26 PM EST
A new simulation by Chinese defense researchers suggests that jamming Starlink coverage over an area the size of Taiwan is technically possible.
Instead of focusing on whether Starlink can be jammed in theory, Chinese military planners are increasingly concerned with how such a feat could be attempted in a real conflict over Taiwan. The challenge is staggering: Taiwan and its allies could rely on a constellation of more than 10,000 satellites that hop frequencies, reroute traffic and resist interference in real time.
However, a recent simulation study by Chinese researchers delivers the most detailed public attempt yet to model a potential countermeasure.
Published on November 5 in the peer-reviewed journal Systems Engineering and Electronics, the paper concludes that disrupting Starlink across an area comparable to Taiwan is technically achievable – but only with a massive electronic warfare (EW) force.
Dynamic Starlink network poses major hurdle for EW
Rather than treating Starlink as a static system, Chinese researchers emphasize that its constantly shifting geometry is the real obstacle. In their peer-reviewed study, the team from Zhejiang University and the Beijing Institute of Technology notes that the constellation’s orbital planes are continuously changing, with satellites moving in and out of view at all times.
This dynamic behavior creates extreme uncertainty for any military attempting to monitor, track or interfere with Starlink’s downlink signals, the South China Morning Post reports. Unlike older satellite networks that depend on a few big geostationary satellites parked over the equator, Starlink behaves nothing like a fixed target.
Traditional systems can be jammed by simply overpowering the signal from the ground, but Starlink changes the equation. Its satellites are low-orbit, fast-moving and deployed by the thousands. A single user terminal never stays linked to just one satellite – it rapidly switches between several, forming a constantly shifting mesh in the sky. As the researchers explain, even if one link is successfully jammed, the connection simply jumps to another within seconds, making interference far harder to sustain.
Distributed jamming swarms seen as the sole viable method
Yang’s research team explains that the only realistic countermeasure would be a fully distributed jamming strategy. Instead of using a few powerful ground stations, an attacker would need hundreds – or even thousands – of small, synchronized jammers deployed in the air on drones, balloons or aircraft. Together, these platforms would form a wide electromagnetic barrier over the combat zone.
The simulation tested realistic jamming by having each airborne jammer broadcast noise at different power levels. Researchers compared wide‑beam antennas that cover more area with less energy to narrow‑beam antennas that are stronger but require precise aiming. For every point on the ground, the model calculated whether a Starlink terminal could still maintain a usable signal.
The Chinese researchers calculated that fully suppressing Starlink over Taiwan, roughly 13,900 square miles, would require at least 935 synchronized jamming platforms, not including backups for failures, terrain interference, or future Starlink upgrades. Using cheaper 23 dBW power sources with spacing of about 3 miles would push the requirement to around 2,000 airborne units, though the team stressed the results remain preliminary since key Starlink anti‑jamming details are still confidential.
privatim
privatim.ch
lundi, 24 novembre 2025
Les logiciels basés sur le cloud n’ont jamais été aussi attractifs. Les infrastructures potentiellement accessibles à tous les utilisateurs d’Internet (appelées « clouds publics ») permettent une allocation dynamique des capacités de calcul et de stockage en fonction des besoins des clients. Cet effet d’échelle est d’autant plus important que l’infrastructure du fournisseur de cloud est étendue – et généralement internationale (par exemple les « hyperscalers » comme Microsoft, Google ou Amazon).
Outre les particuliers et les entreprises privées, de plus en plus d’organes publics font recours à des applications « Software-as-a-Service » (SaaS) de ces fournisseurs. On observe également que les fournisseurs cherchent de plus en plus à pousser leurs clients vers le cloud.
Cependant, les organes publics ont une responsabilité particulière vis-à-vis des données de leurs citoyens. Ils peuvent certes externaliser le traitement de ces données, mais ils doivent s’assurer que la protection des données et la sécurité des informations soient respectées. Avant d’externaliser des données personnelles vers des services de cloud computing, les autorités doivent donc analyser les risques particuliers dans chaque cas, indépendamment de la sensibilité des données, et les réduire à un niveau acceptable par des mesures appropriées (voir l’aide-mémoire cloud de privatim).
Pour les raisons suivantes, privatim considère que l’externalisation par les organes publics de données personnelles sensibles ou soumises à une obligation légale de garder le secret dans des solutions SaaS de grands fournisseurs internationaux n’est pas admissible dans la plupart des cas (comme notamment M365) :
La plupart des solutions SaaS n’offre pas encore de véritable chiffrement de bout en bout, ce qui empêcherait le fournisseur d’accéder aux données en clair.
Les entreprises opérant à l’échelle mondiale offrent trop peu de transparence pour que les autorités suisses puissent vérifier le respect des obligations contractuelles en matière de protection et de sécurité des données. Cela vaut aussi bien pour la mise en oeuvre de mesures techniques et la gestion des changements et des versions que pour l’engagement et le contrôle des collaborateurs et des sous-traitants, qui forment parfois de longues chaînes de fournisseurs de services externes. En outre, les fournisseurs de logiciels peuvent adapter périodiquement et unilatéralement les conditions contractuelles.
L’utilisation d’applications SaaS s’accompagne donc d’une perte de contrôle considérable. L’organe public ne peut pas influencer la probabilité d’une atteinte aux droits fondamentaux. Il peut uniquement réduire la gravité des violations potentielles en ne divulguant pas les données sensibles hors de son domaine de contrôle.
En ce qui concerne les données soumises à une obligation légale de garder le secret, il existe parfois une grande insécurité juridique quant à la mesure dans laquelle elles peuvent être transférées vers des services de cloud computing. Il n’est pas possible de faire appel à tout tiers en tant qu’auxiliaire, seulement parce que les dispositions du droit pénal relatives au secret professionnel et au secret de fonction obligent également les auxiliaires des détenteurs de secrets à garder le silence.
Les fournisseurs américains peuvent être contraints, en vertu de l’acte législatif CLOUD Act adopté en 2018, à fournir des données de leurs clients aux autorités américaines sans respecter les règles de l’entraide judiciaire internationale, même si ces données sont stockées dans des centres de données suisses.Conclusion : l’utilisation de solutions SaaS internationales pour des données personnelles sensibles ou soumises à une obligation légale de garder le secret par des organes publics est possible uniquement si les données sont cryptées par l’organe responsable lui-même et que le fournisseur de services de cloud computing n’a pas accès à la clé.
mixpanel.com
sms-security-incident
Out of transparency and our desire to share with our community, this blog post contains key information about a recent security incident that impacted a limited number of our customers. On November 8th, 2025, Mixpanel detected a smishing campaign and promptly executed our incident response processes. We took comprehensive steps to contain and eradicate unauthorized access and secure impacted user accounts. We engaged external cybersecurity partners to remediate and respond to the incident.
We proactively communicated with all impacted customers. If you have not heard from us directly, you were not impacted. We continue to prioritize security as a core tenant of our company, products and services. We are committed to supporting our customers and communicating transparently about this incident.
What we did in response
| OpenAI
openai.com/index/mixpanel-incident
November 26, 2025
OpenAI shares details about a Mixpanel security incident involving limited API analytics data. No API content, credentials, or payment details were exposed. Learn what happened and how we’re protecting users.
Transparency is important to us, so we want to inform you about a recent security incident at Mixpanel, a data analytics provider OpenAI used for web analytics on the frontend interface for our API product (platform.openai.com(opens in a new window)).
The incident occurred within Mixpanel’s systems and involved limited analytics data related to some users of the API. Users of ChatGPT and other products were not impacted.
This was not a breach of OpenAI’s systems. No chat, API requests, API usage data, passwords, credentials, API keys, payment details, or government IDs were compromised or exposed.
What happened
On November 9, 2025, Mixpanel became aware of an attacker that gained unauthorized access to part of their systems and exported a dataset containing limited customer identifiable information and analytics information. Mixpanel notified OpenAI that they were investigating, and on November 25, 2025, they shared the affected dataset with us.
What this means for impacted users
User profile information associated with the use of platform.openai.com(opens in a new window) may have been included in data exported from Mixpanel. The information that may have been affected was limited to:
Name that was provided to us on the API account
Email address associated with the API account
Approximate coarse location based on API user browser (city, state, country)
Operating system and browser used to access the API account
Referring websites
Organization or User IDs associated with the API account
Our response
As part of our security investigation, we removed Mixpanel from our production services, reviewed the affected datasets, and are working closely with Mixpanel and other partners to fully understand the incident and its scope. We are in the process of notifying impacted organizations, admins, and users directly. While we have found no evidence of any effect on systems or data outside Mixpanel’s environment, we continue to monitor closely for any signs of misuse.
Trust, security, and privacy are foundational to our products, our organization, and our mission. We are committed to transparency, and are notifying all impacted customers and users. We also hold our partners and vendors accountable for the highest bar for security and privacy of their services. After reviewing this incident, OpenAI has terminated its use of Mixpanel.
Beyond Mixpanel, we are conducting additional and expanded security reviews across our vendor ecosystem and are elevating security requirements for all partners and vendors.
What you should keep in mind
The information that may have been affected here could be used as part of phishing or social engineering attacks against you or your organization.
Since names, email addresses, and OpenAI API metadata (e.g., user IDs) were included, we encourage you to remain vigilant for credible-looking phishing attempts or spam. As a reminder:
Treat unexpected emails or messages with caution, especially if they include links or attachments.
Double-check that any message claiming to be from OpenAI is sent from an official OpenAI domain.
OpenAI does not request passwords, API keys, or verification codes through email, text, or chat.
Further protect your account by enabling multi-factor authentication(opens in a new window).
The security and privacy of our products are paramount, and we remain resolute in protecting your information and communicating transparently when issues arise. Thank you for your continued trust in us.
OpenAI
FAQ
Why did OpenAI use Mixpanel?
Mixpanel was used as a third-party web analytics provider to help us understand product usage and improve our services for our API product (platform.openai.com)
Was this caused by a vulnerability in OpenAI’s systems?
No. This incident was limited to Mixpanel’s systems and did not involve unauthorized access to OpenAI’s infrastructure.
How do I know if my organization or I were impacted?
We are in the process of notifying those impacted now, and we will reach out to you, or your organization admin, directly via email to inform you.
Was any of my API data, prompts, or outputs affected?
No. Chat content, prompts, responses, or API usage data were not impacted.
Were ChatGPT accounts affected by this?
No. Users of ChatGPT and other products were not impacted.
Were OpenAI passwords, API keys, or payment information exposed?
No. OpenAI passwords, API keys, payment information, government IDs, and account access credentials were not impacted. Additionally, we have confirmed that session tokens, authentication tokens, and other sensitive parameters for OpenAI services were not impacted.
Do I need to reset my password or rotate my API keys?
Because passwords and API keys were not affected, we are not recommending resets or key rotation in response to this incident.
What are you doing to protect my personal information and privacy?
We have obtained the impacted datasets for independent review and are continuing to investigate potential impact, and monitor closely for any signs of misuse. We are notifying all individually impacted users and organizations and are in contact with Mixpanel on further response actions.
Has Mixpanel been removed from OpenAI products?
Yes.
Should I enable multi-factor authentication for my account?
Yes. While account credentials or tokens were not impacted in this incident, as a best practice security control, we recommend all users enable multi-factor authentication to further protect their accounts. For enterprises and organizations, we recommend that MFA is enabled at the single sign-on layer.
Will I receive further updates if something changes?
We’re committed to transparency and will keep you informed if we identify new information that materially affects impacted users. We will also update this FAQ.
Is there someone I can reach out to if I have questions?
If you have questions, concerns, or security issues, you can reach our support team at mixpanelincident@openai.com.
– Krebs on Security
krebsonsecurity.com
November 26, 2025
A prolific cybercriminal group that calls itself “Scattered LAPSUS$ Hunters” has dominated headlines this year by regularly stealing data from and publicly mass extorting dozens of major corporations. But the tables seem to have turned somewhat for “Rey,” the moniker chosen by the technical operator and public face of the hacker group: Earlier this week, Rey confirmed his real life identity and agreed to an interview after KrebsOnSecurity tracked him down and contacted his father.
Scattered LAPSUS$ Hunters (SLSH) is thought to be an amalgamation of three hacking groups — Scattered Spider, LAPSUS$ and ShinyHunters. Members of these gangs hail from many of the same chat channels on the Com, a mostly English-language cybercriminal community that operates across an ocean of Telegram and Discord servers.
In May 2025, SLSH members launched a social engineering campaign that used voice phishing to trick targets into connecting a malicious app to their organization’s Salesforce portal. The group later launched a data leak portal that threatened to publish the internal data of three dozen companies that allegedly had Salesforce data stolen, including Toyota, FedEx, Disney/Hulu, and UPS.
Last week, the SLSH Telegram channel featured an offer to recruit and reward “insiders,” employees at large companies who agree to share internal access to their employer’s network for a share of whatever ransom payment is ultimately paid by the victim company.
SLSH has solicited insider access previously, but their latest call for disgruntled employees started making the rounds on social media at the same time news broke that the cybersecurity firm Crowdstrike had fired an employee for allegedly sharing screenshots of internal systems with the hacker group (Crowdstrike said their systems were never compromised and that it has turned the matter over to law enforcement agencies).
Members of SLSH have traditionally used other ransomware gangs’ encryptors in attacks, including malware from ransomware affiliate programs like ALPHV/BlackCat, Qilin, RansomHub, and DragonForce. But last week, SLSH announced on its Telegram channel the release of their own ransomware-as-a-service operation called ShinySp1d3r.
The individual responsible for releasing the ShinySp1d3r ransomware offering is a core SLSH member who goes by the handle “Rey” and who is currently one of just three administrators of the SLSH Telegram channel. Previously, Rey was an administrator of the data leak website for Hellcat, a ransomware group that surfaced in late 2024 and was involved in attacks on companies including Schneider Electric, Telefonica, and Orange Romania.
Also in 2024, Rey would take over as administrator of the most recent incarnation of BreachForums, an English-language cybercrime forum whose domain names have been seized on multiple occasions by the FBI and/or by international authorities. In April 2025, Rey posted on Twitter/X about another FBI seizure of BreachForums.
On October 5, 2025, the FBI announced it had once again seized the domains associated with BreachForums, which it described as a major criminal marketplace used by ShinyHunters and others to traffic in stolen data and facilitate extortion.
“This takedown removes access to a key hub used by these actors to monetize intrusions, recruit collaborators, and target victims across multiple sectors,” the FBI said.
Incredibly, Rey would make a series of critical operational security mistakes last year that provided multiple avenues to ascertain and confirm his real-life identity and location. Read on to learn how it all unraveled for Rey.
WHO IS REY?
According to the cyber intelligence firm Intel 471, Rey was an active user on various BreachForums reincarnations over the past two years, authoring more than 200 posts between February 2024 and July 2025. Intel 471 says Rey previously used the handle “Hikki-Chan” on BreachForums, where their first post shared data allegedly stolen from the U.S. Centers for Disease Control and Prevention (CDC).
In that February 2024 post about the CDC, Hikki-Chan says they could be reached at the Telegram username @wristmug. In May 2024, @wristmug posted in a Telegram group chat called “Pantifan” a copy of an extortion email they said they received that included their email address and password.
The message that @wristmug cut and pasted appears to have been part of an automated email scam that claims it was sent by a hacker who has compromised your computer and used your webcam to record a video of you while you were watching porn. These missives threaten to release the video to all your contacts unless you pay a Bitcoin ransom, and they typically reference a real password the recipient has used previously.
“Noooooo,” the @wristmug account wrote in mock horror after posting a screenshot of the scam message. “I must be done guys.”
In posting their screenshot, @wristmug redacted the username portion of the email address referenced in the body of the scam message. However, they did not redact their previously-used password, and they left the domain portion of their email address (@proton.me) visible in the screenshot.
O5TDEV
Searching on @wristmug’s rather unique 15-character password in the breach tracking service Spycloud finds it is known to have been used by just one email address: cybero5tdev@proton.me. According to Spycloud, those credentials were exposed at least twice in early 2024 when this user’s device was infected with an infostealer trojan that siphoned all of its stored usernames, passwords and authentication cookies.
Intel 471 shows the email address cybero5tdev@proton.me belonged to a BreachForums member who went by the username o5tdev. Searching on this nickname in Google brings up at least two website defacement archives showing that a user named o5tdev was previously involved in defacing sites with pro-Palestinian messages. The screenshot below, for example, shows that 05tdev was part of a group called Cyb3r Drag0nz Team.
A 2023 report from SentinelOne described Cyb3r Drag0nz Team as a hacktivist group with a history of launching DDoS attacks and cyber defacements as well as engaging in data leak activity.
“Cyb3r Drag0nz Team claims to have leaked data on over a million of Israeli citizens spread across multiple leaks,” SentinelOne reported. “To date, the group has released multiple .RAR archives of purported personal information on citizens across Israel.”
The cyber intelligence firm Flashpoint finds the Telegram user @05tdev was active in 2023 and early 2024, posting in Arabic on anti-Israel channels like “Ghost of Palestine” [full disclosure: Flashpoint is currently an advertiser on this blog].
‘I’M A GINTY’
Flashpoint shows that Rey’s Telegram account (ID7047194296) was particularly active in a cybercrime-focused channel called Jacuzzi, where this user shared several personal details, including that their father was an airline pilot. Rey claimed in 2024 to be 15 years old, and to have family connections to Ireland.
Specifically, Rey mentioned in several Telegram chats that he had Irish heritage, even posting a graphic that shows the prevalence of the surname “Ginty.”
Spycloud indexed hundreds of credentials stolen from cybero5dev@proton.me, and those details indicate that Rey’s computer is a shared Microsoft Windows device located in Amman, Jordan. The credential data stolen from Rey in early 2024 show there are multiple users of the infected PC, but that all shared the same last name of Khader and an address in Amman, Jordan.
The “autofill” data lifted from Rey’s family PC contains an entry for a 46-year-old Zaid Khader that says his mother’s maiden name was Ginty. The infostealer data also shows Zaid Khader frequently accessed internal websites for employees of Royal Jordanian Airlines.
MEET SAIF
The infostealer data makes clear that Rey’s full name is Saif Al-Din Khader. Having no luck contacting Saif directly, KrebsOnSecurity sent an email to his father Zaid. The message invited the father to respond via email, phone or Signal, explaining that his son appeared to be deeply enmeshed in a serious cybercrime conspiracy.
Less than two hours later, I received a Signal message from Saif, who said his dad suspected the email was a scam and had forwarded it to him.
“I saw your email, unfortunately I don’t think my dad would respond to this because they think its some ‘scam email,'” said Saif, who told me he turns 16 years old next month. “So I decided to talk to you directly.”
Saif explained that he’d already heard from European law enforcement officials, and had been trying to extricate himself from SLSH. When asked why then he was involved in releasing SLSH’s new ShinySp1d3r ransomware-as-a-service offering, Saif said he couldn’t just suddenly quit the group.
“Well I cant just dip like that, I’m trying to clean up everything I’m associated with and move on,” he said.
He also shared that ShinySp1d3r is just a rehash of Hellcat ransomware, except modified with AI tools. “I gave the source code of Hellcat ransomware out basically.”
Saif claims he reached out on his own recently to the Telegram account for Operation Endgame, the codename for an ongoing law enforcement operation targeting cybercrime services, vendors and their customers.
“I’m already cooperating with law enforcement,” Saif said. “In fact, I have been talking to them since at least June. I have told them nearly everything. I haven’t really done anything like breaching into a corp or extortion related since September.”
Saif suggested that a story about him right now could endanger any further cooperation he may be able to provide. He also said he wasn’t sure if the U.S. or European authorities had been in contact with the Jordanian government about his involvement with the hacking group.
“A story would bring so much unwanted heat and would make things very difficult if I’m going to cooperate,” Saif said. “I’m unsure whats going to happen they said they’re in contact with multiple countries regarding my request but its been like an entire week and I got no updates from them.”
Saif shared a screenshot that indicated he’d contacted Europol authorities late last month. But he couldn’t name any law enforcement officials he said were responding to his inquiries, and KrebsOnSecurity was unable to verify his claims.
“I don’t really care I just want to move on from all this stuff even if its going to be prison time or whatever they gonna say,” Saif said.
politico.eu
November 24, 2025 9:12 pm CET
By Mathieu Pollet
“We cannot afford this level of dependence on foreign tech,” lawmakers say in letter obtained by POLITICO.
BRUSSELS — A cross-party group of lawmakers will urge the European Parliament to ditch internal use of Microsoft’s ubiquitous software in favor of a European alternative, according to a letter obtained by POLITICO.
The call comes amid fresh concerns that the dominance of a handful of U.S. tech giants has become too much of a liability for Europe’s security and prosperity, and as the U.S. administration renewed demands for digital concessions at a meeting in Brussels on Monday.
In the scathing letter to be delivered to Parliament President Roberta Metsola on Tuesday, 38 lawmakers also list the screens, keyboards and mouses from Dell, HP and LG — in use across the chamber’s IT systems — as technology that should be ditched.
“With its thousands of employees and vast resources, the European Parliament is best positioned to galvanise the push for tech sovereignty,” the letter reads. “When even old friends can turn into foes and their companies into a political tool, we cannot afford this level of dependence on foreign tech, let alone continue funneling billions of taxpayers' money abroad.”
The lawmakers cite a broad range of European alternatives they argue are viable solutions: from Norwegian internet browser Vivaldi, French search engine Qwant and Swiss secure email suite Proton to German collaboration platform Nextcloud.
“Our mid-term goal should be the complete phase-out of Microsoft products, including the Windows operating system. It’s easier than it sounds,” the lawmakers say, praising the International Criminal Court’s recent move to drop Microsoft over U.S. sanction fears.
The letter is signed by influential members including MEPs Aura Salla and Mika Aaltola from the center-right EPP; Birgit Sippel and Raphaël Glucksmann from the center-left S&D; Stéphanie Yon-Courtin and Marie-Agnes Strack-Zimmermann from the centrist Renew Europe group; Alexandra Geese and Kim van Sparrentak from the Greens; and Leïla Chaibi and Merja Kyllönen from The Left.
“The Parliament's vehicle fleet is almost entirely made up of cars from European brands. The same can be replicated for end-product computer hardware,” they argue. They call to set up a task group of lawmakers and Parliament staffers to help and monitor that transition.
“With enough political will, we will have freed this institution from the danger of foreign tech dependency by the end of the mandate,” they write.
Last week saw Germany swing behind a long-standing push from France to make Europe more reliant on its own technology companies and chart its digital independence from the U.S., at a political summit in Berlin.
Austrian centrist lawmaker Helmut Brandstätter, who coordinated the initiative, said in a statement: “Right now, the European Parliament runs on foreign software that can be switched off, monitored, or politically weaponised overnight. That is not just inconvenient, it is a strategic vulnerability," adding this isn't “anti-American” but “pro European sovereignty.”
“Microsoft is proud to offer the broadest set of sovereignty solutions on the market today,” Robin Koch, a spokesperson for the company, said in a statement. “We will continue to look for new ways to ensure the European Parliament and our other European customers have the options and assurances they need to operate with confidence.”
cisa.gov Alert
Release DateNovember 24, 2025
CISA is aware of multiple cyber threat actors actively leveraging commercial spyware to target users of mobile messaging applications (apps).1 These cyber actors use sophisticated targeting and social engineering techniques to deliver spyware and gain unauthorized access to a victim’s messaging app, facilitating the deployment of additional malicious payloads that can further compromise the victim’s mobile device.
These cyber actors use tactics such as:
CISA strongly encourages messaging app users to review the updated Mobile Communications Best Practice Guidance and Mitigating Cyber Threats with Limited Resources: Guidance for Civil Society for steps to protect mobile communications and messaging apps, as well as mitigations against spyware.
Gen Blogs | gendigital.com
Threat Research Team
November 19, 2025
State-sponsored hacking groups typically operate in isolation, each advancing its own nation’s goals. That’s why any sign of collaboration between them is cause for concern. Yet new evidence uncovered by Gen researchers suggests that two of the world’s most aggressive advanced persistent threat (APT) actors, Russia-aligned Gamaredon and North Korea’s Lazarus, may be operating on shared infrastructure.
This discovery hints at something much bigger than mere technical overlap. It points to a possible new stage in cyber conflict, where geopolitical alliances are mirrored in shared digital operations.
From allies on the battlefield to partners online
Russia and North Korea have maintained a long-standing partnership rooted in shared political and military interests. Moscow backed Pyongyang during and after the Korean War, and in 2024 both nations renewed that alliance through a Comprehensive Strategic Partnership that includes mutual defense commitments.
Since 2022, Pyongyang has stepped up its support for Moscow, formally recognizing Russian-claimed territories in Ukraine and reportedly supplying munitions and troops. In 2024, Reuters reported that North Korean soldiers had been deployed to fight alongside Russian forces in Ukraine, a striking example of the two countries’ deepening cooperation.
Now, we may be witnessing a digital extension of that alliance. On July 28, 2025, Gen’s internal monitoring systems detected a suspicious event linking Gamaredon and Lazarus activity through a shared IP address. The implications are significant: two state-backed actors from different countries may be coordinating at an operational level.
This development aligns with broader patterns highlighted in the Q3/2025 Threat Report, where state sponsored operations showed increasing sophistication, coordination, and diversification of infrastructure. While those observations were confined within national ecosystems, the Gamaredon–Lazarus overlap suggests that similar dynamics may now be emerging across national boundaries.
Background
Gamaredon
Gamaredon is a Russian-aligned APT active since at least 2013, primarily focused on cyber espionage. In 2021, the Security Service of Ukraine issued a press release, attributing several members of the group as part of Russia's Federal Security Service (FSB) 18th Information Security Center. Since its official inception, the group is believed to have conducted more than 5000 cyber-attacks, most of which targeted Ukrainian government agencies. However, with the onset of war in Ukraine, ESET reported that Gamaredon expanded its operations to include NATO member states, likely aiming to disrupt military aid to Ukraine, underscoring the group’s prioritization of hybrid warfare.
Lazarus
Lazarus is a state-sponsored threat actor active since 2009 and widely believed to operate under North Korea’s government. Initially focused on cyber espionage and destructive attacks, Lazarus later shifted toward financially motivated operations to fund future campaigns. In 2021, the United States Department of Justice indicted three members believed to be part of the Lazarus group, connecting them to North Korea’s Reconnaissance General Bureau (RGB), the country’s primary intelligence agency. With the rise of cryptocurrency, Lazarus increasingly targeted digital assets, as evidenced by high-profile breaches such as Stake.com ($41 million), AtomicWallet ($100 million), WazirX ($235 million), and Bybit ($1.4 billion).
Where Gamaredon spies, Lazarus steals, but both ultimately serve their governments’ strategic interests.
The discovery: a shared digital footprint
Just one day after the announcement of new direct flights between Moscow and Pyongyang, Gen identified indicators of a potential collaboration between the Gamaredon and Lazarus APTs. On July 24, 2025, our system tracking Gamaredon’s Command-and-Control (C2) servers via known Telegram and Telegraph channels blocked an IP address:
144[.]172[.]112[.]106
Four days later, during a routine check, the same server was found hosting an obfuscated version of InvisibleFerret (SHA256: 128da948f7c3a6c052e782acfee503383bf05d953f3db5c603e4d386e2cf4b4d), a malware strain attributed to Lazarus. The payload matched Lazarus’ tooling and was delivered through an identical server structure (URL: http[://]144[.]172[.]112[.]106/payload/99/81) previously seen in ContagiousInterview, a Lazarus campaign that targeted job seekers with fake recruitment messages. While the IP could represent a proxy or VPN endpoint, the temporal proximity of both groups’ activity and the shared hosting pattern indicate probable infrastructure reuse, with moderate confidence of operational collaboration. Whether Lazarus leveraged a Gamaredon-controlled server or both actors shared the same client instance remains unclear, but the overlap is too close to ignore.
Implications for the global threat landscape
Cross-country collaborations in the APT ecosystem remain exceptionally rare. The last widely acknowledged example dates back to 2014 with the Regin malware, reportedly co-developed by the U.S. National Security Agency (NSA) and the U.K.’s Government Communications Headquarters (GCHQ).
If confirmed, the Gamaredon–Lazarus overlap would represent the first known case of Russian–North Korean cyber collaboration in the wild.
Such a partnership could have wide-ranging implications:
Operational synergy: Lazarus’s expertise in monetizing cyberattacks through cryptocurrency theft could help Gamaredon fund or conceal future operations.
Strategic alignment: Russia, facing mounting economic and military pressure, could benefit from North Korea’s established infrastructure for covert financial operations.
Escalation potential: This kind of collaboration blurs the line between espionage, sabotage, and organized cybercrime, expanding both nations’ offensive reach.
Not an isolated case: national ecosystems are merging
While cross-border APT collaboration is rare, cooperation within national ecosystems has become increasingly common.
Lazarus x Kimsuky
Kimsuky is another North Korean APT group. It has been active since around 2012 and assessed by Mandiant to operate under the RGB. The group specializes in advanced cyber-espionage campaigns, primarily targeting government entities and consumer-facing organizations.
During analysis of Lazarus’ ContagiousInterview payloads, Gen researchers found that an IP address (216[.]219[.]87[.]41) later reappeared in Kimsuky-linked payloads (e.g., cce27340fd6f32d96c65b7b1034c65d5026d7d0b96c80bcf31e40ab4b8834bcd). This suggests infrastructure reuse or coordination between RGB units, evidence of alignment at North Korea’s national level.
DoNot x SideWinder
DoNot and SideWinder are state-sponsored APT groups believed to have been active since 2013 and 2012, respectively, both with ties to the Indian government and a primary focus on cyber espionage.
Gen identified a DoNot-attributed payload (8bb089d763d5d4b4f96ae59eb9d8f919e6a49611c183f636bfd5c01696447938) that later executed a known SideWinder loader (f4d10604980f8f556440460adc71883f04e24231d0a9a3a323a86651405bedfb). The victim was located in Pakistan, consistent with the typical targeting profile of both groups. This cooperation resembles the previously observed Gamaredon x Turla collaboration, indicating that intra-country partnerships are becoming a tactical norm.
A new phase in cyber geopolitics
The evidence of infrastructure overlap between Lazarus and Gamaredon represents a significant development in the global threat landscape. Historically, cross-country APT collaborations have been exceedingly rare, with only a handful of confirmed cases such as Stuxnet and Regin. This potential partnership signals a shift toward more complex and unpredictable alliances, where geopolitical interests may drive operational convergence.
While the Lazarus–Gamaredon case stands out for its strategic implications, the observed intranational collaborations, such as Lazarus with Kimsuky and DoNot with SideWinder, are equally important. These partnerships demonstrate a growing trend of resource sharing and tactical alignment within national ecosystems, amplifying the reach and resilience of state-sponsored campaigns.
For defenders, these findings underscore an urgent need to adapt detection strategies beyond single-actor attribution. Shared infrastructure, overlapping TTPs, and modular malware frameworks mean that traditional attribution models may fail to capture the full scope of risk. Security teams must:
Enhance infrastructure correlation analysis to detect cross-group overlaps early.
Prioritize intelligence sharing across organizations and sectors to identify emerging alliances.
Implement layered defenses capable of mitigating diverse tactics from multiple threat actors leveraging common resources.
The era of isolated APT operations is fading. As adversaries evolve through collaboration, defenders must respond with equal agility and cooperation to safeguard critical assets.