ScreenConnect Attack: SCKit Turns Remote Support Into an Attack Platform

Key Takeaways 

• On November 11, 2026, Blackpoint Cyber’s SOC responded to widespread unauthorized ScreenConnect deployments through legitimate, cloud hosted management instances. 

• The investigation uncovered SCKit, a toolkit combining rogue remote access installations with attempts to reach technicians and their managed environments. 

• APG recovered encrypted stages and a configured ScreenConnect installer from the campaign’s staging infrastructure. 

• SCKit’s RelayTrap attempts a Guest-to-Host file execution technique associated with CVE-2026-84869. 

• Follow-on components attempt to recover .ASPXAUTH cookies and reuse technician permissions to distribute commands to other endpoints. 

• The SOC confirmed rogue deployments; APG’s test against a current ScreenConnect Host client did not achieve reverse execution or demonstrate a patch bypass. 

Executive Summary 

Early in the afternoon of November 11, 2026, Blackpoint Cyber’s Security Operations Center (SOC) began responding to an influx of unauthorized ScreenConnect deployments originating from legitimate, cloud hosted ScreenConnect instances. Attackers were leveraging existing remote management capabilities to deploy additional ScreenConnect Access clients across managed endpoints, establishing new connections to infrastructure outside the organizations’ legitimate management environments. 

As the SOC continued responding to the activity, Blackpoint Cyber’s Adversary Pursuit Group (APG) began investigating the associated payloads and infrastructure. The investigation led to the identification of SCKit, a malicious toolkit designed to abuse ScreenConnect’s remote management functionality to maintain persistent access and potentially expand an intrusion across additional managed environments. 

While the unauthorized clients provided an immediate means of maintaining access, SCKit also included functionality aimed at the technicians who might connect to affected machines. Its RelayTrap component attempts to replace a legitimate ScreenConnect Guest and send a file back toward the connecting technician for execution. This behavior targets the Host client trust boundary associated with CVE-2026-84869, rather than a vulnerability in the management server itself. 

If successful, subsequent payloads attempt to recover the technician’s authenticated ScreenConnect browser sessions and leverage their existing management permissions to distribute commands across additional endpoints. In an MSP environment, this creates a potential path for attackers to move beyond the original compromised system and into other customer environments through the same infrastructure used to administer them. 

APG recovered the loader directly from the campaign’s EadF.php staging endpoint at ns.mo7sen[.]dev and collected subsequent encrypted stages, supporting executables, and a configured ScreenConnect installer from the same infrastructure. Shared staging URLs, client identifiers, relay infrastructure, filenames, and persistence artifacts establish that this is the same SCKit toolkit associated with the active MSP campaign. Blackpoint’s SOC observed unauthorized deployments, but did not observe successful Guest-to-Host propagation. 

APG also reproduced the toolkit’s attempted reverse transfer in a controlled test against a current ScreenConnect release. The malicious Guest queued the transfer, but the Host never requested or executed the payload. These findings highlight both the campaign’s demonstrated abuse of legitimate remote management access and its unconfirmed attempt to turn a trusted support connection into a route toward additional environments. 

Technical Analysis 

Following the Encrypted Loader 

With access to legitimate, cloud hosted ScreenConnect instances, attackers leveraged the platform’s built-in Run Command functionality to execute commands across managed endpoints. Because these commands were executed through existing ScreenConnect agents, the attackers could deploy additional software under the NT AUTHORITY\SYSTEM context without needing to establish a separate execution method on each machine. 

The initial deployment sequence began by checking for an existing ScreenConnect installation before downloading an attacker controlled ScreenConnect installer to C:\Windows\Temp\sc.msi and executing it silently. This established an additional remote access connection outside the organization’s legitimate management environment. The same command sequence also wrote a Base64 encoded batch script to C:\Windows\Temp\sckit-run.bat, which served as the entry point for deploying the larger SCKit toolkit. 

