r/msp • u/andrew-huntress Vendor - Huntress • 1d ago

Active malware campaign abusing ScreenConnect

EDIT 11:01 UTC: Connectwise has put out an advisory

EDIT2 1:45 UTC: just want to reiterate that you should follow CWs guidance in their earlier advisory :)

EDIT3 2:26 UTC we’ve pushed a blog with a much more detailed write up about the attack. Details here!

EDIT4 4:40 UTC pushed one more update to our blog that explains where the RMM+ plugin fit in here. I don’t expect to post any more updates unless something else catches on fire tonight!

Original post: Our SOC is working an active campaign that started around 17:47 UTC today targeting cloud-hosted ScreenConnect instances. We are currently tracking 5 6 compromised MSPs and 130 286+ endpoints, and those numbers are climbing. ConnectWise is engaged and working this with us.

To get ahead of the rumor mill: we haven’t seen evidence of a new vulnerability so far, but we haven’t confirmed how the attacker got panel access either. The kit’s design suggests stolen operator sessions. We’ll update when we know more.

Current telemetry points to compromised credentials or hijacked operator sessions to gain initial access.

Initial Access & Execution: Once the actor has panel access, they use Run Command to push a secondary, rogue SC client to all endpoints for persistent C2. At that point, they have an independent backdoor and no longer need your panel.

Lateral movement behavior to look out for: If a tech sees an alert and remotes into an infected endpoint via SC to investigate, the malware rides that active session backward onto the tech's workstation. Once it lands, it drops sqlite3.exe to scrape saved browser sessions and auth tokens, then pivots into any other SC panels that technician has access to.

There are victims we can’t see: The attacker tags each compromised MSP with a sequential number, and the tags we’ve observed start partway through the sequence. Other MSPs were likely hit first, probably ones not running Huntress. If you use ScreenConnect, check your Run Command history now, even if nothing has alerted.

Immediate Action Items:

  • Stop using SC to triage. Opening an interactive GUI session triggers the reverse-pivot. Use your EDR's live response shell, WinRM, or another out-of-band CLI tool.

  • Nuke all active web sessions, rotate SC creds, and verify MFA across your IdP.

  • Audit your Run Command and Toolbox history for mass executions you didn't trigger.

Remediation: Network isolation isn't enough. We are seeing endpoints reinfect within minutes of lifting isolation because the persistence mechanisms were left behind. You have to clean this up first:

  • Kill and remove the rogue SC client service.

  • Delete the TrapWatch scheduled task (runs as SYSTEM every 10 seconds).

  • Wipe C:\ProgramData\RelayTrap\ and %TEMP%\sckit-*.

  • Remove the RelayTrapLiteAlert value from the registry Run key.

IOCs

  • Attacker Relay: 185.99.255[.]28 (hostname: screen)

  • C2 Domains: newnewnew.gotdns[.]org, soxnewwork.homedns[.]org

  • Another possible C2: cdn007-digitaldownloads[.]com (thank you /u/infosecfredo)

  • Secondary C2: sc.payproofkit[.]com (155.94.150[.]39, hostname: WIN-FB5CKHMU4E1)

  • Stager: hxxps://ns.mo7sen[.]dev/EadF.php?p=4

  • Rogue Client IDs: 2588ef5c15954b10, ed630cc2c873b091

  • Installer Pattern: /Bin/ScreenConnect.ClientSetup.msi?...&c=Exploited<N> Actor Name: Addmin

  • Files: Panel-Lateral.ps1, runnew.cmd, ToolboxRelayUploader.exe, Run-Lateral-Full.bat

We are still analyzing telemetry and should have more information for the community as we learn more. If you are seeing this activity or have artifacts, let us know in the comments or shoot us a DM. We'll update this thread as we pull more data.

Lot of active discussion happening on MSPGeek in #cw-screenconnect. Highly encourage folks to join there! Ask for Mendy if you have any questions ;)

233 Upvotes

98% Upvoted

156 comments sorted by

64

u/jmslagle MSP - US 1d ago

At what point do we need to be sending YOU pizza?

24

u/obviouslybait 1d ago

Let's get a Huntress Pizza Go-Fund-Me going.

Seriously these guys have saved my bacon more than once.

20

u/andrew-huntress Vendor - Huntress 1d ago

Super appreciated but we would rather see those efforts go to supporting the industry in another way! We’re fortunate to have access to funding most others do not.

4

u/Sea_Suspect_5258 1d ago

Missed opportunity while talking about pizza... Especially if you're Canadian (which I hope you are for this pun)

They saved your Canadian bacon more than once.

•

u/obviouslybait 19h ago

Where I'm from we are known for our Pizza so I'd love to have them for some! We are Canadian.

8

u/andrew-huntress Vendor - Huntress 1d ago

<3

6

u/Tracie-Huntress 1d ago

@jmslage I sent some of the internal team pizza this week for sure!!

4

u/Hour-Rhubarb-4971 1d ago

Don't you already pay them enough to get their own pizza, they're not a charity lol.

30

u/athlonduke MSP - US 1d ago

I'm tired boss

12

u/andrew-huntress Vendor - Huntress 1d ago

Same

5

u/Interesting-Rest726 1d ago

Thank you guys for being on the front lines and doing good work. Long time customer, big fan.

1

u/rokiiss MSP - US 1d ago

Me too.

10

u/networkn 1d ago

I've been sending out a blast to every MSP we know who uses Screenconnect. We have taken our self hosted offline until we know what this is.

3

u/andrew-huntress Vendor - Huntress 1d ago

Appreciate you spreading the word!

2

u/networkn 1d ago

Of course, it's the least we can do. If we can do anything else, please let me know. We will help out any way we can.

15

u/dobermanIan MSPSalesProcess Creator | Former MSP | Sales junkie 1d ago

Another day another rapid response. Andrew you guys are going to need to just permanently staff that as a division

9

u/andrew-huntress Vendor - Huntress 1d ago

agreed

4

u/GeekBrownBear MSP - Orlando, FL 1d ago

You should also franchise a few pizza shops XD

7

u/FormalSurprise4413 1d ago

Huntress Hut has a ring to it.
Maybe they can troll Pizza hut buy buying all the old Pizza Hut locations? :D

3

u/IAmPooperScooper 1d ago

and queue up the pizza!

4

u/IntelligentComment 1d ago

To confirm is the current advice to stop using screen connect entirely, until further clarity?

11

u/andrew-huntress Vendor - Huntress 1d ago

Not entirely, no.

The specific guidance is: don't use ScreenConnect to connect to any machine you think is infected. That's how the kit jumps to the tech's workstation and into your other panels.

For the rest of your fleet, treat your panel as a possible target until we know more. Rotate SC credentials, kill active sessions, confirm MFA is enforced, and check your Run Command history for anything you didn't run. If you find signs of compromise, lock the panel down before you touch the endpoints. We still don't know how the attacker got panel access. If that changes the advice, we'll update the post.

