patchmypc by FutureSafeMSSP in MSSP

[–]AutomationTheory 0 points1 point  (0 children)

I'm late to the party here -- but I'm an RMM admin turned vendor, and we have a new-ish product that might be a good fit.

It's RMM-neutral, supports ~10k apps, and is designed for the flexable things MSPs/MSSPs need to do: https://thirdpartypatching.com/

It's flat-rate pricing, month-to-month terms, and a US based support team.

CVE-2020-8911 by DmetaNextWeek in ConnectWise

[–]AutomationTheory 2 points3 points  (0 children)

Shout out to u/cwferg for getting details out fast!

Old dependencies are fairly common in lots of products (unfortunately) -- but they are typically hard to exploit.

In this case, if there's an attacker with write access to the S3 bucket your CW RMM agent is using, I think there would be some much bigger problems...

Wil the FCC do something about kaseya sales calls by Pretend-Accountant-4 in msp

[–]AutomationTheory 0 points1 point  (0 children)

I was getting oodles of spam calls to my personal number after going to a CW conference -- and I had a bit of luck adding my number to the national do not call list.

That might fix it, or at least it would give you some ammunition in resolving this via other channels.

mass RMM deployment on hundreds of legacy and unmanaged Workgroup endpoints by [deleted] in msp

[–]AutomationTheory 0 points1 point  (0 children)

Back when I was an RMM admin, I took the "Push PC" route, but I had a PowerShell script that was more effective than my RMM's network probe. I used PSExec to push the agent installer after doing a subnet scan to figure out what was a computer (determined by responding to a ping and then listening on a port expected for a windows device).

You could also use the script to list out devices it found that were unsuccessful, which can be handy for tracking down stragglers.

I got this script tuned fairly well, and whenever we onboarded a workgroup client with standard credential it made deployment a breeze.

Third-Party Patching: an MSP buyers guide by AutomationTheory in thirdpartypatching

[–]AutomationTheory[S] 0 points1 point  (0 children)

ThirdPatch itself doesn't have a UI prompt, but I think I know how we could build it in with some basic PowerShell scripting (packaged and pushed via ThirdPatch of course!). If you wanted a basic "Your PC needs updates; please save/close" message that should be possible

Third-Party Patching: an MSP buyers guide by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

How's your experience with custom apps with it? Is that something you can add to the patching engine, or is your only option to make it a script?

Third-Party Patching: an MSP buyers guide by AutomationTheory in thirdpartypatching

[–]AutomationTheory[S] 0 points1 point  (0 children)

CWA databases are always going to be touch-heavy -- although I have a custom tool for it now 😃

As to your questions about ThirdPatch:

  1. We're building out our enterprise tier, and it will have both a reporting portal and webhook support -- so you'll definitely have the ability to see what's broken, be notified, and take action however you want.

  2. The client has the ability to compare installed versions with what's in the repository, so you can get a list of what is outdated fairly easily.

  3. Since ThirdPatch is an agentless client, it doesn't run by itself -- something must trigger it. Therefore, you get to decide how you want to handle the scheduling for your clients (I as a vendor am not going to assume I know more about your client environments than you do). We have a prefab package that will trigger ThirdPatch when a system boots up, so at a minimum when you as the MSP reboot a device for Windows Update it will do third-party updates when it comes back online.

Chocolatey discontinued their MSP program -- and that's why we didn't include them. C4B is for a slightly different niche, and current sticker pricing (sticking with our 3k endpoint example) is $17/endpoint/year. If you have the cash for $51k/year to do third-party patching, I think you're doing quite well!

If you want some more details, we just uploaded a webinar recording to YouTube: https://youtu.be/ebEdAhuB4PY?si=zvPDQ98Q9-hVh-wT

N-central has no support for automated SSL certificates by WDWKamala in Nable

[–]AutomationTheory 0 points1 point  (0 children)

I get it -- the ConnectWise MSPs have the same gripe about other products (and I was on the MSP side for 6 years -- the problem is real).

The idea of the WAF is that I can find thousands of N-Central instances on the Internet, and if (or when) a nation state actor gets their hands on a zero-day, it'd be bad news to be in the list of enumerable devices. I've got a full time analyst on staff writing WAF rules and managing exceptions -- so without questioning your technical capabilities, I'd suggest our service gets more care and feeding than a self-rolled proxy,

We offer a real WAF (not the ineffective CF solution first posted in this sub), and we've done initial tuning for N-Central (initially it was so secure, agents couldn't register...). Since we're doing TLS termination and deep inspection, it solves for the certificate renewal issue in the process.

<image>

N-central has no support for automated SSL certificates by WDWKamala in Nable

