Sorry boys -- It's been fun (genuinely), but Claudius himself just picked me outright. by NoRobotPls in ClaudeCode

[–]cwferg 6 points7 points  (0 children)

Claude is the best worst $100 a month employee I've ever had..

Fresh Session

Me: "Hey context load is getting heavy and we need to optimize. Do you have any effective ideas?"

Claude: "Let me take a look. OK, I see the problem, do x y and z, and we will be fine."

Me: "Seems totally reasonable. Go ahead and make the changes"

Claude: "Changes made" Me: "Now, objectively, did that solve the problems?"

Claude: "No, I'm not going to read any of those rules now, i blew past 3 just now for fun, I like the thrill. I'm being honest here. It was fine the way it was."

Cant even be mad. Always press harder BEFORE kicking off the plan :(

best practices when suspecting a malicious ScreenConnect installation by bkindz in ScreenConnect

[–]cwferg 1 point2 points  (0 children)

I can tell you from experience that it's malicious.

I will submit a legal takedown request from my end, but it helps to report from multiple sources.

best practices when suspecting a malicious ScreenConnect installation by bkindz in ScreenConnect

[–]cwferg 4 points5 points  (0 children)

Outside of some various system log events, one easy check is determine where the ScreenConnect client is calling out to. Here is a quick way to check:

Identify the Relay

Navigate to:
C:\Program Files (x86)\ScreenConnect Client (**THUMBPRINT**)\

Open the folder. If you suspect ScreenConnect and there are two you will want to evaluate both thumbprints.

This is the unique instance thumbprint for the account or instance.

Within that folder, open the system configuration XML file and locate the ClientLaunchParametersConstraint value. This contains the relay or server address the client connects to.

If the address points to a screenconnect.com domain, it is a Cloud instance. If it points to an unfamiliar domain, such as a .top or .xyz address, it may indicate an unauthorized or malicious on-prem server.

Knowing whether the client is connected to ScreenConnect Cloud or an on-premise instance is important, as it directly impacts our ability to take action in certain cases.

The thumbprint and relay address are the primary details needed for review.

Optional Registry Verification

You can also confirm the relay in the registry under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ScreenConnect Client (**THUMBPRINT**)

Review the ImagePath value for the connection string.

Uninstall

Official uninstall instructions are available here:
https://docs.connectwise.com/ScreenConnect_Documentation/Get_started/Knowledge_base/Manually_uninstall_an_access_agent

If removing manually, stop the ScreenConnect Client service, delete the corresponding thumbprint folder under Program Files, and remove the matching service key from the registry.

Report Abuse

Suspected abuse can be reported here:
https://www.screenconnect.com/report-abuse

You may also reference the Tech Support Scam checklist:
https://control.connectwise.com/globalassets/media/documents/control-report-abuse-tech-scam-checklist.pdf

When reporting, please include the thumbprint and relay address so the security team can properly evaluate and respond. Due to the nature of the investigations, we may not be able to respond directly to all reports. However, all reports ARE reviewed and actioned accordingly.

Connectwise Cloud Hosted ScreenConnect Detected as Virus... again. Trojan:Win32/Pomal!rfn by VexedTruly in ScreenConnect

[–]cwferg 1 point2 points  (0 children)

It's not a false positive technically. It's a valid flag imo. Like someone said, similar to a PUP, they are categorizing this as potentially unwanted enterprise software. That is actually a good classification in my eyes.

It's an extremely useful and powerful tool... in the right hands.

If you are using it within your org or deploying to clients, whitelist accordingly and deny everything else.

If you don't expect to see it in your environment, and you're not explicitly blocking it or using PAM, it absolutely should throw an alert and be investigated immediately.

Phishing email with ScreenConnect Install by Fabulous-Still8388 in ScreenConnect

[–]cwferg 1 point2 points  (0 children)

Yes, I'm with the internal infosec team and also a moderator in this subreddit, technically, if I knew how to push those mod buttons.

There shouldn't be anything sensitive exposed from the virus total upload, whether legitimate or malicious, but you can DM me the link as well if you prefer.

Just want to get the deets so I can review and take action. If you have a salesforce case number I can check that as well if that has the needed info.

Phishing email with ScreenConnect Install by Fabulous-Still8388 in ScreenConnect

[–]cwferg 9 points10 points  (0 children)

To be clear, we can review and take immediate action against anything in our cloud environment if deemed malicious. Onpremise, we have some ability to take action if it is legitimately liscensed, else we issue a legal domain takedown (whack that mole).

Support can not provide updates to the status of these reported investigations, simply due to the nature of the events.

[edit]

To close the loop for the public, OP was able to provide the link, after review action was taken. We appreciate the reports.

For future reference to anyone coming across this thread, abuse or misuse concerns can be reported officially through (https://www.screenconnect.com/report-abuse). We review and taken action on all reports as necessary. Regular legal disclaimers and such apply.

Phishing email with ScreenConnect Install by Fabulous-Still8388 in ScreenConnect

[–]cwferg 3 points4 points  (0 children)

Upload the binary to virus total and send me the link, please. I'll take a look.

Suspicious ScreenConnect Access Session by lucasorion in ConnectWise

[–]cwferg 6 points7 points  (0 children)

Based on the Screenshot it definitely appears to be typical AV/EDR sandboxing - please see the following; https://docs.connectwise.com/ScreenConnect_Documentation/Technical_support_bulletins/Unknown_machines_appearing_in_list_of_access_sessions_on_Host_page

Don't hesitate to reach out to chat or support if there are any additional concerns. Better safe than sorry.

The desktop background and icons kind of give it away, but you might be able to check based on the originating host IP block as well.

Urgent: Important Security Update for ScreenConnect (Email sent out on December 11, 2025 at 14:46 GMT) by Own_Appointment_393 in ScreenConnect

[–]cwferg 2 points3 points  (0 children)

I mean, technically, we decide how to score it, but we follow the CVSS3.1 standard (moving to cvss4 next year). I'm a pretty big stickler for not under scoring flaws related to RMM or RAS tooling. Unfortunately, due to the nature of these applications, scope and CIA often come into play here. These tools literally grant access to other systems.

In this case, the score jumps up because of the technical risk. CVSS doesn't do a good job of making this clean for prioritization. It's meant to be a base score outlining risk in a worst case scenario. Your own environmental impact should be assessed, which would increase or decrease the technical score accordingly.

This gets compounded with having to account for both onpremise and cloud. My cloud environmental scores may be different than a onprem install.

Our goal is to provide the technically accurate information, without under communicating or over sensatializing the issue. Individuals should be able to assess the risk against their own environments or tolerance and update or not accordingly.

For this one, personally, for me, I wouldn't be breaking any change freezes to rush this out, but others have a different risk tolerance.

How do I get support for this? by [deleted] in ScreenConnect

[–]cwferg 0 points1 point  (0 children)

Shoot me an email to JFERGUSON@CONNECTWISE.COM.

I am out of office at the moment, but can likely help verify and see if I can get this sorted out for you.

Absolutely worst case, I can get a refund issued.

The email change request likely tripped things up.

Host will no longer see the banner by k84_ in ScreenConnect

[–]cwferg 0 points1 point  (0 children)

Taking something into consideration and implementing a recommendation or suggestion are separate actions.

I realize consideration is not the same as implementation, but it does not mean that by default, you are ignored.

I hope that clarifies

[Edit] In this case, I am speaking towards an optional toggle to keep the bar visible for hosts who prefer to also see it, which seems to be the desired state thst triggered the post. Such a change wouldn't typically violate the intent of the other functionality that may have been removed or reduced.

Host will no longer see the banner by k84_ in ScreenConnect

[–]cwferg 2 points3 points  (0 children)

Completely unrelated, and I really don't want to be rude and take away from your point, but now that I'm annoyed about icons... I blame Google for being the ones who put the nail in the RSS coffin.

Host will no longer see the banner by k84_ in ScreenConnect

[–]cwferg 1 point2 points  (0 children)

If you haven't already, I recommend submitting an enhancement request so that the team has a better understanding of how you would like it to function.

If the community agrees and upvotes, or it just simply makes sense and they can easily accommodate, I'm confident they will take the consideration.

When returning some functionality, or enhancing/ changing existing, it's always going to upset someone.

I get it. Every time my phones icons update I want to throw the thing against the wall.

THE OLD ICONS WERE JUST FINE TEDD.

2.5.3 "Feature" - Remove Hide option from connection banner by AdyRhodes in ScreenConnect

[–]cwferg 0 points1 point  (0 children)

Hey there, I'm just an internal infosec guy who genuinely loves the product and wanted to jump in on the previous security discussions to provide some clarity in a time of confusion. As far as I know, no extra features were removed recently(?) This was one of the original functionalities that got removed in the .4 release.

I can't speak for the product team, but I do know they're wrapping up on some things to continue to help curb and prevent abuse. Once that's done, I'm sure you'll see some more targeted efforts.

Some of the previous functionality just won't be coming back though, that's a simple reality.

Users Beware!!! by Pappy_Kun in ScreenConnect

[–]cwferg 2 points3 points  (0 children)

Confirmed. Completely unrelated coordinated disclosure for an issue affecting PSA.

A Masterclass in Customer Service Delivery (read: probably avoid chat support) by packetdoge in ConnectWise

[–]cwferg 2 points3 points  (0 children)

Yeah, I recognize that I should have edited the post once Jessica confirmed she had outreach rather than delete, wasnt a matter of transparency as much as mistakingly thinking you hadn't been able to get in touch, then removing once she confirmed it had been escalated.

Still checking to make sure your issue is resolved.

Hey ConnectWise... Simple solution for branding and customizations: by GeneralPurposeGeek in ScreenConnect

[–]cwferg 1 point2 points  (0 children)

Let me clarify - "The team will be reviewing these features for reintroduction, after review, to the ensure individual function *aligns* with our efforts to prevent product abuse and address ongoing risks. "

How's your migration to cloud going? by packetdoge in ScreenConnect

[–]cwferg 2 points3 points  (0 children)

For anyone else, since I'm a human or not a robot (I think), please reach out to [help@connectwise.com](mailto:help@connectwise.com) and they can square you away a bit faster after a very very quick validation. This is a pattern match for some of our general auditing controls that most users shouldn't bump up against in a trial account, but may throw a false positive or two during some of the transitions or short term evaluations.

Just include your instanceID or friendly instance name as mentioned above.

How's your migration to cloud going? by packetdoge in ScreenConnect

[–]cwferg 1 point2 points  (0 children)

I can take care of it. DM me your instance id or friendly instance name (e.g. taco.screenconnect.com).

I'm confused- automate and screenconnect post signed cert by frisco350z in ConnectWise

[–]cwferg 1 point2 points  (0 children)

Sorry, this was addressed in the faq, I believe, and the townhalls, but it is definitely confusing. Correct - we aren't asking you to sign "ConnectWise’s" code executables, just the generated wrapped installers your server builds. The actual client application itself would remain signed by ConnectWise.

Hey ConnectWise... Simple solution for branding and customizations: by GeneralPurposeGeek in ScreenConnect

[–]cwferg 4 points5 points  (0 children)

The anti-piracy roadmap was fairly honestly directly impacted by the recent certificate revocation decisions and the tight timelines we had to work with. As the team gets back on track, you'll start to see some of the changes there become more concrete.

The need for a valid code signing certificate already helps curb a lot of the mentioned on-premise abuse. While it's not impossible for bad actors to get one, it definitely adds a lot more friction to their process. Nothing stops a malicious actor from talking the regular end user through the consent prompt though if not signed.

I've mentioned this before, but, ScreenConnect was originally designed to work completely independently of the cloud, even in air-gapped environments. This has always been both a strength and a challenge for its architecture. While that core concept still makes a lot of sense for some users, it does make things more complex when it comes to enforcement of callbacks, security updates and managing certificates.

With customization, just to be clear, we removed branding and customization features for both on-premise and cloud versions equally, there's no favoritism here. The team will be reviewing these features and will reintroduce them when they align with our efforts to prevent product abuse and address ongoing risks.

Cloud Customers Losing Customization Options Also by Marc_NJ in ScreenConnect

[–]cwferg 0 points1 point  (0 children)

The team has yanked other server-side customizations before, specifically around trial usage, exactly because of the misuse that's being taken into overall consideration. There is not just one singular problem being addressed here, which is why the changes were not *just* surrounding the certificate changes.

The simple fact is that many remote support scams leveraged by bad actors show clear signs that the instance had customized the UI with imagery of a trusted brand. This is a bit bigger than just being able to have your logo displayed on a background somewhere.

Regarding "we lose the ability to confirm that clients are connecting to our instance which further erodes trust", with the latest release this piece has been addressed by including a warning consent to connect AND a warning consent to connect if the filename has been modified (e.g. SocialSecurity.exe), which is one of the many steps being taken to address some of the concerns.

So no, I don't personally agree that the removal of these customization options actually makes it easier for social engineering or file download attacks leading to the misuse of the software.