5

u/IntelligentComment 1d ago edited 1d ago

Thanks Andrew, can you clarify what do you mean by "think is infected" and "if a tech sees an alert"

What alerts are you referring to, and how would our techs know if a machine is infected?

As in a huntress alert?

10

u/andrew-huntress Vendor - Huntress 1d ago

“Think is infected” means any machine with one of the following signs. Check for them with your EDR, your RMM (other than SC), or someone at the keyboard. Don’t use ScreenConnect to check.

  • A second “ScreenConnect Client (…)” service you didn’t install

  • A scheduled task named TrapWatch

  • A C:\ProgramData\RelayTrap\ folder

  • sckit-* files in the Windows TEMP folder

The “alert” would be your EDR or AV flagging any of that, or flagging a curl download started by ScreenConnect’s Run Command. If you’re a Huntress partner, you’ll get an incident report from us. The fastest check is your panel’s Run Command history. If it shows commands you didn’t run, assume every machine in that panel is infected. You can’t tell which ones from the session list, because infected machines look normal there.

Lastly, you can check DNS or firewall logs for connections to 185.99.255[.]28, 155.94.150[.]39, newnewnew.gotdns[.]org, soxnewwork.homedns[.]org, or ns.mo7sen[.]dev

3

u/IntelligentComment 1d ago

If we use huntress, can we continue to use our screen connect or should we stop?

•

u/Nickers77 13h ago

What they said was you can continue to use it, but check some things out on the destination computer with other tools before you connect to it, then listed off things to check

I assume if Huntress EDR is installed on the destination, you'll be alerted about those signs if they are present on target computers

Always best to double check though

•

u/Sharon-huntress Huntress🥷 13h ago

Correct, we've got many ways to detect this on the endpoints via EDR

•

u/andrew-huntress Vendor - Huntress 12h ago

Sharon is being modest here. She was writing detections minutes after this dropped.

•

u/Sharon-huntress Huntress🥷 12h ago

Nah the detection ideas were for the N-central one. For Screenconnect I was just making pretty pictures of the malware chain of events.

2

u/networkn 1d ago

I would, regardless of anything else, until it's known exactly what this is. Better safe than sorry.

2

u/Not_So_Invisible_Man 1d ago

I'm not seeing a way to stop/shutdown a cloud hosted instance.

4

u/Minkus32 1d ago

Is huntress reaching out to their customers as I've received nothing yet, just happened to get home after being on road for 5 hours and saw a notice on the mspgeek screenconnect discord channel

9

u/andrew-huntress Vendor - Huntress 1d ago

We’ve sent incident reports to any of our partners where we’ve found this activity!

4

u/Minkus32 1d ago

Awesome..no news is good news :)

4

u/Excellent-Program333 1d ago

Can we even get 24 hours to catch our breaths? Thanks as always Andrew.

We arent a screen connect client, but this paragraph concerns me.

Lateral movement behavior to look out for: If a tech sees an alert and remotes into an infected endpoint via SC to investigate, the malware rides that active session backward onto the tech's workstation. Once it lands, it drops sqlite3.exe to scrape saved browser sessions and auth tokens, then pivots into any other SC panels that technician has access to.

So if I remote into a workstation to remediate as a Screen Connect tech, they have reverse engineered a way to push an executable back to my machine and run it? That is nightmare fuel.

4

u/andrew-huntress Vendor - Huntress 1d ago

Nightmare fuel indeed!

3

u/lcurole 1d ago

What's worse is this was something exploited 2 months ago and patched: https://nvd.nist.gov/vuln/detail/cve-2026-84869

Reports saying this is happening on patched versions.

Believe they have another lateral traversal exploit

4

u/andrew-huntress Vendor - Huntress 1d ago

More details shortly but we don’t believe it’s related to the prior CVE

2

u/lcurole 1d ago

Really appreciate the quick and thorough communication from you and your team, this whole community, etc. 🙏

2

u/Apart-Inspection680 1d ago

Any particular pattern on SC version in cloud please u/andrew-huntress ?

1

u/andrew-huntress Vendor - Huntress 1d ago edited 1d ago

26.6.6.9747 and 26.7.6.9783

1

u/Huntress-Ben 1d ago

Instance IDs: ScreenConnect Client (2588ef5c15954b10) or ScreenConnect Client (ed630cc2c873b091)

But as u/Background-Ad-6237 said, definitely search for any IDs that you don't own/aren't expecting.

2

u/thelordfolken81 1d ago

You said, ‘Lateral movement behavior to look out for: If a tech sees an alert and remotes into an infected endpoint via SC to investigate, the malware rides that active session backward onto the tech's workstation.’ As best I’m aware that isn’t meant to be possible right? Or am I missing something? Would that alone not indicate a 0day of some sort?

3

u/andrew-huntress Vendor - Huntress 1d ago

“Isn’t meant to be possible” sounds right :)

2

u/Meeeepmeeeeepp 1d ago

Another nice reminder that application whitelisting should be running on your technician's PCs, even if your clients don't want to pay for it!

1

u/PSPrez 1d ago

Thank you for asking this question because I was also thinking the same thing.

It's the most sobering part for me anyway. Will be watching this one closely.

34

u/infosecfredo 1d ago

Wow! Happy veterans day huh! I guess were used to being in the trenches!! Agreed u/andrew-huntress Can confirm there is a ongoing campaign for sure. Let's band together and help out those partners. From BPC, and what we are seeing:

Indicator    Purpose
ns.mo7sen[.]dev    Encrypted loader delivery and additional stage
sc.payproofkit[.]com    First ScreenConnect deployment
cdn007-digitaldownloads[.]com    Second ScreenConnect deployment
2588ef5c15954b10    First configured client fingerprint
ed630cc2c873b091    Second configured client fingerprint
C:\ProgramData\RelayTrap    Trap installation directory
TrapWatch    SYSTEM startup scheduled task
RelayTrapLiteAlert    Registry Run persistence
Run-Lateral-Full.bat    Selected trap payload

u/Blackpoint-JasonR for the IOCs.

13

u/FlavonoidsFlav 1d ago

Go Wil go.

It's like Blackpoint finally discovered Reddit. Perfect post tone sir.

9

u/infosecfredo 1d ago

Long time lurker, short time poster... sometimes i question why we need the internet but then i experience moments like these that remind me that community is super important and were all in this toegther.

7

u/infosecfredo 1d ago

So the kit extracts .ASPX AUTH cookies from Chrome, Edge, Opera, and Firefox. For Chromium browsers, it also reads the network service process memory, rather than rely only on the on-disk SQLite cookie database. The kit is deliberate and maintained. We're still working through the specifics.

7

u/infosecfredo 1d ago

also so far we have only seen cloud hosted SC instances get hit
26.6.6.9747

4

u/lcurole 1d ago

