Solarwinds Hack

Hackers who infiltrated government and business networks via a software update from Solarwinds impacted around 50 organizations at first. The attack campaign was first revealed on Dec. 13 by FireEye, which was one of its first victims, but it still remains as to just how many business and government agencies were affected. We know now that Commerce, Homeland Security, State, Treasury, Energy and The National Institutes of Health all became major targets. In addition, Microsoft and VMware of Palo Alto, California disclosed they had also been hacked.

The hack may have been conducted by a Russian group known as APT29 or Cozy Bear, which is linked to Russia's SVR intelligence agency, according to news reports. The Russian hacking group are suspected of infiltrating as many as 18,000 organizations, but it will take months to know just who was penetrated given how wide spread the virus was propagated.

Solarwinds published its own advisory warning Orion users that the software had been corrupted by a highly sophisticated supply chain attack on Solarwinds Orion Platform software, “Version 2019.4 HR 5 through 2020.1, released between March 2020 and June 2020. The Orion suite of software products help manage IT infrastructure, Network Performance, Server & Application Monitoring, Configuration Management, Log/Traffic Analyzer, to IP address Managing, Storage and Cloud base solutions within a supply chain, so once installed would give the hacker complete control over a system.

FireEye said they came up with a method to block attackers' access to at least some endpoints by seizing one of the C2 domains, avsvmcloud[.]com this is how the attackers communicate with systems running the backdoored software, which it calls SUNBURST. "This kill switch will affect new and previous SUNBURST infections by disabling SUNBURST deployments that are still beaconing to avsvmcloud[.]com."

SolarWinds had around 300,000 customers, 425 US Fortune 500 companies Including telecommunication, US Military, and Government agencies of which nearly 18,000 may have been caught up in the supply chain attack. In addition, the attackers may have added multiple backdoors to many systems which the kill switch that FireEye created and deployed to block attackers on the Orion network software instances may stop some attacks, but not all since the virus could still remain active.

The malware includes a list of IP addresses with which the kill switch created by FireEye stopped. Meaning when the malware beacons to the sized avsvmcloud[.]com, one of the IP addresses on its blocklist gets returned to it. This technique will disrupt the attackers’ and limit access to the infected systems.

You see once the backdoored Orion update was installed with the Sunburst hack a name people started calling it. The software waited for a random period of time - typically about two weeks - before attempting to "phone home" to a hard-coded IP address to communicate with a C2 server, according to an analysis published on Dec. 13 by FireEye.

The vulnerability affects the following products versions

VMware Access 20.01 and 20.10 on Linux
VMware vIDM 3.3.1, 3.3.2 and 3.3.3 on Linux
VMware vIDM 3.3.1, 3.3.2, 3.3.3, 19.03
VMware Cloud Foundation 4.x
VMware vRealize Suite Lifecycle Manage 8.X

In addition, researchers at Chinese firm RedDrip Team have built a tool that has been able to decrypt some of the C2 information, which has revealed a partial list of organizations - stretching to more than 1,700 hostnames - that were running Sunburst.

On Saturday, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) warned that the same supply chain hackers appeared to also have been using "initial access vectors other than the SolarWinds Orion platform," including abusing security assertion markup language - aka SAML - tokens. CISA’s advisory specifically noted that by compromising the Security Assertion Markup Language (SAML) signing certificate using their escalated Active Directory privileges. They could create unauthorized but valid tokens and presents them to services that trust SAML tokens from the environment. These tokens can then be used to access resources in hosted environments, such as email, for data exfiltration via authorized application programming interfaces (APIs).”

In addition, after the malware phones home, attackers sometimes pushed a dropper, called Teardrop, to the endpoint. This malware can install and execute additional malware, to help attackers map the network, exfiltrate data and deploy additional tools to facilitate long-term remote access.

Microsoft products were also hacked and for those organizations using the Azure cloud®10, Microsoft offered tools including Azure AD Identity Protection®11, Microsoft Cloud Application Security®12, and Azure Sentinel, but other third-party products may be used to perform log analysis as well.

Here is a list of some of the things to look for on your network.

Examine logs for suspicious tokens that do not match the baseline for SAML tokens that are typical for the tenant, and audit SAML token use to detect anomalies, for example:

·Tokens with an unusually long lifetime;

·Tokens with unusual claims that do not match organizational policy;

·Tokens that claim to have been authenticated using a method that is not used by the organization (e.g., MFA when the organization does not use MFA, or MFA by a provider that does not usually perform MFA);

·Tokens presented without corresponding log entries, such as tokens with MFA claims where there is no corresponding MFA system transaction, or tokens consumed at the resource with no corresponding federation server transaction.

·Tokens that include a claim that it is for inside the corporate network when it is not;

·Tokens that are used to access cloud resources that do not have records of being created by the on-premises identity provider in its logs

·Examine logs for the suspicious use of service principals:

·Audit the creation and use of service principal credentials;

·In particular, look for unusual application usage, such as a dormant or forgotten application being used again;

·Audit the assignment of credentials to applications that allows non-interactive sign-in by the application [18][19]. Look for unexpected trust relationships that have been added to AAD [18]

In addition, you might consider using Azure Active Directory as the Authoritative Identity Provider because by consolidating identity and access natively in the cloud, tenants relieve themselves from the burden of managing the federation of authentication and the on-premises service, and gain more of the protections that the cloud provider has in place, including system hardening, configuration and monitoring. The drawback of doing this is that SSO may not work across on-premises and cloud resources and the tenant must trust the cloud provider to host user credential information

The Cybersecurity and Infrastructure Security Agency (CISA) advisory notes the attackers behind the SolarWinds compromises targeted key personnel at victim firms — including cyber incident response staff, and IT email accounts. Staff should assume their email communications and internal network traffic are compromised, and rely upon out-of-band systems for discussing internally how they will proceed to clean up the hack.