
Petya: “I Want to Believe” - r721
https://labsblog.f-secure.com/2017/06/29/petya-i-want-to-believe/
======
INTPenis
About robust components being developed in February; couldn't that just mean
that it's a sort of pre-made malware or "malware framework" being used to
deploy these two exploits?

I'm thinking that the malware world develops code on the same level as the
rest of the coding world. So developing a robust MBR and network component
that can use drop-in exploits would make sense.

~~~
taneq
That's basically my reading: Some script kiddy got hold of spook-grade malware
and tried to mod it.

~~~
gozur88
This. I don't get the impression people who set up ransomware typically write
all or even very much of the virus. They cobble together bits and pieces from
the web, writing only the portion they couldn't find.

Seems like the tough part would be setting up the whole chain such that you
actually wind up with money in your own bank account without also setting up a
big neon Arrest Me financial trail.

------
mariusmg
" For instance, a machine infected with this malware can re-infect itself via
one of its own propagation mechanisms"

Not even malware gets proper QA these days....

------
shroom
I am an average web developer and I have sound computer and programing skills.
I'm interested in computer security and always fascinated by these articles.

When I read stuff like "Petya (binary edited)" I feel like a complete noob.
Anyone care to elaborate how editing binaries would be done?

Sounds like a daunting task. Even on a normal program. Much more so on malware
that is obfuscated to begin with. Just curious :-)

~~~
simias
I don't find your quote in the original article, where is binary editing
mentioned?

At any rate in general it just means that the binary version is directly
modified instead of, say, modifying the source and recompiling it. When the
source is not available you don't really have a choice.

It doesn't mean however that you'll just open a big binary dump of the program
in emacs and start flipping bits manually. In general you'll first disassemble
the code to figure out what it does, isolate the part that you want to modify,
implement the modification and then you end up with a binary patch.

That's easier said than done though, reverse engineering a complex binary is
very time consuming.

It reminded me of this anecdote:
[https://en.wikipedia.org/wiki/Wing_Commander_%28video_game%2...](https://en.wikipedia.org/wiki/Wing_Commander_%28video_game%29#Development)

>As development for Wing Commander came to a close, the EMM386 memory manager
the game used would give an exception when the user exited the game. It would
print out a message similar to "EMM386 Memory manager error..." with
additional information. The team could not isolate and fix the error and they
needed to ship it as soon as possible. As a work-around, one of the game's
programmers, Ken Demarest III, hex-edited the memory manager so it displayed a
different message. Instead of the error message, it printed "Thank you for
playing Wing Commander."

~~~
mariusmg
>reverse engineering a complex binary is very time consuming.

And still ppl who crack games do it very often. They start with a obfuscated
binary, decrypt it and patch it to remove the protection.

~~~
Filligree
That's not full reverse engineering. They're removing the protection, with a
clearly defined goal they can look at to see if they're done, and that's all.

Very different from trying to figure out everything a program does.

~~~
Forge36
In the case of peyta: is that necessary? There are 2 pieces I know of someone
would want to change, the Bitcoin wallet and removing the Killswitch.

Surely this is easier then a full understanding of the code?

------
amq
Honestly, quite a poor write-up. Bold claims in the beginning, but then too
many meaningless words and too little technical details.

~~~
smoyer
Yes ... there's no content here so don't waste your time reading it.

------
etiam
The followup has arrived: [https://labsblog.f-secure.com/2017/06/30/eternal-
petya-from-...](https://labsblog.f-secure.com/2017/06/30/eternal-petya-from-a-
developers-perspective/)

~~~
smoyer
Same lack of facts as the first article but with new and improved speculation.

~~~
waihtis
Speculation is all there is to this incident. Would you rather have them pose
speculation as facts like many other vendors are doing?

------
robryk
> There’s only two choices to communicate with your customers/victims: use
> email or create a service portal.

What about "have them publish a specially crafted transaction in Bitcoin
blockchain using provided software"?

------
EGreg
Followup: [https://labsblog.f-secure.com/2017/06/30/eternal-petya-
from-...](https://labsblog.f-secure.com/2017/06/30/eternal-petya-from-a-
developers-perspective/)

~~~
jaclaz
Interesting, thanks, but still more questions than answers and a somewhat
condescending or at the opposite (as some other HN readers noted previously)
somewhat "high school" trying to put together something that the teacher would
approve, "Here we establish ..." ?.

------
e9
"It has a vendetta against Kaspersky Lab. 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."

lol

~~~
jaclaz
To me it doesn't sound much as a vendetta.

Basically - if I get right the note - if you have some Kaspersky Lab software
running the malware ONLY writes junk to the first 10 sectors and reboots,
which basically means:

1) on MBR rebuild the MBR partitiontable entries from the existing (untouched)
partition/volumes on disk