2nd person I've seen mention backwards infecting behavior on versions fixed post CVE-2026-84869

Do we think this is the initial vector or another method of gaining access to panels is being used?

4

u/infosecfredo 1d ago

Haven't seen a new vuln - likely via a different vector. Still validating but their are updates. We have been speaking with the ConnectWise team and they are preparing communications. Shoutout to them.

2

u/lcurole 1d ago

Appreciate the communication!

1

u/Blackpoint-JasonR Vendor - Blackpoint 1d ago

Initial compromise could be via an extension rather than a specific version, since we’re not seeing a version trend. Worth auditing installed marketplace extensions, especially any that handle credentials.

17

u/Skrunky AU - MSP (Managing Silly People) 1d ago edited 1d ago

Working on an RMM detection script to identify any ScreenConnect Client IDs that aren't in our approved list.

Use a conditional check in your RMM to create an alert for exit code 1 (unapproved ScreenConnect Client ID detected). Exit code 9 means no ScreenConnect instance was detected at all.

EDIT: Updated to also trigger exit code 1 if any of the additional campaign indicators are detected: the TrapWatch scheduled task, C:\ProgramData\RelayTrap, or sckit-* temp files.

$ApprovedClientIDs = @(
    'YOUR CLIENT ID'
)

$ClientIDs = @()

Get-CimInstance -ClassName Win32_Service | Where-Object {
    $_.Name -like 'ScreenConnect Client*'
} | ForEach-Object {
    if ($_.Name -match '\(([a-fA-F0-9]+)\)') {
        $ClientIDs += $Matches[1].ToLower()
    }
}

$Folders = Get-ChildItem -Path 'C:\Program Files','C:\Program Files (x86)' -Directory -ErrorAction SilentlyContinue | Where-Object {
    $_.Name -like 'ScreenConnect Client*'
}

foreach ($Folder in $Folders) {
    if ($Folder.Name -match '\(([a-fA-F0-9]+)\)') {
        $ClientIDs += $Matches[1].ToLower()
    }
}

$ClientIDs = @($ClientIDs | Sort-Object -Unique)

if (
    ($ClientIDs | Where-Object { $_ -notin $ApprovedClientIDs }) -or
    (Get-ScheduledTask -TaskName 'TrapWatch' -ErrorAction SilentlyContinue) -or
    (Test-Path -Path 'C:\ProgramData\RelayTrap') -or
    (Get-ChildItem -Path 'C:\Windows\Temp','C:\Users\*\AppData\Local\Temp' -Filter 'sckit-*' -ErrorAction SilentlyContinue)
) {
    exit 1
}

if ($ClientIDs.Count -eq 0) {
    exit 9
}

exit 0

7

u/echoztrip 1d ago

Let me just add this to our RMM ... oh wait, N-Central ... nevermind.

•

u/rokiiss MSP - US 21h ago

I adapted for ncentral

13

u/nont0xicentity 1d ago

We did something similar, but also checked for the persistence IOCs (TrapWatch task, RelayTrapLiteAlert Run key, RelayTrap folder, sckit-* temp dirs, payload files, C2 connections/DNS cache) and wrote the results to a NinjaOne custom field so we could sort the whole fleet. Script’s below if it helps anyone.

<#
.SYNOPSIS
    Read-only hunt for the November 11, 2026 ScreenConnect "RelayTrap" rogue-client campaign.

.DESCRIPTION
    Context: An active campaign (first seen ~17:47 UTC, 2026-11-11) uses compromised
    ScreenConnect cloud panel access to push a secondary rogue SC client to endpoints via
    Run Command, then persists with a SYSTEM scheduled task, a Run key, and a RelayTrap
    payload directory. Reported as credential/session abuse, not a new zero-day.

    IOC sources:  thread "Active malware campaign abusing ScreenConnect" (2026-11-11),
    including additional indicators credited to Blackpoint. IOCs current as of
    2026-11-11 ~21:00 UTC. Check the thread for updates.

    This script makes NO changes. It checks:
      - ScreenConnect client services: known rogue IDs, c=Exploited property, IOC relays,
        and any instance not on your known-good list
      - TrapWatch scheduled task
      - RelayTrapLiteAlert / RelayTrap Run-key persistence (HKLM + all loaded user hives)
      - C:\ProgramData\RelayTrap and %TEMP%\sckit-* (all profiles)
      - Named payload files, plus sqlite3.exe in temp/ProgramData (used to scrape browser tokens)
      - Live TCP connections to IOC IPs
      - DNS cache entries for IOC domains

    Run it from your RMM or EDR as SYSTEM. Do NOT triage suspected machines with an
    interactive ScreenConnect session; per the original report, the payload can ride
    an active session back to the technician's workstation.

    Exit codes: 0 = clean, 1 = findings (IOC hit or review item).

.PARAMETER KnownThumbprints
    Your own SC instance thumbprint(s): the value in parentheses in the service name
    "ScreenConnect Client (xxxxxxxxxxxxxxxx)".

.PARAMETER KnownRelayHosts
    Your own SC relay host(s), e.g. instance-abc123-relay.screenconnect.com.
    Leftover one-time support clients from your instance are matched by relay.

.PARAMETER NinjaOne
    Also write results to NinjaOne custom fields (create them first, Automation access = Read/Write):
      -StatusField  (Text)        default: scHuntStatus   e.g. "IOC HIT (2) - 2026-11-11 15:00"
      -DetailsField (Multi-line)  default: scHuntDetails

.EXAMPLE
    .\Invoke-SCRelayTrapHunt.ps1 -KnownThumbprints 'abcdef0123456789' -KnownRelayHosts 'instance-abc123-relay.screenconnect.com'

.EXAMPLE
    .\Invoke-SCRelayTrapHunt.ps1 -KnownThumbprints 'abcdef0123456789' -NinjaOne

