6 ms·

How is ransomware able to spread to all the PCs in a company? (Especially PCs at different locations around the globe) The malware needs to execute itself on

How is ransomware able to spread to all the PCs in a company? (Especially PCs at different locations around the globe) 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.

core_dumped 6y ago
Firewalls can only protect against what's known. Once you've invented or discovered a method the firewall doesn't know about, you're trusted as much as any regular program. Sometimes even changing the binary or payload slightly will thwart some firewalls because they're precise machines looking for precise signatures. It's not super easy to get past a firewall with a known vulnerability, but not impossible. With a 0day the firewall is almost irrelevant.
- packet_nerd 6y ago
  This is true regarding "next-gen" firewalls. But, if you design a plain old segmentation strategy with simple but well thought out allow/deny rules, then a firewall will be pretty valuable in many situations. 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.
halfcat 6y ago
Probably through Active Directory, which has the ability to deploy software. If a domain controller was compromised, the payload could be pushed out across the board. 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.
- SV_BubbleTime 6y ago
  Pretty much this. 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.
  - aj3 6y ago
    > Firewalls do absolutely nothing once someone got your weakest link to click something and go to town. 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).
  - scott_w 6y ago
    > 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. 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?
    - viraptor 6y ago
      This is definitely doable, but it's harder than the naive solution so often it's not done. Same as log storage for example, or any other incremental data. 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.
Kalium 6y ago
Depending on how the network is configured, node-to-node spread may be possible. Firewalls - hardware or software - are not magic and can definitely miss things. 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.
eikenberry 6y ago
It's common to install security management software on systems to allow for centralized update push. That system was probably comprimizsed and used to push out the ransomware.
aj3 6y ago
Apart from some special cases like Wannacry/NotPetya, ransomware crews do only as much lateral movement as is required for privilege escalation. Once they have DA, they can just disable protections and push malware centrally through AD.
- dredmorbius 6y ago
  DA / AD ???
  - danielheath 6y ago
    Domain Admin (root permission in Active Directory).
    - dredmorbius 6y ago
      Thanks, suspected that.
- TwoBit 6y ago
  It seems like a company's real challenge is preventing the escalation, more so than the initial compromise.
nuker 6y ago
Here is the diagram https://www.bleepingcomputer.com/news/security/evil-corp-blocked-from-deploying-ransomware-on-30-major-us-firms/ https://www.bleepingcomputer.com/news/security/evil-corp-blo...
- IshKebab 6y ago
  That doesn't actually say at all. Symantec's report has more detail but it still has gaps: > 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.
  - PeterisP 6y ago
    If you gain local privilege escalation on some workstation user, you can gain access to credentials of user(s) of that workstation which allow you to impersonate that user throughout the network. 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.
  - SturgeonsLaw 6y ago
    Windows caches the logons of the last few users as a hash on the local PC, malware can use those hashes to authenticate against network resources as that user. If one of those users was a domain admin, on most networks they can access just about anything
PeterisP 6y ago
The key point there is that all the recent major events generally are not an automated attack by a simple virus, in such situations the malware opens a command&control link that is [ab]used by multiple skilled people for weeks to gain persistence, move laterally throughout the network, find systems and user accounts with elevated privileges, disable monitoring and backups, deploy to all machines just as your administrators can (because at that point they are the de facto admins of all your systems) and only "pull the trigger" of ransomware when all the prep work is done. 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.
darkhorn 6y ago
Some of our Windows computers were affected but none of our Linux computers were affected.
6c696e7578 6y ago
The common components in the ransomware attacks is Windows and AD. 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.
- lostmsu 6y ago
  None of what you mentioned requires a lot of effort on Windows. Exploits in LSASS are no different from exploits in Linux kernel, and if you stay up to date and configure everything correctly you should be fine.
  - user5994461 6y ago
    LSASS is a system process, need SE_DEBUG_PRIVILEGES to read its memory (full system administrator). As far as I am aware, the last time there was an actual exploit in LSASS was in Windows XP.
- viraptor 6y ago
  I think your generalisation doesn't work once you get to sites with advanced staff and budget. For example this will stop all but extremely targeted attacks: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview https://docs.microsoft.com/en-us/windows/security/threat-pro... but it requires a lot of time managing and the more varied things you do, the more annoying it will be to manage. (+ It's probably impossible for devs)
