NoMoreRansom – One year on!

One year on.  It is fair to say that the No More Ransom project not only exceeded our expectations, but simply blew these initial expectations out of the water.  A collaboration between six partners (McAfee, EC3, Dutch Police, Kaspersky Lab, AWS and Barracuda) has now grown to include more than 100 partners across the public and private sector.  We often hear people talk about Public-Private Partnerships, but here is a true example of that commitment in action.

Because of this commitment from all the partners, this initiative has resulted in the successful decryption of more than 28,000 computers.  Let us put that into context, for zero cost, victims of ransomware who do not have to be customers of any security provider can get their data back for nothing.  They don’t have to fill in a survey, enter their email address, provide their credit card details, in fact they don’t even have to worry about obfuscating their IP address.  For the first time, there is another option.  No longer are victims faced with the option of a) lose my data or b) pay criminals.

So thank you to all of our partners, thank you to those of you that tweeted, blogged about it.  This site has been successful, in fact so successful that we even have ransomware named after us.

Of course, the Queen of England gets a boat named after her, we get ransomware!  Well that’s okay, because it shows that as the tens of millions of dollars we have prevented going into the hands of criminals, they have taken notice.

We will not stop, in fact, we need more partners, more decryption tools, and more successes.   The message of #DontPay seems to be working (as we witnessed with WannaCry and nPetya), and we will continue in our efforts to hurt the bottom line of criminals.


The post NoMoreRansom – One year on! appeared first on McAfee Blogs.

Is WannaCry Really Ransomware?

This post summarizes the significant efforts of a McAfee threat research team that has been relentless in its efforts to gain a deeper understanding of the WannaCry ransomware. We would like to specifically acknowledge Christiaan Beek, Lynda Grindstaff, Steve Grobman, Charles McFarland, and Kunal Mehta for their efforts.

Ransomware follows a relatively simple model: data is encrypted, the victim pays, data is decrypted. At least that is what those who create ransomware want you to believe. This was also our assumption when we began our analysis of WannaCry—that those behind the campaign would decrypt victims’ data once they received payment. However, for a campaign with incredibly effective propagation techniques, reasonable key and data management, and a working anonymous communication fabric with Bitcoin payments, we found a major flaw: The WannaCry attackers appear to be unable to determine which users have paid the ransom and they cannot decrypt on a per-user basis.

Technical summary

Our analysis into the encryption and decryption functions within WannaCry reveals an effective tool set. The authors:

  • Created an 8-byte unique identifier (via CryptGenRandom) that identifies the current machine and all the encrypted files on that machine. This ID is used in all communications with the back end and is intended to allow per-user decryption. (See “Can the attackers be contacted?” for details.)
  • Practiced reasonable data sanitization techniques to prevent the recovery of key material. (See “Does WannaCry prevent recovery of key material?”)
  • Followed reasonable practices to prevent the recovery of plain-text file data. (See “Does WannaCry prevent recovery of file data?”)
  • Developed a (somewhat unreliable) back end that keeps track of which users have encrypted files. (See “Can the authors respond? Can they return a private key?”)
  • Made file decryption possible, provided that the “Check Payment” interaction with the back end results in the decrypted key being written to 00000000.dky. The authors know if the returned data is a key or a message to be displayed to the user. The authors must have tested this at least once, and have thus tested full decryption where the need for the correct private key was clearly known. (See “Recovering the user’s private key”)
  • WannaCry appears to have been written by (at least] two authors or teams with different motives:
    • One author favored Win32 APIs and wrapping those APIs or using object orientation.
    • The other author favored C, common APIs (such as fopen), and long procedural functions. They may have been responsible for weaponizing the file encryptor/decryptor, but we do not know. If we are correct, this code probably introduced the unique ID idea but the interface was not updated to include a way to associate the ID with the user’s Bitcoin wallet.

