In December 2020, a large-scale cyberattack targeting many organizations – predominantly tech companies, mainly in the United States, but not only there – was discovered to have been going on for several months. The attack was of a degree of sophistication that led to a quick consensus of involvement by a foreign government, and was extraordinary in both the amount of care taken in crafting it and the exotic vector of entry; instead of the usual phishing or even exploitation, the attackers carried out an elaborate supply chain attack. In this post, we share a focused analysis of some choice features of the backdoor used (SUNBURST) and one of its payloads (TEARDROP), including an exhaustive deobfuscation of SUNBURST’s hashes encoding strings and an analysis of TEARDROP’s control flow and decryption method; and we share our perspective on what these findings say about the attack and the people behind it, as well as what bearing this attack has on the future of network security in general.
Here’s a story you mighthaveheardalready: Mr. Exemplary CISO wakes up early one morning and goes to work as usual, a spring in his step and a bunch of one-time recovery passwords in his wallet that he never ever loses. He reaches the lobby, swipes his smart card which performs an Adi-Shamir-Level challenge-response scheme, and walks past reception where shoulder-surfers are shot on sight. He boots up his laptop, types the BIOS password which is three sentences from Moby Dick, presents his retina for scanning and waits patiently as the mail exchange server remotely verifies the integrity of his laptop down to the network card circuit design. A spear-phishing email reaches 40 of his colleagues, all of whom report the incident then delete the email without consciously registering the event. Somewhere on the third floor the signing certificate for a certain device driver expires, and the offending server spontaneously combusts, as per protocol. Just when he thinks life can’t get any better, Mr. Exemplary CISO receives one of his favorite things in the world: A software update notification. The updated DLL is signed with the right certificate, its hash had never been seen before, it’s almost identical byte-for-byte to the one sent last version, its sandbox run produces no suspicious behavior; and so the update is installed, and Mr. Exemplary CISO’s organization is, how goes the parlance, “pwned”, because the software supplier’s production server was compromised — via social engineering, an unpatched 1-day vulnerability or the admin password being password123, pick your favorite — and so a sufficiently clever attacker could access that server and flawlessly arrange all the above.
There are so many ways that sufficiently clever attackers could make all our lives miserable, but usually don’t, and this whole ordeal is a somber reminder of that. President of Microsoft, Brad Smith, put it this way: “This is not ‘espionage as usual,’ even in the digital age [..] this is not just an attack on specific targets, but on the trust and reliability of the world’s critical infrastructure”. We’re not quite as eloquent and will just say that this isn’t the Sony hack and it can’t be dismissed with “don’t click update later, don’t click enable macros“. To deflect future attacks of this sort, defenders will have to get technical, get creative, and be willing to make trade-offs that would have seemed wasteful and paranoid before. Somewhere, the author of your favorite banking Trojan just read this news, raised an eyebrow and said “hey, will someone run me a port scan on notepad-plus-plus.org“. Even if every vendor of every popular piece of software does become hyper-vigilant now, we all can’t get too complacent trusting in their hyper-vigilance. That’s what we mean by the threat of a “NetSec New Normal”: an unsettling step into a future of zero trust.
SUNBURST and the Art of Tactical Retreat
Technical details of the SUNBURST backdoor are widely available now in greater abundance than you will ever require, which puts us at liberty to focus on one feature that interests us and perhaps hasn’t been drilled into quite like the others: The backdoor’s elaborate evasion scheme.
The evasions employed by SUNBURST are similar in concept to sandbox evasions. Sandbox evasions are engineered to make sure that the malware doesn’t run on virtual machines designed to detect malware; SUNBURST’s evasions are engineered to make sure that the malware doesn’t run on machines belonging to people who have thought of the word “malware” in the last thirty days. We’ve seen malware that includes blacklists of forensic tools, AV processes and such — but 1. Usually these blacklists were used to violently smother these processes instead of opting not to run the malware at all; and 2. None of them were half as comprehensive as this one. The list is an OCD-level of thorough and can be legitimately used as a resource for reverse engineers to be acquainted with new tools (ever heard of pdfstreamdumper? Well, you have now).
In-line with the overall theme of not wanting to be seen, this blacklist is not given in the form of an array of readable strings. Rather, the readable strings are replaced with FNV-1a hash values. This alone has been an occasional malware feature for years now (except the hipster-ish use of FNV-1a instead of SHA256, or even CRC32 checksums), but the feature that really stands out here is the dedication to maintaining an illusion of code legitimacy even when under direct review. The below code literally attempts to use a Jedi mind trick on the reader: “This is not the malware you are looking for, move along”. The list of processes to blacklist is a “service list” belonging to the “Orion Improvement Business Layer”, and these aren’t hash values of process names associated with AV engines — they are “timestamps”.
The authors weren’t satisfied with just blacklisting processes and services. They also made sure to blacklist some device drivers and entire ranges of IP addresses (by translating the infected machine’s IP to a domain name and including domain names in the blacklist), a feature that was used to blacklist all internal Solarwinds domains. This teaches us that not only the attackers decided to use Solarwinds as a Uber to get to their targets, they also learned in-detail the topology of Solarwinds’ internal networks to evade the prying eyes of vigilant employees. In total, the list of hash-encoded strings embedded in SUNBURST is a paranoid manifesto of over 200 domains, providers and services that SUNBURST will just flatly refuse to deal with. Mark Russinovich put it tersely, saying that the attackers are “afraid of sysinternals“. Which goes to show, even the most advanced and persistent of attackers don’t believe themselves to be invincible — they believe in being just invincible enough, and above all, in not tempting fate.
The full list of FNV-1a obfuscated strings included in SUNBURST is available in Addeneum I.
TEARDROP and Settling for the Ordinary
This attack was, no doubt, an incredible technical achievement on a large scale. Check Point Threatcloud telemetry shows over 250 organizations that were infected with the SolarWinds backdoor, half of which are in the United States. The attackers dotted their i’s and crossed their t’s: they made sure to follow Solarwinds’ coding convention when pushing malicious code; they included a “logic bomb” in their initial payload to delay malicious activity a full two weeks from initial infection, and fool dynamic analysis; they limited their lateral movement to legitimate-seeming operations made with stolen, but valid, user credentials. For all these reasons, it’s noteworthy that this Übermensch-tier attack was used to deploy TEARDROP, a merely human malware dropper.
At the time of discovery TEARDROP was a novel concoction: never-before-seen, possibly even tailor-made for this attack. It was only deployed against a select few targets. If you’re eager to feel its bits and bytes, there’s hashes courtesy of Talos and Sophos, as well as YARA rules by FireEye. TEARDROP runs in-memory but it does register a Windows service, which involves editing the registry.
TEARDROP’s control flow is straightforward. One of the DLL exported functions, Tk_CreateImageType, is called during the service’s execution. This function writes a JPEG image to the current directory, the name of which varies; Symantec reports having come across upbeat_anxiety.jpg and festive_computer.jpg, and FireEye has seen a gracious_truth.jpg. To the untrained eye, these might seem to have been named by a poet; but more likely the image name is randomly generated by concatenating two words from a hard-coded word list that’s out there somewhere, on whatever machine was used to compile this piece of malware.
TEARDROP then performs decryption using a homebrew cipher and a hardcoded key of length 0x96. The process is implemented using the following gem of disassembly:
At a high level, this reads like some sort of homebrew PRNG deciding which key byte to use each time, except the more you attempt to follow the actual process, the less sense it makes. Amazingly, when run dynamically, via some dark magic the generated key indexes simply map to 0, 1, 2, ..., 149, 0, 1, ... and so on; that’s some new level of “pseudo” in “pseudo-random”! As it turns out, this isn’t a PRNG — it’s a compiler-optimized implementation of the modulo operation. Feast your eyes on its underlying reasoning, which is somewhat reminiscent of the Quake Fast Inverse Square Root Hack. If anything, this is mainly a testament to the power of dynamic analysis if we ever saw it. You weren’t going to statically reverse-engineer that. (Alternatively, it is a testament to the power of hex-rays decompiler, which sees through it immediately).
Once the optimization is understood, the decryption code is equivalent to the following:
So, the original encryption was a simple rotating XOR, followed by also XORing every ciphertext byte with the previous ciphertext byte. There’s probably no purer distillation than this of “homebrew cipher thrown together in five minutes for a piece of malware”. This is a perfectly good obfuscation scheme, mind you, but for the thousandth time, there is no reason for that extra XOR to be there. No one is randomly launching the Kasiski attack against in-memory binary blobs in hopes of encountering rotating XOR ciphertexts.
The decrypted payload has the following custom header format, which reads like the tl;dr of a proper PE header:
And here’s a taste of the payload code itself. The First image shows the code of the decrypted BEACON payload found on TEARDROP while the second image shows the code of a known BEACON sample we picked randomly. We won’t fault you for not being able to find the differences between this picture and that picture. Even the PE base address is the same.
The way TEARDROP is built, it could have dropped anything; in this case, it dropped BEACON, a payload included with Cobalt Strike (a “penetration testing” tool based on the well-known Metasploit framework). According to the Cobalt Strike website, BEACON’s purpose is to model advanced attackers. It supports network lateral movement across a variety of protocols, “passive” and “active” modes for C2 check-in, and a configurable C2 communication scheme that can be made to imitate other malware or blend in with the target network’s legitimate traffic.
This really bears consideration. These attackers were riding on the tail of a network breach of almost unprecedented sophistication, and now they had to pick their weapon of choice for conducting lateral movement and data exfiltration. Armed with boundless ambition and abundant resources, they looked over their options and picked… Cobalt Strike? Even Dton, the Nigerian hustler who was covered here earlier this year and objectively ranks in the top 50 of least competent cybercriminals of all time, had an intuition that using well-known commodity malware will cost him in detection rates. We can’t argue with success, and this decision clearly paid off for the attackers, but we’re sure curious about the reasoning behind it. Possibly it was meant to make attribution harder, and we can’t rule out the use of higher-tier payloads for higher-tier targets.
Conclusion: Where to from here?
If we had to pick one actionable pithy phrase in the wake of this breach, it would be “Defense in Depth”. It seems like a cliché that has been with us since forever ago, but it apparently originates with a 2012 paper by the NSA, and the principle behind it is sound and relevant: don’t spend all your energy building a single wall. There are no perfect walls, and someday, someone is going to get through to the other side. When configuring a component, imagine an ongoing attack that is within reach of it now — what will help secure the component? Or an attack that has compromised the component already — how best to pre-empt the attack from propagating further? A lot of principles and practices go into this; the Principle of Least Privilege, to name one.
We’re not Naïve: organizations want to Get Stuff Done, and the incentives they set effectively mandate a Principle of Most Privilege. Employees the world over are constantly demanding, “Just let me do this thing! Don’t make me do something ‘more secure’ that’s 4 times as complicated!”. Even as we rush to zealously Secure Everything, these concerns should be taken seriously. We couldn’t put it better than Avi Douglen has: “how often does strict password complexity policy enforced by IT [..] result in the user writing down his password, and taping it to his screen? That is a direct result of focusing too much on the computer aspect, at the expense of the human aspect. [..] Security at the expense of usability comes at the expense of security.”
Looking at the binaries for SUNBURST and TEARDROP, we’ve learned that even this wildly successful operation had its rough edges. Far from a worry-free power trip, the attackers were wary all the while of having their activity seen at all, never mind recognized for what it was; extensive blacklists of domains and processes had to be created to make sure of that. We’ve learned that even a campaign on this level will not consist purely of ingenuous rabbit-pulls, textbook solutions and tour-de-forces; even while pulling off an astounding network security coup like this, at some points an actor will say “eh, it’ll do” and reach for the ole-reliable forgettable loader, rotating XOR encryption and used-to-death commodity tool. There’s something comforting about that; the attackers won this round, but maybe the game in general is not so hopeless — if defenders step up.
For full technical details on our response to the SolarWinds attack click here
Addendum I: List of FNV-1a Obfuscated Strings Included in SUNBURST