Does CS actually offer any real protection? I always thought it was just feel-good software, that Windows had caught up to separating permissions since after XP or so. Either one is lying/scamming, but which one?
Our ZScaler rep (basically, they technically work for us) come out with massive impressive looking numbers of the thousands of threats they detect and eliminate every month
Oddly before we had zscaler we didn't seem to have any actual problems. Now we have it and while we have lots of zscaler caused problems around performance and location, we still don't have any actual problems.
Feels very much like a tiger repelling rock. But I'm sure the corporate hospitality is fun.
Shouldn't that hit Crowdstrike's stock price much more than it has then? (so far I see ~11% down which is definitely a lot but it looks like they will survive).
If the idea is "we'll hire Crowdstrike for CYA" when things like this happen, the blame is on CS and they pay with their reputation.
EDR deployment is an outcome-modifying measure, usually required as underwritten in a cybersecurity insurance policy for it to be in force. It isn't itself insurance.
An attacker that's using a 0 day to get into a privileged section in a properly set up network is not going to be stopped by CrowdStrike.
Or a CS salesperson playing 3D chess with your comment.
If so, well played!
is there any writeups from the pentesting side of things that we can read to learn more?
https://www.offsec.com/courses/pen-300/
What kind of code should I read? Actually, let me ask this, what kind of code should I write first before diving into this kind of evasion technique? I feel I need to write some small Windows system software like duplicating Process Explorer, to get familiar with Win32 programming and Windows system programming, but I could be wrong?
I think I do have a study path, but it's full of gap. I work as a data engineer -- the kind that I wouldn't even bother to call myself engineer /s
It’s a great goal to eventually learn everything, but knowing the correct tools and techniques and how and when to use them most effectively are very different skillsets from discovering new vulnerabilities or writing new exploit code and you can start at any of them.
Compare for instance a physiologist, a gymnastics coach, and an Olympic gymnast. They all “know how the human body works” but in very different ways and who you’d go to for expertise depends on the context.
Similarly just start with whatever part you are most interested in. If you want to know the techniques and tools you can web search and find lots of details.
If you want to know how best to use them you should set up vulnerable machines (or find a relevant CTF) and practice. If you want to understand how they were discovered and how people find new ones you should read writeups from places like Project Zero that do that kind of research. If you’re interested in writing your own then yes you probably need to learn some system programming. If you enjoy the field you can expand your knowledge base.
When did Crowdstrike get this gold standard super seal of approval? What could they be referring to?
* NTLM/NTLMv1 enabled
* mDNS/llmnr/nbt-ns enabled
* dhcpv6 not controlled
* Privileged account doing plain LDAP (not LDAPS) binds or unencrypted FTP connections
* WPAD not controlled
* lights out interfaces not segregated from business network. Bonus points if its a supermicro which discloses the password hash to unauthenticated users as a design features.
* operational technology not segregated from information technology
* Not a windows bug, but popular on windows: 3rd party services with unquoted exe and uninstall strings, or service executable in a user-writable directory.
I remediate pentests as well as realworld intrusion events and we ALWAYS find one of these as the culprit. An oopsie happening on the public website leading to an intrusion is actually an extreme rarity. It's pretty much always email > standard user > administrator.
I understand not liking EDR or AV but the alternative seems to be just not detecting when this happens. The difference between EDR clients and non-EDR clients is that the non-EDR clients got compromised 2 years ago and only found it today.
unquoted paths are used to make persistence and are just an indicator of some other compromise. There are some very low impact scripts on github that can take care of it
Network segregation, the big thing I see in financial institutions is the cameras. Each one has its own shitty webserver, chances are the vendor is accessing the NVR with teamviewer and just leaving the computer logged in and unlocked, and none of the involved devices will see any kind of update unless they break. Although I've never had a pentester do anything with this I consider the segment to be haunted.
If customers wanted to configure them properly, they could, but they don't. EDR will let them keep all the garbage they seem to love so dearly. It doesn't just check a box, it takes care of many other boxes too.
What does this mean?
dumb admin: let me try .... boom game over man
maybe its the boomers that can't give up Outlook? Otherwise they could've migrated everybody to google workspaces or some other web alternative.
Just as an example: you use a mechanism similar to psexec to execute commands on the remote system using the SMB service. If the remote system has a capable EDR, it will shut that down and report the system from which the connection came from to the SOC, perhaps automatically isolate it. If it doesn't, an attacker moves laterally through your entire network with ease in no time until they have domain admin privs.
Running beacons with good EDRs is difficult, and has become the most challenging aspect of most red team engagements because of that.
No EDR, everything becomes suddenly super easy.
Many moons ago, I failed a "security audit" because `/sbin/iptables --append INPUT --in-interface lo --jump ACCEPT`
"This leaves the interface completely unfiltered"
Since then, I've not trusted any security expert until I've personally witnessed their competence.
Doing so regularly involved allowing additonal ciphers for SSL we deemed insecure, and undoing other configurations for hardening the system. Arguing about it is pointless - either you make your system more insecure, or you don't pass the audit. Typically we ended up configuring it in a way that we can easily toggle those two states, and reverted it back to a secure configuration once the customer got their certificate, and flipped it back to insecure when it was time to reapply for the certification.
Then our dealerships would just disable the configuration anyway.
It's been better in recent years.
Clearly shows lack of testing.
If intially good, probably culture & products have rotten.
Not fit to be in security domain, if like this.
I think the evidence shows that no, they aren't.