legal contact

Wannycry / WannaDecrypt0r / MS17-010

Forked from: rain-1 and enhanced by myself

  • Virus Name: WannaCrypt, WannaCry, WanaCrypt0r, WCrypt, WCRY
  • Vector: All Windows versions before Windows 10 are vulnerable if not patched for MS-17-010. It uses EternalBlue MS17-010 to propagate.
  • Ransom: between $300 to $600. There is code to 'rm' (delete) files in the virus. Seems to reset if the virus crashes.
  • Backdooring: The worm loops through every RDP session on a system to run the ransomware as that user. It also installs the DOUBLEPULSAR backdoor. It corrupts shadow volumes to make recovery harder. (source: malwarebytes)
  • Kill switch: If the website is up the virus exits instead of infecting the host. (source: malwarebytes). This domain has been sinkholed, stopping the spread of the worm. Will not work if proxied (source).

update: A minor variant of the virus has been found, it looks to have had the killswitch hexedited out. Not done by recompile so probably not done by the original malware author. On the other hand that is the only change: the encryption keys are the same, the bitcoin addresses are the same. On the other hand it is corrupt so the ransomware aspect of it doesn't work - it only propagates.


Microsoft first patch for XP since 2014:

Killswitch source:



Although cybersecurity firms Kaspersky and Symantec have both said the code has some similarities with that previously used by the Lazarus Group,[116] (believed to have carried out the cyberattack on Sony Pictures in 2014 and a Bangladesh bank heist in 2016 – and linked to North Korea),[116] this may be either simple re-use of code by another group, or an attempt to shift blame – as in a false flag operation.

Malware samples

Binary blob in PE crypted with pass 'WNcry@2ol7', credits to ens!

essentially the full known catalogue of samples. credit to errantbot and @codexgigassys

Informative Tweets

Cryptography details

  • Each infection generates a new RSA-2048 keypair.
  • The public key is exported as blob and saved to 00000000.pky
  • The private key is encrypted with the ransomware public key and saved as 00000000.eky
  • Each file is encrypted using AES-128-CBC, with a unique AES key per file.
  • Each AES key is generated CryptGenRandom.
  • The AES key is encrypted using the infection specific RSA keypair.

The RSA public key used to encrypt the infection specific RSA private key is embedded inside the DLL and owned by the ransomware authors. even more in depth RE information by cyg_x1!!

Bitcoin ransom addresses

3 addresses hard coded into the malware.

C&C centers

  • gx7ekbenv2riucmf.onion
  • 57g7spgrzlojinas.onion
  • xxlvbrloxvriy2c5.onion
  • 76jdd2ir2embyv47.onion
  • cwwnhwhlz52maqm7.onion


All language ransom messages available here:

m_bulgarian, m_chinese (simplified), m_chinese (traditional), m_croatian, m_czech, m_danish, m_dutch, m_english, m_filipino, m_finnish, m_french, m_german, m_greek, m_indonesian, m_italian, m_japanese, m_korean, m_latvian, m_norwegian, m_polish, m_portuguese, m_romanian, m_russian, m_slovak, m_spanish, m_swedish, m_turkish, m_vietnamese

File types

There are a number of files and folders wannacrypt will avoid. Some because it's entirely pointless and others because it might destabilize the system. During scans, it will search the path for the following strings and skip over if present:

  • "Content.IE5"
  • "Temporary Internet Files"
  • " This folder protects against ransomware. Modifying it will reduce protection"
  • "\Local Settings\Temp"
  • "\AppData\Local\Temp"
  • "\Program Files (x86)"
  • "\Program Files"
  • "\WINDOWS"
  • "\ProgramData"
  • "\Intel"
  • "$"

The filetypes it looks for to encrypt are:

