SCKit abuses ScreenConnect to deploy remote access and target technician sessions

1. ScreenConnect architecture and attack surfaces
2. Attack chain overview
3. Mitigation and protection guidance
4. Indicators of compromise and supporting artifacts
5. References
6. Learn More

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.

6. Browser access targets authenticated ScreenConnect sessions

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.

Figure 7. Database queries and browser-memory scanning target ScreenConnect authentication cookies.

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 – Trojan:BAT/Tikise.A – Trojan:BAT/Tikise.B – Trojan:BAT/Tikise.C – Trojan:BAT/Tikise.D – Trojan:PowerShell/Tikise.A – Trojan:PowerShell/Tikise.B – Trojan:PowerShell/Tikise.C – Trojan:PowerShell/Tikise.D – Trojan:PowerShell/Tikise.E – Trojan:PowerShell/Tikise.F Microsoft Defender for Endpoint – Possible theft of passwords and other sensitive web browser information – Suspicious DPAPI Activity
Command and control	PowerShell and curl.exe retrieve the decoder, toolkit components, and client installers from campaign infrastructure.	Microsoft Defender for Endpoint – Command-line process communicating with malicious network endpoint – Powershell made a suspicious network connection
Multiple tactics	Intrusion activity spans remote commands, client installation, persistence, and security-setting changes.	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.

Microsoft Defender XDR Threat analytics

SCKit abuses ScreenConnect to deploy remote access and target technician sessions

Advanced hunting queries

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

Toolkit command lines and cookie-query activity

Find command lines containing distinctive toolkit names, staging paths, installer markers, or cookie-query strings.

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.

DeviceFileEvents
| where Timestamp > ago(14d)
| where SHA1 in~ (
    "0be01e7bd69cfdd222645d49bb5ad9961372fef2",
    "3f81c9c874a896c46e4bccea2fad2eaa3d9f2054",
    "13ce33b19daee3963f7e15d461b191c38f6bc0d3")
| project Timestamp, DeviceId, DeviceName, FileName, FolderPath,
    SHA1, InitiatingProcessFileName, ReportId

Registry values referencing RelayTrap

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.

DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName matches regex @"(?i)^k[0-9a-f]{32}\.ps1$"
| project Timestamp, DeviceId, DeviceName,
ActionType, FileName, FolderPath, SHA256,
InitiatingProcessFileName

Indicators of compromise and supporting artifacts

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
cdn007-digitaldownloads[.]com	Domain	Campaign infrastructure; configured installer source
newnewnew[.]gotdns[.]org	Domain	Associated ScreenConnect relay
soxnewwork[.]homedns[.]org	Domain	Associated ScreenConnect relay
185[.]99[.]255[.]28	IPv4	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.

Indicator	Type	Role
61a672a13f03a9e81f573535ee92b1ed6cb7e848a33a06048865312d4e185ae2	SHA-256	sc.msi installer package
8e6912deed82e80bb6bd66f73509d024b1f78b993515366d8317e69a97cff4f4	SHA-256	Staged toolkit ZIP
8cb5f48bbe70b5248db7f327f3d1ad6649df5c767d2a7e0711ee147fd92e06af	SHA-256	ToolboxRelayUploader.exe
94b93c649b0ae0281352da9d01761fa9195ab1e6ac7010af3b9ba1646355eb11	SHA-256	Panel-Lateral-free.ps1
7a9aca9fdd4dcc13fe497cabdb13ca1e5d6a529271c8aa495e5ca1c1c80271ec	SHA-256	Panel-Lateral.ps1
b93f10f30ee453d1e1c046fec9d141c41d7680be5cd46c3aeb3febe0f4953b4d	SHA-256	LabConfig.ps1 helper
3c7a98f0fdb6235b8076319c74dc1085f7b349b6d750416dd0cadb07d7972ec4	SHA-256	RelayTrap.cs source
d2ed7a7bf4f8ac9c7969e9b3a07ebd4dda0d858f372c876ac0a041611698de9a	SHA-256	TrapWatch.ps1
4a1dd3cd2ea14368afadf7e9dfdd63b104e3981ef8c85bbb6510919b810af04b	SHA-256	trapkit\install.ps1
cf50d73fa8117a758093b1344de41cd6a6ccddc645cdda1fa91a9264efe93956	SHA-256	Lite-Alert.ps1
81cc2baa35b798d6084bd078662fa29ff28df02c46c6ccdb2b43bde97d19f781	SHA-256	Stage0Loader.ps1
43b7a5e56f9e6c7b74e1ce2b7b5af63f383084625fcc2d3a5985fa1059e2db95	SHA-256	Run-Lateral-Full.bat
50659748723e906c8b3d3c0386bd4cf692f693a3e23639398c1a14d0c31fed61	SHA-256	runnew.cmd
5dd3a6ba806ac472663e243cfc1c034c534d5d9a42ec362c3dbf0f8d950148d0	SHA-256	Stop-LabTrap.bat cleanup-mode launcher
454c43d296b1276bde9a4f6ff1da2221cb35ccdb2fc7991bdd572e45bce12a8a	SHA-256	TRAP-PROOF.bat proof artifact
0be01e7bd69cfdd222645d49bb5ad9961372fef2	SHA-1	sc.msi;
3f81c9c874a896c46e4bccea2fad2eaa3d9f2054	SHA-1	Staged toolkit ZIP;
13ce33b19daee3963f7e15d461b191c38f6bc0d3	SHA-1	Uploader;