2) on GPT restore the partition table from the backup

Both are perfectly doable to restore the system in a full working condition.

It sounds more like a sort of (indirect) "vaccine", instead of getting a
deadly influence, you get just a cold, a couple of aspirins and all is well
(and the malware cannot spread from that machine to other machines on the
network, since it rebooted to the _junk_ and the OS is not running anymore).

~~~
masswerk
As I read it, first there's user-mode encryption in every case. Then, admin-
mode is attempted, and, when successful, either the first 10 sectors including
the MBR are overwritten by garbage, in case Kapersky software was found, or
there's a botched attempt to encrypt the first 25 disk sectors. Mind that
user-mode and admin-mode tasks are apparently in separate modules and that the
user-mode module is run first, while detecting the Kapersky lab process and
overwriting the disk sectors requires admin mode.

To me, the "Kapersky branch" appears to be more destructive than the default
branch.

Edit: Also, there have been reports of the malware scanning and transmitting
any credentials stored on the machine, while in "encrypted mode." (Suggesting,
there's still a functional basic system left in order to accomplish these
tasks.) Couldn't it be for Kapersky AV still being able to detect this
activity and hence rather bricking the machine than giving away some of the
features early?

~~~
qb45
Certainly more destructive for the 99.9% of owners who don't know what MBR or
GPT is.

~~~
jaclaz
I don't get it, really, IF data can be recovered through a procedure (that BTW
is not particularly difficult or new, even if the owners don't know what a MBR
or a GPT is, _any_ technician can recover a disk where only the first 10
sectors were filled with junk) the procedure is NOT destructive at all while
encrypted files, particularly if encrypted with a "good enough" and "random"
key are not recoverable at all.

Of course it may provoke delays/problems/whatever, but data is still there.

If the sequence is:

1) encrypt user files

2) get admin access and crypt MBR (in such a way that is not decryptable)

3) reboot

the "destructive part" is #1, the MBR can be rebuilt from scratch just fine
(and possibly if the reboot is somehow prevented the encryption key may be
recovered from RAM as it happened in some cases for Wannacry, in which case it
is #3 that creates more damage).

The doubt is when the "Kaspersky vendetta happens", if it goes:

1) encrypt user files

2) get admin access and crypt MBR and 24 more sectors(in such a way that is
not decryptable) OR check the presence of Kaspersky and write junk to first 10
sectors of disk

3) reboot

It doesn't anyway change anything, there is no real difference between
rebuilding a MBR (or GPT) because it was crypted and rebuilding it because it
was overwritten by junk data, but once you have rebuilt it, if the files are
encrypted you have lost them all the same.

------
bsaul
This post really reads like high school students trying to write something
that looks professional...

I hope this field doesn't get too poluted by people looking for a thrill. The
stakes start to be too high for that.

~~~
albedoa
I can't believe this was published. It reads like someone attempting to _mock_
a high school student who tries to write something professional.

------
matthewaveryusa
I find all of this absolutely hilarious. "this is not nation state because it
is written in a shoddy way" is akin to "he does not look like a spy because
he's too stupid." Get out. Attribution is almost impossible so don't even try.

"It's sometimes the height of wisdom to feign stupidity.” -Cato 149 B.C.
(that's right, people knew about this simple trick before Jesus was born, you
bet humanity has refined on it since)

~~~
count
Attribution is not 'almost impossible', it just takes human intelligence
sources, and not technology, to get an accurate attribution. And due to the
nature of those sources, those who get the actual attribution won't disclose
it.

~~~
heartbreak
Exactly. This is like the people who said it was impossible to attribute the
DNC email hack. Then they attributed it via classic human intelligence
sources.

We forget there's more to attribution than what can be determined from the
bits.

------
nenreme
> there’s evidence that development on the network propagation component was
> completed in February.

Yet no evidence is provided. Why would they want to hide it?

~~~
r721
They just added another update:

"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."

[https://twitter.com/FSLabs/status/880688502769414144](https://twitter.com/FSLabs/status/880688502769414144)

