Looking at possible connections between #Sunburst and #Kazuar, a thread: #SolarWinds #UNC2452 #DarkHalo

On Dec 21, 2020, as we were observing the great conjunction between Saturn and Jupiter, one of our researchers made a discovery. While looking at Sunburst, he discovered a number of similarities with an older malware known as Kazuar.

These similarities included the victim UID generation algorithm, the sleeping algorithm and the extensive usage of the FNV-1a hash. We spent the next 3 weeks examining these details and looking at possible theories behind the overlap.

The modified 64-bit FNV-1a hash implemented in recent Kazuar has one extra step: result is XORed with a hardcoded constant (0x69294589840FB0E8UL). In Sunburst, after the hash is calculated, result is XORed with (0x5BAC903BA7D81967UL). Note these constants are different.

The usage of these modified 64-bit FNV-1a hashes could be a coincidence, however, we looked for any other malware that uses them, without too much success. DM for a Yara rule to hunt by yourself.

To calculate unique victim UIDs, both Kazuar and Sunburst use a hashing algorithm which is different from their otherwise “favourite” FNV-1a; a combination of MD5+XOR. Kazuar XORs the MD5 of a pre-defined string with a four-byte key which contains the volume serial number.

Sunburst computes an MD5 from a larger set of data, which concatenates the first adapter MAC address (GetAllNetworkInterfaces()), the computer domain (GetIPGlobalProperties().DomainName) and machine GUID, then it XORs together the two halves into an eight-bytes result.

These two victim UIDs algorithms are not identical, however, the usage of an MD5+XOR instead of the otherwise popular FNV1a is curious. Coincidence or programming habit?

Kazuar and Sunburst use the same mathematical formula, relying on Random().NextDouble() to calculate the waiting time. Kazuar randomly waits 2-4 weeks _between_ C2 connections. Sunburst randomly selects a sleeping period between 12 and 14 days _before_ contacting its C2.

In general, large delays, in the range of weeks, between or before C2 connections are not very popular with APT malware. Of course, exceptions exist.

Could it be a false flag? Perhaps Sunburst tried to shift the blame to Kazuar and indirectly, Turla, by adding these similarities? Note the XOR operation after the main FNV-1a computation was introduced in the 2020 Kazuar variants _after_ it had appeared in the Sunburst code.

In this case, the possibility of a false flag is less likely as the authors of Sunburst couldn’t have predicted the Kazuar’s developers’ actions with such high precision.

Although the usage of the sleeping algorithm may be too wide, the custom implementation of the FNV-1a hashes and the reuse of the MD5+XOR algorithm in Sunburst are definitely important clues.

We should also point out that although similar, the UID calculation subroutine and the FNV-1a hash usage, as well the sleep loop, are still not 100% identical.

Possible explanations for these similarities include:

* Sunburst was developed by the same group as Kazuar
* The Sunburst developers adopted some ideas or code from Kazuar, without having a direct connection (they used Kazuar as an inspiration point)

* Both groups, DarkHalo/UNC2452 and the group using Kazuar, obtained their malware from the same source
* Some of the Kazuar developers moved to another team, taking knowledge and tools with them
* The Sunburst developers introduced these subtle links as a form of false flag

At the moment, we do not know which one of these options is true. While Kazuar and Sunburst may be related, the nature of this relation is still not clear.

Through further analysis, it is possible that evidence enforcing one or several of these points might arise. To clarify – we are NOT saying that DarkHalo / UNC2452, the group using Sunburst, and Kazuar or Turla are the same.

Full article+FAQ: https://securelist.com/sunburst-backdoor-kazuar/99981/

Last but not least, mad props to our colleague Georgy Kucherin, who discovered these overlaps.