Client identifiers and behavioral artifacts

Indicator	Type	Role
2588ef5c15954b10	Client ID	Unauthorized ScreenConnect client identifier
ed630cc2c873b091	Client ID	Unauthorized ScreenConnect client identifier

References

• ConnectWise security investigation and partner guidance (advisory covering the RMM+ extension authentication flaw). ConnectWise (accessed 2026-11-13)
• ScreenConnect security bulletin, 2026-09-08 (CVE-2026-84869 fix and client 26.6.5 guidance). ConnectWise (accessed 2026-11-13)
• ScreenConnect extensions. ConnectWise (accessed 2026-11-13)
• 6 tips for ConnectWise Control partners (remote commands from the web console). ConnectWise (accessed 2026-11-13)
• Requirements for protecting antivirus exclusions with tamper protection. Microsoft Learn (accessed 2026-11-13)
• Investigate entities on devices using live response. Microsoft Learn (accessed 2026-11-13)
• Take response actions on a device. Microsoft Learn (accessed 2026-11-13)
• Advanced hunting best practices in Microsoft Defender XDR. Microsoft Learn (accessed 2026-11-13)
• DeviceFileEvents table (advanced hunting schema). Microsoft Learn (accessed 2026-11-13)

Learn More

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

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.  

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender

The post SCKit abuses ScreenConnect to deploy remote access and target technician sessions appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/kBLqf72
via IFTTT

PostgreSQL Patches 52 Flaws, Including 22-Year-Old Bug Enabling Authenticated RCE

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

1. Update the server to 18.7, 17.12, 16.16, 15.20, or 14.25, matching your major version.
2. 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.
3. 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.
4. 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.
5. Update client tools such as pg_dump, pg_restore, reindexdb and vacuumdb on every machine that runs them.
6. Do not use the new composite_type_mismatch setting to turn off the checks. The project says doing so carries security risks.
7. The project's advisory and release notes offer no workaround for servers that cannot be updated yet.
8. PostgreSQL 14 is now end-of-life, and 14.25 is its last release. Older major versions are also affected and received no update.
9. 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

New Mior and Skyfall Attacks Let Rogue Cloud Hosts Steal Secrets From AMD SEV-SNP VMs

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

FBI Says North Korean Hackers Stole Over $400 Million in Crypto Using Deepfake Video Calls

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.

The entire attack plays out as follows -

• 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."

BlueNoroff's updated attack flow (credit: Arctic Wolf)

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

Trezor Confirms Hidden Implants in CryptoBilis-Sold Wallets That Can Steal Recovery Phrases

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.

The company first warned of a suspected implant on October 30, two days after a buyer reported it and before its lab had seen the wallet.

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

Apache CloudStack Kubernetes Provider v1.3.0 Release

The Apache CloudStack project is pleased to announce the release of CloudStack Kubernetes Provider v1.3.0, which makes it easier to run Kubernetes on CloudStack.

The provider lets Kubernetes allocate IP addresses and set up the matching networking rules on CloudStack, so that TCP, UDP and TCP-Proxy LoadBalancer Services can be deployed on Kubernetes. This code used to be part of Kubernetes itself. It was later removed from Kubernetes and donated to the Apache CloudStack project, which maintains it today.

This release brings new features and several bug fixes. The highlights are:

• Load balancer stickiness: New annotations add a CloudStack stickiness policy to a Service’s load balancer, so each client keeps reaching the same node. The LbCookie and SourceBased methods are supported.
• Version detection without an admin account: The provider now gets the CloudStack version from the listCapabilities API, which regular user accounts can call. v1.2.0 used an admin-only API and failed to start with other accounts. You can also set the version yourself with the new version option in the cloud config.
• Separate Network ACL rules per Service on VPC networks: Each Service now gets its own Network ACL rules. Deleting one Service no longer cuts off traffic to other Services that use the same port.
• Proxy protocol changes in place: Turning the proxy protocol on or off for an existing Service now updates the load balancer rule in place instead of failing.
• Large environments: Load balancers are now created correctly when there are more VMs than the CloudStack API returns in one page.
• Testing: A CloudStack simulator environment now runs end-to-end tests in CI, along with many new unit tests.