The WannaCry authors demonstrated good technical governance, for example, the key handling, buffer sanitization, and private key security on disk using a strongly encrypted format. It is odd that with such good governance, the same group neglected to include something as essential as a unique ID for a user (or instance of attack) because this is mandatory to decrypt a specific user’s files. While much of the initial analysis described the WannaCry campaign as “shoddy,” the use of good technical governance suggests that there are elements of this campaign that are well implemented.

This competence raises doubts that the campaign was shoddy. Given the level of capability demonstrated, we would expect the developers would have found and fixed basic errors. Indeed, could the inclusion of these basic errors be an attempt to make the campaign appear amateur? Without apprehending those behind the campaign, it is impossible to know their motivation; yet a thorough analysis of the technical artefacts questions the shoddy theory.



What were the attackers’ motives? Is this real ransomware or something else? For a particular ransomware family to make money in the long term, it must be able to encrypt and decrypt files, and have a reputation that once payment is sent, data can be recovered.

We have identified three potential motives:

  • To make money
    • WannaCry has the key components required for a financially successful campaign—including propagation, key management, data sanitization techniques to prevent data and key recovery, anonymous payment, and messaging and decryption infrastructure.
    • To keep ransom payments flowing, the authors used current messaging infrastructure to ask users to send their Bitcoin wallet IDs to the attackers. This is the same messaging infrastructure that ultimately delivers the user’s private key, allowing full decryption.
    • However, there is limited evidence from the field that payment yields data decryption.
  • To test key components of the ransomware
    • This is likely because the malware contains almost no reverse engineering and debugging protection.
    • We have already seen new WannaCry variants that are harder to analyze because components download 24 hours or so after infection time.
  • To disrupt
    • Ransomware as a destructive mechanism. The use of ransomware to destroy or generate noise, though not common, would be a particularly effective tactic.

Determining the authors intent is not trivial, and likely not possible with the information available. However, to get closer to an answer, the question we need to answer is whether WannaCry is fully functional. Analyzing that leads to a few detailed questions that we explored:

  • Can WannaCry decrypt files?
  • Can the authors be contacted?
  • Can the authors respond? Can they return a private key?
  • Does WannaCry prevent the recovery of files?
  • Does WannaCry prevent the recovery of key material?

Is WannaCry fully functional?

WannaCry can communicate with a back end that maintains its state and prevents the recovery of key material and file data. If one has the user’s private key, the user’s data can be recovered. Despite its bugs and design issues, WannaCry is effective. It is not high quality or well implemented, but it is  effective.

Can WannaCry decrypt files?

The short answer is Yes. WannaCry’s encryption, key management, and file formats have been documented by McAfee Labs, so we will not cover that here. Instead, we will focus on the decryption tool, which we know makes use of the following API sets:

  • Microsoft’s crypto APIs.
    • CryptGenKey, CryptGenRandom, CryptExportKey, CryptImportKey, CryptEncrypt, CryptDecrypt, etc.
  • Microsoft’s file management APIs.
    • CreateFileW, ReadFile, WriteFile, CloseHandle, etc.
  • C runtime library file APIs
    • fopen, fread, fwrite, fflush, fclose, etc.

Using WinDbg or IDA Pro, we can set conditional breakpoints on the APIs used by @[email protected] and dump out useful information. Given the lack of debugging protection in the ransomware, this is one of the fastest ways to understand WannaCry’s behavior.

Sample decryption

To encourage users to pay the ransom, the decryption tool @[email protected] can decrypt a small number of files for free. After the “free” files have been decrypted, the decryptor looks for the file 00000000.dky, which should contain the user’s private key. If found, this key is used to decrypt all files on the system. If we have the user’s private key, can we decrypt all files?

Recovering the user’s private key

To prove that decryption is possible, we need the private key:

  • Break on CryptGenKey and get the handle to any created key pair.
  • Break on CryptExportKey and watch the export of the public and private keys to memory.
    • Here we can steal the private key and check if decryption works.
  • [Optionally] put break points showing the encryption of the private key with the attacker’s public key (hardcoded within the encryptor binary), and save it to disk in 00000000.eky.

