Weirdness with Office 2013 opening Network Files

We had a client with document open problems. They can open up Word/Excel/PowerPoint from a document attached to an email by either clicking on it or saving to their desktop and then double clicking BUT if they double clicked on a network file it opens up a Blank Document dialogue (the standard Word/Excel dialogue when you just open up the program).

We tried repair of Office (both Quick and Full – and even re-licensed Office) without success. We tried resetting the the file associations – with no luck. We did a compare of local Word settings to the clients (luckily the same version) but still no luck.

What we then did on a computer that worked was the capture the actual command (via PROCMON) that gets used when we double click on a document to open it up:

"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "<<documentname>>"

So, we then did this on the client’s computer. In order to save a bit of typing we decided to take a local copy of the document to C:\temp\ so we had:

C:\Temp>"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "C:\Temp\Test Document.docx"

as the command to open up Word with that document.

Bizarrely it worked! So, we then decided to open up the document from the S: (shared) drive and that failed (well, it started up two copies of Word – one that died and then the second one that opened up the Word start up screen):

C:\Temp>"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "S:\Administration\Test Document.docx"

We then decided to see if opening it up using the full path worked – and it did:

C:\Temp>"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "\\SERVER\Shared\Test Document.docx"

So, we had “lucked in” and now had some more information to work with. This managed to get us via Google to the following article: Office docs from network drives won’t open, specifically:

Same problem here. Windows 2008R2, Office 2013 Standard after moving from Xen to VMWare virtualization. I just wanted to say that this problem is also affecting us, but as I was typing, our Admin called back.

He created a new account, which had never used Office 2013 before and that worked!

He then deleted then %APPDATA%\Local\Microsoft\Office folder from an account that didn’t work, after which Office claimed that the profile was corrupt, but then it started normally, regenerated the profile and he can now open the files.

It might be worth renaming this folder and seeing if that works for you.

So, we closed ALL Office programs and renamed the Office folder (we ran this as Administrator to ensure we could rename the file):

C:\Windows\system32>cd \users\TheUser\AppData\Local\Microsoft

C:\Users\TheUser\AppData\Local\Microsoft>ren Office Office.strange


And then we tried that command again:

C:\Temp>"c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE" /n "U:\Administration\Test Document.docx"

And this time it worked!!!

Now, the client may have lost some settings/preferences – but at least he can now open up Word by double clicking.

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.

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!

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.