smartytech
asked on
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?
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?
ASKER
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?
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...
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...
ASKER
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?
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?
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).
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).
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
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