To analyze the key creation, we can use the following breakpoints:

Figure 1: Crypto API breakpoints for key import and export.

As WannaCry initializes, it calls CryptGenKey to generate a new random key, the handle to which is returned in the fourth parameter.

Figure 2: Creating a new random key.

Next, WannaCry exports the public key from the generated key and saves it to the file 00000000.eky. Note the presence of 0x06 and RSA1. This indicates that the exported key blob is a public key. To view the key blob, save the address of the buffer and buffer size in temporary registers, allow the function to return, and dump the key blob using the address and size values from the temporary registers.

Figure 3: Capturing the user’s public key.

Next, WannaCry exports the private-public key pair to memory. Note the presence of 0x07 and RSA2 in the exported buffer.

Figure 4: Capturing the user’s private-public key pair.

Immediately afterward, WannaCry encrypts the user’s private key with the attacker’s public key and writes the file to 00000000.eky. The contents of this file are sent to the attackers when the user clicks “Check Payment” (as discussed further in “Can the attackers be contacted?”).

At this moment, the private-public key pair is easily recoverable, so we can issue a command to dump that memory to a file, as shown below:

Figure 5: Writing the private key to disk from WinDbg.

In Figure 5, we have given the private key almost the correct name. If the file 00000000.dky exists and contains a valid private key that can decrypt files, WannaCry will abort its encryption run. To decrypt files, rename the file to 00000000.dky once all files have been encrypted, and click on Decrypt.

Figure 6: Dialog after WannaCry successfully decrypts all files.

Based on this analysis, WannaCry is capable of per-user decryption, provided that WannaCry can send the user’s private key to the back end, receive the private decrypted key, and place it in the correct location.


Can the attackers be contacted?

WannaCry provides two methods of communication with the attackers: the “Contact Us” link and the “Check Payment” button on the main decryptor interface, shown below in Figure 7.

Figure 7: WannaCry’s Decryptor interface.

If WannaCry allowed recovery, both interface controls should function. Assuming that all communication is over standard network sockets, we can inspect the traffic in real time using WinDbg/IDA Pro with the breakpoints in Figure 8.

Figure 8: Breakpoints for analyzing network traffic.

Our goal is to determine what is being sent to and received from the back end. The detail is not shown here, but WannaCry makes use of TOR to anonymize communications with the attackers, cycling through many TOR servers. We looked for the user’s private key being sent to the back end, where we expected it to be decrypted and sent back if the user had paid the ransom (or if the attackers had decided to randomly decrypt a user’s key). We found one message that was large enough. An example is shown in Figure 9.

Figure 9: A large and interesting buffer sent to the back end.

However, the data did not match any part of the user’s private key stored on disk; could this communication be encrypted? Looking at the call stack, we saw several frames:

Figure 10: Post encryption send call stack.

Looking at the previous frame, we saw a simple wrapper around ws2_32!send, so this is not an encryptor.

Figure 11: ws2_32!send wrapper.

Looking at the frame before the send wrapper in Figure 11, we found a reasonably long function beginning at 0x0040d300 that appears to be responsible for obfuscating the buffer, and we confirmed that using IDA Pro with a second breakpoint, as shown below:

Figure 12: Message obfuscator function breakpoint.

Rerunning our Check Payment debugging run, our new breakpoint fired and revealed the message to be sent prior to obfuscation:

Figure 13: Message to be sent to back end.

The message encodes information that identifies the user. We color-coded the message components in Figures 13 and 15:

  • Green: The 8-byte unique ID stored in the first 8 bytes of 00000000.res. This is created by a call to CryptGenRandom during WannaCry’s initialization and persists for the life of the attack.
  • Orange: The computer name retrieved with GetComputerNameA.
  • Red: The user’s name retrieved by GetUserNameA.
  • Bold: The Bitcoin wallet ID that the user should have sent money to, and the amount that the user should have paid.
  • Cyan: The encrypted user’s private key as read from 00000000.eky.

