4 ms·

I bet they’ll start investing in backup solutions right about now.

hibbelig 6y ago
I recall a story here on HN, some days ago. A company was attacked, then the attackers waited some months to make sure that all backups had been contaminated, then they struck. So victims can only make sure that they have a malware checker that finds the culprit, then do fresh installs, then check each file before it's restored from backup. Sounds like a crazy amount of work.
- andreareina 6y ago
  Immutable append-only backups would protect against this, right? Nuke the OS to make sure you're running on good software, then pull in data that's as good as it was when it was backed up.
  - danielheath 6y ago
    Only to the degree that attackers can't figure out a way around them (given months of planning with access to internal systems & documentation). For instance: I have backups going to an append-only s3 bucket in a separate AWS account, but I don't have monitoring in place to ensure that bucket hasn't been wiped. An email would get generated, but it'd go to the root account holder, who may not notice in time.
    - andreskytt 6y ago
      Kinda makes me wish for the good old days when you could just store a pile of tape
      - nix23 6y ago
        Good old Days? There is a reason Financial Institutes still uses WORM tapes, and they are great!
  - hibbelig 6y ago
    The old backups are clean, yes. But newer backups (created after infiltration) will be contaminated. Immutable and append-only doesn't help because the files were already contaminated when backed up. The attacker could: get the victim infested with malware; ensure that the malware infects all new files; wait one year; then trigger the encrypt function. If the victim pulls a file that is newer than one year old from backup, the victim will pull the malware from backup. (Only if the file is of a type that could be infected in the first place, of course. README.txt will not be infected.)
lonelyasacloud 6y ago
How would restoring from backups also not risk restoring whatever it was that broke their world at the same time?
- beagle3 6y ago
  Proper backup does data independently from code, and proper devops is to always do an install from trusted source. It is unfortunately very rare to find this in practice - everyone seems to be happy with just snapshotting live systems as a backup these days; and it works well enough as long as there is no lingering systemic corruption of data. (And .... Excel, by mixing data with potentially malicious code, is beyond redemption. But good luck quarantining that in a modern suit controlled company)

I recall a story here on HN, some days ago. A company was attacked, then the attackers waited some months to make sure that all backups had been contaminated, then they struck. So victims can only make sure that they have a malware checker that finds the culprit, then do fresh installs, then check each file before it's restored from backup. Sounds like a crazy amount of work.

andreareina 6y ago
Immutable append-only backups would protect against this, right? Nuke the OS to make sure you're running on good software, then pull in data that's as good as it was when it was backed up.
- danielheath 6y ago
  Only to the degree that attackers can't figure out a way around them (given months of planning with access to internal systems & documentation). For instance: I have backups going to an append-only s3 bucket in a separate AWS account, but I don't have monitoring in place to ensure that bucket hasn't been wiped. An email would get generated, but it'd go to the root account holder, who may not notice in time.
  - andreskytt 6y ago
    Kinda makes me wish for the good old days when you could just store a pile of tape
    - nix23 6y ago
      Good old Days? There is a reason Financial Institutes still uses WORM tapes, and they are great!
- hibbelig 6y ago
  The old backups are clean, yes. But newer backups (created after infiltration) will be contaminated. Immutable and append-only doesn't help because the files were already contaminated when backed up. The attacker could: get the victim infested with malware; ensure that the malware infects all new files; wait one year; then trigger the encrypt function. If the victim pulls a file that is newer than one year old from backup, the victim will pull the malware from backup. (Only if the file is of a type that could be infected in the first place, of course. README.txt will not be infected.)

lonelyasacloud 6y ago

How would restoring from backups also not risk restoring whatever it was that broke their world at the same time?

beagle3 6y ago
Proper backup does data independently from code, and proper devops is to always do an install from trusted source. It is unfortunately very rare to find this in practice - everyone seems to be happy with just snapshotting live systems as a backup these days; and it works well enough as long as there is no lingering systemic corruption of data. (And .... Excel, by mixing data with potentially malicious code, is beyond redemption. But good luck quarantining that in a modern suit controlled company)