So, in our opinion, a special operation was conducted in Ukraine by some special service of a certain state, the main purpose of which was to demonstrate the possibility of turning the world economy into a "radioactive ash", using cyber weapons. And the secondary goal was to harm Ukraine's policy and economy.
Cui Prodest?
Let everyone decide for themselves. Why exactly the following conclusions have been made? Let's look at the facts of what was Ukraine attacked with.
The Petya ransomware virus strain got into an AV lab in 2016 and was successfully described by our sequencing (Malware family). Leaping ahead, I would like to mention that commercial companies protected by our AV solutions were not affected by this plague.
In the morning of June 27, 2017, a massive infection of the computer networks of state and commercial organizations began. In 5-6 hours, up to 30% [2] companies of various forms of ownership were affected. On this day, we received the first samples of the new, as we at first thought, strain of the virus Petya.
As a result of the virus code analysis, the specialists of our company identified the following facts and factors of the malware functioning (the following is a purely technical part, non specialists can skip it).
There are three modifications of the virus (connected to its appearance):
-Red Petya is the first variation (version) that was overcome due to there was an error / crash in the implementation code of the Salsa20 algorithm made by the programmers that caused its cryptostrength lower hugely, allowing gaining access to the code.
The point was that the crypto vector used was reduced by the compiler exactly twice, which led to a 16 bit values "rotation" instead of 32 bit ones. As a result, significant bits of the cryptokey were only even. Other mistakes were made, what allowed using the genetic algorithm to calculate the crypto key in 30 seconds.
- Green Petya is the second implementation (version), which fixed the previous "bug" in the code. However, as it turned out, not all code issues were fixed and there was an error in translating LittleEndian -> BigEndian, which reduced cryptostrength. It took three days to get the cryptokey.
- Golden Petya is the latest of implementations (versions), which attacked the information systems on July 17, 2016. This version has this bug fixed. Moreover, the "Sigma" value, which is used to initialize the encryption matrix, has also been modified.
The first superficial study of the virus showed that this product is trying to mimic Petya. Careful study led our team to a conclusion that attempts to write a virus, similar to Petya, were made seem unprofessional deliberately. We specifically highlight this statement, since we believe that in doing so, the message has been sent to the world community.
So, the first piece of news:
When certain processes are found in the memory, a virus instead of installing an encryptor into the boot sector simply destroys the boot sector on it. This can be seen by the following feature: perfc_1 (the entry point) executes within itself the InitProcess, which in turn performs FindoutSomeProcesses, this function calculates hashes of the process names. A flag is displayed if some of them are present. This flag affects behavior:
if ( !(badFlag & 8) || (result = InstallEncryptor()) != 0 )
result = CorruptVolume();
That is if there is some process or setup error, first 10 sectors are filed up with litter.
Second piece of news:
The virus assumes that it will receive enough privileges by using "nuclear" exploits but with a lack of rights, it still tries to do harm by encrypting files on the disk. As it turned out, it carefully places the file README.TXT in the disk root directory or near to its location, where, as it turned out, the key to encrypt (in text format) files gets into. It can also be found in the binary form in the body of the trojan:
.text:10001BF3 03C push offset pszString "MIIBCgKCAQEAxP/VqKc0yLe9JhVqFMQGwUITO6W"...
.text:10001BF8 040 call edi ; CryptStringToBinaryW
.text:10001CC9 034 push dword ptr [esi+14h] ; hKey
.text:10001CCC 038 call edi ; CryptExportKey
.text:10001CCE 020 test eax, eax
.text:10001CD0 020 jz short loc_10001D21
.text:10001CD2 020 mov esi, ds:CryptBinaryToStringW
.text:10001CD8 020 lea eax, [ebp+pcchString]
.text:10001CDB 020 push eax ; pcchString
.text:10001CDC 024 push ebx ; pszString
.text:10001CDD 028 push 1 ; dwFlags
.text:10001CDF 02C push [ebp+pdwDataLen] ; cbBinary
.text:10001CE2 030 mov [ebp+pcchString], ebx
.text:10001CE5 030 push [ebp+pbBinary] ; pbBinary
.text:10001CE8 034 call esi ; CryptBinaryToStringW
Since the key is used symmetrically, it can both encrypt the files and decrypt them but this happens provided that the final part of the encryption (in the boot sector) is not executed.
Third piece of news:
As already has been mentioned, there are many bugs in the code, some of which are:
1. Windows must be installed on the C: drive.
2. If there is a file C: \ Windows \ perfc.dat, the Trojan will not replicate and, as a result, the computer will not be infected.
Fourth piece of news:
We have long been curious about why random numbers are used for the two necessary keys to decrypt files, since under the rules of asymmetric encryption, to obtain a decent cryptokey a key tied to a common public key must be transferred to the server. But as it turned out, the data that are copied from the main part into the boot sector is just a fiction. At first, we supposed that the work of the cryptographic algorithm was in the boot sector but there was not much space for that.
Having examined the arguments mentioned in the article https://securelist.com/petya-the-two-in-one-trojan/74609/ once again, we understood that we didn’t have enough data to draw the final conclusion so we decided to analyze the performance of the new Petya. Surprisingly, the detailed analyses showed that this was a kind of Golden Petya remodelled as Red Petya and, moreover, with clipped elements included.
Conclusion:
1. The part of the code/ code location responsible for ‘skull’ drawing is cut off, as this can be seen from the function below:
seg000:86E0 PrintSkuLLAndWait proc near; CODE XREF: MainWindow+6p
seg000:86E0
seg000:86E0 var_1 = byte ptr -1
seg000:86E0
seg000:86E0 000 enter 4, 0
seg000:86E4 006 push si
seg000:86E5 008 xor si, si
seg000:86E7 008 mov [bp+var_1], 0
seg000:86EB 008 jmp short @@SkipSkuLL
seg000:86ED ; ---------------------------------------------------------------------------
seg000:86ED 008 call GetTimeOfDay
seg000:86F0 008 lea cx, [si+1]
seg000:86F3 008 cmp ax, cx
seg000:86F5 008 jbe short loc_8715
seg000:86F7 008 mov si, ax
seg000:86F9 008 cmp [bp+var_1], 1
seg000:86FD 008 jnz short loc_8703
seg000:86FF 008 mov al, 0C0h ; 'L'
seg000:8701 008 jmp short loc_8705
seg000:8703 ; ---------------------------------------------------------------------------
seg000:8703
seg000:8703 loc_8703: ; CODE XREF: PrintSkuLLAndWait+1Dj
seg000:8703 008 mov al, w_red
seg000:8705
seg000:8705 loc_8705: ; CODE XREF: PrintSkuLLAndWait+21j
seg000:8705 008 push ax
seg000:8706 00A call PrintSkuLL
seg000:8709 00A pop bx
seg000:870A 008 cmp [bp+var_1], 1
seg000:870E 008 sbb al, al
seg000:8710 008 neg al
seg000:8712 008 mov [bp+var_1], al
seg000:8715
seg000:8715 loc_8715: ; CODE XREF: PrintSkuLLAndWait+15j
seg000:8715 008 call CheckFroKeyPresed
seg000:8718 008 or al, al
seg000:871A 008 jz short loc_86ED
seg000:871C
seg000:871C @@SkipSkuLL: ; CODE XREF: PrintSkuLLAndWait+Bj
seg000:871C 008 push w_red ; color
seg000:871E 00A call ClearScreenAndSetCursor
seg000:8721 00A pop bx
seg000:8722 008 pop si
seg000:8723 006 leave
seg000:8724 000 retn
seg000:8724 PrintSkuLLAndWait endp ;
As you can see, the unconditional transfer (86EB) is represented in the way it will never be rendered.
Any experienced investigator will immediately notice that compiler would simply omit this code location if this code was written by authors of the original Petya version. In this particular case, this tells us that the code was changed by third parties that didn’t have the source code. That’s why they modified a binary code of Petya ransomware.
2. The function parameter, responsible for the color change, is corrected in some areas. In that way, after successfully entering the key, the screen should turn yellow, same as Gold Petya.
However, in other places, the color was changed to red.
3. Shortly, the name of the game is that those who launched it never wanted data recovery. Let’s turn to the article https://securelist.com/petya-the-two-in-one-trojan/74609/ once again. Here we see that inside of so-called Onion Sector four parameters are rendered, the last of which is ec_data. Here, without going deep into cryptography much, we can say that this is the basis for the disk recovery. Without these data, the extortion server will never reset the disk password.
Now then, there always were zeros in this very place, and the key that the "extortionists" give out for the personal encryption key and which was formed on the basis of cryptographic operations in previous versions, is now formed according to a simplified program:
.text:100015AC 9AC push 3Ch ; dwLen
.text:100015AE 9B0 lea eax, [ebp+personalKey]
.text:100015B4 9B0 push eax ; pbBuffer
.text:100015B5 9B4 call GenerateRandom
We may conclude that no one was up to make data recovery process, and the attackers, apparently, did not set this goal, or may it be a huge malware bug?
4. 4. Finally, the "Sigma" table includes the values from Petya Gold:
seg000:96DA 01C mov [bp+var_11], 31h ; '1'
seg000:96DE 01C mov [bp+var_10], 6Eh ; 'n'
seg000:96E2 01C mov [bp+var_F], 76h ; 'v'
seg000:96E6 01C mov [bp+var_E], 61h ; 'a'
seg000:96EA 01C mov [bp+var_D], 6Ch ; 'l'
seg000:96EE 01C mov [bp+var_B], 64h ; 'd'
seg000:96F2 01C mov [bp+var_A], 20h ; ' '
seg000:96F6 01C mov [bp+var_9], 73h ; 's'
seg000:96FA 01C mov [bp+var_8], 33h ; '3'
seg000:96FE 01C mov [bp+var_7], 63h ; 'c'
seg000:9702 01C mov [bp+var_6], 74h ; 't'
Summarizing information mentioned above, we conclude the following:
- There is no recovering mechanism for the encrypted data and the attackers didn’t aim to do this.
- A part of the code was developed unprofessionally.
3. The decompiler has been used. We have found enough facts to say that this code was borrowed.
Skipping the technical part and going over to analysis, we may construe that the "writers" were in a big hurry concerning writing of the code, which means that the malware "release" time was reduced, and there was the task to "release" the malware by a specific date.
If we have a look at the calendar, we will see that the major global upcoming event is G-20 summit which begins on July 7, and during which a meeting between executive heads of the nations of the United States and Russia is very likely to take place.
Applying a small historical excursus, a little funny story comes up, which I’d like to mention: French President Charles de Gaulle visited the USSR in 1966 and Leonid Brezhnev showed him the launch of an intercontinental ballistic missile. There was a special operation known as ‘Palm-1’. ‘Is there the same missile aimed at Paris?’ supposedly asked dismayed De Gaulle. Brezhnev smiled and hastened to ‘comfort’ the general: ‘Do not worry, not this one…’
This special operation resulted in withdrawing France from the NATO military organization by de Gaulle's decision in the same year and moving the NATO headquarters from Paris to Brussels.
Proceeding to our topic, based on the logic of the work of standard antiviruses currently having maximum world-wide distribution, the virus writers knew that this epidemic would be stopped during a period of time from 4 hours to 2 days. Leading anti-virus vendors need this time for writing signatures and updating relevant databases.
Virus writers could evade the block for spreading malware by code translation, but they did not do that.
According to information from https://labsblog.f-secure.com/2017/06/29/petya-i-want-to-believe/, used exploits had been purchased in February 2017 that is before Shadow Brokers put these codes in free access. This suggests that the developers or their bosses spend substantial sums of money stated in hundreds of thousands of dollars.
The developers of the malware follow the algorithm of software development and it’s clear that some areas of the code responsible for the files distribution and encryption are developed competently, but the area that is responsible for the malware monetization is performed defiantly unprofessional.
The facts mentioned above demonstrate that we ran into a virus written by a group of professionals with no funding limitations. This suggests that cashing was just a smokescreen for this attack. There were no efforts made to make a little secret of it.
There is only one case in which this situation looks quite reasonable - if this is an open threat from the Russian special services to the world community. Upon that, the grounds of Ukraine haven't been chosen accidentally. On the one hand, Putin "punishes" Ukraine for its disruptive behavior, on the other hand, it allows the global antivirus industry to prepare for this attack and prevent its serious spreading in other territories. The absence of the crypto code replacement by its repacked derivatives also points out this fact, as far as the implementation of the malware repacking mechanism would prevent antivirus companies from stopping this infection, which might lead to the collapse of the global economy.
The fact that malware writers initially implemented mechanisms to exclude the spread of malware is proven by this text - 98% sure that the name is is perfc.dll Create a file in c: windows called perfc with no extension and #petya #Nopetya will not run! Having tellingly launched this virus into Ukrainian information networks, Russia demonstrates that it has been prepared for the next round of the hybrid war. In the face of threats from the international community to strengthen sanctions against Russia, for example, by excluding their banking system from Swift, Putin or his associates can report that a group of patriotically-minded hackers, of course, that have nothing to do with government services in Russia, are able to completely crash the world's economic system out of their patriotic feelings.
Can anyone really make this threat? Unfortunately, such a scenario is possible and this statement does no longer sound as science fiction. Let's hypothetically consider the attack by such a virus - let's call it MegaTsarBomb. It takes an algorithm of this given attack and fixes all the bugs from the virus. Here's what, theoretically, we get:
- Distributed MegaTsarBomb will be repacked every 10 minutes. This will knock down the static signature of most antivirus products.
- 0-day exploits, that are both developed by attackers in their own labs and purchased on the black market, will be used.
- The entry point, with which the distribution of MegaTsarBomb will begin, will not be one, as in the case of Ukraine, but there will be tens of thousands of them.
- MegaTsarBomb will NOT bother itself with file encryption. It will simply irretrievably delete the files and "kill" the machine, the so-called screen of death.
- The recent case of South Korean hosting company paying $ 1 million shows that Linux servers are also prone to data infection by the encryptor and, hence, there will be the Linux version of MegaTsarBomb.
In case of such an attack, based on the statistics received in Ukraine [2], it can be assumed that up to 30% of all computer networks in the world will be infected, which will lead to a clear collapse not only of the world economy, but also to a full over-arching information chaos with all its consequences.
So, if someone at the G-20 Summit would be at risk of being turned off from Swift, if bad behaved, this one can show a photo on their smartphone with a few pretty, skinny girls with a poster - Do not make our MegaTsarBombs laugh.
The report was prepared by the Romad Cyber Systems Inc. Analytics Department
P.S. In the next article, we will address the issue of restoring information systems after such attacks, and we will focus on the issue of how to prevent and block similar attacks on your information systems, we will also describe the methods and means with which decent information protection is possible to be achieved.
[1]. Khromova E.B. Charles de Gaulle in USSR: the anniversary of the visit in 1966. Bulletin of Perm National Research Polytechnic University. Culture. History. Philosophy.Law. 2016. No. 3. Pp. 30-40.
[2]. https://forum.pravda.com.ua/index.php?topic=971772.0;viewresults