Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
Meta was fined €805 million in Italy yesterday over a Facebook for Android feature that suggests photos and videos from users' phone galleries for them to post.
The Garante, Italy's data protection authority, found that the feature was enabled by default and that the app accessed Italian users' photos, videos, and related metadata without their explicit consent.
The company has 60 days to switch the feature off by default, including for people who have already granted the app gallery access, and to request consent separately.
Meta plans to appeal and calls the fine "disproportionate", a spokesperson said in a statement reported by Reuters.
The app asks for gallery access via a single permission that covers the whole app and several functions with different purposes, the authority found. A general notice about enabling other features appears first, but it does not make it clear to users that they are also enabling gallery suggestions.
Fully granted, a permission like this lets the app read the phone's whole photo archive, usually on an ongoing basis. Neither the user nor the authority can check which information is actually used.
The authority found a breach of Article 122 of Italy's Privacy Code, which puts the EU's ePrivacy Directive into Italian law. That rule treats a phone as part of a person's private life. Any access to what the phone stores, therefore, requires free and informed consent, whether or not data is sent anywhere or harm results.
The authority's order, set out in its press release, requires the company to:
Within 60 days, ask for consent through a separate, specific request for this feature, and explain clearly what the feature is for, that it accesses the gallery, and how to turn it off.
Within 60 days, keep the feature off by default, including for people who already granted the permission.
Within 30 days, report to the authority on the work it has started, and within 90 days, on the measures it has taken.
If the company misses the 60-day deadline, the feature cannot be switched on for anyone who has not given valid consent.
Meta said in a statement quoted in a Reuters report that the feature works only after users give permission on their device, and that they can change that permission at any time in their settings.
The Centro Tutela Consumatori Utenti, the Bolzano consumer protection group whose complaint started the investigation, published consumer advice on July 11, 2025. It told users to switch off the gallery suggestion settings in the app and to check what access and permissions the Facebook app has on their phone.
The investigation did not look at whether gallery content was used to train AI models. The company denies any such use. The authority may separately examine a newer feature, launched this year, that allows gallery content to be processed in the cloud.
The company had argued that Ireland's data protection authority should handle the case. The Garante rejected that argument because the ePrivacy rules do not provide a one-stop-shop mechanism.
The feature has been available since 2023. The investigation began in July 2025 and included the authority's own technical analysis.
The fine equals about 0.47% of the group's global revenue. In setting it, the authority weighed the large number of people involved, about 20 million Android users in Italy.
It also weighed how long the breach has lasted. The breach is still ongoing for people who have not updated the app, and for those who have already granted permission, the authority said.
Other factors were a 2019 decision against the company and limited cooperation during the investigation. Changes the company made after the complaint counted in its favor, though the authority judged them late and limited to people who update the app.
from The Hacker News https://ift.tt/6qw7fir
via IFTTT
"An attacker obtained an access key we had issued to Fireworks," Cursor said in a Friday update. "The key was exposed by Fireworks, and the attacker used it to copy data from a read-only storage bucket we used to share data with them."
The disclosure comes nearly two weeks after a trojanized version of Anthropic's official Claude Code extension was distributed through Cursor Marketplace as a legitimate update, attempting to install a persistent SSH backdoor on affected systems.
According to the artificial intelligence (AI)-powered coding platform, the read-only storage bucket is said to have contained limited coding agent traces from sessions that were not in Privacy Mode. Privacy Mode is a Cursor-specific setting that, if enabled, allows users to opt out of their data being used for training purposes.
These sessions, most of which date back to 2025, were permitted to be used for model training. Among these traces were credentials that had not been edited out, exposing the API credentials of less than 0.01% of customers in the process.
The attacker, Cursor added, used these credentials as a starting point to reach select software-as-a-service (SaaS) tools used by Cursor and then access the following data -
Select archived non-production Cursor source code repositories, including some containing business contact information
Limited customer support data and email conversations
Product usage metrics and contact details
Summaries of some coding agent conversations
Some credentials users had sent to the Cursor support team
Cursor said it took steps to deactivate the vendor's key, revoke and rotate credentials, and hunt for signs of deeper access, and contain it after "we identified further access." The company also said it temporarily disabled internal and product services, disrupting access to some Cursor features.
The next phase of the attack took place on October 29, 2026, when the attacker used a stolen credential from the exposed data of its internal system to place trojanized versions of Anthropic's Claude Code extension directly on the cache used to serve Cursor's extension marketplace.
"At most 5,000 users who requested specific cached versions of the extension on October 29 potentially received the malicious build," Cursor said. "It was available for approximately 11 hours before we removed it. We took it down, took the extension marketplace offline, and worked with the cloud service provider hosting the attacker's server to take it down."
The company said it notified affected users who installed versions 2.1.312 or 2.1.313 from the marketplace during the exposure window and helped revoke exposed credentials. It has also moved all inference traffic off Fireworks, deactivated the key issued to it, and cut off its access to all data sets we shared with it.
Furthermore, Cursor emphasized that no additional malicious activity has been detected since November 1, 2026.
There is no evidence that the incident impacted users who had enabled Privacy Mode, customer code repositories, Cursor's own production environment, Cursor app and its official updates, its other apps, or any other extension or plugin downloaded from Cursor Marketplace.
Uber Also Impacted by Fireworks Incident
The development comes as Uber confirmed unknown threat actors stole thousands of drivers' license information after obtaining internal credentials.
"On October 9, 2026, a service provider notified Uber that an unauthorized third-party had compromised the service provider's internal credentials and used them to access Uber's account with the service provider," the company said in a filing with the U.S. state of California. "On October 13, 2026, our investigation determined that the unauthorized party had used the compromised credentials to access Uber data connected to the service provider."
Although the name of the provider was not disclosed, TechCrunch reported that the provider in question is Fireworks AI. Uber has not disclosed how many users were impacted by the breach. Last week, online productivity startup Notion also confirmed its data was stolen in the Fireworks AI hack.
from The Hacker News https://ift.tt/P7ZqlEG
via IFTTT
Brian and Brandon discuss the stunning resignation of NVIDIA CEO Jensen Huang, a story big enough to push election results, Anthropic’s IPO news, and a week of earnings off the agenda. They walk through what has been reported so far: relationships, including one with an executive tied to Megaspeed, a Southeast Asian cloud provider alleged to have funneled NVIDIA GPUs into China, and claims that security staff asked someone who photographed Huang to sign an NDA. Brandon cites Georgia coach Kirby Smart’s “dogs don’t beat dogs” to argue that CEOs have to follow their own company’s policies before anything else matters. To succeed interim CEO Colette Kress, Brian floats Tim Cook, Lisa Su, and Andy Jassy, while Brandon adds Lip-Bu Tan and Rene Haas and suggests NVIDIA may need a team of fixers to restructure Huang’s 60 direct reports. They debate whether extreme wealth breaks a leader’s judgment, and why success makes people afraid to call unusual practices strange. Brandon predicts NVIDIA will be fine because product-market fit covers a lot of mistakes, though AMD and Google’s TPUs get an opening. Brian warns that proven export violations could bring felony charges, large fines, and restated numbers. They close on who leaked the story and why now, with Brian suspecting that the US intelligence and military community saw a political window open after the midterms.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Friday added a high-severity security flaw impacting UnrealIRCd, an open-source Internet Relay Chat (IRC) server, to its Known Exploited Vulnerabilities (KEV) catalog, following reports of active exploitation.
The vulnerability, tracked as CVE-2026-114713 (CVSS score: 8.6), is a case of improper neutralization of delimiters that could be used to execute arbitrary commands with server/IRCOp privileges.
"The labeled-response module in UnrealIRCd 6.0.0 before 6.2.7.1 does not escape the IRCv3 'label' message tag when echoing it into replies, which allows any user on a network with two or more linked servers to inject server-to-server commands that are executed with server authority," reads the description of the flaw in the NIST National Vulnerability Database (NVD).
The addition comes nearly a week after UnrealIRCd's project leader, developer, and maintainer, Bram Matthys (aka Syzop), released UnrealIRCd 6.2.7.1 to address multiple security vulnerabilities identified with the help of artificial intelligence, including CVE-2026-114713.
"We are seeing bad guys exploiting this issue on the internet right now," Matthys said. "Hopefully everyone has hot-patched or updated their server, or at the very least has the spamfilter workaround deployed. If not, do so ASAP!"
Exploitation attempts are said to have commenced a day after the release of the hotfix on November 7, 2026. That said, the exact details of the malicious activity and its end goals are presently unknown. The maintainer described the vulnerability as the "most critical issue" found in UnrealIRCd over the past 15 years.
Federal Civilian Executive Branch (FCEB) agencies have time until November 16, 2026, to apply the fixes under Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk.
from The Hacker News https://ift.tt/1dZvTnc
via IFTTT
Beginning on November 11, 2026, ConnectWise reported an active campaign of a threat actor gaining unauthorized access to cloud-hosted ConnectWise ScreenConnect instances belonging to managed service providers (MSPs). Microsoft Threat Intelligence has confirmed ConnectWise’s reported activity and we have also observed threat actors abusing ScreenConnect, a legitimate remote-support application, to install unauthorized remote-access clients and deploy a malicious worm, SCKit, on ConnectWise customer managed endpoints.
Additionally, Microsoft analyzed the malicious worm’s behavior: deployment starts with commands issued through ScreenConnect to silently install an identical client connected to threat actor-controlled infrastructure. A batch launcher retrieves a PowerShell decoder that decrypts and extracts SCKit using device-specific key material. The toolkit establishes persistence through scheduled tasks and registry Run entries and deploys RelayTrap, a component designed to deliver a malicious payload to a connecting technician.
We have identified that the worm targets IT support technician workstations using the hijacked authenticated ScreenConnect Session and uses the victim’s management console to distribute payloads to other managed devices. The resulting access to either target enables threat actors to remotely administer affected endpoints, execute commands, and deploy further tools independently of the legitimate support instance.
Defenders should investigate technician workstations and downstream affected endpoints. Removing an unauthorized client alone does not remove the toolkit’s persistence or invalidate exposed web sessions. In this blog, we examine SCKit’s attack chain and payload components and provide mitigation guidance, indicators of compromise, and Microsoft Defender XDR advanced hunting queries to help organizations identify and disrupt this activity.
ScreenConnect architecture and attack surfaces
ScreenConnect, formerly ConnectWise Control, is a remote-support and access platform used by MSPs to administer customer devices, often alongside remote monitoring and management (RMM) software. Its operating model has three parts:
Management instance. A cloud-hosted or on-premises ScreenConnect server provides the web console and manages sessions. Its relay service carries communication between the technician and endpoint clients.
Technician workstation. Support staff sign in to the console through a browser and launch a local host client for interactive support.
Customer endpoint. An installed guest, or access, client maintains unattended access and executes commands delivered through ScreenConnect.
An Access session provides persistent, unattended access through the installed client. A Support session is a temporary connection that an end user joins for assistance. ScreenConnect also supports remote commands from the web console without an interactive technician session. The endpoint client receives the command and runs it on the customer device; the technician workstation is not an intermediary for that execution.
Reported server-side entry through extensions
Extensions are add-ons installed on the ScreenConnect server to add features or integrate with other products, including ticketing and RMM tools. ConnectWise Automate was formerly named LabTech; Labtech Plus is a third-party extension, not the Automate product itself. The RMM+ extension family exposes remote-command APIs protected by a separately configured passphrase rather than the technician’s normal console sign-in.
ConnectWise’s advisory describes a reported authentication flaw in RMM+ versions 1.0.31 and 1.0.32: when no access key was configured, the extension accepted an empty key. In that configuration, an unauthorized caller could submit commands to the server’s API for delivery to managed endpoints without a normal ScreenConnect user sign-in. ConnectWise is investigating extension abuse as an initial-access route; the entry method for the reported campaign remains under investigation.
A separate path from customer endpoints to technicians
SCKit is a malware toolkit that includes RelayTrap, a malicious replacement for the ScreenConnect client on an affected customer endpoint. RelayTrap is designed to deliver a payload to a technician’s workstation when they connect for support. ConnectWise states that the fix for CVE-2026-84869 blocks the toolkit’s attempted endpoint-to-technician spread. This client-side attack path is separate from the server-side access used to deploy SCKit.
Figure 1. ScreenConnect’s three operating roles and two distinct attack surfaces. The reported RMM+ entry route targets a server-side extension; RelayTrap targets the client on a connecting technician’s workstation.
Attack chain overview
The deployment sequence below runs on the customer endpoint. It establishes a separate remote-access connection and prepares the scripts and RelayTrap component that target a later technician
Figure 2. SCKit deployment on a customer endpoint and its technician-targeting capabilities. The dashed path describes the toolkit’s propagation design, not a confirmed sequence of infections.
1. ScreenConnect commands install an additional client
The threat actor uses the MSP’s ScreenConnect management instance to direct the installed endpoint client to start cmd.exe. That local process invokes curl.exe to download an MSI over HTTP from an attacker-controlled ScreenConnect server. The command requests /Bin/ScreenConnect.ClientSetup.msi with access-session parameters and a c=Exploited<N> marker (c=Exploited9 in the illustrated command), and saves the installer to C:\Windows\Temp\sc.msi.
Figure 3. Command delivered through ScreenConnect and executed on the customer endpoint to download the client MSI. The attacker-controlled server’s IP is redacted.
Windows Installer then installs the package silently on that endpoint, without restarting it, using /i, /qn, and /norestart. The added client connects to an attacker-controlled ScreenConnect instance, creating a remote-access channel separate from the MSP’s approved instance. Securing access to the legitimate console does not remove this additional client or its connection.
2. A batch launcher retrieves the PowerShell decoder
Further commands on the customer endpoint stage the toolkit. A PowerShell command decodes a URL-safe Base64 string and writes the result to a batch file in Windows Temp. The batch sets BATPATH to its own location, downloads the decoder from ns[.]mo7sen[.]dev/EadF.php?p=4, and starts it with -Mode full.
The decoder reads BATPATH, or falls back to SCKIT_SELF, to locate the launcher. Its hidden-relaunch branch creates a VBScript wrapper and runs it through wscript.exe to start the same batch without a visible window.
The scripts use the following p values at the same server path to request individual components:
Request selector
Component
Role in the chain
p=4
Decoder
Downloads, decrypts, and expands the toolkit
p=3&m=<machine-guid>
Encrypted bundle
Carries scripts, configuration, and trap components
p=5
SQLite utility
Supports browser-cookie database queries
p=1&m=<machine-guid>
Encrypted script
Supplies the loader’s next PowerShell stage
p=6&m=<machine-guid>
Cleanup component
Removes an old trap before optional redeployment
3. The decoder decrypts and extracts the SCKit bundle
The decoder reads MachineGuid from HKLM\SOFTWARE\Microsoft\Cryptography and includes it as the m request parameter. The response provides a Base64-encoded body and two headers, X-Lab-Half and X-Lab-Salt.
To derive the decryption key, the decoder hashes the UTF-8 machine identifier with SHA-256, XORs that hash with 32 bytes decoded from X-Lab-Half, and appends the machine-identifier bytes to the recovered secret material. PBKDF2-HMAC-SHA256 then derives a 32-byte key using the response salt and 4,096 iterations.
The decoder uses the first 16 bytes of the decoded response body as the initialization vector (IV). It decrypts the remaining bytes using AES-256-CBC with PKCS7 padding, decompresses the plaintext with GZip, and writes the resulting ZIP archive. The archive is then extracted to %TEMP%\SCKitBundle.
Figure 4. Selected decoder code for key derivation, decryption, decompression, and bundle extraction.
In full mode, the decoder prepares %TEMP%\SCKit\trapkit\payload and stages the watcher, installer, alert script, and RelayTrap.cs. It also copies its batch launcher into the payload directory for RelayTrap to distribute. The copied launcher retrieves the decoder and starts toolkit deployment.
The decoder also stages ToolboxRelayUploader.exe for console-based payload distribution and retrieves sqlite3.exe for browser-cookie queries if a suitable copy is absent. It includes two launch paths: full mode starts the distribution script without a separate configuration file and supplies a local script path; the other path stages a helper and lab-context.json and passes -SkipLocalExecution.
4. Additional component: PowerShell script loader
Alongside the bundle decoder, SCKit includes a separate loader for encrypted PowerShell scripts. Unlike the decoder, which retrieves and expands an archive, this component requests a script using p=1 with the machine identifier. It applies the same secret-recovery, PBKDF2, AES-CBC, and GZip operations, but uses a salt embedded in its source rather than one supplied in a response header.
After decompression, the loader converts the bytes to UTF-8 text and writes %TEMP%\k<32-hex>.ps1, using a newly generated random GUID for the filename. It starts a hidden PowerShell process to run the file with the forwarded arguments, then attempts to remove the script after the child process exits.
Figure 5. Temporary script creation, execution, and cleanup in the PowerShell script loader.
5. RelayTrap adds persistence and targets connecting technicians
On the customer endpoint, persistence keeps the toolkit available for a later support connection. The deployment places scripts under C:\ProgramData\RelayTrap. The RelayTrapLiteAlert value in the machine-wide CurrentVersion\Run key launches an alert script at user logon. A scheduled task starts the watcher with a payload filename and lists of client identifiers and relay hosts to exclude. The -PollSeconds 10 argument configures the watcher to poll every 10 seconds.
The watcher enumerates ScreenConnect client services and reads their executable paths and connection parameters. For each client, its build routine creates a directory under trapbins, copies libraries from that client’s installation, and uses the .NET C# compiler to build RelayTrap.exe. It checks for changes to the source or client libraries before rebuilding.
Figure 6. The endpoint-side watcher builds RelayTrap using libraries from the corresponding ScreenConnect client.
RelayTrap is designed to reuse the customer endpoint’s ScreenConnect connection details in place of its normal client. When a technician connects with a vulnerable host client, RelayTrap attempts to deliver the staged batch launcher through that session. The launcher retrieves the same decoder, extending the toolkit’s deployment design from the customer device to the technician workstation. Configured skip lists exclude specified client identifiers and relay hosts from processing.
ScreenConnect services are also configured for automatic startup. Registry writes target Microsoft Defender Antivirus path exclusions for staged MSI copies and CWInstall_…\Installer.ps1. The installer configuration lists sc[.]payproofkit[.]com and cdn007-digitaldownloads[.]com as additional ScreenConnect MSI sources. A subsequent curl.exe command downloads another client installer from sc[.]payproofkit[.]com.
SCKit also targets the technician’s browser, which is used to sign in to the management console. The browser-access code searches Chrome, Edge, Opera, and Opera GX profiles for cookies named .ASPXAUTH. Its database route identifies associated hosts and queries encrypted cookie values. It copies cookie databases and their supporting files, with a volume-shadow-copy fallback for locked databases. The decryption code uses the Chromium master key and the Windows Data Protection API (DPAPI) in the current user’s context, with AES-GCM routines for v10 and v11 cookie values.
The memory-scanning route first examines browser network-service processes identified by network.mojom.NetworkService in their command lines. An embedded C# scanner uses OpenProcess, VirtualQueryEx, and ReadProcessMemory to inspect readable committed memory regions for cookie strings and nearby host strings. If the initial scan finds no candidates, it scans other browser processes.
The console-distribution component is designed to combine an authentication cookie with the required anti-forgery and access tokens, enumerate accessible sessions, upload a payload using ToolboxRelayUploader.exe, and queue execution through the Shared Toolbox. The workflow also includes removing the uploaded Toolbox item after distribution.
This component targets the technician’s management-console access, rather than only the original customer device. The account’s permissions determine which additional sessions and devices the distribution workflow can reach.
7. Cleanup and redeployment
The toolkit’s cleanup script places a stop marker in the trap directory. It removes trap-related tasks, services, processes, Run entries, and files, and restores ScreenConnect client services unless client removal was requested. It then removes any remaining stop marker to allow a newly deployed watcher to run.
After running the cleanup script, the decoder’s cleanup mode starts the bundled dropper again unless -NoReArm is set. Cleanup therefore also serves as a path to redeploy the toolkit.
Figure 8. Cleanup restores ScreenConnect services; the decoder checks NoReArm before starting the bundled dropper again.
Mitigation and protection guidance
Secure ScreenConnect administration and technician clients
Address the server-side extension APIs and technician clients separately. Extension authentication and client-side file transfer are different attack surfaces; securing one does not remove the other or an existing endpoint installation.
Keep the identified extensions disabled. Follow the vendor advisory for Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, and RMM+ Password Link. Review their installation and configuration history alongside administrative access.
Update technician clients separately from the console. ConnectWise states that ScreenConnect client 26.6.5 and later block the toolkit’s attempted endpoint-to-technician transfer technique. The fix for CVE-2026-84869 was released on September 8, 2026. Verify each technician client’s installed version; a cloud-console update does not automatically update those clients. The vendor bulletin also describes temporary file-transfer restrictions while updates are pending.
Remove established access
Investigate through a separate channel. Use Microsoft Defender for Endpoint live response or another approved out-of-band method instead of ScreenConnect on a suspected affected device. Isolate affected endpoints and include connecting technician workstations in scope.
Preserve console and endpoint evidence. Retain extension, authentication, Run Command, and Toolbox records together with process, file, task, and registry history. Review Toolbox history for tools removed after use, and inspect queued commands and tools before reconnecting devices.
Revoke exposed sessions from a clean device. Invalidate affected ScreenConnect web sessions and associated identity-provider sessions, rotate exposed credentials, and review accounts and permissions. Password changes alone do not address every existing session.
Remove persistence and unapproved clients. Validate each client’s enrolled instance and relay destination before removing it. Remove malicious tasks, Run values, trap files, and unauthorized exclusions through approved response tooling. Do not use a cleanup script recovered from the kit as a remediation tool.
Verify the complete state before restoring connectivity. Confirm approved services and destinations, effective antivirus settings, and the absence of re-created tasks or scripts. Review tamper-protection events when investigating exclusion changes. Rebuild devices when integrity cannot be established.
Keep Microsoft Defender Antivirus, cloud-delivered protection, and tamper protection enabled. Verify that devices meet the requirements for protecting antivirus exclusions. Maintain an inventory of authorized remote-management instances and use application control to restrict unapproved software.
Microsoft Defender XDR detections
Microsoft Defender XDR customers can use the following Microsoft Defender for Endpoint alert titles to investigate activity associated with this threat. Review related alerts together with device timelines and ScreenConnect audit records to trace command execution, persistence, browser-data access, and network connections.
Tactic
Activity
Microsoft Defender coverage
Execution
ScreenConnect remote commands launch command-shell, batch, and PowerShell stages.
Microsoft Defender Antivirus – Trojan:Win32/SuspScreenConnectDownload.EA – Trojan:Win32/Tikise.EA!cmd – Trojan:Win32/SuspScreenConnectDownload.EA
Microsoft Defender for Endpoint – Suspicious command execution via ScreenConnect
Persistence
Additional ScreenConnect clients and automatic-start services provide remote access. The RelayTrapLiteAlert Run entry and scheduled tasks launch RelayTrap scripts.
Microsoft Defender Antivirus – Trojan:PowerShell/RelayPersist.FC!MTB
Microsoft Defender for Endpoint – Suspicious installation of remote management software – Anomaly detected in ASEP registry – Suspicious Scheduled Task Process Launched
Defense evasion
The loader attempts to remove its temporary PowerShell payload. Registry writes target Microsoft Defender Antivirus path exclusions.
Microsoft Defender Antivirus – Trojan:PowerShell/SCRelayTrap.EC!MTB
Microsoft Defender for Endpoint – Possible PowerShell indicator removal – Suspicious Microsoft Defender Antivirus exclusion
Credential access
The browser component queries .ASPXAUTH cookies, scans browser memory, and uses DPAPI in its decryption routines.
Microsoft Defender Antivirus – HackTool:Win32/ToolboxRelayUploader – Trojan:PowerShell/ScreenConnect.SC!MTB – Trojan:PowerShell/ScreenConnect.DC!MTB
Microsoft Defender for Endpoint – Potential human-operated malicious activity
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics report to get the latest intelligence on SCKit and the abuse of ScreenConnect, including protection status, affected assets, and recommended actions for their environment.
Each query below runs independently and uses a 14-day lookback. Adjust the time range to the investigation window and available retention, and correlate results with approved administrative activity.
Connections to campaign infrastructure
Find connections to the listed domains and IP addresses. Review the full destination, initiating process, and approved remote-support infrastructure for each match.
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemoteUrl has_any (
"ns.mo7sen.dev", "sc.payproofkit.com",
"newnewnew.gotdns.org", "soxnewwork.homedns.org",
"cdn007-digitaldownloads.com")
or RemoteIP in ("185.99.255.28", "155.94.150.39")
| project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine, ReportId
DeviceProcessEvents
| where Timestamp > ago(14d)
| where ProcessCommandLine contains "/EadF.php"
or ProcessCommandLine contains "SCKit"
or ProcessCommandLine contains "RelayTrap"
or ProcessCommandLine contains "Panel-Lateral"
or ProcessCommandLine contains "ToolboxRelayUploader"
or ProcessCommandLine contains ".ASPXAUTH"
or ProcessCommandLine contains "c=Exploited"
| project Timestamp, DeviceId, DeviceName, FileName,
ProcessCommandLine, InitiatingProcessFileName, ReportId
Known installer, archive, and uploader files
Find file events for the sc.msi package, staged ZIP, and uploader using their SHA-1 hashes. The query uses SHA-1 because SHA256 is usually unpopulated in DeviceFileEvents. Combine hash matches with command-line and persistence findings.
Find writes to the RelayTrapLiteAlert value or values containing RelayTrap. Review the registry key, value data, and initiating process.
DeviceRegistryEvents
| where Timestamp > ago(14d)
| where ActionType == "RegistryValueSet"
| where RegistryValueName =~ "RelayTrapLiteAlert"
or RegistryValueData contains "RelayTrap"
| project Timestamp, DeviceId, DeviceName, RegistryKey,
RegistryValueName, RegistryValueData,
InitiatingProcessFileName, ReportId
RelayTrap scheduled-task events
Find scheduled-task events containing RelayTrap or TrapWatch. Inspect the task definition to identify its triggers, executable, and arguments.
DeviceEvents
| where Timestamp > ago(14d)
| where ActionType contains "ScheduledTask"
| where AdditionalFields contains "RelayTrap"
or AdditionalFields contains "TrapWatch"
| project Timestamp, DeviceId, DeviceName, ActionType,
AdditionalFields, InitiatingProcessFileName, ReportId
Microsoft Defender Antivirus path-exclusion writes
Find Microsoft Defender Antivirus path-exclusion registry writes. Review changes naming Windows Temp, ConnectWiseControl_, CWInstall_, or RelayTrap, and verify their authorization and effective policy.
DeviceRegistryEvents
| where Timestamp > ago(14d)
| where ActionType == "RegistryValueSet"
| where RegistryKey contains @"\Windows Defender\Exclusions\Paths"
| project Timestamp, DeviceId, DeviceName, RegistryKey,
RegistryValueName, RegistryValueData,
InitiatingProcessFileName, ReportId
SCKit – Generated PowerShell Loader Artifacts
Identifies temporary PowerShell files matching the k<32-hex>.ps1 naming pattern generated by the SCKit loader, potentially revealing staged payloads independently of known file hashes or infrastructure.
Network addresses are defanged. Use the installer hashes to locate the listed packages, then verify the client’s enrolled ScreenConnect instance and related activity. The toolkit also uses the legitimate SQLite utility; investigate its use alongside the browser-cookie queries described above.
Network infrastructure
Indicator
Type
Role
ns[.]mo7sen[.]dev
Domain
Decoder, bundle, script, and utility retrieval
sc[.]payproofkit[.]com
Domain
Unauthorized ScreenConnect panel and installer source
Unauthorized ScreenConnect server and installer source
155[.]94[.]150[.]39
IPv4
Address associated with the unauthorized panel
File hashes
Hashes identify individual files. The watcher compiles RelayTrap against local client libraries, and embedded configuration changes script hashes. Use file and process behavior to investigate other builds. The table includes configuration, cleanup, and proof artifacts to support the investigation.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
A type confusion flaw in PostgreSQL lets a database user who can create objects run code on the server. Updates released yesterday fix it, along with 51 other security flaws. Full protection from this flaw also requires rebuilding any C-language extensions installed on the server.
The flaw, tracked as CVE-2026-6460, has a CVSS score of 8.8. Any code run this way has the rights of the operating system user that runs PostgreSQL. All versions before 18.7, 17.12, 16.16, 15.20, and 14.25 are affected.
The PostgreSQL Global Development Group, which publishes the database's releases, has not reported any attacks using the flaw. CISA's assessment in the CVE record also lists exploitation as none.
The flaw involves composite types, which are types built from named fields, each with its own data type. A field's type can be changed while older values of that type are still held in other parts of the server.
The server could then read an old value as if it had the new type. The fix, described in the project's release notes, adds version checks so the server can detect a value that no longer matches its type.
Security researcher Mehmet Ince described a working exploit for the flaw, demonstrated on PostgreSQL 18.6, in a technical writeup published this week.
His method is to prepare a query that holds a value, change the type of one of the value's fields, and then run the query. The writeup includes the SQL that crashes an unpatched server this way and a second step that leaks memory addresses. It does not include the SQL for the final step, which makes the server run a command.
He wrote that he could "trigger this crash as a lowest-privileged login role." The project's security advisory describes the attacker only as someone who can create objects, without saying which privileges that takes.
Red Hat, which ships PostgreSQL packages, says in its CVE assessment that an attacker needs a database login with the ability to create or modify objects. None of these sources says whether an account with only default privileges can go beyond the crash to run code.
Ince traces the root of the flaw to May 5, 2004, when PostgreSQL gained the ability to change a column's type. His technique for running code relies on a later change made on May 14, 2015.
He also adapted the exploit for managed PostgreSQL services and privately shared proofs of concept with their security teams in August. The providers he worked with include AWS (Aurora and RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks, and Ubicloud. The writeup does not give each service's current patch status.
The project credits more than a dozen reporters for CVE-2026-6460, including the researcher, and credits him on five other flaws in the same release.
The project rates 32 of the 52 flaws at 8.8, the highest score in the release. Based on the scores in its vulnerability index, only one flaw in the server requires neither a login nor any user action. That flaw, CVE-2026-116322, lets an unauthenticated client trigger a restart of PostgreSQL 18 servers.
Several other fixes are in client tools. A crafted archive can make pg_restore run code as the user running it. A compromised source server can make psql run code through the restore script in pg_dump's tar output.
What Administrators Should Do
Update the server to 18.7, 17.12, 16.16, 15.20, or 14.25, matching your major version.
Rebuild or update every C-language extension at the same time as the server. Extensions built against older releases still load, but they "may not be protected from the vulnerabilities fixed in this release," according to a repository notice from the project's RPM package maintainers. Some extensions will also need source-code changes.
Extensions rebuilt for the new releases can fail to load on older servers. Extension packages in the project's RPM repositories now require the new minor release.
If PostgreSQL runs outside its package's own service unit, for example under Patroni, restart it right after updating, a maintainer of the RPM packages says in a packaging blog post.
Update client tools such as pg_dump, pg_restore, reindexdb and vacuumdb on every machine that runs them.
Do not use the new composite_type_mismatch setting to turn off the checks. The project says doing so carries security risks.
The project's advisory and release notes offer no workaround for servers that cannot be updated yet.
PostgreSQL 14 is now end-of-life, and 14.25 is its last release. Older major versions are also affected and received no update.
After updating, follow the reindexing steps in the release announcement. If you use incremental backups, take a new full backup and base later incremental backups on it.
from The Hacker News https://ift.tt/YpXnovK
via IFTTT
Two attacks made public this week allow a malicious host to read data inside AMD SEV-SNP-protected virtual machines (VMs), which are built to keep the server's operator out.
One of them, Mior, can also modify a VM's memory and fake the signed report confirming which software it runs. Both need control of the server's hypervisor, and Mior also needs control of the server's BIOS. Researchers showed both in lab tests on AMD EPYC server processors.
AMD, which makes the processors, lists SEV firmware for Mior and microcode for Skyfall, both dated August 12. It plans to give server makers platform firmware in November for Skyfall and in December for Mior, and fixes for embedded chips later. Customers are told to get the BIOS update from their server maker.
SEV-SNP brings confidential computing to AMD EPYC server processors. It uses hardware-enforced memory encryption and access control to protect a VM, even from the host's hypervisor.
The ETH Zurich team behind Mior attacked SEV-SNP while it was starting up. During start-up, a security co-processor on the chip, the Platform Security Processor (PSP), fills in a table called the Reverse Map Table (RMP). The RMP records who owns each page of memory and what they may do with it.
The team redirected the PSP's writes to the memory of a graphics card it controlled, instead of to main memory. The team used a card because it believes the PSP reads the values back to check them, and the card could return them. Start-up then finished without errors, but part of the real RMP, including the entry that protects the table itself, stayed uninitialized.
That let the hypervisor rewrite the RMP's protections. The team then enabled debugging on a confidential VM that had it disabled and used the PSP's own debug commands to read and write the VM's memory. This worked in all 1,000 attempts across both test runs.
SEV-SNP also measures a VM's software image when the VM starts, and the PSP signs attestation reports that include this measurement. In a second test, the team copied a harmless VM's measurement into a malicious VM, so the malicious VM's attestation reports described the harmless image instead.
The attack needs control of the hypervisor and the BIOS (also called UEFI), plus a PCIe device such as a graphics card, the Mior paper says. For the tests, the team modified the BIOS to leave the chip's memory-routing settings unlocked.
"We operate in AMD’s threat model defined for SEV-SNP. AMD explicitly distrusts the UEFI, thus an attacker can modify the UEFI," the researchers say.
Ordinary VMs already trust their host and its firmware, so Mior gives an attacker nothing new against them, the team says.
The team ran Mior on one EPYC 9135, a Zen 5 chip. It considers Zen 3 and Zen 4 chips potentially affected but did not test them because it had no setup that allowed it to change their BIOS.
The debugging and attestation tests both worked with ciphertext hiding turned on. That optional SEV-SNP feature stops the hypervisor from even reading encrypted VM memory.
Two earlier attacks by some of the same researchers, the Fabricked attack and the RMPocalypse attack, also corrupted the RMP as SEV-SNP started up. Mior is a separate flaw, unrelated to Fabricked and to the fix for it, the team says. It also worked on older firmware from before that fix.
Skyfall comes from a team at ETH Zurich and Google. It builds on Transient Scheduler Attacks (TSA), a group of flaws in AMD processors that can leak data through instruction timing. TSA was first disclosed on July 8, 2025.
The team found that when a hypervisor intentionally causes a VM to fail to start, the processor has already cached part of the VM's saved state. That data is left behind without the usual cleanup, and the hypervisor can read it through TSA.
This way, the team recovered a VM's saved register values and a disk-encryption key from a test VM. For the key, it changed the VM's kernel to pause at the moment the key sat in registers. In a real attack, the team says, a hypervisor can instead use a technique called SEV-Step to step through the VM until the key reaches the registers.
Skyfall can also read VM memory, but only three fixed cache lines in a page it targets, at offsets 0x0c0, 0x380 and 0x3c0. The rest of the page stays out of reach.
The attack needs a malicious host or hypervisor, but no tampering with the hardware. The team tested it on an EPYC 7313, a Zen 3 chip, and on EPYC 9124 and 9334 chips, which are Zen 4. It did not show the leak on Zen 5 chips.
Beyond VMs, the Skyfall team read decrypted microcode updates on all three test chips. It also recovered register values stored in System Management Mode (SMM) memory, which even the operating system kernel normally cannot read. Both of these attacks need privileged software on the machine.
The program committee of the IEEE Symposium on Security and Privacy, which accepted the Skyfall paper, said it overlooks what a realistic attack on VMs would need. That includes a processor core free of other activity, failing VM starts and performance-counter reads at high speed, and a VM that does not crash or time out during the attack.
Affected Processors and Fixes
AMD tracks Mior as CVE-2026-0462 and rates it 5.9 on the CVSS 4.0 scale in a security advisory. It tracks Skyfall's VM leak as CVE-2026-40671, rated 4.9, in a second advisory that describes the flaw as exposing VM register data.
For Mior, the company lists only SEV-SNP as affected, not the earlier SEV and SEV-ES versions.
It lists the same five EPYC server lines for both flaws, with these fixes:
As listed in the two advisories
EPYC series
Mior platform firmware (target)
Mior SEV firmware (August 12)
Skyfall platform firmware (target)
7003
MilanPI-SP3_1.0.0.L (December)
1.3A.03
MilanPI-SP3_1.0.0.L (November)
8004
GenoaPI_1.0.0.K (December)
1.3A.4
Genoa_100J Patch 3 (November)
8005
TurinPI_1.0.0.C (December)
1.3A.0A
TurinPI_1.0.0.C (November)
9004
GenoaPI_1.0.0.K (December)
1.3A.4
Genoa_100J Patch 3 (November)
9005
TurinPI_1.0.0.C (December)
1.3A.0A
TurinPI_1.0.0.C (November)
The two advisories give the same TurinPI_1.0.0.C package different target months. Microcode for Skyfall is dated August 12 for each of these lines. The Instinct MI300A accelerator has a Skyfall patch dated September 21, and fixes for embedded EPYC models are due between January and April 2027.
The Mior team says updated firmware that mitigates the flaw is already out, and the Skyfall team says new microcode has been released. The advisories do not say whether those updates work on their own or only as part of the BIOS updates, and they list no workaround.
Supermicro, a server maker, has published a BIOS fix list covering flaws in dozens of its H12, H13, and H14 motherboards. The same pages say the boards also need a BMC firmware update and that the company is still testing affected products.
Because the fixes are implemented in the host's firmware, customers who rent confidential VMs depend on their cloud provider to install them. The advisory covering Mior also lists TCB (trusted computing base) values for SNP attestation next to each fixed firmware version. It does not say how VM owners should check them.
Neither advisory says whether the flaws have been used in attacks. Both teams have published code, and the Mior proof-of-concept code needs a BIOS patched to leave the memory-routing settings unlocked.
The EDK II project assigned Skyfall's SMM leak CVE-2026-18448 and rates it 5.6. AMD's EDK II bulletin traces it to missing TSA mitigations in EDK II firmware code.
The bulletin lists EPYC and Ryzen chips, including embedded models, and recommends the company's earlier TSA mitigations plus an EDK II patch when one is available.
For the five EPYC server lines listed above, the bulletin lists only that patch, due in November. Platform firmware with the fix is already available for other chips, including the EPYC 4004 and 4005 models. The EDK II project's own advisory lists no patched version as of today.
from The Hacker News https://ift.tt/1komaty
via IFTTT
The U.S. Federal Bureau of Investigation (FBI) has established that threat actors tied to the Democratic People's Republic of Korea (DPRK aka North Korea) have stolen more than $400 million worth of cryptocurrency as part of a social engineering scheme codenamed FaceStealer in the last 18 months.
As part of a coordinated set of actions announced by the U.S. government, the cloud-based infrastructure used to pull off the "hard-to-detect" campaign has been seized.
In tandem, the U.S. Department of Justice (DoJ) has announced the court-authorized seizure and restraint of more than $1.2 billion worth of cryptocurrency recently stolen by the North Korea-linked TraderTraitor actors following the hack of cryptocurrency exchange Binance. The plundered digital assets are used to fund Pyongyang's illicit weapons program, the DoJ added.
"The North Korean regime relies on proceeds from large-scale cryptocurrency theft to fund its illicit weapons program, stealing billions of dollars in recent years," said FBI Cyber Branch Operations Director Brett Leatherman in a statement.
"North Korean cyber actors have used the FaceStealer scheme to aggressively target individuals in the cryptocurrency and Web3 sectors through deceptive social engineering tactics, resulting in the theft of more than $400 million in the last 18 months."
According to the Justice Department, FaceStealer relies on surreptitiously recorded videos and deepfakes to facilitate cryptocurrency theft. Some aspects of the activity dovetail with a campaign documented by Kaspersky under the name GhostCall in October 2025.
The activity is linked to a prolific North Korea-linked financially motivated threat cluster tracked as BlueNoroff, which is also known by the cryptonyms APT38, CageyChameleon, CryptoCore, DangerousPassword, Nickel Gladstone, Sapphire Sleet, Stardust Chollima, and UNC1069.
The campaign involves luring targets with invitations to video meetings delivered from stolen accounts belonging to prior victims. Targets who join the meeting have their video stream recorded, while simultaneously serving an authentic, prerecorded webcam video of a previous victim or victims known to the target to build trust.
"The North Korean hackers also use super intelligence (SI) to develop deepfake videos of well-known and influential individuals often in the cryptocurrency and web3 industries that make the FaceStealer scheme even more effective," the DoJ said. "Here again, they use the deepfake videos in the meetings with targets to gain the target's trust."
A few seconds into the meeting, a mock technical error is presented to the victim, claiming that they cannot be heard, and they are provided a link to address the non-existent issue. The fix is a ClickFix-style lure that's designed to install malware on the victim's workstation and steal cryptocurrency, as well as abuse the target's privileges to other computer infrastructure.
In an extensive report shared with The Hacker News in July 2026, JUMPSEC revealed how the social engineering operation is built atop a phishing kit designed to impersonate videoconferencing platforms like Zoom and Microsoft Teams. The cybersecurity company has characterized FaceStealer as a victim acquisition platform that involves using compromised trusted contacts as a pathway to fuel a self-propagating attack chain via Telegram.
This includes hijacking social media and communications accounts such as Telegram, LinkedIn, Slack, and Discord for extended periods of time, and then accessing the victim's contact list to target the victim's personal and professional circles.
Compromise a victim: This involves harvesting cryptocurrency wallets, seed phrases, and other valuable access; hijacking their Telegram account or other communication app and locking them out; gaining access to their contacts and chat histories; and secretly recording them during the video chat.
Exploit the victim's Telegram account: The attacker impersonates the victim and sends tailored messages to other contacts on their behalf, proposing a Zoom or Teams meeting under the pretext of discussing an investment opportunity.
Set up the meeting: Should the target express interest, the attacker sends a Calendly invite via Telegram to schedule the video meeting. Shortly before the scheduled meeting time, the victim's Telegram account is used to send a typosquatted link that masquerades as a meeting URL for Zoom ("uu01webzoom[.]us") or Teams ("teams.livemeet[.]us").
Exploit recorded videos: When the target joins the fake Zoom meeting, the attacker plays an already recorded webcam video of the trusted contact and plays other videos, either recorded or deepfake videos, to give the impression that there are multiple participants in the meeting. In addition, headshot images generated using OpenAI ChatGPT are used as static avatar placeholders on the fake calls.
Trick the target into infecting themselves: The attacker sends a message to the target, claiming there is an audio issue or some other technical error (e.g., a deprecated Zoom SDK), and urges them to click on a link to apply an update to address the problem. Alternatively, it can take the form of running a script or copying and pasting malicious code into the command line or Terminal. This results in the deployment of malware that can capture sensitive data from the compromised device, effectively turning the target into the next victim.
Repeat the cycle: With the victim now compromised, the attacker gains control of their device and social media accounts to propagate the attack to their contacts.
Attacks mounted by BlueNoroff are known to specifically single out individuals working in the cryptocurrency and Web3 industries, along with individuals involved in the development and maintenance of open-source software.
The goal is to obtain access to the developers' devices and the software repository accounts they control to facilitate software supply chain attacks. Notably, the FaceStealer scheme was put to use in targeting the maintainer of the popular Axios npm package earlier this year to push a trojanized version that delivered a cross-platform remote access trojan (RAT).
More than 900 victim webcam video recordings used by the threat actors to impersonate victims in follow-on attacks have been seized by the FBI. The agency said it's "aware of several other attempts by North Korean hackers to target software developers, maintainers, and software libraries with significant download volume."
In a report published in April 2026, Arctic Wolf said the targeted social engineering campaign had targeted over 400 victims across more than 20 countries, with most of them concentrated in the U.S., Singapore, the U.K., Hong Kong, South Korea, and the U.A.E.
Deepfake video production pipeline (credit: Arctic Wolf)
"A full 80% of identified targets operate directly in cryptocurrency/blockchain finance (54%) or adjacent finance and investment sectors (26%)," the cybersecurity company noted at the time. "CEOs and founders alone account for 45% of the target set – nearly half. This underscores BlueNoroff's singular operational focus: individuals with access to cryptocurrency assets, wallet infrastructure, exchange platforms, or investment decision-making authority."
The activity has since expanded in scope, with 677 targets identified across 58 countries. More than 80% of the targets are founders and C-suite executives. Besides introducing new lure themes such as a fake Chrome PDF Viewer update, the campaign incorporates generative AI technology from ChatGPT, Google, SpaceXAI Grok, and Wondershare AI Content Generator (AIGC) to supply the attackers with artwork, avatars, and convincing synthetic participant videos.
"Upstream, reconnaissance has both widened and become more deliberate," the company added. "Lure material has been scraped not just from profile photos and prior victims' webcam streams, but from YouTube interviews and conference talks, which are screen-recorded by the actor. This allows them to capture a specific person's likeness and voice – a founder perhaps, or a CEO – and then create fake meeting footage without having to directly compromise the target themselves."
Each new victim offers a pathway to further the attack. The cyclic modus operandi still remains the beating heart of the social engineering operation.
"Combined with their new fake media generation capabilities to produce varied and credible lure content, this presents a significant escalation in BlueNoroff's efforts to compromise high-value individuals who control funds, signing keys, sensitive information, authenticated communications, and trusted professional relationships," Arctic Wolf said.
From FaceStealer to Contagious Interview
It's worth emphasizing here that the FaceStealer campaign is distinct from ClickFake Interview, an iteration of Contagious Interview that also employs ClickFix-style tactics to trigger the execution of malware as part of recruitment-themed campaigns.
Like FaceStealer, this involves the attackers approaching prospective targets by posing as recruiters on platforms like LinkedIn and sharing a "technical assessment" designed to run malware. In a post shared on LinkedIn, Alina Krasavina, an engineering manager at Delivery Hero, detailed how she was targeted in October 2026 by two fake recruiters on the same day, 13 minutes apart.
"The first one sent a 'technical assessment': a Next.js project of 113 files. At the end of next.config.js, after 204 spaces, there was a backdoor," Krasavina said. "The second one didn't send any ZIP. On a video call, a 'Member of Technical Staff' asked me to share my whole screen, download a repo, and run it. When I said no, he told me it was 'a requirement to continue.' After the call, I wrote to the recruiter and asked for another interview format. About a minute later she blocked me."
"The two attacks were built in opposite ways. The first one put the effort into the code and almost none into the recruiter. The second one put it into the people, and I never even saw its code."
According to a joint cybersecurity advisory published by cybersecurity and intelligence agencies from Japan, the U.S., Australia, and Germany in late September 2026, the long-running campaign is estimated to have compromised at least 30,000 devices located in 100 countries.
The attacks experiment with multiple delivery methods to convince victims to run malicious code -
Last month, Sophos disclosed that an employee's corporate macOS device had been compromised in mid-September 2026 after they cloned a public code repository presented as a job interview coding assignment and opened it as a workspace in VS Code.
"The repository contained a weaponized VS Code workspace settings file that replaced the editor's integrated terminal profile," the cybersecurity company said. "When a terminal opened in the workspace, the modified profile silently downloaded and ran a multi-stage payload."
The payload in question is BeaverTail, a JavaScript loader that's used to deliver a Python backdoor referred to as InvisibleFerret. Both malware families are attributed to Contagious Interview.
Sophos said the malware ran in memory on the device for about 26 hours, right from its execution on September 14, 2026, until it was rebooted a day later. The incident did not affect any of its products or services, or customer data or their systems, it added.
What's more, recent research from JFrog has uncovered that the threat actors linked to the campaign have even set up a decoy company named AccuraSoftHire, complete with a careers site, client testimonials, a LinkedIn page, job ads on mainstream boards, and verified recruiters in an attempt to lend credibility and ultimately deceive candidates into running malware through a rigged take-home test and a video verification step.
"Our research shows these lures are built to pass the checks people rely on: a professional website, a LinkedIn page, job ads on mainstream boards and recruiters with LinkedIn's verified badge," Guy Korolevski, senior security researcher at JFrog Security Research, said in a statement shared with The Hacker News.
"Developers and other employees with system access can't be expected to catch that on their own, so employers need to set the rules. Interview assignments with downloads should only ever run in a disposable virtual machine, never on a work laptop. Security teams should also warn employees about downloading unknown files, even from a source they think they can trust. Developers can also check when a recruiter’s profile was created and whether the company's location is the same on every page."
from The Hacker News https://ift.tt/IL3HuDJ
via IFTTT
Three Trezor Safe 5 wallets bought from the reseller CryptoBilis contain an implant, an extra circuit board that can copy their recovery phrases, hardware wallet maker Trezor said yesterday.
The implant reads the phrase from the wallet's screen and sends it over the mobile network to a server controlled by the attackers. The company examined one of the wallets in its lab, identified the other two from photos their owners sent, and has had no reports of lost funds.
A firmware update released earlier this week, version 2.13.1, stops the implants found so far from capturing anything on wallets that run it, the company said, but “the update can’t protect a wallet backup that was captured before it.”
The company has not changed its advice to anyone who bought a Trezor from CryptoBilis since March, including from the reseller's stores on Tokopedia and Shopee:
Move your funds to a new wallet with a new recovery phrase. Restoring the old phrase on another wallet does not solve the problem.
Do not set up an unused wallet from the reseller, and never type an existing recovery phrase into one.
Keep the wallet and contact Trezor Support, which offers a new Trezor wallet to anyone who bought from the reseller since March. Contact Support too if you are not sure where your wallet came from.
Do not weigh or open the wallet to check it. Neither is a reliable test.
Never share your recovery phrase, as the company will never ask for it. Scammers may pose as the company to offer replacements or refunds.
Version 2.13.1 was released for the Safe 7, Safe 5, Safe 3 and Model T, according to the company's firmware changelog. The company will not publish technical details that could help attackers or put customers at risk, it said in an investigation update.
Its engineers extracted and analyzed the implant's firmware from the first wallet it reported. The implant sits between the Safe 5's main board and its screen and changes nothing on the wallet itself, including its firmware and Secure Element, the company found.
The implant copies the recovery phrase when the wallet shows it during backup creation, and when someone types it in to restore an existing wallet to the device. It also copies a passphrase if one appears on the screen. It encrypts the data before sending it, and if it cannot connect, it keeps the data and tries again until it succeeds.
CryptoBilis served as an official reseller for the company's wallets in Southeast Asia until October 9, when the company removed it. That was the day Ledger, another hardware wallet maker, began investigating losses of funds among the reseller's customers.
Ledger later confirmed an unauthorized implant in a wallet the reseller sold. Attackers had fitted genuine Ledger devices with hidden components designed to capture the recovery phrase during setup, then drained wallets in a single coordinated operation, Ledger said in an incident statement.
Trezor says the implants in its wallets work the same way as those found in Ledger devices, adapted to the Safe 5's display. It has not said who fitted the implants or where in the supply chain that happened.
The three wallets were bought between August 20 and September 23. So far the company has found implants only in Safe 5 wallets sold by the reseller, and none in wallets from its other resellers or in its other models.
After the October reports, it asked people who bought a Trezor from the reseller to get in touch, and 48 have done so. It is checking their wallets in its lab or from photos of the insides, and has not said how many it has checked so far.
The company says none of the three owners has lost funds. Trezor wallets are self-custodial, so it cannot see anyone's balance.
The company says it has cut its reseller network by about 80%, dropping trustworthy partners that posed no immediate threat but did not fit its stricter new rules. It first announced the reduction on October 13 in a post on X, more than two weeks before the first report of an implant in one of its own wallets.
In a partner letter that day, it told the dropped resellers that they would get no new stock, could sell what they had until January 1, 2027, and would then be removed from its list of authorized sellers.
It is still investigating. It will post an update if it confirms an implant outside the reseller's wallets or the Safe 5, receives a report of lost funds linked to the implants, or releases new protections.
from The Hacker News https://ift.tt/GLMlVBq
via IFTTT