If your load balancers are on VPC networks, read the upgrade notes before upgrading.

Documentation

The README now includes troubleshooting steps and an FAQ.

• https://github.com/apache/cloudstack-kubernetes-provider/blob/v1.3.0/README.md
• https://docs.cloudstack.apache.org/en/latest/plugins/cloudstack-kubernetes-provider.html

Downloads

The official source code for the v1.3.0 release can be downloaded from the downloads page: https://cloudstack.apache.org/downloads#cloudstack-kubernetes-provider-release

The changelog for this release is here: https://github.com/apache/cloudstack-kubernetes-provider/releases/tag/v1.3.0

The container image is available on Docker Hub: https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags?name=v1.3.0

The post Apache CloudStack Kubernetes Provider v1.3.0 Release appeared first on ShapeBlue.

from CloudStack Consultancy & CloudStack... https://ift.tt/8XU9V6L
via IFTTT

Operation Endgame Takes Down Gootloader, CastleRAT and StealC Servers, Seizes 6.4M Stolen Logins

An international police operation took down servers behind Gootloader, CastleRAT and StealC this week. Criminals used the three malware tools to gain access to computers, steal passwords, and launch ransomware attacks.

Police also seized about 6.4 million stolen logins belonging to more than 40,000 victims, according to Germany's Federal Criminal Police Office (BKA).

Gootloader is a loader: once on a computer, it could download other malware, especially ransomware. It spread through fake legal documents placed on hacked websites, often WordPress sites. Criminals used SEO poisoning to push those sites high in search results.

Gootloader has infected at least 25,000 computers worldwide since 2018, the U.S. Justice Department said. Its operators used those computers to infect more computers, then sold access to the new ones to ransomware criminals. In the U.S., Gootloader was used in ransomware attacks against at least 44 victims, resulting in about $28.8 million in losses.

German police gave a much higher count in their statement in German. Based on what investigators know so far, Gootloader has infected millions of computers worldwide since it first appeared in 2020.

Across the three tools, police seized 235 servers and 257 domains, according to an operation summary from Europol, which supported the action. The takedown is part of Operation Endgame, an international police campaign against malware criminals use to access victims' computers.

For Gootloader, police took down 14 servers and 218 domains and removed malware from 681 hacked websites.

With court approval, U.S. agencies and their international partners removed Gootloader from more than 100 servers, including hacked WordPress sites. They also seized U.S. domains used to deliver and control the malware, according to the Justice Department announcement.

CastleRAT, a remote access trojan (RAT) known since 2025, allows attackers to control an infected computer remotely. Police seized 120 of its servers and 39 domains.

StealC is an infostealer that exfiltrates passwords and other login credentials from infected computers, allowing criminals to sell or misuse them. Police took down its servers again this week, after a June operation against it.

After that June action, its operators changed their infrastructure and brought it back online to stay out of investigators' reach, German police said. Some of StealC's key infrastructure ran on Virtualine/Omegatech, a bulletproof hosting service that advertised its services to criminals.

Police shut that hosting service down in a late-October takedown.

No arrests were announced in this week's action. Dutch police also carried out further investigations targeting Gootloader's main suspect, according to their news release.

What Victims and Site Owners Can Do

Dutch police have loaded data stolen by CastleRAT into Check your hack, a police service where people can enter an email address. If the address is in the data, the police send an email within a few minutes with steps to remove the malware. If it is not, no email arrives.

More data will be added in the coming weeks. The service checks single addresses, not whole domains, but organizations can join No More Leaks, a police project that shares data with private partners. The stolen data is also being shared with services including Have I Been Pwned and the Shadowserver Foundation.

Emails that claim to come from the police and ask people to check the data are fake. The police never send emails with links.

Even after police seize the data, criminals may still have the stolen logins, the police say in their frequently asked questions. As long as the malware stays on a computer, criminals may also keep getting its passwords.

The Shadowserver Foundation is working with internet service providers and computer security incident response teams (CSIRTs) to find infected computers and notify their owners, the Justice Department said. In Germany, the Federal Office for Information Security (BSI) is helping notify victims, according to the BKA.

Denmark's National Special Crime Unit (NSK) helped clean the 681 websites. In a statement in Danish, the unit said it believes the attackers got into the sites with stolen passwords that came through criminal channels. They then installed a backdoor.