Based on the message content, it is reasonable to assert that the attacker’s back end receives all the information required to identify users who have paid the ransom, and should be able to perform per-user decryption, provided there is a mechanism for users to tie their Bitcoin transfers to the 8-byte unique ID that represents their specific encryption instance. However, we found no mechanism to do this and there are no interface elements or instructions to help.

Running the same experiment using the Contact Us interface shown in Figure 14, we sent a message “Hey! Can I have my files back?” to the attackers, and using our breakpoint from Figure 12, we determined that a common messaging framework is used.

Figure 14: Messaging interface.

Figure 15: Message sent to back end.

The results in Figure 15 show:

  • Both Check Payment and Contact Us appear to use a common messaging format
    • 8-byte unique ID, machine name, username is always sent.
    • The payload can vary according to message type.

As a result, we conclude that the attackers should have been able to uniquely identify a user but they clearly omitted a mechanism to tie a payment to an ID, making per-user decryption technically impossible.

Can the authors respond? Can they return a private key?

Shortly after its release, Check Payment began returning a message to users instructing them to use the Contact Us mechanism to send the users’ Bitcoin wallet addresses, as shown in Figure 16.

Figure 16: Request for a Bitcoin wallet address.

This message confirms that the attackers can respond. It also gives us an opportunity to analyze the flow of Check Payment messages. Using the same send and recv breakpoints from Figure 8, we received the following obfuscated message:

Figure 17: Encrypted response received from attackers.

Using the following breakpoint, we then watched for that data being written to the obfuscated buffer; if the obfuscation removal occurs in place, we should be able to look at the decrypted buffer.

Figure 18: Message decryption breakpoint.

Once the breakpoint fires, we saw that the message was modified in place:

Figure 19: In-place decryption of the encrypted message.

Our analysis of the function in question in WinDbg and IDA Pro indicated that on return the message was in plain text. Issuing the gu command to step out of the function, we saw the message decrypted, as shown in Figure 20.

Figure 20: Decrypted check-payment message.

This is the same message that we saw displayed in the dialog box, so end-to-end communication is working. But, how is this message used? Again, we made use of a hardware breakpoint, as shown in Figure 21.

Figure 21: Hardware breakpoint to track the decrypted message.

The preceding breakpoint triggers during a call to fwrite to 0000000.dky; the message is written to a file that should contain the user’s private key, as shown below in a subsequent call to WriteFile as part of fwrite, fflush.

Figure 22: Entire message being written to 00000000.dky

The entire message, or whatever was sent back to the decryptor, is written to the file 00000000.dky. Thus we conclude that Check Payment should return a crypto API key blob for the user’s private key. By enabling our key import breakpoint shown in Figure 1, we verified this, as shown below:

Figure 23: The decrypted message imported as a key in CryptImportKey.

Note the value of eax at the bottom of Figure 23 after CryptImportKey has returned: eax is 0, which means that CryptImportKey failed. If CryptImportKey fails, then WannaCry eventually deletes 00000000.dky and displays the message to the user. If CryptImportKey succeeds, the user can successfully decrypt all the files.

From this analysis, we conclude:

  • The WannaCry communication fabric is active and can return messages.
  • The WannaCry back end is live and tracking users because the help message is returned only once.
  • The WannaCry client expects that a message or private key can be returned from the back end:
    • If the message is not a private key (CryptImportKey fails), the client assumes the message is text that should be shown to the user.
    • Private keys are left on disk in 00000000.dky and allow the user to decrypt their files.

Decryption does not work because the authors omitted a link between payment and the unique ID. But what happens if a user follows the instructions and sends the Bitcoin wallet ID to the attackers? Can the victim decrypt files? So far, a tiny sample of victims have reported the decryption of files, but this appears not to be tied to the payment-making function.

