back to article Lockbit wins ransomware speed test, encrypts 25,000 files per minute

Ransomware moves more quickly than most organizations can respond. Though knowing they have a specific limited window should help inform where to put their defenses, according to security data shop Splunk. The vendor's research team Surge today published research on how long it takes 10 of the big ransomware families including …

  1. CommonBloke

    Honest question, how feasible is it to create a script that frequently scans the running processes and kills anything that's running file encryption? Put simply, detect any process running file encryption and immediately kill it.

    I mean, I understand that if whoever's attacking managed to get root access, you're 100% fcked. But when it's a user's fault for running a compromised program, this could stop the problem before much harm is done.

    1. mootpoint

      I think the problem with this approach would be identifying that the process is running encryption. I'd imagine these would be custom written rather than using any identifiable system processes.

      1. Zippy´s Sausage Factory

        The first thought in my head was to detect anything reading and writing files continually. The problem there is that reading files continually is going to raise a false positive on (for example) an antivirus scan, while continually writing files is going to hit other things like encrypting disks and compressing files. And a way to mark that process as being safe to do what it's doing is going to be able to be commandeered by ransomware anyway.

    2. Anonymous Coward
      Anonymous Coward

      There are products which monitor files for changes, multiple files being changed concurrently or in quick succession etc to help alert for this sort of thing.

      While those are good, decent backups online/offline, well configured RBAC and a layered approach to security are arguably better.

      Ultimately many would simply not stop an attack quick enough so it's best to prevent.

    3. Anonymous Coward
      Anonymous Coward

      Encryption is a legit process

      Encryption is a legit process and a vital part of many software solutions, so shutting down all file encryption processes isn't exactly a feasible option

      1. Eclectic Man Silver badge

        Re: Encryption is a legit process

        You may also have the problem of distinguishing between an attack and a program that compresses files for perfectly legitimately reasons.

        1. Yet Another Anonymous coward Silver badge

          Re: Encryption is a legit process

          >You may also have the problem of distinguishing between an attack and a program

          What about, why is a receptionist's PC suddenly overwriting every file in every folder on every Dept's server?

          In fact why does the mouth breathing external email clicking luser have write access to anything outside their one drive?

      2. Zippy´s Sausage Factory

        Re: Encryption is a legit process

        If they're using the built in Windows encryption, that's one thing. If they've rolled their own libraries, that's probably harder to detect.

    4. Anonymous Coward
      Anonymous Coward

      You may find Patrick's article at Objective See interesting - it's the thinking he went through to develop his RansomWhere software for MacOS.

      Although he focuses on MacOS, the generic points he makes in his analysis also apply to Windows and could maybe be of help to someone writing a ransomwhere detector for Windows.

    5. marcellothearcane

      I've thought before about whether you could have a honeypot file in your harddrive root that a program watches for changes and kills the process that changed it - that would reduce the false positives, but does add a cat and mouse problem where viruses dodge that file.

  2. Danny 2 Silver badge

    Kudos to the coder

    We might not agree with their aims, but being the fastest is admirable coding. I remember spending nights to strip excess machine code. Lockbit - evil, da, but efficient!

    [Leni Riefenstahl's cinematography might seem cliched today in the age of Trump/Putin rallies but recall she was innovative]

    1. badflorist

      Re: Kudos to the coder

      Sure, but it depends on how it works that 4KB... surely it isn't 4KB sequential? I understand without backups your F'd, but 4KB seems like backup == diff_fix (but again I'm not sure about that 4KB).

      1. leexgx

        Re: Kudos to the coder

        Lokbit is best case use for snapshots as it will use very little data so modified data be under 1-100gb so easy to revert

        Most of the nas based ransomware hasn't gained enough access to erase the snapshots just user level to encrypt files (I believe qnap patched it to make/fixed so snapshots are harder to be deleted as non admin could delete snapshots in the past )

  3. DS999 Silver badge

    The downside of SSDs

    With traditional hard drives and a nice fragmented filesystem, encrypting everything would take hours for a typical PC, and days or even weeks for a file server. Much better chance of being discovered and interrupted before it got too far along!

    1. Yet Another Anonymous coward Silver badge

      Re: The downside of SSDs

      The secret genius of sharepoint is revealed

  4. The Man Who Fell To Earth Silver badge
    Black Helicopters

    Maybe a "feature " in future CPU's should be...

    Maybe a "feature " in future CPU's should be to be able to detect whether a certain threshold of CPU usage is being used on AES-NI instructions for some period of time, and provide a flag or something that the OS or AV can check. Obviously one can encrypt without using the AES-NI instruction set, but if ransomware is trying to be fast, it's almost certainly using this instruction set and probably on all the cores it can simultaneously. The devil would be in the details as to what, when & how this would make sense, if it ever does.

    1. badflorist

      Re: Maybe a "feature " in future CPU's should be...

      It would be a little crazy to have a flag raised every time a lock was being installed, I think side-channel folks would love it though.

      1. The Man Who Fell To Earth Silver badge

        Re: Maybe a "feature " in future CPU's should be...

        "threshold" is the operative word. If your CPU has most of its cores running encryption full bore and it's been doing that for the last 20 minutes...

        That's not "normal" even on a system running full disk encryption.

        Side channel means the system is already comprimised.

  5. VoiceOfTruth

    How to help mitigate this

    Keep read-only snapshots of file systems. ZFS can do this, NetApps can too. I imagine that other higher-end file systems/volume managers can do the same. A good thing about NetApps is that Joe User does not have an actual account (I mean in a UNIX way) on them. So he/she/they can't turn off the read-only toggle.

  6. Morten Bjoernsvik

    invest in backups

    Just device a backup and restoration recovery plan. and test it. Store all data on servers encrypted and only allow access via certain applications running in containers as standard users.

    Just today I logged in as admin on a windows server and found the history in powershell holding anything needed to log in to a critical oracle database, leftover from last person being root on the system.

  7. Danny 2 Silver badge

    @Morten

    Just today..leftover from last person being root on the system

    Can I ask what you did? That person is obviously a risk to your employer, and therefore your job.It would be understandable if you reported them and asked for their rights to be limited - or sacked. It would also be understandable if you had a quiet word with them, but both options are risky.

    My boss made a huge security gaff that I found and fixed, and I slagged him mercilessly, but only in private because we were on good terms.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022