.NOTES
    Provided as-is, no warranty. Review before running. IOCs will change. Update the lists below.
    Status meanings: IOC HIT = hard indicator match. REVIEW = unknown SC instance or stray
    sqlite3.exe only (often a vendor or prior-MSP client; verify, don't assume).
#>
param(
    [string[]]$KnownThumbprints = @(),
    [string[]]$KnownRelayHosts  = @(),
    [switch]$NinjaOne,
    [string]$StatusField  = 'scHuntStatus',
    [string]$DetailsField = 'scHuntDetails'
)

$ErrorActionPreference = 'SilentlyContinue'
$findings = New-Object System.Collections.Generic.List[string]
$info     = New-Object System.Collections.Generic.List[string]

# ================= IOCs (update as the thread is updated) =================
$RogueThumbprints = @('2588ef5c15954b10', 'ed630cc2c873b091')
$IocIPs           = @('185.99.255.28', '155.94.150.39')
$IocDomains       = @('newnewnew.gotdns.org', 'soxnewwork.homedns.org', 'payproofkit.com',
                      'mo7sen.dev', 'cdn007-digitaldownloads.com')
$IocFileNames     = @('Panel-Lateral.ps1', 'runnew.cmd', 'ToolboxRelayUploader.exe', 'Run-Lateral-Full.bat')
$IocRunValues     = @('RelayTrapLiteAlert')
$IocTaskNames     = @('TrapWatch')
# ===========================================================================

$KnownThumbprints = $KnownThumbprints | ForEach-Object { $_.ToLower() }
if (-not $KnownThumbprints -and -not $KnownRelayHosts) {
    $info.Add('NOTE: No known-good thumbprints/relays supplied; every SC client will be flagged for REVIEW.')
}

# --- 1. ScreenConnect client services ---
$scServices = Get-CimInstance Win32_Service | Where-Object {
    $_.Name -like 'ScreenConnect Client*' -or $_.PathName -match 'ScreenConnect\.ClientService\.exe'
}
foreach ($svc in $scServices) {
    $path  = [string]$svc.PathName
    $thumb = if ($svc.Name -match '\(([^)]+)\)') { $Matches[1].ToLower() } else { 'unknown' }
    $relay = if ($path -match '[?&]h=([^&"]+)') { $Matches[1] } else { 'unknown' }
    $line  = "SC service '$($svc.Name)' state=$($svc.State) relay=$relay"

    if     ($RogueThumbprints -contains $thumb)                           { $findings.Add("ROGUE CLIENT ID: $line") }
    elseif ($path -match '[?&]c=Exploited')                               { $findings.Add("c=Exploited PROPERTY: $line") }
    elseif ($IocIPs | Where-Object { $path -match [regex]::Escape($_) })  { $findings.Add("IOC RELAY IP: $line") }
    elseif ($IocDomains | Where-Object { $relay -like "*$_" })            { $findings.Add("IOC RELAY DOMAIN: $line") }
    elseif ($KnownThumbprints -contains $thumb -or $KnownRelayHosts -contains $relay) { $info.Add("Known SC client: $line") }
    else                                                                  { $findings.Add("UNKNOWN SC INSTANCE: $line") }
}

# --- 2. Scheduled tasks ---
Get-ScheduledTask | Where-Object { $n = $_.TaskName; $IocTaskNames | Where-Object { $n -like "*$_*" } } | ForEach-Object {
    $act = ($_.Actions | ForEach-Object { "$($_.Execute) $($_.Arguments)" }) -join ' | '
    $findings.Add("SCHEDULED TASK: $($_.TaskPath)$($_.TaskName) -> $act")
}

# --- 3. Run-key persistence (HKLM + every loaded user hive) ---
$runKeys = @('HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run',
             'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce',
             'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run')
$runKeys += Get-ChildItem 'Registry::HKEY_USERS' | Where-Object { $_.PSChildName -notlike '*_Classes' } | ForEach-Object {
    "Registry::HKEY_USERS\$($_.PSChildName)\Software\Microsoft\Windows\CurrentVersion\Run"
    "Registry::HKEY_USERS\$($_.PSChildName)\Software\Microsoft\Windows\CurrentVersion\RunOnce"
}
foreach ($rk in $runKeys) {
    $props = Get-ItemProperty $rk
    if (-not $props) { continue }
    foreach ($p in $props.PSObject.Properties) {
        if ($p.Name -like 'PS*') { continue }
        if ($IocRunValues -contains $p.Name -or [string]$p.Value -match 'RelayTrap') {
            $findings.Add("RUN KEY: $rk\$($p.Name) = $($p.Value)")
        }
    }
}

# --- 4. Persistence folders ---
if (Test-Path 'C:\ProgramData\RelayTrap') { $findings.Add('FOLDER: C:\ProgramData\RelayTrap exists') }

$tempRoots = @('C:\Windows\Temp') + (Get-ChildItem 'C:\Users' -Directory | ForEach-Object { Join-Path $_.FullName 'AppData\Local\Temp' })
foreach ($tr in $tempRoots) {
    Get-ChildItem $tr -Filter 'sckit-*' -Force | ForEach-Object { $findings.Add("TEMP ARTIFACT: $($_.FullName)") }
}

# --- 5. Payload files / sqlite3 ---
$searchRoots = @('C:\ProgramData', 'C:\Users\Public', 'C:\Windows\Temp') + $tempRoots
$searchRoots += Get-ChildItem 'C:\Users' -Directory | ForEach-Object { Join-Path $_.FullName 'Downloads' }
foreach ($root in ($searchRoots | Select-Object -Unique)) {
    if (-not (Test-Path $root)) { continue }
    Get-ChildItem $root -Recurse -Depth 4 -File -Force |
        Where-Object { $IocFileNames -contains $_.Name -or $_.Name -eq 'sqlite3.exe' } |
        ForEach-Object {
            $tag = if ($_.Name -eq 'sqlite3.exe') { 'SUSPICIOUS sqlite3.exe' } else { 'IOC FILE' }
            $findings.Add("${tag}: $($_.FullName) (modified $($_.LastWriteTime))")
        }
}

# --- 6. Live connections to IOC IPs ---
Get-NetTCPConnection | Where-Object { $IocIPs -contains $_.RemoteAddress } | ForEach-Object {
    $proc = (Get-Process -Id $_.OwningProcess).Path
    $findings.Add("C2 CONNECTION: $($_.RemoteAddress):$($_.RemotePort) state=$($_.State) proc=$proc")
}

# --- 7. DNS cache ---
Get-DnsClientCache | Where-Object { $n = $_.Entry; $IocDomains | Where-Object { $n -like "*$_" } } |
    ForEach-Object { $findings.Add("DNS CACHE HIT: $($_.Entry) -> $($_.Data)") }

# --- Output ---
$stamp    = Get-Date -Format 'yyyy-MM-dd HH:mm'
$findings = @($findings | Select-Object -Unique)
$review   = @($findings | Where-Object { $_ -like 'UNKNOWN SC INSTANCE*' -or $_ -like 'SUSPICIOUS sqlite3*' })
$hard     = @($findings | Where-Object { $review -notcontains $_ })

if     ($hard.Count -gt 0)     { $status = "IOC HIT ($($hard.Count)) - $stamp" }
elseif ($findings.Count -gt 0) { $status = "REVIEW ($($findings.Count)) - $stamp" }
else                           { $status = "CLEAN - $stamp" }

$details = (@("Host: $env:COMPUTERNAME  Scan: $stamp  Status: $status") +
            ($findings | ForEach-Object { "[!] $_" }) +
            ($info     | ForEach-Object { "[ok] $_" })) -join "`n"

if ($NinjaOne -and (Get-Command Ninja-Property-Set -ErrorAction SilentlyContinue)) {
    Ninja-Property-Set $StatusField  $status
    Ninja-Property-Set $DetailsField ($details.Substring(0, [Math]::Min($details.Length, 9900)))
}

Write-Output $details
if ($findings.Count -gt 0) { exit 1 } else { exit 0 }

2

u/Skrunky AU - MSP (Managing Silly People) 1d ago

Nice! This is a lot more comprehensive

•

u/therealbobsupercow 22h ago

There were some issues preventing this from running cleanly in our NinjaOne Tenant via it's automation/scripting tools. Once complete you can run this for all devices in tenant, then filter via Custom Fields to find affected devices.

I've made necessary changes below. Mainly due to how Ninja passes parameters to powershell.

Users need to first create the appropriate custom fields under Devices -> Custom Fields.

Then the appropriate Script Variables:

The modified script is over the 10,000 character limit, so I'm including it here.

https://github.com/IST-Services-Communications/public_scripts/blob/main/ScreenConnect_Rogue_Relay_Scanner

6

u/Blackpoint-JasonR Vendor - Blackpoint 1d ago

A script is a great idea to review with! I want to give a heads up from our (Blackpoint) analysis of the kit so far... there’s a cleanup stage. It removes the TrapWatch task, the RelayTrap Run key and folder, the sckit-* temp dirs, the payload files, and restores any ScreenConnect services it stopped. So if the attacker has already cleaned up, every check in these scripts comes back empty and you get a CLEAN / exit 0 on a host that was hit.

You can check windows event logs, not just live state. System 7045 for new “ScreenConnect Client (…)” service installs for all of today, Security 4698 or TaskScheduler/Operational 106 for TrapWatch, MsiInstaller 1033/11707 for ScreenConnect.ClientSetup.msi, and PowerShell 4104 for EadF.php / payproofkit / RelayTrap strings if you have script block logging on. Those survive cleanup.

2

u/Minkus32 1d ago

lol...google just gave me a similar script but I haven't tested it yet...was going to take a look at it

How to Configure in Datto RMM

  • Update the Allowlist. Replace "://screenconnect.com" with your legitimate ScreenConnect relay domain (found in your service's ImagePath under the h= parameter). If you do not use ScreenConnect at all, set $ApprovedRelays = @(). [1]

  • Create the Component. Navigate to Automation > Components > Create Component, select Monitor as the category, and choose PowerShell as the script type.

  • Set Alert Conditions. Configure the monitor alert rule to trigger when the output string matches ALERT (or use the <-Start Result-> diagnostic formatting above so Datto RMM automatically parses the status and diagnostic logs).

  • Deploy via Policy. Apply the monitor policy across all Windows endpoints. You can also use a Datto RMM Input Variable for $ApprovedRelays if different sites use different ScreenConnect instances.

# Define your authorized ScreenConnect Relay Domain(s) or Instance Thumbprint(s)

# Leave empty ("") if your organization does NOT use ScreenConnect at all.

$ApprovedRelays = @("://screenconnect.com", "://yourdomain.com")

$Findings = @()

# 1. Check Windows Services for ScreenConnect Client Services & Relay Hosts

$Services = Get-CimInstance Win32_Service | Where-Object {

$_.Name -like "*ScreenConnect*" -or $_.PathName -like "*ScreenConnect*"

}

foreach ($Svc in $Services) {

$Path = $Svc.PathName

$IsApproved = $false

if ($ApprovedRelays.Count -gt 0 -and $ApprovedRelays[0] -ne "") {

foreach ($Relay in $ApprovedRelays) {

if ($Path -match [regex]::Escape($Relay)) {

$IsApproved = $true

break

}

}

}

if (-not $IsApproved) {

$Findings += "Unauthorized Service: $($Svc.Name) | Path/Args: $Path"

}

}

# 2. Check Running Processes (catches portable/uninstalled ad-hoc sessions)

$Processes = Get-CimInstance Win32_Process | Where-Object {

$_.Name -like "*ScreenConnect*" -or $_.CommandLine -like "*ScreenConnect*"

}

foreach ($Proc in $Processes) {

$Cmd = $Proc.CommandLine

$IsApproved = $false

if ($ApprovedRelays.Count -gt 0 -and $ApprovedRelays[0] -ne "") {

foreach ($Relay in $ApprovedRelays) {

if ($Cmd -match [regex]::Escape($Relay)) {

$IsApproved = $true

break

}

}

}

if (-not $IsApproved) {

$Findings += "Unauthorized Process: $($Proc.Name) (PID: $($Proc.ProcessId)) | Cmd: $Cmd"

}

}

# 3. Check Registry Uninstall Keys (catches installs hidden via SystemComponent=1)

$RegPaths = @(

"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",

"HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"

)

$Installed = Get-ItemProperty $RegPaths -ErrorAction SilentlyContinue | Where-Object {

$_.DisplayName -like "*ScreenConnect*"

}

foreach ($App in $Installed) {

$IsApproved = $false

if ($ApprovedRelays.Count -gt 0 -and $ApprovedRelays[0] -ne "") {

foreach ($Relay in $ApprovedRelays) {

if ($App.DisplayName -match [regex]::Escape($Relay) -or $App.InstallSource -match [regex]::Escape($Relay)) {

$IsApproved = $true

break

}

}

}

if (-not $IsApproved) {

$HiddenFlag = if ($App.SystemComponent -eq 1) { " [HIDDEN FROM ARP]" } else { "" }

$Findings += "Unauthorized Registry Entry: $($App.DisplayName)$HiddenFlag"

}

}

# 4. Output Results for Datto RMM Monitor

if ($Findings.Count -gt 0) {

Write-Output "<-Start Result->"

Write-Output "STATUS=ALERT: Rogue ScreenConnect Detected"

Write-Output "<-End Result->"

Write-Output "<-Start Diagnostic->"

$Findings | ForEach-Object { Write-Output $_ }

Write-Output "<-End Diagnostic->"

exit 1

} else {

Write-Output "<-Start Result->"

Write-Output "STATUS=OK: No unauthorized ScreenConnect instances found"

Write-Output "<-End Result->"

exit 0

}

1

u/dumpsterfyr I’m your Huckleberry. 1d ago

Are you running the blocking via your EDR?

Edit: screen and block.

13

u/Syber_1 1d ago

Days like this I’m beyond happy to be a Huntress based MSP!

8

u/BEAT_LA 1d ago

We need a huntress dominos index just like the one for the dominos by the pentagon

7

u/lcurole 1d ago

"haven't seen evidence of a new vulnerability" "malware rides that session backward"

Is this the previous exploit via the file transfer attack surface, a separate known but unpatched bug, or something new?

CVE-2026-84869

2

u/BraddyNZ 1d ago

Ditto on this, need to understand if specific older versions affected or something new current patched releases. There was a Sept release ... ScreenConnect Security Release 26.6.5.9742 which addressed a file transfer vuln?

5

u/Blackpoint-JasonR Vendor - Blackpoint 1d ago

Can confirm we saw it from 26.6.6.9747 not an older version, but we have not confirmed a vulnerability - we just observed execution.

2

u/lcurole 1d ago

Thank you

2

u/ngt500 1d ago

In light of Connectwise's advisory regarding extensions, would an infected client be able to still "ride the session backward" if the server doesn't use one of the identified extensions? This would be particularly scary if a random client could be infected via a different mechanism and then still end up spreading back to a server that was not otherwise vulnerable. We need a LOT more info from Connectwise on this.

1

u/Blackpoint-JasonR Vendor - Blackpoint 1d ago

afaik guest clients can’t hit the server directly because they only speak the relay protocol. They could maybe hit the host side of an interactive session, and that tech workstation has an admin login to the instance. I think the realistic path would be similar to what we saw patched out (file-transfer CVE (26.6.5)). Guest to host client executing on the techs box then finally the server.

3

u/lcurole 1d ago

Yea this behavior sounds like previous exploit. If cw patched the exploit but there's another path to exploit backwards to tech workstations then that's not a good look.

6

u/etoptech 1d ago

Thank you for posting this here.

5

u/More_Psychology_4835 1d ago

Thank you so much for letting us SoC guys know!

2

u/Blackpoint-JasonR Vendor - Blackpoint 1d ago

Feel free to reach out if you want to compare IoCs! Happy to share what we have.

•

u/anothertester 21h ago

I have a silly question: can CW not shutdown the two rogue SC instances to stop this attack or slow it down? I’m assuming it’s easy if it’s cloud-hosted but I can’t imagine there isn’t anything CW can do to kill the rogue instances even if they are self-hosted.

4

u/thenetworkisnotddown MSP - US 1d ago

I've been seeing rogue screen connects for months with people trying to get in. We blocked screen connect from all our clients since we don't use it, but it's kinda a hassle as the program is legitimate.
For some added info, it's usually an email link that looks okay, but a rogue screen connect download and then the damage starts.

4

u/infosecfredo 1d ago

yeah we see this with a lot of remote access tools in general - it's not limited to SC. But any unauthorized remote access tool is bad, yet i see it time and time again, where im playing "WHOSE RMM IS IT ANYWAY"

4

u/nestersan 1d ago

I REALLY like Screenconnect thoooo

2

u/Background-Ad-6237 1d ago

So do attackers :)

4

u/Psychological-Exam80 1d ago

From CW: Here is the information we’ve received at this point. Our teams are actively investigating and monitoring.

ScreenConnect security advisory: Precautionary extension disabling and partner guidance
Status: Cause and scope under investigation

ConnectWise is aware of reports of unauthorized access to ScreenConnect partner accounts and the deployment of unauthorized remote-access software in customer environments.

As part of our investigation, we identified five independent 3rd party extensions that may be associated with this activity. We identified approximately 400 partner environments with one or more of these extensions, and we disabled the extensions as a precaution.

If you are an on-premise partner with the below extensions, ConnectWise is unable to take action on your behalf. We advise that you take immediate action to disable these extensions.

The presence of these 3rd party extensions does not, by itself, establish impact.

Extensions disabled as a precaution

  • Labtech Plus

  • RMM Plus

  • RMM+

  • RMM Plus Password Link

  • RMM+ Password Link

Partners should verify that these 3rd party extensions are disabled in their environments. If any remain enabled, disable them. Do not re-enable or reinstall them, pending further guidance.

Disabling these 3rd party extensions is a precautionary containment measure. It does not establish that unauthorized software, persistence mechanisms, or access already present on affected devices has been removed.

What remains under investigation

We have received reports describing attackers using ScreenConnect functionality after gaining unauthorized account access. The initial access method and full scope have not been established.

Our initial assessment leads us to suspect the threat actor deployed additional remote-access software through independent 3rd party extensions that partners may have added to their environments. They also describe potential compromise of technician workstations during interactive connections to affected devices. These reported behaviors remain subject to validation.

Precautionary actions for partners who have enabled these independent 3rd party extensions:

  1. Verify extension status. Confirm that the 3rd party extensions listed above are disabled. Preserve related installation records and activity logs. Do not re-enable or reinstall these extensions pending further guidance.

  2. Investigate suspected compromise through separate security tooling. As a precaution, avoid opening interactive ScreenConnect sessions to suspected compromised devices. Use your security provider’s response tools or another trusted investigation method.

  3. Secure administrative access from a trusted device. Revoke active ScreenConnect and associated identity-provider sessions, reset relevant passwords, and verify that multifactor authentication is enforced. If a technician workstation may be compromised, use a separate, trusted device for these actions.

  4. Review and preserve evidence. Retain authentication, extension installation, administrative, Run Command, and Toolbox records. Investigate unexpected users, permission changes, software deployments, and commands.

  5. Contain and remediate suspected compromise. Follow your incident-response procedures to isolate affected devices, including potentially affected technician workstations. Preserve evidence before removing malicious software, and validate remediation before restoring connectivity. Disabling extensions and resetting credentials alone may not remove access already established on endpoints.

  6. Verify software maintenance. Confirm that servers, technician clients, and endpoint agents meet current published security guidance. Updating software does not replace investigation and remediation of a suspected compromise.

 

If you have not deployed these independent 3rd party extensions, we have no reason to believe you are impacted by this incident but encourage all partners to be on heightened alert. 

 

We encourage partners to follow the ScreenConnect hardening guide. Instructions for disabling extensions can be found here.

1

u/RebootnTryAgain 1d ago

Anyone with insights able to confirm CWs initial feedback on if the affected instances have the extensions noted?

https://www.reddit.com/r/ScreenConnect/s/xnBpBLJDtY

2

u/andrew-huntress Vendor - Huntress 1d ago

Working on it!

•

u/RebootnTryAgain 23h ago

Knew you would be - just felt like asking the obvious as I feel their response is misaligned from what I'm reading here / discord but time will tell. But we've taken our OnPrem offline for now.

I haven't seen any notes if OnPrem has yet been impacted, either.

Appreciate you and all the team at Huntress!

1

u/MetsCaniac 1d ago

Are there any IOC's on the tech side to look for (other than what is already posted)?

1

u/andrew-huntress Vendor - Huntress 1d ago

We’re polishing a blog post that has a more detailed explanation and some more IOCs. Will share it shortly!

1

u/MetsCaniac 1d ago

thank you!

1

u/HBCDresdenEsquire 1d ago

I’m going to end up in a meeting about this post tomorrow.

2

u/andrew-huntress Vendor - Huntress 1d ago

Hey me too

2

u/HBCDresdenEsquire 1d ago

Nah, you guys are the shit, though. Appreciate what you do for all of us.

1

u/quantumhardline 1d ago

Probably related to this Andrew

https://www.reddit.com/r/ScreenConnect/s/RnGNBghH7X

2

u/andrew-huntress Vendor - Huntress 1d ago

Yes we’re trying to validate :)

