the main reason for hashing the strings was probably to avoid being caught with a simple yara rule like "MZ-header and contains xagt and sysmon and ollydbg". the xor key and resulting hashes can also be easily changed so they're not helpful for finding other malware of the same group. after looking quite some time at the algorithm (for performance optimization for hash cracking to the point where it's now 4 times as fast as the standard go hash package for fnv1a ;) I came up with the idea of searching for this specific implementation (standard fnv1a plus the extra xor in the end). the 1st rule looks for this in MSIL as generated by C# in sunburst, without relying on the xor key. the 2nd rule looks for the same in x64 binaries, assuming that the attackers only used C# because they had blend into the solarwinds software.
matches 3 known sunburst samples. no false positives in yara-ci.
regarding "The additional XOR operation forces malware analysts to develop custom tools to brute force the hash preimage." in https://www.fireeye.com/blog/threat-research/2020/12/sunburst-additional-technical-details.html:
the main reason for hashing the strings was probably to avoid being caught with a simple yara rule like "MZ-header and contains xagt and sysmon and ollydbg". the xor key and resulting hashes can also be easily changed so they're not helpful for finding other malware of the same group. after looking quite some time at the algorithm (for performance optimization for hash cracking to the point where it's now 4 times as fast as the standard go hash package for fnv1a ;) I came up with the idea of searching for this specific implementation (standard fnv1a plus the extra xor in the end). the 1st rule looks for this in MSIL as generated by C# in sunburst, without relying on the xor key. the 2nd rule looks for the same in x64 binaries, assuming that the attackers only used C# because they had blend into the solarwinds software.
matches 3 known sunburst samples. no false positives in yara-ci.