Wannacry ransomware still infecting companies

Discussion in 'CYBER SECURITY awareness!' started by Dhruv Gupta, Jun 25, 2017.

  1. Dhruv Gupta

    Dhruv Gupta Member

    WannaCry ransomware is still alive, and it just forced Honda to close one of its plants
    Image Source: Health Service Journal
    Yoni Heisler
    June 23rd, 2017 at 2:51 PM
    Just over a month ago, a nasty piece of ransomware called “WannaCry” began infecting PCs all across the world at an alarming rate. Based off of a leaked NSA exploit, the malware worked by encrypting all of a user’s files and offering up a decryption key only upon receipt of a $300 payment via Bitcoin. In the span of just a few days, WannaCry managed to infect nearly 300,000 machines, a tally which could have been much higher had it not been for a researcher who inadvertently activated WannaCry’s kill-switch.
    Read full news here-http://bgr.com/2017/06/23/wannacry-ransomeware-honda-plant/
    This proves that ransomware attacks will only continue to grow in the future.
  2. Google Adsense

  3. kram7750

    kram7750 Member Known Member

    Sadly due to being busy with other things (and also the lack of system resources for VM testing lately) I've been unable to perform analysis on a sample for WannaCry ransomware however I am sure there must be a pattern during execution which AV solutions could dynamically identify to determine the presence of WannaCry. Of course, the author could then change things round (use functions in a different order) so it would not be perfect but it could work out well.

    To elaborate more, let's pretend we have a program called "glassofwater.exe". When this program is executed it will call kernel32.dll!MessageBoxA, kernel32.dll!CreateFileA to obtain a handle to "\\\\.\\kmdriver" and then it will attempt to call kernel32.dll!DeviceIoControl (using he handle acquired from the CreateFileA call). When it has done doing this, it will access the registry to query and then depending on the results it will modify some registry values, drop a file to disk and inject a DLL into lsass.exe via manual map injection.

    Using the above elaboration demonstration, we would assume that there would be: a specific text/title on the MessageBoxA call (second and third parameter of the function call); a specific target for the CreateFileA call; a specific target for the registry query/modifications; a specific file name for the dropped file (and path); the name to the DLL being injected into lsass.exe. With this information, we could hook a function like NtCreateFile and then perform the comparison for the target, hook NtSetValueKey and check the targets for modifications, etc... Depending on the filter results we would be able to differentiate between any old program using the API functions and the glassofwater.exe sample.

    Now of course, usually speaking you cannot just combine a few functions together and use that to identify a threat because a genuine function may also use the same functions in the same order. However, with threats like WannaCry you could analyse the process dynamically to monitor the API calls (and the parameters when these functions are called) and then make a detection system to intercept the same API calls but filter out with the parameters to differentiate between a normal clean program using the same functions and a WannaCry sample.

    If a technique like this could be used for a specific threat such as WannaCry and was implemented then aspects such as static packing/'crypting' would become obsolete for concealing the sample and making it undetected to AV solutions.

    It would not always work out and would not be full-proof but it could be a decent start...
    revC0de, LowcyGier, wwd and 1 other person like this.

Share This Page