Although the message indicates that a user may be able to get the files back (which supports the theory of shoddy design), our limited testing indicated that decryption keys are not returned and files cannot be restored even after payment, which adds weight to the possibility that WannaCry is a prank or test.


Does WannaCry prevent recovery of file data?

Yes and no. There has been a lot of excellent research showing that in some circumstances, files are recoverable:

  • Files on removable and nonsystem volumes.
  • Read-only files.
  • Temporary files.

Files stored in the Desktop and Documents folders are the hardest to recover. What does this mean for our theories? Both are still supported:

  • Developer incompetence: Incorrectly deleting and overwriting original files indicates a hurried or poor engineer.
    • There is a difference between not realizing that per-user file decryption can never work without the unique ID and running into filesystem processing bugs for large batch operations; errors in batch processing are much easier to explain.
  • Prank: The techniques for preventing recovery support the theory that the developers did not go to great lengths to prevent recovery from unpredictable folders and devices:
    • Removable, network, and fixed nonsystem volumes may support file carving as a recovery technique. This is also true for devices that make use of wear leveling.
    • Online storage folders and some versioning tools may provide alternative recovery mechanisms for files.
    • Desktop and documents folders are commonly file locations. Many users would not be able to recover most of their files.

We do not believe that WannaCry file data recovery prevention strongly supports either thesis.


Does WannaCry prevent recovery of key material?

The most important key for data recovery is the user’s private key. We used hardware breakpoints to see what happens to the exported key blob in our earlier example, as shown below:

Figure 24: Hardware breakpoint to trigger on writes to the key blob.

When this breakpoint fires, we found the following code zeroing out the exported key blob:

Figure 25: Assembly of code that modifies the exported key blob.

Thanks to care taken with data sanitization (such as that shown in Figure 25) and the correct use of CryptDestroyKey, WannaCry keeps the user’s private key in a nonencrypted form for the shortest possible time. Thus private key recovery is impractical beyond exploiting issues in the Windows APIs (as described by other authors).

Although the attacker’s motive may remain unknown for some time, we commend the response from victims, who have generally decided to not pay. Our research continues into this campaign; we will release more data as more information arises.

The post Is WannaCry Really Ransomware? appeared first on McAfee Blogs.

WannaCry: The Old Worms and the New

The morning of Friday, May 12 multiple sources in Spain began reporting an outbreak of the ransomware now identified as WannaCry.

Upon learning of these incidents, McAfee immediately began working to analyze samples of the ransomware and develop mitigation guidance and detection updates for its customers.

By Friday afternoon, McAfee’s Global Threat Intelligence system was updated to identify all known WannaCry samples and the company had delivered DAT signature updates to all its customers.

McAfee urges all its customers to ensure these DAT updates have been applied, and furthermore ensure that security updates are applied for all the software solutions they use. For more information, read this Knowledge Center article.

This week’s attacks leveraging the WannaCry ransomware were the first time we’ve seen an attack combine worm tactics along with the business model of ransomware. The weaponization of the Eternal Blue exploit made public weeks ago, and unpatched MS-17-010 Windows OS vulnerabilities by the thousands enabled WannaCry to infect hundreds of thousands of computers, across industries, across continents, and within just a day. Furthermore, these attacks accomplished all this with little or no human involvement, as is typically the case in other ransomware campaigns.

A hybrid of the proven, less the human

WannaCry’s success comes down to its ability to amplify one attack through the vulnerabilities of many machines on the network. The impact of the attack is much greater than what we’ve seen from traditional data ransomware attacks.

Almost all of the ransomware we see in the wild today attack individual users typically through spear-phishing, meaning victims receive an email that appears to be coming from a legitimate source, it lures the victim into clicking on a link or opening an attachment that downloads or executes malicious code on his or her system. But it only impacts that victim’s one computer.