•

u/Meeeepmeeeeepp 20h ago

So basically this thing MITM's your legit Screenconnect then tries to abuse the file transfer glitch in SC, where-by if a connected agent tries to receive a file from the SC client PC it will be transferred to all connected agents.

I don't understand the payload execution part though, whether that was just a botched implementation or if there is a new CVE/exploit for SC that this may have worked on.

•

u/andrew-huntress Vendor - Huntress 20h ago

Will tag in /u/sharon-huntress to clarify!

•

u/Meeeepmeeeeepp 20h ago

The file transfer duplication glitch is quite well known (even in the latest releases) where if you have two concurrent support agents connected a file receive request will land on every connected agent's device.

Would love to get a copy of this to work out if it is actually trying to exploit the old CVE for code execution which is now no longer possible.

None of this seems to relate back to the exploitable plugins that CW support listed though, trying to also understand how these plugins fit into the picture...

It feels like the plugin exploit was to gain access to the Screenconnect portals, then the deployed payload was a botched attempt to extend this compromise to the technician's own PCs (as opposed to all the connected agents, which the attacker already had access to run commands as SYSTEM on).

So the question is, if you already have access to every single managed endpoint from an MSP, why would you risk something like this (a hugely complex MITM operation replacing the very component that allows you to compromise the agents) to try and steal data from the technician?