The batch script then contacted ns.mo7sen[.]dev, requesting a PowerShell decoder from the EadF.php endpoint using p=4 and saving it as sckit-decoder.ps1. The decoder subsequently requested encrypted content through p=3, supplying a host-specific identifier to the staging service. A separate p=5 request retrieved sqlite3.exe, which the later technician-side scripts use to access browser cookie databases. 

SCKit’s delivery is more complicated than a single archive containing the entire toolkit. In the decoder’s active full mode, 11 of the 16 archive members are copied from p=3: three through Copy-KitFile, four in a subsequent loop, and four through direct retrieval. Six components are also embedded in Stage 2, five of which overlap with the p=3 retrieval list; Run-Lateral-Full.bat is carried forward through a self-copy. Four archive members are not deployed in the active full path: LabConfig.ps1, lab-context.json, Panel-Lateral.ps1, and Stop-LabTrap.bat. The last is a 344-byte batch file present in the p=3 archive but never copied by full mode. Separately, the decoder retrieves an 11,936-byte PowerShell cleaner through p=6 and saves it as Stop-LabTrap.ps1. These are overlapping delivery paths, not separate groups to add together. For defenders, the difference matters: examining the p=3 archive alone does not show which files actually reached disk, while on-disk searches can miss archive-only files and separately retrieved components. 

APG retrieved the loader from EadF.php while the staging infrastructure was still responding, then independently decrypted the subsequent PowerShell content and retrieved a configured ScreenConnect MSI. The staging paths, ScreenConnect client IDs, relay addresses, file names, and overlapping artifact hashes match indicators published during the active MSP investigation, including those documented by Huntress. This provides a direct technical basis for linking the recovered toolkit to the campaign rather than relying on behavioral similarities alone. 

This loader begins by retrieving the system’s MachineGuid from HKLM\SOFTWARE\Microsoft\Cryptography, incorporating the identifier into a request for the p=1 payload. The server responds with Base64 encoded content alongside a custom HTTP header, X-Lab-Half, which the loader combines with a hash derived from the MachineGuid to reconstruct the necessary key material. 

The resulting material is processed using PBKDF2-HMAC-SHA256 to derive an encryption key, which is then used to decrypt the response through AES-256-CBC. Once decrypted, the payload is decompressed using GZip, revealing an additional PowerShell installation script. APG reproduced this process using the captured network exchange and recovered the decrypted payload. The recovered loader also uses different salt handling across stages: Stage 0 includes a hard-coded salt string, while the p=4 decoder obtains X-Lab-Salt from the response header. 

The encryption makes casual static inspection harder, but the information needed to recover the plaintext can be reconstructed from the loader and its server response. The CBC wrapper also lacks a separate message authentication code, so it does not provide a reliable integrity check against altered ciphertext. APG was therefore able to analyze the staged payloads without executing the full infection sequence on an affected endpoint. 

The decrypted script is written to a temporary file before being started through a hidden powershell.exe process with execution policy restrictions bypassed. In the toolkit’s installation path, the temporary PowerShell filename is generated as k followed by a 32-character hexadecimal GUID, producing names resembling k<32 hex>.ps1, not a fixed k.ps1. The short-lived file and subsequent PowerShell child are useful hunting opportunities despite the encrypted delivery. 

The recovered payload, internally named SilentForceInstall-WithUninstall.ps1, is responsible for deploying additional ScreenConnect Access clients and preparing the components used to interfere with legitimate remote support sessions. While the script contains functionality for uninstalling existing ScreenConnect installations, that routine is not invoked during its active installation path. Instead, the malware focuses on establishing persistent remote access and preparing the affected system for SCKit’s more unusual capabilities. 

More Than a Rogue ScreenConnect Installation 

The decrypted installation script, SilentForceInstall-WithUninstall.ps1, is responsible for establishing persistent remote access while preparing the compromised endpoint for SCKit’s additional capabilities. It accomplishes this by deploying two unauthorized ScreenConnect Access clients alongside a separate set of components designed to interfere with legitimate remote support sessions. 