- lrnStats 6y ago
  This needs to be flagged

core_dumped 6y ago

Firewalls can only protect against what's known. Once you've invented or discovered a method the firewall doesn't know about, you're trusted as much as any regular program. Sometimes even changing the binary or payload slightly will thwart some firewalls because they're precise machines looking for precise signatures. It's not super easy to get past a firewall with a known vulnerability, but not impossible. With a 0day the firewall is almost irrelevant.

packet_nerd 6y ago
This is true regarding "next-gen" firewalls. But, if you design a plain old segmentation strategy with simple but well thought out allow/deny rules, then a firewall will be pretty valuable in many situations. 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.

halfcat 6y ago

Probably through Active Directory, which has the ability to deploy software. If a domain controller was compromised, the payload could be pushed out across the board. 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.

SV_BubbleTime 6y ago
Pretty much this. 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.
- aj3 6y ago
  > Firewalls do absolutely nothing once someone got your weakest link to click something and go to town. 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).
- scott_w 6y ago
  > 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. 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?
  - viraptor 6y ago
    This is definitely doable, but it's harder than the naive solution so often it's not done. Same as log storage for example, or any other incremental data. 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.

Kalium 6y ago

Depending on how the network is configured, node-to-node spread may be possible. Firewalls - hardware or software - are not magic and can definitely miss things. 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.

eikenberry 6y ago

It's common to install security management software on systems to allow for centralized update push. That system was probably comprimizsed and used to push out the ransomware.

aj3 6y ago

Apart from some special cases like Wannacry/NotPetya, ransomware crews do only as much lateral movement as is required for privilege escalation. Once they have DA, they can just disable protections and push malware centrally through AD.

dredmorbius 6y ago
DA / AD ???
- danielheath 6y ago
  Domain Admin (root permission in Active Directory).
  - dredmorbius 6y ago
    Thanks, suspected that.
TwoBit 6y ago
It seems like a company's real challenge is preventing the escalation, more so than the initial compromise.

nuker 6y ago

Here is the diagram https://www.bleepingcomputer.com/news/security/evil-corp-blocked-from-deploying-ransomware-on-30-major-us-firms/ https://www.bleepingcomputer.com/news/security/evil-corp-blo...

IshKebab 6y ago
That doesn't actually say at all. Symantec's report has more detail but it still has gaps: > 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.
- PeterisP 6y ago
  If you gain local privilege escalation on some workstation user, you can gain access to credentials of user(s) of that workstation which allow you to impersonate that user throughout the network. 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.
- SturgeonsLaw 6y ago
  Windows caches the logons of the last few users as a hash on the local PC, malware can use those hashes to authenticate against network resources as that user. If one of those users was a domain admin, on most networks they can access just about anything

PeterisP 6y ago

The key point there is that all the recent major events generally are not an automated attack by a simple virus, in such situations the malware opens a command&control link that is [ab]used by multiple skilled people for weeks to gain persistence, move laterally throughout the network, find systems and user accounts with elevated privileges, disable monitoring and backups, deploy to all machines just as your administrators can (because at that point they are the de facto admins of all your systems) and only "pull the trigger" of ransomware when all the prep work is done. 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.

darkhorn 6y ago

Some of our Windows computers were affected but none of our Linux computers were affected.

6c696e7578 6y ago

The common components in the ransomware attacks is Windows and AD. 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.

lostmsu 6y ago
None of what you mentioned requires a lot of effort on Windows. Exploits in LSASS are no different from exploits in Linux kernel, and if you stay up to date and configure everything correctly you should be fine.
- user5994461 6y ago
  LSASS is a system process, need SE_DEBUG_PRIVILEGES to read its memory (full system administrator). As far as I am aware, the last time there was an actual exploit in LSASS was in Windows XP.
viraptor 6y ago
I think your generalisation doesn't work once you get to sites with advanced staff and budget. For example this will stop all but extremely targeted attacks: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview https://docs.microsoft.com/en-us/windows/security/threat-pro... but it requires a lot of time managing and the more varied things you do, the more annoying it will be to manage. (+ It's probably impossible for devs)
lrnStats 6y ago
This needs to be flagged