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’re against being sucked up into group think, so we’ve stepped aside, and tried to apply some healthy skepticism. 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.
Pizza: the lunch of champions!
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.
“Can it even be ransomware if it doesn’t have a good payment pipeline?”
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).
So, is everything working properly?
No.
Aha! So that’s evidence of it not being ransomware, right?
No.
But why?
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.
So what doesn’t work?
Decryption of files is not possible.
Why?
For many reasons. We’ll get into that below.
Many reasons? So there’s lots of bugs? Isn’t that evidence that it’s not real ransomware?
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.
Nation state malware is advanced and sophisticated, right? Is this sophisticated?
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.
So it’s a paradox then?
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.
Bad handwriting by yours truly (Andy).
So what’s the deal with this “sophisticated” part?
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.
What’s interesting about that?
February is many weeks before the exploits EternalBlue and DoublePulsar (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.
How does it compare to WannaCry (which also used these exploits)?
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.
So, if the network propagation component is fully-baked, why aren’t the other two?
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.
Do you have anything else to add to your timeline?
Kaspersky Labs 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.
So, can you sum this up for us?
- January 2017. The Shadow Brokers advertised an “auction” which revealed the names of all the exploits they had for sale.
- The NSA, upon noticing their exploits being advertised, hurriedly contacted Microsoft (reportedly with hat in hand), and owned up to their shenanigans.
- February 2017. Microsoft then had a very busy patch cycle and actually missed a patch Tuesday that month.
- Meanwhile, “friends of the Shadow Brokers” were busy finishing up development of a rather nifty network propagation component, utilizing these exploits.
- March 2017. Microsoft rolls out patches. Many fixes (to NSA-exploited vulnerabilities) made.
- April 2017. The Shadow Brokers dump a whole bunch of exploits into the public domain.
- Somebody with possible connections to North Korea notices.
- May 2017. WannaCry, ’nuff said.
- Either the “friends of the Shadow Brokers” had something they felt they needed to get done, and their deadline was stepped up because of WannaCry.
- Or they figured they could “join the party” as yet another ransomware, as long as they capitalized on it within a reasonable amount of time.
- The MBR component of this malware was alpha tested using a watering hole attack.
- June 2017. You are here.
Are you still skeptics?
Always.
But are you still skeptical about this malware being “nation state”?
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.
What other thoughts would you like to share?
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.
Petya user mode ransom note.
You can get infected multiple times.
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.
It has a vendetta against Kaspersky Labs.
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.
One final thing.
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.
Update:
We’ve confirmed that the user-mode encryption-decryption logic is functional and does work.
Tagged: APT, Crypto, Malware, NationState, Petya, Pizza, Ransomware, Th3 Cyb3r, WannaCry, WannaCrypt
Article Link: https://labsblog.f-secure.com/2017/06/29/petya-i-want-to-believe/