The installer contains two configured download sources, sc.payproofkit[.]com and cdn007-digitaldownloads[.]com, each associated with a separate ScreenConnect client installation. After attempting to elevate privileges through PowerShell’s Start-Process -Verb RunAs functionality, the script launches additional PowerShell processes to retrieve and silently install the MSI packages. It also attempts Microsoft Defender exclusions covering installation paths and the msiexec.exe and powershell.exe processes, potentially reducing interference with the deployment. 

During the investigation, APG successfully retrieved a ScreenConnect installer from cdn007-digitaldownloads[.]com. Examination of the MSI revealed an embedded configuration pointing to soxnewwork.homedns[.]org on port 81, identifying the remote relay associated with the unauthorized client. The package contained recognizable ScreenConnect DLLs and supporting components, with no evidence that the underlying vendor binaries had been modified. 

This approach allows attackers to establish persistent access using legitimate remote management software. Rather than modifying ScreenConnect itself, the attackers deploy clients configured to connect to infrastructure under their control. These additional installations provide an independent means of accessing affected endpoints, even if the original management session is terminated or the organization’s legitimate ScreenConnect access is revoked. 

However, SCKit’s functionality extends beyond maintaining these additional remote access connections. The recovered toolkit also contains a collection of scripts and C# source code designed to interfere with existing ScreenConnect Guest sessions. These components are deployed under C:\ProgramData\RelayTrap, where they prepare the endpoint to target technicians who subsequently connect through legitimate support sessions. 

The installation process registers a TrapWatch scheduled task under NT AUTHORITY\SYSTEM. Its script enumerates ScreenConnect services and applies exclusion rules based on specific client IDs and relay addresses, preserving selected connections while targeting another Guest for replacement. The trap is enabled by default, with LabTrapMonitorOnly set to false, and does not first check the Host client’s version. It will therefore attempt its reverse transfer even when a patched Host is expected to reject it. 

When an eligible Guest service is identified, the watcher attempts to stop it and change its startup configuration before launching a custom replacement. Rather than relying on a precompiled executable, TrapWatch.ps1 compiles RelayTrap.cs directly on the affected endpoint, referencing assemblies from the locally installed ScreenConnect client. The C# code also uses reflection to resolve ScreenConnect classes and methods dynamically, helping the replacement interact with different client versions. 

Once compiled, the replacement process uses the original Guest’s connection parameters to reconnect to its ScreenConnect relay. This allows the malicious component to assume the role of the legitimate Guest, maintaining communication with the management environment while controlling the messages sent from the endpoint. To a connecting technician, the session may appear to be an ordinary ScreenConnect connection, despite the underlying Guest process having been replaced. 

Supporting scripts also configure Software Restriction Policy (SRP) and AppLocker related settings referencing ScreenConnect’s local Temp path, alongside the RelayTrapLiteAlert Run key. That Temp path is used for files arriving at the managed Guest, whereas RelayTrap’s malicious transfer travels in the opposite direction, toward the technician’s Host. The script’s DefaultLevel value of 0x40000 denotes *Unrestricted*, so this value alone should not be mistaken for proof that incoming files are blocked. Misapplied restrictive policy defaults could also disrupt legitimate execution on the endpoint. 

The accompanying Lite-Alert.ps1 component watches for ScreenConnect event ID 201, associated in this toolkit with a file-transfer-and-run action. That event is a useful lead when investigating attempted reverse execution, especially when correlated with the technician’s session, the Guest service state, and whether a Host process actually launched the transferred file. 

Together, these components reveal the broader purpose behind SCKit’s installation process. The unauthorized Access clients provide attackers with persistent control over the endpoint, while the RelayTrap components position the malware to intercept legitimate support connections. Rather than simply preventing administrators from accessing an infected machine, the toolkit attempts to use their next connection as an opportunity to extend the intrusion directly to the technician’s workstation. 

