Email Archived Attachments

Berkleigh, we've been really lucky so far to not have been affected by any ransomware but I'm am always concerned about this. Can you please elaborate on your suggestions. Is there some steps we could follow from you on how to do this? Any insights would be much appreciated.

Berkleigh, we've been really lucky so far to not have been affected by any ransomware but I'm am always concerned about this. Can you please elaborate on your suggestions. Is there some steps we could follow from you on how to do this? Any insights would be much appreciated.

Berkleigh, we've been really lucky so far to not have been affected by any ransomware but I'm am always concerned about this. Can you please elaborate on your suggestions. Is there some steps we could follow from you on how to do this? Any insights would be much appreciated.

Sure, while I'm most familiar with SonicWALL hardware the same rules can be applied on Sophos as well. Here is the KB from Dell regarding Cryptowall 2.0, most of this also applies to Cryptowall 3.0 except it uses I2P which can be locked down on the SonicWALL but I'm still looking for where to set it on a Sophos unit.

https://support.software.dell.com/kb/sw12434

On the Sophos go to Web Protection and then activate Application Control.

Click on the Application Control Rules Tab

Create a New Rule, call it whatever you like.

Click on the folder icon under Control These Applications

Type TOR in  the search bar and scroll down to the entry for TOR

Put a check mark in TOR and TOR Directory

Click Apply

Click Save

That will at least block TOR which is used by ransomware to encrypt and store your files.

If you want to really knuckle down when selecting what applications to block just set Productivity to 1 and Risk to 5 and then select all applications listed.

Rather than trying to prevent it from getting in, which can be darn near impossible, blocking its method of going out and getting what it needs to cause the damage is the next best thing. Once you trap it inside your network you can look at the logs to figure out which computer is infected and take steps to clean it up.

Update 1: I did some experimenting with I2P by installing it on one of my Android phones. While inside my network protected by a Sophos UTM I connected to the I2P network and was able to browse .i2p sites using the built-in browser so long as I opened up all outgoing ports from the phone to the internet. It does not appear as though the Sophos will recognize or stop an I2P connection which is a shame because the SonicWALL units DO have a setting in Application Control for I2P, I guess +1 for them.

The verdict appears to be, for now, close all outgoing ports except the ones you absolutely need and you will be relatively safe from CryptoWALL. Sophos really needs to step up and add I2P/EKE blocking immediately if not sooner!

Update 2: So a BIG -1 for SonicWALL, even though they have a setting in app control for I2P the I2P app on my phone gets right past that. At this time it looks like blocking I2P on anything is a daunting task, been toying with blocking some of the ports found here https://geti2p.net/en/faq#ports but have really only slowed it down perhaps someone else will find the combination of settings to effectively block this.

Looking like blocking Encrypted Key Exchange will do the trick, we will soon find out. Unfortunately blocking Encrypted Key Exchange appears to break things like secure web mail and Cisco VPN Client.

Here is some marketing hype from Sophos, not really helpful in regards to telling us how to block it though.

https://blogs.sophos.com/2015/03/03/anatomy-of-a-ransomware-attack-cryptolocker-cryptowall-and-how-to-stay-safe-infographic/

Update 3: Blocking EKE on the SonicWALL was a bust, initially it seemed to work but I2P found a way around that. So I decided to test the theory about blocking NTP (port 123) to see if it would interfere with I2P connecting, unfortunately it did not make a big difference. I gave it some thought and wondered if altering the time on the PC would mess with I2P. Sure enough, I cranked the time forward an hour and lo and behold, I2P failed to connect. It appears as though the security mechanism  used by I2P relies on accurate time at both ends, hence the need for NTP. Reminds me of Windows AD and Kerberos a little. If you run a Windows domain then all of your workstations will get their time from one of the Domain Controllers which you probably want to allow NTP access to using custom firewall rules.

So it appears the easy way to protect yourself from ransomware is to block NTP at the firewall and offset the PC clock FORWARD by an hour, then change your Time Zone to account for the offset so the clock appears correct to the user. Underneath your clock is still off by an hour and will mess with I2P to the point where it won't work. Not an elegant solution but it appears to work, use caution though as this may mess with other secure connections such as VPNs or secure web pages although I tested it with SonicWALL NetExtender and some secure sites and had no issues, YMMV.

Update 4: The time shift method works but only manages to slow I2P down,  eventually it finds a way to compensate. Best defense at this point is to block everything going out except what you need to function, even then it may find a way to use those ports after a while. This method may actually work against ransomeware as it may not be as sophisticated as the actual client itself and not be able to handle the time shift. 

If there were only a way to import a list of IP addresses to block, then we could log the ones the I2P client connects to and import the list into firewall rule to block them. Better yet would be the ability to create new rules on the fly based on IP addresses that are blocked by another rule. 

For example, the I2P client on my phone uses port 12214 to communicate to the I2P network and get what it needs to do what it does. If a firewall rule to block that port could then create new rules to block those IP addresses we would have them beat. Ransomware will likely try every port it finds it can get out on to communicate with I2P so no matter what you do you can't stop it. If a rule could have the ability to create new rules based on the addresses it blocked then it would not matter what port it went out on, the destination would be blocked by a new rule. Sort of an AI 'learning' firewall that builds its own rules, might be a first in the industry. All you would need is one machine on the inside with a working I2P connection, the firewall would then do the rest, each time it would block an ip address accessed by the I2P client the client would try another and it would be perpetually self-updating.

Another option might be to use I2P against itself, when an I2P client initiates a connection it downloads a list of hosts from the i2p-projekt.i2p server called hosts.txt, it also goes out and gets another file called newhosts.txt. The files appear to be in some kind of encrypted format but the API docs on their website should give enough info to get meaningful data from them. Armed with those lists it should not be too hard to create a new firewall rule to block them all, of course this would be an ongoing process as I'm sure new i2p hosts pop up every few minutes.

Bottom line, the best defense is a good offense, have plenty of backups, make backups of those and store them either offsite or preferably on the cloud. And for G_d's sake stop mapping drives in Windows already, what is this 1995? Linux hasn't had mapped drives EVER and it works just fine. XP is dead, 7 and 8 should be able to handle UNCs, if your software is so old it can't handle them then ditch it and move on or upgrade already. And for the love of Pete, quit disabling UAC (I know it is a PITA) and stop making people local administrators already!

Here are a few good links about CryptoWALL 3.0 and how it works, creating a rule to block the IP addresses in the Cisco blog might go a long way in preventing I2P communication although I'm sure the creators have long since added more addresses to the list by now.

http://blogs.cisco.com/security/talos/cryptowall-3-0

https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=776