As most of you may be aware, nation state-sponsored hackers breached software provider SolarWinds to inject a type of malware called “Sunburst” into the SolarWinds’ Orion software platform. Sunburst is a trojanized malware signed with valid digital certs, and contains a back door used to communicate with command and control (CnC) servers on the dark web.
Apart from some very big names (e.g. FireEye and Microsoft) that disclosed their exposure in December (2020) and January (2021), many more entities including many cyber-security vendors have now also disclosed that they were also targeted and breached by the SolarWinds supply chain attack.
While most of these (software) vendors claim that they have contained the attack and have taken mitigating actions, the fallout continues.
“While most of these (software) vendors claim that they have contained the attack and have taken mitigating actions, the fallout continues”
Implementing a defense-in-depth scheme using the various best practices defined below is going to be critical in defeating SolarWinds and other sophisticated malware and better managing third-party cyber risk.
Enable Improved DNS Alerting using a DNS Sinkhole
Deploying a Domain Name Service (DNS) Sinkhole, a technique that helps with the identification and blocking of DNS requests from malware infected hosts on a private network, can prove very effective in detecting suspicious DNS traffic using malicious techniques like DNS tunneling. It enables the redirection of malicious internet-bound traffic by entering a fake entry into a DNS server to change the traffic flow of a malicious URL. The sinkhole allows corporate cybersecurity teams to control any Command and Control (CnC) bound traffic and other malicious traffic across a private network. In addition to sinkholing malicious traffic, this technique can also be used to deploy kill switches against malware. Additional modern ML techniques such as Shannon Entropy on real-time DNS traffic can also be used to alert against such attacks.
Deploy Malware Kill Switch
The kill switch kills or terminates a ransomware process, sometimes working in tandem with a sinkhole to do so. It is generally a file which crashes the parent process when the ransomware attempts to enumerate or encrypt it. This technique can be proactively deployed to work against a generic class of ransomware. Kill switch files are generally pushed to high-risk endpoints or servers by security teams as defensive measures.
The kill switch can also be backdoor into the malware with a command interface that the attacker may have left open to kill the process if/when needed, that can now be used by cyber defense teams.
Perform Monitoring and Alerting Enhancements
To perform cross-functional analysis and create alerts to detect SolarWinds-type attacks, use supervised or unsupervised deep learning machine learning (ML) algorithms to enable real-time full traffic packet capture from network SPAN or TAP ports. These cross-functional alerts within a security incident and event management (SIEM) system with automated orchestrated reactive response will be the only effective way of stopping these attacks.
Detect Golden SAML Attacks
The Golden SAML cyber-attack forges SAML responses and bypasses IdP authentication to access federated services via SSO. This attack builds on the traditional Kerberos attacks such as pass the hash (PTH) or golden or silver ticket (attacks) on Active Directory (AD) where the attacker gains privileged access (e.g., domain admin) on an AD domain controller. To distinguish golden SAML attacks from legitimate SAML authentication events, correlate SP login events with corresponding authentication events within the Identity Provider (IdP) and AD domain controllers (DC), and identify the SP logins using SAML SSO which do not have corresponding events in the DC. To identify golden SAML attacks, detect any of the following: an export of an IdP certificate (to extract the private key), the addition of new custom SAML attributes or modification of existing attributes, and the addition of a new trusted (yet malicious) IdP.
Enabling the capability to detect the reuse of user authentication tokens by different IP addresses, auditing Kerberos traffic, or detecting a sudden spike in (kerb) service ticket requests can also be used as detection triggers.
Reconsider the usage of DOH
While the usage of DNS over HTTPS (DOH) is beneficial to maintain the confidentiality of DNS requests, it can also be used by malware to hide malicious DNS tunneling requests. Thus if the capability does not exist to perform a TLS inspection of DNS traffic, then I recommend that the use of DNS over HTTPS be disabled for corporate environments where visibility into DNS traffic is required to enforce corporate information security standards and gain visibility into malicious DNS requests from corporate networks.
Apart from this, some additional enhancements may be to block all newly registered internet domains for 48 hours, proxy all DNS requests, and block port 53 for outbound DNS requests from internal endpoints and servers. (Internal Endpoints and servers should be configured to use internal namespace servers, not those hosted on the internet.)
Better manage third-party risk
The capability to gain visibility into third-party risk by implementing a threat Intel platform, access to third party breach information and follow general security hygiene protocols can prove beneficial in determining the risk of third-party network and security breaches. Also, critical to
attack prevention is capability to assess the integrity of the software build and delivery process used by vendors to protect themselves from injection of malware, and dependency and namespace confusion attacks.
