In our most recent blog on the SolarWinds attacks, we examined the domain generation algorithm (DGA) used to initiate contact with the attackers’ command and control (C&C) servers. The control flow, what happens after that contact is made, is also noteworthy.
The control flow of Sunburst varies depending on commands received from the attacker. However, the general control flow can be reconstructed in order to understand how communications would have progressed on machines that were of interest to the attackers.
As described in our previous blog, two types of DNS requests are used for initial communications, and both receive DNS replies. The attackers use two fields in the DNS replies: “A records” for control flow and CNAME to hold data on a secondary C&C server.
Normally, when querying DNS, a hostname string is provided to be translated into a numeric IP address, e.g., google.com may translate into 142.250.72.238. The IP address is held in the A record of the response. Sunburst parses the A record for IP addresses, but they are not used as IP addresses at all, but instead are actually triggers for different malware behavior. Instead of the attackers selecting random IP addresses to trigger different behaviors, they have selected IP address ranges belonging to Google, Amazon, and Microsoft. These are possibly chosen in order to reduce the chances of detection. Again, these IPs are not used as IP addresses in any way and the actual computer systems with these IP addresses are not contacted by the malware.
The IP address value received in the DNS reply represents one of five behaviors depending on the current state:
For a typical infection, Sunburst will first send to the C&C server the first 14 characters of the Windows domain name. This will continue for each 14 character chunk, until the entire Windows Domain name is sent.
Next, the attackers will instruct Sunburst to send the current security product statuses and then send information enabling Sunburst to launch a more robust secondary HTTP-based C&C.
Within any DNS reply, the attackers can also instead instruct Sunburst to restore security product service registry keys that were previously disabled back to their believed default settings and quit or reset the internal state as if it is a fresh infection.
In addition, to facilitate lab environment and sandbox avoidance, if the DNS requests result in a private range IP address, including 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, fc00::/7, fec0::/10, ff00::/8, Sunburst will also clean up and exit.
Victims that were of interest to the attackers would have reached the secondary C&C stage. In this case, the DNS reply would contain a hostname in the CNAME record to be used as a HTTP C&C channel. The CNAME value is checked to see if it starts with http:// or https:// and is prepended with https:// otherwise.
Next, Sunburst will perform repeated HTTP GET requests to receive commands, sleeping a variable amount of time between requests. The path portion of the URL always starts with /swip/upd/ followed by randomly selected URL patterns, in the following order.
Optionally, one or more of the following:
Optionally, followed by one of the following:
If no previous string has been selected, one of the following or optionally, one of the following if a previous string has been selected:
Optionally, followed by:
Followed by:
Also, if the first character in the path is a dot (.), the dot is removed. For example, the following are example URLs that could be used:
The final digit before the .xml extension is not a random character, but represents the return code for previous command requests – typically 0 means success and 1 or other values mean error. For the first 16 requests, a different randomly generated path is used each time, but after that it may repeat random generations that it used previously. If data is being sent to the attacker as a result of a command (e.g. sending system information), the path construction will be different and will be covered in a future blog.
Sunburst also adds the custom header “If-None-Match:” set to the previously described 8-byte userid XOR’d by a randomly generated 8-byte sequence that is appended and then converted into lowercase ASCII hex.
After the HTTP GET request is made, Sunburst checks for a valid response from the attacker. The response uses steganography and is a faux, but convincing XML page of data, where only certain fields are utilized by Sunburst.
The faux XML data is searched for a sequence of:
These sequences are concatenated together with non-hexadecimal characters removed. The first DWORD (4 bytes) of the sequence represents the size of the remaining data, which is validated and then the next byte is an XOR key. The rest of the data is then XOR decrypted by the key byte and then decompressed. After being decompressed, the first character is a number that specifies the action to perform followed by the number of included arguments in the following data for the command:
The command number can instruct Sunburst to perform the following behaviors:
If no data needs to be sent to the attacker, the above GET request with the return code encoded in the URL filename is sent.
If data needs to be sent to the attacker as a result of these commands (e.g. sending system information), the data will be included in the next regular HTTP(S) communication as a POST request or a HEAD request if some error occurred where the data is missing. Details on each of these behaviors and how data is uploaded to the attacker will be covered in an upcoming blog.
Tools associated with these attacks will be detected and blocked on machines running Symantec Endpoint products.
File-based protection:
Network-based protection:
For the latest protection updates, please visit the Symantec Protection Bulletin.
Threat Hunter Team
Symantec and Carbon Black
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。