đź’€Unmasking UNC2452 (DarkHalo)
EXECUTIVE SUMMARY
On December 14, SolarWinds filed a Form 8-K disclosure with the Securities and Exchange Commission (SEC), which is used to inform shareholders of publicly held corporations of events that may impact the value of the stock, in relation to the reported intrusion activity. The filing does not provide any details in relation to specific attribution but does indicate that a highly sophisticated, foreign nation-state attacker was responsible for the activity. The filing provides information in relation to the specific updates in which the SUNBURST (or Solorigate) malware was present. According to the statement, “SolarWinds has evidence that the vulnerability was inserted within the Orion products and existed in updates released between March and June 2020….[it was] introduced as a result of a compromise of the Orion software build system and was not present in the source code repository of the Orion products.” This aligns with a statement issued by Microsoft which indicated “This backdoor can be distributed via automatic update platforms or systems in target networks seen globally since March 2020.” Although these specific software updates, beginning in March and continuing through June, were identified by SolarWinds as containing the SUNBURST (or Solorigate) malware, threat intelligence company FireEye has indicated that the campaign associated with the malware began in Spring 2020 and is currently ongoing. Per a statement quoted in a December 14 Reuters report, “SolarWinds said on Monday that fewer than 18,000 of its customers had downloaded a compromised software update”.
THE ADVERSARY
UNC2452 aka “Dark Halo” is a sophisticated group motivated by cyber espionage that has targeted government and private sector entities worldwide. They have employed numerous unique capabilities, including gaining initial access through as software supply chain vulnerability. After gaining access to a victim network, UNC2452 has a light malware footprint, often leveraging legitimate credentials to access data and move laterally.
THE PENTAGON MODEL
MITRE ATT&CK
TTPs for DEFENSE-IN-DEPTH
> Defense Evasion
T1070 — Indicator Removal on Host
Adversaries may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Locations and format of logs are platform or product-specific, however standard operating system logs are captured as Windows events or Linux/macOS files such as Bash History and /var/log/*.
These actions may interfere with event collection, reporting, or other notifications used to detect intrusion activity. This that may compromise the integrity of security solutions by causing notable events to go unreported. This activity may also impede forensic analysis and incident response, due to lack of sufficient data to determine what occurred.
- Encrypt Sensitive Information — Obfuscate/encrypt event files locally and in transit to avoid giving feedback to an adversary.
- Remote Data Storage — Automatically forward events to a log server or data repository to prevent conditions in which the adversary can locate and manipulate data on the local system. When possible, minimize time delay on event reporting to avoid prolonged storage on the local system.
- Restrict File and Directory Permissions — Protect generated event files that are stored locally with proper permissions and authentication and limit opportunities for adversaries to increase privileges by preventing Privilege Escalation opportunities.
File system monitoring may be used to detect improper deletion or modification of indicator files. Events not stored on the file system may require different detection mechanisms.
> Collections
T1114 — Email Collection
Adversaries may target user email to collect sensitive information. Emails may contain sensitive data, including trade secrets or personal information, that can prove valuable to adversaries. Adversaries can collect or forward email from mail servers or clients.
- Network Intrusion Prevention — Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Malware researchers can reverse engineer malware variants that use dynamic resolution and determine future C2 infrastructure that the malware will attempt to contact, but this is a time and resource intensive effort.
- Restrict Web-Based Content — In some cases a local DNS sinkhole may be used to help prevent behaviors associated with dynamic resolution.
Detecting dynamically generated C2 can be challenging due to the number of different algorithms, constantly evolving malware families, and the increasing complexity of the algorithms. There are multiple approaches to detecting a pseudo-randomly generated domain name, including using frequency analysis, Markov chains, entropy, proportion of dictionary words, ratio of vowels to other characters, and more. CDN domains may trigger these detections due to the format of their domain names. In addition to detecting algorithm generated domains based on the name, another more general approach for detecting a suspicious domain is to check for recently registered names or for rarely visited domains.
> Command & Control (C2)
T1568 — Dynamic Resolution
Adversaries may dynamically establish connections to command and control infrastructure to evade common detections and remediations. This may be achieved by using malware that shares a common algorithm with the infrastructure the adversary uses to receive the malware’s communications. These calculations can be used to dynamically adjust parameters such as the domain name, IP address, or port number the malware uses for command and control.
Adversaries may use dynamic resolution for the purpose of Fallback Channels. When contact is lost with the primary command and control server malware may employ dynamic resolution as a means to reestablishing command and control.
- Audit — Enterprise email solutions have monitoring mechanisms that may include the ability to audit auto-forwarding rules on a regular basis. In an Exchange environment, Administrators can use Get-InboxRule to discover and remove potentially malicious auto-forwarding rules.
- Encrypt Sensitive Information — Use of encryption provides an added layer of security to sensitive information sent over email. Encryption using public key cryptography requires the adversary to obtain the private certificate along with an encryption key to decrypt messages.
- Multi-factor Authentication — Use of multi-factor authentication for public-facing webmail servers is a recommended best practice to minimize the usefulness of usernames and passwords to adversaries.
There are likely a variety of ways an adversary could collect email from a target, each with a different mechanism for detection.
File access of local system email files for Exfiltration, unusual processes connecting to an email server within a network, or unusual access patterns or authentication attempts on a public-facing webmail server may all be indicators of malicious activity.
Monitor processes and command-line arguments for actions that could be taken to gather local email files. Remote access tools with built-in features may interact directly with the Windows API to gather information. Information may also be acquired through Windows system management tools such as Windows Management Instrumentation and PowerShell.
Detection is challenging because all messages forwarded because of an auto-forwarding rule have the same presentation as a manually forwarded message. It is also possible for the user to not be aware of the addition of such an auto-forwarding rule and not suspect that their account has been compromised; email-forwarding rules alone will not affect the normal usage patterns or operations of the email account.
Auto-forwarded messages generally contain specific detectable artifacts that may be present in the header; such artifacts would be platform-specific. Examples include X-MS-Exchange-Organization-AutoForwarded set to true, X-MailFwdBy and X-Forwarded-To. The forwardingSMTPAddress parameter used in a forwarding process that is managed by administrators and not by user actions. All messages for the mailbox are forwarded to the specified SMTP address. However, unlike typical client-side rules, the message does not appear as forwarded in the mailbox; it appears as if it were sent directly to the specified destination mailbox. High volumes of emails that bear the X-MS-Exchange-Organization-AutoForwarded header (indicating auto-forwarding) without a corresponding number of emails that match the appearance of a forwarded message may indicate that further investigation is needed at the administrator level rather than user-level.