While reviewing all the community’s fantastic information about the SolarWinds breach known as Solarigate, I noticed that the reports provided information about the Solarigate and how to detect it, but little guidance. Initial reports indicate that the attackers did not actively exploit most SolarWinds customers. However, other actors could have used the breach. This document is broken into two parts; Part 1 is focused on the on-premises environment, and Part 2 will focus on the Azure and Microsoft 365 environments.

In reviewing the potential areas of impact, we focused our efforts on the areas most likely used for ongoing, undetected exploits of on-premise systems. Identity and access systems (accounts, passwords, and certificates) and Local and Group Policy are the most likely areas exploited.

Our recommendations assume that any environment that could have been exploited was exploited. The challenge based on this assumption is that an attacker would have had domain or enterprise admin rights and a significant amount of time to perform actions that would not be detected by anti-malware services. These activities include creating fake accounts, elevating account access, and creating backdoors, all without malicious software. This activity would look like regular activity in your environment.


Mitigation and remediation start with protecting the environment through resetting passwords and a detailed discovery of the environment.


Before changing passwords, a thorough review of organizational password policies needs to be reviewed. Password policies should, at a minimum, comply with NIST 800-63b recommendations. Organizations should implement a fine-grained password policy that allows for different password policies based on account types. Our advice is a minimum password length of 14 characters, without password complexity. Where it is possible, interactive authentications should require multi-factor authentication.

All user accounts, excluding administrative and service account passwords, need to be set to require a change at the next login. Administrator account passwords should be reset to a new complex password and transmitted directly to the person. Devices like routers, switches, integrated management (lights out), management consoles, phone systems, and appliances also need to have their local passwords reset. Finally, cloud services that are not SSO integrated or have non-SSO access accounts also need to be reset.

Service accounts are generally more challenging to reset as there are implications for applications and may require a server or service restart. Creating a service account policy to prevent interactive login can mitigate significant risk and is a good practice. Preventing interactive login may not be an option for all service accounts, and in those situations, passwords should be changed immediately.


It is known that the Solarigate attackers stole SAML signing certificates and modified federated trusts. Organizations using Active Directory Federated Services (AD FS) should follow a two-step strategy to prevent further access. First, replacing all SAML certificates for federation in AD FS and second, migrate all federation services to Azure AD SSO. All user and device certificates should be revoked and reissued. Certificates that are issued through group policy will be reissued without user intervention. A project should be put in place to reissue certificates issued manually, such as web server certificates.


Discovery is not technically complicated; however, the analysis will require human power to find any compromise signs. The code below does not require any special access, though users will need the ActiveDirectory PowerShell module. The PowerShell commands will gather information and generate a CSV of the results for review. The CSV files are created in the folder the commands are run. Additionally, you will need to repeat the discovery process in each forest and domain in your environment for complete discovery.

Domain Trust

There is the possibility that an attacker could create a domain trust. Review all the trusts in your environment to determine if they should exist. Trusts that are no longer needed should be removed, and the unknown trusts should be investigated to determine if it is legitimate. If there are no trusts in your domain, the file will be empty.

Group Policy

Attackers can use Group Policy to configure settings that assist them in their attacks against your environment. A good practice is to remove unlinked group policies if they are no longer needed and alert on adds or changes to group policy. The script creates two CSV files, GPOList.csv that is a list of all GPO’s, and GPOLinks.csv, with all the same information as GPOList.csv, plus the link location and settings for each policy. Look for policies that are new or have been recently modified and validate the settings in those GPOs. GPOs that change firewall rules and anti-malware exclusions could be an indicator of compromise.

User Information

With the potentially long duration of compromise, the user script will get all users created since 1/1/2020. The challenge with user creation is that it is an everyday activity in Active Directory environments. The list should be reviewed for any accounts that don’t match existing employees and known service accounts. Accounts that are unknown or unexpected should be investigated and determined as to their function and need. Accounts with the PasswordNeverExpires or PasswordNotRequired attributes set to TRUE should receive special attention. There are few reasons for an account not to require a password or never to expire.

Group Membership

The review of group membership is likely to have minimal effect as it is a point in time review, and group membership tends to change over time. Reviewing the membership of administrative and sensitive groups will provide more details. It is essential when looking at groups to include distribution groups as they can be used to monitor and pull information from an organization passively.

Service Principal Names (SPNs)

Service Principal Names (SPNs) are identifiers of services that a particular system offers and associates an account with that service. SPNs are stored in the AD Attribute “servicePrincipalName”, which is only visible in Active Directory Users and Computers if you have enabled Advanced Features, and look in the Attribute Editor tab. SPNs are visible on User and Computer objects via LDAP, PowerShell, and other programming languages. SPNs can be used to hide activity and access an existing account easily. However, activity is surfaced in security event logs. The commands below get all user and computer SPNs in Active Directory and export the information to SPNList.csv. Objects can have multiple UPNs, which is semi-colon delimited in the ServicePrincipalNames field. During the review, look for accounts where there likely shouldn’t be an SPNs, like regular user accounts and workstations.

Group Managed Service Accounts

Group Managed Service Accounts (gMSA) are used to manage services and are like a user account. They provide additional security and simplified management of service accounts. For more information on gMSAs and how to use them, please visit https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview.


While these manual steps outlined are the start of re-securing your environment, they are not a long term solution. Monitoring and automated auditing and analysis provide a faster and more in-depth discovery and insight into your environment. While anti-malware and firewalls are the first lines of defense, the next line of defense is monitoring.

Microsoft has several cloud-based tools that greatly assist in providing auditing, investigation, and analysis of your environment. Azure Sentinel is a Security Information and Event Management (SIEM) tool that provides log collection, correlation, analysis, and alerting. Microsoft Defender for Identity  (formerly Azure Advanced Threat Protection) is a cloud-based service that works with Active Directory to identify advanced threats and compromised identities. Azure Sentinel and Microsoft Defender for Identity can provide early warning to changes in your environment that may not be detected as malicious by other systems.