It’s the snake oil industry. They don’t sell security, they sell CISO get out of jail cards in the form of client agents that constantly remind you of their divine presence by being on top of the CPU utilization sorted process list.

There is a LOT of snake oil in the industry, but endpoint protection IS useful. Not every person is a Hacker News reading tech enthusiast. People download and do dumb shit. That is not to say every device needs it and at a max “check every process/file activity” level, though.

Endpoint Protection may be useful but credibility is everything in the industry.

CrowdStrike has done loads to damage their own credibility to anyone paying attention, but because they've chosen to be favorable to certain power players along political lines there are folks out there that treat them like the be-all-end-all of the industry.

As someone in-industry, hearing people parrot press releases from CrowdStrike has me looking at them sideways.

Edit/Addendum: Just to lay bare my opinion of them... CrowdStrike is a clown-ass company run by clown-ass people and with a clown-ass product.

10% of Falcon is blocking dumb shit people do. 90% is blocking things people are supposed to be doing, and have been doing successfully so far.

Nothing starts your week better than "After the latest definitions update, Falcon heuristic started quarantining your core business tools as suspicious".

They fixed it with an update this month, but CrowdStrike was hooking /every/ single call to NtCreateUserProcess on my work machine last month, and you /know/ how electron-based apps work. VSCode took so long to launch its sub processes it would pop up a crash reporter. "Hello World" compiled from C++ would take a minute to launch sometimes. WSL straight up could not be started because the TTY timed out waiting for it.

For some reason java.exe startup was A-OK though so I started using JEdit again.

Aggravatingly, it would occasionally disappear my builds and then flag me to IT. My dude, I am hired as a developer of native windows C++ applications why the hell is this trash on my would-be workstation-class machine?

Your organization and your IT department expect you to work around these issues by doing development on your personal machine, and then copying it to your work machine while pretending like you never tunneled to your personal machine from the office.

That's what it feels like with some of these policies.

> They fixed it with an update this month, but CrowdStrike was hooking /every/ single call to NtCreateUserProcess on my work machine last month, and you /know/ how electron-based apps work. VSCode took so long to launch its sub processes it would pop up a crash reporter. "Hello World" compiled from C++ would take a minute to launch sometimes. WSL straight up could not be started because the TTY timed out waiting for it.

There's nothing wrong in hooking ~EvErY~ call to NtCreateUserProcess or even a thousand other functions in and of itself. The issue is what they're doing inside those hooks.

We have installed another product that also hooks +@EvErY sInglE@+ call to NtCreateUserProcess and to couple dozen other functions and you know what? VSCode works just fine. WSL too. Edge and Chrome too.

Sure there's a measurable effect on performance but nothing like you're describing.

Because your organization's customers demanded your employer get some security certificate, and part of that certification is hoisting that BS on all users

java.exe was probably excluded.

I know what I'm calling my next exploit ;)

These are usually hash-based so you'll need to actually write it in Java or something more modern running on the JVM. Good thing is you'll only need to write it once and it will run anywhere!

I feel your pain at a deep and spiritual level. I have been in charge of at least half a dozen endpoint protection products over the years (deployment, configuration, management, etc.). Once a user experiences what you just described they are (rightfully) suspicious and sour towards endpoint protection.

Questions i would ask in your example: 1) Was the core business tool excluded from the more intrusive protection modules or does the tool have a significant risk surface? 2) What was the threshold set for quarantining? Does it make sense in this case? 3) Is/should your device be part of a "Developer" policy that is more permissive? Are all users of the tool impacted? 4) Does this happen frequently? If so, should definitions be manually pushed in batches so everyone is not nerfed at once. 5) What is the process for the developer to report/fix the false positive? Is the response time sufficient?

I'm probably forgetting a few. The point is, shit happens (especially with technology). You respond, fix, and hopefully learn. If shit happens a lot, its either because the tool owner doesn't give a shit or the product is shit itself. The delicate balance of security and business operations/innovation is all about weighing and evaluating risk/benefit.

Can I ask, since you're as a person who has administered endpoint protection products: how much legitimate stuff do they actually catch?

I work in offense and they can be a huge impediment. Significant work goes into bypassing or staying undetected from these products. While not all the detection occurs at runtime, they report a lot of data back from the endpoint so historical detection can happen.

However what I see is essentially their true positive and false negative rate, I would be interested to know what the false positive rate is.

Yeah, I guess this all boils down to your threat model in the end. As your post seems to indicate, if a dedicated attacker targets you, they're probably going to be able to work around the endpoint protection anyways.

I'm more curious about the case if your org is a few thousand people and you receive random low-effort attacks distributed across those people, will endpoint protection be a panacea?

Not OP, but I've worked for an endpoint protection product company. Part of the onboarding was them loading up a virtual machine with the endpoint installed, then demonstrating several attacks (installing malicious software, running scripts off the internet, etc) and showing the logs of what the endpoint detected, and at what point it shut down the malicious behavior.

The examples shown were behavior based, not hash based. It didn't look up a file in a dictionary, it detected priviledge elevations and such.

No product is perfect, but if you have a need to be protected (especially if you are at risk from adversaries such as in banking, health care, government work, or against corporate espionage) I'm quite confident in saying that you're much better off with it than without.

The same company would also, at random times, attempt to phish us or send us fake emails to get us to click on links, to help educate us on the kinds of threats our customers faced I consider myself fairly savvy, and even I fell for one of them.

I ended up leaving for a variety of reasons, but "losing faith in the product" was not one of them.

You should’ve also demonstrated attacks like ”open the line-of-business app we’ve used daily for years”. My problem is not the hit rate on actual attacks, it’s the hit rate on collateral damage

I'm not the guy above but the better ones can be very useful. And if they are behaving that badly and impeding your work THAT much then it is most likely that the person in your org configuring it just sucks as their job.

Nobody else is running your binaries, so they don’t match the hashes of any of the trusted binaries in the database. Obviously they’re suspect & should be quarantined immediately!

Endpoint protection is theoretically useful.

In practice, most implementations cause more harm than good. Some of them even add vulnerabilities themselves.

I would agree for some of the old guard antivirus (looking at you McCrappy) but with the better ones you are also paying for a huge amount of analytics and reporting. If you are dealing with a breach (even a small one) it can be really really nice (and reassuring especially for people at higher levels) to have nice easy to consume data on what the chain of attack was and where it started.

Nothing you mentioned on the plus side is actually increasing security. It's really just compliance and potentially containment. Some things that could be done to increase security:

- penetration tests paired with employee security training incorporating those results

- updating every piece of software and IOT device as frequently as possible

- don't use products that execute macros when you open documents and train users to click the allow button

- have a functioning SSO system in place and don't rely on something being on the "internal network" as a security measure. Don't have credentials shared between employees, use SSO instead.

- universal usage of MFA and password managers

Download and run mimikatz on an endpoint protected by said “snake oil” and one without. Note the difference.