Kaseya Community

Customers of 3 MSPs Shutdown by Ransomware via Kaseya, need details so we can protect our assets

This question is answered

https://www.darkreading.com/attacks-breaches/customers-of-3-msps-hit-in-ransomware-attacks/d/d-id/1335025?_mc=NL_DR_EDT_DR_daily_20190621&cid=NL_DR_EDT_DR_daily_20190621&elq_mid=91613&elq_cid=28059128

Need to know what was exploited and how we can protect ourselves and our clients.

Verified Answer
  • according to that article this was because of comprimised logins at the MSPs.  This is why everyone should implement PAM software.

All Replies
  • Webroot and connect wise www.bleepingcomputer.com/.../sodinokibi-ransomware-spreads-wide-via-hacked-msps-sites-and-spam

  • according to that article this was because of comprimised logins at the MSPs.  This is why everyone should implement PAM software.

  • 2FA should be mandatory on every remote management client and limited to ONLY those that need access. 2FA should not come at a cost but unfortunately it does. This should just be standard security practice.
  • 2FA aside, since we all know that there's only one solution that works with Kaseya that would allow we as the MSP and our clients who have access to use it, would locking down the ability to create procedures have helped to prevent these attacks?

  • Until 2FA is either handled internally within VSA itself, or multiple authentication platforms can be supported, it's not a solution that works for us where we have our engineers using Microsoft 2FA and our clients need to be able to log into and use VSA too.

    So back to the original question, what can be done internally, to inhibit the abuse of procedures through external or internal sources?



    corrected spelling
    [edited by: PedroPolakoff3 at 1:26 PM (GMT -7) on Jun 21, 2019]
  • This is not just Kaseya but every RMM and PSA and add-on product used by MSPs. This exploit was ultimately the result of a compromised user account. Let me tell you what we've found in MSP environments and you tell me where the primary fault lies:

    Not enabling password complexity on your RMM and PSA applications. This includes allowing password re-use! So often the techs are running the roost and whine about this. Set PW expiration to 9999 and you might be OK. The default password length on some products is 2 characters! is that even a password? If your techs complain about the "inconvenience", offer them to find another job, because the "inconvenience" of a compromise caused by the MSP is often business ending. That's about as inconvenient as it gets.

    While we're talking about RMM/PSA security, why the <bleep> does everyone assign every internal user to the Master (or System) role and scope? Do you like to continually guess how your RMM is configured? Do you want a compromised tech account to be able to own your entire VSA? Role Based Access is possible and not particularly hard to implement. If you aren't sure where to start, there's a Tech Brief on this topic specific to VSA on the Downloads/Documents page of our website. And please, for heaven's sake, make sure that when you create a customer account that you remove the Master/System role/scope from their account!

    I've seen a local admin account password set to "paSSWOrd18365" (changed slightly to protect the guilty). Have we learned nothing about dictionary attacks? We're shouting about 2FA but aren't meeting the most basic criteria of endpoint security. So this may not compromise the MSP, but it can compromise one customer. What if it's your largest customer? Once one is down, how long before more fall?

    Everyone is quick to blame the vendor behind the tool that was used to perpetrate the attack, but nobody wants to admit how woefully inadequate their internal security methods and practices are. Monday's a new day - go review your security settings for RMM, PSA, and any other tool you use. Enable appropriate security, send out an email to your employees with the new requirements, then force a password change on every user account in every application. Don't wait.

    Security starts at home. You don't think twice about locking your front door when you go to work or locking your car when you go shopping, right? This is no different. Leverage what's available to you now.

    Sorry if it sounds harsh, but every time an MSP is compromised, it impacts everyone in this industry. It's time to start taking care of the fundamentals that we have control over.

    Glenn

  • Hear, hear, Glenn! We should make it difficult for the baddies to get at our customers and we have options, so let's use them and use them wisely...

  • if you dont use the live connect part of kaseya, have a look at Azure Active Directory's Application Proxy, you can then 2FA with microsoft azure and then it will proxy the pages to your local VSA, also means you dont need to open port 80 or 443

  • You can make it so your clients are whitelisted to not require 2FA to access the VSA. Admins should definitely have 2FA enabled. Authanvil works well with VSA.

  • But AuthAnvil requires a separate subscription. They should offer 2FA-via-AuthAnvil for Kaseya servers for free and only if you want to use AuthAnvil for other applications should be it extra $.

  • Trust me, I agree. The cost isn't too bad compared to the lost of a customer account though.

  • If the driving reason for not incorporating Two Factor Authentication is cost; I suggest to reach out to your account manager this week as we have been working with our clients to ensure they have protection to their VSA from an AuthAnvil perspective.

  • Oscar - our account manager gave it to us for a year - but no more.  I think AuthAnvil is a good addition if your customers don't have a 2FA solution and you can sell it to them.  But for just securing the VSA itself, it should either be built-in or should be easy/have docs to configure it for Azure or some other 3rd party MFA.

  • 2FA yes. Its better to pay Kaseya for authanvil rather paying to hacker once infected ..!!

  • do not bring a procedure on production VSA, until it is tested in test environment.