Malcolm Harkins, Cylance’s Chief Security and Trust Officer, provides some comments on responsible disclosure in response to researchers who claimed to have found a bypass for CylancePROTECT®.
Watch the video to hear more from Malcolm Harkins on this very important topic:
VIDEO: Malcolm Harkins Speaks on Responsible Disclosure
The Black Hills Information Security (BHIS) blog series entitled “Bypassing Cylance” focuses on tools and frameworks used to establish network connections for remote access. Some of the tools shown by BHIS have capabilities for injecting code into memory and downloading malicious code. However, the series did not focus on these capabilities and simply showed that the tool could run and establish a network connection. In some cases, the threat actor needed to make modifications to the configuration (e.g. copying and renaming powershell.exe) before they could even execute their code.
Importantly, the series did not establish how a malicious actor might gain access to a system to invoke these tools. Also, it did not mention that all the tools needed escalated privileges to modify system configuration, which none of the tools attempted during their series. That point would have been made obvious if the tools attempted to copy a file to a system folder or modify protected areas of the registry. (Of note: the series did highlight CylancePROTECT blocking any attempt to inject a meterpreter payload into memory.)
Cylance understands there are many paths to code execution on an endpoint and recommend the defense-in-depth approach we’ve always advocated. We appreciate the work BHIS did and welcome it. The issues highlighted by BHIS regarding PowerShell were already being worked to tighten up Script Control. Notably, we have only seen this behavior in testing environments. We have not observed malware attempting to copy and rename powershell.exe before invoking PowerShell scripts.
Looking Ahead
To be clear, no solution is 100% effective against attacks, and our Threat Guidance team is currently in the midst of digging into their claims to determine whether there is something our product missed or if the researchers just configured it improperly on their systems.
Regardless, it raises serious questions about responsible disclosure and the need for both vendors and researchers to have open and transparent communication around any potential product vulnerabilities. Researchers should report any issues they find in a product in order to allow vendors proper time to address their concerns and, if issues are confirmed, patch them before any customers are put at risk.
Vendors, on the other hand, are equally responsible to respond in a timely manner and work with researchers to validate or refute their claims.
Failure to adhere to ethical responsible disclosure practices does not further the field of security, and only serves to put organizations at risk.
