Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Sunday May 17 2020, @02:06AM   Printer-friendly
from the novel-approach dept.

Software developed by SMU stops ransomware attacks:

Engineers from SMU's Darwin Deason Institute for Cybersecurity have developed software that detects ransomware attacks before attackers can inflict catastrophic damage.

[...] Unlike existing methods, such as antivirus software or other intrusion detection systems, SMU's new software works even if the ransomware is new and has not been used before.

SMU's detection method is known as sensor-based ransomware detection because the software doesn't rely on information from past ransomware infections to spot new ones on a computer. In contrast, existing technology needs signatures of past infections to do its job.

"With this software we are capable of detecting what's called zero-day ransomware because it's never been seen by the computer before," said Mitch Thornton, executive director of the Deason Institute and professor of electrical and computer engineering in SMU's Lyle School of Engineering. "Right now, there's little protection for zero-day ransomware, but this new software spots zero-day ransomware more than 95 percent of the time."

[...] "The results of testing this technique indicate that rogue encryption processes can be detected within a very small fraction of the time required to completely lock down all of a user's sensitive data files," Taylor noted. "So the technique detects instances of ransomware very quickly and well before extensive damage occurs to the victim's computer files."

[...] SMU's software functions by searching for small, yet distinguishable changes in certain sensors that are found inside computers to detect when unauthorized encryptions are taking place.

[...] Use of the computer's own devices to spot ransomware "is completely different than anything else that's out there," Taylor said.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by KilroySmith on Sunday May 17 2020, @02:28AM (9 children)

    by KilroySmith (2113) on Sunday May 17 2020, @02:28AM (#995220)

    Not really:
    "When attackers encrypt files, certain circuits inside the computer have specific types of power surges as files are scrambled. Computer sensors that measure temperature, power consumption, voltage levels, and other characteristics can detect these specific types of surges, SMU researchers found.

    The SMU software monitors the sensors to look for the characteristic surges."

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 5, Insightful) by coolgopher on Sunday May 17 2020, @02:35AM (4 children)

    by coolgopher (1157) on Sunday May 17 2020, @02:35AM (#995223)

    Uh huh. And how precisely is it going to tell the difference between encryption and say, compression? Pretty sure me running an "xz -9 -T0 disk.img" would look remarkably the same as if some malware was encrypting stuff as fast as it could.

    • (Score: 1) by RandomFactor on Sunday May 17 2020, @04:13AM (1 child)

      by RandomFactor (3682) Subscriber Badge on Sunday May 17 2020, @04:13AM (#995241) Journal

      That was my first thought also. Your encryption and compression, bad guy's encryption. How's a sensor to know the difference?

      I suppose if they can do it securely they could toss an alert up and you have to disable the software for a time period.

      --
      В «Правде» нет известий, в «Известиях» нет правды
      • (Score: 1, Interesting) by Anonymous Coward on Monday May 18 2020, @12:17AM

        by Anonymous Coward on Monday May 18 2020, @12:17AM (#995527)

        Right. This is a heuristic. It will have false positives in real use cases and false negatives (5%) also. It will also be subject to countercounterattack from ransomware, which might null out instead of encrypting if this countermeasure is detected, or might aim to disable this countermeasure before running and being spotted, or might adjust encryption computation (eg. using the GPU, less efficient but 'system noise'-indistinguishable software routines, or so on).

        Practically the heuristic of large-scale "reads A, deletes A and writes B" or "overwrites" events would pair well with this.

    • (Score: 0) by Anonymous Coward on Monday May 18 2020, @12:43PM (1 child)

      by Anonymous Coward on Monday May 18 2020, @12:43PM (#995719)
      Meh, just have some sentinel folders and files. If they get encrypted/changed for no good reason you probably have ransomware or some sort of malware.

      If you want to slow them down you could add honeypot folders with virtual files and folders inside that go on "forever". Then the ransomware might spend lots of time encrypting those files instead of encrypting files you care about. There are lots of clever things you can do for the virtual files - like use "dictionaries" to generate their content and filenames (based on "random" seeds and the path), and cache a few GBs of the writes - so it works even if the ransomware checks to see if stuff is actually written/changed.

      No need for unicorn farts.

      I did email the anti-ransomware honeypot ideas to a few AV vendors coz I'm too lazy to implement them. Most ideas are easy, good implementation and getting market adoption is hard.
      • (Score: 2) by vux984 on Tuesday May 19 2020, @10:34AM

        by vux984 (5045) on Tuesday May 19 2020, @10:34AM (#996258)

        The trouble with such honeypot folders is that everything from desktop indexing software to backup software needs to know about them and be avoid them or they'll fall into them. And Even the naive user doing a simple backup of some folders or something can trip over them, or right clicking on a folder and selecting properties to see how big it is, or how many files in it when doing some manual clean up can trip into them.

        Worse good ransomware, may be written to look at where the backups and search indexers and MRU lists are pointing, so as to target the valuable data first.

        Bottomless pits aren't really a good idea on most systems.

  • (Score: 2) by vux984 on Sunday May 17 2020, @02:58AM (3 children)

    by vux984 (5045) on Sunday May 17 2020, @02:58AM (#995231)

    "When attackers encrypt files, certain circuits inside the computer have specific types of power surges as files are scrambled."

    Are those somehow different circuits then when users deliberately encrypt files?

    Frankly that sounds like bullshit. It might be BS from the source, or it might be journalists attempting to understand something technical and failing.

    But heuristic or behavioral analysis is hardly new; lots of antivirus software and even some backup software now have behavior monitoring to detect a ransomware attack. After all, reading a bunch of files, encrypting them, and overwriting them requires reading a bunch of files, encrypting them, and overwriting them... so if files suddenly start getting overwritten with scrambled copies en mass it's pretty straightforward to sound the alarm... its not inconceivable that there are associated signatures in CPU monitoring that correlate well and can be used as additional tracers on detecting something suspicious going on and its possible these guys have discovered something novel that's useful, but this general type of protection is hardly new.

    • (Score: 3, Insightful) by Immerman on Sunday May 17 2020, @04:23AM (2 children)

      by Immerman (3985) on Sunday May 17 2020, @04:23AM (#995245)

      >Are those somehow different circuits then when users deliberately encrypt files?

      Probably not - but if you don't normally encrypt your files (which is probably by far the norm), being prompted to disallow file system changes in response to any sustained any surge of encryption activity probably goes a long way toward stopping malicious activity. If you do enough sustained encryption to make hitting "allow" a nuisance... maybe this isn't for you. That's no reason to deny it to the vast majority.

      • (Score: 1, Insightful) by Anonymous Coward on Sunday May 17 2020, @06:19AM

        by Anonymous Coward on Sunday May 17 2020, @06:19AM (#995272)

        Additionally, people who do encryption and compression tend to use common COTS software to do so. Maybe 2 dozen products in your whitelist signatures and most people are set. All you need to do is Detect -> Lockdown -> Verify -> Prompt if necessary. When someone says the activity is ok, then you can upload the information necessary to determine if it is worth whitelisting in future versions of the software.

      • (Score: 2) by vux984 on Monday May 18 2020, @01:35AM

        by vux984 (5045) on Monday May 18 2020, @01:35AM (#995560)

        You seem to have missed my overall point: I'm not saying this isn't a good idea. I'm saying its an old idea, and that the novelty of this new research is pretty limited. Limited to perhaps identifying a minor additional signal.