SolarWinds is only the latest system attack that results in a large scale compromise. Attackers target these systems because they have widespread and long-standing access.

Any system that has some level of admin rights across your environment is vulnerable.

THREAD follows

SolarWinds can monitor pretty much any system/device on typical networks &there is value to doing so.

Originally SolarWinds used SNMP ( https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol) to get system status. As more checks & status added, more capability was needed which means agent/remoting capability

This expanded capability and access results in the common situation customers get into due to vendor documentation which often reads as "one click install" (Domain Admin rights) or read this 50 page document on how to deploy with limited permissions.

Most service account passwords don't change & something like SolarWinds was probably installed years ago (a decade +). This often results in a weak password on a system that has rights to many systems.

SolarWinds typically has extensive rights, continue reading thread for detail

SolarWinds can monitor SQL. In order to do this the docs say it requires SYSADMIN role for "initial registration" and that this can be removed after capturing initial data.
https://support.solarwinds.com/SuccessCenter/s/article/SQL-Server-permissions-for-DPA-monitoring?language=en_US

My guess is this doesn't happen, so the SolarWinds service basically owns SQL.

Monitoring VMWare virtual machines should only require Read-Only permissions.
Are you confident this is how it was configured?

https://documentation.solarwinds.com/en/Success_Center/VMAN/Content/VMAN-Required-permissions-for-VMware-and-Hyper-V-credentials.htm

SolarWinds monitors the cloud (AWS) and requires rights to do so:

To define actions that can be performed against an instance, add the following permissions:

ec2:StartInstances
ec2:StopInstances
ec2:RebootInstances
ec2:TerminateInstances

https://documentation.solarwinds.com/en/Success_Center/orionplatform/Content/Core-Cloud-Configure-AWS.htm

SolarWinds monitors the cloud (Azure) and requires rights to do so:

Select Contributor or Reader in the Role field.

If Contributor is used, it "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC."

https://support.solarwinds.com/SuccessCenter/s/article/Configure-Azure-IAM-permissions-for-cloud-monitoring-in-the-Orion-Platform?language=en_US&r=125&ui-knowledge-components-aura-actions.KnowledgeArticleVersionCreateDraftFromOnlineAction.createDraftFromOnlineArticle=1

SolarWinds can monitor/manage network devices like routers and download/upload configurations
https://www.solarwinds.com/engineers-toolset/use-cases/config-editor-viewer

SolarWinds can monitor/manage Microsoft Office 365:

An Office 365 account with Global Administrator rights. Alternatively, ... an admin role that has adequate rights to subscriptions, management groups, monitored mailboxes, and Office 365 API access.

https://support.solarwinds.com/SuccessCenter/s/article/Microsoft-Office-365-template-requirements?language=en_US

SolarWinds can monitor Active Directory which means it needs rights on Domain Controllers.

Hint: WMI access = local admin rights on that system. On a Domain Controller, this usually is provided with Domain Admin rights (it shouldn't though)
https://documentation.solarwinds.com/en/Success_Center/SAM/Content/SAM-Active-Directory-2016-Domain-Controller.htm

So, if you have SolarWinds configure to monitor/manage your environment, follow CISA's guidance to turn it off (for now) & change all related passwords. Review SolarWinds access and adjust as needed.

https://cyber.dhs.gov/ed/21-01/ 

These are just quick examples I found searching "SolarWinds install <TECHNOLOGY/PRODUCT>"

This isn't to pick on SolarWinds but to point out that monitoring/management systems often have extensive rights which makes them a target.

If access isn't limited, compromise is likely.

This is the time to review/tabletop highly privileged service accounts (Domain Admin rights or equivalent) & validate these rights are required. Reduce rights if possible or limit access.

Review agents installed on Domain Controllers with SYSTEM access. Agent control = AD admin

During Active Directory Security Assessments, we see many service accounts with privileged rights that don't require them. Most don't require Domain Admin rights.

We also discover agents on DCs & identify those that have install/run code ability.

Reviewing these is critical