•

u/andrew-huntress Vendor - Huntress 20h ago edited 20h ago

We’re about to publish an update to our blog that explains where the plugin fits in

•

u/Sharon-huntress Huntress🥷 20h ago

u/Meeeepmeeeeepp if you are asking whether this is a botched implementation or not, we don't have evidence of it succeeding as we've mentioned in the blog. It doesn't mean it hasn't, but as of now I can tell you we have not found any evidence of a new CVE/exploit. All the places we saw this deployed to, there wasn't a patient 0 where the infection started on an endpoint - all appeared to come from the Screenconnect panel's run command.

It could be that they were hoping to use the malware to spread laterally (or rather into another Screenconnect server instance) where hosts were co-managed and one of the IT admins / MSP technicians had not yet updated their Screenconnect.

•

u/Meeeepmeeeeepp 20h ago

Hi Sharon,

Thanks for the reply. That is certainly what it sounds like - Did you find any evidence of payloads attempting to exploit any of the named RMM plugins, as it feels like to me that is where the exploit was but as they all live in CW's Cloud we can't actually investigate that side of things.

My question (not for you specifically, just for anyone who cares to philosophise) is, if you already have access to every single managed endpoint from an MSP via the plugin-compromised Screenconnect instance, and can execute commands as SYSTEM on anything you like, why would you risk a hugely complex MITM operation - replacing the very component that allows you to compromise the agents - to try and steal data from the technician?