Officers removed the attackers' code and access, and left a message for the site owners with advice on securing their sites.

Police in Denmark and the Netherlands advise WordPress site owners to take these steps, several of which are set out in a Dutch advice sheet:

• Change all administrator passwords to unique, at least 12-character passwords.
• Turn on multi-factor authentication (MFA).
• Remove accounts you do not recognize.
• Remove any backdoor code from the site.
• Update WordPress, its themes, and its plugins.
• Allow access to the /wp-admin login page only from the IP addresses of your own devices.

from The Hacker News https://ift.tt/2hLNB73
via IFTTT

How to Harden AlmaLinux 9 and 10 for Production

A default AlmaLinux installation starts with SELinux, firewalld, and secure package repositories, but production systems still need a documented security baseline. This guide covers four high-value controls for AlmaLinux 9 and 10: SSH access, firewall exposure, SELinux enforcement, and automated security updates.

The commands are intended for system administrators and DevOps engineers. Test every change in staging, keep an active recovery path, and adapt the baseline to the application, network design, compliance requirements, and storage or cloud platform.

Production Security Baseline

Security hardening reduces avoidable exposure and limits the effect of a compromised account or service. It is a repeatable operating process rather than a one-time command list. Record approved settings, review exceptions, monitor changes, and retest the baseline after major application or operating system updates.

AlmaLinux Production Hardening Checklist

Start by updating supported packages and confirming that recovery access works. Restrict SSH to named administrators using keys, expose only required network services, keep SELinux in enforcing mode, and schedule security updates through a controlled rollout. This article covers that core baseline; production hosts still need centralized logging, backups, account lifecycle controls, vulnerability management, and workload-specific configuration.

Part 1 Secure SSH Access

OpenSSH is a common entry point on managed Linux servers. Review the effective configuration before editing files, require key-based access for administrators, disable direct root login, and validate every change before reloading the service.

Review the Effective SSH Configuration

Do not rely on commented lines in sshd_config. OpenSSH combines the main file with drop-in files, so use sshd -T to view the effective settings.

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication)'

Confirm that a named administrator can connect with a key before disabling password authentication. Keep a second authenticated session open until the new configuration is verified.

sudoedit /etc/ssh/sshd_config.d/40-hardening.conf

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

Configure Key Based Authentication

Generate an Ed25519 key on the administrator workstation and copy the public key to the server. Protect the private key with a passphrase and store recovery credentials according to your access policy.

ssh-keygen -t ed25519
ssh-copy-id admin@server.example.com

Change the SSH Port Only When Required

A non-default port can reduce automated log noise, but it does not replace key authentication, access restrictions, or monitoring. If policy requires another port, update the SSH configuration, SELinux port label, and firewall rule as one planned change.

sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

Open the new port and test it in a second session before removing access to port 22. Roll back the change if validation fails.

Restrict SSH to Named Accounts

Use AllowUsers or an approved group policy to limit SSH access. Review the list whenever administrators join, leave, or change roles.

AllowUsers admin deploy

Validate and Reload SSH

Validate the configuration before applying it. A syntax error can prevent new SSH sessions.

sudo sshd -t

Reload sshd after validation, then inspect the effective values and test a new connection.

sudo systemctl reload sshd
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|allowusers|port)'

Keep the existing administrative session open until a second session succeeds with the intended account, key, port, and source network.

Part 2 Restrict Network Access with Firewalld

AlmaLinux uses firewalld to group interfaces and sources into zones. Apply rules to the zone that actually owns the server interface, and expose only the services required by the workload.

Confirm Firewalld Is Active

Check the service state before relying on firewall rules.

sudo systemctl status firewalld

Review Active Zones and Rules

Identify the active interfaces, their assigned zones, and the services and ports allowed in each zone.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

Use the Correct Zone for Each Interface

There is no universal production zone. Select a zone that matches the interface’s trust boundary, and specify that zone in change commands. Changing the global default zone does not replace a review of existing interface assignments and can disrupt remote access.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-zone-of-interface=eth0

Allow Only Required Services

Add named services or ports only to the zone that serves the workload. The example below assumes the public zone is correct for the host; replace it when another zone owns the interface.

sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

If SSH uses another port, add it to the active zone and verify a new connection before removing the ssh service from that zone.

sudo firewall-cmd --permanent --zone=public --add-port=2222/tcp
sudo firewall-cmd --reload

Restrict Sensitive Ports by Source

Use a rich rule for administration or database access that should originate from a fixed host or trusted subnet. Replace the example addresses and port with approved values.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="8443" protocol="tcp" accept'
sudo firewall-cmd --reload