When a Support Session Runs in Reverse 

With the malicious Guest replacement in place, SCKit attempts to exploit one of the fundamental trust relationships within ScreenConnect: the connection between a technician and the endpoint they are supporting. Normally, a technician uses the ScreenConnect Host client to connect to a remote system running the Guest component, allowing them to interact with the endpoint, transfer files, and perform administrative tasks. SCKit attempts to reverse this relationship, turning an incoming support connection into an opportunity to execute malicious code on the technician’s own workstation. 

The behavior is implemented in RelayTrap.cs, which watches the existing ScreenConnect relay for a Host participant. When a technician opens an interactive support session, the replacement Guest prepares to send a SCKit payload back through that connection. This step does not require the technician’s authenticated management-panel cookie: the attacker already controls the affected endpoint and reuses its Guest assemblies, connection parameters, and local session context. 

The C# code registers a virtual file using ScreenConnect’s metadata and stream classes, then constructs a TransferFilesMessage with FileAction.Run. It also configures the canBeElevated execution flag, with the consent-handling path resolving to false in the recovered implementation. Together, those details show an attempt to turn an ordinary file transfer into execution on the technician’s machine without the expected Host authorization. 

The trap also has a small but consequential timing detail. It marks the Host as a target before a 2.5-second delay preceding the attempted transfer. Disconnecting clears the strike flag but does not cancel the already running worker, so even a short support connection can leave a transfer attempt in flight. That is evidence of an attempted strike, not proof the technician’s Host executed anything. 

The payload selected for this operation is Run-Lateral-Full.bat, a batch script that initiates the next stage of SCKit’s execution chain. Although the recovered toolkit also contains a demonstration payload named TRAP-PROOF.bat, the active configuration points to the lateral movement bootstrap, indicating that the mechanism is intended to support further compromise rather than simply demonstrate file transfer functionality. 

This is the Guest-to-Host behavior associated with CVE-2026-84869. The component at risk is the technician’s ScreenConnect Host client, not the management server. The vulnerability affects builds earlier than 26.6.5.9742; ConnectWise’s 26.6.5 security update introduced the fix. The attacker does not need a separate authenticated ScreenConnect web session to attempt this transfer, but does need control of an existing Guest or its local session context. APG found no indication of an unauthenticated, internet-facing execution path against arbitrary ScreenConnect servers. 

To test whether the toolkit could complete this handoff, APG ran the recovered execution chain against a current ScreenConnect release. The malicious Guest queued the transfer, but the technician-side Host did not request the file or launch a process. This independently confirmed the attempted exploit behavior while providing no evidence of successful execution or a bypass of the vendor’s fix. APG also did not observe successful technician compromise through this mechanism during the campaign. 

The selected payload, Run-Lateral-Full.bat, would retrieve the next decoder and staging components if the Host executed it. The archive also contains runnew.cmd, which requests PowerShell content from the base EadF.php endpoint, suggesting a route for restarting unauthorized Access enrollment on a newly reached system. The base endpoint returned an origin error during later collection, so APG could not validate that specific response. 

The significance of this capability becomes particularly apparent in MSP environments. Technicians regularly connect to endpoints belonging to different customers, often from workstations with access to administrative tools and authenticated management sessions. By targeting the technician rather than remaining confined to the original endpoint, SCKit attempts to move the intrusion into an environment with potentially broader access and privileges. 

The initial endpoint installer does not independently launch the panel lateral movement scripts. APG found no invocation of that chain across the 4,464 lines of the recovered second-stage installer. In the intended self-propagating path, the replacement Guest must first achieve execution on the technician’s workstation, where the browser collection components can access local session data. These components could also run independently if an attacker obtained code execution on the technician’s device by another means. 

From the Technician’s Browser to the Management Panel 