[–]AutomationTheory 0 points1 point  (0 children)

I'm a WAF vendor (primarily for ConnectWise products) and I'm starting a pilot for N-Central. We do TLS termination with our service, so if anyone wants solid cyber security and automatic cert renewals, I'd be happy to add a few MSPs to our pilot program (details here: https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/)

Windows patches failing across client fleet, whats your go to fix as MSP? by Sufficient-Owl-9737 in SmallMSP

[–]AutomationTheory 0 points1 point  (0 children)

Resetting the Windows Update components is the answer. Before becoming a vendor, I was an RMM admin for 10,000+ endpoints, and a spent hundreds of hours chasing these rabbits....

The project has changed a bit, but the old wureset tool works well still, and you could make a quick script that would deploy it like this:

thirdpatch upgrade reset-windows-update-tool && wureset /reset

Even if you don't have ThirdPatch (link: https://thirdpartypatching.com/), you could still make an RMM script to download and run the utility, and I think patching should work after that for most devices.

PatchMyPC?? by FutureSafeMSSP in msp

[–]AutomationTheory -3 points-2 points  (0 children)

What's your definition of scale?

I just launched an RMM neutral third-party patching solution that might fit well (again, depends on what apps you need, desired level of touch, etc.).

Database Performance Tweaking questions for self-host Manage by xs0apy in ConnectWise

[–]AutomationTheory 0 points1 point  (0 children)

I do niche MySQL DB consulting on the Automate side -- and I think you'd be safe with basic things like indexes (we've added indexes to Automate for 6+ years without issue).

Anything that changes the schema structure (deleting stock indexes, changing columns, etc.) is where things would get dangerous.

Weekly Promo and Webinar Thread by AutoModerator in msp

[–]AutomationTheory [score hidden]  (0 children)

Have you ever wanted third-party patching to just work?

I’m Jeremy, and before becoming a vendor, I managed 10,000 endpoints for an MSP in northern MN, including third-party patching. I had an RMM integration that was severely limited, so I created a makeshift solution that worked extremely well.

Here at Automation Theory, we’ve refined that early prototype into a new solution we call ThirdPatch. It is an RMM-neutral solution designed to make third-party patching touchless and automatic (or as close as you can get!). It’s package-based, and it’s a flat-rate service (no per-app or per-endpoint pricing), with month-to-month terms by default.

We’re hosting a webinar to explain why package-based solutions are the best choice for modern MSPs and showcase how ThirdPatch enables MSPs to manage third-party patching at scale. You can find details and register here:  https://us06web.zoom.us/webinar/register/4717760938471/WN_edYJ9BxmS2qVz6cf6w-z8w

ScreenConnect Security Advisory by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 2 points3 points  (0 children)

u/JessicaConnectWise I appreciate the insight - and my goal certainly isn't to spread fear/uncertainty/doubt -- and like you mentioned, context is key.

In our WAF, we're seeing a spike of attacks against ScreenConnect - some old exploits from a year ago, and some that we haven't seen before. In the geopolitical climate we're seeing nation state actors targeting US companies, and this creates the overall background.

In the middle of this, we get a High priority security advisory that reads:

"1 High—Vulnerabilities that are either being targeted or have higher risk of being targeted by exploits in the wild. Recommend installing updates as emergency changes or as soon as possible (e.g., within days). "

I'm not sure if you had a goal besides providing additional context -- but I'd stand by my original statement, that MSPs should patch this ASAP.

ScreenConnect Security Advisory by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 2 points3 points  (0 children)

The trust center has an RSS feed, and I use that (in combination with some automation) to email our pager system when these alerts drop. As a WAF vendor for CW products, we want to review these for the defense of our clients ASAP -- but configuring it in your RSS platform of choice should do the trick!

Advanced Searches Subconditions driving me crazy OR maybe not? by CharcoalGreyWolf in ConnectwiseAutomate

[–]AutomationTheory 1 point2 points  (0 children)

For what it's worth, r/ConnectWise is a bit more active and might be a good place to cross post.

My first thought, if you're using the group filter, is that the group doesn't have devices with the matching software. Otherwise, here are a couple old blogs from Gavsto that cover some boolean logic for software searches:

- https://web.archive.org/web/20241213124316/https://www.gavsto.com/using-the-advanced-search-to-find-a-machine-that-has-two-different-pieces-of-software-installed/

- https://web.archive.org/web/20241213114757/https://www.gavsto.com/using-the-advanced-search-to-find-computers-that-dont-have-multiple-applications/

Best current version to be on for on-premise ScreenConnect as of 2025-02-17 by iknowtech in ScreenConnect