If you think back to the late 90s and early 2000s, when we had Code Red, NIMDA and SQL Slammer, those worms spread really rapidly because they didn’t require a human to take any action in order to activate the malware on the machine.  This week’s attacks did something very similar.

We’re still working to determine how a “patient zero” machine became infected, but, once it was, if other machines hadn’t received the MS-17-010 vulnerability patch, they were infected over their network.

Instead of stealing data or damaging other machines, the malware executed a classic ransomware attack, encrypting files and demanding a ransom payment. The attack essentially combined two techniques to produce something that was highly impactful.

With WannaCry, if the configuration of machines within an organization possessed the Microsoft vulnerability (addressed by Microsoft in March), the ransomware could infect one machine and then move very rapidly to spread and impact many other machines that still had not been patched.

What we’ve typically seen with cybercrime is that when any technique is shown to be effective, there are almost always copycats. Given that this appears to have been quite an effective attack, it would be very reasonable for other attackers to look for other opportunities. One of the things that makes that difficult is you need to have a vulnerability in software that has characteristics that enable worm-like behavior.

What’s unique here is that there is a critical vulnerability that Microsoft has patched, and an active exploit that ended up in the public domain, both which created the opportunity and blueprint for the attacker to be able to create this type of malicious ransomware worm capability.

Open for exploit

In the late 90s, it was common practice to leave all sorts of software running on machines even if it wasn’t used. For instance, one of the worms in the 90s took advantage of a vulnerability in a print server which was by default included on all servers even if there wasn’t a printer attached to the configuration of systems. That could enable a worm to connect to that printer port on all of the servers on a network, creating a worm propagation scenario that infected system after system.

A common practice for addressing this since those days is a best practice known as “least privilege,” which allows an application or service to run only the things on a machine or network that that entity needs to complete a task or function specific to its particular role. Least privilege has reduced the chances of the traditional worm scenario, but unpatched vulnerabilities mimmick this “open” element available for exploit, particularly if such vulnerabilities enable things such as file transfer or sharing across systems.

It would be difficult to orchestrate attacks such as the WannaCry campaign, without all the unpatched vulnerabilities, the publicly released exploit, and a set of proven ransomware technologies and tactics at the attacker’s disposal.

To patch or to not to patch

WannaCry should remind IT of the criticality to apply patches quickly. Part of the reason IT organizations hesitate to patch or run an internal quality assurance process is to ensure that there aren’t software incompatibility issues. One way I like to think about this is that whenever a patch must be applied, there is a risk to applying a patch, and a risk to not applying a patch. Part of what IT managers need to understand and assess is what those two risks mean to their organizations.

By delaying deployment of a patch, they can mitigate risk related to application compatibility. By delaying a patch, they are increasing the risk of being compromised by a threat exploiting a vulnerability. IT teams need to understand for each patch, what those levels of risk are, and then make a decision that minimizes risk for an organization.

Events such as WannaCry have the potential to shift the calculus of this analysis. One of the problems we often see in security is that the lack of an attack is sometimes interpreted as having a good defense.  Companies that have become lax in applying patches may have not experienced any attacks that take advantage of those vulnerabilities. This can reinforce the behavior that it’s okay to delay patching.

This episode should remind organizations that they really do need an aggressive patching plan in order to mitigate the vulnerabilities in their environment.

Why the hospitals?

Hospitals fall into a category I think of as “soft targets,” meaning hospitals generally focus on patient care as their top priority, as opposed to having the best cyber defenders on staff and best cyber defense technologies in place.

The reason for this is that, traditionally, there was very little incentive for cybercriminals to attack a hospital. They could potentially steal patient records or other data, but the total value of data from a hospital would typically be less than that of  the bulk data stolen from other industries such as financial services.