Once code is running on a technician’s workstation, SCKit moves from remote support manipulation to session theft. The toolkit does not request operator cookies from the ScreenConnect server remotely. Instead, it searches the local browser data and process memory of the machine executing its scripts, hoping to recover an existing authenticated management session and reuse that operator’s access. 

The decoder’s active path launches Panel-Lateral-free.ps1 under the runtime filename Panel-Lateral.ps1. Unlike the separate panel script variant also found in the toolkit, this delivered version does not require LabConfig.ps1 to operate. It first attempts the local runnew.cmd bootstrap, potentially creating another unauthorized ScreenConnect Access installation on the technician’s workstation before attempting session recovery. 

The script then begins searching for .ASPXAUTH cookies associated with ScreenConnect management panels. These cookies are used to maintain authenticated web sessions, making them particularly valuable to attackers attempting to access a management environment without obtaining the technician’s credentials. By recovering a valid session cookie, SCKit could potentially impersonate an authenticated operator and interact with the management panel using their existing privileges. 

For Chromium-based browsers, the script queries cookie databases with the downloaded sqlite3.exe and contains DPAPI and AES-GCM handling for supported older browser formats. It also searches browser process memory for authentication strings and inspects Firefox storage. These are local collection routines, which is why the attack needs code execution on the workstation holding the session data, whether through the reverse transfer or another foothold. 

A specific parsing defect makes the database collection routes less reliable than their apparent breadth suggests. The script invokes SQLite with -csv, then splits each returned row on the literal quote-comma-quote sequence (“,”). Ordinary output such as .ASPXAUTH,<hex> does not contain that delimiter. The resulting field count is too small, causing the row to be discarded before decryption is attempted. APG identified this logic in both the Chromium and Firefox collection paths and in both panel-script variants. That leaves the browser-memory route as the more plausible recovery path in this build. 

The collection behavior is also less persistent than the surrounding code suggests. PanelSessionWaitSec defaults to 0 and is not passed by the active launcher, so the anticipated repeated sweep while waiting for an operator to open a panel does not occur. The script makes an immediate collection attempt instead. These details provide concrete explanations for why session recovery may fail even on a workstation with otherwise relevant browser activity. 

If a usable .ASPXAUTH cookie is recovered, the script attempts to replay it against the management panel’s PageService.ashx interface. GetAccessToken is intended to retrieve a token for subsequent relay interactions, while GetLiveData enumerates accessible systems and sessions. This is authenticated-session reuse, separate from the Guest-to-Host file transfer and not a remote cookie disclosure vulnerability in ScreenConnect itself. 

The script then prepares AddSessionEvents calls to distribute execution events across accessible endpoints, including attempts to queue actions for offline enrolled systems. Its active HostSessionWaitSec setting allows up to 150 seconds for a Host connection before falling back to an inline QueuedCommand approach. ToolboxRelayUploader.exe is designed to place a bootstrap in ScreenConnect’s Shared Toolbox through the relay protocol and remove it after use. When that route fails, the PowerShell includes a direct command execution fallback. All of these paths depend on a sufficiently privileged management session. 

That dependency is important: these are legitimate administration features which become dangerous when invoked under a stolen operator session. The recovered code attempts to inherit the technician’s existing reach rather than exploit the management server to grant itself new privileges. No evidence in the analyzed components shows cookies being collected remotely from a technician without executing code on their machine. 

The limits here are primarily in obtaining and reusing a valid session, rather than a demonstrated AddSessionEvents serialization failure. Follow-up testing confirmed that the single-target nested-array request format can work, so APG does not treat its construction as a confirmed defect. Successful cookie recovery and end-to-end distribution across other managed endpoints were not established by the campaign evidence. 

Nevertheless, the intended progression is clear. By first attempting to compromise a technician’s workstation, then recover their authenticated ScreenConnect session, SCKit seeks to turn access to a single managed endpoint into an opportunity to reach other systems under that technician’s control. In an MSP environment, where a single operator may administer systems belonging to multiple customers, the potential reach of this approach extends well beyond the original compromised machine. 