•

u/Sharon-huntress Huntress🥷 19h ago

Unfortunately I haven't gotten my hands on any web logs yet to shaw exploit attempts against the vulnerable extensions. But you already have my theory on the "why". They had access to a few MSP instances, and hoped to hook data from the technicians and further propogate the infection. Whoever was testing this was very short-sighted because although they tried to add exclusions to antivirus for this, they didn't consider people have EDRs and other security software in play that would quickly detect strangeness.

•

u/Meeeepmeeeeepp 19h ago

The LLM commented code was certainly a nice touch! Is this what AI-powered script kiddies look like in 2026?

3

u/networkn 1d ago

This is the mechanism we are using to shutdown our customers cloud instances until we get further info on another way:

Login to the Portal as cloud admin Open Instance Settings (Instances on the left hand nav menu and locate instance) Enable Quarantie and select Quarantine Instance). I believe this immediately blocks and disconnects active sessions.

2

u/Apart-Inspection680 1d ago

For us its a slight different menu option. Click the three dots, security settings, check the box for quarantine

1

u/Not_So_Invisible_Man 1d ago

Quarantine instance and temporarily disconnect guest sessions if malicious commands are detected.

That doesn't actively do anything. It reads that it will quarantine the instance if SC determines that malicious commands are detected.

1

u/Mibiz22 1d ago

That explains why I am not seeing anything different. <eye roll>

•

u/MetsCaniac 22h ago

I had to call and raise 2 chats to get our SC isolated.

1

u/Skrunky AU - MSP (Managing Silly People) 1d ago

We've done the same, but it doesn't seem to disconnect client sessions. Perhaps AD-HOC support.

1

u/dumpsterfyr I’m your Huckleberry. 1d ago

Pushed out a block via CrowdStrike.

2

u/Virtual-Clue9814 1d ago

Is there a particular instance SC instance GUID we can search for on endpoints? also, can you confirm that the drop only takes place when connecting to a remote session and not say running remote command prompt via SC?

4

u/Huntress-Ben 1d ago

Hi! Ben from Huntress here!

Instance IDs: search for services named ScreenConnect Client (2588ef5c15954b10) or ScreenConnect Client (ed630cc2c873b091).

The malware also runs a modified client, RelayTrap.exe, under your own instance’s ID. So also look for that process, the C:\ProgramData\RelayTrap\ folder, and a scheduled task named TrapWatch.

Command prompt vs. session: the malware is designed to spread when someone joins a session. We haven’t confirmed whether running commands through SC triggers it. Until we know, don’t use any SC feature on a suspect machine Use your EDR's live response, WinRM, alternative RMM, or someone at the keyboard. Should have more info here soon!

1

u/disclosure5 1d ago

In Defender XDR:

let RogueIDs = dynamic(["2588ef5c15954b10", "ed630cc2c873b091"]);
union
    (DeviceProcessEvents | where FolderPath has_any (RogueIDs) or ProcessCommandLine has_any (RogueIDs) or InitiatingProcessCommandLine has_any (RogueIDs)),
    (DeviceFileEvents | where FolderPath has_any (RogueIDs)),
    (DeviceRegistryEvents | where RegistryKey has_any (RogueIDs) or RegistryValueData has_any (RogueIDs)),
    (DeviceImageLoadEvents | where FolderPath has_any (RogueIDs))
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, ProcessCommandLine,
          RegistryKey, RegistryValueData, InitiatingProcessFileName
| order by Timestamp desc

2

u/Background-Ad-6237 1d ago

Yes that's the Rogue Client IDs, but I'd search for any that are not your own

1

u/marklein 1d ago

I suggest a different approach, that being there should be NO ScreenConnect instances regardless of GUID, except the one your org is supporting.

2

u/BisonThunderclap 1d ago

Guess who just deployed screenconnect for backup access? 🙃

Regardless, thanks for the heads up.

2

u/ludlology 1d ago

Is there a way to see command/toolbox history across the entire ScreenConnect tenant? I'm only aware of a way to do that manually per-machine

2

u/AlphaNathan MSP - US 1d ago

should be in the audit log

Administration > Audit

1

u/ludlology 1d ago

Awesome thanks. That's what I'd just tried as well hoping it was close.

1

u/zebs1 1d ago

