Is there something in progress, already covered, just wondering what the status is and where I stand on that with my current WSA deployment.
Thanks!
Does WSA protect against the newest Flash zero day that is in the wild? July 2015
+56Yep, we'll protect you against any malware or antivirus payload that is installed via that exploit. Also, Adobe is planning to have a patch out later today to close this vulnerability.
+56And there is a patch out now for the Flash vulnerability, so make sure you update.
I have recently been moving my clients to Webroot, based almost solely on Webroot's claims against superior protection against Cryptolocker and its variants.
Unfortunately, I have had 2 clients (both running Webroot) become infected with Crypolocker via the new zero day exploits. One client was hit on Monday and the other was hit on Wednesday. In both instances, Webroot never killed the offending process and also in both instances, the "journaling" that webroot is supposed to be performing to allow local file rollbacks also didn't work. Needless to say, I am pretty concerned regarding Webroot's protection of Cryptolocker.
On Monday's infection, I found this line in the webroot log file that coincided with the precise time of infection:
Mon 2015-07-13 11:49:32.0013 IR: A highly suspicious action was attempted: C:UsersUsernameAppDataLocalTempA21C.tmp (1)
Unfortunately, Webroot didn't do anything about that "highly suspicous" threat and it went on to take out a server ( which we recovered from backup ). When I asked Webroot Tech Support about that, they responded:
When InfraRed (IR) detects a highly suspicious action the process is terminated. The process was running entirely in memory so when it was terminated there was nothing on the disk to move to the quarantine. There is no alert or notification of this in the software or console at this stage as we prefer to shut the process down as fast as possible. Unfortunately it appears that the malicious process was able to inject the encryption process into a legitimate windows process which allowed the files to be encrypted.
The rub is that while the above answer seems logical, it is contrary to what actually happened. The payload dropped at 11:49 and immediately went to work encrypting the user's local machine and then moved on to the server.
This has happened at 2 completely different installations this week.
As a result, can you please provide some additional information on your statement regarding Webroot's protection ability?
Unfortunately, I have had 2 clients (both running Webroot) become infected with Crypolocker via the new zero day exploits. One client was hit on Monday and the other was hit on Wednesday. In both instances, Webroot never killed the offending process and also in both instances, the "journaling" that webroot is supposed to be performing to allow local file rollbacks also didn't work. Needless to say, I am pretty concerned regarding Webroot's protection of Cryptolocker.
On Monday's infection, I found this line in the webroot log file that coincided with the precise time of infection:
Mon 2015-07-13 11:49:32.0013 IR: A highly suspicious action was attempted: C:UsersUsernameAppDataLocalTempA21C.tmp (1)
Unfortunately, Webroot didn't do anything about that "highly suspicous" threat and it went on to take out a server ( which we recovered from backup ). When I asked Webroot Tech Support about that, they responded:
When InfraRed (IR) detects a highly suspicious action the process is terminated. The process was running entirely in memory so when it was terminated there was nothing on the disk to move to the quarantine. There is no alert or notification of this in the software or console at this stage as we prefer to shut the process down as fast as possible. Unfortunately it appears that the malicious process was able to inject the encryption process into a legitimate windows process which allowed the files to be encrypted.
The rub is that while the above answer seems logical, it is contrary to what actually happened. The payload dropped at 11:49 and immediately went to work encrypting the user's local machine and then moved on to the server.
This has happened at 2 completely different installations this week.
As a result, can you please provide some additional information on your statement regarding Webroot's protection ability?
+56I shared your post with the threat research team here and here's their response:
I am sorry to hear about the difficulties you've had with these infections. Although uncommon, some new zero-day malware variants will initially go undetected if the samples don’t match any known patterns until our Threat Research team analyzes them, which in most circumstances will occur within minutes of first exposure. New malware variants may initially evade detection because the authors of this software are constantly implementing changes to counteract detection techniques. Our Threat Research team is constantly on the lookout for new samples of encrypting ransomware and are continually writing new rules and heuristic signatures to detect them, but it is an ongoing battle.
While the journaling that WSA performs is useful in rolling back the damage performed by most infections, it is important to understand that this potentially may not work in all cases, depending on the evasion techniques utilized by the malware. In the event that journaling is not possible for a new malware variant, our development team updates the agent code to accommodate for the new techniques. Unfortunately we cannot divulge the details about these modifications in our release notes as malware authors will use this information to circumvent our detection algorithms.
To answer your question regarding InfraRed, this is triggered when WSA detects an action that is highly suspicious. The (1) from the provided log entry indicates that the agent detected an action that is usually associated with encrypting ransomware variants. When this occurs, WSA will attempt to terminate the process that is attempting the action. Unfortunately there are some cases where this cannot be done safely, which I assume is what happened here.
We have just implemented a number of improvements to the memory scanning functionality of the WSA agent as of version 9.0.0.64 that have allowed us to create much more effective heuristic signatures for encrypting ransomware. We are currently working to release further engine enhancements specifically designed to heuristically detect this family of malware.
I am sorry to hear about the difficulties you've had with these infections. Although uncommon, some new zero-day malware variants will initially go undetected if the samples don’t match any known patterns until our Threat Research team analyzes them, which in most circumstances will occur within minutes of first exposure. New malware variants may initially evade detection because the authors of this software are constantly implementing changes to counteract detection techniques. Our Threat Research team is constantly on the lookout for new samples of encrypting ransomware and are continually writing new rules and heuristic signatures to detect them, but it is an ongoing battle.
While the journaling that WSA performs is useful in rolling back the damage performed by most infections, it is important to understand that this potentially may not work in all cases, depending on the evasion techniques utilized by the malware. In the event that journaling is not possible for a new malware variant, our development team updates the agent code to accommodate for the new techniques. Unfortunately we cannot divulge the details about these modifications in our release notes as malware authors will use this information to circumvent our detection algorithms.
To answer your question regarding InfraRed, this is triggered when WSA detects an action that is highly suspicious. The (1) from the provided log entry indicates that the agent detected an action that is usually associated with encrypting ransomware variants. When this occurs, WSA will attempt to terminate the process that is attempting the action. Unfortunately there are some cases where this cannot be done safely, which I assume is what happened here.
We have just implemented a number of improvements to the memory scanning functionality of the WSA agent as of version 9.0.0.64 that have allowed us to create much more effective heuristic signatures for encrypting ransomware. We are currently working to release further engine enhancements specifically designed to heuristically detect this family of malware.
Hi.
Do you have a sample of this threat, which encrypted your files? May you send it to me? 😉 Wanna test it.
Thank you
Daniel
Do you have a sample of this threat, which encrypted your files? May you send it to me? 😉 Wanna test it.
Thank you
Daniel
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.