There’s been a lot of speculation and conjecture around this “Petya” outbreak. A great deal of it seems to have been fueled by confirmation bias (to us, at least).
Many things about this malware don’t add up (at first glance). But it wouldn’t be the first time that’s happened.
And yet everyone seems to have had answers to a variety of burning questions – within mere moments of this whole thing exploding. It’s either a case of “wisdom of the crowd” (definitely good) or “group think” (definitely bad).
We prefer to avoid being pulled into group think, so we’ve stepped aside, exercised patience, and tried to apply some healthy skepticism to the matter. We realized that our questions could only be answered after a thorough analysis of the available material. So we took the methodical approach.
There’s a large risk of jumping the gun in this particular case, and it’s too important to us to risk that. Yeah, we get it. This is a topic with very high interest and people have been awaiting our say on the matter. We’ve erred on the side of caution. In the current media landscape, narratives can quickly get out of control of one person or organization’s ability to course correct. We don’t want to be the ones steering the ship in the wrong direction.
Needless to say, our analysts have been working long, hard hours on this case over the past few days, and ordering in so they can keep working.
So, taking the default position of “it does what it says on the tin”, what evidence would convince us to change our minds? (Fans of the scientific method.) We didn’t really know what evidence was needed until we started looking. And, so, over the past 48 hours, we’ve bombarded our colleagues with questions (a lot of which we’ve seen others asking). So, without further ado, let’s start.
Lots of ransomware uses email. There’s only two choices to communicate with your customers/victims: use email or create a service portal. They each have pros and cons. Starting with email doesn’t mean you’ve ruled out creating a portal later on, because in a case such as this, if you build it, they will come (if everything’s working properly).
Malfunctioning malware isn’t rare. It’s possibly evidence of nothing more than a bug in the code, a design flaw, or issues with supporting infrastructure. It’s typically not enough evidence for us to attribute anything in particular.
Decryption of files is not possible.
For many reasons. We’ll get into that below.
To be honest, who knows. It’s evidence of a mess, and we’re still working to untangle all the knots. It’s time-consuming.
This line of questioning is getting us nowhere. Let’s move on.
Yes and no. As you might have guessed from above, part of it most certainly isn’t sophisticated. But… part of it is. We’ve identified three main components. Two of them are pretty shoddy and seem kinda cobbled together. But the third component, the bit that allows the malware to spread laterally across networks, seems very sophisticated and well-tested.
Kinda. You probably can see why we’re trying not to rush to any judgements (we hope!). For the sake of this post, let’s call these three components “user mode component”, “network propagation component”, and “MBR component”. Here’s a diagram.
Aha! So here’s the interesting bit. It appears to be well designed, well tested,
and there’s evidence that development on the network propagation component was completed in February ². The network propagation module was probably already in development in February. ²
Update: see below ².
“We won’t be able to determine the timestamp for the use of NSA tools since it’s part of the main DLL code which has the June timestamp.” ²
“Also, in this particular Petya sample, the shellcode is in a way coupled with the exploits. That is, they didn’t simply plug the shellcode in without properly testing it with their version of the SMB exploit.” ²
February is many weeks before the exploits EternalBlue and EternalRomance (both of which this module utilizes) were released to the public (in April) by the Shadow Brokers. And those exploits fit this component like a glove.
Note: this isn’t rock solid evidence, but it’s far more compelling to us than any of the other reasoning we’ve seen so far.
WannaCry clearly picked these exploits up after the Shadow Brokers dumped them into the public domain in April. Also, WannaCry didn’t do the best job at implementing these exploits correctly.
By comparison, this “Petya” looks well-implemented, and seems to have seen plenty of testing. It’s fully-baked.
Here’s our theory. WannaCry, again.
WannaCry burst onto the scene in May, and started trashing up the joint, causing everyone to scramble to patch SMB vulnerabilities. Microsoft even patched XP! The result of this was a sudden drop in effectiveness of carefully crafted network propagation components (such as the one we’re talking about here). Whatever project these guys were working on, suddenly got its deadline adjusted. And hence everything else was done in a bit of a hurry.
Kaspersky Lab pointed to a Ukraine-based watering hole, and it turns out the MBR component was actually pushed out via that site in late May, post-WannaCry. We feel this might also be consistent with an “adjusted” deadline.
Less and less so. We don’t think any current attribution is rock solid (attribution never really is). We feel this is definitely worth deeper investigation. And more pizza.
We’ve changed our minds on some of our earlier conclusions. Please note this if you’re reading any previous F-Secure analysis. And, of course, this is subject to further revision, as new facts come to light.
As we mentioned earlier, two of the components in this malware are quite shoddy. Here are some interesting/confusing things we found.
The generated “personal installation key” displayed on the MBR version of the ransom page is 60 bytes of randomly generated data. This wouldn’t be a problem if it were sent upstream to the attacker, as a customer ID, but it isn’t (there’s no C&C functionality at all). It’s basically a placeholder that makes the ransomware look legit.
Why the authors of this malware failed to add proper decryption functionality to the MBR lock screen is still a question. Was it intentionally left out, did they make a huge mistake, or did they run out of time?
One of our analysts noted that implementation of the Elliptic curve Diffie–Hellman functionality necessary to enable proper encryption-decryption services in the MBR portion of the malware would take upwards of a week. If the developers were in a hurry, this could be one of the reasons why they opted for the “illusory” functionality we’re seeing.
This malware encrypts files on the user’s system and then, if it can elevate to admin, rewrites the MBR and reboots into a lock screen. Why encrypt files on the machine if you’re going to ultimately render the whole machine unusable? The user-mode encryption step is actually a fallback mechanism for if the malware can’t attain admin rights, which it would need to modify the MBR and execute that phase. Essentially, it’s a way of increasing the author’s chances of receiving a payment.
In cases where the malware fails to elevate, and only encrypts files in user-mode, a ransom note is left for the victim. This ransom note contains a different, much longer key than the one seen in the MBR lock screen. We’re currently looking into whether that key is generated in a way that might allow decryption to happen¹.
This malware also does other stuff that indicates poor testing practices. For instance, a machine infected with this malware can re-infect itself via one of its own propagation mechanisms. In this case, user-mode encryption will run a second time (most likely with elevated privileges), making decryption impossible.
If this malware finds running Kaspersky processes on the system, it writes junk to the first 10 sectors of the disk, and then reboots, bricking the machine completely.
We know of victims who don’t use M.E.Doc and have no obvious connections to Ukraine. Yet they were infected during Tuesday’s outbreak. This mystery is one of the factors that have kept us from jumping on the conspiracy train. And we still don’t have answers here.
¹ Edited on Thursday
We’ve confirmed that the user-mode encryption-decryption logic is functional and does work. Details here.
² Edited on Friday
See also our latest posts on the subject:
Some of the payloads utilized by the network propagation component have compilation timestamps from February 2017. The compilation dates on these payloads don’t have any bearing on when the Eternal* exploits were implemented in the network propagation code.