Verify the Final Firewall Configuration

List all active zones and confirm the rules attached to the interface that carries production traffic.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

Every allowed service, port, source, and forwarding rule should have an owner and a documented reason.

Part 3 Keep SELinux Enforcing

SELinux confines processes even after an application account or service is compromised. Keep it enabled and investigate policy denials instead of disabling enforcement to make an application start.

Check the Current SELinux State

Use sestatus and getenforce to confirm whether SELinux is enabled and enforcing.

sestatus
getenforce

A standard AlmaLinux installation uses enforcing mode. Treat permissive or disabled mode as an exception that needs investigation and an approved remediation plan.

Return SELinux to Enforcing Mode

If SELinux is enabled but permissive, set enforcing mode temporarily, update the persistent configuration, and test the workload.

sudo setenforce 1
sudoedit /etc/selinux/config

If SELinux is disabled, do not switch directly to enforcing on a production host. Set SELINUX=permissive, schedule fixfiles -F onboot, reboot for a complete relabel, resolve denials, and change to enforcing only after validation. Plan the relabel and reboot during a maintenance window.

Diagnose SELinux Denials

Review recent AVC denials and identify the process, target, requested access, and file context. Correct labels, ports, file locations, or documented SELinux booleans before considering a custom policy.

sudo ausearch -m AVC -ts recent
sudo journalctl -t setroubleshoot --since today

Install the troubleshooting tools when a clearer explanation is required.

sudo dnf install -y setroubleshoot-server policycoreutils-python-utils
sudo sealert -a /var/log/audit/audit.log

Use Custom Policy Only as a Last Resort

Generate a local policy module only after confirming that the denied action is expected and no supported label, port type, or boolean solves the problem. Review the generated .te source before loading the module.

sudo ausearch -c '<process-name>' --raw | audit2allow -R -M local_service
less local_service.te

A custom allow rule can grant more access than intended. Keep the source under change control and remove the module when the application no longer needs it.

Part 4 Automate Security Updates

Security updates should follow a defined schedule with monitoring, staged deployment, and reboot handling. DNF Automatic can install security advisories, but it does not decide whether services or the kernel need a restart.

Install DNF Automatic

Install the package from the standard AlmaLinux repositories.

sudo dnf install -y dnf-automatic

Configure Security Only Updates

Edit the DNF Automatic configuration file.

sudoedit /etc/dnf/automatic.conf

Set upgrade_type to security. The install timer used below applies downloaded updates even if apply_updates has another value in the file.

[commands]
upgrade_type = security

Security-only mode limits the automatic transaction to packages associated with security advisories. Review the journal and monitor failed transactions.

Enable the Install Timer

Enable the timer that downloads and installs updates.

sudo systemctl enable --now dnf-automatic-install.timer

Confirm that the timer is enabled and check its next scheduled run.

sudo systemctl status dnf-automatic-install.timer
systemctl list-timers dnf-automatic-install.timer

Stage Updates and Plan Reboots

Use deployment rings or a staging environment before broad rollout. Monitor the first systems, check application health, and schedule required service or kernel restarts. Avoid patching every production node at the same time when redundancy depends on staggered availability.

Final Checks

Before go-live, verify key-based administrative access, the effective SSH policy, active firewalld zones, SELinux enforcing mode, and the DNF Automatic install timer. Record the approved state and retain a tested recovery method for access, package, and boot failures.

This checklist is a baseline, not a complete security program. Add centralized logs, time synchronization, backups with restore tests, least-privilege sudo rules, account lifecycle management, vulnerability scanning, workload-specific controls, and regular configuration review.

FAQ

How often should AlmaLinux security updates be installed?
Apply critical security fixes according to the organization’s exposure and change policy. Internet-facing systems usually need a faster schedule than isolated systems. Use staged deployment, health checks, and planned restarts.

How can I list AlmaLinux security advisories?
Run sudo dnf updateinfo list security to list available security advisories. Use sudo dnf upgrade –security for a reviewed manual security update transaction.

Should I disable SELinux when an application is blocked?
No. Review AVC denials, correct labels and ports, and check documented booleans. Create a narrow local policy only after verifying that the access is required.

Is changing the SSH port a security control?
It mainly reduces automated scanning noise. Key authentication, restricted users, source filtering, logging, and timely updates provide stronger protection.

What should I verify before putting AlmaLinux into production?
Verify supported package versions, SSH recovery access, firewall exposure, SELinux enforcement, automatic update monitoring, backups, logs, time synchronization, account ownership, and application-specific controls.

from StarWind Blog https://ift.tt/RkcBt6S
via IFTTT