.doc, .docx, .xls, .xlsx, .ppt, .pptx, .pst, .ost, .msg, .eml, .vsd, .vsdx, .txt, .csv, .rtf, .123, .wks, .wk1, .pdf, .dwg, .onetoc2, .snt, .jpeg, .jpg, .docb, .docm, .dot, .dotm, .dotx, .xlsm, .xlsb, .xlw, .xlt, .xlm, .xlc, .xltx, .xltm, .pptm, .pot, .pps, .ppsm, .ppsx, .ppam, .potx, .potm, .edb, .hwp, .602, .sxi, .sti, .sldx, .sldm, .sldm, .vdi, .vmdk, .vmx, .gpg, .aes, .ARC, .PAQ, .bz2, .tbk, .bak, .tar, .tgz, .gz, .7z, .rar, .zip, .backup, .iso, .vcd, .bmp, .png, .gif, .raw, .cgm, .tif, .tiff, .nef, .psd, .ai, .svg, .djvu, .m4u, .m3u, .mid, .wma, .flv, .3g2, .mkv, .3gp, .mp4, .mov, .avi, .asf, .mpeg, .vob, .mpg, .wmv, .fla, .swf, .wav, .mp3, .sh, .class, .jar, .java, .rb, .asp, .php, .jsp, .brd, .sch, .dch, .dip, .pl, .vb, .vbs, .ps1, .bat, .cmd, .js, .asm, .h, .pas, .cpp, .c, .cs, .suo, .sln, .ldf, .mdf, .ibd, .myi, .myd, .frm, .odb, .dbf, .db, .mdb, .accdb, .sql, .sqlitedb, .sqlite3, .asc, .lay6, .lay, .mml, .sxm, .otg, .odg, .uop, .std, .sxd, .otp, .odp, .wb2, .slk, .dif, .stc, .sxc, .ots, .ods, .3dm, .max, .3ds, .uot, .stw, .sxw, .ott, .odt, .pem, .p12, .csr, .crt, .key, .pfx, .der

credit herulume, thanks for extracting this list from the binary.

more details came from thanks to cyg_x11

Some other interesting strings

BAYEGANSRV\administrator Smile465666SA

credit: nulldot

Encrypted file format

typedef struct _wc_file_t {
    char     sig[WC_SIG_LEN]     // 64 bit signature WANACRY!
    uint32_t keylen;             // length of encrypted key
    uint8_t  key[WC_ENCKEY_LEN]; // AES key encrypted with RSA
    uint32_t unknown;            // usually 3 or 4, unknown
    uint64_t datalen;            // length of file before encryption, obtained from GetFileSizeEx
    uint8_t *data;               // Ciphertext Encrypted data using AES-128 in CBC mode
} wc_file_t;

credit for reversing this file format info: cyg_x11.

Vulnerability disclosure

The specific vulnerability that it uses to propagate is ETERNALBLUE.

This was developed by "equation group" an exploit developer group associated with the NSA and leaked to the public by "the shadow brokers". Microsoft fixed this vulnerability March 14, 2017. They were not 0 days at the time of release.

POC for MS17-010

Eternalblue exploit as per the NSA Vault7 leak: Thanks to nixawk.

