Cryptowall 3.0 touching other network workstations

Just over two weeks ago, a client of mine had a Cryptowall 3.0 infection, starting from a workstation. It was quickly contained, and we restored from backup, and all is well now. One residual side effect caught me completely off guard, however.

Every Windows workstation on the domain began having the help_decrypt files launch at startup. We found those files in the startup folders on the local C drives of the workstations, as well as in many other folders on C. No files on any of those computers were encrypted, however.

I have never seen nor heard of a crypto variant showing this behavior. Did it find the C$ shares on the network?
smartytechAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
indeed this v3 variant used files with filenames as HELP_DECRYPT.HTML, HELP_DECRYPT.PNG, HELP_DECRYPT.TXT, and HELP_DECRYPT.URL and even new TOR gateways currently used by CryptoWall 3.0 are torforall.com, torman2.com, torwoman.com, and torroadsters.com.. Importantly, CryptoWall will encrypt data files on network shares only if that network share is mapped as a drive letter on the infected computer. If it is not mapped as a drive letter, then CryptoWall will not encrypt any files on a network share. This also means if you have DropBox mapped to a drive letter on an infected computer, CryptoWall will attempt to encrypt the files on the drive.

there is good info from BleedingComputer.com (http://www.bleepingcomputer.com/forums/t/563169/after-a-brief-hiatus-malware-developers-release-cryptowall-30/)

there is a small utility tool called ListCwall (http://www.bleepingcomputer.com/download/listcwall/) that automates the finding and exporting the list of encrypted files from an infected computer. It is useful as it also have option to provide backup (e.g. listcwall -m -b c:\backup) of the encrypted files to another location esp to archive those encrypted files and reformat the machine. Of course, what remains the same is that those files cannot be decrypted even if you are thinking of brute forcing which it is not worthwhile
0
smartytechAuthor Commented:
I am aware of that. My question was, how did workstation A place the help_decrypt files on the C drive of workstation B, C, D, etc, when there are no mapped drives between workstations?
0
btanExec ConsultantCommented:
will be best to look at the firewall or network logs coming from that "first" machine having that symptom and contained. At that pt of time, it may have shown the destination systems that it attempts to start the spreading. I suspect it may be the AD and check it event viewer for any recent gpo or login script push down to machine to "plant" this file from some central file server or even from this "first" machine.

It is a matter of tracing back as after action - most of the time is to perform forensic that "first"  machine to understand how it get infected and if it some external storage media, the same media may have been used in systems. It can be a phished email sent out as broadcast with links to some compromised site too...need to check the email client send folder of the originating machine ... too many variant and moving part to ascertain - we can only isolate that machine and dissect to start piecing up the puzzle pieces..

the key is those machines in domain is "infected" while the standalone or isolated from domain are not. it is still wise to check the registry and scan those domain machine. Traces left to all definitely means there is still possibility of the carrier in the domain somewhere and with someone or in some media /email...
0
smartytechAuthor Commented:
Having a hard time understanding your English; I think you are suggesting that multiple machines on the network were infected, including (or starting with) the server. That is not the case. We scanned multiple other machines, including the server, and none showed any infection. The only thing we found were the help_decrypt files placed on other machines.

The source of the infection was a user trying to download a driver or video player and becoming infected (he admitted as much).

I have never heard of a crypto variant being able to access anything besides physical/mapped drives. It appears this one did. I'm just thankful it only had the ability to create those help_decrypt files and not actually encrypt other computers.

Any suggestions to stopping a future infection from being able to create said files?
0
btanExec ConsultantCommented:
There are file of the IOC found on those machine, we cannot be sure they are not infected unless we understand where those files comes from. Who placed it, What is the content (same as the actual infected payload), Who place those files, How do those files come about? These are questions not answer - hence there is no confirmation those machines are clean unless examination of it assures that.

Noted the first infection is via visiting a site and the user's actual execution of the binary on prompted by the site.  so better to check
a) Any other user visited that same compromised website and check also the FW
b) Any further machines *before and after the first infected machine is removed has malware callback to the C&C
c) Any inserted thumbdrive user has during the period of infection before he is alerted by your security team and have his machine removed and isolated

Cryptolock3.0 does this spreading via mapped drived as shared, but I believe it may not be the end as the executed binary would have downloaded more malicious besides CLv3. The machine will need some forensic check to see any other infection trails - in startup folder or autorun registry or running process/listenting port showing any other anomalies or difference from the original machine build ...

For the prevention, as shared application whitelisting (see Cryptoprevent or Applocker) is a good mean and not giving user local admin right are good start. Also keep the machine patched as always and limit the no of user doing remote and do have explore the NAC prior to granting internal resource (including mapped drive).
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Security

From novice to tech pro — start learning today.