Crypto Locker Virus - how to find patient ZERO that started this?

That does seem odd.  You can identify the computer that initiated the problem by looking at local documents and seeing if they are encrypted or searching for the Crypto Help.html file on local drives.

Because of these sorts of viruses, I've been encouraging clients to be more restrictive in their shares.  That is, don't let all users have access to all shared files if you can avoid it.  In addition to limiting the damage, it can help narrow down the origin.

These viruses come in by spam, start there, ive had this come through our spam wall in an "auspost" australia post format, a pretty well written mail with a link inside no attachment.

if your spam company cant keep this out route it through mimecast! i bet they can. Spam and proxy prevention have gone to a 10/10 importance imo with these viruses.

Your AV is useless, it wont detect these files the EXE itself is often encrypted just so you know why perfectly good AV is getting blitzed by these things.

Right, we do the same, but this one seems to have been initiated in a way that included full admin rights (because the ADMINISTRATORS group shows as owner).  

On all files that you mentioned, it shows owner as "DOMAIN-NAME\Administrators" as owner.  Not a specific user.

who is part of the built in administrators group?

Shut down all Systems, even the servers, then do a forensic investigation on ALL affected HDDs, server and clients.
Find the disc that had things started first, this might give clues of where it started.

It might also be the attackers came in via a different trojan/keylogger. Stole admin credentials on infected system and put the cryptolocker directly into some systems with admin credentials, maybe even on the servers.

You should perform an offline AV-scan on all HDDs on the affected domain.

We found patient zero, it was 2 users that came in earlier than the rest, we checked against LOGIN TIME and FILE CREATION TIME of the "how to decrypt.htm" files.  Strangely, neither of these users were in any admin group of any kind.  

HOWEVER .... full permissions were granted at the SHARE and NTFS level, which would have let the user (or the attacking program) change file attributes.  This is a big reason to give read / change rights but NOT full control, IMHO.

About the NTFS level, im not sure. As far as I'm thinking of, a user without admin rights CANNOT assign admin ownership to files, even he has full control rights.

full control means only modify rights plus the user could change access permissions on the files and CLAIM ownership for HIMSELF, not admin.

If the files of the cryptor are admin owned, it means that the virus is running with domain admin credentials. It means your whole AD needs to be set up again from scratch.

The thing about the ransomware is that it will attempt to gain local admin privilege, provided that the victim has admin rights and with that able to dump out and encrypt as required on the infected machine. The account that changes those files is not significant to leading the investigation whom is the origin to start the infection. The means to gain admin can be stealing the admin credentials (spear phishing, social media etc) or through already machine login with user whom has admin rights or infected external storage etc. That is the prep work by the attacker, it may not necessary be leading to insider job etc but commonly this is an understandable worry.

There is other channel of infiltration via the poisoned email, spam, document with embedded exploits to download and dump out the ransomware. That are the leads we should be focusing on as well as the callback to specific IPs to the C&C servers. It is searching needle in the haystack but we need to make sure we are at the right haystack first - that is the suggestion that we can consider. The forensic of the workstation has to be done to piece out the trails of activities, looking at the ransomware files are not going to do us good to find the "source"...

Just a few cents..

It turns out that the file permissions must have been adjusted by the ransomware as I had suggested.  We have since removed the CHANGE OWNER permission in shares that users need full control on...now they have full permissions without this ability, and hopefully this will prevent the owner from being changed in the future so that we can quickly identify patient ZERO in future infections.  So far, in subsequent infections, we were able to look at the file owner to identify where this came in without error.