|
psydude posted:Definitely. Automated containment and response (such as issuing an 802.1X change of authorization upon detection for quarantine) is becoming a big selling point right now. Companies are spending shitloads on tools like this, without any staff that knows how the gently caress to actually use them (actually, this is true for any infosec budget spending lately). It's completely nuts. Even large, well-funded enterprises I've worked with are prone to it. The EDR tech is super cool (and I really do dig the host isolation features) when it's deployed correctly, but it's still used in a sort of reactive manner by most companies, just struggling to play whack-a-mole with monitoring events. It's nice to not be completely dependent on finding someone from the helldesk in a remote office and tell them to unplug someone's network port asap (and pray they pull the right one) though. So, great solutions but the implementation tends to be lackluster. Kudos to the companies that do it well, though. For today's WannaCry ransomware hilarity, most of the prevention was super straightforward (and should have been planned for in general incident response plans and security strategies), and there's a shitload of methods to mitigate specific capabilities of the malware. The best part was the researcher who jumped in and registered the C2 domain and sinkholed it though, which really took the wind out of this one before it could get much, much worse. Unfortunately, the genie's effectively out of the bottle and this worm/ransomware hybrid poo poo is going to become the new normal. One of the bigger challenges will be moving from a narrower focus on things like AppLocker and other application whitelisting solutions to impair the malware executables' ability to run, and also having to focus on the long-forgotten worm mitigations we stopped thinking about after Conficker mostly died off, and looking at more granular network segmentation, analyzing protocols and services in use, how shares are utilized, etc. Disabling SMBv1 isn't going to be doable for everyone for ~reasons~ but should be considered for most portions of the network, for example (and I'm totally generalizing here). That helps prevent the self-propagation aspect for the most part. After that, you're back to the usual ransomware bullshit: dealing with malicious documents, lovely email gateway configurations, and easily-misled users.
|
#
¿
May 13, 2017 00:54
|
|
|
|
| # ¿ May 20, 2024 19:22 |
|
|
windshipper posted:For your normal, every day Joe, what would you recommend doing to prevent this sort of thing happening to them? Beyond the standard, "Don't click funny links in weird emails, don't visit weird websites, etc"? I'm assuming you're coming at this from a personal user thing, rather than for a business-like environment, so I'll take that angle. Aside from what you said, which is still correct, the best basic poo poo that works for me:
Most malware affecting regular folks these days typically comes in via email, or by exploiting vulnerabilities in web browsers and their plugins. So the main course of action is simply to try to limit that surface area by being aware of what you're using and how you're using it. The email stuff preys on peoples' short attention spans, and uses basic social engineering to goad them to open things. Somehow people still fall for anything marked as a FedEx or UPS notification. Edit: and let Windows run its damned updates. Don't sit there and wait three weeks telling it to delay. Oct fucked around with this message at 01:32 on May 13, 2017 |
|
#
¿
May 13, 2017 01:29
|
|
|
psydude posted:Certain products (Cisco AMP, Palo Alto TRAPS) can flat out prevent ransomware from executing once they're on the target machine. These are just now starting to gain mainstream adoption in larger enterprises, though. Yup, we resell AMP (and Carbon Black, Crowdstrike, etc. etc...) as a VAR, so I've gotten all of the dog and pony shows (please don't take me as being dismissive, unless your marketing basis is that your product is powered by AI or Machine Learning though, I don't post often but tend to agree with you). I work on the IR consulting side, so the vendors to show off for us, hoping we will use the tools in engagements (and recommend them to clients, naturally). The adoption rate on EDR has really stepped up over the past year and a half. Thing is, I've seen all of these products fail on ransomware more times than I can count. They are still awesome for response, and they're not bad by any means, but I don't trust them more than traditional AV for prevention (but I love being able to trace back infection vectors for root cause analysis with these newer solutions). I still see better success in that area by either mitigating the infection vectors, or more extensive endpoint hardening. I suppose I'm a big proponent of using a scalable, manageable solution that is flexible, but backing it up with low- or no-cost mechanisms too. I mostly agree with your comment on MSSPs as well. They're incredibly helpful for augmenting internal security staffs. That said, quality SOC analysts who don't get burnt out are in short supply, and a lot of the ones I've seen entering the field (either for MSSP or internal ops) are not getting the right training. There's a huge gap in critical thinking skills that is killing efficacy, and throwing money at the problem doesn't seem to be the answer. And that doesn't even begin to get at the other issues like continuing to perceive security exclusively as a cost center too. It's gonna continue to be rough for a while here, but I guess that's good for job security. Too bad it lets the slackers continue to skate by too though.
|
|
#
¿
May 13, 2017 04:27
|
|
|
Mr. Nice! posted:He didn't figure out what the domain did until after he registered it. That's the dangerous part. It's a fair concern, however it would also be pretty inconsistent with the way ransomware (and most commodity malware, botnets, etc.) tends to function. His blog post (linked in the tweet) summarizes what is most likely correct: the authors used the unregistered domain as a poor anti-sandbox technique. Most modern sandboxes (as well as analysis VMs like Remnux) use a fake DNS and webserver configuration. By having the malware attempt to resolve that fake domain (some analysis writeups noted that the domain looked like random keyboard mashing on the home row and number keys), it would know it was being detonated in a sandbox if it received a valid response. This in turn would cause the malware to stop executing and not fully unpack and deploy its payload. Again, yes, in a certain sense it's careless to register a domain without context, but given our understanding of common malware functionalities, it would be pretty unlikely to see a valid domain query response met with some sort of dead-hand scorched earth switch. Because the author's objective is to make money, there's little value in that (because of the crypto, there's little point in adding the code needed to destructively erase the encrypted data to impair forensic recovery; doing so adds a lot of additional layers of complexity and custom coding, which costs them more money). Similarly, they know that it's pointless to do if it's being run in a sandbox (because the analyst doesn't give a poo poo). I'm inclined to believe this was more of a proof of concept run, with the side effect of making a bit of cash. The author will probably be able to afford some better anti-analysis code with the cash they made this time around.
|
|
#
¿
May 13, 2017 19:39
|
|