What ransomware has done as a criminal business model is provide an incentive to attack any organization. Given that criminals are demanding a ransom, it’s far easier to exploit an organization with weaker cyber defenses than an organization with stronger cyber defenses, which is why we’ve seen hospitals, schools, municipal police departments, and universities become victims of ransomware over the last year. While we’re now starting to see the targeting of “harder” organizations as well, at least for now, there are a lot of opportunities for criminals to continue to target these soft target organizations.

What next?

Although this attack is something new, and something we need to be thoughtful of, when we see such a vulnerability occur in the wild, and an exploit published that could be used by cybercriminals, we should always expect and be prepared for this kind of attack, and many more copy-cat attacks following soon after.



The post WannaCry: The Old Worms and the New appeared first on McAfee Blogs.

An Analysis of the WannaCry Ransomware Outbreak

Charles McFarland was a coauthor of this blog.

Over the course of Friday, May 12 we received multiple reports of organizations across multiple verticals being victim to a ransomware attack. By Friday afternoon, McAfee’s Global Threat Intelligence system was updated to identify all known WannaCry samples and the company had delivered DAT signature updates to all its customers. But the wave of attacks ranks as one of the more notable cyber events in history.

Once infected, the encrypted files contain the file extension .WNCRYT. Victims’ computers then proceed to display the following message with a demand for $300 to decrypt the files.


Exploit MS17-010:

The malware is using the MS17-010 exploit to distribute itself. This is a SMB vulnerability with remote code execution options. Details at . Exploit code is available on multiple sites, including this example:

This exploit is also known as the Equation Group’s ETERNALBLUE exploit, part of the FuzzBunch toolkit released by Shadow Brokers a couple of weeks ago.

With MS17-010, the attacker can use just one exploit to get remote access with system privileges, meaning both steps (Remote Code Execution +Local Privilege Escalation combined) use just one bug in the SMB protocol. Analyzing the exploit code in Metasploit, a popular hacking tool, we see the exploit uses KI_USER_SHARED_DATA, which has a fixed memory address (0xffdff000 on 32-bit Windows) to copy the payload and transfer control to it later.

By remotely gaining control over a victim’s PC with system privileges without any user action, the attacker can spray this malware in the local network by having control over one system inside this network (gaining control over all systems that are not fixed and are affected by this vulnerability), and that one system will spread the ransomware to all vulnerable Windows systems not patched for MS17-010.


By using command-line commands, the Volume Shadow copies and backups are removed:

Cmd /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete & bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet

File size of the ransomware is 3.4MB (3514368 bytes).

Authors called the ransomware WANNACRY—the string hardcoded in samples.

Ransomware is writing itself into a random character folder in the ProgramData folder with the filename tasksche.exe or in the C:\Windows\ folder with the filename mssecsvc.exe and tasksche.exe.











The ransomware grants full access to all files by using the command:

Icacls . /grant Everyone:F /T /C /Q


Using a batch script for operations:



Content of batch file (fefe6b30d0819f1a1775e14730a10e0e)

echo off

echo SET ow = WScript.CreateObject(“WScript.Shell”)> m.vbs

echo SET om = ow.CreateShortcut(“C:\


.exe.lnk”)>> m.vbs

echo om.TargetPath = “C:\


.exe”>> m.vbs

echo om.Save>> m.vbs

cscript.exe //nologo m.vbs

del m.vbs

del /a %0

Content of M.vbs

SET ow = WScript.CreateObject(“WScript.Shell”)