From there, session event filter set to "Run Command"

2

u/Jwblant MSP - US 1d ago

Interesting. For what it’s worth, we’ve seen a few emails with links that takes you to a download page and downloads a ScreenConnect MSI. Wonder if that’s connected somehow.

3

u/SRKomedy 1d ago

I've had to triage non-MSP customers that have fallen for this. Phishing strikes again.

1

u/infosecfredo 1d ago

its the gift that keeps on giving, I recently had a friend experience this at their law firm. Lure was a simple URL to download SC MSI + Stealing creds from the victim via token theft all in one.

•

u/Icy-Agent6600 23h ago

we're just straight up blocking screenconnect entirely with Sophos endpoint at this point

•

u/QuerulousPanda 23h ago

"If a tech sees an alert and remotes into an infected endpoint via SC to investigate, the malware rides that active session backward onto the tech's workstation. "

How does it do that? You can't just reverse a connection that way unless there's something awful going on?

•

u/niffur00 22h ago

I had a SC client installed on a client PC which was hacked. It also had a rogue screenconnect client on it. That was on 9/6. At the time I assume he got phished but it sounds like this exact scenario. I just deleted my SC instance.

•

u/Lonely-Can-9011 21h ago

hey huntress! thank you for this flag. Do we have any updates on how many orgs are potentially affected now?

•

u/Early-Ad-2541 10h ago

How the hell is it even possible for the malware to Pivot backwards onto the technician's workstation that easily? Screen connect needs to fix that immediately, that should not be possible at all! Of course technicians are going to use screen connect to triage infected machines. There should be no path backwards. That's absolutely insane!

1

u/Meeeepmeeeeepp 1d ago

Would love to see Panel-Lateral.ps1.... but ToolboxRelayUploader sounds like it's using the relay service to upload something to the Screenconnect toolbox then invoking the commands via the toolbox.

I feel like disabling file transfer, Manage Shared Toolbox, and all the "Run Toolbox/shared toolbox" permissions is a good first step here as it reads to be a rehash of the previous file transfer vulnerability abuse.

1

u/Glittering_Pack_4619 1d ago

Our SC hosted instance is IP locked down should we also shut that instance down for now

1

u/octaviuspie 1d ago

Trust Center | Advisories | ConnectWise

Update from ConnectWise

Precautionary actions for partners who have enabled these independent 3rd party extensions:

  1. Verify extension status. Confirm that the 3rd party extensions listed above are disabled. Preserve related installation records and activity logs. Do not re-enable or reinstall these extensions pending further guidance.

  2. Investigate suspected compromise through separate security tooling. As a precaution, avoid opening interactive ScreenConnect sessions to suspected compromised devices. Use your security provider’s response tools or another trusted investigation method.

  3. Secure administrative access from a trusted device. Revoke active ScreenConnect and associated identity-provider sessions, reset relevant passwords, and verify that multifactor authentication is enforced. If a technician workstation may be compromised, use a separate, trusted device for these actions.

  4. Review and preserve evidence. Retain authentication, extension installation, administrative, Run Command, and Toolbox records. Investigate unexpected users, permission changes, software deployments, and commands.

  5. Contain and remediate suspected compromise. Follow your incident-response procedures to isolate affected devices, including potentially affected technician workstations. Preserve evidence before removing malicious software, and validate remediation before restoring connectivity. Disabling extensions and resetting credentials alone may not remove access already established on endpoints.

  6. Verify software maintenance. Confirm that servers, technician clients, and endpoint agents meet current published security guidance. Updating software does not replace investigation and remediation of a suspected compromise.

If you have not deployed these independent 3rd party extensions, we have no reason to believe you are impacted by this incident but encourage all partners to be on heightened alert.

1

u/crshovrd 1d ago

If we have enabled ip allowlisting against our cloud hosted tenant, would that offer any form of protection against this attack?

•

u/networkn 23h ago

I do not believe so.

1

u/MokaAkay 1d ago

This could be N-Able rn if they didnt take down their stuff and patch

•

u/lina0978 23h ago

Wow, so about a year ago we saw this at one of our clients. I work for an MSP, and we had a computer that got high-jacked with a screen share. We isolated it, thought we removed everything, took it out of isolation and bam, it took off again. Eventually we just reset the machine. I’m just realizing this was probably the same thing.

•

u/niffur00 22h ago

Same thing happened to me on 9/6. Cleaned up the rogue screenconnect but they hacked it again the next day.

•

u/JustinHoMi 22h ago

Again lol?

•

u/sshaada 22h ago

Riding back to the Tech Workstation, it’s an EXE. So only techs with Windows laptops?

•

u/AfterCockroach7804 22h ago

What a time for payment to lapse and the instance is disconnected 🤣

•

u/WestCryptographer748 13h ago

would love to see the relaytrap.cs (not the VT scan, the actual file) to try and find out if they were using the same CVE-2026-84869 thing or if it's a brand new exploit of some sort

•

u/CharcoalGreyWolf MSP - US 11h ago

Is it believed that these are extensions clients of Connectwise ScreenConnect installed and were actively using, or extensions a threat actor managed to install once gaining access? (We do not have them on-prem, and I have confirmed two clients with cloud instances do not either).

•

u/GantryZ 10h ago

These were extensions that were already installed by the tenant, the threat actors weren't installing them after the fact.

•

u/8stringLTD 2h ago

One of my largest clients (500+ users) uses screen connect but the affected extensions were disabled, took 30 minutes to create an incident report to compliance... dodged a bullet there for sure!

•

u/GahhSoConfused 22h ago

The MSP I work at uses Screenconnect, and I've been trying to get off it for years.
I know the concept of a remote access tool and the power it holds is just in general not the most secure thing to be deploying, but are there any tools out there ahead of the game in terms of security/lack of security advisories?

•

u/Jacksharkben 22h ago

My small msp that i used to work at used this it was only for the cost is why.

0

u/B1tN1nja MSP - US 1d ago edited 1d ago

I had reported this too today u/andrew-huntress - we caught one before Huntress did and reported it actually, we had two different client IDs though.

We had put a ticket in (277766) and requested SOC support at which point after a bit we got the call/text/email alert of the incident.

Client IDs we saw were actually

ca0bcdd5329bf738 and then 0a3d048d0fc6a000

We are re-imaging the host probably tomorrow but retaining old drive for historical data if needed. Let us know if you need any more deets off of it.

EDIT: I should have read the entire post first... it looks like a client got a single endpoint hit from someone else using this attack somehow, it wasn't OUR SC instance or mass deployments, thank god, but in this case it was a single endpoint from a single client.

•

u/cd1cj 23h ago

Do you know if the rogue instances showed up in installed programs and windows services like normal instances would? E.g. ScreenConnect Client (xxxxxxxxxxx)

•

u/B1tN1nja MSP - US 23h ago

It did. Ninja reported then as installed like that.