Where the Propagation Chain Breaks 

The deployment activity and the proposed propagation loop have different levels of evidence. Blackpoint’s SOC saw attackers issue commands through legitimate ScreenConnect infrastructure and install unauthorized clients on managed endpoints. The broader loop, from a trapped Guest to the technician’s Host and then through stolen panel sessions, was reconstructed from the recovered code rather than observed completing in the campaign. 

APG’s controlled test helps narrow the first boundary. RelayTrap was armed and submitted its file execution request, but the current Host client did not fetch the file or run it. Because SCKit performs no version gating before sending the request, an attempted strike against a patched Host is expected behavior, not evidence that CVE-2026-84869 was bypassed. The vendor’s 26.6.5 client fix remained effective in this test. 

The installer also contains several implementation flaws with operational consequences. Its Invoke-UninstallOthers routine is never called, KeepClientIds and CopyIds match in a way that prevents an intended hiding step, and one service check can count a stopped client as running. The first operator-safety check, Test-LabOnlyOwnClients, always returns false in the recovered build, leaving protection against striking the attacker’s own systems dependent on a separate hostname exclusion list. Those issues do not make the observed unauthorized installations harmless, but they help explain why the intended loop may be less reliable than the design suggests. 

Cleanup adds another wrinkle. The recovery path can rearm persistence unless invoked with -NoReArm, and -NoRun does not suppress all preliminary downloads, writes, or cleanup behavior. A responder who assumes either switch makes the script entirely inert could be surprised by the resulting activity. The SRP-related registry changes also deserve care: a mistakenly restrictive global default could disrupt legitimate execution across the host. 

A separate question is the role of third-party ScreenConnect extensions. ConnectWise has reported precautionary disabling of five independently developed extensions across approximately 400 partner environments while investigating possible initial access paths. APG found no technical link between those extensions and SCKit’s RelayTrap execution request or its browser session collection routines. Their possible role in obtaining the first management-panel access remains a separate, unresolved question. 

The immediate intrusion risk does not depend on that entire chain succeeding. A rogue Access client gives an attacker a separate remote control channel, and possession of an authenticated management session can already enable command distribution through legitimate features. Neither condition, by itself, proves that the Guest-to-Host transfer succeeded or that the session-hijacking code recovered a cookie. 

Taken together, the results show a toolkit with a coherent ambition but uneven reliability. Its observed deployments establish the practical threat, while code review and testing identify the boundaries between attempted file execution, local cookie recovery, and authenticated panel fan-out. Those boundaries are the most useful places for defenders to hunt, validate impact, and avoid assuming that every intended stage succeeded. 

Conclusion 

SCKit shows how an attacker can use a trusted remote management platform for more than distributing a malicious installer. The campaign began with unauthorized ScreenConnect deployments through legitimate management instances, while the recovered toolkit revealed an additional plan to turn subsequent support connections against the technicians making them. 

The toolkit combines encrypted delivery, rogue Access enrollment, a replacement ScreenConnect Guest, and local browser session collection. The Guest-to-Host technique targets CVE-2026-84869, while the later panel code attempts to reuse a technician’s existing permissions to distribute commands to other managed endpoints. These are distinct steps, each with its own prerequisites and opportunities for detection. 

Blackpoint’s SOC confirmed unauthorized deployments. APG also independently recovered the campaign’s staged components and tested the reverse transfer against a current ScreenConnect Host client, where the request was queued but the payload was neither retrieved nor executed. Neither campaign telemetry nor controlled testing established successful propagation to a technician workstation or a bypass of the vendor patch. 

For MSPs, the practical lesson is to investigate the management relationship, not only the endpoint. Rogue Access installations, administrative command history, technician workstations, and browser sessions all deserve attention, especially when support personnel have already connected to a suspected system. 

SCKit may not have completed the full worm-like loop visible in its code, but the observed abuse of ScreenConnect was enough to establish unauthorized access. Understanding exactly where the attempted expansion stops is essential to separating confirmed compromise from the additional risk the toolkit was built to create. 

