Comment: Dr Johannes Ullrich, Dean of Research at the SANS Technology Institute
3CX is a company that sells voice-over-IP systems. Last week, customers complained that 3CX’s VoIP software was triggering anti-virus warnings. 3CX initially dismissed this as a false alarm. Then, earlier this week, SentinelOne published a notice stating that the application contained a backdoor likely created by a state-sponsored actor from North Korea. This backdoor allows full remote access to systems running the 3CX desktop application.
The Electron framework is very popular for quickly creating cross-platform desktop applications. Its use of web technologies allows developers to move from web-based and desktop applications to tools. But Electron, like many similar technologies, relies heavily on open source libraries. These libraries are generally unverified, and developers should be careful when using them. All third-party libraries must be scanned for vulnerabilities, and anti-malware warnings about these libraries must not be ignored.
Two events this week highlight the difficulties faced by security teams in complex modern environments that rely on third-party tools and services. First, 3CX dismissed reports of its application triggering malware alerts. This resulted in a significantly delayed response, which likely caused significant harm to the company’s customers. Secondly, Microsoft Defender classified many Zoom URLs as malicious. This was a genuine false alarm and none of the URLs were malicious. But it flooded security teams with alerts, possibly causing them to ignore valid warnings from the tool.
If companies are affected by the 3CX incident and have installed the malicious version of the VoIP client: They must treat this as an incident. They must not simply remove the VoIP client, carry on as before and pretend that nothing happened. The attackers had access to their systems. This access may have lasted several days. They could install more malware, change configurations and steal data. IT security teams need to not only check for the absence of published signs of compromise, but validate the configuration of each affected system and check network logs for possible data exfiltration or other suspicious connections.
More information was prepared in this podcast: https://isc.sans.edu/podcastdetail.html?podcastid=8432