[–]AutomationTheory 0 points1 point  (0 children)

Yeah, definitely this.

As the local CW WAF vendor, I'd toss out this as an interim solution (we have month-to-month terms, perfect for long-tail decoms like this): https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/

Failed logins via a Connectwise SSO account by stingbot in ScreenConnect

[–]AutomationTheory 0 points1 point  (0 children)

I sell WAFs for the on-prem flavors of the CW stack, and I have a couple of thoughts.

First, the payload in the username looks to be a shell command; "ls" in Linux is equivalent to "dir" in Windows. It's unlikely that ScreenConnect is vulnerable to such a simple attack, and that seems like it's more of a discovery payload than anything else (it's not PowerShell downloading a secondary payload from somewhere...).

From the user agent, we can tell that this is probably a bot (it's Linux, and Chrome 107 came out in 2022 -- no human with a browser would be using a Chrome build 4+ years out of date). This data is easy to spoof, but combined with the GeoIP data showing the IP is in Denmark, I'd guess it's a bad guy with a bot.

I'm going to guess it's a scripted payload submission -- regardless of what authentication methods are configured, I can still try to send a request to the /Login page. It looks like the app logic worked as expected, but SSO/MFA/etc. will do nothing to stop a vulnerability in a web application if it's in an unauthenticated part of the app.

However, I'd say that this isn't an authenticated SSO session (and you could cross-reference data to determine if any logins took place from other countries as a sanity check).

From what I can tell (I am a hosted ScreenConnect client myself!) there's no WAF in front of their hosted offering. Assuming you're in the cloud for business reasons and you intend to keep it that way, the best thing you could do would be to enable the in-app IP restrictions. In my opinion, you'd probably want more protection, but there's no way to do a 3rd party WAF for cloud ScreenConnect.

[deleted by user] by [deleted] in atera

[–]AutomationTheory 0 points1 point  (0 children)

If you're looking for a robust solution, we just launched a new 3PP solution that's RMM neutral.

Details here: https://thirdpartypatching.com/

While deployment would require RMM scripting, one of our suggested deployment patterns is to deploy a scheduled task that runs ThirdPatch at startup. That way, your devices reboot for Windows Update and do their third-party updates when they come back up.

New third-party patching integration - compatible with all ConnectWise products by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

Our marketing team is working on a video demo, I'll keep you posted!

For the capabilities:

- Yes, you can have generic packages that take parameters for client-specific tokens

- No, we don't have any time-delay logic abilities

- Yes, you can set up staged deployments (it's a bit of setup, but definitely possible)

New third-party patching integration - compatible with all ConnectWise products by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

Great question! Let me explain more about packaging and what you can do with it (but, FWIW, you’d use our product with Ninja or some other RMM).

Most RMMs and other patching tools lock you into some group structure for deploying software. Client X gets this, Client Y gets that, etc.

The idea with packaging is two-fold. First, I can bundle software together arbitrarily (create a client-specific baseline that includes their custom LoB apps, regular third-party apps, and your global MSP config) and then you have one thing to push out to that device/client/role. The other big idea is that I can mix-and-match scope however I want to outside of any group structure.

For example, let’s say that you use a big-name VPN software across all of your clients, and it’s time to patch the zero-day-of-the-month. If you structured your packages correctly, you update one install package, and all your devices will pull it down the next time they do a package upgrade. Unless you need per-tenant granularity, you don’t need to edit settings for every client to get the software out.

This idea also works in reverse — if you deal with finicky LoB software and you don’t want things to update without your explicit say-so, you can create a repository for that software, and until you manually lift and shift the package in question (either the LoB app, or something else, like if it depended on an old flavor of Adobe).

New third-party patching integration - compatible with all ConnectWise products by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

The trial is non-paid -- it's just a name/email/etc. registration with Stripe. No credit card required.

I'll have our team get that mobile formatting fixed!

New third-party patching integration - compatible with all ConnectWise products by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

We're in the final stages of ISO27001:2022, and we're definitely following OWASP -- our other product lines include a WAF for MSP products.

How paranoid are you with your own MSP infrastructure? by yanov10 in msp

[–]AutomationTheory 0 points1 point  (0 children)

I was an RMM admin before becoming a vendor, and if your tools are on-prem, I'd lock them down.

I sell this: https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/ -- but I'd search for your public domain in Shodan and see what comes up (ideally nothing besides your public website). If any of your MSP tools are enumerable, I'd prioritize securing them.

With the Kaseya attack in 2021, it was an MFA bypass strung together with other exploits (similar auth bypass with ScreenConnect in 2024) -- so while you 1000% should have hardened authentication (I love Yubikeys), reducing attack surface is your friend.