Petya Ransomware cyber attack is spreading across the globe – Part 2

Following our first blog providing an early analysis about Petya, we are sharing further findings of the malware analysis that we have performed. We divided this post into the three areas we have briefly analyzed after the Petya attack: the propagation techniques of the malware, the encryption techniques used, and how to detect it.

Propagation: Exploit
It seems that might be using exploits to propagate itself (EternalBlue). In addition to EternalBlue and EternalRomance, it uses DoublePulsar to inject DLLs from kernel-mode.Furthermore, the payloads are XOR’d with a static 0xCC key, as shown here:


To find exploitable targets, Petya enumerates peers of the infected machine and other network resources.


Propagation: Stolen credentials

The malware uses different methods to steal credentials from the infected machine. One of the techniques used to steal credentials is using CredEnumerate API:


After enumerating all credentials, the malware verifies if they are valid or not:

Immediately after, it tries to connect to those targets using the PsExec / WMIC methods mentioned in the previous post.

The ransomware also uses what we believe is a reduced version of Mimikatz to retrieve passwords from memory. Using these passwords, the malware will attempt to spread on the network by using the Windows tool psexec. We found multiple similarities between the tool and the Mimikatz source code, such as:

Original Mimikatz source code
            *pPeb = *RtlGetCurrentPeb();
            status = kull_m_memory_copy([...]);

Decompiled tool source code
if ( v5 ) {
    if ( v5 == 1     && NtQueryInformationProcess([...]) >= 0 && ReturnLength == 24
      && v10 ) {
      v13 = v10;
      v16 = read_n_write_process_memory(&v11, &v13, 0x10u);
    v7 = RtlGetCurrentPeb();

Original Mimikatz source code
#define KULL_M_WIN_MIN_BUILD_2K3    3000
#define KULL_M_WIN_MIN_BUILD_7      7000
#define KULL_M_WIN_MIN_BUILD_8      8000
#define KULL_M_WIN_MIN_BUILD_BLUE   9400
if(cLsass.osContext.BuildNumber < KULL_M_WIN_MIN_BUILD_2K3)                       
    helper = &lsassEnumHelpers[0];                
else if(cLsass.osContext.BuildNumber < KULL_M_WIN_MIN_BUILD_VISTA)                        
    helper = &lsassEnumHelpers[1];                
else if(cLsass.osContext.BuildNumber < KULL_M_WIN_MIN_BUILD_7)                        
    helper = &lsassEnumHelpers[2];                
else if(cLsass.osContext.BuildNumber < KULL_M_WIN_MIN_BUILD_8)                        
    helper = &lsassEnumHelpers[3];                
else if(cLsass.osContext.BuildNumber < KULL_M_WIN_MIN_BUILD_BLUE)
Decompiled tool source code
if ( dword_95CD74 >= 3000 ){ # -> KULL_M_WIN_MIN_BUILD_2K3
    if ( dword_95CD74 >= 5000 ){ # -> KULL_M_WIN_MIN_BUILD_VISTA
        if ( dword_95CD74 >= 7000 ){ # -> KULL_M_WIN_MIN_BUILD_7
            if ( dword_95CD74 >= 8000 ){ # -> KULL_M_WIN_MIN_BUILD_8
              v2 = &unk_959CC4;
              if ( dword_95CD74 >= 9400 ) # -> KULL_M_WIN_MIN_BUILD_BLUE



here are more examples of matching functions and similar structure, but the authors made some modifications to the Mimikatz source code as well, such as invoking some functions dynamically by using GetProcAddress.

They also added some new features. For example, they added the possibility to use named pipes to retrieve the stolen passwords found by the tool from the main thread of the malware. The named pipe can be used as an argument when invoking the password recovery tool so that the tool can share the retrieved passwords:

      v2 = CreateFileW(lpFileName, 0xC0000000, 0, &SecurityAttributes, 3u, 0, 0);
      if ( v2 != -1 )
      v5 = GetModuleHandleW(L"kernel32″);
      v6 = GetProcAddress(v5, "GetLastError");
      if ( v6() == 231 ){
            if ( !WaitNamedPipeW(lpFileName, 0xBB8u) )
                  return v2;
}while ( v1 );


The malware uses two different techniques to ransom the machine.

While the system is running each file is encrypted by mapping a view of it in memory, encrypting it, then flushing to disk, i.e. it doesn’t use the standard ReadFile / WriteFile APIs, possibly to avoid basic behavioral detections.


It is important to note that this stage will always encrypt files, no matter if admin privileges are granted or not:



If the malware is executed with admin credentials, it will overwrite the MBR (Master Boot Record).

Afterward, the computer is rebooted in a random amount of time, by scheduling a “shutdown /f /r” task, as shown below:


Which results in a scheduled task, similar to this one:



After the system (with overwritten MBR) is rebooted, and the ransomware will begin its stage two (16-bit stage). During this stage, the ransomware will encrypt the MFT (Master File Table):



In order to be able to detect this sample, we provide a Yara rule based on the samples spread during last days:

rule petya_eternalblue : petya_eternalblue {
        author      = "blueliv"
        description =  "Based on spreading petya version: 2017-06-28″
        /* Some commands executed by the Petya variant */
       $cmd01 = "schtasks %ws/Create /SC once /TN \"\" /TR \"%ws\" /ST %02d:%0″ wide
       $cmd02 = "shutdown.exe /r /f" wide
       $cmd03 = "%s \\\\%s -accepteula -s" wide
       $cmd04 = "process call create \"C:\\Windows\\System32\\rundll32.exe \\\"C:\\Windows\\%s\\\" #1″ wide
       /* Strings of encrypted files */
       $str01 = "they have been encrypted. Perhaps you are busy looking" wide
        /* MBR/VBR payload */
        $mbr01 = {00 00 00 55 aa e9 ?? ??}
        all of them

Dark Commerce

Exploring the cybercrime industry and its business models: part 1

Read free report
Demo Free Trial MSSP