New Site Recovers Files Locked by Cryptolocker Ransomware — Krebs on Security

Great news for those affected by the CryptoLocker virus.

But early Wednesday morning, two security firms – Milpitas, Calf. based FireEye and Fox-IT in the Netherlands — launched, a site that victims can use to recover their files. Victims need to provide an email address and upload just one of the encrypted files from their computer, and the service will email a link that victims can use to download a recovery program to decrypt all of their scrambled files.

The free decryption service was made possible because Fox-IT was somehow able to recover the private keys that the cybercriminals who were running the CryptoLocker scam used on their own (not free) decryption service. Neither company is disclosing much about how exactly those keys were recovered other than to say that the opportunity arose as the crooks were attempting to recover from Operation Tovar, an international effort in June that sought to dismantle the infrastructure that CryptoLocker used to infect PCs.


New Site Recovers Files Locked by Cryptolocker Ransomware — Krebs on Security.

The price of data sovereignty? $33.5million |

THE Australian Defence Force’s optometry service provider has been sacked after sending patients’ medical records offshore.

OPSM’s parent company Luxottica Retail Australia yesterday lost its $33.5 million contract with the ADF after sending Defence personnel’s optical claims information overseas for processing.

Full story here – Luxottica loses contract with ADF after sending diggers’ data offshore |

Why you should NEVER shrink your SQL data files | Paul S Randall

We were dealing with a client who had a very large database that was out growing their disk space.  Initial plan was to shrink the database to regain the almost 18GB of space that was not used anymore.  Started the shrink and found it was taking a very long time to complete.  Even worse when it completed performance was worse than before – even though the database was now smaller.  Strange!

It was at this moment that something snagged in my brain and I remembered something I had read about NEVER having AutoShrink and ONLY AS A LAST RESORT do a shrink. I  found the article and thought I would share it here:

From SQL Server Shrink

Shrinking of data files should be performed even more rarely, if at all. Here’s why – data file shrink causes *massive* index fragmentation. 


The only way to remove index fragmentation without causing data file growth again is to use DBCC INDEXDEFRAG or ALTER INDEX … REORGANIZE. These commands only require a single 8KB page of extra space, instead of needing to build a whole new index in the case of an index rebuild operation.


Valuable lesson learned!

Critical Update for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 | Microsoft

Important All future security and nonsecurity updates for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 require this update to be installed. We recommend that you install this update on your Windows RT 8.1, Windows 8.1, or Windows Server 2012 R2-based computer in order to receive continued future updates.

What this means is that unless you get this patch onto your client machines they will be unable to download and install security updates from May onwards… therefore you NEED TO GET THIS TESTED AND DEPLOYED OUT SOONER THAN LATER.

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 Update April, 2014.

More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack

We have been tracking the recent issue of “WordPress Sites Used for Distributed Denial of Service Attack” for a couple of days and the write up at Sucuri is very good explain the issues behind the latest Distributed Denial Of Service (DDOS) attack – basically ANY WordPress with the default install can be used to launch a DDOS attack against a specific target. What happens is that the “ping back” feature of WordPress is used to then bombard a third party with so much traffic it simply can’t handle it.

Sucuri has done a very good job in giving us a look into their logs of the recent attacks and I would recommend that ALL WordPress sites should be checked against the following service:

If you do decide to disable PingBacks (which is NOT recommended if you do have comments on your Posts) then the best option is to disable the XML-RPC function that supports PingBack via the following plug-in:

Note that this will also disable remote posting/editing (like is used in the iPad/Android WordPress platforms), so tread carefully with this change.

Also, you can do this yourself according to Brian Krebs:

As Sucuri notes, for the gearheads who don’t trust plugins, one easy way to block your WordPress blog from participating in these attacks is to create your own plugin that incorporates the following code:

add_filter( ‘xmlrpc_methods’, function( $methods ) {
unset( $methods[''] );
return $methods;
} );

Post Mortem of a Hack…

We had a call from a client recently that said that their site was hacked and it was serving up content not associated with them. We were a bit surprised by this as we monitor the site AND we also look for specific keywords to prevent this sort of hijack. Our immediate reaction was to investigate the cause of the hack but as the “redirected content” was of an adult nature, the client themselves rolled back the changes without keeping a copy of the hacked files. This left us a bit in the dark and with the monitoring software also “blind” to the change we had nothing to go on with.

What happened next was rather surprising: while trawling through the logs to see if we could find something of note, the hacker got in again and redid the hack. Quite nice of him/her to do that while we were watching as we then had a timeframe to work with (within 15 minutes) AND we could see the files that had changed.

Once we had that information we quarantined the changes, rolled them back and blocked the hacker’s IP address so we had stability and could investigate further.

What we found was a very sophisticated hack that targeted the .htaccess files on the server and setup a redirect that excluded MOST external monitoring solutions based on HTTP_USER_AGENT. The “polluted” .htaccess was quite extensive:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} …467 browser agents listed!… [NC,OR]
…some other conditions applied…
RewriteRule ^(.*)$ <<site>> [L,R=302]

As our monitoring system uses their own “UserAgent” setting this was not recognised by the HTTP_USER_AGENT pattern and therefore did not see the change to the site – so we never got the alert that the site had been altered.

Digging a bit deeper we found the root cause of the hack: an out of date WordPress installation with a misconfigured theme that allowed upload of PHP files that could then be run. This went searching for web application folders that had files that could be overwritten. While the client had “secured” their WordPress files by executing a chmod -w * they had not also executed that on the .htaccess files (as these are not picked up by the “*” pattern match).

Remediation Steps:

  1. Upgrade WordPress, the Plugins and Themes to the latest version
  2. Secure the .htaccess files
  3. Ensure that the wp-uploads directory does not allow server execution ANY files

We learnt a valuable lesson here and will be applying some changes to our standard setup procedures across ALL clients (whether they use WordPress or not). We are also reviewing the logs of the attack with a third party to see if we can track back to the individual(s) concerned.