This was published less than a day ago, thought it would be wise to bring to the attention of the team for any available performance improvements/detection opportunity.
CC @nivedithab if you would pass this along for review
2 Likes
I will share the details with the team to look at it and get back to you with feedback.
1 Like
Hi @BeeHiveCyberSecurity , there is no detailed information on what their EDR settings were, but I can say OpenEDR runs on unknown telemetry policy, meaning only unknown telemetry will be pushed. Therefore it is expected to see much less alerts.
I believe the user didn’t use ZeroTrust Containment within this test. If they did, Containment module would have catched this kind of attack already.
1 Like
If it’s any context, I’m assuming their testing scenario was using the Xcitium OpenEDR Default Policy with just Endpoint Manager and the EDR Agent. They did not specify building their own ruleset or making any changes to it and I’m assuming they didn’t spring to license XCS.
Alerts were generated while the user was testing that items were “Ran in Containment”.
Does this not imply that containment was active?
Does XCITIUM in general for researchers publish a “test this way” posture to follow? If not, could you?
My original purpose of referencing this here is not to highlight particularly a failure in protection, BUT a requirement for detection opportunity. “Run virtually in containment”, if nothing else at the lowest level alerts the blue team an unknown file has shown up in the environment. “Add file to Application Control” is more a feedback alert than an actual security-facing alert, as the adding here was done automatically.
To quote the article,
Aside from those alerts, it didn’t detect our file as malicious, it didn’t detect privilege escalation and it didn’t detect our credential dumping, we where able to successfully do most of the Red Teaming Attack Lifecycle without triggering any major alerts.
Even though there were alerts generated according to what again, I’m assuming is the XCITIUM OpenEDR Default policy, none of them are high fidelity or high severity enough compared to the offensive techniques accomplished - privilege escalation and credential dumping, as two major touchpoints. While during earlier testing he DID, trigger, a credential stealing alert, or as OpenEDR refers to it “Credential stealing with mimikatz”; he was able to also directly obfuscate the point of detection FOR that alert - meaning it was comparatively low fidelity.
Thoughts?
Hello i’m the author of the article just wanted to clarify I mostly used default settings and cloned default profiles, I added some folders to be excluded for testing purposes but when it came to testing the shellcode loader that would load the Sliver beacon the default containment rules where in effect.
Also when I started working on this I was originally using Havoc C2 instead of Sliver however my Havoc payloads didn’t work in containment forcing me to switch to try another C2.
1 Like