Thanks Mark.
We are following up as our engineering and research teams have reviewed the feedback.
A few days after we made our endpoint security integration generally available for all users, a security researcher explored how the endpoint security capabilities of Elastic Agent work and posted about their findings. This researcher uncompressed and decoded some artifacts placed on a host when endpoint security is installed, which led us to want to address two core points here:
- Elastic Security’s commitment to openness and our ongoing efforts to provide easy ways for community feedback.
- An analysis of the points raised in the twitter thread about some details in the artifacts.
As long as security software has existed, so have potential bypasses - both real and theoretical. From the early days of signature-based antivirus, to network intrusion prevention systems, to advanced security deployments we have been in a perpetual cat and mouse game between attackers and defenders. Attackers have almost always been able to bypass defenses, and generally they were advanced threats who could leverage these bypasses and keep them secret as they exploited organization after organization. This activity was primarily because security was kept largely a secret in terms of approach and technique. Elastic aims to take a wholly different approach.
At Elastic, we believe that being open and transparent is critical to everything we do. This is true of all our solutions -- Enterprise Search, Observability, and Security, where “security by obscurity” and closed/black box systems have failed for so long. This culture of openness is why we were especially excited to learn that security researchers have been exploring how Elastic Security works and the value of free and open XDR. Our mission at Elastic Security is to protect the world’s data from attack by making security open to everyone. The only way we can do that is to engage continuously with the security community and apply lessons learned from all areas of cyber defense.
We were not trying to “protect” these specific endpoint artifacts from analysis because there is no way to stop someone dedicated enough from accessing them as we have seen occur time and time again in the security industry. When we launched our SIEM detection engine capability last year, we pushed all our detection rules into the open in a public github repository. We are evaluating what else we can soon add to that repository, continuing our commitment to openness. Your feedback and suggestions are paramount to our success, and we will provide an easy place for you to communicate with our team.
We thank you for your passion for Elastic and for making us all more secure.
Details within the artifacts
There are a few points in the thread that we will address in this post and we hope the community will continue to engage with us in our discussion forums on this specific topic, and participate in our public bug bounty program.
- Decoding of Elastic Agent artifacts
The artifacts are compressed and then RC4 encoded is applied with a simple, symmetric key. The artifacts were not meant to be “secret” and we welcome your feedback on the contents.
- Digital certificate validation
Elastic does not use just string matching on the subject name of a digital certificate. Our Agent also verifies that the digital certificate on the file is valid (not revoked) and trusted by a root certificate. That is why we use multiple layers of prevention and detection - to try to minimize bypasses as much as possible. When Microsoft started requiring that device drivers be signed, it wasn’t so much for security reasons but rather to point to vendors that were causing BSoDs. When building ML models, behavioral rules, ransomware detection, etc., Elastic and other security vendors need a way to keep up with the constantly evolving software industry. Hashes are a very specific way to do that, but they do not usually generalize well. Instead, Elastic and other security vendors not only look at the behavior or characteristics of the file or program but also at the signer to determine if it is known to cause false positives but may not be malicious.
- Use of wildcard fields
When building behavioral preventions, we (and every other endpoint vendor) need to strike a balance between preventing what may appear as malicious behavior and avoiding business disruption due to false positives. We ship logic to suppress prevention and alerting for legitimate behaviors as we see them in the field. We offset the risk of bypass in a number of ways, including building many layers of prevention: for example if you rename your tool msbuild.exe but you aren’t Microsoft, our malware scanning will still evaluate it. If it’s ransomware, our behavioral and canary prevention will still detect and block the activity. If you inject into another process, our soon-to-be-in-production memory protection is likely to stop that. Additionally, we have many rules that look for processes masquerading as common filenames, so one alert may be suppressed but a separate alert will take place due to the masquerading.
- Canary files
Elastic security delivers multiple layers of ransomware protection. The canary implementation is just one of them. Our machine learning malware protection capability stops a significant amount of known and unknown ransomware. In addition, we employ master boot record protection (MBR) to stop an attacker from modifying the MBR. We also leverage a behavioral based approach to stopping ransomware should our machine learning model for malware protection miss the initial execution. Finally, as another layer of defense, we watch canary files placed on the file system. We aimed to balance operational impact and easy cleanup of the canary files over complete obfuscation - taking a measured approach. Combining the four+ layers of ransomware protection along with additional behavioral protections coming soon provide very robust protection against ransomware. We validate this by unit testing our entire suite of protections against a massive corpus of real world ransomware families. We appreciate the identification of areas for improvement and will continue to strengthen these protections.
In Conclusion
By providing our Elastic Agent and endpoint security integration available to everyone, we can bring to bear the power of the entire security community to make our product better for all users. We encourage this type of feedback, take it seriously, and use it to continue to protect the world's data from attack. Thank you for all the feedback and please continue to engage with us on this topic here.