<story><title>QuickBooks Cloud Hosting Firm iNSYNQ Hit in Ransomware Attack</title><url>https://krebsonsecurity.com/2019/07/quickbooks-cloud-hosting-firm-insynq-hit-in-ransomware-attack/</url></story><parent_chain><item><author>johngalt</author><text>A generally safe backup process looks like this:&lt;p&gt;Production has no access to backup.&lt;p&gt;Backup has read only access to production.&lt;p&gt;Backup writes are append and not overwrites.&lt;p&gt;Deletes&amp;#x2F;archival are governed by a retention process.</text></item><item><author>AdmiralAsshat</author><text>This is a question I&amp;#x27;ve thought alot about, so many some Sys Admins can give a good idea about how to approach it:&lt;p&gt;How do you create a backup server that is reachable by production servers (so that they can back up to it) &lt;i&gt;without&lt;/i&gt; then being vulnerable to the same kind of ransomware attacks that infect the production servers? You can&amp;#x27;t exactly make them read-only, or else they can&amp;#x27;t accept the &amp;quot;legitimate&amp;quot; writes that might occur during the normal backup process.</text></item></parent_chain><comment><author>ipython</author><text>One absolutely diabolical mechanism that was used (at least 5 years ago when this scourge of ransomware started to rear its ugly head) goes something like this:&lt;p&gt;1. Gain access to change the code on the front-end web servers (usually PHP)&lt;p&gt;2. Change the database access layer to transparently encrypt data being written to the database, and decrypt data being read from the database. The key would be loaded into memory by curl&amp;#x27;ing an attacker-controlled website at startup.&lt;p&gt;3. Wait 30 days&lt;p&gt;4. Notify the company that they&amp;#x27;re compromised, turn off the attacker-controlled key service, and restart the web front end&lt;p&gt;Now step (3) ensures that most data in the database has been re-written, and if your backups are dumps of the production database, you now have a month of encrypted backups that you can&amp;#x27;t read... If you&amp;#x27;re lucky, you may have a month-old backup to restore from; if you&amp;#x27;re unlucky, you rotate every 30 days.</text></comment>
<story><title>QuickBooks Cloud Hosting Firm iNSYNQ Hit in Ransomware Attack</title><url>https://krebsonsecurity.com/2019/07/quickbooks-cloud-hosting-firm-insynq-hit-in-ransomware-attack/</url></story><parent_chain><item><author>johngalt</author><text>A generally safe backup process looks like this:&lt;p&gt;Production has no access to backup.&lt;p&gt;Backup has read only access to production.&lt;p&gt;Backup writes are append and not overwrites.&lt;p&gt;Deletes&amp;#x2F;archival are governed by a retention process.</text></item><item><author>AdmiralAsshat</author><text>This is a question I&amp;#x27;ve thought alot about, so many some Sys Admins can give a good idea about how to approach it:&lt;p&gt;How do you create a backup server that is reachable by production servers (so that they can back up to it) &lt;i&gt;without&lt;/i&gt; then being vulnerable to the same kind of ransomware attacks that infect the production servers? You can&amp;#x27;t exactly make them read-only, or else they can&amp;#x27;t accept the &amp;quot;legitimate&amp;quot; writes that might occur during the normal backup process.</text></item></parent_chain><comment><author>gowld</author><text>Also, backups must include a physical process of moving a copy of backups to an airgapped secondary system (a human ejecting disks&amp;#x2F;CDs&amp;#x2F;tapes and carrying them to another storage container), so that it&amp;#x27;s impossible for an attacker to compromise the backups via the same software exploit that corrupts the primary data.</text></comment>