Remediation's and countermeassures:

  • Addiotional IOC's came available and can be downloaded here.
  • MS17-010 Scanner:
  • Make sure the KillSwitchURL is accessible or create a fake URL
  • Create the mutex to stop a client to start the malware
  • Disable SMB1
    • dism /online /norestart /disable-feature /featurename:SMB1Protocol
  • Use a Yara rule to detect
  • Decrypt on your own (not verified)
    • Thanks to cybernova
    • Private key in hex (2048 bit):
    • @defuse: You have to use my java library to crack RSA, with this main code:


    Further reading

    How the encryption is done
    Thanks to modexp


    This is a quick post about the WanaCryptor ransomware wreaking havoc on many networks across the world this weekend. With all the news coverage, most of you already know the trouble caused by it.

    Once executed on a system, it will use the RSA and AES cryptographic algorithms to encrypt files before demanding payment in exchange for a key necessary to recover those files. If you want to understand the RSA cryptosystem, please read here since all the talk about public and private keys might be confusing to some readers at first.


    The source code provided along with this post is intended primarily for security researchers who wish to understand the encryption and decryption process, which may help with recovery of files in the event authors of ransomware decide to release their private key.

    There’s no discussion here on any behavior of the ransomware except the encryption/decryption process so if you want information about something else, have a look at this file here which was compiled by various security researchers in the #wannadecryptor channel on Freenode IRC servers.

    For the source code to wanaforksee sources in C here. It’s only been compiled with MSVC and tested on Windows, although MINGW should compile it ok, provided it’s a recent version.

    Encryption Process

    Each system generates an RSA key pair of 2048-bits using the CryptGenKey API which is part of the Microsoft Crypto API (CAPI).

    The public key is stored in 00000000.pky using CryptExportKey
    The private key is stored in 00000000.eky using CryptExportKey but is also encrypted before storage using CryptEncrypt API with the master public key embedded inside the DLL responsible for encrypting files on disk.

    This encryption of private key is what prevents recovery of files without assistance from the ransomware authors.

    For each file encrypted, CryptGenRandom API is used to derive a 16-byte value which is used with AES-128 in CBC mode to encrypt the data.

    The AES key is encrypted with the users public key and stored along with AES ciphertext.

    The only way to recover this AES key and thus the contents of encrypted files is through decryption using the private key and we need the master private key to do this.

    Ransom payment process

    Although I haven’t researched this at all, it seems reasonable to make some assumptions based on the encryption model that some component of the ransomware sends the encrypted private key stored in 00000000.eky to a server over the TOR network where it’s decrypted by the ransomware authors using their master private key.

    The decrypted private key is then sent back to the victim’s system and stored as 00000000.dky which allows @WanaDecryptor@.exe to recover files.

    Open to correction of course. It has been pointed out by some that there’s no way for the ransomware authors to identify who makes a payment.

    Because of the algorithm used, it isn’t feasible to recover data from encrypted files without assistance from the ransomware authors.

    The rest of post may only be of interest to developers / researchers.


    You’ll see these values throughout the source code shown here.

    WanaCryptor Archive Structure

    Each encrypted file or what I call archive, has a predefined structure necessary for successful decryption.

    • Signature

      64-bit signature. Currently set to the string “WANACRY!

    • Key Length

      Indicates length in bytes of the following encrypted AES key.

    • Encrypted AES key

      128-bit AES key encrypted using the users RSA public key stored in 00000000.pky
      This key is generated by CryptGenRandom.

    • Unknown 32-bit value

      I’m unsure what this is for yet. It’s usually set to 3 or 4

    • File Length

      64-bit value obtained from GetFileSizeEx which indicates the original size of file.

    • Ciphertext

      Encrypted data using AES-128 in CBC mode. Uses zero padding.

    The following is a structured hex dump of encrypted file generated by the malware.

    RSA Key Generation

    As said, the RSA keys generated are unique to each system.

    In the tool, both public + private keys are exported in their plaintext form. The private key is also encrypted for illustrating how the malware does it.

    AES Key Generation

    The AES keys for each file are generated using CryptGenRandom API which is cryptographically secure and therefore invulnerable to attack.

    When decrypting an archive, we need to decrypt the encrypted AES key using the RSA private key blob stored in 00000000.dky

    In both scenarios, because I’m using Crypto API for AES, additional steps are required to import the key into a CAPI key object.

    I’d guess using a custom AES was probably easier to use than Crypto API, but that’s just speculation on my part.


    WanaCryptor uses Zero Padding, but Crypto API doesn’t support it.

    Rather than set the bFinalize flag to TRUE when encrypting final block, the buffer should be aligned by 16 bytes and padded with null bytes. The bFinalize flag should remain FALSE in order to be compatible with WanaCryptor.

    Here’s an example of creating a WanaCryptor archive and using Crypto API to perform AES-128-CBC encryption of file data.


    As with Encryption, the bFinalize flag (if using Crypto API) should always be FALSE. This is because Microsoft Crypto CSPS don’t support zero padding.


    Without the master private key generated by the authors, it’s not possible to recover data from encrypted files unless by miracle someone discovers a flaw with either AES or RSA.

    Thanks to 0x4d_ for helping with post and all the folks on freenode for researching this malware over the weekend.

    This tool will require a lot more testing before it can be considered reliable and the only reason for releasing it early is so that others can study the source and write their own decryption tools.