{"id":8212,"date":"2017-06-30T10:12:38","date_gmt":"2017-06-30T18:12:38","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2017\/06\/30\/news-1987\/"},"modified":"2017-06-30T10:12:38","modified_gmt":"2017-06-30T18:12:38","slug":"news-1987","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2017\/06\/30\/news-1987\/","title":{"rendered":"EternalPetya &#8211; yet another stolen piece in the package?"},"content":{"rendered":"<p><strong>Credit to Author: Malwarebytes Labs| Date: Fri, 30 Jun 2017 16:53:36 +0000<\/strong><\/p>\n<p>Since\u00a0June 27th we have been\u00a0investigating the outbreak of the <a href=\"https:\/\/blog.malwarebytes.com\/cybercrime\/2017\/06\/petya-esque-ransomware-is-spreading-across-the-world\/\" target=\"_blank\" rel=\"noopener noreferrer\">new Petya-like malware<\/a> armed with an infector similar to\u00a0WannaCry. Since day one, various contradicting theories started popping up. Some believed that this malware is a rip-off of the original Petya, while others think\u00a0that it is another step in Petya&#8217;s\u00a0evolution. However, those were just different opinions and none of them were\u00a0backed up with enough evidence to hold solid. In this post, we will try to fill this gap by making step-by-step comparisons of the current kernel and the one on which it is based (<a href=\"https:\/\/blog.malwarebytes.com\/threat-analysis\/2016\/12\/goldeneye-ransomware-the-petyamischa-combo-rebranded\/\" target=\"_blank\" rel=\"noopener noreferrer\">Goldeneye Petya<\/a>).<\/p>\n<h3>Why is it important to know whether or not the code was recompiled?<\/h3>\n<p>Answering this question and collecting enough evidence is crucial for further discussions on attribution. The source code of the original Petya has never been leaked publicly, so in case it was recompiled\u00a0it proves that the original Petya&#8217;s author, Janus, is somehow linked to the current outbreak (either this is his work or he has sold the code to another actor).<\/p>\n<p>In this analysis, we hope to identify if this malware could have\u00a0been the work of anyone with the appropriate skills to modify the compiled binary or not. Doing so would not entirely disprove\u00a0Janus as the creator, but his involvement\u00a0becomes less likely.<\/p>\n<p>Anyways, let&#8217;s take a look at the code.<\/p>\n<h3>Sectors<\/h3>\n<p>Looking at the sectors, we can find that the layout of EternalPetya is identical to Goldeneye. Full comparison:<\/p>\n<p><strong>Petya kernel:<\/strong><\/p>\n<ul>\n<li>Petya Goldeneye: sector 1<\/li>\n<li>Petya Eternal:\u00a0sector 1<\/li>\n<\/ul>\n<p><strong>Data sector:<\/strong><\/p>\n<ul>\n<li>Petya Goldeneye: 32<\/li>\n<li>Petya Eternal: 32<\/li>\n<\/ul>\n<p><strong>Verification sector:<\/strong><\/p>\n<ul>\n<li>Petya Goldeneye: 33<\/li>\n<li>Petya Eternal: 33<\/li>\n<\/ul>\n<p><strong>Original MBR (xored with 7)<\/strong><\/p>\n<ul>\n<li>Petya Goldeneye: 34<\/li>\n<li>Petya Eternal: 34<\/li>\n<\/ul>\n<h3>Hexadecimal comparison<\/h3>\n<p>Comparing both kernels at hexadecimal level, we can see tiny differences at various points. However, there are big portions of code that are identical in both.<\/p>\n<p>The screenshots below show fragments of the (current) EternalPetya on the left, and Goldeneye on the right.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18676\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/tiny_diffs.png\" alt=\"\" width=\"599\" height=\"265\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/tiny_diffs.png 599w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/tiny_diffs-300x133.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/tiny_diffs-195x85.png 195w\" sizes=\"auto, (max-width: 599px) 100vw, 599px\" \/><\/p>\n<p>Its\u00a0interesting that, at some point, the layout of the same strings in the memory was\u00a0shifted:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18673\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/texts_layout.png\" alt=\"\" width=\"628\" height=\"412\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/texts_layout.png 628w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/texts_layout-300x197.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/texts_layout-600x394.png 600w\" sizes=\"auto, (max-width: 628px) 100vw, 628px\" \/><\/p>\n<p>As mentioned, the data sector starts in both cases at the same offset. This sector stores the random Salsa20 key and nonce, which are generated per victim, and this is identical in both cases. However, in Goldeneye the victim ID is much longer, which is not surprising taking into the account the fact that in the past it was supposed to be the encrypted backup of the Salsa key, and now it is just an arbitrary string, so it&#8217;s length doesn&#8217;t really matter.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18675\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/data_sector_comparison.png\" alt=\"\" width=\"614\" height=\"507\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/data_sector_comparison.png 614w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/data_sector_comparison-300x248.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/data_sector_comparison-600x495.png 600w\" sizes=\"auto, (max-width: 614px) 100vw, 614px\" \/><\/p>\n<h3>The Bootloader<\/h3>\n<p>The first thing that struck\u00a0me as\u00a0different\u00a0was the bootloader. Fragment of the hexdump (as before: EternalPetya on the left, and Goldeneye on the right.):<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18677\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/bootloader_hex.png\" alt=\"\" width=\"606\" height=\"272\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/bootloader_hex.png 606w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/bootloader_hex-300x135.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/bootloader_hex-600x269.png 600w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/bootloader_hex-604x270.png 604w\" sizes=\"auto, (max-width: 606px) 100vw, 606px\" \/><\/p>\n<p>Functionality-wise, it is the same in both cases. It is supposed to read 32 (0x20) sectors from the disk, starting from sector 1, and load them into memory at the address 0x8000. However, the opcodes that are used in both cases to do the same operations are a bit different.<\/p>\n<p>This is the old bootloader, used in Goldeneye:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18670\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/golden_boot.png\" alt=\"\" width=\"771\" height=\"318\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/golden_boot.png 771w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/golden_boot-300x124.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/golden_boot-600x247.png 600w\" sizes=\"auto, (max-width: 771px) 100vw, 771px\" \/><\/p>\n<p>And this is the bootloader used in the EternalPetya\u00a0version:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18671\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/eternal_boot.png\" alt=\"\" width=\"790\" height=\"317\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/eternal_boot.png 790w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/eternal_boot-300x120.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/eternal_boot-600x241.png 600w\" sizes=\"auto, (max-width: 790px) 100vw, 790px\" \/><\/p>\n<p>My first impression upon seeing this was that the code was recompiled with different settings, however, another possibility also exists. The total length of the different\u00a0fragments are\u00a0the same &#8211; so, we cannot exclude the possibility that someone manually edited them inside\u00a0the pre-compiled\u00a0binary.<\/p>\n<h3>Optimizations &#8211; and why it matters<\/h3>\n<p>So far we&#8217;ve seen some interesting changes, but they were not enough to prove or disprove whether the code was recompiled. However, the breakthrough in the research may lie in the interesting observation made by <a href=\"https:\/\/twitter.com\/David3141593\/status\/880495627326640128\" target=\"_blank\" rel=\"noopener noreferrer\">David Buchanan<\/a>.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"550\">\n<p lang=\"en\" dir=\"ltr\">The Salsa20 Key expansion was modified using a hexeditor, NOT by modifying the source <a href=\"https:\/\/t.co\/Q06ZEle8k9\">pic.twitter.com\/Q06ZEle8k9<\/a><\/p>\n<p>&mdash; David Buchanan (@David3141593) <a href=\"https:\/\/twitter.com\/David3141593\/status\/880495627326640128\">June 29, 2017<\/a><\/p>\n<\/blockquote>\n<p><script async src=\"\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>His theory was based on compiler optimization, which ensures\u00a0that the same character will not need to be stored in the memory twice. We can see this rule applied in examining the code responsible for storing a string in the memory. Inside of\u00a0Goldeneye&#8217;s key expansion function, we can find that this kind of optimization absolutely happens &#8211; every character is unique, no character is loaded twice:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18666\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/explan_golden.png\" alt=\"\" width=\"450\" height=\"338\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/explan_golden.png 450w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/explan_golden-300x225.png 300w\" sizes=\"auto, (max-width: 450px) 100vw, 450px\" \/><\/p>\n<p>But in the corresponding fragment of the current kernel, we can find that this rule is broken. The character &#8216;d&#8217; repeats and optimization was not applied:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18681\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/d_repeated.png\" alt=\"\" width=\"600\" height=\"338\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/d_repeated.png 600w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/d_repeated-300x169.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/d_repeated-400x225.png 400w\" sizes=\"auto, (max-width: 600px) 100vw, 600px\" \/><\/p>\n<p>If the same code was\u00a0generated by a\u00a0compiler, this fragment would look identical\u00a0to other repeated characters:<\/p>\n<pre>mov al, 'd'  mov [bp+var_B], al  mov [bp+var_3], al  <\/pre>\n<p>This is a very strong argument against the theory of the code being recompiled. But anyway, let&#8217;s continue the analysis and see if we can find\u00a0even more evidence.<\/p>\n<h3>Closer look at the changes<\/h3>\n<p>In a\u00a0<a href=\"https:\/\/blog.malwarebytes.com\/threat-analysis\/2017\/06\/eternalpetya-lost-salsa20-key\/\" target=\"_blank\" rel=\"noopener noreferrer\">previous post<\/a> I presented a fast comparison of the current kernel vs Goldeneye, done with the help of IDA plugin, BinDiff:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18650\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/comparison.png\" alt=\"\" width=\"519\" height=\"736\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/comparison.png 519w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/comparison-212x300.png 212w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/comparison-423x600.png 423w\" sizes=\"auto, (max-width: 519px) 100vw, 519px\" \/><\/p>\n<p>We can see that significant modifications have\u00a0been made\u00a0only in the functions related to displaying the information screen. Let&#8217;s check how exactly these\u00a0changes have\u00a0been applied.<\/p>\n<h4>main_info_screen (offset 0x8426):<\/h4>\n<p>Changes of the main_info_screen pointed out by the BinDiff (left: current, right: Goldeneye):<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18683\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/main_info_diff.png\" alt=\"\" width=\"921\" height=\"165\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/main_info_diff.png 921w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/main_info_diff-300x54.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/main_info_diff-600x107.png 600w\" sizes=\"auto, (max-width: 921px) 100vw, 921px\" \/><\/p>\n<p>As we can see, the call to a function at 0x008848E was replaced with NOPs (No Operation). This is a common practice\u00a0used to remove an\u00a0unwanted function in case of patching compiled binaries. Yet, sometimes it can be also introduced by #Ifdefs. The rest of the code matches the previous version, even using the same offsets. However, the addresses to the displayed strings are different in both binaries:<\/p>\n<p>The unreferenced\u00a0function is still present in the current binary:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18686\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/patched_out_func.png\" alt=\"\" width=\"456\" height=\"108\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/patched_out_func.png 456w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/patched_out_func-300x71.png 300w\" sizes=\"auto, (max-width: 456px) 100vw, 456px\" \/><\/p>\n<p>&#8230;and called in some other places of code:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18689\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/current_graph.png\" alt=\"\" width=\"402\" height=\"345\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/current_graph.png 402w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/current_graph-300x257.png 300w\" sizes=\"auto, (max-width: 402px) 100vw, 402px\" \/><\/p>\n<p>Comparison to the Goldeneye&#8217;s call graph, it lacks one of the references, but the other ones are consistent:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18688\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/golden_graph.png\" alt=\"\" width=\"653\" height=\"324\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/golden_graph.png 653w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/golden_graph-300x149.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/golden_graph-600x298.png 600w\" sizes=\"auto, (max-width: 653px) 100vw, 653px\" \/><\/p>\n<h4>sub_86E0 (offset 0x86E0):<\/h4>\n<p>Another change is in the function itself, that is also a part of the information screen. It is not referenced from any other place in the code:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18691\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/called_from_main.png\" alt=\"\" width=\"409\" height=\"318\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/called_from_main.png 409w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/called_from_main-300x233.png 300w\" sizes=\"auto, (max-width: 409px) 100vw, 409px\" \/><\/p>\n<p>As we can see, it is called at the beginning of the function:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18692\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/called_from_main-1.png\" alt=\"\" width=\"509\" height=\"226\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/called_from_main-1.png 509w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/called_from_main-1-300x133.png 300w\" sizes=\"auto, (max-width: 509px) 100vw, 509px\" \/><\/p>\n<p>In the Goldeneye kernel, the corresponding function was the one responsible for <a href=\"https:\/\/www.youtube.com\/watch?v=mSqxFjZq_z4\" data-rel=\"lightbox-video-0\" target=\"_blank\" rel=\"noopener noreferrer\">printing the skull<\/a>:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18696\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/print_skull.png\" alt=\"\" width=\"341\" height=\"326\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/print_skull.png 341w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/print_skull-300x287.png 300w\" sizes=\"auto, (max-width: 341px) 100vw, 341px\" \/><\/p>\n<p>The first jump leads\u00a0to the loop responsible for displaying the skull and waiting for the key to be pressed by the user. Fragment of the code:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18697\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/loop_top.png\" alt=\"\" width=\"784\" height=\"483\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/loop_top.png 784w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/loop_top-300x185.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/loop_top-600x370.png 600w\" sizes=\"auto, (max-width: 784px) 100vw, 784px\" \/><\/p>\n<p>Looking inside the EternalPetya code, we are almost sure that this function was patched post-compilation, rather than recompiled. The first jump, that was supposed to lead to the loop leads directly to the function end:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-18695\" src=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/patched_func-1.png\" alt=\"\" width=\"862\" height=\"415\" srcset=\"https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/patched_func-1.png 862w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/patched_func-1-300x144.png 300w, https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/patched_func-1-600x289.png 600w\" sizes=\"auto, (max-width: 862px) 100vw, 862px\" \/><\/p>\n<p>The original code is still in the binary, but it is never referenced (dead code).<\/p>\n<h3>Are the patches reversible?<\/h3>\n<p>I thought as a finishing touch of this research it would be interesting to reverse the changes and bring the dead code back to life. As an input, I used the dumped code of:<\/p>\n<ul>\n<li>EternalPetya kernel + bootloader (<a href=\"https:\/\/virustotal.com\/en\/file\/b5d2ad3c7758f58aa329243af4ce4a906771a1a199210ed0c61f82d47edb3b1d\/analysis\/\" target=\"_blank\" rel=\"noopener noreferrer\">f3471d609077479891218b0f93a77ceb<\/a>).<\/li>\n<\/ul>\n<p>My version (reverse patch): (<a href=\"https:\/\/virustotal.com\/en\/file\/1b06b9b31543522b51304664641882c824b45fa70bce99538533eb4282246f8a\/analysis\/\" target=\"_blank\" rel=\"noopener noreferrer\">7957520271edf003742db63fc250c231<\/a>).<\/p>\n<p>Indeed, after applying the patches, we are back to seeing the same blinking screen, only the skull is gone (the corresponding strings has been overwritten):<\/p>\n<p><iframe  src='https:\/\/www.youtube.com\/embed\/I3gK3C_0zUs?version=3&#038;rel=1&#038;fs=1&#038;autohide=2&#038;showsearch=0&#038;showinfo=1&#038;iv_load_policy=1&#038;wmode=transparent' width=\"100%\" height=\"420\" frameborder=\"0\" ><\/iframe> <\/p>\n<h3>Conclusions<\/h3>\n<p>I think the presented evidence is enough to prove, that the code was not recompiled from the original source (in contrary to what I initially suspected). Thus, the involvement of the original Petya author, <a href=\"https:\/\/twitter.com\/JanusSecretary\" target=\"_blank\" rel=\"noopener noreferrer\">Janus<\/a>, seems unlikely. It seems in this case he was just chosen as a scapegoat by some different actor.<\/p>\n<p>The edits made in the code are well crafted &#8211; the person doing them was fluent in assembly\u00a0and knew exactly\u00a0what to change and why.\u00a0While the first impression of this malware appeared to be a clear recompilation of the modified Petya source code, after doing a deeper analysis, we have identified numerous nuances that show otherwise.<\/p>\n<p>EternalPetya seems to be a patchwork made of code stolen from various sources. In addition to the modified version of the GoldenEye Petya kernel, we found the leaked NSA exploits from the &#8220;Eternal&#8221; series as well as legitimate applications, such as PsExec.<\/p>\n<p>It is common practice among unsophisticated actors (script-kiddies) to steal and repurpose someone else&#8217;s code. However, in this case, the composition was done well by a person or team with immense knowledge and careful execution. A possible reason for using so many stolen elements, apart from saving actor&#8217;s time, could have been to throw off any obvious signs of\u00a0attribution.<\/p>\n<p>There are still many mysteries to solve about this malware which creates many theories that, until proven true, are nothing more than\u00a0speculation.<\/p>\n<h3>Appendix<\/h3>\n<p>Read also:<\/p>\n<blockquote data-secret=\"oy4Koqgm7i\" class=\"wp-embedded-content\">\n<p><a href=\"https:\/\/blog.malwarebytes.com\/threat-analysis\/2017\/06\/eternalpetya-lost-salsa20-key\/\">EternalPetya and the lost Salsa20 key<\/a><\/p>\n<\/blockquote>\n<p><iframe loading=\"lazy\"  src=\"https:\/\/blog.malwarebytes.com\/threat-analysis\/2017\/06\/eternalpetya-lost-salsa20-key\/embed\/#?secret=oy4Koqgm7i\" width=\"100%\" height=\"420\" frameborder=\"0\" ><\/iframe> <\/p>\n<hr \/>\n<p class=\"p1\"><em><span class=\"s1\">This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. <\/span><span class=\"s1\">She loves going in details about malware and sharing threat information with the community. <\/span><span class=\"s2\">Check her out on Twitter @<a href=\"https:\/\/twitter.com\/hasherezade\" target=\"_blank\" rel=\"noopener noreferrer\">hasherezade<\/a> and her personal blog: <a href=\"https:\/\/hshrzd.wordpress.com\/\"><span class=\"s3\">https:\/\/hshrzd.wordp<\/span><\/a><\/span><\/em><\/p>\n<p>The post <a rel=\"nofollow\" href=\"https:\/\/blog.malwarebytes.com\/threat-analysis\/2017\/06\/eternalpetya-yet-another-stolen-piece-package\/\">EternalPetya &#8211; yet another stolen piece in the package?<\/a> appeared first on <a rel=\"nofollow\" href=\"https:\/\/blog.malwarebytes.com\">Malwarebytes Labs<\/a>.<\/p>\n<p><a href=\"https:\/\/blog.malwarebytes.com\/threat-analysis\/2017\/06\/eternalpetya-yet-another-stolen-piece-package\/\" target=\"bwo\" >https:\/\/blog.malwarebytes.com\/feed\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p><strong>Credit to Author: Malwarebytes Labs| Date: Fri, 30 Jun 2017 16:53:36 +0000<\/strong><\/p>\n<table cellpadding='10'>\n<tr>\n<td valign='top' align='center'><a href='https:\/\/blog.malwarebytes.com\/threat-analysis\/2017\/06\/eternalpetya-yet-another-stolen-piece-package\/' title='EternalPetya - yet another stolen piece in the package?'><img src='https:\/\/blog.malwarebytes.com\/wp-content\/uploads\/2017\/06\/shutterstock_494287042.jpg' border='0'  width='300px'  \/><\/a><\/td>\n<\/tr>\n<tr>\n<td valign='top' align='left'>Since 27th June we&#8217;ve been investigating the outbreak of the new Petya-like malware armed with an infector similar to WannaCry. Since the day one, various contradicting theories started popping up. Some believed, that it is a rip-off the original Petya, others &#8211; that it is another step in its evolution. However, so far, those were just different opinions, and none of them was backed up with enough evidence. In this post, we will try to fill this gap, by making a step-by-step comparison of the current kernel and the one on which it is based (Goldeneye Petya).<\/p>\n<p>Categories: <\/p>\n<ul class=\"post-categories\">\n<li><a href=\"https:\/\/blog.malwarebytes.com\/category\/threat-analysis\/malware-threat-analysis\/\" rel=\"category tag\">Malware<\/a><\/li>\n<li><a href=\"https:\/\/blog.malwarebytes.com\/category\/threat-analysis\/\" rel=\"category tag\">Threat analysis<\/a><\/li>\n<\/ul>\n<p>Tags: <a href=\"https:\/\/blog.malwarebytes.com\/tag\/attribution\/\" rel=\"tag\">attribution<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/eternalpetya\/\" rel=\"tag\">EternalPetya<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/hasherezade\/\" rel=\"tag\">hasherezade<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/hexedit\/\" rel=\"tag\">hexedit<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/janus\/\" rel=\"tag\">janus<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/malwarebytes\/\" rel=\"tag\">Malwarebytes<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/notpetya\/\" rel=\"tag\">NotPetya<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/nsa\/\" rel=\"tag\">NSA<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/petya\/\" rel=\"tag\">petya<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/psexec\/\" rel=\"tag\">psexec<\/a><a href=\"https:\/\/blog.malwarebytes.com\/tag\/ransomware\/\" rel=\"tag\">ransomware<\/a><\/p>\n<table width='100%'>\n<tr>\n<td align=right>\n<p><b>(<a href='https:\/\/blog.malwarebytes.com\/threat-analysis\/2017\/06\/eternalpetya-yet-another-stolen-piece-package\/' title='EternalPetya - yet another stolen piece in the package?'>Read more&#8230;<\/a>)<\/b><\/p>\n<\/td>\n<\/tr>\n<\/table>\n<\/td>\n<\/tr>\n<\/table>\n<p>The post <a rel=\"nofollow\" href=\"https:\/\/blog.malwarebytes.com\/threat-analysis\/2017\/06\/eternalpetya-yet-another-stolen-piece-package\/\">EternalPetya &#8211; yet another stolen piece in the package?<\/a> appeared first on <a rel=\"nofollow\" href=\"https:\/\/blog.malwarebytes.com\">Malwarebytes Labs<\/a>.<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[10488,10378],"tags":[12861,12849,10492,12862,12863,3764,10560,12830,10626,12823,12864,3765,10494],"class_list":["post-8212","post","type-post","status-publish","format-standard","hentry","category-malwarebytes","category-security","tag-attribution","tag-eternalpetya","tag-hasherezade","tag-hexedit","tag-janus","tag-malware","tag-malwarebytes","tag-notpetya","tag-nsa","tag-petya","tag-psexec","tag-ransomware","tag-threat-analysis"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/8212","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=8212"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/8212\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=8212"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=8212"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=8212"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}