Recommendations 

• Audit ScreenConnect extensions. Review independently developed RMM integrations with remote command capabilities for unexpected configuration changes or API activity. Their presence alone does not establish involvement in SCKit, and APG identified no direct link to its reverse transfer or session theft routines. 

• Investigate suspicious ScreenConnect activity. Review operator sessions, Run Command history, and Shared Toolbox activity for unauthorized commands, unusual software deployments, and similar actions executed across multiple managed endpoints. 

• Identify unauthorized ScreenConnect Access clients. Audit installed clients and their configured relay addresses against approved management infrastructure. Investigate unexpected secondary installations, particularly those communicating with infrastructure associated with this campaign. 

• Update ScreenConnect clients. Verify that technician-side Host and endpoint-side Guest clients have been updated to a patched build, 26.6.5.9742 or later, and follow ConnectWise’s guidance on reinstalling Host clients and updating Access agents. Avoid interactive ScreenConnect connections to suspected trapped endpoints until RelayTrap has been ruled out; use an isolated response channel instead. 

• Hunt for SCKit artifacts. Investigate TrapWatch, C:\ProgramData\RelayTrap, the RelayTrapLiteAlert Run key, new Defender exclusions for msiexec.exe or powershell.exe, and PowerShell connections to ns.mo7sen[.]dev. Review ScreenConnect event ID 201 in session context for file transfer and execution activity. Include generated filenames matching k[0-9a-f]{32}\.ps1, not only a literal k.ps1. 

• Revoke potentially compromised sessions. If a technician interacted with a suspected endpoint, review their workstation for execution and browser-cookie access, terminate potentially exposed ScreenConnect web sessions from a clean device, and rotate affected credentials. Do not assume that the absence of the separate LabConfig.ps1 file rules out the delivered panel script. 

Indicators of Compromise 

Host and File Indicators 

Indicator	SHA-256
Stage0Loader.ps1	81cc2baa35b798d6084bd078662fa29ff28df02c46c6ccdb2b43bde97d19f781
SilentForceInstall-WithUninstall.ps1	a1937467fd862916f89342cdd61f55c4bc405fb35b6e1379e27cfbfdba77dcdc
p=4 decoder	338e37f58043635ebab64ee5fdc919935e55cb146ca97834b358f934e55e88ec
p=3 decoded bundle	8e6912deed82e80bb6bd66f73509d024b1f78b993515366d8317e69a97cff4f4
RelayTrap.cs	3c7a98f0fdb6235b8076319c74dc1085f7b349b6d750416dd0cadb07d7972ec4
TrapWatch.ps1	d2ed7a7bf4f8ac9c7969e9b3a07ebd4dda0d858f372c876ac0a041611698de9a
Panel-Lateral-free.ps1	94b93c649b0ae0281352da9d01761fa9195ab1e6ac7010af3b9ba1646355eb11
ToolboxRelayUploader.exe	8cb5f48bbe70b5248db7f327f3d1ad6649df5c767d2a7e0711ee147fd92e06af
ScreenConnect.ClientSetup.msi	d85315bd7602b6f5c13dc0eada2c9cba0892c7cd3b1eb7dacb1bffdd536ceb21

Network Indicators 

Indicator	Context
185.99.255[.]28	Threat Actor ScreenConnect Server
hxxps://ns.mo7sen[.]dev/EadF.php	Initial staging and bootstrap
sc.payproofkit[.]com	Configured Access installer source
cdn007-digitaldownloads[.]com	Recovered Access MSI source
soxnewwork.homedns[.]org	Relay embedded in recovered MSI
newnewnew.gotdns[.]org	Configuration / skip-list indicator
2588ef5c15954b10	Configured first Access client
ed630cc2c873b091	Configured second Access client

Subscribe to receive updates from Blackpoint’s Adversary Pursuit Group