The malware needs to execute itself on each computer. But I would think this would be thwarted by hardware firewalls as well as apps like Windows Firewall.
If my PC at work gets infected, somehow it can magically infect the guy down the hall's PC too? I thought that was made impossible years ago.
In the case discussed in this article, attackers took three months between the initial compromise and the ransomware attack. One can do a lot in that time.
Some leverage known exploits against elements like LSASS, so if the person infected has credentials for another computer, why not slurp up all the credential tokens on remote computers that you can log into too.
If you use Linux/Unix on the other hand, you can do descent things to contain access. Firstly, elevated management accounts can restrict login sources, either by ssh authorized_keys or deny rules in sshd_config. Secondly, and very importantly, you can contain what applications can access through SELinux.
Running Windows these days is like walking around with "Kick me" hung around your neck.
As far as I am aware, the last time there was an actual exploit in LSASS was in Windows XP.
It may also have been a matter of servers getting infected, infecting hosted files in shares, and client machines open the files to get infected.
Or, as another user points out, domain controllers can readily do this.
Endpoints like PCs and servers check in with domain controllers at recurring intervals, so even if all endpoints are behind firewalls and can’t talk to one another, they still reach out to domain controllers periodically to pull down configuration updates and so forth.
Firewalls do absolutely nothing once someone got your weakest link to click something and go to town.
From my last penn test it goes, phish, get a click and execute or credentials, use a hack like getting legacy NetBIOS exploit to give up hashes for all your users, crack the hashes and hope someone used a short 12 char password or something dictionary-easy like “Wr3st1ing1!”, then leverage that access again and again until you have a printer that someone gave domain admin access to because it was easier than setting correct policies, an admin actual, a service not account that has good AD privileges, etc. Then start pushing software as admin.
Most of the time it’s not even this complicated.
The only thing that “saves” you from paying the ransom is good backups. But if a group is fairly competent, they’ll encrypt your backups too. So it needs to be offline.
I don’t have much love for Barracuda Backup, but for very little money you get nightly offsite backups that might just save your cyber insurance or company itself from having to pay.
Disaster recovery can be quick if you can restore hundreds of virtual servers (and you're going to have hundreds), whole key machines, and all the user and network config from backup. If all you have is data files and bare hardware, then the business is going to have a lot of expensive downtime while you rebuild all the infrastructure. "cattle not pets" approach and automated provisioning of machines from config files helps in this regard, but almost no company has that for all their critical infrastructure, especially if we're talking about non-IT companies whose critical infrastructure is not some single consumer-facing app (e.g. Twitter), but a diverse, distributed collection of third-party IT solutions for various business-critical needs.
This is the part I’ve never understood. Surely you should be backing up in an append only fashion initiated from the backup server?
My best guess is that this gets managed from AD as well, so they find it and take over?
The key idea is assuming everything is compromised. Whether you use append or whatever, is not helpful if the functionality to change that configuration exists, because that gets changed, backup server is gone, backup storage is gone, etc.
You have to design a system where even a rogue IT admin with full access to everything can’t screw you. Usually that involves third parties where there is no mechanism for a rogue IT person or other attacker to delete your offline backups. So some people have Iron Mountain pick up disks in a lock box daily, or use an online backup service that specifically has features for this, where they keep extra copies of your backups completely offline and provide no mechanism for the customer to delete them.
OK, brilliant — this is a nice articulation of a fundamental principle.
Do you know of any books that describe how to design such systems?
Guaranteeing that offline backups exist is a great start, but if the backups contain backdoors, restoring could be extremely laborious and yet unsuccessful.
I do wonder if some of my misunderstanding is because my experience is mostly SaaS companies, so paying external providers is more “natural” vs a company that makes its money selling units.
Related - see how many examples of S3 policies split access into read and write rather than read, append, write. It doesn't even matter where the logic lives - only whether the storage service allows you to delete anything.
The trick is to get another S3 account (or any large storage really), to download everything from that bucket periodically. The "replication" needs read-only access to the first bucket. The second account doesn't need to be accessed by anything or anybody so it is relatively safe.
Well, fw would be effective if organizations used network segmentation effectively, but of course close to no one does that in practice (e.g. usually IT/support have access to everything).
It is quite challenging to recover from this kind of breach since the attackers had every opportunity to touch every system connected to the AD and leave backdoors behind. I have seen companies trashing their whole AD, re-imaging all machines and basically starting from scratch at great cost.
(They might still have to reimage all their machines but at least they still have a list of employees and customers)
https://www.bleepingcomputer.com/news/security/evil-corp-blo...
> The initial compromise of an organization involves the SocGholish framework, which is delivered to the victim in a zipped file via compromised legitimate websites.
> The zipped file contains malicious JavaScript, masquerading as a browser update.
So are people just like "this random website is trying to download a browser update, ok I'll unzip it and run it, even though I never normally have to do this". Seems plausible.
Then:
> Privilege escalation was performed using a publicly documented technique [there's a link] involving the Software Licensing User Interface tool (slui.exe), a Windows command line utility that is responsible for activating and updating the Windows operating system.
> The attackers used the Windows Management Instrumentation Command Line Utility (wmic.exe) to execute commands on remote computers, such as adding a new user or executing additional downloaded PowerShell scripts.
It's not really clear to me how local privilege escalation allows you to execute commands on remote computers though.
If it's a privileged user, then you can move to many more workstations, if it's a non-privileged user then you may be able to use their normal access (email, network shares, access to internal applications) to try and trip some privileged user into compromising their workstation in a way that you could not from the outside. Or you can wait a month until some tech support person logs in to that workstation and you can steal their credentials.
Extreme example: you can think of an air gap as a "firewall" with all deny rules. Air gaps are pretty secure. (Yes, there are still way's in but finding them will be many orders of magnitude harder than finding a 0day in a "next-gen" firewall).
Another example: I put all printers in a dedicated VLAN and block all traffic in and out except specific print ports from the print server IP only. In practice, way more secure than any "next-gen" firewall will ever be.