LockBit's new variant is 'most dangerous yet,' hitting Windows, Linux and VMware ESXi Trend Micro has sounded the alarm over the new LockBit 5.0 ransomware strain, which it warns is "significantly more dangerous" than past versions due to its newfound ability to simultaneously target Windows, Linux, and VMware ESXi environments. In a technical breakdown of source binaries obtained from recent attacks, Trend …
It just goes to show that although taking down the infrastructure is temporarily it's not substitute for taking down the people responsible. The solution to that would be to offer rewards for information leading to the prosecution of offenders. Information might include "So-and-So is asleep in room whatever of some hotel something in somewhere with an extradition treaty even if the last thing they remember is walking into a Moscow bar." Apart from delivering results it would leave then wondering how far they can trust those around them.
If an American or Brit is engaging in ransomware attacks, then I would say fair's fair. The risk with extrajudicial action, of course, is that an innocent person gets fingered and punished, which is the real problem. If all the ransomware scum, regardless of nationality, were to disappear, I'd have no problem with it, legal or not, but the likelihood is high that the innocent (or at least not guilty of this crime) would be caught up as well.
You can't do that kind of stuff without solid proof - like catching them physically hacking a server.
But if you get that - catch them in the physical act - making them disappear, I have no problems with.
They've got no regard for other people's lives - why should I care about theirs.
Yet Another Utopian Solution (YAUS). Sounds goob. But, in reality, the miscreants will predictably mostly find a number of ways to escape justice.
They may choose to operate from a country that doesn't much care if US/EU/UK operations are attacked -- North Korea, Iran, Russia.
and/or
They may choose to operate from countries where the local strongmen/authorities will overlook their activities for a cut of the revenue stream.
and/or
They may leave (a) trail(s) of digital "breadcrumbs" leading to some innocent party.
and/or
They may find ways to corrupt the enforcement agency/agencies.
and/or
They'll come up with some other protective scheme(s). It's not like they're stupid. If they were stupid, they probably wouldn't be a threat.
Like way too many simplistic "solutions" to complex problems this looks like the foundation of a Now you have two (or more) problems. The original problem and the unexpected consequences of the "solution".
• Spending days negotiating with ransomware scum and maybe shelling out in bitcoin
• Implement (& test !) decent backups and be up & running again after a few days hard work restoring your systems
In either case your systems are down for a bit, it is a matter of how long it takes to get back.
Am I misunderstanding something ?
.
Threatening to put your data up on the dark web is a different threat.
Yes, but not the point that someone planted something on your system.
It could sit there for a month, seeing when it could do the most damage or silently spreading.
Then activate and do its cryptographic thing.
So you wipe everything and re-install from the backup taken days before, and it's back- threaded through your network once again.
Incremental backups could show when it started encrypted, but wouldn't cure an infection.
I helped a company recover from ransomware, and the first thing the attackers went after was the backup server. The ESXi root passwords got scrambled as well, and the virtual machines on disk were encrypted and the filenames scrambled, so it might have been a version of LockBit (the customer declined to share the outcome of the forensic analysis). The thing that saved their bacon was storage array snapshotting, which allowed the affected virtual machines to be rolled back to a pre-ransomware state. Of course, the customer could have pulled their tapes from offsite, reconstructed the backup server from bootstrap, and recovered their data from tape, but that would have taken much, much longer, and assumes that the tape backups were complete, which is frequently not the case.
For an environment of significant size, "just recover from backups" is the nuclear option, to be avoided at all costs. Prevention is way better than cure.
>> For an environment of significant size, "just recover from backups" is the nuclear option, to be avoided at all costs. Prevention is way better than cure.
I agree but... as it is nigh on impossible to fully protect against this, well-practised recoveries should be considered essential. I would go for archived backups, read-only, managed completely separately from all the other infrastructure.
There are at least two ways of dealing with ransomware for DR purposes. You will have to accept that you will be losing some data and how much is up to you.
Option 1 is air gapped backups and this is the gold standard. The classic method is tape and you must remove the tapes from the robotics/drive and store them away from the production system.
Option 2 is something like Veeam's "Hardened Linux repo" and using immutability - This is a silver gilt standard method and you have to be very careful with this. A hardened repo uses a one shot admin account to setup a service for the repo - the username and password are not kept on the Veeam backup box after setup. Veeam will ask the service to set the immutable flag on backup files and only remove them after a set time. However, if the backup server has another way to get at the box housing the repos, then the flags can be removed.
Prevention is the best bet but is not infallible (its hard to prevent all future threats)! Air-gapped backups are the gold standard and a suitable LTO drive or two or a full robotics unit and a slack handful of tapes don't cost the earth.
a suitable LTO drive or two or a full robotics unit and a slack handful of tapes don't cost the earth
.. and I want anyone who objects to that expense to put in writing that they will pay back their bonus for saving money, twice, if it goes wrong. Directors can get it in the neck under DORA/NIS2 anyway or from their shareholders as it is now IMHO clearly a breach of their fiduciary duty.
This is what annoys me the most, some accountant objecting to the cost of a decent offline fallback - it's now very, VERY clear that there is a high probability that you WILL get hit, irrespective of how wonderful your IT team is (I am not prepared to believe that all that have fallen victim so far were slackers on the job or unaware of the risk).
As for the ESXi risk - seen it up close. Again, some cheapskate decided not to spring for the licenses that allowed for live updates, offline updates were cheaper. You guessed it: there was never enough downtime to do the updates, so when a Windows till system got compromised the ransomware found what was pretty much an open playground and encrypted all the VMs. They couldn't even operate their heating after that. And again, no decent backups either.
The thing that saved their bacon was storage array snapshotting
Which is one of ZFS' greatest features, among others. Of course your ZFS administrative password has to be separate from everything else, and you don't really want the same OS for that as the payload in case of common vulnerability, but in many cases you could be doing 3 hour snapshots with little overhead and less data loss on compromise. In fact, a high change in disk usage on snapshoting would be a simple indicator of encryption of mass data.
Sadly those at TrueNAS decided to drop FreeBSD in favour of Linux, making more of a monoculture for compromise.
Paul Crawford: "In fact, a high change in disk usage on snapshoting would be a simple indicator of encryption of mass data."
I've mulled this over many times. I'm sure there's an independent system to be had, maybe as a retro fittable hardware interface, which cuts of the data/SSD/storage device when it detects this.
I don't have worry about backup on a large scale but the simple system I run is a working set of discs which are on 24/7 with 2x ZFS systems as backup. But the 2x ZFS systems share only one power and network lead so one *has* to be air-gapped at all times. An Rsync client does the rest. It's very simple to manage.
> Trend Micro has sounded the alarm over the new LockBit 5.0 ransomware strain, which it warns is "significantly more dangerous" than past versions due to its newfound ability to simultaneously target Windows, Linux, and VMware ESXi environments.
How does LockBit initially infect the Windows, Linux, and VMware ESXi environments ?
Why are so many asking that question? It is not the same binary, but the probably same source code then compiled to the OS is should run on. The infection vector is used, the payload for your environment is dropped (which of course includes the payloads for all environments to spread in the LAN), and done.
There IS code out there which can actually run on multiple platforms, even multiple CPUs by genious combining of code which is basically "NOP" on one architecture, and a "Jump to this entry point" on another. But there is no need to get this far.
You don't need multiplatform binaries. All you need to do is write it in something like Python or Perl, which are interpreted, or Java that uses a JVM to execute the architecture independent intermediate code (OK, the JVM should be in a sandbox, but...).
I'm not saying that the code does not need to be tailored for the target platform, but the shipped code does not absolutely have to be a binary compiled for that target.
I believe that modern system design is lazy, and relies on unnecessary technical sophistication to try to enforce a secure 'flat' environment, when a segmented approach with airgaps can be both simpler, and IMHO more secure. If you can't move into a different domain because of physical separation and different authentication domains (I'm using this in a literal as well as a Windows sense), then the damage that can be done is very limited.
@Jou (Mxyzptlk)
My guess is that focus on the word "binary" might just be a distraction.
To the best of my knowledge Python3 runs pretty well on Windows, Linux and Apple machines.
I guess that there are other powerful interpreted languages with the same character across OS variants.
> Python3 runs pretty well on Windows, Linux and Apple machines.
Which is rather useless if not installed. Same for "perl" "java" and other strange suggestions. Linux python possibly, but usually not by default, perl for sure. if you are a malware writer you have to use the lowest of the APIs available, the one which is on all installations of those OS-es. For Win it is Win32/WPF and (depending on target) powershell 2.0 to 5.1. For Mac an Linux similar "lowest common" apis are there and their shells with scripting capability.
Unless you're talking ksh93, it can be difficult to do some of the more esoteric network scans and other OS manipulation from, say, bash. Shells generally do not have the ability to interact with a system at the network level, whereas things like Python and Perl normally have the ability to link to libraries giving access to a whole range of abilities provided in libraries that have to be on the system for other purposes. Such is the curse of dynamically linkable libraries and run-time linking.
Pretty much every general purpose Linux system I've seen recently have both Perl and Python installed, if only because package managers and other system admin. tools are written in those languages. Of course, this suggests that hardening an internet facing system should involve removing these powerful scripting languages, but you may then need to find other ways of administering the systems.
If you really want to make a Linux system, or other UNIX system significantly more secure, you could write all commands and utilities in a high level compiled language, and statically link them, and disable dynamic linking, but outside of embedded systems, how many systems are set up like this?
I grok'd this. There are apparently 2 vectors:
* Phishing e-mails
* internet-facing open ports of vulnerability
Once in, it scans the rest of the network looking for whatever it can find and does its dirty work.
So, to prevent problems:
* limit external access, especially RDP and things like SCP, VPN's
* don't use html mail or outlook or anything likely to make phishing attacks easier to pull off.
a firewall appliance probably a good idea too
At least one of the recent high profile attacks was a bad actor getting a password reset via the company helpdesk. Not sure why they aren't using 2FA.
And there are compromised employee attacks,
https://www.bbc.co.uk/news/articles/c3w5n903447o
don't work for Microsoft. Windows etc might then even worth using.
I suspect that the hurried, deranged deployment of AI "everywhere, all at once" as it were is going to make these malefactors' working lives so much easier.
In my experience most security failures in relatively well secured environments can usually be ascribed to a single expedient illadvised manglement decision.
What I cannot understand is that to recover from a Ransomware attack is very very expensive !!!
Why don't companies spend say 5-10% of that figure to train the users 'Properly' to avoid the usual methods that the malware gets into the systems in the first place.
Surely it is worth the price to close the door on this major problem.
The training needs to be realistic, to show how these things happen and the staff (top to bottom) need to be advised that 'non -compliance' means you become an ex-member of staff immediately ... no excuses or get out clauses.
This needs to be so draconian because people always believe they are an exception to the rules, particularly senior staff.
Training is cheaper than recovery !!!
The once a year 'training' that lasts an hour or so does not work ... as written it is simply an inconvenience that is lived with !!!
The lesson needs to be taught with a 'heavy hammer' and the seriousness 'hammered' home from day one for ALL staff !!!
:)
"Training is cheaper than recovery !!!"
But training is paid now, lowering quarterly earnings, while recovery might never be needed.
Also, the costs of recovery should be handled by future CE/FOs, costing them their bonuses. Training now would cost current CE/FOs their bonuses.
Getting hit by ransomware is bad, but installing Trend Micro's antivirus is even worse. Maybe it protects against the ransomware but the cost is your machines will suffer continuously from Trend Micro's software. I've seen that crap peg CPU at 100% and destroy laptop battery life doing god knows what.
I'm reading this article as I am experimenting with using Claude to create a Rust CLI application that calls a Python transformer (via pyo3) and it's working. I can easily add in a websocket monitoring mechanism using AI prompts. It all works, and it scares the crap out of me. FWIW, I'm developing on Linux, building Dockerfiles and .deb's, all using prompts.
Looking at the Cargo.lock and .venv/bin, there is an astounding amount of dependencies upon dependencies. It's the same thing with NodeJS (npm) and .NET (NuGet) projects that I've worked on . It's always been that way.
Except now of manually adding in package dependencies, AI will do it all for you, quickly and efficiently. Safety seems to be a non-consideration (at the societal, enterprise or individual level).
The absence of paid-for curated ecosystems for packages is disappointing, but maybe not surprising. Especially in AI/ML where you have to constantly get the "latest" to something to work, it may not be possible to review everything quickly enough. Inevitable, even if you could get enough developers and organizations to pay in, which seems doubtful, you still have the challenge of "keeping up" so that developers don't have to go outside of the ecosystem. Ultimately, a walled garden will have to have gates to sneak through.
Yes, we leverage VMs, containers, etc. to try and sandbox things; but ultimately whatever we build is going to have to run somewhere, accessing resources like databases, file systems, caches, etc. do whatever it is we built them to do.
Static analysis may be one answer, but it almost seems like that needs to be backed into cargo/npm/pypi themselves, as opposed to a tack-on that maybe gets run in a build pipeline.
I just don't see how individual developers can effectively mitigate all of this risk.
It's possible taking down the malware servers without catching or punishing the criminals may encourage rather than discourage criminal behaviour.
In related news, crypto-locker victims are surprised to discover their backups were intentionally compromised by the baddies before the ransom demanded.
While I'm very much in favour of frequent incremental backups using the snapshot features of modern copy-on-write filesystems, keeping administrative access to the backup server separate from all the other IT infrastructure is impossible unless the only way to log in to the backup server is through a physical VT52 terminal. Unfortunately, VT52s were in short supply when in full production during the 70's and they're even more difficult to find these days.
... should stop treating this filfth as "hackers" or "cybercriminals" and deal with them as what they are - Terrorists (domestic or otherwise).
They do more damage than a bomb set off somewhere.
These "people" have almost certainly killed by attacking hospitals and health centres, etc.
Don't send the police or alphabet agencies in when they're found - send a fully kitted-out tac-team.
If they're domestic - prosecute them for treason. If they're foreign nationals - stick them in a dark hole somewhere.