SET om = ow.CreateShortcut(“C:\



om.TargetPath = “C:\




Indicators of compromise


































IP Addresses



  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com (sinkholed)
  • Rphjmrpwmfv6v2e[dot]onion
  • Gx7ekbenv2riucmf[dot]onion
  • 57g7spgrzlojinas[dot]onion
  • xxlvbrloxvriy2c5[dot]onion
  • 76jdd2ir2embyv47[dot]onion
  • cwwnhwhlz52maqm7[dot]onion


  • @[email protected]
  • @[email protected]
  • @[email protected]
  • Please Read Me!.txt (Older variant)
  • C:\WINDOWS\tasksche.exe
  • C:\WINDOWS\qeriuwjhrf
  • 131181494299235.bat
  • 176641494574290.bat
  • 217201494590800.bat
  • [0-9]{15}.bat #regex
  • !WannaDecryptor!.exe.lnk
  • 00000000.pky
  • 00000000.eky
  • 00000000.res
  • C:\WINDOWS\system32\taskdl.exe


Bitcoin Wallets

  • 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn
  • 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94
  • 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
Here is a snort rule submitted to Sans from Marco Novak:

alert tcp $HOME_NET 445 -> any any (msg:”ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response”; flow:from_server,established; content:”|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|”; depth:16; fast_pattern; content:”|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|”; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:2;)

And other SNORT rules from Emerging Threats:


alert smb any any -> $HOME_NET any (msg:”ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Request (set)”; flow:to_server,established; content:”|00 00 00 31 ff|SMB|2b 00 00 00 00 18 07 c0|”; depth:16; fast_pattern; content:”|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|”; distance:0; flowbits:set,ETPRO.ETERNALBLUE; flowbits:noalert; classtype:trojan-activity; sid:2024220; rev:1;)

alert smb $HOME_NET any -> any any (msg:”ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response”; flow:from_server,established; content:”|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|”; depth:16; fast_pattern; content:”|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|”; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:1;)



rule wannacry_1 : ransom



author = “Joshua Cannell”

description = “WannaCry Ransomware strings”

weight = 100

date = “2017-05-12”



$s1 = “Ooops, your files have been encrypted!” wide ascii nocase

$s2 = “Wanna Decryptor” wide ascii nocase

$s3 = “.wcry” wide ascii nocase

$s4 = “WANNACRY” wide ascii nocase

$s5 = “WANACRY!” wide ascii nocase

$s7 = “icacls . /grant Everyone:F /T /C /Q” wide ascii nocase



any of them


rule wannacry_2{


author = “Harold Ogden”

description = “WannaCry Ransomware Strings”

date = “2017-05-12”

weight = 100


$string1 = “msg/m_bulgarian.wnry”

$string2 = “msg/m_chinese (simplified).wnry”

$string3 = “msg/m_chinese (traditional).wnry”

$string4 = “msg/m_croatian.wnry”

$string5 = “msg/m_czech.wnry”

$string6 = “msg/m_danish.wnry”

$string7 = “msg/m_dutch.wnry”

$string8 = “msg/m_english.wnry”

$string9 = “msg/m_filipino.wnry”

$string10 = “msg/m_finnish.wnry”

$string11 = “msg/m_french.wnry”

$string12 = “msg/m_german.wnry”

$string13 = “msg/m_greek.wnry”

$string14 = “msg/m_indonesian.wnry”

$string15 = “msg/m_italian.wnry”

$string16 = “msg/m_japanese.wnry”

$string17 = “msg/m_korean.wnry”

$string18 = “msg/m_latvian.wnry”

$string19 = “msg/m_norwegian.wnry”

$string20 = “msg/m_polish.wnry”

$string21 = “msg/m_portuguese.wnry”

$string22 = “msg/m_romanian.wnry”

$string23 = “msg/m_russian.wnry”

$string24 = “msg/m_slovak.wnry”

$string25 = “msg/m_spanish.wnry”

$string26 = “msg/m_swedish.wnry”

$string27 = “msg/m_turkish.wnry”

$string28 = “msg/m_vietnamese.wnry”


any of ($string*)



McAfee urges all its customers to ensure McAfee’s DAT updates have been applied to ensure the latest protection. We furthermore advise customers to be diligent in applying security updates for all the software solutions they use.

For more information on McAfee’s response to WannaCry, please read this Knowledge Center article.

The post An Analysis of the WannaCry Ransomware Outbreak appeared first on McAfee Blogs.