Ransomware Detection Capability
-
Lets put more emphasis on detection more than protection.. Your client running some code that infects is not going to be prevented from doing that by running an IPS at your firewall - but sure as such traffic flows over an IPS it could detect such traffic and stop it from from going across that interface.
You would need to be running IPS between all your internal networks, and that does nothing from devices on the same network, etc.
-
Ransomware often uses C&C servers that can be thwarted by a dnsbl as well, by stopping requests to those domains you can prevent infection with less resource use than a IDS/IPS.
For example https://ransomwaretracker.abuse.ch/blocklist/
-
Doesn't prevent infection.. Blocking C&C only tells you have something infected to be honest.. While this is part of detection and sure a valid piece in the security walls you put up..
User runs code - infected, all their stuff encrypted.. How does your blocking their C&C prevent that?
Users are really the weakest link in any security chain.. You want to prevent infection get rid of the users ;) But I am the million visitor to this site, I just won and IPad I need to click that link to claim it.. Oh looks like I just got an invoice for something I never ordered - better open that file, etc. Oh look at that - free usb stick here on the ground, wonder whats on it ;)
-
User runs code - infected, all their stuff encrypted.. How does your blocking their C&C prevent that?
Usually before the encryption begins, there's a key exchange that takes place between the malware and the C&C server. If communication to the C&C server is blocked, then you can at least extend the amount of time to remove the malware before it finds a way around the block.
-
[quote[quote author=virgiliomi link=topic=142895.msg779074#msg779074 date=1516330952]
Usually before the encryption begins,
And which idiot malware writer would do it that way? It would be stupid to do it that way… Not saying there might not be variants that work that way..Don't get me wrong - blocking known C&C would not be a bad thing.. And is a valid piece in security... I just do buy that its a "prevention" method.. I would see it as a detection - since the client is not going to attempt to contact C&C unless they are already infected or in the process of being infected. So how is that prevention ;) Prevention is the act of preventing something from happening.. Knowing something happened is detection..
-
I agree with johnpoz, this just for detection. Machine is still infected.
-
At the risk of jumping into a cat fight, I will offer some observations to this discussion – ;D
Snort can be both a detection and prevention platform. It really depends on the specific malware, and even more so on the specific strain of a given malware. Using the example of a file encrypter such as Wannacry, if you were the malware author here is probably how you would code it.
Once you get your dropper package on a victim, have the dropper phone home to a C&C server for two things. First, it will register the IP address and/or some other information about the specific victim host. Second, it might ask for the encryption key to use on the victim. If I were the malware writer, the last thing I would do is hardcode the encryption key inside the dropper package. It would be discovered in short order and my scheme would collapse. Also, I would likely not use the same encryption key for every victim. This would prevent victim "A" from sharing the "purchased" decryption key witih victims "B", "C" and so on. I would use a number of encryption keys, and perhaps even create a unique key per victim. That information exchange is what talking back to the C&C host would be about. After all, the malware creator has to know what decryption key to "sell you" when you pay the ransom to get your files back. So either he does something foolish and hard codes the key in the malware, or he is more sophisticated and uses one or more C&C servers to send keys to ransomware installs. That way he can associate keys with victims. This assumes the malcreant is honest at some level as in he really intends to unlock your files when you pay the ransom in Bitcoin.
So using my points in the example above, you can see that if Snort or any IPS can prevent the back channel communication to the C&C host, it can potentially prevent the malware from encrypting the files. Plus, the detection of the C&C communication attempt alerts the admin that something is amiss on the victim. So two proverbial birds have been killed with the single IPS stone. Granted that technically speaking the victim is still infected with the file encrypter dropper, but its malicious intent was thwarted and an alarm was generated to alert the cops so to speak. So from one point of view you could say the malware was prevented from doing its thing on the victim host.
I'm not saying every ransomware package works this way, but some do. So for malware that needs to get further instructions from a C&C server before proceeding with its dirty work, an IPS like Snort, Suricata or even pfBlockerNG can act as a form of prevention by blocking the attempt of the malware to get instructions from HQ.
Bill
-
Valid points…
And sure make sense to get a new encryption for every victim machine - but why would I not have a fallback encryption to use if can not contact c&c for new unique key.
Shoot for that matter some of them encrypt without any actual way to decrypt, etc. Your files are gone be it you pay the ransom or not, etc. The second your machine executed some code it shouldn't have all bets are off.
Once that happens it all just becomes detection and containment. You can prevent it from spreading throughout your network.. But you didn't prevent the box from running that bad code by running your IPS..
pfblocker could be seen as more of prevention method than IPS.. Since it can block the user from going to places that they could pick up the bad code and have it run on their machine, etc. Blocking traffic based upon dest be it direct IP or fqdn could be seen as prevention - blocking specific traffic by its content that is known to be bad traffic is not prevention its just detection and containment of the bad traffic.
Blocking said bad traffic based upon its content inbound before it touches your servers would be prevention.. Say blocking a possible sql injection, etc.
-
Valid points…
And sure make sense to get a new encryption for every victim machine - but why would I not have a fallback encryption to use if can not contact c&c for new unique key.
Shoot for that matter some of them encrypt without any actual way to decrypt, etc. Your files are gone be it you pay the ransom or not, etc. The second your machine executed some code it shouldn't have all bets are off.
Once that happens it all just becomes detection and containment. You can prevent it from spreading throughout your network.. But you didn't prevent the box from running that bad code by running your IPS..
pfblocker could be seen as more of prevention method than IPS.. Since it can block the user from going to places that they could pick up the bad code and have it run on their machine, etc. Blocking traffic based upon dest be it direct IP or fqdn could be seen as prevention - blocking specific traffic by its content that is known to be bad traffic is not prevention its just detection and containment of the bad traffic.
Blocking said bad traffic based upon its content inbound before it touches your servers would be prevention.. Say blocking a possible sql injection, etc.
All true, and there are exceptions and special cases to consider for each point of view. My point was just to chime in that detection and prevention can sometimes be co-mingled, but it depends on the specific circumstance of malware, victim and IPS. In my hypothetical example I assumed the malware author is marginally "honest" and intends to actually unlock your files when you pay the ransom. Of course that is not guaranteed to be the case. Thankfully I've never had to deal with the issue either privately or in my former professional IT life.
Bill
-
I agree with johnpoz, this just for detection. Machine is still infected.
Correct… you haven't prevented the infection, but you have prevented data loss from occurring. And you still have the opportunity to remove the infection without incurring any data loss. Of course, if you're not backing up your data, shame on you... but that's a different story. :)
-
How does your blocking their C&C prevent that?
It doesn't always but it depends on the variant - for example CrytoLocker will stay dormant (and does not encrypt files) if it cannot reach the designated C&C server.
Has that kept it out? No. But you now have a hit on your DNSBL which you can use to isolate an infected machine.
