{"id":14405,"date":"2025-07-08T01:30:47","date_gmt":"2025-07-08T01:30:47","guid":{"rendered":"https:\/\/newestek.com\/?p=14405"},"modified":"2025-07-08T01:30:47","modified_gmt":"2025-07-08T01:30:47","slug":"discovery-of-compromised-shellter-security-tool-raises-disclosure-debate","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=14405","title":{"rendered":"Discovery of compromised Shellter security tool raises disclosure debate"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

CISOs whose staff use the commercial Shellter Elite antivirus evasion software to detect vulnerabilities need to immediately update to the latest version after the recent discovery that threat actors are using a stolen version to distribute malware.<\/p>\n

It\u2019s not because the abuse of security tools is news \u2014 it isn\u2019t. Threat actors have been leveraging stolen or copied versions of the Cobalt Strike<\/a> adversary simulation tool for years to help in their attacks. But for CISOs, this incident raises another question: How fast should security researchers notify a vendor that a product has been compromised before publicly announcing the vulnerability?<\/p>\n

In this case, on July 2, Elastic Security Lab, part of the Elastic search platform, which also makes an endpoint security solution, blogged that it found<\/a> multiple infostealer campaigns using what appeared to be a compromised version of Shellter Elite 11.0 to get around IT defenses.<\/p>\n

That version of the application was released April 16. Elastic says that, late that month, its researchers identified multiple campaigns deploying various information stealers protected by Shellter Elite.<\/p>\n

In a reply on July 4, the Shellter Project thanked Elastic for providing manipulated samples that helped the vendor confirm the identity of the customer involved, who is believed to have leaked their copy of the software subsequently taken advantage of by threat actors. Shellter says it has a \u201crigorous vetting process\u201d to determine who is allowed to buy its security products, but \u201ca company which had recently purchased Shellter Elite licenses had leaked their copy of the software\u201d to outsiders.<\/p>\n

But Shellter also blasted Elastic <\/a>for not alerting it quickly. \u201cElastic Security Labs chose to act in a manner we consider both reckless and unprofessional,\u201d the company complained in its blog.\u00a0\u201cThey were aware of the issue for several months but failed to notify us. Instead of collaborating to mitigate the threat, they opted to withhold the information in order to publish a surprise expos\u00e9\u2014prioritizing publicity over public safety.<\/p>\n

\u201cDue to this lack of communication, it was sheer luck that the implicated customer did not gain access to our upcoming release. Had we not postponed the launch for unrelated personal reasons, they would have received a new version with enhanced runtime evasion capabilities\u2014even against Elastic\u2019s own detection mechanisms.\u201d<\/p>\n

Shellter Elite has a number of capabilities, including managing the runtime evasion steps necessary for red teams to load their command and control beacons that would attempt to conceal test attacks from defending blue teams. These capabilities, which would be valuable to threat actors, include the ability to evade static and dynamic analysis.<\/p>\n

Asked for a reply, in an email today to CSO, the Elastic Security Labs team said it became aware of potentially suspicious activity on June 18. Its blog, however, says that in late April its researchers noticed multiple financially motivated infostealer campaigns that had been using Shellter to package payloads.<\/p>\n

Asked to explain the discrepancy in dates, Elastic said the file creation metadata of the malware samples were obtained in June.<\/p>\n

Elastic also says in its statement to CSO that it \u201cpromptly began investigating behaviors we identified as previously undetected malicious activity using publicly available information and telemetry voluntarily shared by our users. Following our initial investigation and after rigorous analysis, we determined that the publicly available tool, Shellter, was being used for evasion purposes. Our findings were published within two weeks of this determination.\u201d<\/p>\n

The blog and research were \u201cconducted in line with our commitment to transparency, responsible disclosure, and a defender-first mindset,\u201d the statement says.<\/p>\n

\u201cWe publish our findings directly and transparently to inform defenders as quickly as possible, as is industry standard and part of the work for our customers and users,\u201d the statement adds. \u201cOur priority is to inform the security community promptly and accurately about our research. We believe the public interest is best served by disclosing research as quickly as possible, once a thorough analysis has been concluded, to help defenders respond to emerging threats, including techniques used to bypass security controls.\u201d<\/p>\n

Asked for comment on whether it has heard from Elastic, a Shellter spokesperson said it outlined its position in its blog.<\/p>\n

However, one expert says this isn\u2019t a case of ethical vulnerability disclosure. Instead, says Robert Beggs, head of Canadian incident response firm Digital Defence and a user of Shellter products, it\u2019s a clash of very different perspectives on keeping networks secure: Offensive (Shellter) versus defensive (Elastic).<\/p>\n

\u201cThe\u00a0entire goal of Elastic is to be able to detect the Shellter application,\u201d Beggs said in an email to CSO.<\/p>\n

\u201cWhy\u00a0wouldn\u2019t Elastic want to publicize that it has the ability to detect a tool like Shellter\u2019s?\u00a0Being able to do so goes beyond good publicity, it demonstrates the real value of Elastic against a tool that is designed to hide from it.\u201d<\/p>\n

\u201cShellter might not like it,\u201d he said, \u201cbut Elastic did a good analysis of the event\u201d in its blog.<\/p>\n

There are no ethics between two diametrically opposed vendors, he argued.\u00a0\u201cImagine if a company found that their product was used to bypass Microsoft Defender, a common defensive tool,\u201d he said.\u00a0\u201cIs there an ethical obligation to immediately warn Microsoft?\u00a0 Or, is it the responsibility of Microsoft to monitor the environment, identify failures of its own tool, reverse engineer WHY the failure took place, and then alter Defender to compensate for the new attack?\u00a0 Clearly, Microsoft has always assumed the responsibility of looking after its own tool, and making it effective at its job.<\/p>\n

\u201cIn the same way, Elastic is not responsible to go to Shellter to tell Shellter how their tool is being used, or how they can detect it,\u201d he wrote.\u00a0\u00a0<\/p>\n

\u201cShellter has not made its case,\u201d Beggs maintained.\u00a0\u201cThere is no \u2018ethical violation\u2019.\u00a0 Elastic did a great job of finding the \u2018enemy\u2019 and should enjoy the reward of reporting this to the world. Shellter has tried to take the high moral road, apologizing to its customers for \u2018the inconvenience this may have caused\u2019.\u00a0 What inconvenience?\u00a0 Someone else misused a product that does not impact any other customer in any way.<\/p>\n

\u201cShellter has created a tempest in a teapot, invoking a concept of \u2018responsible disclosure\u2019 that really does not exist between vendors of offensive and defensive products.\u00a0 And considering this to be some violation of non-existent ethics is an extreme, and poor, interpretation of the events,\u201d Beggs said.<\/p>\n

There are no hard rules for vulnerability disclosure. However, a number of organizations do have guidelines.<\/p>\n

For example, the Open Web Application Security Project (OWASP) has guidelines<\/a> for researchers and vendors or organizations. One key recommendation: Researchers may decide to publicly disclose a hole, but it should be done in response to an organization ignoring reported vulnerabilities to put pressure on them to develop and publish a fix.<\/p>\n

OWASP prefers a vulnerability be reported privately to the developers. The organization or individual developer may then choose to publish the details of the vulnerabilities, but, OWASP stresses, this is done at the discretion of the developer or organization, not the researcher.<\/p>\n

Security researchers, OWASP says, should<\/p>\n